基于属性的访问控制（ABAC）定义与思考 ——ABAC的基本概念

本文件为联邦机构提供了基于属性的访问控制（ABAC）的定义。ABAC是一种逻辑访问控制方法，在这种方法中，对执行操作的授权是通过评估与主体、客体、申请操作相关联的属性来确定的，在某些情况下，还会根据描述许可操作的策略的环境条件来确定。本文档还提供了使用ABAC改进组织内部和组织之间的信息共享的注意事项，同时保持对该信息的控制。

关键词：访问控制；访问控制机制；访问控制模型；访问控制策略；基于属性的访问控制（ABAC）；授权；权限。

 第一部分 ABAC的基本概念 

 理解ABAC 

全面理解ABAC需要理解逻辑访问控制的基本原理。逻辑访问控制的目的是保护客体（无论是数据、服务、应用程序、网络设备还是其他类型的IT资源）不受未授权操作的影响，这些操作可能包括发现、读取、创建、编辑、删除和执行客体。受保护客体归个人或组织所有，并具有某种内在价值，激励这些所有者保护它们。作为客体的所有者，他们有责任建立一个策略，来描述可以对客体执行哪些操作、由谁执行，以及主体在什么上下文中可以执行这些操作。如果主体满足客体属主所建立的访问控制策略，则该主体被授权可以对客体执行所需的操作，即该主体被授予对该客体的访问权限。如果主体不满足策略，则拒绝对该客体的访问。

计算机安全架构师和管理员在逻辑上部署访问控制机制（ACM），通过控制来自主体的访问请求来保护客体。ACM可以使用很多方法来执行应用于客体的访问控制策略。ACM可以定义为：

访问控制机制（ACM）：能够接收来自主体的访问请求，并决定和强制执行访问控制决策的逻辑组件。

ACM如何工作可以通过各种逻辑访问控制模型来描述。这些访问控制模型提供了一个框架和一组边界条件，客体、主体、操作和规则可以在这些边界条件上组合起来生成和执行访问控制决策。每个模型都有其自身的优点和局限性，但重要的是要注意这些模型的发展演变过程，以充分理解ABAC模型的灵活性和适用性。

MAC/DAC

伴随着自主访问控制（DAC）和强制访问控制（MAC）概念的出现，逻辑访问控制在20世纪60年代和70年代早期应用于国防部（DoD）的某些项目中。在国防部可信计算机系统评估标准（TCSEC）或“橙皮书”[TCSEC]中有这些术语的详细定义，在[NIST800-53]中也可以找到相关定义。

IBAC/ACL

随着计算机网络的发展，限制对特定受保护客体的访问的需求刺激了基于身份的访问控制（IBAC）的发展。IBAC使用访问控制列表（ACL）等机制来提取那些允许访问客体的身份标识。如果主体提供的身份凭证与ACL中保存的身份凭证匹配，则会授予该主体访问该客体的权限。主体执行读、写、编辑、删除等操作所需的每个权限都由客体属主单独管理。每个客体都有自己的ACL和分配给每个主体的权限集。在IBAC模型中，授权决策是在任何特定的访问请求之前做出的，这就决定了主体也要被添加到ACL中。对于要放置在ACL中的每个主体，客体属主必须根据客体的管理策略，来评估主体的身份、客体和上下文属性，最后决定是否将该主体添加到ACL。这个决定是静态的，而且客体属主需要一个通知机制，以便在需要时能够重新进入评估流程，并从ACL中移除某个主体，来应对主体、客体或上下文变化所带来的影响。随着时间的推移，如果无法删除或撤消访问权限，则会导致用户权限累积。

RBAC

基于角色的访问控制模型（RBAC）[FK92，ANSI359，SCFY96]采用了可分配给主体、具有特定权限集的预定义角色。例如，被分配“经理”和“分析员”角色的主体将能够访问不同的客体集。在这个模型中，访问权限是由为每个个体分配角色的人预先隐式定义的，但最终由客体属主在确定角色权限时明确。在处理主体的访问请求时，访问控制机制需要在执行访问控制决策前，评估分配给主体的角色，以及该角色对客体所拥有的操作权限。请注意，角色可以被视为主体的一个属性，访问控制机制基于对“主体角色”这一属性的计算，生成对客体的策略决策。随着RBAC规范的流行，它减少了对ACL的需求，并使企业访问控制能力的集中管理成为可能。

