Day 5 - Week 4 복습: CloudTrail·Config·감사 스택 종합

Week 4의 도구들은 CloudWatch와는 다른 질문에 답한다. CloudWatch가 "지금 무슨 일이 일어나고 있는가"를 실시간으로 보여준다면, 이번 주의 도구들은 "과거에 누가 무엇을 했고, 지금 상태가 규정을 준수하며, 그 증거를 외부 감사관에게 어떻게 제출하는가"라는 사후적·규범적 질문을 다룬다. 보안 사고 대응과 컴플라이언스는 실시간 탐지만큼이나 사후 추적과 증거 체계가 중요하다. 오늘은 CloudTrail, CloudTrail Lake, AWS Config, Audit Manager가 어떤 계층을 이루는지 재조명하고, 출제 시나리오 10개로 마무리한다.

Week 4 핵심 개념 연결 지도

[AWS API 호출 발생]
        │
        ▼
[CloudTrail]  ─→  Event History (90일 무료, 변경 불가)
        │                │
        │                ▼
        │         [S3 Trail]  ─→  Log File Validation (SHA-256 해시 체인)
        │                │              → Athena 쿼리 분석
        │                │              → SIEM 연동 (Splunk, Sumo Logic)
        │                ▼
        │       [CloudTrail Lake]  ─→  SQL 쿼리 (Event Data Store)
        │                │              → 7년 보존 / Organization 통합
        │                │              → 외부 이벤트 수집 가능
        │                ▼
        │       [Insights Events]  ─→  ML: ApiCallRateInsight / ApiErrorRateInsight
        │                              → 7일 baseline 학습 필요
        │
        ▼
[EventBridge default bus]  ─→  Rule 패턴 매칭 → SNS / Lambda / SSM
        (모든 API 호출 자동 전달)
        │
        ▼
[AWS Config]  ─→  Configuration Item (리소스 상태 스냅샷)
        │              → Resource Timeline (변경 이력 시각화)
        │
        ▼
  [Config Rules]  ─→  평가 트리거 (Configuration change | Periodic)
        │              → NON_COMPLIANT 감지
        │              → SNS 알림
        ▼
[Auto Remediation]  ─→  SSM Automation Runbook 자동 실행
        │
        ▼
[Conformance Pack]  ─→  여러 Rule 묶음 (HIPAA/PCI/NIST 기반)
        │              → Organization 전체 배포
        ▼
[AWS Audit Manager]  ─→  Framework → Control → Data Source → Assessment
                         → 자동 증거 수집 (Config/CloudTrail/Security Hub)
                         → PDF/CSV 보고서 출력

💡 관련 이론: 이 스택의 설계는 보안 공학의 심층 방어(Defense in Depth) 원칙과 감사 추적(Audit Trail) 이론을 구현한다. NIST SP 800-92 "Guide to Computer Security Log Management"는 "누가 무엇을 언제 했는지 항상 재구성 가능해야 한다(accountability)"를 핵심 원칙으로 제시한다. CloudTrail이 이 accountability를 위한 원본 데이터를, Log File Validation이 tamper-evidence를, Config가 상태 추적을, Audit Manager가 컴플라이언스 보고를 담당하는 계층 구조다.

핵심 비교표

CloudTrail vs AWS Config

CloudTrail Lake vs S3 Trail + Athena

CloudTrail Lake의 컬럼형 저장소 설계는 OLAP(Online Analytical Processing) 데이터베이스의 표준 접근이다. 로우 기반 저장소(OLTP)가 특정 행의 전체 컬럼을 빠르게 읽는 데 최적화된 반면, 컬럼형 저장소는 특정 컬럼(예: eventName, sourceIPAddress)만 스캔하는 분석 쿼리에서 I/O와 비용을 크게 줄인다. Apache Parquet, Google BigQuery, Amazon Redshift가 같은 원리다. 감사 쿼리는 대부분 "특정 eventName의 모든 행"을 찾는 컬럼 지향 패턴이므로 Lake의 컬럼형 저장이 유리하다.

