CloudTrail Guard에서 가장 먼저 결정해야 했던 것은 “어떤 클라우드를 로그 분석 대상으로 삼을 것인가”였다.
처음부터 AWS만을 전제로 두지는 않았다. GCP의 Cloud Audit Logs는 시스템 이벤트를 깔끔하게 기록해주며, Azure의 Activity Log와 Entra ID 로그 역시 가시성 측면에서 매우 강력한 추적 기능을 제공합니다. 즉, 벤더사의 로깅 기능 자체만 놓고 보면 어느 것을 선택해도 보안 분석 관점에서 충분히 의미 있는 데이터를 얻을 수 있을 것 같았다.
이에 따라 기능의 유무보다는 다른 기준이 필요하다는 생각이 들었다.
따라서 데이터 확보와 연구 생태계의 성숙도를 중심으로 4가지 기준을 세워서 비교를 해보았다.
클라우드 로그를 선택할 때 고려한 기준
|
이러한 엔지니어링 관점의 기준들을 적용한 결과, 최종적으로 AWS CloudTrail를 선택하기로 했다.
1. 사실상의 표준이 된 로그 구조 (기준 1)
AWS의 모든 리소스 통제는 철저하게 API 기반으로 이루어진다. 콘솔 조작, CLI 명령, SDK 호출 등 모든 행위가 CloudTrail에 일관된 JSON 포맷으로 기록된다. 이는 "사용자 행위 → API 호출 → 로그 이벤트"로 이어지는 매핑을 직관적으로 만들어준다. 수많은 상용 SIEM 솔루션과 오픈소스 보안 도구들이 이 구조를 기본으로 다루고 있기 때문에, 수집된 로그를 파싱하고 기계학습 모델을 위한 데이터로 전처리하는 과정에서 참고할 수 있는 레퍼런스가 타 클라우드 대비 월등히 많다.
2. 압도적인 공격 시뮬레이션 및 위협 모델링 생태계 (기준2, 3)
AWS는 클라우드 시장 점유율이 가장 높기 때문에, 그만큼 보안 연구원들의 주요한 타겟이 되었다. 이는 방어자 입장에서 엄청난 이점이다. Pacu, CloudGoat, Stratus Red Team 등 AWS에 특화된 오픈소스 공격 시뮬레이션 도구들이 존재한다. 이를 활용하면 실제 침해 사고와 동일한 시나리오를 재현하고, 이 과정에서 발생하는 공격 데이터를 직접 수집할 수도 있게 된다. 그럼 우리가 설계한 모델의 신뢰성을 확실하게 검증할 수 있을 것이다.
3. 프로젝트 범위와 연구 목표에 가장 적합한 선택 (기준 4)
GCP와 Azure 역시 감사 로그와 보안 분석 기능을 제공하지만, 이번 프로젝트의 목표는 API 호출 시퀀스를 기반으로 이상 행위를 탐지하는 모델을 설계하는 것이다. 따라서 하나의 플랫폼에 집중하여 데이터 수집, 시퀀스 생성, 라벨링, 모델 학습, 성능 평가까지의 전 과정을 깊이 있게 수행하는 것이 더 중요하다고 판단하였다.
AWS는 CloudTrail을 중심으로 한 연구 사례, 공격 시나리오, 탐지 레퍼런스, 공개 자료가 가장 풍부한 환경 중 하나이다. 또한 IAM, S3, EC2 등 주요 서비스의 행위가 CloudTrail에 일관된 형태로 기록되기 때문에 공격 흐름을 시퀀스 단위로 분석하기 용이하다. 제한된 인원과 기간 내에서 탐지 모델과 전체 파이프라인을 완성도 있게 검증하기 위해서는, 가장 많은 참고 자료와 검증 수단을 제공하는 AWS가 현실적인 선택이라고 판단하였다.
마무리하며
결론적으로 AWS를 선택한 것은, 가진 리소스 안에서 가장 풍부한 공격 데이터를 확보할 수 있고, 가장 신뢰성 있는 위협 탐지 시나리오를 검증하기에 최적이라 판단했기 때문이다.
물론 GCP나 Azure 역시 충분히 훌륭한 로그 환경과 보안 분석 기능을 제공한다. 다만 이번 프로젝트의 목적은 API 호출을 시퀀스로 묶어서 탐지한다는 아이디어를 실제로 구현하고 검증하는 것이다. 따라서 가장 많은 레퍼런스와 연구 사례, 공격 시뮬레이션 환경을 제공하는 AWS로 진행하기로 결정하였다.
'Project Diary > Cloudtrail-guard' 카테고리의 다른 글
| [Cloudtrail-guard] 02. 전체 아키텍처를 구성하며 고민했던 점 (0) | 2026.06.09 |
|---|---|
| [Cloudtrail-guard] 00. 프로젝트를 시작하게 된 이유 (0) | 2026.06.09 |