应用程序及多环境下AWS访问密钥使用的最佳实践

一、核心最佳实践 #

• 禁止硬编码密钥：绝对不要把访问密钥、秘密密钥写进代码、配置文件或者提交到版本控制系统里，一旦泄露后果严重。
• 遵循最小权限原则：给任何持有密钥的实体只分配完成任务必需的权限，权限越少，泄露后的风险越低。
• 定期轮换密钥：每90天左右轮换一次密钥，哪怕没发现泄露迹象，也能降低长期暴露的安全隐患。
• 启用泄露检测：利用AWS的密钥泄露检测功能，监控密钥是否出现在公开渠道，一旦发现立即失效并轮换。
• 禁用根账户密钥：根账户拥有AWS账号的最高权限，绝对不能用根账户生成的密钥给应用使用，所有操作都要通过IAM实体完成。

二、应用/环境专属密钥的正确获取方式 #

AWS官方更推荐使用临时凭证而非长期密钥，但如果你的场景必须用长期密钥，或者需要适配现有应用，可以参考以下方案：

1. 使用IAM服务角色（首推） #

如果应用运行在AWS自家服务上（比如EC2、Lambda、ECS、EKS等），直接给这些服务绑定IAM角色即可：

• 应用无需手动管理密钥，AWS SDK会自动从服务内部获取临时凭证，凭证还会自动轮换
• 以EC2为例，给实例附加角色后，应用可以通过实例元数据服务获取凭证，执行命令：curl http://169.254.169.254/latest/meta-data/iam/security-credentials/[你的角色名]
• 这种方式完全避免了长期密钥的存储和维护风险，权限也能精准控制。

2. 创建应用专用IAM用户（仅用于AWS外部的应用） #

如果应用运行在AWS之外，必须用长期密钥，可以创建只对应单个应用/环境的IAM用户：

• 比如给生产环境的订单服务创建app-prod-order-service，预发布环境的支付服务创建app-staging-payment-service，每个用户独立隔离
• 给每个用户分配仅满足该应用需求的权限，严格遵循最小权限原则
• 生成密钥后，不要直接存在应用配置里，而是存到安全的密钥管理系统（比如AWS Secrets Manager），应用运行时再从系统中读取。

3. 按环境隔离权限 #

针对生产、预发布、开发等不同环境，必须做权限隔离：

• 为每个环境创建独立的IAM策略和角色/用户，确保开发环境的权限无法访问生产资源，防止误操作或者漏洞扩散
• 比如生产环境的IAM用户只能访问生产区域的S3桶、RDS实例，预发布环境的用户只能访问预发布对应的资源池。

内容的提问来源于stack exchange，提问作者Kristoffer Tølbøll