Config Rule 평가 트리거 비교

Configuration change 트리거는 AWS Config가 CloudTrail 이벤트를 소비해서 리소스 변경을 감지하고 CI(Configuration Item)를 생성한 직후 Rule을 평가한다. 따라서 CloudTrail이 정상 동작하지 않으면 Config Rule의 configuration change 트리거도 지연된다. Periodic 트리거는 이 의존성이 없어 Config 서비스 내부 스케줄러로 동작한다. 외부 시스템 상태(Credential report, IAM 사용자 목록)를 기반으로 하는 Rule은 "설정 변경"이 없어도 점검이 필요해 Periodic이 맞다.

Audit Manager vs Config vs Trusted Advisor

Audit Manager가 자동화하는 "지속적 컴플라이언스(Continuous Compliance)" 개념은 NIST SP 800-137 "Information Security Continuous Monitoring"에서 이론적 기반을 가진다. 연 1회 점검식 감사(snapshot audit)에서 상시 증거 수집(continuous evidence collection)으로의 전환이 핵심이다. PCI-DSS v4.0(2022년 출시)은 연속 모니터링을 명시적으로 권고하는 방향으로 바뀌었고, Audit Manager의 Assessment 상시 실행이 이 요구사항을 충족하는 표준 구현이다.

다른 클라우드 플랫폼과의 비교

GCP의 Cloud Audit Logs는 CloudTrail과 유사하지만 Data Access 로그가 기본 비활성화이고, 활성화 시 Cloud Logging 비용에 포함된다는 점이 다르다. Azure Activity Log는 구독 레벨의 컨트롤 플레인 작업을 90일 보관(기본)하며, 장기 보관은 Log Analytics Workspace나 Storage Account로 내보내야 한다는 점이 CloudTrail S3 Trail과 유사하다. 세 플랫폼 모두 "기본 감사 로그는 있지만 데이터 플레인(객체 접근) 로그는 별도 활성화 + 추가 비용"이라는 구조는 동일하다.

Organization Trail의 내부 동작과 거버넌스 패턴

Organization Trail이 켜지면 멤버 계정에서 발생하는 모든 이벤트가 관리 계정의 S3 버킷으로 집약된다. 멤버 계정 사용자는 이 Trail을 수정하거나 삭제할 수 없다. 이 잠금(lock) 메커니즘이 보안 거버넌스의 핵심이다.

[Management Account]
  └─ Organization Trail 생성
       ├─ S3 버킷: s3://org-audit-logs/
       │    └─ Prefix: AWSLogs/{org-id}/{account-id}/
       └─ 멤버 계정 전체에 자동 적용
            ├─ Account A: Trail READ-ONLY (삭제/수정 불가)
            ├─ Account B: Trail READ-ONLY
            └─ Account C: Trail READ-ONLY (신규 계정 자동 적용)

가상의 사례로, 2021년 국내 SI 기업 B사는 멤버 계정 담당자가 실수로 Trail을 삭제해 2주간의 감사 로그가 없는 상태가 됐다. 외부 보안 감사에서 이 기간 로그 공백이 발견돼 추가 설명 자료를 수동으로 준비하는 데 상당한 인력이 투입됐다. 이후 Organization Trail을 활성화하고 SCP로 cloudtrail:DeleteTrail, cloudtrail:StopLogging 액션을 멤버 계정에서 Deny하는 정책을 적용했다. Organization Trail이 존재하더라도 추가 SCP로 Trail 조작을 이중으로 차단하는 것이 표준 거버넌스 패턴이다.

CloudTrail Insights: ML 기반 이상 감지의 한계와 적합한 사용 사례

Insights는 7일간 과거 데이터를 baseline으로 학습하고, 현재 API 호출량 또는 에러율이 통계적으로 유의미하게 벗어나면 Insight 이벤트를 생성한다. 두 가지 유형이 있다.

