把工單或聊天紀錄外發出去前，規則個資遮蔽能遮住什麼、遮不住什麼

貼出去的不是一份文字，是多份以後收不回來的副本

很多人把「遮蔽」理解成畫面上的禮貌：把完整號碼換成星星，看起來專業一些。真正的問題發生在貼上之後。工單系統會存正文，LINE 或 Slack 會存訊息，錯誤監控會抓堆疊，工作階段重播會記輸入框，外包佇列還會再匯出一份。你在自己螢幕上改掉幾個字，改變不了已經寫進這些系統的副本。晚一步再去「清掉工單」，只能改目前這一份；歷史檢索、郵件通知和下游客戶分析往往還留著原文。

OWASP 日誌速查表把這件事寫成開發約束，而不是文案建議。它列出通常不該直接寫入日誌、而應刪除、遮罩、清洗、雜湊或加密的內容：敏感個人資料與部分可識別資訊（例如健康資訊、政府身分識別）、認證口令、存取權杖、加密金鑰和其他主金鑰、銀行帳戶或支付卡持卡人資料。工單和群組在公司裡經常扮演「非正式日誌」：檢索方便、權限比正式環境鬆、保留時間更長。把使用者原話整段貼進去，等於主動製造一份 OWASP 不建議留下的紀錄。

HTTPS 只保護傳輸過程中的竊聽。它不擦掉你已經交給下一個系統的明文。上一篇寫過：網址列裡的查詢字串會進歷史紀錄、Referer 和存取日誌。正文裡的號碼是同一類暴露，只是載體從 URL 換成了段落。外發前要處理的，不是「這個工單系統安不安全」，而是「這一段裡有沒有不該離開目前分頁的欄位」。

規則認的是形狀和校驗位，不是這段話在說什麼

規則個資遮蔽的工作方式很窄。它用正規表示式找候選字串，再用校驗函式丟掉明顯不像的命中，最後按優先順序處理重疊。它不知道「王小明」是人名，也不知道「明天送到信義區市府路」是地址。它只知道：這一串數字是不是常見手機形態，這一串是不是過了已知證件格式，這一串 16 位是不是過了金融卡常用的 Luhn 校驗。

這和「模型讀懂了工單再改寫」不是一條路。大模型外發前再掃一遍個資，本身又把原文送給了另一個處理方；閘道側遮蔽也是把文字送去識別服務。規則掃描可以完全留在目前分頁：輸入不離開瀏覽器，結果是遮罩後的副本。代價是涵蓋面取決於名單。名單外的證件、自造金鑰前綴、被空白拆開的數字，都會漏。

校驗位用來降低誤傷，不是用來證明「這就是真實身分」。大陸 18 位公民身分號碼按 GB 11643-1999 / ISO 7064 MOD 11-2 計算第 18 位：前 17 位分別乘以加權因子 7、9、10、5、8、4、2、1、6、3、7、9、10、5、8、4、2，加總後對 11 取餘，再對照校驗字元表 10X98765432；餘數為 2 時第 18 位是 X，代表 10。通過校驗只說明「這串字元像一個合法號碼」，不說明戶籍庫裡有這個人。台灣國民身分證統一編號是 1 個英文字母加 9 位數字，規則用「字母加數字、長度落在 6 到 12」這類通用形態收下，沒有走內政部檢查碼。通過規則只代表「長得像證件」，不代表「這張證是真的、或檢查碼算對了」。金融卡一側常用 ISO/IEC 7812 的 Luhn 演算法：從右往左隔位乘 2，大於 9 則減 9，總和能被 10 整除才收下。一串隨便敲的 16 位數字，多數過不了 Luhn，規則就不該把它當成卡號。

六類欄位分別認什麼，遮完長什麼樣

能被穩定認出來的，通常是「有公開格式、還能加一層校驗」的欄位。下面按常見外發文字裡的出現順序寫，遮罩形狀以「保留少量首尾、中間換星號」的智慧遮蔽為例；需要把可見數字也抹掉時，應改用完全遮蔽。

