匿名化

假名化是一種去識別化技術，會將機密資料值替換為加密產生的權杖。假名化廣泛用於金融和醫療保健等產業，有助於降低使用中資料的風險、縮小法規遵循範圍，並盡可能減少系統接觸機密資料的機會，同時保留資料的實用性和準確性。

Sensitive Data Protection 支援三種去識別化假名化技術，並對原始機密資料值套用三種密碼編譯轉換方法之一，藉此產生權杖。接著，每個原始私密值都會替換成對應的權杖。假名化有時也稱為「權杖化」或「代理替換」。

假名化技術可產生單向或雙向權杖。單向權杖經過不可逆的轉換，雙向權杖則可反向轉換。由於權杖是使用對稱式加密建立，因此可產生新權杖的加密編譯金鑰也能反轉權杖。如果不需要可逆性，可以使用採用安全雜湊機制的單向權杖。

瞭解假名化如何協助保護機密資料，同時讓業務營運和分析工作流程輕鬆存取及使用所需資料，這對您很有幫助。本主題將探討假名化的概念，以及 Sensitive Data Protection 支援的三種資料轉換密碼編譯方法。

如要瞭解如何實作這些假名化方法，以及更多 Sensitive Data Protection 的使用範例，請參閱「對機密資料進行去識別化」。

使用假名化的時機

以下是一些常見用途：

• 保留分析資料集的參照完整性：將客戶 ID 和主鍵替換為一致的加密權杖，讓團隊在 BigQuery 中彙整及匯總資料表，而不必公開機密 ID。
• 縮減法規遵循和稽核範圍：將信用卡號和個人識別資訊 (PII) 替換為格式保留權杖，縮小下游應用程式中的 PCI DSS 或 HIPAA 法規遵循範圍。
• 保護測試和開發環境：將實際工作環境資料庫複製到具有權杖化欄位的低階開發環境。這種做法可讓開發人員使用實際資料結構測試應用程式，而不必存取客戶的實際記錄。
• 為授權工作流程啟用安全可逆性：使用雙向加密 (例如 AES-SIV 或 FPE)，並將金鑰儲存在 Cloud Key Management Service 中，確保只有經過驗證且具備權限的後端服務，才能在法律要求時將原始值去權杖化。
• 使用密碼雜湊強制執行不可逆的資料遮蓋：產生單向 HMAC-SHA-256 摘要。如果需要跨記錄關聯進行統計分析，但還原原始明文在運算上必須不可行，就適合使用這個方法。

Sensitive Data Protection 支援的加密方法

Sensitive Data Protection 支援三種假名化技術，全都使用加密編譯金鑰。可用方法如下：

• 使用 AES-SIV 的確定性加密：輸入值會替換為使用 AES-SIV 加密演算法和加密編譯金鑰加密的值，並使用 base64 編碼，然後在前面加上代理註解 (如有指定)。這個方法會產生雜湊值，因此不會保留字元集或輸入值的長度。使用原始加密編譯金鑰和整個輸出值 (包括替代註解)，即可重新識別經過加密的雜湊值。進一步瞭解使用 AES-SIV 加密技術權杖化的值格式。
• 格式保留加密：輸入值會替換為使用 FPE-FFX 加密演算法和加密編譯金鑰加密的值，然後在前面加上替代註解 (如有指定)。根據設計，輸出值會保留輸入值的字元集和長度。您可以使用原始加密編譯金鑰和整個輸出值 (包括代理註解)，重新識別加密值。(如要瞭解使用這種加密方法時的一些重要考量，請參閱本主題稍後的「格式保留加密」一節)。
• 密碼雜湊：輸入值會替換為已加密和雜湊的值，方法是使用雜湊式訊息驗證碼 (HMAC)-安全雜湊演算法 (SHA)-256，對輸入值使用加密編譯金鑰。轉換的雜湊輸出長度一律相同，且無法重新識別。進一步瞭解使用密碼編譯雜湊權杖化的值格式。

下表匯總了這些假名化方法。表格下方會說明表格列。

