# 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 逻辑

## 数据库设计

```prisma
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 标准](https://csrc.nist.gov/projects/role-based-access-control)