欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

数据权限筛选(RLS)的两种实现介绍

程序员文章站 2022-06-25 12:34:54
介绍了使用Security Policy和RlsStrategy两种方式实现行级数据安全,即数据权限筛选 ......

 

在应用程序中,尤其是在统计的时候, 需要使用数据权限来筛选数据行。 简单的说,张三看张三部门的数据, 李四看李四部门的数据;或者员工只能看自己的数据, 经理可以看部门的数据。这个在微软的文档中叫row level security,字面翻译叫行级数据安全,简称rls。


要实现rls, 简单的思路就是加where条件语句来做数据筛选。但是必须是先where, 也就是在其他where条件和orderby、fetch rows 之前执行, 否则会对 排序、分页查询造成影响。这是一个难点。
另一个难点是如何对现有的业务代码侵入性降到最低——不影响现有查询逻辑的写法,甚至当需要的时候,可以关闭rls。为了校验数据, 必须保持rls开关的灵活性,尤其是在开发阶段。

下面介绍我在项目中使用过的两种实现方式。

数据权限筛选(rls)的实现(一) -- security policy方式实现
这个主要参考微软的官文介绍实现, 分三个步骤, a. 定义predicate函数, 根据user参数来筛选数据, b. 定义security policy, 使用前面指定的predicate函数, c.在指定表上应用security policy。
其中的user, 一种是通过当前连接数据库的登录用户来获取,一种是通过exec sp_set_session_context @key=n'userid', @value=@userid 来传入用户。后者更适合我们在应用查询中使用统一的连接字符串。由于我们数据访问层是通过ef来实现的, 所以我们统一在自定义的dbcontext类型中做了改造:

 1 public abstract class rlsdbcontext : dbcontext
 2 {
 3 
 4     protected readonly iuserprovider userprovider;
 5     protected rlsdbcontext(
 6     string connectionstring,
 7     iuserprovider userprovider)
 8     : base(options)
 9     {
10         this.connectionstring = connectionstring;
11         this.userprovider = userprovider;
12     }
13 
14     protected override void onconfiguring(dbcontextoptionsbuilder optionsbuilder)
15     {
16         connection = new sqlconnection(connectionstring);
17         if (enablerls)
18         {
19             connection.statechange += connection_statechange;
20         }
21 
22         if (!enablememorydb)
23         {
24             optionsbuilder.usesqlserver(connection);
25         }
26 
27         base.onconfiguring(optionsbuilder);
28     }
29 
30     private void connection_statechange(object sender, system.data.statechangeeventargs e)
31     {
32         if (e.currentstate == connectionstate.open)
33         {
34             string userid = userprovider.currentuserid;
35             //此处判断条件用于流程hook接口未配置认证而获取不到用户的情况
36             if (!string.isnullorempty(userid))
37             {
38                 sqlcommand cmd = connection.createcommand();
39                 cmd.commandtext = @"exec sp_set_session_context @key=n'userid', @value=@userid";
40                 cmd.parameters.addwithvalue("@userid", userid);
41                 cmd.executenonquery();
42             }
43         }
44         else if (e.currentstate == connectionstate.closed)
45         {
46             //暂时注释:在分页查询场景下存在rls获取总数之前sql连接关闭的情况
47             //connection.statechange -= connection_statechange;
48         }
49     }
50 
51 }

 

这样, 我们就能确保在访问数据库的适合, 传入了当前用户信息

具体的示例, 可以参考《row-level security
但是这个方式有个很大的问题, 就是性能不理想, 尤其是在判断条件中有or逻辑的时候。 比如这个场景:每个部门只能看自己的数据,如果是数据管理员,不论在哪个部门, 可以看所有部门的数据。加了or逻辑后, 大概1w行数据查询需要10s钟,这超出了应用能接收的范围。示例predicate function如下

 1 create function [dbo].[predicate_myfilter_rls]
 2 (
 3     @orgid nvarchar(200)
 4 )
 5 returns table
 6     with schemabinding
 7 as
 8 return
 9    select top 1 1 as accesspredicateresult
10    from dbo.[user] a
11    where
12        a.userid = session_context(n'userid')
13     and
14       (
15         a.orgid = @orgid or a.orgid = '0000000000000000000000'
16       )
17 go

 


关于性能问题的佐证,可以参考《row-level security for middle-tier apps – using disjunctions in the predicate

由于性能问题的障碍, 所以我们放弃了这种实现方式。但是这种方式比较优雅的满足了上述的两个条件,即实现了底层数据先筛选的逻辑,也对业务查询方法无侵入。在简单的场景中,应该是一款适合的方案。

 

数据权限筛选(rls)的实现(二) -- 后台rlsstrategy方式实现
另一种做法, 是我们自行研究的rlsstrategy的实现方式。首先我们了解下接口irlsstragety

 1 public interface irlsstragety<tentity, tuserconstraintentity>
 2 {
 3     expression<func<tuserconstraintentity, bool>> userpredicate
 4     {
 5         get;
 6     }
 7 
 8     expression<func<tentity, object>> outerkeyselector
 9     {
10         get;
11     }
12 
13     expression<func<tuserconstraintentity, object>> innerkeyselector
14     {
15         get;
16     }
17 
18     bool skip();
19 }

 

