NGAC标准规范

标准规范"/>

NGAC标准规范

本文继续整理了《ABAC相关标准在数据服务中的应用——XACML和NGAC的比较》一文中第二部分NGAC标准规范，如需完整内容请至公众号【权说安全】查看。

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

 第二部分  NGAC标准规范  

NGAC在表示访问请求，表达和管理策略与属性，以及计算和执行决策方面采取了与XACML完全不同的方法。NGAC通过一组标准化的、通用的关系（Relation）和功能（Function）来定义访问控制，这些关系和功能在策略的表达和执行中是可重用的。

为了简洁易读，本节对NGAC规范进行了概述，介绍NGAC的核心框架和功能，但并非面面俱到。在某些情况下，NGAC相关细节和术语可能被替换，以简化表述。

1

策略及其属性元素

NGAC的访问控制数据由基本元素、容器和可配置关系组成。在NGAC的术语中，用户（user）、操作（operation）和客体（object）分别对应于XACML中的主体（subject），动作（action）和资源（resource）。除此之外，NGAC还包括进程、管理操作和策略类（Policy Class）等概念。与XACML一样，NGAC也支持用户和客体的属性，但它将属性和策略类实体视为容器。这种容器的概念有助于制定、管理策略和属性。

NGAC将用户和进程视为独立但相关的实体。NGAC进程可以看作是操作系统进程的简化，它们具有id、内存和用于资源分配的描述符（例如句柄）。与操作系统进程一样，NGAC进程可以利用系统资源（例如剪贴板）进行进程间通信。用户尝试访问的进程具有与该用户相同的属性。

尽管XACML资源类似于NGAC客体，但NGAC通过术语“客体”作为对客体的数据内容的间接引用。给定这种一对一的对应关系，就可以用“客体”标识与其具有相同名称的客体属性（注：本质上，客体的数据内容是客体的一种属性，在NGAC中，客体既指代该客体本身，又指代该客体的数据内容，因此它认为，“客体”是客体的一种属性）。客体集代表了需要保护的实体，例如文件、剪贴板、电子邮件和数据库记录字段等。

与XACML主体的属性值类似，NGAC用户容器（即用户属性）可以表示角色、从属关系或与策略相关的其他常见特征，例如安全许可。

客体容器（即属性）通过对客体集的标识来描述数据和其他资源，例如与某些项目、应用程序或安全分类关联的客体集。客体容器还可以表示复合对象，例如文件夹、收件箱、表列或行，以满足不同数据服务的需求。策略类容器在更宽泛的层次上对策略或数据服务的集合进行分组和描述，每个容器表示一组不同但又相关的策略元素。每个用户、用户属性和客体属性必须至少包含在一个策略类中。策略类可以相互排斥或在不同程度上重叠，以满足广泛的策略需求（注：策略类即策略）。

NGAC支持对一般的常见操作的控制，包括针对客体的基本输入和输出操作（即读写），以及针对访问控制数据的一组标准管理操作。此外，NGAC部署还可以考虑并提供对其他数据服务操作的控制，甚至可以专门为操作环境定义资源操作。另一方面，管理操作只涉及NGAC数据元素和关系的创建和删除，是NGAC框架的一个固定组成部分，与实际的操作环境无关。

2

关系

NGAC不是通过规则来表达策略，而是通过配置4种类型的关系（Relation）来表达策略，这些关系包括指派（Assignment，用于定义容器的成员关系）、关联（Association，用于确定特权）、禁止（Prohibition，用于指定特权例外）和职责（Obligation，用于动态改变访问状态）。

2.1

指派和关联

NGAC使用元组（x，y）来指代将元素x指派给元素y，在本文中记为x→y。指派关系通常意味着包含（x包含在y中）。一个或多个指派关系形成的链用“→+”表示。指派中可以使用的实体包括用户、用户属性、客体属性（包括所有客体）和策略类。

用户的所有操作都离不开访问权限。与操作的分类相似，访问权限也分为两类：非管理权限和管理权限。

执行操作时所持有的访问权限是通过关联获得的。关联是一个三元组，用ua---ars---at表示，其中ua是用户属性，ars是访问权限集，at是用户属性或客体属性。关联中的at属性用作对自身和该属性所包含的策略元素的引用。类似地，关联中的ua属性也被视为对用户和ua中用户属性的引用。关联“ua---ars---at”的含义是，ua中包含的用户可以对at引用的策略元素执行ars中的访问权限。at引用的策略元素集依赖于（并且对其有意义）ars中的访问权限。

