通过 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 服务，以便在与配置为使用 EKM 服务的 Cloud KMS 密钥对应的 Google Cloud 位置进行请求处理。如需了解详情，请参阅 Compute Engine 区域选择最佳实践和区域和可用区。
- 尽可能使用 Cloud Interconnect：Cloud Interconnect 使用 VPC 网络在 Google Cloud与您的数据中心之间建立高可用性、低延迟的连接，并有助于消除对互联网的依赖。
- 根据需要在距离 EKM 服务最近的区域部署 Google Cloud 网络解决方案：理想情况下，Cloud KMS 密钥应存储在距离 EKM 服务最近的区域。如果有某个Google Cloud 区域比存储 Cloud KMS 密钥的区域更靠近 EKM 服务，请在离 EKM 服务最近的区域使用 Google Cloud 网络解决方案（例如 Cloud VPN）。此选项有助于确保网络流量尽可能使用 Google 基础架构，从而降低对互联网的依赖。
- 当 EKM 流量通过互联网中转时，使用优质层级网络：优质层级会尽可能使用 Google 的基础架构通过互联网路由流量，以提高可靠性并缩短延迟时间。
启用高可用性
EKM 服务中存在单点故障会降低依赖的 Google Cloud 资源的可用性。此类故障点可能存在于 EKM 服务的关键依赖项以及底层计算和网络基础架构中。
如需实现高可用性，请考虑以下事项：
- 跨独立故障域部署副本：部署至少两个 EKM 服务副本。如果您使用的是多区域 Google Cloud位置，请至少在两个不同的地理位置部署 EKM，每个位置至少有两个副本。通过最大限度减少和增强跨副本故障矢量，确保每个副本不仅仅代表 EKM 服务的复制数据平面。请参考以下示例：
- 配置生产更改（包括服务器二进制文件和配置推送），以便一次仅修改一个副本。验证所有更改均在监督下进行，并且有经过测试的回滚可供使用。
- 了解并尽量减少底层基础架构中的跨副本故障模式。例如，确保副本依赖于独立且冗余的电源馈送。
使副本能够抵御单台机器故障：请验证服务的每个副本至少由三台设备、机器或虚拟机主机组成。此配置可让系统在某台机器因更新而停机或在意外停机期间（N+2 预配）处理流量。
限制控制平面问题的影响范围：配置 EKM 服务的控制平面（例如密钥创建或删除），以便在各个副本之间复制配置或数据。这些操作通常更复杂，因为这些操作需要同步并会影响所有副本。问题可能会快速传播，从而影响整个系统。以下是一些可减少问题影响的策略：
- 控制传播速度：默认情况下，确保更改的传播速度尽可能慢，以确保易用性和安全性。在必要时设置例外情况，例如，允许快速传播对密钥的访问权限，以便用户撤消错误。
- 将系统划分为多个分片：如果有多个用户共用 EKM，请将其划分为完全独立的逻辑分片，以便一个分片中的用户触发的问题不会影响另一个分片中的用户。
- 预览更改的影响：请尽可能让用户在应用更改之前查看更改的影响。例如，修改密钥访问权限政策时，EKM 可以确认根据新政策被拒绝的近期请求数量。
- 实现数据 Canary 版：首先仅将数据推送到系统的一小部分。如果子集保持正常运行，则将数据推送到系统的其余部分。
实现全面的健康检查：创建用于衡量整个系统是否正常运行的健康检查。例如，仅验证网络连接的健康检查对解决许多应用级问题没有帮助。理想情况下，健康检查应与实际流量的依赖项密切相关。
设置跨副本故障切换：在 EKM 服务组件中设置负载均衡，以便其使用健康检查，并主动从不健康的副本中耗尽流量，并安全地故障切换到健康的副本。
添加安全机制来管理过载并避免级联故障：系统可能会因各种原因而发生过载。例如，当某些副本变为不健康状态时，重定向到健康副本的流量可能会导致这些副本过载。当请求量超出系统可处理的数量时，系统应尝试安全快速地处理其能处理的请求，同时拒绝多余的流量。
确保可靠的持久性：如果未使用 EKM 服务中的外部密钥加密 Google Cloud 中的数据，则无法恢复这些数据。因此，密钥持久性是 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，如果您的业务需要区域隔离，这种配置可能无法满足您的需求。如果与本地数据中心的连接使用的是互联网，请使用 HA 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 网络中进行负载均衡
对于您部署 EKM 的大多数 EKM 服务，建议在 Google Cloud 中使用负载平衡器与 VPC 网络搭配使用。下图展示了此架构。
在此架构中，Cloud EKM 通过混合连接访问在两个本地数据中心之间复制的 EKM 服务，并在 Google Cloud 区域中使用多层中间负载均衡。如果与本地数据中心的连接使用的是互联网，您可以使用高可用性 VPN 而非 Cloud Interconnect。
内部直通式网络负载平衡器提供单个 IP 地址，资源可以使用该 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。 |