What is row-level security?

什么是行级安全性？ | Databricks 博客

跳至主要内容

数据 + AI 基础

什么是行级安全性？

作者：Databricks 员工

摘要

• 行级安全性（RLS）根据用户身份、角色或会话上下文过滤表数据，确保每个人只能看到他们被授权访问的行，无论是在仪表板、笔记本、API 或其他工具中。

• 有效的 RLS 依赖于清晰的访问逻辑、可靠的键列以及读写操作的独立控制，并通过多个用户角色的测试来支持。

• RLS 最有效的方式是与其他治理措施（如表权限、列级安全性、数据脱敏和审计日志）结合使用，因为单独使用时，它无法保护敏感列或对聚合结果进行保护。

行级安全性（RLS）是一种数据库访问控制机制，它根据用户的身份、角色或会话上下文限制用户可以读取或修改的表中的行。

与限制对整个表或特定列的访问不同，RLS 按行过滤数据。数据库引擎在查询时自动应用该过滤器，因此无论用户使用什么工具访问数据，规则都是一致的。

RLS 是细粒度访问控制的一部分，与以下内容并列：

• 列级安全性

• 数据脱敏

• 表级授权

例如，一个销售人员可以查询公司的订单表，但只能看到分配给他们的区域的订单，即使表中包含所有区域的数据。用户编写一个标准的 SELECT 语句，引擎只返回用户被允许查看的行。

如今，RLS 是多租户 SaaS、区域数据隔离和合规性用例的核心构建模块。本文将介绍 RLS 的工作原理、适用场景、局限性以及它在 Databricks 平台上的实现方式。

行级安全性是如何工作的？

行级安全性通过向表应用一个过滤规则（通常称为策略或谓词）来实现。当用户运行查询时，数据库引擎会自动应用该过滤器，并仅返回用户被允许查看的行。

在实践中，RLS 通常分为以下三个步骤：

• 用户运行查询：用户编写一个标准查询，而无需自己添加任何安全过滤器。

• 数据库检查用户身份：引擎通过内置函数（如 CURRENT_USER）、由应用程序设置的会话变量或将用户和组映射到允许数据的映射表来评估用户。

• 引擎过滤结果：RLS 谓词对用户可以查看的行返回 TRUE，对其他所有行返回 FALSE。只有通过谓词的行才会被返回。

由于执行发生在数据库层，相同的规则在所有访问路径上都保持一致，包括 BI 仪表板、笔记本、即席 SQL、API 和第三方工具。这种一致性使 RLS 非常强大：一个规则，应用于所有地方，由引擎执行。

大多数引擎还会区分读取和写入的执行。读取谓词控制 SELECT 查询返回的内容。写入谓词通常通过 WITH CHECK 子句单独定义，控制用户可以插入、更新或删除的行。

两个谓词可以相同，但它们不一定需要相同。例如，用户可能被允许读取所有区域的行，但只能插入属于他们自己区域的行。当表接受写入时，定义这两方面非常重要，因为跳过写入检查是团队在生产环境中错误配置 RLS 的最常见方式之一。

行级安全与列级安全及其他访问控制的对比

行级安全（RLS）是几种细粒度访问控制之一，在生产环境中通常与其他控制方式结合使用。下表展示了每种控制方式的适用场景。

| 控制方式 | 限制内容 | 典型使用场景 | |--------|--------|--------| | 行级安全（RLS） | 表中的特定行 | 限制用户只能查看其所在区域、租户或部门的数据 | | 列级安全（CLS） | 表中的特定列 | 隐藏分析师可见的薪资、社会安全号码（SSN）或个人身份信息（PII）列 | | 对象级安全（OLS） | 整个表、视图或度量 | 完全阻止对敏感数据集的访问 | | 数据脱敏 | 列中可见的值 | 仅显示信用卡号码的最后四位数字 | | GRANT / REVOKE | 表级的读写权限 | 允许或拒绝对整个表的访问 |

这些控制方式的设计目的是分层叠加。典型的配置使用表级权限控制谁可以访问表，使用行级安全来限定可见的行，使用列级安全或数据脱敏来保护这些行中的敏感字段。将它们视为一个堆栈而不是一个可选菜单，使治理既可审计又具有弹性。某一层的配置错误不会影响其他层。

