읽을 수 있는 로그 설계

사고가 난 뒤 쓸 수 있는 로그를 만들기 위해 시각, 사용자, 행위, 결과와 보존 정책을 어떻게 설계해야 하는지 설명합니다.

기록은 있는데 질문에 답하지 못합니다

접속 로그 파일은 남아 있지만 사용자 값이 비어 있고 시각의 기준도 적혀 있지 않습니다. 저는 이런 상태를 로그가 있다고 표현하기 어렵다고 봅니다. 용량을 소비하며 저장된 문자열과 조사에 쓸 수 있는 기록은 다릅니다.

로그는 나중에 물을 질문에서 거꾸로 설계해야 합니다. 누가, 언제, 어디서, 무엇을 시도했고, 허용되었는지 실패했는지를 구분할 수 있어야 합니다. 관리자 권한 변경, 대량 조회, 파일 다운로드처럼 위험이 큰 행위는 대상과 결과까지 남기는 편이 좋습니다.

저장 기간을 무작정 늘리면 비용과 개인정보 위험이 함께 커집니다. 반대로 시스템 기본값만 따르면 사고를 인지했을 때 필요한 구간이 이미 지워질 수 있습니다. 저는 위협 시나리오, 탐지 주기, 법적 보존 요구, 저장 비용을 함께 놓고 기간을 정합니다.

원본 시스템과 중앙 수집 구간의 손실도 확인합니다. 네트워크 단절이나 수집기 장애가 발생했을 때 누락을 알리는 장치가 없으면 조용한 공백이 생깁니다. 로그 수집 성공 여부 자체도 감시 대상입니다.

여러 시스템의 기록을 맞추려면 시계 동기화와 일관된 사용자 식별값이 필요합니다. 직원 이름만 남기면 동명이인과 계정 변경을 구분하기 어렵습니다. 계정 식별자, 기기 식별자, 세션 식별자를 함께 남기면 한 행위의 흐름을 연결하기 쉬워집니다.

중요 로그는 변경이나 삭제 권한을 제한하고, 접근 자체를 기록합니다. 사고 당사자가 운영 권한을 가진 상황까지 생각해야 합니다. 평소에는 잘 보이지 않는 설계 차이가 조사 가능 범위를 정합니다.