AWS CloudTrail 완전 정복: 클라우드의 'CCTV'가 모든 행동을 기록하는 법

들어가며: "누가 이 서버를 삭제한 거야?"

월요일 아침. 프로덕션 RDS 인스턴스가 사라졌다. 금요일 밤까지는 정상이었는데. 팀에 물어보면 "나는 안 했어"라는 답만 돌아온다.

• 누가 삭제했는가?
• 언제 삭제했는가?
• 콘솔에서? CLI에서? 어떤 IP에서?
• 실수인가? 악의적인가?

이 질문들에 답하려면 모든 행동의 기록이 필요하다. 건물에 CCTV가 있어야 도둑을 찾을 수 있듯, 클라우드에는 모든 API 호출의 로그가 있어야 한다.

이것이 CloudTrail이다. AWS에서 일어나는 모든 것을 기록하는 서비스.

1. CloudTrail이란 무엇인가

정의

AWS CloudTrail은 AWS 계정에서 이루어지는 모든 API 호출과 이벤트를 기록하고 저장하는 서비스다. 2013년 11월 출시.

AWS에서 일어나는 모든 것은 결국 API 호출이다:

• 콘솔에서 EC2를 시작하면 → RunInstances API 호출
• CLI로 S3에 파일을 올리면 → PutObject API 호출
• Lambda가 DynamoDB에 쓰면 → PutItem API 호출
• 심지어 콘솔에 로그인해도 → ConsoleLogin 이벤트

CloudTrail은 이 모든 API 호출을 JSON 형태로 기록한다.

CCTV 비유

CloudTrail 이벤트 예시

누군가가 EC2 인스턴스를 종료했을 때의 기록:

{
  "eventTime": "2026-03-07T03:15:22Z",
  "eventSource": "ec2.amazonaws.com",
  "eventName": "TerminateInstances",
  "awsRegion": "ap-northeast-2",
  "sourceIPAddress": "203.0.113.45",
  "userIdentity": {
    "type": "IAMUser",
    "userName": "kim-developer",
    "arn": "arn:aws:iam::123456789:user/kim-developer"
  },
  "requestParameters": {
    "instancesSet": {
      "items": [{ "instanceId": "i-0abc123def456" }]
    }
  },
  "responseElements": {
    "instancesSet": {
      "items": [{
        "instanceId": "i-0abc123def456",
        "currentState": { "name": "shutting-down" }
      }]
    }
  }
}

이 한 건의 로그에서 알 수 있는 것:

• 누가: kim-developer (IAM 사용자)
• 언제: 2026-03-07 새벽 3시 15분
• 어디서: IP 203.0.113.45, 서울 리전
• 무엇을: EC2 인스턴스 i-0abc123def456을 종료

"누가 서버를 삭제했어?"의 답이 3초 만에 나온다.

2. CloudTrail의 탄생 배경

규제와 감사의 요구

CloudTrail이 탄생한 배경에는 규제 준수(Compliance) 요구가 있다.

SOX법(Sarbanes-Oxley, 2002): 미국의 기업 회계 개혁법. 기업의 모든 재무 관련 IT 시스템에 대한 접근 로그와 변경 기록을 유지해야 한다.

PCI DSS: 신용카드 데이터를 다루는 기업은 시스템 접근에 대한 감사 추적(audit trail) 을 유지해야 한다.

HIPAA: 의료 데이터를 다루는 기업은 데이터 접근에 대한 로깅이 의무.

한국 전자금융감독규정: 금융기관은 정보시스템에 대한 접근 기록을 5년간 보관해야 한다.

이런 규제들은 공통적으로 **"누가, 언제, 무엇을 했는지 증명할 수 있어야 한다"**를 요구한다. CloudTrail은 이 요구의 AWS 구현이다.

3. CloudTrail의 세 가지 이벤트 유형

관리 이벤트, 데이터 이벤트, Insights 이벤트

