VMware Engine 安全性最佳实践

本文档介绍了推荐用于管理和配置 Google Cloud VMware Engine 的安全性最佳实践，适用于已熟悉 VMware Engine 的用户。如果您是新手，您可以考虑从了解前提条件和 VMware Engine 安全性开始。

VMware Engine 提供安全责任共担模型。受信任的云安全性是通过客户和作为服务提供商的 Google 共同承担责任实现的。遵循这些最佳实践可帮助您节省时间、防止错误并缓解故障点的影响。

VMware Engine 网络

以下各部分介绍了在 Google Cloud 中 VMware Engine 环境。

识别和了解环境的所有流量

VMware Engine 利用 VMware Engine 网络和 VPC 对等互连将从 VMware Engine 私有云网络到 VPC 网络的专用网络连接。来自 Google Cloud 环境中 VPC 的入站流量或来自本地网络的入站流量会遍历 Google 管理的租户单元网络。

使用 VMware Engine 的公共 IP 服务进行互联网数据传输

互联网流量可以使用 VMware Engine 的公共 IP 服务直接进入私有云。互联网流量也可以使用 Google Cloud 上的公共负载均衡器进入。在这种情况下，系统会将流量 就像任何其他入站流量一样请注意，这些方案是互斥的。如果互联网流量需要自定义控制（例如 Google Cloud 环境中的中央实例或服务提供的网址过滤、IPS/IDS 或流量检查），则应通过您的 VPC 网络路由互联网绑定流量。

如果这对您不适用或您已在 我们建议您将外部 IP 地址服务 启动容器此外，我们还建议您使用外部访问规则来拒绝不适用于您的应用的互联网流量模式。

将 VMware Engine NSX-T 中的网关和分布式防火墙上的南北向和东西向防火墙规则分开

在第 1 层逻辑路由器上，在 NSX-T 中配置分布式防火墙 (DFW)，将虚拟的第 2 层网域之间的内部流量进行分段。NSX DFW 旨在处理各分段之间的（内部）东西向网络流量并允许以下述防火墙规则，即允许和拒绝分段中各个实例之间的流量的规则。

为实现精细的网络访问权限控制，请确保对 DFW 应用受限的默认政策，以默认拒绝实例之间的网络流量。使用 DFW 明确允许应用之间以及应用内部服务之间的流量。

配置 NSX 网关防火墙，以控制进入和离开私有云的南北向流量。

NSX 网关防火墙旨在控制南北向流量，建议用于控制边界到其他安全区域的流量等应用场景。如果您需要一致地为整个私有云配置南北向流量，请在第 0 层路由器上配置网关防火墙。如果您需要为每个单独的 NSX-T 分段配置南北向流量，请在第 1 层路由器上配置网关防火墙。

除了 NSX-T 防火墙，建议使用 VPC 防火墙 允许和阻止 VMware Engine 私有云和 VPC 中的工作负载。传入的数据传输至 来自 VMware Engine 工作负载的 Compute Engine 实例 默认受限于仅有意开放的流量。

到管理设备以及 vSphere/vSAN CIDR 范围的出站数据传输应 也使用 VPC 防火墙来阻止 VPC 访问它们仅打开向 传输的传出数据 从受信任的主机和 IP 地址访问管理设备。 请务必注意，管理设备不在 NSX-T 内部 因此，DFW 规则不适用于限制访问权限。

在 NSX-T 中应用零信任安全原则和微细分

使用 NSX-T DFW 对 就像单个虚拟机一样精细这种保护 默认情况下，拒绝的单个虚拟机之间的流量通常也称为 “Micro-segmentation”， 这是一种比传统的防火墙方法更精细的防火墙方法， 第 3 层域之间的防火墙实现。

私有云中所有 VMware Engine vSphere 主机上的 Hypervisor 内核中都会启用 DFW，它可控制位于相同或不同 NSX 分段中的工作负载之间的流量。可通过将虚拟机组织到政策组中来定义允许流量进出虚拟机的防火墙规则，这些政策组可以具有灵活的成员资格条件，例如虚拟机标记或名称一致。

微分段使您能实现具有细粒度流量的网络 控制需要明确允许流量模式的位置。所有网络流都由身份和设备验证流程（而非隐式信任）控制的这一安全概念通常也称为零信任安全性。

从 Cloud Marketplace 门户部署第三方防火墙设备以实现 IPS/IDS 功能

