SQL Server的行级安全性详解

英文：SQL  Detailed explanation of server's row level security

目录一、前言二、描述三、权限四、安全说明：侧信道攻击五、跨功能兼容性六、示例一、前言行级别安全性使您能够使用组成员身份或执行上下文来控制对数据库表中行的访问。行级别安全性 （RLS） 简化了应用程序中的安全性设计和编码。RLS 可帮助您对数据行访问实施限制。例如，您可以确保工作人员仅访问与其部门相关的数据行。另一个示例是将客户的数据访问限制为仅与其公司相关的数据。访问限制逻辑位于数据库层中，而不是远离另一个应用程序层中的数据。每次尝试从任何层访问数据时，数据库系统都会应用访问限制。这通过减少安全系统的表面积，使您的安全系统更加可靠和强大。通过使用创建安全策略 Transact-SQL 语句和作为内联表值函数创建的谓词实现 RLS。行级别安全性首次引入 SQL Server 2016 （13.x）。二、描述RLS 支持两种类型的安全谓词。筛选器谓词以静默方式筛选可用于读取操作（选择、更新和删除）的行。阻止谓词显式阻止违反谓词的写入操作（插入后、更新后、更新之前、删除之前）。对表中行级数据的访问受定义为内联表值函数的安全谓词的限制。然后，安全策略调用和强制执行该函数。对于筛选器谓词，应用程序不知道从结果集中筛选的行。如果筛选了所有行，则将返回空集。对于块谓词，任何违反谓词的操作都将失败并显示错误。从基表中读取数据时应用筛选器谓词。它们影响所有获取操作：选择、删除和更新。用户无法选择或删除已筛选的行。用户无法更新筛选的行。但是，可以更新行，以便以后对其进行筛选。块谓词会影响所有写入操作。“插入后”和“更新后”谓词可以防止用户将行更新为违反谓词的值。BEFORE UPDATE 谓词可以阻止用户更新当前违反谓词的行。在删除之前 谓词可以阻止删除操作。筛选器和阻止谓词以及安全策略都具有以下行为：可以定义一个谓词函数，该函数与另一个表联接和/或调用函数。如果使用 （默认值） 创建安全策略，则可以从查询访问联接或函数，并按预期工作，而无需任何其他权限检查。如果使用 创建安全策略，则用户将需要对这些附加表和函数的 SELECT 权限才能查询目标表。如果谓词函数调用 CLR 标量值函数，则还需要 EXECUTE 权限。可以针对已定义但已禁用安全谓词的表发出查询。筛选或阻止的任何行不受影响。如果 dbo 用户、db_owner角色的成员或表所有者查询已定义并启用了安全策略的表，则会按照安全策略的定义过滤或阻止行。尝试更改由架构绑定安全策略绑定的表的架构将导致错误。但是，可以更改谓词未引用的列。尝试在已为指定操作定义谓词的表上添加谓词会导致错误。无论是否启用谓词，都会发生这种情况。尝试修改函数（用作架构绑定安全策略中的表的谓词）将导致错误。定义多个包含非重叠谓词的活动安全策略会成功。筛选器谓词具有以下行为：定义用于筛选表中行的安全策略。应用程序不知道针对 SELECT、UPDATE 和 DELETE 操作筛选的任何行。包括筛选掉所有行的情况。应用程序可以插入行，即使它们将在任何其他操作期间被筛选。块谓词具有以下行为：UPDATE 的块谓词被拆分为 BEFORE 和 AFTER 的单独操作。例如，不能阻止用户将行更新为具有高于当前值的值。如果需要这种逻辑，则必须将触发器与 DELETE 和 INSERT 中间表一起使用，以同时引用旧值和新值。如果谓词函数使用的列未更改，优化程序将不会检查 AFTER UPDATE 块谓词。尚未对批量 API 进行任何更改，包括批量插入。这意味着块谓词 AFTER INSERT 将应用于批量插入操作，就像它们将常规插入操作一样。三、权限创建、更改或删除安全策略需要“更改任何安全策略”权限。创建或删除安全策略需要对架构具有 ALTER 权限。此外，添加的每个谓词都需要以下权限：对用作谓词的函数的 SELECT 和 REFERENCE 权限。对绑定到策略的目标表的 REFERENCES 权限。对用作参数的目标表中的每一列的 REFERENCES 权限。安全策略适用于所有用户，包括数据库中的 dbo 用户。Dbo 用户可以更改或删除安全策略，但可以审核他们对安全策略的更改。如果高特权用户（如 sysadmin 或 db_owner）需要查看所有行以排除故障或验证数据，则必须编写安全策略以允许这样做。如果使用 创建安全策略，则要查询目标表，用户必须对谓词函数以及谓词函数中使用的任何其他表、视图或函数具有 SELECT 或 EXECUTE 权限。如果使用 （默认值） 创建安全策略，则当用户查询目标表时会绕过这些权限检查。四、安全说明：侧信道攻击（1）恶意安全策略管理器。请务必注意，恶意安全策略管理器具有在敏感列上创建安全策略的足够权限，并有权创建或更改内联表值函数，但可以与对表具有选择权限的其他用户串通，通过恶意创建旨在使用侧通道攻击推断数据的内联表值函数来执行数据泄露。此类攻击需要串通（或授予恶意用户的过多权限），并且可能需要多次迭代修改策略（需要删除谓词的权限以破坏架构绑定）、修改内联表值函数以及在目标表上重复运行 select 语句。我们建议您根据需要限制权限，并监视任何可疑活动。应监视活动，例如不断更改的策略和与行级别安全性相关的内联表值函数。（2）精心设计的查询。通过使用利用错误的精心设计的查询，可能会导致信息泄露。五、跨功能兼容性通常，行级别安全性将跨功能按预期工作。但是，也有一些例外。本节记录了将行级别安全性与 SQL Server 的某些其他功能结合使用的几个注意事项和注意事项。DBCC SHOW_STATISTICS报告未过滤数据的统计信息，并可能泄露受安全策略保护的信息。因此，对查看具有行级别安全策略的表的统计信息对象的访问受到限制。用户必须拥有该表，或者用户必须是 sysadmin 固定服务器角色、db_owner固定数据库角色或db_ddladmin固定数据库角色的成员。文件流：RLS 与文件流不兼容。内存优化表：必须使用该选项定义用作内存优化表的安全谓词的内联表值函数。使用此选项，将禁止内存优化表不支持的语言功能，并在创建时发出相应的错误。索引视图：通常，可以在视图之上创建安全策略，也可以在受安全策略约束的表之上创建视图。但是，不能在具有安全策略的表之上创建索引视图，因为通过索引查找行将绕过该策略。变更数据捕获：变更数据捕获可能会泄漏应筛选为db_owner成员或为表启用 CDC 时指定的“控制”角色成员的用户（注意：您可以将此函数显式设置为 NULL，以使所有用户都能访问变更数据）。实际上，db_owner和此控制角色的成员可以查看表上的所有数据更改，即使表上有安全策略也是如此。更改跟踪：更改跟踪可能会将应筛选的行的主键泄露给同时具有“选择”和“查看更改跟踪”权限的用户。实际数据值不会泄露;只有 A 列被更新/插入/删除了带有 B 主键的行的事实。如果主密钥包含机密元素（如社会保险号），则会出现问题。然而，在实践中，这个CHANGETABLE几乎总是与原始表连接，以获得最新的数据。全文搜索：使用以下全文搜索和语义搜索函数的查询预计会降低性能，因为引入了额外的联接来应用行级安全性并避免泄漏应过滤的行的主键：CONTAINSTABLE、FREETEXTTABLE、semantickeyphrasetable、semanticsimilaritydetailstable、semanticsimilaritytable、semanticsimilaritytable。列存储索引：RLS 与聚集列存储索引和非聚集列存储索引兼容。但是，由于行级别安全性应用函数，因此优化程序可能会修改查询计划，使其不使用批处理模式。分区视图：不能在分区视图上定义块谓词，也不能在使用块谓词的表上创建分区视图。筛选器谓词与分区视图兼容。时态表：时态表与 RLS 兼容。但是，当前表上的安全谓词不会自动复制到历史记录表中。要将安全策略应用于当前表和历史记录表，必须在每个表上单独添加安全谓词。六、示例向数据库进行身份验证的用户的方案。创建三个用户，并创建并填充一个包含六行的表。然后，它为表创建一个内联表值函数和安全策略。然后，该示例演示如何为各种用户筛选 select 语句。（1）创建三个将演示不同访问功能的用户帐户。CREATE USER Manager WITHOUT LOGIN;CREATE USER SalesRep1 WITHOUT LOGIN;CREATE USER SalesRep2 WITHOUT LOGIN;GO（2）创建一个表来保存数据。CREATE SCHEMA SalesGOCREATE TABLE Sales

