資料遮蓋簡介

注意：如果預留項目是以特定 BigQuery 版本建立，可能無法使用這項功能。如要進一步瞭解各版本啟用的功能，請參閱「BigQuery 版本簡介」。

BigQuery 支援資料欄層級的資料遮蓋功能，您能針對不同使用者群組，選擇性地掩蓋特定資料欄的資料，但這些使用者還是能正常使用該資料欄。資料遮罩功能是以資料欄層級存取控管為基礎，因此請先熟悉該功能，再繼續操作。

將資料遮蓋與資料欄層級存取控管功能搭配使用時，您可以根據不同使用者群組的需求，設定資料欄資料的存取權範圍，從完整存取權到無存取權。舉例來說，對於稅號資料，您可能想授予會計群組完整存取權、分析師群組遮罩存取權，以及銷售群組無存取權。

本文說明如何使用政策標記遮蓋資料。或者，您也可以使用資料治理標記，這是用於資料遮蓋和資料欄層級存取控管的 Resource Manager 標記。

注意：您必須保持啟用 datacatalog.googleapis.com API，才能建立及管理用於資料遮蓋和資料欄層級安全性的 Data Catalog 政策標記和分類。雖然 Data Catalog 中繼資料搜尋和目錄功能已淘汰，並轉換至 Knowledge Catalog，但 Policy Tag Manager 服務 (分類和政策標記)、其 datacatalog.googleapis.com API 方法和稽核記錄，以及 roles/datacatalog Identity and Access Management (IAM) 角色並未淘汰。

優點

資料遮蓋功能有下列優點：

• 簡化資料共用程序。您可以遮蓋機密資料欄，以便與更多人共用資料表。
• 與資料欄層級存取控管不同，您不必排除使用者無法存取的資料欄，即可修改現有查詢。設定資料遮蓋功能後，現有查詢會根據使用者獲派的角色，自動遮蓋資料欄資料。
• 您可以大規模套用資料存取政策。您可以編寫資料政策、將其與政策標記建立關聯，並將政策標記套用至任意數量的資料欄。
• 可啟用屬性式存取控管。附加至資料欄的政策標記會提供情境資料存取權，這項權限由資料政策和與該政策標記相關聯的主體決定。

資料遮蓋工作流程

如要遮蓋資料，您可以建立分類和政策標記，然後在政策標記上設定資料政策。或者，您也可以採取下列任一做法：

• 直接在資料欄上設定資料政策。將資料遮蓋規則對應至資料，不必處理政策標記或建立額外分類。
• 使用資料治理標記。使用資料治理標記 (預先發布版) 進行資料欄層級存取控管和資料遮蓋。

直接在資料欄設定資料政策

您可以直接在資料欄設定動態資料遮蓋。如要這樣做，請按照下列步驟操作：

1. 建立資料政策。

2. 將資料政策指派給資料欄。

使用政策標記遮蓋資料

圖 1 顯示設定資料遮蓋的工作流程：

圖 1. 資料遮蓋元件。

請按照下列步驟設定資料遮罩：

1. 設定分類和一或多個政策標記。

2. 為政策標記設定資料政策。資料政策會將資料遮蓋規則和一或多個主體 (代表使用者或群組) 對應至政策標記。

   使用 Google Cloud 控制台建立資料政策時，您可以在一個步驟中建立資料遮蓋規則並指定主體。使用 BigQuery Data Policy API 建立資料政策時，您可以在一個步驟中建立資料政策和資料遮蓋規則，並在第二個步驟中指定資料政策的主體。

3. 將政策標記指派給 BigQuery 資料表中的資料欄，即可套用資料政策。

4. 將應有遮蓋資料存取權的使用者指派給 BigQuery 遮蓋讀取者角色。最佳做法是在資料政策層級指派 BigQuery 遮蓋資料讀取者角色。在專案層級或更高層級指派角色，會授予使用者專案下所有資料政策的使用者授權，這可能會導致權限過多而引發問題。

   與資料政策相關聯的政策標記，也可用於資料欄層級存取控管。在這種情況下，政策標記也會與一或多個主體建立關聯，這些主體會獲得 Data Catalog 精細讀取者角色。這樣一來，這些主體就能存取原始、未遮蓋的資料欄資料。

圖 2 顯示資料欄層級存取控管和資料遮蓋如何搭配運作：

圖 2. 資料遮蓋元件。

如要進一步瞭解角色互動，請參閱「遮罩讀取者和精細讀取者角色的互動方式」。如要進一步瞭解政策標記沿用，請參閱「角色和政策標記階層」。