行级安全的常见使用场景

行级安全是强制规定共享表中谁能看到什么的标准方法，它根据用户的属性（如区域、租户或分类）与一个关键列进行匹配，以过滤行。当一个数据集需要服务于具有不同可见性规则的多个受众时，大多数团队都会选择使用行级安全。

• 多租户 SaaS：使用租户 ID 列和会话上下文，在共享表中隔离每个客户的数据。这避免了为每个租户创建单独的模式或数据库所带来的运营成本，同时在查询时完全隔离每个客户的数据。

• 区域隔离：限制销售、人力资源或订单数据，使用户只能看到其所在国家或区域的记录，而无需按地理区域拆分底层表。

• 部门访问：为财务、市场和运营团队提供对同一张表的访问权限，但根据部门或成本中心列分配不同的行。

• 合规性要求：强制执行数据驻留规则，例如在 GDPR 下仅允许欧盟员工查看欧盟记录，或在 HIPAA、CCPA 或行业特定法规下限制受保护的类别。

• 医疗和临床数据：允许临床医生共享一个患者表，但只能看到自己的患者，从而在不跨部门复制记录的情况下支持 HIPAA 的最低必要访问原则。

• 合作伙伴和供应商门户：在外部合作伙伴之间共享一个数据集，同时根据各自记录过滤每个合作伙伴，使一个单一的源表能够支持数十个面向合作伙伴的视图。

如何实现行级安全：4 个步骤

在各个平台上，实现行级安全的通用模式是一致的，必要时会使用特定于供应商的语法。

• 确定过滤逻辑：决定访问权限由什么决定：用户 ID、组成员资格、区域、租户 ID 或映射表。过滤逻辑应能从会话上下文或稳定的查找中推导出来，而不是由用户在查询时控制的值。

• 添加或确认关键列：确保表中有一个过滤可以使用的列，例如租户 ID、区域或所有者 ID。如果尚未存在这样的列，应在策略生效前计划进行回填，并考虑对列进行索引以保持谓词的低成本。

• 定义策略或行过滤器：编写一个返回 TRUE 的谓词，用于标识用户有权查看的行，并为写入操作单独设置检查（如果表允许写入）。尽可能在 SQL 中实现逻辑。大多数引擎对 SQL 谓词的优化效果优于其他语言中的函数调用。

• 使用多个用户身份进行测试：以不同角色运行查询，确认显示的行正确且不同租户之间没有信息泄露。包括一个负面测试：没有匹配行的用户应看到空结果，而不是错误，同时应单独测试特权用户以确认其可以绕过所有者限制的行为。

REPORT

企业级智能体 AI 实施指南

立即阅读

行级安全的优势

将访问逻辑移至数据层可以在多个实际方面带来好处。简而言之，数据库成为访问权限的权威来源，而不是每个接触数据的应用程序。

• 集中逻辑：访问规则与数据一起存在，而不是分散在应用程序代码或 BI 工具中。

• 一致执行：无论用户从笔记本、仪表板还是 API 查询，规则都是一致的。

• 多层防御：如果应用层检查被绕过或存在错误，行级安全（RLS）可以提供额外的保护层。

• 更简单的应用程序代码：开发人员不需要在每个查询中手动添加 WHERE 子句。

• 更容易审计：合规团队可以审查一个策略，而不是追踪跨系统的访问逻辑。

• 新工具更快上手：新的 BI 工具或笔记本环境可以继承现有的行级规则，而无需进行自定义集成工作。

行级安全的局限性和风险

行级安全功能强大，但团队应提前了解其已知的陷阱。这些限制通常在生产环境中或审计时才显现，因此提前了解它们非常重要。

管理员和所有者绕过

在许多数据库中，表所有者和高权限管理员默认会绕过行级安全。例如，PostgreSQL 需要设置 FORCE ROW LEVEL SECURITY 才能将策略应用于表所有者，其他数据库引擎也有类似设置。这是一个常见的审计发现：除非你的配置明确强制策略应用于特权用户，否则应假设特权用户可以看到所有行。在批准策略之前，应从特权会话中测试策略，而不仅仅是普通会话。

