2

我在 AWS 中运行了几个微服务，其中一些相互通信，其中一些具有外部客户端或作为外部服务的客户端。

为了实现我的服务，我需要一些秘密（用于签名/验证令牌的 RSA 密钥对、对称密钥、API 密钥等）。我为此使用 AWS SecretsManager，它工作正常，但我现在正在实施对密钥轮换的适当支持，我有一些想法。

  • 我正在使用 AWS SecretsManager，定期（约 5 分钟）获取秘密并在本地缓存它们。
  • 我正在使用 AWS SecretsManager 的版本阶段功能来根据需要引用 AWSCURRENT 和 AWSPREVIOUS 版本。

假设服务 A 需要服务 B 的密钥 K：

  • 假设在开始时，K 具有当前值 K1 和先前值 K0。
  • 服务 A 将始终使用（并在本地缓存）K 的 AWSCURRENT 版本与 B 通信，因此在本例中为 K1
  • 服务 B 将 AWSCURRENT 和 AWSPREVIOUS 版本保留在其本地缓存中并同时接受 [K1, K0]
  • 在轮换 K 时，我首先确保服务 B 使用的密钥被轮换，这样在刷新间隔过去后，服务 B 的所有实例都接受 [K2, K1] 而不是 [K1, K0]。在刷新间隔过去之前，A 的所有实例仍然使用 K1。
  • 当刷新间隔过去时，意味着 B 的所有实例都必须获取 K2，我轮换密钥以进行服务，以便 A 将使用 K1 或 K2，直到刷新间隔结束，然后只使用 K2。
  • 这样就完成了密钥轮换（但如果认为 K1 被泄露，我们可以再次轮换 B 的密钥以推出 K1 并得到 [K3, K2]）。

这是最好的方法还是有其他需要考虑的？

然后，在某些情况下，我有一个在同一服务中使用的对称密钥 J，例如用于加密某些会话的密钥。因此，在对服务 C 的一次请求中，会话使用密钥 J1 加密，然后需要在稍后阶段使用 J1 解密。我有多个 C 服务实例。

这里的问题是，如果相同的秘密用于加密和解密，旋转它会变得更加混乱 - 如果密钥旋转到具有值 J2 并且一个实例已刷新以便它将使用 J2 加密，而另一个实例仍然看不到J2，解密会失败。

我可以在这里看到一些方法：

  1. 用不同的轮换方案分成两个秘密，一次轮换一个，类似于上面。这增加了要处理的额外秘密的开销，具有相同的值（除了它们之间有一段时间轮换）

  2. 让解密在失败时强制刷新秘密：

    • 加密始终使用 AWSCURRENT（J1 或 J2 取决于是否刷新）
    • 解密将尝试 AWSCURRENT 然后 AWSPREVIOUS，如果两者都失败（因为使用 J2 和 [J1, J0] 存储的另一个实例的加密）将请求手动刷新密钥（现在存储 [J2, J1]），然后尝试AWSCURRENT 和 AWSPREVIOUS 再次。

  3. 在密钥窗口中使用三个密钥并始终使用中间的一个进行加密，因为它应该始终位于所有其他实例的窗口中（除非它被旋转了几次，比刷新间隔快）。这增加了复杂性。

还有哪些其他选择？这似乎是一个标准用例，但我仍然努力寻找最佳方法。

编辑 - - - - - - - - -

根据 JoeB 的回答，到目前为止我提出的算法是这样的：假设最初秘密的当前值为 K1，而 PENDING 值为 null。

普通手术

  • 所有服务定期（每 T 秒）查询 SecretsManagerAWSCURRENT和AWSPENDING自定义标签ROTATING并全部接受（如果存在）-> 所有服务接受 [ AWSCURRENT=K1]
  • 所有客户端都使用AWSCURRENT=K1

密钥轮换

  1. 为 PENDING 阶段设置一个新值 K2
  2. 等待 T 秒 -> 现在所有服务都接受 [ AWSCURRENT=K1, AWSPENDING=K2]
  3. 添加ROTATING到 K1 版本 + 移动AWSCURRENT到 K2 版本 +AWSPENDING从 K2 中删除标签（似乎没有标签的原子交换）。直到 T 秒过去，一些客户端将使用 K2 和一些 K1，但所有服务都接受两者
  4. 等待 T 秒 -> 所有服务仍然接受 [ AWSCURRENT=K2, AWSPENDING=K1] 并且所有客户端使用AWSCURRENT=K2
  5. ROTATING从 K1移除舞台。请注意，K1 仍然有AWSPREVIOUS舞台。
  6. T 秒后，所有服务将只接受 [ AWSCURRENT=K2]，K1 有效死亡。