資料遮蓋規則

使用資料遮蓋功能時，系統會根據執行查詢的使用者角色，在查詢執行階段將資料遮蓋規則套用至資料欄。遮罩作業的優先順序高於查詢中的任何其他作業。資料遮蓋規則會決定要對資料欄資料套用哪種資料遮蓋類型。

您可以使用下列資料遮蓋規則：

• 自訂遮蓋常式。對資料欄套用使用者定義函式 (UDF) 後，傳回資料欄的值。必須具備常式權限，才能管理遮蓋規則。這項規則支援所有 BigQuery 資料類型，但 STRUCT 資料類型除外。不過，對 STRING 和 BYTES 以外資料類型的支援有限。輸出內容取決於定義的函式。

  如要進一步瞭解如何為自訂遮蓋常式建立 UDF，請參閱「建立自訂遮蓋常式」。

• 日期年份遮罩。將資料欄的值截斷至年份，並將值的所有非年份部分設為年初，然後傳回該值。這項規則只能用於採用 DATE、DATETIME 和 TIMESTAMP 資料類型的資料欄。例如：

  類型	原始	遮罩
  DATE	2030-07-17	2030-01-01
  DATETIME	2030-07-17T01:45:06	2030-01-01T00:00:00
  TIMESTAMP	2030-07-17 01:45:06	2030-01-01 00:00:00

  注意：系統會根據世界標準時間時區截斷資料。如要變更，請使用 @@time_zone 系統變數調整預設時區。

• 預設遮蓋值。根據資料欄的資料類型，傳回該資料欄的預設遮蓋值。如要隱藏資料欄的值，但顯示資料類型，請使用這個方法。如果將這項資料遮蓋規則套用至資料欄，則對於具備遮蓋讀取者存取權的使用者，該資料欄在查詢 JOIN 作業中的實用性會降低。這是因為預設值不夠獨特，在彙整資料表時無法發揮作用。

  下表列出各資料類型的預設遮蓋值：

  資料類型	預設遮蓋值
  STRING	""
  BYTES	b''
  INTEGER	0
  FLOAT	0.0
  NUMERIC	0
  BOOLEAN	FALSE
  TIMESTAMP	1970-01-01 00:00:00 UTC
  DATE	1970-01-01
  TIME	00:00:00
  DATETIME	1970-01-01T00:00:00
  GEOGRAPHY	POINT(0 0)
  BIGNUMERIC	0
  ARRAY	[]
  STRUCT	NOT_APPLICABLE 政策標記無法套用至使用 STRUCT 資料類型的資料欄，但可與這類資料欄的葉欄位建立關聯。
  JSON	null

• 電子郵件遮罩。將有效電子郵件地址的使用者名稱替換為 XXXXX，然後傳回資料欄的值。如果資料欄的值不是有效的電子郵件地址，則會傳回經過 SHA-256 雜湊函式處理後的資料欄值。這項規則只能用於採用 STRING 資料類型的資料欄。例如：

  原始	遮罩
  [e-mail]	[e-mail]
  randomtext	jQHDyQuj7vJcveEe59ygb3Zcvj0B5FJINBzgM6Bypgw=
  test@[e-mail]	Qdje6MO+GLwI0u+KyRyAICDjHbLF1ImxRqaW08tY52k=

• 前四個字元。傳回資料欄值的前 4 個字元，並將字串的其餘部分替換為 XXXXX。如果資料欄的值長度等於或小於 4 個字元，則會傳回經過 SHA-256 雜湊函式處理後的資料欄值。這項規則只能用於採用 STRING 資料類型的資料欄。

• 雜湊 (SHA-256)。傳回資料欄值，該值已透過 SHA-256 雜湊函式執行。如要讓使用者在查詢的 JOIN 作業中使用這個資料欄，請使用這個選項。這項規則只能用於採用 STRING 或 BYTES 資料類型的資料欄。

  資料遮罩中使用的 SHA-256 函式會保留類型，因此傳回的雜湊值與資料欄值具有相同的資料類型。舉例來說，STRING 資料欄值的雜湊值也具有 STRING 資料類型。

  重要事項：SHA-256 是確定性雜湊函式，初始值一律會解析為相同的雜湊值。但不需要加密金鑰。這讓惡意行為人有可能使用蠻力攻擊，透過 SHA-256 演算法執行所有可能的原始值，並查看哪個值產生的雜湊與資料遮罩傳回的雜湊相符，藉此判斷原始值。

