티켓이나 채팅 기록을 밖으로 보내기 전에, 규칙 기반 마스킹이 가릴 수 있는 것과 가릴 수 없는 것

붙여넣는 순간, 사본은 하나가 아닙니다. 나중에 거둬들일 수 없는 여러 장입니다

많은 사람이 마스킹을 화면의 예절로 생각합니다. 번호를 별표로 바꾸면 메시지가 단정해 보입니다. 실제 문제는 붙여넣은 뒤에 생깁니다. 티켓 시스템은 본문을 저장합니다. 채팅 서비스는 메시지를 남깁니다. 오류 모니터는 스택을 긁습니다. 세션 리플레이는 입력란을 기록합니다. 외주 대기열은 또 한 파일을 내보냅니다. 내 화면에서 몇 글자를 고친다고, 이미 쓰인 사본은 바뀌지 않습니다. 나중에 「티켓을 정리」해도 고치는 것은 지금 이 행뿐입니다. 검색 기록, 메일 알림, 아래쪽 분석에는 원문이 남는 일이 많습니다.

OWASP 로깅 치트시트는 이를 문체 조언이 아니라 개발 제약으로 적습니다. 로그에 그대로 넣지 말고 삭제, 마스킹, 정제, 해시, 암호화를 해야 하는 항목을 나열합니다. 민감한 개인정보와 일부 식별자(건강정보, 정부 신분증), 인증 비밀번호, 액세스 토큰, 암호 키와 다른 마스터 비밀, 은행 계좌와 결제 카드 소지자 데이터입니다. 회사 안에서 티켓과 단체 채팅은 자주 「비공식 로그」가 됩니다. 검색은 쉽고, 권한은 운영 DB보다 느슨하며, 보관은 더 깁니다. 이용자 원문을 통째로 붙이는 것은, OWASP가 남기지 말라고 한 기록을 일부러 만드는 일입니다.

HTTPS가 지키는 것은 전송 구간의 도청입니다. 다음 시스템에 이미 넘긴 평문은 지우지 않습니다. 앞 글에서 같은 점을 주소창 쿼리로 썼습니다. 기록, Referer, 액세스 로그로 갑니다. 문장 안의 번호는 같은 종류의 노출입니다. 실리는 곳만 URL에서 문장으로 바뀝니다. 보내기 전에 물을 것은 「이 티켓 도구가 안전한가」가 아닙니다. 「이 문단에, 이 탭을 떠나면 안 되는 필드가 있는가」입니다.

규칙은 형태와 검사 자리를 봅니다. 이 문장이 무엇을 말하는지는 읽지 않습니다

규칙 마스킹의 일은 좁습니다. 정규식으로 후보를 찾고, 공개된 검사로 아닌 것 같은 적중을 버리고, 우선순위로 겹침을 가릅니다. 「김민수」가 이름인 줄 모르고, 「내일 강남역 2번 출구로 보내 주세요」가 주소인 줄도 모릅니다. 아는 것은 이것뿐입니다. 이 11자리가 중국 본토 휴대 형태인지, 이 18자리가 공민신분번호 검사를 통과하는지, 이 16자리가 카드에 쓰는 Luhn을 통과하는지.

「모델을 보내 티켓을 읽고 PII를 다시 쓰자」와는 길이 다릅니다. 밖으로 나가는 모델 검사는 원문을 다른 처리자에게 넘깁니다. 게이트웨이 쪽 마스킹도 텍스트를 식별 서비스로 보냅니다. 규칙 검사는 현재 탭에 남을 수 있습니다. 입력은 브라우저를 떠나지 않고, 결과는 마스킹된 사본입니다. 대가는 범위입니다. 명단 밖의 신분증, 스스로 만든 키 접두사, 공백으로 가른 숫자는 빠집니다.

검사 자리는 오탐을 줄입니다. 「이 사람이 존재한다」는 증명이 아닙니다. 중국 18자리 공민신분번호의 마지막 글자는 GB 11643-1999 / ISO 7064 MOD 11-2로 계산합니다. 앞 17자리에 가중치 7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2를 곱하고, 합을 11로 나눈 나머지를 표 10X98765432에 대응합니다. 나머지가 2이면 18번째가 X이고, 10을 뜻합니다. 통과는 「이 문자열이 형식이 맞다」일 뿐입니다. 호적에 그 사람이 있다는 뜻이 아닙니다. 카드는 ISO/IEC 7812의 Luhn을 씁니다. 오른쪽부터 한 자리 건너 2를 곱하고, 9를 넘으면 9를 빼고, 합이 10으로 나눠떨어져야 받습니다. 아무렇게나 친 16자리는 대개 Luhn을 못 넘습니다. 규칙이 그걸 카드로 보면 안 됩니다.

