2023年，某头部云厂商内部审计发现：一个生产环境的存储桶被配置了47条重叠的IAM策略，最终生效权限连配置者自己都说不清。这不是个案——随着微服务拆分到200+个服务、多租户SaaS成为标配，权限配置的复杂度正在以指数级膨胀。
传统RBAC（基于角色的访问控制）的崩溃早有征兆。NIST在2004年定义的4级RBAC模型，至今仍有90%的企业卡在Level 1（扁平角色）。当"角色爆炸"成为工程师的日常噩梦，ABAC（基于属性的访问控制）和ReBAC（基于关系的访问控制）被推到台前。但三者的边界究竟在哪？AWS IAM的JSON策略里为什么能同时看到三种模型的影子？
RBAC：从"钥匙串"到"钥匙山"
RBAC的核心逻辑像一把钥匙串：用户不直接开锁，而是拿到一串钥匙（角色），钥匙能开哪些门由管理员预先定义。这种间接性在小型团队里优雅简洁——5个角色覆盖20个人，人人权责清晰。
NIST的4级模型中，Level 1是扁平角色（Kubernetes RBAC属于此类），Level 2引入角色继承（如"高级开发"自动包含"开发"权限），Level 3强制职责分离（财务审批不能自己记账），Level 4则是完整的策略规则引擎。现实残酷：绝大多数企业连Level 2都没跑通。
Kubernetes的RBAC设计暴露了早期云原生对权限的简化假设。它的四个核心资源——Role、ClusterRole、RoleBinding、ClusterRoleBinding——实现了纯允许模式（Allow-only），没有显式拒绝。这意味着权限只能做加法：如果用户同时绑定了"只读"和"管理员"两个角色，系统会大方地合并所有权限，而非取交集。
AWS IAM在RBAC基础上做了关键改造。策略不再直接绑人，而是绑给IAM Role，用户或服务通过AssumeRole（角色扮演）临时获取凭证。这层抽象让跨账户授权成为可能，但也埋下了复杂度——一个Role可能被数十个策略文档交叉引用，权限的"生效时刻"变成动态计算的结果。
ABAC：当"你是谁"比"你的头衔"更重要
RBAC的瓶颈出现在规模化时刻。某电商平台的真实案例：需要为"上海仓库的夜班质检员，且入职满6个月"开放特定接口。用RBAC实现？得创建"上海-仓库-夜班-资深-质检员"这个角色，然后发现全国有37个仓库、3个班次、5个职级——角色数量直奔四位数。
ABAC把权限判断从"查头衔"转向"算属性"。AWS IAM的Condition块是典型实现：
策略不再问"你是不是S3-Admin角色"，而是问"你的请求是否来自VPC终端节点、是否在办公时间段、是否启用了多因素认证"。属性可以来自用户（部门、职级）、资源（标签、创建时间）、环境（IP地址、请求时间），甚至外部系统（HR系统的入职日期）。
这种灵活性代价显著：策略评估从O(1)的查表变成O(n)的条件计算。AWS文档明确警告，过度复杂的Condition会显著增加IAM决策延迟。更隐蔽的风险是属性漂移——当HR系统里的"入职日期"被手动修改，权限边界可能无声无息地滑动。
Kubernetes在1.30版本后逐步支持ABAC，但社区态度谨慎。核心维护者的判断是：属性策略的调试成本远高于角色策略，"能查到为什么允许"比"能表达复杂规则"对运维更关键。
ReBAC：权限即图，关系即规则
ReBAC的崛起与Google Zanzibar论文直接相关。这家搜索巨头在2019年开源了内部权限系统的核心思想：把"用户-资源-关系"建模为图结构，权限判断转化为图遍历查询。
传统模型问"Alice有没有读权限"，ReBAC问"Alice和这份文档之间是否存在owner/editor/viewer路径"。路径可以跨资源类型延伸：文档属于文件夹，文件夹属于项目，项目属于组织——权限继承不再是角色层级的垂直复制，而是资源拓扑的水平流动。
OpenFGA和SpiceDB是这一模型的主流实现。它们的策略语言（如Cedar、Rego）允许声明式定义关系链：
定义"viewer"关系时，可以声明"如果用户是文档所在项目的admin，则自动获得viewer权限"。这种推导是实时计算的，不需要像RBAC那样预先展开所有继承关系。
Azure的层级范围结构（Management Group → Subscription → Resource Group → Resource）被业界视为ReBAC思想的商业化落地。角色在高层分配后自动流向子节点，这与NIST Level 2的角色继承有本质区别：后者是角色定义的复用，前者是权限实例的传播。
ReBAC的挑战在于图查询的性能边界。当资源层级深达10层、关系边数以亿计时，单次授权检查可能触发复杂的子图遍历。Zanzibar的解决方案是激进缓存+预计算，但这套架构的运维成本让多数企业望而却步。
混合现实：没有纯血模型，只有场景适配
回到AWS IAM的JSON策略——它从来不是纯粹的RBAC。Effect、Action、Resource是角色骨架，Condition注入属性判断，而Resource的ARN（亚马逊资源名称）层级结构又隐含了关系继承。一个生产级策略往往三层嵌套：基于角色分配策略，基于属性限制条件，基于资源层级隐式授权。
这种混合性解释了为什么"权限即代码"工具（如Terraform的IAM模块）难以标准化。团队被迫在三个维度做取舍：表达力（能否描述业务规则）、可审计性（能否回答"为什么允许"）、性能（决策延迟是否可接受）。
Cedar语言的设计试图弥合这一裂缝。它同时支持RBAC的角色声明、ABAC的属性判断、ReBAC的关系推导，并通过"策略切片"技术保证评估性能。但2024年的用户调研显示，采用Cedar的团队中，73%最终退化为"高级RBAC"——只用其角色功能，属性与关系逻辑由应用层硬编码。
权限模型的选择，最终是组织复杂度的镜像。20人团队用RBAC Level 1足够，200人团队需要Level 2的角色工程，2000人团队被迫引入ABAC属性治理，20000人团队则在ReBAC的图数据库前评估运维投入。没有银弹，只有对"当前最痛的问题"的诚实回答。
你的生产环境里，最近一次权限审计能追溯到什么时候？审计报告里"无法解释的有效权限"条目，是0条，还是已经多到懒得数了？
热门跟贴