如果您需要高级第 7 层安全，包括 从您网络的其他部分或 NSX-T 网络分段，请考虑部署第三方防火墙 设备。可以将第三方设备部署为 Google Cloud 网络中两个 VPC 之间的多 NIC 设备，也可以部署在与 NSX-T 集成的私有云内。

如需深入了解可用于各种高级安全应用场景（例如 IPS/IDS、DDoS、SSL 分流等）的、具有集中式设备的 VMware Engine 架构，请参阅云架构中心中的“使用集中式设备确保网络安全”文档。

使用 Google Cloud Armor 保护 VMware Engine 上的 Web 服务免受 DDoS 攻击

如果您通过 客户 VPC，我们建议将 VMware Engine 工作负载 混合网络端点组中，并利用 外部 HTTP(S) 负载均衡器。这两种设置都允许您 Google Cloud Armor 适用于面向公众的应用，从而缓解 DDoS 攻击和 SQL 注入或跨站脚本攻击等常见漏洞。

如果您需要使用 Envoy 代理或 Certificate Authority Service 的集成，我们建议您使用 Cloud Service Mesh。在所有其他情况下，我们都建议使用外部 HTTP(S) 负载均衡器。

按照以下任一设置中的说明将 VMware Engine 工作负载添加到混合 NEG 中：

以私密方式连接到 Google Cloud 服务，而无需接入互联网

VMware Engine 私有云工作负载可以使用专用 Google 访问通道来访问 Google Cloud API，例如 Cloud Storage API。我们建议您使用专用 Google 访问通道来访问 Google 服务，而无需通过互联网发送流量，因为这样可以降低出站数据传输费用并缩短延迟时间。如此一来，对于只需要 Google API 访问权限的工作负载，就无需使用通往互联网的网络路径。深入了解专用 Google 访问通道，了解更多技术详情和配置步骤。

同样，需要从服务提供方网络（如 Cloud SQL 或 Memorystore 实例）访问 Google Cloud 资源的 VMware Engine 工作负载应使用 PSA 建立非公开连接。有关详情，请访问 PSA 部分， VMware Engine

加密本地环境与 Google Cloud 之间的通信

VMware Engine 上需要与本地系统通信的工作负载应通过加密通道进行连接。我们建议使用 在本地数据中心与本地数据中心之间传输数据的传输加密方法， Google Cloud本地系统与 Google Cloud 之间的关联 可以通过设置具有 IPsec 隧道的 Cloud VPN 进行加密，也可以 在互连的 VLAN 连接上使用内置的 IPsec。此外，应使用 TLS 在应用组件之间启用应用层加密。

使用 VPC Service Controls 防止数据受到渗漏的危害

建议将 Cloud Storage 存储桶和 BigQuery 数据集等敏感资源放入 VPC Service Controls 边界中，以使用 VPC Service Controls 缓解数据渗漏风险。如果工作负载需要访问边界内的数据，则也需要将它们放置在边界内。具体而言，托管私有云的 Google Cloud 项目必须是 VPC Service Controls 边界的一部分，才能访问受 VPC Service Controls 保护的资源。

您需要在 VPC Service Controls 中配置入站和出站数据传输政策 以允许 VMware Engine 提供方服务 API 进入 边界。有关设置的详细指导，请按照关于将 VPC Service Controls 与 VMware Engine 搭配使用的文档页面进行操作。

VMware Engine IAM 和权限

以下部分介绍 VMware Engine 环境中用户权限的最佳实践。处理 VMware Engine 环境和用于部署私有云的 Google Cloud 项目内的权限非常重要。

使用预定义角色或自定义角色授予访问权限

可以像您习惯利用其他 VMware Engine 环境那样利用 VMware Engine 方法来管理 vSphere 角色和权限。但是，集群部署等活动需要 Identity and Access Management (IAM) 中的权限。下表列出了相关的访问管理器、由它们授予权限的身份源以及它们启用的活动示例。

平台 组件 身份源 配置权限的位置 示例活动
Google Cloud VMware Engine 门户 Cloud Identity Identity and Access Management 例如，私有云部署和取消、集群部署和取消。
VMware Engine vCenter LDAP vCenter 界面中的主机和集群、虚拟机和文件夹、数据存储区 例如，虚拟机创建、虚拟机文件夹创建、数据存储区对象的创建和删除
NSX-T LDAP NSX-T Manager 界面中的“用户和角色” 例如，NSX 分段创建、防火墙配置、负载均衡器配置。
vCenter 虚拟机客机操作系统 例如，Active Directory、LDAP、本地用户 客机操作系统 例如，SSH 或 RDP 登录、文件操作

