📚 课程目录第4章授权模型

授权模型：RBAC、ABAC、ACL等授权模型原理与适用场景

核心原理：从“谁”到“什么条件”的授权演进

授权模型解决的核心问题是：在确认身份之后，系统如何判定一个主体（用户、服务、设备）能否对某个资源执行特定操作。不同模型对“判定依据”的抽象层次不同，直接决定了权限管理的灵活性、安全粒度和运维成本。

ACL（访问控制列表）是最直接的模型——在资源上挂一张“允许名单”，列出哪些主体可以执行哪些操作。它贴近直觉，但主体数量增长时列表会迅速膨胀，且无法表达“所有实习生”这类群体语义。

RBAC（基于角色的访问控制）引入“角色”作为中间层，将权限授予角色，再将角色分配给用户。用户与权限解耦，权限调整只需修改角色定义，大幅降低管理复杂度。RBAC 的核心是静态职责分离（SoD）与动态职责分离（DSD），前者约束用户不能同时拥有互斥角色（如“审批人”与“申请人”），后者在会话中临时限制角色激活。

ABAC（基于属性的访问控制）则把判定条件抽象为属性表达式：主体属性（部门、职级）、资源属性（密级、所属项目）、环境属性（时间、IP、设备状态）。策略引擎对属性集合求值，返回“允许/拒绝”。ABAC 表达能力最强，但策略编写与性能调优复杂度也最高。

  关键区别速览：ACL 是“资源视角的名单”，RBAC 是“组织视角的岗位”，ABAC 是“上下文视角的规则”。三者并非互斥，现代系统常组合使用——外层 ABAC 做动态过滤，内层 RBAC 做基础授权，ACL 用于个别资源的例外放行。

方法流程：如何选择与落地授权模型

选择授权模型不是“越高级越好”，而是匹配业务的安全需求与管理成本。推荐按以下流程决策：

梳理资源与操作粒度：列出需要保护的资源类型（API、数据表、文件、微服务）及操作（读、写、删除、调用）。粒度越细，对 ABAC 的需求越高。
分析主体组织模式：用户数量是否庞大？是否存在清晰的岗位/部门结构？若用户可归入固定岗位，RBAC 是首选；若用户属性差异大且权限随上下文变化，需引入 ABAC。
评估动态性需求：权限是否随时间、地点、设备状态、数据密级变化？例如“仅允许在工作时间访问生产库”“仅允许从办公网 SSH 登录”，这类需求必须用 ABAC 的环境属性。

设计混合策略：实践中通常以 RBAC 为骨架，对敏感资源叠加 ABAC 策略，对个别例外用 ACL 做白名单覆盖。例如：

# 伪代码示例：K8s + OPA 策略
# RBAC 层：绑定角色
kind: RoleBinding
metadata:
  name: dev-reader
subjects:
- kind: User
  name: "alice@corp.com"
roleRef:
  kind: ClusterRole
  name: view

# ABAC 层：OPA 策略（限制仅工作日可写）
allow {
  input.method == "write"
  input.user.role == "dev"
  time.weekday(input.time) != "saturday"
  time.weekday(input.time) != "sunday"
}

规划审计与可视化：无论选择哪种模型，都必须记录授权判定日志（主体、资源、动作、结果、策略ID），便于安全审计与策略调优。

案例/场景：三种模型在 AI 平台中的典型应用

场景	推荐模型	原因说明
模型仓库（Model Registry）的读写权限	RBAC	角色清晰：模型开发者、审核者、部署工程师；权限相对稳定
训练数据集的列级脱敏访问	ABAC	同一角色不同项目成员，对含 PII 数据的列访问需按项目归属动态判断
推理服务（Inference Service）的临时调试通道	ACL	仅需为个别 SRE 工程师临时开放 5 分钟访问，用 ACL 白名单最直接
GPU 资源池的调度权限	RBAC + ABAC	基础角色决定可用队列，ABAC 根据任务优先级和当前集群负载动态调整

实战建议：在 AI 平台中，模型文件与训练数据通常采用 RBAC 控制“谁能访问”，而推理请求的鉴权则叠加 ABAC 控制“在什么条件下允许调用”。例如：某模型的在线推理接口，要求调用方服务账号具备 inference.invoker 角色（RBAC），同时请求必须携带有效的项目标签且来源 IP 在允许网段内（ABAC）。

误区/复盘：常见实施陷阱与规避

误区一：RBAC 角色划分过细。为每个功能点创建一个角色，导致角色数量爆炸，管理成本反而超过直接 ACL。复盘：角色应映射“组织岗位”而非“功能权限”，细粒度差异用 ABAC 补充。
误区二：ABAC 策略缺乏测试。属性表达式逻辑复杂，线上出现“开发环境放行、生产环境拒绝”的诡异问题。复盘：必须建立策略仿真测试集，覆盖正反用例，并纳入 CI/CD 流程。
误区三：忽略 ACL 的“默认拒绝”。在 ACL 模型中，如果资源没有显式授权记录，部分系统会默认允许（尤其是旧系统）。复盘：所有授权模型都应遵循 默认拒绝（Default Deny） 原则，未匹配到任何允许策略的请求一律拒绝。
误区四：混合模型时策略冲突无优先级。当 RBAC 允许但 ABAC 拒绝时，系统行为不确定。复盘：明确拒绝优先（Deny Overrides）策略——任何一层返回拒绝，最终结果即为拒绝，避免权限绕过。

安全提醒：在 AI 平台中，训练数据与模型权重属于高价值资产。若使用 ABAC 控制数据访问，务必确保资源属性（如数据密级）由系统自动打标，而非依赖用户手工输入，否则用户可能通过修改资源标签绕过策略。

授权模型的选择本质是安全粒度与管理复杂度的权衡。ACL 适合小规模、静态的资源；RBAC 适合组织架构清晰的企业系统；ABAC 适合属性多变、需要动态判定的云原生与 AI 场景。生产环境中，以 RBAC 为基础、ABAC 为扩展、ACL 为补充的混合架构最为常见。关键在于：明确每种模型的边界，制定统一的策略冲突解决规则，并始终将“默认拒绝”作为安全底线。