서버 로그 개인정보 마스킹: 장애 기록을 안전하게 남기는 운영법

서버 로그에는 비밀번호, 인증 토큰, 주민등록번호, 결제정보를 원문으로 남기지 말아야 합니다. 이메일·전화번호처럼 장애 조사에 꼭 필요하지 않은 개인정보도 수집 단계에서 빼고, 필요한 식별자는 내부 사용자 ID나 되돌릴 수 없는 해시로 바꾸세요. 이미 쌓인 로그는 접근 권한, 보관 위치, 삭제 일정까지 함께 점검해야 합니다.

서버 로그가 두 번째 개인정보 저장소가 되는 순간

로그는 장애 원인을 찾고 보안 사고의 흐름을 재구성하는 데 필요합니다. NIST는 로그 관리를 생성, 전송, 저장, 접근, 폐기까지 이어지는 과정으로 설명합니다. 수집만 켜 두고 나머지를 정하지 않으면 관리가 끝난 것이 아닙니다.[4]

문제는 개발 중 편의를 위해 요청 본문 전체를 기록할 때 생깁니다. 상담 폼의 이름·전화번호·문의 내용, 로그인 요청의 인증 값, 결제 요청의 카드 관련 값이 한 줄에 섞일 수 있습니다. 운영 데이터베이스에서는 권한을 엄격히 나눴는데 로그 검색 도구에는 여러 사람이 접근하는 역전도 생깁니다.

개인정보의 안전성 확보조치 기준은 접속기록을 식별자, 접속일시, 접속지 정보, 처리한 정보주체 정보, 수행업무 등으로 정의합니다. 동시에 접속기록이 위·변조되거나 도난·분실되지 않도록 안전하게 보관하라고 정합니다.[1] 많이 기록하는 것보다, 조사에 필요한 항목을 정해 보호하는 쪽이 맞습니다.

남겨야 할 값과 빼야 할 값을 먼저 나눈다

OWASP는 로그에 언제, 어디서, 누가, 무엇을 했는지를 조사할 수 있는 정보를 담으라고 권합니다. 반면 세션 식별값, 접근 토큰, 비밀번호, 암호화 키, 결제정보, 민감한 개인정보는 원문 기록을 피하고 삭제·마스킹·해시·암호화하라고 안내합니다.[3]

내부 사용자 ID도 다른 시스템과 결합하면 사람을 알아볼 수 있습니다. 로그를 개인정보와 무관한 데이터라고 단정하지 말고, 누가 어떤 목적으로 조회하는지부터 적어 두는 편이 안전합니다.

마스킹과 해시는 목적이 다르다

마스킹은 일부만 가려 운영자가 형태를 확인하게 합니다. 예를 들어 이메일은 도메인만 남기고, 전화번호는 끝자리도 필요 없다면 전부 숨길 수 있습니다. 화면 문의를 찾을 때는 원문 전화번호 대신 별도의 요청 ID를 고객에게 안내하는 방식이 더 낫습니다.

해시는 같은 값이 반복됐는지 비교할 때 씁니다. 단순 해시는 짧고 예측 가능한 값에 약하므로, 시스템이 관리하는 비밀값을 섞은 키 기반 해시를 검토할 수 있습니다. 원문을 되찾아야 한다면 해시가 아니라 암호화가 필요하지만, 그때는 키 접근 권한과 교체 절차가 새 과제가 됩니다.

{
  "event": "login_failed",
  "occurredAt": "2026-09-18T09:12:00Z",
  "userRef": "usr_8f2…",
  "requestId": "req_b31…",
  "ipRange": "203.0.113.xxx",
  "reason": "invalid_credential"
}

위 예시는 구조를 설명하기 위한 가상 값입니다. 실제 필드와 마스킹 수준은 사고 조사 목적, 법적 근거, 서비스 위험도에 맞춰 정해야 합니다.

코드 한곳에서 걸러야 빠뜨리지 않는다

각 화면 개발자가 알아서 개인정보를 지우게 하면 새 기능이 추가될 때 빠지기 쉽습니다. 공통 로거에서 허용된 필드만 통과시키고, 금지 필드가 들어오면 기록 전에 제거하는 방식이 관리하기 쉽습니다.

1. 로그인, 상담, 결제, 관리자 화면에서 발생하는 로그 종류를 목록으로 만듭니다.
2. 각 로그가 해결해야 할 질문을 한 줄로 적습니다. 예: "누가 언제 주문 상태를 바꿨는가?"
3. 그 질문에 필요 없는 본문과 개인정보 필드를 삭제합니다.
4. 공통 로거에 허용 목록과 마스킹 규칙을 넣습니다.
5. 테스트용 비밀번호·토큰·전화번호를 보내 로그 검색에서 검출되지 않는지 확인합니다.
6. 새 화면을 배포할 때 로그 항목 검토를 코드 리뷰 체크리스트에 넣습니다.

OWASP도 애플리케이션 전반에서 호출하는 공통 로그 처리기를 두고, 외부 입력의 줄바꿈·구분 문자를 정리해 로그 주입을 막으라고 안내합니다. 로그 기능 자체도 코드 리뷰와 보안 테스트에 포함해야 합니다.[3]

저장된 로그의 접근과 삭제도 설계한다

개인정보보호위원회 안내서는 접속기록을 빠뜨리지 않는 것과 함께, 업무시간 외 열람·다운로드나 여러 접속지 사용처럼 이상 징후를 점검하는 사례를 제시합니다.[2] 로그를 모으기만 하고 아무도 확인하지 않으면 사고 탐지 자료로 쓰기 어렵습니다.

다음 항목은 월간 운영 점검표로 쓰기 좋습니다.

• 로그 저장소의 읽기 권한이 현 담당자에게만 있는지 확인합니다.
• 관리자 조회와 다운로드 자체도 별도 기록으로 남깁니다.
• 저장 중인 로그가 바뀌거나 삭제됐는지 알아낼 장치를 둡니다.
• 서비스별 보관 근거와 삭제 시점을 문서에 적습니다.
• 백업과 분석용 복사본도 같은 삭제 일정에 포함합니다.
• 로그 수집 실패와 저장 공간 부족을 알리는 경보를 시험합니다.

OWASP는 로그를 전송할 때 안전한 통신을 사용하고, 저장 후에는 무단 열람·수정·삭제를 막으며, 필요한 보관기간보다 오래 두지 말라고 권합니다.[3] NIST도 로그를 폐기까지 포함한 수명주기로 다룹니다.[4]

오늘 바로 할 수 있는 30분 점검

먼저 운영 로그 검색창에서 password, token, authorization, phone, email, resident, card 같은 필드명을 찾아보세요. 실제 비밀값을 검색어로 입력하지는 마세요. 의심 필드가 나오면 해당 이벤트의 생성 코드와 접근자를 확인합니다.

그다음 최근 로그인 실패, 상담 접수, 결제 오류, 관리자 다운로드 로그를 각각 한 건씩 살펴봅니다. 장애 원인을 찾는 데 필요한 정보와 과하게 남은 정보를 분리하고, 과한 값은 수집 지점에서 제거합니다. 이미 저장된 로그를 지워야 한다면 법적·계약상 보관 의무와 사고 조사 필요성을 먼저 확인해야 합니다.

로그 구조와 운영 권한을 함께 손봐야 한다면 웹사이트 제작·개선 범위에서 현재 수집 흐름과 관리자 화면을 한 번에 점검할 수 있습니다. 첫 목표는 로그를 없애는 것이 아니라, 문제를 재현할 만큼만 남기고 그 기록을 안전하게 관리하는 것입니다.