AWS CloudTrail 사고조사 실전 가이드: 계정 침해 타임라인과 IAM 행위 추적

서론

AWS 환경에서 침해사고가 발생했을 때 가장 중요한 로그는 CloudTrail이다. GuardDuty나 VPC Flow Logs보다 먼저 확인해야 할 것이 CloudTrail 로그다. 공격자가 AWS 계정 내부에 침입하면 지속성을 유지하기 위해 생성한 사용자, 도출한 스냅샷, 비활성화한 보안 통제, 도난당한 데이터 — 거의 모든 행동은 CloudTrail에 흔적을 남긴다. CloudTrail을 능숙하게 읽을 수 있다면 언제, 누가, 무엇을 했는지 정확히 재구성할 수 있다.

하지만 많은 분석가는 CloudTrail을 제대로 읽는 법을 배우지 못한 상태다. "API 호출을 로깅한다"는 정도만 알고, 한번도 본 적 없는 길고 복잡한 JSON 덩어리에 막혀 실제 사고 대응 때는 다른 도구에 의존하거나 로그를 제대로 분석하지 못한다.

이 글은 AWS CloudTrail 로그 구조부터 실제 침해사고 조사 시나리오, Athena 쿼리 예시까지 사고 대응 실무가 바로 활용할 수 있도록 정리한다.

본론

CloudTrail이란 무엇인가

AWS에서 거의 모든 작업은 API 호출을 통해 이루어진다. AWS 콘솔에서 "인스턴스 생성"을 클릭하면 콘솔이 RunInstances API를 호출하고, 배포 스크립트가 역할을 맡으면 AssumeRole이 실행되며, 애플리케이션이 S3에서 파일을 읽으면 GetObject가 호출된다. CloudTrail은 계정 내 활동 장부로서 누가 언제 어디서 어떤 API를 호출했고 성공했는지 기록한다.

컨트롤 플레인 vs 데이터 플레인

CloudTrail에는 두 가지 "플레인"이 있으며, 로그 수집 방식이 완전히 다르다.

• 컨트롤 플레인(Control Plane) — 리소스를 관리하는 작업. EC2 인스턴스 생성, 보안 그룹 삭제, 정책 첨부, 액세스 키 생성 등이다. 이러한 관리 이벤트(Management Events)는 트레일(Event Data Store)에서 기본적으로 기록된다. 단, 한 트레일의 첫 번째 관리 이벤트 사본만 무료이며 같은 이벤트를 두 번째 이상 트레일로 추가 전송하면 과금된다. CloudTrail Lake를 통해 수집·보존·분석하면 별도 요금이 적용된다.
• 데이터 플레인(Data Plane) — 리소스 내부의 활동. S3에서 객체 읽기, Lambda 호출, DynamoDB 항목 조회 등이다. 이러한 데이터 이벤트(Data Events)는 기본적으로 비활성화되어 있으며, 수백만 개의 로그가 발생할 수 있기 때문에 비용이 발생한다.

많은 분석가가 빠지는 함정은 S3 데이터 유출 경보를 조사하면서 CloudTrail을 확인했을 때 GetObject 호출이 하나도 기록되지 않은 것을 보고 "공격자가 흔적을 지웠다"고 결론 내리는 경우다. 실제로는 데이터 이벤트가 활성화되지 않아 로그가 아예 생성되지 않은 상황이다.

CloudTrail이 아닌 것

CloudTrail의 한계를 명확히 아는 것이 정확한 조사의 시작점이다.

• 네트워크 로그가 아니다. 패킷, 포트 스캔, 전송 바이트 수는 확인할 수 없다. 그것은 VPC Flow Logs의 역할이다. CloudTrail은 "누군가 이 파일에 GetObject를 호출했다"는 정도만 알려주며, 유출 양은 API 호출 횟수와 패턴으로 추론해야 한다.
• 호스트 내부 가시성이 아니다. 공격자가 EC2 인스턴스에 SSH로 접속해 bash 명령을 실행해도, CloudTrail은 해당 인스턴스가 발사하는 AWS API 호출만 볼 수 있다. 호스트 셸 히스토리는 볼 수 없으며, EDR이나 Syslog, Auditd 같은 OS 수준 로깅이 필요하다.
• 실시간이 아니다. 이벤트는 보통 약 5분 내에 기록되지만 최대 15분이 소요될 수 있다. 빠르게 진행되는 실시간 사고 대응 중 최근 이벤트가 보이지 않는다고 해서 사건이 발생하지 않았다고 판단해서는 안 된다.