在 Google Cloud IAM 中，有两个预定义角色具有 VMware Engine 门户的权限：

  • VMware Engine Service Admin - 授予对 Google Cloud 上的 VMware Engine 服务的完整访问权限。
  • VMware Engine Service Viewer - 授予对 Google Cloud 上的 VMware Engine 服务的只读权限。

这些权限与 VMware Engine 门户中的操作和 与 API 或 CLI 中的操作无关。请注意，基本角色还具有管理 VMware Engine 服务（Owner、Editor）或查看服务详情 (Viewer) 的权限。通常建议使用预定义角色而不是基本角色，因为它们可提供更精细的权限。

应使用预定义角色或自定义角色来限制通过 API 或 CLI 以编程方式访问 VMware Engine（使用服务账号），因为它们包含仅适用于 VMware Engine 的更精细权限。如果编程式访问仅用于只需要预定义角色的特定权限子集的任务，则建议创建自定义角色。

在组织的资源层次结构中选择适当的 IAM 角色分配位置。如果您在一个项目中运行所有 VMware Engine 私有云，则只能在项目级分配角色。如果技术或组织要求导致您的私有云位于不同的项目中，请在用于私有云的项目通用的文件夹中定义所需的角色。

只需在 vCenter、NSX-T 或 HCX 内完成的活动不需要 Cloud IAM 权限。只需要在工作中进行操作的员工 这些环境不需要前面列出的 IAM 角色。而是应使用在 vCenter 和 NSX-T 中配置了权限的 LDAP 身份。我们建议仅向有限数量的用户提供 VMware Engine Service Admin 或 VMware Engine Service Viewer 角色，因为这些角色会授予强大的 CloudOwner 用户账号（针对 vCenter）和管理员用户账号（针对 NSX-T）的访问权限。这些用户 账号只能用于初始设置或应急流程。

限制并主动审核管理员访问权限

VMware Engine Service Admin 角色非常强大，仅应分配给需要管理 VMware Engine 私有云及其集群的生命周期的用户。通常，手动添加或删除集群和节点的操作不会频繁发生，这些操作可能会对集群的结算或可用性产生重大影响。仅将此角色分配给您组织中的极少数人。

请务必定期审核分配有 VMware Engine Service Admin 角色的人员（无论该角色是直接在用于 VMware Engine 的项目上分配的，还是在资源层次结构中的父级级层分配的）。此审核应包含其他角色，例如包含 VMware Engine 的相关关键权限的基本 Editor 和 Owner 角色。您可以使用 IAM Roles Recommender 等服务来帮助识别特权过高的角色。

配置 LDAP 或 Active Directory 身份源

应配置支持 LDAP 身份验证的身份提供方（如 Active Directory），以便为 vCenter 和 NSX Manager 启用用户身份验证。建议的做法是使用集中式身份生命周期管理、群组管理、密码管理等。请注意，不支持通过将 vCenter 和 NSX-T 与 Active Directory 直接联接来进行集成式 Windows 身份验证。

轮替内置服务账号的密码

VMware Engine 生成用于访问管理设备的凭据 （例如 vCenter、NSX-T 和 HCX）。建议您 建立轮替默认 vCenter 服务密码的流程 账号 CloudOwner@gve.local 和默认的 NSX-T 服务账号管理员。 两个用户账号都应该仅用于初始配置，并且 应定期轮换紧急程序及其密码（例如， 每 60 天或 90 天）。 同样，定期轮替 通常用于集成第三方工具。轮替服务账号密码的频率越高，作恶方找到密码时该密码仍有效的可能性就越小。

VMware Engine 日志记录和监控

以下部分介绍了虚拟机工作负载和 VMware Engine 基础架构（负责提供工作负载使用的资源）的日志记录和监控最佳实践。

注入 VMware Engine 日志和指标

许多组织都希望在集中的单一管理平台中收集和分析日志。在 Google Cloud 中，Cloud Logging 和 Cloud Monitoring 产品提供了可用于集中管理日志和指标的服务。可以使用独立代理将 VMware Engine 与 Cloud Monitoring 集成。在此配置中，vCenter 会将 ESXi CPU 和内存利用率等指标转发到 Cloud Monitoring。建议根据 vCenter 转发的指标创建信息中心，或者开始使用 GitHub 上发布的一些示例信息中心。

