VPC 设计的最佳做法与参考架构

本指南介绍了设计 Google Cloud 中的虚拟私有云 (VPC) 时的一些最佳做法和典型企业架构。本指南适用于已经熟悉 Google Cloud 网络概念的云网络架构师和系统架构师。

一般原则和前期步骤

确定决策者、时间安排和前期工作

在进行 VPC 网络设计时,第一步是确定决策者、时间安排和必要的前期工作,从而确保满足利益相关方的要求。

利益相关方可能包括应用所有者、安全架构师、解决方案架构师和运营管理员。利益相关方本身可能会发生变化,具体取决于您是为项目、业务线还是整个组织规划 VPC 网络。

前期工作包括让团队熟悉有关 VPC 网络设计的概念和术语。相关实用文档包括:

提早考虑 VPC 网络设计事宜

在 Google Cloud 中设计组织设置时,提早进行 VPC 网络设计。组织级别的部分设计选择在流程后期无法轻易更改。

因此,在进行任何重要部署之前,请慎重考虑您的 VPC 网络设计选择。 如果不重新创建资源,则无法将资源从一个 VPC 网络重新定位到另一个 VPC 网络。

不同的 VPC 网络配置可能会对路由、规模和安全产生重大影响。因此,慎重规划和深入了解相关注意事项,可以帮助您建立扎实的架构基础,以应对日益增加的工作负载。

力求简单易行

为了确保架构可靠而且易于管理和理解,最好的办法是让 VPC 网络拓扑的设计简单易行。

使用清晰的命名惯例

确保命名惯例简单、直观且一致。这样可以确保管理员和最终用户了解每个资源的用途、所处位置以及与其他资源的区别。

为了简化命名,对于较长的字词可以使用广泛认可的缩写形式。尽量使用熟悉的术语,以便提高可读性。

在制定命名惯例时,请参考以下示例所示的字词:

  • 公司名称:Acme Company:acmeco
  • 业务部门:Human Resources:hr
  • 应用代码:Compensation system:comp
  • 区域代码:northamerica-northeast1:na-ne1,europe-west1:eu-we1
  • 环境代码devtestuatstageprod

在上例中,人力资源部门的薪酬系统开发环境命名为 acmeco-hr-comp-eu-we1-dev