4. CloudTrail이 핵심인 보안 사고들

사고 1: Capital One — CloudTrail이 증거를 제공

2019년 Capital One 사고(이 시리즈에서 반복 등장)에서, 공격자 Paige Thompson의 행동은 CloudTrail에 모두 기록되어 있었다.

CloudTrail 로그를 통해 수사관이 파악한 것:

• 어떤 IAM 역할이 사용됐는가
• 어떤 S3 버킷에 접근했는가
• 언제, 어떤 IP에서 접근했는가
• 어떤 데이터를 다운로드했는가

CloudTrail이 없었다면 공격 범위를 파악하는 것조차 불가능했을 것이다. FBI 수사에서 CloudTrail 로그가 핵심 증거로 사용됐다.

사고 2: SolarWinds 공격의 AWS 영향 분석

2020년 SolarWinds 공급망 공격 이후, 영향을 받은 기업들이 "공격자가 우리 AWS에서 뭘 했는가?"를 확인하는 데 CloudTrail을 사용했다. 공격자의 AWS API 호출 기록을 추적하여 피해 범위를 특정했다.

사고 3: 내부자 위협 감지

5. CloudTrail 실전 활용

활용 1: 보안 사고 조사 (포렌식)

"이 S3 버킷에 누가 접근했는가?"

-- CloudTrail Lake 쿼리
SELECT
  eventTime,
  userIdentity.arn AS who,
  sourceIPAddress AS from_ip,
  eventName AS action,
  requestParameters
FROM events
WHERE eventSource = 's3.amazonaws.com'
  AND requestParameters LIKE '%sensitive-bucket%'
  AND eventTime > '2026-03-01'
ORDER BY eventTime DESC

활용 2: 비용 이상 감지

"갑자기 EC2 비용이 올라갔는데, 누가 인스턴스를 만들었지?"

SELECT
  eventTime,
  userIdentity.userName AS who,
  requestParameters
FROM events
WHERE eventName = 'RunInstances'
  AND eventTime BETWEEN '2026-03-01' AND '2026-03-07'
ORDER BY eventTime DESC

활용 3: IAM 키 유출 대응

GitHub에 AWS 키가 노출됐다. 해당 키로 어떤 작업이 이루어졌는지 즉시 확인:

SELECT
  eventTime,
  eventName,
  awsRegion,
  sourceIPAddress,
  errorCode
FROM events
WHERE userIdentity.accessKeyId = 'AKIAIOSFODNN7EXAMPLE'
ORDER BY eventTime DESC

활용 4: 규제 준수 감사

감사관이 "지난 6개월간 프로덕션 DB에 누가 접근했는가?"를 요청할 때:

CloudTrail 로그를 S3에 장기 보관하고, Athena 또는 CloudTrail Lake로 쿼리하여 접근 기록을 즉시 제출.

6. CloudTrail vs CloudWatch Logs: 헷갈리기 쉬운 두 서비스

7. CloudTrail 구성 모범 사례

반드시 해야 할 것

1. 조직 전체 Trail 생성

모든 리전, 모든 계정의 이벤트를 하나의 S3 버킷에 수집:

aws cloudtrail create-trail \
  --name organization-trail \
  --s3-bucket-name my-cloudtrail-logs \
  --is-multi-region-trail \
  --is-organization-trail \
  --enable-log-file-validation

--enable-log-file-validation은 로그 파일의 위변조를 감지하는 기능. 공격자가 자신의 흔적을 삭제하려 해도 감지할 수 있다.

2. S3 버킷 보호

CloudTrail 로그가 저장되는 S3 버킷은 특별히 보호해야 한다:

• 버킷 정책으로 삭제 차단
• S3 Object Lock으로 변경·삭제 불가능하게
• 별도의 보안 계정(Log Archive Account)에 저장

3. EventBridge 알림 설정

위험한 행동을 실시간으로 감지:

