匿名化

假名化是一種去識別化技術,它以加密產生的令牌取代敏感資料值。假名化技術廣泛用於金融和醫療照護等產業,有助於降低使用中資料的風險、縮小法規遵循範圍,以及盡量減少系統中機密資料的曝光,同時保留資料的實用性和準確度。

Sensitive Data Protection 支援三種去識別化匿名化技術,並對原始機密資料值套用三種加密轉換方法之一,藉此產生權杖。然後將每個原始私密值替換為對應的代碼。 假名化有時也稱為「權杖化」或「替代替換」

假名化技術可產生單向雙向權杖。單向權杖經過不可逆的轉換,雙向權杖則可還原。由於權杖是使用對稱式加密建立,因此可用於產生新權杖的加密編譯金鑰,也能反向產生權杖。對於不需要可逆性的情況,可以使用採用安全哈希機制的單向令牌。

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

如需如何導入這些假名化方法的說明,以及更多使用 Sensitive Data Protection 的範例,請參閱「去識別化機密資料」。

Sensitive Data Protection 中支援的加密方法

Sensitive Data Protection 支援三種假名化技術,全都使用加密金鑰。可用的方法如下:

  • 使用 AES-SIV 進行確定性加密:輸入值會替換為使用 AES-SIV 加密演算法和加密金鑰加密的值,並以 Base64 編碼,然後預先加上代理註解 (如有指定)。這個方法會產生雜湊值,因此不會保留輸入值的字元集或長度。加密雜湊值可以使用原始加密金鑰和整個輸出值(包括代理註解)重新識別。 進一步瞭解使用 AES-SIV 加密技術代碼化的值格式
  • 格式保留加密:使用 FPE-FFX 加密演算法和加密編譯金鑰加密輸入值,然後視需要加上代理註解,並將輸入值替換為加密值。根據設計,輸出值會保留輸入值的字元集和長度。使用原始加密編譯金鑰和整個輸出值 (包括代理值註解),即可重新識別加密值。(如要瞭解使用這項加密方法時的重要考量,請參閱本主題後文的「保留格式的加密」一節)。
  • 加密雜湊:輸入值會替換為經過加密和雜湊處理的值,而加密和雜湊處理是使用雜湊式訊息驗證碼 (HMAC) - 安全雜湊演算法 (SHA) - 256,以加密編譯金鑰對輸入值進行處理。經過雜湊處理的轉換輸出長度一律相同,且無法重新識別。瞭解更多使用加密哈希進行標記化的值的格式

下表匯總了這些去識別化方法。表格後方會說明表格列。

使用 AES-SIV 的確定性加密 格式保留加密 加密雜湊
加密類型 AES-SIV FPE-FFX HMAC-SHA-256
支援的輸入值 長度至少要有 1 個字元,且沒有字元集限制。 長度至少 2 個字元,且必須採 ASCII 編碼。 必須是字串或整數值。
代理值註解 選填。 選填。 不適用
上下文調整 選填。 選填。 不適用
保留字元集和長度
可復原
參照完整性
  • 加密類型:去識別化轉換中使用的加密類型。
  • 支援的輸入值:輸入值的最低要求。
  • 替代註解: 使用者指定的註解,會加在加密值前面,為使用者提供背景資訊,並提供 Sensitive Data Protection 資訊,用於重新識別去識別化的值。如要重新識別非結構化資料,必須使用替代註解。使用 RecordTransformation 轉換結構化或表格資料的資料欄時,可選擇是否指定。
  • 上下文調整: 引用一個資料字段,該字段「調整」輸入值,以便將相同的輸入值去標識化為不同的輸出值。使用 RecordTransformation 轉換結構化或表格資料的資料欄時,可選擇性指定內容調整項。要瞭解更多信息,請參閱使用上下文調整
  • 保留字元集和長度:去識別化值是否由與原始值相同的字元集組成,以及去識別化值的長度是否與原始值相符。
  • 可還原:可使用加密編譯金鑰、代理值註解和任何情境調整項目重新識別。
  • 參考完整性: 參照完整性允許記錄即使在資料被單獨去識別化後,仍然保持彼此之間的關係。給定相同的 加密金鑰上下文調整,每次轉換資料表時,資料表都會被替換為相同的混淆形式,這確保了值之間的連接(以及結構化資料中的記錄之間的連接)即使在跨表的情況下也能保留。

Sensitive Data Protection 的權杖化運作方式

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

