医疗云环境下访问控制增强模型

陈英杰， 沈济南， 梁 芳， 许振武， 胡俊鹏,

(1.湖北民族大学 信息工程学院 湖北 恩施 445000；2.四川大学 网络空间安全学院 四川 成都 610207)

0 前言

在我国，医疗资源的错位导致医院级别呈正三角形分布，而相应门诊量呈倒三角形分布。群众对优质医疗的追求导致“排队三小时，看病三分钟”的现象普遍发生。究其原因：一是患者对于医疗服务的要求日渐提高，对医疗服务质量与水平有更高的要求；二是医疗资源及医疗信息共享不充分，形成了医患间信息严重不对称现象。

随着云计算技术的发展以及在国家层面医改政策的驱动下，打通不同医疗机构间的数据孤岛，构建基于云计算的互联网医疗健康平台，实现医疗数据共享，已成为未来医疗信息化发展趋势。医疗云平台以网上远程复诊为依托，整合不同的医疗服务机构资源，优化医疗配置，缓解“看病难、看病贵、看病烦”的问题。医疗机构自身有完备的医疗管理信息系统，医疗云平台除了构建自身的业务流程外，还需要和现有的医疗机构，如药店、保险服务、支付机构、查询机构等进行对接，由此，安全问题显得尤为突出。

1 医疗云平台访问控制需求

对于已有平台安全的整体需求，从系统层面基于角色的访问控制(role-based access control，RBAC)模型，提出了基于密码学的访问控制(cryptographic access control，CAC)增强模型。

云环境下的访问控制趋于将传统的访问控制与密码技术结合。CAC是对某些元素或功能进行加密的访问控制形式。在访问控制概念出现之前，密码学的首要目的就是在信息被传输时以及在信息处理的其他阶段，保护信息的机密性。在访问控制的显式连接中，密码技术只是后来才被使用。许多能够进行细粒度访问控制的通用CAC系统已经存在了一段时间，但目前还没有CAC实际是什么的具体定义。

在综合分析表1现有CAC基础上，给出了CAC普适性定义[1-3]。CAC是一种访问控制实施方法，涉及应用层信息对象的加密转换，目的是防止对对象的未经授权的操作。假设信息对象独立于它们的呈现、存储、处理和传输类型、状态和技术，如果密钥管理涉及加密转换，并且密钥本身形成了与环境无关的信息对象，则不能排除CAC之外的环境相关信息对象的密钥管理。在这种情况下，密钥管理对象将受到CAC的保护。在更受限制的环境中，CAC的更正式定义的例子包括基于约束的角色访问控制(constraint based role based access control，CRBAC)[4]，其将RBAC建模为多方计算游戏，并定义正确执行策略的安全保障。

表1 CAC普适性定义需求

CAC是研究访问控制的主要工具，在大多数CAC设置中，重点是加密实际内容。然而，大量研究工作的动机是将密码支持扩展到其他访问控制模型元素，而不仅仅是实际的访问检查。

医疗云平台构建过程中，涉及不同的医院、药店、卫生组织等机构，用户具有多样性，上述CAC的访问控制场景并不适合医疗云平台。为此，提出了基于RBAC的访问控制增强模型。

2 基于RBAC的访问控制增强模型

2.1 访问控制增强模型

为了解决医疗云平台下的数据安全问题，需要将访问控制策略与加密机制进行结合，以应对云环境下数据存储过程中的隐私泄露问题。一方面，访问控制策略对用户身份进行认证，可以保证数据的合法访问，但明文存放的数据云服务提供商(cloud service provider，CSP)可访问，不能保护数据的隐私；另一方面，通过加密机制对数据进行加密处理，通过控制密钥的分发可以进一步加强访问控制。医疗云平台访问控制模型如图1所示。

图1 医疗云平台访问控制增强模型

平台基于RBAC模型，实现对系统合法用户的访问控制及授权，采用加密方法以确保云平台中数据的机密性。

系统管理模块在系统初始化阶段运行，实现用户、角色的创建，并产生角色对应的公共信息以及用户和角色的私钥。

角色管理模块管理系统中每个角色对应的用户，将用户和角色之间建立关联，实现角色中用户的增加及删除操作，角色对应的通用权限分配由系统管理初始化。

