AWS CloudTrail vs GCP Audit Logs: 클라우드 보안 감사 모니터링 설계

AWS CloudTrail 뭐하는 녀석인가

1) 개념 요약

CloudTrail = “AWS 계정에서 누가(Who), 언제(When), 무엇을(What), 어디서(Where) 했는지 기록하는 보안·감사 로그 서비스”

AWS Console / CLI / SDK / 기타 서비스의 API 호출 내역을 기록
관리형 서비스라서 계정 생성 시점부터 기본적으로 일부는 자동 활성화
계정 단위/조직 단위(Organizations)로 구성 가능
로그를 S3, CloudWatch Logs, EventBridge 등으로 연계 → 장기보관/실시간 탐지에 활용

2) CloudTrail이 기록하는 주요 정보

각 이벤트(로그 레코드)에는 보통 이런 정보가 포함됩니다.

eventTime: 언제 호출되었는지 (UTC 시간)
eventSource: 어느 서비스인지 (예: ec2.amazonaws.com)
eventName: 어떤 API 호출인지 (예: RunInstances, CreateUser)
userIdentity: 누가 호출했는지
- IAM User, Role, Federated User, Root, AWS 서비스 계정 등
sourceIPAddress: 어디에서 접근했는지 (IP)
userAgent: 브라우저, CLI, SDK 등 클라이언트 정보
requestParameters / responseElements: 어떤 파라미터로 무엇을 요청/응답했는지
errorCode / errorMessage: 실패 시 오류 정보

→ 즉, “누가 / 언제 / 어디서 / 어떤 권한으로 / 무슨 행동 / 결과는 어땠는지”를 남기는 감사 추적(Audit Trail) 역할.

3) CloudTrail 로그 유형

CloudTrail은 크게 다음과 같은 이벤트를 다룹니다.

Management Events (제어면, Control Plane)
- 계정, IAM, 보안 설정, 리소스 생성/변경/삭제 등
- 예: EC2 인스턴스 생성, IAM 사용자/Role 생성, S3 버킷 정책 변경
- 기본적으로 대부분의 트레일에 포함되는 핵심 대상
Data Events (데이터면, Data Plane)
- 리소스 내부 데이터 접근/조작 이벤트
- 예: S3 GetObject / PutObject, Lambda Invoke
- 관리 이벤트보다 로그량이 많고 비용 영향이 커서 선택적으로 활성화
Insights Events (이상 행위 감지용)
- 비정상적인 API 호출 패턴 감지 (예: 특정 API 호출 빈도 급증 등)
- 기본 이벤트에서 통계를 뽑아 “이상하다 싶을 때만” 추가 레코드 생성

4) CloudTrail 구성 요소

Trail (트레일)
- “어떤 이벤트를(Management/Data/Insights), 어느 리전에서, 어느 계정에 대해, 어디(S3/CloudWatch)로 보낼지” 정의하는 설정 단위
- Organization Trail 기능으로 AWS Organizations 전체 계정에 동일 정책 적용 가능
Event History (이벤트 히스토리)
- 콘솔에서 기본 제공되는 최근 90일 관리 이벤트 조회 기능
- 별도 S3 저장 설정 없이도 짧은 감사 용도로는 바로 사용 가능
S3 / CloudWatch Logs / EventBridge 연동
- S3: 장기 보관, 다른 분석 도구(SIEM 등) 연계
- CloudWatch Logs: 로그 기반 Metric/Alarm 설정
- EventBridge: 특정 이벤트 → 자동 대응(예: 계정 생성 시 자동 권한 축소 Lambda 호출)

5) 보안·컴플라이언스 CloudTrail 역할

포렌식 조사: 사고 발생 시 “누가, 언제, 뭘 잘못했는지” 추적
권한 오남용 탐지: Root 계정 사용, IAM 정책 변경, Key 생성/삭제 등 감시
변경 관리(Change Management): 인프라 변경이 표준 절차를 따랐는지 검증
컴플라이언스 대응: ISO 27001, SOC 2, 금융권 등에서 요구하는 Audit Trail 제공

GCP에서 CloudTrail에 대응하는 서비스 구조

GCP에는 CloudTrail과 1:1로 완전히 동일한 이름의 서비스는 없지만, 기능 관점에서 조합하면 거의 동일하거나 더 세밀하게 구현 가능합니다.

1) CloudTrail에 가장 직접 대응: Cloud Audit Logs

Cloud Audit Logs = “GCP 리소스에 대한 관리 및 데이터 접근 로그”
→ CloudTrail의 Management / Data Events에 해당

Audit Logs는 다음 4유형이 있습니다.