• ApiCallRateInsight: 특정 API의 호출량이 baseline 대비 spike
• ApiErrorRateInsight: 특정 API의 에러율이 baseline 대비 급등

⚠️ 함정: Insights는 7일 학습 기간이 지나야 의미 있는 탐지를 한다. 서비스를 막 배포하거나 트래픽 패턴이 완전히 바뀐 직후에는 false positive가 많다. 또한 Insights는 Trail이 활성화된 계정에서만 동작한다. 그리고 Insights 자체도 별도 비용($0.35/100K analyzed events)이다. 소규모 계정에서는 GuardDuty의 CloudTrail 기반 위협 탐지와 비용 효율성을 비교해보는 것이 좋다. GuardDuty는 CloudTrail을 자동으로 분석하고 Findings를 생성한다는 점에서 Insights와 보완 관계다.

CloudTrail Insights의 ML 알고리즘은 공개되지 않지만, API 호출량 이상 탐지에 적합한 알고리즘은 CUSUM(Cumulative Sum Control Chart)과 EWMA(Exponentially Weighted Moving Average)다. CUSUM은 시계열에서 평균 변화를 누적적으로 감지하는 통계 방법으로, Page(1954)가 제안했다. 소규모 지속적 변화(APT 공격에서 자주 보이는 낮고 느린 데이터 유출)를 감지하는 데 효과적이다. CloudTrail Insights가 밤새 조금씩 이루어진 S3 GetObject 증가를 감지하는 데 이 방식이 쓰일 가능성이 높다.

Auto Remediation과 SSM Automation의 실패 패턴

Auto Remediation은 Config Rule이 NON_COMPLIANT를 감지했을 때 SSM Automation Runbook을 자동으로 실행한다. 실무에서 "작동 안 한다"는 사례의 90%는 세 가지 원인 중 하나다.

1. AutomationAssumeRole 권한 부족: Runbook이 실행될 때 사용하는 IAM Role에 대상 리소스 수정 권한이 없음
2. Runbook 파라미터 매핑 오류: Config Rule의 리소스 ARN이 Runbook의 입력 파라미터로 올바르게 전달되지 않음
3. 리소스가 이미 삭제됨: Rule이 평가한 시점과 Runbook이 실행된 시점 사이에 리소스가 없어짐

가상의 사례로, 2023년 금융권 C사는 s3-bucket-public-read-prohibited Rule에 Auto Remediation을 연결했다. 테스트 환경에서는 잘 동작했는데 프로덕션에서 작동하지 않았다. 조사 결과 AutomationAssumeRole의 S3 버킷 정책 수정 권한(s3:PutBucketPublicAccessBlock)이 테스트 환경 버킷에는 있었지만 프로덕션 버킷에는 Resource ARN 패턴이 달라 권한이 없었다. Config 콘솔의 "Remediation Execution Status" 탭에서 "AutomationExecution failed: Access Denied" 메시지로 원인을 특정했다. AutomationAssumeRole에 Resource: "*"를 쓰는 것은 최소 권한 원칙에 어긋나지만, ARN 패턴 실수를 방지하기 위해 규칙별 역할을 분리하는 것이 더 안전하다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

보안팀이 "누가 프로덕션 S3 버킷에서 고객 PII 데이터를 다운로드했는지" 추적해야 한다. 필요한 CloudTrail 설정은?

• AManagement Events만 활성화하면 GetObject를 포함한 모든 S3 접근이 컨트롤 플레인 이벤트로 기록되어 충분하다
• BS3 Data Events 활성화 — 특정 버킷의 GetObject/PutObject 추적
• CCloudTrail Insights를 활성화해 비정상적 다운로드 spike를 ML로 감지하면 누가 받았는지 식별된다
• DGuardDuty S3 Protection을 켜면 의심스러운 데이터 접근을 Finding으로 만들어 다운로드 주체까지 특정한다

