部署蓝图

Last reviewed 2023-12-20 UTC

本部分介绍可用于部署蓝图、蓝图的命名规则以及蓝图建议的替代方案的流程。

综合应用

如需根据此蓝中的最佳实践和建议部署自己的企业基础，请按照本部分总结的概要任务执行操作。部署包含必要的设置步骤、通过 GitHub 上的 terraform-example-foundation 自动执行的部署，以及初始基础部署完成后必须手动配置的其他步骤。

流程 步骤

部署基础流水线资源的前提条件

在部署基础流水线之前，请完成以下步骤：

如需连接到现有的本地环境，请准备以下内容：

从 GitHub 部署 terraform-example-foundation 的步骤

按照每个阶段对应的 README 说明从 GitHub 部署 terraform-example-foundation：

IaC 部署后的其他步骤

部署 Terraform 代码后，请完成以下操作：

面向具有敏感工作负载的客户的额外管理控制

Google Cloud 提供了额外的管理控制，可帮助您满足安全性和合规性要求。但是，某些控制需要额外成本或在运营方面的权衡，可能不适合每个客户。这些控制还需要针对特定要求提供自定义输入，这些输入无法在所有蓝图中通过适合所有客户的默认值来实现完全自动化。

本部分介绍您集中应用于基础的安全控制。本部分并非旨在详尽无遗地介绍可应用于特定工作负载的所有安全控制。如需详细了解 Google 的安全产品和解决方案，请参阅 Google Cloud 安全性最佳实践中心。

根据您的合规性要求、风险偏好和数据敏感性，评估以下控制是否适合您的基础。

控制 说明

使用 VPC Service Controls 保护您的资源

借助 VPC Service Controls，您可以定义安全政策，以阻止对受信任边界外的 Google 管理的服务的访问、阻止从不可信位置访问数据，以及降低数据渗漏风险。但是，在您定义异常以允许预期的访问模式之前，VPC Service Controls 可能会导致现有服务中断。

评估缓解渗漏风险的价值是否值得采用 VPC Service Controls 所带来的复杂性和运营开销。此蓝图准备受限网络和可选变量，用于配置 VPC Service Controls，但在您执行设计和启用边界的附加步骤之前，边界不会启用。

限制资源位置

您可能有一些监管要求，即云资源只能部署在已获批准的地理位置。此组织政策限制条件强制资源只能在您定义的位置列表中部署。

启用 Assured Workloads

Assured Workloads 提供额外的合规性控制，可帮助您满足特定监管制度。此蓝图在部署流水线中提供可选变量以进行启用。

启用数据访问日志

您可能需要记录对某些敏感数据或资源的所有访问。

评估工作负载处理需要数据访问日志的敏感数据的位置，并为处理敏感数据的每项服务和环境启用日志。

启用 Access Approval

Access Approval 可确保 Cloud Customer Care 和工程部门每次在需要访问您的客户内容时均需要您的明确批准。

评估查看 Access Approval 请求所需的操作流程，以减少在解决支持突发事件中可能的延迟。

启用 Key Access Justifications

借助 Key Access Justifications，您能够以编程方式控制 Google 能否访问您的加密密钥，包括用于自动化操作的加密密钥和 Customer Care 访问您的客户内容所用的加密密钥。

评估与 Key Access Justifications 相关的费用和运营开销，以及它对 Cloud External Key Manager (Cloud EKM) 的依赖性。

停用 Cloud Shell

Cloud Shell 是一个在线开发环境。此 shell 托管在您的环境外部的 Google 管理的服务器上，因此它不受您可能已在自己的开发者工作站上实现的控制的约束。

如果要严格控制开发者可用于访问云资源的工作站，请停用 Cloud Shell。您还可以在自己的环境中评估 Cloud Workstations 的可配置工作站选项。

限制对 Google Cloud 控制台的访问

通过 Google Cloud，您可以根据群组成员资格、可信 IP 地址范围和设备验证等访问权限级别属性来限制对 Google Cloud 控制台的访问。某些属性需要额外订阅 BeyondCorp Enterprise。

请在更大的零信任部署过程中，评估您对用户访问基于网络的应用（例如控制台）所信任的访问模式。

命名惯例

我们建议您为 Google Cloud 资源制定标准化命名惯例。下表介绍了蓝图中资源名称的建议惯例。

资源 命名惯例

文件夹

fldr-environment

