AWS CloudTrail
IT 위키
더 많은 작업
- AWS CloudTrail; CloudTrail; 클라우드트레일
- AWS 계정에서 사용자, 역할, AWS 서비스가 수행한 API 호출과 활동을 이벤트로 기록해 감사·보안 분석·규정 준수에 쓰게 하는 AWS 서비스
AWS CloudTrail은 "누가, 언제, 어디서, 어떤 리소스에, 무엇을 했는가"를 남긴다. 콘솔 클릭, AWS CLI, SDK, 다른 AWS 서비스의 호출이 모두 API 요청이므로 CloudTrail 이벤트가 된다. 보안 사고 조사, 변경 추적, 감사 증적에 기본으로 쓰인다. 리소스의 성능 상태는 아마존 CloudWatch, 리소스 구성이 규칙에 맞는지는 이 문서의 AWS Config 절이 다룬다.
| 방식 | 설명 | 비용 |
|---|---|---|
| 이벤트 기록(Event history) | 리전별로 최근 90일의 관리 이벤트를 조회·검색·다운로드할 수 있다. 계정을 만들면 바로 쓸 수 있고, 기록 자체는 변경할 수 없다 | 무료 |
| 추적(Trail) | 이벤트를 S3 버킷에 계속 전달해 장기 보관한다. CloudWatch Logs와 아마존 EventBridge로도 보낼 수 있다 | 관리 이벤트 사본 하나는 CloudTrail 요금 없음(S3 저장 요금 별도), 데이터 이벤트 등은 과금 |
| CloudTrail Lake | 이벤트를 ORC 형식의 이벤트 데이터 저장소에 모으고 SQL로 조회하는 관리형 데이터 레이크 | 수집·저장·쿼리 과금. 2026년 5월 31일부터 신규 고객에게 열려 있지 않다 |
90일보다 오래 보관하거나 Athena로 분석하려면 추적을 만들어 S3에 저장해야 한다.
| 유형 | 내용 | 기본 기록 |
|---|---|---|
| 관리 이벤트 | 리소스를 만들고 바꾸는 제어 영역 작업(보안 그룹 수정, 인스턴스 생성, IAM 정책 연결, 콘솔 로그인) | 예 |
| 데이터 이벤트 | 리소스 안에서 일어나는 데이터 영역 작업(S3 객체의 GetObject·PutObject·DeleteObject, Lambda Invoke 등). 양이 많다 | 아니요, 별도로 켜야 함 |
| 네트워크 활동 이벤트 | VPC 엔드포인트를 거친 API 호출 활동 | 아니요 |
| Insights 이벤트 | API 호출량이나 오류율이 평소와 다르게 급변한 것을 탐지 | 아니요 |
"S3 객체를 누가 내려받았는지"는 데이터 이벤트를 켜야 기록된다는 점이 자주 출제된다.
- 다중 리전 추적: 모든 리전의 이벤트를 하나의 S3 버킷에 모은다. 새 리전에서 일어난 활동도 빠지지 않게 하는 기본 권장 구성이다.
- 조직 추적: AWS Organizations의 관리 계정이나 위임된 관리자 계정에서 만들면 관리 계정과 모든 멤버 계정의 이벤트를 한 버킷에 모은다. 멤버 계정 사용자는 조직 추적을 볼 수는 있지만 삭제하거나 수정할 수 없다.
- 암호화: 로그 파일은 S3 서버 측 암호화로 저장되며, SSE-KMS로 지정한 KMS 키를 쓰게 할 수 있다.
- 보관 버킷 보호: 로그 버킷은 별도 보안 계정에 두고 버킷 정책, MFA 삭제, S3 객체 잠금 등으로 삭제를 막는 구성이 일반적이다.
로그 파일 무결성 검증을 켜면 CloudTrail이 전달하는 로그 파일마다 해시를 만들고, 1시간마다 그동안의 로그 파일 해시를 담은 다이제스트 파일을 같은 버킷의 별도 폴더에 전달한다. 해시는 SHA-256, 서명은 SHA-256 with RSA를 쓴다. 이를 통해 로그 파일이 전달 후 수정·삭제되었는지 확인할 수 있다. "감사 로그가 변조되지 않았음을 증명"하라는 요구의 답이다.
AWS Config는 AWS 리소스의 구성 상태와 그 변경 이력을 기록하고, 구성이 원하는 규칙에 맞는지 계속 평가하는 서비스다. CloudTrail이 "어떤 API 호출이 있었는가"를 기록한다면, Config는 "그 결과 리소스 구성이 어떻게 바뀌었고 지금 규정을 지키는가"를 기록한다.
| 기능 | 설명 |
|---|---|
| 구성 기록기 | 지원 리소스의 구성 항목(configuration item)과 리소스 간 관계를 기록한다. 구성 스냅샷과 이력은 S3 버킷에, 변경 알림은 SNS로 보낸다 |
| 구성 이력 조회 | 특정 시점에 보안 그룹 규칙이 어땠는지, 언제 바뀌었는지 시간순으로 본다 |
| 규칙(Config rules) | 바람직한 구성을 정의해 평가한다. AWS 관리형 규칙(예: S3 버킷 퍼블릭 읽기 금지, EBS 암호화 여부)과 Lambda나 Guard로 만드는 사용자 지정 규칙이 있다. 구성이 바뀔 때 또는 주기적으로 평가하며, 배포 전에 평가하는 사전 예방 평가도 지원한다 |
| 적합성 팩(conformance pack) | 여러 규칙과 수정 조치를 YAML 템플릿 하나로 묶어 계정·리전 또는 조직 전체에 배포 |
| 수정 조치(remediation) | 비준수 리소스를 Systems Manager Automation 문서로 고친다. 수동 실행이나 자동 실행을 선택 |
| 집계자(aggregator) | 여러 계정·리전의 Config 데이터를 한곳에서 조회 |
- 예: "퍼블릭 읽기가 허용된 S3 버킷을 찾아 자동으로 차단"은 관리형 규칙 + 자동 수정 조치로 구현한다.
- Config는 변경을 탐지하고 평가하는 서비스이지 변경을 사전에 막는 서비스는 아니다. 사전에 막으려면 SCP나 IAM 정책을 쓴다.
| 구분 | 아마존 CloudWatch | AWS CloudTrail | AWS Config |
|---|---|---|---|
| 답하는 질문 | 리소스와 애플리케이션이 지금 어떤 상태인가 | 누가 어떤 API를 언제 호출했는가 | 리소스 구성이 어떻게 바뀌었고 규칙을 지키는가 |
| 데이터 | 지표, 로그, 경보 | API 활동 이벤트 | 구성 항목, 구성 이력, 규정 준수 평가 결과 |
| 대표 동작 | 경보 → Auto Scaling·SNS | 감사 로그 보관, EventBridge로 특정 API 호출에 반응 | 비준수 탐지 → 자동 수정 |
| 시험 키워드 | 성능, 사용률, 임계값 | 감사, 추적, 누가 삭제했나 | 규정 준수, 구성 변경 이력, 드리프트 |
- "누가 리소스를 삭제·수정했는지 조사"는 CloudTrail이다. 90일이 넘은 기록이 필요하면 추적을 S3로 보내 두었어야 한다.
- "모든 계정·모든 리전의 API 활동을 중앙 버킷에 수집"은 조직 추적(다중 리전)이다.
- "로그가 변조되지 않았음을 검증"은 로그 파일 무결성 검증이다.
- "S3 객체 수준 접근 기록"은 데이터 이벤트를 켜야 한다.
- "리소스 구성이 사내 규정을 지키는지 지속 평가하고 위반 시 자동 수정"은 AWS Config 규칙 + 수정 조치, 여러 규칙 묶음 배포는 적합성 팩이다.
- "특정 API 호출이 일어나면 즉시 대응"은 CloudTrail 이벤트를 EventBridge 규칙으로 받아 Lambda나 SNS로 처리한다.
- AWS CloudTrail이란 무엇인가요? – AWS
- CloudTrail 개념 – AWS
- CloudTrail 로그 파일 무결성 검증 – AWS
- AWS Config란 무엇인가요? – AWS
- 적합성 팩 – AWS