图6给出了用图表示的指派和关联关系，图6a是一个访问控制策略的配置，其对应策略类为“Project Access”，图6b是一个数据服务配置，其对应策略类为“File Management”。图中，用户和用户属性位于左侧，客体和客体属性位于右侧，箭头表示指派关系，虚线表示关联关系。注意，引用的策略元素集依赖于ars中的访问权限。每个关联的at属性是一个客体属性，访问权限是读/写。在关联“Division---{r}---Projects”中，Projects引用的策略元素是客体o1和o2，意味着用户u1和u2可以读取对象o1和o2。如果有一个关联“Division ---{create assign to}---Projects”，那么Projects引用的策略元素将是Projects、Project1和Project2，这意味着用户u1和u2可以（管理性地）创建与Projects、Project1和Project2的指派关系。

图6 指派和关联的示例

2.2

特权的派生

总的来说，关联和指派间接地指定（u，ar，e）形式的特权，意为用户u被允许（或有能力）在元素e上执行访问权ar，其中e可以是用户、用户属性或客体属性。确定特权（派生关系）的存在是计算访问决策的前提，但仅确定特权又不足以计算出访问决策（后面再讨论）。

NGAC引入了一个算法，用来确定一个或多个策略类和关联的特权。（u，ar，e）是一个特权当且仅当对于每个包含e的策略类pc，以下条件为真：

 ◆ 用户u包含在关联的用户属性中；

 ◆ 元素e包含在该关联的属性at中；

 ◆ 该关联的属性at包含在策略类pc中；

 ◆ 访问权限ar是该关联的访问权限集的成员。

注意，用于确定权限的算法适用于包含一个或多个策略类的配置（Configuration）。表2的左、右栏分别列出了图6a和图6b中的派生特权。

表2 图6a和6b中的派生特权

（u1，r，o1），（u1，w，o1），（u1，r，o2）， （u2，r，o1），（u2，r，o2），（u2，w，o2）， （u2，r，o3），（u2，w，o3）

（u1，r，o2），（u1，w，o2），（u2，r，o2）， （u2，w，o2），（u2，r，o3），（u2，w，o3）， （u2，r，o4），（u2，w，o4）

图7是将图6a和图6b中综合在一起配置时的指派和关联。注意，出于确定派生权限的需要，未考虑用户属性到策略类的指派关系，因此图中没有显示。

图7综合配置（图6a和图6b）的指派和关联关系

表3列出了在综合考虑图6a和图6b时的派生特权。

表3 综合配置（图6a和图6b）中的派生特权

（u1，r，o1），（u1，w，o1），（u1，r，o2），（u2，r，o1），（u2，r，o2）， （u2，w，o2），（u2，r，o3），（u2，w，o3），（u2，r，o4），（u2，w，o4）

注意，（u1，r，o1）是表3中的特权，因为o1只在策略类“Project Access”中，并且存在一个关联“Division---{r}---Projects”，其中u1在Division中，r在{r}，o1在Projects中。但是，（u1，w，o2）不是表3中的特权，因为o2在“Project Access”和“File Management”策略类中都存在，尽管存在一个关联“Alice---{r，w}---o2”，其中u1在Alice中，w在{r，w}，o2在o2和“File Management”中，但是在“Project Access”中不存在这样的关联。

NGAC配置间接指定了规则。图6a的访问控制策略指定“指派给Group1或Group2的用户可以读取Projects中包含的客体，但只有Group1用户可以写入Project1对象，只有Group2用户可以写入Project2对象”。该策略还指定了“Group2用户可以在Gr2-Secret中读/写数据对象”。虽然图6a指定了如何读写客体的策略，但该配置被认为是不完整的，因为它没有指定如何创建和管理用户、客体、策略元素，以及指派和关联。

图6b描述了文件管理数据服务的访问策略。用户u2（Bob）对Bob Home（表示其主目录）中包含的被指派客体属性（Proposals、Reports表示一个目录）的客体具有读/写权限，用户u1（Alice）对客体o2具有读/写访问权限。这种配置也是不完整的，因为通常用户希望文件管理数据服务能够为他们创建和管理文件夹，并为他们的文件夹创建和分配数据对象。文件管理数据服务的另一个共同特性是，用户能够向其他用户授予或撤销对受其控制的客体的访问权限。

