기준: DOP-C02 시험 가이드오류 제보
Week 14는 한 문장으로 요약된다 — "탐지하고(Detect), 통합하고(Aggregate), 평가하고(Assess), 증명하고(Prove), 자동으로 대응한다(Respond)." GuardDuty가 위협을 탐지하고, Security Hub가 모든 Finding을 ASFF로 통합하며, Config가 리소스 컴플라이언스를 평가하고, Audit Manager·Macie·Inspector·Access Analyzer가 감사 증거·민감 데이터·취약점·외부 노출을 다루며, 이 모두가 EventBridge → SSM Automation/Lambda로 자동 대응에 연결된다. 오늘은 이 다섯 조각을 하나의 그림으로 다시 맞추고, 실전 시나리오 12개로 경계 케이스와 함정을 점검한다.
[데이터 평면 로그·리소스 상태]
│
┌──────────────┬──────────┼──────────────┬─────────────────┐
▼ ▼ ▼ ▼ ▼
GuardDuty Inspector Macie Access Analyzer Config
(위협·행동) (CVE 취약점) (민감데이터) (외부노출·미사용) (리소스 컴플라이언스)
│ │ │ │ │
└──────────────┴──────────┴──── ASFF ────┴─────────────────┘
│
▼
┌──────────────────┐
│ Security Hub │ ← 정규화·중복제거·우선순위·표준평가
│ (단일 진실출처) │ FSBP/CIS/PCI/NIST
└─────────┬────────┘
│
┌───────────────┼────────────────┐
▼ ▼ ▼
Custom Action Automation Rule Findings-Imported
(수동 HITL) (필드갱신만) → EventBridge
│
┌──────────────────┴─────────┐
▼ ▼
SSM Automation Runbook Lambda
(격리·스냅샷·교정) (커스텀 수정)
[감사] Audit Manager → SOC2/HIPAA/PCI 증거 자동수집 → Assessment Report
[거버넌스] Firewall Manager(중앙 WAF/Shield) │ CloudTrail Lake(7년 SQL 조사)
[멀티계정] Delegated Administrator │ [멀티리전] Region/Config Aggregator
핵심 관통 원리는 셋이다. 첫째, 모든 신호가 ASFF로 정규화되어 Security Hub로 수렴한다 — 도구마다 다른 출력을 하나의 언어로 통일하는 게 자동화의 전제다. 둘째, 자동 대응은 작업의 위험도·가역성에 따라 갈린다 — 안전·가역적이면 완전 자동(Imported→Lambda), 파괴적이면 사람 승인(Custom Action HITL). 셋째, 멀티 계정은 Delegated Administrator, 멀티 리전은 Aggregator라는 직교 축으로 통합한다.
| 헷갈리는 짝 | 구분 |
|---|---|
| GuardDuty vs Inspector | 위협·행동 탐지(런타임) vs CVE 취약점 스캔(자산) |
| Config vs CloudTrail | 리소스 상태·형상 vs API 호출·행위 감사 |
| Config vs Audit Manager | 지금 컴플라이언트한가 평가·교정 vs 증명할 증거 수집·보고서 |
| Macie vs Inspector | S3 민감 데이터(PII/PHI) vs 패키지 CVE 취약점 |
| Custom Action vs Automation Rule | 운영자 수동 트리거(HITL) vs Lambda 없는 자동 필드 갱신 |
| Automation Rule vs Imported→Lambda | Finding 필드만 갱신(리소스 수정 불가) vs 실제 리소스 수정 |
| Delegated Administrator vs Aggregator | 멀티 계정 통합 vs 멀티 리전 통합 |
| Suppression Rule vs Trusted IP | Finding 보존+숨김 vs Finding 생성 차단(사각지대 위험) |
💡 관련 이론: 이 전체 스택은 NIST 사이버보안 프레임워크(CSF)의 5함수로 정리된다. 식별 Config·Macie·Access Analyzer / 보호 Firewall Manager·Conformance Pack·KMS / 탐지 GuardDuty·Inspector·Security Hub / 대응 EventBridge→SSM·Lambda / 복구 스냅샷·백업·PITR. 시나리오에서 "어느 단계가 비어 있는가"를 CSF로 진단하면 무엇을 추가할지 빠르게 보인다. NIST CSF는 2014년 미국 행정명령(EO 13636)에 따라 중요 인프라 보호용으로 만들어졌고, 2024년 CSF 2.0에서 "거버넌스(Govern)" 함수가 추가되어 6함수가 됐다 — 거버넌스는 위 다섯을 관통하는 정책·역할·리스크 관리 층으로, AWS에선 Organizations·Control Tower·SCP가 이를 담당한다.
🔍 더 깊이: 이 스택을 관통하는 또 하나의 사상이 심층 방어(defense in depth)다. 단일 통제에 의존하지 않고 탐지·예방·대응을 여러 겹으로 쌓아, 한 겹이 뚫려도 다음 겹이 막는다 — 중세 성의 해자·성벽·내성 구조에서 따온 군사 개념(미 NSA가 정보보안에 도입)이다. Week 14의 도구들은 서로 다른 층을 채운다: Firewall Manager·Config(예방, 잘못된 설정 차단), GuardDuty·Inspector(탐지, 뚫린 뒤 감지), EventBridge→SSM(대응, 자동 격리), CloudTrail Lake(사후, 무슨 일이 있었나). 캐피털 원 사고(Day 1)가 보여준 건 한 겹(WAF 오설정)이 뚫렸을 때 다음 겹(자격 증명 탈취 탐지·자동 무력화)이 없으면 피해가 커진다는 것이다 — 심층 방어의 부재가 곧 단일 장애점이 된다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
GuardDuty가 프로덕션 EC2에서 Backdoor:EC2/C&CActivity.B!DNS(Severity 8.7)를 탐지했다. 사람 개입 없이 ①포렌식 증거 보존 ②네트워크 격리 ③운영팀 알림을 자동화하되, 공격자가 무엇을 했는지 조사할 수 있어야 한다. 올바른 자동 대응 순서는?
문제 2
50개 계정 × 3개 리전 조직에서 모든 계정·리전의 보안 Finding을 Audit 계정 한 화면에서 보려 한다. 올바른 설정 조합은?
문제 3
FSBP 표준의 S3.1(퍼블릭 액세스 차단) 컨트롤이 FAILED인 버킷을 사람 없이 즉시 비공개로 교정하려 한다. 올바른 구현은?
문제 4
PCI DSS·NIST 800-53 컴플라이언스 규칙 묶음을 조직 전체(OU)에 일괄 배포하고, 위반 시 자동 수정도 함께 걸려 한다. 올바른 도구는?
문제 5
자동 Remediation을 켰는데 같은 리소스가 끊임없이 수정-재위반(flapping)하며 API 스로틀과 비용 폭증이 발생한다. 원인 진단과 안전장치는?
문제 6
ECR에 컨테이너 이미지를 푸시할 때 OS 패키지뿐 아니라 npm/pip 의존성의 CVE까지 자동 스캔하고, 새 CVE가 공개되면 이미 푸시된 이미지를 자동 재평가하려 한다. 올바른 선택은?
문제 7
S3 데이터 레이크(수백 TB)에서 카드번호·SSN을 자동 발견하되 비용을 통제하려 한다. 올바른 접근은?
문제 8
외부 계정·공개에 노출된 S3 버킷·IAM Role을 "놓치는 케이스 없이" 발견하고, CloudTrail 활동 기반으로 과도한 IAM 권한을 최소 권한까지 줄이려 한다. 올바른 조합은?
문제 9
SOC2·PCI 감사철마다 사람이 스크린샷·로그를 모으는 작업을 없애고, 증거를 상시 자동 수집해 감사인에게 보고서로 제출하려 한다. 올바른 도구는?
문제 10
false positive를 줄이고 싶지만, 그 IP/패턴이 나중에 실제로 침해됐을 때를 대비해 사후 조사용 기록은 남기고자 한다. GuardDuty에서 올바른 선택은?
문제 11
Security Hub에서 운영자가 콘솔에서 특정 Finding을 선택해 직접 대응을 트리거하려 한다(프로덕션 영향이 큰 파괴적 작업이라 사람 판단 필요). 올바른 구성과 발행되는 이벤트 타입은?
문제 12
한 핀테크 조직의 종합 요구: ①멀티 계정 전체에 위협 탐지 자동 적용(신규 계정 포함) ②모든 Finding을 한 화면 통합 ③S3 PII 발견 ④컨테이너 CVE 스캔 ⑤외부 노출 탐지 ⑥7년 보안 사고 SQL 조사 ⑦멀티 계정 WAF 중앙 관리. 각 요구를 올바른 서비스에 매핑한 것은?
🎯 시나리오 (종합 진단 연습): 한 SaaS 기업이 "보안 도구는 다 켰는데 사고가 났다"고 한다. 조사해 보니 GuardDuty·Security Hub·Config가 모두 활성이고 Finding도 쌓이는데, 아무런 자동 대응이 없어 운영자가 수천 개 알림에 묻혀 진짜 Critical을 놓쳤다. CSF로 진단하면 탐지(Detect)는 충분하나 대응(Respond)이 비어 있다. 처방: ① Security Hub Automation Rule로 저위험 Finding을 자동 억제해 노이즈를 줄이고(알람 피로·기저율 오류 완화), ② Critical+특정 타입은 EventBridge→SSM Runbook으로 완전 자동 격리, ③ 파괴적 작업은 Custom Action으로 HITL, ④ Macie로 어느 버킷에 PII가 있는지 먼저 식별(Identify)해 우선순위를 정한다. "도구를 켜는 것"과 "탐지를 대응으로 잇는 것"은 다른 일이며, 후자가 빠지면 탐지는 소음일 뿐이다.
종합 시나리오 - 엔터프라이즈 케이스: Week 1~14의 CI/CD·IaC·모니터링·보안을 하나의 엔터프라이즈 사례로 엮어 실전 적용을 점검한다.