감사 로그: 무엇을 기록하고, 어떻게 온전하게 유지하며, 누가 읽을 수 있는가

무엇인가

(인용한) OWASP Logging Cheat Sheet는 각 항목이 언제, 어디서, 누가, 무엇을 했는지를 기록해야 한다고 요구합니다: 이벤트 시각과 로그 시각, 애플리케이션과 호스트, 행위를 한 사용자나 머신의 신원과 발신 주소, 이벤트 유형, 영향을 받은 객체, 결과와 사유입니다. 항상 기록해야 할 이벤트 목록에는 인증 성공과 실패, 인가 실패, 사용자 관리 작업, 관리자 권한 사용, 민감 데이터 접근, 키 사용과 교체, 설정 변경이 포함됩니다. 감사 로그는 이 가운데 어떤 주체(principal)를 대신해 취해진 행동을 기록하는 부분집합이며, 문제 해결용 출력이 아니라 하나의 기록으로 보관됩니다.

왜 중요한가

감사 로그는 중요한 행동에 대해 빠짐없이 남아 있고, 그 행동의 당사자가 조용히 고쳐 쓸 수 없을 때에만 가치가 있습니다. 이 치트시트가 직접 나열하는 로그 공격 목록에는, 공격자가 흔적을 지우려고 기록 자체를 막거나 로그를 훼손하는 경우와, 책임자를 숨기기 위해 엉뚱한 신원이 기록되게 만드는 경우가 포함되어 있습니다.

적용 방법

• 주체(principal)와 객체가 무엇인지 알 수 있는 애플리케이션 계층에서 감사 이벤트를 내보냅니다. 안정된 스키마를 가진 구조화된 레코드로 만듭니다: 행위자, 행위자 유형, 동작, 객체 유형과 id, 결과, 사유, 요청 id, UTC 기준 타임스탬프.
• 행위자는 표시 이름이 아니라 식별자로 기록하고, 위임 대행("관리자 X가 사용자 Y로서 행동")도 명시적으로 남깁니다.
• 세션 식별자, 접근 토큰, 비밀번호, 키, 전체 개인정보는 기록하지 않습니다. 치트시트는 이런 데이터를 제외하거나 마스킹해야 할 대상으로 명시합니다.
• 항목은 애플리케이션이 변경할 수 없는 저장소로 즉시 전송합니다: write-only 데이터베이스 역할 아래의 추가 전용(append-only) 테이블, 또는 보존 잠금이 걸린 객체 스토리지. (인용한) Amazon S3 Object Lock은 write-once-read-many 모델을 제공하며, 컴플라이언스 모드에서는 보존 기간 동안 어떤 사용자도 덮어쓰거나 삭제할 수 없다고 설명합니다.
• 해시 체인이나 주기적인 서명된 다이제스트 같은 변조 증거 메커니즘을 추가하고, 일정에 따라 검증합니다.
• 읽기 권한은 지정된 그룹으로 제한하고, 모든 읽기를 기록하며, 치트시트가 요구하듯 권한 목록을 주기적으로 검토합니다.
• 보존 기간을 미리 정하고 일정에 따라 삭제합니다. 목적이 끝난 감사 데이터를 계속 갖고 있는 것 자체가 위험 요인입니다.

함정

감사 기록을 일주일 만에 로테이션되는 애플리케이션 로그에 섞어 넣는 것. 의도("삭제 요청됨")만 기록하고 결과는 기록하지 않는 것. 조회할 수 없는 자유 형식 텍스트 메시지. 이벤트에 담긴, 클라이언트가 보내온 사용자 id를 그대로 신뢰하는 것. 사고가 나기 전까지는 아무도 읽지 않는 불변 로그.