Page 334 - 《软件学报》2021年第5期
P. 334

1558                                     Journal of Software  软件学报 Vol.32, No.5,  May 2021

                    (3)  策略判定合约 PDP Contract
                    策略判定点 PDP 用于对访问控制策略的判定,最终结果为允许访问 Permit 或者拒绝访问 Deny.当 AAR 中
                 的属性和属性值分别满足某一策略中的属性和属性值的谓词或约束时,称此访问请求满足该策略,即属性相同
                 且属性值符合策略谓词或约束条件,最终根据策略的判定结果为 Permit 或 Deny.否则,当 AAR 中所提供的属性
                 信息不足或存在不满足策略中属性谓词或约束的,最终结果为 Unknown.在本文策略结果判定中,对判定为
                 Unknown 的请求最终以 Deny 为授权结果.PDP Contract 用于访问控制的判定.
                    PDP Contract 伪代码如下所示.
                    算法 4.
                    输入:AAR,Policy.
                    输出:策略判定结果(result).
                    Begin
                    Req_xAttrVp_Set=AAR.xAttrVp_Set, Rule=Policy.Rule;
                    //判断请求属性是否包含策略属性
                    if (Policy.pAttr_Set(xAttr_Set)⊆Req_xAttrVp_Set.xAttr_Set){
                    //判断请求是否满足策略规则
                      for (i=0; i<Rule.length; i++){
                      if (Req_xAttrVp_Set.xAttr==Rule[i].xAttrVp_Set.xAttrVp.xAttr
                    && Req_xAttrVp_Set.attrValue∝Rule[i].xAttrVp_Set.xAttrVp.attrValue)
                    results[i]=Rule[i].Result;
                      }//end for
                    //合并策略集结果
                      result=Conbining(results[⋅],CombiningAlgorithm);
                      return result;
                    }
                    else
                      return null;
                    End

                 3    实例分析

                    本节以某零售行业供应链中各机构交互作为实例进行分析.在零售行业内,各机构处于不同地理位置,且存
                 在协作关系,这就需要各机构之间进行频繁的数据共享和信息交互,但每个机构由于在供应链的分工不同而无
                 法共享所有数据,因此,各机构需要根据自己的安全需求制定访问控制策略.同时,行业内数据具有一定的通用
                 性,并且数据的爆炸增长所带来的海量性和动态性,均使本文所述模型可以恰当地应用于此类场景,具体如下.
                    A,B,C,D 为同一零售行业内的 4 家机构,其中,A 为供应商,B,C 为中间商,D 为零售商,各机构将属性和访问控
                 制策略存储在共同维护的区块链中.各机构供货关系如图 8 所示.
                    在同一行业内,各机构对实体的描述相似,因此在本系统中,各机构共同协商对实体的属性标准,但各机构
                 在策略中对实体描述的属性集不相同,例如,A 作为供应商,使用如下属性集对策略中的实体进行描述:
                                         {s_ID,s_Role,s_Name,r_Name,r_Level,a,e_Time},
                 其中,s_ID 表示主体 ID,s_Role 表示主体角色,s_Name 表示主体名,r_Name 表示资源名,r_Level 表示资源等级,a
                 表示操作,e_Time 表示访问时间.
                    B,C 作为中间商,对访问该资源的主体要求提供更多的属性,例如,B 在上述属性集合基础上增加了环境属
                 性约束 e_Location(访问地点);C 在上述属性集合基础上增加了主体属性 s_Level(主体等级),而对于新增加的数
   329   330   331   332   333   334   335   336   337   338   339