“Project Access”策略缺少的管理功能在第4.4.1节中讨论，“File Management”数据服务在第4.5节中讨论。

尽管图7描述了策略的交集，但NGAC使用AND和OR的布尔逻辑来表示策略的组合。图8描述了第3.4节中指定的XACML策略1的NGAC等效配置。这两个策略都指定了“指派给Intern的用户可以读用户的病历，而且Doctor可以读和写与其同病房的用户的病历，或者Doctor可以读和写指派给重症患者的病历，而与病历指派的病房无关”。

图8 XACML 策略1的NGAC等价表达

图8显示了与XACML主体和资源（在表1中）相对应的NGAC用户和对象，这些用户和对象被指派了表1中的属性值。相应地，图8的派生特权（表4中列出）与表1中指定的授权状态也是一致的。

表4 图8配置中的派生特权

（u3，r，o5），（u3，w，o5），（u3，r，o7），（u3，w，o7），（u4，r，o6）

2.3

禁止（否决）

除了指派和关联之外，NGAC还包括3种类型的禁止关系：用户否决（User-deny）、用户属性否决（User Attribute-deny）和进程否决（Process-deny）。通常，否决关系用于指定特权例外排除。用户否决、用户属性否决和进程否决分别表示为u_deny（u，ars，pe），ua_deny（ua，ars，pe），p_deny（p，ars，pe），其中u是用户，ua是用户属性，p是进程，ars是访问权限集，pe是策略元素（用作对自身和被pe包含的策略元素的引用）。这些关系的含义分别是用户u、ua中的用户和进程p不能对pe中的策略元素执行ars中的访问权限。用户否决和用户属性否决可以由管理员直接创建，也可以作为职责的结果动态创建（参见第4.2.4节）。例如，管理员可以设置一个限制条件，“任何用户都不能更改自己的纳税申报表，尽管他被指派了IRS Auditor用户属性并具有读/写所有纳税申报表的能力”。当通过职责创建时，用户否决和用户属性否决可以采用动态的策略条件，这种条件可以提供对职责分离策略（Separation of Duty）的支持（如果用户执行了能力x，则该用户将立即被排除在“能够执行能力y”之外）。此外，每个禁止关系的策略要素部分都可以指定为其补集，用¬表示。u_deny（u，ars，¬pe），ua_deny（ua，ars，¬pe）和p_deny（p，ars，¬pe）是指用户u、被指派给ua的用户和进程p不能对不在pe中的策略元素执行ars中的访问权限。

进程否决关系只能通过职责创建。它们的主要用途是执行限制条件（例如，如果进程读取绝密数据，则阻止该进程写入任何非绝密客体）。

2.4

职责

职责关系以(ep, r)对的形式表示，其含义为“当ep发生时，执行r”，其中ep是事件模式，r是一系列管理操作（称为响应）。事件模式指定了一组条件，如果进程在客体上成功执行操作的上下文与这组条件匹配，那么与对应响应相关的管理操作必须立刻执行。环境上下文和事件模式可以定义一些参数，如进程的用户，所执行的操作，以及客体属性。

职责可以指定一些操作条件以支持基于历史的策略和数据服务。此类条件包括利益冲突（如果用户从某个敏感数据集中读取信息，则禁止该用户从另一个数据集中读取数据）和工作流（批准某个工作项使另一个用户能够读取和批准该工作项）。此外，基于历史的策略还包括防止数据泄漏给未授权主体的策略，第4.5节讨论了职责在数据防泄漏中的使用。

3

NGAC的决策功能

NGAC访问决策功能以进程为单位来控制访问。进程所代表的用户必须对其操作所涉及的策略元素拥有足够的权限。函数process_user（p）表示与进程p相关联的用户。

访问请求的格式为（p，op，argseq），其中p是进程，op是操作，argseq是与操作相关的参数序列。也就是说，访问请求包含一个操作和一个可枚举的参数列表（包含了参数的个数、类型和传参顺序）。

访问决策功能需要将进程的操作和参数序列，映射到一组访问权限和策略元素对（即{（ar，pe）}），进程的用户必须持有这些权限和策略元素对才能对其授权。

在确定是否授予或拒绝访问请求时，授权决策功能会考虑适用于用户及其进程的所有特权和限制（拒绝），这些特权和限制源自相关的关联和禁止关系，并且限制优先于特权：

