2. 密钥权限模型概述：为什么需要密钥？密钥与RBAC结合的场景

2.1 为什么需要密钥？

先聊个基础问题。咱们做权限系统，RBAC本身已经把用户、角色、权限管得明明白白了，为什么还要把「密钥」拉进来？

我早年带一个项目时，就踩过这个坑。业务方说"我们把用户角色分好，权限就搞定了吧"。结果上线没两天，有人直接拿着别人的跑来接口调用——身份没验证，任何权限都是空谈。说白了，RBAC管的是「你能做什么」，但前提是系统得知道「你是谁」。密钥就是干这个的。

具体来说，密钥在权限模型里解决三个核心问题：

• 身份确认 —— 保证请求方确实是你声明的那个实体，不是伪造的。
• 请求完整性 —— 消息在传输过程中没被篡改。签名算法会校验内容是否一致。
• 防重放 —— 配合时间戳和随机数，让同一个签名不能重复使用。

2.2 密钥在RBAC中的位置

你想想看，一次完整的请求，经过几步？

1. 客户端拿着密钥（比如 + Secret）发请求。
2. 服务端验证密钥，确认身份，拿到用户ID。
3. 根据用户ID查出该用户的角色列表。
4. RBAC引擎判断该角色是否有权限执行当前操作。
5. 放行或拒绝。

这里面，密钥负责第1、2步，RBAC负责第3、4步。两者是串联关系，不是替代关系。我在另一个项目中见到有人试图用密钥的权限直接映射到操作——结果密钥一过期，整个权限失效，运维直接炸锅。

2.3 密钥与RBAC结合的典型场景

实际场景里，最常见的几种结合方式：

场景	密钥作用	RBAC作用	典型风险
OpenAPI接口鉴权	校验 + 签名	控制接口级别权限	密钥泄露后权限范围过大
微服务间调用	JWT或mTLS证书	服务角色访问白名单	证书轮换不及时造成断联
数据加密+访问控制	加密密钥解密字段	决定谁能看到解密后的数据	密钥与角色绑定不当造成越权
第三方集成（SaaS）	客户端凭证（Client Credential）	应用角色权限树	同一密钥被多个场景复用

举个例子，我在设计一个SaaS平台的API网关时，每个第三方应用发一个一对密钥（AppKey + AppSecret）。网关校验签名合法后，把AppKey映射到一个「应用角色」上，然后RBAC引擎根据这个角色去查允许访问的API端点。密钥只负责「你是谁」，不负责「你能去哪儿」。

2.4 密钥与RBAC的协作流程（核心图示）

下面这张图把整体结构画出来了。我把它叫做「密钥+RBAC双引擎模型」。

2.5 密钥管理中的避坑指南

结合几个真实案例，我想分享几点注意事项：

• 密钥不要硬编码。我见过Git仓库里直接放着数据库密钥的，一泄露就全完。用密钥管理服务（KMS）或环境变量，别写死在代码里。
• 密钥与角色一一绑定。一个密钥对应一个身份，不要一个密钥对多个用户。否则审计时根本查不清谁干的。
• 定期轮转。我曾经负责的项目里，一个用了两年没换，直到被第三方滥用才发现。现在强制90天自动轮转，配合灰度发布。
• 最小权限原则。给密钥绑定的角色只赋必要权限，别图省事直接给管理员角色。