감사 이벤트에 꼭 남겨야 할 필드와 빼야 할 필드

감사 로그는 ‘누가 무엇을 언제 바꿨는가’를 설명해야 합니다. 그렇다고 요청 본문 전체를 남기면 비밀번호, 주민번호, 고객 파일 내용이 로그에 쌓일 수 있습니다. 추적에 필요한 메타데이터와 보호해야 할 값을 분리하는 스키마가 중요합니다.

감사 이벤트의 목적을 한정한다

보안 조사, 권한 변경 추적, 규제 대응 등 무엇을 증명해야 하는지 먼저 정합니다. 일반 디버그 로그와 감사 이벤트를 혼합하면 누락도 늘고 보관 정책도 불명확해집니다.

누가·무엇을·어떻게를 구조화한다

이벤트 ID, 발생 시각, 행위자 ID와 역할, 테넌트 ID, 대상 종류·ID, 행위, 결과, 요청 추적 ID를 기본 필드로 둡니다. 변경 전후는 전체 값 대신 안전한 필드명·상태 변화로 표현할 수 있습니다.

남기면 안 되는 값을 차단한다

비밀번호, 액세스 토큰, 세션 식별자, 결제 수단, 민감한 개인정보는 원문을 기록하지 않습니다. 필요한 식별자는 마스킹이나 별도 참조 키를 사용하고 자유 입력 필드가 로그에 섞이지 않도록 합니다.

수정 불가능성과 접근 권한을 설계한다

감사 로그를 관리자도 임의로 고칠 수 있으면 증거력이 약해집니다. 쓰기·조회 권한을 분리하고 삭제·보관 정책을 정하며 조회 자체도 추적합니다. 보관 기간은 적용 법규와 계약을 확인해야 합니다.

누락을 테스트한다

권한 변경, 데이터 내보내기, 실패한 로그인, 관리자 조작처럼 중요한 경로에 이벤트가 실제로 남는지 자동 테스트합니다. 로그가 과도하게 쌓이는지와 누락이 생기는지를 함께 봐야 합니다.

현장에 적용할 때의 순서

1. 감사 목적과 핵심 행위를 정의
2. 행위자·대상·결과·추적 ID를 구조화
3. 민감값 제외와 접근 권한을 자동 검증

주의할 실패: 요청 본문 전체를 감사 로그로 저장

관찰할 지표: 핵심 이벤트 누락률·민감값 유입 건수

적용 전 체크리스트

• 핵심 행위별 필수 필드를 스키마로 정의한다
• 비밀·민감값의 원문 기록을 테스트로 차단한다
• 감사 로그의 조회·보관·삭제 권한을 분리한다

참고 자료

OWASP Logging Cheat Sheet. 이벤트 기록과 민감정보 배제 원칙은 OWASP 공식 가이드를 참고했습니다. 법정 보관 기간은 업종·관할에 따라 별도 확인해야 합니다.

이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.

#감사로그 #AuditLog #보안 #이벤트스키마 #개인정보보호 #SaaS #추적성 #로그설계 #접근통제 #운영