【系统架构设计】授权架构：RBAC、ABAC 与策略引擎

上一篇：认证架构 下一篇：零信任架构

一个 SaaS 平台在初期用三个角色（Admin、Editor、Viewer）就能覆盖全部权限需求。当租户数量增长到数百家，每家又要求”只能看自己部门的数据”“审批流只对特定项目生效”时，角色数量从 3 个膨胀到 3000 个——这就是角色爆炸（Role Explosion）。本文围绕”当 RBAC（Role-Based Access Control）的角色爆炸时怎么办”这一核心问题，逐步展开 ABAC（Attribute-Based Access Control）、ReBAC（Relationship-Based Access Control）与策略引擎（Policy Engine）的架构设计。

一、问题场景

授权（Authorization）回答的是”已认证的主体能否对资源执行某操作”。与认证（Authentication）不同，授权的复杂度随业务增长呈指数级上升。

1.1 典型业务需求

在企业级系统中，授权需求通常包含以下维度：

• 功能权限：用户是否能访问某个菜单或 API 端点；
• 数据权限：用户是否能看到某条记录（行级）或某个字段（列级）；
• 操作权限：用户是否能对资源执行特定动作（读、写、删除、审批）；
• 上下文约束：操作是否在允许的时间窗口、网络环境、设备条件下发生。

1.2 授权决策的四个参与方

XACML（eXtensible Access Control Markup Language）标准定义了授权决策的四个核心组件：

请求 --> [PEP] --查询--> [PDP] --获取属性--> [PIP]
                          |
                     [PAP: 策略存储]

这一架构模型贯穿后续所有授权方案的讨论。

1.3 从单体到微服务的授权挑战

在单体架构中，授权逻辑通常内嵌在业务代码里，通过 if-else 或注解完成。微服务架构下，挑战显著增加：

• 每个服务都需要独立做授权决策，但策略必须全局一致；
• 服务间调用的身份传递需要可信的令牌机制；
• 权限变更需要在所有服务间快速生效；
• 授权决策的延迟直接影响 API 响应时间。

二、RBAC 模型与角色爆炸

2.1 RBAC 核心概念

RBAC 由 NIST（National Institute of Standards and Technology）标准化，其核心思想是通过角色（Role）间接地将权限（Permission）赋予用户（User）。

用户 --分配--> 角色 --关联--> 权限

NIST RBAC 模型定义了四个层级：

• RBAC0（Core）：用户-角色-权限的基本映射；
• RBAC1（Hierarchical）：角色继承，高级角色自动拥有低级角色的权限；
• RBAC2（Constrained）：静态和动态职责分离（SoD，Separation of Duties）；
• RBAC3（Symmetric）：RBAC1 + RBAC2 的完整组合。

2.2 数据模型

-- RBAC 核心表结构
CREATE TABLE users (
    id         BIGINT PRIMARY KEY,
    username   VARCHAR(64) NOT NULL UNIQUE
);

CREATE TABLE roles (
    id         BIGINT PRIMARY KEY,
    name       VARCHAR(64) NOT NULL UNIQUE,
    parent_id  BIGINT REFERENCES roles(id)  -- 角色继承
);

CREATE TABLE permissions (
    id         BIGINT PRIMARY KEY,
    resource   VARCHAR(128) NOT NULL,
    action     VARCHAR(32)  NOT NULL,
    UNIQUE(resource, action)
);

CREATE TABLE user_roles (
    user_id    BIGINT REFERENCES users(id),
    role_id    BIGINT REFERENCES roles(id),
    PRIMARY KEY(user_id, role_id)
);

CREATE TABLE role_permissions (
    role_id       BIGINT REFERENCES roles(id),
    permission_id BIGINT REFERENCES permissions(id),
    PRIMARY KEY(role_id, permission_id)
);

2.3 角色爆炸问题

假设一个系统有以下维度：

• 3 个基础角色：管理员、编辑者、查看者；
• 10 个部门；
• 5 个项目；
• 4 个数据密级。