数据所有者使用其所属角色的公共参数对数据进行加密存储，同时向角色管理模块请求将数据加密到对应角色。角色管理模块在其控制用户到角色映射的功能中，决定将哪些用户分配给角色，哪些用户排除在外。

数据请求者使用系统提供的解密密钥和角色的公共信息解密云端的密文。当数据请求者是该数据加密角色的成员，或者数据请求者所属角色继承了密文加密角色时，能正确解密。

2.2 RBAC模型设计

RBAC0是最基本的核心模型，包含用户(user)、角色(role)、权限(permission)、对象(object)、操作(operation)等基本元素[5]，其中：静态职责分离(static separation of duty, SSD)对用户可以同时被分配到哪组角色设置限制[6]。

定义1(核心RBACO)对于给定的对象、操作、权限、用户、角色及会话集合，定义关系及映射如下。

UA⊆U×R具有特定的映射UA.M:R→2U，如果U′⊆U,r∈R且U′=UA.M(r)，则(∀u∈U′):∈UA。

对象权限为PA，对象映射为OBJ.m，操作映射为OPS.m，会话用户映射为SU.m，会话角色映射为SR.m，则PA⊆P×R，OBJ.M:P→2OBJ(映射的范围是对象的幂集)，OPS.M:P→2OPS，SU.M:S→U，SR.M:S→2R。如果R′⊆R,s∈S且R′=SR.M(s)，则(∀r∈R′):∈UA，SP.M:S→2P。

UA的映射关系表明，用户具有的角色组只能由系统的角色管理机构分配，而不能由用户选择系统分配外的其他角色。

角色继承使系统中角色的管理更贴近于现实生活中的组织层次关系[7]，继承关系可以分为广义继承和有限继承。RBAC1被认为是在RBAC0的基础上增加了角色继承关系。

定义2(RBAC1)对于偏序关系RH⊆R×R，记为≥，如果r1,r2∈R，且r1≥r2⟹AP.M(r2)⊆AP.M(r1)∧AU.M(r1)⊆Au.M(r2)，AU.M和AP.M满足如下描述。

(1)存在角色继承结构的授权用户AU.M:R→2U，如果U′⊆U,r1,r2∈R,r1≥r2，并且U′=AU.M(r2)，有∀u∈U′:∈UA。则表明该用户分配到了该角色及其所有继承的角色。

(2)角色继承结构中存在的授权权限：AP.M:R→2P，如果P′⊆P,r1,r2∈R,r1≥r2，并且P′=AP.M(r2)，有∀p∈P′:∈PA。则表明该权限分配给了该角色及其所有继承的角色。

另外，如果∀(r,r1,r2∈R):(r≥r1)∧(r≥r2)⟹r1=r2，则称该继承关系是有限继承，否则为广义继承。

RBAC标准还涉及如何处理职责分离的规范。职责分离可以静态或动态地完成，这些都被称为RBAC中的约束模型。RBAC标准模型中的SSD指的是对UA关系的约束，而动态职责分离(dynamic separation of duty, DSD)指的是对激活角色或SR.M关系的约束。

定义3(RBAC2)Constrained RBAC由RBAC0、角色继承和以下关系组成[8]。

(1)在角色继承结构中，SSD⊆2R×N是由〈rs,n〉组成的集合，其中，n≥2，且

(2)DSD⊆2R×N是由〈rs,n〉组成的集合，其中，n≥2，∀(rs∈2R,n∈N)，∈DSD必须满足：|rs|≥n；∀(s∈S,rs,rs′∈2R,n∈N):[∈DSD∧rs′⊆rs∧rs′⊆SR.M(s)]⟹|rs′|

对于SSD来说，不应该给任何用户分配超过rs中列出的n-1个敏感角色。在一些模型中，n在所有情况下都被严格限制在2以内，但是在ANSI标准中[9]，这被认为是过于严格的限制。在DSD中，定义基本上意味着对于rs中列出的敏感角色，同一时间最多可以激活n个。

从某种意义上来说，DSD更多地基于一种称为及时撤销信任的最小特权原则，在RBAC约束模型中，如果没有DSD概念，这种原则很难实现，也容易出错。

