身份、权限与密钥生命周期治理

现代运维中的身份不仅是员工账号，还包括服务账号、CI/CD 机器人、云角色、Kubernetes ServiceAccount、SSH 密钥、API Token 和证书。只管理“谁能登录服务器”远远不够；需要知道每个身份由谁负责、为什么存在、能访问什么、何时到期、如何轮换，以及离职或泄露时如何立即撤销。

本文从治理和运维落地角度组织，不绑定单一厂商。身份、密钥和加密实现涉及安全边界，生产设计应由安全、平台和业务负责人共同评审。

一、先建立身份分类

资产清单要把身份和资源、负责人、用途、环境、权限、创建与到期时间关联起来。

二、认证和授权分开设计

认证回答“你是谁”，授权回答“你能做什么”。启用 MFA 不能弥补管理员权限过大，RBAC 也不能弥补账号被共享。

推荐原则：

• 人员使用唯一账号，禁止多人共用管理员账号；
• 高风险操作使用抗钓鱼 MFA 和二次确认；
• 权限基于岗位和任务，不基于个人长期积累；
• 生产权限与办公身份之间有清晰边界；
• 服务通过工作负载身份获取权限，避免模拟人员账号；
• 所有授权变更可审计并具备到期时间。

三、最小权限不是一次性项目

最小权限需要持续闭环：

1. 根据任务授予初始权限；
2. 记录实际使用情况；
3. 识别长期未使用或从未使用的权限；
4. 缩减权限并验证业务；
5. 对例外权限设置期限与复核；
6. 岗位变化、项目结束或离职时自动触发回收。

不要把“为了避免报错”作为永久授予管理员权限的理由。可以使用临时提权或按需授权解决紧急任务。

四、Just-in-Time临时授权

JIT 模式允许用户在需要时申请有限时长的权限：

申请人：值班工程师
资源：生产订单数据库只读
原因：调查 INC-2026-041
有效期：60 分钟
审批人：数据库负责人
限制：只读、指定来源设备、禁止导出
到期：自动撤销并生成审计记录

高风险权限可以要求双人审批、工单绑定、受管设备和会话录制。紧急情况下允许 break-glass，但使用后立即告警、复盘并轮换相关凭据。

五、服务账号治理

每个服务账号至少要有：

• 唯一名称和明确负责人；
• 业务用途和调用方；
• 最小权限和资源范围；
• 使用环境，禁止测试凭据直接访问生产；
• 认证方式与凭据来源；
• 轮换、撤销和失效方式；
• 最后使用时间和异常使用告警；
• 下线条件。

禁止多个系统共用同一个数据库账号或 API Token。共享凭据会扩大泄露范围，也无法判断具体调用来源。

六、秘密值的生命周期

秘密值包括密码、Token、私钥、连接串、Webhook 密钥和加密密钥。完整生命周期包含：

1. 创建：使用安全随机源和合适算法；
2. 分发：通过受控通道交付，不在聊天和工单明文发送；
3. 存储：进入专用 Secret Manager、KMS 或受控密码库；
4. 使用：只向授权工作负载短时暴露；
5. 轮换：在不中断业务的情况下更换；
6. 撤销：泄露或下线时立即失效；
7. 销毁：删除副本、缓存和过期版本；
8. 审计：记录谁在何时以什么身份访问。

Base64 只是编码，不是加密。环境变量也可能通过进程信息、崩溃转储和调试页面泄露。

七、动态秘密与短期凭据

动态秘密由系统按请求临时生成，带租约并可自动撤销。例如应用启动后以工作负载身份请求一个有效 30 分钟的数据库账号。优点包括：

• 减少长期静态秘密；
• 泄露窗口更短；
• 每个实例或任务可以独立归因；
• 项目结束或任务完成后自动失效。

动态秘密依赖 Secret Manager 的高可用与时钟准确性。应用应处理续租失败、暂时不可用和缓存过期，不能在取不到秘密时回退到代码中的默认密码。

八、无中断轮换策略

许多轮换失败是因为只替换了服务端密码，应用仍使用旧值。推荐双凭据或版本化流程：

1. 创建新凭据版本 B，旧版本 A 仍有效
2. 将应用切换到 B，观察认证成功率
3. 确认全部实例已刷新
4. 撤销 A
5. 验证旧凭据无法使用
6. 清理缓存和历史副本

证书轮换还要检查信任链、客户端缓存、负载均衡、SNI、双向 TLS 和时间同步。加密密钥轮换可能涉及重新加密，需要区分“新写入使用新密钥”和“旧数据仍可解密”的窗口。

九、SSH访问治理

