Amazon SCS-C02: 로깅, 감사 및 포렌식 — 학습 가이드
다음의 일부입니다: AWS Security Specialty SCS-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.
Amazon GuardDuty 탐지 결과 및 해결
GuardDuty는 관리형 위협 탐지 서비스로, 백그라운드에서 세 가지 원격 측정 스트림인 CloudTrail 관리 이벤트(선택적으로 S3 데이터 이벤트), VPC Flow Logs, Route 53 DNS 쿼리 로그를 지속적으로 수집합니다. GuardDuty가 이러한 로그 소스를 사용하기 위해 별도로 활성화하거나, 전송하거나, 비용을 지불할 필요가 없습니다. 서비스가 복제된 스트림을 직접 읽기 때문입니다. 이것이 GuardDuty가 단일 API 호출로 켜질 수 있고, 별도의 로그 파이프라인 엔지니어링 없이 몇 분 안에 탐지 결과를 생성하기 시작할 수 있는 이유입니다.
탐지 결과는 0.1에서 8.9 사이의 심각도 값을 가지며, 낮음(0.1–3.9), 중간(4.0–6.9), 높음(7.0–8.9)으로 매핑됩니다. 조치가 필요한 일반적인 탐지 결과에는 UnauthorizedAccess:EC2/SSHBruteForce, Backdoor:EC2/C&CActivity.B!DNS, CryptoCurrency:EC2/BitcoinTool.B, Recon:IAMUser/MaliciousIPCaller가 포함됩니다. 해결 패턴은 탐지 결과에 따라 다릅니다. EC2 기반 침해는 일반적으로 격리 보안 그룹으로 인스턴스를 격리하고, 포렌식을 위해 볼륨 스냅샷을 생성한 후 종료하는 조치가 필요합니다. IAM 기반 탐지 결과는 액세스 키를 교체하고 해당 보안 주체의 최근 CloudTrail 활동을 검토해야 합니다.
다중 계정 환경의 경우, AWS Organizations를 통해 GuardDuty를 활성화하고 위임된 관리자 계정(일반적으로 보안 도구 계정)을 지정하십시오. 위임된 관리자는 서비스가 켜져 있는 모든 리전의 모든 기존 및 신규 멤버 계정에서 GuardDuty를 자동으로 활성화할 수 있습니다. 위임된 관리자 구성이 없으면, 계정별 GuardDuty 탐지 결과는 각 멤버 계정에 격리되어 유지됩니다. 탐지기를 개별적으로 활성화해도 중앙에서 집계되지 않습니다.
AWS Security Hub 및 교차 계정 집계
Security Hub는 정규화 및 집계 계층입니다. GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config 및 수십 개의 파트너 제품에서 탐지 결과를 수집하여 AWS 보안 탐지 결과 형식(ASFF)으로 변환합니다. 또한 CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS, NIST 800-53과 같은 표준에 대해 자체적인 제어를 실행합니다.
교차 계정, 교차 리전 집계는 GuardDuty와 동일한 방식으로 작동합니다. Organizations 위임된 관리자에 Security Hub를 등록한 다음, 다른 리전의 탐지 결과가 해당 단일 창으로 복제되도록 집계 리전을 지정합니다. 흔한 실수는 각 계정에서 Security Hub를 활성화하고 통합된 뷰를 기대하는 것입니다. 위임된 관리자와 집계 리전 없이는 각 계정은 여전히 자신의 탐지 결과만 볼 수 있습니다.
Security Hub 자체는 이메일을 보내지 않습니다. 알림 및 자동화는 기본 EventBridge 버스에서 Security Hub 탐지 결과 이벤트를 매칭하고 이를 SNS, Lambda, Step Functions 또는 Systems Manager Automation 문서로 전달하여 구축됩니다.
CloudTrail: 관리 이벤트 vs 데이터 이벤트
CloudTrail은 두 가지 범주의 활동을 기록하며, 이 둘을 혼동하는 것이 탐지 범위에서 가장 흔한 공백입니다.
관리 이벤트: 제어 영역 작업 —
RunInstances,CreateBucket,AttachRolePolicy,PutBucketAcl. 새로운 추적에서 기본적으로 활성화됩니다.데이터 이벤트: 대용량, 리소스 수준 작업 — S3 객체 수준 호출(
GetObject,PutObject,DeleteObject,PutObjectAcl), LambdaInvoke, DynamoDB 항목 수준 API 호출. 기본적으로 비활성화되어 있으며 별도로 요금이 청구됩니다.
보안 요구 사항이 “PutObjectAcl을 통해 누군가 S3 객체를 퍼블릭으로 만들 때 탐지"하는 것이라면, 일반적인 관리 이벤트 추적은 이를 캡처하지 못합니다. 개별 객체에 대한 ACL 변경은 데이터 이벤트이기 때문입니다. 마찬가지로, 민감한 버킷에서의 GetObject 송신은 데이터 이벤트 없이는 보이지 않습니다. PutBucketAcl(버킷 수준)은 관리 이벤트이며 기록되지만, PutObjectAcl(객체 수준)은 그렇지 않습니다.
관리 계정 또는 위임된 관리자 계정에서 생성된 **조직 추적(organization trail)**을 사용하여 모든 멤버 계정의 이벤트가 단일 S3 버킷에 캡처되고 멤버 계정 보안 주체가 비활성화할 수 없도록 하십시오. 다음을 통해 추적을 보호하십시오:
대상 버킷에 SSE-KMS 암호화를 사용하고, 권한 없는 복호화를 거부하는 KMS 키 정책을 적용합니다.
CloudTrail 서비스 보안 주체 없이는
s3:PutObject를 거부하고 삭제를 거부하는 버킷 정책을 적용합니다.로그 파일 무결성 검증을 활성화하여, 조작 여부를 증명할 수 있도록 SHA-256으로 서명된 시간별 다이제스트 파일을 생성합니다.
생성 예시:
aws cloudtrail create-trail \
--name org-trail \
--s3-bucket-name central-ct-logs \
--is-organization-trail \
--is-multi-region-trail \
--enable-log-file-validation \
--kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail put-event-selectors \
--trail-name org-trail \
--event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,
"DataResources":[{"Type":"AWS::S3::Object",
"Values":["arn:aws:s3:::sensitive-bucket/"]}]}]'
EventBridge 및 SNS 알림
EventBridge는 탐지 결과를 사람 및 자동화된 응답자와 연결하는 라우팅 패브릭입니다. 모든 GuardDuty 탐지 결과, 모든 Security Hub 탐지 결과 업데이트, 모든 CloudTrail 파생 이벤트는 기본 이벤트 버스에 도달합니다. 규칙은 JSON 이벤트 패턴을 사용하여 필터링한 다음, 하나 이상의 대상(SNS, Lambda, SQS, Kinesis Data Firehose, Step Functions, Systems Manager)으로 팬아웃(fan out)됩니다.
심각도가 높은 GuardDuty 탐지 결과를 이메일용 SNS 주제와 분석을 위해 OpenSearch로 데이터를 공급하는 Firehose 전송 스트림 양쪽으로 전달하는 표준적인 패턴은 다음과 같습니다.
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"],
"detail": { "severity": [ { "numeric": [ ">=", 7 ] } ] }
}
CRITICAL 심각도의 Security Hub 탐지 결과를 이메일로 라우팅하는 경우:
{
"source": ["aws.securityhub"],
"detail-type": ["Security Hub Findings - Imported"],
"detail": {
"findings": {
"Severity": { "Label": ["CRITICAL"] },
"Workflow": { "Status": ["NEW"] }
}
}
}
이메일 엔드포인트는 간단한 SNS 구독입니다. 구독자는 전송이 시작되기 전에 이메일로 전송된 링크를 통해 확인해야 합니다. 단일 규칙은 최대 5개의 대상을 가질 수 있으므로, 알림 및 다운스트림 분석에 중복 규칙이 필요하지 않습니다.
패턴을 작성할 때, CloudTrail 관리 이벤트는 "detail-type": "AWS API Call via CloudTrail"과 함께 도착하지만, 데이터 이벤트는 CloudWatch Logs에 게시하는 추적을 구성하고 측정치 필터를 사용하거나 EventBridge의 CloudTrail 데이터 이벤트 통합을 통해 구독하지 않는 한 기본 버스에 나타나지 않는다는 점을 기억하십시오. 데이터 이벤트를 활성화하지 않고 기본 버스에서 "eventName": "PutObjectAcl"과 일치하는 EventBridge 규칙을 작성하면 아무것도 매칭되지 않습니다.
CloudWatch Logs, Insights, 지표 필터 및 경보
CloudTrail(및 VPC Flow Logs, 애플리케이션 로그)을 CloudWatch Logs로 전송하면 실시간에 가까운 탐지가 가능해집니다. 지표 필터는 모든 수신 로그 이벤트를 패턴과 비교하여 스캔하고 사용자 지정 CloudWatch 지표를 증가시킵니다. 해당 지표에 대한 CloudWatch 경보는 SNS를 트리거합니다.
예: 반복적인 콘솔 로그인 실패 시 경보 발생.
aws logs put-metric-filter \
--log-group-name /aws/cloudtrail/org \
--filter-name ConsoleSignInFailures \
--filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }' \
--metric-transformations metricName=ConsoleLoginFailures,metricNamespace=Security,metricValue=1
CloudWatch Logs Insights는 전용 쿼리 언어를 사용하여 애드혹 쿼리를 제공하며, 경보 발생 후 인시던트 대응에 유용합니다:
fields @timestamp, userIdentity.arn, sourceIPAddress, eventName
일반적인 함정
S3 객체 수준 활동 누락:
PutObjectAcl,GetObject,DeleteObject는 데이터 이벤트입니다. 기본 추적은 관리 이벤트만 캡처하므로 데이터 이벤트 선택기를 추가해야 합니다. 그렇지 않으면 해당 API 이름을 대상으로 하는 결과, 경보 또는 EventBridge 규칙이 아무런 알림 없이 실행되지 않습니다.위임된 관리자 없는 중앙 가시성: 모든 계정에서 GuardDuty나 Security Hub를 활성화해도 결과가 집계되지 않습니다. 결과는 AWS Organizations에 위임된 관리자를 등록하고, Security Hub의 경우 집계 리전을 선택한 후에만 중앙에서 통합됩니다. 교차 계정 초대는 소규모 환경에서는 작동하지만 확장성이 떨어지며 계정별 수락이 필요합니다.
필터에서 관리 이벤트와 데이터 이벤트 혼동:
PutBucketAcl(버킷)은 관리 이벤트이며 모든 표준 EventBridge 또는 지표 필터에서 작동합니다. 반면PutObjectAcl(객체)은 데이터 이벤트를 활성화하고 동일한 파이프라인으로 전달하지 않는 한, 패턴이 아무리 잘 만들어져도 작동하지 않습니다.
실용적인 문제: 사용 사례 시나리오
시나리오: Meridian Financial은 전용 보안 계정과 중앙 집중식 로깅 계정을 갖춘 다중 계정 AWS Organization을 운영하고 있습니다. 이들의 환경에는 S3의 고객 PII, EC2/Lambda의 트랜잭션 API가 포함되어 있으며, CloudTrail은 이미 관리 이벤트를 중앙 S3 버킷에 기록하고 있습니다. 팀들은 더 빠른 탐지와 계정 간의 조율된 대응을 원합니다.
과제: 보안 엔지니어들은 S3 GET 요청의 급증과 잠재적인 데이터 유출을 시사하는 관련 GuardDuty 결과를 탐지했지만, 경보는 노이즈가 많고 연관된 CloudTrail 컨텍스트와 계정 간 자동화된 차단 조치가 부족합니다.
권장 접근 방식:
- 모든 멤버 계정에서 Amazon GuardDuty를 활성화하고 보안 계정을 GuardDuty 위임된 관리자로 지정합니다. S3 데이터 이벤트 보호를 활성화하여 결과에 객체 수준 액세스 이상이 포함되도록 합니다.
- 계정별로 CloudTrail을 구성하여 보존을 위해 관리 이벤트를 중앙 S3로 전달하고, 선택된 고부가가치 데이터 이벤트(S3 GetObject/PutObject/DeleteObject 및 Lambda Invoke)를 지연 시간이 짧은 검사를 위해 보안 계정의 CloudWatch Logs로 전달합니다.
- 보안 계정에서 AWS Security Hub를 켜고 멤버 계정과의 교차 계정 집계를 활성화하여 GuardDuty 결과, CloudTrail에서 파생된 결과, Config/Inspector 결과가 중앙 집중화되고 정규화되도록 합니다.
- 심각도가 높은 GuardDuty 및 Security Hub 결과와 일치하는 EventBridge 규칙을 생성하고, 이를 SNS로 라우팅하여 페이저 알림을 보내고, CloudTrail 컨텍스트를 사용하여 차단 조치(API 키 해지, IAM 세션 제거, EC2 ENI 격리)를 수행하는 해결 Lambda 함수로 라우팅합니다.
- IAM 보안 주체별로 비정상적인 s3:GetObject 비율에 대한 CloudWatch Logs 지표 필터를 추가하고, 동일한 EventBridge/SNS/Lambda 파이프라인을 트리거하는 경보를 추가합니다. 보안 계정에서 CloudWatch Logs Insights 쿼리를 사용하여 인시던트 분류를 위해 경보를 연관된 CloudTrail 이벤트로 보강합니다.
근거: 결과(GuardDuty + Security Hub)를 중앙 집중화하고 대상 CloudTrail 데이터 이벤트를 CloudWatch로 전송하면 EventBridge/SNS/Lambda를 통해 지연 시간이 짧은 상관관계 분석, 경보 및 자동화된 차단이 가능해집니다. 이는 탐지, 교차 계정 집계 및 자동화된 대응에 대한 AWS 모범 사례와 일치합니다.
중앙 집중식 CloudTrail 및 로그 무결성
CloudTrail은 AWS API 활동의 권위 있는 기록이며, 모든 감사 아키텍처의 기반은 AWS Organizations 내의 전용 로그 아카이브 계정에 있는 단일 중앙 S3 버킷으로 전달되는 하나의 다중 리전 추적입니다. 다중 리전 추적은 현재 모든 리전 그리고 AWS가 나중에 출시하는 모든 리전의 관리 이벤트를 자동으로 캡처합니다. 단일 리전 추적은 다른 곳에서 워크로드가 시작되는 순간 사각지대를 만들어내며, 이는 감사 중 전형적인 완전성 실패 사례입니다. 조직 수준에서 적용하면 추적은 모든 멤버 계정의 이벤트도 캡처하므로, 조직에 가입하는 새 계정은 계정별 구성 없이도 적용됩니다.
추적에서 로그 파일 검증을 활성화하십시오. 그러면 CloudTrail은 전달된 로그 파일의 SHA-256 해시를 포함하는 서명된 다이제스트 파일을 매시간 동일한 S3 버킷으로 전달합니다. aws cloudtrail validate-logs 명령은 다이제스트 체인을 따라가며 변조, 삭제 또는 누락을 탐지합니다. 검증이 없으면 방어자는 인시던트 발생 후 로그가 변경되지 않았음을 증명할 수 없으며, 이는 포렌식 증거로서의 효력을 상실하게 만듭니다.
aws cloudtrail create-trail \
--name org-trail \
--s3-bucket-name corp-audit-logs \
--is-multi-region-trail \
--is-organization-trail \
--enable-log-file-validation \
--kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail start-logging --name org-trail
전달 실패는 거의 항상 CloudTrail 버그가 아닌 다운스트림 권한 문제입니다. S3 버킷은 추적을 생성하기 전에 존재해야 하며, 버킷 정책은 추적과 일치하는 aws:SourceArn 조건과 함께 cloudtrail.amazonaws.com에 s3:PutObject 권한을 부여해야 하고, 객체 소유자는 버킷 소유자여야 합니다(bucket-owner-full-control). 추적이 SSE-KMS를 사용하는 경우, CMK 정책은 CloudTrail 서비스 보안 주체에 대해 kms:GenerateDataKey*를 허용해야 하며, 또한 모든 소비자(Athena, 보안 엔지니어, Lambda 파서)는 해당 키에 대한 kms:Decrypt 권한을 가져야 합니다. 일반적인 장애 모드는 다음과 같습니다. 로그는 잘 전달되지만, 쿼리 역할에 로그 암호화 CMK에 대한 Decrypt 권한이 없기 때문에 Athena 쿼리가 “AccessDenied"를 반환합니다. 암호화를 비활성화하지 말고 키 정책에서 이 문제를 해결해야 합니다.
CloudWatch Logs, 지표 필터 및 실시간 경보
CloudTrail은 5~15분 배치 단위로 S3에 로그를 전송합니다. 이는 사후 감사에는 충분하지만 실시간 탐지에는 너무 느립니다. 민감한 이벤트에 대한 경보를 설정하려면, 추적(trail)을 CloudWatch Logs로 스트리밍하거나(추적 옵션 중 하나) 특정 이벤트를 EventBridge를 통해 라우팅해야 합니다. CloudWatch Logs 접근 방식은 JSON 이벤트와 패턴을 매칭하여 CloudWatch 지표를 증가시키는 **지표 필터(metric filters)**를 사용하며, 이 지표는 CloudWatch 경보와 SNS 알림을 작동시킵니다. 가장 대표적인 예시는 루트 콘솔 로그인입니다:
{ $.eventName = "ConsoleLogin" && $.userIdentity.type = "Root" }
EventBridge는 KMS 키 비활성화, IAM 정책 변경과 같이 범위가 좁고 잘 알려진 이벤트에 더 적합합니다. 규칙이 Logs 비용 없이 Lambda나 Step Functions를 직접 트리거할 수 있기 때문입니다. 집계된 수치나 대시보드가 필요할 때는 지표 필터를 사용하십시오.
CloudWatch Logs의 보존 기간은 기본적으로 **만료 없음(Never Expire)**으로 설정되어 있는데, 이는 비용이 많이 들고 거의 올바른 설정이 아닙니다. 컴플라이언스 체제에 맞춰 로그 그룹별로 보존 기간을 명시적으로 설정해야 합니다(aws logs put-retention-policy). 일반적으로 CloudWatch에 90일간 ‘핫’ 데이터로 보관하고, 구독 필터나 Kinesis Data Firehose를 통해 S3에 장기 아카이브하는 방식을 사용합니다.
민감한 데이터의 위생(hygiene)을 위해 계정 수준에서 CloudWatch Logs 데이터 보호 정책을 적용하십시오. 이 정책은 관리형 데이터 식별자(신용카드 번호, AWS 보안 키, SSN 등)를 사용하여 수집 시점에 일치하는 문자열을 마스킹합니다. 중요한 점은, 마스킹 해제에는 logs:Unmask 권한이 필요하며 이 권한은 비상시에만 사용하는 ‘break-glass’ 역할에만 부여해야 한다는 것입니다. 로그 그룹을 읽을 수는 있지만 Unmask 권한이 없는 사용자는 별표(*)만 보게 됩니다. 계정 전체에 적용되는 정책은 현재 및 미래의 모든 로그 그룹에 적용되므로 올바른 통제 방식입니다. 그룹별 정책은 새로운 서비스가 새 그룹을 생성함에 따라 설정이 누락될 수 있습니다.
대규모 로그 쿼리: Insights와 Athena
두 쿼리 엔진은 서로 다른 데이터 계층을 처리합니다.
CloudWatch Logs Insights는 전용 쿼리 언어를 사용하여 CloudWatch Logs에 이미 저장된 데이터를 쿼리합니다. 최신 운영 데이터(Lambda 로그, Logs에 저장된 VPC Flow Logs, 애플리케이션 로그)에 이상적입니다. 빠르고 스키마 설정이 필요 없지만, CloudWatch 보존 기간과 스캔된 GB당 비용에 제약을 받습니다.
Amazon Athena는 S3의 데이터에 대해 Presto/Trino SQL을 실행합니다. CloudTrail, ALB 액세스 로그, S3에 저장된 VPC Flow Logs, CloudFront 로그에 대한 대규모 포렌식 쿼리에 이상적입니다. 스캔된 TB당 5달러의 비용이 발생하며, **파티션 프로젝션(partition projection)**이나 날짜/리전(Region)에 대한 Glue 파티션을 사용하여 스캔 비용을 대폭 절감할 수 있습니다.
일반적인 포렌식 사용 사례는 누가 KMS 키를 비활성화했는지 식별하는 것입니다. CloudTrail JSON은 중첩 구조이므로, CloudTrail이 생성한 Athena 테이블은 userIdentity를 구조체(struct)로 노출합니다:
SELECT eventTime,
userIdentity.arn AS principal,
userIdentity.sessionContext.sessionIssuer.arn AS assumed_role,
userIdentity.sessionContext.attributes.mfaAuthenticated AS mfa,
sourceIPAddress,
requestParameters
FROM cloudtrail_logs
WHERE eventName = 'DisableKey'
AND eventTime BETWEEN '2024-05-01T03:00:00Z' AND '2024-05-01T03:30:00Z';
ALB 봇 분석을 위해서는 ALB 액세스 로그를 S3로 활성화하고, 로그 접두사에 대해 Athena 테이블을 정의한 다음, 알려진 악성 IP 테이블과 조인하여 QuickSight에서 집계 결과를 시각화합니다. QuickSight는 Athena에서 데이터를 읽으므로, 파이프라인은 ALB → S3 → Athena → QuickSight 순서가 됩니다. ALB 로그를 CloudWatch Logs Insights로 보내는 것은 기본적으로 지원되는 경로가 아니며, ALB 로그는 S3로만 전송됩니다.
VPC Flow Logs는 두 대상 중 하나로 보낼 수 있습니다. filter dstPort=3389 and action="REJECT"와 같은 전술적 조사를 위해서는 Logs를 선택하고, 수개월 규모의 추세 쿼리를 위해서는 S3(Parquet 형식, 파티셔닝 적용)를 선택하십시오.
Audit Manager 증적 수집
AWS Audit Manager는 PCI DSS, HIPAA, SOC 2, CIS와 같은 프레임워크에 매핑된 증적 수집을 지속적으로 자동화합니다. Config 규칙, Security Hub 결과, CloudTrail 이벤트, 리소스 인벤토리에서 증적을 가져와 통제 평가(control assessments)로 패키징합니다. Organizations 관리 계정이나 위임된 관리자 계정에서 활성화하면 모든 멤버 계정에서 증적을 수집하여 평가 보고서를 생성합니다. 이 보고서는 매니페스트가 포함된 압축된 증적 번들로, 감사관들이 수동 스크린샷 대신 인정하는 자료입니다. 시나리오에서 지속적, 다중 계정, 프레임워크 연계 증적 수집을 요구할 때 이것이 정답입니다. Config만으로는 리소스 규정 준수 여부는 알 수 있지만 프레임워크 매핑은 제공하지 않습니다. Security Hub는 결과를 제공하지만 평가 패키징은 하지 않습니다. 자체적으로 만든 Athena 보고서는 지속적이지 않습니다.
함정 요약
로그 누락의 원인을 CloudTrail로 단정하는 것은 대부분 잘못된 생각입니다. 버킷이 존재하지 않거나, 버킷 정책이 CloudTrail 보안 주체를 거부하거나, 객체 소유권이 잘못 구성되었을 수 있습니다. S3를 먼저 확인하세요.
단일 리전(Single-Region) trail은 저렴해 보이지만 불완전한 감사 기록을 생성합니다. 조직 전체를 커버하기 위해서는 다중 리전(multi-Region)이 기본적으로 올바른 선택입니다.
SSE-KMS로 암호화된 로그는 CMK 정책이 해당 보안 주체(principal)에게
kms:Decrypt권한을 부여하지 않는 한 Athena, Lambda 파서, 엔지니어에게 보이지 않습니다. 암호화를 비활성화하는 것이 해결책이 아니라, 키 정책을 수정하는 것이 올바른 방법입니다.
실제 문제: 사용 사례 시나리오
시나리오: Meridian Financial은 프로덕션, 스테이징, 그리고 전용 로깅 계정으로 구성된 다중 계정 AWS Organization을 운영하고 있습니다. 이 환경은 고객 대면 API, 분석 시스템, IAM으로 관리되는 보안 암호를 호스팅하며, 사고 대응 및 규정 준수 요청을 지원하기 위해 중앙 집중식의 변경 불가능한(tamper-evident) 로깅과 신속한 조사 도구가 필요합니다.
과제: 최근 의심스러운 콘솔 로그인 및 IAM 정책 변경 시퀀스가 몇 시간 동안 감지되지 않았습니다. 이로 인해 로그 무결성과 시기적절한 경보가 포렌식 재구성 및 Audit Manager 증거 수집에 부적절하다는 우려가 제기되었습니다.
권장 접근 방식:
- 모든 리전에서 AWS Organizations CloudTrail(조직 trail)을 활성화하고, CloudTrail 로그 파일 무결성 검증을 켭니다. 로그와 다이제스트 파일을 중앙 집중식 S3 버킷으로 전송하되, 소규모 보안 팀에게만 복호화를 허용하는 키 정책을 가진 KMS CMK로 암호화하고, S3 액세스 로깅과 버전 관리를 활성화합니다.
- 관리 이벤트와 선택된 데이터 이벤트를 CloudWatch Logs로 스트리밍하도록 CloudTrail을 구성합니다. 그런 다음, 고위험 패턴(새로운 IP에서의 콘솔 로그인 실패, CreateUser, PutRolePolicy)에 대한 CloudWatch Logs 메트릭 필터를 생성하고, 페이징 및 자동화된 Lambda 플레이북을 위해 CloudWatch Alarms를 SNS 주제에 연결합니다.
- 최근 이벤트의 대화형 조사를 위해 CloudWatch Logs Insights 대시보드를 배포하고, 정책에 따라 증거를 보존하기 위해 로깅 계정에 보존 및 수명 주기 규칙을 설정합니다.
- AWS Glue로 CloudTrail S3 객체를 카탈로그화하고, 대규모 회고 분석 및 조사관을 위한 CSV 증거 자료 추출을 위해 Athena 쿼리(리전/날짜/서비스별로 파티셔닝됨)를 실행합니다.
- CloudTrail, AWS Config, IAM 증거를 자동으로 증거 폴더에 수집하고 규정 준수 검토자를 위해 주기적인 내보내기를 예약하는 AWS Audit Manager 평가를 생성합니다.
근거: CloudTrail을 중앙 집중화하고 검증하며, 실시간 메트릭 필터 및 경보를 위해 CloudWatch로 스트리밍하고, 확장 가능한 쿼리를 위해 Athena/Logs Insights를 사용하는 것은 탐지, 불변 로깅, 포렌식 준비 상태에 대한 AWS 모범 사례를 따르는 것입니다. 동시에 Audit Manager는 감사를 위한 증거 수집을 자동화합니다.
← 위협 탐지 및 알림 · 모든 도메인 · 암호화 →
이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
시험 합격하기 →