여섯 종류를 각각 무엇으로 보고, 가린 뒤 어떤 모양인가

안정적으로 지칭할 수 있는 필드는 「공개된 형식이 있고, 한 겹 더 검사할 수 있는」 것들입니다. 표는 밖으로 나가는 텍스트에 자주 나오는 순서입니다. 마스크 모양은 앞뒤 일부를 남기고 가운데를 별표로 바꾸는 스마트 마스킹을 전제로 합니다. 남은 숫자까지 지워야 하면 완전 마스킹으로 바꿉니다.

전화 규칙은 「이어진 11자리」와 「공백, 괄호, 하이픈이 있는」 표기를 같이 봐야 합니다. 중국 본토 휴대가 1[3-9]로 시작해 11자리인 것은 공개된 번호 형태이지, 어떤 통신사 내부표가 아닙니다. 국제번호는 E.164의 흔한 겉모습으로 잡습니다. +로 시작하고 뒤에 숫자 7–15자리. 너무 짧거나 더 긴 숫자열 한가운데에 끼면 버려야 합니다. 그렇지 않으면 주문번호와 송장번호도 전화가 됩니다.

한국 현장의 일상 표기는 이 중심에서 한 칸 바깥에 있습니다. 국내 휴대는 대개 010-1234-5678처럼 3-4-4입니다. 북미식 3-3-4와도, 중국 본토 11자리 1[3-9]와도 다릅니다. +8210…처럼 국가번호를 붙인 열은 국제 규칙에 걸릴 수 있습니다. 하이픈만 있는 국내형은 통과하는 일이 많습니다. 이는 고장으로 쓰기보다, 규칙 경계를 먼저 적어 두는 편이 맞습니다.

신분증 쪽은 중국 18자리에 더해, 미국 사회보장번호를 AAA-GG-SSSS로 썼을 때의 무효 구역(000, 666, 9로 시작, 그룹 00, 일련 0000)과 영국 국민보험번호(알파벳 2자 + 숫자 6자리 + 끝 A–D, BG / GB 등 접두사 제외)를 봅니다. 이 검사는 「신분증처럼 보인다」는 확신을 올립니다. 「이 사람이 존재한다」는 증명이 아닙니다. 한국 주민등록번호는 생년월일 6자리와 뒤 7자리, 하이픈을 합치면 13자리입니다. 18자리도 아니고, 하이픈 달린 SSN도 아니며, 13자리 이상 Luhn 카드와도 다릅니다. 영문이 섞인 6–12자리 잡다한 번호 규칙에도 잘 안 맞습니다. 13자리를 그대로 붙이면 규칙은 통과시키는 쪽이 보통입니다. 운전면허번호, 여권번호 같은 다른 고유식별정보도 같은 칸에 둡니다.

카드 쪽에서 결제 업계는 「화면에 몇 자리까지 보여도 되는가」와 「저장할 때 어떻게 자르는가」를 나눕니다. PCI 보안표준위원회는 8자리 BIN 설명에서, 주계좌번호를 보여줄 때 각 브랜드가 널리 받는 상한은 여전히 앞 여섯과 뒤 넷이라고 다시 적습니다. 회신 확인에 뒤 네 자리만 필요한 자리라면, 뒤 네 자리만 보여야 합니다. 티켓을 보내는 일은 매입 시스템이 아닙니다. 기본은 뒤 네 자리만 남기는 편이 안전합니다. 이는 PCI 인증 주장이 아닙니다. 16자리를 채팅에 그대로 붙이는 것이, 표시 쪽의 흔한 상한을 넘는다는 사실입니다.

이메일 마스크가 로컬만 가리고 도메인을 남기면, 받는 사람은 「어느 회사 사람인지」를 읽습니다. 키 규칙은 공개 접두사에 기대입니다. GitHub 클래식 개인 액세스 토큰은 ghp_ 뒤 36자, 세분 토큰은 github_pat_. AWS IAM 액세스 키 식별자는 흔히 AKIA 뒤 16자. Stripe 라이브 키는 sk_live_. Slack 봇 토큰은 xoxb-. 접두사가 있는 이유는 SDK와 스캐너가 알아보기 위해서입니다. 규칙이 막을 수 있는 이유도 같습니다. 안정된 접두사가 없는 자체 토큰, 「g h p 밑줄……」로 가른 열은 평범한 문장으로 통과합니다.

