去識別化簡介
發現敏感資料只是成功的一半。一旦識別出敏感資料，您必須決定如何保護它，同時仍允許組織從中獲取價值。去識別化 (De-identification) 是移除或轉換敏感資訊的過程，使資訊不再能與特定個人關聯。
對於 PSE 而言，掌握 Cloud DLP 中的各種轉換技術對於實現安全的資料分析、機器學習以及跨環境的資料共享至關重要。
白話文解釋（Plain English Explanation）
比喻 1：圖書館的善本書區
Cloud DLP 去識別化就像圖書館把珍貴手稿鎖在玻璃櫃後面。訪客可以閱讀影印本（也就是轉換後的資料集）——但影印本上人名被塗黑（刪節 / Redaction）、信用卡號碼有一半被遮住（遮罩 / Masking），或頁碼被替換成圖書館內部編碼（權杖化 / Tokenization）。原版手稿仍鎖在金庫，只有持有 KMS 封裝金鑰的授權館員才能取出。
比喻 2：航空公司的乘客名單
**格式保留加密（FPE）**就像航空公司把乘客真實的護照號碼換成一個假號碼，但仍維持相同形狀——9 位數字、相同的檢查碼模式。登機口掃描器（也就是您的舊型應用程式）不會當機，因為格式完整保留，但即使名單外洩，也無法揭露真實旅客身分。**日期位移（Date Shifting）**也是類似道理：一份被位移 47 天的航班紀錄，仍能保留航班之間的時間間隔（對詐欺偵測有用），卻不會暴露真實的旅行時間。
比喻 3：醫院的研究資料室
醫院透過分組／概括化（Bucketing / Generalization）將匿名病歷分享給研究人員。原本的「A 病患，年齡 27 歲，郵遞區號 94043」會變成「A 病患，年齡 20-30 歲，郵遞區號 940」。研究人員仍能計算「糖尿病患者的平均年齡」，但無法定位到單一個人——這就是 k-anonymity 的實際應用。DLP 的去識別化範本**就像醫院 IRB 核准的食譜書，確保每一份離開資料室的資料集都套用一致的處理規則。
核心轉換技術
Cloud DLP 提供了多種轉換資料的方法，具體取決於所需的隱私級別與資料可用性。
1. 遮罩與刪節 (Masking and Redaction)
- 刪節 (Redaction)： 完全移除敏感值（例如，將 "John Doe" 替換為
[REDACTED]）。 - 遮罩 (Masking)： 使用固定字元替換資料的一部分（例如，
4532 XXXX XXXX 1234）。
2. 虛擬姓名化與權杖化 (Pseudonymization and Tokenization)
虛擬姓名化是使用代理值（「權杖 (Token)」）替換敏感值。
- 決定性 (Deterministic)： 相同的輸入始終產生相同的輸出。這允許在 BigQuery 中跨不同資料集進行 JOIN 操作。
- 非決定性 (Non-deterministic)： 相同的輸入每次產生不同的輸出。安全性更高，但會破壞用於關聯分析的資料可用性。
虛擬姓名化 (Pseudonymization) 是一種去識別化方法，它將資料記錄中的識別欄位替換為一個或多個人工識別碼或虛擬姓名。
3. 格式保留加密 (Format-Preserving Encryption, FPE)
FPE 在加密值的同時，維持其原始格式與長度。
- 範例： 16 位元的信用卡號碼在加密後仍為 16 位元的數字。
- 好處： 允許預期特定格式的舊型應用程式 (Legacy Apps) 無需修改即可繼續運作。
進階轉換技術
日期位移 (Date Shifting)
與其移除日期（長期研究可能需要日期），您可以將其位移隨機的天數。
- 如果使用 加密金鑰 (Crypto Key)，特定使用者在特定資料集內的位移量將保持一致。
- 在隱藏實際日期的同時，維持事件的先後順序與時間間隔。
分組/概括化 (Bucketing / Generalization)
使用一個範圍或較不具體的值替換具體值。
- 範例： 將年齡
27替換為級距20-30。 - 好處： 降低被重新識別的風險 (k-anonymity)，同時保留統計趨勢。
在選擇轉換方式時，隱私性與可用性之間總是存在權衡。刪節提供最高的隱私性但零可用性，而分組則提供高可用性但隱私性較低。
管理去識別化金鑰
大多數加密轉換（FPE、權杖化、日期位移）都需要金鑰。
- 暫時性金鑰 (Transient Keys)： 即時產生並隨後丟棄。如果您永遠不需要還原轉換，請使用此方式。
- 封裝金鑰 (Wrapped Keys / KMS)： 在 Cloud KMS 中管理的金鑰。如果獲得授權，這允許進行重新識別 (Re-identification)（解除遮罩）。
如果您在權杖化中使用暫時性金鑰，則無法跨不同的 DLP 工作執行 JOIN 操作，因為相同的輸入會映射到不同的權杖。
去識別化範本
與檢查範本類似，去識別化範本 (De-identification Templates) 允許您標準化轉換邏輯。
- 定義哪些 InfoTypes 應該被遮罩、哪些應該使用 FPE 加密，以及哪些應該進行分組。
- 可以在 DLP 工作中引用，或在使用 DLP API 進行即時去識別化時使用。
BigQuery 的安全分析
PSE 常用的模式是將 DLP 與 BigQuery 整合：
- DLP 代理 (DLP Proxy)： 使用 Cloud Function 攔截資料，呼叫 DLP API 進行去識別化，然後將「清洗後」的資料存入 BigQuery。
- 遠端函式 (Remote Functions)： 直接從 BigQuery 的 SQL 查詢中呼叫 DLP API，為特定使用者動態遮罩資料。
效能與最佳化
對大型資料庫中的每一列呼叫 DLP API 可能會很慢且昂貴。
- 批次處理 (Batching)： 在單次 API 呼叫中發送多條記錄。
- 來源端轉換： 在資料到達雲端之前進行去識別化，以最小化暴露風險。
- 取樣 (Sampling)： 使用檢查工作找出 PII 存在的欄位，然後僅對這些特定欄位應用去識別化。
Sensitive Data Protection：轉換方法選擇
Cloud DLP（已於 2023 年更名為 Sensitive Data Protection）透過 content.deidentify API 提供六種主要的 PrimitiveTransformation 類型。選錯方法會浪費資料可用性或洩漏資料——PSE 考試會直接測試這個對照矩陣。
決策矩陣
| 方法 | API 欄位 | 可還原？ | 保留格式 | 保留 JOIN | 典型 InfoType |
|---|---|---|---|---|---|
replaceConfig |
靜態字串 | 否 | 否 | 否 | EMAIL_ADDRESS → [EMAIL] |
characterMaskConfig |
字元 + 數量 | 否 | 部分 | 否 | CREDIT_CARD_NUMBER → ****1234 |
cryptoReplaceFfxFpeConfig |
FFX-FPE 搭配 KMS | 是（需金鑰） | 是 | 是 | US_SOCIAL_SECURITY_NUMBER |
cryptoDeterministicConfig |
AES-SIV 搭配 KMS | 是（需金鑰） | 否 | 是 | PERSON_NAME 用於分析 |
cryptoHashConfig |
HMAC-SHA-256 | 否 | 否 | 是（同金鑰） | EMAIL_ADDRESS 用於追蹤 |
dateShiftConfig |
±N 天，context 鍵控 | 是（需金鑰） | 是（日期） | 是（依 context） | DATE_OF_BIRTH 用於世代研究 |
redactConfig |
直接刪除 | 否 | 否 | 否 | 自由文字中的 PII 移除 |
各方法的最佳場景
cryptoReplaceFfxFpeConfig(FPE)： 當下游主機系統（Mainframe）或舊型 COBOL 系統會驗證格式（例如信用卡號的 Luhn 檢查碼）時為必選。底層使用 NIST SP 800-38G 的 FFX 模式。只支援英數字基數；不支援空白與 Unicode。cryptoDeterministicConfig(AES-SIV)： BigQuery 分析 JOIN 的最佳預設選擇。無格式限制——輸出是不透明的類 base64 權杖。無法用於需要相容舊系統格式的場景。cryptoHashConfig： 單向 HMAC。適用於 GA 風格的匿名使用者 ID，當您永遠不需要還原原始值時——同一個 email 在同一把金鑰下永遠雜湊出相同的值，可在不儲存 PII 的前提下進行世代計數。dateShiftConfig搭配context： 將FieldId（例如patient_id）作為 context 傳入——DLP 會為每位病患衍生一個專屬的位移量，讓該病患所有日期都位移相同天數，維持長期研究的完整性。
只有 FFX-FPE、決定性加密 (Deterministic Encryption) 與附帶 context 的日期位移可以透過 content.reidentify 進行重新識別——而且必須原始的 CryptoKey（Transient、Unwrapped 或 KMS-Wrapped）仍然可用。雜湊在數學上是單向的——一旦原始值消失就永久消失了。
對於 BigQuery 原生資料管線，低敏感度欄位可以完全跳過 DLP API，改用 AEAD 函式（AEAD.ENCRYPT_AES_GCM）搭配 KMS 封裝的 keyset——這能以 SQL 速度提供決定性加密，且不會占用每列的 API 配額。把 DLP API 留給 InfoType 探索與多欄位的複雜範本即可。
六種轉換，兩大可還原性類別：
- 可還原（需金鑰）： FPE、Deterministic、Date Shift
- 不可還原： Redact、Replace、Mask、Hash
加密轉換可用的三種金鑰類型：
- Transient（暫時性） — DLP 即時產生並丟棄（無法重新識別）
- Unwrapped（未封裝） — 您在請求中直接提供 base64 原始金鑰（不安全，僅開發環境用）
- KMS-Wrapped（KMS 封裝） — 生產環境標準；DLP 透過
cloudkms.cryptoKeyVersions.useToDecrypt解封裝
PSE 考試情境
情境 1：維持分析用的資料可用性
「一名資料科學家需要分析 BigQuery 中的客戶交易模式。資料表包含信用卡號。您如何在保護卡號的同時，允許科學家計算不重複的客戶數量？」
解答： 使用決定性權杖化 (Deterministic Tokenization) 或 格式保留加密 (FPE)。這兩者都確保相同的信用卡號始終映射到相同的權杖，從而允許執行 COUNT(DISTINCT card_token) 操作。
情境 2：支援服務的重新識別
「一位客戶支援代理人需要查看某位在資料集中已被去識別化的使用者的原始電子郵件地址。這該如何實現？」 解答： 在初始去識別化時使用 KMS 封裝的加密金鑰 (KMS-wrapped Crypto Key)。然後，授權該支援代理人的身分，使用相同的金鑰執行重新識別 (Re-identify) 操作。
總結檢查表
- 列出刪節、遮罩與權杖化之間的差異。
- 解釋為什麼 FPE 對舊型應用程式很有用。
- 描述日期位移如何維持事件序列。
- 區分決定性與非決定性加密。
- 識別用於轉換的兩種類型金鑰（暫時性 vs. KMS）。
- 解釋資料隱私性與資料可用性之間的權衡。