• 隨機雜湊。使用加鹽雜湊演算法傳回資料欄值的雜湊。隨機雜湊提供的安全性比標準 Hash (SHA-256) 規則更強。這項規則只能用於採用 STRING 或 BYTES 資料類型的資料欄。

  • 非確定性：系統會為每項查詢產生不重複的隨機值 (鹽)。在不同的查詢中，相同的資料欄值會產生不同的雜湊結果。這有助於防止蠻力攻擊，以及分析遮蓋資料模式。
  • 加入控制項：
    • 只有在同一個查詢中，才能對以 RANDOM_HASH 遮蓋的資料欄執行 join 作業。
    • 由於每個查詢都有隨機鹽，因此無法跨不同查詢進行彙整。
    • 只有在套用至資料欄的資料政策屬於相同 Google Cloud 專案時，才支援 join。方法是在雜湊輸入中加入資料政策的專案 ID。
  • 限制：
    • 隨機雜湊僅支援在資料欄上設定的資料政策，不支援政策標記。

• 最後四個字元。傳回資料欄值的最後 4 個字元，並將字串的其餘部分替換為 XXXXX。如果資料欄的值長度等於或小於 4 個字元，則會傳回經過 SHA-256 雜湊函式處理後的資料欄值。這項規則只能用於採用 STRING 資料類型的資料欄。

• Nullify。傳回 NULL，而非資料欄值。如要同時隱藏資料欄的值和資料類型，請使用這個選項。如果將這項資料遮蓋規則套用至資料欄，則對於具備遮蓋讀取者存取權的使用者，該資料欄在查詢 JOIN 作業中的實用性會降低。這是因為 NULL 值不夠獨特，無法在彙整資料表時發揮作用。

資料遮蓋規則比較

下表比較 BigQuery 中可用的不同資料遮蓋選項，考量其在 join 中的使用能力和相對安全性強度：

• 可彙整性：指遮蓋的資料是否可用於 SQL JOIN 作業。您可以使用遮蓋方法，為特定輸入內容產生一致的輸出內容 (在彙整範圍內具有確定性)，並保留足夠的獨特性。
• 安全性強度：表示防止原始資料去匿名化或反向工程的保護等級。這是相對比較。

遮蓋選項	類型	可加入性	安全強度
失效	預先定義	否	最高：將資料替換為 NULL。不會洩漏原始值的相關資訊。
預設遮蓋值	預先定義	否	最高：根據資料類型，以預設值取代資料。不會洩漏原始值的相關資訊。
電子郵件遮罩	預先定義	否	中度：遮蓋使用者名稱 (例如 [e-mail] 變成 [e-mail])，但網域名稱仍會顯示。未遮罩的網域可能會透露組織隸屬關係，因此可能屬於機密資訊。這項資訊可能會與其他資料建立關聯，用於去匿名化。如果網域內潛在個體的數量較少，這項遮罩技術的效果就會降低，更容易推斷出原始使用者。如果值不是有效的電子郵件地址，系統會使用 SHA-256 進行雜湊處理 (中等安全性強度)。
前四個字元	預先定義	否	低到中：傳回前 4 個字元，其餘字元則以 XXXXX 取代。如果字串長度不超過 4 個字元，則會使用 SHA-256 進行雜湊處理。如果對這些短字串使用 SHA-256，安全性會非常低，因為輸入空間有限 (1 到 4 個字元)，很容易就能計算出所有可能輸入內容的彩虹表，進而進行反向查詢。
最後四個字元	預先定義	否	低到中：傳回最後 4 個字元，並在前面加上 XXXXX 來取代其餘字元。如果字串長度不超過 4 個字元，則會使用 SHA-256 進行雜湊處理。與「前四個字元」類似，在短字串上使用 SHA-256 時，由於容易反向查詢，安全性會非常低。
日期年份遮罩	預先定義	否	中度：只顯示年份，截斷其餘日期 (例如 2030-07-17 變成 2030-01-01)。會洩漏部分資訊，且容易受到統計分析。
隨機雜湊	預先定義	是 (在同一查詢中)	高：在雜湊運算中，服務會針對每次查詢執行，使用不重複的隨機密鑰。這可有效防範預先計算資料表攻擊 (例如彩虹表)。只有在同一個查詢執行作業中，相同輸入值的輸出內容才會一致。由於每次查詢的鹽值都會變更，因此無法跨不同查詢執行彙整作業。
雜湊 (SHA-256)	預先定義	是	中等：雖然 SHA-256 在密碼學上提供強大的抗碰撞性，但在這種遮蓋情境下，容易受到各種攻擊。由於是確定性雜湊，因此容易受到彩虹表攻擊、已知明文攻擊和統計分析。您可以在這裡彙整不同查詢執行作業。
自訂遮蓋常式 – SHA-256	自訂	是	中等：安全性屬性與預先定義的 SHA-256 相同。提供強大的抗碰撞能力，但由於其確定性，容易受到彩虹表、已知明文和統計分析攻擊。
自訂遮蓋常式：加鹽 SHA-256	自訂	是	高 (取決於適當的鹽保護)：在自訂 UDF 定義中，使用一致的秘密鹽硬式編碼，安全性高於標準 SHA-256。安全性取決於鹽的保密性。必須限制 UDF 定義的存取權。BigQuery 會從執行詳細資料中遮蓋常數，有助於防止鹽值外洩。與 RANDOM_HASH 不同的是，使用這個「特定」UDF 的查詢中，鹽會保持一致，支援跨查詢彙整。
自訂遮蓋處理常式 - AEAD 加密	自訂	是	高 (取決於金鑰管理是否得當)：可提供強大的安全性和可彙整性。 重要注意事項：如要搭配使用 AEAD 加密和 KMS 包裝金鑰組，查詢使用者通常需要具備 KMS 金鑰的 cloudkms.cryptoKeyVersions.useToDecryptViaDelegation 權限。這項權限可讓使用者將包裝金鑰組用於加密和解密。因此，包裝的金鑰集必須受到保護。如果使用者有權存取包裝金鑰，就能解密 (取消遮蓋) 機密資料欄資料。