如果用纯 RBAC 表达”某用户在某部门的某项目中以某密级角色操作”，需要的角色数量为：

3 x 10 x 5 x 4 = 600 个角色

这还只是四个维度。实际业务中维度更多，角色数量轻松突破数千甚至数万。角色爆炸带来的问题：

• 管理成本剧增：管理员无法理解上千个角色的含义；
• 分配错误频繁：角色命名混乱导致误授权；
• 审计困难：无法快速回答”某用户为什么能访问这个资源”；
• 变更风险高：修改一个角色可能影响大量用户。

2.4 RBAC 的适用边界

RBAC 并非无用，它在以下场景仍然是最佳选择：

• 权限维度少（不超过 2-3 个）；
• 组织结构扁平；
• 权限粒度为功能级别而非数据级别；
• 用户规模有限（数百到数千）。

超出这些边界，就需要引入 ABAC 或 ReBAC。

三、ABAC 模型

3.1 核心思想

ABAC（Attribute-Based Access Control）不再依赖预定义的角色，而是基于属性（Attribute）动态计算授权决策。一条 ABAC 策略的形式为：

当 主体属性 AND 资源属性 AND 操作属性 AND 环境属性 满足条件时，允许/拒绝

3.2 属性分类

3.3 XACML 架构

ABAC 的标准实现遵循 XACML 架构，各组件的交互流程如下：

sequenceDiagram
    participant Client as 客户端
    participant PEP as PEP（执行点）
    participant PDP as PDP（决策点）
    participant PIP as PIP（信息点）
    participant PAP as PAP（管理点）

    Client->>PEP: 发起资源请求
    PEP->>PDP: 授权查询（主体、资源、操作）
    PDP->>PIP: 获取主体属性
    PIP-->>PDP: 返回属性值
    PDP->>PIP: 获取资源属性
    PIP-->>PDP: 返回属性值
    PDP->>PAP: 加载匹配策略
    PAP-->>PDP: 返回策略集
    PDP->>PDP: 评估策略
    PDP-->>PEP: 返回决策（Permit/Deny）
    PEP-->>Client: 允许或拒绝请求

3.4 策略示例

以下是一条 ABAC 策略的伪代码表示：

策略：文档编辑权限
目标：resource.type == "document"
规则：
  IF subject.department == resource.ownerDepartment
     AND subject.clearance >= resource.classification
     AND action IN ["read", "write"]
     AND environment.time BETWEEN "09:00" AND "18:00"
  THEN Permit
  ELSE Deny

3.5 ABAC 的优势与局限

优势：

• 策略数量不随维度组合增长——一条策略即可覆盖多个维度；
• 支持动态、上下文感知的细粒度授权；
• 策略与代码解耦，可独立管理和审计。

局限：

• 策略编写复杂度高，需要专业知识；
• 属性来源分散，PIP 集成成本大；
• 策略冲突解决（Combining Algorithm）逻辑复杂；
• 性能开销：每次决策可能需要多次属性查询。

四、ReBAC 与 Google Zanzibar

4.1 ReBAC 核心思想

ReBAC（Relationship-Based Access Control）的核心观点是：权限由对象之间的关系（Relationship）决定。与 ABAC 关注属性不同，ReBAC 关注实体间的图结构关系。

例如：

• “Alice 是 Document-123 的 editor” —— 这是一条关系；
• “editor 隐含 viewer” —— 这是关系的继承规则；
• “Alice 能否查看 Document-123？” —— 通过关系图遍历得出答案。

4.2 Google Zanzibar 概述

Google 在 2019 年发表的论文《Zanzibar: Google’s Consistent, Global Authorization System》描述了其全球授权系统。Zanzibar 为 Google Drive、YouTube、Cloud IAM 等产品提供统一的授权服务，峰值每秒处理数百万次授权检查。

4.3 Relation Tuple 模型