这里面提供了三个表达式和一个bool 方法判断是否要略过rls筛选。
下面是一个基本的实现:

 1 public class genericuserorgrlsstragety<tentity, torguser> : irlsstragety<tentity, torguser>
 2 where tentity : class, iuserid
 3 where torguser : class, iorguser
 4 {
 5     private readonly iorgprovider userorgprovider;
 6     public genericuserorgrlsstragety(iorgprovider userorgprovider)
 7     {
 8         this.userorgprovider = userorgprovider;
 9     }
10 
11     public virtual expression<func<torguser, bool>> userpredicate
12     => user => user.orgid == userorgprovider.currentuserorgid;
13 
14     public virtual expression<func<tentity, object>> outerkeyselector
15     => entry => entry.userid;
16 
17     public virtual expression<func<torguser, object>> innerkeyselector
18     => user => user.userid;
19 
20     public virtual bool skip()
21     {
22         return false;
23     }
24 }

 

下面我来解释下这个逻辑。 假设应用中有这样两张表
t_bizdata(id, bizamount, org) 和t_orguser(org, user), 前者是业务表, 记录了业务数据和所属业务组织的机构,后者是机构人员表,记录了人员和机构之间的关系。 根据这两个表,我们可以实现orga的用户可以查看orga的数据, orgb的用户可以查看orgb的数据

如果不考虑rls, 则查询语句是 

select * from t_bizdata

 


如果考虑rls, 则查询语句是

select a.* from t_bizdata a
   inner join t_orguser b on a.org=b.org
where b.user=@user

 

两者比较,我们发现多了一个限制表和三处灵活点:
1 限制表就是 inner join t_orguser b,
2 灵活点 a) 取左表属性; b)取右表属性; c)取右表条件判断

这三个灵活点就是我们接口定义的三个表达式, 限制表是作为泛型类型传入进来的。

理解了这一点, 我们就可以看看下面这个代码

 1         public static iqueryable<tentity> filterbyuser<tdbcontext, tentity, tuserconstraintentity>(
 2                 this iqueryable<tentity> queryable,
 3                 tdbcontext dbcontext,
 4                 irlsstragety<tentity, tuserconstraintentity> rlsstragety
 5                 )
 6         where tdbcontext : dbcontext
 7         where tentity : class
 8         where tuserconstraintentity : class, iuserid
 9         {
10             if (dbcontext is null)
11             {
12                 throw new system.argumentnullexception(nameof(dbcontext));
13             }
14 
15             if (rlsstragety == null
16                 || rlsstragety.userpredicate == null
17                 || rlsstragety.outerkeyselector == null
18                 || rlsstragety.innerkeyselector == null
19                 || rlsstragety.skip()
20                 )
21             {
22                 return queryable;
23             }
24 
25             
26             iqueryable<tentity> result = queryable.join(
27                        dbcontext.set<tuserconstraintentity>()
28                                 .where(rlsstragety.userpredicate)
29                      , rlsstragety.outerkeyselector
30                      , rlsstragety.innerkeyselector
31                      , (p, q) => p
32                    );
33             return result;
34         }

 

我们都知道queryable 是ef实现查询的对象,它描述了查询的过程,所以我们在原queryable对象的基础上扩充了join逻辑, 从而实现了类似sql 语句的两表inner join查询。 该过程是在分页之前加入的,这样才能保证查询的结果。

 1         public virtual async task<ipaged<tentity>> getpagedlistasync<tentity>(object filter, cancellationtoken cancellationtoken = default) where tentity : class
 2         {
 3             if (filter == null)
 4             {
 5                 filter = new object();
 6             }
 7             ipaged<tentity> result = new paged<tentity>();
 8 
 9             iqueryable<tentity> queryable = getpagedqueryable<tentity>(filter);
10             result.rows = await queryable.tolistasync(cancellationtoken).configureawait(false);
11 
12             iqueryable<tentity> queryableforcount = getcountqueryable<tentity>(filter);
13             result.total = await queryableforcount.countasync(cancellationtoken).configureawait(false);
14 
15             return result;
16         }

 


以上准备工作做好了, 在查询的时候,就可以这样写了:

stragety =
serviceprovider.getservice<myrlsstragety>();

var pagelist = await rlsdatainquirer.getpagedlistasync(filter, stragety);

 

最后, 补充下skip()方法的逻辑。

        public override bool skip()
        {
            string orgid = userorgprovider.currentuserorgid;

            // 如果是信息管理部则跳过关联判断
            return orgid.equals(infosupervisordepartmentorgid, stringcomparison.currentcultureignorecase);
        }

 

我们看到,filterbyuser方法的第19行, 如果skip()返回为true, 则会跳过rls的逻辑。这个主要是为了特殊处理高级管理权限设计的。

 

总结:

     使用security policy 除了可以过滤用户权限数据外, 还可以用于更新和删除数据时的权限检查; 而使用rlsstrategy则只能基于现有的框架来实现查询数据行时的筛选,但是性能上要好很多,而且也比较灵活。同时,因为底层是转换成了sql语句,所以对字段加索引应该可以进一步提高查询的性能。