ABAC

从实施访问控制时所使用的属性来看，ACL和RBAC可以看做是ABAC的特例。ACL使用“身份标识”的属性。RBAC使用“角色”属性。它们之间的关键区别在于ABAC的策略概念，ABAC的策略可以表示为针对多种不同属性的复杂的布尔运算。虽然可以使用ACL或RBAC来实现ABAC的策略目标，但是由于ABAC访问控制的需求与ACL和RBAC模型之间的抽象层次不同，这种实现方式执行起来非常困难，而且代价非常大。ACL或RBAC模型的另一个问题是，如果AC需求发生了变化，可能很难确定所有需要更新的数据在ACL或RBAC实现中的位置。

与ABAC的访问控制框架一致的一个例子是可扩展访问控制标记语言（XACML）[XACML]。XACML模型使用规则、策略、基于规则和策略的组合算法、属性（主体、资源或客体、操作和环境条件）、职责和建议等元素。它的参考体系结构包括策略决策点（PDP）、策略执行点（PEP）、策略管理点（PAP）和策略信息点（PIP）等功能来控制访问。另一个例子是下一代访问控制标准NGAC[ANSI499]。

一般来说，在主体发出请求之前，ABAC避免将权限（“操作-客体”对）直接分配给主体/角色/组。相反，当主体请求访问时，ABAC引擎根据请求者的指派属性、客体的指派属性、环境条件以及根据这些属性和条件指定的一组策略，来做出访问控制决策。根据这种设计，策略在创建和管理时无需直接引用过多的用户和客体，用户和客体也不会直接引用策略。

01

ABAC的优点

在许多AC系统中，逻辑访问控制解决方案主要基于主体的身份。例如，在IBAC或RBAC中，对客体的访问权被单独授予本地标识的主体，或者被授予该主体所属的本地定义的角色。这种AC实现方式通常管理起来很麻烦。在非ABAC的多组织访问方法示例（如图1所示）中，组织A的主体（已通过身份认证）在对组织B的客体发起访问时，需要预先在组织B为其创建身份标识（如账号），并将该身份添加至组织B的访问控制列表。

图1 传统（非ABAC）多组织访问方法

此外，如身份和角色这样的主体信息，在表达现实世界的AC需求时往往不够充分。RBAC根据主体与角色的关联做出策略决策，但它不太容易支持多因素决策（例如，基于物理位置的决策，以及医疗保险可移植性和责任法案（HIPAA）专业培训记录；最近关于HIPAA数据保护的培训可能是查看医疗记录的先决条件）。RBAC通常基于相对固定的组织位置来进行角色分配，在某些需要动态访问控制决策的环境中，RBAC架构就会暴露其不足，因为需要创建大量的临时角色，并限制其成员资格，通常会导致所谓的“角色爆炸”。

为了在AC决策时，避免要求主体预先获悉客体信息，或者客体属主预先获悉主体信息，我们需要一种特殊的方法。通过组织间统一的主、客体属性定义，ABAC避免了将访问权限直接显式地授予某个主体。此外，对于需要耗费大量时间来管理ACL/角色/用户组的大型企业来说，ABAC模型更具灵活性。通过调整主、客体属性定义的一致性，在不影响安全等级的同时，身份认证（主要与主体属性有关）和授权功能（与主、客体属性都有关系）可以在相同或独立的基础设施中实现。

02

ABAC的定义

ABAC的描述方式多种多样。例如，早期一篇关于web服务的论文认为ABAC“基于请求者拥有的属性授予其对服务的访问能力”[WWJ04]，地理信息系统中的安全性讨论将ABAC描述为一种“用与用户相关联的属性值确定用户权限”的方法[CGLO09]。

还有一篇论文将ABAC总结为一个“基于主体、客体和环境属性，并支持强制和自主访问控制需求”的模型[YT05]。所有这些定义的共同点是，ABAC通过将主体属性、客体属性和环境条件结合起来，按照它们与访问控制规则的匹配情况来确定访问（即对系统客体的操作）。以下是ABAC高级别的定义：