電話規則要同時照顧「連續數字」和「帶空白、括號、短橫」的寫法。大陸號用 1[3-9] 開頭的 11 位是公開號段形態。台灣手機常見 09 開頭的 10 碼，規則多半按「長度剛好 10 位」收下，遮成 ***-***- 加後四碼，不是電信業號段表，也不是大陸號那種前三後四。國際號按 E.164 的常見外觀來抓：以 + 開頭、後面 7 到 15 位數字。數字太短或夾在更長數字中間，應被丟掉，否則訂單編號、宅配單也會被當成手機。

證件字號裡，大陸 18 位除了校驗位，還要求地址碼非 0 開頭、出生年在 19 或 20 世紀、月份和日期落在合法範圍。美國社會安全號若寫成 AAA-GG-SSSS，官方排除過若干無效區號：000、666、以 9 開頭；分組不能是 00，序號不能是 0000。英國國民保險號是兩個字母、六位數字、再加 A–D，並排除 BG、GB 等前綴。台灣身分證字號沒有走內政部加權檢查碼；規則認的是「1 到 2 個字母加 6 到 9 位數字」這類外觀。這些規則提高的是「像證件」的把握，不是「此人存在」的證明。

卡號一側，支付產業把「螢幕上最多露出多少位」和「儲存時如何截斷」分成兩件事。PCI 安全標準委員會在 8 位 BIN 說明裡重申：展示主帳號時，各品牌普遍接受的上限仍是前六後四；具體崗位若只需要後四位核對，就只應看到後四位。工單外發不是收單系統，預設只留後四位更穩妥。這不構成 PCI 認證聲明，只說明：把 16 位完整貼進 LINE，已經超過展示側的常見上限。

電子信箱遮罩若只擋本地部分、留下完整網域，接收方仍能看出「這是哪家公司的人」。金鑰規則依賴公開前綴：GitHub 經典個人存取權杖用 ghp_ 加 36 位，細粒度權杖用 github_pat_；AWS IAM 存取金鑰識別常見 AKIA 加 16 位；Stripe 直播金鑰用 sk_live_。前綴存在，是為了讓 SDK 和掃描器認出來——這也是規則能擋住它們的原因。沒有穩定前綴的自造 token、被拆成「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 位公民身分號碼全是數字（末位也可能是 X）。若有人把末位是數字的身分號碼當成「一長串卡號」送給金融卡規則，Luhn 偶爾也會算對。兩類規則疊在同一段文字上時，必須先定優先順序，否則同一串會被遮兩次，或被遮成錯誤的形狀。

一種穩妥排法是：證件字號優先於金鑰，金鑰優先於電話，電話優先於電子信箱，電子信箱優先於金融卡，金融卡優先於 IP。理由很具體。先認證件，避免 18 位身分號碼被 Luhn 收成卡號；金鑰前綴比「像電話的數字」更特殊；電子信箱裡的數字不應再被電話規則切一刀；IP 最寬，放最後以免吃掉版本號或訂單裡的點分數字。重疊時只保留優先順序更高、或更長的那一次命中。

你在頁面上關掉「身分證」、只開「金融卡」時，行為應反過來：允許把那串數字按卡號處理。這是除錯規則時的預期，不是預設外發策略。預設應六類全開，再人工看漏網的姓名和地址。

星星不等於已去識別，也不等於可以當公開資料用

《個人資料保護法》第 2 條把個人資料寫成「得以直接或間接方式識別該個人之資料」，並列舉姓名、出生年月日、國民身分證統一編號、護照號碼、病歷、聯絡方式、財務情況等。星號中間換掉幾碼，條文沒有把它寫成已經不是個人資料。施行細則第 3 條把間接識別寫得更白：保有該資料的機關若須與其他資料對照、組合、連結，才能認出特定人，仍屬間接識別。學說實務常把「無法直接或間接識別」叫去做識別化；個資法本文並未把「去識別化」三個字寫進條文，更沒有把「中間換成星號」寫成已經合規。

智慧遮蔽故意留下可核對的尾巴：手機後四碼、卡號後四碼、電子信箱網域、金鑰前綴。工單裡若同時還有姓名、地址或內部客戶編號，後四碼足夠把人從「可識別」推回「已識別」。這最多接近去識別化的方向，達不到「已無從識別、可當非個資使用」。完全遮蔽把命中段落換成等長星號，少了一條拼接線索，但仍留下長度、位置和周圍句子。句子本身可能寫著「請回撥機主」或「身分證影本見附件」。

