在云环境里，AWS上对远程运维访问的控制需要兼顾便捷与安全。本文提出一套针对跳板机的公钥管理一体化方案，覆盖部署、轮换和审计。方案以最小权限、自动化和可追溯为核心，便于满足企业合规与安全运营需求。
设计目标与风险点
目标包括：确保公钥的安全存储、实现一键分发与撤销、制定可审计的轮换流程，以及在出现异常时快速定位责任。主要风险在于密钥泄露、部署不一致与审计盲点，需通过集中管理与事件留痕降低风险。
核心组件与角色
- KMS：用于加密静态存储的公钥和轮换凭证。
- Secrets Manager / SSM Parameter Store：作为公钥或元数据的安全存储。
- SSM（Systems Manager）：用于将公钥分发到跳板机的authorized_keys，支持Run Command与Session Manager。
- Lambda：实现自动化轮换、校验与回滚逻辑。
- CloudTrail与CloudWatch：用于审计事件和告警。
- IAM：实现最小权限策略与角色分离。
工作流概览
1）密钥的安全存储与元数据管理
将所有运维用户的公钥以加密形式保存在Secrets Manager或SSM的SecureString中，使用专用的KMS密钥加密。每个公钥项附带元数据（所属人、有效期、指派机器标签），便于后续查询和审计。
2）自动化部署与撤销
通过SSM的Run Command或Document，读取加密的公钥并写入目标跳板机的~/.ssh/authorized_keys。部署流程由CI/CD或EventBridge触发，并记录每次操作的执行ID与返回值。撤销时同样调用SSM命令从authorized_keys移除指定公钥，支持回滚机制。
3）周期性轮换与验证
定义轮换策略（例如90天），由Lambda或Secrets Manager的自定义轮换器自动生成新的密钥对并替换云端存储和目标主机，同时保留旧密钥的审计记录与短期回退窗口。替换后执行自动化验证脚本，确保SSH登录正常。
4）审计与异常检测
所有公钥的存取、部署、轮换操作均记录到CloudTrail和CloudWatch Logs，并发送到集中化的SIEM或S3存储。设置基于EventBridge的告警，触发不可预期的快速轮换或人为介入。
实施细节与最佳实践
- 对储存公钥的Secrets使用单独的KMS密钥且启用密钥轮换与密钥策略。
- 限制可以调用SSM分发命令的IAM角色，区分自动化账户与人工运维账户，实施强制MFA。
- 在跳板机上利用文件ACL和临时目录避免凭据被持久化到错误位置，定期扫描authorized_keys文件的一致性。
- 对轮换流程实施金丝雀发布：先在小范围内替换并验证，再全量推广。
- 保存每次部署与轮换的快照（公钥哈希）以便事后审计与还原。
合规与运维流程建议
合规要求通常要求可追溯的操作链和及时的密钥更换证明。建议将轮换凭证和审计事件与变更管理系统挂钩，所有公钥变动必须伴随变更单编号与审批记录。对关键资产上启用更严格的轮换周期和人工审批流程。
常见问题与应对
当发现未知公钥出现在跳板机时，应立即触发紧急响应：通过CloudWatch告警启动自动化脚本撤除该公钥，锁定相关账号，触发后续的取证流程并通知安全团队。
结论
将公钥的部署、轮换与审计整合为一体化流程，可显著提高跳板机访问的安全性与可控性。依靠AWS的KMS、Secrets Manager、SSM、Lambda、CloudTrail与CloudWatch等服务，可以构建自动化、可审计且符合企业合规的运维访问体系。
FAQ
问：若不使用跳板机，改用SSM Session Manager，公钥管理还必要吗？
答：SSM Session Manager可以完全替代基于SSH的跳板机访问，避免公钥分发的复杂性。但若组织已有依赖SSH的工作流，仍需公钥管理；建议逐步迁移到Session Manager以减少密钥管理负担，同时保留审计链路。
问：如何保证轮换过程不会造成运维中断？
答：采用分阶段金丝雀发布、先在非生产或少量主机上验证新公钥，并实现短期回退机制。同时执行部署后自动化验证（登录测试），并在轮换窗口外限制人工影响，能将中断概率降至最低。