3. 零信任中的身份与访问管理：身份即新边界
传统安全模型里，我们习惯在数据中心门口修一堵高墙。墙内的人默认可信，墙外的人一律拦截。但现实是——攻击者一旦进了墙，基本就畅通无阻了。我在2018年帮一家金融客户做渗透测试时，发现他们内网一台打印机的默认密码都没改，攻击者从那里横向移动到了核心数据库。嗯，这就是边界思维的代价。
零信任的核心逻辑很简单：不再信任网络位置，只信任身份。说白了，你的账号、设备、行为才是新边界。每次访问都要重新验证，不管你在办公室还是咖啡厅。
核心转变： 从「你在哪里」→「你是谁」→「你的权限是什么」
3.1 身份即新边界
为什么说身份是新边界？因为网络边界已经模糊了。员工用个人设备、SaaS应用、混合云……你根本画不出一条清晰的网络边界线。但身份是确定的——每个用户、每个服务账号都有一个唯一标识。
我个人习惯把身份分为三类：
- 人类身份：员工、合作伙伴、客户
- 非人类身份：API密钥、服务账号、机器人、IoT设备
- 混合身份：临时凭证、联邦身份（SSO）
在密钥管控场景下，非人类身份往往被忽视。我记得有个客户把所有API密钥都写死在配置文件里，版本控制库一泄露，几百个密钥全裸奔。你想想看，这些密钥背后就是数据库、云存储、支付接口的访问权限——比一个员工的密码值钱多了。
我的建议： 把非人类身份和人类身份放在同一个治理框架下。不要因为「只是服务账号」就降低安全要求。
3.2 多因素认证（MFA）在密钥保护中的作用
MFA不是新概念，但在零信任里它的角色变了。以前MFA主要是防密码泄露，现在MFA是每次访问的准入凭证。尤其是对密钥的访问——谁可以查看密钥？谁可以轮换密钥？谁可以删除密钥？这些操作都应该绑定MFA。
我参与过一个密钥管理平台的设计，当时团队觉得「管理员访问密钥库已经用了VPN，再加MFA太麻烦」。结果呢？VPN凭证被钓鱼，攻击者直接拿到了所有数据库密钥。从那以后，我坚持一个原则：密钥的读操作可以降级，但写操作必须MFA。
| 操作类型 | 示例 | MFA要求 |
|---|---|---|
| 读取密钥 | 查看密钥明文 | 建议MFA（高风险环境强制） |
| 轮换密钥 | 生成新版本 | 强制MFA |
| 删除密钥 | 销毁密钥 | 强制MFA + 审批 |
| 导出密钥 | 下载到本地 | 强制MFA + 审计 |
MFA的实现方式也要选对。短信验证码我基本不推荐——SIM swap攻击太常见了。硬件安全密钥（如YubiKey）或者基于时间的一次性密码（TOTP）更靠谱。我在团队里推的是FIDO2/WebAuthn，既防钓鱼又用户体验好。
避坑指南： 我曾经见过一个团队给所有密钥操作都加了MFA，结果自动化流水线全崩了——因为脚本没法输入验证码。记住：非人类身份的MFA要用设备绑定或短生命周期令牌，别套用人类MFA的方案。
3.3 基于属性的访问控制（ABAC）与密钥策略
传统RBAC（基于角色的访问控制）有个问题：角色太粗。比如「管理员」这个角色，可能包含密钥管理、用户管理、审计日志查看等权限。但实际场景里，你可能只想让某个管理员管理特定环境的密钥。
ABAC就灵活多了。它基于属性做决策：
- 主体属性：用户角色、部门、安全等级
- 资源属性：密钥类型、环境（生产/测试）、敏感度
- 环境属性：访问时间、网络位置、设备状态
- 操作属性：读/写/删除/轮换
举个例子：
策略：允许访问生产环境数据库密钥
条件：
- 主体.角色 == "数据库管理员"
- 主体.部门 == "基础架构"
- 资源.环境 == "production"
- 资源.类型 == "database"
- 环境.时间 between "09:00" and "18:00"
- 环境.设备.合规 == true
你看，这个策略比「管理员可以访问所有密钥」精确多了。我在一个电商项目里就用ABAC实现了「开发人员只能查看测试环境的支付密钥，且只能在工作时间操作」——既保证了安全，又不影响开发效率。
ABAC vs RBAC 对比：
| 维度 | RBAC | ABAC |
|---|---|---|
| 粒度 | 粗（角色级别） | 细（属性级别） |
| 灵活性 | 低（角色变更需审批） | 高（动态属性决策） |
| 管理成本 | 低（角色少） | 中（属性定义需规划） |
| 适用场景 | 组织架构稳定 | 多云、微服务、动态环境 |
3.4 密钥策略设计实战
密钥策略不是写一堆规则就完事了。我总结了一个三步法：
- 分类：按用途、环境、敏感度给密钥打标签
- 映射：把ABAC属性映射到密钥标签上
- 执行：在策略引擎里落地，并持续审计
下面是一个简化的密钥策略示例（伪代码）：
policy "restrict-payment-key-access" {
effect = "deny"
condition {
resource.label.env == "production"
resource.label.type == "payment"
subject.role != "payment-admin"
}
}
policy "auto-rotate-key" {
effect = "rotate"
condition {
resource.label.sensitivity == "high"
resource.age > 30d
}
}
嗯，这里要注意：策略引擎的性能。如果每次密钥访问都实时计算ABAC策略，延迟可能会很高。我建议用策略缓存或者预计算访问矩阵来优化。另外，策略变更要有灰度机制——别一上线就把所有人锁在外面。
我的经验： 刚开始别搞太复杂的ABAC策略。先定义5-10个核心属性，跑通流程后再逐步细化。我见过一个团队一开始定义了50个属性，结果策略引擎跑一次要200毫秒——没人愿意用。
3.5 知识体系总览
下面这张图把本章的核心逻辑串起来了。你可以看到身份、MFA、ABAC和密钥策略之间的关系：
从这张图你可以看到，整个体系是层层递进的。身份定义了「谁可以参与」，MFA确保了「确实是这个人」，ABAC和密钥策略决定了「这个人能做什么」。少了任何一层，密钥管控都会出现盲区。
好了，这一章的内容就到这里。记住：在零信任里，身份不是用户名密码那么简单——它是你整个安全体系的基石。把身份管好了，密钥管控就成功了一半。