📚 课程目录第1章 RBAC模型概述

一、RBAC 模型概述：定义、发展历史与核心三要素

咱们直接切入正题。RBAC，全称 Role-Based Access Control，基于角色的访问控制。这玩意儿说白了，就是解决“谁在系统里能干什么”这个问题的一种标准化方案。

我做安全审计这些年，看过太多权限混乱的遗留系统。有的系统，权限直接挂在用户身上，几百号人，每个都得单独配。后来人走了，权限没清，成了巨大的安全漏洞。嗯，那时候我就意识到，没有一套好的权限模型，审计就是个无底洞。

RBAC 的核心思想其实很简单：不直接把权限赋给用户，而是把权限赋给“角色”，再把“角色”赋给用户。 你想想看，这跟现实世界是不是一模一样？一个公司里，你是什么“职位”（角色），就有什么样的“权力”（权限）。

  一句话总结： 用户 - 角色 - 权限。用户通过角色间接获得权限。这就是 RBAC 的精髓。

1.1 发展历史：为什么会有 RBAC？

在 RBAC 还没普及之前，主流的访问控制模型主要有两种：

自主访问控制（DAC）： 文件的创建者自己决定谁能访问。比如 Linux 文件系统的 rwx 权限。问题很明显——管理分散，容易误配，大型系统里根本管不过来。
强制访问控制（MAC）： 系统根据安全标签（比如密级）强制控制。多用在军队、政府。太死板，灵活性差，不适合商业环境。

这俩模型都有硬伤。直到 1992 年，David Ferraiolo 和 Richard Kuhn 提出了 RBAC 的概念，后来被 NIST（美国国家标准技术研究院）标准化。我记得当时看到这个模型时，第一反应就是：这不就是企业组织架构的数字化映射吗？

它解决了几个关键痛点：

管理效率： 新增一个人，给他分配“销售员”角色就行，不用逐个配几百个权限。
安全性： 员工离职，移除角色即可，权限回收干净彻底。
合规性： 审计时可以清晰地看到“销售经理”这个角色拥有哪些权限，而不需要去查几千个用户各自的权限列表。

1.2 核心三要素：用户、角色、权限

这是 RBAC 的基石，也是你未来做密钥权限审计的抓手。咱们一个一个拆开看。

1. 用户（User）

用户就是系统操作的主体。可以是人，也可以是服务账户、、甚至是一台机器。在审计中，我们关注的是：这个用户是谁？ 他当前关联了哪些角色？

避坑指南： 我曾经审计过一个项目，发现他们给一个运维脚本的服务账户赋予了“超级管理员”角色。这太危险了。服务账户应该遵循最小权限原则，只给必要的角色。

2. 角色（Role）

角色是 RBAC 的灵魂。它是权限的集合，也是用户与权限之间的桥梁。一个角色通常对应一个岗位或一种职责。比如“订单审核员”、“数据库管理员”、“只读用户”。

设计角色的核心原则是：

职责分离（SoD）： 不能让一个人既有“创建订单”的角色，又有“审核订单”的角色。
最小权限： 角色只包含完成工作所必需的最小权限集合。多一个都不要给。

3. 权限（Permission）

权限就是“能对什么资源做什么操作”。

对象（Object）： 被操作的资源。比如一个文件、一个数据库表、一个 API 接口、一个加密密钥。
操作（Operation）： 对资源的具体行为。比如读取、写入、删除、执行、签名、解密。

在密钥权限审计里，权限通常表现为：能否使用某个 KMS（密钥管理系统）的密钥进行 encrypt、decrypt、sign、verify 操作。

要素	定义	审计关注点
用户（User）	操作主体（人、服务、设备）	用户身份是否唯一？是否激活？关联的角色是否合理？
角色（Role）	权限的容器/职责的抽象	角色定义是否清晰？是否存在角色爆炸？角色间是否有冲突？
权限（Permission）	对资源的操作许可	权限粒度是否合适？是否遵循最小权限？密钥的操作权限是否有滥用？

1.3 三要素在审计中的实际意义

咱们做密钥权限审计，整天跟这三样东西打交道。我给你梳理一下具体的审计场景：

用户 - 角色关联审计： 检查是否有用户被赋予了不合理的角色。比如一个普通开发人员，为什么会有“KMS 密钥管理员”角色？这种通常是误配或权限泛滥。
角色 - 权限关联审计： 检查某个角色是否拥有超出其职责范围的权限。举个例子，“日志查看员”角色如果被赋予了“密钥删除”权限，那一定是设计缺陷。
权限本身审计： 检查密钥的使用权限是否被合理细分。比如你的系统支持对同一个密钥，设置“仅用于加密”和“仅用于解密”的权限吗？如果所有密钥操作都是一个“超级权限”，那风险就太大了。

一个重要提醒： 很多人做审计，只看用户和角色的关系，忽略了角色和权限的关系。这是一个常见的盲区。角色本身如果被赋予了过大的权限，那就是一个“特洛伊木马”。你查用户查得再细，也发现不了问题。

1.4 一个简单的 RBAC 权限数据示例

为了方便你理解，我写一个简化版的 RBAC 权限配置。虽然在实际系统（比如 KMS，如 AWS KMS、HashiCorp Vault）里表达方式不同，但逻辑是一致的。

// 定义角色
{
  "roles": [
    {
      "role_name": "kms_encryptor",
      "permissions": [
        {"effect": "Allow", "action": "kms:Encrypt", "resource": "key/xxx"},
        {"effect": "Allow", "action": "kms:GenerateDataKey", "resource": "key/xxx"}
      ]
    },
    {
      "role_name": "kms_auditor",
      "permissions": [
        {"effect": "Allow", "action": "kms:DescribeKey", "resource": "*"},
        {"effect": "Allow", "action": "kms:ListKeys", "resource": "*"}
      ]
    }
  ],
  // 用户与角色关联
  "user_role_assignments": [
    {"user": "alice", "roles": ["kms_encryptor"]},
    {"user": "bob", "roles": ["kms_auditor"]}
  ]
}

看到没？alice 只能加密，不能解密。bob 只能查看，不能操作。这就是最小权限。你在做审计的时候，就是要拿着这样的配置，去跟实际的业务需求核对。

1.5 本章小结

这一章我们先把 RBAC 的骨架搭起来了。你得记住：核心三要素是用户、角色、权限。 角色是中间层，负责解耦。理解了这个，你才能看懂后面更复杂的 RBAC 变种（比如层级 RBAC、约束 RBAC）。