• 人员使用个人密钥，禁止共享私钥；
• 私钥使用口令或硬件保护；
• 服务端禁用不必要的密码登录和 root 直登；
• 通过堡垒机、证书化 SSH 或短期证书集中授权；
• authorized_keys 纳入资产扫描和定期复核；
• 离职、设备丢失和密钥泄露可以快速撤销；
• 会话、命令和文件传输按合规要求审计；
• 不把生产私钥复制到多个运维人员电脑。

仅更改 SSH 端口不能替代认证、权限、网络访问控制和监控。

十、Kubernetes身份与Secret

Kubernetes 中应注意：

• 每个工作负载使用独立 ServiceAccount；
• 禁止默认向所有 Pod 自动挂载不需要的 Token；
• RBAC 限制命名空间、资源和动作；
• etcd 静态加密与密钥管理要配置并验证；
• Secret 不进入镜像、Git 历史和普通日志；
• 使用外部 Secret Manager 时保护身份交换链路；
• 限制 exec、读取 Secret 和创建特权 Pod 的能力；
• 审计授权拒绝、Token 使用和高风险资源操作。

能够创建 Pod 的用户可能通过挂载 ServiceAccount 或主机路径间接扩大权限，权限评审不能只看是否有 get secrets。

十一、CI/CD凭据

流水线是供应链高价值目标。建议：

• 优先使用 OIDC 或工作负载身份换取短期云凭据；
• 每个环境和项目独立授权；
• Fork、外部 PR 和不受信分支不能获得生产秘密；
• 日志自动掩码不能作为唯一保护，脚本仍不得输出秘密；
• Runner 隔离并禁止普通用户进入高权限执行环境；
• 部署权限与代码合并权限适当分离；
• 每次秘密访问可以归因到流水线、提交和发起人；
• 制品签名私钥使用受控密钥服务或硬件保护。

十二、人员入转离流程

入职

按岗位模板授予最低基础权限，强制 MFA，完成设备登记和安全培训。

转岗

先撤销旧岗位权限，再按新职责授权。不能只叠加新权限。

离职

按统一时间点禁用身份、撤销会话和 Token、回收设备、转移资产所有权，并检查个人持有的共享秘密是否需要轮换。

外包和临时账号必须设置结束日期，不能依赖人工记忆。

十三、定期权限复核

复核报告至少包括：

• 高权限和跨环境账号；
• 90 天未使用身份；
• 没有负责人或负责人已离职的账号；
• 永不过期 Token 与证书；
• 多人共用、无法归因的凭据；
• 权限与岗位模板不一致的例外；
• 即将到期证书和轮换失败；
• break-glass 使用记录。

资源负责人确认“仍需要”时应填写用途和期限，而不是一键全选通过。

十四、泄露响应

发现秘密可能泄露时：

1. 不在公共频道继续复制泄露值；
2. 确定秘密类型、权限、环境和依赖；
3. 立即撤销或轮换，不要只从 Git 删除；
4. 查询访问日志和异常操作，评估影响时间窗；
5. 搜索镜像、日志、制品、备份和 Fork 中的副本；
6. 更新所有合法消费者并验证；
7. 记录根因，补充提交前和流水线扫描；
8. 若涉及数据或客户影响，按事件响应流程升级。

Git 历史中的秘密即使从最新提交删除，也应视为已泄露并轮换。

十五、治理指标

指标用于降低风险，不应用来鼓励无意义的高频轮换或掩盖例外。

十六、常见错误

• 所有人共用一个 root 或数据库账号；
• 启用 MFA 后仍给所有人长期管理员权限；
• 把 Kubernetes Secret 的 Base64 当成加密；
• 轮换只改服务端，不验证所有消费者；
• Token 永不过期且没有最后使用时间；
• CI/CD 日志掩码后就允许脚本输出秘密；
• 离职只禁用邮箱，没有撤销云会话和 SSH 密钥；
• break-glass 账号长期用于日常操作；
• 权限复核只由账号本人确认。

十七、落地检查清单

• [ ] 人员、服务、自动化和紧急身份都有清单与负责人；
• [ ] 高风险访问使用 MFA、临时授权和审计；
• [ ] 服务账号不共享，生产与测试权限隔离；
• [ ] 秘密集中存储，不进入代码、镜像和日志；
• [ ] 轮换支持双版本并验证旧凭据失效；
• [ ] 入转离流程自动触发授权和回收；
• [ ] CI/CD 使用短期凭据并限制不受信代码；
• [ ] 证书、Token 和 SSH 密钥有到期与异常告警；
• [ ] 泄露响应覆盖撤销、调查、消费者更新和复盘。

十八、参考资料

• CISA Zero Trust Maturity Model
• OWASP Secrets Management Cheat Sheet
• Kubernetes Secrets Good Practices