environment 是 Google Cloud 组织中的文件夹级资源的说明。例如 bootstrap、common、production、nonproduction、development 或 network。

例如：fldr-production

项目 ID

prj-environmentcode-description-randomid

  • environmentcode 是环境字段的简写形式（b、c、p、n、d 或 net 之一）。共享 VPC 宿主项目使用关联环境的 environmentcode。跨环境共享的网络资源的项目（例如 interconnect 项目）使用 net 环境代码。
  • description 是关于项目的其他信息。您可以使用简短易懂的缩写词。
  • randomid 是一个随机后缀，用于防止在全局范围内必须唯一的资源名称冲突，并阻止猜测资源名称的攻击者。此蓝图会自动添加四个字符的随机字母数字标识符。

例如：prj-c-logging-a1b2

VPC 网络

vpc-environmentcode-vpctype-vpcconfig

  • environmentcode 是环境字段的简写形式（b、c、p、n、d 或 net 之一）。
  • vpctype 是 shared、float 或 peer 中的一个。
  • vpcconfig 是 base 或 restricted，用于指示该网络是否应与 VPC Service Controls 一起使用。

例如：vpc-p-shared-base

子网

sn-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode 是环境字段的简写形式（b、c、p、n、d 或 net 之一）。
  • vpctype 是 shared、float 或 peer 中的一个。
  • vpcconfig 是 base 或 restricted，用于指示该网络是否应与 VPC Service Controls 一起使用。
  • region 是资源所在的任何有效 Google Cloud 区域。为避免达到字符数限制，我们建议移除连字符并使用某些区域和方向的缩写形式。例如，au（澳大利亚）、na（北美洲）、sa（南美洲）、eu（欧洲）、se（东南方）或 ne（东北方）。
  • description 是关于子网的其他信息。您可以使用简短易懂的缩写词。

例如：sn-p-shared-restricted-uswest1

防火墙政策

fw-firewalltype-scope-environmentcode{-description}

  • firewalltype 是 hierarchical 或 network。
  • scope 是 global 或资源所在的 Google Cloud 区域。为避免达到字符数限制，我们建议移除连字符并使用某些区域和方向的缩写形式。例如，au（澳大利亚）、na（北美洲）、sa（南美洲）、eu（欧洲）、se（东南方）或 ne（东北方）。
  • environmentcode 是拥有政策资源的环境字段的简写形式（b、c、p、n、d 或 net 之一）。
  • description 是有关分层防火墙政策的其他信息。您可以使用简短易懂的缩写词。

例如：

fw-hierarchical-global-c-01

fw-network-uswest1-p-shared-base

Cloud Router

cr-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode 是环境字段的简写形式（b、c、p、n、d 或 net 之一）。
  • vpctype 是 shared、float 或 peer 中的一个。
  • vpcconfig 是 base 或 restricted，用于指示该网络是否应与 VPC Service Controls 一起使用。
  • region 是资源所在的任何有效 Google Cloud 区域。为避免达到字符数限制，我们建议移除连字符并使用某些区域和方向的缩写形式。例如，au（澳大利亚）、na（北美洲）、sa（南美洲）、eu（欧洲）、se（东南方）或 ne（东北方）。
  • description 是有关 Cloud Router 的额外信息。您可以使用简短易懂的缩写词。

例如：cr-p-shared-base-useast1-cr1

Cloud Interconnect 连接

ic-dc-colo

  • dc 是 Cloud Interconnect 连接到的数据中心的名称。
  • colo 是本地数据中心的 Cloud Interconnect 对等互连的对接网点名称。

例如：ic-mydatacenter-lgazone1

Cloud Interconnect VLAN 连接

vl-dc-colo-environmentcode-vpctype-vpcconfig-region{-description}

  • dc 是 Cloud Interconnect 连接到的数据中心的名称。
  • colo 是本地数据中心的 Cloud Interconnect 对等互连的对接网点名称。
  • environmentcode 是环境字段的简写形式（b、c、p、n、d 或 net 之一）。
  • vpctype 是 shared、float 或 peer 中的一个。
  • vpcconfig 是 base 或 restricted，用于指示该网络是否应与 VPC Service Controls 一起使用。
  • region 是资源所在的任何有效 Google Cloud 区域。为避免达到字符数限制，我们建议移除连字符并使用某些区域和方向的缩写形式。例如，au（澳大利亚）、na（北美洲）、sa（南美洲）、eu（欧洲）、se（东南方）或 ne（东北方）。
  • description 是有关 VLAN 的其他信息。您可以使用简短易懂的缩写词。

