本文整理了《Guide to Attribute Based Access Control (ABAC) Definition and Considerations》一文核心思想和观点的第二部分《企业ABAC的实施问题》，第一部分详见《ABAC的基本概念》。

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

第二部分 企业ABAC的实施问题 

在跨企业部署ABAC系统之前，必须考虑许多因素。在充分考虑目前技术状况和总结联邦政府内部多次尝试在大型企业中部署ABAC的经验教训的基础上，整理了一些指导原则供读者借鉴。这些建议按照图6所示的NIST系统开发生命周期（SDLC）的各个阶段分别给出。有关SDLC的更多信息，请参阅[NIST800-100]。企业ABAC部署主要考虑前四个阶段：启动、获取/开发、实施/评估和操作/维护。本节专门关注这些阶段。

图6 ACM NIST系统开发生命周期（SDLC）

企业ABAC的开发和部署需要考虑许多影响其设计、安全性和互操作性的因素。这些因素导致了一系列应该考虑的问题：

• ABAC实施的项目论证。开发/获取新功能和从旧功能过渡的成本是多少？ABAC提供了哪些重要的好处？ABAC引入了哪些新的风险（如果有的话），需要哪些新的管理结构来管理共享的功能和策略文档？这些策略以前都是由人工介入的决策。哪些数据集、系统、应用程序和网络需要ABAC功能？数据丢失或误用如何管理？

• 了解运营需求和整个企业架构。如何管理、监视和验证权限以实现合规？企业将公开哪些接口和客体用于信息共享？将使用什么ACM？如何共享和管理主体和客体属性？访问控制规则是什么？它们是如何抽取、评估和执行的？企业内部如何管理信任？

• 建立或完善业务流程以支持ABAC。访问规则和策略是否被充分理解和记录？如何识别和分配所需的属性？如何以层次化方式应用多个策略并消除冲突？如何处理访问失败？新策略由谁创建？如何共享和管理公共策略？

• 开发和获取一套可互操作的能力。互操作性如何实现？如何将身份管理中的主体属性集成到ABAC中？如何处理不同或特殊的身份需求？如何跨企业实体共享和维护主体属性？身份验证、授权、属性管理、决策或强制执行能力的集中化实现和分布式部署的利弊是什么？如何在策略决策中使用环境条件？在策略决策中，信任在安全、质量、准确等层面是如何量化、传递和使用的？如何在组织之间映射主体属性？如何制定策略以整合最新的可用主体、客体和环境条件属性集？

• 性能评估。如何为未连接、带宽受限或资源受限的用户管理主体属性？企业新成员的接口规范如何可用？属性和策略更改的质量和及时性如何衡量和实现？整个系统和端到端性能是否足够？

以下各节将更详细地讨论这些原则和问题。

壹 启动阶段的考虑

在启动阶段，企业评估ABAC系统的需求及其潜在用途，确定ABAC系统是一个独立的信息系统，还是已有系统的一个组件。一旦这些任务完成并确定ABAC的能力需求，在ABAC系统获得批准之前，还需要一些工作，包括明确定义目标和高级需求。在这个阶段，企业需要定义ABAC系统的高级业务、操作需求以及企业架构。

1 ABAC项目的论证

与任何主要系统的部署一样，在部署企业ABAC之前，应进行重要的需求评估、商业研究和规划活动，以确定在给定目标环境下，ABAC是否是正确的访问控制方式。ABAC的优点是可以在事先不知道或不了解主体的情况下提供访问控制能力，并对有限的一组任务或业务关键目标提供大规模的企业信息共享。

在生成任何技术需求或做出部署决策之前，评估和论证ABAC项目以及定义该项目的企业目标非常重要。实施企业ABAC会带来巨大的开发、实现和操作成本，企业客体的共享和保护方式也会发生改变。来自其他组织的案例研究或经验报告可能有助于规划ABAC的部署。对于有限的一组客体，采用增量方法逐步实现ABAC保护可能更为实际。这一实施方式将在最大程度上建立和利用适合于整个企业的策略和属性。逐步构建ABAC功能所带来的反馈能够完善策略和属性定义，并行使必要的治理和配置管理功能，以支持整个企业更广泛地使用ABAC。应当指出，如果不解决以下各小节中提出的问题，企业在部署ABAC时可能会遭受重大延误并产生额外费用。

2 可扩展性、可行性和性能要求

