CloudTrail로 AWS 활동 추적 및 감사 완벽 가이드

AWS CloudTrail을 활용하여 누가, 언제, 무엇을 했는지 추적하고 감사하는 방법을 알아봅니다. 보안 사고 대응과 규정 준수를 위한 필수 서비스입니다.

1. CloudTrail의 역할과 중요성

어느 날 새벽 2시, 김개발 씨의 휴대폰이 울렸습니다. "운영 서버의 EC2 인스턴스가 모두 종료되었습니다." 다급히 AWS 콘솔에 접속한 김개발 씨는 당황했습니다.

대체 누가, 언제, 왜 인스턴스를 종료한 것일까요?

CloudTrail은 AWS 계정에서 발생하는 모든 API 호출을 기록하는 서비스입니다. 마치 건물의 CCTV가 모든 출입을 녹화하듯, CloudTrail은 AWS에서 일어나는 모든 활동을 빠짐없이 기록합니다.

이를 통해 보안 사고 조사, 규정 준수, 운영 문제 해결에 필수적인 증거를 확보할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

# CloudTrail 클라이언트 생성
cloudtrail = boto3.client('cloudtrail')

# 최근 이벤트 조회 - 누가 무엇을 했는지 확인
response = cloudtrail.lookup_events(
    LookupAttributes=[
        {
            'AttributeKey': 'EventName',
            'AttributeValue': 'TerminateInstances'  # EC2 종료 이벤트 추적
        }
    ],
    MaxResults=10
)

# 이벤트 상세 정보 출력
for event in response['Events']:
    print(f"시간: {event['EventTime']}")
    print(f"사용자: {event['Username']}")
    print(f"이벤트: {event['EventName']}")

김개발 씨는 입사 6개월 차 클라우드 엔지니어입니다. AWS를 다루는 일에는 어느 정도 익숙해졌지만, 이번처럼 갑작스러운 사고는 처음이었습니다.

새벽에 울린 알람에 급히 일어나 콘솔에 접속했지만, 이미 인스턴스는 모두 종료된 상태였습니다. "대체 누가 이런 짓을 한 거지?" 김개발 씨는 팀 슬랙 채널에 급하게 메시지를 보냈습니다.

하지만 아무도 자신이 종료했다고 대답하지 않았습니다. 해킹인 걸까요?

실수인 걸까요? 원인을 알 수 없어 더욱 불안해졌습니다.

이때 선배 개발자 박시니어 씨가 답장을 보냈습니다. "CloudTrail 확인해봤어요?" CloudTrail이란 정확히 무엇일까요?

쉽게 비유하자면, CloudTrail은 AWS 세계의 블랙박스와 같습니다. 자동차 블랙박스가 운행 중 발생하는 모든 상황을 녹화하듯, CloudTrail은 AWS 계정에서 발생하는 모든 API 호출을 기록합니다.

콘솔에서 버튼을 클릭하든, CLI로 명령어를 실행하든, SDK로 코드를 돌리든 모든 활동이 기록됩니다. CloudTrail이 없던 시절에는 어땠을까요?

사고가 발생하면 원인을 파악하기가 매우 어려웠습니다. 누군가 실수로 리소스를 삭제해도 증거가 없었습니다.

보안 감사를 받을 때도 활동 내역을 증명할 방법이 마땅치 않았습니다. 마치 CCTV 없는 건물에서 도난 사건이 발생한 것과 같았습니다.

바로 이런 문제를 해결하기 위해 AWS는 CloudTrail을 제공합니다. CloudTrail을 사용하면 누가, 언제, 어디서, 무엇을 했는지 정확히 파악할 수 있습니다.

API 호출의 소스 IP 주소, 사용된 IAM 자격 증명, 요청 파라미터까지 모두 기록됩니다. 이 정보는 보안 사고 조사뿐 아니라 규정 준수 감사, 운영 문제 해결에도 핵심적인 역할을 합니다.

위의 코드를 살펴보겠습니다. 먼저 boto3 라이브러리로 CloudTrail 클라이언트를 생성합니다.

그다음 lookup_events 메서드를 호출하여 특정 이벤트를 조회합니다. 이 예제에서는 'TerminateInstances' 이벤트, 즉 EC2 인스턴스 종료 이벤트만 필터링합니다.

결과로 반환된 이벤트에서 시간, 사용자, 이벤트명을 출력합니다. 실제로 김개발 씨가 이 코드를 실행하자 놀라운 결과가 나왔습니다.

"시간: 02:15:32, 사용자: terraform-automation-role, 이벤트: TerminateInstances" 범인은 해커가 아니었습니다. 자동화된 Terraform 스크립트가 잘못 설정되어 실행된 것이었습니다.

CloudTrail 덕분에 원인을 빠르게 파악하고 재발 방지 대책을 세울 수 있었습니다. 하지만 주의할 점도 있습니다.

CloudTrail의 기본 이벤트 기록은 90일간만 보관됩니다. 장기 보관이 필요하다면 별도로 **추적(Trail)**을 생성하여 S3 버킷에 저장해야 합니다.

또한 모든 이벤트가 실시간으로 기록되는 것은 아닙니다. 보통 15분 이내에 기록되지만, 이 지연 시간을 고려해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언 덕분에 김개발 씨는 CloudTrail의 중요성을 깨달았습니다.

"앞으로는 정기적으로 CloudTrail 로그를 모니터링해야겠어요." 이제 AWS 환경에서 일어나는 모든 일을 추적할 수 있다는 사실이 든든하게 느껴졌습니다.

실전 팁

💡 - CloudTrail은 기본적으로 활성화되어 있지만, 90일 이후 로그는 자동 삭제됩니다

중요한 계정에서는 반드시 S3 버킷으로 로그를 내보내는 추적을 설정하세요
lookup_events API는 최근 90일 이벤트만 조회 가능합니다

2. 관리 이벤트와 데이터 이벤트

김개발 씨가 CloudTrail 로그를 살펴보던 중 의문이 생겼습니다. EC2 인스턴스 생성, IAM 정책 변경 같은 이벤트는 잘 보이는데, S3 버킷에 파일을 업로드한 기록은 왜 보이지 않는 걸까요?

CloudTrail은 이벤트를 관리 이벤트와 데이터 이벤트로 구분합니다. 관리 이벤트는 리소스의 생성, 수정, 삭제와 같은 제어 작업을 기록하고, 데이터 이벤트는 리소스 내부의 데이터 작업을 기록합니다.

마치 은행에서 계좌 개설은 관리 이벤트, 입출금 거래는 데이터 이벤트와 같습니다.

다음 코드를 살펴봅시다.

import boto3

cloudtrail = boto3.client('cloudtrail')

# 추적 생성 시 이벤트 유형 설정
response = cloudtrail.put_event_selectors(
    TrailName='my-security-trail',
    EventSelectors=[
        {
            # 관리 이벤트 설정
            'ReadWriteType': 'All',  # 읽기/쓰기 모두 기록
            'IncludeManagementEvents': True,
            # 데이터 이벤트 설정 (S3 버킷)
            'DataResources': [
                {
                    'Type': 'AWS::S3::Object',
                    'Values': ['arn:aws:s3:::my-sensitive-bucket/']
                }
            ]
        }
    ]
)

print("이벤트 셀렉터 설정 완료")

박시니어 씨가 김개발 씨 옆에 앉았습니다. "CloudTrail 로그, 잘 보고 있어요?" "네, 그런데 이상한 게 있어요." 김개발 씨가 화면을 가리켰습니다.

"어제 누군가 S3 버킷에서 고객 데이터 파일을 다운로드했다는데, 로그에서 찾을 수가 없어요." 박시니어 씨가 고개를 끄덕였습니다. "아, 그건 데이터 이벤트라서 그래요.

기본적으로 CloudTrail은 관리 이벤트만 기록하거든요." CloudTrail의 이벤트는 크게 두 가지로 나뉩니다. 첫 번째는 **관리 이벤트(Management Events)**입니다.

이것은 AWS 리소스에 대한 제어 작업을 기록합니다. EC2 인스턴스 시작, IAM 사용자 생성, VPC 설정 변경, RDS 데이터베이스 삭제 등이 여기에 해당합니다.

마치 은행에서 계좌를 개설하거나 해지하는 것과 같은 관리적인 작업입니다. 두 번째는 **데이터 이벤트(Data Events)**입니다.

