授权的核心问题不是“用户是谁”，而是“经过身份认证后，用户应该拥有什么访问权限”。随着系统规模扩大，简单的权限分配方式会逐渐无法满足需求，因此授权模型需要在易管理性和精细控制能力之间找到平衡。文章主要讨论 RBAC、ABAC、PBAC 和 PAM 等授权方式，说明不同模型如何根据角色、属性、策略和特权等级决定访问权限。
文章重点说明，RBAC 通过角色绑定权限，适合组织结构稳定的场景，但容易随着业务复杂化产生角色膨胀；ABAC 通过用户、资源和环境属性进行动态判断，可以实现更细粒度控制，但规则管理更加复杂；PBAC 则进一步将授权逻辑抽象为策略，使权限决策能够根据上下文和业务规则动态变化。PAM 关注的是高权限账户的保护，通过最小权限、审计和额外安全控制降低特权访问风险。
真正需要记住的是，授权模型的发展方向不是简单替代旧模型，而是在不同复杂度场景下选择合适的控制方式。RBAC 解决“什么角色拥有什么权限”，ABAC 解决“满足什么条件可以访问”，PBAC 解决“根据哪些规则动态决策”，而现代系统通常需要组合这些模型，才能同时满足安全性、灵活性和可维护性。
访问控制真正困难的问题，不是判断“用户属于什么角色”，而是判断“用户与资源之间是什么关系”。传统 RBAC 通过角色决定权限，但在复杂系统中，权限往往取决于资源归属、成员关系、协作关系等动态上下文。文章讨论 ReBAC 如何通过描述实体之间的关系来实现更灵活的授权模型。
ReBAC 的核心认知是：权限并不一定来自静态角色，而可以从用户、资源以及它们之间的关系推导出来。文章重点通过 RBAC、ABAC 与 ReBAC 的对比，说明关系模型为什么更适合团队协作、文档管理、社交网络等需要细粒度授权的场景，并进一步介绍如何将权限规则表示为关系图，通过关系链判断访问是否允许。
真正需要记住的是，RBAC 解决的是“你是什么角色”，而 ReBAC 解决的是“你和这个资源有什么关系”。当系统中的权限开始依赖资源拥有者、组织结构、成员关系或协作状态时，基于关系的授权模型能够避免大量硬编码规则，让权限管理从角色匹配转变为关系推理。
很多人把 MAC 理解成“权限管得更严格”，但文章强调，它真正的特点是 所有访问规则都由中央统一制定和强制执行，用户既不能修改自己的权限，也不能将权限授予他人。系统会根据用户的安全级别（Clearance）和资源的安全标签（Security Label）自动做出访问决策，而不是由资源拥有者决定。
文章还进一步解释了安全标签的组成、MAC 的工作流程，以及它在政府、军队、金融等高安全场景中的应用，同时也指出其代价——管理复杂、灵活性低，不适合变化频繁的业务环境。读完后最应该记住的是，MAC 的核心不是限制用户，而是限制“授权本身”：授权权力集中在系统和管理员手中，而不是资源所有者手中。
MAC（Mandatory Access Control）的核心不是 控制权限，而是 控制谁有权决定权限。文章强调，在 MAC 模型下，资源所有者无权自行授权，所有访问规则都由管理员统一制定，并由操作系统或安全内核强制执行。用户能否访问资源，不取决于资源拥有者，而取决于 资源的安全级别（Security Label） 和用户的 安全许可（Security Clearance） 是否匹配。
真正需要记住的是，MAC 追求的是一致性和不可绕过，而不是灵活性。它适用于政府、军队等对数据保密要求极高的场景，因为任何用户都不能修改授权规则或将权限转授他人；代价则是管理复杂、灵活性低，不适合需要频繁调整权限的普通业务系统。
RBAC 的价值并不只是“给用户分配角色”，而是 把权限管理从“用户 → 权限”变成“用户 → 角色 → 权限”。文章围绕这一模型展开，说明角色本质上是一组权限的集合，用户可以拥有多个角色，权限也可以跨 API 组织和复用，从而避免逐个用户管理权限带来的复杂性。
不过，文章也点出了 RBAC 的边界：角色只能解决职责相对固定的授权问题。当权限开始依赖部门、时间、位置等动态条件时，就需要在 RBAC 基础上结合属性或策略扩展，而不是不断增加角色。真正需要记住的是，RBAC 的核心是简化权限管理，而不是覆盖所有授权场景。
PBAC（Policy-Based Access Control）的重点不是引入一种新的权限模型，而是 把授权规则从应用代码中抽离出来，由统一的策略集中管理和实时决策。文章用 RBAC、ABAC 和 ReBAC 做对比，说明 PBAC 可以综合角色、属性、关系以及时间、地点、设备、风险等上下文信息，通过统一的策略引擎动态决定是否授权，而不必在每个系统里分别维护权限逻辑。
读完后最应该记住的是，PBAC 的核心不是 Policy，而是 Centralization（集中化）。它并不是要取代 RBAC 或 ABAC，而是将这些模型纳入统一的策略框架中，让授权规则能够一致地管理、快速更新和跨系统复用，从而适应越来越复杂的业务场景。
DAC（Discretionary Access Control）的核心不在于 ACL（访问控制列表），而在于 权限由资源所有者决定。文章围绕这一点展开，说明文件、文件夹、云盘共享等常见权限管理都属于 DAC：资源创建者可以自主决定谁可以读、写或执行，并通过 ACL 将这些决定落实到系统中。
真正需要记住的是，DAC 的优势来自“自主”，缺点也来自“自主”。它足够灵活，适合日常业务系统；但权限分散在资源所有者手中，容易因人为配置错误导致权限过大、难以统一管理，因此并不适合安全要求高或规模庞大的组织。
ABAC 真正难的并不是写策略，而是 让策略能够持续工作。文章没有把重点放在策略语法，而是围绕 ABAC 落地需要解决的几个关键问题展开：如何识别用户、资源和环境属性，如何保证这些属性始终保持最新，如何将授权逻辑从业务代码中解耦，以及如何集中管理和评估策略。只有这些基础能力建立起来，ABAC 才能真正替代散落在代码里的权限判断。
读完后最应该记住的是，实现 ABAC 更像是在建设一套授权基础设施，而不是实现一套权限规则。策略只是最终产物，真正的工作在于属性建模、数据同步、策略管理和统一决策，这些才决定了 ABAC 是否具备可维护性和扩展性。
这篇文章并没有停留在解释 ABAC 是什么，而是试图回答 为什么越来越多的系统会从 RBAC 演进到 ABAC。文章认为，随着业务变得复杂，权限规则开始依赖租户、资源、时间、地域、订阅等级等上下文信息，继续增加角色只会导致 Role Explosion（角色爆炸）。ABAC 的价值就在于把这些规则从固定角色中剥离出来，用属性和策略动态决定权限。
不过，文章也没有把 ABAC 描述成 RBAC 的替代品，而是强调 RBAC 往往是起点，ABAC 是演进方向。很多系统会保留角色作为基础能力，再逐步引入属性和策略，让授权模型既保持简单，又能应对不断增长的业务复杂度。真正需要记住的是，ABAC 解决的不是权限不够，而是 RBAC 难以持续维护的问题。
[什么是基于属性的访问控制（ABAC）](https://www.okta.com/en-gb/blog/identity-security/attrib ute-based-access-control-abac/)
ABAC（Attribute-Based Access Control）的核心并不是用 角色（Role） 决定权限，而是根据 属性（Attribute） 动态做授权决策。文章将用户属性、资源属性、操作类型和环境属性（如时间、地点）放到同一个授权模型中，说明访问权限不是固定分配的，而是由一组策略实时计算出来的，因此能够表达比 RBAC 更细粒度、更灵活的权限规则。
读完后最应该记住的是，ABAC 的本质不是增加更多权限，而是让“权限”从角色转变为策略。它解决的是角色数量不断膨胀、权限越来越复杂的问题，用统一的策略和属性组合代替大量预定义角色，使授权能够随着用户、资源和环境的变化动态调整。