IP는 점 구분 십진의 유효 범위(각 옥텟 0–255)로 잡아, 버전 문자열 1.2.3을 덜 집어삼키게 합니다. 데모와 카나리아는 문서용 예약 구간을 쓰고, 운영 주소를 쓰지 마세요. RFC 5737은 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24를 남겨 두고, 공중 경로에 나오지 말라고 합니다. 이메일 데모는 example.com입니다. 근거는 RFC 2606의 예약 도메인이며, 실제 회사가 아닙니다.

신분증 번호와 카드 번호는 같은 숫자열을 두고 싸웁니다

18자리 공민신분번호는 끝이 숫자이면 전부 숫자입니다. 그 열을 「긴 카드 번호」로 카드 규칙에 넘기면 Luhn이 우연히 맞을 수 있습니다. 두 규칙이 한 문단에 겹치면 우선순위를 먼저 정해야 합니다. 정하지 않으면 같은 구간을 두 번 가리거나, 잘못된 모양으로 가립니다.

안정된 순서는 이렇습니다. 신분증 번호를 키보다 먼저, 키를 전화보다 먼저, 전화를 이메일보다 먼저, 이메일을 카드보다 먼저, 카드를 IP보다 먼저. 이유는 구체적입니다. 신분증을 먼저 확정하면 18자리가 Luhn에 카드가 되지 않습니다. 키 접두사는 「전화처럼 보이는 숫자」보다 특수합니다. 이메일 안의 숫자를 전화 규칙이 한 번 더 자르면 안 됩니다. IP가 가장 넓어서 마지막에 두면 버전 문자열이나 주문의 점 구분 숫자를 덜 먹습니다. 겹치면 우선순위가 높거나 더 긴 적중만 남깁니다.

페이지에서 「신분증 번호」를 끄고 「카드 번호」만 켜 두면, 그 숫자열을 카드로 다루는 것이 맞습니다. 규칙을 시험할 때의 예상이지, 기본 발송 방침이 아닙니다. 기본은 여섯 종류를 모두 켜고, 빠진 이름과 주소·주민등록번호는 사람이 봅니다.

별표는 익명정보가 아니고, 가명처리가 끝났다는 뜻도 아닙니다

개인정보 보호법 제2조는 개인정보를 「살아 있는 개인에 관한 정보로서 성명, 주민등록번호 및 영상 등을 통하여 개인을 알아볼 수 있는 정보」와, 다른 정보와 쉽게 결합하면 알아볼 수 있는 정보로 적습니다. 같은 조는 가명처리를 「개인정보의 일부를 삭제하거나 일부 또는 전부를 대체하는 등의 방법으로 추가 정보가 없이는 특정 개인을 알아볼 수 없도록 처리하는 것」으로 정의하고, 그렇게 만든 결과를 가명정보라고 부릅니다. 개인정보보호위원회의 가명정보 처리 가이드라인(2026년 3월 개정)은 가명처리를 통계 작성, 과학적 연구, 공익적 기록 보존 같은 활용 절차로 다룹니다. 티켓 한 줄을 별표로 바꾼 일을, 그 절차가 끝났다고 쓰지 않습니다.

제58조의2는 익명정보를 법 적용 밖으로 둡니다. 「시간·비용·기술 등을 합리적으로 고려할 때 다른 정보를 사용하여도 더 이상 개인을 알아볼 수 없는 정보」입니다. 가명정보는 여전히 개인정보입니다. 추가 정보를 분리해 두면 다시 이을 여지가 남습니다. 스마트 마스킹은 대조용 꼬리를 일부러 남깁니다. 전화 뒤 네 자리, 카드 뒤 네 자리, 이메일 도메인, 키 접두사. 티켓에 이름, 주소, 사내 고객번호가 같이 있으면, 뒤 네 자리만으로 「알아볼 수 있는」 상태에서 「알아본」 상태로 되돌릴 수 있습니다. 이는 가명처리 방향에 가까워질 수는 있어도, 익명정보에는 닿지 않습니다. 완전 마스킹은 적중 구간을 같은 길이의 별표로 바꿔 이음 실마리를 하나 줄입니다. 길이, 위치, 주변 문장은 남습니다. 문장 자체가 「계약자에게 회신해 주세요」나 「주민등록증 사본은 첨부」라고 쓰여 있을 수도 있습니다.

