sql 如何设置行级锁

With the release of SQL Server 2016 comes many great new features. One of these is the implementation of row level security in the database engine.

随着SQL Server 2016的发布，带来了许多强大的新功能。 其中之一是在数据库引擎中实现行级安全性。

This blogpost will cover the aspects of this new feature – including:

该博客文章将涵盖此新功能的各个方面–包括：

• Setup建立
• Best practice最佳实践
• Performance性能
• Possible security leaks可能的安全漏洞

介绍 (Introduction)

The row level security feature was released earlier this year to Azure – following Microsoft’s cloud-first release concept.

行级安全功能已于今年早些时候发布到Azure，这是Microsoft的云优先发布概念。

A past big issue with the SQL Server engine was that in only understands tables and columns. Then you had to simulate security using secured views, stored procedures or table value functions. The problem here was to make sure that there were no way to bypass them.

SQL Server引擎过去的一个大问题是只能理解表和列。 然后，您必须使用安全视图，存储过程或表值函数来模拟安全性。 这里的问题是确保没有办法绕过它们。

With SQL Server 2016, this is no longer an issue.

使用SQL Server 2016，这不再是问题。

Now the SQL Server engine handles the security policy in a central controlled area.

现在，SQL Server引擎在中央控制区域中处理安全策略。

设置和最佳实践 (Setup and best practice)

The Row-level security is based on a special inline table valued function. This function returns either a single row with a 1 or no rows based on the users rights to that specific row.

行级安全性基于特殊的内联表值函数。 此函数根据对特定行的用户权限返回具有1行或不具有行的单行。

Let us take an example:

让我们举个例子：

First of all, I’ll create a database and some users to test with:

首先，我将创建一个数据库和一些用户进行测试：

CREATE DATABASE RowFilter;
GOUSE RowFilter;
GOCREATE USER userBrian WITHOUT LOGIN;
CREATE USER userJames WITHOUT LOGIN;
GO

A table with examples and grant select to the new users:

包含示例和授予新用户选择权限的表：

CREATE TABLE dbo.SalesFigures (
[userCode] NVARCHAR(10),
[sales] MONEY)
GOINSERT  INTO dbo.SalesFigures
VALUES ('userBrian',100), ('userJames',250), ('userBrian',350)
GOGRANT SELECT ON dbo.SalesFigures TO userBrian
GRANT SELECT ON dbo.SalesFigures TO userJames
GO

Now we’ll add a filter predicate function as below:

现在，我们将添加一个过滤谓词函数，如下所示：

CREATE FUNCTION dbo.rowLevelPredicate (@userCode as sysname)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS rowLevelPredicateResult
WHERE @userCode = USER_NAME();
GO

This illustrates that the current user must have associated records in order to get any results. Notice that the functions does not have access to the rows itself.

这说明当前用户必须具有关联的记录才能获得任何结果。 请注意，函数无法访问行本身。

Furthermore the function can contain joins and lookup tables in the where clause – but beware of the performance hit here. Look further down this post for more info.

此外，该函数可以在where子句中包含联接和查找表-但是要注意此处的性能。 进一步查看此帖子以获取更多信息。

The last thing to do is to add a filter predicate to the table dbo.SalesFigures:

最后要做的是向表dbo.SalesFigures添加一个过滤谓词：

CREATE SECURITY POLICY UserFilter
ADD FILTER PREDICATE dbo.rowLevelPredicate(userCode)
ON dbo.SalesFigures
WITH (STATE = ON);
GO

That’s it.

而已。

Let’s test the results with the users added before:

让我们用之前添加的用户来测试结果：

 EXECUTE AS USER = 'userBrian';
SELECT * FROM dbo.SalesFigures;
REVERT;
GO

This gives me 2 rows:

这给了我2行：

EXECUTE AS USER = 'userJames';
SELECT * FROM dbo.SalesFigures;
REVERT;
GO

This gives me 1 row:

这给了我1行：

The execution plan shows a new filter predicate when this row level security is added:

添加此行级安全性后，执行计划将显示一个新的过滤谓词：

To clean up the examples.

清理示例。

USE master;
DROP DATABASE RowFilter;

性能 (Performance)

Some might ask, “what about the performance – isn’t there a performance hit in this use of functions?”