雜湊衝突和彙整完整性

SHA-256 和隨機雜湊等雜湊技術，在理論上存在雜湊衝突的風險，即兩個不同的原始值產生相同的雜湊值。如果使用這些規則遮蓋資料欄，並在 JOIN 作業中使用，衝突可能會導致查詢結果中的資料關聯不正確 (錯誤比對)。

不過，對於任何實際資料集，SHA-256 衝突的統計機率幾乎可以忽略不計。因此，使用者可以高度信賴雜湊遮罩規則，確保彙整資料的完整性。

資料遮蓋規則階層

一個政策標記最多可設定九項資料政策，每項政策都可連結不同的資料遮蓋規則。其中一項政策會保留給資料欄層級存取控管設定。這樣一來，系統就能根據使用者所屬的群組，將多項資料政策套用至使用者查詢中的資料欄。在這種情況下，BigQuery 會根據下列階層，選擇要套用哪項資料遮蓋規則：

1. 自訂遮蓋處理常式
2. 隨機雜湊
3. 雜湊 (SHA-256)
4. 電子郵件遮罩
5. 最後四個字元
6. 前四個字元
7. 日期年份遮罩
8. 預設遮蓋值
9. 失效

舉例來說，使用者 A 同時是員工和會計群組的成員。使用者 A 執行查詢，其中包含已套用 confidential 政策標記的 sales_total 欄位。confidential 政策標記有兩項相關聯的資料政策：一項以員工角色為主體，並套用無效資料遮蓋規則；另一項以會計角色為主體，並套用雜湊 (SHA-256) 資料遮蓋規則。在這種情況下，雜湊 (SHA-256) 資料遮蓋規則的優先順序高於無效資料遮蓋規則，因此雜湊 (SHA-256) 規則會套用至使用者 A 查詢中的 sales_total 欄位值。

圖 3 說明瞭這種情況：

圖 3：資料遮蓋規則優先順序。

角色和權限

管理分類和政策標記的角色

您必須具備 Data Catalog 政策標記管理員角色，才能建立及管理分類和政策標記。

角色/ID	權限	說明
Data Catalog 政策標記管理員 (datacatalog.categoryAdmin)	datacatalog.categories.getIamPolicy datacatalog.categories.setIamPolicy datacatalog.taxonomies.create datacatalog.taxonomies.delete datacatalog.taxonomies.get datacatalog.taxonomies.getIamPolicy datacatalog.taxonomies.list datacatalog.taxonomies.setIamPolicy datacatalog.taxonomies.update resourcemanager.projects.get resourcemanager.projects.list	在專案層級套用。 這個角色可授予下列權限： 建立、讀取、更新及刪除分類和政策標記。 取得及設定政策標記的 IAM 政策。

建立及管理資料政策的角色