对于进程访问请求（p，op，argseq）和映射（op，argseq）→{（ar，pe）}，该进程被授权当且仅当对于{（ar，pe）}中的每个（ari，pei）存在一个特权（u，ari，pei），其中u=process_user（p），且（ari，pei）对u或p都未被否决。

在图7所示的情况中，如果访问请求为（p，read，o1），其中p是u1的进程，（read，o1）映射到（r，o1）。因为在表3中存在特权（u1，r，o1），并且（r，o1）对于u1或p没有被拒绝，那么该访问请求将被准许。假设在图7中存在关联“Division---{create assign to}---Projects”和“Bob---{create assign from}---Bob Home”，以及访问请求（p，assign，<o4，Project1>），其中p是u2的进程，（assign，<o4，Project1>）映射到{（create assign from，o4），（create assign to，Project1）}。因为特权（u2，create assign-from，o4）和（u2，create assign-to，Project1）在假设下是存在的，并且（create assign-from，o4）和（create assign-to，Project1）对于u2或p不会被拒绝，所以该请求将被准许。

4

管理层面的考虑

许多访问权限被归类为管理性访问权限，例如创建文件并将其分配给某个文件夹所需的权限，从使用的角度来看，可以说是非管理性的。但是，从策略规范的角度来看，它们被认为是管理性的（因为，在这种情况下，创建对象的访问权和将对象分配给对象属性的访问权限需要关联起来）。这两类访问权限的主要区别在于，非管理性操作指发生在受保护资源（以客体来表示）上的活动，而管理性操作指发生在策略和属性（以NGAC定义、维护的策略元素和关系来表示）上的活动。

4.1

管理性关联

为了执行管理操作，发起请求的用户必须拥有适当的访问权限。与前面通过关联来指定资源访问权限的方法一样，对策略元素和关系进行管理操作的权限也是通过关联来定义的。在非管理性访问权限（即资源访问权限）中，资源操作与执行这些操作所需的访问权是同义的（例如，“r”访问权限对应“read”操作），但在管理性权限中，管理性访问权不一定是管理性操作的同义词。相反，为了授权单个操作可能需要获得一个或多个管理性访问权限。

有些管理性访问权被明确分为两部分，分别用“from”和“to”后缀表示。这种情况下，必须同时持有这两部分权限，才能进行其对应的管理性操作。

例如，考虑以下两个关联，它们为“Project Access”策略的配置（在图6a中描述）提供了管理性能力的支持：

ProjectAccessAdmin---{create-u-to, delete-u-from, create-ua-to, delete-ua-from, create-uua-

 from, create-uua-to, delete-uua-from, create-uaua-from, create-uaua-to, delete-uaua- 

 from, delete-uaua-to }---Division

ProjectAccessAdmin---{create-o-to, delete-o-from, create-oa-to, delete-oa-to, create-ooa-

 from, create-ooa-to, delete-ooa-from, create-oaoa-from, create-oaoa-to, delete-oaoa-from,

 delete-oaoa-to }--- Projects

第一个关联的含义是ProjectAccessAdmin中的用户可以在Division中创建和删除用户、用户属性、用户到用户属性（uua）和用户属性到用户属性（uaua）的指派。第二个关联类似地建立了在Projects中创建和删除对象（o）、对象属性（oa）、对象到对象属性（ooa）和对象属性到对象属性（oaoa）的指派的权限。

紧跟前面的两个关联，接下来的两个关联将继续完善图6a中的配置，从而实现完整的策略管理。在下面的这两个关联中，ProjectAccessAdmin中的用户通过已持有的读写权限，可以创建和删除Division中的用户属性与Projects中的客体属性之间的关联。

ProjectAccessAdmin --- {create-assoc-from, delete-assoc-from} --- Division.

ProjectAccessAdmin --- {create-assoc-to, delete-assoc-to, r-allocate, w-allocate} --- Projects

4.2

委托

在策略中，管理能力是如何创建的？答案是从具有对所有访问控制数据执行所有管理操作能力的超级用户开始。系统的初始状态由空的NGAC配置（没有数据元素、属性和关系）组成。超级用户可以直接创建管理能力（注：通过创建管理策略），但实际上更可能是创建管理员，并将创建和删除管理权限的能力委托给他们。管理能力的委托和撤销是通过创建和删除关联来实现的。通过关联分配访问权限所遵循的原则是，关联的创建者必须已被分配对相关属性的访问权限（以及必要的create-assoc-from和create-assoc-to权限），才能将其委托给其他人。该原则为管理属性创建和管理能力委托提供了系统的解决方法，从超级用户开始，到具有管理和数据服务能力的用户结束。

