1. 权限隔离基础：什么是权限隔离、为什么需要权限隔离、权限隔离的常见模型
各位同学，咱们今天聊的是整个课程的地基——权限隔离。说实话，我见过太多密钥泄露的事故，追根溯源，十有八九是权限没管好。你想想看，如果连谁该拿钥匙、谁不该拿钥匙都分不清，那密钥分发策略就是空中楼阁。
1.1 什么是权限隔离
权限隔离，说白了就是把不同角色的操作边界划清楚。就像公司里，前台能开门禁，但进不了财务室；财务能看账本，但改不了代码。在系统里，我们通过权限模型来定义：谁（主体）能对什么（资源）做什么（操作）。
我个人习惯用一个简单的公式来理解：
权限 = 主体 + 资源 + 操作 + 环境约束举个例子，一个运维工程师（主体）只能在凌晨2点到4点（环境约束）对生产数据库（资源）执行 SELECT 查询（操作）。这就是权限隔离的具象化。
核心要点：权限隔离不是限制人，而是保护系统。把权限切得越细，攻击者拿到一个账号后能造成的破坏就越小。
1.2 为什么需要权限隔离
我在项目中遇到过好几次这样的情况：团队为了图省事，给所有开发人员都配了 root 权限。结果有一次，一个新同事误操作删了生产环境的表……嗯，那天晚上大家都没睡好。
权限隔离的必要性，我总结为三点：
- 最小权限原则：每个角色只给够用的权限，多一分都不要。你想想，一个只读账号为什么要能执行 DROP TABLE？
- 故障隔离：权限切分后，一个人的误操作不会波及整个系统。我曾经见过一个案例，测试环境的权限没隔离好，结果测试脚本直接写进了生产库——还好发现得早。
- 审计追溯：权限清晰了，出了问题才能快速定位是谁、在什么时候、做了什么。没有权限隔离，日志里全是 root 操作，查都查不了。
避坑指南：我曾经接手过一个项目，所有服务共用一个数据库账号。后来被审计发现，整改花了整整两周。记住：权限隔离越早做，成本越低。等项目跑起来再补，那叫重构，不是优化。
1.3 权限隔离的常见模型
业界主流的权限模型有三种：DAC、MAC 和 RBAC。我按自己的理解，用最直白的方式给你讲清楚。
| 模型 | 全称 | 核心思想 | 典型场景 |
|---|---|---|---|
| DAC | 自主访问控制 | 资源所有者自己决定谁能访问 | Linux 文件权限、个人网盘分享 |
| MAC | 强制访问控制 | 系统统一规则，用户不能改 | 军事系统、政府机密系统 |
| RBAC | 基于角色的访问控制 | 权限绑定到角色，用户通过角色获得权限 | 企业管理系统、云平台 IAM |
1.3.1 DAC（自主访问控制）
DAC 是最早出现的模型。它的逻辑很简单：谁创建了文件，谁就有权决定谁能访问它。Linux 里的 chmod 777 就是典型的 DAC。
但这里有个坑——DAC 太灵活了。我记得有一次，一个开发人员为了方便，把自己的 SSH 私钥设成了 644 权限，结果被另一个同事不小心 cat 出来了。这就是 DAC 的弱点：权限控制完全依赖用户的判断力。
我的建议：DAC 适合个人环境或小团队，但在企业级密钥分发场景里，千万别依赖它。你没法保证每个人都懂安全配置。
1.3.2 MAC（强制访问控制）
MAC 和 DAC 正好相反。系统管理员定好规则后，普通用户无权修改。每个主体和资源都被打上安全标签，系统根据标签决定是否允许访问。
举个例子，在 SELinux 里，一个进程即使有 root 权限，如果它的安全上下文不对，照样访问不了某些文件。这就像机场的安检——你就算买了头等舱的票，没有登机牌也过不了闸机。
MAC 的优点是安全等级高，缺点是配置复杂。我在做政府项目时用过 SELinux，说实话，光调策略就花了一周。但一旦配好，确实安心。
1.3.3 RBAC（基于角色的访问控制）
RBAC 是目前最主流的模型，也是咱们这门课的重点。它的核心是引入「角色」这个中间层。用户不再直接和权限挂钩，而是通过角色来获得权限。
你想想看，一个公司有成百上千个员工，如果每个人都要单独配权限，那管理员得累死。但如果你定义好「管理员」「运维」「开发」「审计」这几个角色，把权限绑到角色上，然后把人加到角色里——是不是清晰多了？
# 伪代码示例：RBAC 权限判断
if user.has_role('admin'):
grant_access('all_resources')
elif user.has_role('operator'):
grant_access('production_db', 'read_only')
elif user.has_role('developer'):
grant_access('dev_env', 'full_control')
else:
deny_access()关键点：RBAC 的威力在于「角色继承」和「职责分离」。比如「超级管理员」可以继承「普通管理员」的所有权限，而「审计员」和「操作员」不能是同一个人——这就是防勾结。
1.4 三种模型的对比与选择
为了让你看得更清楚，我画了一张对比图：
从图上你能看出来，三种模型的核心区别在于谁掌握控制权。DAC 是用户自己管，MAC 是系统强制管，RBAC 是通过角色间接管。在密钥分发这个领域，我强烈建议你优先考虑 RBAC——它既不像 DAC 那样松散，又不像 MAC 那样死板。
个人经验：我在设计密钥管理系统时，通常会用 RBAC 作为基础模型，然后在关键操作上叠加 MAC 的强制规则。比如：运维角色可以查看密钥，但导出密钥必须经过审批流程——这就是 RBAC + MAC 的混合策略。
1.5 本章小结
权限隔离不是什么高深的理论，它就是给系统划好边界，让每个人只在自己的地盘里干活。DAC 太随意，MAC 太死板，RBAC 刚刚好——这也是为什么大多数企业级系统都选 RBAC 的原因。
记住一句话：权限隔离做得好，密钥分发就成功了一半。后面的章节里，我们会基于 RBAC 模型，一步步搭建完整的密钥分发体系。