🔒 보안 & 모니터링

왜 보안 모니터링을 구축해야 할까?

새벽 3시, 여러분의 AWS 계정에서 이상한 일이 벌어지고 있습니다. 누군가 여러분의 IAM 자격 증명을 이용하여 도쿄 리전에서 EC2 인스턴스 20대를 시작했습니다. 목적은 암호화폐 채굴. 아침에 출근해서 AWS 콘솔을 열었을 때, 하루 만에 $500의 청구서가 쌓여 있습니다.

이것은 가상의 이야기가 아닙니다. GitHub에 실수로 AWS Access Key를 커밋하면, 15분 이내에 봇이 스캔하여 해당 키로 EC2 인스턴스를 대량 생성합니다. 키가 노출된 지 1시간 만에 수천 달러의 비용이 발생한 사례는 수없이 보고되고 있습니다.

만약 보안 모니터링 체계가 구축되어 있었다면 어떨까요?

• CloudTrail이 비정상적인 API 호출(도쿄 리전에서의 RunInstances)을 기록합니다.
• GuardDuty가 "평소와 다른 리전에서의 EC2 대량 생성"을 위협으로 탐지하고 즉시 알림을 보냅니다.
• CloudWatch 알람이 비용 이상 증가를 감지하여 경고합니다.
• Security Hub가 모든 보안 이벤트를 통합하여 보안 점수와 우선순위를 제공합니다.

새벽 3시 5분에 이메일/슬랙 알림을 받고, 즉시 해당 IAM 키를 비활성화하면 피해를 최소화할 수 있습니다.

이 실습에서는 AWS의 보안 모니터링 서비스 5가지를 직접 설정하고 연동합니다:

• CloudWatch: 리소스 메트릭 모니터링 + 알람 설정
• CloudTrail: 모든 API 호출 기록(감사 추적)
• GuardDuty: 머신러닝 기반 위협 탐지
• AWS Config: 리소스 구성 변경 추적 + 규정 준수 평가
• Security Hub: 위 서비스들의 결과를 통합하는 보안 대시보드

아키텍처 개요

보안 모니터링 흐름

비용 예측

Step 1: CloudWatch 대시보드 및 알람 설정

CloudWatch는 AWS 리소스의 "건강 진단 도구"입니다. CPU 사용률, 네트워크 트래픽, 디스크 I/O 등의 메트릭을 실시간으로 수집하고, 임계값을 초과하면 알람을 발생시킵니다.

대시보드를 먼저 만들어 핵심 지표를 한눈에 볼 수 있게 구성합니다. 그런 다음 CPU 사용률 80% 이상 시 알림을 보내는 알람을 생성합니다. 프로덕션 환경에서는 CPU, 메모리, 디스크, 네트워크 등 다양한 지표에 대한 알람을 설정하고, 복합 알람(Composite Alarm)으로 알림 피로를 줄입니다.

SNS(Simple Notification Service) 주제를 생성하여 이메일로 알림을 받습니다. 실무에서는 SNS → Lambda → Slack/PagerDuty 경로로 즉각적인 알림을 구성합니다.

# 대시보드 생성
aws cloudwatch put-dashboard \
  --dashboard-name lab-security-dashboard \
  --dashboard-body '{"widgets":[{"type":"metric","properties":{"metrics":[["AWS/EC2","CPUUtilization"]],"period":300}}]}'
 
# 알람 생성
aws cloudwatch put-metric-alarm \
  --alarm-name high-cpu-alarm \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1

Step 2: CloudTrail 트레일 생성

CloudTrail은 AWS 계정에서 발생하는 모든 API 호출을 기록하는 감사 서비스입니다. "누가, 언제, 어디서, 어떤 API를 호출했는가"를 완벽하게 추적합니다. 보안 사고 조사의 가장 첫 번째 단계는 항상 CloudTrail 로그 분석입니다.

관리 이벤트(Management Events)는 리소스 생성/삭제/변경 같은 제어 영역 API를 기록합니다. 데이터 이벤트(Data Events)는 S3 객체 읽기/쓰기, Lambda 함수 호출 같은 데이터 영역 API를 기록합니다. 데이터 이벤트는 양이 많아 비용이 발생하므로, 보안에 민감한 버킷에만 선택적으로 활성화합니다.

Step 3: GuardDuty 활성화

GuardDuty는 머신러닝 기반 위협 탐지 서비스입니다. CloudTrail 로그, VPC Flow Logs, DNS 쿼리 로그를 분석하여 비정상적인 패턴을 자동으로 감지합니다. 에이전트 설치나 인프라 변경 없이, 활성화만 하면 즉시 보호가 시작됩니다.

GuardDuty가 탐지할 수 있는 위협 유형은 다양합니다. 비정상적인 API 호출 패턴(자격 증명 도용), 암호화폐 채굴 활동, 포트 스캔, C&C(Command and Control) 서버와의 통신 등을 감지합니다.

"샘플 결과 생성" 기능을 사용하면 실제 위협 없이도 다양한 탐지 유형의 예시를 확인할 수 있습니다. 이를 통해 알림 파이프라인이 정상 동작하는지 테스트합니다.

# GuardDuty 활성화
aws guardduty create-detector --enable
 
# 샘플 결과 생성 (테스트용)
DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)
aws guardduty create-sample-findings --detector-id $DETECTOR_ID \
  --finding-types "Recon:EC2/PortProbeUnprotectedPort"