在考虑ABAC产品或技术的部署时，可扩展性、可行性和性能是需要考虑的重要问题。企业ABAC（允许一个组织访问同一企业中由另一个组织管理的客体）需要ABAC组件之间的复杂交互。通常，这些组件跨组织边界分布在整个企业中，有时分布在不同的网络上。企业越大、组织机构越多样化，这些交互就越复杂。以往通过一个简单的请求就可以访问文件库里的文档，现在变成了，从企业策略库拉取策略、从物理/逻辑上分散的多个属性源拉取不同的属性、通过第三方验证与该文档相关的客体属性的完整性、在企业的某个IT设施上生成策略决策，最后又在另一个IT设施上执行该策略决策。可行性评估应该检查业务应用是否支持ABAC，无论它是原生地支持，还是通过第三方来实现支持。所有这些潜在的交互都存在性能成本，在确定通过企业ABAC实现共享的客体范围时，必须对这些成本进行评估。为了减轻潜在的性能和可扩展性问题，应该考虑各种体系结构。ABAC组件的部署分布应该考虑到底层企业架构，以及要共享的数据和客体的位置。例如，PDP和PEP可部署在同一个管理单元下。

2.1 开发维护费用

虽然ABAC在跨企业部署时提供了许多重要的新功能，但从长远来看，ABAC的开发、部署和维护成本可能会超过它的价值。此外，为了使用ABAC而对应用程序进行改造的成本与采购、设置和维护授权基础设施（指ABAC系统）是完全分开。虽然可以通过放弃当前的解决方案来节约一些维护成本，但这些节余的部分很快就会被ABAC的主体属性和策略的管理和维护成本，以及对新系统的支持成本抵消掉。为了确定风险成本和安全成本之间的平衡点，ABAC这种更精确、一致和灵活的安全特性必须被仔细地评估并量化。综合考虑到这些因素，ABAC并不是解决所有访问控制问题的通用方案，但可证明的是，在主体和客体具有各种不同属性的环境中，如果访问决策涉及这些属性之间的复杂关系，那么ABAC就是一种可行的解决方案。

2.2 向ABAC迁移的成本

伴随着迁移到ABAC，管理和业务流程面临重大的转变，即客体由企业制定的策略和企业控制的属性（有时还包括本地控制）控制。这些客体现在可能需要与一组其他的特性相关联，而这些特性可能并未在访问控制中使用过。习惯于登录网络后随意访问资源的用户可能不会再拥有便利。虽然策略制定者将尽其所能制定出反映当前的任务和业务需求的策略，但在访问那些关键任务或业务功能时，总会出现一些意料之外的拒绝访问。

随着ABAC产品的部署实现和企业访问控制的变化，新的流程和功能需要集成到用户的日常业务流程和企业策略中。在迁移过程中，重要的是确保用户理解为什么要改变这些访问控制，以及这些更改会对业务的完成产生什么影响。这些用户需要在新的ABAC系统和过程中接受培训。部署ABAC所带来的这些变化需要适当地传达给用户，以便展示其价值，包括更好的用户体验、增强的安全性和对关键信息的保护、新的ABAC系统的要求以及将逐步淘汰的传统访问控制系统。用户也可能对现有业务流程比较满意，不能立刻看到部署ABAC所带来的价值，那就需要重点强调ABAC在增强企业安全态势方面与现有的访问控制机制之间的差别。

2.3 权限审查和授权监控的需求

有的企业可能希望对主体及其权限能力进行审查，包括对与客体关联的访问控制条目的审查。简单地说，在发出请求之前，需要知道每个人有哪些访问权限，有时被称为“事前审计”，通常在证明“合规性”（符合特定的法规或指令）的时候，是非常必要的。另一个常见的审查目的是确定谁有权访问特定客体或特定资源集。ABAC系统可能不适合有效地进行这些审计。相反，ABAC的一个关键特性是客体属主能够在事先不知道主体的情况下保护和共享客体。对能够访问给定客体的主体集的计算需要大量的数据检索和运算量，这可能需要每个客体属主通过模拟企业中每个已知主体的访问请求来计算。限制ABAC实现的范围有助于预先确定访问授权，但如果企业需要此类验证，则应研究验证授权有效性的其他方法。

2.4 理解客体保护要求

企业的不同位置存在大量不同的操作和客体类型，需要对其强制执行AC策略，包括操作系统、应用程序、数据服务和数据库管理系统。尽管可能存在一些NLP来辅助访问授权，但大多数客体的访问控制是通过由本地业务规则管理的本地组策略实现的，或者取决于一些未记录的评估因素和非标准的潜规则。实现ABAC首先需要对客体及其保护要求有一个透彻的理解，否则开发和实现企业ABAC的成本将急剧增加。建议首先将企业ABAC部署应用于具有良好定义、控制，以及文档记录的客体。

2.5 企业治理与控制