{
  "source": ["aws.cloudtrail"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventName": [
      "DeleteTrail",
      "StopLogging",
      "CreateUser",
      "AttachUserPolicy"
    ]
  }
}

"CloudTrail 자체를 끄려는 시도", "새 IAM 사용자 생성", "정책 변경" — 이런 이벤트를 즉시 감지하여 Slack/이메일로 알림.

CloudTrail 비용

8. 실제 사례

AWS 자체의 CloudTrail 활용

AWS는 자체 서비스 운영에도 CloudTrail과 동일한 원리의 감사 로깅을 사용한다. 2019년 AWS Nitro System을 발표할 때, "AWS 직원조차 고객 인스턴스의 메모리에 접근할 수 없으며, 모든 접근 시도가 로깅된다"고 강조했다.

Goldman Sachs: 금융 규제 준수

Goldman Sachs는 CloudTrail을 활용하여 모든 AWS 리소스 접근을 감사한다. 규제 당국의 감사 요청 시, CloudTrail 로그에서 특정 기간의 접근 기록을 즉시 추출하여 제출한다.

Netflix: 보안 자동화

Netflix는 CloudTrail 이벤트를 실시간으로 분석하는 자체 보안 도구 Security Monkey (현재 Repokid로 진화)를 운영한다. 비정상적 IAM 활동을 자동으로 감지하고, 과도한 권한을 자동으로 축소한다.

한국 기업 사례

• 토스: 전자금융감독규정에 따라 CloudTrail로 모든 접근 기록을 5년간 S3 + Glacier에 보관. 금융감독원 감사 대응
• 카카오뱅크: CloudTrail + SIEM(보안 정보 이벤트 관리)으로 실시간 위협 감지
• 쿠팡: 멀티 계정 환경에서 Organizations Trail로 전 계정 감사 로그 중앙 수집

9. CloudTrail의 진화

CloudTrail Lake (2023~)

기존에는 CloudTrail → S3 → Athena로 쿼리해야 했다. CloudTrail Lake는 이벤트를 직접 SQL로 쿼리할 수 있는 관리형 데이터 레이크다:

• S3 + Glue + Athena 파이프라인 불필요
• 최대 7년간 이벤트를 Lake에 보관
• 대시보드 내장
• 교차 계정 이벤트 통합 분석

CloudTrail Insights: AI 기반 이상 감지

CloudTrail Insights는 평소의 API 호출 패턴을 학습하고, 비정상적인 패턴을 자동으로 감지한다:

• "평소 시간당 10건이던 RunInstances가 갑자기 500건" → 키 유출 의심
• "처음 보는 리전에서 API 호출" → 비인가 접근 의심
• "평소 사용하지 않던 API가 호출됨" → 공격자의 탐색 행위

마치며: "기록되지 않으면, 일어나지 않은 것과 같다"

보안의 세계에서 가장 무서운 것은 **"무슨 일이 일어났는지 모르는 것"**이다.

해킹을 당했는데 CloudTrail이 없으면:

• 공격자가 무엇에 접근했는지 모른다
• 언제부터 침입했는지 모른다
• 피해 범위가 어디까지인지 모른다
• 규제 당국에 보고할 증거가 없다
• 같은 공격을 방지할 방법을 모른다

이 시리즈에서 다룬 모든 보안 서비스의 관계:

IAM이 "예방"이라면, CloudTrail은 "탐지와 증거"다. 예방이 100% 완벽할 수는 없다. 그래서 탐지와 증거 수집이 필요하다.

코어닷투데이의 AWS 환경에서 CloudTrail은 항상 켜져 있다. 모든 API 호출이 기록되고, 위험한 행동은 즉시 알림이 오고, 로그는 변경 불가능한 상태로 장기 보관된다. "누가 언제 무엇을 했는가"에 대한 답은 항상 3초 안에 나온다. 그것이 안심하고 잠들 수 있는 보안의 기초다.