一、前言

行级别安全性使您能够使用组成员身份或执行上下文来控制对数据库表中行的访问。

行级别安全性 （RLS） 简化了应用程序中的安全性设计和编码。RLS 可帮助您对数据行访问实施限制。例如，您可以确保工作人员仅访问与其部门相关的数据行。另一个示例是将客户的数据访问限制为仅与其公司相关的数据。

访问限制逻辑位于数据库层中，而不是远离另一个应用程序层中的数据。每次尝试从任何层访问数据时，数据库系统都会应用访问限制。这通过减少安全系统的表面积，使您的安全系统更加可靠和强大。

通过使用创建安全策略 Transact-SQL 语句和作为内联表值函数创建的谓词实现 RLS。

行级别安全性首次引入 SQL Server 2016 （13.x）。

二、描述

RLS 支持两种类型的安全谓词。

• 筛选器谓词以静默方式筛选可用于读取操作（选择、更新和删除）的行。
• 阻止谓词显式阻止违反谓词的写入操作（插入后、更新后、更新之前、删除之前）。

对表中行级数据的访问受定义为内联表值函数的安全谓词的限制。然后，安全策略调用和强制执行该函数。对于筛选器谓词，应用程序不知道从结果集中筛选的行。如果筛选了所有行，则将返回空集。对于块谓词，任何违反谓词的操作都将失败并显示错误。