成功的企业ABAC需要协调和确定一些业务流程和技术因素，也要建立企业的职责和主管。如果没有适当的治理模型，企业将开发出烟囱式解决方案，企业的互操作性将大大降低。建议组建一个企业治理机构来管理所有身份、凭证和访问管理功能的部署和操作，并建议每个下属组织建立一个类似的机构，以确保ABAC部署实现过程中的管理一致性。此外，建议治理机构开发一个“信任模型”，用于描述信任链，并帮助确定信息和服务的所有权和责任，确定对附加策略和治理的具体需求，以及确定验证或实施信任关系的技术方案。信任模型也有助于组织明确，如何使用和保护他们共享信息，以及怎样信任来自其他组织的共享信息。

此外，企业授权服务应与安全审计、数据丢失预防、安全配置管理、持续监控和网络防御能力紧密集成。授权服务本身不足以保障网络上关键任务客体所需的安全性，应充分理解企业安全需求以及ABAC实施将带来的影响。例如，当使用分布式ACM架构时，访问控制决策和事件的审计能力可能会受到影响。

ABAC系统可以受益于企业环境中部署的信任框架。通过对使用ACL的传统信任链和使用ABAC的信任链比较（图7和图8）可知，要使ABAC正常工作，需要有许多更复杂的信任关系。ACL由客体属主或管理员建立，通过将用户添加到ACL来设置对客体的访问，实现客体访问规则的执行。在ABAC中，信任的根来源于不同的起点，例如主体属性的主管部门或策略管理员。

图7 ACL信任链

图8 ABAC信任链

在管理信息共享的固有风险、部署企业ABAC解决方案时，必须从两个角度考虑风险。首先，ABAC解决方案可以被视为诸多保护企业、降低风险的安全控制选项之一。ABAC的实施可以降低未授权操作访问受保护资源的风险，因为ABAC可以通过一致地实施执行易更新的精确策略，应对不断变化的威胁。第二，ABAC将受保护的客体暴露给未知实体访问，ABAC可能增加，也可能减少企业的运营风险。假设属性发布过程是正常的，ABAC系统在一定程度上依赖于属性发布机构。风险源的多样性给ABAC带来了许多挑战，必须通过治理和正式的信任模型来应对这些挑战。

在建立ABAC固有风险的治理模型时，重要的是确保与每个责任机构建立机制和协议，以便监测和管理这些信任根以及由于不正当访问而产生的任何责任。

3 开发操作需求和体系结构

在实施ABAC解决方案之前，必须满足下列几个顶层的操作和架构（architecture）规划需求：

• 首先，确定将由ABAC共享和保护的客体。

• 第二，定义规则或策略。

• 第三，与主、客体属性的主管部门一起，协调访问控制规则开发人员，确定和定义主、客体属性。

• 第四，开发与策略编写、验证和管理相关的流程。

• 最后，确定ACM在企业中的部署位置，与属性、策略和策略决策相关的请求和响应如何产生。

3.1 客体标识和策略分配

ABAC解决方案需要共享和保护的客体可能随着组织要求的差异而有所不同。每个客体或客体类都必须被标识出来，保护每个客体或客体类的策略或规则也都必须写入文档。需要建立一组业务流程来给在ABAC部署范围内创建的每个新客体建立标识、分类和分配策略。

3.2 属性体系结构

通常，访问控制策略通过一些包含属性的条文来描述。因此，策略中所有用到的属性都必须建立、定义，并受赋值范围的约束。定义"属性及其赋值范围"的数据模式（Schema）必须发布给所有参与者，以帮助客体属主开发规则。一旦建立了属性和赋值范围，就需要建立为主体和客体提供属性和适当属性值的方法，以及包含属性存储库、检索服务或完整性检查服务的体系结构，为了实现这些属性的共享，还需要为其实现开发接口和共享机制。

3.3 主体属性

人作为主体时，其主体属性通常是由企业组织提供，并且可能由几个不同的主管部门（人力资源、安保、组织领导等）提供。在这种情况下，获取权威数据的方法是众所周知的。例如，只有安保部门能够基于官方的个人许可信息，提供许可属性或对许可属性值的断言；个人不能修改自己的许可属性值。其他主体属性可能涉及主体的当前任务、物理位置和发送请求的设备等；需要开发评估模块来确保此类主体属性数据的质量（精准度，有效性等）。

权威部门提供的主体属性应该在质量、保证、隐私和服务期望方面具有适当的可信性。这些期望可以在属性实践声明（APS）中定义。APS提供将在整个企业中使用的属性列表，并且可以标识企业的权威属性源。另外，还需要进一步扩展网络基础设施功能（包括维护属性机密性、完整性和可用性的能力），以便在组织内部或跨组织共享和复制权威的主体属性数据。

3.4 客体属性