따라서 「규칙을 돌렸다」를 「이 문단은 공개 지식 창고에 넣어도 된다」나 「어떤 인증을 충족했다」로 쓸 수 없습니다. 도구 페이지도 개인정보 보호법이나 GDPR 인증을 주장하지 않습니다. 맞는 문장은 이렇습니다. 알려진 형태의 칸은 마스크로 바뀌었다. 알려지지 않은 형태의 칸은 움직이지 않았다. 특정 사람으로 다시 이을 수 있는지는, 문맥을 보고 여러분이 판단한다.

규칙이 모르는 한 문장이, 발송 사고의 본체인 경우가 많습니다

빠짐을 목록으로 쓰는 편이, 적중을 기능으로 쓰는 것보다 쓸모 있습니다. 첫째는 안정된 숫자 형태가 없는 직접 식별입니다. 한글 이름, 도로명 주소, 직장, 병력 서술, 아이 학교. 규칙에 「전국 성명표」는 없고, 이름 인식을 붙인 클라우드도 평범한 단어를 이름으로 오인하는 일이 있습니다. 둘째는 다시 쓴 기밀입니다. 「공일공 일이삼사 오육칠팔」, 전각 숫자, 사이에 「의」나 폭 없는 문자를 넣은 열, 텍스트가 아니라 스크린샷. 정규식이 보는 것은 지금 코드포인트 열입니다. 사람이 읽어 준 번호가 아닙니다.

셋째는 공개 접두사가 없는 비밀입니다. 데이터베이스 접속 문자열, JWT 세 토막, 자체 token=, 사내 시스템의 세션 쿠키는 ghp_ / AKIA / xoxb-의 짧은 명단에 없습니다. 넷째는 첨부와 리치 텍스트입니다. 워드 머리글, 표의 숨은 열, 메일 서명의 휴대전화, PDF 안의 레이어. 규칙이 검사하는 것은 입력란에 붙인 일반 텍스트뿐입니다. 다섯째는 의미 층의 기밀입니다. 미공개 계약 금액, 취약점 세부, 민원 원문. PII 형태가 아닙니다. 밖으로 내면 같은 종류의 해가 납니다.

한국 현장에서는 한 종류를 더 앞에 적어야 합니다. 주민등록번호 13자리, 운전면허·여권 같은 다른 고유식별정보, 하이픈이 있는 010 / 011 국내 휴대. 위에서 본 대로, 이들은 여섯 종류의 중심에 들어 있지 않습니다. +82를 붙인 휴대와, 공개 접두사가 있는 키와, Luhn을 통과하는 카드는 잡을 수 있습니다. 13자리 고유식별정보와, 읽어 준 숫자와, 주소는 통과시킵니다. 「마스킹했다」는 화면을 보고 안심하는 것은, 이 차이를 놓쳤을 때입니다.

「맞았는데, 가린 종류가 틀린」 경우도 있습니다. 주문번호, 송장, 회의실 내선이 전화처럼 보일 수 있습니다. 문서 버전 10.20.30.40은 IPv4처럼 보입니다. 검사와 경계(앞뒤가 숫자가 아님)는 일부를 막고, 전부를 막지는 않습니다. 그래서 결과란은 「어떤 종류가 몇 번 맞았는지」를, 별표투성이 문장과 같이 내야 합니다. 대조하는 것은 종류가 맞는지이지, 별표가 충분한지가 아닙니다.

바로 확인하기: 카나리아를 입력란에 넣고, Network를 검색합니다

「로컬에서 마스킹하고, 올리지 않는다」는 구호는 스스로 증명되지 않습니다. 그 자리에서 보이는 것은 네 가지입니다. 어떤 종류가 지칭되었는지, 마스크 모양이 맞는지, 일부러 남긴 문장이 그대로인지, 원문이 업무 데이터로 나갔는지.

먼저 실제 신원이 없는 카나리아를 만듭니다. 전화는 국제형의 버릴 수 있는 열, 예를 들어 +821012345678(본인 번호로 바꾸지 마세요). 메일은 canary@example.com. IP는 203.0.113.10. 카드는 4111111111111111. 키는 공개 접두사 뒤를 버릴 수 있는 문자로 채운 가짜 토큰, 예를 들어 ghp_ 뒤에 직접 만든 36자. 끝나면 폐기한 것으로 칩니다. 누구의 실제 주민등록번호도 쓰지 마세요. 13자리 검사를 보여 주고 싶다면, 분명히 가짜라고 표시한 버리는 숫자열만 쓰고 기대값은 「적중에 안 나온다」입니다.