4.3

管理指令和例程

管理指令和例程是形成策略规范的手段。每个涉及管理操作的访问请求都与管理例程一一对应，管理例程使用访问请求中的参数序列来执行访问。如本节前面所述，仅当进程对执行操作所涉及的元素拥有非否决访问权限时，访问决策函数才会授权访问请求（以及启动相应的管理例程）。管理例程依次使用一个或多个管理指令来执行访问。

管理指令描述了改变NGAC策略元素和关系（它们共同组成了授权状态）的基本操作。一个管理命令可以被表示为一个参数化的过程，其函数体描述了在执行所描述的行为时，策略的状态更改情况（例如，当应用某个函数f时，策略元素或关系Y将状态更改为Y′）。管理指令通过下列格式定义：

cmdname（x1:type1，x2:type2，…，xk:typek）

…preconditions …

{ 

Y′=f（Y，x1，x2，…，xk）

} 

下面给个例子，管理指令CreateAssoc定义了关联的创建，其前提条件规定了x、y和z参数分别对应用户属性（UA）、访问权限集（ARS）和策略元素（PE）元素。函数体描述了将元组（x，y，z）添加到关联关系集（ASSOC）中，从而将关系的状态更改为ASSOC′。

createAssoc (x, y, z) 

 x ∈ UA ⋀ y ∈ ARS ⋀ z ∈ PE ⋀ (x, y, z) ∉ ASSOC

 { 

 ASSOC′ = ASSOC ⋃ {(x, y, z)} 

 }

每个管理指令都需要对NGAC配置进行修改，包括创建或删除策略元素，策略元素间的指派，关联，禁止或职责。

与管理例程相比，管理指令更基础，也就是说，管理指令为NGAC框架提供了基础功能，而管理例程使用一个或多个管理指令来执行它们的功能。

管理例程主要由一个参数化接口和一系列管理命令调用组成。管理例程基于管理命令来定义NGAC模型的保护能力。管理例程的函数体作为一个原子事务执行，错误或能力不足造成的任何指令执行失败都会导致整个例程失败，产生与没有执行任何指令相同的效果。管理例程通过下列格式定义： 

rtnname (x1: type1, x2: type2, …, xk: typek ) 
 … preconditions …
{
cmd1;
conditiona cmd2, cmd3;
. . .
conditionz cmdn;
} 

管理例程的名称rtnname位于例程的形式参数声明之前，x1: type1, x2: type2, …, xk: typek（k≥ 0). 管理例程的每个形参可以作为管理指令cmd1, cmd2, …, cmdn (n ≥ 0) 的调用参数，它们组成了管理例程的函数体，并且每个命令可以有一个前置条件，这些前置条件可以确保管理指令的参数的合法性。

例如，在创建新用户时，管理员通常会创建多个容器，将它们链接在一起，并授权用户将这些容器作为其工作空间进行访问。与手动为每个新用户逐步执行此操作序列的方式不同，整个操作序列可以定义为一个可重复执行的管理例程，并作为原子操作整体执行。

要执行一个例程，用户（管理）必须具有执行该例程中每个管理命令所必需的能力。

5

其他类型的操作和策略

NGAC接受能够创建/管理策略元素和关系（表示策略和属性）的管理性操作，以及可以在客体（表示数据服务资源）上执行的基本输入和输出操作（例如，读和写）。

为了适应数据服务，NGAC可以建立并提供对其他类型的操作（例如发送、提交、批准和创建文件夹）的控制。但它不一定需要这样做，因为数据服务能力中的数据消费、操纵、管理和权限分发等基本操作，可以通过对数据的读/写操作和对数据元素、属性和关系的管理操作（这些操作可以改变用户读/写数据的访问状态）的组合来实现。

考虑下面的管理例程，它创建了一个“file management”用户，并为该用户提供创建和管理客体和文件夹的能力，以及在图6b的情况下中控制和共享对客体的访问。该例程假定指派给“File Management”策略类的用户属性“Users”已经存在。

