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

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

                    经过以上步骤,D 机构可以获得相应的访问权限进行资源访问,以查看其请求资源的相关信息,比如产品价
                 格、配置信息等等.当然,D 机构也可能因为提交的属性不满足 B 或 C 的策略要求而导致访问失败.
                    D 作为访问主体所具有的属性是其本身所具有的,无需系统预先为 D 分配权限,D 能否获得某资源的访问
                 权限,首先取决于 D 所具有的属性能否满足其所访问资源的属性要求.对于不断变化的数据,使用不断扩展的属
                 性对其恰当描述.随着对某一实体的属性描述增加,ABAC 策略数目呈线性增长.例如在上文给出的 C 机构策略
                 中,主体等级大于等于 3(s_Level≥3)即可访问资源等级为 private 或 public 的商品(r_Level≤private),一条策略即
                 可满足要求.如果使用 RBAC,除了需要预先为不同的主体分配明确的角色外,还需要根据主体的角色制定相应
                 的策略,见表 2,等级为 3 级的零售商的权限需要指定两条策略.权限列表会随着零售商角色的增多呈指数增长.

                                      Table 2    Relationship between RBAC role and permissions
                                               表 2   RBAC 角色和权限对应关系

                                         角色 Roles              权限 Permissions
                                         1 级零售商         可以访问资源等级为 public 的商品
                                         2 级零售商         可以访问资源等级为 public 的商品
                                                        可以访问资源等级为 public 的商品
                                         3 级零售商
                                                        可以访问资源等级为 private 的商品
                    请求域可以选择将具体请求使用资源拥有域的公钥加密处理,若请求多个安全域同类型资源的访问权限
                 时,则需要分别用他们的公钥加密,封装成多个事务请求发送,有效保障安全域的隐私性;请求域也可以选择不
                 加密,那么所有拥有该资源的安全域均可以响应该请求,如果均同意授权,请求域可以获得所有该资源相关的访
                 问权限.资源 url 由资源拥有域自主决定是否授予请求域,一旦发现区块链网络中有恶意节点根据属性构造恶意
                 请求时,被请求域可以拒绝分享资源 url,在访问控制策略由资源拥有域制定并维护的条件下,进一步提高安全
                 域的自主性,有效保障资源安全.
                    综上所述,本文所提出的基于区块链的域间访问控制模型能够适应于很多以多域环境为背景的应用场景
                 中,为域间数据共享提供了一种更安全、更主动、更灵活、更细粒度、扩展性更高的访问控制模型.
                 4    实验分析

                    本文基于 Hyperledger Fabric [32] 实现了原型系统.Fabric 是一种商用区块链框架,它所具有的高度模块化、
                 支持多种编程语言的智能合约、可插拔共识机制的特点令其应用的场景更加广泛.在上述实例场景中,各安全
                 域通过 Fabric 提供的配置文件进行设置,以组织的形式加入同一个通道(channel)中,共同维护一条联盟链,非常
                 符合本文模型应用的前提.在各安全域以联盟形式参与维护区块链后,通过链码(智能合约)为各域的访问控制
                 提供属性、策略查询或策略判定服务.
                    本文实验环境具体为 64 位 Ubuntu 18.04 操作系统,4G 内存,Intel(R) Core(TM) i5-4590@3.30GHz 处理器,
                 Hyperledger Fabric 版本为 1.40,Docker 版本为 19.03,go 版本为 1.12.9.本文分别测试策略数量为 1000,2000,3000,
                 4000,6000 的查询效率和策略判定时间.需要说明的是:测试所用数据库为 CouchDB,且仅限于本文所述算法,对
                 于如何提高底层数据库的查询效率并不是本文讨论的重点;同时,如何从底层方面提高整体查询效率需要进一
                 步研究.
                    查询效率体现在查询时间的长短,重点在于和未使用布隆过滤器的查询方法进行对比.根据上文对于布隆
                 过滤器相关内容可知:当 m/n 越大时,误判率越低,且哈希函数的个数对于误判率的影响会随着哈希函数的增加
                 而降低.图 9 为哈希函数个数 k 和误判率的关系,可以看出:当 k>5 时,误判率下降极为缓慢且在可接受范围内,
                 故本文使用 k=6 进行查询效率测试.图 10 为使用布隆过滤器和常规方法的查询时间比较.
                    策略判定时间体现在策略响应请求的平均时间长短.本文随机选择 20 条请求,每条请求中属性个数为 5,重
                 点测试时间和策略数目的关系,重复 50 次实验取平均值.如图 11 所示.可以看出:随着策略数的增加,策略判定的
                 平均时间增加,且增长率较快.
   331   332   333   334   335   336   337   338   339   340   341