ABAC相关标准在数据服务中的应用

摘要：可扩展访问控制标记语言（Extensible Access Control Markup Language，XACML）和下一代访问控制（Next Generation Access Control，NGAC）是两种截然不同的基于属性的访问控制（Attribute-based Access Control，ABAC）标准。虽然它们的目标都是提供一种标准化的方式来表达和执行各种类型的访问控制策略，以满足各种数据服务上的多样化策略的需要，但这两个标准在描述和实施访问控制策略的方式上有明显的差异。

关键词：访问控制；访问控制机制；访问控制模型；访问控制策略；基于属性的访问控制；授权；可扩展访问控制标记语言；下一代访问控制；特权

第三部分

XACML与NGAC的分析比较

XACML与NGAC很相似，它们都提供灵活的、与机制无关的、不同粒度的策略规则表示，并且它们都通过属性来计算决策。但是，XACML和NGAC在策略的表达、属性的处理、决策的计算和请求的表示上有很大的不同。本节主要从访问控制功能与专有操作环境的分离度以及NIST SP 800-162中提及的4个ABAC考虑因素（支持策略的范围和类型、运行效率、属性和策略管理，对审查和资源发现的支持），来分析了这些异同。

为了进行比较，本文对XACML和NGAC的一些术语进行了统一。

1

访问控制与专有操作环境的分离度

XACML和NGAC都将数据服务的访问控制功能与其专有操作环境剥离出来，但剥离的程度不同。XACML部署中可能由多个操作环境，每个操作环境承载一个或多个应用程序，但共享一个公共的授权基础设施。这些操作环境都实现了自己的身份验证方法，并且为了支持其应用程序，实现了自己特有的操作例程。XACML访问请求中的特定应用的操作与操作环境中实现的操作例程是一一对应的。因此，支持XACML的应用需要依赖操作环境PEP，才能正常工作。访问请求由特定操作环境的PEP发出，策略决策也返回给该PEP。

尽管NGAC部署可以包括一个具有应用程序编程接口（API）的PEP，该API可以识别兼容特定操作环境的操作（例如，消息传递系统的发送和转发操作），但它并不一定非要这样做。NGAC包括的PEP带有一个通用API，该API提供了一组与操作环境无关的通用操作（读、写、创建、删除策略元素和关系），并且支持实现一个公共的、集中式的PEP来为多个应用程序的请求提供服务。尽管通用操作可能无法满足每个应用程序的要求（例如，对属性值进行计算的事务），但它可以满足来自多个应用程序的大多数操作要求，包括通常与数据的消费、操纵和管理以及访问权限的分配有关的操作。例如，消息传递数据服务的“发送”操作可以通过对NGAC数据元素和关系的一系列管理操作来实现，其中“收件箱”和“发件箱”表示为客体属性。管理操作创建一个消息（客体）并将其指派给发件人的“发件箱”和收件人的“收件箱”，其中发件人和收件人对各自的“发件箱”和“收件箱”中包含的客体具有读取访问权限。第4节中描述的文件管理数据服务是另一个数据服务的示例，它也是通过NGAC通用操作来实现特定应用程序的操作（创建、管理文件和文件夹）。另外，还有一些应用场景，包括支持工作流、日历、记录管理以及考勤等操作。

XACML没有把PEP设计成一个数据服务无关的组件，换言之，XACML架构下的PEP与特定的操作环境是紧密耦合的。但是，NGAC PEP可以在应用程序调用和底层客体及其相关特权之间提供一个抽象层次。

NGAC PEP所拥有的抽象层次结构使它可以完全取代操作环境中（原有）的访问控制机制，因为它可以通过相同的API、操作方式、访问控制数据元素和关系以及功能组件，向用户提供各种数据服务，并在应用的执行过程中表达/实施各种各样、任务特定的访问控制策略。

2

支持的策略范围和类型

访问控制策略是一个宽泛的术语，涉及各种类型的控制方法。在本报告中，这些控制分为两大类：自主访问控制（DAC）和强制访问控制（MAC）。此外，MAC还进一步分为两个子类：支持限制的MAC策略和不支持限制的MAC策略。