CloudTrail 접근 방식

CloudTrail에 접근하는 세 가지 방식이 있으며, 각각 가능한 일이 다르다.

Athena 쿼리는 cloudtrail_logs 테이블을 대상으로 하지만, 이 테이블은 누군가가 생성해야 존재한다. 일반 트레일을 S3에 저장한 경우 콘솔의 "Athena 테이블 생성" 버튼으로 CREATE TABLE 문을 생성한 후 쿼리한다. Lake의 경우 이벤트 데이터 스토어가 이미 쿼리 가능하다.

CloudTrail의 4가지 이벤트 타입

공격자는 로깅되고 있지 않은 틈새에서 활동하므로, 4가지 타입을 모두 이해해야 한다.

1. 관리 이벤트(Management Events)

컨트롤 플레인의 연산을 기록한다. CreateUser, AttachRolePolicy, RunInstances, ConsoleLogin, AssumeRole 등이 포함되며 기본적으로 활성화되어 있다. 모든 조사의 기반이 된다. Read(Describe, List — 공격자의 정찰 단계)와 Write(Delete, Put — 실제 피해)로 나뉜다.

2. 데이터 이벤트(Data Events)

데이터 플레인의 연산을 기록한다. S3 객체 수준(GetObject, PutObject, DeleteObject), Lambda Invoke, DynamoDB 항목 접근 등이 포함된다. 기본적으로 비활성화되어 있으며 사후에 활성화할 수 없다. 사건 발생 전에 켜두지 않으면 증거가 아예 존재하지 않는다.

3. 인사이트 이벤트(Insights Events)

AWS의 내장 이상 감지 기능으로 관리 이벤트의 비정상 패턴을 잡아낸다. 두 가지 신호를 제공하며, 비정상 호출 비율(ApiCallRateInsight)과 비정상 오류 비율(ApiErrorRateInsight)이다. 예컨대 AccessDenied 오류가 급증하는 것은 공격자가 무엇을 할 수 있는지 탐색(probing)하는 전형적인 패턴이다. 기본적으로 비활성화되어 있다.

4. 네트워크 활동 이벤트(Network Activity Events)

2024년 추가된 최신 기능으로, VPC 엔드포인트에 도달하는 컨트롤 플레인 호출을 기록한다. 엔드포인트 정책으로 거부된 호출도 포함하므로, VPC 내부 리소스가 해서는 안 되는 API를 호출하거나 데이터 주변부 거부를 캐치하는 데 유용하다.

CloudTrail 로그 레코드 구조

모든 CloudTrail 이벤트는 JSON 객체다. 하나를 능숙하게 읽을 수 있다면 수백만 개도 읽을 수 있다. 다음은 IAM 사용자가 액세스 키를 생성하는 전형적인 관리 이벤트다.