이것은 리소스 안에서 일어나는 데이터 작업을 기록합니다. S3 객체 업로드 및 다운로드, Lambda 함수 호출, DynamoDB 항목 읽기 및 쓰기 등이 여기에 해당합니다.

은행에 비유하면 계좌에서 입출금하는 거래 내역과 같습니다. 왜 이렇게 구분할까요?

데이터 이벤트는 발생 빈도가 매우 높기 때문입니다. 인기 있는 웹사이트의 S3 버킷에서는 초당 수천 건의 객체 요청이 발생할 수 있습니다.

이 모든 것을 기본으로 기록한다면 비용이 천문학적으로 늘어날 것입니다. 그래서 AWS는 데이터 이벤트를 선택적으로 활성화하도록 설계했습니다.

위의 코드를 살펴보겠습니다. put_event_selectors 메서드를 사용하여 추적에 이벤트 셀렉터를 설정합니다.

ReadWriteType을 'All'로 설정하면 읽기와 쓰기 이벤트를 모두 기록합니다. IncludeManagementEvents를 True로 설정하여 관리 이벤트를 활성화합니다.

그리고 DataResources 배열에서 특정 S3 버킷의 데이터 이벤트를 기록하도록 지정합니다. 실무에서는 어떻게 활용할까요?

금융 서비스 회사를 예로 들어보겠습니다. 고객의 금융 정보가 담긴 S3 버킷이 있다면, 누가 언제 그 데이터에 접근했는지 반드시 추적해야 합니다.

이럴 때 해당 버킷에 대해 데이터 이벤트를 활성화합니다. 반면, 공개 이미지가 저장된 버킷은 굳이 데이터 이벤트를 기록할 필요가 없을 수 있습니다.

주의할 점이 있습니다. 데이터 이벤트는 추가 비용이 발생합니다.

이벤트 100,000건당 비용이 청구되므로, 트래픽이 많은 버킷에 무분별하게 적용하면 예상치 못한 비용이 발생할 수 있습니다. 따라서 정말 감사가 필요한 민감한 데이터가 있는 리소스에만 선별적으로 적용하는 것이 좋습니다.

김개발 씨가 이해한 표정을 지었습니다. "그렇군요!

그럼 고객 데이터가 있는 버킷에만 데이터 이벤트를 켜면 되겠네요." 박시니어 씨가 웃었습니다. "맞아요.

모든 곳에 다 적용하면 비용 폭탄 맞을 수 있어요. 필요한 곳에만 현명하게 적용하세요."

실전 팁

💡 - 관리 이벤트는 무료로 첫 번째 추적에 포함되지만, 데이터 이벤트는 별도 비용이 발생합니다

민감한 데이터가 있는 S3 버킷, 중요한 Lambda 함수에만 데이터 이벤트를 활성화하세요
고급 이벤트 선택기를 사용하면 더 세밀한 필터링이 가능합니다

3. CloudTrail 추적 생성

김개발 씨는 CloudTrail의 기본 이벤트 기록이 90일만 보관된다는 사실을 알게 되었습니다. 보안 감사를 위해 최소 1년간의 로그가 필요한데, 어떻게 해야 할까요?

박시니어 씨가 알려준 해답은 바로 **추적(Trail)**을 생성하는 것이었습니다.

**추적(Trail)**은 CloudTrail 이벤트를 S3 버킷에 지속적으로 저장하는 설정입니다. 추적을 생성하면 90일 제한 없이 원하는 기간만큼 로그를 보관할 수 있습니다.

또한 CloudWatch Logs로 실시간 모니터링을 설정하거나, 여러 리전의 이벤트를 한곳에 모을 수도 있습니다.

다음 코드를 살펴봅시다.

import boto3

cloudtrail = boto3.client('cloudtrail')

# 멀티 리전 추적 생성
response = cloudtrail.create_trail(
    Name='company-security-trail',
    S3BucketName='my-cloudtrail-logs-bucket',
    S3KeyPrefix='cloudtrail-logs',
    IncludeGlobalServiceEvents=True,  # IAM 등 글로벌 서비스 이벤트 포함
    IsMultiRegionTrail=True,          # 모든 리전 이벤트 수집
    EnableLogFileValidation=True,     # 로그 무결성 검증 활성화
    KMSKeyId='arn:aws:kms:ap-northeast-2:123456789012:key/my-key'
)

# 추적 시작 (생성만으로는 로깅이 시작되지 않음)
cloudtrail.start_logging(Name='company-security-trail')

print(f"추적 생성 완료: {response['TrailARN']}")

김개발 씨가 보안팀으로부터 메일을 받았습니다. "내년 보안 감사를 위해 최근 1년간의 AWS 활동 로그가 필요합니다." 김개발 씨는 당황했습니다.

CloudTrail 콘솔에서 확인해보니 이벤트 기록은 90일치만 보관되고 있었습니다. 이미 지나간 기록은 영영 사라진 것일까요?

"걱정 마세요." 박시니어 씨가 말했습니다. "지금이라도 추적을 생성하면 앞으로의 로그는 영구 보관할 수 있어요.

이미 지나간 건 어쩔 수 없지만요." **추적(Trail)**이란 정확히 무엇일까요? 추적은 CloudTrail 이벤트를 외부 저장소로 내보내는 파이프라인과 같습니다.

물탱크에서 물이 넘치기 전에 수도관을 연결해 다른 곳으로 보내는 것처럼, 추적은 90일이 지나 사라지기 전에 이벤트를 S3 버킷으로 안전하게 옮겨줍니다. 추적을 생성할 때 중요한 설정들이 있습니다.

첫째, IsMultiRegionTrail입니다. 이것을 True로 설정하면 모든 AWS 리전에서 발생하는 이벤트를 수집합니다.

공격자가 잘 사용하지 않는 리전에서 리소스를 생성하는 경우가 많으므로, 멀티 리전 추적은 보안에 필수입니다. 둘째, IncludeGlobalServiceEvents입니다.

IAM, CloudFront, Route 53 같은 글로벌 서비스의 이벤트를 포함할지 결정합니다. 이런 서비스는 특정 리전에 속하지 않지만, 보안에 매우 중요하므로 반드시 포함해야 합니다.

셋째, EnableLogFileValidation입니다. 이 옵션을 활성화하면 로그 파일의 무결성을 검증할 수 있습니다.

누군가 로그 파일을 위조하거나 삭제해도 탐지할 수 있습니다. 법적 증거로 사용하려면 반드시 활성화해야 합니다.

위의 코드를 단계별로 살펴보겠습니다. create_trail 메서드로 추적을 생성합니다.

S3BucketName에 로그를 저장할 버킷을 지정합니다. 이 버킷은 미리 생성되어 있어야 하고, CloudTrail이 쓸 수 있는 권한이 설정되어야 합니다.

KMSKeyId를 지정하여 로그를 암호화할 수도 있습니다. 중요한 점은 start_logging을 호출해야 한다는 것입니다.

추적을 생성했다고 자동으로 로깅이 시작되지 않습니다. 반드시 start_logging을 호출하여 로깅을 시작해야 합니다.

이 부분을 놓치면 추적은 만들었는데 아무것도 기록되지 않는 상황이 발생합니다. 실무에서 흔히 하는 실수가 있습니다.

추적용 S3 버킷에 적절한 버킷 정책을 설정하지 않는 것입니다. CloudTrail은 로그를 쓰기 위해 특정 권한이 필요합니다.

AWS 문서에서 제공하는 버킷 정책 템플릿을 꼭 참고하세요. 김개발 씨가 물었습니다.

"추적을 여러 개 만들어도 되나요?" 박시니어 씨가 대답했습니다. "네, 가능해요.

하지만 첫 번째 추적의 관리 이벤트는 무료이고, 추가 추적부터는 비용이 발생해요. 보통은 하나의 멀티 리전 추적으로 충분합니다."

실전 팁

💡 - 추적 생성 후 반드시 start_logging을 호출해야 로깅이 시작됩니다

S3 버킷에 CloudTrail용 버킷 정책을 먼저 설정해야 합니다
조직 추적(Organization Trail)을 사용하면 모든 AWS 계정의 로그를 중앙에서 관리할 수 있습니다

4. S3에 로그 저장 및 암호화

추적을 생성한 김개발 씨는 또 다른 고민에 빠졌습니다. CloudTrail 로그에는 민감한 정보가 담겨 있을 수 있는데, S3 버킷에 그냥 저장해도 괜찮을까요?

보안팀에서 "로그도 암호화해야 한다"고 강조했던 말이 떠올랐습니다.