DAC是一种管理策略，允许系统用户许可或禁止其他用户访问其控制的资源/客体。限制对客体访问的方法通常基于用户的身份或指派给他们的属性。这些控制是自主决定的，因为有权访问资源的用户能够在没有系统管理员干预的情况下，将该访问权传递给其他用户。虽然XACML理论上可以实现DAC策略，但它并不高效。考虑DAC的传播特性，DAC允许客体的所有者/创建者（简称客体属主）将其部分或全部能力授予其他用户，并且被授予方可以进一步将这些能力传播给其他用户。在XACML中，无法仅通过“访问策略”（注：需要额外的管理策略）的定义来支持DAC的这种“传播”特性。XACML适合于根据属性来定义全局访问策略的场景，但对于DAC策略，用户属性的唯一修饰符是“访问主体”（注，即“主体是一个访问的主体”），没有其他的预定义属性来表示“该主体是客体属主”（注，即没有办法为主体定义一个属性，来表示它是客体属主）。

因此，客体属主的所有访问能力和管控这些能力的管理能力必须通过可信管理策略来定义。通过将客体属主指定为“访问主体”，可以使属主获得资源访问能力，而向其他用户授予权限的管理能力，则可以通过将属主指定为该策略的受托人而获得。这个可信管理策略可以派生出后续的管理策略（属主作为策略的颁发者并持有特定的能力），而且在这些派生的管理策略（标记为非可信）中，受托人的指定为属主向其他用户授权和能力传播提供了一种可能。虽然XACML通过利用其委托特性，可以支持DAC策略，但这种方法引入了繁重的管理负担，需要定义一个可信管理策略和一组针对客体属主和能力接受者的派生管理策略。

NGAC通过一种更灵活的方法，为用户提供管理能力，包括实现不同风格的DAC所必需的功能。在第4.5节的管理例程“create-file-mgmt-user(user-id, user-name, user-home)”示例中，创建了用户u1（Bob）并赋予其“File Management”数据服务能力。这些能力包括：创建客体并将它们分配到他的Home目录，从而对这些客体具有读/写访问权限。此外，Bob被赋予对其Home目录中客体的所有权和控制能力，Bob可以授予其他用户（例如Alice）对其Home中任何客体的读/写访问权。因为Alice也是“File Management”用户，所以Alice可以创建这些客体的副本，将其放在自己的Home目录中，并授予其他用户访问其副本的权限。

与DAC不同，对于普通用户来说，MAC支持其对资源客体执行资源操作的能力，但不支持他可能影响这些资源访问能力的那些管理能力（例如能力传播）。在对资源客体执行操作时，MAC策略不可避免地要对用户施加一些限制规则。

表达MAC策略可能是XACML最强大的优势。XACML可以使用各种数据类型（例如字符串和整数）的属性值来定义规则。毫无疑问，有些策略可以用XACML规则轻松地表达出来，但对NGAC来说却不那么容易表达。例如，金融交易可能涉及将某人的信用额度累加到其账户余额。XACML在表达策略时也考虑了环境属性，NGAC并不直接支持这些策略。这些环境驱动的策略本质上是动态的，授权状态可以在不涉及任何管理行为的情况下发生变化。例如，威胁级别可以从“低”变为“高”。XACML还包括一个职责的概念，用于指示PEP在访问请求被批准（或拒绝）之前（或之后）执行一些动作。XACML职责可以通过多种方式补充和完善MAC策略。虽然NGAC也使用“职责”一词，但NGAC职责指的是不同的策略结构。

MAC策略通常依赖于并包括管理策略，在多组织或协作环境中尤其如此。在这种环境中，管理策略要求不同的组织实体负责不同方面的策略及其属性的管理，通常还要求能够防止资源能力和管理能力的结合。例如，防止管理员授予自己对敏感资源的访问权限。XACML不适合表达这样的策略。考虑图6a所示的MAC策略。虽然XACML可以表达和实施这个策略，但是它不能很容易地表达“谁可以将用户指派到不同的组（属性）”这样的策略，但NGAC可以。NGAC可以创建管理属性，并为用户提供低至单个配置元素粒度的管理能力。此外，NGAC可以（通过禁止关系）否决相同粒度的管理功能。

尽管XACML已经被证明，能够通过XACML概要文件来表达RBAC标准的各个特性，但是没有证明该配置文件对动态职责分离（用于实施最小特权原则）和静态职责分离（用于对抗欺骗）的支持。附录B（下一代访问控制-通用操作和数据结构，NGAC-GOADS）展示了NGAC对RBAC标准的所有特性的支持，还同时展示了对Chinese wall策略的支持，而XACML不能完全支持该策略。

