3. 访问控制与身份认证：RBAC模型、ABAC模型、多因素认证、Kerberos协议简介
访问控制和身份认证，说白了就是解决两个问题：你是谁，以及你能干什么。在存储系统里，这两个问题尤其敏感——数据一旦放出去，想收回来可就难了。
我这些年参与过的存储项目，几乎每个都在访问控制上栽过跟头。有的是权限配得太粗，运维人员不小心删了生产库；有的是认证太弱，被内部人员钻了空子。所以这一章，咱们把几个核心模型和协议掰开揉碎讲清楚。
3.1 RBAC模型：基于角色的访问控制
RBAC（Role-Based Access Control）是目前最普及的模型。它的核心思想很简单：用户不直接拥有权限，而是通过角色来获得权限。
举个例子。你是一家公司的存储管理员，手下有备份员、审计员、普通用户。如果每个人单独配权限，1000个用户就得配1000次。但用RBAC，你只需要定义三个角色：
- 备份员：可以读取所有卷、执行备份命令
- 审计员：可以查看日志、不能修改数据
- 普通用户：只能访问自己的目录
然后把人往角色里一扔，完事。维护成本直线下降。
核心三要素：用户（User）、角色（Role）、权限（Permission）。关系是：用户→角色→权限。
我在项目中遇到过一个问题：某团队给所有DBA配了同一个角色，结果有人误操作删了表，追责时发现根本分不清是谁干的。所以后来我强制要求：每个用户必须有独立账号，角色只控制权限范围，不掩盖操作痕迹。
RBAC的优缺点
| 优点 | 缺点 |
|---|---|
| 管理简单，适合组织架构清晰的企业 | 角色爆炸——业务复杂时角色数量失控 |
| 权限继承清晰，审计方便 | 细粒度控制不足，比如“只允许读上午9点到下午5点的数据”做不到 |
| 大多数存储系统原生支持（如Ceph、NetApp） | 静态模型，无法根据上下文动态调整 |
我的建议：如果你的组织层级稳定、角色不超过20个，RBAC是最佳选择。别贪多，角色一多，管理成本反而上去了。
3.2 ABAC模型：基于属性的访问控制
ABAC（Attribute-Based Access Control）比RBAC灵活得多。它不看角色，而是看属性。属性可以是用户的（部门、职级）、资源的（机密等级、创建时间）、环境的（访问时间、IP地址）。
你想想看，如果需求是“只有财务部的员工，在工作时间（9:00-18:00），才能访问财务报表”。用RBAC你得专门建一个“财务部工作时间角色”，但用ABAC，一条策略就够了：
策略示例：
IF 用户.部门 == "财务部"
AND 资源.类型 == "财务报表"
AND 环境.时间 BETWEEN "09:00" AND "18:00"
THEN 允许访问是不是很直观？ABAC的策略引擎会在每次访问时，动态计算这些条件。说白了，它把权限判断变成了一个规则引擎。
我曾经在一个跨国项目里用过ABAC。需求是：欧洲区的员工只能访问欧洲节点的数据，亚太区的只能访问亚太节点的。如果用RBAC，得为每个区域建角色，员工调岗还得改角色。ABAC一条规则搞定：IF 用户.区域 == 资源.区域 THEN 允许。维护量少了一个数量级。
注意：ABAC虽好，但策略引擎的性能开销不小。每次访问都要计算属性、匹配规则，高并发场景下可能成为瓶颈。我见过一个案例，因为策略规则写了200多条，每次文件打开都要等几百毫秒——用户直接炸了。
RBAC vs ABAC 怎么选？
| 场景 | 推荐模型 |
|---|---|
| 组织架构固定，权限需求简单 | RBAC |
| 需要根据时间、地点、设备等动态条件控制 | ABAC |
| 合规要求严格，需要细粒度审计 | ABAC + RBAC 混合 |
| 存储系统性能敏感，延迟要求高 | RBAC（ABAC需缓存优化） |
3.3 多因素认证：别只靠密码
密码这东西，我做了这么多年存储，越来越觉得它靠不住。弱口令、撞库、钓鱼……你永远不知道你的用户会把密码贴在显示器上。
多因素认证（MFA）的核心思路是：至少使用两种不同类型的证据来证明身份。三类常见因素：
- 你知道的：密码、PIN码
- 你拥有的：手机（TOTP）、硬件令牌、智能卡
- 你是什么：指纹、人脸、虹膜
在存储系统里，我最推荐的是密码 + TOTP（基于时间的一次性密码）。成本低、实现简单、安全性提升明显。
避坑指南：我曾经给一个存储管理平台上了MFA，结果忘了给API调用留白名单。结果所有自动化脚本全挂了——因为脚本没法输验证码。记住：MFA要区分交互式登录和程序化访问，API调用建议用证书或Token代替。
3.4 Kerberos协议简介
Kerberos这个名字你可能听过，但未必真正理解它解决了什么问题。说白了，它解决的是在不可信网络里安全证明身份的问题。
想象一下：你登录存储系统，输入密码。如果密码直接在网络里传，被截获就完了。Kerberos的做法是：密码永远不在网络里传输，而是通过一个可信第三方（KDC，密钥分发中心）来颁发“通行证”（Ticket）。
流程大致是这样：
- 用户向KDC的认证服务（AS）发起请求，证明自己知道密码
- AS验证通过后，返回一个TGT（票据授权票据），用用户的密码加密
- 用户拿着TGT，向KDC的票据授权服务（TGS）申请访问某个服务的票据
- TGS验证TGT有效后，颁发一个服务票据，用服务端的密钥加密
- 用户拿着服务票据去访问存储服务，服务端解密验证，放行
整个过程，密码只在第1步本地加密使用，网络里传的都是票据。这就是Kerberos的精髓。
实际经验：Kerberos在Hadoop、Ceph、Active Directory里用得非常多。但配置起来有点麻烦——时钟同步必须做好（误差超过5分钟就会失败），DNS解析也得正确。我遇到过好几次因为NTP没配好，Kerberos认证死活过不去的案例。
3.5 知识体系总览
下面这张图把本章的核心逻辑串起来了。你可以看到：身份认证解决“你是谁”，访问控制解决“你能干什么”，两者缺一不可。
3.6 小结
这一章我们聊了四个核心概念：
- RBAC：简单粗暴，适合组织架构稳定的场景
- ABAC：灵活强大，适合动态、细粒度的控制需求
- 多因素认证：别只靠密码，加一道锁安全翻倍
- Kerberos：密码不传网，票据保平安
嗯，这些理论听起来都不难。但真正落地的时候，坑往往藏在细节里——比如时钟同步、策略性能、API兼容性。后面几章我们会深入到具体存储系统的配置实战，到时候再一一拆解。