Stratus Red Team 中 AWS Secrets Manager 批量检索场景的重现问题分析

问题背景

在使用 Stratus Red Team 2.15.0 进行 AWS 安全测试时，发现了一个关于 aws.credential-access.secretsmanager-batch-retrieve-secrets 攻击技术场景的重现问题。该场景模拟攻击者批量检索 Secrets Manager 中的敏感信息，但在重复执行时遇到了障碍。

问题现象

当用户尝试重新触发该攻击场景时，系统报错显示无法创建 Secrets Manager 密钥，原因是同名的密钥已被标记为待删除状态。错误信息明确指出："You can't create this secret because a secret with this name is already scheduled for deletion"。

技术分析

根本原因

1. 密钥命名机制：当前实现使用固定模式的密钥名称（如 secret-1, secret-2...），而非随机字符串
2. AWS Secrets Manager 的删除机制：AWS 对密钥删除有保护期，即使设置了立即删除（recovery_window_in_days=0），实际操作中仍可能有短暂延迟

现有解决方案

项目代码中已通过 Terraform 设置了 recovery_window_in_days = 0，理论上应该立即删除密钥。但在实际环境中，特别是在快速连续执行场景时，AWS API 可能存在处理延迟。

解决方案验证

经过验证，正确的操作流程应该是：

1. 使用 stratus detonate 触发场景
2. 使用 stratus cleanup 进行清理
3. 等待约10秒后再重新触发

这种操作方式能够成功避免密钥命名冲突问题。而手动清理 AWS 控制台中的密钥可能会导致状态不一致，从而引发问题。

最佳实践建议

对于需要频繁测试此场景的用户，建议：

1. 始终使用 Stratus Red Team 自带的 cleanup 功能，而非手动操作
2. 在连续测试时保持适当的时间间隔（建议10秒以上）
3. 如需更频繁测试，可考虑修改 Terraform 模板使用随机字符串作为密钥名前缀

总结

这个问题展示了云环境安全测试中资源生命周期管理的重要性。通过理解 AWS Secrets Manager 的工作原理和 Stratus Red Team 的实现机制，用户可以更有效地进行连续安全测试。项目维护者也应持续关注此类边界情况，优化工具的健壮性。