보안 서비스 역할 비교

5가지 보안 서비스의 역할이 혼동될 수 있으므로, 각 서비스가 "어떤 질문에 답하는가"를 정리합니다.

이 5가지 서비스를 모두 활성화하고 Security Hub로 통합하면, AWS 환경의 보안 상태를 360도 관점에서 모니터링할 수 있습니다.

Step 4: AWS Config 규칙 설정

AWS Config는 리소스의 "구성 상태"를 지속적으로 추적하는 서비스입니다. CloudTrail이 "누가 무엇을 했는가"를 기록한다면, Config는 "리소스의 현재 상태가 올바른가"를 평가합니다.

이 실습에서는 보안에 중요한 두 가지 규칙을 설정합니다. S3 퍼블릭 읽기 차단 규칙은 실수로 데이터가 공개되는 것을 방지하고, IAM 루트 액세스 키 확인 규칙은 루트 계정에 액세스 키가 생성되어 있지 않은지 확인합니다 (루트 계정에는 액세스 키를 사용하지 않는 것이 보안 모범 사례입니다).

Step 5: Security Hub 활성화 및 보안 점수 확인

Security Hub는 위에서 설정한 모든 보안 서비스의 결과를 하나의 대시보드로 통합합니다. CloudTrail, GuardDuty, Config, 그리고 서드파티 보안 도구의 결과까지 모아서, 보안 점수(Security Score)를 산출하고 우선순위가 높은 문제를 먼저 해결하도록 안내합니다.

"AWS 기본 보안 모범 사례(AWS Foundational Security Best Practices)" 표준을 활성화하면, AWS가 권장하는 보안 설정을 자동으로 평가합니다. 각 항목에는 심각도(CRITICAL, HIGH, MEDIUM, LOW)가 부여되며, CRITICAL과 HIGH 항목을 우선적으로 해결해야 합니다.

# Security Hub 활성화
aws securityhub enable-security-hub \
  --enable-default-standards
 
# 보안 점수 확인
aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}' \
  --max-items 5

트러블슈팅 가이드

핵심 개념 확인

완성 후 테스트 가이드

실무에서 자주 묻는 질문

Q: 이 모든 보안 서비스를 활성화하면 비용이 많이 들지 않나요?

의외로 대부분의 서비스가 무료이거나 매우 저렴합니다. CloudTrail의 첫 번째 트레일(관리 이벤트)은 무료, GuardDuty는 30일 무료 후에도 분석량 기준으로 과금(소규모 계정은 월 몇 달러), CloudWatch 알람은 10개 무료, Security Hub는 첫 30일 무료입니다. Config만 규칙 평가당 $0.003로 가장 비용이 발생하지만, 보안 사고 한 건의 피해액에 비하면 극히 작은 투자입니다.

Q: 알림이 너무 많이 오면 어떻게 하나요?

"알림 피로(Alert Fatigue)"는 실제로 심각한 문제입니다. 모든 알림에 둔감해지면 정말 중요한 알림도 놓치게 됩니다. 해결 방법: (1) CloudWatch 복합 알람으로 여러 조건을 AND 조합 (2) GuardDuty에서 신뢰할 수 있는 IP/계정을 허용 목록에 추가 (3) Security Hub에서 CRITICAL/HIGH만 알림 설정 (4) 알림 채널을 분리(CRITICAL → PagerDuty 호출, HIGH → Slack, MEDIUM/LOW → 이메일 다이제스트).

Q: IAM Access Key가 GitHub에 노출되었을 때 가장 먼저 해야 할 일은?

(1) 즉시 해당 키를 비활성화합니다(삭제가 아님 — 삭제하면 어떤 리소스에 영향이 있는지 추적이 어려워집니다). (2) CloudTrail에서 해당 키로 수행된 모든 API 호출을 확인합니다. (3) 의심스러운 리소스(EC2 인스턴스, IAM 사용자 등)를 정리합니다. (4) 새 키를 생성하고 모든 애플리케이션을 업데이트합니다. (5) 마지막으로 이전 키를 삭제합니다.

확장 아이디어

1. EventBridge + Lambda 자동 대응: GuardDuty 위협 탐지 시 EventBridge를 통해 Lambda 함수를 트리거하여, 의심스러운 IAM 키를 자동으로 비활성화하는 자동 대응을 구현합니다.
2. CloudWatch Logs Insights 분석: CloudTrail 로그를 CloudWatch Logs로 전송하고, Logs Insights로 "비정상적인 시간대의 API 호출", "실패한 인증 시도" 등을 쿼리합니다.
3. 멀티 계정 보안 관리: AWS Organizations + GuardDuty 관리자 계정을 설정하여, 여러 계정의 보안 탐지를 중앙에서 관리합니다.
4. Inspector 취약점 스캔: Amazon Inspector를 활성화하여 EC2 인스턴스와 Lambda 함수의 소프트웨어 취약점을 자동으로 스캔합니다.
5. SIEM 연동: Security Hub의 결과를 Splunk, Elastic SIEM 등 외부 보안 분석 도구로 내보내어 고급 위협 분석을 수행합니다.

보안 사고 대응 시나리오

보안 모니터링 체계가 구축된 후, 실제 보안 사고가 발생했을 때 어떤 순서로 대응하는지 시나리오를 통해 이해합니다.

학습 정리

리소스 정리