Admin Activity Logs
- 리소스 생성/수정/삭제 같은 관리 작업 로그
- 항상 활성화(Opt-out 불가), 비용은 별도 과금 X (로그 저장 시 스토리지 비용만)
Data Access Logs
- 데이터 읽기/쓰기 작업이 주 대상
- 예: BigQuery Table Query, Cloud Storage 객체 읽기/쓰기, Secret Manager Secret 접근 등
- 대부분 서비스에서 기본 비활성화 → 필요 서비스에만 Opt-in
- CloudTrail의 Data Events에 해당
System Event Logs
- Google 내부 시스템에서 발생하는 리소스 관리 이벤트
- 예: 자동 스케일링, 시스템 관리에 따른 리소스 변경 등
Policy Denied Logs
- IAM Policy 나 Org Policy 등에 의해 거부된 요청
- AWS에서는 AccessDenied 에러를 CloudTrail에서 보는 느낌과 비슷

→ 이 모든 Audit Logs는 Cloud Logging(예전 Stackdriver Logging)에 저장됩니다.

2) 로그 저장·검색·연동: Cloud Logging

CloudTrail + CloudWatch Logs + S3의 역할을 GCP에서는 조합해서 사용합니다.

Cloud Logging
- Audit Logs를 기본 저장
- 강력한 필터 기능으로 특정 이벤트 검색
  - 예: IAM 역할 변경
  - resource.type="iam_role" protoPayload.methodName="google.iam.admin.v1.CreateRole"
Log Router / Sinks
- 로그를 BigQuery / Cloud Storage / Pub/Sub로 Export
- 조직·폴더·프로젝트 단위로 라우팅 정책 구성 가능

3) CloudTrail Lake / Athena 분석과 대응: BigQuery + SCC + Policy

BigQuery Export → 쿼리 기반 분석
- Cloud Audit Logs → BigQuery Sink로 내보내기
- SQL로 자유롭게 감사 분석:
  - “지난 30일 동안 방화벽 변경 내역”
  - “특정 사용자 계정의 모든 활동 이력”
  - “특정 서비스 계정의 사용 패턴”
Security Command Center(SCC)
- GCP의 통합 보안 대시보드
- Config/취약점/권한/이상행위 등 종합 관리
- CloudAuditLogs, IAM 설정, 네트워크 설정 등과 연계하여 보안 이슈 형태로 보여줌
Organization Policy + IAM Analyzer
- “조직 차원의 정책”을 걸어서
  - 외부 공개 차단, 특정 Region 금지, 외부 서비스 계정 사용 제한 등
- IAM Analyzer를 통해 IAM Policy의 실질 권한, Public/External Access 여부 분석

AWS CloudTrail ↔ GCP Cloud Audit Logs 기능 매핑

관점	AWS	GCP
API 호출 감사	CloudTrail	Cloud Audit Logs (Admin/Data/System/Policy)
기본 이벤트 조회	CloudTrail Event History	Cloud Logging 뷰어(Audit 로그 필터)
관리 이벤트	Management Events	Admin Activity Logs
데이터 이벤트	Data Events	Data Access Logs
이상 행위 탐지	CloudTrail Insights	(직접 쿼리, SCC, Cloud Logging + Alerting 조합)
로그 저장	CloudTrail → S3/CloudWatch	Audit Logs → Cloud Logging → GCS/BigQuery
쿼리 분석	CloudTrail Lake / Athena	BigQuery Export
조직 단위 구성	Organization Trail	Org-level Log Sink / Org Policy / SCC
실시간 대응	EventBridge	Pub/Sub + Cloud Functions / Cloud Run + Alerting

300x250

이제부터는 “보안 관점에서 실제로 체크해야 할 항목” 위주로, AWS와 GCP를 동일 관점에서 정리해볼게요.

감사 로그 기본 설정 체크리스트

1) 로그 활성화 여부 (기본 vs 추가 설정)

AWS
- Management 이벤트는 기본 수집
- Organization Trail로 모든 계정 커버했는지 확인
- Data Events (S3 Object, Lambda Invoke 등) 중요 버킷/함수에 대해 활성화 여부 점검
GCP
- Admin Activity Logs는 항상 수집
- Data Access Logs가 민감 리소스에 대해 활성화 되어 있는지 확인
  - BigQuery(민감 데이터 테이블)
  - Cloud Storage(민감 버킷)
  - Secret Manager, KMS, IAM, Compute, GKE 등

내/외부 감사 대응용 체크리스트에
“CloudTrail / Audit Logs 설정 현황”을 표로 정리해두는 게 좋습니다.

로그 보관·위변조 방지·접근 통제

장기 보관 정책
- AWS: CloudTrail → S3 버킷
  - S3 버킷에 Lifecycle Policy (예: 1년 Standard, 이후 Glacier Deep Archive 5년)
