授权术语混乱：我们来解决它

# 授权术语一团糟：让我们来理清它 - IDPro 来源：https://idpro.org/authorization-terminology-is-a-mess-lets-fix-it/ **作者：Andrea Chiarelli** 在《基于策略的访问控制（PBAC）是一种授权模型吗？》（https://idpro.org/is-pbac-an-authorization-model/）一文中，我论述了PBAC常被拿来与基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）进行比较，仿佛它们属于同一类别，但实际上它们回答的是不同的问题。 RBAC和ABAC描述的是决策**基于什么数据**：角色或属性。PBAC描述的是**如何做出**决策：通过集中式策略引擎，而非硬编码在应用程序中的逻辑。一个是关于规则的形式，另一个是关于规则的存放位置以及由谁来评估。 在我看来，将它们视为竞争选项，就像将食谱与厨房进行比较一样。 这种区分试图解决一个特定的困惑，但它留下了更大的困惑未解：PBAC并非唯一被如此错误归类的术语。 强制访问控制（MAC）和自主访问控制（DAC）也常常与RBAC和ABAC相提并论，尽管它们描述的是谁管理规则，而非规则本身的样子。 访问控制列表（ACL）和基于关系的访问控制（ReBAC）也常常与“授权模型”被混为一谈，但根据不同的文献，一个可以说是另一个的特例。 授权领域的术语几十年来一直在访问控制研究、身份提供商和标准机构中积累，其中很多术语虽然使用了统一的语言（“*这是什么模型？*”），但实际回答的是不同的问题。 本文将“模型与架构”的区分泛化为一个完整的分类法。我不想问“*这个系统使用的是哪种授权模型？*”，而是想对任何授权系统提出五个更具体的问题，独立回答每个问题，然后再看像RBAC、ABAC、MAC和PBAC这样的熟悉标签实际应归于何处。如果这些术语在被放置到正确的轴上后不再相互竞争，那就说明这些轴确实发挥了作用。 ## 授权的核心问题 授权回答一个问题：**此主体能否对此对象执行此操作？** 用户读取文件、服务调用API、进程写入数据库。每个授权决策都归结为同一个三元组：主体、动作、对象。 在一个最简单的系统中，由于请求方和决策方没有分离，所以无需决策。想象一下你自己的日记，放在你自己房间的抽屉里。你想读它，就打开抽屉阅读。没有人需要授予你许可，因为没有其他人参与：想要和得到是同一个动作。 现实系统很少如此简单，因为被访问的资源通常属于多个相关方。把同一本日记放在一个有室友的房子里，或者移到公司的文件柜里，情况立即改变。并非每个想打开抽屉的人都应被允许，而且必须有人逐一决定谁可以、谁不可以。 资源服务器正是为软件执行这项工作。多租户SaaS应用、内部API、被数十个服务访问的云存储桶：所有这些都需要某个东西来审视一个请求，并决定是否允许它。这个“某个东西”就是本文接下来要讨论的内容，事实证明它比“RBAC”或“PBAC”这样的单个词所能捕捉的更具复杂性。 ## 授权请求的处理过程 追踪一个授权请求通过资源服务器的流程，无论具体技术如何，都会出现一组一致的阶段：请求到达，服务器收集关于用户和资源的上下文，策略根据规则评估该上下文。评估产生允许或拒绝的决定，服务器通过放行或拒绝该请求来执行该决定。 本质上，每个授权系统都出现相同的五个阶段： 1. **有人定义规则。** 开发人员硬编码一个检查；安全团队编写策略；资源所有者设置其文件的共享权限。 2. **规则呈现出具体形式。** 应用代码中的条件语句；JSON文档；XACML策略；导出到数据库表中的电子表格行。 3. **某些数据需要提供给决策。** 用户角色；数据库中列出的部门；一天中的时间；请求用户与资源所有者之间的关系。 4. **计算出一个决定。** 规则和数据一起被评估，产生允许或拒绝。 5. **执行该决定。** 必须有东西实际执行结果：阻止请求或将其重定向。 这五个阶段映射到一个在访问控制架构中已存在一段时间的术语： - 策略管理点（谁定义规则） - 策略信息点（什么数据为决策提供依据） - 策略决策点（在哪里计算决定） - 策略执行点（在哪里执行） Brossard关于ABAC架构的概述（https://idpro.org/the-state-of-the-union-of-authorization/）更详细地阐述了这个PAP/PIP/PDP/PEP分解，如果这些术语是新的，值得一读。 这里值得引入一个相关的、更具学术性的框架，来自Mohamed、Auer、Hofer和Küng于2022年对授权和访问控制研究的系统性文献综述（https://www.sciencedirect.com/org/science/article/pii/S1744008422000180）。论文构建了一个包含四个层级的阶梯：**授权策略**（自主、强制或混合）位于**授权模型**（系统推理所依据的主体、客体和其他组件）之上，而授权模型又位于**授权策略**（具体的规则实例）之上。并行地，**访问控制模型**（允许/拒绝的决策逻辑）由**访问控制机制**（实际运行的软件）来执行。这是一种严谨的方式，表达了本文所论证的相同观点：策略、模型、政策和机制是分离的层级，混淆它们正是术语失效的地方。 这五个阶段中的任何一个，本身都无法告诉你一个系统“是RBAC”还是“是PBAC”。每个阶段实际上是一个独立的问题，有其独立的答案集合。这是下面分类法的种子。 ## 一致的分类法 六个轴覆盖了上述五个阶段（授权策略与授权模型分离，因为模型可以被多种具体策略实例化）。每个轴有少量常见答案，每个熟悉的术语（ACL、RBAC、ABAC、ReBAC、MAC、DAC、PBAC）实际上是对某个特定轴的回答，而非对整个系统的标签。 一个区分六个轴的有用方法是借鉴软件领域之外的隐喻：法律机器。立法机构起草规则，规则被写成法典，法院将这些法典与案件事实相权衡，然后警察执行判决。将“法律系统”替换为“授权系统”，同样的六项工作将在下面逐一重现。 ### 授权管理：谁设置规则？ 在规则可以被评估之前，必须首先有人有权编写它。这种权力可以集中于一处，也可以分散在多处，系统在此处的答案独立于规则实际说了什么。授权管理可以是： - **集中式**：安全团队或管理员为所有人定义规则。这是强制访问控制（MAC）背后的模式：访问由中央权威决定，而非资源所有者。 - **分散式**：资源的所有者决定谁可以访问它。这是自主访问控制（DAC）：经典的“*与这些人共享此文件*”模式。 - **混合式**：一些规则来自中央权威，另一些来自单个资源所有者，分层组合。 Mohamed等人的文献综述也这样处理策略，他们的比较分析很有启发性：当他们根据此轴对访问控制模型进行分类时，RBAC、ABAC和ReBAC系列都落在混合类别中，而非清晰地属于DAC或MAC。这本身就是一个有用的数据点。它证实了管理策略确实独立于授权模型：一个基于角色的系统可以是集中管理的、所有者管理的，或两者兼有，无论如何它仍然是RBAC。 法律系统正是基于这种区分运作。议会，或旧制度下的国王，为全体人民立法：集中管理。两个邻居就栅栏线位置达成协议，或房主决定谁得到钥匙，是分散管理，更接近合同法和财产法实际运作的方式。大多数现实法律系统混合两者，就像大多数授权系统一样。 ### 授权模型：什么数据类型驱动决策？ 一旦编写规则的权力确定下来，下一个问题是规则实际推理的内容：决策每次运行时检查的特定信息种类。这就是大多数人提到“授权模型”时所指的轴，也是我之前关于PBAC的文章所关注的。以下是一些常见的授权模型： - **基于身份（ACL）**：决策检查特定主体是否出现在附属于对象的列表上。 - **基于角色（RBAC）**：决策检查主体是否持有已被授予所请求权限的角色。 - **基于属性（ABAC）**：决策根据规则检查主体、对象、动作或环境的属性（部门=“财务”，权限≥“机密”，时间在上午9点至下午5点之间）。 - **基于关系（ReBAC）**：决策检查主体和对象之间的关系，通常是通过遍历图（此用户是否是拥有此文档的团队的成员？）。 诚实地说明这里的模糊性是值得的。根据不同的学术来源，ACL和RBAC可以被描述为ABAC的特例，其中所涉及的属性恰好是身份或角色成员资格。这四个类别对于一个实用的分类法来说是最有用的切分，并非声称这些类别在数学层面是互斥的。 法律对规则实际内容做了同样的区分。宪法和行政法通常通过职位定义谁可以行动，“*只有总统可以签署此项条约*”，这是基于角色的。法规法更多地触及属性，“*任何收入超过一千万美元的企业必须提交此报告*”。家庭法和合同法则取决于关系：配偶、父母、商业伙伴。而一部法律或禁令指定某个特定个人或公司，就是法律上的ACL等价物。不同法律领域选择不同标准的原因，与不同授权系统选择不同标准的原因相同：每个标准适用于不同类型的决策。 ### 授权策略：规则采取什么形式？ 一旦选择了模型，它仍然必须以具体形式记录在某个地方： - 应用代码中的硬编码条件语句。 - 在运行时加载和解释的结构化文档（JSON、YAML）。 - 专为授权设计的声明式策略语言，如XACML、Rego（Open Policy Agent）或Cedar。 - 数据库表中的一行数据。 这个轴很重要，因为两个系统可以共享相同的授权模型（都是RBAC），但由于策略表达方式的不同，在可维护性、可审计性以及谁有权更改规则方面可能完全不同。 在法律隐喻中，这仅仅是法律本身：法典或法条的实际文本，独立于谁通过了它，也独立于它属于哪个法律领域。 ### 授权信息：决策相关数据来自哪里？ 规则的好坏取决于评估它的数据，而这些数据并非都以相同方式到达。值得将规则所依赖的内容与系统实际获取它的方式分开： - **硬编码在内**：数据在应用程序的正常请求流中已经可用，无需额外查找。 - **基于令牌**：数据作为JWT或类似凭证中的声明到达，由身份提供商在签发时填充。 - **查询获取**：应用程序在决策时查询数据库、目录或外部服务。 - **环境相关**：数据描述请求本身的上下文，而非主体或对象：时间、位置、设备状态、网络。 即使是严谨的学术处理，这里也模糊了一个真正的区别。Mohamed等人的框架将环境属性折叠到授权模型的组成部分中，与主体和对象并列，而不是将“*这些数据在运行时实际来自哪里*”视为一个独立的架构问题。我认为这是PBAC文章所指出的那种错误的小版本：知道决策依赖于“一天中的时间”是建模问题，但知道请求必须通过网络往返目录服务才能获取它是一个架构问题，对延迟和故障模式有实际影响。 法庭依赖于同样的输入：事实和事件。证词、文件、时间戳、先前记录。同样的法律应用于不同的事实集会产生不同的判决，就像同样的策略应用于不同的令牌声明或不同的数据库查询会产生不同的授权决定一样。而且，正如在授权系统中一样，这些事实来自哪里（证人席上的证人、通过传票调取的文件，或专家报告）与法律本身说了什么，是一个独立的关注点。 ### 授权决策：决策如何以及在何处计算？ 一旦规则及其数据都可用，就必须有东西实际运行评估。这个“东西”可以存在于几个不同的地方，它在哪里是一个架构问题，而非规则本身的问题： - **硬编码在应用程序代码中**：与业务逻辑内联的if语句或框架原生权限检查。 - **专用库或模块**：决策逻辑被分离出来，但仍在应用程序进程内运行。 - **集中式策略引擎**：一个接收上下文并返回决策的独立服务，通常被多个应用程序共享。 **PBAC属于这里**，而不是在“授权模型”轴上。将决策点集中到策略引擎中是关于*何处*进行评估的架构选择，它与任何授权模型都兼容：PBAC引擎可以评估基于角色的规则、基于属性的规则或两者的混合。这正是为什么PBAC不是RBAC和ABAC的同级。它回答的问题与RBAC和ABAC所回答的问题不同。 这正是法庭隐喻恰当的地方：法院，特别是法官，是决策引擎。法律和事实进入，判决产出。而一个法律系统将不同类型案件路由到不同专门法院（交通法庭、家庭法庭、最高法院）而不改变底层法律的习惯，很好地描绘了PBAC的实质。这是一个关于哪个法庭审理案件的选择，而非对法律本身的改变。 ### 授权执行：决策如何以及在何处执行？ 只有当有东西基于决策采取行动时，决策才重要，而该行动不一定发生在决策做出的地方。授权执行可以存在于： - **硬编码在应用程序代码中**：与...