카나리아를 평범한 티켓 문장에 넣습니다. 「이용자 canary@example.com이 로그인할 수 없다고 합니다. 회신은 +821012345678. 출발 IP는 203.0.113.10. 시험 카드 4111111111111111. 토큰 ghp_…. 배송지는 서울특별시 종로구 세종대로 209.」 실행 뒤 이메일, 국제형 전화, IP, 카드, 토큰은 적중 집계에 나오고 위 표의 모양으로 바뀌어야 합니다. 「서울특별시 종로구 세종대로 209」는 원문 그대로 남아야 합니다. 이는 고장이 아닙니다. 규칙의 경계입니다. 주소까지 가렸다면, 쓰는 도구가 순수 규칙이 아니거나 규칙이 너무 넓습니다. 오탐을 따로 보세요.

같은 문단에 국내형 010-1234-5678(가상)과, 13자리 버리는 숫자열을 더해도 됩니다. 적중 집계에 안 나오면 빠짐의 시연입니다. 나오면 그 회차의 규칙이 넓을 뿐입니다. 어느 쪽이든 결론은 같습니다. 국내 휴대와 주민등록번호에 해당하는 열은 사람 눈의 몫입니다.

이어서 개발자 도구의 Network를 열고 Preserve log를 켠 뒤, 카나리아의 독특한 문자열로 검색합니다. 예를 들어 +821012345678, canary@example.com, 가짜 토큰 전체. XHR / Fetch의 요청 줄, 쿼리, 본문에 나오면 안 됩니다. 방문 통계의 query와 body에도 나오면 안 됩니다. 정적 스크립트 파일 이름에 「privacy」「redact」가 보이는 것은 예상입니다. 원문이 업무 필드로 나가는 것만이 실패입니다.

1. 가상 국제형 전화, example.com 메일, RFC 5737 주소, 시험 카드, 접두사가 있는 가짜 토큰으로 티켓 문장을 만들고, 한글 주소를 일부러 남깁니다.
2. 실행 뒤 숫자·계정 다섯 종류가 지칭되고, 주소가 결과에 남는지 대조합니다.
3. 카나리아 원문으로 Network를 검색합니다. 업무 요청에 걸리면 입력이 이 탭을 떠난 것입니다.

이 절차가 증명하는 범위는 좁습니다. 이번 실행에서 알려진 형태는 마스크가 되었고, 주소 문장은 그대로이며, 관찰한 HTTP 필드로 원문은 이 탭을 떠나지 않았다. 확장 프로그램이 입력란을 읽지 않았다는 증명은 아닙니다. 실제 티켓으로 바꾸면 빠지지 않는다는 증명도 아닙니다. 브라우저를 바꾸거나 규칙 스위치를 바꾼 뒤에는 카나리아를 한 번 더 돌릴 가치가 있습니다.

열자마자 쓰는 마스킹 페이지에서 경계를 손에 익히세요

종류 스위치와 적중 집계를 페이지에 올려 두고 연습하려면, MakePwd의 UTM 제거·개인정보 마스킹에서 개인정보 마스킹으로 들어가면 됩니다. 열자마자 쓰며, 가입도 계정도 없습니다. 검사와 마스킹은 현재 탭에서 끝납니다. 제품 설명대로 원문은 요청으로 나가지 않고 analytics에도 기록되지 않습니다. 켜고 끌 수 있는 종류가 위의 여섯입니다. 전화번호, 신분증 번호, 카드 번호, 이메일, API 키, IP. 기본은 스마트 마스킹이며 완전 마스킹으로 바꿀 수 있습니다. 한 번의 텍스트 상한은 512 KB입니다. 페이지는 한계를 분명히 씁니다. 모든 신분증 형식을 인식하지 못하고, 텍스트가 어떤 준수 요건을 충족한다고 증명하지도 못합니다. 중요한 발송은 사람이 다시 봐야 합니다.

연습은 카나리아만 씁니다. 실행 뒤 세 곳을 동시에 봅니다. 적중 종류 횟수, 결과 텍스트의 주소가 잘못 움직이지 않았는지, Network에 원문이 있는지. 횟수는 「종류를 맞췄는가」에 답합니다. 주소는 「규칙이 어디서 멈추는가」에 답합니다. Network는 「올렸는가」에 답합니다. 세 곳을 통과한 뒤에야 동료에게 말할 수 있습니다. 가린 것은 이 종류다. 주소는 남아 있다. 카나리아는 나간 흔적을 찾아 봤다.