有人可能会问：“性能如何？使用函数是否会对性能造成影响？”

The short answer is “It depends”.

简短的回答是“取决于”。

If you only use a direct filter on the table there is very little to no impact on the performance. The filter is applied directly to the table as any other filter. Compared to the old way of doing the row filter with stored procedures or table valued functions this new approach is performing better.

如果仅在表上使用直接过滤器，则对性能几乎没有影响。 该过滤器与任何其他过滤器一样直接应用于表。 与使用存储过程或表值函数对行过滤器进行处理的旧方法相比，这种新方法的性能更好。

If you plan to use lookup tables or joins in the predicate function, then you must beware of the helper tables’ indexes and how fast they can deliver data to the function. If the tables are large and slow performing (without indexes etc.) then you will experience bad performance in the row filter function. But that’s just like any other lookup or join that you might do in your solutions.

如果计划使用查找表或谓词函数中的联接，则必须注意帮助表的索引以及它们可以将数据传送到函数的速度。 如果表很大且执行缓慢（没有索引等），则行过滤器功能将导致性能下降。 但这就像您在解决方案中可能执行的其他任何查找或联接一样。

最佳实践 (Best practices)

There are some best practices given from Microsoft:

Microsoft提供了一些最佳实践：

• It is highly recommended to create a separate schema for the RLS objects (predicate function and security policy).强烈建议为RLS对象创建一个独立的架构（谓词功能和安全策略）。
• The ALTER ANY SECURITY POLICY permission is intended for highly-privileged users (such as a security policy manager). The security policy manager does not require SELECT permission on the tables they protect.ALTER ANY SECURITY POLICY权限适用于特权较高的用户（例如安全策略管理器）。 安全策略管理器不需要对其保护的表的SELECT权限。
• Avoid type conversions in predicate functions to avoid potential runtime errors.避免在谓词函数中进行类型转换，以避免潜在的运行时错误。
• Avoid recursion in predicate functions wherever possible to avoid performance degradation. The query optimizer will try to detect direct recursions, but is not guaranteed to find indirect recursions (i.e., where a second function calls the predicate function).尽可能避免谓词函数中的递归，以避免性能下降。 查询优化器将尝试检测直接递归，但不能保证找到间接递归（即，第二个函数调用谓词函数）。
• Avoid using excessive table joins in predicate functions to maximize performance.避免在谓词函数中使用过多的表联接以最大化性能。

可能的安全漏洞 (Possible security leaks)

This new row filter context can cause information leakage using some carefully codes queries.

使用一些仔细的代码查询，此新的行过滤器上下文可能导致信息泄漏。

Above example can be breached with the following query:

上面的示例可以被以下查询破坏：

SELECT 1/([sales]-250) FROM dbo.SalesFigures
WHERE Usercode = 'userJames'

This will give an error: Divide by zero error encountered.

这将产生一个错误： 遇到错误除以零 。

This will tell the user trying to access the table, that userJames has a sale of 250. So even though the row filter prevents users from accessing data that they are not allowed, hackers can still try to determine the data in the table using above method.

这将告诉尝试访问该表的用户，userJames的销售额为250。因此，即使行过滤器阻止用户访问不允许的数据，黑客仍然可以尝试使用上述方法确定表中的数据。

结论 (Conclusion)

The new row level security feature has been very much a wanted feature for quite a while now, and with the function now in place, and planned to be released in the RTM version of SQL Server 2016, the DBA’s and other people working with security can use this out-of-the-box.

新的行级安全性功能已经成为相当长一段时间以来人们一直想要的功能，并且该功能已经存在，并且计划在SQL Server 2016的RTM版本中发布，DBA和其他从事安全性工作的人员可以开箱即用。

I hope this post makes a great start for you if you would like to try out the row level security function. Currently the feature is awailable in the latest CTP version (2.2) – which can be downloaded here:
SQL Server 2016 Community Technology Preview

如果您想尝试行级安全功能，希望这篇文章对您来说是个不错的开始。 当前，该功能在最新的CTP版本（2.2）中可用–可以在此处下载：
SQL Server 2016社区技术预览

翻译自: https://www.sqlshack.com/row-level-security-in-sql-server-2016/

sql 如何设置行级锁