对于其他常用的网络资源,请参考以下格式:

  • VPC 网络
    语法:{company name}-{description(App or BU)-label}-{environment-label}-{seq#}
    示例:acmeco-hr-dev-vpc-1

  • 子网
    语法:{company-name}-{description(App or BU)-label}-{region/zone-label}
    示例:acmeco-hr-na-ne1-dev-subnet

  • 防火墙规则
    语法:{company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
    示例:acmeco-hr-internet-internal-tcp-80-allow-rule

  • IP 路由
    语法:{priority}-{VPC-label}-{tag}-{next hop}
    示例:1000-acmeco-hr-dev-vpc-1-int-gw

地址和子网

使用自定义模式的 VPC 网络

在启动首个项目时,请使用默认网络,即名为 default自动模式 VPC 网络。自动模式的网络会在每个使用一组可预测的 RFC 1918 地址范围的 Google Cloud 区域中自动创建子网和对应的子网路由,其主要 IP 地址范围是 /20 CIDR。default 网络还自动包含一些预先填充的防火墙规则

虽然自动模式的 VPC 网络可以运用在早期探索阶段,但是对于大多数的生产环境,更适合使用自定义模式的 VPC 网络。

出于以下原因,我们建议企业从一开始就使用自定义模式的 VPC 网络:

  • 自定义模式的 VPC 网络更容易集成到现有 IP 地址管理方案中。由于所有自动模式的网络均使用相同的内部 IP 地址范围,因此在连接本地企业网络时,自动模式的 IP 地址范围可能会重叠。
  • 您无法使用 VPC 网络对等互连将两个自动模式的 VPC 网络连接在一起,因为其子网使用相同的主要 IP 范围。
  • 您可以为自定义模式的子网选择唯一的描述性名称,使 VPC 网络更易于理解和维护。
  • 引入新区域后,Google Cloud 会在自动模式的网络中自动创建新子网。自定义模式的 VPC 网络在规划方面更灵活,可以避免地址重叠。

创建自定义模式的 VPC 网络后,您可以删除 default 网络。请注意,您不能删除 VPC 网络,除非您移除了依赖于该网络的所有资源(包括虚拟机实例)。

如需详细了解自动模式与自定义模式的 VPC 网络之间的差异,请参阅 VPC 网络概览

将多个应用组合为数量更少但地址范围更大的子网

通常,有些企业可能会出于各种原因而将自身的网络分成许多很小的地址范围,例如,为了识别或隔离应用或者保持小型广播网域规模。

但是,我们建议您在要运营的区域将同类型的多个应用组合到数量更少、更易于管理但地址范围更大的子网中。

与使用子网掩码的其他网络环境不同,Google Cloud 使用软件定义网络 (SDN) 方法在全球 VPC 网络的所有虚拟机之间实现全网状可达性。子网数量不影响路由行为。

您可以使用服务帐号或网络标记应用特定的路由政策或防火墙规则。Google Cloud 中的身份不仅仅基于子网 IP 地址。

有些 VPC 功能按子网来配置,这些功能包括 Cloud NAT专用 Google 访问通道VPC 流日志别名 IP 地址范围。如果您需要对这些功能进行更精细的控制,请使用其他子网。

单个 VPC 网络和共享 VPC

刚开始时,对具有共同需求的资源使用单个 VPC 网络。

对许多简单的使用场景而言,单个 VPC 网络即可提供您需要的功能,而且比那些更复杂的方案更容易创建、维护和理解。通过将具有共同需求和特征的资源组合到单个 VPC 网络中,您可以建立 VPC 网络的边界,作为排查潜在问题的范围。

如需查看该配置的示例,请参阅单个项目、单个 VPC 网络参考架构。

有些因素可能会导致您创建额外的 VPC 网络,这些因素包括规模、网络安全性、财务因素、运营要求以及身份和访问权限管理 (IAM)。

使用共享 VPC 管理多个工作组

对具有多个团队的组织来说,共享 VPC 可以有效简化单个 VPC 网络在多个工作组之间的架构。最简单的方法是,使用单个共享 VPC 网络部署单个共享 VPC 宿主项目,然后将团队的服务项目附加到每个宿主项目中。

在此配置中,所有网络资源的网络政策和控制都集中在一起,更易于管理。服务项目部门可以配置和管理非网络资源,从而明确划分组织内不同团队的职责。

同时,这些项目中的资源可以通过内部 IP 地址,以更安全而高效的方式实现跨项目边界的相互通信。您可以从中央宿主项目来管理共享网络资源(如子网、路由和防火墙),从而确保各项目执行一致的网络政策。

如需查看该配置的示例,请参阅单个宿主项目、多个服务项目、单个共享 VPC 参考架构。

在子网级别授予网络用户角色

集中式共享 VPC 的管理员可以在子网级别向 IAM 成员授予网络用户 (networkUser) 角色,实现精确的服务-项目授权;或者在宿主项目级别向这些成员授予所有子网的网络用户角色。

在遵循最小权限原则的前提下,我们建议您在子网级别向相关用户、服务帐号或群组授予网络用户角色。

由于子网是区域性的,因此您可以利用这种精确控制为每个服务项目指定在哪些区域部署资源。

利用共享 VPC 架构,您还可以在组织内灵活部署多个共享 VPC 宿主项目。之后,每个共享 VPC 宿主项目可以包含一个或多个共享 VPC 网络。在此配置中,不同环境可以轻松执行不同的政策。

如需了解更多信息,请参阅 IAM 网络角色

如果资源需要多个网络接口,请使用单个宿主项目

如果服务项目需要将资源部署到多个独立的 VPC 网络(例如具有多个网络接口的虚拟机实例),则宿主项目必须包含提供相关服务的所有 VPC 网络。这是因为一个服务项目只能附加到一个宿主项目中。

从服务项目到多个 VPC

如果资源需求超出单个项目的配额,请使用多个宿主项目

如果一个项目的配额无法满足所有 VPC 网络的总体资源需求,请使用具有多个宿主项目的架构并为每个宿主项目使用单个共享 VPC 网络,而不能使用具有多个共享 VPC 网络的单个宿主项目。评估您的规模要求非常重要,因为使用单个宿主项目需要托管项目中有多个 VPC 网络,并且在项目级别强制执行配额。

如需查看该配置的示例,请参阅多个宿主项目、多个服务项目、多个共享 VPC 参考架构。

如果需要为每个 VPC 网络使用单独的管理政策,请使用多个宿主项目

因为每个项目都有自己的配额,所以请为每个 VPC 网络使用单独的共享 VPC 宿主项目扩缩总体资源。由于 IAM 权限也是在项目级别实现的,因此每个 VPC 网络将拥有单独的 IAM 网络和安全管理权限。例如,如果您将两个 VPC 网络(VPC 网络 A 和 VPC 网络 B)部署到同一宿主项目中,则网络管理员 (networkAdmin) 角色将同时适用于这两个 VPC 网络。

决定是否创建多个 VPC 网络

为每个项目创建单个 VPC 网络以将 VPC 资源配额映射到项目

配额是在项目级别应用的默认约束条件,您可以通过 Google Cloud 申请更多配额来提升配额。它们主要用于防止意外资源用量。但是,仍有许多因素可能会导致您申请增加配额。

如果您预计的资源用量可能会超出默认的 VPC 资源配额,我们建议您为每个项目创建单个 VPC 网络。这样可以轻松将项目级别的配额增加情况映射到每一个 VPC 网络,而不是同一项目中的 VPC 网络组合。

限制常应用于 VPC 网络内部,主要用于从总体上保护系统资源。虽然 Google Cloud 支持团队和销售团队可以配合您的请求提高某些限制,但通常不能轻易提高。

请参阅 VPC 资源配额和限制,了解目前的具体值。

Google 支持团队可以在一定程度上提高扩缩限制,但有时候您可能需要构建多个 VPC 网络来满足扩缩需求。如果您的 VPC 网络需求超出了限制,请与 Google Cloud 销售团队及支持团队探讨具体情形并找出最优方法来满足您的需求。

为每个自主团队创建一个 VPC 网络,并在公用 VPC 网络中使用共享服务

有些大型企业部署会涉及到自主团队,每个自主团队都需要完全控制各自的 VPC 网络。为此,您可以为每个业务部门创建一个 VPC 网络,同时在一个公用 VPC 网络中使用共享服务(例如分析工具、CI/CD 流水线和构建机器、DNS/目录服务),从而满足上述需求。如需详细了解如何为共享服务创建公用 VPC 网络,请参阅共享服务部分。

在不同项目中为独立 IAM 控件创建 VPC 网络

VPC 网络是项目级别的资源,具有精细的项目级别身份和访问权限管理 (IAM) 控件,其中包括以下角色:

  • networkAdmin
  • securityAdmin
  • networkUser
  • networkViewer

默认情况下,IAM 控件在项目级别进行部署,并且每个 IAM 角色都适用于项目中的所有 VPC 网络。

如果您需要为每个 VPC 网络使用独立的 IAM 控件,请在不同项目中创建 VPC 网络。

如果您需要针对特定 Compute Engine 资源(例如虚拟机实例、磁盘和映像)的 IAM 角色,请使用 Compute Engine 资源的 IAM 政策

将敏感数据隔离在自己的 VPC 网络中

如果企业需要处理合规性计划、敏感数据,或者由 HIPAA 或 PCI-DSS 等合规标准严格监管的数据,则通常需要采取进一步的安全措施。有一种方法可以提高安全性并轻松证明合规性,即将上述环境分别隔离在自己的 VPC 网络中。

连接多个 VPC 网络

根据费用、性能和安全需要选择 VPC 连接方法

在决定实现多个 VPC 网络后,下一步是连接这些 VPC 网络。VPC 网络是 Google Andromeda SDN 内的独立租户空间,它们彼此间通过多种方法进行通信。后续部分将介绍关于选择 VPC 连接方法的一些最佳做法。

下表汇总了每种方法的优缺点,后续部分将介绍关于选择 VPC 连接方法的一些最佳做法。

优点 缺点
VPC 网络对等互连
  • 易配置。
  • 管理开销低。
  • 带宽高。
  • 出站流量费用低(与单个 VPC 网络相同)。
  • 每个 VPC 网络都维护各自的分布式防火墙。
  • 每个 VPC 网络都维护各自的 IAM 帐号和权限。
  • 非传递性。
  • 扩缩数量受限于全组对等互连 VPC 网络,其中包括虚拟机、路由及内部转发规则的数量。
  • 要求地址空间不能重叠。
  • 静态和动态路由不会进行传播。
  • 发送方虚拟机的来源标记和来源服务帐号不会在 VPC 网络对等互连中传播。
外部路由(公共 IP 或 NAT 网关)
  • 无需配置。
  • VPC 网络之间完全隔离。
  • IP 地址空间可以重叠。
  • 带宽高。
  • 同一地区内的虚拟机出站流量费用高于其他方式(如 VPC 网络对等互连)的这一费用。
  • 需要使用外部 IP 地址公开虚拟机。
  • 无使用专用 IP 地址的防火墙。
  • 静态和动态路由不会进行传播。
  • 发送方虚拟机的来源标记和来源服务帐号不会在对等互连网络中被认可。
Cloud VPN
  • 为路由器中心辐射型拓扑启用传递性拓扑(仅限静态路由)。
  • 可通过 ECMP 进行扩缩。
  • 服务等级协议 (SLA) 承诺传统 VPN 可用性高达 99.9%。
  • 当此功能正式推出时,SLA 承诺 HA VPN 可用性高达 99.99%
  • 管理开销。
  • 按互联网出站流量费率计费。
  • 延时略高。
  • 每个隧道的吞吐量限制在 1.5 Gbps 左右。
  • MTU 较低,因为进行了额外的隧道封装。
  • 发送方虚拟机的来源标记和来源服务帐号在隧道将会丢失。
Cloud Interconnect - 专用互连或合作伙伴互连
  • 支持在部署中实现基于冗余的 SLA:
  • 每个专用互连链接都是 10 Gbps 或 100 Gbps 连接。多个互连链接可以捆绑起来,从而增加吞吐量,每个专用互连连接最多可包含 8 条 10 Gbps 线路 (80 Gbps) 或 2 条 100 Gbps (200 Gbps) 线路。
  • 可通过在多个互连中使用 ECMP 增加吞吐量。
  • 通过互连连接在 VPC 网络之间发送的流量将会产生额外费用和出站流量费用。
  • 流量未加密。
  • 云原生解决方案会有额外的延时。
  • 路径中具有可能发生故障的其他硬件设备。
多网络接口(多 NIC)
  • 可通过托管的实例组及实例间的 ECMP 路由进行扩缩。
  • 为实现最优性能,每个 vCPU 都有 2 Gbps 的出站流量上限,理论上最高可达到 16 Gbps。
  • 每个实例最多只能具有 8 个接口。
  • 负载平衡仅适用于虚拟机的默认网络接口 (nic0)。

如果不超出资源限制,请使用 VPC 网络对等互连

当您需要连接 VPC 网络,但是不能使用单个共享 VPC 时,只要所有直接连接的对等互连方的资源需求总量不超出虚拟机实例、对等互连连接数以及内部转发规则的限制,我们建议您使用 VPC 网络对等互连

VPC 网络对等互连可以让两个 VPC 网络通过 Google SDN 在内部实现互连,无论它们是否属于同一个项目或组织。VPC 网络对等互连将会合并互连方之间的控制平面和流量传播,从而实现相同的转发特征,就像所有虚拟机都在同一个 VPC 网络中一样。当 VPC 网络建立对等互连后,所有子网、别名 IP 地址范围以及内部转发规则都会处于可访问的状态,并且每个 VPC 网络都会维护各自的分布式防火墙。VPC 网络对等互连不具有传递性。

VPC 网络对等互连是连接 VPC 网络的首选方法,原因如下:

  • 无网关瓶颈 - 流量在对等方之间转发,就像所有虚拟机都在同一个 VPC 网络中一样。
  • 计费 - 无需额外费用;计费方式与所有虚拟机都在同一个 VPC 网络中类似。

如果不需要专用 IP 地址通信,请使用外部路由

如果不需要专用 IP 地址进行通信,可以使用外部 IP 地址或 NAT 网关进行外部路由。

在部署 VPC 网络时,通向 Google 默认互联网网关的路由的优先级将预配为 1000。如果此路由存在,并为虚拟机提供了外部 IP 地址,则虚拟机可以通过 Google 的互联网网关来发送出站流量。您还可以将服务部署到 Google 的任一公共负载平衡产品后面,以便从外部访问服务。

具有外部地址的虚拟机可通过 Google 的骨干网彼此进行私密通信,而不论它们的区域和网络服务层级如何。您可以使用 GCP 防火墙规则控制虚拟机的外部入站流量。

外部路由是一种理想的扩缩方式,但是务必要了解公共路由对费用的影响。如需了解详情,请参阅网络价格文档

如果采用 Cloud VPN 以外的方式连接 VPC 网络会超出总体对等互连组限制,则使用 Cloud VPN 连接 VPC 网络。

通过使用静态或动态路由在两个端点之间创建 IPSec 隧道,Cloud VPN 可以提供托管式服务来连接 VPC 网络。传统 VPN 和静态路由可以在 VPC 网络之间以及中心辐射型的拓扑中实现传递性路由,如本文档后面部分所述。请勿将 Cloud VPN 用作本地网络之间的传输网络,如 Cloud VPN 文档中所述。 对于其他场景,我们建议使用高可用性 VPN,因为其正式版可提供 SLA 承诺的 99.99% 的可用性,但仅支持动态路由。

不过,使用 Cloud VPN 可能受到性能限制:由于进行了额外的隧道封装,因此 Cloud VPN 需要在 VPC 网络中使用较低的最大传输单元 (MTU),这会限制单个流的吞吐量。

使用 Cloud Interconnect 通过本地设备来控制 VPC 网络之间的流量

Cloud Interconnect 通过高可用性、低延时的连接将本地网络扩展到 Google 的网络。您可以使用 Cloud Interconnect - 专用互连直接连接到 Google,或使用 Cloud Interconnect - 合作伙伴互连通过支持的服务提供商来连接到 Google。

专用互连将在 Google 与主机托管服务提供商或本地位置之间提供高速 L2 服务。因此,您可以使用本地路由设备在 VPC 网络之间进行路由,同时使用现有的本地安全和检查服务对 VPC 网络之间的所有流量进行过滤。由于使用本地系统时会有额外往返,导致两个 VPC 网络之间的所有流量都会具有额外的延时。

合作伙伴互连也会提供上述类似功能,另外它还能够在 L3 级别与提供商直接对等互连,让提供商在 VPC 网络之间进行路由。之后,无需 NAT 设备或 VPN 隧道,也能访问本地网络和 Google Cloud VPC 网络中的 RFC 1918 IP 地址。

由于许多企业安全设备可以通过多 NIC 虚拟机用在 Google Cloud 上,因此,除非在极少数情况下,因公司政策要求使用本地设备传送所有流量,否则无需使用 Cloud Interconnect 在 VPC 网络之间路由流量。

使用多 NIC 虚拟设备通过云端设备来控制 VPC 网络之间的流量

多网络接口(多 NIC)虚拟机常用于需要附加安全机制或服务的 VPC 网络,因为多 NIC 虚拟机可以帮助虚拟机实例在 VPC 网络之间进行通信。

虚拟机只能为所连接的每个 VPC 网络使用一个接口。 如需将某个虚拟机部署到多个 VPC 网络中,您必须对该虚拟机所连接的每个 VPC 网络拥有适当的 IAM 权限。

在部署多 NIC 虚拟机时,请牢记以下特征:

  • 多 NIC 虚拟机最多可以有 8 个接口。
  • 每个接口的子网 IP 地址范围不能重叠。

使用共享 VPC 的多 NIC

如果多个 VPC 网络需要访问公共资源但不互相访问,请创建一个共享服务 VPC

VPC 网络提供全网状的全球可达性。因此,在进行连接时,无需特别留意同一 VPC 网络中的共享服务和持续集成流水线,因为它们本身始终可以访问。共享 VPC 扩展了此概念,使得共享服务可以驻留在隔离项目中,同时可提供与其他服务或使用方的连接。

访问共享服务的两种方法是 VPC 网络对等互连和 Cloud VPN。如果不会超出总体资源限制,请使用 VPC 网络对等互连来连接到共享服务 VPC 网络。如果会超出总体对等互连组限制,请使用 Cloud VPN 连接共享服务 VPC 网络。

VPC 网络对等互连 Cloud VPN 对等互连
对等 VPC 网络限制 25 VPN 隧道配额
实例 15500(针对所有对等互连的 VPC 网络) 15000(针对每个 VPC 网络)
内部转发规则 50(针对所有对等互连的 VPC 网络) 50(针对每个 VPC 网络)
费用 无需额外费用 按 VPN 隧道和流量出站费用计费
吞吐量 与 VPC 网络内部相同 每个 Cloud VPN 隧道最高可达 3 Gbps

VPC 网络对等互连为共享服务的连接提供了一种简单方法。在此模型中,每个 VPC 网络都会与公用的共享服务 VPC 网络建立对等互连关系,从而提供可达性。在使用 VPC 网络对等互连时,还要注意扩缩,因为所有互连方的总体资源用量都具有扩缩限制。

使用 VPC 网络对等互连的共享服务

VPC 网络对等互连也可以与专用服务访问通道Service Networking API 配合使用。在使用 Service Networking API 时,您可以让同一组织内或其他组织的客户使用您提供的服务,但是要让他们选择使用 VPC 网络对等互连来连接的 IP 地址范围。

Cloud VPN 是 VPC 网络对等互连的替代方案。由于 Cloud VPN 通过托管的 IPSec 隧道来建立可达性,因此它没有 VPC 网络对等互连的总体上限。Cloud VPN 使用 VPN 网关进行连接,并且不考虑 IPSec 互连方的总体资源用量问题。Cloud VPN 的缺点包括费用增加(VPN 隧道和流量出站),同时产生维护隧道所需的管理开销以及 IPSec 的性能开销。

使用 Cloud VPN 的共享服务

混合设计:连接本地环境

在确定混合连接的需要,并且选定符合您的带宽、性能和安全要求的解决方案之后,需要思考如何将它集成到您的 VPC 设计当中。

使用共享 VPC 后将缓解为每个项目复制相同解决方案的需求。例如,在将 Cloud Interconnect 解决方案集成到共享 VPC 时,所有虚拟机(无论区域或服务项目如何)均可访问 Cloud Interconnect 连接。

尽量使用动态路由

通常情况下,我们建议您使用动态路由。但在有些情况下,您也可能需要使用静态路由,例如您的本地设备不支持动态路由的时候。

动态路由

动态路由适用于所有互连解决方案,包括 HA VPN、专用互连及合作伙伴互连。动态路由使用 Google 的 Cloud Router 作为边界网关协议 (BGP) 发言者来提供动态外部 BGP (eBGP) 路由。

Cloud Router 不在数据平面中;它只能在 SDN 中创建路由。

动态路由不会使用标记,Cloud Router 路由器也绝不会重新通告已知的前缀。

您可以在每个 VPC 网络上启用 Cloud Router 路由器的两种模式之一(区域或全球)。如果选择区域路由模式,则 Cloud Router 路由器将仅通告共同驻留在 Cloud Router 路由器部署区域中的子网。相反地,如果选择全球路由模式,则路由器会通告所有子网(无论区域如何),但是对在该区域之外的通告和已知路由将会作出罚分处理。这样可以始终优先考虑本地互连,确保在区域内保持对称性;罚分等于罚分指标 (MED) 200 加上区域间的 TTL(以毫秒为单位)。

静态路由

静态路由仅适用于传统 VPN。静态路由可用于设置指向某 Cloud VPN 隧道的下一个跃点路由。

默认情况下,静态路由适用于所有虚拟机,无论区域如何。通过静态路由,网络管理员还可以使用实例标记有选择性地设置路由适用于哪些虚拟机,以便在创建路由时指向这些虚拟机。

静态路由在全球 VPC 网络内应用,并且所有静态路由的路由优先级相同。因此,如果您在多个区域具有前缀和优先级都相同的多个隧道,虚拟机将会在所有隧道中使用基于哈希的 5 元组 ECMP。要优化此设置,您可以引用每个区域的实例标记并相应地创建首选路由,从而创建首选的区域内路由。

如果您不希望出站流量经过 Google 的默认互联网网关,您可以设置首选的默认静态路由,令其通过隧道将所有流量发回本地。

使用连接 VPC 网络扩缩具有多个 VPC 网络的中心辐射型架构

如果您需要扩缩具有多个 VPC 网络的中心辐射型架构,请在专用 VPC 网络中配置一个集中式混合连接,然后使用自定义通告路由与其他项目建立对等互连。这样可以将静态或动态已知路由导出到互连方的 VPC 网络,进而提供集中式配置并对您的 VPC 网络设计进行扩缩。

这与传统的混合连接部署形成鲜明对比,传统部署会在每个 VPC 网络中使用 VPN 隧道或 VLAN 连接。

下图展示了集中式混合连接与 VPC 网络对等互连自定义路由:

混合设计

网络安全

从数据中心和自定义安全硬件的物理安全到专业的研究团队,Google Cloud 将在其基础架构和服务中提供强大的安全功能。但是,保护 Google Cloud 资源是一项共同的责任。您必须采取适当措施来帮助确保您的应用和数据得到保护。

确定明确的安全目标

在评估云原生或云端安全控件之前,首先需要确定一套明确的安全目标,让所有相关方认同将这些目标作为产品的基本组成部分。这些目标必须强调其可实现性、文档和迭代,以便在开发过程中随时引用和改进。

限制外部访问

在创建使用 VPC 网络的 Google Cloud 资源时,您可以选择资源所驻留的网络和子网。系统会从与子网关联的任一 IP 地址范围为资源分配内部 IP 地址。 如果防火墙规则允许,VPC 网络中的资源可以通过内部 IP 地址互相通信。

将互联网访问权限仅授予那些需要该权限的资源。仅具有专用内部 IP 地址的资源仍然可以通过专用 Google 访问通道来访问多个 Google API 和服务。此专用访问通道使资源能够与关键 Google 和 Google Cloud 服务进行交互,同时保持与公共互联网隔离。

此外,您还可以使用组织政策进一步限制允许哪些资源使用外部 IP 地址。

但是,在阻止互联网访问之前,请认真考虑对虚拟机实例的影响。阻止互联网访问虽然可以降低数据渗露的风险,但是它也会阻止合法流量,包括软件更新以及第三方 API 和服务需要的流量。如果没有互联网访问,则只能通过通过 Cloud VPN 隧道、Cloud Interconnect 连接或 Identity-Aware 代理连接的本地网络访问虚拟机实例。通过 Cloud NAT,虚拟机可以启动与互联网的出站连接来提供必要的流量,但不会公开公共入站连接。

为敏感数据定义服务边界

在涉及敏感数据的工作负载中,您可以使用 VPC Service Controls 为您的 VPC 资源及 Google 托管式服务配置服务边界,并控制跨边界的数据移动。使用 VPC Service Controls 将您的项目和本地网络组合到单个边界中,以防通过 Google 托管式服务来访问数据。服务边界不能包含来自不同组织的项目,但是您可以使用边界网桥帮助不同服务边界内的项目和服务进行通信。

尽量使用 Google Cloud 原生防火墙规则管理流量

Google Cloud VPC 包含一个 L3/L4 有状态防火墙,可水平扩缩并以分布式方式应用于每个虚拟机。

Google Cloud Marketplace 拥有庞大的第三方解决方案生态系统,其中包含可实现以下目的的虚拟机:提供高级安全机制,例如防止信息泄露、应用漏洞和权限升级;检测已知和未知的威胁;应用网址过滤功能。此外,在云服务提供商和本地环境之间使用单一的供应商实现政策也具有运营优势。

一般情况下,通过指定相同优先级(使用 5 元组哈希分配流量)或不同优先级(创建冗余路径)的路由来将流量路由到这些虚拟机,请参阅下图中通向开发版子网的多条路径。

使用原生防火墙规则管理流量

大多数解决方案都需要多个网络接口(多 NIC)。但对虚拟机而言,每个 VPC 网络最多只能有一个接口,因此在创建多 NIC 虚拟机时,每个接口必须连接到单独的 VPC 网络。

在将第三方解决方案部署到 VPC 网络中时,还要特别注意扩缩因素,原因如下:

  • 限制:大多数基于虚拟机的设备必须插入到数据路径中。因此需要一个多 NIC 虚拟机来桥接驻留在同一个项目中的多个 VPC 网络。由于 VPC 资源配额在项目级别设置,因此对所有 VPC 网络的总体资源需求可能会有所限制。
  • 性能:如果在 VPC 网络的完全水平可扩缩特性中引入基于虚拟机的阻塞点,将给云设计方法带来不利影响。

在具有大规模需求的架构中,为了充分考虑上述因素的影响,请在您的端点中加入安全控件。首先应强化虚拟机的安全并使用 GCP 防火墙规则。在此策略中,您还需要引入基于主机的端点检查代理,这些代理不会通过多 NIC 虚拟机来更改您的 VPC 网络转发架构。

如需查看该配置的其他示例,请参阅 VPC 网络之间的有状态 L7 防火墙参考架构

尽量使用更少、但更宽泛的防火墙规则集

VPC 防火墙仅允许在任何虚拟机上设定数量有限的规则。不过,您可以将多个规则合并成一个复杂的规则定义。例如,如果 VPC 网络中的所有虚拟机都需要明确允许使用 10 个入站 TCP 端口,在这种情况下,您有两个选择:编写 10 个单独的规则,每个规则定义一个端口;或定义一个规则来包含全部 10 个端口。显然,定义一个规则来包含全部 10 个端口效率更高。

创建一个适用于整个 VPC 网络的通用规则集,然后根据目标来为更小一些的虚拟机分组使用更有针对性的规则集。也就是说,首先要定义宽泛的规则,然后根据需要逐步定义更细化的规则:

  1. 应用对 VPC 网络中的所有虚拟机通用的防火墙规则。
  2. 应用可以划分到多个虚拟机中的防火墙规则,例如服务实例组或子网。
  3. 将防火墙规则应用于各个虚拟机,例如 NAT 网关或堡垒主机。

尽量使用服务帐号隔离虚拟机

许多组织的环境都需要为 VPC 网络中的一小组虚拟机配置特定的规则。在这些情况下,您可以采取以下两种常用方法:子网隔离和目标过滤。

子网隔离

使用子网隔离时,子网将为所应用的 GCP 防火墙规则构建安全边界。这种方法常用于本地网络结构中以及虚拟机身份中包含 IP 地址和网络位置的情况。

如前所述,您可以通过对这些实例应用唯一的网络标记或服务帐号来标识特定子网上的虚拟机。这样,您就可以为子网中具有关联网络标记或服务帐号的虚拟机创建一些仅适用于它们的防火墙规则。例如,如需创建一个防火墙规则来允许同一子网内的虚拟机之间进行所有通信,您可以在“防火墙规则”页面中使用以下规则配置:

  • 目标指定的目标标记
  • 目标标记subnet-1
  • 来源过滤子网
  • 子网:按名称(例如:subnet-1)选择子网。

目标过滤

使用目标过滤时,所有虚拟机要么驻留在同一个子网中,要么属于任意一组子网。在这种方法中,子网成员资格不会被视为防火墙规则实例身份的一部分。相反,您可以使用网络标记或服务帐号限制同一子网中虚拟机之间的访问。使用相同防火墙规则的每组虚拟机都会应用相同的网络标记。

为了说明这一点,假设有一个三层(网络、应用、数据库)的应用,该应用的所有实例都部署在同一个子网中。网络层可以与最终用户及应用层进行通信,应用层可以与数据库层进行通信,但不允许在层与层之间进行其他通信。运行网络层的实例带有网络标记 web,运行应用层的实例带有网络标记 app,而运行数据库层的实例带有网络标记 db

以下防火墙规则实现了此方法:

规则 1:允许最终用户 → 网络层通信 目标指定的目标标记
目标标记web
来源过滤IP 地址范围
来源 IP 地址范围0.0.0.0/0
规则 2:允许网络层 → 应用层通信 目标指定的目标标记
目标标记app
来源过滤来源标记
来源标记web
规则 3:允许应用层 → 数据库层通信 目标指定的目标标记
目标标记db
来源过滤来源标记
来源标记app

不过,虽然可以使用标记执行如上所述的目标过滤,但我们还是建议您尽可能使用服务帐号。目标标记不受访问权限控制,当虚拟机处于使用中时,具有 instanceAdmin 角色的用户可以更改目标标记。而服务帐号受访问权限控制,也就是说,特定用户必须经过明确授权才能使用服务帐号。 每个实例只能有一个服务帐号,但可以有多个标记。 另外,只有在虚拟机停止后才能更改分配给该虚拟机的服务帐号。

在使用标记时,使用自动化框架监控安全政策

使用标记时,请谨记实例管理员可以更改这些标记。 这可能会违反安全政策。因此,如果您在生产环境中使用了标记,请使用自动化框架帮助您克服标记缺乏 IAM 治理的问题。例如,使用 Forseti,它可以让您深入了解配置更改并帮助您解决问题。

使用附加工具帮助保护您的应用

除了防火墙规则外,您还可以使用以下附加工具保护您的应用:

  • 使用 Google Cloud 全球 HTTP(S) 负载平衡器支持高可用性和协议标准化。
  • Google Cloud Armor 与 HTTP(S) 负载平衡器集成,在网络边缘提供 DDoS 防护机制以及拦截或允许 IP 地址的功能。
  • 使用 Cloud Identity-Aware Proxy (IAP) 验证用户身份和请求上下文,以确定是否应允许用户访问,从而控制对应用的访问权限。
  • 通过 Security Command Center 提供一个界面来执行安全性数据分析、异常值检测和漏洞检测。

网络服务:NAT 和 DNS

通过 Cloud NAT 使用固定外部 IP 地址

如果您需要从一系列虚拟机中获取固定外部 IP 地址,请使用 Cloud NAT。例如,当第三方允许来自特定外部 IP 地址的请求时,您可能需要固定出站 IP 地址。通过 Cloud NAT,您可以在用于出站通信的每个区域中使用少量 NAT IP 地址。

但是,即便没有自己的外部 IP 地址,Cloud NAT 也允许您的虚拟机实例通过互联网进行通信。GCP 防火墙规则是有状态的。也就是说,如果在来源与目标或目标与目的地之间允许连接,只要连接处于活跃状态,则任何方向的所有后续流量都允许通过。换言之,在建立会话后,防火墙规则就会允许双向通信。

使用专用 DNS 地区执行名称解析

通过 Cloud DNS 上的专用地区,可以在您的 VPC 网络内使用 DNS 及服务的内部 IP 地址解析服务,而无需对外公开此映射。

使用水平分割 DNS 从 VPC 网络内部(而非外部)将服务映射到不同的 IP 地址。例如,您可以通过网络负载平衡从公共互联网上公开服务,但是通过内部负载平衡可以在 VPC 网络内部使用相同的 DNS 名称提供同一服务。

Google 托管式服务的 API 访问权限

尽量使用默认的互联网网关

从 VPC 网络内的资源到 Google API 之间的访问遵循默认互联网网关的下一个跃点。虽然有了下一个跃点网关的名称,但是从实例到 Google API 的流量路径仍保留在 Google 网络中。

默认情况下,只有具有外部 IP 地址的实例才能与 Google API 和服务进行通信。如果您需要从没有外部 IP 地址的实例进行访问,请为每个子网使用专用 Google 访问通道功能。这不会减慢 Google API 的通信速度。

Google Kubernetes Engine (GKE) 会自动在已部署节点的子网上启用专用 Google 访问通道。在这些子网中,所有没有外部 IP 地址的节点均可访问 Google 托管式服务。

如果需要修改默认路由,请为 Google API 添加显式路由

如果您需要修改默认路由,请为 Google API 目标 IP 地址范围添加显式路由。

在默认路由 (0.0.0.0/0) 未使用默认互联网网关的下一个跃点的环境中,请为 Google API 使用的目标 IP 地址范围配置显式路由。然后将该显式路由的下一个跃点设置为默认互联网网关。例如,您需要通过本地设备来检查所有流量,这也是上述情形的一种。

在同一子网上部署使用 Google API 的实例

在同一子网中部署需要访问 Google API 和服务的实例,然后为没有外部 IP 地址的实例启用专用 Google 访问通道。

如果您是从本地环境中访问 Google API,请按照为本地主机配置专用 Google 访问通道中的说明来通过专用 IP 地址范围访问某些 Google 服务。在激活此功能前,请查看具体支持哪些服务,因为通过此服务提供的 IP 地址将无法访问其他 Google API。激活此功能可能需要一些附加 DNS 配置,例如配置 DNS 视图。

日志记录、监控和可见性

针对特定使用场景和目标受众执行日志记录

使用 VPC 流日志执行网络监控、取证、实时安全分析和费用优化。您可以在子网级别启用或停用 VPC 流日志。如果为子网启用了 VPC 流日志,它们将从该子网的所有虚拟机实例中收集数据。

这些日志将会记录虚拟机实例发送和接收的网络流样本。 您的日志记录使用场景有助于确定哪些子网需要进行日志记录以及记录多长时间。

以 5 秒为间隔,通过连接从 Compute Engine 虚拟机汇总并实时导出流日志。您可以在 Cloud Logging 中查看流日志,并将其导出到 Cloud Logging 导出功能支持的任何目标位置。

Logging 中的日志提取页面可以跟踪项目中的日志数量,同时允许您停用所有日志提取操作或排除(舍弃)您不感兴趣的日志条目,以便最大限度降低超出每月配额的日志费用。

日志是确保成功运营和安全的关键部分,但是只有您查看日志并采取行动,它们才会发挥作用。针对目标受众提供个性化的日志,确保您的 VPC 网络实现成功运营和安全。

如需了解详情,请参阅使用 VPC 流日志

对于有长时间连接的 VPC 网络,增大日志汇总的时间间隔

对于大部分为长期连接的 VPC 网络,请将日志汇总时间间隔设置为 15 分钟,从而显著减少生成的日志数量并且实现更快速、更简单的分析。

一个增加日志汇总时间间隔的工作流例子是网络监控,其中包括以下任务:

  • 执行网络诊断
  • 按虚拟机和应用过滤流日志以了解流量变化
  • 分析流量增长情况以预测容量

使用 VPC 流日志采样减少数量

您可以使用 VPC 流日志采样减少 VPC 流日志的数量,但是仍能查看低级别的样本和汇总视图。

一个使用采样减少数量的工作流例子是了解网络使用情况和优化网络流量费用。此工作流包含以下任务:

  • 估算区域和地区之间的流量
  • 估算通向互联网上特定国家/地区的流量
  • 确定最高用量者

只需要 IP 地址和端口数据时,移除其他元数据

如果在某些安全使用场景中,您只对 IP 地址和端口感兴趣,请移除其他元数据来减少 Cloud Logging 中使用的数据量。

一个移除元数据的工作流例子是网络取证,其中包含以下任务:

  • 确定哪些 IP 地址在何时与谁进行过通信
  • 确定通过分析网络流发现的任何被入侵的 IP 地址

参考架构

本部分将着重介绍几个架构,用于演示本文档中提及的一些最佳做法。

单个项目、单个 VPC 网络

在此初始参考架构中,包含在多个区域中部署可用性高的架构所需的所有组件,同时具有子网级别隔离功能,并且服务等级协议 (SLA) 承诺的与您本地数据中心连接的可用性高达 99.99%。

单个项目、单个 VPC 网络

单个宿主项目、多个服务项目、单个共享 VPC

建立在初始参考架构的基础上,共享 VPC 宿主项目和多个服务项目可让管理员将创建和管理实例等管理职责委托给服务项目管理员,同时保持对子网、路由和防火墙等网络资源的集中控制。

单个宿主项目、多个服务项目、单个共享 VPC

多个宿主项目、多个服务项目、多个共享 VPC

下图展示了 VPC 隔离架构,该架构建立在我们的高可用性设计基础上,并将 prod 与其他项目分离开来。进行 VPC 隔离的原因很多,包括审计要求(如 PCI)、环境之间的配额因素或者仅仅是为了增加一个逻辑隔离层。您只能为每个位置使用两个互连(实现冗余),但可以通过它们向多个 VPC 网络或区域添加多个互连连接。

多个宿主项目、多个服务项目、多个共享 VPC

使用隔离时还需要进行复制,因为您需要决定将代理、身份验证和目录服务等核心服务放在何处。 但是使用共享服务 VPC 网络则没有此需要,您可以通过 VPC 网络对等互连与其他 VPC 网络共享这些服务,同时进行集中管理和部署。

多个宿主项目、多个服务项目、多个共享 VPC

VPC 网络之间的有状态 L7 防火墙

此架构具有多个通过 L7 下一代防火墙 (NGFW) 设备(充当 VPC 网络之间的多 NIC 网桥)桥接的 VPC 网络。

引入了不信任的外部 VPC 网络以终止混合互连和基于互联网的连接,这些连接会在 L7 NGFW 的外部线路上终止,以便执行检查。此设计有许多不同的形式,但是关键原则是在流量到达信任的 VPC 网络之前对通过防火墙的流量进行过滤。

在该设计中,要求每个 VPC 网络都驻留在将插入基于虚拟机的 NGFW 的项目中。由于配额是在项目级别强制执行的,因此您必须考虑所有 VPC 资源的总体用量。

VPC 之间的有状态 L7 防火墙

后续步骤