• 加密類型：去識別化轉換中使用的加密類型。
• 支援的輸入值：輸入值的最低要求。
• 替代註解：使用者指定的註解，會附加在加密值前面，為使用者提供背景資訊，並提供資訊給 Sensitive Data Protection，用於重新識別去識別化值。必須提供代理註解，才能重新識別非結構化資料。使用 RecordTransformation 轉換結構化資料或表格型資料的資料欄時，可選擇是否指定。
• 結構定義調整：參照「調整」輸入值的資料欄位，以便將相同的輸入值去識別化為不同的輸出值。使用 RecordTransformation 轉換結構化資料或表格型資料的資料欄時，可選擇是否調整結構定義。詳情請參閱「使用情境調整」。
• 保留字元集和長度：去識別化值是否由與原始值相同的字元集組成，以及去識別化值的長度是否與原始值相符。
• 可還原：可使用加密編譯金鑰、代理註解和任何情境調整，重新識別。
• 參照完整性：參照完整性可讓記錄在個別去識別化後，仍能維持彼此之間的關係。只要使用相同的加密編譯金鑰和結構定義調整，資料表每次轉換時都會替換成相同的模糊處理形式，確保值 (以及結構化資料、記錄) 之間的連結保持不變，即使跨資料表也一樣。

Sensitive Data Protection 的權杖化運作方式

Sensitive Data Protection 支援的三種方法，其權杖化基本程序都相同。

步驟 1：Sensitive Data Protection 選取要權杖化的資料。最常見的做法是使用內建或自訂的 infoType 偵測工具，比對所需的機密資料值。如果掃描的是結構化資料 (例如 BigQuery 資料表)，您也可以使用記錄轉換，對整欄資料執行權杖化。

如要進一步瞭解 infoType 和記錄轉換這兩類轉換，請參閱「去識別化轉換」。

步驟 2：Sensitive Data Protection 使用加密編譯金鑰加密每個輸入值。您可以透過下列三種方式提供這組金鑰：

• 使用 Cloud Key Management Service (Cloud KMS) 包裝金鑰。(為確保最高安全性，建議使用 Cloud KMS)。
• 使用 Sensitive Data Protection 在去識別化時產生，然後捨棄的暫時金鑰。暫時金鑰只會保留每個 API 要求的完整性。如果您需要完整性，或打算重新識別這項資料，請勿使用這個金鑰類型。
• 直接以原始文字形式提供。(不建議)。

詳情請參閱本主題後續的「使用加密編譯金鑰」一節。

步驟 3 (僅限密碼雜湊和使用 AES-SIV 的確定性加密)：Sensitive Data Protection 會使用 base64 編碼加密值。使用密碼雜湊時，這個經過編碼和加密的值就是權杖，接著會繼續執行步驟 6。使用 AES-SIV 進行確定性加密時，這個經過編碼和加密的值就是代理值，只是權杖的其中一個元件。接著繼續執行步驟 4。

步驟 4 (僅限使用 AES-SIV 進行格式保留和確定性加密)：Sensitive Data Protection 會在加密值中加入選用的代理註解。代理註解會在加密代理值前面加上您定義的描述性字串，協助您識別這些值。舉例來說，如果沒有註解，您可能無法區分去識別化的電話號碼和去識別化的身分證字號或其他身分證件號碼。此外，如要重新識別非結構化資料中，已使用格式保留加密或確定性加密去識別化的值，您必須指定替代註解。(使用 RecordTransformation 轉換結構化或表格資料欄時，不需要代理註解)。

步驟 5 (僅限結構化資料的格式保留和確定性加密，採用 AES-SIV)：Sensitive Data Protection 可使用其他欄位的選用內容，「調整」產生的權杖。這樣您就能變更權杖的範圍。舉例來說，假設您有一個行銷廣告活動資料庫，其中包含電子郵件地址，而您想為廣告活動 ID「調整」的相同電子郵件地址產生不重複的權杖。這樣一來，使用者就能在同一個廣告活動中彙整同一位使用者的資料，但無法跨不同廣告活動彙整資料。如果使用情境調整項建立權杖，則必須使用這個情境調整項，才能反轉去識別化轉換。使用 AES-SIV 支援情境，進行格式保留和確定性加密。進一步瞭解如何使用情境調整功能。

步驟 6：Sensitive Data Protection 將原始值替換為去識別化值。

權杖化值比較

本節說明使用本主題討論的三種方法去識別化後，一般權杖的樣貌。機密資料值範例是北美電話號碼 (1-206-555-0123)。

使用 AES-SIV 的確定性加密