例如：vl-mydatacenter-lgazone1-p-shared-base-useast1-cr1

组

grp-gcp-description@example.com

其中，description 是有关该群组的其他信息。您可以使用简短易懂的缩写词。

例如：grp-gcp-billingadmin@example.com

自定义角色

rl-description

其中，description 是有关角色的其他信息。您可以使用简短易懂的缩写词。

例如：rl-customcomputeadmin

服务账号

sa-description@projectid.iam.gserviceaccount.com

其中：

  • description 是有关服务账号的其他信息。您可以使用简短易懂的缩写词。
  • projectid 是全局唯一的项目标识符。

例如：sa-terraform-net@prj-b-seed-a1b2.iam.gserviceaccount.com

存储桶

bkt-projectid-description

其中：

  • projectid 是全局唯一的项目标识符。
  • description 是关于存储桶的其他信息。您可以使用简短易懂的缩写词。

例如：bkt-prj-c-infra-pipeline-a1b2-app-artifacts

默认建议的替代方案

此蓝图中建议的最佳实践可能并不适用于所有客户。您可以自定义任何建议，以满足您的特定要求。下表根据您现有的技术栈和工作方式，介绍了您可能需要的一些常见变体。

决策区域 可能的替代方案

组织：此蓝图使用单个组织作为所有资源的根节点。

确定 Google Cloud 着陆区的资源层次结构介绍了可能偏好多个组织的场景，例如：

  • 您的组织包含将来可能会被出售或作为完全独立的实体运行的子公司。
  • 您希望在未连接到现有组织的沙盒环境中进行实验。

文件夹结构：此蓝图具有简单的文件夹结构，工作负载划分到顶层的 production, non-production 和 development 文件夹中。

确定 Google Cloud 着陆区的资源层次结构介绍了其他方法，可根据您希望管理资源并继承政策的方式设计文件夹结构，例如：

  • 基于应用环境的文件夹
  • 基于区域实体或子公司的文件夹
  • 基于责任框架的文件夹

组织政策：此蓝图在组织节点上强制执行所有组织政策限制条件。

您针对业务的不同部分可能实施了不同的安全政策或工作方式。在此场景中，在资源层次结构的较低节点上强制执行组织政策限制条件。查看可帮助满足您的要求的组织政策限制条件的完整列表。

部署流水线工具：蓝图使用 Cloud Build 运行自动化流水线。

您可能更倾向于将其他产品用于部署流水线，例如 Terraform Enterprise、GitLab Runners、GitHub Actions 或 Jenkins。 此蓝图包含每种替代产品的说明。

用于部署的代码库：蓝图使用 Cloud Source Repositories 作为托管式专用 Git 代码库。

使用您偏好的版本控制系统来管理代码库，例如 GitLab、GitHub 或 Bitbucket。

如果您使用在本地环境中托管的专用代码库，请配置从代码库到 Google Cloud 环境的专用网络路径。

身份提供方：此蓝图假定使用本地 Active Directory，并使用 Google Cloud Directory Sync 将身份与 Cloud Identity 联合。

如果您已经在使用 Google Workspace，则可以使用已在 Google Workspace 中管理的 Google 身份。

如果您还没有身份提供方，则可以直接在 Cloud Identity 中创建和管理用户身份。

如果您已有身份提供方（例如 Okta、Ping 或 Azure Entra ID），则可以管理现有身份提供方中的用户账号，并同步到 Cloud Identity。

如果您有阻止使用 Cloud Identity 的数据主权或合规性要求，并且其他 Google 服务（例如 Google Ads 或 Google Marketing Platform）不需要托管式 Google 用户身份，则您可能更倾向于使用员工身份联合。在这种情况下，请注意支持的服务的限制。

多个区域：此蓝图会将区域级资源部署到两个不同的 Google Cloud 区域中，以帮助实现具有高可用性和灾难恢复要求的工作负载设计。

如果您的最终用户位于更多地理位置，您可以配置更多 Google Cloud 区域，以便创建更靠近最终用户且延迟时间更短的资源。

如果您具有数据主权限制，或者可以在一个区域中满足可用性需求，则只能配置一个 Google Cloud 区域。

IP 地址分配：此蓝图提供了一组 IP 地址范围。

