授权术语一团糟:是时候彻底厘清了

投资策略与投资组合管理 加密市场分析 监管和法律更新

在信息安全和身份管理的世界里,有一个长期困扰从业者的问题:授权领域的术语实在是过于混乱。每当我们试图讨论一个系统的访问控制方式,RBAC、ABAC、PBAC、MAC、DAC、ACL、ReBAC 等术语就会像一锅大杂烩一样被丢到桌面上,被当作可以相互替代的选项进行比较和选择。然而,这种做法从根本上就存在严重的概念混淆,因为这些术语实际上回答的是截然不同的问题。 理解授权的本质 在深入探讨术语问题之前,我们需要先回到授权的本质。授权回答的核心问题非常简单:在某个主体试图对某个对象执行某个动作时,这个操作是否应该被允许。无论是用户读取文件、服务调用 API,还是进程写入数据库,所有的授权决策都可以归结为主体、动作、对象这三元组的判断。

在最简单的情况下,根本不需要任何授权决策,因为请求者和决策者是同一个主体。想象一下你自己的日记本,放在你自己房间的抽屉里,你想阅读它,打开抽屉即可。没有人需要授予你权限,因为没有第三方利益相关者的存在。然而,现实系统很少能保持这种简单状态。当资源被多人共享时,无论是合租公寓里的室友,还是公司文件柜中的文档,情况就立刻改变了。不是所有想打开抽屉的人都应该被放行,必须有人根据具体情况决定谁可以、谁不可以。

对于软件系统而言,资源服务器承担的就是这个角色。无论是多租户的 SaaS 应用、内部 API,还是被众多服务访问的云存储桶,都需要一个组件来检查请求并决定是否予以放行。这个组件就是我们需要深入理解的对象,而它的内部结构远比 RBAC 或 PBAC 这样的单一标签所能描述的更加丰富。 授权请求的处理流程 让我们跟随一个授权请求穿越资源服务器,无论具体使用何种技术实现,一个一致的处理阶段序列都会浮现出来:请求到达,服务器收集关于用户和资源的上下文信息,策略根据规则评估这些上下文,评估产生允许或拒绝的决策,服务器通过放行或拒绝请求来执行该决策。 这五个阶段几乎出现在每一个授权系统中。某个角色必须先定义规则,无论是开发人员硬编码的检查、安全团队编写的策略,还是资源所有者为自己文件设置的共享权限。

规则需要以某种具体形式存在,可以是应用代码中的条件语句、JSON 文档、XACML 策略,或者是某人从电子表格导出到数据库表的一行数据。某些数据必须为决策提供输入,可能是用户的角色、数据库中列出的部门、一天中的时间,或者是请求用户与资源所有者之间的关系。然后会计算出决策,规则和数据被一起评估,产生允许或拒绝的结果。最后,决策必须被执行,必须有某个组件根据结果采取行动,阻止请求或重定向请求。 这五个阶段对应着访问控制架构中已存在一段时间的术语体系:策略管理点定义规则的制定者,策略信息点提供决策所需的数据,策略决策点是决策计算发生的位置,策略执行点是决策被执行的地方。 有意思的是,学术界对这一分层有着更严格的表述。

2022 年 Mohamed、Auer、Hofer 和 Küng 发表的系统性文献综述中,他们构建了一个四级阶梯模型。授权策略可以是自主的、强制的或混合的,它位于授权模型之上;授权模型描述系统所推理的主体、对象及其他组件;授权模型之上是授权策略,即具体的规则实例。平行地,访问控制模型是允许或拒绝的决策逻辑,由访问控制机制作为实际运行的软件来执行。这种严谨的表述恰恰说明,策略、模型、策略实例和机制是不同的层级,混淆它们正是术语混乱的根源。 六维度分类法的提出 基于处理流程的五个阶段(授权策略从授权模型中分离出来,因为一个模型可以由多种具体策略工件实例化),我们可以构建一个六维度的分类体系。每个维度都有少量常见的答案,而每一个熟悉的术语本质上都是对某一特定维度的回答,而非整个系统的标签。