Zanzibar 的核心数据结构是关系元组（Relation Tuple），格式为：

namespace:object#relation@user

具体示例：

doc:readme#owner@user:alice
doc:readme#viewer@group:engineering#member
folder:root#parent@doc:readme
group:engineering#member@user:bob

每个元组表达一条关系事实。其中各字段含义如下：

4.4 命名空间配置

命名空间配置（Namespace Configuration）定义关系的继承和推导规则：

name: doc
relations:
  owner:
    union:
      - this                          # 直接关系
  editor:
    union:
      - this
      - computedUserset:
          relation: owner             # owner 隐含 editor
  viewer:
    union:
      - this
      - computedUserset:
          relation: editor            # editor 隐含 viewer
      - tupleToUserset:
          tupleset:
            relation: parent          # 从父对象继承
          computedUserset:
            relation: viewer

4.5 Check API 流程

Zanzibar 的核心 API 是 Check，用于回答”用户 U 是否对对象 O 具有关系 R”。

flowchart TD
    A[Check 请求: user:bob 是否为 doc:readme#viewer] --> B{直接关系查找}
    B -->|存在| C[返回 Permit]
    B -->|不存在| D{关系继承: viewer 包含 editor?}
    D -->|是| E{查找 doc:readme#editor@user:bob}
    E -->|存在| C
    E -->|不存在| F{关系继承: editor 包含 owner?}
    F -->|是| G{查找 doc:readme#owner@user:bob}
    G -->|存在| C
    G -->|不存在| H{间接关系: tupleToUserset}
    H --> I{查找 doc:readme#parent 的所有对象}
    I --> J[对每个父对象递归检查 viewer 关系]
    J -->|任一返回 Permit| C
    J -->|全部返回 Deny| K{用户组展开}
    K --> L{查找 doc:readme#viewer@group:*#member}
    L --> M[对每个组检查 user:bob 是否为 member]
    M -->|任一匹配| C
    M -->|全部不匹配| N[返回 Deny]

4.6 一致性模型

Zanzibar 使用 Zookie（也称 Snapshot Token）来解决分布式环境下的一致性问题。

问题场景：管理员刚刚撤销了 Alice 对 Document-123 的访问权限，但由于副本延迟，某个节点仍然返回”允许”。

解决方案：

1. 每次写入关系元组时，系统返回一个 Zookie（本质上是一个时间戳或版本号）；
2. 后续的 Check 请求携带 Zookie；
3. PDP 节点确保使用不早于 Zookie 所对应时间点的数据快照进行评估。

写入：DELETE doc:readme#viewer@user:alice
返回：zookie = "Zr4x8kP2"

检查：Check(doc:readme#viewer, user:alice, zookie="Zr4x8kP2")
结果：Deny（使用 >= Zr4x8kP2 时间点的数据）

这种机制在 Google 内部被称为”New Enemy Problem”的解决方案——确保权限撤销不会因为读取旧副本而被绕过。

4.7 Expand 与 Read API

除了 Check，Zanzibar 还提供：

• Expand API：展开某个对象-关系的所有用户集合，用于权限审计；
• Read API：读取满足过滤条件的关系元组，用于列举用户的所有可访问资源。

4.8 开源实现

Zanzibar 模型有多个开源实现：

五、策略引擎：OPA

5.1 OPA 概述

OPA（Open Policy Agent）是 CNCF（Cloud Native Computing Foundation）毕业项目，提供通用的策略引擎。OPA 将策略从代码中解耦，以声明式语言 Rego 编写策略，通过 REST API 或嵌入库的方式集成。

5.2 Rego 策略语言

Rego 是一种声明式查询语言，语法受 Datalog 启发。以下是一个 API 授权策略示例：

package authz

import rego.v1

default allow := false

# 管理员拥有所有权限
allow if {
    input.user.roles[_] == "admin"
}

# 用户只能访问自己部门的数据
allow if {
    input.action == "read"
    input.resource.department == input.user.department
}

# 文档所有者可以编辑
allow if {
    input.action == "write"
    input.resource.type == "document"
    input.resource.owner == input.user.id
}

# 工作时间内才允许导出操作
allow if {
    input.action == "export"
    input.user.roles[_] == "editor"
    time.clock(time.now_ns())[0] >= 9
    time.clock(time.now_ns())[0] < 18
}

5.3 OPA 集成架构

OPA 支持两种主要集成模式：

Sidecar 模式：OPA 作为独立进程（通常是 Sidecar 容器）运行，应用通过 HTTP/gRPC 调用。

Library 模式：OPA 以 Go 库的形式嵌入应用进程，无网络开销。

flowchart LR
    subgraph Sidecar模式
        A1[应用服务] -->|HTTP/gRPC| B1[OPA Sidecar]
        B1 -->|定期拉取| C1[Bundle Server]
        B1 -->|推送| D1[Decision Log]
    end

    subgraph Library模式
        A2[应用服务 + OPA SDK] -->|定期拉取| C2[Bundle Server]
        A2 -->|推送| D2[Decision Log]
    end

    subgraph 管理平面
        C1 --- E[策略仓库 Git]
        C2 --- E
        D1 --- F[日志分析平台]
        D2 --- F
    end

5.4 Go 语言集成示例

以下示例展示如何在 Go 服务中以 Library 模式集成 OPA：

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "log"

    "github.com/open-policy-agent/opa/rego"
)

// AuthzInput 构造授权请求的输入结构
type AuthzInput struct {
    User     UserInfo     `json:"user"`
    Action   string       `json:"action"`
    Resource ResourceInfo `json:"resource"`
}

type UserInfo struct {
    ID         string   `json:"id"`
    Department string   `json:"department"`
    Roles      []string `json:"roles"`
}

type ResourceInfo struct {
    Type       string `json:"type"`
    Department string `json:"department"`
    Owner      string `json:"owner"`
}

func main() {
    ctx := context.Background()

    // 从文件或 Bundle 加载策略
    query, err := rego.New(
        rego.Query("data.authz.allow"),
        rego.Load([]string{"./policy"}, nil),
    ).PrepareForEval(ctx)
    if err != nil {
        log.Fatalf("策略编译失败: %v", err)
    }

    // 构造授权请求
    input := AuthzInput{
        User: UserInfo{
            ID:         "alice",
            Department: "engineering",
            Roles:      []string{"editor"},
        },
        Action: "read",
        Resource: ResourceInfo{
            Type:       "document",
            Department: "engineering",
            Owner:      "bob",
        },
    }

    // 执行策略评估
    results, err := query.Eval(ctx, rego.EvalInput(input))
    if err != nil {
        log.Fatalf("策略评估失败: %v", err)
    }

    allowed := false
    if len(results) > 0 {
        allowed = results[0].Expressions[0].Value.(bool)
    }

    inputJSON, _ := json.MarshalIndent(input, "", "  ")
    fmt.Printf("输入:\n%s\n决策: %v\n", string(inputJSON), allowed)
}

5.5 Sidecar 模式下的 HTTP 调用

当 OPA 以 Sidecar 运行时，应用通过 HTTP 调用获取决策：

package authz

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "time"
)

// OPAClient 封装对 OPA Sidecar 的 HTTP 调用
type OPAClient struct {
    baseURL    string
    httpClient *http.Client
}

func NewOPAClient(baseURL string) *OPAClient {
    return &OPAClient{
        baseURL: baseURL,
        httpClient: &http.Client{
            Timeout: 100 * time.Millisecond,
        },
    }
}

type OPARequest struct {
    Input interface{} `json:"input"`
}

type OPAResponse struct {
    Result bool `json:"result"`
}

func (c *OPAClient) Check(input interface{}) (bool, error) {
    reqBody, err := json.Marshal(OPARequest{Input: input})
    if err != nil {
        return false, fmt.Errorf("序列化请求失败: %w", err)
    }

    resp, err := c.httpClient.Post(
        c.baseURL+"/v1/data/authz/allow",
        "application/json",
        bytes.NewReader(reqBody),
    )
    if err != nil {
        return false, fmt.Errorf("调用 OPA 失败: %w", err)
    }
    defer resp.Body.Close()

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return false, fmt.Errorf("读取响应失败: %w", err)
    }

    var opaResp OPAResponse
    if err := json.Unmarshal(body, &opaResp); err != nil {
        return false, fmt.Errorf("解析响应失败: %w", err)
    }

    return opaResp.Result, nil
}

5.6 Bundle 管理

OPA 的策略和数据通过 Bundle 机制分发：

# OPA 配置文件
services:
  bundle-server:
    url: https://policy-server.internal
    credentials:
      bearer:
        token: "${BUNDLE_TOKEN}"

bundles:
  authz:
    service: bundle-server
    resource: bundles/authz
    polling:
      min_delay_seconds: 10
      max_delay_seconds: 30

decision_logs:
  service: bundle-server
  resource: /logs
  reporting:
    min_delay_seconds: 5
    max_delay_seconds: 10

Bundle 的生命周期管理流程：

1. 策略开发者在 Git 仓库中编写和修改 Rego 策略；
2. CI/CD 流水线对策略执行单元测试（opa test）；
3. 测试通过后，将策略打包为 Bundle 并推送到 Bundle Server；
4. 各 OPA 实例定期拉取最新 Bundle；
5. 所有决策日志（Decision Log）异步上报，用于审计和分析。

5.7 Decision Logging

OPA 的决策日志记录每一次授权决策的完整上下文，包括输入、策略版本、决策结果和耗时。这对于安全审计和策略调试至关重要。

{
  "labels": {
    "id": "opa-sidecar-order-service",
    "version": "0.45.0"
  },
  "decision_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "input": {
    "user": {"id": "alice", "roles": ["editor"]},
    "action": "write",
    "resource": {"type": "document", "owner": "alice"}
  },
  "result": true,
  "timestamp": "2026-04-13T10:30:00Z",
  "metrics": {
    "timer_rego_query_eval_ns": 125000
  }
}

六、权限数据存储与缓存

6.1 存储模型选择

不同授权模型对存储有不同的要求：

6.2 权限反规范化

在高频查询场景下，规范化的权限数据（多表 JOIN）性能不足。常见的反规范化（Denormalization）策略：

策略一：预计算权限集

将用户的有效权限集预先计算并存储，避免实时遍历角色继承树。

-- 物化视图：用户有效权限
CREATE MATERIALIZED VIEW user_effective_permissions AS
SELECT DISTINCT ur.user_id, p.resource, p.action
FROM user_roles ur
JOIN roles r ON ur.role_id = r.id
JOIN role_permissions rp ON rp.role_id = r.id
JOIN permissions p ON rp.permission_id = p.id
UNION
SELECT DISTINCT ur.user_id, p.resource, p.action
FROM user_roles ur
JOIN roles r ON ur.role_id = r.id
JOIN roles parent ON r.parent_id = parent.id
JOIN role_permissions rp ON rp.role_id = parent.id
JOIN permissions p ON rp.permission_id = p.id;

策略二：位图编码

将权限编码为位图（Bitmap），用位运算进行授权判断：

// 权限位图：每个权限对应一个位
const (
    PermRead   uint64 = 1 << iota // 0b0001
    PermWrite                      // 0b0010
    PermDelete                     // 0b0100
    PermAdmin                      // 0b1000
)

type UserPermission struct {
    UserID     string
    ResourceID string
    Bitmap     uint64
}

func (up *UserPermission) HasPermission(perm uint64) bool {
    return up.Bitmap&perm == perm
}

func (up *UserPermission) Grant(perm uint64) {
    up.Bitmap |= perm
}

func (up *UserPermission) Revoke(perm uint64) {
    up.Bitmap &^= perm
}

6.3 缓存策略

权限数据的缓存需要在性能和一致性之间取得平衡。

本地缓存：

// 基于 LRU 的本地权限缓存
type PermissionCache struct {
    cache    *lru.Cache
    ttl      time.Duration
}

type cacheEntry struct {
    allowed   bool
    expiresAt time.Time
}

func NewPermissionCache(size int, ttl time.Duration) *PermissionCache {
    c, _ := lru.New(size)
    return &PermissionCache{cache: c, ttl: ttl}
}

func (pc *PermissionCache) Get(key string) (bool, bool) {
    val, ok := pc.cache.Get(key)
    if !ok {
        return false, false
    }
    entry := val.(*cacheEntry)
    if time.Now().After(entry.expiresAt) {
        pc.cache.Remove(key)
        return false, false
    }
    return entry.allowed, true
}

func (pc *PermissionCache) Set(key string, allowed bool) {
    pc.cache.Add(key, &cacheEntry{
        allowed:   allowed,
        expiresAt: time.Now().Add(pc.ttl),
    })
}

6.4 缓存失效模式

事件驱动失效示例：

// 使用消息队列进行权限缓存失效
type PermissionInvalidator struct {
    cache      *PermissionCache
    subscriber messaging.Subscriber
}

func (pi *PermissionInvalidator) Start(ctx context.Context) error {
    return pi.subscriber.Subscribe(ctx, "permission.changed", func(msg *messaging.Message) error {
        var event PermissionChangeEvent
        if err := json.Unmarshal(msg.Data, &event); err != nil {
            return err
        }

        // 按变更范围清除缓存
        switch event.Scope {
        case "user":
            pi.cache.InvalidateByPrefix("user:" + event.UserID)
        case "role":
            // 角色变更影响所有持有该角色的用户，需要批量失效
            pi.cache.InvalidateByPrefix("role:" + event.RoleID)
        case "global":
            pi.cache.Flush()
        }

        return nil
    })
}

6.5 最终一致性权衡

权限系统的一致性要求因场景而异：

• 强一致性场景：金融交易授权、数据删除权限——必须实时生效，不可使用缓存或使用 Zookie 模式；
• 最终一致性可接受场景：文档查看权限、菜单显示——短暂的延迟（数秒）不会造成安全风险；
• 折中方案：对于”授予权限”使用最终一致性（用户稍后看到新权限可以接受），对于”撤销权限”使用强一致性（安全性优先）。

七、工程案例

7.1 案例背景：SaaS 协作平台的授权演进

某 B2B SaaS 协作平台（类似企业级文档协作工具）在三年内经历了授权架构的三次演进。

第一阶段：纯 RBAC（0-100 家客户）

初期产品功能简单，定义了三个全局角色：

Admin   -> 所有操作权限
Editor  -> 创建、编辑、查看文档
Viewer  -> 仅查看文档

此阶段运行良好，管理简单，开发成本低。

第二阶段：角色爆炸（100-500 家客户）

随着多租户和组织层级的引入，客户提出了差异化权限需求：

• 租户 A 要求”部门经理只能看到本部门的文档”；
• 租户 B 要求”外部协作者只能看到被明确共享的文档”；
• 租户 C 要求”审批流中的审批人临时获得编辑权限”。

为满足这些需求，团队开始为每个租户创建定制角色：

TenantA_DeptManager_Engineering
TenantA_DeptManager_Sales
TenantB_ExternalCollaborator
TenantC_Approver_ProjectX
...

角色数量从 3 个增长到 1200 个。问题开始显现：

• 客户支持团队无法理解角色含义；
• 新功能上线需要为所有租户批量创建角色；
• 角色分配错误导致两次数据泄露事件。

第三阶段：混合架构（500+ 家客户）

团队决定重构授权架构，采用 RBAC + ReBAC 的混合方案：

• RBAC 层：保留少量全局角色（Admin、Member、Guest），用于功能权限；
• ReBAC 层：使用 SpiceDB 管理文档级别的细粒度权限（所有者、编辑者、查看者）；
• ABAC 层：使用 OPA 处理跨领域策略（IP 白名单、工作时间限制、合规要求）。

7.2 混合架构设计

flowchart TD
    A[API 请求] --> B[API Gateway / PEP]
    B --> C{功能权限检查}
    C -->|RBAC| D[角色服务]
    D -->|通过| E{数据权限检查}
    D -->|拒绝| Z[返回 403]
    E -->|ReBAC| F[SpiceDB]
    F -->|通过| G{策略检查}
    F -->|拒绝| Z
    G -->|ABAC| H[OPA]
    H -->|通过| I[转发至后端服务]
    H -->|拒绝| Z

7.3 SpiceDB 关系建模

definition user {}

definition organization {
    relation admin: user
    relation member: user
}

definition workspace {
    relation org: organization
    relation admin: user
    relation member: user

    permission manage = admin + org->admin
    permission access = member + manage
}

definition document {
    relation workspace: workspace
    relation owner: user
    relation editor: user
    relation viewer: user

    permission write = owner + editor + workspace->manage
    permission read = viewer + write + workspace->access
    permission delete = owner + workspace->manage
}

7.4 迁移过程中的关键决策

7.5 迁移效果

八、选型对比

8.1 三种模型对比

8.2 OPA 集成模式对比

8.3 选型决策树

根据业务需求，可按以下路径选择授权模型：

Q1: 权限维度是否超过 3 个？
  否 -> RBAC
  是 -> Q2

Q2: 权限是否与对象间关系强相关（共享、协作、层级）？
  是 -> ReBAC（Zanzibar 模型）
  否 -> Q3

Q3: 是否需要基于上下文动态决策（时间、地点、设备）？
  是 -> ABAC（OPA / XACML）
  否 -> RBAC + 数据过滤

实际工程中，混合架构是常态：RBAC 管功能权限，ReBAC 管资源级权限，ABAC 处理横切策略。

九、总结

授权架构没有银弹。RBAC 简单直接但不耐扩展；ABAC 灵活强大但管理成本高；ReBAC 在协作和资源共享场景中表现出色。工程实践中的关键原则：

1. 从 RBAC 起步：不要过早引入复杂模型，在角色爆炸成为实际痛点时再演进；
2. 策略与代码分离：使用 OPA 等策略引擎将授权逻辑从业务代码中剥离；
3. 选择合适的一致性级别：授予权限可容忍最终一致性，撤销权限需要强一致性；
4. 可审计性优先：授权系统必须能回答”谁在什么时候基于什么规则访问了什么资源”；
5. 混合架构是常态：不同层级的权限用不同模型处理，通过 PEP 统一编排。

当 RBAC 的角色爆炸时，答案不是”抛弃 RBAC”，而是在合适的层次引入 ReBAC 和 ABAC，让每种模型各司其职。

参考资料

1. Sandhu, R., et al. “Role-Based Access Control Models.” IEEE Computer, 1996.
2. NIST. “An Introduction to Role-Based Access Control.” NIST Special Publication, 2010.
3. OASIS. “eXtensible Access Control Markup Language (XACML) Version 3.0.” 2013.
4. Paans, R., et al. “Zanzibar: Google’s Consistent, Global Authorization System.” USENIX ATC, 2019.
5. Open Policy Agent Documentation. https://www.openpolicyagent.org/docs/latest/
6. SpiceDB Documentation. https://authzed.com/docs
7. OpenFGA Documentation. https://openfga.dev/docs
8. Bertocci, V. “Authorization in Microservices.” O’Reilly, 2023.
9. CNCF. “Open Policy Agent: Policy-based control for cloud native environments.” https://www.cncf.io/projects/open-policy-agent/
10. Ory Keto Documentation. https://www.ory.sh/docs/keto

上一篇：认证架构 下一篇：零信任架构