BigQuery 的策略标签长期承担着敏感列保护任务，例如限制用户读取邮箱、证件号和银行卡号。随着数据跨项目、跨区域扩张，区域级分类体系开始面临重复维护、灾备同步和集中治理等问题。处于预览阶段的 IAM 数据治理标签建立在 Resource Manager 标签体系之上，把全局数据分类与区域安全策略拆开管理，为 BigQuery 列级安全提供了新的实现路径。
从区域策略标签转向全局分类
数据治理标签是一种特殊的 Resource Manager 标签。创建标签键时，将 purpose 设置为 DATA_GOVERNANCE，便可将其用于 BigQuery 列级安全。
它带来几个关键变化：
- 标签全局可用：可以在组织或治理项目中定义一次
data_class:pii，然后用于不同项目和区域的 BigQuery 列。 - 策略仍按区域执行：数据策略必须创建在 BigQuery 表所在区域。全局标签解决分类复用问题，区域策略负责实际授权。
- 支持灾备场景：标签及相关数据策略会复制到次要区域，使安全配置能随区域故障转移延续。
- 最多五级层次结构：可以表达
PII > Private > Email一类逐级细化的分类。 - 分类与执行解耦：团队可以先给数据打标签，完成资产盘点；只有创建数据策略后，标签才开始影响访问结果。
这种分层尤其适合职责分离：治理团队维护标签树，数据团队把标签绑定到列，安全团队负责区域数据策略和授权主体。
三层权限模型不能混为一谈
列级安全并不替代表级权限。一次查询至少涉及两层判断：
- 用户是否拥有表的基础访问权限，例如
roles/bigquery.dataViewer。 - 用户是否匹配该列标签对应的数据策略。
数据策略可以允许主体读取原始值，也可以返回 SHA-256 等掩码结果。如果查询者拥有表权限，却没有匹配敏感列的数据策略，授权引擎会拒绝其访问受保护的列。
还要注意一个容易造成配置遗漏的边界：标签键和值是全局资源，而数据策略是区域资源。如果同一分类被用于 us-east1 和 europe-west1 的表，就需要确认两个区域都有对应策略。
可以这样实践：创建标签、绑定列并配置策略
下面是一套可以改造的最小流程。运行前请先登录 gcloud，并将项目、数据集、表名、区域和授权主体替换为真实值。由于功能处于预览阶段，还应先确认目标项目已经启用所需 API，并拥有创建 Resource Manager 标签及 BigQuery 数据策略的权限。
1. 创建数据治理标签树
export GOVERNANCE_PROJECT="my-governance-project"
gcloud resource-manager tags keys create data_class \
--parent="projects/${GOVERNANCE_PROJECT}" \
--purpose=DATA_GOVERNANCE
gcloud resource-manager tags values create pii \
--parent="${GOVERNANCE_PROJECT}/data_class"
gcloud resource-manager tags values create private \
--parent="${GOVERNANCE_PROJECT}/data_class/pii"
gcloud resource-manager tags values create email \
--parent="${GOVERNANCE_PROJECT}/data_class/private"
生产环境中不要只追求层级深度。标签树需要稳定、可解释，并能映射到真实的授权规则。若 email 与 phone_number 最终使用完全相同的策略，把它们都归到 private 可能更容易维护。
2. 用 JSON 批量绑定现有列
先导出现有表结构，避免手写 schema 时遗漏字段模式、描述或嵌套结构：
export DATA_PROJECT="my-data-project"
export DATASET="customer_data"
export TABLE="customers"
bq show --schema --format=prettyjson \
"${DATA_PROJECT}:${DATASET}.${TABLE}" > schema.json
在 schema.json 中为敏感字段增加 dataGovernanceTagsInfo。下面展示了核心结构；更新真实表时，应保留导出文件中的其他字段：
[
{
"name": "user_email",
"type": "STRING",
"mode": "NULLABLE",
"dataGovernanceTagsInfo": {
"dataGovernanceTags": {
"my-governance-project/data_class": "email"
}
}
},
{
"name": "phone_number",
"type": "STRING",
"mode": "NULLABLE",
"dataGovernanceTagsInfo": {
"dataGovernanceTags": {
"my-governance-project/data_class": "private"
}
}
}
]
应用更新：
bq update \
--project_id="${DATA_PROJECT}" \
--schema=schema.json \
"${DATASET}.${TABLE}"
单列变更也可以用 SQL 完成，适合纳入数据库迁移脚本：
ALTER TABLE `my-data-project.customer_data.customers`
ALTER COLUMN phone_number
SET OPTIONS (
data_governance_tags = [
('my-governance-project/data_class', 'private')
]
);
移除标签时，将选项设为空数组：
ALTER TABLE `my-data-project.customer_data.customers`
ALTER COLUMN phone_number
SET OPTIONS (data_governance_tags = []);
3. 创建区域数据策略
下面的请求为带有 pii 标签的列创建 SHA-256 掩码策略。将 my-data-project、us-east1、标签键以及群组地址替换为实际配置：
export DATA_PROJECT="my-data-project"
export LOCATION="us-east1"
export GOVERNANCE_TAG_KEY="my-governance-project/data_class"
export MASKED_GROUP="grp-sales@corp.com"
curl --fail-with-body --request POST \
"https://bigquerydatapolicy.googleapis.com/v2/projects/${DATA_PROJECT}/locations/${LOCATION}/dataPolicies" \
--header "Authorization: Bearer $(gcloud auth print-access-token)" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data "{
\"dataPolicy\": {
\"dataPolicyType\": \"DATA_MASKING_POLICY\",
\"dataMaskingPolicy\": {
\"predefinedExpression\": \"SHA256\"
},
\"grantees\": [
\"principalSet://goog/group/${MASKED_GROUP}\"
],
\"dataGovernanceTag\": {
\"key\": \"${GOVERNANCE_TAG_KEY}\",
\"value\": \"pii\"
}
},
\"dataPolicyId\": \"masking-policy-data-class-pii\"
}"
原始数据访问应使用独立的 RAW_DATA_ACCESS_POLICY，并只授予确实需要明文数据的主体。不要把广泛业务群组同时放进掩码策略和原始访问策略，否则掩码层可能失去实际意义。
用 INFORMATION_SCHEMA 做持续审计
标签绑定完成后，可以从 INFORMATION_SCHEMA.COLUMNS 检查列级分类：
SELECT
table_name,
column_name,
data_governance_tags[SAFE_OFFSET(0)].key AS tag_key,
data_governance_tags[SAFE_OFFSET(0)].value AS tag_value
FROM `my-data-project.customer_data.INFORMATION_SCHEMA.COLUMNS`
WHERE table_name = 'customers'
ORDER BY ordinal_position;
这条查询适合接入 CI 或定期审计任务。例如，维护一份必须分类的字段名称规则，对 email、government_id、card_number 等字段检查标签是否为空。需要留意的是，当前材料提到的后续方向包括单列多标签和基于标签组合定义策略，因此现阶段不宜提前依赖这些尚未提供的能力。
上线前的检查清单
采用 IAM 数据治理标签时，可以按下面的顺序收敛风险：
- 确认预览功能是否满足组织的稳定性与合规要求。
- 先设计标签语义和所有权，再批量修改表结构。
- 为每个数据区域建立策略清单，避免只有标签、没有区域策略。
- 分开维护掩码访问与原始访问主体，并落实最小权限。
- 使用测试账号验证三种结果：无权访问、看到掩码、看到原文。
- 在故障转移演练中验证次要区域的策略状态，而不是只相信配置已经复制。
- 持续查询
INFORMATION_SCHEMA，发现未分类的新增敏感列。
IAM 数据治理标签的核心价值，不只是换一种方式给列贴标签，而是让分类体系具备全局作用域，同时保留区域化的安全执行。对跨区域 BigQuery 环境而言，这能减少重复分类工作；代价是团队必须更清楚地区分标签、数据策略和基础 IAM 权限，并把三者都纳入审计与变更流程。