根据ANSI标准，合规性是通过实施功能规范的核心集来实现的，这种实现需要完成标准定义的核心RBAC命令。这些命令包括管理命令、系统支持功能及审查功能。

RBAC概念支持最小权限、职责分离及数据抽象原则。较好地解决了DAC和MAC由于各自特点产生的局限问题。但随着计算环境和网络环境的不断发展变化，RBAC的局限性也逐步显现出来，进而也出现了基于RBAC核心思想发展起来的其他访问控制模型，包括基于任务的访问控制模型、面向分布式和跨域的访问控制模型、时空相关的访问控制模型、基于安全属性的访问控制模型及基于加密的访问控制模型等。表2给出了RBAC2中管理命令及系统支持功能的描述。

表2 RBAC2命令及描述

为实现基于角色的访问控制，构建4个数据表，表之间关系如图2。

图2 医疗云平台权限数据表关系

(1)ac_item数据表：用于记录角色、权限、路由信息(用户对系统功能URL访问的路径)。

(2)ac_item_child数据表：用来记录权限、路由、角色之间的关系，一般记录内容为某个权限对应哪几个路由，或者某个角色对应哪几个权限。

(3)ac_assignment数据表：用于给用户绑定角色或权限。

(4)ac_rule数据表：规则表，用来记录角色或者权限能否成功执行。

以上四个数据表为权限管理基本表，此外还有对应的用户表，诸如管理员表(user表)、医生表(doctor表)及患者表(patient表)等。

系统权限的管理遵循RBAC规范，按照用户-角色-权限的模式进行配置。在角色管理模块，系统管理员登录系统进行系统角色的设置。在权限管理模块，根据不同角色对应的权限进行设置。系统中所有角色的权限都是通过路由的形式进行配置管理，通过 URL及访问规则实现权限控制。

3 增强模型核心算法

3.1 权限路由形成过程

路由模块的功能主要是针对系统中的用户访问路径信息进行维护，既可以检索系统中所有的路由，又可以新增路由。对于实现某些功能操作的路由，根据需求选择将其插入数据库ac_item数据表中，方便后续对已选中的路由进行使用。具体路由形成过程如下。

(1)系统启动会读取主配置文件，找到modules模块。

(2)解析modules模块，如果有子模块则递归遍历子模块，找到所有路径规则。

(3)根据模块路径规则，生成命名空间。

(4)根据命名空间找到模块下面的控制器文件。

(5)在控制器文件中识别出所有的动作函数，即action+动作名。

(6)最终形成“模块/控制器/动作”格式的所有路由。

3.2 增强模型主要算法

Mpp=(q,G,GT,w,v,h,hγ,…,hγN,H1,H2)，

v=e(g,h)，w=gγ；Msk=(g,γ)。

(2)角色创建CreateRole(Msk,RoleId)。创建身份为RoleId的角色，生成角色对应的私钥。

角色的公共参数信息：

角色RoleId中所有的用户集合记作SRoleId。

(3)创建用户CreateUser(Msk,UserId)。创建身份为UserId的用户。生成用户私钥，

(4)为用户分配角色UserAssignment(Mpp,SKRoleIdi,SRoleIdi,UserIdβ)。将UserIdβ分配到RoleIdi角色组。该操作需要更新角色组中的用户成员列表，将UserIdβ添加到集合SRoleIdi中，并形成新的角色公共信息。具体操作如下。

Ki=vri,Ti=g-ti,Wi=w-ri,

Ti送云服务提供商，输出该角色新的公共参数信息，

PIRoleIdi=(RoleIdi,Rpp1RoleIdi,Rpp2RoleIdi,Wi,Vi,Yi,SRoleIdi)。

C4=vz·m，C=(C1,C2,C3,C4)。

(6)数据解密Dec(Mpp,PIRoleIdi,DKUserIdβ,C)。角色RoleIdi的成员UserIdβ解密文档C，L表示RoleIdi所有继承角色RoleIdi的角色集合，包含角色总数为m，U表示L所包含所有角色中的用户的集合，包含用户数为n，则

UserIdβ可以用UK解密文档C。