您必須具備下列其中一個 BigQuery 角色，才能建立及管理資料政策：

角色/ID	權限	說明
BigQuery 資料政策管理員 (bigquerydatapolicy.admin) BigQuery 管理員 (bigquery.admin) BigQuery 資料擁有者 (bigquery.dataOwner)	bigquery.dataPolicies.create bigquery.dataPolicies.delete bigquery.dataPolicies.get bigquery.dataPolicies.getIamPolicy bigquery.dataPolicies.list bigquery.dataPolicies.setIamPolicy bigquery.dataPolicies.update	bigquery.dataPolicies.create 和 bigquery.dataPolicies.list 權限適用於專案層級。其他權限則適用於資料政策層級。 這個角色可執行下列操作： 建立、讀取、更新及刪除資料政策。 取得及設定資料政策的身分與存取權管理政策。

您也需要 datacatalog.taxonomies.get 權限，可從多個 Data Catalog 預先定義角色取得。

可將政策標記附加至資料欄的角色

您必須具備 datacatalog.taxonomies.get 和 bigquery.tables.setCategory 權限，才能將政策標記附加至資料欄。datacatalog.taxonomies.get 包含在 Data Catalog 政策標記管理員和檢視者角色中。BigQuery 管理員 (roles/bigquery.admin) 和 BigQuery 資料擁有者 (roles/bigquery.dataOwner) 角色包含 bigquery.tables.setCategory。

查詢遮蓋資料的角色

您必須具備 BigQuery 遮蓋資料讀取者角色，才能查詢已套用資料遮蓋的資料欄。

角色/ID	權限	說明
經過遮蓋的讀取者 (bigquerydatapolicy.maskedReader)	bigquery.dataPolicies.maskedGet	這個角色只能授予 Resource Manager 資源 (專案、資料夾和組織)。 這個角色可授予權限，查看與資料政策相關聯的資料欄遮蓋資料。 此外，使用者必須具備適當權限，才能查詢資料表。詳情請參閱「必要權限」。

「遮蓋資料讀取者」和「精細讀取者」角色的互動方式

資料遮罩是以資料欄層級存取控管為基礎。對於特定資料欄，有些使用者可能具備 BigQuery 遮蓋讀取者角色，可讀取遮蓋資料；有些使用者可能具備 Data Catalog 精細讀取者角色，可讀取未遮蓋資料；有些使用者可能同時具備這兩種角色，有些使用者則不具備任何角色。這些角色的互動方式如下：

• 同時具備「精細讀取者」和「遮蓋讀取者」角色的使用者：使用者看到的內容取決於各角色在政策標記階層中的授予位置。詳情請參閱「政策標記階層中的授權沿用」。
• 具備「精細讀取者」角色的使用者：可查看未遮蓋 (未模糊處理) 的資料欄資料。
• 具備「遮蓋資料讀取者」角色的使用者：可查看遮蓋 (模糊處理) 的資料欄資料。
• 不具備上述任一角色的使用者：權限遭拒。

如果資料表的資料欄受到保護，或受到保護且遮蓋，使用者必須是適當群組的成員，才能對該資料表執行 SELECT * FROM 陳述式，這樣他們才能獲得所有這些資料欄的遮蓋讀取者或精細讀取者角色。

如果使用者未獲派這些角色，則必須在 SELECT 陳述式中指定他們有權存取的資料欄，或使用 SELECT * EXCEPT (restricted_columns) FROM 排除受保護或遮蓋的資料欄。

政策標記階層中的授權繼承

系統會從與資料欄相關聯的政策標記開始評估角色，然後在分類的每個遞增層級檢查，直到確定使用者具備適當權限，或達到政策標記階層的頂端。

舉例來說，請參考圖 4 所示的政策標記和資料政策設定：

圖 4：政策標記和資料政策設定。

假設您有一個資料表資料欄，已加上 Financial 政策標記，而某位使用者同時是 [e-mail] 和 [e-mail] 群組的成員。當這位使用者執行包含已加上註解資料欄的查詢時，系統會根據政策標記分類中定義的階層，決定其存取權。由於使用者透過 Financial 政策標記獲得 Data Catalog 精細讀取者角色，因此查詢會傳回未遮蓋的資料欄資料。

如果另一個使用者僅具備 [e-mail] 角色，並執行包含已註解資料欄的查詢，則查詢會傳回使用 SHA-256 演算法雜湊處理的資料欄資料，因為使用者已透過 Confidential 政策標記 (Financial 政策標記的父項) 取得 BigQuery 遮蓋讀取者角色。

