本文整理了NIST.SP 800-205《Attribute Considerations for Access Control Systems》（Vincent C. Hu, David F. Ferraiolo, D. Richard Kuhn）的核心思想和观点，完整内容请至《权说安全》公众号。
摘要：在利用属性实现逻辑访问控制的方法中，授权组件按照策略、规则或用于描述给定属性集和许可操作的关系，通过评估与主体、客体、请求操作和环境相关的属性来确定访问决策。
关键词：访问控制，访问控制机制，访问控制模型，访问控制策略，属性，基于属性的访问控制，授权，权限
第一部分
对“属性”的基本考虑
一
“属性”的应用考虑
访问控制对属性评估的依赖，不仅体现在AC策略规则的定义方面，还体现在策略的执行过程中。良好、可靠、及时更新的属性数据对于适当且合理的访问决策至关重要，因此，AC功能或属性提供者提供的属性需要通过某种验证机制来保障属性的上述特性，同时也需要定义和描述一组原则和标准，用来确定那些可以用于访问决策的属性。
基于属性的AC系统通过属性来定义、实施AC策略。属性一般由权威部门建立、发布、存储和管理，跨组织共享的属性还需保障属性的定位、检索、发布、验证、更新、修改、安全和撤销能力。因此，属性的建立和定义都必须符合数字策略的要求，并受许可取值范围的约束，系统设计者必须为这些属性及其取值范围开发定义合适的数据模式，以帮助主体（例如，用户）和客体（例如，受保护的资源/服务）属主进行AC策略的开发。
除了需要建立属性及其允许值，还需要为该组织框架内的主体和客体创建提供属性和属性值的方法，用于存储、检索、更新或撤销属性。此外，还需要开发或引入实现属性共享的接口和机制。最后，为了实现属性保障，还需要建立一个属性评估方案，该方案通常需要从五个方面来确保属性的安全可信：
◆ 规划设计。指属性系统建设及属性共享机制的总体规划，以及在属性提供者和AC功能之间维护属性隐私的规则。这一考虑应从业务运营的需要出发，同时兼顾运营效率和保密性的目标。
◆ 真实性。保障属性定义的语义及语法正确性，为属性定义建立相应策略和技术基础，确保从协商、可信定义、通信协议、度量测量和属性维护等流程中获得的属性是可信的。
◆ 安全性。考虑存储和传输属性采用的安全标准和协议，避免系统漏洞或未授权操作损害属性数据的完整性和机密性。
◆ 及时性。指属性变化的刷新频率。属性系统必须确保属性的更新和检索频率足够频繁，以充分支持访问控制的实施。此功能还可确保在紧急情况下（如低带宽、服务丢失），当无法访问权威属性源或存储库的最新属性时，由访问控制组件使用的最新属性集可以及时缓存。此外，还需要考虑属性存储库的故障转移和备份功能。
◆ 管理维护。提供属性的维护机制，以确保有效和一致地使用属性，包括元数据、属性分组的层次结构、与属性性能相关的转换及优化方法，以及其他支持功能（例如，与认证集成的属性，用于记录属性访问和更新的日志等）。
1
规划设计
跨组织共享的属性需要支持各种使用方式，包括定位、检索、发布、验证、更新、修改、保护和撤销等操作。因而，属性必须由相应策略定义，并受允许值的约束。属性及其允许值的设计方案必须发布给所有参与者，以便在策略（关系）和规则开发中使用。属性可以由多个组织创建和共享，因此，属性框架的设计必须根据业务和访问控制的需要，考虑属性在创建、维护和使用中的问题。属性提供者和AC功能也需要维护隐私以满足保密要求。减少授权决策中使用的属性源数量可以提高系统性能，并简化整体访问控制解决方案的安全管理。此外，与参与属性准备的组织机构建立密切的工作关系，也有利于推进整个访问控制解决方案的部署。
1.1
主体属性
通常，AC功能或属性提供者所需的主体属性由属性权威部门提供，这些由属性权威部门提供的属性不包括属于非个人实体（NPE）的主体，例如系统中的自治服务、应用程序或操作系统。一般，组织内可能有多个权威部门，每个部门对不同的主体属性拥有权威性。例如，安全部门可能是“许可”属性的权威，而人力资源部门可能是“姓名”属性的权威。为了支持主体可以跨组织访问资源，需要保障主体属性的共享性，确保主体属性在不同组织间是一致的、可对应或可以相互映射，以便跨组织实施等效的安全策略。例如，在组织A中具有“Lead”角色职务的成员希望访问组织B中的资源，组织B需要使用类似的角色名称（例如，Task Lead）来表示等效角色。表1显示了主体属性的一个示例。
表1 主体属性示例
属性名称
属性值
策略应用
公司ID
ID号（例如，组织A）
主体和管理客体访问
部门
部门名称（例如，软件开发）
主体和管理客体访问
团队
组名称（例如，测试组）
主体和管理客体访问
名称
人员姓名（例如，Joe Smith）
主体和管理客体访问
授权
授权级别（例如，1）
管理客体访问
角色
角色ID（例如，任务负责人）
管理客体访问
培训技能等级ID
表征培训技能等级的ID标记（例如，最低要求）
管理客体访问
注：“策略应用”一栏列出了该属性适用的策略规则类型，如果AC系统应用了这些策略，则需要通过此属性来评估访问权限。
由于主体属性可能由不同的部门提供（例如，人力资源、安全、组织领导等），因此必须规范权威数据的获取方法。例如，只有安全部门才能根据人员许可信息提供或断言许可属性和属性值，个人不得更改自己的许可属性值。其他主体属性可能涉及主体的当前任务、物理位置和发送请求的设备，需要开发相应的程序来评估和确保此类属性数据的质量。
此外，权威主体属性的提供能力应当满足隐私保护和服务期望的要求。这些期望可在属性实践声明（APS，Attribute Practice Statement）中详细说明，APS提供了可供使用的属性列表，以及整个组织中的权威属性源。尽管如此，还需要额外的网络基础设施功能，以便在属性提供者和AC功能之间共享和复制权威主体属性数据。
1.2
客体属性
访问控制功能的数据资源属主（或监管者）、属性提供者通常在客体创建时提供客体属性。例如，客体属性可以绑定到客体对象，也可以存储在外部存储库中，并通过元数据服务引用。虽然可能不需要在整个企业中使用一组通用的客体属性，但必须在单个系统中一致地使用客体属性，以满足AC策略要求，并且应为用户发布可用的客体属性集，以便他们可以标记、标识客体属性或将客体属性应用于他们自己的客体。有时，可能还需要确保客体属性数据不被篡改或更改（即保持静态）以满足访问请求。表2给出了客体属性的一个示例。
表2 客体属性示例
属性名称
属性值
策略应用
客体ID
客体ID编号（如234567）
主体和管理客体访问
客体所有者
客体属主或组织的名称（例如，组织B）
主体和管理客体访问
客体创建日期和时间
日期和时间（如2015年5月26日）
主体和管理客体访问
客体删除日期和时间
日期和时间（如2017年5月26日）
主体和管理客体访问
授权
授权级别（例如，1）
管理客体访问
限制访问级别ID
表征限制等级的ID标记（例如，公共）
管理客体访问
注：“策略应用”一栏列出了需要此属性适用的策略类型，如果AC系统应用了这些策略，则需要通过该属性评估访问权限。
访问控制机构可能无法适当和密切地监控所有事件。通常情况下，客体信息是由非安全流程和需求驱动的，这些流程和需求取决于使用这些客体的业务案例。因此，必须采取措施确保客体属性的指派和验证流程是合适且权威的，并且经过了客体属主或管理员的认可。例如，客体属性不能由主体修改以操纵访问控制决策的结果。客体可以通过加密方式与其属性建立绑定关系，以便识别客体或其相应属性是否发生过不适当地修改。为了满足策略的使用需要，还必须部署相应的机制，确保为所有创建的客体分配适当的客体属性，为此可能需要实现一个企业客体属性管理器，从总体上来协调这些需求。在策略决策时，客体属性必须可供使用。最后，在创建客体属性时，还有一些其他的注意事项：
◆ 通常，主体并不知道客体的属性值（例如，客体的安全级别或谁可以访问客体）。应考虑客体属性的数据机密性，以便授权主体只看到适用于他们的数据。
◆ 与主体属性一样，需要定义客体属性名称和允许值的数据模式，以确保客体属性在其语法定义和语义中是有效的。
◆ 在共享属性的策略中，属性值需要保持一致。
联邦政府和业界已经做出了大量努力来创建客体属性标记工具，这些工具不仅能提供数据标记，还可以提供属性到客体的加密绑定，以及客体属性的字段验证功能，以满足访问控制决策的需要。例如，全球联合身份特权管理（GFIPM）规范[8]提供了主体属性的数据模型，而国家身份交换联合会（NIEF）规范[9]提供了一组属性定义，旨在促进组织间属性数据的交换共享。
1.3
属性粒度
对于支持最小特权原则的访问控制机制，必须对与主体相关联的属性进行约束，以进一步限制其访问能力。特定于组织的最小特权策略是通过AC规则的定义来描述的，AC系统提供了各种定义AC规则的方法，可以实现具有不同粒度、灵活性、范围及客体分组的最小特权策略，这涉及到AC系统可以控制的客体属性（例如，数据字段）的粒度。例如，此特性可以支持对数据库记录中具有不同分类的数据字段进行隐私控制。此外，还需要一些AC系统来控制或管理终端系统组件，如服务器、工作站、路由器、交换机、监控设备、移动终端、防火墙、电子邮件、用户、数据库和web应用程序。因此，基于组织的需求和体系结构来考虑属性的粒度是非常重要的。
1.4
环境条件
环境条件是指通常不与任何特定主体或客体关联，但在决策过程中需要关注的上下文信息。与主体和客体属性不同，环境条件不是在运行态之前以管理方式创建和管理的，而是内在的、必须由AC功能动态探测以用于访问决策。在授权访问请求时，AC功能根据当前匹配的环境变量评估环境条件，如当前日期、时间、定位、威胁和系统状态。环境条件驱动AC策略支持异常或动态规则的定义，以取代仅由主体或客体属性定义的规则。在使用环境条件定义AC规则时，需要确保环境条件变量及其值是全局可访问的、防篡改的，并且与使用它们的环境相关，这一点很重要。
1.5
示例
表3通过一个示例，给出了在属性规划设计阶段，需要关注的一些原则。
表3 属性规划设计的基本原则（示例）
关注点
基本原则
应用范围
覆盖率
属性涵盖组织的所有保护策略要求（即语义完备）
主体、客体
管理维护
集中统一管理
主体、客体、环境条件
粒度
属性基于组织的安全和操作要求
客体
2
真实性
除NPE外，属性的真实性断言受AC功能或属性提供者在获取、评估和维护属性时所采取的措施的影响。影响真实性的两个特征包括：
◆ 属性可信度
◆ 属性准确性
2.1
属性可信度
属性可信度关注对属性源的认证、识别和验证，主要适用于远程属性提供者或访问控制功能的属性源。属性值的真实性和信息的权威性之间存在区别。但是，重点必须放在AC功能或属性提供者信任（例如，凭据、联盟关系）的属性上，它们描述了对应的主体、客体或环境条件。例如，来自不同机构的信用评分可能不一致，但用户可能更信任来自特定信用报告机构提供的属性值。表4显示了基于不同置信水平的属性可信度示例。
表4 属性可信度示例
置信水平
属性来源
低
自报告
第三方公共属性源
中
属性验证（主要针对主体）
经过身份认证的属性源
高
从独立的潜在因素（即原始属性源）导出
高级身份认证（主要针对主体）
具有服务级别协议（SLA）的经过身份认证的属性源
属性可信度证明来自于基于风险的决策的概念，组织对远程AC功能或属性提供者提供的属性进行信任评估，然后根据评估结果做出基于风险的决策。要实现这一目标，可以采用的做法包括：
◆ 确定、定义和描述一组标准化的属性元数据，这些元数据可供AC功能使用，以帮助其评估授权决策所用属性的可信度。
◆ 确定、定义和描述一组可用于评估属性可信度的标准（如表4所示），其中包括用于确定给定属性客观置信水平的评分机制。
◆ 根据组织的风险承受能力，为远程AC功能和属性提供者制定指导性的性能指标和操作规范。
对于远程主体属性（即属性不是来自本地AC功能或NPE），属性保障依赖于用于确定和报告属性的信任链。如果报告属性的远程AC功能或属性提供者未对其进行验证，则必须提供相关证据，以证明这些属性经过了权威验证，并且它们与相关系统保持关联。
2.2
属性准确性
考虑到大量的实体需要进行互操作，属性定义不可避免地会出现同义但不同名。因此，制定所有实体都遵守的互操作标准和协议，对于实现组织间的合作至关重要。因而，需要制定属性定义的语法和语义标准，以确保互操作的成功实现。例如，需要考虑的一点是，虽然可以确保属性用户获得的某个属性来自可信的信用报告机构，但该属性值的信用评分可能不准确。因此，具有标准化语法和语义、对命名空间进行规范的属性字典需要由AC功能和属性提供者共同商定和发布。
AC功能和属性提供者之间数据类型（例如，整数、字符串、布尔值）和分类（例如，级别、等级）的不同是导致属性值不准确的主要原因。因此，制定数据解释/转换协议，有助于保证为策略评估提供准确的属性值。例如，访问控制模型固有的属性值（例如，RBAC的角色）必须准确地分配给与组织业务职能相关的主体。除非AC功能或属性提供者制定了产生属性值的标准、算法或协议，否则通常使用属性可信度（参看4.2.1）评估其准确性。
2.3
示例
表5给出了属性准确性评估标准的示例
关注点
基本原则
属性应用
验证
通过提供和管理适当验证属性的准确性
主体、客体、环境条件
标准应用
存在文档化的规则或标准用于属性值分配和定义（语法和语义规则）
主体、客体
信任标准
存在可用于确定属性可信度的标准
主体、客体
远程AC功能/属性提供者指南
存在针对远程AC功能或属性提供者的性能指南和规范
主体、客体
《属性元数据：一种用于评估联邦属性的方案》（NISTIR 8112）[3]，根据组织用于支持业务决策的标准化属性的元数据，从属性的精准、出处、流转、隐私和分类等方面对其准确性进行审查。该文档使企业能够通过基于属性的自动决策系统，来实现更广泛的基本业务功能，另外，还提供了一个信任评估框架及相关组件的建设指南，以实现标准化属性的可信度评估。
本文第5节展示了一个通用的属性框架示例，该示例通过集成和定义属性来实现属性准确性，从一个管理企业环境中的多个AC系统的NLP开始，展示了该组织的属性框架结构。
3
安全性
AC功能和属性提供者必须确保属性值及其元数据的安全性，防止属性数据受到篡改或损坏，对存储的属性信息进行充分审查，并在其飞地内为属性提供高级别的保护。属性安全还决定了由属性提供者向AC功能提供属性是不是安全。换句话说，AC功能或属性提供者如何确保接收方实际接收的属性就是它打算发送的属性？属性安全性包括对属性存储和属性传输的安全性评估。例如，为了提高属性传输的安全性，可以通过加密和签名机制（例如，签名SAML断言[10]，TLS[11]）传输属性。
3.1
存储安全性
存储安全性主要评估属性的存储机制和AC措施，以及在属性生成过程中，属性提供者所提供的保护手段。注意，第4.2.2节关注的是属性值的语义准确性，本节存储安全性关注的是属性生成和管理中的安全，其评估的因素或能力包括：
◆ 加密措施
◆ 为检测属性值的篡改而采取的措施
◆ 属性数据存储环境中部署的纵深防御设施
◆ 保护属性更新、复制、撤销或修改等操作的安全策略
◆ 属性变更的记录和审核
评估存储安全性的因素或功能通常也用于评估本地AC功能，因为这些信息可以在本地获取。但是，对于属性提供者、远程AC功能或不能访问本地系统的远程属性提供者，可能需要一份包含评估因素（或能力）检查表的协议或合同，来对相关评估因素进行约定。
3.2
传输安全性
传输安全性评估属性在传输过程中的安全性，需要评估的因素或能力包括：
◆在属性提供者或AC功能之间传输属性请求和属性值的安全协议（例如，在无加密的情况下传输，而不是在启用PKI的TLS会话中传输）。
◆重放攻击保护通常通过远程AC功能或属性提供者提供的数字签名来实现。可以保证属性的完整性和机密性。
◆传输的属性应支持多层接收处理（即，当属性由远程AC功能或提供者发送时，确保该属性可以正确通过路由转发链传输）。例如，对于在上层通过数字签名（加密绑定）为属性提供散列值，以确保属性的完整性。
除了AC功能和属性提供者的安全传输外，还必须考虑AC功能之间的安全措施。为了做出正确的策略决策，应保护AC功能之间传输的属性不会受到系统内部其他进程的篡改。如果可能，应考虑引入一组供AC系统使用的措施或方案（如SAML），以帮助确定属性是否已满足安全考虑的相关要求。
3.3
示例
表6给出了属性安全性标准的一个示例。
表6 属性安全性的基本原则（示例）
关注点
基本原则
属性应用
存储库安全
安全或可信的属性存储库（例如，专用或共享属性存储库）
主体、客体、环境条件
通信安全
AC功能和属性提供者之间的安全通信（例如，加密）
主体、客体、环境条件
过程完整性
AC功能之间的属性传输受到保护，不受任何功能的更改
主体、客体、环境条件
抗抵赖能力
属性传输的防抵赖方法
主体、客体、环境条件
属性更改策略
应用于创建、更新、修改和删除属性的策略、规则
主体、客体、环境条件
4
及时性
及时性主要关注属性在刷新、计时、缓存和备份等方面的功能和能力，确保访问控制能够处理准确的访问权限，避免因过时或不同步的属性信息而出现AC错误。
4.1
刷新
AC功能需要了解属性值的获取频度，必要时还要知道（什么时间）处理属性值是安全的。及时性需要考虑AC功能或属性提供者如何根据实际情况来更新或验证属性值，鉴于刷新率对特定属性的影响，主动获取也必须着重考虑（信息是从另一个来源推送到AC功能或属性提供者，还是主动按计划提取）。计划或按需获取的属性值可确保属性值的最新性，从而确保属性值的适用性，即越新越好。
4.2
同步
AC功能之间属性传输序列的同步必须根据AC系统处理方案或协议的顺序进行协调，确保属性更新不会导致错误的AC决策。例如，为了使XACML [12]中的AC功能保持同步，在授权过程中不允许通过策略管理点（PAP）更新属性信息，更新或新添加的属性将在策略实施点（PEP）完成当前授权过程之后才可使用。
4.3
缓存
在紧急情况下（例如，低带宽、服务丢失），无法访问权威属性源或存储库中最近更新的属性时，及时性可以保证缓存中保存了最近的最新属性集，能够为受保护对象实施访问控制提供必要的信息。此外，还需要考虑属性存储库的故障恢复能力。
4.4
备份
属性是组织AC系统的关键组件，在系统正常运行过程中，属性应始终可用。因此，及时性还应包括故障转移，以及从属性存储库或传输系统的故障中恢复属性的能力。
4.5
示例
表7给出了一组可用于帮助确定属性及时性的考虑因素。
表7 属性及时性的基本原则（示例）
关注点
基本原则
属性应用
刷新频率
属性刷新频率满足系统性能要求
主体、客体、环境条件
缓存
运行时的属性缓存满足系统性能要求和AC功能之间的协议
主体、客体
处理时序
AC功能之间的属性传输是协调的，不会产生错误
主体、客体
备份能力
支持故障转移或备份
主体、客体
5
管理机制
为了确保属性使用的有效性和一致性，需要建立一套属性管理机制来审查与属性相关的一系列因素。这些机制包括用于属性分组的元数据和层次结构、用于属性效率的最小化和转换方法，与其他组件相关的支持功能，如与身份认证的属性集成、属性委派、属性审查，以及用于记录属性访问和更新的日志，下面分别对这些内容进行介绍。
5.1
利用元数据分组
在属性的管理过程中，元数据作为属性的扩展信息应用于主体和客体，这有助于实施细粒度访问控制策略。元数据还可用于指派属性的保障级别或真实性[3]、安全性和及时性的综合置信度。标准化的属性元数据是每个属性的基本信息元素，包括与属性值相关的信息（例如，更新频率），与属性创建或建立过程相关的信息（例如，属性是自断言的，还是从记录中检索出来的）以及属性自身的来源信息（例如，来自权威属性源）。不管采用何种访问控制方法，针对属性元数据元素建立的评分系统都可以为访问决策提供支持，AC功能可以根据属性的置信度得分，决定如何使用远程AC功能或属性提供者提供的属性。
表8给出了一个提供共享属性的信息源的标准元数据示例。其中，特定属性值“Person”对于公共信息的访问请求是允许的，但不足以允许他访问敏感系统，因为其元数据“许可级别”是自报告的，并且不是来自权威属性源。（约定）
表8 属性源元数据的标准属性名-值（示例）
属性名
属性值
实体适用性
人
名称
乔·史密斯
分类
公开
置信水平
1（自我报告）
保障细节-刷新方式
拉
保障细节-最近更新
3/8/2015
属性源
USAJOBS.gov
为了提高访问控制的灵活性并方便属性管理，可以对属性进行分组和划分层次化等级，避免为每个主、客体指派相同的属性，将主/客体划入不同的分组，每个分组的“组”原数据（即元属性）[13]表示系统中主体/客体的共同特征。如果一组元数据具有相同的特征，还可以将这组元数据继续提炼抽象到更高阶的组中。这种分组层次结构形成了一个偏序关系，低阶组自动获得分配给高阶组的所有属性。
图2给出了一个分组层次结构的示例，其中属性“Attribute_1”（其ID=User Group_A）和“Attribute_2”（其ID=User Group_B），属于元数据Metadata_1（其Group ID = Support，Skill = Administration）的值。元数据Metadata_1和Metadata_2继承自Metadata_3（其Division ID=Production，Security Class=2）。因此，如果主体具有Attribute_1，则它也将具有Metadata_1和Metadata_3的属性值。
图2 元数据的分组层次结构示例
5.2
属性的权限等级结构
在访问控制系统中，属性可以根据其权限关系在树结构中进行分类。这种关系可以通过树中的节点属性来表示，这样，如果高级主体属性被指派给低级主体属性，那么与该低级主体属性相关联的所有访问权限都将由该主体（通过属性值继承具有了高级属性）自动获得。图3（a）显示了一个示例，其中具有“Role=Professor”属性的主体同时也持有具有“Role=TA”属性的主体的权限。对于客体，如果将高级客体属性指派给低级客体属性，则自动允许与此高级客体属性关联的所有访问通过属性值继承访问具有低级属性的客体。图3（b）显示了一个示例，其中对具有“Type=Secret”属性的客体的访问也可以访问具有“Type=Classified”属性的客体。
图3 主体（a）和客体（b）属性的权限等级结构
5.3
属性转换
有时候，由于需要指派属性的主体和客体的数量和种类过多，可能会从不同角度增加访问控制管理的难度。例如，云端可能有多种类型的虚拟机、存储设备、对象存储资源（例如，对象、容器、帐户）或网络资源（例如，防火墙、路由器），它们都有自己的各种属性。最终，出现了很多仅与特定类型对象相关的特殊属性，当新的对象类型添加到系统时，还会继续出现新的属性。因此，为主体和客体进行属性分配或撤销需要付出相当大的努力。此外，通过这些属性定义的授权策略也是庞大且复杂的，可能会导致定义、更新、修改和审查方面的困难。
为了解决这些困难，需要在属性管理中引入一些转换机制，包括约简、扩展和分组（参看4.5.2）等。属性约简可以对特定类型主/客体的具体属性进行抽象，将较大的属性集转换为较小的属性集。最小化授权决策中使用的属性源的数量可提高性能，同时简化AC系统的整体安全管理，如属性的创建、更新、删除、导入或导出、授权策略的模块化设计以及分层策略的建模[14]。
5.4
与认证的集成
IT资源从内部托管向基于公共资源（例如，云端）托管的转变，以及越来越多的主体从组织边界之外访问应用程序，增加应用分布和访问行为的复杂度。主体和客体的属性可以与主体和对象的身份相关联，这使得通过到高级身份验证技术（如联邦数字身份）的安全连接或单点登录（SSO）来获得/信任身份认证系统提供的主体和对象属性是有效的或必需的。属性是在访问控制规则的特权和约束中指定的，然而应用程序需要的信息除了主体（用户）的身份之外，还包括地理位置、时间、角色、组织、帐户和认证信息。此外，将用于身份认证和访问控制的属性与公司的身份验证系统集成的好处之一是可以将成本和管理对象控制在预算之内[5]。
例如，XACML需要关于主体的上下文信息，以及正在访问的客体的上下文信息，以便正确评估访问请求。对于XACML部署来说，通过标准化的入站身份协议，如SAML、OAuth或OpenID Connect，将这种通过标准方式获得的身份信息用作进行细粒度访问控制的属性，显然要简单得多。更具体地说，SAML提供了将身份信息传递到访问控制属性的标准，并在此过程中承担两个主要角色：1）建立身份的组织，称为身份提供者（IdP），2）将要使用此身份的组织，称为服务提供者（SP）。该断言是由IdP向SP进行的密钥交换所建立的可信身份声明。服务提供商和身份提供商将协商SP要求使用哪些信息作为属性契约，该属性通常标识提出请求的主体。它还可以包含为了使应用程序能够正常工作，SP所需的其他属性，特别是在计算AC决策的时候[15]。
5.5
授权
数据资源AC策略的正确实施取决于属性管理策略的实施，特别是在联邦或协作环境中尤其如此，管理策略要求不同的组织实体对不同属性的管理具有不同但可能重叠的责任。通常做法是，基于互信的概念，将属性值的创建和对主/客体属性的指派限制在不同位置或功能中。建立和管理属性管理策略的严格首选方法是使用委托（Delegation）。委托使得授权人（委托人）将自己或他人的全部或部分权限授予另一主体（被委托人），这有助于为管理角色的创建采取一种系统的、策略保留的方法。管理能力的委托链从单个管理员开始，到具有属性管理能力的主体结束。委托假设系统通过一组标准的管理操作来管理属性，这组操作使用了与AC策略一致的策略执行接口和集中式策略决策功能。
5.6
属性审查
将一个或多个属性指派给主体会间接授予主体对客体执行各种操作的能力。类似地，将一个或多个客体属性指派给客体会间接地为各个主体建立对该客体的访问入口，以便对该客体执行操作。AC系统的一个理想功能是能够针对每一个属性及其组合，检查主体的操作能力和客体的访问入口。该功能有时被称为“事前审查”和“对象发现”，一些人认为“事前审查”是RBAC最突出的特征之一[6]。属性审查包括审查为主体分配某个角色的后果，以及主体在发出访问请求之前发现或查看可访问客体的能力。对客体访问入口的审查能力同样重要。为客体指派属性或删除指派会产生什么后果？另一个有价值的审查是确定主体访问客体时所需的属性，以及哪些属性可能阻止此类访问。
5.7
日志
为了更严格的安全性，组织可能要求所有活动（包括属性的创建、修改、删除和使用等）都记录在审计跟踪日志中，以便为以后的调查提供属性和值的更改信息。此外，对高风险属性的高风险特权访问应进行适当的监控，属性验证方案也需要每年复审。
5.8
示例
表9给出了属性管理标准的一个示例。
表9 属性管理的基本原则（示例）
关注点
基本原则
应用属性
属性结构
属性元数据、层次结构和继承方案精准满足AC策略的要求
元数据（元属性）
与身份认证的集成
属性集成到组织的身份认证系统中，用于实现属性联合、SSO等
主体，客体
属性效率
属性扩展和属性源精简提高AC系统性能
主体，客体
属性委托
基于委托的属性管理策略
主体，客体
属性审查
支持对属性指派的审查
主体，客体
访问日志
支持对记录属性更改和访问的日志审计
主体，客体、环境条件
基于本节的考虑因素，下一节将展示一个通用的属性框架示例，通过使用元数据来集成和定义属性，从一个管理企业环境中的多个AC系统的NLP开始，展示了该组织的属性框架结构。
未完待续
以上是易安联红岸实验室本期为大家分享的《“属性”在访问控制系统中的应用》第一部分对“属性”的基本考虑译文，若您和我们一样热爱钻研，关注网络安全最新动态，关注零信任发展，欢迎加入群聊和我们一起讨论吧。
了解更多
,