NGAC还支持基于历史的职责分离。Simon和Zurko在他们关于职责分离的开创性论文中，将基于历史的职责分离描述为最友好的职责分离形式，它可以纳入其他形式SoD策略的目标。NGAC还可以支持其他的基于历史的策略，包括双人（two-person）控制、工作流和利益冲突。

到目前为止，尽管在策略决策中使用了属性，但其最终的结果都是基于用户的授权状态。换句话说，策略和属性一起构成了{（u，ar，o）}形式的授权状态，其中用户u被授权在访问权限ar下访问客体o。这样的策略忽略了一个事实“实际上访问客体内容的是进程而不是用户”。一般来说，基于用户的授权控制（无论是MAC还是DAC）都有一个缺陷：它们无法防止数据通过恶意软件、恶意或自满的用户行为“泄漏”给未经授权的主体。

为了说明这个问题，假设以下授权状态{（u1，r，o1）、（u1，w，o2）和（u2，r，o2）}。注意，无法确定u2是否能够读取o1的内容。在一种情况下，u1可以读取并随后将o1的内容写入o2。即使策略可以完全依赖“对用户的信任”，也必须考虑可能存在的特洛伊木马。这种威胁的存在原因是；实际上，用户并不对客体执行操作，而是在用户的能力下，进程对客体（资源）的内容执行操作（动作）。因此，由u1执行的程序可以读取o1的内容，并且在没有u1参与或知情的情况下，将该内容写入o2。注意，即使添加了基于用户的否决条件或关系NOT（u2，r，o1），也不能防止这种泄漏。早在20世纪70年代，随着Bell和LaPadula安全模型的建立以及可信计算机安全评估标准（TCSEC）中定义的MAC策略，人们就认识到了防止数据泄漏（通常称为限制）的重要性。

因为XACML不支持与用户分离的进程的策略定义和实施，所以它无法对用户施加与MAC限制策略相关的约束。XACML的另一个缺点是它的PDP是无状态的，也限制了策略的定义和执行。尽管XACML包含了职责的概念，但它并未用于更改授权状态。

考虑下面的XACML TCSEC MAC策略定义：

// TCSEC MAC Policy Specification //
/* Policy applies to all subjects with clearance levels – Top-Secret, Secret, or Unclassified and resources with classification levels –Top-Secret, Secret, or Unclassified for both “read” and “write” actions */
/* :Attribute-Category :Attribute ID :Attribute Value */
:access-subject :Clearance :Top-Secret
:access-subject :Clearance :Secret
:access-subject :Clearance :Unclassified
:resource :Classification :Top-Secret
:resource :Classification :Secret
:resource :Classification :Unclassified
:action :action-id :read
:action :action-id :write
/* Rule 1 and Rule 2 apply to permissible and non-permissible “reads” */
/*:Attribute-Category :Attribute ID :Attribute Value */
:action :action-id :read

Function: string-greater-or-equal
/*:Attribute-Category :Attribute ID
:access-subject :Clearance
:resource :Classification
/*:Attribute-Category :Attribute ID :Attribute Value */
:action :action-id :read

