CloudTrail 멀티 계정 중앙 로깅
CloudTrail 기본 개념
이벤트 유형 | 내용 | 기본 기록 |
Management Events | API 호출, 콘솔 로그인, 리소스 생성/삭제 |  기본 제공 (90일, Trail 없이도) |
Data Events | S3 객체 수준(GetObject, PutObject), Lambda 실행 | 별도 활성화 필요 (추가 비용) |
Insights Events | 비정상적인 API 호출 패턴 탐지 | 별도 활성화 필요 |
Trail 없이는 90일만 보관
장기 감사 기록이 필요하면 반드시 Trail 생성 → S3 저장
Organization Trail — 멀티 계정 중앙 로깅
AWS CloudTrail을 사용해 관리 계정의 사용자가 조직의 모든 AWS 계정에 대한 이벤트를 로깅하는 Organization Trail을 생성할 수 있다. Organization Trail은 조직의 모든 멤버 계정에 자동으로 적용된다. 멤버 계정은 Organization Trail을 볼 수 있지만 수정하거나 삭제할 수 없다.
Management Account
│
▼ Organization Trail 생성
│ (자동으로 모든 멤버 계정에 복제)
├── Member Account A ─┐
├── Member Account B ─┼──→ 중앙 S3 버킷 (Log Archive Account)
├── Member Account C ─┘ └── AWSLogs/
└── Member Account D ├── 111111111111/ (Account A)
├── 222222222222/ (Account B)
└── 333333333333/ (Account C)
Plain Text
복사
멀티계정 중앙 로깅 Best Practice
별도의 AWS 계정을 Log Archive Account로 생성하는 것을 권장한다. AWS Organizations를 사용하는 경우 이 계정을 조직에 등록하고, 조직의 모든 AWS 계정 데이터를 로깅하는 Organization Trail 생성을 고려하는 것이 좋다. 이 계정에 대한 접근은 계정 및 감사 데이터에 접근해야 하는 신뢰할 수 있는 관리자만으로 제한한다.
중앙 로깅 아키텍처 3계층
1.
Log Archive Account (전용 계정)
•
S3 버킷 (모든 계정 로그 수집)
•
버킷 정책: CloudTrail write 허용, 멤버 계정 read 거부
2.
Security/Audit Account
•
CloudWatch Logs → 실시간 모니터링
•
Athena → 로그 쿼리 분석
•
Security Hub → 보안 이벤트 통합
3.
Management Account
•
Organization Trail 관리
•
S3 버킷 정책 및 KMS 키 관리
CloudTrail 로그 무결성 검증
•
Log File Integrity Validation 활성화 시 → SHA-256 해시 + RSA 서명으로 로그 변조 탐지
•
validate-logs CLI 명령으로 검증
누군가 로그를 삭제하거나 변조했는지 확인 → Log File Integrity Validation
특정 API 호출이 언제 발생했는지 추적 → CloudTrail Management Events
AWS RAM(Resource Access Manager)
AWS Resource Access Manager(RAM)는 AWS 리소스를 다른 AWS 계정이나 AWS Organizations 내에서 쉽고 안전하게 공유할 수 있게 해주는 서비스이다. Transit Gateway, Subnet, AWS License Manager 구성, Amazon Route 53 Resolver 규칙 등의 리소스를 RAM으로 공유할 수 있다. RAM을 활용하면 여러 계정에 중복 리소스를 생성할 필요없이 운영 오버헤드를 크게 줄일 수 있다.
RAM으로 공유 가능한 주요 리소스 (시험 단골)
리소스 | 대표 활용 사례 |
Transit Gateway | 네트워킹 계정에서 TGW 생성 → 모든 계정 공유 |
VPC Subenet | 중앙 VPC 서브넷을 다른 계정 리소스에 공유 |
Route 53 Resolver Rules | DNS 포워딩 규칙 공유 |
License Manager | 소프트웨어 라이선스 공유 |
Aurora DB Cluster | DB 클러스터 공유 |
Network Firewall Policy | 방화벽 정책 공유 |
TGW + RAM 조합 패턴 (시험 단골)
Transit Gateway는 AWS 계정 간에 동작하며, AWS RAM으로 다른 계정과 공유할 수 있다. TransitGateway를 공유한 후 다른 계정 소유자는 자신의 VPC를 해당 Transit Gateway에 연결할 수 있다.
[Networking Account] — TGW 소유
│
│ RAM으로 공유 (Organizations 전체 또는 특정 계정)
▼
[Account A] [Account B] [Account C]
│ │ │
└──────────────┴──────────────┘
각 계정이 자신의 VPC를 TGW에 attach
→ 중앙에서 라우팅 제어
Plain Text
복사
RAM 사용 3단계
1.
Resource Share 생성 (소유자 계정)
2.
리소스 추가 + Principal 지정 (계정 ID, OU ID, 또는 Organization ID)
3.
수신 계정에서 초대 수락 (Organizations 내부면 자동 수락 가능)
RAM의 핵심 가치 — 중복 리소스 제거
•
RAM 없을 때
◦
Account A: TGW 생성
◦
Account B: TGW 생성 ← 중복. 비용 2배, 관리 복잡
◦
Account C: TGW 생성 ← 중복
•
RAM 사용 시
◦
Networking Account: TGW 생성 1개
◦
Account A, B, C: RAM으로 공유받아 사용 ← 비용 절감, 중앙 관리
멀티 계정 환경에서 Transit Gateway를 중앙에서 관리하면서 여러 계정이 공유
→ RAM + TGW 조합
VPC Peering과 달리 TGW를 RAM으로 공유하면 Organization 외부 계정과도 공유 가능
Summary
개념 | 한 줄 요약 |
Organization Trail | 관리 계정에서 생성 → 전체 멤버 계정 자동 로깅 → 중앙 S3 |
RAM | 리소스 중복 생성 없이 멀티계정 공유 (TGW, 서브넷 등) |