客体属性通常在客体创建时设置，可绑定到客体或存储在客体以外并被客体引用。显然，访问控制机构无法密切监测所有事件。通常，这些信息是由非安全流程和需求驱动的。完好的属性数据才能支持完好的策略决策，必须采取某种措施，确保客体属性只能以客体属主或管理员认为合适的流程来进行分配或验证。例如，客体属性不能被主体修改以操纵访问控制决策的结果。访问控制机制在计算策略决策时，客体属性必须可供检索。创建客体属性的其他注意事项包括：

• 一般来说，用户不知道客体属性的值（例如，给定用户被授权访问哪个敏感分区）。这应该在ACM中考虑，以便用户只看到适用于他们的值。

• 与主体属性一样，需要一个定义属性名和允许值的客体属性模式。

• 属性需要在DP、MP和NLP中保持一致。

联邦政府和商业界已经做出了许多努力来创建客体属性标记工具，这些工具不仅提供数据标记，还提供客体属性的加密绑定和客体属性字段的验证，以满足访问控制决策要求。

3.5 环境条件

环境条件是指与特定的主体或客体无关，但在决策过程中必需的上下文信息。与主体和客体属性不同的是，它们不是因管理需要才被创建和管理，而是内在的、必须由ABAC系统检测到。环境条件（如当前日期、时间、位置、威胁和系统状态）通常在授权访问请求时根据当前匹配的环境变量进行评估。环境条件允许ABAC策略定义例外规则，或者只通过主体/客体属性无法描述的动态AC规则。在使用环境条件编写ABAC规则时，需要确保环境条件变量及其值是全局可访问的、防篡改的、并且与当前的使用环境相关。

3.6 访问控制规则

在ABAC中，所有AC规则都必须包含一些属性的组合和允许操作还可能包括条件、层次化的继承和一些复杂逻辑，它们为ABAC实现提供了丰富的选项。规则集和它们到客体的应用方式都必须进行适当的管理。规则必须准确、完整地反映NLP，并且由权威部门（企业组织或资源属主）开发定义、应用、维护、共享和断言。ABAC支持来自多个利益相关方的多个规则，也需要新的技术来协调不同的规则，以获得信息共享与保护之间的平衡。在某些情况下，可能需要限制哪些规则对哪些客体可见，以降低未经授权的主体通过操纵属性来获取授权的可能性。在其他情况下，被拒绝访问的主体应该需要一种方法验证或纠正那些导致拒绝访问的条件。某些组织可能希望跟踪访问被拒绝的情况，以便检查规则是否合适。同样，规则定义和部署机制和过程中应该包括强大的规则冲突消解（解决不同规则的决策结果不一致的问题）能力，以便确定规则冲突和解决方式。

3.7 访问控制机制与上下文处理

为避免客体保护中的冲突和脆弱性，ACM的组成结构和部署方式必须预先确定。例如，如果某一客体由两个不同的组织持有，未经授权的主体不应该仅通过限制较弱的组织的授权，就获得对象的访问权。企业组织应以一致的方式管理、维护和使用ACM，以确保互操作性和全面的安全性。

ACM检索信息、计算决策和执行决策的顺序可能因实现的差异而大不相同，甚至在计算访问控制决策时还要考虑环境条件。这就是上下文处理，简单指ACM在收集决策所需数据时执行的工作流。

此外，出于性能和可扩展性的考虑，策略、属性和决策信息在整个企业中存储和交换的位置，以及如何实现也是一个需要的考虑因素。

贰 采购/开发阶段的考虑

在采购/开发阶段，企业通过设计、购买、编程、开发等各种方式来搭建系统。通常，在此阶段，组织准备要在企业范围内运行的业务流程，并定义要部署和集成的系统。在这个阶段的第一环节，企业应该同时定义系统的安全性和功能需求。在这一阶段的最后环节，在项目进入实施/评估阶段之前，组织应对技术和安全特性/功能进行开发性测试，以确保它们能够按预期运转。

1 业务流程生成和部署准备

1.1 规则文件

对于由组织控制的每种类型的客体，都应该有一组对应的访问控制规则记录在NLP中。（用例可能是企业为一组对象定义NLP的最简单的方法）这些规则应该规定主体能或不能与这些由组织控制的数据或服务进行交互（包括创建、查看、修改、删除、转发），以及在什么上下文或环境条件下拥有这些特权。记录这些规则的时候，应当包含组织对适用策略和指南的解释、适用客体的特殊敏感性以及与这些客体相关的用户社区知识。