使用確定性加密和 AES-SIV 進行去識別化時，系統會使用 AES-SIV 搭配加密編譯金鑰，將輸入值 (以及任何指定的內容調整項，如有) 加密，並使用 base64 編碼，然後視需要加上代理註解 (如有指定)。這種方法不會保留輸入值的字元集 (或「字母」)。為了產生可列印的輸出內容，系統會以 Base64 編碼格式編碼結果值。

假設已指定代理 infoType，產生的權杖格式如下：

SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE

下圖為範例權杖，這是使用 AES-SIV 對值 1-206-555-0123 進行確定性加密，去識別化作業的輸出內容。選用的代理 infoType 已設為 NAM_PHONE_NUMB：

1. 代理註解
2. 代理值 infoType (由使用者定義)
3. 轉換值的字元長度
4. 代理 (轉換) 值

如未指定代理註解，產生的權杖會等於轉換後的值，或註解圖表中的 #4。如要重新識別非結構化資料，則需要整個權杖，包括代理註解。轉換資料表等結構化資料時，可選擇是否使用替代註解。Sensitive Data Protection 可使用 RecordTransformation 對整個資料欄執行去識別化和重新識別化，不需使用替代註解。

格式保留加密

使用格式保留加密進行去識別化時，系統會使用格式保留加密的 FFX 模式 (「FPE-FFX」) 和加密編譯金鑰，將輸入值 (以及任何指定的內容調整項，選用) 加密，然後視需要加上替代註解 (如有指定)。

與本主題所述的其他權杖化方法不同，輸出代理值與輸入值的長度相同，且不使用 base64 編碼。您可以定義加密值組成的字元集 (或「字母」)。您可以透過下列三種方式，指定 Sensitive Data Protection 在輸出值中使用的字母：

• 使用四個列舉值之一，代表四種最常見的字元集/字母。
• 使用基數值，指定字母表的大小。如果指定 2 的最小基數值，則會產生僅由 0 和 1 組成的字母。指定最大基數值 95 會產生包含所有數字字元、大寫英文字元、小寫英文字元和符號字元的字母。
• 列出要使用的確切字元，建立字母表。舉例來說，如果指定 1234567890-*，則會產生僅由數字、連字號和星號組成的替代值。

下表列出四種常見的字元集，並依列舉值 (FfxCommonNativeAlphabet)、基數值和字元集清單排序。最後一列列出完整字元集，對應最大基數值。

假設已指定代理 infoType，產生的權杖格式如下：

SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE

下圖為 Sensitive Data Protection 去識別化作業的輸出結果，該作業使用格式保留加密，並以 95 為基數，對 1-206-555-0123 值進行加密。選用的代理 infoType 已設為 NAM_PHONE_NUMB：

1. 代理註解
2. 代理值 infoType (由使用者定義)
3. 轉換值的字元長度
4. 替代 (轉換) 值：長度與輸入值相同

如未指定代理註解，產生的權杖會等於轉換後的值，或註解圖表中的 #4。如要重新識別非結構化資料，則需要整個權杖，包括代理註解。轉換資料表等結構化資料時，可選擇是否使用替代註解。Sensitive Data Protection 可使用 RecordTransformation 對整個資料欄執行去識別化和重新識別化，不需使用替代註解。

密碼雜湊

使用密碼雜湊進行去識別化時，系統會使用 HMAC-SHA-256 搭配加密編譯金鑰，對輸入值進行雜湊處理，然後使用 base64 進行編碼。去識別化值一律為統一長度，取決於金鑰大小。

與本主題討論的其他權杖化方法不同，密碼編譯雜湊會建立單向權杖。也就是說，使用密碼編譯雜湊進行去識別化後，就無法還原。

以下是對 1-206-555-0123 值使用密碼編譯雜湊的去識別化作業輸出內容。這個輸出內容是雜湊值的 Base64 編碼表示法：

XlTCv8h0GwrCZK+sS0T3Z8txByqnLLkkF4+TviXfeZY=

使用加密編譯金鑰

在 Sensitive Data Protection 中，有三種加密編譯金鑰選項可與加密編譯去識別化方法搭配使用：

