보안 기준: 감사 로그와 사고 대응

시스템에 어떤 기록이 남는지, 문제가 생겼을 때 어떤 순서로 대응하는지를 정리한 문서입니다. 전체 구성은 업무 시스템 보안 기준에 있습니다.

기록이 없으면 조사할 수 없습니다

보안에서 기록은 사고를 막는 장치가 아니라 사고 뒤에 무엇이 일어났는지 아는 수단입니다. 그리고 기록은 소급되지 않습니다. 남기지 않은 기간은 나중에 되살릴 수 없습니다.

그래서 감사 로그는 구축 초기에 넣습니다. 나중에 필요해지는 시점은 대부분 사고가 난 뒤이고, 그때는 이미 늦습니다.

무엇을 남기나

감사 로그는 다음 네 가지에 답할 수 있어야 합니다.

질문	남기는 것
누가	사용자 계정과 그때의 이름
언제	시각
무엇을	대상 자료와 동작(등록·수정·삭제·승인)
무엇에서 무엇으로	바뀐 항목의 이전 값과 새 값

마지막이 가장 자주 빠집니다. 「홍길동이 어제 거래처를 수정함」까지만 남으면, 무엇이 어떻게 바뀌었는지 알 수 없어 조사에 쓸 수 없습니다.

기록 대상은 업무에 영향이 큰 것부터 정합니다. 금액, 단가, 권한, 거래 조건, 삭제가 대표적입니다. 화면 정렬 순서 같은 것까지 남기면 양만 늘고 찾기 어려워집니다.

로그인 기록

자료 변경과 별개로 접속 기록도 남깁니다.

• 로그인 성공과 실패
• 접속 시각
• 비정상적으로 반복된 로그인 시도

퇴직자의 접근 여부를 확인하거나, 계정 공유 정황을 확인할 때 쓰입니다.

보관 기간

고객사가 정합니다. 길수록 조사에 유리하지만 보관 비용과 개인정보 측면을 함께 봐야 합니다. 로그에 이름이나 연락처가 담긴다면 개인정보 보관 기준과 맞추는 것이 좋습니다. 개인정보가 포함되는 프로젝트는 별도로 협의합니다.

사고가 났을 때의 순서

「대응」과 「책임」은 다릅니다. 원인이 어디에 있든 듀오랩스는 먼저 상황을 확인하고 복구를 돕습니다. 원인 분류는 그다음입니다.

1. 확인 — 어떤 자료에 어떤 영향이 있었는지 범위를 확인합니다
2. 차단 — 계속 진행 중인 접근이라면 먼저 끊습니다(계정 정지, 접근 차단)
3. 통지 — 고객사 담당자에게 알립니다. 법령상 신고 의무가 있는 경우 그 절차를 함께 확인합니다
4. 복구 — 필요하면 백업에서 복구합니다
5. 원인 정리 — 코드 문제인지, 계정 운영 문제인지, 플랫폼 문제인지 나눕니다
6. 재발 방지 — 같은 경로가 다시 열리지 않도록 조치하고 기록으로 남깁니다

원인 구분에 대해서는 보안 책임 분담 문서를 참고하시기 바랍니다.

고객사가 준비해 두면 좋은 것

준비	이유
연락 담당자와 연락 방법	사고는 업무 시간에만 확인되지 않습니다
내부 보고 경로	누구에게 먼저 알릴지 정해 두면 대응이 빨라집니다
계정 정지 권한자	즉시 차단해야 할 때 결정할 사람

자주 막히는 곳

상황	원인	대응
조사하려는데 기록이 없습니다	감사 로그를 나중에 넣기로 미뤘습니다	구축 시 포함합니다. 지난 기간은 복구할 수 없습니다
기록은 있는데 무엇이 바뀌었는지 모릅니다	동작만 남기고 값의 변화를 남기지 않았습니다	이전 값과 새 값을 함께 남기도록 보완합니다
로그가 너무 많아 찾기 어렵습니다	모든 동작을 남겼습니다	대상과 보관 기간을 정리합니다
사고 시 누구에게 알려야 할지 정해져 있지 않습니다	연락 체계가 없습니다	담당자와 보고 경로를 미리 정합니다