无法隐藏列或汇总结果

行级安全过滤行，但不会隐藏列或阻止汇总结果。如果分析师被阻止查看个别欧盟记录，但未与列或汇总限制结合使用行级安全，他仍可能在未过滤的表上运行 SELECT COUNT(*)。为弥补这一差距，应将行级安全与列级安全或数据脱敏结合使用，并考虑是否需要对最敏感的表进行汇总查询的治理。

性能开销

每个查询都会应用行级安全的谓词，如果过滤逻辑复杂或键列未被索引，可能会降低性能。对策略引用的列进行索引，并尽可能简化谓词。优先使用简单的 CASE 表达式，而不是子查询或映射表查找。如果引擎支持，将用户与行的映射关系预计算到一个小型、良好索引的表中，而不是实时计算。

由行级安全性（RLS）导致的空结果集与“没有匹配数据”看起来完全一样。开发人员在寻找缺失的行时，常常需要花费数小时，直到他们意识到策略已经将其过滤掉。在开发过程中，记录有效的用户身份和策略版本，为工程师提供一种方法，以便在结果看起来不正确时确认 RLS 是否处于活动状态，并将策略与表模式放在同一位置进行记录，以确保其可发现性。

配置错误的写入规则

RLS 策略通常有两个方面：一个 USING 子句用于过滤用户可以读取的内容，一个 WITH CHECK 子句用于控制用户可以插入或更新的内容。仅定义其中一方面是一个常见的错误：如果只设置了读取过滤而没有写入检查，用户可能会插入或更新他们不应拥有的行。当表接受写入时，始终要定义这两方面，并在策略审查过程中运行写入测试。

Databricks 平台上的行级安全性

在 Databricks 平台上，行级安全性通过 Unity Catalog 中的行过滤器实现，Unity Catalog 是 Databricks 的统一治理层，用于数据和人工智能。模式很简单：定义一个 SQL 用户定义函数，该函数返回允许特定用户查看的行的 true 值，然后将其附加到目标表。过滤器在查询时自动运行，使用当前用户的身份或会话上下文来确定返回哪些行。

行过滤器在 Databricks SQL、笔记本、作业和连接的 BI 工具中一致地执行，无需为每个界面编写自定义逻辑。它们与列掩码配合使用，实现完整的细粒度访问控制，并且所有访问过滤表的查询都会被记录在 Unity Catalog 的血缘关系和审计日志中，因此治理和安全团队可以清楚地看到哪些策略适用于哪些表以及哪些用户查询了哪些内容。

常见问题

什么是动态行级安全性？动态 RLS 在查询时使用当前用户的标识或会话上下文评估访问规则，因此同一策略对不同用户返回的结果不同。所有现代 RLS 实现都以这种方式工作，包括 Databricks 的 ABAC 策略、行过滤器和动态视图。

行级安全性与列级安全性有什么区别？RLS 限制用户可以看到的行；列级安全性限制用户可以看到的列，通常用于隐藏敏感字段，如工资或社会安全号码。大多数生产部署都会同时使用这两种方式。

仅依靠行级安全性是否足以保护敏感数据？不。RLS 处理行可见性，但不会隐藏列值、阻止聚合查询或替换身份和访问管理。将其与列级安全性、表级授权和审计日志结合使用，作为纵深防御策略的一部分。

Databricks 如何实现行级安全性？通过 Unity Catalog，提供三种选项：ABAC 策略、表级行过滤器和动态视图。ABAC 推荐用于大规模治理；行过滤器和动态视图适用于更定制化的需求。

行级安全性是否会影响查询性能？是的，但影响通常是可以管理的。保持策略逻辑简单，对策略引用的列进行索引，并优先使用 SQL UDF 而不是 Python UDF。在策略更改前后对查询进行性能分析，以尽早发现性能下降问题。

在 Databricks 上开始使用细粒度访问控制

行级安全性作为更广泛治理模型的一部分最为有效，该模型还涵盖列、数据掩码、血缘关系和审计。了解 Unity Catalog 如何在 Databricks 平台上将行级安全性、列掩码和统一治理结合在一起。

订阅以获取最新文章

订阅我们的博客，即可将最新文章发送到您的邮箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"