Role-based access control policy administration

Role-based access control policy administration
复制标题

基于角色的访问控制策略管理

DOI:
--
复制
发表时间:
2004
期刊:
影响因子:
--
通讯作者:
András Belokosztolszki
András Belokosztolszki
中科院分区:
--
文献类型:
--
作者:
András Belokosztolszki

文献摘要

被引文献

相似文献

Internet的广泛普及对访问控制策略规范提出了新的要求。由于组织之间需要特别的合作,应用程序不再彼此隔离;因此,访问控制策略面临着一个庞大的、异构的、动态的环境。策略在保持其主要功能的同时,会随着环境的变化而进行许多小的调整。在本文中,我们研究了基于角色的访问控制(RBAC)策略的长期管理,特别是OASIS RBAC策略。为了封装策略的持久目标,我们以元策略的形式引入了扩展。这些元策略的预期生命周期长于单个策略的生命周期,它们包含有关策略的额外信息和限制。期望在策略规范时检查连续的策略版本,以确保它们符合元策略设置的需求和指导方针。在三类元策略中的第一类中,我们通过使用上下文标签对策略组件进行注释来将它们组合在一起。基于这种分组和上下文标签上的信息流关系,我们限制了策略组件可能连接到其他组件组的方式。我们使用它来划分概念上完全不同的策略部分,并引用这些一致的部分来指定策略限制和策略执行行为。在我们的第二类元策略—遵从性策略—中,我们在抽象策略模型上指定需求。然后将其用于静态策略检查。由于遵从性测试是在策略规范时执行的,因此遵从性策略可能包含一些限制,这些限制要么不能包含在策略中,要么包含这些限制会降低策略执行性能。我们还指出了如何使用遵从性策略在不泄露敏感信息的情况下提供有关组织策略的信息。元策略的最后一类称为接口策略,它通过允许组织使用彼此策略中的组件来帮助组织之间建立和维护合作。基于遵从性策略,它们使用抽象策略组件模型,并且还可以为组件导出者和导入者指定需求。使用这样的接口策略,我们可以自动协调合作各方之间的兼容性问题。最后,在我们的元策略的基础上,我们考虑了策略的演变和自我管理,据此,我们将RBAC策略视为分布式资源,通过RBAC本身的帮助指定对其的访问。这支持由许多具有不同权限、信任和管辖权的管理员维护策略的环境。我们已经在Desert中测试了所有这些概念,我们的概念验证实现。
The wide proliferation of the Internet has set new requirements for access control policy specification. Due to the demand for ad-hoc cooperation between organisations, applications are no longer isolated from each other; consequently, access control policies face a large, heterogeneous, and dynamic environment. Policies, while maintaining their main functionality, go through many minor adaptations, evolving as the environment changes. In this thesis we investigate the long-term administration of role-based access control (RBAC) – in particular OASIS RBAC – policies. With the aim of encapsulating persistent goals of policies we introduce extensions in the form of meta-policies. These meta-policies, whose expected lifetime is longer than the lifetime of individual policies, contain extra information and restrictions about policies. It is expected that successive policy versions are checked at policy specification time to ensure that they comply with the requirements and guidelines set by meta-policies. In the first of the three classes of meta-policies we group together policy components by annotating them with context labels. Based on this grouping and an information flow relation on context labels, we limit the way in which policy components may be connected to other component groups. We use this to partition conceptually disparate portions of policies, and reference these coherent portions to specify policy restrictions and policy enforcement behaviour. In our second class of meta-policies – compliance policies – we specify requirements on an abstract policy model. We then use this for static policy checking. As compliance tests are performed at policy specification time, compliance policies may include restrictions that either cannot be included in policies, or whose inclusion would result in degraded policy enforcement performance. We also indicate how to use compliance policies to provide information about organisational policies without disclosing sensitive information. The final class of our meta-policies, called interface policies, is used to help set up and maintain cooperation among organisations by enabling them to use components from each other’s policies. Being based on compliance policies, they use an abstract policy component model, and can also specify requirements for both component exporters and importers. Using such interface policies we can reconcile compatibility issues between cooperating parties automatically. Finally, building on our meta-policies, we consider policy evolution and self-administration, according to which we treat RBAC policies as distributed resources to which access is specified with the help of RBAC itself. This enables environments where policies are maintained by many administrators who have varying levels of competence, trust, and jurisdiction. We have tested all of these concepts in Desert, our proof of concept implementation.