Function: string-less
/*:Attribute-Category :Attribute ID
:access-subject :Clearance
:resource :Classification
/* Rule 3 & Rule 4 apply to permissible and non-permissible “writes” */
/*:Attribute-Category :Attribute ID :Attribute Value */
:action :action-id :write
Function: string-less-or-equal
/*:Attribute-Category :Attribute ID
:access-subject :Clearance
:resource :Classification
/*:Attribute-Category :Attribute ID :Attribute Value */
:action :action-id :write
Function: string-greater
/*:Attribute-Category :Attribute ID
:access-subject :Clearance
:resource :Classification
… preconditions …
cmd1;
conditiona cmd2, cmd3;
conditionz cmdn;

假设用户被指派到Top Secret，Secret，或Unclassified，Policy3确实会强制执行TCSEC MAC策略，但会阻止用户在资源级别低于用户许可级别的情况下写入资源。

图10是NGAC对上述MAC策略的定义，其中假设用户（未显示）被直接指派到Top Secret或Secret（图的左侧），对象被直接指派到Top Secret或Secret（图的右侧）。

图10 NGAC表达的TCSEC-MAC

图中的指派和关联指定了，Top Secret用户可以读写Secret客体和Top Secret客体，Secret用户可以读写Secret客体和写Top Secret客体。注意，指派和关联本身并不能防止较高级别的数据泄漏到较低分类。通过以下两项职责，NGAC可以防止数据的非法泄漏，同时允许用户拥有指派和关联所允许的全部能力。换句话说，用户可以在同一个会话中读取Top Secret数据并写入Secret数据，但要通过两个不同的进程来完成。

(1) when process p reads o→+TopSecret do create p-deny(p, {w},¬TopSecret)

(2) when process p reads o→+Secret do create p-deny(p, {w}, ¬Secret-Top Secret)

第一个职责指定：当进程读取包含在Top Secret中的客体时，拒绝进程写入Top Secret（客体属性）容器之外的任何客体。类似地，第二个职责指定：当进程读取Secret容器中的客体时，拒绝进程写入Secret-Top Secret容器之外的任何客体。

缺少对限制的支持，可以说很多策略XACML都无法实施。这些限制性策略包括RBAC的某些实例（例如，只有医生才能读取病历），ORCON和隐私策略（例如，我知道谁可以读取我的数据或个人信息），或利益冲突（例如，不允许数据集A的用户同时成为另一个数据集B的用户）。通过进程级控制与职责的结合，NGAC展现了对这些和其他限制性MAC策略的支持。

尽管XACML和NGAC都支持策略的组合，但它们的动机是不同的。XACML的动机是解决冲突。也就是说，策略和规则可能具有不同的效用（允许或拒绝），必须在评估期间选择性地应用一种组合算法来解决。NGAC的动机是确保在计算决策时遵守多种策略的组合（例如DAC和RBAC）。

3

运行效率

虽然XACML和NGAC都能选择性地识别和评估与访问请求相关的策略和条件，但它们的实现方法有很大的差别。XACML请求是主体（用户）、资源、操作和环境的属性“名-值”对的集合，这些属性“名-值”对可能被转换为XACML规范形式以方便PDP使用。XACML通过属性与策略目标的匹配情况来识别适用策略和规则。整个过程涉及收集所有策略（可信和非可信访问策略）和适用策略中所有规则中的属性和目标匹配条件，发送管理请求（用于确定适用的非可信访问策略的信任链）。如果属性不足以评估适用的策略或规则，PDP还可以搜索其他属性，访问过程至少会搜索两个数据存储库（PIP和PRP）。PDP评估策略中的每个适用规则，并在计算策略级决策时应用组合算法。该过程一直在所有适用的策略上执行，并通过对策略的评估结果应用组合算法来产生最终决策。

为了响应访问请求，NGAC通过存储在独立数据库中的访问控制数据来计算决策，这些数据可以表示为一组数据集合，也可以更典型地用图来表示。在用图表示时，策略元素用户、客体、用户属性、客体属性和策略类分别对应5种类型的节点。这些策略元素之间的连接用有向边表示。此外，从用户属性到客体属性的连接用允许的操作集进行标记。XACML在生成最终决策时，存在明显清晰的过程来识别适用策略、组合本地的决策结果。但在NGAC中，所有这些过程都是在图（表示访问控制数据）上执行的路径搜索算法（以确定是否存在适当的权限）的一部分。如果确实存在这样的特权并且不存在例外（禁止），则该请求被准许，否则被拒绝。像策略和属性一样，禁止是通过关系而不是搜索来发现的。NGAC没有与XACML功能相似的上下文处理器（用于将请求和决策转换为规范形式，或用来检索属性）。尽管职责被视为NGAC访问控制过程的一个组成部分，但只有在做出决策并成功更改或使用数据服务之后，职责才会发挥作用。

访问决策的计算过程可以大致划分为3个阶段，包括：

◆ 将策略从磁盘加载到内存

◆ 找到适用的策略

◆ 策略评估

下面讨论了影响XACML和NGAC性能的主要因素。

3.1

策略的加载

在这个阶段，ABAC系统将策略从磁盘（或其他持久性存储介质）加载到内存中，并将它们转换为适于高效计算的内存表示形式或数据结构。对于XACML，策略的主要组成部分包括：目标（主体、客体、动作和环境属性值的组合）和一组规则。这个阶段是XACML访问决策计算过程中最耗性能的阶段，当策略库中有超过100个策略时，处理时间显著增加。无论有多少策略，加载过程都需要解析外部XML表示的策略，并将其转换为内存结构。常用的性能优化方法包括缓存需频繁加载的策略（使用“策略标识符-已加载策略”的组合），只加载代理（Proxy）策略（指仅包含目标的策略）而不是完整的策略内容，并使用高效的解析器（基于DOM或StAX）将其转换为内存数据结构。

对于NGAC，磁盘和内存中的策略都可以表示为一个图。因此，从策略的磁盘表示格式到内存格式的转换处理非常少，而且非常有效。此外，为了计算决策，所有需要的信息都可以驻留在内存中。在NGAC参考实现版本1.6中，当PDP被初始化时，访问控制信息被加载到内存中，当发生管理操作时，更新访问控制数据。

3.2

查找适用策略

在这个阶段，通过将请求与加载的策略进行匹配，识别出内存驻留的适用策略集。对于XACML，匹配速度与策略库中的规则数量无关，仅与策略目标的复杂性有关。由于请求与策略的匹配算法只需要策略目标中的信息，因此将代理策略单独放在内存中就可以满足这一需要。使用代理策略（而不是完整策略）可以加快适用策略的识别过程。在通过代理策略识别适用的策略之后，必须将其完整的策略内容从磁盘加载到内存中。当策略数量较多时，这种磁盘操作（从策略存储加载到内存）所涉及的开销将变得非常大。此阶段中使用的另一个性能优化方法是缓存“请求-适用策略”的组合。

就NGAC而言，查找适用策略（更准确地说是适用的策略要素）是其决策计算的固有方面。在计算决策时，NGAC只考虑（图上）从代表访问请求中的用户和目标客体的节点可以到达的节点。

3.3

决策处理

在这个阶段，根据内存中的所有适用策略评估访问请求，并计算最终决策。XACML在这个阶段最重要的任务是评估适用策略中各种规则中的逻辑表达式，另外，还要通过上下文处理器或PIP检索动态属性（如时间、IP地址等环境属性），并应用组合算法。因此，此阶段的性能受策略库中规则数量的影响。性能优化可以通过缓存“请求-访问决策”的组合和使用高效的逻辑表达式计算算法来实现。在访问请求相似（而不是完全随机）的应用程序环境中，缓存对性能的影响非常显著。因为在这类应用程序环境中，使用动态属性的规则数量是有限的，策略存储库也相对稳定（没有频繁添加/删除策略或策略集）。尽管我们没有对XACML决策过程的复杂性进行形式化分析，但实验研究表明，影响性能的最重要因素是策略或规则的数量，它们达到一定数量级别后会带来一些可伸缩性问题。这个级别取决于部署环境中的许多因素，例如敏感度，应用程序的数量，以及访问控制粒度。

关于NGAC，存在有效特权（执行某个操作所需的权利）的必要条件可以用图形表示法描述如下：允许用户对客体执行操作当且仅当存在一组用期望操作标记的有向边，使得每条边的尾部从用户可达，且每条边的头部从目标客体可达，且从头部节点集可达的策略类节点集是从目标客体可达的策略类节点集的超集。

NGAC规范使用集合论表示法描述了什么是有效的ABAC实现，但没有提供具体的实现指南，这就为各种具有不同效率的决策处理算法和实现留下了竞争空间。在文献[30]中，开发并实现了一种复杂度与策略图的大小成线性关系的算法，其复杂度为O（m+n），其中m是边数，n是节点数。这个线性关系不是与整个访问控制图相关，而仅与图中和特定用户相关的部分有关。

4

属性和策略管理

XACML和NGAC都提供了一种委托机制来支持访问策略的去中心化管理，允许委托人（delegator）将其自身或其他人的全部或部分权限委托给受托人（delegate）。与NGAC不同，XACML的委托方法仅是部分解决方案。它依赖于可信和非可信访问策略，并假定可信访问策略是有效的，而且它们的源是在委托模型之外建立的。XACML支持多个策略编写者共同编写策略。尽管XACML策略组件的独立编写、收集和组合很方便，但是XACML没有介绍协调多个编写者对策略组件的创建和修改的规范方法。NGAC能够系统地建立管理责任，该方法从一个可以创建并委托管理能力的管理员开始，到逐步地将权限委托给中间管理员，该过程以具有数据服务、策略和属性管理能力的用户结束。

尽管可以想象一种通过使用XACML策略来管理属性的方法，但实际上，属性值的创建以及主体和资源到这些属性的指派通常是在不同的场所执行的，缺乏任何协调或管理的概念。

因为XACML是用XML实现的，所以它继承了XML的优点和缺点。XACML的灵活性和表达能力虽然强大，但使策略的定义变得复杂而冗长。在异构环境中使用XACML需要完整的数据类型和功能定义，即使实际的策略规则很简单，这些定义也会生成冗长的策略文本。一般来说，资源管理员很难创建和维护以抽象语言表示且与平台无关的策略。与XACML不同，NGAC是一个基于关系的标准，它避免了定义抽象语言来表达平台无关策略时，所带来的语法和语义复杂性。NGAC策略以配置元素的形式来表示，这些元素一般集中维护，并且可以以图形方式呈现和操作。例如，为了描述属性之间的层级关系，NGAC只需要在属性之间添加一些连接来表示它们的指派关系；而在XACML中，关系需要按照精确的语法顺序插入。

NGAC这种图形化表达策略的能力非常有助于管理，管理员可以看到受管属性之间的关系，以及覆盖这些属性的相关策略。

XACML不允许普通用户修改策略。NGAC通过一组标准的管理操作来管理其访问控制数据（策略和属性），这组管理操作采用了与处理资源访问请求相同的PEP接口和决策函数。换句话说，NGAC不区分普通用户和管理员，所有用户都可以拥有各种各样的能力来访问资源客体和访问控制数据客体。极端情况下，用户可能只拥有管理强制策略的能力，但不能访问那些受该强制策略控制的资源。或者，用户可以完全控制自己的数据，并负责设置自己的策略。后者的典型例子包括社交网络、消息传递系统和日程程序等。

XACML以条件形式定义策略的方式提高了策略表达的效率。考虑第3.4节中图8所示的NGAC表达的策略（与XACML策略1等效）。NGAC使用5种关系表示策略，而XACML只提供了3种规则。注意，随着策略涉及的病房数量的增加，NGAC关联关系的数量也会增加，但XACML规则的数量将始终保持不变。对于此策略，XACML和NGAC的属性指派数量是相同的。另一方面，对于某些策略，XACML属性指派的数量可能远远超过NGAC等效策略所需的数量。对于第5.2节中通过XACML规则和NGAC关系表示的TCSEC MAC策略，在NGAC配置下，不需要直接指定关于未分级用户或未分类客体的策略或属性。更重要的是，NGAC需要的属性指派数量要少得多。要使XACML TCSEC MAC策略工作，需要将所有资源指派给Unclassified、Secret或Top Secret属性，而要使NGAC TCSEC MAC策略工作，只需要将实际已分类的客体指派给Secret或Top-Secret属性。

5

审查和资源发现

访问控制的理想特性包括审查用户/主体的能力和客体/资源的访问控制条目，此功能也称为“事前审查”和“资源发现”。“事前审查””被认为是RBAC最突出的特性之一，包括能够检查用户的能力或为用户分配角色的后续影响，以及用户发现或查看可访问资源的能力。检查客体/资源的访问控制条目同样重要。可以访问某客体/资源的用户/主体是谁？将客体/资源指派给某个属性或删除指派会产生什么后果？

NGAC提供了高效的算法来支持对每个用户和每个客体的审查。Biswas、Sandhu和Krishnan在参考文献[6]中提到，对可枚举的策略（如NGAC）进行审查本质上非常简单。在文献[30]提供了一个用于检索用户可访问客体的线性算法，但该算法与整个访问控制数据库中的数据集和关系并不是线性的，而只是与特定用户相关的部分存在线性关系。因此，从经验上讲，算法的实际执行速度可能比理论分析看到的要快。基于逻辑表达式的策略模型（如XACML）无法有效地进行策略审查。在这样的系统中进行策略审查等价于命题逻辑中的可满足性问题，它是NP完全的。确定主体对资源执行操作的权限只能通过发出请求来确定，换句话说，在不测试所有可能的决策结果的情况下，不存在确定授权状态的方法。

6

结论

XACML与NGAC的相似之处在于，它们都在决策计算中使用了属性，并且都提供灵活的、与机制无关的策略规则表示，这些规则的粒度可能会有所不同。然而，XACML和NGAC在策略的表达和管理、属性的处理、决策的计算和请求的表示上有很大差异，而大多数差异来源于它们对策略和属性表示方法的差异。XACML通过包含属性值的逻辑表达式来定义策略，而NGAC则使用包含关系配置的枚举（集合）。由于这些原因，XACML和NGAC分别具有各自的优缺点。

XACML具有很强的表达能力和灵活性。XACML可以使用各种类型的属性值来定义策略规则，而NGAC将所有属性都视为容器。因此，在XACML中可以表达的某些策略是NGAC无法表达的。XACML在表达策略时考虑了环境属性，而NGAC没有。此外，XACML还包含了一个职责或建议的概念，职责或建议指示PEP在访问请求被批准（或拒绝）之前（或之后）执行一些动作，为补充和完善策略提供了额外的手段。

NGAC也具有强大的表达能力，可以表达许多与XACML相同的策略。但是，有些策略（包括各种基于历史的策略）只有NGAC才能表达。与NGAC不同的是，XACML不能识别独立于用户能力的进程能力。如果没有这些特性，可以说XACML无法实施“数据防泄漏”策略（这些策略的目的是防止数据“泄漏”给未经授权的用户）。

有些策略使用逻辑表达式来表达可能比用枚举来表达更有效。与XACML策略等价的NGAC配置需要用显式的关系来表示XACML策略规则中属性的可能值，导致用NGAC替换XACML时，所创建的关系的数量可能需要倍增。通过XML实现的XACML继承了XML的优点和缺点。XACML的灵活性和表达能力虽然强大，但使策略的定义变得复杂而冗长。在异构环境中应用XACML需要完整数据类型和函数定义，即使实际的策略规则很简单，这些定义也会生成冗长的策略文本。与XACML不同，NGAC是一种基于关系的标准，它避免了定义一种抽象语言来表达策略，所带来的语法和语义复杂性。NGAC策略以配置元素的形式来表示，配置元素通常以图形方式呈现和操作。

除了策略表达之外，策略审查也是ABAC的一个重要功能。策略审查可以涉及许多情况，包括识别用户的可访问资源、为用户指派某个属性的影响后果，或者为用户提供发现或查看可访问资源的能力。基于逻辑表达式的策略（如XACML）无法有效地进行策略审查。对基于逻辑逻辑表达式的策略进行审查相当于命题逻辑中的可满足性问题（本质上，随着策略规模数量的增加，分析可能变得更加困难）。相反，对使用枚举的策略（如NGAC）进行审查相对简单。

尽管有些策略用XACML表达比NGAC高效，但并不意味着会对NGAC的运行性能产生任何负面影响。评估请求的效率与存储在NGAC策略数据库中的关系数没有直接关系。相反，策略只根据与访问请求相关的用户或客体的策略元素进行评估。XACML策略评估的两个阶段包括策略加载（从磁盘到PDP内存）和请求评估。在这两个阶段中，性能与考虑的策略数直接相关。相反，在NGAC评估请求时，它没有关系的加载过程，也不必考虑所有与该关系相关的策略。

XACML和NGAC对访问控制数据（属性和策略）的创建和修改进行策略化管控的能力不同。XACML（通过可选的概要文件）提供了对非可信访问策略和非可信管理策略的去中心化管理，但该方法仅是部分解决方案，因为它依赖于可信策略和非可信策略，假定可信策略是有效的，并且它们的起源是在委托模型之外建立的。此外，XACML委托模型没有为访问策略的修改提供策略化管控的方法，也没有直接为其属性的管理提供策略化管控的方法。NGAC为管理角色的创建和管理能力的委托提供了一种系统的、受策略保护的方法，从一个管理员和一组访问控制数据的空集开始，到具有数据服务、策略和属性管理能力的用户。

为了支持互操作性，XACML和NGAC将底层操作环境中特定于数据服务的访问控制逻辑替换为集中式的策略决策功能。XACML部署由一个或多个数据服务组成，每个数据服务都有一个驻留在特定操作环境中的PEP，该PEP向公共PDP发出由特定数据服务的操作和数据类型组成的请求。NGAC则更进了一步，尽管其部署可以包括识别特定数据服务操作（例如，消息传递系统的发送和转发操作）的PEP，但它不一定非要这样做。NGAC可以包含一个集中式PEP，并由其生成一组通用的、与数据服务无关的操作。

在比较XACML和NGAC的标准时，本文档着重考虑了用户/供应商在部署、实现ABAC产品时需要关注的因素，但这些关注点并不是详尽无遗的。从用户角度来看，新出现的NGAC缺乏可供测试和评估的产品。从供应商的角度来看，NGAC规范只用集合论方法描述了其有效实现的组成部件，从而为各个相互竞争的实现技术留出了充足的空间。但是，XACML作为一系列专有和开源产品的基础，几乎涵盖了部署的所有方面。