기준: SCS-C03 시험 가이드오류 제보
이번 주는 "로깅 그 자체"가 아니라 쌓인 로그를 어떻게 신호로, 신호를 어떻게 대응으로 바꾸는가를 다뤘다. 오늘은 네 날의 도구들 — CloudWatch(임계 탐지), Security Hub(집계·정규화·점수), Athena/OpenSearch/Logs Insights(분석), EventBridge/Security Lake(자동화·통합) — 을 하나의 흐름으로 꿰고, 시험에서 도구를 헷갈리게 만드는 경계들을 정리한다. 핵심은 개별 기능 암기가 아니라 "이 요구에는 왜 이 도구가 정답이고 저 도구는 왜 아닌가"를 즉답하는 것이다.
[수집] [탐지] [집계·정규화] [분석] [자동화·대응]
CloudTrail ─┐ CloudWatch ─┐
VPC Flow ───┼─▶ Metric Filter│ Security Hub ─┐ Athena(S3,사후)
ELB/R53 ────┤ + Alarm ├──결과──▶ (ASFF 정규화) ├──▶ Logs Insights ──┐
앱 로그 ─────┘ GuardDuty ───┤ 보안점수/표준 │ OpenSearch │
Inspector ───┤ (CIS/FSBP) │ (준실시간) │
Macie ───────┘ │ ▼
└──▶ EventBridge ──▶ SNS(알림)
(라우팅) ──▶ Lambda/SSM(교정)
──▶ Step Functions(오케스트레이션)
[통합 저장] Security Lake: 위 원시 로그들을 OCSF/Parquet로 정규화해 S3 데이터 레이크로 — Athena/OpenSearch/SIEM이 단일 스키마로 질의
이 흐름은 NIST CSF의 Detect(탐지) 와 Respond(대응) 기능을 AWS 서비스로 사상(map)한 것이다. CloudWatch/GuardDuty는 탐지, Security Hub는 탐지 결과의 집계·평가, EventBridge는 대응의 오케스트레이션을 담당한다. 시험 문제는 보통 "이 요구가 탐지인가, 집계인가, 분석인가, 대응인가"를 먼저 식별하면 후보 서비스가 좁혀진다.
시험장에서 실제로 돌려야 하는 것은 위 그림이 아니라 질문의 순서다. 지문을 읽고 아래 순서대로 물으면 대부분의 문항에서 후보가 하나로 줄어든다.
① 요구가 무엇을 하려는 것인가?
├─ "발견하고 싶다" → 탐지 (②로)
├─ "모아서 보고 싶다" → 집계 → Security Hub (컨트롤이면 + Config)
├─ "캐묻고 싶다" → 분석 (③으로)
└─ "자동으로 조치하고 싶다" → 대응 → EventBridge (+ Lambda/SSM/Step Functions)
② 무엇을 탐지하나?
├─ 특정 로그 패턴의 횟수 → CloudWatch 지표 필터 + 알람
├─ 위협 행위·악성 통신 → GuardDuty
├─ 소프트웨어 취약점 → Inspector
├─ 민감 데이터 → Macie
├─ 외부 노출 권한 → IAM Access Analyzer
├─ 구성이 기준을 벗어남 → Config / Security Hub 표준
└─ 평소와 다른 메트릭 → CloudWatch Anomaly Detection
③ 데이터가 어디 있고 질문의 시제는?
├─ CloudWatch Logs + "지금" → Logs Insights
├─ S3 + "그때"(일회성·저비용) → Athena (+ 파티션·Parquet)
├─ 인덱스 + "계속"(상시 대시보드) → OpenSearch
└─ 조직 전역 원시 로그 + 단일 스키마 → Security Lake(OCSF)
이 트리에서 실수가 가장 많이 나는 분기는 ①의 첫 갈래다. "탐지"와 "집계"를 구분하지 못하면 Security Hub와 GuardDuty 사이에서 흔들린다. 판별법은 간단하다 — 지문이 "무엇이 일어났는지 알아내라"면 탐지, "이미 여러 도구가 알아낸 것을 한곳에서 보라"면 집계다.
두 번째로 실수가 많은 곳은 ③이다. "로그 분석"이라는 같은 표현이 세 도구 모두에 걸리므로, 지문에서 데이터 위치와 비용/즉시성 언급을 찾아야 한다. "비용을 최소화"는 Athena, "즉시·별도 적재 없이"는 Logs Insights, "상시 대시보드·전문검색"은 OpenSearch로 거의 예외 없이 이어진다.
헷갈리기 쉬운 영역. 무엇을 탐지하느냐로 구분한다.
| 요구 | 정답 | 이유 |
|---|---|---|
| 특정 로그 패턴(루트 사용, 로그인 실패 N회)을 임계로 경보 | CloudWatch Metric Filter + Alarm | 단일 로그 그룹 내 패턴 → 숫자 → 임계 |
| 악성 IP 통신, 크립토마이닝, 자격증명 이상 사용 | GuardDuty | 위협 인텔·ML 기반 행위 탐지 |
| EC2/컨테이너/Lambda의 CVE 취약점 | Inspector | 소프트웨어 취약점 스캔 |
| S3의 PII/민감데이터 발견 | Macie | 데이터 분류·발견 |
| 시간대마다 변동하는 메트릭의 "평소와 다름" | CloudWatch Anomaly Detection | 임의 메트릭 ML 밴드 |
| 외부에 의도치 않게 공유된 리소스(버킷/역할) | IAM Access Analyzer | 외부 접근 가능성 분석 |
⚠️ 함정: "보안 이상을 탐지"라는 모호한 표현에 GuardDuty를 반사적으로 고르면 안 된다. 무엇이 이상인지가 결정한다 — 특정 API 호출 임계면 CloudWatch, 위협 행위면 GuardDuty, 취약점이면 Inspector, 민감데이터면 Macie.
데이터 위치와 시간성이 결정한다.
| 요구 | 정답 | 핵심 기준 |
|---|---|---|
| S3에 쌓인 대용량 로그를 일회성 SQL로, 저비용 | Athena | 데이터=S3, 사후·일회성 |
| CloudWatch Logs에 있는 로그를 즉시 질의 | Logs Insights | 데이터=CloudWatch Logs, 즉시 |
| 준실시간 대시보드·전문검색·반복 상관 | OpenSearch | 인덱싱, 상시 운영 |
| 조직 전역 로그를 단일 정규화 스키마로 | Security Lake(+Athena/OpenSearch) | OCSF 정규화 저장소 |
🎯 시나리오: "90일 전 사고를 조사하는데 로그는 S3에만 있고 비용을 최소화"한다 → Athena + 파티셔닝. "로그가 CloudWatch Logs에 있고 사고 대응 중 즉시" → Logs Insights. "SOC가 상시 대시보드로 모니터링" → OpenSearch. 같은 "로그 분석"이라도 위치·시간성으로 답이 갈린다.
세 서비스가 "조직 보안 상태"라는 비슷한 단어 주변에 모여 헷갈린다.
Config → 구성 평가(설정이 규정에 맞나) → Security Hub 표준의 엔진
Security Hub → 탐지 결과 집계·점수(대시보드) → ASFF 포맷
Security Lake→ 원시 로그 정규화 저장소(분석용) → OCSF 포맷
⚠️ 함정: "여러 소스를 정규화"라는 말이 둘 다에 쓰여 헷갈린다. 탐지 결과의 정규화·집계·점수는 Security Hub(ASFF). 원시 로그의 정규화 저장·분석은 Security Lake(OCSF). 포맷 이름(ASFF vs OCSF)이 결정적 단서다.
시나리오 A — 루트 사용 즉시 탐지 및 알림
$.userIdentity.type = "Root" ..., metricValue=1, defaultValue=0.Sum, period 300, threshold ≥1, notBreaching, N=1/M=1.Average 통계, defaultValue 누락, 단일 리전 trail, SNS KMS 키 정책 누락.시나리오 B — 다계정 보안 상태 일원화
시나리오 C — CRITICAL 결과 자동 교정
source=aws.securityhub, Severity.Label=CRITICAL, Workflow.Status=NEW.시나리오 D — 사후 포렌식
시나리오 E — 로그가 조용해졌다
StopLogging 이벤트 검색) → CloudWatch Logs로 이벤트가 들어오고 있나 → 지표 필터가 매칭되고 있나(메트릭 그래프) → 알람 상태 이력 → SNS 구독·KMS 키 정책.treat-missing-data=breaching)으로 로그 유입 중단 자체를 경보로 만든다.시나리오 F — 알림이 너무 많아 아무도 안 본다
시나리오 G — 같은 컨트롤이 수백 건 실패한다
성숙한 조직은 이들을 계층으로 운영한다. 핫(최근, 빈번 질의)=OpenSearch, 웜/콜드(장기, 가끔 조사)=S3+Athena, 정규화 허브=Security Lake, 결과 평면=Security Hub, 자동화 신경계=EventBridge. 한 도구가 모든 걸 하지 않는다는 것, 그리고 각 도구의 비용 모델(상시 클러스터 vs 종량 스캔)이 계층화 결정을 좌우한다는 것이 실무·시험 공통의 통찰이다.
week8 전체에서 반복해 나온 주제가 하나 있다 — 이 배관은 오류 없이 멈춘다. 어느 지점이 끊겨도 화면에는 아무 표시가 없고, 오히려 평온해 보인다. 시험 문항의 상당수가 정확히 이 지점을 짚는다.
| 끊긴 곳 | 증상 | 확인 방법 | 구조적 해법 |
|---|---|---|---|
| trail이 CloudWatch Logs로 안 감 | 지표 필터가 항상 0 | 메트릭 그래프가 평평 | 하트비트 알람 |
| 로그 그룹 KMS 키 정책 누락 | 로그 수집 실패 | 키 정책의 서비스 주체 | 배포 시 정책 검증 |
defaultValue·Sum 미설정 | 알람이 발동 안 함 | 알람 이력이 비어 있음 | 표준 템플릿(IaC) |
| SNS 토픽 KMS 정책 누락 | 알람은 ALARM인데 알림 없음 | 알람 상태 vs 수신 이력 대조 | 합성 이벤트 도달 시험 |
| Config 레코더 중지/범위 축소 | 컨트롤이 NO_DATA, 점수는 상승 | 평가된 컨트롤 수 추적 | 점수와 컨트롤 수를 함께 본다 |
| Security Hub 집계 리전 미지정 | 다른 리전 CRITICAL을 못 봄 | 리전별 결과 수 확인 | 집계 리전 구성 |
| 크로스계정 버스 권한 한쪽만 | 이벤트가 중앙에 안 옴 | DLQ 적체 여부 | DLQ 적체 자체를 알람으로 |
| 대응 핸들러 실패 | 결과는 있는데 조치가 없음 | Step Functions 실행 이력 | 재시도 + DLQ + 아카이브 재생 |
| 주기 작업 중단 | 상태형 위험이 방치됨 | 마지막 성공 실행 시각 | 실행 하트비트 |
| 데이터 이벤트 미활성화 | "무엇을 가져갔나"에 답 불가 | trail 이벤트 셀렉터 | 사전 활성화(소급 불가) |
마지막 행이 특히 중요하다. 로깅은 소급 적용되지 않는다. 다른 실패는 발견 후 고치면 그 시점부터 정상화되지만, 데이터 이벤트를 켜지 않았던 기간은 영원히 공백으로 남는다. 이것이 week7에서 배운 원칙이 week8에서도 그대로 유효한 이유다.
클라우드 침해 사후 보고서에서 되풀이되는 두 문장이 있다 — "신호는 이미 로그에 있었다"와 "경보는 울렸지만 아무도 대응하지 않았다." 2013년 Target 침해에서는 보안 도구의 경보가 발생했으나 대응으로 이어지지 않은 점이 미 상원 보고서 등을 통해 공개적으로 지적됐고, 대형 클라우드 침해 사례들에서도 침해 자체보다 발견까지 걸린 시간이 반복해 문제로 꼽혔다. 두 문장은 서로 다른 실패처럼 보이지만 원인은 하나다 — 신호가 사람과 자동화에 닿는 경로가 설계되지 않았다. week8이 다룬 것은 결국 그 경로다. 로그를 숫자로 바꾸는 변환(day1), 여러 판단을 한 스키마로 모으는 정규화(day2), 쌓인 것을 캐묻는 질의(day3), 그리고 신호를 조치로 잇는 라우팅(day4). 어느 한 구간이 없으면 나머지가 전부 있어도 결과는 "탐지하지 않은 것"과 같아진다.
네 날 모두에서 같은 문제가 다른 얼굴로 나왔다. day1에서는 알람이 너무 많아지는 문제, day2에서는 컨트롤 결과가 리소스 수만큼 늘어나는 문제, day4에서는 자동화가 오히려 알림을 늘리는 문제. 시험에서는 "노이즈를 줄이되 사각지대는 만들지 마라"라는 정형화된 문장으로 나온다.
정답과 오답의 구분선은 하나다 — 탐지를 줄이는가, 도달을 줄이는가.
| 접근 | 정답/오답 | 이유 |
|---|---|---|
| 등급별 채널 분리 | 정답 | 탐지는 전부 유지, 도달만 조정 |
| N of M·복합 알람으로 지속성 요구 | 정답 | 단발 오탐만 걸러짐 |
| 승인된 예외를 사유와 함께 억제 | 정답 | 결과·기록은 남음 |
| 중간 이하 등급을 집계해 요약 | 정답 | 추세는 반드시 확인 |
| 티켓을 리소스당으로 묶기 | 정답 | 처리 가능한 단위로 변환 |
| 지표 필터·알람 삭제 | 오답 | 영구 사각지대 |
| 임계값을 크게 올리기 | 오답 | low-and-slow 공격에 투명해짐 |
| 표준·통합 비활성화 | 오답 | 원천 가시성 상실 |
| 탐지기의 신뢰 목록에 넣기 | 오답 | 결과를 만들지 않는다 |
| 전부 온콜로 보내기 | 오답 | 결과적으로 아무도 안 봄 = 탐지 중단 |
마지막 두 행이 짝을 이룬다는 점이 흥미롭다. 너무 적게 보내는 것과 너무 많이 보내는 것은 같은 결과에 도달한다 — 신호가 사람에게 닿지 않는다. 알림 설계는 "얼마나 보낼까"가 아니라 "받는 사람이 매번 행동할 수 있는 양인가"로 판단해야 한다.
defaultValue=0 + Alarm Sum이 카운트 탐지의 짝. 단, 하트비트 알람만 예외(breaching).SECURITY_CONTROL)도 함께.시험이 "가장 먼저 해야 할 것"을 묻는 형태로 나올 때를 대비해, 구축 순서를 한 줄로 정리해 둔다.
0. 로그 원본 확보 CloudTrail(전 리전·조직) → S3(별도 Log Archive 계정)
+ 알람 걸 로그만 CloudWatch Logs로 이중 전달
※ 소급 불가 — 가장 먼저, 데이터 이벤트 필요 여부도 지금 결정
▼
1. 구성 평가 기반 각 계정·리전 AWS Config 레코더 활성화
※ 이것 없이는 Security Hub 표준이 전부 무의미
▼
2. 임계 탐지 CIS 모니터링 세트: 지표 필터 + 알람 + 하트비트
▼
3. 집계·표준 Security Hub 활성화 → CIS → FSBP → 통합 컨트롤 결과
→ 위임 관리자 + 중앙 구성 + 집계 리전
▼
4. 질의 능력 Athena 테이블(파티션 프로젝션) + 작업 그룹 가드레일
(상시 감시가 필요하면 Firehose → OpenSearch 추가)
▼
5. 대응 자동화 EventBridge 규칙 → 가역 조치 자동 / 비가역은 승인 게이트
+ DLQ + 아카이브 + 등급별 라우팅
▼
6. 조직 전역 표준화 Security Lake(OCSF) — 서드파티 SIEM·다계정 분석이 필요할 때
이 순서에는 논리가 있다. 아래 단계는 위 단계 없이 성립하지 않는다. Config 없이 표준이 없고, 로그 없이 질의가 없으며, 집계 없이 단일 자동화가 없다. 시험에서 "먼저 해야 할 일"을 묻는 문항의 답은 거의 항상 더 아래에 있는 전제다 — "표준 컨트롤이 평가되지 않는다"의 답이 Config 활성화인 것처럼.
Week 8의 한 문장: "로그는 쌓는 것이 아니라 신호로 변환하고, 정규화해 모으고, 질의하고, 자동으로 대응하는 것이다." CloudWatch는 단일 신호 임계, Security Hub는 결과 집계·점수, Athena/OpenSearch/Logs Insights는 위치·시간성에 따른 분석, EventBridge는 대응 라우팅, Security Lake는 OCSF 정규화 허브.
시험 대비의 관점에서 이번 주가 남기는 것은 세 가지 반사다.
그리고 실무의 관점에서 남는 것은 하나다. 이 파이프라인은 만든 날이 가장 잘 동작하고, 이후로는 조용히 낡아 간다. Config 범위가 좁아지고, 새 계정이 자동 등록에서 빠지고, 알림 채널의 구독자가 퇴사하고, 대응 핸들러의 권한이 회수된다. 어느 것도 오류를 내지 않는다. 그래서 탐지 파이프라인의 마지막 구성 요소는 언제나 파이프라인 자신을 감시하는 장치 — 하트비트 알람, DLQ 적체 감시, 주기 작업의 실행 기록, 그리고 정기적인 합성 이벤트 도달 시험 — 이다. week9에서는 이 배관 위에 실제 탐지 서비스들(GuardDuty·Detective·Inspector)을 올리고, 그것들이 만든 결과를 어떻게 읽는지를 다룬다.
defaultValue=0 + Sum)과 하트비트 알람의 예외(breaching)를 구분하는가선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
"S3에 PII가 저장되어 있는지 발견", "EC2의 CVE 취약점 스캔", "악성 IP와의 통신 탐지"에 각각 대응하는 서비스 조합으로 옳은 것은?
문제 2
로그가 CloudWatch Logs에 있고, 사고 대응 중 별도 적재 없이 즉시 질의해 AccessDenied 추세를 보려 한다. 가장 적합한 도구는?
문제 3
여러 탐지 서비스(GuardDuty, Inspector, Macie)의 결과를 단일 포맷으로 집계하고 CIS/FSBP 표준 합격률을 보안 점수로 보려 한다. 그리고 별개로, 조직 전역 *원시 로그*를 OCSF 표준으로 정규화해 SIEM이 질의하게 하려 한다. 각각의 서비스는?
문제 4
CloudTrail 로그로 5분 동안 콘솔 로그인 실패 5회 이상을 탐지하는 알람이 동작하지 않는다. 구성에서 함께 점검해야 할 두 가지는?
문제 5
GuardDuty가 EC2 크립토마이닝을 탐지하면 자동으로 인스턴스를 격리하고 포렌식용 EBS 스냅샷을 만든 뒤 보안팀에 알리는 파이프라인을 구성한다. 운영 위생상 반드시 고려할 것을 모두 고른 묶음은?