如果使用者不屬於這兩個角色，嘗試查詢加上註解的資料欄時，就會收到存取遭拒錯誤。

與上述情境相反，請參考圖 5 所示的政策標記和資料政策設定：

圖 5. 政策標記和資料政策設定。

您的情況與圖 4 相同，但使用者在政策標記階層的較高層級獲得「精細讀取者」角色，在政策標記階層的較低層級獲得「經過遮蓋的讀取者」角色。因此，查詢會傳回這位使用者的遮蓋資料欄資料。即使使用者在標記階層中獲得更上層的精細讀取者角色，也會發生這種情況，因為服務在政策標記階層中向上移動時，會使用遇到的第一個指派角色來檢查使用者存取權。

如要建立單一資料政策，並套用至政策標記階層的多個層級，可以將資料政策設定在代表最高階層層級的政策標記上。舉例來說，假設分類結構如下：

• 政策標記 1
  • 政策標記 1a
    • 政策標記 1ai
  • 政策標記 1b
    • 政策標記 1bi
    • 政策標記 1bii

如要將資料政策套用至所有政策標記，請在政策標記 1 設定資料政策。如要將資料政策套用至政策標記 1b 及其子項，請在政策標記 1b 設定資料政策。

資料遮蓋功能與不相容的功能

當您使用與資料遮蓋不相容的 BigQuery 功能時，服務會將遮蓋的資料欄視為受保護的資料欄，且僅授予具備 Data Catalog 精細讀取者角色的使用者存取權。

舉例來說，請參考圖 6 所示的政策標記和資料政策設定：

圖 6：政策標記和資料政策設定。

假設您有一個資料表資料欄，並加上 Financial 政策標記，而使用者是 [e-mail] 群組的成員。如果該使用者嘗試透過不相容的功能存取已加上註解的資料欄，就會收到存取遭拒錯誤。這是因為他們透過 Financial 政策標記獲得 BigQuery 遮蓋讀取者角色，但在這種情況下，他們必須具備 Data Catalog 精細讀取者角色。由於服務已為使用者決定適用的角色，因此不會繼續檢查政策標記階層中更上層的其他權限。

資料遮蓋範例和輸出內容

如要瞭解標記、主體和角色如何搭配運作，請參考以下範例。

在 example.com，基本存取權是透過 [e-mail] 群組授予。所有需要定期存取 BigQuery 資料的員工都是這個群組的成員，該群組已獲派從資料表讀取資料所需的所有權限，以及 BigQuery 遮蓋讀取者角色。

員工會被指派到其他群組，以便存取工作所需的受保護或遮罩資料欄。這些額外群組的所有成員也都是 [e-mail] 的成員。您可以在圖 7 中查看這些群組與適當角色的關聯：

圖 7.example.com 的政策標記和資料政策。

接著，政策標記會與資料表資料欄建立關聯，如圖 8 所示：

圖 8.與資料表資料欄相關聯的 Example.com 政策標記。

根據與資料欄相關聯的標記，執行 SELECT * FROM Accounts; 會為不同群組產生下列結果：

• [e-mail]：這個群組已獲得 PII 和 Confidential 政策標記的 BigQuery 遮蓋讀取者角色。系統會傳回下列結果：

  SSN	Priority	生命週期價值	建立日期	電子郵件
  空值	""	0	1983 年 3 月 8 日	空值
  空值	""	0	2009 年 12 月 29 日	空值
  空值	""	0	2021 年 7 月 14 日	空值
  空值	""	0	1997 年 5 月 5 日	空值

• [e-mail]：這個群組已獲得 SSN 政策標記的 Data Catalog 精細讀取者角色。系統會傳回下列結果：

  SSN	Priority	生命週期價值	建立日期	NULL
  123-45-6789	""	0	1983 年 3 月 8 日	空值
  234-56-7891	""	0	2009 年 12 月 29 日	空值
  345-67-8912	""	0	2021 年 7 月 14 日	空值
  456-78-9123	""	0	1997 年 5 月 5 日	空值

• [e-mail]：這個群組已獲得 Confidential 政策標記的 Data Catalog 精細讀取者角色。系統會傳回下列結果：

  SSN	Priority	生命週期價值	建立日期	電子郵件
  空值	高	90,000	1983 年 3 月 8 日	空值
  空值	高	84,875	2009 年 12 月 29 日	空值
  空值	中	38,000	2021 年 7 月 14 日	空值
  空值	低	245	1997 年 5 月 5 日	空值

