本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
通过在两个现有用户之间交替来轮换 AWS Secrets Manager 密钥
您可以将 AWS Secrets Manager 配置为自动轮换受保护资源的密钥。
本主题中介绍了如何为系统配置轮换,该系统允许您创建两个用户(可以根据需要为其更改密码)并在两个用户之间交替。这样,您可以消除在限制为使用一个用户账户的方案中发生停机的可能性。在这种情况下,您更改的不仅仅是密钥版本中的密码。每个版本还必须捕获用户更改,随每个轮换周期在每个用户之间交替。
如果管理员允许创建第三个“主”用户,并且该用户具有提升的权限以更改前两个用户的密码,我们建议您这样做。这比允许用户具有更改自己的密码的权限提供了更好的安全性。如果以这种方式配置方案,则需要创建第二个密钥以用于更改在第一个密钥中切换的用户的密码。先创建该“主”密钥,以便在配置“用户”密钥时可以引用该密钥。
Secrets Manager 提供模板来实施以下场景,该场景会停用当前凭证,但不会立即删除这些凭证。相反,Secrets Manager 使用暂存标签 AWSPREVIOUS
标记具有这些凭证的密钥版本。这会将这些凭证保留一个额外的轮换周期以作为“上次已知良好的”凭证。如果当前凭证发生问题,Secrets Manager 会保留可用于恢复的凭证。
仅在第二个轮换周期后轮换函数将用户恢复活动状态时,Secrets Manager 才会删除这些凭证,如本主题后面所述。这意味着,如果您希望一组给定的凭证仅在给定的天数内有效,我们建议您将轮换期设置为该天数的一半减 1。这样,就可以完成两个轮换周期,并在指定时间范围内完全弃用凭证。
例如,如果合规性规定的最大凭证生命周期为 90 天,建议将轮换间隔设置为 44 天 (90/2 - 1 = 44)。在第 0 天,Secrets Manager 在轮换中创建新凭证并将其标记为
AWSCURRENT
。在第 44 天,下一个轮换将具有这些凭证的密钥降级为 AWSPREVIOUS
,并且客户端停止使用这些凭证。在第 88 天,下一个轮换从版本中删除所有暂存标签。Secrets Manager 在此时完全弃用版本,使用新密码重复使用数据库上的用户,这会再次启动该周期。
轮换如何使用标签在两个用户之间交替
使用暂存标签允许 Secrets Manager 在两个用户之间来回切换。一个标记为 AWSCURRENT
的用户正在被客户端使用。在触发 Lambda 函数轮换时,轮换过程将向处于非活动状态的第二个用户分配新密码。Secrets Manager 将这些凭证存储在新版本的密钥中。在确认可以使用新密钥版本中的凭证进行访问后,轮换过程将
AWSCURRENT
标签移动到新版本,从而使之成为活动版本。下次触发时,Secrets Manager 的角色反转两个用户账户。
基本示例方案
下面将更详细地介绍此方案:
-
在此方案中,一个应用程序先使用具有单个版本“A”的密钥访问数据库。此 A 版本的密钥附加了标签
AWSCURRENT
并包含前两个用户的凭证。此应用程序通过请求标记为AWSCURRENT
的版本来检索密钥(下图中的步骤 1 和 2)。然后,应用程序使用该密钥版本中的凭证访问数据库(步骤 3)以检索所需的数据(步骤 4)。 -
在第一次轮换期间,该过程创建新的密钥版本“B”(不是新密钥,而是同一密钥的新版本)。该过程克隆 A 版本的所有详细信息,只是将用户名切换到第二个用户并生成新密码。然后,轮换过程使用此新密码更新第二个用户。此密钥版本 B 最初具有轮换过程附加的标签
。因为您将自定义应用程序编程为始终请求AWSPENDING
AWSCURRENT
标签,并且该标签尚未更改,所以此应用程序继续检索并使用原来的 A 版本密钥中的凭证来访问数据库。 -
在测试版本 B 密钥以确保其正常工作后,轮换过程会从 A 版本移动
AWSCURRENT
标签并将标签附加到新的 B 版本的密钥。这还会自动将AWSPREVIOUS
暂存标签移动到具有AWSCURRENT
暂存标签的旧版本。这样,在您需要恢复时,它可以作为“上次已知良好的”版本。可以在一个额外的轮换周期内继续使用密钥的AWSPREVIOUS
版本进行恢复。Secrets Manager 在下一个周期弃用密钥。 -
来自自定义应用程序的下一个请求现在收到密钥的 B 版本,因为 B 现在具有
AWSCURRENT
标签。自定义应用程序使用第二个用户及其新密码访问数据库。
配置两个用户之间的轮换
如果您将密钥用于某个支持的 Amazon RDS 数据库,请按照 实现旋转 Amazon RDS 数据库密钥 中的过程进行操作。
如果要为另一个服务或数据库配置轮换,请按照以下说明创建 Lambda 轮换函数并对其进行自定义:
-
在数据库或服务中创建两个用户。记下您使用的用户名和密码。确保每个用户可以更改其密码。
-
使用第一个用户的凭证创建密钥。
按照 旋转 AWS Secrets Manager 其他数据库或服务的秘密 中的步骤创建一个可自定义的通用 Lambda 轮换函数模板。在转到步骤 7 时,使用以下信息自定义函数。
使用以下逻辑作为编写轮换函数的基础:
-
createSecret 阶段:
-
使用 操作检索 版本的密钥。
-
从
SecretString
字段中提取受保护密钥文本,并将其存储在可使用的文件结构中。 -
查看
username
字段并确定备用用户名。 -
确定具有备用用户名的用户在数据库中是否存在。如果不存在,则必须是首次使用轮换过程。克隆当前用户及其权限。
-
将密钥的结构副本中的
username
条目设置为备用用户名。 -
生成符合受保护资源支持的最大长度和复杂性要求的新密码。
-
将密钥的结构副本中的
password
条目设置为新密码。 -
将结构的已修改副本作为
SecretString
参数在对PutSecretValue
的调用中传递,从而存储在结构中。Secrets Manager 将密钥的新版本标记为AWSPENDING
。
-
-
setSecret 阶段:
-
使用 操作检索 版本的密钥。
-
从
SecretString
字段中提取用户名和密码。 -
向受保护资源的身份验证系统发出命令来将指定用户的密码更改为该值。
-
-
testSecret 阶段:
-
使用 操作检索 版本的密钥。
-
尝试访问受保护资源以尝试使用密钥中的凭证进行访问。
-
-
finishSecret 阶段:
-
将标签
AWSCURRENT
移动到标记有AWSPENDING
的版本。 -
(可选)从密钥的版本中删除
AWSPENDING
标签。
-
在此方案中,用户在密钥轮换期间收到错误的可能性较小。在您配置新版本时,用户继续使用旧版本。仅当 Secrets Manager 测试了新版本之后,您才将标签切换为指向新版本,然后客户端开始使用它。但是,由于在更改密码时,由于某些服务器驻留在具有传播延迟的场中,您应该确保包含合理的延迟(最可能在您测试之前的
setSecret
步骤中),以确保密码有时间传播到所有服务器。此外,对于这种情况,请务必在客户端应用程序中包括合理的重试功能,以帮助减轻这种风险。