从基表中读取数据时应用筛选器谓词。它们影响所有获取操作：选择、删除和更新。用户无法选择或删除已筛选的行。用户无法更新筛选的行。但是，可以更新行，以便以后对其进行筛选。块谓词会影响所有写入操作。

• “插入后”和“更新后”谓词可以防止用户将行更新为违反谓词的值。
• BEFORE UPDATE 谓词可以阻止用户更新当前违反谓词的行。
• 在删除之前 谓词可以阻止删除操作。

筛选器和阻止谓词以及安全策略都具有以下行为：

• 可以定义一个谓词函数，该函数与另一个表联接和/或调用函数。如果使用 （默认值） 创建安全策略，则可以从查询访问联接或函数，并按预期工作，而无需任何其他权限检查。如果使用 创建安全策略，则用户将需要对这些附加表和函数的 SELECT 权限才能查询目标表。如果谓词函数调用 CLR 标量值函数，则还需要 EXECUTE 权限。
• 可以针对已定义但已禁用安全谓词的表发出查询。筛选或阻止的任何行不受影响。
• 如果 dbo 用户、db_owner角色的成员或表所有者查询已定义并启用了安全策略的表，则会按照安全策略的定义过滤或阻止行。
• 尝试更改由架构绑定安全策略绑定的表的架构将导致错误。但是，可以更改谓词未引用的列。
• 尝试在已为指定操作定义谓词的表上添加谓词会导致错误。无论是否启用谓词，都会发生这种情况。
• 尝试修改函数（用作架构绑定安全策略中的表的谓词）将导致错误。
• 定义多个包含非重叠谓词的活动安全策略会成功。

筛选器谓词具有以下行为：

• 定义用于筛选表中行的安全策略。应用程序不知道针对 SELECT、UPDATE 和 DELETE 操作筛选的任何行。包括筛选掉所有行的情况。应用程序可以插入行，即使它们将在任何其他操作期间被筛选。

块谓词具有以下行为：

