行筛选器和列掩码策略评估和运行时行为

本页介绍在查询时如何评估 ABAC 策略，包括：

• 如何处理多个策略之间的冲突
• 列掩码类型转换的工作原理
• 删除策略所依赖的标记或函数时，哪些安全措施会阻止数据泄露

策略评估和强制实施

当用户查询表时，ABAC 评估分为两个阶段：Unity 目录中的策略评估以及 Databricks Runtime 中的策略强制实施。

不同的用户可能会看到来自同一查询的不同结果，因为策略评估取决于用户的身份、组成员身份以及他们访问的数据上的标记。 对组成员身份或标记分配的更改在查询时动态更改有效策略。

策略评估（Unity Catalog）

Unity Catalog 使用可保护对象的元数据（例如受管标签分配）以及发起查询的用户的身份和群组成员身份，执行以下步骤：

1. 标识其范围涵盖查询表的所有策略。
2. 对于其中每个策略，检查查询用户是否在 TO 列表中而不是 EXCEPT 列表中。
3. 对于每个策略，根据查询对象的标记（包括继承的标记）来评估表和列条件。 列条件必须至少匹配一列。
4. 如果策略适用，请确定有效的行筛选器或列掩码，并将其作为表元数据的一部分发送到 Databricks Runtime。

策略强制实施 （Databricks Runtime）

Databricks Runtime 查询规划器将有效的行筛选器或列掩码转换为表扫描顶部的安全视图，这些扫描在查询执行过程中强制筛选和屏蔽。 这是用于 表级行筛选器和列掩码的相同强制机制。

故障关闭设计

ABAC 遵循失败关闭模式，如果无法验证安全性，Azure Databricks默认会拒绝访问。 Azure Databricks仅在能够安全地执行所有适用策略时才允许访问受ABAC保护的表。 这适用于不受支持的计算版本、基础表数据的特定操作，以及删除策略依赖项（标记或函数）的情况。

不支持的计算版本

ABAC 策略需要 Databricks Runtime 16.4 或更高版本，或无服务器计算。 如果用户尝试从不支持的版本访问 ABAC 保护的表，查询将失败（拒绝访问），以防止未受保护的数据泄露。

在专用访问模式下，Azure Databricks将控制的实施委托给无服务器计算，以确保应用细粒度访问控制。 若要允许用户在较旧的运行时访问这些表，必须显式将其从策略中免除。

不支持对受保护数据的操作

某些操作与行筛选器或列掩码不兼容。 这些操作失败，而不是绕过执行。 若要执行这些操作，主体必须列在适用于该表的每个 ABAC 策略的 EXCEPT 子句中。 豁免主体不受策略约束，因此Azure Databricks不需要强制执行该策略，可以安全地允许此操作。

需要免除执行主体的操作包括管道刷新、备份进程和管理工作流，如下所示：

• 在运行 Databricks Runtime 版本低于 16.4 的计算资源上访问 ABAC（基于属性的访问控制）保护的表。
• 不可能时间旅行查询
• 深度和浅克隆
• OpenSharing，共享所有者必须不受该策略约束，并且具有所需的 OpenSharing 权限。 请注意，该策略不控制收件人的访问权限。
• AI 搜索索引创建和同步

有关这些限制和其他限制的更多详细信息，请参阅 行筛选器和列掩码策略的要求、配额和限制。

已删除策略依赖项

ABAC 策略依赖于受管理的标签和 UDF。 当策略仍在引用这些依赖项时，如果删除这些依赖项，则对策略范围内表的查询将失败。

受治理的标签删除

如果删除 ABAC 策略引用的受治理标记，则针对附加策略的对象的所有查询及其子对象失败并出现 INVALID_PARAMETER_VALUE.UC_ABAC_UNKNOWN_TAG_POLICY 错误。 即使标记未应用于查询表，也会发生这种情况。

删除受治理的标记后，它将成为未治理的标记。 删除了允许值的限制，任何没有APPLY TAG权限的人都有ASSIGN，可以修改值。

若要解决此错误，请还原已删除的标记，或更新或删除引用错误的策略。 请参阅 “创建和管理受管理标记”。

删除标记的列

Azure Databricks阻止删除应用了受控制标记的列。 若要删除列，具有 ASSIGN 标记和 APPLY TAG 对象的用户必须先删除该标记，然后才能删除该列。

