部署蓝图

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

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

• 创建 Cloud Identity 账号并验证网域所有权。
• 向您的 Google Cloud 销售团队申请账单结算账号，或创建自助结算账号。
• 强制对管理员账号执行安全最佳实践。
• 验证并调解使用方用户账号的问题。
• 配置外部身份提供方作为可靠来源以同步用户账号和单点登录。
• 预配运行蓝图所需的访问权限控制群组。
• 确定您将使用的网络拓扑。
• 确定源代码管理工具。terraform-example-foundation 的说明会写入在 Cloud Source Repositories 中托管的 Git 代码库。
• 确定 CI/CD 自动化工具。terraform-example-foundation 会为不同的自动化工具提供不同的指令集。

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

• 根据蓝图所需的范围的数量和大小规划 IP 地址分配。
• 订购专用互连连接。

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

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

• 暂存 0-bootstrap 以创建基础流水线。

  如果使用自助结算账号，则您必须申请更多项目配额，然后才能继续下一阶段。

• 暂存 1-org 以配置组织级层资源。
• 暂存 2-environments 以创建环境。
• 暂存 3-networks-dual-svpc or 3-networks-hub-and-spoke，以在首选拓扑中创建网络资源。
• 暂存 4-projects 以创建基础设施流水线。
• （可选）暂存 5-app-infra，以获取基础设施流水线的示例用法。

IaC 部署后的其他步骤

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

• 完成本地配置更改。
• 激活 Security Command Center 高级方案。
• 将 Cloud Billing 数据导出到 BigQuery。
• 注册 Cloud Customer Care 方案。
• 启用 Access Transparency 日志。
• 与 Google Cloud共享 Cloud Identity 中的数据。
• 应用非 IaC 部署自动执行的 Cloud Identity 管理控制。
• 评估哪些面向具有敏感工作负载的客户的额外管理控制适合您的使用场景。
• 查看操作最佳实践，并规划如何将现有操作和功能连接到基础资源。

使用 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 Google Cloud 可让您根据群组成员资格、可信 IP 地址范围和设备验证等访问权限级别属性来限制对控制台的访问。某些属性需要额外订阅 Chrome 企业进阶版。

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

文件夹

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

• environmentcode 是环境字段的简写形式（b、c、p、n、d 或 net 之一）。
• vpctype 是 svpc、float 或 peer 中的一个。

例如：vpc-p-svpc

子网

sn-environmentcode-vpctype-region{-description}

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

例如：sn-p-svpc-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-svpc

Cloud Router

cr-environmentcode-vpctype-region{-description}

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

例如：cr-p-svpc-useast1-cr1

Cloud Interconnect 连接

ic-dc-colo

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

例如：ic-mydatacenter-lgazone1

Cloud Interconnect VLAN 连接

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

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

例如：vl-mydatacenter-lgazone1-p-svpc-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 Service Controls。

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

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

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

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

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

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

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

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

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

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

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

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

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

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