{
  "eventTime": "2026-02-14T09:31:07Z",
  "eventSource": "iam.amazonaws.com",
  "eventName": "CreateAccessKey",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "203.0.113.47",
  "userAgent": "aws-cli/2.15.30 Python/3.11.6 Darwin/23.2.0",
  "userIdentity": {
    "type": "IAMUser",
    "arn": "arn:aws:iam::123456789012:user/dev-sergei",
    "accountId": "123456789012",
    "accessKeyId": "AKIAIOSFODNN7EXAMPLE",
    "userName": "dev-sergei"
  },
  "requestParameters": {
    "userName": "dev-sergei"
  },
  "responseElements": {
    "accessKey": {
      "accessKeyId": "AKIAI44QH8DHBEXAMPLE",
      "status": "Active",
      "userName": "dev-sergei"
    }
  },
  "errorCode": null,
  "readOnly": false,
  "eventType": "AwsApiCall",
  "managementEvent": true,
  "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}

주요 필드 해설

userIdentity — "누가 했는가"

AWS 아이덴티티는 계층적으로 구성되어 있으며 userIdentity 블록을 잘못 읽으면 잘못된 방향으로 조사가 이어진다.

Root: AWS 계정 루트 사용자. 잘 관리되는 계정에서는 거의 API 호출을 해서는 안 된다. 낯선 IP에서 루트 활동이 감지되면 자동 P1 사고다.

IAMUser: IAM 사용자명 및 액세스 키를 가진 장주기 아이덴티티. 장주기 키(AKIA...)는 git 저장소, .env 파일, CI/CD 파이프라인에 자주 유출되므로, 주거 IP나 VPN IP에서 갑자기 IAMUser 활동이 감지되면 고신호 신호다.

AssumedRole: IAM 역할을 맡아 생성된 임시 자격 증명. EC2 인스턴스 프로파일, Lambda 실행 역할, AWS SSO/IAM Identity Center, 크로스 계정 접근 등 현대 AWS의 근간이다.

"userIdentity": {
  "type": "AssumedRole",
  "principalId": "AROACKCEVSQ6C2EXAMPLE:i-0abcd1234efgh5678",
  "arn": "arn:aws:sts::123456789012:assumed-role/app-server-role/i-0abcd1234efgh5678",
  "sessionContext": {
    "sessionIssuer": {
      "type": "Role",
      "userName": "app-server-role"
    },
    "attributes": {
      "creationDate": "2026-02-14T08:00:11Z",
      "mfaAuthenticated": "false"
    }
  }
}

역할 세션 읽는 법:

• 역할 식별: sessionIssuer.userName가 기본 역할명(app-server-role)을 알려준다.
• 세션명 식별: ARN의 슬래시 이후 문자열(i-0abcd1234efgh5678)을 확인한다. EC2 인스턴스가 인스턴스 프로파일 역할을 맡으면 AWS가 자동으로 EC2 인스턴스 ID를 세션명으로 설정하므로, 특정 서버가 호출했는지 알 수 있다.
• 생성 시각 비교: 임시 역할 자격 증명은 최대 12시간(역할 체이닝 시 1시간)만 유효하다. EC2 인스턴스는 임시 자격 증명을 자동으로 회전하므로, creationDate가 오래되어도 활동이 계속된다고 해서 한 세션이 영구적으로 생존하는 것은 아니다.
• 도난된 자격 증명 함정: AssumedRole 이벤트의 sourceIPAddress는 자격 증명이 현재 사용 중인 위치를 나타내며, 역할이 처음 맡아진 위치와 다를 수 있다. 공격자가 EC2 인스턴스에서 메타데이터 자격 증명을 긁어온 자신의 노트북에서 실행하면, 역할 ARN은 동일하지만 sourceIPAddress가 외부 IP로 바뀐다. 이 IP 불일치가 바로 핵심 유출 탐지 포인트다.

가장 중요한 개념은 아이덴티티 체이닝이다. 사람이 콘솔에 로그인(ConsoleLogin)하면 관리자 역할을 맡아(AssumeRole — 세션명과 함께 단기 키 생성) 작업을 수행한다(AssumedRole 이벤트). 조사는 accessKeyId, principalId, 역할 세션명을 연결하며 하나로 엮어간다.

사고 대응에서 핵심이 되는 이벤트들

1. ConsoleLogin — 진입점

responseElements.ConsoleLogin의 Success나 Failure를 확인한다. additionalEventData.MFAUsed에 특히 주안점을 둔다. MFA가 의무화된 환경에서 "MFAUsed": "No" 상태로 성공 로그인하면 치명적 경보다. 같은 IP에서 Failure 이벤트 연쇄 후 Success가 발생하면 패스워드 브루트포스나 크리덴셜 스테핑 공격이다.

2. GetCallerIdentity — 정찰 단계

단독으로 sts:GetCallerIdentity는 해가 없다. "나는 누구인가"를 확인하는 것뿐이다. 그러나 도난된 액세스 키를 가져온 직후 공격자가 실행하는 첫 명령이 바로 이다. GetCallerIdentity 직후 List와 Describe 정찰 호출이 비 기업 IP에서 연속으로 발생하면 교과서적인 공격자 오리엔테이션 패턴이다.

3. IAM 지속성 및 권한 상승

공격자가 발판을 확보하면 자격 증명 회전에서도 생존할 수 있도록 백도어를 즉시 구축한다.

• 아이덴티티 생성: CreateUser, CreateAccessKey, CreateLoginProfile(프로그래매틱 계정에 콘솔 패스워드 로그인 활성화)
• 정책 조작: AttachUserPolicy, AttachRolePolicy, PutUserPolicy(AdministratorAccess 또는 인라인 "Action": "*" 부여)
• 조용한 상승: UpdateAssumeRolePolicy(공격자가 제어하는 AWS 계정이 역할을 맡을 수 있도록 신뢰 정책 수정) 또는 SetDefaultPolicyVersion(관리 정책의 백도어 버전으로 전환 — "Policy Attached" 경보를 트리거하지 않음)
• iam:PassRole 피벗: RunInstances나 CreateFunction을 사용해 과다 권한 IAM 역할을 EC2 인스턴스나 Lambda 함수에 첨부 — IAM 정책을 수정하지 않고도 관리자 권한 차용

4. 반 포렌식 (방증 소거)

예상치 못하게 다음 이벤트가 발생하면 P1 침입으로 간주한다.

• StopLogging, DeleteTrail, UpdateTrail, PutEventSelectors — CloudTrail 자체 비활성화 또는 무력화. StopLogging은 예상치 못하게 발생하면 거의 정당한 이유가 없으며, 자체 고우선순위 경보가 필요하다.
• DeleteFlowLogs — 네트워크 가시성 제거
• PutBucketLogging(공백으로 설정) — S3 접근 로깅 제거
• DeleteDetector, StopMonitoringMembers — GuardDuty 끄기
• DeleteBucket / PutBucketPolicy(버킷 공개) — 파괴 또는 노출

5. 데이터 유출 (데이터 이벤트 활성화 시)

• S3: 민감한 버킷에서 GetObject 급증, ListObjects 전체 스윕, 새로운 IP/프린시플에서 읽기, 알 수 없는 계정 버킷으로 복사
• 스냅샷/AMI: CreateSnapshot 후 ModifySnapshotAttribute로 공유/공개 설정, 또는 ModifyImageAttribute로 AMI — 디스크 전체를 공격자 계정과 공유하며 데이터 도난
• RDS: CreateDBSnapshot 후 ModifyDBSnapshotAttribute — 동일한 패턴, 다른 어휘

실제 사고 조사 시나리오

트리거: GuardDuty에서 UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS 경보 발생. 즉, EC2 인스턴스 역할의 자격 증명이 AWS 외부 IP에서 사용되고 있다는 의미다. 누군가 인스턴스에서 자격 증명을 도난받아 자신의 머신에서 사용하고 있다.

8단계 조사 플레이북

1. 식별자 고정(Pin Identifier)

GuardDuty가 역할과 일반적으로 accessKeyId를 제공한다. 이 키 ID가 실마리이며, 도난된 자격 증명이 수행하는 모든 행동에 이 키가 붙는다. 접두사 참고: AKIA는 장주기 IAM 사용자 키, ASIA는 임시 STS 키(도난된 인스턴스 자격 증명), AROA는 역할 고유 ID다. ASIA면 임시 역할 자격 증명을 쫓는 것이며, 대응 방법이 바뀐다. 임시 키는 "삭제"할 수 없고 세션을 무효화해야 한다.

2. 전체 세션 추출(Pull Full Session)

첫 쿼리는 항상 이 형태다. 해당 자격 증명이 수행한 모든 작업을 시간순으로 확인한다.

SELECT eventTime, eventName, sourceIPAddress, awsRegion, errorCode, requestParameters
FROM cloudtrail_logs
WHERE useridentity.accesskeyid = 'ASIAEXAMPLE1234567'
  AND eventTime > '2026-02-14T00:00:00Z'
ORDER BY eventTime ASC;

상단에서 하단으로 읽으면 API 호출 하나하나가 공격자의 세션이다.

3. 정찰 단계 찾기(Find IOCs / Recon)

상단 부근에서 GetCallerIdentity와 정찰 호출(ListBuckets, DescribeInstances, ListUsers, ListRoles)을 확인한다. 이때의 sourceIPAddress가 공격자의 실제 IP이며, 이제 IOC(Compromise Indicator)로 얻은 정보를 다른 곳에도 스윕한다.

4. 성공과 실패 분리(Split Success / Fail)

errorCode로 필터한다. AccessDenied 이벤트는 공격자가 시도했으나 실패한 것으로, 역할의 한계와 공격자의 의도를 보여준다(CreateUser 시도 후 거부 → 지속성을 원함). 성공한 readOnly=false 호출이 실제 피해다. 실패는 의도를, 성공은 영향을 드러낸다.

5. 지속성 탐색(Hunt Persistence)

이 세션/IP에서 CreateUser, CreateAccessKey, AttachUserPolicy, UpdateAssumeRolePolicy, CreateLoginProfile을 확인한다. 새 키나 사용자가 생성됐다면, 그것은 두 번째 실마리다. 첫 자격 증명을 회전한 후 공격자가 새 키로 전환하므로, 해당 활동도 추적해야 한다.

6. 반 포렌식 확인(Check Anti-Forensics)

StopLogging, DeleteTrail, DeleteDetector, DeleteFlowLogs가 등장했는지 확인한다. 있다면 해당 시각부터 로그가 불완전할 수 있으며, 명시적으로 맹점을 기록하고 중앙 집중식 조직 트레일(작업 계정 공격자가 접근할 수 없는 곳)에 의존한다.

7. 유출 평가(Assess Exfiltration)

스냅샷/AMI 공유 패턴과 데이터 이벤트가 활성화된 경우 S3 읽기 패턴을 확인한다. ModifySnapshotAttribute, ModifyImageAttribute, PutBucketPolicy 중 리소스에 접근할 수 있는 주체를 변경하는 모든 활동은 명확한 다운로드 없이 데이터가 유출되는 경로다.

8. 타임라인 및 전체 검색(Timeline & Sweep)

eventID를 포함한 깔끔한 UTC 타임라인을 구성한 후, 모든 IOC(공격자 IP, 생성된 사용자명, 새 키 ID)를 모든 계정, 모든 리전, 더 넓은 시간 창에 걸쳐 검색한다. 이것이 두 번째 발판을 포착하고 폭발 범위를 확인하는 방법이다. 로그 파일 유효성이 활성화됐다면 aws cloudtrail validate-logs를 실행해 증거가 변조되지 않았음을 입증한다.

aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:us-east-1:123456789012:trail/my-trail \
  --start-time 2026-02-14T00:00:00Z \
  --end-time 2026-02-15T00:00:00Z

그 후 격리: 자격 증명 회전/비활성화, 세션 무효화, 지속성 제거.

자주 사용하는 Athena 쿼리

-- 실패(거부) 호출 — "무엇을 탐색하고 있는가"
SELECT eventTime, useridentity.arn, eventName, sourceIPAddress, errorCode
FROM cloudtrail_logs
WHERE errorCode IN ('AccessDenied', 'Client.UnauthorizedOperation', 'UnauthorizedOperation')
  AND from_iso8601_timestamp(eventTime) > current_timestamp - interval '24' hour
ORDER BY eventTime DESC;

-- MFA 없이 콘솔 로그인
SELECT eventTime, useridentity.arn, sourceIPAddress,
  json_extract_scalar(additionalEventData, '$.MFAUsed') AS mfa_used
FROM cloudtrail_logs
WHERE eventName = 'ConsoleLogin'
  AND json_extract_scalar(responseElements, '$.ConsoleLogin') = 'Success'
  AND json_extract_scalar(additionalEventData, '$.MFAUsed') = 'No'
ORDER BY eventTime DESC;

-- CloudTrail 자체 접촉 — 반 포렌식 트리거
SELECT eventTime, useridentity.arn, eventName, sourceIPAddress
FROM cloudtrail_logs
WHERE eventName IN ('StopLogging', 'DeleteTrail', 'UpdateTrail', 'PutEventSelectors')
ORDER BY eventTime DESC;

-- 루트 활동 — 비어 있어야 함
SELECT eventTime, eventName, sourceIPAddress, awsRegion
FROM cloudtrail_logs
WHERE useridentity.type = 'Root'
ORDER BY eventTime DESC;

-- 도난된 자격 증명 전체 세션 추적
SELECT eventTime, eventName, sourceIPAddress, errorCode, requestParameters
FROM cloudtrail_logs
WHERE useridentity.accesskeyid = 'ASIAEXAMPLE1234567'
ORDER BY eventTime ASC;

주의해야 할 함정들

• 데이터 이벤트는 기본 비활성화다. 사건 발생 전부터 활성화하지 않으면 S3 읽기나 Lambda 호출 기록은 아예 존재하지 않는다.
• STS 리전 함정: 글로벌 서비스는 us-east-1에 로깅되지만, 현대 SDK는 리전별 STS 엔드포인트를 호출하므로 AssumeRole과 GetCallerIdentity는 호출자의 로컬 리전에 로깅된다. us-east-1만 확인하지 않는다.
• 크로스 리전 중복: 여러 리전에 전송된 글로벌 이벤트는 sharedEventId를 공유하므로 SQL에서 이 ID로 중복 제거한다.
• eventName은 콘솔 버튼명이 아니다. 하나의 UI 클릭이 다른 이름의 API 호출(또는 여러 서비스의 여러 호출)을 암묵적으로 트리거할 수 있다.
• sourceIPAddress가 항상 IP는 아니다. AWS 서비스 간 호출에는 DNS 이름(cloudformation.amazonaws.com 등)이, 콘솔 클릭에는 사용자의 브라우저 IP가 기록된다.
• 임시 자격 증명 IP는 이동한다. AssumedRole 이벤트는 자격 증명이 사용된 IP를 로깅하며, 역할이 맡아진 IP와 다를 수 있다. 이 불일치가 핵심 유출 탐지 포인트다.
• 로그 보호: 트레일 버킷과 설정이 작업 계정에 있으면 관리자 권한 공격자가 둘 다 삭제할 수 있다. 조직 트레일을 별도의 잠긴 계정 S3 Object Lock/MFA-delete로 배치한다.

대응 전략

CloudTrail의 사고 대응 가치는 사건 발생 전에 결정된다. CloudTrail 설정을 다음과 같이 준비해 둔다.

즉시 적용

1. 다 리전(Multi-Region) 조직 트레일 설정 — 전용, 잠긴 로그 아카이브 계정으로 단일 변조 방지 진리원 구성. 보안 운영이 관리 계정에 상주 액세스 권한을 갖지 않도록 위임 관리자 계정으로 관리한다.
2. 로그 파일 유효성 검사 활성화 — CloudTrail이 시간별 다이제스트 파일(SHA-256 해시)을 버킷에 작성한다. aws cloudtrail validate-logs로 두 시각 간 로그 파일이 변경되거나 삭제되지 않았음을 입증할 수 있다. 이것은 증거 연쇄다.
3. S3 Object Lock 또는 MFA-delete 적용 — 로그가 공격자의 관리자 액세스보다 오래 생존하도록 한다.

단기 구성

1. 데이터 이벤트 선택적 활성화 — 모든 S3가 아닌 실제로 민감한 버킷(핵심 자산)과 중요한 Lambda에만 활성화. 버킷 ARN 접두사, resources.type, readOnly 등 고급 이벤트 선택자로 범위를 좁혀 해당 버킷의 GetObject만 로깅한다.
2. CloudTrail Insights 활성화 — 저렴한 호출률/오류률 이상 신호 트리거다.
3. 고신호 실시간 경보 목록: StopLogging, 루트 사용, MFA 없는 ConsoleLogin, AdministratorAccess의 AttachUserPolicy, UpdateAssumeRolePolicy, CreatePolicyVersion, 권한 상승된 사용자의 CreateAccessKey, GuardDuty 디텍터 삭제. 소수 고신호 경보가 수백 개 소음 경보보다 효과적이다.

장기 전략

1. 조사 쿼리 저장 및 파라미터화 — 사건 당일 첫날이 복사-붙여넣기 수준으로 준비되어 있어야 한다.
2. CloudTrail Lake 도입 검토 — Athena 구성 없이 SQL로 직접 쿼리 가능, 최대 7~10년 보존. 비용은 더 높지만 파이프라인 구성이 필요 없다.

결론

CloudTrail은 무서운 JSON 벽이 아니다. 올바르게 설정하면 완전하고 변조 방지 가능하며 쿼리 가능한 클라우드 활동 기록이다. 사고 대응 중 침착함을 유지하는 분석가는 JSON 스키마를 암기해서가 아니다. 수천 개의 평범한 CloudTrail 이벤트를 읽었기에 이상한 것이 즉시 이상해 보이는 것이다. 그 유창함은 마법이 아니며 근육 기억이다. 오늘 자신이 가진 Event History 열개를 직접 읽어보는 것으로 시작한다.

참고문헌

1. AWS CloudTrail 공식 문서
   https://docs.aws.amazon.com/cloudtrail/

2. AWS CloudTrail 이벤트 레퍼런스
   https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html

3. AWS CloudTrail Lake 문서
   https://docs.aws.amazon.com/cloudtrail/lake/latest/userguide/cloudtrail-lake.html

4. 원문 — How to Actually Read AWS CloudTrail
   https://systemweakness.com/how-to-actually-read-aws-cloudtrail-f2b3d64a7736

5. GuardDuty 통합 및 CloudTrail
   https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_cloudtrail.html

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.