先把日誌視為一條資料供應鏈
敏感資料通常不是工程師刻意寫入日誌，而是隨著除錯物件、HTTP 標頭、例外堆疊或第三方 SDK 自動流入。常見項目包括姓名、電話、電子郵件、身分識別碼、地址、Cookie、存取權杖、API 金鑰、資料庫連線字串，以及含有使用者問題與內部文件片段的 AI 提示詞。RAG 系統還要注意檢索結果、文件 metadata 與模型回應，因為它們可能把原本受權限保護的內容複製到可搜尋的日誌平台。
第一步不是先寫遮罩規則，而是畫出資料流：哪些應用程式產生日誌、經過哪些代理或佇列、送到哪個索引、誰能查詢、保存多久，以及備份與匯出檔放在哪裡。應用程式、API Gateway、LINE webhook、ERP／CRM 介接程式、雲端函式和 IoT 平台可能各自採用不同記錄方式；只修正其中一處，其他入口仍可能持續洩漏。
接著建立簡單且可執行的分類。可將欄位分成允許明文、必須遮罩、只可用不可逆代碼表示，以及禁止記錄四類。除錯價值也要一併考量：訂單編號通常可保留，電子郵件可局部遮罩，用於跨事件關聯的使用者識別則可改成以受控金鑰產生的 HMAC。分類結果應落在共用 logging library、欄位 schema 與程式碼審查規則，而不是只存在文件中。
偵測要結合欄位語意、內容模式與抽樣驗證
最穩定的策略是優先採用結構化日誌與允許清單。應用程式明確記錄 event、status、latency、trace_id 等必要欄位，比序列化整個 request、user 或 exception 物件安全得多。對 password、authorization、cookie、token、secret、credential 等已知欄位名稱，應在共用元件中直接拒絕或替換；即使內容看起來無害，也不應交由各服務自行判斷。
內容掃描仍然必要，但不能只依賴單一正規表示式。電子郵件、電話、身分識別碼與雲端金鑰可以使用格式規則；JWT、私鑰區塊、Bearer token 與高熵字串可使用前綴、長度、字元分布和上下文共同判斷。欄位名稱與內容特徵應加權處理，例如名為 authorization 的長字串比一般錯誤訊息中的隨機識別碼更值得攔截。掃描器要在測試環境、日誌收集管線與既有索引上分層執行，避免把全部責任壓在某個入口。
- 在來源端阻止：禁止記錄完整 request body、HTTP headers、模型提示詞與第三方回應，改為挑選必要欄位。
- 在傳輸管線遮罩：於 collector 或 processor 套用第二層規則，涵蓋無法立即修改的舊系統與套件。
- 在儲存端持續掃描：對新索引與歷史資料抽樣，偵測規則遺漏、格式漂移及新型憑證。
- 在 CI 建立測試：放入合成的個資與測試金鑰，確認它們不會出現在測試輸出；不要用真實秘密值當測試資料。
偵測規則一定會遇到誤判與漏判。規則過寬會破壞錯誤訊息、降低可觀測性，甚至造成收集管線延遲；規則過窄則留下風險。工程團隊應保存命中類型、來源服務與規則版本，但不要把被攔截的原文另寫進稽核日誌。先在影子模式觀察命中結果，再逐步啟用阻擋，通常比一次全面上線更可控。
依使用目的選擇刪除、遮罩、雜湊或代碼化
不同敏感資料需要不同處理。密碼、私鑰、session cookie 與可直接使用的存取權杖沒有合理的日誌用途，應完整刪除。電子郵件或電話若只供客服辨識，可保留少量頭尾字元；若只需統計，不應保留可還原的片段。信用卡、身分識別碼等高風險資料也不應因為「已遮掉幾碼」就被視為安全，仍須限制存取與保存期限。
一般雜湊不適合低變化範圍的資料，因為電話或電子郵件可能被字典猜回。若需要在不同事件間穩定關聯，可使用帶有受管控祕密金鑰的 HMAC，並把金鑰放在 Secret Manager 或 KMS，而不是寫進程式碼或環境輸出。若日後需要經授權還原，則應採代碼化或加密，並將對照表、解密權限與查詢稽核置於獨立安全邊界。可還原能力會增加營運與權限風險，不能只是為了「以後可能有用」而保留。
遮罩順序同樣重要。理想情況是在資料離開程式程序前完成，因為 collector 端遮罩無法保護應用程式本機檔案、崩潰傾印或代理前的暫存。管線層是必要的防禦縱深，但要明確處理巢狀 JSON、陣列、URL query、編碼後內容與多行堆疊。遮罩失敗時，對認證資料宜採拒絕寫入；對一般事件則可保留安全欄位並標示 redaction_error，避免整個可觀測性系統因單筆格式異常而停止。
發現外洩後，清除日誌不等於事件結束
一旦確認敏感資料已進入日誌，先停止新的寫入，再判斷該值是否仍可被利用。API 金鑰、密碼、權杖與連線憑證應優先撤銷或輪替；只刪除日誌不能讓已被看見或匯出的秘密失效。同時縮小日誌平台的查詢與匯出權限，保存必要的存取稽核，確認資料是否流入告警通知、工單、聊天訊息、下載檔、快取、備份或下游分析系統。
歷史清除需要依儲存架構制定清單。可搜尋索引可能支援依條件刪除或重建索引，物件儲存與備份則可能只能依生命週期到期。不可直接修改的備份應記錄隔離方式、到期時間與還原限制，確保未來還原時會重新套用遮罩或立即清除。若事件涉及法規、契約或調查保存義務，刪除前要由適當的資安、法務與資料治理角色確認；技術團隊不應自行假設「全部刪掉」就是正確答案。
最後以合成測試資料重跑完整路徑，確認來源、collector、索引、告警與匯出結果都不再出現原值，並將本次遺漏轉成自動化測試與共用規則。成熟的做法不是永遠追求零日誌，而是讓每個欄位都有明確用途、最小揭露、有限保存期與可驗證的清除程序。跨 LINE、ERP、CRM、雲端與 AI 系統的環境尤其需要共同標準；必要時，可由熟悉介接架構的整合團隊協助盤點端到端資料流。