create-file-mgmt-user(user-id, user-name, user-home) {

 createUAinUA(user-name, Users);

 createUinUA(user-id, user-name);

 createOAinPC(user-home, File Management);

 createAssoc(user-name, {r, w}, user-home);

 createAssoc(user-name, {create-o-to, delete-o-from}, user-home);

 createAssoc(user-name, {create-ooa-from, create-ooa-to, 

  delete-ooa-from, create-oaoa-from, create-oaoa-to, delete-oaoa-from}, user-home);

 createAssoc(user-name, {create-assoc-from, delete-assoc-from}, Users);

 createAssoc(user-name, {create-assoc-to, delete-assoc-to, r-allocate,

w-allocate}, user-home);}

该例程在（u1、Bob和Bob Home）参数下，可以为用户u1创建“File Management”数据服务能力。通过该例程，用户属性“Bob”被创建并指派给“Users”，用户u1被创建并指派给“Bob”。此外，对象属性“Bob Home”被创建并指派给策略类“File Management”。此外，用户u1被授予（委托）在Bob Home中创建、组织和删除客体属性（该属性提供文件夹）的管理功能，并且u1被授予创建、读取、写入和删除与文件对应的客体并将这些文件放入其文件夹的能力。最后，u1被提供了自主能力，可以将自己目录下文件的读写权限授予“Users”容器中的其他用户。

如图6b所示，在执行此管理例程后，用户u1可以使用以下例程授予用户u2（Alice）对客体o2的读/写访问权：

grant(user-name, rights, file/folder) { createAssoc(user-name, rights, file/folder)}

通过这个例行程序，Bob可以根据自己的意愿，“授予”Alice读取o3的权限。然而，即使Bob这样做，Alice也不能读取o3。这是因为o3包含在“Project Access”策略类中而缺少特权（u1，r，o3）。虽然Bob不能通过其委托的“grant”能力向Alice提供对客体o3的读取访问特权，但是Bob可能会将读取o3内容的能力“泄漏”给Alice。只要Bob首先读取o3的内容，然后将该内容写入o2就能达到此目的。即使Bob是不会执行此类操作的可信用户，但代表Bob的恶意进程也可能在Bob不知情的情况下执行该行为。为防止数据泄漏，策略配置中需要增加以下职责：

当进程p执行（r，o），其中o→+ Gr2-Secret，执行create p-deny(p, {w}, ¬Gr2-Secret)

此职责将阻止进程（及其用户）读取Gr2-Secret中任何对象的内容并将其写入另一个容器（不是Gr2-Secret）中的对象。

6

NGAC功能架构

NGAC的功能架构（如图9所示）与XACML一样，也分为4个功能层：实施、决策、管理和访问控制数据，各功能组件协同工作以实现受策略保护的访问和数据服务。在这些组件中，PEP能够捕获应用程序的访问请求，包括进程id、用户id、操作以及该操作涉及的数据资源或访问控制数据元素和关系。管理操作例程在PAP中实现，资源读/写例程在RAP中实现。

图9 NGAC标准功能架构

为确定是否准许当前要执行的访问操作，PEP将访问请求提交给PDP。PDP通过PAP基于存储在PIP中的数据元素和关系的当前配置（即策略）来计算决策。

与XACML体系结构不同，来自NGAC PEP的访问请求信息以及NGAC关系（由PDP检索）提供了生成决策的完整上下文。PDP将批准或拒绝的决定返回给PEP。如果授予访问权限并且操作是读/写操作，PDP还返回客体内容所在的物理位置，PEP向对应的RAP发出对客体内容执行操作的命令，RAP最后返回其执行的结果状态。在读取操作的情况下，RAP还返回数据内容的类型（例如PowerPoint），PEP还要调用正确的数据服务应用来使用它。如果访问请求与管理操作有关，并且决策结果为准许，则PDP向PAP发出命令，使其对存储在PIP中的数据元素或关系执行操作，并且PAP将状态返回给PDP，而PDP再将状态转发给PEP。如果RAP或PAP返回的状态为“成功”，则PEP向事件处理点（Event Processing Point，EPP）提交访问上下文。

如果该上下文与某个职责的事件模式匹配，那么EPP将自动执行该职责的管理操作，从而可能更改访问状态。注意，NGAC是数据类型无关的，它将可访问的实体视为资源数据或访问控制数据的元素或关系，直到访问过程完成之后，数据的实际类型才对相应的应用程序起作用。