基于属性的访问控制（ABAC）：一种访问控制方法，根据主体的指派属性、客体的指派属性、环境条件和与这些属性和条件相关的一组策略，允许或拒绝主体对客体所请求的操作。

属性是主体、客体或环境条件的特征。属性信息以“名称-值”对的形式定义。

主体是人或NPE（如对客体发起访问请求的设备）。主体可以被指派一个或多个属性。在本文档中，假设主体和用户是通过义的。

生成由ABAC系统管理其访问的系统资源，例如包含或接收信息的设备、文件、记录、表、进程、程序、网络或域。它可以是资源或被请求访问的实体，也可以是任何可被主体操作的对象，包括数据、应用程序、服务、设备和网络。

操作是应主体对客体的请求而需要被执行的功能。操作包括读、写、编辑、删除、复制、执行和修改。

策略是规则或关系的表达，它使我们能够，根据给定的主体、客体和可能的环境条件的属性值来确定是否允许主体所请求的访问。

环境条件：访问请求所处的环境/态势上下文。环境条件是可检测的环境特征，独立于主体或客体，可以包括当前时间、星期几、用户位置或当前威胁级别。

高级ABAC定义如图2所示，其中ABAC ACM接收主体的访问请求，然后根据特定策略检查主体和客体的属性。然后，ACM确定主体可以对客体执行哪些操作。

图2 ABAC的基本场景

1)主体请求访问客体

2)访问控制机制评估a）规则，b）主体属性，c）客体属性，以及d）环境条件，来计算策略决策

3)如果被授权，主体可以访问客体

03

ABAC基本概念

在最基本的组成形式中，ABAC主要包括对主体属性、客体属性、环境条件以及访问控制规则或策略（定义了基于主、客体的属性组合的一些允许操作）的评估计算。所有的ABAC解决方案都包含这些用于评估属性的基本组件，并强制执行通过这些属性所生成的策略决策（参见下面的图3）。

图3 ABAC的核心机制

即使在一个小型的独立系统中，ABAC也依赖于主体和客体的属性分配，以及访问规则的设计。系统中的每个客体都必须指派特定的属性，用来描述该客体。某些属性可能属于某个完整的客体实例，例如“所有者”属性。但有些属性可能只能属于客体的某一部分。例如，某个文档客体的属主为组织A，但文档中部分内容的知识产权是组织B的，该文档同时又是组织C所运行的程序的一部分。另一个示例，考虑文件管理系统中位于某个目录中的某个文档。此文档具有标题、作者、创建日期和上次编辑日期等，所有的客体属性都由文档的创建者、作者或编辑者确定，还可以为其指派其他客体属性，如归属组织、知识产权种类、出口管制分类或安全级别。每次创建或修改新文档时，都必须抽取这些客体属性。这些客体属性通常嵌入在文档中，但也可以由专门的应用程序将其提取到一张单独的数据表中，引用合并或管理。

使用系统的每个主体都必须指派特定的属性。以用户访问文件管理系统为例。管理员在系统中将用户映射为主体，并将该用户的特征转化为主体属性。此主体可能有一个名字、角色和组织隶属关系。其他主体属性可能包括美国公民身份、国籍和安全许可等。这些主体属性由组织内负责维护文件管理系统主体标识信息的机构分配和管理。在添加新用户，删除老用户，或者主体（即用户）特征发生变化时，这些主体属性可能就需要更新。

对于系统中的每个客体来说，必须至少存在一条策略，用于描述该客体的访问规则，其中包含所允许的主体、操作和环境条件。此策略通常从描述组织业务流程和运营规范的文档或程序性规章制度派生。例如，医院制度规定只有经授权的医务人员才能访问患者的病历。在实际系统中，如果客体是“类型”属性为“患者病历”的文档，访问控制机制就会筛选出“病历访问规则”并计算策略决策，从而拒绝那些“人员类型”属性为“非医务支持人员”的主体的读取请求。注意，这只是实现属性和规则之间关联的方法之一。

