Day 4 - 로그 무결성·보존·중앙화: S3 Object Lock, 교차 계정 로그 집계, KMS 암호화 로그

지금까지 무엇을 로깅하는지(CloudTrail, Config, Flow Logs, Resolver)를 배웠다. 오늘은 그 로그를 어떻게 신뢰할 수 있게 보관하는가를 다룬다. 감사 로그의 가치는 세 가지 속성에 달려 있다: 무결성(변조되지 않음), 가용성·보존(필요할 때 존재함), 기밀성(허가된 자만 봄). 공격자와 내부자 모두 로그를 노린다 — 흔적을 지우기 위해. 그래서 "로그를 만든 사람조차 지울 수 없게" 만드는 것이 보안 로깅의 정점이다.

위협 모델: 왜 로그를 따로, 강하게 보호하는가

로그 보관 설계는 명확한 위협 모델에서 출발한다:

1. 공격자가 운영 계정 권한을 탈취 → 로그를 삭제·변조해 침해 흔적 제거.
2. 악의적 내부자 → 자신의 부정 활동 로그를 수정.
3. 실수·랜섬웨어 → 로그 우발적 삭제·암호화.

대응 원칙은 세 가지다: ① 로그를 별도 계정(로깅 전용 계정)으로 보내 운영 계정 침해와 격리, ② Object Lock으로 누구도(루트조차) 보존 기간 내 삭제·변조 불가, ③ KMS 암호화로 기밀성과 키 기반 접근 통제.

📚 사례: 랜섬웨어 사고 대응 보고에서 가장 자주 반복되는 문장은 "백업은 있었지만 백업도 함께 암호화·삭제되었다"이다. 그리고 두 번째로 자주 반복되는 문장이 "정확히 언제 침입했는지 알 수 없었다"이다