로그, JSON, HAR 공유 전에 PII를 마스킹하는 방법

로그, JSON, HAR를 공유하기 전에는 작업용 사본을 만들고, 상대에게 필요 없는 필드를 제거한 뒤, 필요한 식별자는 일관된 대체 토큰으로 바꾸고 수신자 관점에서 결과를 다시 읽으세요. 파일에 실제 인증 정보가 들어 있었다면 사본을 마스킹하는 것만으로 대응이 끝나지 않습니다. 노출된 인증 정보를 즉시 폐기한 다음 새 값으로 교체하고, 가능한 범위에서 노출 사본을 지우며, 보안 또는 서비스 책임자에게 알리고 최초 노출 시점 이후의 접근 기록을 확인해야 합니다.

신뢰 경계 밖으로 보내면 안 되는 값

OWASP는 세션 식별자, access token, 비밀번호, 연결 문자열, 암호화 키, 민감한 개인정보, 결제 정보를 로그에 직접 남기지 말고 제거·마스킹·정제·해시·암호화하는 방식을 권고합니다. 파일 경로, 내부 네트워크 이름과 주소, 이름, 전화번호, 이메일 주소도 별도 처리가 필요할 수 있습니다.

지원 티켓, AI 프롬프트, 채팅, 외부 업로드를 준비할 때는 다음 항목을 확인하세요.

• Authorization, API 키, 커스텀 인증 헤더
• 쿠키, 세션 ID, 리프레시 토큰, 서명된 URL, 비밀번호 재설정 링크
• 계정·건강·상담·결제 정보가 담긴 요청·응답 본문
• 이메일 주소, 전화번호, 이름, 우편 주소, 정부 발급 식별번호
• 사용자 ID, 토큰, 문서명이 들어간 쿼리 매개변수와 URL 경로
• 내부 호스트명, 사설 IP 주소, 파일 시스템 경로, 데이터베이스명, 환경 정보가 드러나는 스택 트레이스

반대로 타임스탬프, 상태 코드, 요청 ID, 오류 이름을 무조건 모두 지우지는 마세요. 이런 값은 요청을 연결해 보는 데 꼭 필요할 수 있습니다. 진단에 필요한 정보만 남기고 나머지를 줄이는 것이 핵심입니다.

공유 전에 이 순서대로 처리하기

1. 질문과 수신자를 먼저 정합니다. 예를 들어 “42번 요청이 왜 403을 반환했나?”처럼 상대가 확인해야 할 내용을 한 문장으로 적습니다. 질문이 좁으면 관련 없는 본문, 사용자, 시간대를 버리기 쉽습니다.
2. 폐기 가능한 작업용 사본을 만듭니다. 접근이 제한된 원본은 승인된 위치에 보관하세요. 유일한 사고 증적을 직접 편집하지 말고, 정제하려는 원문을 또 다른 온라인 서비스에 먼저 붙여넣지도 마세요.
3. 캡처 범위부터 줄입니다. 로그는 필요한 시간대와 서비스만 남깁니다. HAR는 가능하다면 깨끗한 세션에서 필요한 탭과 요청만 열어 문제를 다시 재현합니다.
4. 더 안전한 HAR 내보내기를 고릅니다. Chrome DevTools는 Cookie, Set-Cookie, Authorization 같은 헤더를 제외한 정제된 HAR 내보내기를 제공합니다. 이를 출발점으로 쓰되, 쿼리 문자열, 본문, 커스텀 헤더, URL, 애플리케이션 데이터 속의 비밀값까지 모두 잡는다고 가정하면 안 됩니다.
5. 값을 마스킹하기 전에 불필요한 필드 전체를 지웁니다. 요청·응답 본문, 쿠키 블록, 스택 트레이스 구간이 진단에 필요 없다면 통째로 제거하세요. 남긴 필드가 적을수록 마스킹 규칙이 놓칠 패턴도 줄어듭니다.
6. 필요한 식별자는 일관되게 치환합니다. [USER_01], [EMAIL_01], [TOKEN_01], [INTERNAL_HOST_01] 같은 대체 토큰을 씁니다. 하나의 자료 안에서는 같은 값에 같은 토큰을 써서 요청 관계를 보존하되, 서로 무관한 사례끼리 매핑을 재사용하지는 마세요.
7. 구조와 변경 내용을 검증합니다. 수정한 JSON이나 HAR를 다시 구문 분석합니다. 비밀정보 이름, 이메일 형태, bearer 문자열, 쿠키, 사설 호스트, 조직 고유 식별자를 키와 값에서 모두 검색하세요. URL, 헤더, 본문을 나눠 읽고 신뢰할 수 있는 환경에서 원본과 정제본을 비교합니다.
8. 쓸모를 확인한 뒤 좁게 공유합니다. 처음 정한 질문에 필요한 요청 순서, 타임스탬프, 상태, 오류가 남았는지 봅니다. 승인된 접근 제어 채널에서 꼭 필요한 인원에게만 보내고 보관 기간도 가능한 한 짧게 잡습니다.
9. 작업 자료를 정리합니다. 정책이 허용하는 시점에 임시 원본 내보내기와 로컬 매핑 파일을 삭제합니다. 티켓이나 채팅에 첨부파일이 더 필요 없다면 보이지 않을 것이라 기대하지 말고 그곳에서도 제거합니다.