문제 2

Root 사용자가 콘솔에 로그인하면 즉시 SNS 알림 + Slack 통보를 자동화하려 한다. 어떤 도구 조합이 가장 적합한가?

• ACloudTrail 로그를 CloudWatch Logs로 보낸 뒤 { $.userIdentity.type = "Root" } Metric Filter + CloudWatch Alarm으로 SNS 발송
• BEventBridge Rule (CloudTrail 이벤트 패턴 userIdentity.type = Root) → SNS + Lambda(Slack)
• CConfig Rule root-account-mfa-enabled로 Root 사용을 평가하고 NON_COMPLIANT 시 SNS로 알림
• DAudit Manager의 Root 접근 Control을 Assessment에 추가해 로그인 발생을 증거로 수집·통보

문제 3

회사가 "S3 public bucket이 만들어지면 자동으로 차단"을 운영자 개입 없이 처리하려 한다. 가장 적합한 조합은?

• ACloudTrail Insights로 퍼블릭 버킷 생성 API의 호출량 spike를 감지해 EventBridge로 차단 Lambda를 트리거
• BConfig Rule s3-bucket-public-read-prohibited + Auto Remediation AWS-DisableS3BucketPublicReadWrite
• CGuardDuty S3 Threat Detection으로 퍼블릭 노출을 Finding으로 만들고 자동으로 Public Access Block을 적용
• DAmazon Macie로 퍼블릭 버킷의 민감 데이터를 분류한 뒤 위험 버킷의 퍼블릭 액세스를 자동 차단

문제 4

외부 감사를 위해 1년치 CloudTrail 데이터를 SQL로 분석해야 한다. 가장 적합한 도구는?

• AEvent History를 콘솔에서 필터링 — 변경 불가한 90일 이벤트를 CSV로 내보내 외부 SQL 도구로 1년치 분석
• BCloudTrail Lake — 콘솔에서 직접 SQL 쿼리, 7년 보존, ETL 불필요
• CTrail 이벤트를 DynamoDB Streams로 적재한 뒤 PartiQL로 1년치를 쿼리
• DS3 Trail 없이 Athena만 단독으로 띄워 CloudTrail Event History를 직접 테이블로 쿼리

문제 5

비정상적으로 많은 EC2 RunInstances 호출을 자동 감지하려면 어떤 서비스가 가장 적합한가?

• AConfig Rule ec2-instance-no-public-ip로 신규 인스턴스를 평가해 비정상 생성을 NON_COMPLIANT로 표시
• BCloudTrail Insights (ApiCallRateInsight — 7일 baseline 학습 후 spike 감지)
• CCloudTrail 로그를 CloudWatch Logs로 보내 Logs Insights stats count(*) by bin(5m) 쿼리로 RunInstances 급증을 주기적으로 집계
• DAudit Manager의 EC2 Control로 RunInstances 호출을 증거로 수집해 호출량 이상을 보고서로 식별

문제 6

회사가 HIPAA 컴플라이언스 증거를 외부 감사관에게 제출해야 한다. 가장 효율적인 도구는?

• AConfig Aggregator의 HIPAA 관련 Rule 평가 결과를 CSV로 내보내 Control별로 수동 매핑·정리
• BAudit Manager의 사전 제공 HIPAA Framework로 Assessment 실행 → 자동 증거 수집 → PDF/CSV 보고서
• CCloudTrail Lake에서 HIPAA 관련 API 호출을 SQL로 추출해 엑셀로 변환한 뒤 감사 증빙으로 제출
• DTrusted Advisor의 보안 점검 결과와 Security Hub 점수를 캡처해 컴플라이언스 증거로 묶어 제출

문제 7

멀티 계정에서 비준수 리소스를 한눈에 보려 한다. 어떤 구성이 표준인가?