- GCP: Cloud Audit Logs → Cloud Storage / BigQuery
  - GCS 버킷에 Retention Policy 설정 (예: 3년, 5년 등)
  - BigQuery Table에 Partition/Retention 정책 설정
위변조 방지
- AWS
  - S3 버킷에 Object Lock(Compliance Mode), Versioning, MFA Delete 설정
  - 별도 “로그 보관 전용 계정”을 만들고 Write only 권한만 부여하는 패턴도 있음
- GCP
  - Cloud Storage 버킷에 Retention Policy + 잠금(Lock) 적용
  - Audit용 프로젝트/버킷을 운영계와 분리하여, 삭제/수정 권한 최소화
로그 접근 권한
- “누가 감사 로그를 볼 수 있는지” 엄격 관리
- 운영자와 감사자 역할 분리
- AWS: CloudTrail 로그가 저장된 S3 버킷과 CloudWatch Logs에 대한 IAM 정책 최소화
- GCP: Logging Viewer / Private Logs Viewer / BigQuery Viewer 등 역할(Role) 최소 부여

실시간 모니터링 및 경보(Detection)

1) 공통적으로 꼭 감시해야 할 이벤트 유형

Root / 고권한 계정 사용
- AWS: Root 로그인, AssumeRole로 관리자 Role 획득
- GCP: roles/owner, roles/editor, Custom Admin Role로의 권한 부여 및 사용
IAM / 권한 변경
- AWS: CreateUser, AttachUserPolicy, PutRolePolicy, CreateAccessKey 등
- GCP: IAM Policy 변경 (SetIamPolicy 계열), Service Account Key 생성
네트워크·보안 설정 변경
- AWS: Security Group, NACL, Route Table, VPC Peering, CloudFront, WAF 설정 변경
- GCP: Firewall Rules 변경, VPC Peering, Cloud Armor 정책 변경, Load Balancer 구성 변경
로그·모니터링 설정 변경
- CloudTrail/Audit Logs 비활성화, S3/버킷·GCS 삭제, Log Sink 삭제/변경, Alert Policy 삭제 등
암호화/Secret 관련 행위
- KMS 키 생성/삭제/Rotation 변경, Secret Manager/Parameter Store 접근 등

2) AWS에서 구현 예시

CloudTrail → CloudWatch Logs → Metric Filter → CloudWatch Alarm
예: Root 계정 사용 감지
- Metric Filter:
- { ($.userIdentity.type = "Root") && ($.eventName != "Describe*" ) }
- Alarm 연계 → SNS → 이메일/Slack/티켓 시스템
CloudTrail → EventBridge → Lambda
- 특정 API 호출 발생시 자동 대응 (예: 특정 리전에 VM 생성되면 자동 종료)

3) GCP에서 구현 예시

Cloud Audit Logs → Cloud Logging → Log-based Metrics → Alerting
- 예: IAM Policy 변경 감지
- resource.type="project" protoPayload.serviceName="iam.googleapis.com" protoPayload.methodName="SetIamPolicy"
- 이 필터로 Log-based Metric 생성 후 → Alert Policy로 Slack/Webhook 등 알림
Cloud Audit Logs → Pub/Sub → Cloud Functions / Cloud Run
- 특정 이벤트 발생 시 자동 Remediation
  - 예: Public Storage 버킷이 생성되면 즉시 Private으로 변경
  - 예: Owner 권한이 부여되면 보안팀에 Slack 알림 + 자동 롤백

정기 점검(Periodic Review) 프로세스

월간/분기별 리뷰 항목
- 지난 기간 동안의
  - Root / Owner 계정 사용 내역
  - IAM 정책 변경 내역
  - 네트워크·방화벽 정책 변경 내역
  - 로그/모니터링 설정 변경 내역
- AWS: Athena / CloudTrail Lake / 외부 SIEM Report
- GCP: BigQuery 쿼리 / SCC Findings Report
권한 정리(Role Right-Sizing)
- Audit Logs 기반으로 실제 사용하지 않는 권한 제거
- 예: 6개월간 사용되지 않은 고권한 Role/Service Account 파악 후 축소/삭제
자동화된 Compliance Check
- AWS Config, Security Hub
- GCP SCC + Config Validator/Policy Controller
- “CloudTrail/Audit Logs 설정 여부”도 정책으로 관리 가능

내부 사용자(운영팀/개발팀)에게 줄 수 있는 “실무 가이드” 예시