(7)用户撤销UserRevoke(Mpp,SKRoleId,URoleId,UserId)。将用户UserIdβ从角色RoleIdi中删除，URoleIdi是角色RoleIdi的用户集合，数量为n。

K′i=vr′i,Ti=g-t′i,Wi=w-r′i，

云服务商用T′i替换Ti，并将角色的公共信息替换成PIRoleIdi=(RoleIdi,Rpp1RoleIdi,Rpp2RoleIdi,W′i,V′i,Y′i,URoleIdi)。

3.3 基于PRE的RBAC增强模型

医疗云平台中静态数据的保护采用改进的PRE(proxy re-encryption, PRE)加密机制与RBAC访问控制策略融合，基于RBAC模型，进行用户身份信息的认证及授权管理。增强RBAC模型的访问控制能力，同时实现数据的细粒度访问控制。基于PRE的RBAC增强模型如图3所示。

图3 基于PRE的RBAC增强模型

系统中包含三类主要用户：数据所有者，云服务提供商和数据请求者(可以是任何形式的数据请求发起者，如病人、医生、查询机构、政府部门等)。图3中，给出了RBAC模型中用户、角色、权限、操作以及资源数据表的基本字段的关系描述。

针对云环境下租户数据存储方案各自的特点，结合云环境下医疗平台中静态数据存储的特点，利用改进的代理重加密机制对RBAC访问控制模型进行增强，提出了一种基于安全等级的云租户静态数据保护方案，在保证数据的机密性的同时实现了数据的细粒度访问控制。

该模型中，数据所有者(data owner, DO)需要完成四项任务。

(1)通过(key generation center, KGC)为合法用户产生密钥对；

(2)执行重加密密钥生成算法为合法用户生成重加密密钥；

(3)依据访问控制模型构建用户权限及用户的重加密密钥表User_PREkey；

(4)执行加密算法，完成文档的首次加密。

CSP依据DO提供的用户权限及重加密密钥，执行代理重加密算法，生成重加密密文。数据请求者进行合法身份认证后，完成数据的查询及执行解密算法完成相关数据的解密。

3.4 基于ABE的RBAC增强模型

基于密文的属性加密(ciphertext policy attribute based encryption, CP-ABE)方案由加密者决定解密数据的访问控制策略[10-11]，基于密钥策略属性的加密(key policy attribute based encryption, KP-ABE)中属性访问结构用于描述用户密钥，由接收方制定访问控制策略[12-13]。故而，CP-ABE更适合于应用系统的部署。图4给出了基于CP-ABE的RBAC增强模型。

图4 基于CP-ABE的RBAC增强模型

该模式下，DO构建RBAC访问控制模型，并对需要保护的数据表按照访问结构进行加密处理，CSP根据DO提供的用户权限及访问控制策略进行密钥的分发。

数据请求者进行合法身份认证后，完成数据的查询及执行解密算法，完成相关数据的解密。

代理重加密允许代理将为用户加密的密文转换成重加密密文，该密文可以由不同的用户解密，而不必知道这些用户中的任何一个的私钥。ABE中的代理重新加密已在文献[14-15]中得到解决，ABE-PRE允许用户委托指定用户使用委托用户的相关属性解密代理重新加密的密文。

4 访问控制模型对比分析

医疗云平台访问控制模型需要满足安全性、机密性、最小特权、职责分离、粒度控制、分布式环境等指标。增强模型与前述的访问控制模型进行对比，满足医疗环境下的访问控制需求情况如表3所示。表格中“G”表示满足该项指标或者该项性能较好，“-”则表示目前尚未具有该项性能或者性能不好。

表3 访问控制模型比较

5 结束语

目前，医疗云平台的发展还处在初始阶段，医疗云平台中包含大量的隐私数据，在云计算环境下，传统的访问控制模型无法保障医疗数据的机密性。本文结合医疗云平台的特点，提出了基于RBAC的访问控制增强模型，为医疗云平台下的静态数据安全共享及动态数据安全计算提供安全访问控制支撑，实现对系统合法用户的访问控制及授权，采用了加密方法确保云平台中数据的机密性。未来可尝试用更好的方法实现共享的同时，提高机密性。