如需收集平台日志，VMware Engine 私有云可以将 Syslog 日志转发到中心化日志聚合器。您可以对 vCenter 和 NSX-T Syslog 消息执行此操作。收集、保留和分析 Syslog 消息 具有重要的安全使用场景，例如基于 管理员用户（或紧急用户）登录时，执行此类操作， 。若要分析 Syslog 消息，需要配置 Syslog 聚合器（如 Fluentd 或 Standalone 代理）以通过中继服务将消息发送到 Cloud Logging。

建议在单个项目的中央信息中心内分析来自 VMware Engine 的日志。如果您的 VMware Engine 环境跨多个项目，则您还需要通过配置日志接收器和监控范围来聚合您的项目。

使用 Cloud Logging 代理进行工作负载虚拟机日志记录

VMware Engine 工作负载虚拟机可以使用 Logging 代理将日志直接发送到 Cloud Logging API。Logging 代理基于 fluentd，并将日志从常见的第三方应用和系统软件流式传输到 Cloud Logging。最佳做法是采用相同的方法来收集和分析 VMware Engine 上的工作负载虚拟机日志以及 Compute Engine 实例和本地资源的日志（如果适用）。在 VMware Engine 上使用 Logging 代理与 Compute Engine 上虚拟机使用的方法一致，这样一来，两个平台上的工作负载都会将其日志发送到 Cloud Logging。

应用 Access Transparency 和 Access Approval 政策的等效功能

虽然 VMware Engine 不支持 Access Transparency Google Cloud 中的 AxT (AxT) 和访问权限审批 (AxA) 功能， 具有可通过请求启用的同等功能的流程。

为确保访问透明度的等效性，您需要考虑多个日志源，包括：

  • vCenter 日志 - 可使用远程 syslog 服务器配置导出。
  • ESXi 日志 - 可使用远程 syslog 配置收集这些日志，但需要向 Google Cloud 提交支持请求来配置 ESXi syslog 转发。

如果您有严格的监管要求，我们会实施相关政策，以提供用于访问权限审批的等效功能。此政策中，标准服务操作需要生成支持服务工单，并提供访问服务运维人员需要访问权限的原因。

Google Cloud Access Approval 例外情况适用。

VMware Engine 加密

以下部分介绍了私有云中存储加密的最佳实践，以及为私有云选择密钥提供方时需要考虑的驱动因素。

使用启用了 vSAN 静态加密的 Google 管理的密钥提供方

静态数据加密是使用 vSAN 软件加密实现的。默认情况下，VMware Engine 会在每个 ESXi 集群上启用 vSAN 加密，并在 vCenter 中配置默认密钥提供方。Google 要求客户在其 ESXi 集群上使 vSAN 加密保持启用状态，如果停用 vSAN 加密，则违反了 VMware Engine 的服务条款。许多组织都要求将静态加密作为其公司政策的一部分，或者根据法规有义务加密数据（例如 NIST、FIPS）。

每个 ESXi 主机都使用标准 AES-256 XTS 模式通过随机生成的不同数据加密密钥 (DEK) 加密数据。DEK 是使用密钥加密密钥 (KEK) 进行加密的，仅以加密形式存储在磁盘上。vCenter 服务器仅存储 KEK 的 ID，而不存储存储 KEK 本身，它存储在 Cloud Key Management Service (KMS) 中。您可以选择保存 KEK 的 Cloud KMS 的位置。

我们建议您使用 Google 管理的默认密钥提供方。但是，如果您需要自行管理 Cloud KMS，则可以使用其中一个受支持的供应商提供的符合第三方 KMIP 1.1 要求的 Cloud KMS。在这两种情况下，密钥提供商都可用于加密静态数据和传输中的 vMotion 流量。

下表重点介绍了默认密钥提供方与第三方 Cloud KMS 集成之间的主要区别：

密钥提供方 优点 缺点
（默认）Google 管理的密钥提供方
  • 简单易用：“开箱即用”部署，无需供应商管理，也没有运营负担
  • Google 的端到端支持
  • 能够以最简单的方法轮替 DEK/KEK 是关键要求
  • 无需支付额外费用
  • 内置可用区冗余，可实现高可用性
  • 不能自带密钥材料 (BYOK)
  • KEK 在 Google 基础架构中进行存储和管理。不支持外部密钥管理器 (EKM)。
