컴플라이언스는 문서가 아니라 증적이다
규제 대응을 정책 문서 작성으로 끝내려는 조직이 많다. 그러나 감사가 실제로 묻는 것은 "규정을 만들었느냐"가 아니라 "그 규정대로 했다는 것을 증명할 수 있느냐"다. 사고가 났을 때, 또는 정기 점검이 들어왔을 때 제출해야 하는 것은 잘 쓴 보고서가 아니라 그 시점의 로그와 처리 이력이다.
여기서 보안 운영과 컴플라이언스가 만난다. 평소에 로그를 제대로 수집·보존하고, 위협을 탐지해 대응한 이력을 남겨 두면, 그것이 그대로 감사 증적이 된다. 반대로 평소에 안 하던 일을 감사 직전에 만들어 낼 수는 없다. 컴플라이언스는 이벤트가 아니라 운영의 부산물이어야 한다.
우리는 어떤 규제를 받는가 — 규제 지형
산업마다 받는 규제는 다르지만, 로그 관점에서 요구하는 바는 의외로 비슷하다. 먼저 대표적인 규제와 그 성격을 정리한다.
| 대상 | 주요 규제 | 로그 관점의 핵심 요구 |
|---|---|---|
| 공공·지자체 | ISMS-P, 공공 감사 | 주요 시스템 로그 보존, 접근·처리 이력 증적 |
| 금융·보험 | 전자금융감독규정, 금융보안원 기준 | 이상거래 탐지·대응 이력, 보존·무결성 |
| 의료기관 | 개인정보보호법, 의료법(이중 규제) | 의료정보 접근 기록, 비인가 접근 탐지·기록 |
| 교육·연구 | 개인정보보호법, 기관 지침 | 대규모망 로그 관리, 개인정보 접근 통제 |
세부 조항은 제각각이지만, 공통적으로 요구하는 것은 결국 세 가지로 수렴한다. 충분히 오래 보존하라(보존), 위·변조되지 않았음을 보장하라(무결성), 누가 무엇을 했는지 추적 가능하게 하라(추적성). 이 세 가지가 컴플라이언스 로그 운영의 기둥이다.
규제 요구 → LogCenter 기능 매핑
추상적인 요구를 실제 기능에 연결하지 못하면 컴플라이언스는 공허해진다. 핵심 요구를 LogCenter 기능에 직접 매핑하면 다음과 같다.
| 규제 요구 | 대응하는 LogCenter 기능 |
|---|---|
| 로그를 일정 기간 이상 보존 | 로그 저장 설정 — 호스트별 보존 기간(로그 파일/인덱스 파일 분리) |
| 원본 로그의 위·변조 방지 | 백업 시 암호화 키 설정, 무결성 검사, 파일 무결성 모니터링(FIM) |
| 접근·처리 이력의 추적성 | 티켓 — 생성·상태 변경·소명·종료 전체 히스토리 기록 |
| 위협 탐지·대응 수행 증명 | 탐지 결과·종합 탐지 현황, CTI 매칭 이력, MITRE 매핑 |
| 정기·수시 보고서 제출 | 맞춤 보고서 — 자동 생성·예약 전송, PDF/Word/Excel/PPT |
이제 기둥 세 가지(보존·무결성·추적성)와 보고서를 차례로 들여다본다.
보존과 무결성 — 증적의 토대
감사에서 가장 먼저 확인하는 것이 보존이다. ISMS-P는 주요 시스템 로그를 최소 6개월 이상 보존하도록 요구한다. LogCenter는 보존 기간을 호스트별로, 그리고 로그 파일과 인덱스 파일을 나눠 설정한다. 검색·분석에 쓰는 인덱스는 비용에 맞춰 짧게, 규제 대상 원본은 요구 기간만큼 길게 가져가는 분리 운영이 현실적이다.
보존만으로는 부족하다. "그 로그가 위·변조되지 않았다"는 보장이 있어야 법적 증거로 쓸 수 있다. LogCenter는 백업 시 암호화 키를 설정해 원본의 변조를 방지하고, 무결성 검사로 이를 검증한다.
무결성 검증에 실패한 항목은 파일 무결성 모니터링(FIM) 화면에서 따로 모아 볼 수 있다. 무결성이 깨진 로그가 있다는 것 자체가 중요한 신호이므로, 정기적으로 점검하는 것이 좋다.
추적성 — 티켓이 곧 감사 응답이다
감사관이 "이 탐지에 어떻게 대응했는가"라고 물으면, 답은 말이 아니라 이력이어야 한다. LogCenter의 티켓은 생성부터 종료까지 전 과정 — 상태 변경, 소명 요청과 답변, 종료 사유 — 을 히스토리로 남긴다. 이것이 "누가, 언제, 어떻게 처리했는가"에 대한 가장 강력한 증적이다.
특히 소명 요청 기능은 내부 감사 프로세스와 잘 맞는다. 비업무 시간 접근이나 대량 다운로드처럼 본인 확인이 필요한 탐지에 대해, 인사 정보에 등록된 이메일로 소명을 요청하고 그 답변까지 티켓에 기록한다. 티켓의 IoC·MITRE ATT&CK·원본 로그 탭은 복사·Excel 내보내기가 되므로, 그대로 사고 대응 보고서의 근거가 된다.
보고서 자동화 — 감사 산출물을 즉시
보존·무결성·추적성이 갖춰져 있어도, 그것을 감사가 요구하는 형식으로 빠르게 뽑아내지 못하면 현장에서 고생한다. 맞춤 보고서는 종합 탐지 현황·티켓·리소스 데이터를 위젯으로 끌어와 정형화된 문서로 출력한다.
실무 효과는 두 가지다. 첫째, 일·주·월 단위 정기 보고서를 자동 생성·발송하도록 걸어 두면 매번 수작업 집계가 사라진다. 둘째, ISMS-P·개인정보보호법 감사에서 요구하는 로그 수집·접근 이력 보고서를 즉시 제출 가능한 형태로 준비할 수 있다. 전송 형식은 PDF·Word·Excel·PowerPoint를 지원한다.
심층 사례 — 금융 현장점검 D-7, 3개월치 이력을 하루 만에
규제 대응이 평소 운영에 녹아 있을 때와 아닐 때의 차이는 점검이 닥쳤을 때 분명해진다. 한 사례로 따라가 본다.
| 단계 | 무슨 일이 있었나 | LogCenter에서 한 일 |
|---|---|---|
| ① 통보 | 금융 현장점검이 7일 뒤로 통보되고, 3개월치 접근·대응 이력 제출이 요구됐다 | 평소 보존 정책이 6개월로 설정돼 있어 대상 기간이 그대로 남아 있음 |
| ② 조회 | 대상 시스템의 원본 로그를 기간별로 확보해야 했다 | 원본 로그 정보에서 호스트/클러스터·기간을 선택해 즉시 조회·다운로드 |
| ③ 검증 | 제출 로그가 위·변조되지 않았음을 입증해야 했다 | 암호화 백업과 무결성 검사 결과로 무결성 보장 |
| ④ 집계 | 탐지된 이벤트에 어떻게 대응했는지 설명해야 했다 | 티켓 히스토리·소명·종료 기록을 Excel로 내보내 근거 확보 |
| ⑤ 제출 | 정해진 형식의 보고서를 기한 내 제출해야 했다 | 맞춤 보고서로 자동 생성, PDF·Excel로 즉시 제출 |
보안 담당자를 위한 활용 방안
컴플라이언스를 "감사철 행사"가 아니라 상시 운영으로 만드는 실무 방안을 정리한다.
| 활용 방안 | 실무 적용 |
|---|---|
| 보존 정책 전수 점검 | 호스트별 보존 기간 누락이 없는지 정기 점검. 인덱스는 짧게, 원본은 규제 기간만큼 분리 운영 |
| 무결성 검증 정례화 | 백업 암호화 키 설정과 무결성 검사를 정기 작업으로. 실패 항목은 FIM에서 즉시 확인 |
| 티켓을 감사 단위로 운영 | 탐지→대응을 반드시 티켓으로 남겨 "처리했다"가 아니라 "이렇게 처리했다"를 증명 |
| 정기 보고서 자동화 | 일·주·월 보고서를 예약 발송으로 걸어 두어 감사 산출물을 상시 확보 |
| 규제 매핑 문서화 | 각 규제 요구를 어떤 기능·설정으로 충족하는지 매핑표를 유지해 감사 응답을 표준화 |
운영 체크리스트
- 보존 기간이 규제를 만족하는가. 원본은 규제 요구 기간(예: ISMS-P 최소 6개월) 이상, 호스트 전수 설정.
- 무결성이 보장되는가. 백업 암호화 키 설정 + 무결성 검사 정례화 + FIM 정기 점검.
- 포맷이 등록돼 검색 가능한가. 원본만 쌓이고 파싱이 안 되면 감사 때 제출·검색이 불가능하다.
- 대응이 티켓으로 남는가. 탐지→대응 흐름이 히스토리·소명·종료까지 기록되는지 확인.
- 보고서가 자동화돼 있는가. 정기 보고서 예약 발송 + 감사용 즉시 출력 양식 준비.
- 규제 매핑표가 최신인가. 규제 개정 시 매핑표와 보존 기간을 함께 갱신.
컴플라이언스는 결국 신뢰의 문제다. "우리는 합리적인 보안 조치를 했고, 그것을 증명할 수 있다"고 말할 수 있느냐다. 그 증명은 감사 직전의 벼락치기가 아니라, 평소에 로그를 보존하고 무결하게 지키며 대응 이력을 남기는 운영에서 나온다. LogCenter의 보존·무결성·티켓·보고서를 한 줄기로 엮어 두면, 규제 대응은 부담이 아니라 평소 운영의 자연스러운 결과가 된다.