记录NLP有助于DP的开发，并提供从数字策略到书面策略的追溯。例如，许多组织难以将授权功能从ACL迁移到更健壮的ABAC基础设施，原因在于缺少NLP。例如，在接收到访问请求时，数据属主按照某种原则（通常没有文档记录）进行评估，“此人是否为工作组成员？”或“我对他或他的单位熟悉吗？”，然后在将请求者的名称添加到ACL之前作出访问决策。有良好文档记录的NLP能够将访问控制的决策过程，从人工生成的方式过渡到由一致的自动策略驱动生成的方式。

1.2 本地策略

除非上级部门或义务要求，下级组织不应降低本地策略的严格程度。如果企业中的下属组织能够独立地放宽企业策略制定的限制条件，那么系统固有的安全性就会受到破坏，可能允许本地访问本应被禁止的企业客体。

在联合企业中，本地访问策略实现的时候，需要基于主体所在的组织到本地组织的属性映射，并能够反映与客体关联的企业访问控制策略。根据组织之间的共享协议，具有共享所有权或控制权的客体应根据最严格的策略进行保护。

1.3 属性的一致性约定与理解

企业主体和客体属性的定义和取值范围必须是有效且一致的，以便授权组件能够在整个企业中，按照全局一致的已知属性值计算授权决策。无论这些属性是在组织内专用还是跨组织使用，属性的生命周期管理是属性主管部门的责任。

1.4 理解属性的意义

属性服务提供者需要描述属性及其与其他属性的关系，以便使用者能够正确、有效地使用属性。属性服务提供者必须记录属性值的权威定义和含义，并指导这些属性的使用。在某些情况下，必须将属性与其他属性结合使用，才能建立有效的上下文，例如角色和组织的组合——除非角色定义在组织上下文中，否则它没有任何意义。例如，对于整个组织的运营总监，他的职责可能包括财务、人力资源、法律和其他部门，其上下文含义与IT部门Web服务分部的运营总监完全不同。如果不了解属性、上下文，也不理解属性值对策略决策的意义，那么DP和决策可能会在信息不足的情况下或使用错误的算法生成。

1.5 访问失败的处理过程

应建立一套针对拒绝访问和运行错误等异常情况进行处理的流程/程序，以便在给定任务、角色以及确保知其所需原则的前提下，为用户提供一种能够矫正/调整访问决策结果的方法。由于在ABAC中，授权服务从传统的将帐户添加到ACL中的方式逐渐成熟，发展到自动决策的方式，系统用户很难理解和矫正访问拒绝（指矫正决策结果）。ABAC为获得访问授权而建立的“属性发现”和“属性获取”流程将有助于简化这种转变,这也可以扩展到解决连接丢失等访问授权服务组件时的问题。

在任务关键型角色中，主体应该能够理解这些限制，并请求一些例外的操作，如转向官方的帮助系统，或者尝试其他路径来访问等效的信息或服务。

1.6 属性的隐私考虑

开发ABAC应依从所有适用的隐私法律、指令和政策。由于主体属性的个人性和描述性，属性共享的实施可能会由于无意中将属性数据暴露给不受信任的第三方，或将敏感信息聚集在保护程度较低的环境中，而增加侵犯个人身份信息（PII）隐私的风险。支持“属性共享”的组织应通过信托协议，以确保正确处理PII和执行PII条例。这些协议应详细说明信任链中所有组成部分对PII的授权使用和处理，以及验证、补救和裁定违规责任的方法。第二个考虑是，主体属性可以通过授予/拒绝决策的模式来呈现。如果主体访问某个特定资源，则该主体必须具有该资源的访问规则中指定的属性，组织应保护访问日志或其他可能泄漏授予/拒绝决策的信息。

1.7 数字策略创建和维护

系统中定义的每个DP都应满足NLP的要求。DP属于敏感数据，需要像客体一样，按照适当的策略来进行保护。这些策略可能与DP特定部分的创建和修改有关。DP必须由能够解释NLP，并有权编写DP的人来编写或修改。一个NLP可能需要定义多个DP来实施，应特别考虑确保低级策略不会与高级策略冲突。不同的组织应制定和维持只适用于其组织或下属组织的本地策略（local policy）或特定策略。

2 系统开发解决方案

2.1 企业内的标准化和互操作性

实现者应该使用全面的标准化方法，通过利用满足这些目标的产品或能力，实现当前的互操作性和未来部署的灵活性。实现互操作性和经济高效的ABAC部署的惯例方法是使用一系列标准、规范和标准化配置（定义标准选项的子集，即配置文件）。具有可选元素的标准可能会被开发者以不同的方式实现，最终导致完全符合标准的服务或应用程序却无法支持互操作。因此，应该定义明确和标准化的配置文件，特别是在跨组织环境中。当获取ABAC解决方案时，实施者应该使用通常约定的专门配置文件，同时考虑标准注册机构提供的标准和配置文件。