授权管理回答的是谁有权制定规则。在规则被评估之前,必须有人拥有编写规则的权力。这种权力可以集中在一处,也可以分散在多个地方。集中式管理意味着安全团队或管理员为所有人定义规则,这是强制访问控制背后的模式,访问权限由中央权威而非资源所有者决定。分散式管理意味着资源所有者自己决定谁可以访问它,这就是自主访问控制,经典的与特定人共享文件的模式。混合式则是部分规则来自中央权威,部分规则来自个人资源所有者,二者叠加。

值得注意的是,Mohamed 等人的文献综述以同样的方式处理策略维度,他们对访问控制模型的比较分析很有启发性:当他们按此维度对访问控制模型进行分类时,RBAC、ABAC 和 ReBAC 系列都落在了混合类别中,而非干净地归入 DAC 或 MAC。这本身就说明管理策略与授权模型是真正独立的维度:一个基于角色的系统既可以是集中管理的,也可以是所有者管理的,或者两者兼而有之,无论哪种情况它仍然是 RBAC。 授权模型回答的是什么类型的数据驱动决策。一旦制定规则的权力得以确定,下一个问题就是规则实际推理的对象是什么,决策每次运行时检查的具体信息类型。这是大多数人提及授权模型时所指的维度,也是之前关于 PBAC 文章的核心。常见的授权模型包括:基于身份的访问控制列表,决策检查特定主体是否出现在对象附带的列表中;基于角色的访问控制,决策检查主体是否持有已被授予所请求权限的角色;基于属性的访问控制,决策检查主体、对象、动作或环境的属性是否与规则匹配;基于关系的访问控制,决策检查主体与对象之间的关系,通常通过遍历图结构完成。

必须诚实地承认这里存在一定的模糊性。根据不同的学术来源,ACL 和 RBAC 可以被描述为 ABAC 的特例,其中所讨论的属性恰好是身份或角色成员关系。这四个类别是有用分类法中最实用的划分,但这并不意味着在数学层面它们彼此互斥。 授权策略回答的是规则以什么形式存在。一旦选择了模型,它仍然需要以具体工件的形式记录下来。它可以是应用代码中的硬编码条件语句,可以是运行时加载和解释的结构化文档(JSON、YAML),可以是专门为授权构建的声明式策略语言(如 XACML、Rego、Cedar),也可以是数据库表中的一行数据。

这个维度之所以关键,是因为两个系统可以共享相同的授权模型(都是 RBAC),却因策略表达方式的不同而在可维护性、可审计性和规则修改资格方面完全不同。 授权信息回答的是决策数据从何而来。规则的质量取决于评估它的数据,而这些数据并非都以相同方式获得。有必要将规则所依赖的内容与系统在运行时实际获取它的方式区分开来。数据可以是硬连线式的,即在正常请求流程中已经可用,无需额外查找;可以是基于令牌的,即作为 JWT 或类似凭证中的声明,由身份提供商在签发时填充;可以是查询式的,即应用在决策时查询数据库、目录或外部服务;也可以是环境性的,即描述请求本身上下文而非主体或对象的数据,包括时间、位置、设备状态、网络环境。 即使在严谨的学术研究中,这里也存在真实的区分被模糊的情况。

Mohamed 等人的框架将环境属性归入授权模型的组件列表,与主体和对象并列,而没有将运行时数据实际从哪里来视为独立的架构考量。我认为这是 PBAC 文章所指出问题的微小版本:知道决策依赖于一天中的某个时间是一个建模问题,但知道请求必须通过网络往返到目录服务才能获取该数据则是一个架构问题,对延迟和故障模式有着切实影响。 授权决策回答的是决策如何计算以及在哪里计算。一旦规则和数据都可用,就必须有某个组件实际运行评估。这个组件可以存在于几个不同的位置,而它所在位置是一个关于架构的问题,而非关于规则本身的问题。决策可以硬连线到应用代码中,作为业务逻辑内联的条件语句或框架原生权限检查;可以由专门的库或模块处理,决策逻辑被抽出但仍在应用进程内运行;也可以由集中式策略引擎处理,这是一个接收上下文并返回决策的独立服务,通常被多个应用共享。