• UPDATE 的块谓词被拆分为 BEFORE 和 AFTER 的单独操作。例如，不能阻止用户将行更新为具有高于当前值的值。如果需要这种逻辑，则必须将触发器与 DELETE 和 INSERT 中间表一起使用，以同时引用旧值和新值。
• 如果谓词函数使用的列未更改，优化程序将不会检查 AFTER UPDATE 块谓词。
• 尚未对批量 API 进行任何更改，包括批量插入。这意味着块谓词 AFTER INSERT 将应用于批量插入操作，就像它们将常规插入操作一样。

三、权限

创建、更改或删除安全策略需要“更改任何安全策略”权限。创建或删除安全策略需要对架构具有 ALTER 权限。

此外，添加的每个谓词都需要以下权限：

• 对用作谓词的函数的 SELECT 和 REFERENCE 权限。
• 对绑定到策略的目标表的 REFERENCES 权限。
• 对用作参数的目标表中的每一列的 REFERENCES 权限。

安全策略适用于所有用户，包括数据库中的 dbo 用户。Dbo 用户可以更改或删除安全策略，但可以审核他们对安全策略的更改。如果高特权用户（如 sysadmin 或 db_owner）需要查看所有行以排除故障或验证数据，则必须编写安全策略以允许这样做。

如果使用 创建安全策略，则要查询目标表，用户必须对谓词函数以及谓词函数中使用的任何其他表、视图或函数具有 SELECT 或 EXECUTE 权限。如果使用 （默认值） 创建安全策略，则当用户查询目标表时会绕过这些权限检查。

四、安全说明：侧信道攻击

（1）恶意安全策略管理器。

请务必注意，恶意安全策略管理器具有在敏感列上创建安全策略的足够权限，并有权创建或更改内联表值函数，但可以与对表具有选择权限的其他用户串通，通过恶意创建旨在使用侧通道攻击推断数据的内联表值函数来执行数据泄露。此类攻击需要串通（或授予恶意用户的过多权限），并且可能需要多次迭代修改策略（需要删除谓词的权限以破坏架构绑定）、修改内联表值函数以及在目标表上重复运行 select 语句。我们建议您根据需要限制权限，并监视任何可疑活动。应监视活动，例如不断更改的策略和与行级别安全性相关的内联表值函数。

（2）精心设计的查询。

通过使用利用错误的精心设计的查询，可能会导致信息泄露。

五、跨功能兼容性

• 通常，行级别安全性将跨功能按预期工作。但是，也有一些例外。本节记录了将行级别安全性与 SQL Server 的某些其他功能结合使用的几个注意事项和注意事项。
• DBCC SHOW_STATISTICS报告未过滤数据的统计信息，并可能泄露受安全策略保护的信息。因此，对查看具有行级别安全策略的表的统计信息对象的访问受到限制。用户必须拥有该表，或者用户必须是 sysadmin 固定服务器角色、db_owner固定数据库角色或db_ddladmin固定数据库角色的成员。
• 文件流：RLS 与文件流不兼容。
• 内存优化表：必须使用该选项定义用作内存优化表的安全谓词的内联表值函数。使用此选项，将禁止内存优化表不支持的语言功能，并在创建时发出相应的错误。
• 索引视图：通常，可以在视图之上创建安全策略，也可以在受安全策略约束的表之上创建视图。但是，不能在具有安全策略的表之上创建索引视图，因为通过索引查找行将绕过该策略。
• 变更数据捕获：变更数据捕获可能会泄漏应筛选为db_owner成员或为表启用 CDC 时指定的“控制”角色成员的用户（注意：您可以将此函数显式设置为 NULL，以使所有用户都能访问变更数据）。实际上，db_owner和此控制角色的成员可以查看表上的所有数据更改，即使表上有安全策略也是如此。
• 更改跟踪：更改跟踪可能会将应筛选的行的主键泄露给同时具有“选择”和“查看更改跟踪”权限的用户。实际数据值不会泄露;只有 A 列被更新/插入/删除了带有 B 主键的行的事实。如果主密钥包含机密元素（如社会保险号），则会出现问题。然而，在实践中，这个CHANGETABLE几乎总是与原始表连接，以获得最新的数据。
• 全文搜索：使用以下全文搜索和语义搜索函数的查询预计会降低性能，因为引入了额外的联接来应用行级安全性并避免泄漏应过滤的行的主键：CONTAINSTABLE、FREETEXTTABLE、semantickeyphrasetable、semanticsimilaritydetailstable、semanticsimilaritytable、semanticsimilaritytable。
• 列存储索引：RLS 与聚集列存储索引和非聚集列存储索引兼容。但是，由于行级别安全性应用函数，因此优化程序可能会修改查询计划，使其不使用批处理模式。
• 分区视图：不能在分区视图上定义块谓词，也不能在使用块谓词的表上创建分区视图。筛选器谓词与分区视图兼容。
• 时态表：时态表与 RLS 兼容。但是，当前表上的安全谓词不会自动复制到历史记录表中。要将安全策略应用于当前表和历史记录表，必须在每个表上单独添加安全谓词。