CloudTrail 로그를 S3에 저장할 때는 반드시 암호화와 접근 제어를 설정해야 합니다. AWS KMS를 사용한 서버 측 암호화(SSE-KMS)로 로그를 보호하고, 엄격한 버킷 정책으로 접근을 제한합니다.

또한 MFA Delete를 활성화하여 로그의 무단 삭제를 방지할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3
import json

s3 = boto3.client('s3')

# CloudTrail 로그 버킷의 버킷 정책 설정
bucket_policy = {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSCloudTrailAclCheck",
            "Effect": "Allow",
            "Principal": {"Service": "cloudtrail.amazonaws.com"},
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::my-cloudtrail-logs-bucket"
        },
        {
            "Sid": "AWSCloudTrailWrite",
            "Effect": "Allow",
            "Principal": {"Service": "cloudtrail.amazonaws.com"},
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::my-cloudtrail-logs-bucket/*",
            "Condition": {
                "StringEquals": {"s3:x-amz-acl": "bucket-owner-full-control"}
            }
        }
    ]
}

s3.put_bucket_policy(
    Bucket='my-cloudtrail-logs-bucket',
    Policy=json.dumps(bucket_policy)
)

보안팀 이보안 씨가 김개발 씨에게 찾아왔습니다. "CloudTrail 추적 설정했다고 들었어요.

로그 저장 버킷 보안은 어떻게 되어 있나요?" 김개발 씨가 자신 있게 대답했습니다. "S3 버킷에 저장하고 있어요." 이보안 씨의 표정이 굳어졌습니다.

"그 버킷, 암호화는요? 접근 제어는?

버전 관리는 활성화되어 있나요?" 김개발 씨는 아무 말도 하지 못했습니다. 그냥 버킷을 만들고 추적만 연결했을 뿐, 보안 설정은 생각하지 못했던 것입니다.

CloudTrail 로그 버킷은 왜 특별히 보호해야 할까요? CloudTrail 로그에는 누가 무엇을 했는지에 대한 모든 정보가 담겨 있습니다.

공격자 입장에서 이 로그를 삭제하거나 수정할 수 있다면, 자신의 흔적을 완전히 지울 수 있습니다. 따라서 로그 버킷은 AWS 환경에서 가장 철저하게 보호해야 할 리소스 중 하나입니다.

첫 번째로 암호화를 설정해야 합니다. CloudTrail은 기본적으로 S3 관리형 키(SSE-S3)로 로그를 암호화합니다.

하지만 더 높은 보안 수준을 원한다면 **AWS KMS(SSE-KMS)**를 사용해야 합니다. KMS를 사용하면 누가 로그를 복호화했는지도 CloudTrail에 기록되어, 로그에 대한 접근까지 감사할 수 있습니다.

두 번째로 버킷 정책을 설정해야 합니다. 위의 코드에서 보듯이, CloudTrail 서비스가 로그를 쓸 수 있도록 허용하면서도 다른 불필요한 접근은 차단해야 합니다.

또한 퍼블릭 액세스 차단을 활성화하여 실수로라도 버킷이 공개되지 않도록 해야 합니다. 세 번째로 버전 관리와 객체 잠금을 고려해야 합니다.

S3 버전 관리를 활성화하면 로그 파일이 삭제되거나 수정되어도 이전 버전을 복구할 수 있습니다. 더 나아가 **S3 객체 잠금(Object Lock)**을 사용하면 일정 기간 동안 로그를 삭제하거나 수정할 수 없게 만들 수 있습니다.

이는 규정 준수 요구사항을 충족하는 데 필수적입니다. 네 번째로 수명 주기 정책을 설정합니다.

로그를 영원히 보관하면 비용이 계속 늘어납니다. 보통 규정에 따라 1년, 3년, 7년 등의 보관 기간이 정해져 있습니다.

수명 주기 정책으로 오래된 로그를 S3 Glacier로 이동하거나, 보관 기간이 지난 로그를 자동 삭제할 수 있습니다. 이보안 씨가 설명을 마쳤습니다.

"이 정도는 기본이에요. 특히 금융, 의료 분야에서는 로그 보관과 무결성 증명이 법적 요구사항이기도 해요." 김개발 씨가 진지하게 메모했습니다.

"알겠습니다. 지금 바로 버킷 보안 설정을 점검해보겠습니다."

실전 팁

💡 - SSE-KMS 암호화를 사용하면 로그 접근도 감사할 수 있어 더 안전합니다

S3 객체 잠금의 거버넌스 모드와 규정 준수 모드의 차이를 이해하고 선택하세요
로그 버킷에 대한 접근 로그(S3 서버 액세스 로깅)도 활성화하면 이중 보안이 됩니다

5. CloudTrail Insights로 이상 활동 탐지

어느 날 김개발 씨는 AWS 비용 리포트를 보다가 깜짝 놀랐습니다. 지난주 EC2 인스턴스 시작 횟수가 평소의 10배나 되었습니다.

누군가 비정상적으로 많은 인스턴스를 생성한 것일까요? 이런 이상 패턴을 자동으로 탐지할 방법은 없을까요?

CloudTrail Insights는 머신러닝을 활용하여 AWS 계정의 비정상적인 활동을 자동으로 탐지합니다. 평소 API 호출 패턴을 학습하고, 이와 다른 비정상적인 급증이나 감소가 발생하면 자동으로 알림을 생성합니다.

마치 신용카드 회사가 평소와 다른 결제 패턴을 감지하는 것과 같습니다.

다음 코드를 살펴봅시다.

import boto3

cloudtrail = boto3.client('cloudtrail')

# 추적에 Insights 활성화
response = cloudtrail.put_insight_selectors(
    TrailName='company-security-trail',
    InsightSelectors=[
        {
            'InsightType': 'ApiCallRateInsight'  # API 호출 빈도 이상 탐지
        },
        {
            'InsightType': 'ApiErrorRateInsight'  # API 오류 빈도 이상 탐지
        }
    ]
)

# Insights 이벤트 조회
insights = cloudtrail.lookup_events(
    LookupAttributes=[
        {
            'AttributeKey': 'EventCategory',
            'AttributeValue': 'Insight'
        }
    ],
    MaxResults=5
)

for event in insights.get('Events', []):
    print(f"Insight 발견: {event['EventName']} at {event['EventTime']}")

"이거 좀 이상하지 않아요?" 김개발 씨가 AWS 콘솔 화면을 박시니어 씨에게 보여줬습니다. 비용 탐색기에서 EC2 관련 비용이 지난주에 급격히 상승한 것이 보였습니다.

박시니어 씨가 화면을 살펴보더니 말했습니다. "CloudTrail Insights 켜놨어요?

이런 이상 패턴을 자동으로 잡아주는 기능이 있어요." CloudTrail Insights란 무엇일까요? Insights는 CloudTrail의 지능형 탐지 기능입니다.

마치 은행에서 "고객님, 평소와 다른 해외 결제가 감지되었습니다"라고 알려주는 이상 거래 탐지 시스템과 같습니다. 평소의 API 호출 패턴을 학습하고, 이와 크게 다른 활동이 발생하면 자동으로 Insight 이벤트를 생성합니다.

Insights가 탐지하는 이상 활동에는 두 가지 유형이 있습니다. 첫 번째는 ApiCallRateInsight입니다.

특정 API의 호출 빈도가 평소보다 급격히 증가하거나 감소할 때 탐지합니다. 예를 들어, 평소 하루에 10번 호출되던 RunInstances가 갑자기 1000번 호출된다면 이상 징후로 감지됩니다.

두 번째는 ApiErrorRateInsight입니다. 특정 API의 오류율이 평소보다 급증할 때 탐지합니다.

공격자가 무작위로 접근을 시도하거나, 잘못된 자격 증명으로 반복적인 요청을 보낼 때 이런 패턴이 나타납니다. 어떻게 동작하는지 좀 더 자세히 살펴보겠습니다.

Insights는 지난 7일간의 API 호출 패턴을 **기준선(baseline)**으로 사용합니다. 그리고 현재 활동이 이 기준선에서 통계적으로 유의미하게 벗어나면 Insight 이벤트를 생성합니다.

이 과정은 모두 자동으로 이루어지므로, 별도의 규칙을 정의할 필요가 없습니다. 위의 코드를 살펴보겠습니다.

put_insight_selectors로 추적에 Insights를 활성화합니다. InsightSelectors 배열에 탐지하고 싶은 유형을 지정합니다.

두 가지 모두 활성화하는 것이 권장됩니다. 그다음 lookup_events로 EventCategory가 'Insight'인 이벤트를 조회하여 탐지된 이상 활동을 확인합니다.

실제로 Insights가 도움이 되는 상황을 생각해보겠습니다. 어느 날 새벽, 공격자가 탈취한 자격 증명으로 여러 리전에서 고사양 EC2 인스턴스를 대량으로 생성합니다.

암호화폐 채굴에 악용하려는 것입니다. 평소 RunInstances API는 하루에 몇 번 호출되지 않았는데, 갑자기 수백 번 호출됩니다.

Insights는 이를 즉시 탐지하여 알림을 생성합니다. 주의할 점도 있습니다.

Insights는 추가 비용이 발생합니다. 분석되는 이벤트 수에 따라 요금이 청구됩니다.

또한 활성화 후 최소 7일이 지나야 기준선이 형성되어 제대로 된 탐지가 시작됩니다. 그리고 Insights가 모든 유형의 이상을 탐지하는 것은 아닙니다.

API 호출 빈도에 초점을 맞추기 때문에, 다른 유형의 보안 위협은 별도 도구로 모니터링해야 합니다. 김개발 씨가 Insights를 활성화한 후, 마음이 한결 편해졌습니다.

"이제 뭔가 이상한 일이 생기면 자동으로 알려주겠네요."

실전 팁

💡 - Insights 활성화 후 7일이 지나야 기준선이 형성되어 정상 동작합니다

EventBridge와 연동하여 Insight 이벤트 발생 시 자동 알림을 받을 수 있습니다
Insights는 관리 이벤트에만 적용되며, 데이터 이벤트에는 적용되지 않습니다

6. 누가 언제 무엇을 했는지 추적하기

드디어 김개발 씨가 실제 보안 사고 조사를 맡게 되었습니다. 내부 감사팀에서 요청이 왔습니다.

"지난 화요일에 누군가 프로덕션 RDS 데이터베이스의 보안 그룹을 변경했습니다. 누가 했는지 확인해주세요." CloudTrail을 활용해 범인을 찾아봅시다.

CloudTrail 로그를 효과적으로 분석하면 AWS 환경에서 발생한 모든 활동을 추적할 수 있습니다. Athena를 사용하여 S3에 저장된 로그를 SQL로 쿼리하거나, CloudWatch Logs Insights로 실시간 분석을 수행할 수 있습니다.

이를 통해 누가, 언제, 어디서, 무엇을 했는지 정확하게 파악할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3
from datetime import datetime, timedelta

cloudtrail = boto3.client('cloudtrail')

# 특정 이벤트 검색 - 보안 그룹 변경 추적
response = cloudtrail.lookup_events(
    LookupAttributes=[
        {
            'AttributeKey': 'EventName',
            'AttributeValue': 'AuthorizeSecurityGroupIngress'
        }
    ],
    StartTime=datetime.now() - timedelta(days=7),
    EndTime=datetime.now(),
    MaxResults=50
)

for event in response['Events']:
    import json
    detail = json.loads(event['CloudTrailEvent'])
    print(f"시간: {event['EventTime']}")
    print(f"사용자: {detail.get('userIdentity', {}).get('userName', 'N/A')}")
    print(f"소스 IP: {detail.get('sourceIPAddress')}")
    print(f"리소스: {detail.get('requestParameters', {})}")
    print("-" * 50)

"화요일이라고요? 정확히 몇 시쯤인가요?" 김개발 씨가 감사팀에 물었습니다.

"오전 중으로 알고 있어요. 정확한 시간은 모르겠고요." 김개발 씨는 CloudTrail 콘솔을 열었습니다.

이제 실전입니다. 지금까지 배운 것을 모두 활용할 때입니다.

가장 먼저 이벤트 이름을 특정해야 합니다. 보안 그룹 관련 작업에는 여러 API가 있습니다.

AuthorizeSecurityGroupIngress(인바운드 규칙 추가), RevokeSecurityGroupIngress(인바운드 규칙 제거), AuthorizeSecurityGroupEgress(아웃바운드 규칙 추가) 등이 있습니다. 어떤 변경이었는지에 따라 검색할 이벤트가 달라집니다.

위의 코드를 살펴보겠습니다. lookup_events를 사용하여 최근 7일간의 AuthorizeSecurityGroupIngress 이벤트를 검색합니다.

StartTime과 EndTime으로 시간 범위를 지정합니다. 결과에서 CloudTrailEvent 필드를 JSON으로 파싱하면 상세 정보를 얻을 수 있습니다.

CloudTrail 이벤트에는 어떤 정보가 담겨 있을까요? userIdentity에는 API를 호출한 주체 정보가 있습니다.

IAM 사용자명, 역할, AWS 계정 ID 등을 확인할 수 있습니다. sourceIPAddress는 요청이 발생한 IP 주소입니다.

콘솔에서 작업했다면 사용자의 컴퓨터 IP가, CLI나 SDK를 사용했다면 해당 서버의 IP가 기록됩니다. eventTime은 정확한 발생 시각입니다.

requestParameters에는 API 호출 시 사용된 파라미터가 담겨 있습니다. 보안 그룹 변경의 경우, 어떤 포트를 열었는지, 어떤 IP 대역을 허용했는지 확인할 수 있습니다.

더 복잡한 분석이 필요하다면 Athena를 사용합니다. S3에 저장된 CloudTrail 로그를 SQL로 쿼리할 수 있습니다.

"지난 한 달간 IAM 정책을 변경한 모든 사용자와 변경 횟수"와 같은 복잡한 분석도 가능합니다. AWS에서 제공하는 CloudTrail용 Athena 테이블 생성 쿼리를 사용하면 쉽게 설정할 수 있습니다.

김개발 씨가 코드를 실행하자 결과가 나왔습니다. "시간: 2024-03-12 09:42:15, 사용자: deploy-user, 소스 IP: 10.0.1.50" 배포 자동화에 사용되는 서비스 계정이었습니다.

김개발 씨는 해당 서버의 담당자에게 연락했습니다. 확인 결과, 배포 스크립트에서 실수로 잘못된 보안 그룹 규칙이 적용된 것이었습니다.

"범인을 찾았어요!" 김개발 씨가 감사팀에 보고했습니다. "배포 스크립트 버그였습니다.

수정 완료했고, 재발 방지를 위해 배포 전 보안 그룹 변경을 검토하는 프로세스를 추가하겠습니다." 이보안 씨가 흐뭇하게 웃었습니다. "CloudTrail 제대로 활용하네요.

이제 AWS에서 무슨 일이 일어나도 추적할 수 있겠어요." CloudTrail은 AWS 환경의 디지털 포렌식 도구입니다. 보안 사고가 발생했을 때 원인을 파악하고, 영향 범위를 확인하고, 재발을 방지하는 데 핵심적인 역할을 합니다.

또한 규정 준수 감사에서 "누가 언제 무엇을 했는지" 증명해야 할 때도 필수입니다. 김개발 씨는 이제 CloudTrail을 확실히 이해하게 되었습니다.

AWS 환경에서 일어나는 모든 일을 추적하고 감사할 수 있다는 자신감이 생겼습니다.

실전 팁

💡 - Athena를 사용하면 대용량 로그도 SQL로 빠르게 분석할 수 있습니다

CloudWatch Logs로 로그를 스트리밍하면 실시간 알림과 모니터링이 가능합니다
정기적으로 중요 이벤트(IAM 변경, 보안 그룹 변경 등)에 대한 알림을 설정해두세요

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#CloudTrail#Security#Audit#Logging#Monitoring#AWS,CloudTrail,Security,Audit

CloudTrail로 AWS 활동 추적 및 감사 완벽 가이드

AWS CloudTrail을 활용하여 누가, 언제, 무엇을 했는지 추적하고 감사하는 방법을 알아봅니다. 보안 사고 대응과 규정 준수를 위한 필수 서비스입니다.

# CloudTrail로 AWS 활동 추적 및 감사 완벽 가이드 AWS CloudTrail을 활용하여 누가, 언제, 무엇을 했는지 추적하고 감사하는 방법을 알아봅니다. 보안 사고 대응과 규정 준수를 위한 필수 서비스입니다. --- ## 목차 1. [CloudTrail의_역할과_중요성](#cloudtrail의-역할과-중요성) 2. [관리_이벤트와_데이터_이벤트](#관리-이벤트와-데이터-이벤트) 3. [CloudTrail_추적_생성](#cloudtrail-추적-생성) 4. [S3에_로그_저장_및_암호화](#s3에-로그-저장-및-암호화) 5. [CloudTrail_Insights로_이상_활동_탐지](#cloudtrail-insights로-이상-활동-탐지) 6. [누가_언제_무엇을_했는지_추적하기](#누가-언제-무엇을-했는지-추적하기) --- ## 1. CloudTrail의_역할과_중요성 어느 날 새벽 2시, 김개발 씨의 휴대폰이 울렸습니다. "운영 서버의 EC2 인스턴스가 모두 종료되었습니다." 다급히 AWS 콘솔에 접속한 김개발 씨는 당황했습니다. 대체 누가, 언제, 왜 인스턴스를 종료한 것일까요? **CloudTrail**은 AWS 계정에서 발생하는 모든 API 호출을 기록하는 서비스입니다. 마치 건물의 CCTV가 모든 출입을 녹화하듯, CloudTrail은 AWS에서 일어나는 모든 활동을 빠짐없이 기록합니다. 이를 통해 보안 사고 조사, 규정 준수, 운영 문제 해결에 필수적인 증거를 확보할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 # CloudTrail 클라이언트 생성 cloudtrail = boto3.client('cloudtrail') # 최근 이벤트 조회 - 누가 무엇을 했는지 확인 response = cloudtrail.lookup_events( LookupAttributes=[ { 'AttributeKey': 'EventName', 'AttributeValue': 'TerminateInstances' # EC2 종료 이벤트 추적 } ], MaxResults=10 ) # 이벤트 상세 정보 출력 for event in response['Events']: print(f"시간: {event['EventTime']}") print(f"사용자: {event['Username']}") print(f"이벤트: {event['EventName']}") ``` 김개발 씨는 입사 6개월 차 클라우드 엔지니어입니다. AWS를 다루는 일에는 어느 정도 익숙해졌지만, 이번처럼 갑작스러운 사고는 처음이었습니다. 새벽에 울린 알람에 급히 일어나 콘솔에 접속했지만, 이미 인스턴스는 모두 종료된 상태였습니다. "대체 누가 이런 짓을 한 거지?" 김개발 씨는 팀 슬랙 채널에 급하게 메시지를 보냈습니다. 하지만 아무도 자신이 종료했다고 대답하지 않았습니다. 해킹인 걸까요? 실수인 걸까요? 원인을 알 수 없어 더욱 불안해졌습니다. 이때 선배 개발자 박시니어 씨가 답장을 보냈습니다. "CloudTrail 확인해봤어요?" **CloudTrail**이란 정확히 무엇일까요? 쉽게 비유하자면, CloudTrail은 AWS 세계의 **블랙박스**와 같습니다. 자동차 블랙박스가 운행 중 발생하는 모든 상황을 녹화하듯, CloudTrail은 AWS 계정에서 발생하는 모든 API 호출을 기록합니다. 콘솔에서 버튼을 클릭하든, CLI로 명령어를 실행하든, SDK로 코드를 돌리든 모든 활동이 기록됩니다. CloudTrail이 없던 시절에는 어땠을까요? 사고가 발생하면 원인을 파악하기가 매우 어려웠습니다. 누군가 실수로 리소스를 삭제해도 증거가 없었습니다. 보안 감사를 받을 때도 활동 내역을 증명할 방법이 마땅치 않았습니다. 마치 CCTV 없는 건물에서 도난 사건이 발생한 것과 같았습니다. 바로 이런 문제를 해결하기 위해 AWS는 CloudTrail을 제공합니다. CloudTrail을 사용하면 **누가, 언제, 어디서, 무엇을** 했는지 정확히 파악할 수 있습니다. API 호출의 소스 IP 주소, 사용된 IAM 자격 증명, 요청 파라미터까지 모두 기록됩니다. 이 정보는 보안 사고 조사뿐 아니라 규정 준수 감사, 운영 문제 해결에도 핵심적인 역할을 합니다. 위의 코드를 살펴보겠습니다. 먼저 boto3 라이브러리로 CloudTrail 클라이언트를 생성합니다. 그다음 **lookup_events** 메서드를 호출하여 특정 이벤트를 조회합니다. 이 예제에서는 'TerminateInstances' 이벤트, 즉 EC2 인스턴스 종료 이벤트만 필터링합니다. 결과로 반환된 이벤트에서 시간, 사용자, 이벤트명을 출력합니다. 실제로 김개발 씨가 이 코드를 실행하자 놀라운 결과가 나왔습니다. "시간: 02:15:32, 사용자: terraform-automation-role, 이벤트: TerminateInstances" 범인은 해커가 아니었습니다. 자동화된 Terraform 스크립트가 잘못 설정되어 실행된 것이었습니다. CloudTrail 덕분에 원인을 빠르게 파악하고 재발 방지 대책을 세울 수 있었습니다. 하지만 주의할 점도 있습니다. CloudTrail의 기본 이벤트 기록은 90일간만 보관됩니다. 장기 보관이 필요하다면 별도로 **추적(Trail)**을 생성하여 S3 버킷에 저장해야 합니다. 또한 모든 이벤트가 실시간으로 기록되는 것은 아닙니다. 보통 15분 이내에 기록되지만, 이 지연 시간을 고려해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언 덕분에 김개발 씨는 CloudTrail의 중요성을 깨달았습니다. "앞으로는 정기적으로 CloudTrail 로그를 모니터링해야겠어요." 이제 AWS 환경에서 일어나는 모든 일을 추적할 수 있다는 사실이 든든하게 느껴졌습니다. **실전 팁** 💡 - CloudTrail은 기본적으로 활성화되어 있지만, 90일 이후 로그는 자동 삭제됩니다 - 중요한 계정에서는 반드시 S3 버킷으로 로그를 내보내는 추적을 설정하세요 - lookup_events API는 최근 90일 이벤트만 조회 가능합니다 --- ## 2. 관리_이벤트와_데이터_이벤트 김개발 씨가 CloudTrail 로그를 살펴보던 중 의문이 생겼습니다. EC2 인스턴스 생성, IAM 정책 변경 같은 이벤트는 잘 보이는데, S3 버킷에 파일을 업로드한 기록은 왜 보이지 않는 걸까요? CloudTrail은 이벤트를 **관리 이벤트**와 **데이터 이벤트**로 구분합니다. 관리 이벤트는 리소스의 생성, 수정, 삭제와 같은 제어 작업을 기록하고, 데이터 이벤트는 리소스 내부의 데이터 작업을 기록합니다. 마치 은행에서 계좌 개설은 관리 이벤트, 입출금 거래는 데이터 이벤트와 같습니다. 다음 코드를 살펴봅시다. ```python import boto3 cloudtrail = boto3.client('cloudtrail') # 추적 생성 시 이벤트 유형 설정 response = cloudtrail.put_event_selectors( TrailName='my-security-trail', EventSelectors=[ { # 관리 이벤트 설정 'ReadWriteType': 'All', # 읽기/쓰기 모두 기록 'IncludeManagementEvents': True, # 데이터 이벤트 설정 (S3 버킷) 'DataResources': [ { 'Type': 'AWS::S3::Object', 'Values': ['arn:aws:s3:::my-sensitive-bucket/'] } ] } ] ) print("이벤트 셀렉터 설정 완료") ``` 박시니어 씨가 김개발 씨 옆에 앉았습니다. "CloudTrail 로그, 잘 보고 있어요?" "네, 그런데 이상한 게 있어요." 김개발 씨가 화면을 가리켰습니다. "어제 누군가 S3 버킷에서 고객 데이터 파일을 다운로드했다는데, 로그에서 찾을 수가 없어요." 박시니어 씨가 고개를 끄덕였습니다. "아, 그건 **데이터 이벤트**라서 그래요. 기본적으로 CloudTrail은 관리 이벤트만 기록하거든요." CloudTrail의 이벤트는 크게 두 가지로 나뉩니다. 첫 번째는 **관리 이벤트(Management Events)**입니다. 이것은 AWS 리소스에 대한 제어 작업을 기록합니다. EC2 인스턴스 시작, IAM 사용자 생성, VPC 설정 변경, RDS 데이터베이스 삭제 등이 여기에 해당합니다. 마치 은행에서 계좌를 개설하거나 해지하는 것과 같은 **관리적인** 작업입니다. 두 번째는 **데이터 이벤트(Data Events)**입니다. 이것은 리소스 **안에서** 일어나는 데이터 작업을 기록합니다. S3 객체 업로드 및 다운로드, Lambda 함수 호출, DynamoDB 항목 읽기 및 쓰기 등이 여기에 해당합니다. 은행에 비유하면 계좌에서 **입출금하는 거래 내역**과 같습니다. 왜 이렇게 구분할까요? 데이터 이벤트는 발생 빈도가 매우 높기 때문입니다. 인기 있는 웹사이트의 S3 버킷에서는 초당 수천 건의 객체 요청이 발생할 수 있습니다. 이 모든 것을 기본으로 기록한다면 비용이 천문학적으로 늘어날 것입니다. 그래서 AWS는 데이터 이벤트를 선택적으로 활성화하도록 설계했습니다. 위의 코드를 살펴보겠습니다. **put_event_selectors** 메서드를 사용하여 추적에 이벤트 셀렉터를 설정합니다. **ReadWriteType**을 'All'로 설정하면 읽기와 쓰기 이벤트를 모두 기록합니다. **IncludeManagementEvents**를 True로 설정하여 관리 이벤트를 활성화합니다. 그리고 **DataResources** 배열에서 특정 S3 버킷의 데이터 이벤트를 기록하도록 지정합니다. 실무에서는 어떻게 활용할까요? 금융 서비스 회사를 예로 들어보겠습니다. 고객의 금융 정보가 담긴 S3 버킷이 있다면, 누가 언제 그 데이터에 접근했는지 반드시 추적해야 합니다. 이럴 때 해당 버킷에 대해 데이터 이벤트를 활성화합니다. 반면, 공개 이미지가 저장된 버킷은 굳이 데이터 이벤트를 기록할 필요가 없을 수 있습니다. 주의할 점이 있습니다. 데이터 이벤트는 **추가 비용**이 발생합니다. 이벤트 100,000건당 비용이 청구되므로, 트래픽이 많은 버킷에 무분별하게 적용하면 예상치 못한 비용이 발생할 수 있습니다. 따라서 정말 감사가 필요한 민감한 데이터가 있는 리소스에만 선별적으로 적용하는 것이 좋습니다. 김개발 씨가 이해한 표정을 지었습니다. "그렇군요! 그럼 고객 데이터가 있는 버킷에만 데이터 이벤트를 켜면 되겠네요." 박시니어 씨가 웃었습니다. "맞아요. 모든 곳에 다 적용하면 비용 폭탄 맞을 수 있어요. 필요한 곳에만 현명하게 적용하세요." **실전 팁** 💡 - 관리 이벤트는 무료로 첫 번째 추적에 포함되지만, 데이터 이벤트는 별도 비용이 발생합니다 - 민감한 데이터가 있는 S3 버킷, 중요한 Lambda 함수에만 데이터 이벤트를 활성화하세요 - 고급 이벤트 선택기를 사용하면 더 세밀한 필터링이 가능합니다 --- ## 3. CloudTrail_추적_생성 김개발 씨는 CloudTrail의 기본 이벤트 기록이 90일만 보관된다는 사실을 알게 되었습니다. 보안 감사를 위해 최소 1년간의 로그가 필요한데, 어떻게 해야 할까요? 박시니어 씨가 알려준 해답은 바로 **추적(Trail)**을 생성하는 것이었습니다. **추적(Trail)**은 CloudTrail 이벤트를 S3 버킷에 지속적으로 저장하는 설정입니다. 추적을 생성하면 90일 제한 없이 원하는 기간만큼 로그를 보관할 수 있습니다. 또한 CloudWatch Logs로 실시간 모니터링을 설정하거나, 여러 리전의 이벤트를 한곳에 모을 수도 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 cloudtrail = boto3.client('cloudtrail') # 멀티 리전 추적 생성 response = cloudtrail.create_trail( Name='company-security-trail', S3BucketName='my-cloudtrail-logs-bucket', S3KeyPrefix='cloudtrail-logs', IncludeGlobalServiceEvents=True, # IAM 등 글로벌 서비스 이벤트 포함 IsMultiRegionTrail=True, # 모든 리전 이벤트 수집 EnableLogFileValidation=True, # 로그 무결성 검증 활성화 KMSKeyId='arn:aws:kms:ap-northeast-2:123456789012:key/my-key' ) # 추적 시작 (생성만으로는 로깅이 시작되지 않음) cloudtrail.start_logging(Name='company-security-trail') print(f"추적 생성 완료: {response['TrailARN']}") ``` 김개발 씨가 보안팀으로부터 메일을 받았습니다. "내년 보안 감사를 위해 최근 1년간의 AWS 활동 로그가 필요합니다." 김개발 씨는 당황했습니다. CloudTrail 콘솔에서 확인해보니 이벤트 기록은 90일치만 보관되고 있었습니다. 이미 지나간 기록은 영영 사라진 것일까요? "걱정 마세요." 박시니어 씨가 말했습니다. "지금이라도 추적을 생성하면 앞으로의 로그는 영구 보관할 수 있어요. 이미 지나간 건 어쩔 수 없지만요." **추적(Trail)**이란 정확히 무엇일까요? 추적은 CloudTrail 이벤트를 외부 저장소로 내보내는 **파이프라인**과 같습니다. 물탱크에서 물이 넘치기 전에 수도관을 연결해 다른 곳으로 보내는 것처럼, 추적은 90일이 지나 사라지기 전에 이벤트를 S3 버킷으로 안전하게 옮겨줍니다. 추적을 생성할 때 중요한 설정들이 있습니다. 첫째, **IsMultiRegionTrail**입니다. 이것을 True로 설정하면 모든 AWS 리전에서 발생하는 이벤트를 수집합니다. 공격자가 잘 사용하지 않는 리전에서 리소스를 생성하는 경우가 많으므로, 멀티 리전 추적은 보안에 필수입니다. 둘째, **IncludeGlobalServiceEvents**입니다. IAM, CloudFront, Route 53 같은 글로벌 서비스의 이벤트를 포함할지 결정합니다. 이런 서비스는 특정 리전에 속하지 않지만, 보안에 매우 중요하므로 반드시 포함해야 합니다. 셋째, **EnableLogFileValidation**입니다. 이 옵션을 활성화하면 로그 파일의 무결성을 검증할 수 있습니다. 누군가 로그 파일을 위조하거나 삭제해도 탐지할 수 있습니다. 법적 증거로 사용하려면 반드시 활성화해야 합니다. 위의 코드를 단계별로 살펴보겠습니다. **create_trail** 메서드로 추적을 생성합니다. S3BucketName에 로그를 저장할 버킷을 지정합니다. 이 버킷은 미리 생성되어 있어야 하고, CloudTrail이 쓸 수 있는 권한이 설정되어야 합니다. KMSKeyId를 지정하여 로그를 암호화할 수도 있습니다. 중요한 점은 **start_logging**을 호출해야 한다는 것입니다. 추적을 생성했다고 자동으로 로깅이 시작되지 않습니다. 반드시 start_logging을 호출하여 로깅을 시작해야 합니다. 이 부분을 놓치면 추적은 만들었는데 아무것도 기록되지 않는 상황이 발생합니다. 실무에서 흔히 하는 실수가 있습니다. 추적용 S3 버킷에 적절한 버킷 정책을 설정하지 않는 것입니다. CloudTrail은 로그를 쓰기 위해 특정 권한이 필요합니다. AWS 문서에서 제공하는 버킷 정책 템플릿을 꼭 참고하세요. 김개발 씨가 물었습니다. "추적을 여러 개 만들어도 되나요?" 박시니어 씨가 대답했습니다. "네, 가능해요. 하지만 첫 번째 추적의 관리 이벤트는 무료이고, 추가 추적부터는 비용이 발생해요. 보통은 하나의 멀티 리전 추적으로 충분합니다." **실전 팁** 💡 - 추적 생성 후 반드시 start_logging을 호출해야 로깅이 시작됩니다 - S3 버킷에 CloudTrail용 버킷 정책을 먼저 설정해야 합니다 - 조직 추적(Organization Trail)을 사용하면 모든 AWS 계정의 로그를 중앙에서 관리할 수 있습니다 --- ## 4. S3에_로그_저장_및_암호화 추적을 생성한 김개발 씨는 또 다른 고민에 빠졌습니다. CloudTrail 로그에는 민감한 정보가 담겨 있을 수 있는데, S3 버킷에 그냥 저장해도 괜찮을까요? 보안팀에서 "로그도 암호화해야 한다"고 강조했던 말이 떠올랐습니다. CloudTrail 로그를 S3에 저장할 때는 반드시 **암호화**와 **접근 제어**를 설정해야 합니다. AWS KMS를 사용한 서버 측 암호화(SSE-KMS)로 로그를 보호하고, 엄격한 버킷 정책으로 접근을 제한합니다. 또한 MFA Delete를 활성화하여 로그의 무단 삭제를 방지할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 import json s3 = boto3.client('s3') # CloudTrail 로그 버킷의 버킷 정책 설정 bucket_policy = { "Version": "2012-10-17", "Statement": [ { "Sid": "AWSCloudTrailAclCheck", "Effect": "Allow", "Principal": {"Service": "cloudtrail.amazonaws.com"}, "Action": "s3:GetBucketAcl", "Resource": "arn:aws:s3:::my-cloudtrail-logs-bucket" }, { "Sid": "AWSCloudTrailWrite", "Effect": "Allow", "Principal": {"Service": "cloudtrail.amazonaws.com"}, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::my-cloudtrail-logs-bucket/*", "Condition": { "StringEquals": {"s3:x-amz-acl": "bucket-owner-full-control"} } } ] } s3.put_bucket_policy( Bucket='my-cloudtrail-logs-bucket', Policy=json.dumps(bucket_policy) ) ``` 보안팀 이보안 씨가 김개발 씨에게 찾아왔습니다. "CloudTrail 추적 설정했다고 들었어요. 로그 저장 버킷 보안은 어떻게 되어 있나요?" 김개발 씨가 자신 있게 대답했습니다. "S3 버킷에 저장하고 있어요." 이보안 씨의 표정이 굳어졌습니다. "그 버킷, 암호화는요? 접근 제어는? 버전 관리는 활성화되어 있나요?" 김개발 씨는 아무 말도 하지 못했습니다. 그냥 버킷을 만들고 추적만 연결했을 뿐, 보안 설정은 생각하지 못했던 것입니다. **CloudTrail 로그 버킷**은 왜 특별히 보호해야 할까요? CloudTrail 로그에는 누가 무엇을 했는지에 대한 모든 정보가 담겨 있습니다. 공격자 입장에서 이 로그를 삭제하거나 수정할 수 있다면, 자신의 흔적을 완전히 지울 수 있습니다. 따라서 로그 버킷은 AWS 환경에서 가장 철저하게 보호해야 할 리소스 중 하나입니다. 첫 번째로 **암호화**를 설정해야 합니다. CloudTrail은 기본적으로 S3 관리형 키(SSE-S3)로 로그를 암호화합니다. 하지만 더 높은 보안 수준을 원한다면 **AWS KMS(SSE-KMS)**를 사용해야 합니다. KMS를 사용하면 누가 로그를 복호화했는지도 CloudTrail에 기록되어, 로그에 대한 접근까지 감사할 수 있습니다. 두 번째로 **버킷 정책**을 설정해야 합니다. 위의 코드에서 보듯이, CloudTrail 서비스가 로그를 쓸 수 있도록 허용하면서도 다른 불필요한 접근은 차단해야 합니다. 또한 **퍼블릭 액세스 차단**을 활성화하여 실수로라도 버킷이 공개되지 않도록 해야 합니다. 세 번째로 **버전 관리와 객체 잠금**을 고려해야 합니다. S3 버전 관리를 활성화하면 로그 파일이 삭제되거나 수정되어도 이전 버전을 복구할 수 있습니다. 더 나아가 **S3 객체 잠금(Object Lock)**을 사용하면 일정 기간 동안 로그를 삭제하거나 수정할 수 없게 만들 수 있습니다. 이는 규정 준수 요구사항을 충족하는 데 필수적입니다. 네 번째로 **수명 주기 정책**을 설정합니다. 로그를 영원히 보관하면 비용이 계속 늘어납니다. 보통 규정에 따라 1년, 3년, 7년 등의 보관 기간이 정해져 있습니다. 수명 주기 정책으로 오래된 로그를 S3 Glacier로 이동하거나, 보관 기간이 지난 로그를 자동 삭제할 수 있습니다. 이보안 씨가 설명을 마쳤습니다. "이 정도는 기본이에요. 특히 금융, 의료 분야에서는 로그 보관과 무결성 증명이 법적 요구사항이기도 해요." 김개발 씨가 진지하게 메모했습니다. "알겠습니다. 지금 바로 버킷 보안 설정을 점검해보겠습니다." **실전 팁** 💡 - SSE-KMS 암호화를 사용하면 로그 접근도 감사할 수 있어 더 안전합니다 - S3 객체 잠금의 거버넌스 모드와 규정 준수 모드의 차이를 이해하고 선택하세요 - 로그 버킷에 대한 접근 로그(S3 서버 액세스 로깅)도 활성화하면 이중 보안이 됩니다 --- ## 5. CloudTrail_Insights로_이상_활동_탐지 어느 날 김개발 씨는 AWS 비용 리포트를 보다가 깜짝 놀랐습니다. 지난주 EC2 인스턴스 시작 횟수가 평소의 10배나 되었습니다. 누군가 비정상적으로 많은 인스턴스를 생성한 것일까요? 이런 이상 패턴을 자동으로 탐지할 방법은 없을까요? **CloudTrail Insights**는 머신러닝을 활용하여 AWS 계정의 비정상적인 활동을 자동으로 탐지합니다. 평소 API 호출 패턴을 학습하고, 이와 다른 비정상적인 급증이나 감소가 발생하면 자동으로 알림을 생성합니다. 마치 신용카드 회사가 평소와 다른 결제 패턴을 감지하는 것과 같습니다. 다음 코드를 살펴봅시다. ```python import boto3 cloudtrail = boto3.client('cloudtrail') # 추적에 Insights 활성화 response = cloudtrail.put_insight_selectors( TrailName='company-security-trail', InsightSelectors=[ { 'InsightType': 'ApiCallRateInsight' # API 호출 빈도 이상 탐지 }, { 'InsightType': 'ApiErrorRateInsight' # API 오류 빈도 이상 탐지 } ] ) # Insights 이벤트 조회 insights = cloudtrail.lookup_events( LookupAttributes=[ { 'AttributeKey': 'EventCategory', 'AttributeValue': 'Insight' } ], MaxResults=5 ) for event in insights.get('Events', []): print(f"Insight 발견: {event['EventName']} at {event['EventTime']}") ``` "이거 좀 이상하지 않아요?" 김개발 씨가 AWS 콘솔 화면을 박시니어 씨에게 보여줬습니다. 비용 탐색기에서 EC2 관련 비용이 지난주에 급격히 상승한 것이 보였습니다. 박시니어 씨가 화면을 살펴보더니 말했습니다. "CloudTrail Insights 켜놨어요? 이런 이상 패턴을 자동으로 잡아주는 기능이 있어요." **CloudTrail Insights**란 무엇일까요? Insights는 CloudTrail의 **지능형 탐지 기능**입니다. 마치 은행에서 "고객님, 평소와 다른 해외 결제가 감지되었습니다"라고 알려주는 이상 거래 탐지 시스템과 같습니다. 평소의 API 호출 패턴을 학습하고, 이와 크게 다른 활동이 발생하면 자동으로 Insight 이벤트를 생성합니다. Insights가 탐지하는 이상 활동에는 두 가지 유형이 있습니다. 첫 번째는 **ApiCallRateInsight**입니다. 특정 API의 호출 빈도가 평소보다 급격히 증가하거나 감소할 때 탐지합니다. 예를 들어, 평소 하루에 10번 호출되던 RunInstances가 갑자기 1000번 호출된다면 이상 징후로 감지됩니다. 두 번째는 **ApiErrorRateInsight**입니다. 특정 API의 오류율이 평소보다 급증할 때 탐지합니다. 공격자가 무작위로 접근을 시도하거나, 잘못된 자격 증명으로 반복적인 요청을 보낼 때 이런 패턴이 나타납니다. 어떻게 동작하는지 좀 더 자세히 살펴보겠습니다. Insights는 지난 7일간의 API 호출 패턴을 **기준선(baseline)**으로 사용합니다. 그리고 현재 활동이 이 기준선에서 통계적으로 유의미하게 벗어나면 Insight 이벤트를 생성합니다. 이 과정은 모두 자동으로 이루어지므로, 별도의 규칙을 정의할 필요가 없습니다. 위의 코드를 살펴보겠습니다. **put_insight_selectors**로 추적에 Insights를 활성화합니다. InsightSelectors 배열에 탐지하고 싶은 유형을 지정합니다. 두 가지 모두 활성화하는 것이 권장됩니다. 그다음 **lookup_events**로 EventCategory가 'Insight'인 이벤트를 조회하여 탐지된 이상 활동을 확인합니다. 실제로 Insights가 도움이 되는 상황을 생각해보겠습니다. 어느 날 새벽, 공격자가 탈취한 자격 증명으로 여러 리전에서 고사양 EC2 인스턴스를 대량으로 생성합니다. 암호화폐 채굴에 악용하려는 것입니다. 평소 RunInstances API는 하루에 몇 번 호출되지 않았는데, 갑자기 수백 번 호출됩니다. Insights는 이를 즉시 탐지하여 알림을 생성합니다. 주의할 점도 있습니다. Insights는 **추가 비용**이 발생합니다. 분석되는 이벤트 수에 따라 요금이 청구됩니다. 또한 활성화 후 최소 7일이 지나야 기준선이 형성되어 제대로 된 탐지가 시작됩니다. 그리고 Insights가 모든 유형의 이상을 탐지하는 것은 아닙니다. API 호출 빈도에 초점을 맞추기 때문에, 다른 유형의 보안 위협은 별도 도구로 모니터링해야 합니다. 김개발 씨가 Insights를 활성화한 후, 마음이 한결 편해졌습니다. "이제 뭔가 이상한 일이 생기면 자동으로 알려주겠네요." **실전 팁** 💡 - Insights 활성화 후 7일이 지나야 기준선이 형성되어 정상 동작합니다 - EventBridge와 연동하여 Insight 이벤트 발생 시 자동 알림을 받을 수 있습니다 - Insights는 관리 이벤트에만 적용되며, 데이터 이벤트에는 적용되지 않습니다 --- ## 6. 누가_언제_무엇을_했는지_추적하기 드디어 김개발 씨가 실제 보안 사고 조사를 맡게 되었습니다. 내부 감사팀에서 요청이 왔습니다. "지난 화요일에 누군가 프로덕션 RDS 데이터베이스의 보안 그룹을 변경했습니다. 누가 했는지 확인해주세요." CloudTrail을 활용해 범인을 찾아봅시다. CloudTrail 로그를 효과적으로 분석하면 AWS 환경에서 발생한 모든 활동을 추적할 수 있습니다. **Athena**를 사용하여 S3에 저장된 로그를 SQL로 쿼리하거나, **CloudWatch Logs Insights**로 실시간 분석을 수행할 수 있습니다. 이를 통해 누가, 언제, 어디서, 무엇을 했는지 정확하게 파악할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 from datetime import datetime, timedelta cloudtrail = boto3.client('cloudtrail') # 특정 이벤트 검색 - 보안 그룹 변경 추적 response = cloudtrail.lookup_events( LookupAttributes=[ { 'AttributeKey': 'EventName', 'AttributeValue': 'AuthorizeSecurityGroupIngress' } ], StartTime=datetime.now() - timedelta(days=7), EndTime=datetime.now(), MaxResults=50 ) for event in response['Events']: import json detail = json.loads(event['CloudTrailEvent']) print(f"시간: {event['EventTime']}") print(f"사용자: {detail.get('userIdentity', {}).get('userName', 'N/A')}") print(f"소스 IP: {detail.get('sourceIPAddress')}") print(f"리소스: {detail.get('requestParameters', {})}") print("-" * 50) ``` "화요일이라고요? 정확히 몇 시쯤인가요?" 김개발 씨가 감사팀에 물었습니다. "오전 중으로 알고 있어요. 정확한 시간은 모르겠고요." 김개발 씨는 CloudTrail 콘솔을 열었습니다. 이제 실전입니다. 지금까지 배운 것을 모두 활용할 때입니다. 가장 먼저 **이벤트 이름**을 특정해야 합니다. 보안 그룹 관련 작업에는 여러 API가 있습니다. AuthorizeSecurityGroupIngress(인바운드 규칙 추가), RevokeSecurityGroupIngress(인바운드 규칙 제거), AuthorizeSecurityGroupEgress(아웃바운드 규칙 추가) 등이 있습니다. 어떤 변경이었는지에 따라 검색할 이벤트가 달라집니다. 위의 코드를 살펴보겠습니다. **lookup_events**를 사용하여 최근 7일간의 AuthorizeSecurityGroupIngress 이벤트를 검색합니다. StartTime과 EndTime으로 시간 범위를 지정합니다. 결과에서 **CloudTrailEvent** 필드를 JSON으로 파싱하면 상세 정보를 얻을 수 있습니다. CloudTrail 이벤트에는 어떤 정보가 담겨 있을까요? **userIdentity**에는 API를 호출한 주체 정보가 있습니다. IAM 사용자명, 역할, AWS 계정 ID 등을 확인할 수 있습니다. **sourceIPAddress**는 요청이 발생한 IP 주소입니다. 콘솔에서 작업했다면 사용자의 컴퓨터 IP가, CLI나 SDK를 사용했다면 해당 서버의 IP가 기록됩니다. **eventTime**은 정확한 발생 시각입니다. **requestParameters**에는 API 호출 시 사용된 파라미터가 담겨 있습니다. 보안 그룹 변경의 경우, 어떤 포트를 열었는지, 어떤 IP 대역을 허용했는지 확인할 수 있습니다. 더 복잡한 분석이 필요하다면 **Athena**를 사용합니다. S3에 저장된 CloudTrail 로그를 SQL로 쿼리할 수 있습니다. "지난 한 달간 IAM 정책을 변경한 모든 사용자와 변경 횟수"와 같은 복잡한 분석도 가능합니다. AWS에서 제공하는 CloudTrail용 Athena 테이블 생성 쿼리를 사용하면 쉽게 설정할 수 있습니다. 김개발 씨가 코드를 실행하자 결과가 나왔습니다. "시간: 2024-03-12 09:42:15, 사용자: deploy-user, 소스 IP: 10.0.1.50" 배포 자동화에 사용되는 서비스 계정이었습니다. 김개발 씨는 해당 서버의 담당자에게 연락했습니다. 확인 결과, 배포 스크립트에서 실수로 잘못된 보안 그룹 규칙이 적용된 것이었습니다. "범인을 찾았어요!" 김개발 씨가 감사팀에 보고했습니다. "배포 스크립트 버그였습니다. 수정 완료했고, 재발 방지를 위해 배포 전 보안 그룹 변경을 검토하는 프로세스를 추가하겠습니다." 이보안 씨가 흐뭇하게 웃었습니다. "CloudTrail 제대로 활용하네요. 이제 AWS에서 무슨 일이 일어나도 추적할 수 있겠어요." CloudTrail은 AWS 환경의 **디지털 포렌식** 도구입니다. 보안 사고가 발생했을 때 원인을 파악하고, 영향 범위를 확인하고, 재발을 방지하는 데 핵심적인 역할을 합니다. 또한 규정 준수 감사에서 "누가 언제 무엇을 했는지" 증명해야 할 때도 필수입니다. 김개발 씨는 이제 CloudTrail을 확실히 이해하게 되었습니다. AWS 환경에서 일어나는 모든 일을 추적하고 감사할 수 있다는 자신감이 생겼습니다. **실전 팁** 💡 - Athena를 사용하면 대용량 로그도 SQL로 빠르게 분석할 수 있습니다 - CloudWatch Logs로 로그를 스트리밍하면 실시간 알림과 모니터링이 가능합니다 - 정기적으로 중요 이벤트(IAM 변경, 보안 그룹 변경 등)에 대한 알림을 설정해두세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS,CloudTrail,Security,Audit

언어: Python

태그: AWS, CloudTrail, Security, Audit, Logging, Monitoring, AWS,CloudTrail,Security,Audit

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

CloudTrail로 AWS 활동 추적 및 감사 완벽 가이드

목차

1. CloudTrail의 역할과 중요성

2. 관리 이벤트와 데이터 이벤트

3. CloudTrail 추적 생성

4. S3에 로그 저장 및 암호화

5. CloudTrail Insights로 이상 활동 탐지

6. 누가 언제 무엇을 했는지 추적하기

댓글 (0)

함께 보면 좋은 카드 뉴스

CloudFormation 중첩 스택과 재사용 패턴

CloudFormation으로 Infrastructure as Code 구현하기

AWS Service Quotas로 리소스 한도 확인 및 증가 완벽 가이드

CloudWatch로 리소스 모니터링 및 자동화 완벽 가이드

IAM으로 AWS 보안 및 권한 체계 구축