本文整理了《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信任链
