로그 저장에서 한 걸음 더 나아가 누락·변경을 검증할 수 있는 감사 증거 체계를 설계합니다.
왜 이 문제가 생길까
관리자 조작을 모두 기록해도 같은 관리자가 로그를 수정하거나 일부 파일을 삭제할 수 있다면 증거력은 약합니다. '로그가 남는다'와 '남은 로그가 원본 그대로임을 검증할 수 있다'는 다른 문제입니다. 특히 사고 조사에서는 특정 기간의 로그가 통째로 빠졌는지도 알아야 합니다.
시스템은 무엇을 구분해야 할까
이벤트마다 순서 식별자, 발생·수집 시각, 행위자, 대상, 결과를 기록하고 일련의 로그를 해시 체인 또는 구간별 다이제스트로 묶습니다. 검증 기준점은 운영 로그와 다른 권한 경계에 보관하거나 서명합니다. 생성, 보관, 검증 역할을 분리해 단일 계정이 이벤트와 기준점을 동시에 바꾸지 못하게 합니다. 검증 실패 시 원본 보존, 영향 구간 식별, 조사 절차까지 연결합니다.
현장에서 적용하면
월요일 새벽의 관리자 권한 변경을 조사할 때 해당 레코드가 보이는지만 확인하지 않습니다. 직전·직후 이벤트의 연결과 해당 구간의 다이제스트를 다시 계산해 누락이나 수정 여부를 검증합니다. 검증 도구는 가능하면 별도 환경에서 실행하고, 결과 자체도 누가 언제 확인했는지 기록합니다.
도입할 때 놓치기 쉬운 점
해시를 같은 DB 행에 함께 저장하고 둘 다 수정할 수 있으면 변조 탐지 효과가 제한됩니다. 해시 체인은 기록의 무결성을 돕지만 입력 당시 사실이 진실이었다는 것까지 증명하지는 못합니다. 또한 개인정보가 들어간 로그의 접근·보존·삭제 정책도 별도로 지켜야 합니다.
시작 전 점검할 세 가지
- 로그와 검증 기준점의 권한 경계가 분리됐는가
- 누락된 구간까지 탐지할 순서·시각 정보가 있는가
- 정기적으로 실제 검증과 사고 대응 연습을 하는가
참고 자료: AWS CloudTrail의 로그 무결성 검증 설명
#감사로그 #로그무결성 #변조탐지 #해시체인 #보안감사 #접근통제 #사고조사 #클라우드보안 #운영보안 #증거보존
