RBAC 核心概念：用户、角色、权限、会话及其在密钥系统中的映射
搞 RBAC 权限映射，第一个要啃下来的就是这四个概念——用户、角色、权限、会话。很多团队把这四个词挂在嘴边，但真到了密钥系统里落地，才发现偏差不小。我记得刚带项目那会儿，组里讨论「密钥权限」吵了三天，最后发现是大家对「权限」本身的定义就没对齐。好，咱们一个一个说清楚。
1. 用户（User）——从「谁在操作」到「谁持有密钥」
在标准 RBAC 里，用户就是最基础的操作主体。一个人、一个服务、一个设备——只要能发起操作，就是一个用户实体。你想想看，系统根本不管你是谁，它只认你的唯一标识。
但到了密钥系统里，「用户」这个概念就变味了。
密钥系统里的用户，不再是单纯的登录账号，而是密钥的持有者或调用者。我在项目中遇到过这样的情况：一个微服务 A 调用另一个服务 B 的加密接口，服务 A 本身就是一个「密钥用户」——它持有 TLS 证书，证书里的 Subject DN 就是它的身份。
具体映射关系是这样的：
| RBAC 用户 | 密钥系统映射 | 实际例子 |
|---|---|---|
| 自然人账号 | 证书主体（Subject DN） | CN=ZhangSan, OU=Dev, O=Company |
| 服务/进程 | 设备指纹 / SPIFFE ID | spiffe://prod/mesh/svc-payment |
| 物联网设备 | 预置证书 / 密钥别名 | device:gateway-001 |
| 临时任务 | 令牌中的 sub 声明 | JWT 的 "sub": "task:backup" |
2. 角色（Role）——从「身份分组」到「密钥用途分类」
角色是什么？说白了，就是一组权限的集合。你把「财务审核」这个角色赋给小李，小李就自动拥有了审核相关的所有权限。这样你就不用一条一条给他配了。
密钥系统里的角色，映射到的是密钥的用途分类。
我个人的习惯是，在 HSM 或 KMS 里定义三类角色：
- 密钥管理员 —— 负责创建、轮换、销毁密钥，但不接触明文数据。
- 密钥使用者 —— 只能用密钥做加密或签名，不能导出密钥材料。
- 审计员 —— 只读权限，查看密钥操作日志，不能碰任何密钥。
把 RBAC 的角色直接对应到密钥系统的策略组，你会发现权限控制瞬间清晰了。举个例子：
// 密钥管理系统中的角色定义（伪代码）
role "key-admin" {
permissions = ["key.create", "key.rotate", "key.delete", "key.list"]
}
role "key-user" {
permissions = ["key.encrypt", "key.decrypt", "key.sign"]
}
role "key-auditor" {
permissions = ["key.list", "audit.log.read"]
}3. 权限（Permission）——从「允许做什么」到「密钥能做什么」
权限是 RBAC 最细粒度的控制单元。在传统系统里，权限可能是「读取订单」「编辑用户」这样的操作。但在密钥系统里，权限对应的是密码学操作。
这一点很容易踩坑。很多人以为「有权限」就是「能访问密钥」，其实不对。密钥系统的权限控制的是：你能拿这把钥匙干什么。
标准密钥操作权限表：
| 密码学操作 | 映射的 RBAC 权限 | 控制粒度 |
|---|---|---|
| Encrypt（加密） | key:encrypt |
按密钥 ID + 算法 |
| Decrypt（解密） | key:decrypt |
按密钥 ID + 上下文 |
| Sign（签名） | key:sign |
按密钥用途 + 摘要算法 |
| Verify（验签） | key:verify |
通常放开，只验不签 |
| DeriveKey（密钥派生） | key:derive |
严格控制派生路径 |
| Export（导出） | key:export |
极少开放，需多人审批 |
你发现没有？同一个密钥，不同角色对它拥有的权限天差地别。管理员能导出密钥，使用者只能拿它加密——这就是 RBAC 在密钥系统里最实在的映射。
4. 会话（Session）——从「临时连接」到「密钥上下文」
会话在标准 RBAC 里是一个动态概念。用户登录、建立会话、激活角色、执行操作，然后会话失效。它解决的是「什么时候有权限」的问题。
密钥系统里的会话，映射的是密钥的使用上下文和生命周期。说白了，就是密钥在什么条件下、什么时间段内可以被使用。
我举几个具体的映射场景：
- TLS 会话 —— 握手阶段协商出临时会话密钥，连接断开密钥自动销毁。这就是一个典型的「密钥会话」。
- 临时令牌 —— KMS 签发的临时密钥令牌，15 分钟内有效，过期后权限自动回收。
- 密钥版本上下文 —— 同一把密钥的不同版本，只有当前活跃版本才能用于加密操作。
5. 四个概念的联动与映射关系图
好，上面我们把四个概念拆开讲了。但实际运行的时候，它们是联动的。我画了一张图，把 RBAC 核心概念到密钥系统的映射关系串起来，你一看就明白。
这张图的逻辑很直白。左边是标准 RBAC 的四个核心构件，右边是它们在密钥系统里的具体映射。箭头不是简单的「等于」，而是「对应到」——对应过程中需要做适配和转换，这也是咱们这门课后面要深挖的地方。
6. 映射实践中的几个关键经验
概念讲完了，我补充几条在项目里摔出来的经验，你直接拿去用：
- 用户映射别偷懒： 别只用 IP 地址当密钥用户标识。设备重启、网络换段，IP 一变，权限就乱了。用证书 DN 或 SPIFFE ID，稳定得多。
- 角色映射要分层： 密钥系统的角色别超过 5 个。角色越多，审计越乱。我一般就分管理员、使用者、审计员三层，够用了。
- 权限映射按最小化： 给密钥使用者只开 Encrypt 和 Sign，别顺手把 Decrypt 也开了。解密权限一放开，数据 confidentiality 就悬了。
- 会话映射别忘超时： 临时密钥令牌一定要设有效期，而且别太长。15 分钟是安全下限，超过 1 小时就要掂量掂量了。