4. AWS Systems Manager Parameter Store：与 Secrets Manager 对比、标准/高级参数、层次结构
说起 AWS 里的密钥管理，很多人第一个想到的是 Secrets Manager。但我个人习惯先看看 Parameter Store。为什么？因为它免费，而且功能其实不弱。我刚开始接触云安全时，总觉得 Secrets Manager 才是正统，后来在一个成本敏感的项目里，Parameter Store 帮我省了一大笔钱，嗯，从那时起我就认真研究它了。
4.1 Parameter Store 是什么？
说白了，Parameter Store 就是 AWS 的一个集中化参数仓库。它可以存数据库连接串、、配置项，甚至整个 JSON 文件。你想想看，它和 Secrets Manager 都能存敏感信息，但定位完全不同。
| 特性 | AWS Systems Manager Parameter Store | AWS Secrets Manager |
|---|---|---|
| 定价 | 标准参数免费，高级参数 $0.05/参数/月 | 每个 secret $0.40/月，外加 API 调用费 |
| 最大密钥长度 | 标准 4KB，高级 8KB | 64KB |
| 自动轮换 | 不支持（需配合 Lambda） | 内置轮换（RDS、自定义） |
| 层次结构 | 原生支持路径树（如 /prod/db/password） | 不支持层次结构，必须用标签 |
| CloudFormation 集成 | 支持（AWS::SSM::Parameter） | 支持（AWS::SecretsManager::Secret） |
| 访问控制 | 基于 IAM + KMS（高级参数） | 基于 IAM + 资源策略 |
| 跨账户共享 | 通过 Resource Access Manager | 通过资源策略直接共享 |
表格里就能看出关键差异。如果你只需要存一些配置值，且不要求自动轮换，Parameter Store 就是性价比之王。我曾经在一个微服务架构里，用了 200 多个参数来管理不同环境的配置，每个月账单几乎为 0。换成 Secrets Manager 的话，光基础费就 80 美元了。
4.2 标准参数 vs 高级参数
Parameter Store 内部有两种参数类型，很多人一开始没注意，结果踩了坑。我记得有个同事把 存为标准参数，后来发现数据被加密了，但用的是默认的 SSM 托管的 KMS 密钥，而他的 Lambda 角色没有解密权限……嗯，这里要仔细说。
标准参数
- 免费，单参数最大 4KB
- 默认使用 SSM 托管的 KMS 密钥（aws/ssm）加密
- 不支持自动轮换
- 非敏感数据可用纯文本（String 或 StringList）
高级参数
- 每参数每月 $0.05，但支持 8KB 大小
- 必须使用 KMS 客户管理密钥（CMK）
- 支持参数策略（如过期时间、通知事件）
- 适合存密码、令牌等敏感数据
一个小技巧：如果你需要将标准参数升级为高级参数，不能直接改类型。必须新建一个高级参数，然后把旧参数删除。我在一次迁移中漏删了旧参数，结果应用还在读标准参数，新密文根本没用上，排查了半天。
4.3 层次结构：这才是 Parameter Store 的大杀器
Secrets Manager 没有层次路径的概念，你只能用名字来区分。但 Parameter Store 可以像文件系统一样组织参数。举个例子：
/myapp/prod/db/host
/myapp/prod/db/port
/myapp/prod/db/password
/myapp/dev/db/host
/myapp/dev/db/port
/myapp/dev/db/password
有了层次结构，你可以用通配符一次性获取整个子树。比如用 AWS CLI：
aws ssm get-parameters-by-path --path /myapp/prod/ --recursive --with-decryption
这个特性在微服务场景下特别实用。我做过一个项目，每个服务有自己的 /service-a/prod/、/service-b/prod/ 层级，代码里只需要拼一个路径前缀就能拿到所有配置，避免了硬编码。
层次结构的最佳实践
- 用环境做第一级：
/prod/、/staging/、/dev/ - 用服务名做第二级：
/prod/orders/、/prod/auth/ - 用具体配置项做第三级：
/prod/orders/db_url - 别忘了加
WithDecryption=true，否则加密参数返回的是密文
小心权限陷阱：层次结构的参数，IAM policy 可以用 Path 条件限制。比如只允许访问 /prod/* 下的参数。但我遇到过一个问题——标准参数路径写错了，权限给了 /prood/*，结果生产环境怎么都读不到参数，因为在控制台里参数名拼写错误。建议写 IaC 时用代码生成路径，避免手打。
4.4 什么时候用 Parameter Store，什么时候用 Secrets Manager？
我会按这个简单原则判断：
- 存非敏感配置（端口号、域名、feature flag） → Parameter Store 标准参数（免费）
- 存敏感数据但能接受手动轮换或自定义自动化 → Parameter Store 高级参数（便宜）
- 需要自动轮换、跨账户共享、审计事件详情 → Secrets Manager（付费但省心）
我曾经把 RDS 密码存在 Parameter Store 高级参数里，然后写了一个 Lambda 每月轮换一次。虽然能跑，但维护起来比 Secrets Manager 的自动轮换麻烦不少。所以如果预算允许，数据库密码这种东西我还是建议上 Secrets Manager。
4.5 实战避坑指南
我曾经有过一次惨痛经历。当时为了节省成本，把所有密码都放在 Parameter Store 标准参数里，用的是默认加密。结果在审计时发现，所有 EC2 实例的实例角色默认都有 ssm:GetParameters 权限，一个低权限的实例就能读走数据库密码。后来我紧急改成了高级参数，并限制只有特定服务角色的实例才能访问指定路径。
安全基线：
- 敏感数据必须用高级参数 + 客户管理 KMS 密钥
- 对每个参数或路径设置严格的 IAM 条件
- 定期使用 AWS Config 规则检查是否有非加密参数存储了密码（关键字：password、secret、key）
4.6 总结要点
- Parameter Store 免费层非常适合配置管理，层次结构是独一无二的优势
- 标准参数只适合非敏感数据，高级参数才适合密钥
- 与 Secrets Manager 的选择并非二选一，完全可以混用——非敏感用 SSM，敏感用 SM
- 层次路径要规划好，建议从第一天就用 /环境/服务/项目 的格式，否则改起来很痛苦
嗯，这一章内容就这些。下一个章节我们会深入 Parameter Store 的自动化与 CI/CD 集成，看看怎么在 CodePipeline 里安全地注入参数——到时候我会分享一个差点把生产环境搞挂的真实案例。