六、示例

向数据库进行身份验证的用户的方案。创建三个用户，并创建并填充一个包含六行的表。然后，它为表创建一个内联表值函数和安全策略。然后，该示例演示如何为各种用户筛选 select 语句。

（1）创建三个将演示不同访问功能的用户帐户。

CREATE USER Manager WITHOUT LOGIN;CREATE USER SalesRep1 WITHOUT LOGIN;CREATE USER SalesRep2 WITHOUT LOGIN;GO

（2）创建一个表来保存数据。

CREATE SCHEMA SalesGOCREATE TABLE Sales.Orders    (    OrderID int,    SalesRep nvarchar(50),    Product nvarchar(50),    Quantity smallint    );

（3）用六行数据填充表，显示每个销售代表的三个订单。

INSERT INTO Sales.Orders  VALUES (1, 'SalesRep1', 'Valve', 5);INSERT INTO Sales.Orders  VALUES (2, 'SalesRep1', 'Wheel', 2);INSERT INTO Sales.Orders  VALUES (3, 'SalesRep1', 'Valve', 4);INSERT INTO Sales.Orders  VALUES (4, 'SalesRep2', 'Bracket', 2);INSERT INTO Sales.Orders  VALUES (5, 'SalesRep2', 'Wheel', 5);INSERT INTO Sales.Orders  VALUES (6, 'SalesRep2', 'Seat', 5);-- View the 6 rows in the tableSELECT * FROM Sales.Orders;

（4）向每个用户授予对表的读取访问权限。

GRANT SELECT ON Sales.Orders TO Manager;GRANT SELECT ON Sales.Orders TO SalesRep1;GRANT SELECT ON Sales.Orders TO SalesRep2;GO

（5）创建新架构和内联表值函数。当列中的行与执行查询的用户 相同或执行查询的用户是经理用户时，该函数返回。此用户定义的表值函数示例可用于用作下一步中创建的安全策略的筛选器。

CREATE SCHEMA Security;GO  CREATE FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))    RETURNS TABLEWITH SCHEMABINDINGAS    RETURN SELECT 1 AS tvf_securitypredicate_resultWHERE @SalesRep = USER_NAME() OR USER_NAME() = 'Manager';GO

（6）创建将函数添加为筛选器谓词的安全策略。必须将状态设置为ON才能启用策略。

CREATE SECURITY POLICY SalesFilterADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)ON Sales.OrdersWITH (STATE = ON);GO

（7）允许对函数的 SELECT 权限。

GRANT SELECT ON Security.tvf_securitypredicate TO Manager;GRANT SELECT ON Security.tvf_securitypredicate TO SalesRep1;GRANT SELECT ON Security.tvf_securitypredicate TO SalesRep2;

（8）更改安全策略以禁用该策略。

ALTER SECURITY POLICY SalesFilterWITH (STATE = OFF);

（9）连接到 SQL 数据库清理练习资源。

DROP USER SalesRep1;DROP USER SalesRep2;DROP USER Manager;DROP SECURITY POLICY SalesFilter;DROP TABLE Sales.Orders;DROP FUNCTION Security.tvf_securitypredicate;DROP SCHEMA Security;DROP SCHEMA Sales;

到此这篇关于SQL Server的行级安全性详解的文章就介绍到这了,更多相关SQL Server行级安全性内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！