因此，「跑過規則」不能寫成「這段可以進公開知識庫」或「已經滿足某項認證」。工具頁也不聲稱符合個資法或 GDPR。正確的句子是：已知形狀的欄位被換成了遮罩；未知形狀的欄位沒有被動；是否還能識別出具體的人，要結合上下文由你判斷。

規則認不出的，往往才是外發事故裡的那一句

把漏報寫成清單，比把命中寫成功能更有用。第一類是沒有穩定數字形態的直接識別：中文姓名、住址、任職單位、病歷描述、孩子的學校。規則沒有一份「全國姓名表」可查，開了姓名識別的雲端服務也常把普通詞誤判成姓名。第二類是被改寫的敏感值：「零九一二三四零零零零」、全形數字、中間插入「的」或零寬字元、用截圖而不是文字。正規表示式看的是目前碼點序列，不是人讀出來的號碼。

第三類是沒有公開前綴的秘密。資料庫連線字串、JWT 三段式、自造的 token=、內部系統的工作階段 cookie，都不在 ghp_ / AKIA 那張短名單上。第四類是附件和富文字：Word 頁首、表格隱藏欄、電子郵件簽名裡的手機、PDF 裡的圖層。規則只掃你貼進輸入框的純文字。第五類是語意層面的機密：未公開的合約金額、漏洞細節、客戶申訴原話。它們不是個資形態，但外發同樣會造成傷害。

還有一類「命中了但遮錯了」。訂單編號、宅配單、會議室分機有時會長得像電話；文件版本 10.20.30.40 長得像 IPv4。校驗和邊界（前後不是數字）能擋掉一部分，擋不掉全部。所以結果區必須同時給出「命中了哪些類型、各幾次」，而不是只給一段已經打星的文字。你要核對的是類型對不對，不是星星夠不夠多。

當場核對：金絲雀進輸入框，再搜 Network

口號寫「本機遮蔽、不上傳」無法自證。能當場看到的是四件事：哪些類型被點名，遮罩形狀對不對，故意漏掉的句子還在不在，以及原文有沒有作為業務資料出站。

先準備一段不含真實身分的金絲雀。電話用自己編的 0912000123（明顯虛構的 09 開頭十碼，不要改成你或同事的號）。電子信箱用 canary@example.com。IP 用 203.0.113.10。卡號用 4111111111111111。金鑰用一段帶公開前綴、其餘全是可丟棄字元的假權杖，例如 ghp_ 後面跟你自己編的 36 位，用完即當失效。證件字號不要用任何人的真實號碼；若要驗證規則有沒有認「字母加數字」，用明顯不可能的字串（例如 A100000000）並在段落標明「虛構」。

把金絲雀嵌進一句正常工單：「使用者 canary@example.com 稱無法登入，回撥 0912000123，來源 IP 203.0.113.10，測試卡 4111111111111111，權杖 ghp_……。收件地址寫在台北市信義區市府路。」跑完之後，電子信箱、電話、IP、卡號和權杖應出現在命中統計裡，並按上表變成遮罩；「台北市信義區市府路」應原樣保留——這不是故障，這是規則邊界。若地址也被遮了，說明你用的不是純規則，或規則被擴得過寬，需要另看誤傷。

再開啟開發者工具的 Network，勾選 Preserve log，用金絲雀裡的獨特字串搜尋，例如 0912000123、canary@example.com 或假權杖全文。XHR / Fetch 的請求行、查詢字串和請求體都不該出現它們；造訪統計的 query 與 body 同樣不該出現。靜態指令稿檔名裡出現「privacy」「redact」是預期。原文作為業務欄位出站，才算失敗。

1. 用虛構 09 手機、example.com 電子信箱、RFC 5737 位址、測試卡號和帶前綴的假權杖拼一段工單，並故意留一句中文地址。
2. 跑完對照命中類型：五類數字／帳號應被點名，地址應仍在結果裡。
3. 用金絲雀原文搜尋 Network；任一業務請求命中即說明輸入離開了分頁。

