尽管IAM（身份与访问管理）概念已被提出多年，市场上也已经有不少云厂商推出各自的IAM解决方案。但能够有效运用IAM，实现企业零信任安全落地实则是一项极其复杂，并且耗费较多资源与时间的艰巨任务。相比于企业对于内外部人员身份管理的复杂多变，应对多样化认证方式的建设难度，授权与鉴权的灵活扩展管理，可谓是IAM解决方案中一座充满更多挑战的高峰，以致很多企业或望而生畏，或在混沌中摸索攀登。
什么是PBAC模型？
要想了解PBAC访问控制模型，就必须得先了解在此之前已有的访问控制模型。
最早的访问控制采用ACL（Access Control Lists）进行授权，以根据设定的条件对接口上的数据包进行过滤，允许其通过或丢弃。目前仍较多应用于路由器或交换器上。
而最常见的是RBAC（Role-Based Access Control）模型。目前大部分系统仍主要基于RBAC模型设计权限管理功能。该授权模型将权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这样的设计极大地简化了权限的管理，比较适用于用户角色简单的系统。对于用户角色复杂，权限粒度划分较细的复杂系统，这种授权模型将会带来角色的爆发式增长。对业务管理以及系统运营都提出了很高的要求。
随之ABAC（Attribute-Based Access Control）被越来越多的企业所推崇。ABAC可以基于访问者主体属性（如岗位、部门、年龄等）、资源对象属性（被访问文件格式、目录、标签等）、访问环境属性（如时间、地点、设备类型等）以及操作属性（如读写等）是否满足某种条件来进行授权判断（可以编写简单的逻辑）。可以看出ABAC模型可以支持细粒度授权，对于访问控制管理也更为灵活，无需对大批量用户逐一操作，仅需修改或失效部分权限policy即可。所以理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。可以看出，基于属性的访问控制已初步具备灵活策略模型的构建基础，但其适用范围仍较为有限，且依托于XACML语言开发，部署及运维复杂度较高，对IT团队依赖度很高，业务团队难以运营。
近些年PBAC（Policy-Based Access Control）在整合了ABAC及RBAC模型基础上，被PlainID提出。作为新一代IAM的核心要素，被越来越多的学者和企业所关注。在PBAC下，授权可以用自然语言设置策略，基于任务或事件等其他不同的场景灵活配置管理。通过隔离数据访问、控制访问蔓延，甚至阻止授权用户以危险方式访问数据，使遵守GRC和GDPR等法规变得更加容易。在笔者前面的文章（助力中通零信任安全架构落地的现代化IAM平台）中，已提出零信任架构核心逻辑组件，而PBAC的授权模型即用来实现IAM大脑中枢的动态访问控制核心逻辑。
图1 零信任架构核心逻辑组件
PBAC模型如何落地？
1.ABAC & PBAC的实现机制
当访问主体需要访问某个资源进行某项操作时，访问控制机制在请求发起后便开始运行计算。权限访问控制引擎会整体评估访问主体属性、被访问资源属性以及其他环境条件因素，而最后会产生是否允许操作的结果。
图2 NIST 800-162：访问控制机制示例
（图片源于互联网，侵删）
在访问时，所有的请求都由PEP（Policy Enforcement Point，策略执行点）截获，PEP属于一种特殊类型的引用监控器，用于保护用户数据以及应用。策略执行点可部署在网关等不同节点。当处理访问请求时，将这些信息发送给负责计算访问决策的PDP（Policy Decision Point，策略决策点）进行判断计算。考虑到若每次访问请求均请求PDP可能会造成访问控制响应较长时间。在搭建PBAC控制模型时，可以考虑在每次PDP计算完成后，将策略结果预缓存至PEP处，以提高系统响应效率。
PDP策略决策点和能够提供关于主体或客体的访问信息的PIP（Policy Information Point，策略信息点）进行协调，并从系统中唯一的策略池（Policy Repository）取回一个适用的策略规则。调取规则主要选择主体描述符、对象描述符、环境描述符与PIP中提供主体、资源、环境属性相匹配，并且访问操作类型与请求访问类型一致的规则。而PAP（Policy Administration Point，策略管理点）则是对策略规则以及策略集进行增删改等常规管理。同样，也可以在PIP以及PDP进行缓存处理，以最大限度地提升权限判断的性能。
由于规则和策略会由不同的团队设计维护，因此对于相同的对象和主体可能会存在不同的策略规则。可以考虑在策略管理点引入静态策略冲突检测，以及在策略决策点中运用动态策略冲突化解器来解决冲突。
图3 策略访问控制时序图
当搭建IAM访问控制模型时，需要与身份中心、应用网关与资源中心等不同模块进行联动，同时结合终端访问设备、不同环境条件属性，在控制台的策略管理中心针对不同用户组/标签、角色、应用/服务/数据库等资源，统一管理里访问策略规则。需要在资源中心存储管理策略信息中心所需的各种基础数据，同时对于用户信息、资源标签/分组信息、证书信息等建立缓存机制。对于进行策略决策计算后的结果可以分层缓存至应用服务或网关，并结合用户、应用、环境等行为审计结果，持续对决策结果进行优化更新。具体可参考如下所示的某云厂商访问控制模块业务架构示意图。
图4 访问控制模块业务架构示意图（图片源于互联网，侵删）
2.策略类型
很多云厂商的权限策略为基于身份的策略，较少涉及到基于资源的策略。而AWS的策略类型和控制逻辑基本是最复杂的，并且涵盖的控制场景也是最全面。如下以AWS的权限策略为例，列举权限策略的几种类型：
基于身份的策略
将托管和内联策略附加给特定身份（用户、用户组或角色），以控制其可以对特定资源在特定条件下执行的特定操作。托管策略在于可以将独立的策略附加给多个用户、用户组或角色；而内联策略则是直接添加到单个用户、组或角色的策略。内联策略和身份之间是一一对应关系。当删除身份时，内联策略也同时被删除。
基于资源的策略
授予指定的委托人在特定条件下对该资源执行特定操作的权限。基于资源的策略均是内联策略，没有基于托管资源的策略。委托人可以与资源位于同一个账户中，也可以位于其他账户中。若两者在同一账户中，则不需要额外的基于身份的策略。若两者分布在不同账户，则需要先使用基于身份的策略授予对资源委托人的访问权限。
权限边界
权限边界属于策略权限中的高级功能，常规大部分企业并不涉及该策略类型。该策略定义基于身份的策略可以授予实体的最大权限，但不授予权限。因此实体只能执行基于身份的策略和其权限边界同时允许的操作。但基于资源的策略则不受权限边界的限制。
组织服务控制策略（SCP）
该策略定义了组织或组织单元（OU）账户成员的最大权限。SCP 限制基于身份的策略或基于资源的策略授予账户中实体（用户或角色）的权限，但不授予权限。
访问控制列表 (ACL)
可使用ACL控制其他账户中的特定委托人可以访问该策略中附加的资源。不能使用 ACL 控制同一账户中的委托人访问权限。ACL 类似于基于资源的策略，但ACL是唯一不使用 JSON 策略文档格式的策略类型。
会话策略
会话策略是高级策略，在以编程方式为角色或联合身份用户创建临时会话时，将在参数中传递这些策略。会话的权限是用于创建会话的 IAM 实体（用户或角色）的基于身份的策略与会话策略的交集。权限也可以来自基于资源的策略。
3.策略评估计算逻辑
鉴于对于相同的身份实体或被访问的资源，可能存在同时被不同团队、不同策略规则控制的情况。如上文中提到的静态策略冲突化解器，其在对策略进行冲突计算的时候，会基于一定的评估逻辑进行运算。当然动态策略冲突化解器也可以基于相同原则，或者有业务逻辑做强制优先级排列评估。本文主要基于常规策略评估逻辑以AWS为例进行阐述，对于业务特殊策略评估优先级排序逻辑暂不在考虑范围内。
图5 AWS策略评估逻辑图（图片源于互联网，侵删）
拒绝评估：默认情况下，所有请求都被隐式拒绝。即默认是不允许访问的。在所有应用于请求的所有策略中，执行代码查找应用于请求的Deny语句，即为显式拒绝。如果代码找到一个适用的显式拒绝，则返回结果为拒绝。如果没有显式拒绝，则会继续判断；
组织SCP：评估适用于请求的组织服务控制策略 (SCP)。SCP适用于附加 SCP的账户的委托人。如果没有在SCP中找到任何适用的Allow语句，则隐式拒绝请求。代码将返回拒绝最终决定。如果没有SCP，或者SCP允许所请求的操作，则继续判断；
基于资源的策略：若请求中被访问的资源有基于资源的策略，并且该策略允许访问主体执行请求的操作，则返回结果为允许。如果没有基于资源的策略，或者如果策略不包含 Allow语句，则继续判断；
IAM权限边界：若访问主体使用的IAM实体设置权限边界，且不允许所请求的操作，则请求会被隐式拒绝，返回结果为拒绝；若无权限边界或权限边界允许所请求的操作，则继续判断；
会话策略：检查访问主体是否在使用会话策略。若存在会话策略且不允许所请求的操作，则请求会被隐式拒绝，返回结果为拒绝；若无会话策略或会话策略允许所请求的操作，则继续判断；
基于身份的策略：若任何适用于当前访问主体的基于身份策略的有允许请求的操作，则返回结果为允许。否则，则隐式拒绝，返回结果为拒绝。
4.策略语言要素
Gartner和NIST（美国国家标准与技术研究所）报告中均提出了需要使用基于会话的动态策略评估的细粒度和动态访问控制。而实现动态访问控制的PBAC模型落地，则需要依托策略语言实现逻辑规则的表达。目前业界中AWS是运用上述理论指导实践运用最成功的云服务厂商。借助AWS策略模型语言，国内云厂商也推出了基于策略的访问控制模型。基本均涵盖以下要素：
效力（Effect）：访问请求是否允许或拒绝。
操作（Action）：访问请求的具体操作，如读、写、列表查看等。
资源（Resource）：所有数据源和计算服务均可被定义为资源。资源包括：帐号、人员、服务器、终端设备、API等一切可被操作的实体。
限制条件（Condition），可选配置，对于动态访问请求中的主体条件、环境条件等均可以在限制条件中进行定义。
主体（Principal）：访问主体元素，可以指定允许或拒绝访问资源的委托人。但对于基于身份的策略类型是无法使用该元素的。可以在 IAM 角色的信任策略和基于资源的策略中使用它。
PBAC模型实际解决哪些应用场景问题？
场景1：租户-用户组/用户分类/用户帐号权限管理
图6 场景1实现示意图
目前国内大部分云厂商以及IDaaS服务商对于租户内帐号权限策略管理均支持上图所示的方式进行管理。可以通过给不同组织机构下的不同用户组或特定属性标签的用户分类、用户单独配置系统预置的权限策略，或由IAM用户自定义权限策略，灵活管理基于身份或资源的策略访问控制。
场景2：跨租户/项目/帐号体系资源委托与授权管理
图7 场景2实现示意图
当租户内资源访问权限管理限制较严格，或租户不同项目、不同业务帐号体系之间对于权限访问控制均有比较严格的管理，并且不希望对于其他外包、合作伙伴或身份实体范围以外的用户开放过多权限时，此时可以考虑利用PBAC授权模型，对于满足特定条件的身份帐号B授予有限的资源访问权限。同时B也可以将A委托的资源分配给其帐号下专职管理委托的IAM用户，由其代为管理。当合作关系发生变更时，此时对于实体A的帐号，可以随时修改或删除该策略规则，那么实体B帐号以及帐号下可以管理该委托的用户对该委托的使用权限也将被修改或撤销。
场景3：在线协同办公等终端应用的临时授权管理
图8 场景3实现示意图
对于很多在线协同办公的应用平台，由于支持云空间文件管理，如需考虑对于敏感文件权限或特定群组人员权限进行限制，可以采用在控制端对临时访问服务分配特定角色策略权限，灵活支持客户端上用户对云空间文件访问控制。对于不同的业务需要，均可以在底层实现上采用此种处理模式。
场景4：企业身份集成的角色权限自动颁发
图9 场景4实现示意图
目前很多云厂商已身份提供商联邦身份认证的服务，但这仅解决了单点登录的问题。对于登录后的联邦身份用户权限的控制，也是不容忽视的问题。可以采用如上所示的方式，对于满足不同条件的联邦身份用户，可根据用户身份转换规则，使企业用户拥有云服务平台上不同的角色权限，从而实现权限的自动颁发。
场景5：风控规则策略或各种任务式策略执行
对于企业内部安全风控规则策略或其他业务逻辑的定时任务执行，可以借助PBAC模型实现。可以通过对访问主体属性、环境属性以及被访问资源属性进行灵活条件配置。从而达到限制特定标签属性的身份主体，仅可从特定IP网段、特定时间范围内或特定端口访问特定的资源。可通过组织SCP、权限边界以及会话策略对各种网络攻击行为进行默认拒绝处理等等。
结语
综上，可以看出基于PBAC的访问控制模型构建零信任IAM内核具有很多优点：①可以基于标准策略语言处理，访问决策的制定和执行是独立控制的，因此可以支持多种执行机制；②该模式可以兼容支持ACL、RBAC、ABAC控制模型，具有更好的扩展性；③策略的各种隐式表达也可以降低非法访问的可能性。
但与此同时，PBAC模型也并非完美。该种权限控制模式对系统性能提出了较高的要求，且配置过程对于普通业务用户仍较为复杂。因此在考虑落地实现时，不仅在考虑IAM控制台端的功能时，需要花费更多的精力进行产品设计，以达到系统灵活配置与用户体验的平衡。还需要结合企业的实际情况对权限策略决策点、执行点、信息点等子模块进行分层设计。
未来我们也需要克服基于PBAC模型无法快速支持对特定资源被哪些身份实体可访问的反向查询问题等。总之，PBAC模型在IAM解决方案中的落地任重而道远，我们将保持初心，打造强大灵活的零信任IAM平台，为我们的用户提供更好的零信任访问管理服务。
声明：本文来自中通安全应急响应中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
