한 달에 한 번이던 보안 점검을, 매일 자동으로

4개 클라우드에 걸친 수많은 프로젝트를 운영했지만, 클라우드 안의 계정과 보안 리소스를 직접 다루는 보안팀은 없었습니다. 보안팀의 역할은 CSPM을 운영해 결과를 전달하는 데까지였습니다.

보안 점검은 월말에 한 번, 각 클라우드 콘솔과 로그를 모아 며칠씩 수동으로 확인했습니다.

한 달에 한 번 점검하면, 누군가 자신에게 과도한 권한을 주거나, Access Key(만료되지 않는 장기 접속 키)를 발급하거나, 주요 서버를 지워도 최대 한 달 가까이 모를 수 있었습니다.

보안 사고에서 가장 중요한 것은 이상 행위를 얼마나 빨리 알아차리느냐인데, 당시 구조는 사고가 지나간 뒤에야 확인하는 방식이었습니다.

누가 시킨 일은 아니었지만, 이 공백을 그대로 두면 안 된다고 생각해 직접 바꾸기로 했습니다.

어려웠던 점은 같은 “권한 변경”이라도 클라우드마다 기록 방식이 모두 달랐다는 것입니다. 그래서 하나의 공통 기준으로 바꾸는 것부터 시작했습니다.

1. 수집: 각 클라우드의 공식 SDK(프로그램에서 클라우드를 다루는 도구)로 4개 클라우드의 모든 프로젝트에서 감사 로그와 리소스 현황을 가져왔습니다.
2. 정규화: 제각각인 로그를 “누가, 언제, 어떤 리소스에, 무엇을 했나”라는 공통 기준으로 바꿨습니다.
3. 점검 항목: IAM(권한 관리) 권한 변경, 권한 사용 이력, 보안그룹·방화벽 규칙의 생성·삭제·변경 이력, 서버 등 주요 리소스의 생성·삭제·변경 이력.

정규화 예시(설명용 가상 데이터)

4. 크리티컬 행위 정의: 모든 변경을 알림으로 보내면 결국 아무도 보지 않게 되므로, 사고로 이어질 수 있는 행위만 골랐습니다. 특정 권한을 본인이나 타인에게 부여하려는 행위, Access Key 발급 시도, 주요 서버·DB의 중지·삭제·변경 시도입니다.
5. 실행 주기: 매일 새벽 1회 자동 실행하고, 결과는 구글 시트에 기록합니다.
6. 알림과 대응 흐름: 크리티컬 행위가 확인되면 텔레그램·슬랙으로 알림 → 행위자에게 의도 확인 → 주의·시정 요청 → 조치 완료로 기록합니다.

클라우드별 크리티컬 이벤트 예시(각 클라우드 감사 로그에 실제로 남는 이벤트 이름의 예)

알림 메시지 예시(가상)

🔴 [CRITICAL] Access Key 발급 시도
클라우드: AWS / 프로젝트: game-a-prod
행위자: user-a / 대상: user-a
시각: 2025-03-12 02:14 (KST)
→ 행위자 확인 후 시트에 조치 상태를 기록해 주세요.

보안은 사고가 난 뒤 분석하는 것보다, 사고로 이어질 수 있는 신호를 먼저 정의하고 놓치지 않는 구조를 만드는 것이 더 중요합니다.

권한이 없을 때는 “이렇게 하자”는 제안보다 “이렇게 해봤더니 좋아졌다”는 결과가 가장 강한 설득입니다.