单个授权服务组件（例如，策略决策点、策略执行点、策略检索点、属性检索点、元属性检索点）应使用标准的开放接口开发，以便来自多个产品的系统可以同时部署，并能够确保互操作性。企业应考虑将功能、接口、基础设施和产品支持的需求作为采购流程的筛选条件，而不用考虑目标产品的分类或从属关系。

2.2 身份管理集成

访问客体的请求必须经过身份验证，证明是来自唯一的主体。身份验证通过使用身份凭证来实现，并且必须在做出访问决策之前完成。ABAC系统需要支持组织使用的认证机制和凭证。这可能意味着，如果这些认证机制或凭证阻碍了ABAC的实现，组织就需要对其身份验证基础设施进行升级改造。这些凭证中传递的主体属性应能唯一地确定主体，负责颁发凭证的身份审查过程应确保该身份实体可被追责。在整个企业中，身份发行和审查过程应被认为是可信的，并足以执行问责要求。采用强身份验证方法（[NIST800-63-3，NIST800-63B]）能够满足这些要求。一旦主体被认证，其主体属性就可以用来确定访问决策，并且访问决策可以被支持审计的系统捕捉到，以提供访问请求的属性信息。例如，采用可信的证书颁发机构颁发的X.509证书，通过安全传输层协议TLS1.2与客户端完成认证会话的访问请求，通过证书与实体建立绑定关联。

2.3 支持NPE

在访问控制服务中对NPE的支持有特殊的要求。授权服务使用与实体关联的任何形式的属性。绑定到NPE的属性不仅有助于定义唯一的NPE，而且还反映了组织中该实体的上下文。

在某些情况下，NPE主体可能代表一个或多个人类主体。这些NPE可以携带自己的、独立于任何人类主体的身份凭证。请注意，基于NPE凭证生成访问决策的访问控制系统将无法在访问请求发生时，将该请求归结于某个用户、或担任某个角色的人，或登录到组帐户的人。NPE可以独立行事，也可以代表经过认证的个人。NPE可以包括网络设备（如交换机、路由器），运行在服务器（如门户程序）、工作站和其他终端设备上的进程。随着任务和安全功能的日益自动化，NPE将在授权服务交互中扮演更大的角色。

2.4 ABAC组件间的授权和数据完整性

当授权服务组件交换敏感信息时，授权服务要求ABAC组件（如PEP、PDP）之间进行双向认证。对于每次数据交换，都应考虑对数据源、数据完整性和及时性进行验证。例如，当授权服务需要从权威的属性服务获取属性时，应使用双向身份验证，然后使用验证消息完整性和消息来源的机制。在属性数据的交换过程中，双方都应使用强身份验证协议（例如，X.509身份验证）来提供双方所需的安全保障级别。

2.5 集成其他安全组件

授权服务本身不足以确保分布在整个企业中的关键任务客体所需的安全性。需要建设全面和一致的安全能力来确保所需的保证级别，通过集成这些能力，能够为制定和实施访问决策提供更全面、更完备的安全信息。这些安全组件包括主体身份验证、安全审计、安全配置管理、入侵检测和监视功能。

2.6 属性源的选择和访问

授权权限需要仔细的处理，以便权威的属性源能够向策略决策点提供属性。当有多个属性服务可用时，可能具有不同的元属性（如保障级别），属性“存储/策略信息点”应在满足属性检索的策略匹配度、性能和可用性要求之间进行平衡。

2.7 主体属性的共享存储库

如果目标网络的连通性可以充分利用规模效益、加强质量控制和标准接口，则应考虑采用共享存储库来存储主体属性。使用共享属性库的另一个优点是，可以为来自多个源的数据提供单一的访问点。与管理多个连接相比，构建和管理到单个访问点的连接可能更简单。在某些情况下，连通性受限、带宽不足或时断时续的网络连接都会妨碍授权服务提供商可靠地使用共享存储库。因此，有必要维护数据的本地副本，它们不能与共享属性存储库保持同步，也无法访问当前最新数据。

2.8 最小属性集

在某些企业中，可以定义一组最小的属性集合。通过定义标准的企业主、客体属性集，可以方便地修改DP以反映策略的变化。这种方法的典型例子是分类网络中的分类和区分标记。在大多数情况下，如果没有适当的标记，就无法将客体放置在网络，访问控制策略的定义要能够处理有限且众所周知的分类和分区标记。

2.9 环境条件

在策略需要的时候，环境（或上下文）信息能够输入到访问控制过程中。典型的环境信息包括包括威胁级别、主体/客体位置、身份验证方法或当前时刻。在一定时间内，环境条件的变化可能比主、客体属性的变化要快得多。

2.10 属性管理

