去年十月，我在一個兩百人的技術群組裡貼過一段支付回呼日誌，只想問一句為什麼簽章驗證總是過不了。三分鐘後有人私訊我：「樓上日誌裡有四個真實手機號碼、一個身分證號，還有一個內網 IP，你自己看著辦。」我立刻收回訊息，但群組裡早就有人截了圖。那次事故最後走了公司內部流程，使用者資訊被外部接觸的可能性沒辦法完全排除。從那以後我給自己定了一條死規矩：任何要離開自己螢幕的文字，先在本機過一遍再貼。
一、外洩幾乎都不是被駭，是「順手一貼」
回頭檢視那條日誌，我貼出去的不只是手機號碼。真正容易被忽略的漏點是這些：
- 請求標頭裡的
Authorization和Cookie，很多排障求助的截圖會一起截進去，等於把工作階段權杖公開。 - URL 查詢字串裡的
mobile=13800001234，比內文裡的手機號碼更容易被漏看，因為它看起來像「設定的一部分」。 - SQL 片段，尤其是
INSERT INTO user_order (...)的完整語句，欄位值一覽無遺。 - 訂單號加上收件地址和稱呼——三者拼起來就足以定位到具體的人，就算每個欄位單獨看都「不算敏感」。
- 測試帳號往往是員工自己的手機號碼，寫進程式碼儲存庫或截圖裡就再也收不回來。
- 截圖裡的號碼，別人用 OCR 也掃得出來，所以打碼要打在圖上，不能只處理文字。
二、為什麼要保留格式，而不是整條塗黑
全部塗掉看起來最安全，但同事沒辦法憑它核對是哪一筆訂單，最後你還是得打開另一個管道把原值念給他聽——脫敏就白做了。通行的做法是保住「能對上號」的那幾位，遮住「能認出人」的那幾位。我常用的規則：
| 類型 | 遮掩規則 | 脫敏後 |
|---|---|---|
| 手機號碼（11 位） | 保留前 3 後 4，遮中間 4 位 | 138****5678 |
| 身分證號（18 位） | 保留前 3 後 4，遮中間 11 位 | 110***********1234 |
| 銀行卡號 | 只保留後 4 位 | **** **** **** 1234 |
| 電子郵件 | 保留 @ 前的首字元和完整網域 | z***@example.com |
| IP 位址 | 保留前兩段，後兩段遮掉 | 192.168.*.* |
身分證這一條最關鍵：第 7 到 14 位正好是出生年月日，必須落在被遮的區間裡；只遮末位校驗碼的那種「打碼」等於沒打。手機號碼遮中間 4 位有一萬種可能，配上姓名和城市並非絕對安全，但比完整號碼低一個數量級。
三、我的三步流程，最後一步是反查
- 文字先在隱私資訊遮蔽裡過一遍：貼進去，它會按格式把手機號碼、身分證、銀行卡、電子郵件、IP 一併遮掉，遮掩字元可以換成
#或自訂符號，整段一次處理完再複製出來。全部在瀏覽器本機完成，內容不離開這台裝置，這是我敢拿它處理生產日誌的前提。 - 圖片是另一件事。聊天記錄或後台截圖只能打在像素上，我用圖片馬賽克框選敏感區域，可以反覆框多個區塊，顆粒度調到 40px 以上再往外發；同一區域打兩遍比追求一次到位更省心。
- 發出去之前做一次反向核對：把處理結果貼進文字資訊擷取，選手機號碼、身分證、電子郵件、IP 四類各掃一遍，清單應該是空的。這一步是我那次事故之後加的——人眼看三行長的日誌，很容易漏掉藏在 URL 裡的那一個號碼。
反查有個天然邊界，必須說清楚：這類工具按格式比對數字字串，它不認中文姓名、收件地址、門市名稱和訂單號。所以第三步只能攔住「號碼漏遮」，攔不住「語意可辨識」，最後那遍還是得靠人腦。
四、哪些做法看起來像脫敏，其實不是
- Base64 或 URL 編碼：完全可逆，沒有金鑰，等於在原值外面套了一層信封。審查時被點到是最虧的一種。
- 只留前後各一位：看起來很安全，但如果同時給了姓名和生日，留下的位數就足夠把候選集合縮到很小。
- 遮掉的位數不固定：一行遮 3 位、下一行遮 5 位，讀的人反而能靠位數推斷原始號碼長度和號段。
- 靠手動刪除：刪掉手機號碼卻留下
"phone":鍵名附近的空格和對齊痕跡，同樣能猜出大致範圍；批次場景一律用工具跑，別用 Delete 鍵。 - 把脫敏當成一次性的截圖動作：真正穩健的做法是在日誌層就替換，輸出前統一遮，而不是等排障的人複製時再補。
法規用語上有一條容易搞混：《個人資訊保護法》把「去識別化」和「匿名化」分開寫——去識別化後如果不借助額外資訊仍無法識別特定個人，那它還是個人資料；匿名化則要求無法識別且不能還原。前面表格裡保留後四位的做法屬於前者，所以對外發布和對內展示是兩件事，不能因為「我已經打過碼」就把脫敏結果直接公開到外部社群。
五、常見問題
Q：脫敏和加密有什麼差別？
加密有金鑰、可還原，目的是儲存和傳輸時保護；脫敏通常是不可逆的遮掩，目的是展示時少暴露。兩者不衝突，日誌該加密儲存，截圖該脫敏再發。
Q：已經發出去的訊息還能補救嗎？
收回只對自己可見，別人已經複製或截圖的部分收不回來。能做的是評估暴露面：號碼是否還能登入、是否需要通知當事人、涉及支付的是否要換卡，越早啟動流程越好。
Q：遮成星號之後還能還原嗎？
不能，遮掩是單向的。原始資料要自己留好，脫敏結果只用於分享，不要把它當成可逆的中間格式存進資料庫。
Q：脫敏後的資料能直接拿去當測試資料嗎？
號碼類欄位可以，但要注意「可用」和「能對上」是兩回事：唯一約束、外鍵關聯會因為批次遮掩而衝突。正式建測試庫應該走批次脫敏腳本，而不是逐段貼。
Q：處理的內容會不會被上傳？
我選的都是純瀏覽器本機完成的做法，文字和圖片都不離開裝置。涉及生產資料時，這一條比效率更重要，值得當成挑選工具的先決條件。
現在回想那則私訊，最幸運的地方是提醒我的恰好是同一個人。脫敏這件事的成本大概就是複製貼上之後多花二十秒，收益是避免一次要花兩週走完的調查流程——這筆帳怎麼算都划算，前提是你把它變成流程裡的固定一步，而不是每次臨時才想起來。