这与声明性管道和其他修改表架构的自动化工作流相关。 如果管道尝试删除标记列，操作将失败。 若要取消阻止管道，具有所需标记权限的用户必须删除该标记，运行管道，使架构更改成功，然后将标记重新应用到相关列。 如果未重新应用标记，则针对数据的查询将失败，因为策略仍在范围内，但预期标记不再位于对象上。

策略引用的函数删除

如果在策略仍在作用范围内时删除了该策略引用的 UDF，那么针对该范围内表的查询将失败。UC_DEPENDENCY_DOES_NOT_EXIST 若要解析，请还原函数或更新策略以引用其他 UDF。

多个筛选器和掩码的规则

在查询时，对于特定的表和用户，只能应用一个唯一的行筛选器。 同样，对于给定的列和用户，每列在运行时只能有一个唯一的列掩码来进行解析。 这可以防止不明确的结果。

如果多个不同的筛选器或掩码应用于同一用户和表（或列），Azure Databricks阻止访问并返回错误。 例如：

• 表级筛选器或掩码与 ABAC 策略冲突。 在同一目标上，已具有手动应用的行筛选器或列掩码的表或列与任何由ABAC定义的筛选器或掩码发生冲突。
• 行筛选器的 USING COLUMNS 子句引用了一个匹配多个列的 MATCH COLUMNS 别名。 子句USING COLUMNS将列值传递给UDF。 MATCH COLUMNS如果子句中的USING COLUMNS别名与多个列匹配，则引擎无法确定要传递给 UDF 的列，并且查询失败并出现错误。
• 另一策略的USING COLUMNS子句引用了一个掩码列。 如果列被一个策略屏蔽，则不能将其用作另一策略子句中的 USING COLUMNS 输入参数。

同一表或列可以存在多个 ABAC 策略，如果它们产生相同的有效筛选器或掩码。 例如，引用具有相同参数的同一 UDF 的两个策略会解析为相同的筛选器或掩码，并且不会冲突。

排查策略冲突问题

当Azure Databricks在给定用户的策略评估期间检测到多个不同的筛选器或掩码时，它会引发 INVALID_PARAMETER_VALUE.UC_ABAC_MULTIPLE_ROW_FILTERS 或 COLUMN_MASKS_FEATURE_NOT_SUPPORTED.MULTIPLE_MASKS 错误，并阻止对表的访问，直到冲突得到解决。

诊断并解决问题的方法：

1. 使用 SHOW EFFECTIVE POLICIES 查看适用于该表的所有策略。
2. 检查 INFORMATION_SCHEMA.ROW_FILTERS 和 INFORMATION_SCHEMA.COLUMN_MASKS，以发现可能发生冲突的任何表级行筛选器或列掩码。
3. 检查其 TO/EXCEPT 主体和 WHEN/MATCH COLUMNS 条件中哪些策略重叠。
4. 解决方式：
   • 优化策略条件。 更新 WHEN 或 MATCH COLUMNS 子句，使其更具体，因此不同的策略面向不同的表或列。
   • 调整受治理的标记。 查看触发意外策略匹配的列或表的标记分配，并删除或更新它们。
   • 调整主要组件。 更新 TO/EXCEPT 子句，以便每个用户在每个表（用于行筛选器）或每列（用于列掩码）中至多被一个策略覆盖。
   • 重组策略。 将重叠策略合并为单个策略，或将广泛策略拆分为单独的显式目标策略。

列掩码的自动类型转换

Azure Databricks 会自动转换从 ABAC 策略解析的列掩码函数的输入和输出。 输入列值被转换类型以匹配掩码函数的参数类型，并且函数输出被转换类型以匹配目标列的数据类型。 这可确保屏蔽列时类型一致性和可靠的查询行为。 自动强制转换的工作原理如下：

1. 掩码函数执行：当策略评估确定应用掩码时，掩码函数将针对匹配的列值执行。
2. 自动类型强制转换：Azure Databricks 自动将输入列值转换为函数参数类型，并将函数输出转换为目标列的数据类型。
3. 结果返回：正确键入的结果将返回到查询。

如果输入或输出类型不兼容，转换将失败，查询将返回运行时错误。 类型转换遵循 ANSI SQL 标准（CAST完全兼容性详细信息），但新增了一个功能：在 Databricks Runtime 18.1 及更高版本上，ABAC 列掩码策略可以将结构体转换为VARIANT，这在一般 SQL 中不受支持。

必须确保掩码函数返回与目标列兼容的类型。 查看与转换兼容的掩码函数以获取示例，并了解 VARIANT 方法以便在不同列类型之间实现灵活屏蔽。