步驟 1:Sensitive Data Protection 選取要權杖化的資料。最常見的方法是使用內建或自訂的 infoType 偵測器 來匹配所需的敏感資料值。如果您正在掃描 結構化資料(例如 BigQuery 資料表),您也可以使用 記錄轉換 對整個資料列執行斷詞。

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

步驟 2:使用加密編譯金鑰,Sensitive Data Protection 會加密每個輸入值。您可以透過以下三種方式之一提供此密鑰:

  • 透過使用雲端金鑰管理服務(雲端 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 執行確定性加密去識別化作業後產生的代碼。可選的代理資訊類型已設定為 NAM_PHONE_NUMB

註解圖:使用確定性加密 (採用 AES-SIV 轉換方法) 進行代碼化的值。

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

如未指定替代註解,產生的權杖會等於轉換後的值,或註解圖中的 #4。如要重新識別非結構化資料,必須提供整個權杖,包括替代註解。轉換表格等結構化資料時,替代註解為選用項目;Sensitive Data Protection 可使用 RecordTransformation 對整欄資料執行去識別化和重新識別化作業,無須替代註解。

格式保留加密

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

與本主題所述的其他代碼化方法不同,輸出代理值與輸入值長度相同,且不會使用 Base64 編碼。您定義加密值所用的字元集 (或「字母表」)。您可以透過三種方式指定字母,供 Sensitive Data Protection 用於輸出值:

  • 請使用四個列舉值之一,代表四個最常見的字元集/字母。
  • 使用基數值,指定字母的大小。指定最小基數值為 2 將會得到一個僅由 01 組成的字母表。指定 95 的最大基數值會產生字母,其中包含所有數字字元、大寫英文字母、小寫英文字母和符號字元。
  • 透過列出要使用的確切字元來建立字母表。舉例來說,指定 1234567890-* 會產生僅由數字、連字號和星號組成的代理值。

下表列出四種常見的字元集,並分別提供列舉值 (FfxCommonNativeAlphabet)、基底值和字元集清單。最後一列會列出完整字元集,對應於最大基數值。

字母/字元集名稱 Radix 角色列表
NUMERIC 10 0123456789
HEXADECIMAL 16 0123456789ABCDEF
UPPER_CASE_ALPHA_NUMERIC 36 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
ALPHA_NUMERIC 62 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
- 95 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz~`!@#$%^&*()_-+={[}]|\:;"'<,>.?/

假設已指定代理值 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。如要重新識別非結構化資料,必須提供整個權杖,包括替代註解。在轉換結構化資料(例如表格)時,代理註解是可選的;敏感資料保護可以使用 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),因為該調整實際上是指向資料列(例如識別碼)的指標。 Sensitive Data Protection 會使用內容調整項指定欄位中的值,加密輸入值。為確保加密值一律為不重複的值,請指定包含不重複 ID 的調整項資料欄。

請看這個簡單的例子。下表顯示多筆病歷,其中有些包含重複的病患 ID。

record_id patient_id icd10_code
5437 43789 E11.9
5438 43671 M25.531
5439 43789 N39.0、I25.710
5440 43766 I10
5441 43766 I10
5442 42989 R07.81
5443 43098 I50.1、R55
... ... ...

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

record_id patient_id icd10_codes
5437 47222 E11.9
5438 82160 M25.531
5439 47222 N39.0、I25.710
5440 04452 I10
5441 04452 I10
5442 47826 R07.81
5443 52428 I50.1、R55
... ... ...

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

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

假設您想查看同一位病患是否出現在每個 icd10_codes 值中,但不想查看同一位病患是否出現在不同 icd10_codes 值中,如要這麼做,請將「icd10_codes」欄指定為情境修正項。

這是使用 icd10_codes 資料欄做為脈絡調整項,將 patient_id 資料欄去識別化後的資料表:

record_id patient_id icd10_codes
5437 18954 E11.9
5438 33068 M25.531
5439 76368 N39.0、I25.710
5440 29460 I10
5441 29460 I10
5442 23877 R07.81
5443 96129 I50.1、R55
... ... ...

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

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

record_id patient_id icd10_code
5437 15826 E11.9
5438 61722 M25.531
5439 34424 N39.0、I25.710
5440 02875 I10
5441 52549 I10
5442 17945 R07.81
5443 19030 I50.1、R55
... ... ...

請注意,表格中每個去識別化的 patient_id 值現在都是唯一的。

如要瞭解如何在 DLP API 中使用內容微調,請注意下列轉換方法參考主題中 context 的用法:

後續步驟