• [e-mail]：這個群組已獲得 Financial 政策標記的 BigQuery 遮蓋讀取者角色。系統會傳回下列結果：

  SSN	Priority	生命週期價值	建立日期	電子郵件
  空值	""	Zmy9vydG5q=	1983 年 3 月 8 日	空值
  空值	""	GhwTwq6Ynm=	2009 年 12 月 29 日	空值
  空值	""	B6y7dsgaT9=	2021 年 7 月 14 日	空值
  空值	""	Uh02hnR1sg=	1997 年 5 月 5 日	空值

• 所有其他使用者：不屬於上述任何群組的使用者，會收到存取遭拒錯誤，因為他們未獲派 Data Catalog 精細讀取者或 BigQuery 遮蓋讀取者角色。如要查詢 Accounts 資料表，他們必須在 SELECT * EXCEPT (restricted_columns) FROM Accounts 中僅指定有權存取的資料欄，以排除受保護或遮蓋的資料欄。

費用注意事項

資料遮蓋可能會間接影響處理的位元組數，進而影響查詢費用。如果使用者查詢的資料欄已透過「Nullify」或「Default Masking Value」規則遮蓋，系統就不會掃描該資料欄，因此處理的位元組數會減少。

規定與限制

以下各節說明資料遮蓋適用的限制和限制類別。

資料政策管理

• 如果預留項目是以特定 BigQuery 版本建立，則可能無法使用這項功能。如要進一步瞭解各版本啟用的功能，請參閱「BigQuery 版本簡介」。
• 每個政策標記最多可建立九項資料政策。其中一項政策會保留給資料欄層級存取控管設定。
• 資料政策、相關聯的政策標記，以及任何使用這些政策的常式，都必須位於同一個專案中。

政策標記

• 含有政策標記分類的專案必須屬於某個組織。
• 政策標記分類的範圍限定為機構。如果將專案遷移至其他組織，專案將無法存取原始 Data Catalog 分類。過時的政策標記可能仍會顯示在結構定義編輯器的資料表資料欄中，但會從 Google Cloud 控制台的政策標記 UI 中移除，且無法套用至新資料表。如要將專案遷移至新組織，請務必執行下列操作：
  • 在目標組織的專案中，手動重新建立政策標記分類、政策標記和相關聯的資料政策。
  • 在目的地組織中，明確授予資料夾層級的 BigQuery 管理員 (roles/bigquery.admin) 和 Data Catalog 管理員 (roles/datacatalog.admin 或 roles/datacatalog.categoryAdmin) 角色。
  • 更新已遷移專案中的資料表資料欄，參照目的地組織中新建立的政策標記。

• 政策標記階層從根節點到最低層級子標記，最多只能有五個層級，如以下螢幕截圖所示：

  

設定存取控管機制

分類中的資料政策與至少一個政策標記建立關聯後，系統會自動強制執行存取控管。如要關閉存取控管功能，必須先刪除與分類法相關聯的所有資料政策。

materialized view 和重複記錄遮罩查詢

如果已有 materialized view，對相關聯基礎資料表執行的重複記錄遮蓋查詢會失敗。如要解決這個問題，請刪除 materialized view。如果基於其他原因需要 materialized view，可以在其他資料集中建立。

查詢分區資料表中的遮罩資料欄

不支援對分區或分群資料欄進行資料遮罩的查詢。

SQL 方言

不支援舊版 SQL。

自訂遮蓋處理常式

自訂遮蓋處理常式有下列限制：

• 自訂資料遮蓋功能支援所有 BigQuery 資料類型，但 STRUCT 除外，因為資料遮蓋功能只能套用至 STRUCT 資料類型的葉欄位。
• 刪除自訂遮蓋常式不會刪除使用該常式的所有資料政策。不過，使用已刪除遮蓋常式的資料政策，會留下空白的遮蓋規則。如果使用者在其他資料政策中具備「遮蓋資料讀取者」角色，且該政策具有相同標記，則可查看遮蓋資料。其他人會看到以下訊息： Permission denied. 懸置參照指向空白遮罩規則，可能會在七天後由自動化程序清除。
• 每個政策標記只能有一個自訂遮蓋處理常式。

與其他 BigQuery 功能的相容性

BigQuery API

與 tabledata.list 方法不相容。如要呼叫 tabledata.list，您必須具備這個方法傳回的所有資料欄的完整存取權。Data Catalog 精細讀取者角色可授予適當的存取權。