계정 사용 수칙
- Root/Owner 계정은 비상용 + MFA 필수 + 일상적 사용 금지
- 개인 계정 + Role Assume / Workload Identity Federation 사용 권장
변경 작업 시 원칙
- 변경 작업 전후로 Change Ticket 번호와 연동
- 긴급 변경도 나중에라도 Ticket로 정리 → CloudTrail/Audit Logs와 매핑
로그 삭제·비활성화 금지
- CloudTrail/Audit Logs 비활성화/변경은 보안 정책 위반으로 명시
- Log Sink / Trail 설정 변경은 보안팀 Change 승인 필수
포렌식 협조 절차
- 사고 시 “언제·어떤 리소스·어떤 계정이 연관된 것으로 보이는지”를 보안팀에 전달
- 보안팀은 CloudTrail/Audit Logs 기반으로 상세 조사

“정리 요약” – CloudTrail & GCP 대응 운영 전략

CloudTrail / Cloud Audit Logs는 클라우드 보안의 “CCTV + 출입기록”이다.
- 둘 다 누가, 언제, 무엇을, 어디서 했는지 기록해주는 핵심 컴포넌트.
AWS ↔ GCP 매핑
- CloudTrail ↔ Cloud Audit Logs
- CloudWatch Logs / EventBridge ↔ Cloud Logging / Pub/Sub / Alerting
- CloudTrail Lake / Athena ↔ BigQuery Export
- Security Hub / GuardDuty ↔ SCC, IAM Analyzer, Threat Detection 계열(추가 서비스)
보안팀 점검 포인트
- (1) 감사 로그 활성화 범위 (특히 Data Events / Data Access)
- (2) 장기 보관 + 위변조 방지 + 접근 통제
- (3) Root/Owner/관리자·IAM·네트워크·로그 설정 변경에 대한 실시간 알림
- (4) 월간/분기 감사 리포트 & 권한 다이어트
- (5) 내부 운영팀에 대한 명확한 가이드와 정책 문서화

728x90

그리드형(광고전용)

저작자표시 비영리 동일조건 (새창열림)

pages.kr 날으는물고기 <º)))><

AWS CloudTrail vs GCP Audit Logs: 클라우드 보안 감사 모니터링 설계

AWS CloudTrail vs GCP Audit Logs: 클라우드 보안 감사 모니터링 설계

AWS CloudTrail 뭐하는 녀석인가

1) 개념 요약

2) CloudTrail이 기록하는 주요 정보

3) CloudTrail 로그 유형

4) CloudTrail 구성 요소

5) 보안·컴플라이언스 CloudTrail 역할

GCP에서 CloudTrail에 대응하는 서비스 구조

1) CloudTrail에 가장 직접 대응: Cloud Audit Logs

2) 로그 저장·검색·연동: Cloud Logging

3) CloudTrail Lake / Athena 분석과 대응: BigQuery + SCC + Policy

AWS CloudTrail ↔ GCP Cloud Audit Logs 기능 매핑

감사 로그 기본 설정 체크리스트

1) 로그 활성화 여부 (기본 vs 추가 설정)

로그 보관·위변조 방지·접근 통제

실시간 모니터링 및 경보(Detection)

1) 공통적으로 꼭 감시해야 할 이벤트 유형

2) AWS에서 구현 예시

3) GCP에서 구현 예시

정기 점검(Periodic Review) 프로세스

내부 사용자(운영팀/개발팀)에게 줄 수 있는 “실무 가이드” 예시

“정리 요약” – CloudTrail & GCP 대응 운영 전략

댓글

티스토리툴바

AWS CloudTrail vs GCP Audit Logs: 클라우드 보안 감사 모니터링 설계

AWS CloudTrail vs GCP Audit Logs: 클라우드 보안 감사 모니터링 설계

AWS CloudTrail 뭐하는 녀석인가

1) 개념 요약

2) CloudTrail이 기록하는 주요 정보

3) CloudTrail 로그 유형

4) CloudTrail 구성 요소

5) 보안·컴플라이언스 CloudTrail 역할

GCP에서 CloudTrail에 대응하는 서비스 구조

1) CloudTrail에 가장 직접 대응: Cloud Audit Logs

2) 로그 저장·검색·연동: Cloud Logging

3) CloudTrail Lake / Athena 분석과 대응: BigQuery + SCC + Policy

AWS CloudTrail ↔ GCP Cloud Audit Logs 기능 매핑

감사 로그 기본 설정 체크리스트

1) 로그 활성화 여부 (기본 vs 추가 설정)

로그 보관·위변조 방지·접근 통제

실시간 모니터링 및 경보(Detection)

1) 공통적으로 꼭 감시해야 할 이벤트 유형

2) AWS에서 구현 예시

3) GCP에서 구현 예시

정기 점검(Periodic Review) 프로세스

내부 사용자(운영팀/개발팀)에게 줄 수 있는 “실무 가이드” 예시

“정리 요약” – CloudTrail & GCP 대응 운영 전략

관련글

댓글

티스토리툴바