如果您启用 Cloud External Key Manager (Cloud EKM) 的 Cloud Key Management Service (Cloud KMS)，则可以使用您通过外部密钥管理合作伙伴管理的密钥来帮助保护Google Cloud中的数据。本文档介绍了 Google Cloud 客户如何通过 Cloud KMS 和 Cloud EKM 部署高可用性外部密钥管理器 (EKM) 服务。
将 Cloud EKM 与 EKM 服务搭配使用时，需要在云工作负载可靠性和数据保护控制措施之间进行明确的风险权衡。使用云外的加密密钥加密云中的静态数据会增加新的故障风险，可能会导致 Google Cloud 服务数据无法访问。为应对这些风险，您必须将高可用性和容错能力纳入 Cloud EKM 架构。
概览
借助 Cloud EKM，您可以使用保留在 Google Cloud 之外的密钥材料来控制对存储在支持的 Google Cloud服务中的数据的访问权限。Cloud EKM 密钥是客户管理的加密密钥 (CMEK)。借助 Cloud EKM，您可以创建和管理使用 EXTERNAL 和 EXTERNAL_VPC 保护级别的 Cloud KMS 密钥资源。启用 Cloud EKM 后，每个加密操作请求都会导致对外部密钥执行加密操作。初始请求操作的成功与否在很大程度上取决于对外部密钥的加密操作的结果。
Cloud KMS 使用与外部密钥管理系统集成的专用 API 对外部密钥请求操作。本文档将提供此 API 的服务称为 EKM 服务。
如果 EKM 服务变得不可用，则集成 Google Cloud 服务的读取和写入数据平面操作可能会失败。这些故障的显示方式与依赖的 Cloud KMS 密钥处于不可用状态（例如已停用）时的故障类似。错误消息会说明错误来源以及应对措施。此外，Cloud KMS 数据访问审核日志还包含这些错误消息的记录以及描述性错误类型。如需了解详情，请参阅 Cloud EKM 错误参考。
Cloud EKM 架构的最佳实践
Google 的《站点可靠性工程》一书介绍了有助于指导可靠系统开发和维护的最佳实践。本部分将介绍在 EKM 服务与 Google Cloud集成时，如何应用这些实践。以下最佳实践适用于 Cloud EKM 参考架构：
- 配置低延迟、可靠的网络连接
- 启用高可用性
- 快速检测和缓解故障
配置低延迟、可靠的网络连接
Cloud KMS 使用虚拟私有云 (VPC) 网络或互联网连接到 EKM 服务。VPC 解决方案通常使用混合连接在本地数据中心托管 EKM 服务。Google Cloud 与数据中心之间的连接必须快速可靠。使用互联网时，您需要稳定、不间断的可访问性以及快速可靠的 DNS 解析。从 Google Cloud的角度来看，任何中断都可能导致 EKM 服务不可用，并可能无法访问受 EKM 保护的数据。
当 Google Cloud 服务的数据平面与 EKM 服务通信时，每个 EKM 服务绑定调用的超时时间都是固定的（150 毫秒）。超时时间是从 Cloud KMS 密钥的 Google Cloud 位置的 Cloud KMS 服务开始计时的。如果Google Cloud 位置是多区域，则超时时间从 Cloud KMS 接收请求的区域开始计算，该区域通常是发生受 CMEK 保护的数据资源操作的区域。此超时时间足以让 EKM 服务处理来自附近Google Cloud 区域的请求。
此超时有助于防止依赖外部密钥的下游服务发生级联故障。通常可能会导致更高级别应用出现不良用户体验的尾部延迟时间问题，实际上可能会表现为对外部密钥的访问失败，从而导致更高级别的逻辑操作失败。
如需最大限度地缩短延迟时间并创建可靠的网络，请考虑以下事项：
- 尽可能缩短与 Cloud KMS 之间的往返通信延迟时间：将 EKM 服务配置为尽可能在地理位置上靠近 Google Cloud 位置（与配置为使用 EKM 服务的 Cloud KMS 密钥相对应）的位置提供服务。如需了解详情，请参阅 Compute Engine 区域选择最佳实践和区域和可用区。
- 尽可能使用 Cloud Interconnect： Cloud Interconnect 使用 VPC 网络在 Google Cloud和您的数据中心之间创建高可用性、低延迟的连接，有助于消除对互联网的依赖。
- 在最接近 EKM 服务的区域中部署 Google Cloud 网络解决方案（如有必要）：理想情况下，Cloud KMS 密钥应存储在最接近 EKM 服务的区域中。如果存在比 Cloud KMS 密钥所在区域更靠近 EKM 服务的Google Cloud 区域，请在最靠近 EKM 服务的区域中使用 Google Cloud 网络解决方案，例如 Cloud VPN。此选项有助于确保网络流量尽可能使用 Google 基础设施，从而减少对互联网的依赖。
- 当 EKM 流量通过互联网传输时，使用高级层级网络： 高级层级尽可能使用 Google 的基础设施通过互联网路由流量，以提高可靠性并缩短延迟时间。
- 使用适当的客户端截止时间：如果您直接调用 Cloud KMS API 来获取 Cloud EKM 密钥，请将客户端截止时间配置为至少 10 秒，以便为外部密钥操作留出足够的时间来完成。
启用高可用性
EKM 服务中存在单点故障会使依赖 Google Cloud 资源的可用性降至单点故障的可用性。此类故障点可能存在于 EKM 服务的关键依赖项以及底层计算和网络基础设施中。
如需启用高可用性，请考虑以下事项：
- 跨独立故障网域部署副本：部署至少两个 EKM 服务副本。如果您使用的是多区域 Google Cloud位置，请在至少两个不同的地理位置部署 EKM，每个位置至少有两个副本。通过最大限度地减少和强化跨副本故障向量，确保每个副本不仅代表 EKM 服务的复制数据平面。请参考以下示例：
- 配置生产环境变更（包括服务器二进制文件和配置推送），以便一次只修改一个副本。验证所有更改是否都在监督下进行，并且随时可以进行经过测试的回滚。
- 了解并最大限度地减少底层基础架构中的跨副本故障模式。例如，确保副本依赖于独立且冗余的电源馈送。
使副本能够应对单台机器中断：验证服务的每个副本是否包含至少三个设备、机器或虚拟机主机。此配置可让系统在某台机器因更新而停机或发生意外中断时继续提供流量服务（N+2 预配）。
限制控制平面问题的受影响范围：配置 EKM 服务的控制平面（例如密钥创建或删除），以在副本之间复制配置或数据。这些操作通常更复杂，因为它们需要同步并会影响所有副本。问题可能会迅速传播，影响整个系统。以下是一些可用于减少问题影响的策略：
- 控制传播速度：默认情况下，确保更改的传播速度尽可能慢，但要保证可用性和安全性。在必要时设置例外情况，例如，允许快速传播对密钥的访问权限，以便用户撤消错误操作。
- 将系统划分为分片：如果许多用户共享 EKM，请将他们划分为完全独立的逻辑分片，以便一个分片中由用户触发的问题不会影响另一个分片中的用户。
- 预览更改效果：如果可能，请让用户在应用更改之前查看更改效果。例如，在修改密钥访问权限政策时，EKM 可以确认在新政策下最近有多少请求会被拒绝。
- 实现数据金丝雀测试：首先仅将数据推送到系统的一小部分。如果子集保持健康状态，则将数据推送到系统的其余部分。
实现全面的健康检查：创建可衡量整个系统是否正常运行的健康检查。例如，仅验证网络连接的健康检查无法帮助解决许多应用级问题。理想情况下，健康检查应与实际流量的依赖项密切相关。
设置副本之间的故障切换：在 EKM 服务组件中设置负载均衡，使其能够使用健康检查，并主动从健康状况不佳的副本中耗尽流量，安全地故障切换到健康状况良好的副本。
纳入安全机制，以管理过载并避免级联故障：系统可能会因各种原因而过载。例如，当某些副本健康状况不佳时，重定向到健康副本的流量可能会使这些副本过载。当系统面临的请求超出其可处理的范围时，应尝试安全快速地处理可处理的请求，同时拒绝过多的流量。
确保提供可靠的持久性保证： Google Cloud 中通过 EKM 服务使用外部密钥加密的数据在没有外部密钥的情况下无法恢复。因此，密钥持久性是 EKM 服务的一项核心设计要求。配置 EKM 服务，以在多个实体位置安全地备份冗余的密钥材料副本。为高价值密钥配置额外的保护措施，例如离线备份。 确保您的删除机制允许在发生意外和出现 bug 时进行恢复。
快速检测和缓解故障
EKM 服务每中断一分钟，依赖的 Google Cloud资源可能就会无法访问，这可能会进一步增加基础架构的其他依赖组件发生级联故障的可能性。
为了快速检测和缓解故障，请考虑以下事项：
- 配置 EKM 服务以报告指示可靠性威胁事件的指标：设置响应错误率和响应延迟时间等指标，以便快速发现问题。
- 建立运营实践，以便及时通知和缓解突发事件：通过跟踪平均检测时间 (MTTD) 和平均恢复时间 (MTTR) 指标来量化运营实践的有效性，并定义通过这些指标衡量的目标。利用这些指标，您可以发现当前流程和系统中的模式和不足之处，以便快速应对突发事件。
Cloud EKM 参考架构
以下架构介绍了使用Google Cloud 网络和负载均衡产品部署 EKM 服务的一些方法。
通过 Cloud VPN 或 Cloud Interconnect 进行直接连接
如果您在Google Cloud 上运行高吞吐量应用，并且 EKM 服务在单个数据中心内运行，建议在 Google Cloud 与本地数据中心之间建立直接连接。下图展示了此架构。
在此架构中，Cloud EKM 通过区域中的混合连接访问位于本地数据中心的 EKM 服务，而 Google Cloud中没有任何中间负载均衡。
如果可能，请使用单区域应用的 99.9% 可用性配置部署 Cloud EKM 到 EKM 服务连接。99.99% 可用性配置要求在多个 Google Cloud区域中使用 Cloud Interconnect，如果您的业务需要区域隔离，则可能无法满足您的需求。如果与本地数据中心的连接使用互联网，请使用高可用性 VPN，而不是 Cloud Interconnect。
此架构的主要优势在于 Google Cloud中没有中间跳数，从而减少了延迟和潜在的瓶颈。如果您希望在 EKM 服务托管在多个数据中心时设置直接连接，则必须在所有数据中心内配置使用相同（任播）IP 地址的负载均衡器。如果您使用此配置，则数据中心之间的负载平衡和故障切换仅限于路由可用性。
如果您设置了 VPC 网络，则通过 VPC 网络访问的外部密钥必须使用 Cloud KMS 中的区域位置。密钥不能使用多区域位置。如需了解详情，请参阅外部密钥管理器和区域。
Google Cloud中来自互联网的负载均衡
如果您需要多区域 Cloud KMS 密钥，建议在 Google Cloud 中使用具有互联网连接的负载均衡器。下图展示了此架构。
在此架构中，EKM 在两个本地站点中都有副本。每个后端在 Google Cloud 中都使用混合连接网络端点组 (NEG) 表示。此部署使用外部代理网络负载均衡器将流量直接转发到其中一个副本。与其他依赖于 VPC 网络的方法不同，外部代理网络负载均衡器具有外部 IP 地址，并且流量来自互联网。
每个混合连接 NEG 可能包含多个 IP 地址，这使得外部代理网络负载均衡器能够直接将流量均衡分配到 EKM 服务的实例。无需在本地数据中心内添加额外的负载均衡器。
外部代理网络负载均衡器不与特定区域相关联。它可以将传入流量导向最近的健康区域，因此非常适合多区域 Cloud KMS 密钥。不过，负载均衡器不允许配置主后端和故障切换后端。流量均匀分配到区域中的多个后端。
在 Google Cloud的 VPC 网络中进行负载均衡
建议在 Google Cloud 中使用负载均衡器，以便为部署 EKM 的大多数 EKM 服务提供支持。下图展示了此架构。
在此架构中，Cloud EKM 通过 Google Cloud 区域中具有多层中间负载均衡的混合连接来访问在两个本地数据中心之间复制的 EKM 服务。如果与本地数据中心的连接使用互联网，则可以使用高可用性 VPN 而不是 Cloud Interconnect。
内部直通式网络负载均衡器提供了一个 IP 地址，资源可以使用该地址通过虚拟网络发送流量。负载均衡器会根据后端的健康状况故障转移到备用数据中心。
虚拟机实例组是代理流量所必需的，因为内部负载均衡器无法将流量直接路由到本地后端。您可以部署负载均衡器代理，以在实例组中运行 Cloud Marketplace 中的 Nginx Docker 映像。您可以将 Nginx 用作 TCP 负载均衡器。
由于此方法使用 Google Cloud中的负载均衡器，因此您不需要本地负载均衡器。 Google Cloud 负载均衡器可以直接连接到 EKM 服务的实例，并在这些实例之间均衡负载。消除本地负载均衡器可简化配置，但会降低 EKM 服务提供的灵活性。例如，如果某个 EKM 实例返回错误，本地 L7 负载均衡器可以自动重试请求。
如果您设置了 VPC 网络，则通过 VPC 网络访问的外部密钥必须使用 Cloud KMS 中的区域位置。密钥不能使用多区域位置。如需了解详情，请参阅外部密钥管理器和区域。
参考架构比较
下表比较了 Cloud EKM 的参考架构选项。该表还包含一个列，用于说明合作伙伴管理的 EKM 架构。在此方案中，合作伙伴负责部署和管理 EKM，并以服务的形式向客户提供 EKM。
| 选项 | 直接连接 | 从互联网进行负载均衡 | 在 VPC 网络中进行负载均衡 | 由合作伙伴提供的全托管 EKM |
|---|---|---|---|---|
互联网或 VPC 网络 |
VPC |
互联网 |
VPC |
互联网 |
Google Cloud中的负载均衡器 |
否 |
是 |
是 |
否 |
需要本地负载均衡器 |
是 |
否 |
否 |
是（由合作伙伴管理） |
支持多区域 Cloud KMS 位置 |
否 |
是 |
否 |
是 |
建议用于 |
高吞吐量应用，其中 EKM 服务在单个站点中运行。 |
何时需要多区域 Cloud KMS 密钥。 |
大多数 EKM 服务（您可以在其中部署自己的 EKM）。 |
您可以改用合作伙伴的 EKM，而无需部署自己的 EKM。 |