实现主、客体属性绑定的规则间接地指定了特权（即哪些主体可以对哪些客体执行哪些操作）。允许的操作规则可以通过多种计算机语言表示，例如：

 ◆ 用属性和条件的布尔组合来表示特定操作的授权条件

 ◆ 能够把主、客体属性和许可操作关联在一起的某种关系运算

一旦建立了客体属性、主体属性和策略，就可以使用ABAC保护客体。访问控制机制通过限制手段（只有允许的主体能够对客体执行允许的操作）来介入对客体的访问。ACM将策略、主体属性和客体属性组合在一起，然后根据策略中定义的算法计算和执行策略决策。ACM必须能够管理策略的决策和执行流程，包括确定要检索的策略、要以何种顺序检索何种属性以及从哪里检索属性，然后，ACM执行必要的计算以便生成策略决策。

ABAC模型中可实现的策略仅受限于计算机语言的策略表示能力和可用属性的丰富性。这种灵活性使得不必单独指定每个主体和每个客体之间的关系，就可以实现最大范围内的主体对最大范围内的客体的访问控制。例如，一个主体被分配了一组基于工作岗位的主体属性（例如，南希·史密斯是心脏科的护士），客体在创建时被分配了客体属性（例如，包含心脏病患者病历的文件夹）。主管机构制定相应的规则来管理允许的操作（例如，心脏科的所有护士都可以查看心脏病患者的医疗记录）。这种灵活性使得在主体、客体和属性的整个生命周期中，属性和它们的值都可以非常方便地修改。

为受规则集（指定了哪些操作是允许的）控制的主体和客体提供属性的这种做法，使得无限多的主体能够请求对客体执行操作——完全不需要客体属主或规则生成器事先知道主体的任何信息。当新的主体加入组织时，也不需要修改规则和客体。只要主体被分配了访问客体所必需的属性（例如，心脏科的所有护士都被分配了这些属性），不需要对现有规则或客体属性做任何修改。这种特性通常被称为适应外部（非预期）用户，是使用ABAC的主要好处之一。

与其他一些方案相反，在ABAC的定义中，操作没有“属性”。如定义所述“属性是以‘名称-值’对形式所提供的信息”。例如，“read = all”（或“all = read”）都是不合适的。操作可以有许多类型或类别，它们不是“属性”，而是一组固定的值。可以将操作本身设置为“属性名”，例如“operation = read ”，但这将是操作的唯一属性，而且是多余的。

为实现追责能力，需要跟踪特定主体（与特定用户有关）对客体的访问。如果访问决策是基于属性的，但是特定的访问请求和决策不能追溯到主体或用户ID，则可能会失去追责能力。

04

企业ABAC概念

虽然ABAC推动了信息共享，但在企业中部署实现ABAC时，其关键组件会变得更加复杂。随着企业规模的扩大，部署架构中需要复杂的、甚至是独立建设的管理设施，以确保企业范围的一致的信息共享、策略和属性的使用、受控的数据分发，以及访问控制机制的实施。

企业：一组需要相互协作和联合的实体，实体之间要求支持信息共享和管控。

图4展示了部署企业ABAC所需的主要组件。有些企业已具备实施ABAC的基础。例如，大多数企业都有某种形式的身份和凭证管理系统，用来管理主体属性（如名称、唯一ID、角色、许可等）。同样，许多企业可能有一些组织策略或准则来建立访问规则，对访问企业客体的主体进行授权。但是，这些规则通常不是以机器可执行的格式编写的，无法在不同的应用程序中使用。ABAC策略必须以机器可执行的格式实现，存储在策略库中，并发布给ACM使用。这些数字策略包括计算访问控制决策所需的主体和客体属性。企业主体属性必须通过主体属性管理组件创建、存储，并在企业各组织之间共享。同样，企业客体属性必须通过客体属性管理组件建立并绑定到客体。最后，剩下的任务就是部署ABAC访问控制机制。本节的其余部分将详细介绍企业级ABAC的主要组件。

图4 企业ABAC的场景示例

4.1

早期的访问控制模型

