사고가 의심돼 지난달 접속 이력을 찾았는데 장비에는 최근 며칠치만 남아 있다면, 지금 보이는 정상 상태만으로 과거의 안전을 설명하기 어렵다. 로그 보존은 저장 공간을 확보하는 일과 함께, 필요한 시점의 기록을 찾아 사건의 순서를 재구성할 수 있게 만드는 일이다.
로그는 사고 당시의 기록
로그에는 로그인, 권한 변경, 시스템 설정 변경, 파일 접근 같은 사건이 기록된다. 방화벽에서 통신을 확인해도 그 연결로 누가 어떤 업무를 했는지는 애플리케이션 기록을 함께 봐야 알 수 있다. 따라서 수집 대상은 장비 목록보다 ‘사고가 발생했을 때 확인할 질문’을 기준으로 정하는 편이 실용적이다.
예를 들어 관리자 계정 오용을 조사하려면 인증 성공·실패, 관리자 권한 부여, 실제 관리 작업을 이어서 확인할 수 있어야 한다. NIST SP 800-92 로그 관리 가이드는 로그 관리 인프라와 조직의 운영 절차를 함께 다룬다. 장비별 기록을 모았다는 사실과 조사에 사용할 관리 체계를 갖췄다는 사실은 구분해야 한다.
보존 기간은 검색 기간과 전체 보관 기간을 별개로 설정
최근 기록을 빠르게 검색하는 저장소와, 오래된 기록을 필요할 때 꺼내는 보관소는 역할이 다르다. 모든 기록을 같은 속도로 검색하려 하면 비용이 커질 수 있고, 압축 파일로만 보관하면 사고 대응 시 복원 시간이 길어질 수 있다. 보존 정책에는 기간과 함께 조회 가능한 상태로 만드는 데 걸리는 시간도 적어 둔다.
가상 설계 예시로 최근 30일은 즉시 검색하고, 그 이전 기록은 전체 보존 기간 180일에 포함해 별도 보관할 수 있다. 이때 전체 기간은 210일이 아니라 180일이다. 이 수치는 설명을 위한 예시이며 법정 기간이나 모든 기업에 적합한 권고값이 아니다. 실제 기간은 해당 기록에 적용되는 의무, 계약, 조사 필요성과 개인정보 처리 범위를 검토해 확정한다.
수집부터 보관까지 연결되는 기본 구성
기본 구성은 로그 발생 시스템, 중앙 수집기, 검색 저장소, 장기 보관소로 나눌 수 있다. 중앙 수집기는 기록을 받아 형식을 맞추고 저장 단계로 전달한다. 검색용으로 변환한 기록과 원본을 식별할 수 있게 연결해 두면, 화면에 표시된 필드가 원래 기록과 다른 경우 대조하기 쉽다.
전송이 끊겼을 때 원본 장비가 얼마나 임시 저장하는지, 재전송을 지원하는지, 중복 기록을 어떻게 식별하는지는 제품별로 확인해야 한다. 수집기 자체의 정상 상태만 보지 말고 각 발생지의 마지막 수신 시각과 평소 대비 수집량도 확인한다. 기록이 없는 상태가 정상적인 무활동인지 수집 장애인지 구별할 수 있어야 한다.
로그별 관리 기준 수립
다음 표는 관리대장의 출발점으로 사용할 수 있는 작성 예시다. 실제 대장에는 각 행마다 보존 근거, 즉시 검색 기간, 전체 보존 기간, 저장 위치, 복원 목표시간, 점검 담당자를 추가한다. 기간을 정하지 못한 항목은 임의로 채우지 말고 결정 책임자와 확정 기한을 기록한다.
| 대상 | 확인하려는 내용 | 핵심 기록 예시 | 담당 역할 예시 |
|---|---|---|---|
| 인증·VPN | 누가 언제 접속했는가 | 계정 식별자, 접속 시각, 결과, 접속지 | 계정·네트워크 운영 |
| 서버·관리 시스템 | 누가 권한과 설정을 바꿨는가 | 작업자, 대상, 변경 내용, 결과 | 서버·시스템 운영 |
| 업무 애플리케이션 | 어떤 업무 행위가 있었는가 | 행위자, 대상 식별자, 작업, 결과 | 업무 시스템 운영 |
| 로그 수집·보관 시스템 | 기록이 빠지거나 지워졌는가 | 수집 중단, 정책 변경, 조회·삭제 이력 | 플랫폼 운영·보안 검토 |
시간·무결성·민감정보를 함께 관리
서로 다른 시스템의 시간을 비교하려면 신뢰할 수 있는 시간원으로 동기화하고 시간대 정보를 일관되게 다뤄야 한다. 사건 발생 시각과 수집 시각도 구별한다. 지연 전송된 기록을 수집 시각만으로 정렬하면 실제 작업 순서를 잘못 해석할 수 있다. NIST SP 800-92 로그 관리 가이드는 시간 동기화와 저장·보관 운영을 함께 설명한다.
기록을 만든 계정이 보관 기록까지 자유롭게 삭제하지 못하도록 권한을 나누고, 보관 정책 변경과 로그 접근도 기록한다. 파일 해시를 비교하면 변경 여부 확인에 도움이 되지만, 기록과 기준 해시를 함께 바꿀 수 있다면 신뢰에 한계가 있다. 읽기 전용 보관이나 변경 방지 기능의 적용 범위도 함께 검토한다. 관련 보호 조치는 OWASP Logging Cheat Sheet의 로그 보호 항목에서도 확인할 수 있다.
보안을 위해 남기는 로그라도 비밀번호, 접근 토큰, 비밀키를 그대로 저장해서는 안 된다. OWASP Logging Cheat Sheet의 기록 제외 대상 안내는 이런 민감값의 직접 기록을 피하도록 설명한다. 전체 요청 본문을 무조건 수집하기보다 조사에 필요한 필드를 선별하고, 개인정보가 포함되는 필드는 필요성과 접근 범위를 별도로 검토한다.
파일 존재 확인을 넘어 복원·검색을 시험
가상 점검 절차로 한 달에 한 번 장기 보관 대상의 과거 하루를 선택하고, 승인된 환경에서 복원해 보는 방법을 사용할 수 있다. 다음은 이 글에서 제안하는 운영 예시이며 공식 표준이 정한 점검 주기는 아니다.
- 선택한 날짜의 대상 시스템과 보관 파일 목록을 확인한다.
- 복원을 시작하고 검색 가능한 상태가 될 때까지 걸린 시간을 기록한다.
- 계정·시간 범위·작업 종류로 표본 기록을 찾아 필수 필드가 유지됐는지 확인한다.
- 발생지 기록과 수집 기록을 비교할 수 있는 구간에서 누락·중복·시간 차이를 점검한다.
- 무결성 확인 결과와 오류를 남기고, 임시 복사본은 승인된 절차로 정리한다.
표본이 검색됐다는 사실만으로 전체 기록의 완전성이 입증되지는 않는다. 마지막 수신 시각, 기간별 수집량, 전송 오류와 함께 판단해야 한다. 복원에 실패했다면 ‘보관 완료’로 끝내지 말고 원인, 담당자, 재점검 일정을 남긴다.
실무 관점에서는 제품보다 'R&R'과 'RTO'를 수립
보안 담당자가 한 명인 조직이라면 모든 장비의 수집 설정, 저장 용량, 장애 복구까지 혼자 맡는 구조는 지속하기 어렵다. 이 글의 운영 제안은 시스템 운영자가 발생지와 전송 상태를 관리하고, 보관 플랫폼 운영자가 저장·복원을 맡으며, 보안 담당자가 필요한 기록과 점검 결과를 검토하도록 나누는 것이다. 실제 역할은 조직의 권한과 인력에 맞춰 정한다.
용량도 원본 발생량만 보고 계산하지 않는다. 가령 하루 원본이 10GB라면 180일분의 단순 합계는 1,800GB다. 이는 색인, 복제본, 압축률, 증가분을 반영하지 않은 계산이므로 구매 용량으로 바로 사용하면 안 된다. 일정 기간 실측한 뒤 검색 저장소와 보관소 각각의 사용량을 계산한다.
NIST의 2023년 로그 관리 계획 가이드 공개 초안은 생성·전송·저장·접근·폐기를 관리 범위로 설명한다. 이 관점에서 관리대장은 보관 기간 한 칸으로 끝나지 않는다. 누가 수집 장애를 처리하고, 누가 과거 기록을 복원하며, 언제 보관을 종료하는지까지 연결돼야 한다. 해당 자료는 최종 표준이 아닌 공개 초안이다.
다음 점검에서는 가장 오래된 기록을 요청
‘로그가 쌓이고 있다’는 보고를 받았다면 정책상 남아 있어야 하는 가장 오래된 날짜의 기록을 하나 요청해 보자. 정해진 시간 안에 찾아서 읽을 수 있는지, 필요한 필드가 남아 있는지, 변경 여부를 확인할 근거가 있는지가 판단 기준이다. 이 확인이 어렵다면 보존 기간을 늘리기 전에 수집·검색·복원 과정부터 보완하는 편이 효과적이다.