这应该适用于单独的秘密和用于加密和解密的对称秘密。

不幸的是，我不知道如何为此使用内置的旋转机制，因为它需要几个步骤，中间有延迟。一个想法是发明一些自定义步骤并让该setSecret步骤创建一个 CloudWatch cron 事件，该事件将在 T 秒后再次调用该函数，并使用 stepsswapPending和调用它removePending。如果 SecretsManager 可以自动支持这一点，那就太棒了，例如通过支持函数返回一个值，指示应该在 T 秒后调用下一步。

4

1 回答 1

5

对于您的凭据问题，只要服务 B 支持两个活动凭据，您就不必在应用程序中保留当前和以前的凭据。为此，您必须确保在准备好之前不会将凭证标记为 AWSCURRENT。然后应用程序总是获取并使用 AWSCURRENT 凭证。要在旋转 lambda 中执行此操作，您将采取以下步骤：

  1. 将新凭证存储在带有阶段标签 AWSPENDING 的密钥管理器中（如果您在创建密钥时通过了一个阶段，则该密钥未标记为 AWSCURRENT）。还要使用在创建密钥时提供给 lambda 的幂等性令牌，这样就不会在重试时创建重复项。
  2. 获取存储在 AWSPENDING 阶段下的秘密管理器中的秘密，并将其作为凭证添加到服务 B 中。
  3. 验证您是否可以使用 AWSPENDING 凭证登录到服务 B。
  4. 将 AWSPENDING 凭证的阶段更改为 AWSCURRENT。

这些是秘密管理器在创建多用户 RDS 轮换 lambda 时所采取的相同步骤。请务必使用 AWSPENDING 标签，因为 Secrets Manager 对此进行了特殊处理。如果服务 B 不支持两个活动凭据或多个用户共享数据，则可能没有办法做到这一点。请参阅有关此的机密管理器轮换文档。

此外，Secrets Manager 轮换引擎是异步的，并且会在失败后重试（这就是每个 Lambda 步骤必须是幂等的原因）。有一组初始重试（大约 5 次），然后每天进行一些重试。您可以通过异常失败第三步（测试秘密）来利用这一点，直到满足传播条件。或者，您可以将 Lambda 执行时间延长至15 分钟，并休眠适当的时间以等待传播完成。但是， sleep 方法具有不必要地占用资源的缺点。

请记住，只要您删除挂起阶段或将 AWSCURRENT 移动到挂起阶段，轮换引擎就会停止。如果应用程序 B 接受当前和待处理（或当前、待处理和上一个，如果您想更加安全），如果您添加您描述的延迟，上述四个步骤将起作用。您还可以查看AWS Secrets Manager 示例 Lambda，了解如何为数据库轮换操作阶段的示例。

对于您的加密问题，我见过的最佳方法是将加密密钥的标识符与加密数据一起存储。因此，当您使用密钥 J1 加密数据 D1 时，您可以存储或以其他方式传递给下游应用程序，例如秘密 ARN 和应用程序的版本（例如 V）。如果服务 A 在消息 M(...) 中向服务 B 发送加密数据，它将按如下方式工作：

  1. A 获取阶段 AWSCURRENT 的密钥 J1（由 ARN 和版本 V1 标识）。
  2. A 使用密钥 J1 将数据 D1 加密为 E1，并在消息 M1(ANR, V1, E1) 中将其发送给 B。
  3. 后来 J1 轮换到 J2 并且 J2 被标记为 AWSCURRENT。
  4. A 获取阶段 AWSCURRENT（由 ARN 和 V2 标识）的密钥 J2。
  5. A 使用密钥 J2 将数据 D2 加密为 E2 并将其在消息 M2(ANR, V2, E2) 中发送给 B。
  6. B 接收到 M1 并通过指定 ARN、V1 来获取密钥 (J1) 并解密 E1 以获得 D1。
  7. B 接收 M2 并通过指定 ARN、V2 来获取密钥 (J2) 并解密 E2 以获得 D2。

请注意，密钥可以由 A 和 B 缓存。如果要长期存储加密数据，则必须确保在加密数据不再存在或重新加密之前不会删除密钥当前密钥。您还可以通过传递不同的 ARN 来使用多个密钥（而不是版本）。

另一种选择是使用KMS进行加密。服务 A 将发送加密的 KMS 数据密钥而不是密钥标识符以及加密的有效负载。加密后的 KMS 数据密钥可以由 B 通过调用 KMS 来解密，然后使用数据密钥对 payload 进行解密。

于 2019-01-22T23:17:18.940 回答