seobangwool 님의 블로그

어떤 클라우드를 로그 분석 대상으로 삼을지 정해졌으니, 해당 클라우드 서비스를 통해 API 시퀀스를 처리하는 전체 아키텍처를 잡아두어야 했다.CloudTrail 로그를 수집하고 분석하는 기능 자체는 어렵지 않게 설명할 수 있지만, 실제로 프로젝트 구조를 잡는 과정에서는 여러 고민이 있었다. 로그를 어디까지 저장할 것인지, Lambda 내부에서 어떤 로직을 처리할 것인지, 단일 이벤트 중심으로 볼 것인지 API 호출 흐름 중심으로 볼 것인지, 탐지 결과를 어떤 방식으로 남길 것인지 등을 고민하게 되었다.이번 글에서는 현재 구상한 전체 아키텍처를 간단히 소개하고, 그 과정에서 고민했던 지점들을 중심으로 정리해보려고 한다.전체 아키텍처 소개현재까지 구상한 전체 아키텍처는 크게 세 단계로 나눌 수 있다.로그 수..

CloudTrail Guard에서 가장 먼저 결정해야 했던 것은 “어떤 클라우드를 로그 분석 대상으로 삼을 것인가”였다.처음부터 AWS만을 전제로 두지는 않았다. GCP의 Cloud Audit Logs는 시스템 이벤트를 깔끔하게 기록해주며, Azure의 Activity Log와 Entra ID 로그 역시 가시성 측면에서 매우 강력한 추적 기능을 제공합니다. 즉, 벤더사의 로깅 기능 자체만 놓고 보면 어느 것을 선택해도 보안 분석 관점에서 충분히 의미 있는 데이터를 얻을 수 있을 것 같았다. 이에 따라 기능의 유무보다는 다른 기준이 필요하다는 생각이 들었다. 따라서 데이터 확보와 연구 생태계의 성숙도를 중심으로 4가지 기준을 세워서 비교를 해보았다. 클라우드 로그를 선택할 때 고려한 기준데이터 전처리 용..

이 프로젝트를 시작하게 된 이유kisia에서 운영하는 클라우드 보안 수업을 수강하다가, 클라우드 서비스가 API 중심 아키텍처로 동작한다는 점에 관심을 갖게 되었다. 특히 AWS 환경에서는 사용자의 대부분의 행위가 API 호출 형태로 기록되므로, 이러한 API들을 하나의 흐름으로 분석할 수 있다면 비정상 접근이나 위험 행위 등을 탐지할 수 있지 않을까? 라는 궁금증이 생겼다.총 3인으로 진행하는 프로젝트이고, 현재 한 달간 진행이 되었다. 아직 프로젝트 초기이지만, 데이터 수집과 탐지 기준 설정 등 여러 시행착오를 겪고 있다. 지금까지 마주한 문제점과 기술 선정 이유와 같이 프로젝트 진행에 있었던 고민의 흔적을 남겨두면 추후 보완할 때 도움이 될 것 같아서 작성하게 되었다. 간단하게 프로젝트에 대해 설명..