自然语言策略（NLP）是策略的高级表达形式，它定义了如何管理信息访问，以及在什么情况下谁可以访问什么信息。NLP用人类可以理解的语言来表述策略，但是在ACM中可很难直接使用。NLP含混不清的语义，使它很难通过形式化的方法，推导出可操作的元素，最终导致企业策略无法编码为计算机可以理解的形式。然而，NLP可能是程序专用的（注：指由/为专门的应用编写），考虑应用系统的情况，NLP适用于定义跨多个应用的主体行为的策略。例如，NLP可能适用于针对组织单位内部或跨组织单位的客体的策略，或者基于知其所需、能力、授权、义务或利益冲突因素等情况下的策略。这些策略可能需要跨越多个计算平台和应用程序。NLP在本文件中定义如下：

自然语言策略（NLP）：用于描述企业客体的管理和访问方式的语句。NLP是可以转换为机器可执行的访问控制策略的自然语言表述。

给出与企业内每个组织都相关的NLP，下一步是将这些NLP转换成一组可以在企业内部ACM中部署执行的通用规则。为了实现这一步，必须先确定策略中需要的主体/客体属性的组合和允许的操作。通常，这些值在不同组织中可能是不同的，因此需要组织间达成某种形式的共识，或者将其映射到每个组织的现有属性中，以实现企业内不同组织间的互操作性。最后，达成一致的主、客体属性列表、许可操作和来自现有组织特定属性的所有映射被翻译成机器可执行的格式。

NLP实现必须包含数字策略（DP）算法或机制。为了提高性能和简化规范，NLP可能需要分解并转换为不同的DP，以适应企业基础设施中已有的功能组件。DP在本文件中定义为：

数字策略（DP）：直接编译成机器可执行代码或信号的访问控制规则。主体/客体属性、操作和环境条件是DP的基本元素，DP规则的编译结果由访问控制机制执行。

多个DP可能需要元策略（Metapolicy）或指导DP使用和管理的策略，来处理DP的分级授权、冲突消除以及存储和更新。MP用于管理DP。根据复杂性等级，基于NLP所指定的策略优先级和组合策略的结构，可能需要层次化的MP。MP在本文件中定义为：

元策略（MP）：与策略相关的策略，或用于管理策略的策略，例如优先级的分配和DP的冲突消除方法或其他MP。

一旦开发定义了DP和MP，接下来需要对它们进行管理、存储、验证、更新、按优先级排序、消除冲突、共享、引退和部署执行。上述每一个操作都需要通过一组功能来实现，这些功能通常分布部署在整个企业中，统称为数字策略管理（DPM）。组织中可能有多个策略主管部门和层级化的管理架构，他们在企业策略上可能存在差异，DP和MP的管理规则可能需要由总部机构决定。

正确的DP定义和开发对于识别出访问控制决策所需的主、客体属性至关重要。请记住，DP语句由主体和客体属性对，以及满足一组允许操作所需的环境条件组成。一旦确定了满足企业客体集的整个允许操作集所需的主体和客体属性集，该属性集就包含了满足ABAC决策定义、分配、共享和评估所需的整个属性集。因此，在实现企业ABAC功能时，对NLP和DP的定义必须通过属性来实现。有关DP管理的其他问题，请参见本文件第3节。

4.2

企业ABAC中的属性管理

接下来，考虑在审查NLP和DP时定义的属性列表。如果没有足够的客体和主体属性集，ABAC就无法工作。属性需要被命名、定义、确定赋值范围、分配一个模式，并与主体和客体建立关联。主体属性需要由主管部门建立、发布、存储和管理。客体属性必须被指派给客体。跨组织共享的属性还需要定位、检索、公布、验证、更新、修改和撤消。

主体属性由属性主管机构提供，这些机构通常通过属性管理点来管理属性，而且通常有多个主管部门，分别负责对不同属性的管理。例如，安全部门可能主管“许可”属性，而人力资源部门可能主管“姓名”属性。为支持主体跨组织访问客体而共享的主体属性必须在组织之间是一致可比的，或映射到等价策略进行部署执行。例如，组织A中具有“Job Lead”角色的某个成员希望访问组织B中的信息，但组织B使用“Task Lead”表示等效的角色。这个方式还适用于企业属性模式与特定应用模式之间的映射，特别是在定义企业模式之前已经构建的，或使用自有内置模式的商用现货（COTS）产品。组织必须规范主体属性名称和值，或者为所有组织维护等价术语的映射，这应该由总部机构来负责管理。