BigLake 資料表

相容。資料遮蓋政策會對 BigLake 資料表強制執行。

BigQuery Storage Read API

相容。BigQuery Storage Read API 會強制執行資料遮蓋政策。

BigQuery BI Engine

相容。BI Engine 會強制執行資料遮蓋政策。BI Engine 不會加速處理已啟用資料遮罩的查詢。在數據分析中使用這類查詢，可能會導致相關報表或資訊主頁的速度變慢，且費用更高。

BigQuery Omni

相容。資料遮蓋政策會對 BigQuery Omni 資料表強制執行。

定序

部分相容。您可以將 DDM 套用至對照欄，但遮蓋作業會在對照前套用。這種作業順序可能會導致非預期的結果，因為定序可能不會按照預期影響遮蓋的值 (例如，遮蓋後可能無法進行不區分大小寫的比對)。您可以使用其他解決方法，例如使用自訂遮蓋常式，在套用遮蓋函式前先將資料正規化。

複製工作

不相容。如要將資料表從來源複製到目的地，您必須具備來源資料表所有資料欄的完整存取權。Data Catalog 精細讀取者角色可授予適當的存取權。

資料匯出

相容。如果您具備 BigQuery 遮蓋讀取者角色，匯出的資料會經過遮蓋。如果您具備 Data Catalog 精細讀取者角色，匯出的資料就不會遮蓋。

資料列層級安全性

僅適用於具有非子查詢資料列存取政策的查詢。資料遮罩會套用至資料列層級安全性。舉例來說，如果資料列存取權政策套用至 location = "US"，且 location 經過遮蓋，使用者就能看到 location = "US" 的資料列，但結果中的位置欄位會經過遮蓋。

如果查詢涉及子查詢資料列存取政策，則必須具備資料列存取政策所參照資料欄的精細讀取者存取權。

在 BigQuery 中搜尋

部分相容。您可以對已套用資料遮蓋的索引或未索引資料欄，呼叫 SEARCH 函式。

對已套用資料遮罩的資料欄呼叫 SEARCH 函式時，必須使用與存取層級相容的搜尋條件。舉例來說，如果您具備「遮蓋讀取者」存取權，且資料遮蓋規則為「雜湊 (SHA-256)」，則應在 SEARCH 子句中使用雜湊值，如下所示：

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "sg172y34shw94fujaweu");

如果您具備「精細讀取者」存取權，則可在 SEARCH 子句中使用實際資料欄值，如下所示：

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "[e-mail]");

如果您具備資料欄的遮蓋讀取者存取權，且該資料欄使用的資料遮蓋規則為「無效」或「預設遮蓋值」，則搜尋功能可能不太實用。這是因為您用來做為搜尋條件的遮罩結果 (例如 NULL 或 "") 不夠獨特，無法發揮作用。

搜尋已套用資料遮蓋的索引資料欄時，只有在您具備該資料欄的 Fine-Grained Reader 存取權時，系統才會使用搜尋索引。

快照

不相容。如要建立資料表的快照，您必須具備來源資料表所有資料欄的完整存取權。Data Catalog 精細讀取者角色可授予適當的存取權。

重新命名資料表

相容。資料遮蓋不會影響資料表重新命名。

時間回溯

與時間修飾符和 SELECT 陳述式中的 FOR SYSTEM_TIME AS OF 選項相容。目前資料集結構定義的政策標記會套用至擷取的資料。

查詢快取

部分相容。BigQuery 會快取查詢結果約 24 小時，但如果在此之前資料表資料或結構定義有所變更，快取就會失效。在下列情況下，即使使用者未獲派資料欄的 Data Catalog 精細讀取者角色，仍可能在執行查詢時看到資料欄資料：

1. 使用者已獲得資料欄的 Data Catalog 精細讀取者角色。
2. 使用者執行包含受限制資料欄的查詢，系統會快取資料。
3. 在步驟 2 的 24 小時內，使用者會獲得 BigQuery 遮蓋讀取者角色，並撤銷 Data Catalog 精細讀取者角色。
4. 在步驟 2 的 24 小時內，使用者執行相同的查詢，系統會傳回快取資料。

Wildcard 資料表查詢

不相容。您必須具備完整存取權，才能存取符合萬用字元查詢的所有資料表中的所有參照資料欄。Data Catalog 精細讀取者角色會授予適當的存取權。

後續步驟

• 取得啟用資料遮蓋功能的逐步說明。