基于角色的访问控制会话控制对动态互斥角色进行了授权审查，保证健康信息系统的安全性

医学信息学解锁27（2021）100780放松的基于角色的访问控制会话控制实现对健康信息系统上动态互斥角色属性Marcelo Antonio de Carvalho Junior*，Paulo Bandiera-Paiva巴西圣保罗联邦大学A R T I C L EI N FO保留字：访问控制正式描述系统安全评估A B S T R A C T基于角色的访问控制（RBAC）会话控制用于系统内受控对象的授权审查，以检查用户预期的操作是否被他/她拥有的关联角色所允许。会话控制还用于通过动态互斥角色（DMER）强制执行职责分离（SoD），由于其冲突的权限性质，限制在会话期间可以与特定用户相关联的角色。由于对RBAC标准的可能解释，规定会话控制功能以防止将冲突角色分配给用户的RBAC要求可能无法很好地实现。这种松散的解释是在这里讨论的评估RBAC功能的文字描述和目标，并正式说明不同的解释，使用Z符号和有色Petri网（CPN），以有效地证明所产生的功能和它的反射系统使用。讨论了三个不同方面的安全属性比较的解释和对RBAC功能的影响：a）用户的授权特征对系统的会话的含义，b）实际的DMER冲突检测能力，和c）考虑RBAC管理员能力的可能的共谋情况。正式定义了两种不同的RBAC会话控制功能的解释，充分利用其内部功能和系统上的预期行为的调查。的功能的评估，以突出的模糊性，可能导致不太安全的实现，以便提供一个更强大的RBAC描述，可以应付更严格和可预测的行为对健康信息系统（HIS）。在系统上执行不良会话控制的结果包括无法满足医疗保健公司的安全策略，甚至由于没有对用户交互施加预期的限制和约束而1. 介绍基于角色的访问控制（RBAC）作为卫生信息系统（HIS）授权审查的主要访问控制组件的实现是相当普遍的[1]。这种以管理员为中心的访问控制允许通过对用户可以执行的任务数量施加限制（反映在分配的角色中）来实施医疗保健组织安全策略。在HIS上实现RBAC的优点在于，可以使用权限分配（PA）来创建与角色上反映的特定医疗保健专业人员职责相关的特定权限。PERMS是权限的矩阵表示，其中包含以链接到角色的访问列表（ACL）形式情况下多个职责和责任，由于医疗保健日常事务的复杂性，而且由于医疗保健组织驱动的需求，有时这些特定角色实际上是由同一专业人员执行的，因此是由同一RBAC用户执行的。当授予同一用户的角色中描述的权限中存在冲突操作时，就会出现安全问题[4]。根据安全观点，冲突授权意味着那些将使用户受益的行为，降低系统实现适当和公正验证的能力，甚至允许用户的不道德行为。一个典型的例子是系统上的* 通讯作者。电子邮件地址：carvalho. unifesp.br（M。 Antonio de Carvalho Junior）。https://doi.org/10.1016/j.imu.2021.100780接收日期：2021年10月4日;接收日期：2021年10月28日;接受日期：2021年10月30日2021年11月2日网上发售2352-9148/©2021的 自行发表通过Elsevier 公司这是一个开放接入文章下的CCBY-NC-ND许可证（http://creativecommons.org/licenses/by-nc-nd/4.0/）中找到。可在ScienceDirect上获得目录列表医学信息学期刊主页：www.elsevier.com/locate/imuM. Antonio de Carvalho Junior和P. Bandiera-Paiva医学信息学解锁27（2021）1007802≥ ≥ ⊆×∈∕∈∀ ∈ ∈∈或后果如果同一个用户能够批准他自己的请求，这两个问题（自利、部分验证和不道德行为）都可能发生。医疗保健专业人员以外的其他人员也可能需要在面向患者的HIS上进行冲突授权隔离。无论是使用常规图形用户界面（GUI）还是通过操作应用程序编程接口（API）[5]，患者和外部用户都可能与系统流程进行交互，从而产生冲突意图。在记录内保持层级关系的HIS允许家庭背景视图和家长控制，可以允许用户代表其子女请求电子健康记录（EHR）导出，但不能从法律责任较低链之外的另一名患者请求导出。在保险公司实施事先授权的情况下，质疑处方治疗权利的外部用户永远不应被赋予允许请求或编辑药物/程序以匹配健康计划所涵盖的药物/程序的角色。应实现的安全属性，以防止这些这种情况被称为职责分离（SoD）[6]。简单地说，SoD是一个原则，即一个敏感的HIS任务需要由两个或更多步骤组成。没有一个用户可以执行关键操作的整个步骤。更一般地说，当关键的HIS流程（例如，药物处方、管理和电子健康记录系统（EHR-S）的检查/审计登记）由““kRBAC应用该逻辑通过角色隔离来实现，其中“SoD在RBAC上的实现是通过互斥角色（MER）来实现的，它将那些权限冲突的角色隔离，因此不能被同一个用户一起使用。用于MER合并的RBAC特性可以静态（SMER）或动态（DMER）提供。我们在这篇文章中的贡献集中在描述RBAC支持功能RC-16 [3]实现中的细微变化，该功能控制用户会话中角色的使用。一个更宽松的解释中描述的RBAC标准的功能被认为是其反射DMER的目标和HIS上的最终结果进行了比较，与RC-16功能的更严格的实施。当然，这里提到的用于在健康信息系统[4]上实施DMER属性的松散RBAC会话控制实现的安全反射只有在医疗保健组织选择为其用户分配多个角色时才能在实践中看到。本文的其余部分分为以下几个部分：a) “RBAC通过声明访问控制属性，解决RBAC中的DMER功能，引用以前的工作和导致本文的主要研究领域的兴趣，向读者介绍知识背景; b）“目标和方法”，其中我们概述了Z符号和CPN声明的使用，以正式描述与会话控制相关的RBAC功能; c）“RBAC会话控制功能和可能的实现解释”比较了针对RC-16功能的RBAC标准要求的两种可能的解释以及对HIS用例例程的导出的含义; d）“讨论HIS 上的RBAC 会话控制改进”，其中我们讨论了由于RC-16 功能的松散实现而可能克服HIS 上的不期望的反射; e）结论。2. RBAC动态互斥角色DMER的原理是防止HIS在会话期间的系统交互期间使用分配给用户的冲突SMER大胆地禁止RBAC管理员在UA期间分配冲突角色，DMER允许更大的灵活性，因为只要在会话期间不使用这些角色，就可以将这些角色授予用户假设用户将登录到HIS以执行过程或操作，然后离开系统。在此期间（会话持续时间），DMER强制执行使用冲突角色因此，MER属性在不同的时刻保持在适当的位置，但是在方法上类似，通过实现检查role-setintersection [3，6]，例如：role-set 2 ROLES，nn，（role-set，n）2. |角色集|2，其中MER（2 ROLES N）是对（role-set，n），强制在mer：MER [7，8]内有效的集合的最小划分。的情况下在DMER中，当用户开始会话时，会话期间的划分强制执行针对角色集：2个名称，因此必须在会话期间通过RC-16功能从PERMS提交其授权集执行.因为RBAC功能向在会话期间呈现所分配角色的用户声明两个有效条件，所以使用“活动角色集”的宽松语义，可以使用完整集来实现HIS，诸如：user ∈ USERS;活动角色集<${ r：ROLES|（user）}; sessionscin∈SESSIONS;或通过允许使用r选择的一部分it，其定义为：使用r∈USERS;活动角色集<${ r：ROLES|（用户名）UA };会话SESSIONS。实现中的这种微妙差异对DMER在会话期间捕获冲突的能力具有显著影响，因为没有什么可以阻止用户选择单个角色，甚至是他/她知道不属于冲突集的那些角色因此，在HIS上激活角色的一种可能的实现方式将导致DMER验证，该验证是依赖于用户的，期望在会话上捕获角色，例如：user_ sessions′= user_ sessions \{user_sessions（user）}{用户会话（user_ sessions（user）会话{session}）}session_roles′= session_roles{session_active_role-set}因此，受到SoD约束的会话（session _ roles）上的结果角色可能永远不会触发DMER。所描绘的DMER流（图1）有助于理解session_roles变量内容的重要性以及HIS实现的影响，这将导致给定用户会话的角色选择。在使用RBAC的HIS上的通用授权审查流中，RC-16函数将基于底层系统会话ID和用户的UA填充变量user_sessions和session_roles。在实际示例中，在HIS上实现动态会话控制的会话持续时间将基于该底层用户的会话特征来限制生存时间[9]。RC-09和RC-34函数分别用于返回分配给该用户的角色集以及来自这些角色的相关权限（角色）。最后，RC-14将检查EHR对象的预期交互是否存在于角色“PA”上。在使用RBAC的SoD感知HIS中，RC-16* 还将检查愿意在会话中激活的角色是否不违反MER存储库中针对该特定会话的任何现有“合并”约束，例如合并x会话_角色|梅尔X|二<、观察不同用户意图的用例场景在来自图1的示例性HIS配置条件下，使用来自相同mer1条件的两个角色的用户意图将触发DMER，从而抑制第二角色（r2）在session_roles中可用，从而导致授权阻止。这是因为超过了由mer的最大基数确定的满足条件3. 目的与方法本文的目的是强调基于角色的访问控制（RBAC）功能，以实施动态互斥角色（DMER）的可能失败的条件。该目标通过陈述在捕获职责分离（SoD）冲突的过程中评估的角色可能受到HIS访问控制实施者的RBAC功能性解释的影响的场景来实现。所使用的方法是比较会话控制需求的两种不同解释（通过模拟执行动画和事件有效性技术[10]），考虑RBAC标准[3]作为参考。每一种解释所产生的实现都被正式描述和模拟，以利用系统流程和RBAC功能的预期行为我们使用ZM. Antonio de Carvalho Junior和P. Bandiera-Paiva医学信息学解锁27（2021）1007803表1图1.一、 在（RC-16）函数执行之后考虑DMER审查的RBAC通用授权决策。4.1. 在UA上使用全套角色的RBAC会话功能E X用于DMER激活的示例性用例场景（基于图1所示的HIS配置）①的人。用户会话EHR RC-16' session_roles上的用户意图结果User100001 Process100001 Process 100001流程1r1、r3、r4阻塞User200003 Process2符号[11]和有色Petri网（CPN）分别用于形式化描述和仿真。CPN模拟的特点是一个简单的用例场景，以说明一个典型的医疗保健用户在会话上的角色激活，并描述RC-16功能，可能会导致不安全的条件。CPN工具用作CPN实现[12]。函数式编程用于模拟所有RBAC函数约束和逻辑，以进行可视化演示。在模拟和视频中，会话控制功能的示例性实现解释了突出差异和含义的实际功能执行，可以在以下位置看到https://bioinfo.unifesp.br/HIS-RBAC/CPN%20Model/Supporting/RC-16.cpnhttps://bioinfo.unifesp.br/HIS-RBAC/CPN%20Model/Supporting/RC-16-1.cpnhttps://bioinfo.unifesp.br/HIS-RBAC/CPN%20Model/Videos/Supporting/RC16.mp4https://bioinfo.unifesp.br/HIS-RBAC/CPN%20Model/Videos/Supporting/RC16.1.mp44. RBAC会话控制函数及其实现如前所述，使用RC-16 [3]函数（在CPN和视频上描述为RC 16.1）在RBAC上轻松实现会话控制可以避免在HIS上设置DMER约束。 这可能是因为RBAC实现依赖于要在实施RBAC身份感知实现（SMER/DMER）的DMER属性之前填充的session_roles对象。下面讨论RBAC标准的这两种可能的解释一般来说，从RBAC功能的角度来看，将所有用户的角色激活到他/她的部分与激活一个或多个角色一样合法。当我们查看用于创建会话（RC-16）的函数的RBAC表达式时，会话中的角色是这种不同流的直接结果：解释1（用户：NAME;活动角色集：2个NAMES;会话：NAME）user∈USERS;活动角色集<${r：ROLES|（user r）∈UA};session∈scinSESSIONSSESSIONS′=SESSIONS{ session}user _ sessions′=user _ sessions \ { user_ sessions（user）}{用户会话（user _ sessions（user）会话{ session}）}session_roles′=session_roles{session_active-role-set}会话（1）如图所示，该函数要求用户和会话分别在USERS和SESSION存储库中有效。还检查active-role- set是否是Roles中存在的角色的子集或等同于Roles中存在的角色，以及这些角色是否存在于该特定用户的UA集中。如在该功能的CPN实现中所描述的（图2），使用从UA可用于该特定用户的整个角色集。在上面使用CPN的模拟中，会话请求转换采用用户名和会话模拟函数输入。CST161和FN161使用函数编程来仿真函数约束。最后一个转换FN162用与用户1相关联的所有角色填充session_roles。在例示的CPN流中，设置了角色“主任”和“医师”。因此，将使用会话上存在的活动角色集的DMER约束通常可以用于SoD决策。4.2. RBAC会话功能使用来自UA的单个角色激活然而，在第二种解释中，可以仅考虑该用户的部分UA内容来触发DMER功能。这是因为RBAC子句允许实现者在会话中添加或删除活动角色。session_roles变量填充M. Antonio de Carvalho Junior和P. Bandiera-Paiva医学信息学解锁27（2021）1007804图二、CPN工具上的RBAC Create Session（RC-16）函数表示，考虑来 自 UA 的 全套角色。因此，可以使用用户交互进行角色选择，而不是考虑会话上的活动角色集的UA全集，例如：解释2（用户：NAME;角色：NAME;会话：NAME）user∈USERS;role {r：ROLES|（user）∈UA};sessionscin∈SESSIONSSESSIONS′=SESSIONS{ session}user _ sessions′=user _ sessions \ { user_ sessions（user）}{用户会话（user _ sessions（user）会话{ session}）}session_roles′=session_roles{session_role}（2）在第二种解释中（图3），请注意，输入也将使用用户对角色的选择：名称，这里由连接到最后一个转换FN 162的位置“角色选择”表示。这导致session_- roles直接被用户的意图操纵。在第二个CPN流示例中，对于同一UA，将仅使用“Director”角色激活DMER例如，在select-boX popup上取消选中），因此不会找到SoD• 含义1-用户虽然允许用户选择应在会话期间激活的角色有助于更灵活的HIS实现，但它阻止识别特定的用户配置文件。在分配多个角色的情况下，如果存在授权依赖性，HIS界面（按钮、链接、选项卡、报告等）可能无法完全加载• 隐含2 - DMER冲突检测能力如在填充RBAC函数的session_roles的解释2中所见，DMER直接依赖于会话中的现有角色来识别冲突。因此，如果用户在某个时间选择一个角色（基于每个会话），则可能永远不会触发DMER条件。图3.第三章。 RBAC创建会话（RC-16）功能，考虑用户从 UA 选择角色。M. Antonio de Carvalho Junior和P. Bandiera-Paiva医学信息学解锁27（2021）1007805=含义3 -考虑RBAC管理员能力的共谋场景由于RBAC中的UA是以管理为中心的功能，因此DMER功能也可能被不道德或意外的管理员操作所规避。在HIS中的角色分配可以在医疗保健常规期间进行，由于不稳定的任务和职责负担的专业人员。这可能会导致用户的UA不断变化。由于DMER功能依赖于UA存储库，因此角色的管理会直接影响相关SoD识别不能一起操作的角色的能力。不幸的是，这种管理依赖性还可能导致通过允许分配会故意违反公司安全策略的角色来掩盖误导或非法行为的意图。5. 基于角色访问控制的HIS系统会话控制改进探讨如图所示，对RBAC需求的更宽松的解释可以允许用户操纵会话上的角色激活，这反过来会对在HIS上应用SoD约束的能力产生负面影响。实施者仍然可以使用这种宽松的解释，只要在初始会话_角色填充之后提示用于角色选择的交互功能，允许MER约束最初从用户的UA的完整集合接合。除此之外，下面讨论更安全的实现的其他考虑因素。5.1. 持续DMER审查能力RBAC本地会话控制的主要限制之一是缺乏检索会话上特定HIS进程的角色激活历史的能力[13]。也就是说，RBAC上的会话生命周期包括会话销毁，其避免了对用户或使用完整UA集进行的过去激活的保持。 现有的删除过程session_rolessession_roles\{session_roles（session）}相反，可以反馈另一个变量来存储session_roles的过去透视视图，就像我们之前建议的那样[14]，让我们说session_history。来自参与系统上给定过程实例的用户的多个会话也应该触发SoD阻抗。 理想情况下，受SoD约束的角色的基数函数应通过考虑此历史角色激活（例如2 UA（用户）），将用户映射到特定HIS过程（对象相关）。|session_history（user）|.因此，我们认为，的上述挥发性会话持续时间问题不会干扰DMER冲突的识别。5.2. 同时举行的会议和长期会议与DMER功能相关的另一个重要安全方面是，同一用户可以使用RBAC感知会话控制在HIS上并发登录多次。这是因为RC-16函数依赖于底层系统来控制会话有效性和持久性。因此，来自特定用户的完整UA（session_roles（s_user-sessions（user）将始终在新会话开始时可用，因为RBAC从一开始就没有看到到user_sessions的绑定。在这种情况下，共享凭证的用户或甚至使用不同PC连接到HIS的同一用户可以单独使用现有角色（在解释2场景中），以免在DMER上触发 SoD使用零信任心态的更好方法是可以通过更彻底地应用函数约束来检查用户会话的唯一性，例如：session ∈ scinSESSIONS <$session <$user _ sessions （ user ）<${ session }。5.3. 医疗保健专业多重职责一个关键组件，使其难以遵守SoD最佳实践，并使使用RBAC的HIS更容易出现以下情况DMER无法参与的是角色粒度。这个问题是有争议的，因为它涉及到另一个安全概念和最佳做法，称为“最小风险”。因此，遵循这一原则，应该在角色上实现允许执行特定任务的绝对数量的权限。这是为了防止用户持有不必要的授权。但是，由于医疗保健场景非常复杂，并且有许多任务需要同一用户在HIS上执行，因此该概念实际上可能导致与用户相关联的大量角色。因此，我们在本文中强调了单独选择角色的6. 今后工作我们目前正在研究可能的替代方案，通过使用CPN模拟不同的访问控制流和SoD约束适用条件来降低DMER计算复杂度[15，16该研究还包括使用模糊集理论[17]比较各种用户授权查询（UAQ）技术[16]和RBAC中非常规职责分离策略方法的内部计算工作量。我们的目标是通过利用更有效的PA构造来降低LSA算法的复杂性，从而使得能够通过非常角色创建阶段来指示冲突7. 结论通过DMER功能在RBAC会话上实现的SoD安全特性依赖于RC-16函数来执行正确填充“session_roles”变量内容。正如对RBAC的RC-16功能需求的不同解释的实现所证明的那样，该功能需求将会话控制功能添加到该访问控制中，该可变内容直接受到功能输出的影响。用CPN来描述不同的解释的两个模拟显示了完全不同的函数行为。这里描述的第二个函数解释表明，在会话期间选择要激活的角色期间允许用户交互可能导致双重事件。一方面，它可以为医疗保健组织增加更多的灵活性，因为同一个用户可以在授权和授权方面采取不同的行动。然而，从另一方面来看，这种能力可以规避用户行为无意或有意施加的限制。即使使用由RBAC NIST标准描述的功能，并且因此不执行非法的功能操作，来自HIS开发者的RC- 16功能要求和行为的更宽松的解释也可能导致DMER约束不能被触发的情况。在某些情况下，会话授权的访问控制实现可能会破坏医疗保健公司的安全策略。竞合利益没有人申报。不适用。缩写HIS健康信息系统RBAC基于角色的访问控制CPN有色Petri网EHR电子健康记录EHR-S：电子健康记录系统GUI图形用户界面应用程序编程接口NIST国家标准与技术·M. Antonio de Carvalho Junior和P. Bandiera-Paiva医学信息学解锁27（2021）1007806=MER互斥角色SoD职责分离ACL：访问控制列表PC个人电脑LSA线性搜索算法作者Carvalho MA deJ.起草了手稿，并提供了概念，CPN设计和初步建议，Bandiera-Paiva P.提供了CPN模拟和案例研究解释，验证和一般审查。伦理批准和参与同意不适用因发表同意书不适用因资金我们要感谢CAPES [政府协调机构提高高等教育人员]及其与圣保罗联邦大学（Unifesp）的合作伙伴关系赞助这个项目。数据和材料项目https://bioinfo.unifesp.br/HIS-RBAC/引用[1] Ferraiolo DF，Cugini JA，Kuhn DR，基于角色的访问控制：特征和动机。NIST;1995年。[2] Sandhu R，Ferraiolo DF，Kuhn DR.基于角色的访问控制的NIST模型：走向统一标准。第五届ACM基于角色的访问控制研讨会，2000年7月26日至27日。p. 47比63 柏林[3] INCITS 359-2012信息技术-基于角色的访问控制。美国国家标准学会。;（可在http://webstore.ansi.org/购买; 2012年。[4] 布洛贝尔湾电子健康记录系统的授权和访问控制IntJMed Inf 2004;73（3）.[5] [10]杨文辉，李文辉，李文辉. 部署面向患者的应用程序编程接口：卫生系统经验的主题分析。J Med Internet Res 2020;22（4）.[6] Uddin M，Islam S，Al-Nemrat A.一种基于授权流程和任务角色的动态访问控制模型。 IEEE Access 2019;7.[7] Aftab MU，Qin Z，Hundera NW，Ariyo O，Zakria，Son NT，et al.基于权限的动态角色访问控制模型中的职责分离。对称（巴塞尔）2019;11（5）。[8] 卢J，周J. 基于角色的访问控制中职责分离策略的规范和实施。2011. 2135-40[9] MühlbacherJR，Praher C. DS RBAC-基于角色的访问控制中的动态会话JUnivers Comput Sci 2009;15（3）.[10] SargentRG. 仿真模型的验证和确认J Simulat 2013;7（1）.[11] YuS，Brewster JJ. 基于SOD的RBAC模型的形式化描述与实现。J Softw 2012;7（4）.[12] 范德阿尔斯特WMP，斯塔尔C。业务流程建模-面向Petri网的方法。麻省理工学院出版社; 2011.p. 四百[13] 王东，刘伟，陆军，马新.基于角色访问控制模型中职责分离策略的历史约束。2009年电子商务和信息系统安全国际会议，EBISS 2009; 2009。[14] Carvalho MA deJ，Bandiera-Paiva P.通过有色Petri网（CPN）建模评估ISO 14441基于角色的访问控制（RBAC）限制模式的隐私要求。Proc-Int Carnahan ConfSecur Technol 2017：1 2017年10月。[15] 李宁，崔普尼塔拉MV，比兹里Z.关于相互排斥的角色和职责分离。ACM传输信息系统安全[Internet] 2007;10（2）：5-es.网址：http：//portal. acm.org/citation.cfm? doid1237500.1237501。[16] Armando A，Gazzarata G，Turkmen F.对UAQ求解器进行基准测试。ACMSymposium on Access Control Models and Technologies（ACM访问控制模型和技术研讨会）SACMAT; 2020.[17] 作者：Jalili R.基于模糊关系的角色访问控制模型中的职责分离。第三届国际研讨会Inf Assur Secur; 2007。第125-30页[互联网]，http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm? arnumber = 4299762。五百块