• A계정마다 콘솔에 로그인해 Config 대시보드의 NON_COMPLIANT 목록을 확인하고 스프레드시트로 취합
• BConfig Aggregator를 Audit Account에 두고 모든 계정·리전 데이터를 통합
• CCloudWatch Cross-Account Observability(OAM)로 각 계정 Config 메트릭을 중앙 대시보드 위젯에 모아 비준수 현황을 표시
• DCloudTrail Lake Organization EDS에 SQL을 돌려 리소스 변경 이벤트로부터 비준수 리소스를 역산

문제 8

Auto Remediation이 설정됐는데 NON_COMPLIANT 리소스가 자동으로 교정되지 않는다. 트러블슈팅 순서는?

• AConfig Rule을 삭제하고 재생성한 뒤 Remediation을 다시 연결해 평가 캐시를 초기화한다
• BConfig 콘솔의 Remediation Execution Status 확인 → AutomationAssumeRole의 IAM 권한 검토 → Runbook 실행 로그 확인
• CConfig의 S3 Delivery Channel을 재설정해 Configuration Item 전달 지연으로 인한 교정 실패를 해소한다
• DConfiguration Recorder를 중지·재시작해 리소스 상태 기록을 강제로 재동기화한다

문제 9

Microsoft Windows BYOL 라이선스 200코어 한도를 초과하면 자동으로 EC2 시작을 차단하려 한다. 어떤 도구가 필요한가?

• AConfig Rule로 실행 중인 Windows 인스턴스의 vCPU 합계를 주기적으로 평가해 200코어 초과 시 NON_COMPLIANT로 차단
• BLicense Manager Configuration + LicenseCountHardLimit = true + AMI 연결
• CTrusted Advisor의 라이선스 점검으로 코어 사용량을 모니터링하고 한도 근접 시 권고로 알림
• DService Quotas에 Windows 코어 쿼터를 200으로 설정해 초과 RunInstances를 거부

문제 10

Trail의 무결성을 외부 감사관에게 입증해야 한다. 필요한 기능은 무엇이며, 어떻게 검증하는가?

• ATrail S3 버킷에 버전 관리를 활성화해 모든 로그 파일의 이전 버전을 보존하고 변경 이력으로 무결성을 입증
• BLog File Validation 활성화 → 1시간 단위 digest 파일 + SHA-256 해시 체인 → aws cloudtrail validate-logs 명령으로 검증
• CTrail 버킷에 MFA Delete를 활성화해 로그 파일 삭제·덮어쓰기를 차단함으로써 무결성을 보장
• DTrail 로그를 SSE-KMS로 암호화하고 키 정책으로 접근을 제한해 로그가 변조되지 않았음을 입증

Week 5 예고 — CloudOps의 핵심 무기: AWS Systems Manager

Week 5는 CloudWatch와 CloudTrail이 "무슨 일이 일어나고 있나"와 "누가 했나"를 추적한다면, Systems Manager(SSM)는 "어떻게 고치고 유지하는가"를 자동화하는 운영 실행 엔진이다.

• Day 1: SSM 개요, Agent 설치 패턴, Fleet Manager, Inventory 수집
• Day 2: Run Command, State Manager(Desired State 강제), Maintenance Window
• Day 3: Patch Manager — 베이스라인, 패치 그룹, 패치 컴플라이언스
• Day 4: Parameter Store(SecureString/KMS), Session Manager(VPN 없는 SSH 대체), Automation Runbook
• Day 5: Week 5 복습 + 시나리오 10문제

SSM은 SOA-C02에서 CloudWatch와 함께 단일 출제 비중 1위급 서비스다. Auto Remediation, Patch Manager, Run Command, Parameter Store는 시험 단골 시나리오다. CloudTrail의 Auto Remediation Runbook, Config의 Remediation Execution, CloudWatch Alarm의 EC2 Action이 모두 SSM과 연결되므로, Week 5가 끝나면 Week 3-5가 하나의 완성된 운영 자동화 루프로 연결된다.