일관된 대체 토큰은 요청 간 연관성을 남기지만 데이터를 익명으로 만들지는 않습니다. 드문 타임스탬프, 주문 금액, 호스트명, 자유 입력 문장이 다른 정보와 결합되면 여전히 한 사람을 알아볼 수 있습니다. 눈에 잘 띄는 패턴뿐 아니라 맥락도 확인해야 합니다.

실제 값 없이 디버깅 맥락 남기기

원문:

2026-09-05T09:14:22Z request_id=req-7f2 user_email=alex@example.com
GET https://billing.internal/accounts/9481?invite_token=<live-token>
Authorization: Bearer <live-access-token>
response_status=403 error=scope_missing

공유용 사본:

2026-09-05T09:14:22Z request_id=req-7f2 user_email=[EMAIL_01]
GET https://[INTERNAL_HOST_01]/accounts/[ACCOUNT_01]?invite_token=[TOKEN_01]
Authorization: [REDACTED_CREDENTIAL_01]
response_status=403 error=scope_missing

두 번째 사본에는 시간, 요청 연결 정보, 경로 형태, 응답 상태, 오류가 남습니다. 사람, 계정, 내부 호스트, 초대 토큰, bearer 인증 정보의 실제 값은 드러나지 않습니다.

JSON은 주석을 끼워 넣거나 따옴표 일부를 지우지 말고 유효한 JSON 구조를 유지하세요. HAR도 뷰어가 읽는 객체 형태는 보존하되 필요 없는 항목과 민감한 필드를 제거합니다. 수동으로 고친 뒤에는 반드시 파일을 다시 불러오거나 구문 분석하세요. 문법이 깨진 자료는 안전하지도, 쓸모 있지도 않습니다.

인증 정보가 노출됐다면 사고 대응으로 전환하기

마스킹은 앞으로 읽는 사람에게 보이는 내용을 바꿀 뿐입니다. 티켓, 프롬프트, 이메일, 터미널 녹화, HAR에 이미 복사된 토큰을 무효화하지는 못합니다. 비밀값이 의도한 경계 밖에 들어간 순간부터 잠재적으로 침해된 것으로 다뤄야 합니다.

1. 먼저 폐기합니다. 발급 시스템에서 토큰, 세션, API 키, 인증서, 서명 링크를 최대한 빨리 비활성화하세요. OWASP의 비밀정보 지침도 노출된 키의 즉시 폐기를 요구합니다.
2. 그다음 교체합니다. 새 값을 만들고 정상 사용처를 갱신합니다. 이전 인증 정보가 더는 동작하지 않는지 확인하세요. 기존 값을 무효화하지 않고 새 값만 발급해서는 충분하지 않습니다.
3. 사본을 차단합니다. 플랫폼이 허용하면 첨부파일이나 메시지를 지우고, 티켓·문서의 접근 범위를 제한하며, 임시 내보내기를 삭제합니다. 백업이나 이미 만들어진 복사본까지 사라진다는 보장은 없으므로 삭제를 폐기 대신 사용하면 안 됩니다.
4. 알리고 조사합니다. 서비스 책임자나 보안 대응 경로에 연락합니다. 노출 가능 시점과 위치를 기록하고 비밀정보 관리 시스템, 인증 시스템, 애플리케이션, 공급자 접근 로그에서 예상 밖 사용을 확인합니다.
5. 발생 원인을 막습니다. 같은 인증 정보가 다시 기록되지 않도록 로깅 코드를 고치고, 문제가 된 필드의 테스트를 추가하며, 인접한 로그 경로도 점검합니다. 매번 내보내기 파일을 정제하는 것보다 처음부터 수집하지 않는 편이 안전합니다.

1차 출처

• OWASP Logging Cheat Sheet
• OWASP Secrets Management Cheat Sheet
• Chrome DevTools Network 참고 문서: HAR 내보내기