Sql Server 2016 有一个新功能叫 Row-Level Security ,大概意思是行版本的安全策略(原来我是个英语渣_(:з」∠)_)数据库
直接上例子。这个功能至关经过对表添加一个函数做为过滤规则,使得拥有不一样条件的用户(或者登陆名) 之类的,只能获取到符合条件的数据。相对来讲是提供了那么一点的便捷性,固然也增长了数据的安全性,至关于每一个用户链接进来只能看到安全
符合规则的数据(固然,这里的用户只是一个举例。实际上是能够经过编写过滤函数来实现的)函数
举个例子测试
有三个用户 Sales1 ,Sales 2 ,Manager 3个数据库用户,而后用一个Sales的表来寄存他们的订单记录spa
CREATE TABLE Sales ( OrderID int, SalesRep sysname, Product varchar(10), Qty int ); INSERT Sales VALUES (1, 'Sales1', 'Valve', 5), (2, 'Sales1', 'Wheel', 2), (3, 'Sales1', 'Valve', 4), (4, 'Sales2', 'Bracket', 2), (5, 'Sales2', 'Wheel', 5), (6, 'Sales2', 'Seat', 5); -- View the 6 rows in the table SELECT * FROM Sales; go
这是所有表的数据的截图code
而后添加3个用户,分别就是Sales1 Sales2 Manager 3个用户,分别对他们的赋予Sales表的查询和删除(用于测试删除功能) 的权限。blog
CREATE USER Manager WITHOUT LOGIN; CREATE USER Sales1 WITHOUT LOGIN; CREATE USER Sales2 WITHOUT LOGIN; GRANT SELECT,delete ON Sales TO Manager; GRANT SELECT,delete ON Sales TO Sales1; GRANT SELECT,delete ON Sales TO Sales2;
而后如下是这个功能的核心部分。首先咱们建立一个过滤函数,而后将这个过滤函数添加到这个表的安全策略里面,就能够看到效果了。it
函数逻辑很简单,传入一个@SalesRep 的名称,用于匹配当前的 User_Name。匹配了才返回数据table
而后下面一行是建立了一个安全策略,而且在Sales 的表里面使用函数 fn_securitypredicate 做为表的筛选器。传入函数的参数选定为 SalesRep 字段(也就是咱们建表的那个销售表明字段了)class
CREATE FUNCTION fn_securitypredicate(@SalesRep AS sysname) RETURNS TABLE WITH SCHEMABINDING AS RETURN SELECT 1 AS fn_securitypredicate_result WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'Manager'; CREATE SECURITY POLICY SalesFilter ADD FILTER PREDICATE dbo.fn_securitypredicate(SalesRep) ON dbo.Sales WITH (STATE = ON);
而后咱们看下查询的结果
EXECUTE AS USER = 'Sales1'; SELECT * FROM Sales; REVERT; EXECUTE AS USER = 'Sales2'; SELECT * FROM Sales; REVERT; EXECUTE AS USER = 'Manager'; SELECT * FROM Sales; REVERT;
效果就是这样,固然若是是要设置不一样的过滤条件,设置不一样的字段的时候,是能够经过上文的函数里面的代码和安全策略进行设置的。按照这个过滤状况,若是登陆用户非Sales1 Sales2 Manager 3个其中之一,是什么都查询不了的。
另外,用户没法删除被过滤的数据。比方说 Sales1 不能删除或修改OrderID = 3 的数据。
RLS的出现也是能帮助咱们减轻必定功能上面的实现的~
简单的演示了一下这个RLS的功能~分享得不够好的地方烦请你们拍砖.