감사 로그는 남기되 민감정보는 줄이는 방법
감사 로그는 사고 조사에 필요하지만 요청 본문을 통째로 남기면 비밀번호나 고객 정보까지 장기 보관할 수 있습니다. 추적 가능성과 데이터 최소화를 함께 설계해야 합니다.
데이터 흐름의 경계를 확인한다
먼저 답해야 할 감사 질문을 정합니다. 누가 언제 어떤 대상에 무슨 변경을 했고 승인 근거가 무엇이었는지면 충분한 경우가 많습니다. 원본 파일 전체나 인증 토큰을 기본적으로 저장할 필요는 없습니다.
실패와 중복 처리를 정한다
로그 필드를 허용 목록으로 정의하고 민감정보는 기록 전에 제거합니다. 예외 메시지에 요청 본문이 포함될 수 있으므로 실패 경로도 점검합니다. 개인 식별이 필요하면 별도 참조 ID를 두고 원본 조회는 엄격한 권한으로 제한합니다.
작은 범위에서 재처리한다
로그 위변조를 막기 위해 쓰기·열람·삭제 권한을 분리합니다. 보존 기간이 끝나면 자동 삭제되는지 시험합니다. 규정상 오래 보존해야 한다면 접근 기록과 암호화 정책도 함께 설계해야 합니다.
지연과 불일치를 관측한다
필수 필드 누락률, 민감정보 검출 건수, 조사에 걸린 시간, 권한 없는 열람 시도를 봅니다. 로그가 많아도 필요한 사건을 찾기 어렵다면 설계가 좋은 것이 아닙니다. 표본 사건을 실제로 재구성해 유용성을 검증합니다.
복구 절차를 유지한다
감사 로그와 디버그 로그의 목적을 혼동하지 않습니다. 디버그 로그는 더 상세하지만 짧게 보관하고, 감사 로그는 최소한의 구조화된 사실을 안정적으로 남깁니다. 고객에게 보여 주는 활동 내역은 이해 가능한 문장으로 따로 표현합니다.
현장에 적용할 때의 순서
- 감사 질문에서 필수 필드 정의
- 민감정보를 기록 전에 제거
- 보존·열람·삭제 권한 분리
주의할 실패: 요청 본문을 모두 장기 저장
관찰할 지표: 민감정보 검출·필드 누락·조사 시간
적용 전 체크리스트
- 감사 질문에서 필수 필드 정의
- 민감정보를 기록 전에 제거
- 보존·열람·삭제 권한 분리
참고 자료
OWASP — Logging Cheat Sheet. 보안 로그에 남길 정보와 피할 민감정보는 OWASP 지침을 참고했습니다. 운영 지표와 보존 구분은 적용 제안입니다.
이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.
#감사로그 #데이터최소화 #보안로그 #개인정보 #추적성 #네이처프랙탈 #시스템설계 #서비스운영 #안정성 #데이터활용
이 주제를 실제 시스템으로 옮기려면 웹 서비스 개발 살펴보기