您可能需要根据现有混合环境中的 IP 地址可用性来更改使用的特定 IP 地址范围。如果您修改了 IP 地址范围，请使用蓝图来指导所需范围的数量和大小，并查看 Google Cloud 的有效 IP 地址范围。

混合网络：此蓝图在多个物理站点和 Google Cloud 区域中使用专用互连以实现最大带宽和可用性。

根据您对费用、带宽和可靠性的要求，您可以改为配置合作伙伴互连或 Cloud VPN。

如果您需要在完成专用互连之前开始部署具有专用连接的资源，则可以从 Cloud VPN 开始，并在稍后更改为使用专用互连。

如果您当前没有本地环境，则可能根本不需要混合网络。

VPC Service Controls 边界：蓝图建议使用单个边界，其中包含与受限 VPC 网络关联的所有服务项目。与基本 VPC 网络关联的项目不包含在边界内。

您的用例可能需要为一个组织配置多个边界，或者您可能决定完全不使用 VPC Service Controls。

如需了解详情，请参阅确定如何通过 Google API 缓解数据渗漏。

Secret Manager：蓝图会部署一个项目，以在 common 文件夹中使用 Secret Manager 存储组织范围的密文，并在每个环境文件夹中部署一个项目，以用于特定于环境的密文。

如果您有一个团队负责管理和审核整个组织中的敏感密文，您可能更愿意仅使用一个项目来管理对 Secret 的访问权限。

如果您允许工作负载团队管理自己的密文，则不得使用集中的项目来管理对密文的访问权限，而是让团队在工作负载项目中使用自己的 Secret Manager 实例。

Cloud KMS：蓝图将部署一个项目，以在 common 文件夹中使用 Cloud KMS 管理组织范围内的密钥，并为每个环境文件夹创建一个项目，以用于每个环境中的密钥。

如果您有一个团队负责管理和审核整个组织中的加密密钥，您可能更愿意仅使用一个项目来管理对密钥的访问权限。集中式方法可以帮助满足 PCI 密钥监管等合规性要求。

如果您允许工作负载团队管理自己的密钥，则不得使用集中的项目来管理对密钥的访问权限，而是让团队在工作负载项目中使用自己的 Cloud KMS 实例。

聚合日志接收器：此蓝图在组织节点上配置一组日志接收器，以便中央安全团队可以查看整个组织的审核日志。

您可能有不同的团队负责审核业务的不同部分，并且这些团队可能需要不同的日志来完成其工作。在这种情况下，请在适当的文件夹和项目中设计多个聚合接收器，并创建过滤器以便每个团队仅接收必要的日志，或者设计日志视图以对常见日志存储桶进行精细访问权限控制。

监控范围限定项目：此蓝图为每个环境配置单个监控范围限定项目。

您可以配置由不同团队管理的更精细的范围限定项目，范围限定为包含每个团队管理的应用的项目集。

基础设施流水线的粒度：此蓝图使用这样的模型，即每个业务部门都有单独的基础设施流水线来管理其工作负载项目。

如果您有中心团队负责部署所有项目和基础设施，则可能更倾向于使用由中心团队管理的单个基础设施流水线。该中心团队可以接受来自工作负载团队的拉取请求，以便在项目创建之前进行审核和批准，或者团队可以自行创建拉取请求来响应工单系统。

如果各工作负载团队能够自定义自己的流水线，并且您希望为流水线设计更精细的特权服务账号，则您可能希望使用更精细的流水线。

SIEM 导出：此蓝图管理 Security Command Center 中的所有安全发现结果。

确定您要将安全发现结果从 Security Command Center 导出到 Google Security Operations 等工具还是导出到现有 SIEM，或者团队是否会使用控制台来查看和管理安全发现结果。您可以针对具有不同范围和职责的不同团队配置多个具有唯一过滤条件的导出。

来自本地的 Google Cloud 服务的 DNS 查找：该蓝图为每个共享 VPC 配置唯一的 Private Service Connect 端点，这有助于实现具有多个 VPC Service Controls 边界的设计。

如果您不需要多个 VPC Service Control 边界，则可能不需要在此粒度级别从本地环境路由到 Private Service Connect 端点。

您可以简化此设计以使用具有相应 API 软件包的单个 Private Service Connect 端点或使用 private.googlepais.com 和 restricted.googleapis.com 的通用端点，而不是按环境将本地主机映射到 Private Service Connect 端点。

后续步骤