分配属性的权限应该被明确地定义，并与适当的属性策略保持一致。某些形式的有效性验证、完整性检查和来源确认机制（用于验证属性的完备性、允许值、完整性和更改历史）应集成到用于属性管理框架中。

2.11 NLP/DP可溯性

高层级的企业书面策略/NLP和低层级的企业或本地DP之间的、全面和一致的可溯性应由合适的机构维护。这样可以确保书面策略的变更能得到充分评估，并相应地调整后续的DP。有了策略的可溯性，本地组织中多余的DP将是可审计的、可验证的，并且可以根据任何更改需求进行更改。

2.12 基于约定属性的策略规则

如果组织与其他组织达成了使用已定义属性列表的协议（某些特定于行业和用例专用的属性组），则拥有这些客体的组织必须确保它仅基于这些属性编写访问控制策略。如果只影响有限的安全信息共享能力，无论多有限，都应尽力使用公认可接受的共享企业属性集，以确保基本的互操作性。当新的需求出现时，企业可以选择引入新的企业属性和它们的共享规则。

例如，OASIS XACML 美国出口管制（EC-US）和知识产权管理（IPC）概要文件是具有限定值域、特定领域的标准化属性的范例。EC-US概要文件记录了美国商务部出口管理条例（EAR）和美国国务院国际武器贸易条例（ITAR）访问控制决策的共同属性。

2.13 策略决策服务的外部化

通常将PDP实现为与单个企业服务和应用程序分离的服务。这种方式可以避免为每个企业服务或应用提供相似决策服务所带来负担和费用，因为单个PDP可以支持多个企业授权服务。授权服务提供商使用由大型企业或组织提供的PDP服务，可以极大地简化服务/应用程序开发；节省了用于软件许可、培训、配置和部署这些服务实例的资金；并将运营和维护从单个应用中移除。

3 企业ABAC功能的其他考虑

在开发和实现ABAC企业授权功能时，架构师和程序管理人员必须记住，从现在使用的当前访问控制方法到最终项目完成将会是一个长期的过程。随着标准和技术的成熟，组织需要接受一些概念，这些概念有助于增强互操作性并促进高保障性的解决方案，同时抛弃专有的、烟囱式的解决方案。

3.1 访问控制决策的可信度

访问控制决策是通过从权威来源收集的、与风险水平相适应的准确、及时和相关的数据计算出来的的。访问控制决策的可信度取决于用于计算决策的信息的及时性、相关性、权威性、质量、可靠性和完备性。建立信任的其他因素包括身份识别和身份验证过程（例如，身份验证机制的强度、身份审查、凭证发放和校对、认证、源IP地址）。在采用基于风险的ABAC方法时，应考虑上述因素。

3.2 组织间的属性映射

组织可以用不同的名称命名属性和属性值。为企业的不同组织提供属性映射方案，可以最大限度地减少对被称为“企业属性”的这类属性的需要，这一点可能很重要。属性映射用作不同命名的属性或属性值之间的转换。例如，一个组织可以使用名称“公民身份”，而另一个组织可能使用名称“国籍”来引用同一组属性值。

在实践中，跨组织ABAC可以遵循第3.1.3.1节和第3.1.3.2节中概述的协作方法。这样，每个组织能够在同一个框架内作出本地决定，该框架可以保证组织之间的适当控制。创建新策略时，如果策略作者创建或指定自己的属性，则策略可能无法互操作。使用预先约定的属性将使策略更加统一和易于理解。

叁 实施/评估阶段的考虑

在实现/评估阶段，组织安装或实现系统，配置并启用系统的安全特性，测试这些功能特性，最后获得操作运行该系统的正式授权。在这个阶段中，大多数的考虑都集中在优化性能和确保安全功能的正常运行方面上。

1 属性缓存

当ABAC解决方案从原型/试点转移到部署时，可以考虑使用属性缓存来提高性能。如果每个访问决策都需要跨网络的属性请求，ABAC的性能可能会受到负面影响。这在低带宽、高延迟的环境中尤其明显。

除了与属性缓存有关的性能问题外，组织还需要对属性新鲜度对安全性的影响进行权衡。不能持续刷新的属性显然不如实时刷新的属性安全。例如，上次刷新后，主体的访问权限可能已发生变化，但在下次刷新缓冲数据之前，这些变化不会反映在缓冲数据中。

具有零星连通性的环境需要在本地级别缓存属性。使用本地缓存属性的安全后果需要在组织范围内的策略级来确定，并需要使用适当的技术手段来解决。在这些断开连接的环境中，管理员可以使用基于风险的分析作为访问决策的基础，因为本地（断开连接的）级别的属性可能会在系统刷新前更改或删除。本地（断开连接的系统）对可能过时的缓存属性的使用可能会给系统带来一定的风险，因为本地系统没有使用最新的可用属性。因此，有必要对是否部署此类解决方案进行基于风险的分析。