• Cloud KMS 包裝的加密編譯金鑰：這是最安全的加密編譯金鑰類型，可與 Sensitive Data Protection 去識別化方法搭配使用。Cloud KMS 包裝金鑰是由 128、192 或 256 位元的加密編譯金鑰組成，並已使用其他金鑰加密。您提供第一個加密編譯金鑰，然後使用儲存在 Cloud Key Management Service 的加密編譯金鑰包裝。這類金鑰會儲存在 Cloud KMS 中，以便日後重新識別。如要進一步瞭解如何建立及包裝金鑰，以便進行去識別化和重新識別，請參閱「快速入門導覽課程：將機密文字去識別化及重新識別」。

• 暫時性加密編譯金鑰：暫時性加密編譯金鑰由 Sensitive Data Protection 在去識別化時產生，然後捨棄。因此，請勿將暫時性加密編譯金鑰與任何要反轉的加密去識別化方法搭配使用。暫時性加密編譯金鑰只會保留每個 API 要求的完整性。如果您需要跨多個 API 要求維持完整性，或打算重新識別資料，請勿使用這種金鑰類型。

• 未包裝的加密編譯金鑰：未包裝的金鑰是原始 base64 編碼的 128、192 或 256 位元加密編譯金鑰，由您在向 DLP API 提出的去識別化要求中提供。您有責任妥善保管這類加密編譯金鑰，以便日後重新識別。由於這類金鑰有意外外洩的風險，因此不建議使用。這些金鑰可用於測試，但對於實際工作環境工作負載，建議改用 Cloud KMS 包裝的加密編譯金鑰。

如要進一步瞭解使用加密編譯金鑰時可用的選項，請參閱 DLP API 參考資料中的 CryptoKey。

使用情境調整

根據預設，無論輸出權杖是單向或雙向，去識別化的所有加密編譯轉換方法都具有參照完整性。也就是說，如果使用相同的加密編譯金鑰，輸入值一律會轉換為相同的加密值。如果可能出現重複的資料或資料模式，重新識別的風險就會增加。如要讓相同的輸入值一律轉換為不同的加密值，您可以指定專屬的內容調整項。

轉換表格型資料時，您需要指定情境調整項 (在 DLP API 中簡稱為 context)，因為調整項實際上是指向資料欄 (例如 ID) 的指標。Sensitive Data Protection 會使用情境調整項指定的欄位值，加密輸入值。為確保加密值一律為不重複值，請為包含專屬 ID 的調整項指定資料欄。

請參考以下簡單範例。下表顯示多份病歷，其中部分病歷包含重複的病患 ID。

如果您指示 Sensitive Data Protection 去識別化表格中的病患 ID，系統預設會將重複的病患 ID 去識別化為相同的值，如下表所示。舉例來說，病患 ID「43789」的兩個例項都會去識別化為「47222」。(patient_id 欄顯示使用 FPE-FFX 進行假名化後的權杖值，不含代理註解。詳情請參閱「格式保留加密」一節。

這表示參照完整性的範圍涵蓋整個資料集。

如要縮小範圍，避免發生這種情況，請指定情境調整。您可以將任何資料欄指定為情境調整，但為確保每個去識別化值都是不重複的，請指定每個值都是不重複的資料欄。

假設您想查看同一位病患是否出現在每個 icd10_codes 值中，但不想查看同一位病患是否出現在不同的 icd10_codes 值中。為此，您需要將 icd10_codes 欄指定為情境調整。

使用 icd10_codes 欄做為情境調整項，對 patient_id 欄進行去識別化處理後，資料表如下：

請注意，第四和第五個去識別化 patient_id 值 (29460) 相同，因為原始 patient_id 值相同，且兩個資料列的 icd10_codes 值也相同。由於您需要在 icd10_codes 值的範圍內，使用一致的病患 ID 執行分析，因此這項行為正是您需要的。

如要完全切斷 patient_id 值和 icd10_codes 值之間的參照完整性，可以改用 record_id 欄做為情境調整項：

請注意，資料表中每個去識別化的 patient_id 值現在都是不重複的值。

如要瞭解如何在 DLP API 中使用內容調整，請參閱下列轉換方法參考主題中 context 的用法：

• 格式保留加密：CryptoReplaceFfxFpeConfig
• 使用 AES-SIV 的確定性加密： CryptoDeterministicConfig
• 日期偏移： DateShiftConfig

後續步驟

• 完成端對端範例，瞭解如何建立包裝金鑰、將內容權杖化，以及重新識別權杖化內容。

• 查看程式碼範例，瞭解如何將機密資料權杖化。

• 瞭解如何使用 DLP API 將資料去識別化。