第三方 Cloud KMS 密钥提供方
  • 完全控制加密数据和加密密钥
  • 硬件支持的密钥可以存储在 HSM 设备中
  • 复杂程度和运营开销更高
  • 费用增加
  • 延迟时间可能更长，尤其是在 SaaS KMS 的情况下
  • 可用性可能会降低

请注意，不建议同时启用虚拟机级加密和 vSAN 数据存储区加密，因为加密虚拟机的重复信息删除效率接近零。

根据组织的标准自动轮替加密密钥

您负责使用 VMware Engine vSphere 进行 KEK 轮替。 默认密钥提供方和外部 Cloud KMS 都是如此。可以从 vCenter 或其 API 启动 KEK 轮替。请考虑根据组织的要求自动执行 KEK 轮替。您可以在 GitHub 上找到示例 PowerCLI 脚本。

VMware Engine 备份和灾难恢复

请务必保护您的数据免受威胁（例如勒索软件、损坏和人为错误）。此外，业务关键型应用依赖于几乎随时可用的数据，因此您几乎没有时间在服务突然中断时恢复数据。本部分并未完整介绍在有效设计备份和灾难恢复策略以确保数据安全且可用时涉及的备份和灾难恢复的所有方面，但包含为您的 VMware Engine 环境选择正确策略时需要考虑的关键因素。

使用备份和灾难恢复服务备份工作负载

借助备份和灾难恢复服务，Google Cloud 提供了一个集中管理的内置备份解决方案，该方案可用于各种使用场景，包括用于备份 Compute Engine 和 Google Cloud VMware Engine 上的工作负载。备份和灾难恢复服务是 Google 推荐用于备份工作负载的单一解决方案，因为它提供了诸多优势，例如广泛的工作负载支持、节省空间、永久增量备份和灵活的存储方案。

Google Cloud VMware Engine 还支持使用基于代理的第三方备份解决方案。如果您已有第三方备份产品的许可，则可能会首选这些解决方案。此类工具的前提条件如下：

  • 它们提供应用级备份
  • 它们经过应用供应商的认证
  • 它们经过 VMware Engine for vSAN 的认证
  • 它们支持 VMware Engine vStorage API for Data Protection (VADP) 协议标准或进行应用级备份

无论您选择哪种备份解决方案，我们都建议您使用经济实惠的 Cloud Storage 存储方案来长期保留备份。Cloud Storage 是一种高度耐用且经济实惠的对象存储服务。可以将 Cloud Storage 存储桶配置为自动在多个区域中复制存储对象，这非常适合多区域 Cloud 拓扑。

Cloud Storage 还非常适合长期归档，因为它提供了生命周期政策，可在存储对象生命周期超过预定义值时自动将其移动到其他存储层级。如果需要经济实惠的备份存储位置以及中高 RPO（特别是当成本是驱动因素时），就可使用此方案。

或者，您也可以选择 vSAN 存储来将 RPO 降至最低。如果可接受较高的备份存储费用且 Cloud Storage 无法满足 RPO 要求，请使用此存储方案。如需长期归档，请避免使用此方案，因为存在以下风险：VMware Engine 集群大小会受到存储空间的限制。

使用备份和灾难恢复服务实现灾难恢复

我们建议您使用备份和灾难恢复服务在 VMware Engine 上恢复应用。为防止生产工作负载在区域内的单个可用区发生服务中断，建议在该区域的次要可用区中部署和运行私有云，前提是 VMware Engine 在多个可用区中可用。如果情况并非如此，则建议在次要区域中恢复应用。

除了 Google Cloud 备份和灾难恢复之外，VMware Engine 还与其他灾难恢复方案（例如 VMware Engine SRM 和 Zerto）兼容。VMware Engine SRM 和 Zerto 都依赖于 vSphere Replication 进行灾难恢复，在这种情况下，通常支持较低的 RPO 目标。如果您的 RPO 目标是数分钟而不是数小时，请考虑使用基于 vSphere Replication 的灾难恢复解决方案。

核对清单摘要

以下核对清单总结了使用 VMware Engine 时的安全性最佳实践。

任务 主题
VMware Engine 网络
VMware Engine IAM 和权限
VMware Engine 日志记录和监控
VMware Engine 加密
VMware Engine 备份和灾难恢复

后续步骤