例如，现在要在一艘船上部署，该船仅与企业网络之间存在间断性的，非理想的网络连接。因为部署的用户群在整个运输过程中只有微小的变化，所以支持“意料之外”的系统用户就不那么重要了。在这种情况下，主体属性的批量下载和本地存储对于大多数本地访问控制决策来说可能就足够了。因此，主体属性数据可以在整个部署过程中存储在船上，本地应用程序和服务可以使用本地存储中的数据，而无需访问权威的企业属性源。虽然这是特殊环境的一个案例，但不应认为这是唯一的解决办法。

2 属性源最小化

最小化授权决策中的属性源的数量，可以提高性能并简化ABAC解决方案的安全管理。计划部署ABAC解决方案的组织，可能会受益于在解决方案部署过程中，组织的所有利益相关者之间建立起来的密切的工作关系。

3 接口规范

为了确保能够可靠地访问ABAC服务，所有通过企业ABAC功能参与信息共享的组织都应充分了解各类请求（包括属性请求和DP请求）的接口、交互方式和先决条件。同样重要的是，当基础设施和接口需求发生变化时，要确保能向所有依赖这些部件的组织提供更新通知，以便他们能够规划相应组件的修改。

肆 操作/维护阶段的考虑

在操作/维护阶段，系统和产品均已就位，系统的操作、增强和修改已经开发和测试完毕，硬件和软件也得以到添加或更换。在此阶段，组织应当监控系统的性能，以确保其符合预先设定的用户和安全需求，同时所需的系统修改也已完成。

1 质量数据的可用性

由于访问控制决策所需的信息（在某些情况下包括决策本身）可能处在客体和使用者外部，因此对信息和服务的访问将更加依赖于外部服务提供及时和准确数据的能力。基础设施必须是健壮的、经过良好测试的、有弹性的，并且可以根据任务需求进行扩展。这对于支持属性服务、属性存储、策略存储、策略和属性生成和验证组件、决策引擎、元属性存储库和信息通道。如果外包，服务协议应详细说明可用性、响应时间、数据质量和完整性要求。例如，对于被视为关键部件的数据和服务，必须考虑故障转移、冗余备份和业务连续性。为了保持高质量数据的可用性，需要由经过培训、授权的人员执行属性值的添加、更新和删除，并定期进行审核。

属性、服务的提供者和使用者之间的正式协议应该满足适当的服务、质量、可用性、保护和使用标准。各种法律法规规定了与相应保护信息相关的职责、责任和处罚。协议应包含这些要求以及与数据责任相关的要求。

在组织之间建立适当程度的信任协议是重要的。这些协议将有助于用一系列要求形式化这些信任关系，并可能有助于对违规项的处罚。属性服务的APS和MOU/MOA以及权威和负责的属性源也可以将组织策略转化为操作规程。这些正式协议描述了这些服务的目的、用途、参与者、责任和管理。

结论

该文件整理了许多以前独立的ABAC知识，以弥合现有技术和ABAC实现之间的鸿沟，并满足联邦政府内对ABAC产生的兴趣。

ABAC通过计算策略规则中实体（主体和客体）、操作和与环境的属性值，生成策略决策，来控制对客体的访问。ABAC依赖于对主体的属性、客体的属性以及形式关系或访问控制规则（定义允许操作所应满足的主体-客体属性组合）的求值。ABAC支持精确的访问控制，允许为访问控制决策提供大量的离散输入，以及这些变量的不同组合，以反映不同的规则、策略或访问限制。因此，ABAC允许数量不受限制的组合属性，以满足丰富的策略集需求。

本文定义了理解ABAC所必需的基本概念。具体来说，包括主体和客体属性，以及ABAC模型及其组件的一般特性。按照系统开发生命周期给出了一些思考建议，供企业在ABAC项目的规划、设计、开发、实现和运营过程中借鉴。特别针对大型企业，讨论了ABAC机制的优点和常见缺陷。

ABAC提供了前所未有的灵活性和安全性，同时促进了不同组织之间的信息共享。至关重要的是，这些能力的开发和部署基于共同的概念和功能要求，以确保最大程度的互操作性。ABAC非常适合大型企业。ABAC系统可以实现现有的基于角色的访问控制策略，并且可以支持从基于角色的访问控制迁移到基于请求方不同特性的、更细粒度的访问控制策略。它支持外部（非可预期）用户，并为其提供更高效的管理。然而，与简单的访问控制系统相比，ABAC系统更复杂，因此实现和维护成本更高。