1、权限管理基础：什么是权限管理、权限管理的目标、常见权限模型概述
各位好，我是老刘。在密钥权限这个领域摸爬滚打了十几年，今天咱们聊聊最基础的东西——权限管理。
你可能觉得，“权限管理”不就是给用户分个角色、打个勾吗？嗯，表面看确实是这样。但我见过太多项目因为权限设计不清晰，最后出大乱子。有一次生产环境密钥被误删，原因就是某个实习生拿到了不該有的管理员权限… 从那天起我就明白，权限管理绝不是随便搞搞的事。
1.1 什么是权限管理？
说白了，权限管理就是一套控制“谁能干什么”的规则。
核心就三个要素：主体（谁）、客体（什么资源）、操作（增删改查）。
- 主体：用户、服务账号、设备等发起请求的实体。
- 客体：文件、数据库、API、密钥等被保护的资源。
- 操作：读取、写入、执行、删除、授权等行为。
我个人的习惯是，每次设计系统前都会先列一张“主体–客体–操作”映射表。你想想看，如果连这个都没理清，后面谈什么安全？
1.2 权限管理的目标
很多新人以为权限管理只是为了“不让坏人进来”。其实不止。我归纳了四个核心目标：
| 目标 | 说明 | 我踩过的坑 |
|---|---|---|
| 机密性 | 未授权用户不能获取敏感信息 | 曾经把生产密钥配到了开发环境配置文件里，差点泄露 |
| 完整性 | 数据不能被未授权方篡改 | 一个运维脚本没加权限检查，导致配置被批量改坏 |
| 可用性 | 授权用户能正常访问资源 | 过度收紧权限导致正常业务崩溃，教训深刻 |
| 可审计性 | 所有操作都可以追溯 | 没有日志，出问题只能靠猜… 后来我逼着团队上了全链路审计 |
1.3 常见权限模型概述
这里我重点讲四种主流模型。你在项目中遇到的大部分场景，都能用它们覆盖。
1.3.1 DAC（自主访问控制）
资源所有者自己决定谁能访问。Linux文件权限就是典型：chmod 755 这种。自由度高，但管理成本高，很容易留下“走后门”的风险。我记得早期一个内部工具用DAC，结果每个员工都能随便改权限，最后变成一锅粥。
1.3.2 MAC（强制访问控制）
系统强制给主体和客体打安全标签，用户不能改。常用于军事、政府系统。比如 SELinux。好处是安全等级高，坏处是配置复杂，真不是一般业务能hold住的。
1.3.3 RBAC（基于角色的访问控制）
这是咱们课程的核心。把权限赋予角色，再把角色赋予用户。灵活性好，管理简单。现在大多数企业系统都在用。我所在的公司从DAC切换到RBAC后，密钥权限管理效率提升了至少3倍。
1.3.4 ABAC（基于属性的访问控制）
根据用户、资源、环境等多维属性动态判断。比如“只允许上班时间来自内网的运维工程师执行重启”。这种模型很强大，但规则引擎复杂，一般配合RBAC使用。
| 模型 | 控制粒度 | 灵活性 | 管理成本 | 适用场景 |
|---|---|---|---|---|
| DAC | 细（按文件） | 高 | 低（初期） | 个人系统、小团队 |
| MAC | 粗（按标签） | 低 | 高 | 强安全领域 |
| RBAC | 中（按角色） | 中 | 中 | 企业应用、密钥管理 |
| ABAC | 细（按属性） | 极高 | 高 | 复杂动态场景 |
下面这张图把权限管理的整体结构画出来了。你可以对照着看，方便理解各个模型的关系。
从这个图能看出来，无论选哪种模型，最终都要围绕那四个目标去落地。我个人建议：大多数场景先用RBAC，它清晰又省力。如果业务实在复杂，再在部分资源上用ABAC补丁。
嗯，基础概念就这些。下节课我们会直接上手搭建一个最简单的RBAC权限结构，到时候你就能感受到“角色”这个东西有多好用了。