fischerX/docs/architecture/design-decisions/0005-rbac-authorization.md

ADR-0005: RBAC 权限模型

状态	接受
创建日期	2026-05-25
作者	技术团队

上下文

我们需要设计一个灵活且可扩展的权限系统。需求包括：

• 用户角色管理
• 资源访问控制
• 权限继承
• 易于管理和扩展

决策

我们决定使用 RBAC (基于角色的访问控制) 模型：

1. 用户: 可以被分配多个角色
2. 角色: 一组权限的集合
3. 权限: 对特定资源的特定操作

备选方案

方案 1: ACL (访问控制列表)

优点:

• 简单直观
• 适合小规模应用

缺点:

• 用户多时难以管理
• 缺少灵活性
• 难以维护

方案 2: ABAC (基于属性的访问控制)

优点:

• 非常灵活
• 支持复杂规则
• 动态权限

缺点:

• 复杂度过高
• 性能开销
• 实现和维护困难
• 对当前项目可能过度设计

方案 3: 混合方案 (RBAC + ABAC)

优点:

• 兼顾灵活性和简单性

缺点:

• 复杂度增加
• 当前项目不需要

后果

正面影响

1. 易于理解: 角色概念直观
2. 灵活管理: 可以随时创建新角色和权限
3. 权限继承: 角色可以继承其他角色
4. 可审计: 清楚知道谁有什么权限
5. 易于扩展: 可以添加新的角色和权限

负面影响

1. 初始设计: 需要仔细设计角色和权限
2. 权限膨胀: 需要定期审查，防止权限过多过杂
3. 实现复杂度: 需要在应用层实现 RBAC 逻辑

数据库设计

model User {
  id    String @id @default(cuid())
  roles Role[]
}

model Role {
  id          String     @id @default(cuid())
  name        String     @unique
  permissions Permission[]
  users       User[]
  description String?
}

model Permission {
  id          String   @id @default(cuid())
  name        String   @unique // 格式: "resource:action" (如 "user:read")
  description String?
  roles       Role[]
}

相关链接

• NIST RBAC 标准