링크의 추적 파라미터는 다른 일입니다. 티켓에 utm_source나 fbclid가 남은 전체 URL이 붙어 있으면, 먼저 키 이름으로 쿼리를 벗기고, 그다음 본문의 번호를 다룹니다. 절차는 UTM이 붙은 전체 링크를 채팅에 붙이면 어떤 추적 정보가 함께 나갑니다에 있습니다. 마스킹 뒤에도 그대로 도착해야 하는 비밀이면 일회용 링크로 한 번 보내고, 키는 URL의 # 프래그먼트에 둡니다. 파일 전체는 파일 암호화에서 이 기기로 .lock / .enc를 만듭니다. 단일 파일은 5 GB까지입니다. 그다음 클라우드 드라이브나 메일로 올립니다. 어느 단계도 로그인을 요구하지 않습니다.

자주 묻는 질문

별표로 가린 뒤에도 이 글은 개인정보입니까?

대개 그렇습니다. 개인정보 보호법 제2조는 가명처리를, 추가 정보 없이는 특정 개인을 알아볼 수 없도록 일부를 지우거나 바꾸는 일로 정의합니다. 제58조의2의 익명정보는 시간·비용·기술을 합리적으로 고려해도 더 이상 개인을 알아볼 수 없는 정보입니다. 뒤 네 자리가 남은 전화번호, 도메인이 남은 이메일은 티켓 문맥과 붙이면 다시 이어질 수 있습니다. 규칙 마스킹은 가명처리 쪽에 가까워질 수는 있어도, 익명정보라고 쓸 수 없습니다.

규칙 마스킹이 사람 검토를 대신할 수 있습니까?

없습니다. 규칙은 형태와 검사 자리를 보고, 의미를 읽지 않습니다. 이름, 주소, 주민등록번호, 읽어 준 숫자, 스크린샷, 잘라 쓴 키는 통과할 수 있습니다. 중요한 발송은 결과를 직접 다시 읽어야 합니다. 도구 페이지는 개인정보 보호법이나 GDPR 인증을 주장하지 않습니다.

마스킹이 원문을 서버에 올리나요?

제품 설명에 따르면 검사와 마스킹은 현재 탭에서 끝납니다. 원문은 요청 본문으로 나가지 않고 analytics에도 기록되지 않습니다. 지어 낸 카나리아로 Network를 검색해 이번 실행을 확인할 수 있습니다. 확장 프로그램이 입력란을 읽지 않았다는 증명은 아닙니다.

마스킹으로 끝나지 않는 비밀은 어떻게 보내나요?

흩어진 전화번호와 일부 신분증 번호는 규칙 마스킹을 씁니다. 비밀번호 문장 전체, 미공개 자료, 그대로 도착해야 하는 키는 일회용 링크로 한 번 보내고, 키는 URL의 # 프래그먼트에 둡니다. 파일 전체는 파일 암호화에서 이 기기로 .lock 또는 .enc를 만든 뒤 메일이나 클라우드 드라이브로 보냅니다.

다음에 보내기 전에 기억할 세 가지

첫째, 붙여넣기는 복사입니다. 티켓, 채팅, 모니터, 내보내기가 각각 한 줄을 남깁니다. 지금 페이지를 고쳐도 이미 나간 글은 돌아오지 않습니다. 둘째, 규칙은 형식이 있고 검사할 수 있는 칸만 가립니다. 이름, 주소, 읽어 준 숫자, 자체 토큰, 주민등록번호는 사람 몫이며, 남은 꼬리와 문맥은 여전히 사람을 가리킬 수 있습니다. 셋째, 세 곳을 봅니다. 적중 종류, 일부러 남긴 문장, 카나리아로 Network 검색.

다음 질문이 「전체 링크의 쿼리도 같이 보내도 되는가」라면 UTM이 붙은 전체 링크를 채팅에 붙이면 어떤 추적 정보가 함께 나갑니다를 읽으세요. 평문이 업무 데이터로 이 탭을 떠났는지 확인하려면 브라우저에서 암호화할 때, 평문이 나가지 않았는지 직접 확인하는 법을 읽으세요. 이 글은 결론에 적을 수 있는 선만 긋습니다. 규칙 마스킹이 티켓 본문에 할 수 있는 일, 그리고 했다고 쓰면 안 되는 일.