PBAC 应当被归入这里,而非授权模型维度。将决策点集中到策略引擎中是关于评估发生位置的一种架构选择,它与任何授权模型都兼容:PBAC 引擎可以评估基于角色的规则、基于属性的规则,或者两者的混合。这正是 PBAC 不是 RBAC 和 ABAC 同类的原因,它回答的是与 RBAC 和 ABAC 完全不同的问题。 授权执行回答的是决策如何执行以及在哪里执行。决策只有在被付诸实施时才有意义,而这种实施不必发生在做出决策的同一位置。授权执行可以位于应用代码中,做出决策的同一代码路径也会对其进行操作;可以由专门的中间件执行,作为框架级组件根据决策拦截请求;也可以是分布式执行,由网关、边车或代理在网络边缘执行决策,独立于应用本身。

与授权决策维度一样,这是架构问题而非模型问题。通过 API 网关执行 ABAC 决策的系统和通过内联中间件执行 ABAC 决策的系统都是毫无疑问的 ABAC,它们只是对执行位置做出了不同的选择,通常是出于运营规模或需要共享同一策略的服务数量等考量。 六维度协同工作的图景 一个真实授权系统的完整描述应该是跨所有六个维度的元组,而非单一的术语。RBAC 仅对授权模型维度有所说明,而对其他五个维度只字未提。一个授权系统完全可以同时具备以下特征:集中式管理(MAC 维度)、基于角色的模型(RBAC 维度)、JSON 策略文档、基于令牌的信息、共享策略引擎(PBAC 架构)、网关级执行。这是一个连贯且常见的现实配置,其中的每一个标签都同时准确,因为每一个都回答了不同的问题。

大多数授权讨论中的混乱源于人们为每个系统选择一个标签并将其视为全面的描述,但实际上它只是对话中首先涉及的维度的答案。如果术语被放置在正确的轴上后就不再相互竞争,那就是这些轴发挥了实际效用的标志。 跨领域的类比有助于澄清这种关系。我们可以借用法律体系的运作作为类比。立法机构起草规则,规则被写成法律文本,法庭对照案件事实权衡这些法律,警察执行判决。将法律系统替换为授权系统,同样的六项工作就会逐一重新出现。

授权管理对应立法权的归属,授权模型对应法律所涉及的具体领域(宪法关注角色、合同关注关系),授权策略对应法律文本的形态,授权信息对应呈堂事实和证据的来源,授权决策对应法庭作为决策引擎的角色,授权执行对应警察作为执行机构的位置。 这种类比的有趣之处在于它的局限性恰好与软件术语的局限相同。没有人会把法庭称为行政法,也不会因为法官考虑了证人的证词就声称存在证人法。但其下的六项工作是立法者的角色、适用的法律类别、法律的实际条文、适用的事实、判决者、执法者在法庭中和在策略引擎中一样可分离,混淆它们在任何领域都会导致同样的范畴错误。 术语问题的根源与解决 授权领域的术语问题不在于缺乏词汇。事实上,问题恰恰相反:词汇过多。

MAC、DAC、RBAC、ABAC、ReBAC、ACL、PBAC 以及更多术语,每一个都由不同的论文、标准或供应商在不同时期、不同层级上创造,却被当作扁平的授权模型清单进行选择,而其中大多数术语实际上根本不相互竞争。 当真正为现实系统选择授权方法时,分离问题维度会带来非常实际的帮助。基于访问规则自然依赖的内容(角色、属性、关系)来选择授权模型。基于运营约束(需要共享策略的服务数量、可容忍的延迟、谁需要审计或修改规则)来单独选择架构,即决策被制定和执行的位置。这是两个独立的决策,各有不同的取舍集合,将它们捆绑成单一选择会隐藏实际需要决定的一半内容。 所有这些并不会使单个标签变得错误。

RBAC 是对模型的有用描述,PBAC 是对架构的有用描述,它们只是没有描述同一件事。一致的分类法让我们能够准确地说出每一个标签具体指的是什么。在身份管理和信息安全行业日益复杂的今天,构建清晰的认知框架比记住更多缩写词更重要。理解授权系统的真正结构,区分管理、模型、策略、信息、决策、执行这六个独立维度,才能在面对实际需求时做出明智的技术选择,而非在混乱的术语森林中迷失方向。 这种思维方式的转变不仅有助于技术决策,还有更利于团队沟通和知识传承。当团队使用统一的分类法讨论授权系统时,歧义大大降低,讨论效率显著提升。

新成员加入团队时也能更快地建立完整的认知图景,而非陷入术语的迷宫。这正是厘清授权术语混乱带来的更深层次收益,它不仅修复了一个概念问题,更为整个领域的成熟奠定了基础。 。