CloudTrail·Config·중앙 로깅으로 만드는 감사와 구성 추적
_Category: Logging & Monitoring_
보안 사고가 발생한 후 가장 먼저 듣는 말은 "로그 있어요?"입니다. 로그가 없으면 무슨 일이 있었는지 알 수 없고, 변조되었다면 신뢰할 수 없습니다. SCS-C03는 "어떻게 기록하고, 어떻게 보호하고, 어떻게 활용하는가"를 반복해서 묻습니다. CloudTrail, Config, CloudWatch Logs, EventBridge, Kinesis Data Firehose, Athena, VPC Flow Logs, Audit Manager까지 이어지는 감사·로깅 아키텍처 전체를 살펴봅니다.
---
감사 가능성의 의미와 SCS-C03가 묻는 핵심
감사 가능성(auditability)이란 "누가, 언제, 어디서, 무엇을, 어떻게 했는지" 나중에도 증명할 수 있는 상태입니다. 신뢰받는 감사 기록은 완전성(빠짐없는 기록), 무결성(변조 불가), 가용성(필요할 때 꺼낼 수 있음) 세 가지를 갖춰야 합니다.
SCS-C03 대표 시나리오 패턴입니다.
"모든 API 호출을 기록하고 변조 여부를 감지해야 한다" → CloudTrail + Log File Integrity Validation + S3 Object Lock "리소스 구성이 바뀌었을 때 변경 전·후를 추적해야 한다" → AWS Config Configuration Item "특정 API 호출이 발생하는 즉시 보안팀에 알려야 한다" → CloudTrail + EventBridge + SNS "여러 계정의 로그를 한 곳에 모아야 한다" → Log Archive Account + Kinesis Data Firehose
CloudTrail과 Config는 서로 다른 질문에 답합니다. CloudTrail은 "무슨 일이 있었나?"(API 행동 이력)이고, Config는 "지금 이 리소스가 어떤 상태인가?"(구성 스냅샷·변경 이력)입니다. 시험은 두 서비스를 혼동하도록 유사한 시나리오를 제시하므로 역할 분담을 명확히 이해해야 합니다.
---
CloudTrail의 3가지 이벤트 (Management / Data / Insights)
CloudTrail을 "건물 출입 기록부"에 비유하면 이해가 쉽습니다. 단, 장부에는 세 종류의 기록이 있습니다.
| 이벤트 유형 | 기록 대상 | 기본 활성화 | 예시 | |------------|----------|------------|------| | Management Events | AWS 리소스 관리 API (콘트롤 플레인) | 기본 활성화 (Event History 90일) | CreateBucket, RunInstances, AuthorizeSecurityGroupIngress | | Data Events | 리소스 내 데이터 접근 (데이터 플레인) | 기본 비활성화 (별도 설정 필요) | S3 GetObject/PutObject, Lambda Invoke, DynamoDB GetItem | | Insights Events | 비정상적인 API 활동 패턴 자동 탐지 | 기본 비활성화 (별도 활성화 필요) | 갑자기 급증한 TerminateInstances 호출 수 |
Management Events는 Trail 없이도 콘솔에서 90일치 Event History를 무료로 볼 수 있습니다. 하지만 90일이 지나면 사라지므로 장기 보존하려면 Trail을 만들어 S3에 저장해야 합니다.
Data Events는 S3 버킷, Lambda 함수, DynamoDB 테이블 단위로 선택 활성화합니다. S3 Data Events를 켜지 않으면 GetObject·PutObject는 기록되지 않습니다. 트래픽이 많은 환경에서는 로그 볼륨이 폭발하므로 비용 트레이드오프를 고려하세요.
Insights Events는 과거 7일치 Management Events를 기준선으로 삼아 비정상 API 활동을 자동 탐지합니다. 평소 하루 10건이던 호출이 수천 건으로 급증하면 Insights Event가 생성됩니다. 내부자 위협이나 자격증명 탈취 초기 탐지에 유용합니다.
Event History vs Trail: Event History는 무료이지만 90일 제한, 단일 리전. Trail은 S3 장기 보존, Athena 분석 가능, Multi-Region 설정으로 모든 리전 이벤트를 단일 버킷에 집중합니다.
!CloudTrail 이벤트 3가지 유형
Trail 설계: Multi-Region·Org-wide·Tamper-proof 패턴
Trail 전체 설계에는 세 가지 결정이 필요합니다.
Multi-Region Trail은 "Apply trail to all regions"를 활성화하면 모든 리전 이벤트가 단일 S3 버킷으로 집중됩니다. IAM·STS·CloudFront 등 Global Services 이벤트는 "Include global service events"를 추가로 켜야 합니다.
Org-wide Trail은 Organizations 관리 계정에서 생성하면 멤버 계정 전체에 자동 적용됩니다.
변조 방지(Tamper-proof) 스택이 핵심입니다.
| 보호 수단 | 역할 | |----------|------| | Log File Integrity Validation | 매 시간 Digest 파일(SHA-256 + RSA 서명) 생성 — aws cloudtrail validate-logs로 검증 | | S3 Object Lock Compliance 모드 | 루트 포함 누구도 보존 기간 중 삭제 불가 — "공증된 보관함" | | S3 Object Lock Governance 모드 | 특별 권한(BypassGovernanceRetention) 보유자만 해제 가능 | | S3 MFA Delete | S3 버전 삭제 시 MFA 인증 요구 | | Cross-Account Log Archive | 운영 계정이 로그 버킷에 PutObject만 가능, 삭제 불가 | | KMS SSE-KMS | 로그 내용 기밀성 보호, 키 정책으로 복호화 권한 제어 |
Log Archive Account 패턴의 핵심은 계정 분리입니다. 전용 Log Archive 계정의 S3 버킷에 모든 멤버 계정 로그가 집중되고, 멤버 계정은 PutObject만 허용됩니다. 운영 계정이 침해당해도 공격자는 로그를 삭제하거나 변조할 수 없습니다.
---
AWS Config: 구성 변경 추적과 규정 준수 자동화
AWS Config를 "방 가구 변경 일지"에 비유합니다. 소파가 어디 있었는지, 누가 옮겼는지, 지금 규정된 위치에 있는지를 기록하고 평가합니다.
Configuration Item(CI)은 리소스 상태 스냅샷입니다. 리소스 유형, 속성값, 연결된 다른 리소스, 변경 시각이 포함되며, 변경될 때마다 새 CI가 생성되어 타임라인 형태로 이력을 조회할 수 있습니다. Configuration Recorder는 지원 리소스를 자동 추적하는 엔진으로 리전별로 하나씩 만들어야 합니다.
Config Aggregator는 멀티 계정·멀티 리전 Config 데이터를 집계 계정으로 모아 관리 계정에서 한눈에 확인할 수 있습니다.
Config Rules는 구성이 정책을 충족하는지 자동 평가합니다. Managed Rules(AWS 제공 150개 이상, "restricted-ssh", "s3-bucket-public-read-prohibited" 등), Custom Rules(Lambda 함수로 조직 고유 정책), Conformance Pack(PCI-DSS·HIPAA·NIST 800-53 등 규제별 Rules 묶음 패키지)이 있습니다.
Remediation Actions는 비준수 리소스를 Systems Manager Automation 문서와 연결해 자동 수정합니다.
| 질문 | 답하는 서비스 | |------|-------------| | 누가 이 리소스를 변경했나? | CloudTrail (API 호출자, UserAgent, IP) | | 이 리소스가 언제 어떻게 변경되었나? | Config (CI 타임라인) | | 현재 이 리소스가 정책을 준수하나? | Config Rules |
---
CloudWatch Logs와 EventBridge로 실시간 알림·자동화
CloudTrail 로그를 S3에만 보내면 최대 15분 지연이 발생합니다. 실시간 반응에는 두 경로를 사용합니다.
첫째, CloudWatch Logs 경로입니다. Trail에서 "CloudWatch Logs 전송"을 활성화하면 이벤트가 거의 실시간으로 로그 그룹에 전달됩니다. Metric Filter로 특정 패턴을 감지해 CloudWatch Alarm을 생성하고 SNS로 알림을 보냅니다. 예를 들어 콘솔 로그인 실패를 탐지하는 패턴은 입니다. Subscription Filter는 로그 그룹 스트림을 Kinesis Data Firehose, Kinesis Data Streams, Lambda로 실시간 포워딩합니다.
둘째, EventBridge 경로입니다. EventBridge는 "사건 발생 즉시 울리는 사이렌"입니다. API 호출 수 초 내에 이벤트를 발생시켜 Lambda, SNS, SQS, Step Functions 등을 트리거합니다. CloudTrail → CloudWatch Logs 전달 설정 없이도 바로 동작합니다.
시험 선택 기준입니다. 실시간 API 변경 탐지 → CloudTrail + EventBridge. Config rule은 구성 변경 후 평가 완료까지 수 분 지연 + 준수 상태가 바뀌지 않으면 알림 없음. CloudWatch Logs Metric Filter는 CloudTrail → CWL 전달 설정 추가 필요.
CloudWatch Logs Insights는 SQL 유사 쿼리로 로그를 대화식 분석합니다. 저장된 쿼리를 대시보드에 붙이거나 스케줄 쿼리로 주기 실행할 수 있습니다.
---
중앙 로그 집계 아키텍처 (Log Archive Account · Firehose · OpenSearch · Athena)
수십·수백 개 계정이 각각 로그를 쌓으면 전체 파악이 어렵습니다. Log Archive Account 패턴이 해법입니다. 전용 계정의 S3 버킷에 모든 계정 로그를 집중하고, 멤버 계정은 PutObject만 허용합니다. S3 Object Lock(Compliance 모드) + Org-wide Trail 조합으로 운영 계정 침해 시에도 로그를 안전하게 보존합니다.
실시간 스트리밍 집계에는 Kinesis Data Firehose가 사용됩니다. CloudWatch Logs Subscription Filter → Kinesis Data Firehose → 중앙 S3 버킷 또는 OpenSearch로 실시간 전달합니다. OpenSearch에서는 Kibana 대시보드로 보안 이벤트를 시각화하고 임계값 초과 시 알림을 설정합니다.
대용량 사후 분석에는 Athena가 적합합니다. S3의 CloudTrail 로그나 VPC Flow Logs에 Athena 테이블을 만들면 표준 SQL로 자유롭게 질의합니다. 서버리스 방식으로 간헐적 분석에 비용 효율적입니다.
VPC Flow Logs는 CloudTrail의 네트워크 사이드 보완재입니다. CloudTrail이 API 행동을 기록한다면, VPC Flow Logs는 네트워크 트래픽(IP, 포트, 바이트)을 기록합니다. 두 데이터를 Athena로 조인하면 API 호출자와 네트워크 경로를 교차 분석할 수 있습니다. Flow Logs는 패킷 페이로드를 기록하지 않습니다. 패킷 내용 검사가 필요하면 VPC Traffic Mirroring을 선택합니다.
AWS Audit Manager는 PCI-DSS·HIPAA·SOC 2 등 규제 증거를 Config, CloudTrail, Security Hub에서 자동 수집하고 감사 보고서를 생성합니다.
---
시험에서 헷갈리는 로깅 시나리오
실제 문제에서 자주 등장하는 혼동 포인트입니다.
"모든 S3 객체 접근을 기록해야 한다": Management Events만 켜면 GetObject·PutObject는 기록되지 않습니다. S3 Data Events를 별도 활성화해야 합니다.
"보안 그룹 변경이 발생하면 즉시 알려야 한다": Config rule은 평가 완료까지 수 분 지연이 있고, 이미 비준수 상태였던 리소스에 같은 위반이 반복되면 상태 변화가 없어 알림이 없습니다. CloudTrail + EventBridge가 정답입니다.
"루트 사용자 API 호출이 발생하면 즉시 알려야 한다": CloudTrail(이미 활성화) + EventBridge rule() + SNS 이메일 조합을 선택합니다. GuardDuty는 루트 로그인 자체를 finding으로 생성하지 않고 비정상 패턴만 탐지합니다.
"구성 준수 상태 지속 평가 + 변경 이력 감사": 두 요구사항을 분리합니다. 구성 준수 평가는 Config Rules, 감사 이력은 CloudTrail. Security Hub + GuardDuty는 위협 탐지·집계에 특화되어 이 시나리오에는 부적합합니다.