這套步驟證明的範圍很窄：這一次操作裡，已知形狀被換成遮罩，地址類句子沒被動，原文沒有作為已觀察到的 HTTP 欄位離開目前分頁。它不證明擴充功能沒有讀取輸入框，也不證明換一段真實工單不會漏報。換瀏覽器或改規則開關之後，值得再跑一遍金絲雀。

用開啟即用的遮蔽頁把邊界練熟

若你希望用一個把類型開關和命中統計寫在頁面上的工具來練習，可以從 MakePwd 的隱私清洗切入個資遮蔽。開啟即可使用，無需註冊，也沒有帳號。掃描和遮罩發生在目前分頁；依產品說明，原文不作為請求發出，也不會寫入 analytics。可勾選的類型就是上面六類：電話、身分證、金融卡、電子信箱、API Key、IP。預設智慧遮蔽，可改完全遮蔽。單次文字上限是 512 KB。頁面明確寫了：不能識別所有證件格式，不能證明文字已符合個資法或其他合規要求，重要外發必須人工覆核。

練習時只用金絲雀。跑完同時看三處：命中類型計數、結果文字裡的地址有沒有被誤傷、Network 裡有沒有原文。計數回答「認對了沒有」；地址回答「規則邊界在哪」；Network 回答「有沒有上傳」。三處都過，才能向同事解釋：我遮的是這些類型，我知道地址還在，我搜過金絲雀沒有出站。

連結形態的追蹤參數是另一件事。工單裡若還貼了帶 utm_source 或 fbclid 的完整 URL，應先按鍵名剝離查詢字串，再處理正文裡的號碼。步驟見把帶 UTM 的完整連結貼進聊天，會把哪些追蹤資訊一起發出去。若遮蔽之後仍是一段必須原樣送達的機密，用閱後即焚一次性發送，金鑰留在 URL 的 # 片段；整份檔案則用檔案加密盒在本機做成 .lock / .enc（單檔不超過 5 GB）再走雲端硬碟或電子郵件。這些步驟都不要求登入。

常見問題

星號遮罩之後，這段文字還算個人資料嗎？

通常還算。個資法第 2 條把個人資料寫成得以直接或間接方式識別該個人的資料；施行細則把間接識別寫成須與其他資料對照、組合、連結後才能認出特定人。留下後四碼的手機、帶網域的電子信箱，配上工單上下文仍可能被拼回。規則遮蔽最多接近去識別化方向，不能寫成已經不是個人資料。

規則個資遮蔽能替代人工覆核嗎？

不能。規則認的是模式和校驗位，不是語意。姓名、地址、口述數字、截圖和改寫過的金鑰都可能漏過。重要外發仍要自己通讀結果。工具頁也不聲稱符合個資法或 GDPR 認證。

個資遮蔽會不會把原文上傳？

依產品說明，掃描和遮罩發生在目前分頁，原文不作為請求發出，也不寫入 analytics。可用虛構金絲雀在 Network 裡搜尋原文核對。這只證明這一次觀察到的請求，不證明擴充功能沒有讀取輸入框。

整段還沒遮蔽完的機密該怎麼發？

散落的手機號碼、證件字號用規則遮罩；整段口令、未公開材料和必須原樣送達的金鑰，用閱後即焚一次性發送，金鑰留在 URL 的 # 片段。整份檔案用檔案加密盒在本機做成 .lock 或 .enc 再走雲端硬碟或電子郵件。

下次外發前記住的三件事

第一，貼上即複製。工單、LINE、監控和匯出各留一份，事後改目前頁收不回已經發出去的原文。第二，規則只擋有格式、能校驗的欄位；姓名、地址、口述數字和自造金鑰要人看，遮罩留下的尾巴加上下文仍可能識別到人。第三，核對看三處：命中類型、故意留下的句子、用金絲雀搜尋 Network。

若你還要繼續追問「完整連結裡的查詢字串該不該一起外發」，請讀把帶 UTM 的完整連結貼進聊天，會把哪些追蹤資訊一起發出去。若要核對明文有沒有作為業務資料離開分頁，請讀線上加密安全嗎？怎麼當場核對明文沒有離開本機。本文只把「規則個資遮蔽對工單正文能做什麼、不能寫成什麼」收成可以寫進結論的範圍。