在创建或修改客体时，需要建立、维护客体属性，并将其指派给客体。虽然可能不需要在整个企业中使用一套通用的客体属性，但应该一致地使用客体属性，来满足企业策略的要求，并且应该为其他人公布可用的属性集，以便他们可以标记、标注或以其他方式将这些属性应用于他们自己的客体。有时，还需要确保客体属性没有出于满足访问请求的目的，而被篡改或更改。客体可以通过密码技术绑定到其客体属性，以识别客体或其相应属性是否被篡改。必须部署某种机制以确保所有客体被创建并指派适当的客体属性集，以满足ACM中实施的策略，部署必要的企业级的客体属性管理器应该可以满足这些需求。

在管理属性的过程中，出现了“元属性”（即属性的特征）的概念。元属性作为扩展属性信息应用于主体、客体和环境条件，用于实施更细化的策略，这些策略包含与属性相关的信息（用于管理企业属性管理所需的数据）。元属性在本文档中定义为：

元属性：在ACM中实现MP和DP处理时所必需的与属性相关的信息。

有关属性管理的其他问题，请参见本文档的第3节。

4.3

企业ABAC中访问控制机制的部署实施

最后，考虑ACM在整个企业中的分布和管理。根据用户的需求、企业的规模、资源的分布以及需要访问或共享的客体的敏感性，ACM的分布对于ABAC实现的成功至关重要。ACM的功能组件可以物理上和逻辑上分散部署在企业中，而不是像ABAC的系统级视图描述的那种集中式。

ACM中有几个重要的功能“点”，用于检索和管理策略的服务节点，其中包含了用于处理策略上下文或工作流、以及检索和评估属性的一些逻辑组件。图5给出了这些功能点：策略执行点（PEP）、策略决策点（PDP）、策略信息点（PIP）和策略管理点（PAP）。这些组件处于同一环境中，相互配合以实现访问控制决策和策略执行。

图5 ACM功能点示例

PDP对DP和MP进行评估以产生访问控制决策。PDP和PEP在本文件中定义如下：

策略决策点（PDP）：通过评估适用的DP和MP来计算访问决策。PDP的主要功能之一是根据MP调节或消除DP间的冲突。

PEP执行PDP做出的策略决策：

策略执行点（PEP）：以执行策略决策的方式响应主体对受保护客体的访问请求；访问控制决策由PDP生成。

PDP和PEP功能可以是分布式的或集中式的，并且可以在物理和逻辑上彼此分离。例如，企业可以建立一个集中控制的企业决策服务，该服务评估属性和策略，生成策略决策并传递给PEP。这种方式方便对主体属性和策略进行集中管理和控制。或者，企业内的本地组织可以利用集中的DP存储库，实现独立的PDP。ACM组件的设计和部署需要一个管理单元来协调ABAC的各组件功能。

要计算策略决策，PDP必须具有有关属性的信息，这些信息由PIP提供。本文件中的PIP定义为：

策略信息点（PIP）：作为属性或策略评估所需数据的检索源，提供PDP做出决策所需的信息。

在执行这些策略决策之前，必须对它们进行彻底的测试和评估，以确保它们满足预期的需要，这些功能由PAP执行。PAP可定义为：

策略管理点（PAP）：提供一个用户接口，用于创建、管理、测试和调试DP和MP，并将这些策略存储在适当的策略库中。

最后，作为ACM中的可选组件，上下文处理器负责管理策略和属性的检索顺序。对实时性要求比较高的场合，或“决策结果要求立即终止访问”的那些策略来说，该部件非常重要。例如，需要在访问请求之前提前检索属性，或者缓存属性以避免在访问请求时检索所带来的时间延迟。上下文处理器还需要与PIP协调，向请求上下文添加属性值，并将规范形式（例如XACML）的授权决策转换为本机支持的格式。上下文处理器可以定义为：上下文处理器：按工作流逻辑定义的顺序，检索并执行策略和属性。