企业基础蓝图

Last reviewed 2023-12-20 UTC

本页内容的上次更新时间为 2023 年 12 月,代表截至本文撰写之时的状况。由于我们会不断改善对客户的保护机制,Google 的安全政策和系统今后可能会发生变化。

本文档介绍了在 Google Cloud中部署一组基础资源的最佳实践。云基础是资源、配置和能力的基准,使公司能够采用Google Cloud 来满足其业务需求。设计良好的基础可让您的环境中的所有工作负载实现一致的治理、安全控制、扩缩、可见性和对共享服务的访问权限。 Google Cloud 部署本文档中介绍的控制和治理后,您可以将工作负载部署到 Google Cloud。

企业基础蓝图(以前称为安全基础蓝图)适用于负责设计 Google Cloud上的企业级环境的架构师、安全从业人员和平台工程团队。此蓝图包含以下内容:

您可以通过以下两种方式之一使用本指南:

  • 根据 Google 的最佳实践创建完整的基础。您可以在开始时部署本指南中的所有建议,然后自定义环境以满足您的业务特定要求。
  • 查看 Google Cloud上的现有环境。您可以将设计的特定组件与 Google 推荐的最佳实践进行比较。

支持的使用场景

企业基础蓝图提供了一个基准层资源和配置,有助于在 Google Cloud上启用所有类型的工作负载。无论您是将现有的计算工作负载迁移到 Google Cloud、构建容器化 Web 应用,还是创建大数据和机器学习工作负载,企业基础蓝图都可以帮助您构建环境来大规模支持企业工作负载。

部署企业基础蓝图后,您可以直接部署工作负载,也可以部署其他蓝图以支持需要额外功能的复杂工作负载。

纵深防御安全模型

Google Cloud 服务受益于底层的 Google 基础架构安全设计。您负责在 Google Cloud之上构建的系统中设计安全机制。企业基础蓝图可帮助您为服务和工作负载实现纵深防御安全模型。 Google Cloud

下图展示了Google Cloud 组织的纵深防御安全模型,该模型结合了架构控制、政策控制和检测性控制。

纵深防御安全模型。

下图介绍了以下控制:

  • 政策控制属于程序化限制条件,用于强制执行可接受的资源配置并防止进行有风险的配置。此蓝图结合使用了政策控制(包括流水线中的基础设施即代码 (IaC) 验证)和组织政策限制条件。
  • 架构控制是 Google Cloud资源(如网络和资源层次结构)的配置。此蓝图架构基于安全最佳实践。
  • 借助检测性控制,您可以检测组织内的异常行为或恶意行为。此蓝图使用 Security Command Center 等平台功能,与安全运维中心 (SOC) 等现有检测控制和工作流集成,并提供强制执行自定义检测性控制的功能。

主要决策

本部分汇总了该蓝图的架构概要决策。

该蓝图中的关键 Google Cloud 服务。

下图说明了 Google Cloud 服务如何有助于做出关键架构决策:

  • Cloud Build:基础设施资源使用 GitOps 模型进行管理。声明式 IaC 是使用 Terraform 编写的,并在版本控制系统中接受管理以供审核和批准,资源使用 Cloud Build 作为持续集成和持续部署 (CI/CD) 自动化工具进行部署。流水线还强制执行政策即代码检查,以在部署前验证资源是否符合预期配置。
  • Cloud Identity:从现有身份提供方同步用户和群组成员资格。用户账号生命周期管理和单点登录 (SSO) 的控制依赖于身份提供方的现有控制和流程。
  • Identity and Access Management (IAM):允许政策(以前称为 IAM 政策)允许访问资源,并根据作业功能应用于群组。系统会将用户添加到相应的群组,以获得对基础资源的“只能查看”权限。对基础资源的所有更改都通过 CI/CD 流水线进行部署,该流水线使用特权服务账号身份。
  • Resource Manager:所有资源都由单个组织管理,并且文件夹资源层次结构按环境组织项目。项目标有元数据(包括费用归属)以方便进行治理。
  • 网络:网络拓扑使用共享 VPC 为跨多个区域和可用区的工作负载提供网络资源,这些资源按环境分隔并集中管理。本地主机、 Google Cloud VPC 网络中的资源 Google Cloud 和服务之间的所有网络路径都是专用的。默认情况下,不允许出站流量前往公共互联网或入站流量来自公共互联网。
  • Cloud Logging:汇总日志接收器配置为将与安全和审核相关的日志收集到一个集中项目中,以进行长期保留、分析以及导出到外部系统。
  • 组织政策服务:组织政策限制条件配置为防止各种高风险的配置。
  • Secret Manager:为负责管理和审核敏感应用密文的使用的团队创建集中式项目,以帮助满足合规性要求。
  • Cloud Key Management Service (Cloud KMS):为负责管理和审核加密密钥的团队创建集中式项目,以帮助满足合规性要求。
  • Security Command Center:Security Command Center 的内置安全控制和可用于检测和响应安全事件的自定义解决方案相结合,提供了威胁检测和监控功能。

如需了解这些主要决策的替代方案,请参阅替代方案

后续步骤

身份验证和授权

本部分介绍如何使用 Cloud Identity 来管理员工用于访问 Google Cloud服务的身份

外部身份提供方作为可靠来源

我们建议您将 Cloud Identity 账号与现有身份提供方联合。联合可帮助您确保现有账号管理流程适用于 Google Cloud 和其他 Google 服务。

如果您还没有身份提供方,则可以直接在 Cloud Identity 中创建用户账号。

下图简要展示了身份联合和单点登录 (SSO)。它使用位于本地环境中的 Microsoft Active Directory 作为示例身份提供方。

外部身份提供方联合。

下图介绍了以下最佳实践:

  • 用户身份在本地环境的 Active Directory 域中接受管理并与 Cloud Identity 联合。Active Directory 使用 Google Cloud Directory Sync 为 Cloud Identity 预配身份。
  • 尝试登录 Google 服务的用户将被重定向到外部身份提供方以使用 SAML 进行单点登录,其使用其现有凭据进行身份验证。没有密码会与 Cloud Identity 同步。

下表提供了各身份提供方对应的设置指南的链接。

我们强烈建议您在身份提供方处使用防网上诱骗机制(例如 Titan 安全密钥)强制执行多重身份验证。

Cloud Identity 的推荐设置并非通过此蓝图中的 Terraform 代码自动执行。如需了解除了部署 Terraform 代码之外还必须配置的推荐安全设置,请参阅 Cloud Identity 管理控制

访问权限控制群组

主账号是一种可被授予资源访问权限的身份。主账号包括用户的 Google 账号、Google 群组、Google Workspace 账号、Cloud Identity 网域和服务账号。某些服务还允许您向使用 Google 账号进行身份验证的所有用户或互联网上的所有用户授予访问权限。为了让主账号能够与 Google Cloud 服务进行交互,您必须在 Identity and Access Management (IAM) 中为其授予角色。

要大规模管理 IAM 角色,我们建议您根据用户的工作职能和访问权限要求将用户分配给相应群组,然后为这些群组授予 IAM 角色。您应按照现有身份提供方中的流程将用户添加到群组,以创建群组和授予成员资格。

我们不建议向单个用户授予 IAM 角色,因为单独的分配可能会增加管理和审核角色的复杂性。

此蓝图将配置群组和角色,使其对基础资源拥有“只能查看”权限。我们建议您通过基础流水线部署蓝图中的所有资源,并且不要向群组用户授予可在流水线外修改基础资源的角色。

下表显示了该蓝图配置的可查看基础资源的群组。

名称 说明 角色 范围
grp-gcp-org-admin@example.com 可以在组织级层授予 IAM 角色的高权限管理员。他们可以访问任何其他角色。不建议在日常使用此特权。 组织管理员 组织
grp-gcp-billing-admin@example.com 可以修改 Cloud Billing 账号的高权限管理员。不建议在日常使用此特权。 结算账号管理员 组织
grp-gcp-billing-viewer@example.com 负责查看和分析所有项目的支出的团队。 Billing Account Viewer 组织
BigQuery User 结算项目
grp-gcp-audit-viewer@example.com 负责审核安全相关日志的团队。

Logs Viewer

BigQuery User

日志记录项目
grp-gcp-security-reviewer@example.com 负责审核云安全的团队。 Security Reviewer 组织
grp-gcp-network-viewer@example.com 负责查看和维护网络配置的团队。 Compute Network Viewer 组织
grp-gcp-scc-admin@example.com 负责配置 Security Command Center 的团队。 Security Center Admin Editor 组织
grp-gcp-secrets-admin@example.com 负责管理、存储和审核应用使用的凭据和其他密文的团队。 Secret Manager Admin Secret 项目
grp-gcp-kms-admin@example.com 负责强制执行加密密钥管理以满足合规性要求的团队。 Cloud KMS Viewer KMS 项目

在基础上构建自己的工作负载时,您可以创建其他群组并授予基于每个工作负载的访问权限要求的 IAM 角色。

我们强烈建议您避免使用基本角色(例如 Owner、Editor 或 Viewer),而是使用预定义角色。基本角色过于宽松,可能存在安全风险。Owner 和 Editor 角色可能会导致提升权限和横向移动,而 Viewer 角色包括可读取所有数据的权限。如需了解 IAM 角色的最佳实践,请参阅安全使用 IAM

超级用户账号

拥有超级用户账号的 Cloud Identity 用户会绕过组织的 SSO 设置并直接向 Cloud Identity 进行身份验证。这种例外情况是故意为之,以便在 SSO 配置错误或中断时,超级用户仍然可以访问 Cloud Identity 控制台。但是,这意味着您必须考虑为超级用户账号提供额外的保护。

为了保护您的超级用户账号,我们建议您始终使用 Cloud Identity 中的安全密钥强制执行两步验证。有关信息,请参阅管理员账号的安全最佳实践

消费者用户账号问题

如果您在开始使用 Google Cloud之前未使用过 Cloud Identity 或 Google Workspace,则贵组织的员工可能已经在使用与其公司电子邮件身份关联的消费者账号来访问 Google Marketing Platform 或 YouTube 等其他 Google 服务。消费者账号完全由创建账号的个人拥有和管理。由于这些账号不受组织控制,并且可能同时包含个人和公司数据,因此您必须决定如何将这些账号与其他公司账号整合起来。

我们建议您在加入 Google Cloud时整合现有消费者用户账号。如果您尚未将 Google Workspace 用于所有用户账号,我们建议限制创建新的消费者账号

Cloud Identity 的管理控制

Cloud Identity 具有各种管理控制,但 Terraform 代码在蓝图中不会自动执行这些控制。我们建议您在构建基础的过程中尽早执行每个最佳实践安全控制。

控制 说明
部署两步验证

用户账号可能通过钓鱼式攻击、社会工程学、密码泄露或各种其他威胁被破解。两步验证有助于减轻这些威胁。

我们建议您使用防范网上诱骗机制(例如 Titan 安全密钥或基于防范网上诱骗 FIDO U2F (CTAP1) 标准的其他密钥)对组织中的所有用户账号强制执行两步验证机制。

设置Google Cloud 服务的会话时长 开发者工作站上的永久性 OAuth 令牌若公开,可能会带来安全风险。我们建议您将重新身份验证政策设置为每 16 小时使用一次安全密钥进行身份验证。
设置 Google 服务的会话时长 (仅限 Google Workspace 客户)

其他 Google 服务中的持久 Web 会话如果公开,可能会带来安全风险。我们建议您强制执行网络会话时长上限,并将其与 SSO 提供方中的会话长度控制保持一致。

将 Cloud Identity 中的数据与 Google Cloud 服务共享

来自 Google Workspace 或 Cloud Identity 的管理员活动审核日志通常在管理控制台中管理和查看,与 Google Cloud 环境中的日志分开。这些日志包含与您的 Google Cloud 环境相关的信息,例如用户登录事件。

我们建议您将 Cloud Identity 审核日志共享到您的Google Cloud 环境,以便集中管理来自所有来源的日志。

设置单点登录后验证

此蓝图假定您使用外部身份提供方设置单点登录。

我们建议您根据 Google 的登录风险分析启用额外的控制层。应用此设置后,如果 Google 认为用户登录可疑,则用户可能会在登录时看到其他基于风险的登录验证。

修复消费者用户账号的问题

具有您网域中的有效电子邮件地址,但没有 Google 账号的用户可以注册不受管理的消费者账号。这些账号可能包含公司数据,但不受账号生命周期管理流程的控制。

我们建议您采取措施来确保所有用户账号都是受管理的账号。

对超级用户账号停用账号恢复

所有新客户的超级用户账号自行恢复功能在默认情况下关闭(现有客户可能启用了此设置)。关闭此设置有助于降低攻击者利用遭到入侵的手机、被盗用的电子邮件或社会工程学攻击获得对您的环境的超级用户特权的风险。

规划超级用户在无法访问其账号时联系组织内的其他超级用户所需的内部流程,并确保所有超级用户都熟悉支持团队协助的恢复流程。

强制执行和监控用户的密码要求 在大多数情况下,用户密码通过外部身份提供方管理,但超级用户账号会绕过 SSO,必须使用密码登录 Cloud Identity。对使用密码登录 Cloud Identity 的任何用户(尤其是超级用户账号)停用密码重用并监控密码强度。
为群组的使用设置组织级政策

默认情况下,外部用户账号可以添加到 Cloud Identity 中的群组。我们建议您配置共享设置,以免群组所有者添加外部成员。

请注意,此限制不适用于超级用户账号或拥有群组管理员权限的其他委派管理员。由于身份提供方的联合服务运行时需要使用管理员权限,因此群组共享设置不适用于此群组同步。我们建议您查看身份提供方和同步机制中的控制,确保非网域成员不会添加到群组,或者确保您将应用群组限制

后续步骤

组织结构

在 Google Cloud 中用于管理资源的根节点是组织。 Google Cloud 组织提供了资源层次结构,为组织政策和访问权限控制的资源和连接点提供所有权结构。资源层次结构由文件夹、项目和资源组成,它定义了组织内 Google Cloud 服务的结构和使用。

层次结构中较低层次的资源会继承 IAM 允许政策和组织政策等政策。默认情况下,所有访问权限都会被拒绝,直到您将允许政策直接应用于资源或资源从资源层次结构中的更高级层继承允许政策为止。

下图展示了蓝图部署的文件夹和项目。

example.com 组织结构。

以下部分介绍了图中的文件夹和项目。

文件夹

此蓝图使用文件夹来根据项目的环境对项目进行分组。此逻辑分组用于在文件夹级层应用允许政策和组织政策等配置,然后文件夹中的所有资源都会继承这些政策。下表介绍了此蓝图中的文件夹。

文件夹 说明
bootstrap 包含用于部署基础组件的项目。
common 包含资源由所有环境共享的项目。
production 包含具有生产资源的项目。
nonproduction 包含生产环境的副本,可用于在将工作负载升级到生产环境之前对其进行测试。
development 包含用于开发的云资源。
networking 包含所有环境共享的网络资源。

项目

此蓝图根据资源的功能和访问权限控制的预期边界,使用项目对单独的资源进行分组。下表介绍了蓝图中包含的项目。

文件夹 项目 说明
bootstrap prj-b-cicd 包含用于构建组织基础组件的部署流水线。如需了解详情,请参阅部署方法
prj-b-seed 包含基础设施的 Terraform 状态和运行流水线所需的 Terraform 服务账号。如需了解详情,请参阅部署方法
common prj-c-secrets 包含组织级密文。如需了解详情,请参阅使用 Secret Manager 存储应用凭据
prj-c-logging 包含审核日志的聚合日志源。如需了解详情,请参阅用于安全和审核用途的中心化日志
prj-c-scc 包含有助于配置 Security Command Center 提醒和其他自定义安全监控的资源。如需了解详情,请参阅使用 Security Command Center 进行威胁监控
prj-c-billing-export 包含具有组织账单导出功能的 BigQuery 数据集。如需了解详情,请参阅在内部成本中心之间分配费用
prj-c-infra-pipeline 包含用于部署工作负载要使用的虚拟机和数据库等资源的基础设施流水线。如需了解详情,请参阅流水线层
prj-c-kms 包含组织级加密密钥。如需了解详情,请参阅管理加密密钥
networking prj-net-{env}-shared-base 包含共享 VPC 网络的宿主项目,适用于不需要 VPC Service Controls 的工作负载。如需了解详情,请参阅网络拓扑
prj-net-{env}-shared-restricted 包含共享 VPC 网络的宿主项目,用于需要 VPC Service Controls 的工作负载。如需了解详情,请参阅网络拓扑
prj-net-interconnect 包含在本地环境和Google Cloud之间提供连接的 Cloud Interconnect 连接。如需了解详情,请参阅混合连接
prj-net-dns-hub 包含本地 DNS 系统和 Cloud DNS 之间的中心通信点的资源。如需了解详情,请参阅集中式 DNS 设置
prj-{env}-secrets 包含文件夹级密文。如需了解详情,请参阅使用 Secret Manager 存储和审核应用凭据
prj-{env}-kms 包含文件夹级加密密钥。如需了解详情,请参阅管理加密密钥
应用项目 包含您在其中为应用创建资源的各种项目。如需了解详情,请参阅项目部署模式流水线层

资源所有权治理

我们建议您始终为项目应用标签,以辅助治理和费用分配。下表介绍了添加到每个项目以便在蓝图中进行治理的项目标签。

标签 说明
application 与项目关联的应用或工作负载的简单易懂名称。
businesscode 用于描述项目所属业务部门的短代码。代码 shared 用于表示未与任何业务部门明确关联的常见项目。
billingcode 用于提供退款信息的代码。
primarycontact 负责项目的主要联系人的用户名。由于项目标签不能包含特殊字符(如符号 @),因此它设置为不带 @example.com 后缀的用户名。
secondarycontact 负责项目的次要联系人的用户名。由于项目标签不能包含特殊字符(例如 @),因此请仅设置没有 @example.com 后缀的用户名。
environment 用于标识环境类型的值,例如 bootstrapcommonproductionnon-production,developmentnetwork.
envcode 用于标识环境类型的值,缩写形式为 bcpndnet
vpc 此项目预期使用的 VPC 网络的 ID。

Google 可能偶尔会发送重要通知,例如账号中止或产品条款更新。此蓝图使用重要联系人将这些通知发送到您在部署期间配置的群组。重要联系人在组织节点上配置,并由组织中的所有项目继承。我们建议您查看这些群组并确保电子邮件受到可靠监控。

重要联系人的用途与项目标签中所配置的 primarycontactsecondarycontact 字段的用途不同。项目标签中的联系人适用于内部治理。例如,如果您在工作负载项目中发现不合规的资源并需要联系所有者,则可以使用 primarycontact 字段查找负责该工作负载的人员或团队。

后续步骤

  • 了解网络(本系列的下一个文档)。

网络

资源在您的 Google Cloud组织内部以及在云环境和本地环境之间通信需要网络。本部分介绍蓝图中 VPC 网络、IP 地址空间、DNS、防火墙政策以及与本地环境的连接的结构。

网络拓扑

蓝图仓库为您的网络拓扑提供以下选项:

  • 对每个环境使用单独的共享 VPC 网络,并且不同环境之间不允许直接传输网络流量。
  • 使用中心辐射型模型来添加 hub 网络,以连接 Google Cloud中每个环境,并通过网络虚拟设备 (NVA) 控制环境之间的网络流量。

如果您不想在环境之间存在直接的网络连接,请选择双共享 VPC 网络拓扑。当想要在环境之间允许由 NVA 过滤的网络连接时,例如当您依赖的现有工具需要有一个直接网络路径连接您环境中每个服务器时,请选择中心辐射型网络拓扑

这两种拓扑使用共享 VPC 作为主网络结构,因为共享 VPC 可明确划分职责。网络管理员在集中式宿主项目中管理网络资源,而工作负载团队在附加到宿主项目的服务项目中部署他们自己的应用资源并使用网络资源。

这两种拓扑都包含每个 VPC 网络的基本版本和受限版本。基本 VPC 网络用于包含非敏感数据的资源,而受限 VPC 网络用于包含敏感数据且需要 VPC Service Controls 的资源。如需详细了解如何实现 VPC Service Controls,请参阅使用 VPC Service Controls 保护您的资源

双共享 VPC 网络拓扑

如果您需要在 Google Cloud上的开发网络、非生产网络和生产网络之间进行网络隔离,我们建议使用双共享 VPC 网络拓扑。此拓扑为每个环境使用单独的共享 VPC 网络,并且每个环境会另外在基本共享 VPC 网络和受限共享 VPC 网络之间拆分。

下图显示了双共享 VPC 网络拓扑。

蓝图 VPC 网络。

该图描述了双共享 VPC 拓扑的以下主要概念:

  • 每种环境(生产、非生产和开发)都会为基本网络配置一个共享 VPC 网络,为受限网络配置一个共享 VPC 网络。此图仅显示生产环境,但每个环境都采用此同一模式。
  • 每个共享 VPC 网络都有两个子网,各子网位于不同的区域中。
  • 通过使用四个 Cloud Router 服务(每个区域两个以实现冗余)与每个共享 VPC 网络的专用互连实例建立四个 VLAN 连接,从而实现与本地资源的连接。如需了解详情,请参阅本地环境与 Google Cloud之间的混合连接

根据设计,此拓扑不允许网络流量直接在环境之间流动。如果您确实需要网络流量直接在环境之间流动,则必须执行额外步骤才能允许此网络路径。例如,您可以配置 Private Service Connect 端点,以将服务从一个 VPC 网络公开给另一个 VPC 网络。或者,您可以配置本地网络,以允许流量从一个Google Cloud 环境流向本地环境,然后流向另一个 Google Cloud 环境。

中心辐射型网络拓扑

如果您在 Google Cloud 中部署的资源需要有一个直接网络路径来连接多个环境中的资源,我们建议使用中心辐射型网络拓扑。 Google Cloud

中心辐射型拓扑虽然使用了双共享 VPC 拓扑中的几个概念,但它可修改拓扑以添加 hub 网络。下图展示了中心辐射型拓扑。

使用基于 VPC 对等互连的中心辐射型连接时的 example.com VPC 网络结构

该图描述了中心辐射型网络拓扑的以下主要概念:

  • 此模型添加了一个 hub 网络,每个开发网络、非生产网络和生产网络 (spoke) 都通过 VPC 网络对等互连连接到 hub 网络。或者,如果您预计会超出配额限制,则可以改用高可用性 VPN 网关
  • 仅允许通过 hub 网络连接到本地网络。所有 spoke 网络都可以与 hub 网络中的共享资源通信,并使用此路径连接到本地网络。
  • hub 网络包括每个区域在内部网络负载均衡器实例后冗余部署的 NVA。此 NVA 充当网关,以允许或拒绝流量在 spoke 网络之间进行通信。
  • hub 网络还托管需要连接到所有其他网络的工具。例如,您可以将用于配置管理的虚拟机实例上的工具部署到通用环境。
  • 每个网络的基本版本和受限版本都具有相同的中心辐射型模型。

为了实现 spoke 之间的流量传输,该蓝图会在 hub 共享 VPC 网络上部署 NVA,以充当网络之间的网关。路由通过自定义路由交换从 hub VPC 网络交换到 spoke VPC 网络。在这种情况下,spoke 之间的连接必须通过 NVA 进行路由,因为 VPC 网络对等互连不具有传递性,因此 spoke VPC 网络之间无法直接相互交换数据。您必须将虚拟设备配置为有选择地允许 spoke 之间的流量。

项目部署模式

为工作负载创建新项目时,您必须确定此项目中的资源如何连接到现有网络。下表介绍了蓝图中使用的项目部署模式。

模式 说明 用法示例
共享基本项目

这些项目作为服务项目配置到基本共享 VPC 宿主项目。

当项目中的资源符合以下条件时,请使用此模式:

  • 需要与本地环境或同一共享 VPC 拓扑中的资源建立网络连接。
  • 需要一个网络路径连接专用虚拟 IP 地址中包含的 Google 服务。
  • 不需要 VPC Service Controls。
example_base_shared_vpc_project.tf
共享受限项目

这些项目作为服务项目配置到受限共享 VPC 宿主项目。

当项目中的资源符合以下条件时,请使用此模式:

  • 需要与本地环境或同一共享 VPC 拓扑中的资源建立网络连接。
  • 需要一个网络路径连接受限虚拟 IP 地址中包含的 Google 服务。
  • 需要 VPC Service Controls。
example_restricted_shared_vpc_project.tf
悬浮项目

悬浮项目未连接到拓扑中的其他 VPC 网络。

当项目中的资源符合以下条件时,请使用此模式:

  • 不需要与本地环境或共享 VPC 拓扑中的资源建立全网状连接。
  • 不需要 VPC 网络,或者您希望不考虑主 VPC 网络拓扑来管理此项目的 VPC 网络时(例如,当您想要使用与已用范围冲突的 IP 地址范围时)。

您可能遇到这样的情况:您希望将悬浮项目的 VPC 网络与主 VPC 网络拓扑分开,但还希望在网络之间公开有限数量的端点。 在这种情况下,请使用 Private Service Connect 发布服务,以跨 VPC 网络共享对单个端点的网络访问权限,但不公开整个网络。

example_floating_project.tf
对等互连项目

对等互连项目会创建自己的 VPC 网络,并与拓扑中的其他 VPC 网络建立对等互连。

当项目中的资源符合以下条件时,请使用此模式:

  • 需要在直接对等互连的 VPC 网络中建立网络连接,但不需要与本地环境或其他 VPC 网络建立传递性连接。
  • 管理此项目的 VPC 网络,而不考虑主网络拓扑。

如果您创建了对等互连项目,则有责任分配非冲突的 IP 地址范围并规划对等互连组配额

example_peering_project.tf

IP 地址分配

本部分介绍蓝图架构如何分配 IP 地址范围。您可能需要根据现有混合环境中的 IP 地址可用性更改所使用的特定 IP 地址范围。

下表提供了为蓝图分配的 IP 地址空间的明细。中心环境仅适用于中心辐射型拓扑。

用途 VPC 类型 区域 中心环境 开发环境 非生产环境 生产环境
主要子网范围 基本 区域 1 10.0.0.0/18 10.0.64.0/18 10.0.128.0/18 10.0.192.0/18
区域 2 10.1.0.0/18 10.1.64.0/18 10.1.128.0/18 10.1.192.0/18
未分配 10.{2-7}.0.0/18 10.{2-7}.64.0/18 10.{2-7}.128.0/18 10.{2-7}.192.0/18
受限 区域 1 10.8.0.0/18 10.8.64.0/18 10.8.128.0/18 10.8.192.0/18
区域 2 10.9.0.0/18 10.9.64.0/18 10.9.128.0/18 10.9.192.0/18
未分配 10.{10-15}.0.0/18 10.{10-15}.64.0/18 10.{10-15}.128.0/18 10.{10-15}.192.0/18
专用服务访问通道 基本 全球 10.16.0.0/21 10.16.8.0/21 10.16.16.0/21 10.16.24.0/21
受限 全球 10.16.32.0/21 10.16.40.0/21 10.16.48.0/21 10.16.56.0/21
Private Service Connect 端点 基本 全球 10.17.0.1/32 10.17.0.2/32 10.17.0.3/32 10.17.0.4/32
受限 全球 10.17.0.5/32 10.17.0.6/32 10.17.0.7/32 10.17.0.8/32
代理专用子网 基本 区域 1 10.18.0.0/23 10.18.2.0/23 10.18.4.0/23 10.18.6.0/23
区域 2 10.19.0.0/23 10.19.2.0/23 10.19.4.0/23 10.19.6.0/23
未分配 10.{20-25}.0.0/23 10.{20-25}.2.0/23 10.{20-25}.4.0/23 10.{20-25}.6.0/23
受限 区域 1 10.26.0.0/23 10.26.2.0/23 10.26.4.0/23 10.26.6.0/23
区域 2 10.27.0.0/23 10.27.2.0/23 10.27.4.0/23 10.27.6.0/23
未分配 10.{28-33}.0.0/23 10.{28-33}.2.0/23 10.{28-33}.4.0/23 10.{28-33}.6.0/23
次要子网范围 基本 区域 1 100.64.0.0/18 100.64.64.0/18 100.64.128.0/18 100.64.192.0/18
区域 2 100.65.0.0/18 100.65.64.0/18 100.65.128.0/18 100.65.192.0/18
未分配 100.{66-71}.0.0/18 100.{66-71}.64.0/18 100.{66-71}.128.0/18 100.{66-71}.192.0/18
受限 区域 1 100.72.0.0/18 100.72.64.0/18 100.72.128.0/18 100.72.192.0/18
区域 2 100.73.0.0/18 100.73.64.0/18 100.73.128.0/18 100.73.192.0/18
未分配 100.{74-79}.0.0/18 100.{74-79}.64.0/18 100.{74-79}.128.0/18 100.{74-79}.192.0/18

下表展示了以下分配 IP 地址范围的概念:

  • IP 地址分配可细分为基本共享 VPC、受限共享 VPC、区域和环境的每个组合的范围。
  • 某些资源是全球性的,不需要对每个区域进行细分。
  • 默认情况下,对于区域级资源,蓝图将部署在两个区域中。此外,还有未使用的 IP 地址范围,因此您可以再扩展六个区域。
  • hub 网络仅用于中心辐射型网络拓扑,而开发、非生产和生产环境可用于这两种网络拓扑。

下表介绍了每种 IP 地址范围的使用方式。

用途 说明
主要子网范围 您部署到 VPC 网络的资源(例如虚拟机实例)会使用这些范围内的内部 IP 地址。
专用服务访问通道 某些 Google Cloud 服务(例如 Cloud SQL)要求您为专用服务访问通道预先分配子网范围。此蓝图在全球范围内为每个共享 VPC 网络预留一个 /21 范围,以便为需要专用服务访问通道的服务分配 IP 地址。创建依赖于专用服务访问通道的服务时,您可以从预留的 /21 范围分配区域级 /24 子网。
Private Service Connect 此蓝图为每个 VPC 网络预配了一个 Private Service Connect 端点,以便与 Google Cloud API 通信。此端点允许 VPC 网络中的资源访问 Google Cloud API,而无需依赖流向互联网或公开通告的互联网范围的出站流量。
基于代理的负载均衡器 某些类型的应用负载均衡器要求您预先分配代理专用子网。虽然蓝图不会部署需要此范围的应用负载均衡器,但提前分配范围有助于在工作负载需要请求新子网范围以启用特定负载均衡器资源时减少冲突。
次要子网范围 某些用例(例如基于容器的工作负载)需要次要范围。此蓝图会为次要范围分配 RFC 6598 IP 地址空间中的范围。

集中式 DNS 设置

对于 Google Cloud 和本地环境之间的 DNS 解析,我们建议您在两个权威 DNS 系统中使用混合方法。 Google Cloud 在此方法中,Cloud DNS 会处理Google Cloud 环境的权威 DNS 解析,而您现有的本地 DNS 服务器会处理本地资源的权威 DNS 解析。您的本地环境和 Google Cloud 环境通过转发请求在环境之间执行 DNS 查找。

下图展示了蓝图中使用的多个 VPC 网络中的 DNS 拓扑。

蓝图的 Cloud DNS 设置。

该图描述了蓝图部署的 DNS 设计的以下组件:

  • 通用文件夹中的 DNS 中心项目是本地环境和 Google Cloud环境之间的 DNS 交换中心。DNS 转发使用已在您的网络拓扑中配置的专用互连实例和 Cloud Router 路由器。
    • 在双共享 VPC 拓扑中,DNS 中心使用基本生产共享 VPC 网络。
    • 在中心辐射型拓扑中,DNS 中心使用基本中心共享 VPC 网络。
  • 每个共享 VPC 网络中的服务器都可以通过每个共享 VPC 宿主项目中的 Cloud DNS 和 DNS 中心之间配置的 DNS 转发解析其他共享 VPC 网络中的 DNS 记录。
  • 本地服务器可以使用允许来自本地服务器的查询的 DNS 服务器政策来解析 Google Cloud环境中的 DNS 记录。此蓝图在 DNS 中心配置入站服务器政策,以分配 IP 地址,而本地 DNS 服务器会将请求转发到这些地址。发送到 Google Cloud 的所有 DNS 请求都会先到达 DNS 中心,然后该中心再解析来自 DNS 对等体的记录。
  • Google Cloud 中的服务器可以使用查询本地服务器的转发区域来解析本地环境中的 DNS 记录。发送到本地环境的所有 DNS 请求都来自 DNS 中心。DNS 请求来源为 35.199.192.0/19。

防火墙政策

Google Cloud 具有多种防火墙政策类型。分层防火墙政策在组织或文件夹级层强制执行,从而在层次结构的所有资源中一致继承防火墙政策规则。此外,您还可以为每个 VPC 网络配置网络防火墙政策。此蓝图兼备这些防火墙政策,可使用分层防火墙政策在所有环境中强制执行通用配置,使用网络防火墙政策在每个 VPC 网络上强制执行更具体的配置。

此蓝图不使用旧版 VPC 防火墙规则。我们建议仅使用防火墙政策,从而避免与旧版 VPC 防火墙规则混用。

分层防火墙政策

此蓝图定义了一个分层防火墙政策,并将该政策附加到每个生产、非生产、开发、引导和通用文件夹。此分层防火墙政策包含应在所有环境中广泛强制执行的规则,并将更精细规则的评估委托给每个环境的网络防火墙政策。

下表介绍了此蓝图部署的分层防火墙政策规则。

规则说明 流量方向 过滤条件(IPv4 范围) 协议和端口 操作
将来自 RFC 1918 的入站流量评估委托给层次结构中的较低级层。 Ingress

192.168.0.0/16、10.0.0.0/8、172.16.0.0/12

all Go to next
将流向 RFC 1918 的出站流量评估委托给层次结构中的较低级层。 Egress

192.168.0.0/16、10.0.0.0/8、172.16.0.0/12

all Go to next
使用 IAP 进行 TCP 转发 Ingress

35.235.240.0/20

tcp:22,3390 Allow
Windows 服务器激活 Egress

35.190.247.13/32

tcp:1688 Allow
Cloud Load Balancing 健康检查 Ingress

130.211.0.0/22、35.191.0.0/16、209.85.152.0/22、209.85.204.0/22

tcp:80,443 Allow

网络防火墙政策

此蓝图为每个网络配置一个网络防火墙政策。每项网络防火墙政策开始时都是一组最低权限规则,这些规则允许访问 Google Cloud 服务并拒绝流向所有其他 IP 地址的出站流量。

在中心辐射型模型中,网络防火墙政策包含允许 spoke 之间通信的额外规则。网络防火墙政策允许从一个 spoke 到 hub 或其他 spoke 的出站流量,并允许来自 hub 网络中的 NVA 的入站流量。

下表介绍了蓝图中为每个 VPC 网络部署的全球网络防火墙政策中的规则。

规则说明 流量方向 过滤 协议和端口
允许流向 Google Cloud API 的出站流量。 Egress 为每个网络配置的 Private Service Connect 端点。请参阅 Google API 专用访问通道 tcp:443
拒绝其他规则不匹配的出站流量。 Egress 全部 all

允许从一个 spoke 流向另一个 spoke 的出站流量(仅适用于中心辐射型模型)。

Egress 中心辐射型拓扑中使用的所有 IP 地址的聚合。离开 spoke VPC 的流量会先路由到 hub 网络中的 NVA。 all

允许从 hub 网络中的 NVA 流向 spoke 的入站流量(仅适用于中心辐射型模型)。

Ingress 源自 hub 网络中的 NVA 的流量。 all

首次部署蓝图时,VPC 网络中的虚拟机实例可以与 Google Cloud 服务通信,但不能与同一 VPC 网络中的其他基础架构资源通信。如需允许虚拟机实例进行通信,您必须向网络防火墙政策添加额外的规则并添加明确允许虚拟机实例通信的标记。标记会添加到虚拟机实例,系统会针对这些标记评估流量。此外,标记还具有 IAM 控件,因此您可以集中定义它们并将其使用委托给其他团队。

下图举例说明了如何添加自定义标记和网络防火墙政策规则,以允许工作负载在 VPC 网络内进行通信。

example.com 中的防火墙规则。

下图演示了此示例的以下概念:

  • 网络防火墙政策包含规则 1,该规则拒绝来自所有来源的出站流量(优先级为 65530)。
  • 网络防火墙政策包含规则 2,该规则允许入站流量从具有 service=frontend 标记的实例进入具有 service=backend 标记的实例,优先级为 999。
  • instance-2 虚拟机可以接收来自 instance-1 的流量,因为该流量与规则 2 允许的标记匹配。根据优先级值评估在规则 1 前匹配的规则 2。
  • instance-3 虚拟机不接收流量。唯一与此流量匹配的防火墙政策规则是规则 1,因此来自 instance-1 的出站流量会被拒绝。

Google Cloud API 的专用访问通道

如需让 VPC 网络或本地环境中的资源访问Google Cloud 服务,我们建议使用专用连接,而不是到公共 API 端点的出站互联网流量。此蓝图在每个子网上配置专用 Google 访问通道,并使用 Private Service Connect 创建内部端点以与 Google Cloud 服务通信。通过综合利用这些控制,您可以使用专用路径连接 Google Cloud 服务,而无需依赖互联网出站流量或公开通告的互联网范围。

此蓝图使用 API 软件包配置 Private Service Connect 端点,以区分可以在哪个网络中访问哪些服务。基本网络使用 all-apis 软件包,可以访问任何 Google 服务,而受限网络使用 vpcsc 软件包,可以访问支持 VPC Service Controls 的一组有限服务。

如需从本地环境中的主机进行访问,我们建议您对每个端点使用自定义 FQDN 惯例,如下表所示。此蓝图对每个 VPC 网络使用唯一的 Private Service Connect 端点,这些端点配置为访问一组不同的 API 软件包。因此,您必须考虑如何将服务流量从本地环境路由到具有正确 API 端点的 VPC 网络,并且如果您使用的是 VPC Service Controls,请确保流向 Google Cloud 服务的流量到达预期边界内的端点。为 DNS、防火墙和路由器配置本地控制以允许访问这些端点,并将本地主机配置为使用适当的端点。如需了解详情,请参阅通过端点访问 Google API

下表介绍了为每个网络创建的 Private Service Connect 端点。

VPC 环境 API 软件包 Private Service Connect 端点 IP 地址 自定义 FQDN
基本 常用 all-apis 10.17.0.1/32 c.private.googleapis.com
开发 all-apis 10.17.0.2/32 d.private.googleapis.com
非生产 all-apis 10.17.0.3/32 n.private.googleapis.com
生产 all-apis 10.17.0.4/32 p.private.googleapis.com
受限 常用 vpcsc 10.17.0.5/32 c.restricted.googleapis.com
开发 vpcsc 10.17.0.6/32 d.restricted.googleapis.com
非生产 vpcsc 10.17.0.7/32 n.restricted.googleapis.com
生产 vpcsc 10.17.0.8/32 p.restricted.googleapis.com

为确保 Google Cloud 服务的流量通过 DNS 查找进入正确端点,此蓝图会为每个 VPC 网络配置专用 DNS 区域。下表介绍了这些专用 DNS 区域。

专用区域名称 DNS 名称 记录类型 数据
googleapis.com. *.googleapis.com. CNAME private.googleapis.com.(针对基本网络)或 restricted.googleapis.com.(针对受限网络)
private.googleapis.com(针对基本网络)或 restricted.googleapis.com(针对受限网络) A 该 VPC 网络的 Private Service Connect 端点 IP 地址。
gcr.io. *.gcr.io CNAME gcr.io.
gcr.io A 该 VPC 网络的 Private Service Connect 端点 IP 地址。
pkg.dev. *.pkg.dev. CNAME pkg.dev.
pkg.dev. A 该 VPC 网络的 Private Service Connect 端点 IP 地址。

此蓝图具有额外的配置,可强制一致使用这些 Private Service Connect 端点。每个共享 VPC 网络还会强制执行以下政策:

  • 允许出站流量从所有来源流向 TCP 443 上 Private Service Connect 端点的 IP 地址的网络防火墙政策规则。
  • 拒绝出站流量流向 0.0.0.0/0(包括用于访问 Google Cloud 服务的默认网域)的网络防火墙政策规则。

互联网连接

此蓝图不允许其 VPC 网络与互联网之间的入站或出站流量。对于需要互联网连接的工作负载,您必须执行额外步骤来设计所需的访问路径。

对于需要出站流量进入互联网的工作负载,我们建议您通过 Cloud NAT 管理出站流量,以在无主动发送的入站连接的情况下允许出站流量,或者通过安全 Web 代理管理出站流量,以实现更精细的控制,从而仅允许出站流量流向可信 Web 服务。

对于需要从互联网传入入站流量的工作负载,我们建议您使用 Cloud Load BalancingGoogle Cloud Armor 设计工作负载以受益于 DDoS 和 WAF 保护。

我们不建议您设计允许在虚拟机上使用外部 IP 地址在互联网与虚拟机之间直接连接的工作负载。

本地环境与 Google Cloud之间的混合连接

如需在本地环境与Google Cloud之间建立连接,我们建议您使用专用互连来最大限度地提高安全性和可靠性。专用互连连接是本地网络与Google Cloud之间的直接链接。

下图展示了本地环境与 Google 虚拟私有云网络之间的混合连接。

混合连接结构。

该图描述了模式的以下组件,以实现专用互连的 99.99% 可用性

  • 四个专用互连连接,其中两个连接在一个都市区(都市圈),两个连接在另一个都市圈。在每个都市圈中,对接网点内有两个不同的可用区。
  • 连接分为两对,每对均连接到单独的本地数据中心。
  • VLAN 连接用于将每个专用互连实例连接到共享 VPC 拓扑附加的 Cloud Router 路由器
  • 每个共享 VPC 网络都有四个 Cloud Router 路由器,每个区域两个,并且动态路由模式设置为 global,以便每个 Cloud Router 路由器可以通告所有子网(无论区域如何)。

通过全局动态路由,Cloud Router 路由器向 VPC 网络中的所有子网通告路由。Cloud Router 路由器向远程子网(Cloud Router 路由器区域以外的子网)通告路由所采用的优先级,低于向本地子网(位于 Cloud Router 路由器区域的子网)通告的优先级。(可选)在为 Cloud Router 路由器配置 BGP 会话时,您可以更改通告的前缀和优先级

从 Google Cloud 到本地环境的流量使用最靠近云资源的 Cloud Router 路由器。在一个区域内,多个到本地网络的路由具有相同的多出口判别器 (MED) 值, Google Cloud 使用等成本多路径 (ECMP) 在所有可能的路由之间分配出站流量。

本地配置更改

如需配置本地环境与Google Cloud之间的连接,您必须在本地环境中配置其他更改。此蓝图中的 Terraform 代码会自动配置Google Cloud 资源,但不会修改任何本地网络资源。

此蓝图会自动启用某些从本地环境到Google Cloud 的混合连接的组件,包括:

  • Cloud DNS 配置了在所有共享 VPC 网络和单个 hub 之间的 DNS 转发,如 DNS 设置中所述。Cloud DNS 服务器政策配置了入站转发器 IP 地址
  • Cloud Router 路由器经过配置,可为 Private Service Connect 端点使用的 IP 地址导出所有子网的路由和自定义路由。

如需启用混合连接,您必须执行以下额外步骤:

  1. 订购专用互连连接
  2. 配置本地路由器和防火墙以允许出站流量进入 IP 地址空间分配中定义的内部 IP 地址空间。
  3. 配置本地 DNS 服务器,以将发往Google Cloud 的 DNS 查找转发到已由蓝图配置的入站转发器 IP 地址
  4. 配置本地 DNS 服务器、防火墙和路由器以接受来自 Cloud DNS 转发区域 (35.199.192.0/19) 的 DNS 查询。
  5. 配置本地 DNS 服务器,以使用 Cloud API 的专用访问通道中定义的 IP 地址响应从本地主机到 Google Cloud 服务的查询。
  6. 对于通过专用互连连接进行的传输加密,请配置 MACsec for Cloud Interconnect 或配置通过 Cloud Interconnect 实现的高可用性 VPN 以进行 IPsec 加密。

如需了解详情,请参阅为本地主机配置专用 Google 访问通道

后续步骤

检测性控制

Security Command Center 的内置安全控制和可用于检测和响应安全事件的自定义解决方案相结合,提供了威胁检测和监控功能。

用于安全和审核用途的中心化日志

此蓝图配置日志记录功能,以使用聚合到单个项目的日志来跟踪和分析 Google Cloud 资源的更改。

下图展示了该蓝图如何将多个项目中多个来源的日志聚合到集中式日志接收器中。

example.com 的日志记录结构。

图中描述了以下内容:

  • 日志接收器在组织节点配置为聚合来自资源层次结构中所有项目的日志。
  • 多个日志接收器配置为将与过滤条件匹配的日志发送到不同的目标位置以进行存储和分析。
  • prj-c-logging 项目包含用于日志存储和分析的所有资源。
  • (可选)您可以配置其他工具以将日志导出到 SIEM。

此蓝图使用不同的日志源,并在日志接收器过滤条件中包含这些日志,以便可以将日志导出到中心目标位置。下表介绍了日志源。

日志源

说明

管理员活动审核日志

您不能配置、停用或排除管理员活动审核日志。

系统事件审核日志

您不能配置、停用或排除系统事件审核日志。

政策拒绝审核日志

您不能配置或停用政策拒绝审核日志,但可以选择使用排除项过滤器来排除这些日志。

数据访问审核日志

默认情况下,蓝图不会启用数据访问日志,因为这些日志的数量和费用可能较高。

如需确定是否应启用数据访问日志,请评估工作负载处理敏感数据的位置,并考虑是否需要为处理敏感数据的每个服务和环境启用数据访问日志。

VPC 流日志

此蓝图将为每个子网启用 VPC 流日志。此蓝图将日志采样配置为对 50% 的日志进行采样,以降低费用。

如果您创建其他子网,则必须确保为每个子网启用 VPC 流日志。

防火墙规则日志记录

此蓝图为每条防火墙政策规则启用防火墙规则日志记录。

如果您为工作负载创建其他防火墙政策规则,则必须确保为每个新规则启用防火墙规则日志记录。

Cloud DNS 日志记录

此蓝图为托管区域启用 Cloud DNS 日志。

如果您创建了其他托管区域,则必须启用这些 DNS 日志。

Google Workspace 审核日志记录

需要执行一次性启用步骤,此步骤无法由蓝图自动执行。如需了解详情,请参阅与Google Cloud 服务共享数据

Access Transparency 日志

需要执行一次性启用步骤,此步骤无法由蓝图自动执行。有关详情,请参阅启用 Access Transparency

下表介绍了日志接收器,以及它们如何在蓝图中与受支持的目标位置搭配使用。

接收器

目标位置

Purpose

sk-c-logging-la

日志路由到 Cloud Logging 存储桶(启用了 Log Analytics 和关联 BigQuery 数据集)

主动分析日志。在控制台中使用 Logs Explorer 运行临时调查,或使用关联的 BigQuery 数据集编写 SQL 查询、报告和视图。

sk-c-logging-bkt

日志路由到 Cloud Storage

长期存储日志,以用于法规遵从、审核和突发事件跟踪。

(可选)如果您有强制执行数据保留的合规性要求,我们建议您额外配置存储桶锁定

sk-c-logging-pub

日志路由到 Pub/Sub

将日志导出到外部平台,例如现有 SIEM。

这需要完成额外的工作才能与 SIEM 集成,例如以下机制:

如需了解如何启用其他日志类型以及编写日志接收器过滤条件,请参阅日志范围限定工具

使用 Security Command Center 进行威胁监控

我们建议您为组织激活 Security Command Center 高级方案,以自动检测 Google Cloud 资源中的威胁、漏洞和配置错误。Security Command Center 会从多个来源创建安全性发现结果,包括:

如需详细了解 Security Command Center 解决的漏洞和威胁,请参阅 Security Command Center 来源

部署蓝图后,您必须激活 Security Command Center。如需查看相关说明,请参阅为组织激活 Security Command Center

激活 Security Command Center 后,我们建议您将 Security Command Center 生成的发现结果导出到现有工具或流程,以对威胁进行分类和响应。此蓝图创建 prj-c-scc 项目,其中包含要用于此集成的 Pub/Sub 主题。根据现有工具,使用以下任一方法导出发现结果:

  • 如果您使用控制台直接在 Security Command Center 中管理安全发现结果,请为 Security Command Center 配置文件夹级层和项目级层角色,以便团队仅查看和管理他们所负责项目的安全发现结果。
  • 如果您将 Google SecOps 用作 SIEM,请将数据注入到 Google SecOps。 Google Cloud

  • 如果您通过与 Security Command Center 集成来使用 SIEM 或 SOAR 工具,请与 Cortex XSOARElastic StackServiceNowSplunkQRadar 共享数据。

  • 如果您使用可从 Pub/Sub 注入发现结果的外部工具,请将持续导出配置为 Pub/Sub,并将现有工具配置为从 Pub/Sub 主题注入发现结果。

用于自动日志分析的自定义解决方案

您可能需要根据日志为基于自定义查询的安全性事件创建提醒。自定义查询可通过分析 Google Cloud 上的日志并仅导出值得调查的事件,帮助补充 SIEM 的功能,尤其是当您无法将所有云日志导出到 SIEM 时。 Google Cloud

此蓝图通过设置可使用关联的 BigQuery 数据集查询的集中式日志来源,帮助启用此日志分析。如需自动执行此功能,您必须实现 bq-log-alerting 中的代码示例,并扩展基础功能。通过示例代码,您可以定期查询日志源并将自定义发现结果发送到 Security Command Center。

下图展示了自动日志分析的简要流程。

自动日志记录分析。

下图展示了自动日志分析的以下概念:

  • 来自不同来源的日志会聚合到一个集中式日志存储桶中,其中包含日志分析和关联的 BigQuery 数据集。
  • BigQuery 视图配置为查询要监控的安全性事件的日志。
  • Cloud Scheduler 每 15 分钟将事件推送到 Pub/Sub 主题一次并触发 Cloud Run 函数。
  • Cloud Run 函数会在视图中查询新事件。如果发现事件,则会将其作为自定义发现结果推送到 Security Command Center。
  • Security Command Center 会将关于新发现结果的通知发布到另一个 Pub/Sub 主题。
  • SIEM 等外部工具会订阅 Pub/Sub 主题,以注入新的发现结果。

该示例有多个可查询潜在可疑行为的使用场景。例如,通过您指定的一系列超级用户或其他具有高度特权的账号登录、更改日志记录设置,或者更改网络路由。您可以通过针对要求编写新的查询视图来扩展使用场景。自行编写查询或参考安全日志分析以获取可帮助您分析 Google Cloud 日志的 SQL 查询库。

用于响应资产变化的自定义解决方案

如需实时响应事件,我们建议您使用 Cloud Asset Inventory 来监控资产更改。在这个自定义解决方案中,资产 Feed 配置为实时触发向 Pub/Sub 发送关于资源更改的通知,然后 Cloud Run 函数运行自定义代码,以根据是否应允许更改来强制执行您自己的业务逻辑。

此蓝图具有一个自定义治理解决方案示例,该解决方案监控有关添加高度敏感角色(包括 Organization Admin、Owner 和 Editor)的 IAM 更改。下图描述了此解决方案。

自动还原 IAM 政策更改并发送通知。

上图展示了以下概念:

  • 对允许政策进行更改。
  • Cloud Asset Inventory Feed 会向 Pub/Sub 发送有关允许政策更改的实时通知。
  • Pub/Sub 会触发函数。
  • Cloud Run functions 函数运行自定义代码来强制执行您的政策。示例函数具有评估更改是否已将 Organization Admin、Owner 或 Editor 角色添加到允许政策的逻辑。如果是这样,该函数会创建自定义安全发现结果并将其发送到 Security Command Center。
  • (可选)您可以使用此模型自动进行补救工作。在 Cloud Run 函数中编写其他业务逻辑,以自动对发现结果执行操作,例如将允许政策还原为其之前的状态。

此外,您还可以扩展此示例解决方案使用的基础设施和逻辑,以向对您的业务至关重要的其他事件添加自定义响应。

后续步骤

可接受的资源配置的预防性控制

我们建议您定义政策限制条件,以实施可接受的资源配置和防止有风险的配置。此蓝图在流水线中结合使用了组织政策限制条件和基础设施即代码 (IaC) 验证。这些控制可防止创建不符合政策指南的资源。在设计和构建工作负载时尽早实施这些控制有助于避免日后需要执行补救工作。

组织政策限制条件

组织政策服务会强制执行限制条件,以确保在您的组织中无法创建某些资源配置,即使拥有足够权限的 IAM 角色的人员也无法创建这些配置。 Google Cloud

此蓝图在组织节点强制执行政策,以便组织中的所有文件夹和项目都会继承这些控制。这套政策旨在防止某些高风险的配置(例如将虚拟机公开给公共互联网或授予对存储桶的公共访问权限),除非您有意允许此政策的例外情况。

下表介绍了此蓝图中实施的组织政策限制条件

组织政策限制条件 说明

compute.disableNestedVirtualization

如果配置不当,Compute Engine 虚拟机上的嵌套虚拟化可能会避开虚拟机的监控功能和其他安全工具。此限制条件会阻止创建嵌套虚拟化。

compute.disableSerialPortAccess

compute.instanceAdmin 等 IAM 角色允许使用 SSH 密钥对实例串行端口进行特权访问。如果 SSH 密钥公开,则攻击者可以访问串行端口并绕过网络和防火墙控制。此限制条件会阻止串行端口访问。

compute.disableVpcExternalIpv6

如果配置不当,外部 IPv6 子网可能会向未经授权的互联网访问的开放。此限制条件会阻止创建外部 IPv6 子网。

compute.requireOsLogin

如果密钥暴露,则设置元数据中的 SSH 密钥这种默认行为会允许对虚拟机进行未经授权的远程访问。此限制条件强制使用 OS Login 而不是基于元数据的 SSH 密钥。

compute.restrictProtocolForwardingCreationForTypes

如果转发配置不当,外部 IP 地址的虚拟机协议转发可能会导致未经授权的互联网出站流量。此限制条件仅允许为内部地址转发虚拟机协议。

compute.restrictXpnProjectLienRemoval

删除共享 VPC 宿主项目可能会中断所有使用网络资源的服务项目。此限制条件可防止这些项目的项目安全锁被移除,从而防止意外或恶意删除共享 VPC 宿主项目。

compute.setNewProjectDefaultToZonalDNSOnly

建议不要使用全局(项目范围)内部 DNS 旧版设置,因为这会降低服务可用性。此限制条件可防止使用旧版设置。

compute.skipDefaultNetworkCreation

系统会在启用 Compute Engine API 的每个新项目中创建默认 VPC 网络和过于宽松的默认 VPC 防火墙规则。此限制条件会跳过默认网络和默认 VPC 防火墙规则的创建。

compute.vmExternalIpAccess

默认情况下,虚拟机是使用外部 IPv4 地址创建的,这可能会导致未经授权的互联网访问。此限制条件配置一个空的外部 IP 地址许可名单,虚拟机可以使用此许可名单,并拒绝所有其他地址。

essentialcontacts.allowedContactDomains

默认情况下,重要联系人可以配置为将有关您的网域的通知发送到任何其他网域。此限制条件强制要求只有已批准网域中的电子邮件地址才能设置为重要联系人的收件人。

iam.allowedPolicyMemberDomains

默认情况下,可以向任何 Google 账号(包括非受管账号和属于外部组织的账号)授予允许政策。此限制条件可确保只能向您自己网域中的受管理账号授予组织中的允许政策。 您也可以选择允许其他网域

iam.automaticIamGrantsForDefaultServiceAccounts

默认情况下,系统会自动向默认服务账号授予过于宽松的角色。此限制条件可防止自动向默认服务账号授予 IAM 角色。

iam.disableServiceAccountKeyCreation

服务账号密钥是高风险的永久性凭据,在大多数情况下,可以使用更安全的服务账号密钥替代方案。此限制条件会阻止创建服务账号密钥。

iam.disableServiceAccountKeyUpload

如果密钥材料暴露,则上传服务账号密钥材料可能会增加风险。此限制条件可阻止上传服务账号密钥。

sql.restrictAuthorizedNetworks

如果将 Cloud SQL 实例配置为不通过 Cloud SQL Auth 代理使用授权网络,则该实例可能向未经身份验证的互联网访问开放。此政策可防止配置授权网络进行数据库访问,并强制该用 Cloud SQL Auth 代理。

sql.restrictPublicIp

如果使用公共 IP 地址创建实例,则 Cloud SQL 实例可能会向未经身份验证的互联网访问开放。此限制条件可防止 Cloud SQL 实例使用 公共 IP 地址

storage.uniformBucketLevelAccess

默认情况下,可以通过旧版访问控制列表 (ACL)(而不是 IAM)访问 Cloud Storage 中的对象,这可能会在配置错误时导致访问权限控制不一致和意外暴露。旧版 ACL 访问权限不受 iam.allowedPolicyMemberDomains 限制条件的影响。此限制条件强制要求只能通过 IAM 统一存储桶级访问权限配置访问权限,而不能通过旧版 ACL 进行配置。

storage.publicAccessPrevention

如果配置错误,Cloud Storage 存储桶可能会向未经身份验证的互联网访问开放。此限制条件可防止向 allUsersallAuthenticatedUsers 授予访问权限的 ACL 和 IAM 权限。

这些政策是我们向大多数客户和对大多数场景推荐的初始政策,您可能需要修改组织政策限制条件,以适应某些工作负载类型。例如,storage.publicAccessPrevention 会阻止使用 Cloud Storage 存储桶作为后端供 Cloud CDN 托管公共资源的工作负载,或者 iam.allowedPolicyMemberDomains 会阻止面向公众且要求身份验证的 Cloud Run 应用。在这些情况下,请在文件夹或项目级层修改组织政策以允许狭义例外。您还可以定义一个对政策许可例外或强制执行的标记,然后将该标记应用于项目和文件夹,从而有条件地向组织政策添加限制条件

如需了解其他限制条件,请参阅可用限制条件自定义限制条件

基础设施即代码的部署前验证

此蓝图使用 GitOps 方法管理基础设施,也就是说所有基础设施更改均通过受版本控制的基础设施即代码 (IaC) 实现,并且可以在部署之前进行验证。

在蓝图中强制执行的政策定义了流水线可以部署的可接受资源配置。如果提交到 GitHub 代码库的代码未通过政策检查,则不会部署任何资源。

如需了解如何使用流水线以及如何通过 CI/CD 自动化强制执行控制,请参阅部署方法

后续步骤

部署方法

我们建议您使用声明式基础设施,以一致且可控的方式部署基础。此方法通过在流水线中强制执行可接受的资源配置政策控制来帮助实现一致的治理。此蓝图使用 GitOps 流程进行部署,在部署流水线中将 Terraform 用于定义基础设施即代码 (IaC)、将 Git 代码库用于代码的版本控制和批准,以及将 Cloud Build 用于用于 CI/CD 自动化。有关此概念的说明,请参阅使用 Terraform、Cloud Build 和 GitOps 管理基础设施即代码

以下部分介绍如何使用部署流水线来管理组织中的资源。

流水线层

为了区分负责管理环境的不同层的团队和技术栈,我们推荐了一款模型,该模型使用不同的流水线和不同角色来负责每一层栈。

下图介绍了我们建议的用于区分基础流水线、基础设施流水线和应用流水线的模型。

蓝图流水线。

下图介绍了此模型中的流水线层:

  • 应用流水线为每个工作负载(例如容器或映像)部署工件。我们建议由一个中心团队负责管理多个业务部门和工作负载使用的基础资源。
  • 基础设施流水线部署工作负载(例如虚拟机实例或数据库)使用的项目和基础设施。此蓝图会为每个业务部门设置单独的基础设施流水线,或者您可能更倾向于多个团队使用的单个基础设施流水线。
  • 应用流水线为每个工作负载部署工件,例如例如容器或映像。您可能有多个不同的应用团队使用单独的应用流水线。

以下部分介绍每个流水线层的用法。

基础流水线

基础流水线用于部署基础资源。它还设置了用于部署工作负载使用的基础设施的基础设施流水线。

如需创建基础流水线,请先将 terraform-example-foundation 克隆或复刻到您自己的 Git 代码库中。按照 0-bootstrap README 文件中的步骤配置您的引导文件夹和资源。

阶段 说明

0-bootstrap

引导 Google Cloud 组织。此步骤还会在后续阶段为蓝图代码配置 CI/CD 流水线。

  • CICD 项目包含用于部署资源的 Cloud Build 基础流水线。
  • seed 项目包括包含基础基础设施的 Terraform 状态的 Cloud Storage 存储桶,以及包括基础流水线用于创建资源的高权限服务账号。Terraform 状态通过存储对象版本控制提供保护。当 CI/CD 流水线运行时,它会充当在 seed 项目中受管理的服务账号。

0-bootstrap 阶段创建基础流水线后,以下阶段会在基础流水线上部署资源。请查看每个阶段的 README 说明,并按顺序实现每个阶段。

阶段 说明

1-org

通过组织政策设置顶级共享文件夹、共享服务项目、组织级日志记录和基准安全设置。

2-environments

在您创建的 Google Cloud 组织中设置开发、非生产和生产环境。

3-networks-dual-svpc

3-networks-hub-and-spoke

在您选择的拓扑和关联的网络资源中设置共享 VPC。

基础设施流水线

基础设施流水线会部署工作负载使用的项目和基础设施(例如虚拟机实例和数据库)。基础流水线会部署多个基础设施流水线。基础流水线和基础设施流水线之间的这种区别有助于分离平台范围的资源和工作负载专用资源。

下图描述了此蓝图如何配置旨在由不同团队使用的多个基础设施流水线。

多个基础设施流水线

该图描述了以下主要概念:

  • 每个基础设施流水线都独立于基础资源用于管理基础设施资源。
  • 每个业务部门都有自己的基础设施流水线,该流水线在 common 文件夹中的专用项目中接受管理。
  • 每个基础设施流水线都有一个服务账号,该账号有权将资源仅部署到与该业务部门关联的项目。此策略会在用于基础流水线的特权服务账号与每个基础设施流水线使用的服务账号之间实现职责分离

如果您的组织中有多个实体具备独立管理基础设施的技能和意愿,尤其是在实体具有不同的要求时(例如它们想要强制执行不同类型的流水线验证政策),建议使用这个多基础设施流水线方法。或者,您可能希望由采用一致验证政策的单个团队来管理单个基础设施流水线。

terraform-example-foundation 中,第 4 阶段配置基础设施流水线,第 5 阶段演示了使用该流水线部署基础设施资源的示例。

阶段 说明

4-projects

设置文件夹结构、项目和基础设施流水线。

5-app-infra (可选)

以基础设施流水线为例,使用 Compute Engine 实例部署工作负载项目。

应用流水线

应用流水线负责为每个工作负载(例如运行应用业务逻辑的映像或 Kubernetes 容器)部署应用工件。这些工件会部署到基础设施流水线部署的基础设施资源中。

企业基础蓝图可设置基础流水线和基础设施流水线,但不会部署应用流水线。如需查看示例应用流水线,请参阅企业应用蓝图

使用 Cloud Build 自动执行流水线

此蓝图使用 Cloud Build 自动执行 CI/CD 流程。下表介绍了 terraform-example-foundation 代码库部署的基础流水线和基础设施流水线中内置的控制。如果您要使用其他 CI/CD 自动化工具开发自己的流水线,我们建议您应用类似的控制。

控制 说明

拆分 build 配置以在部署之前验证代码

此蓝图对整个流水线使用两个 Cloud Build build 配置文件,并且与某个阶段关联的每个代码库有两个与这些 build 配置文件关联的 Cloud Build 触发器。将代码推送到代码库分支时,系统会触发 build 配置文件首次运行 cloudbuild-tf-plan.yaml,该命令会针对分支使用政策检查和 Terraform 方案验证代码,然后 cloudbuild-tf-apply.yaml 对该方案的结果运行 terraform apply

Terraform 政策检查

此蓝图包含一组由 Google Cloud CLI 中的政策验证强制执行的 Open Policy Agent 限制条件。这些限制条件定义了流水线可以部署的可接受资源配置。如果一个构建不符合第一个 build 配置中的政策,则第二个 build 配置将不会部署任何资源。

在蓝图中强制执行的政策复刻自 GitHub 上的 GoogleCloudPlatform/policy-library。您可以为库编写其他政策,强制执行自定义政策以满足您的要求。

最小权限原则

基础流水线在每个阶段都有不同服务账号,允许政策仅授予该阶段相应的最低权限 IAM 角色。每个 Cloud Build 触发器都会作为该阶段的特定服务账号运行。使用不同的账号有助于降低修改一个代码库可能会影响另一个代码库管理的资源这种风险。如需了解应用于每个服务账号的特定 IAM 角色,请参阅引导阶段的 sa.tf Terraform 代码。

Cloud Build 专用池

此蓝图使用 Cloud Build 专用池。 通过专用池,您可以选择强制执行其他控制,例如限制对公共代码库的访问或在 VPC Service Controls 边界内运行 Cloud Build。

Cloud Build 自定义构建器

此蓝图需要创建自己的自定义构建器来运行 Terraform。如需了解详情,请参阅 0-bootstrap/Dockerfile。 此控制会强制流水线在运行时使用一组固定版本的已知库。

部署审批

或者,您可以向 Cloud Build 添加手动审批阶段。此审批会在触发构建之后且在运行构建之前添加额外的检查点,以便特权用户可以手动审批构建。

分支策略

我们建议使用永久性分支策略,将代码提交到 Git 系统并通过基础流水线部署资源。下图描述了永久性分支策略。

蓝图部署分支策略

该图描述了 Git 中的三个永久性分支(开发、非生产和生产),这些分支反映了相应的Google Cloud 环境。此外,还有多个与Google Cloud 环境中部署的资源不对应的临时功能分支。

我们建议您对 Git 系统强制执行拉取请求 (PR) 流程,以便合并到永久性分支的任何代码都具有已获批准的 PR。

如需使用此永久性分支策略开发代码,请遵循以下简要步骤:

  1. 当您开发新功能或修复问题时,请基于开发分支创建一个新的分支。为分支使用命名惯例,包括更改类型、工单编号或其他标识符以及直观易懂的说明,例如 feature/123456-org-policies
  2. 完成功能分支中的工作后,创建一个针对开发分支的 PR。
  3. 提交 PR 时,PR 会触发基础流水线执行 terraform planterraform validate 以暂存并验证更改。
  4. 验证对代码的更改后,将功能或问题修复合并到开发分支中。
  5. 合并过程会触发基础流水线运行 terraform apply,以将开发分支中的最新更改部署到开发环境。
  6. 使用与您的用例相关的任何手动审核、功能测试或端到端测试,审核开发环境中的更改。然后,通过创建以非生产分支为目标的 PR 将更改升级到非生产环境,并合并您的更改。
  7. 要将资源部署到生产环境,请重复与第 6 步相同的过程:检查并验证已部署的资源,创建一个针对生产分支的 PR,然后进行合并。

后续步骤

操作最佳实践

本部分介绍在环境中部署和操作其他工作负载时必须考虑的操作。 Google Cloud 本部分并非旨在详尽无遗地介绍您的云环境中的所有操作,而是介绍与架构方面的建议和蓝图部署的资源相关的决策。

更新基础资源

虽然蓝图为您的基础环境提供了一个具有某种见解的起点,但您的基础要求可能会随着时间的推移而增加。完成初始部署后,您可以调整配置设置或构建新的共享服务,以供所有工作负载使用。

如需修改基础资源,我们建议您通过基础流水线进行所有更改。查看分支策略,简要了解编写代码、合并代码以及触发部署流水线的流程。

确定新工作负载项目的属性

通过自动化流水线的项目工厂模块创建新项目时,必须配置各种属性。为新工作负载设计和创建项目的过程应包含针对以下各项的决策:

  • 要启用哪种 Google Cloud API
  • 要使用哪种共享 VPC,或者是否创建新的 VPC 网络
  • 要为流水线创建的初始 project-service-account 创建哪些 IAM 角色
  • 要应用哪些项目标签
  • 项目要部署到哪个文件夹
  • 要使用哪个结算账号
  • 是否将项目添加到 VPC Service Controls 边界
  • 是否为项目配置预算和结算提醒阈值

如需全面了解每个项目的可配置属性,请参阅自动化流水线中的项目工厂的输入变量

大规模管理权限

在基础上部署工作负载项目时,您必须考虑如何向这些项目的目标开发者和使用方授予访问权限。我们建议您将用户添加到由现有身份提供方管理的群组中,将该群组与 Cloud Identity 同步,然后将 IAM 角色应用于该群组。始终牢记最小权限原则

我们还建议您使用 IAM Recommender 来识别授予超权限角色的允许政策。设计一个定期审核建议或自动将建议应用于部署流水线的流程。

协调网络团队和应用团队之间的更改

该蓝图部署的网络拓扑假定您有一个负责管理网络资源的团队,以及多个负责部署工作负载基础设施资源的独立团队。当工作负载团队部署基础设施时,他们必须创建防火墙规则以允许其工作负载的组件之间的预期访问路径,但他们无权修改网络防火墙政策本身。

规划团队如何协同工作来协调更改部署应用所需的集中式网络资源。例如,您可以设计一个工作负载团队为其应用请求标记的流程。然后,网络团队创建标记并向网络防火墙政策添加规则,以允许流量在具有标记的资源之间流动,然后将要使用标记的 IAM 角色委派给工作负载团队。

使用 Active Assist 产品组合优化环境

除了 IAM Recommender 之外, Google Cloud 还提供 Active Assist 服务组合,以提出有关如何优化环境的建议。例如,防火墙数据分析无人使用的项目 Recommender 提供了切实可行的建议,可帮助您加强安全状况。

设计一个定期审核建议或自动将建议应用于部署流水线的流程。确定哪些建议应由中心团队管理,哪些应由工作负载所有者负责,并应用 IAM 角色相应地访问这些建议。

许可组织政策的例外情况

该蓝图会强制执行一组组织政策限制条件,虽然我们会在大多数情况下,向大多数客户推荐这些限制条件,但您的合法使用场景可能需要您广泛实施的组织政策有一些受限的例外。

例如,该蓝图会强制执行 iam.disableServiceAccountKeyCreation 限制条件。此限制条件是一项重要的安全控制,因为泄露的服务账号密钥可能会产生严重的负面影响,并且大多数场景都应使用更安全的服务账号密钥替代方案进行身份验证。但是,可能存在只能使用服务账号密钥进行身份验证的使用场景,例如本地服务器需要访问Google Cloud 服务,但无法使用工作负载身份联合。在这种场景中,只要强制执行了附加补偿性控制(例如管理服务账号的最佳实践),您就可以决定允许政策例外。

因此,您应设计一个工作负载请求政策例外的流程,并确保负责许可例外的决策者具备相应的技术知识来验证使用场景和就是否必须实施附加控制来进行补偿提供咨询。向工作负载许可例外时,请在尽可能窄的范围内修改组织政策限制条件。您还可以定义一个对政策许可例外或强制执行的标记,然后将该标记应用于项目和文件夹,从而有条件地向组织政策添加限制条件

使用 VPC Service Controls 保护您的资源

该蓝图将基本网络和受限网络分开,从而帮助您为 VPC Service Controls 准备环境。但是,默认情况下,Terraform 代码不会启用 VPC Service Controls,因为此启用过程可能会中断。

边界会拒绝源自边界(包括控制台、开发者工作站和用于部署资源的基础流水线)外部的流量访问受限的 Google Cloud 服务。如果您使用 VPC Service Controls,则必须为边界设计例外,以允许您预期的访问路径。

VPC Service Controls 边界用于在 Google Cloud 组织和外部来源之间提供渗漏控制。该边界并非旨在替换或复制用于对个别项目或资源进行精细访问权限控制的允许政策。在设计和构建边界时,我们建议您使用通用的统一边界来降低管理开销。

如果您必须设计多个边界来精细控制组织内的服务流量, Google Cloud 我们建议您明确定义更复杂的边界结构可防范的威胁,以及边界之间执行预期操作所需的访问路径。

如需采用 VPC Service Controls,请评估以下各项:

启用边界后,我们建议您设计一个持续将新项目添加到正确边界的流程,以及一个在开发者遇到当前边界配置拒绝的新使用场景时设计例外的流程。

在单独的组织中测试组织范围的更改

我们建议您切勿在未经测试的情况下将更改部署到生产环境。对于工作负载资源,单独的开发、非生产和生产环境有利于实施此方法。但是,组织的某些资源没有单独的环境来方便测试。

对于组织级层的更改或可能会影响生产环境的其他更改(例如身份提供方和 Cloud Identity 之间的配置),请考虑创建一个单独的组织进行测试。

控制对虚拟机的远程访问

由于我们建议您通过基础流水线、基础设施流水线和应用流水线来部署不可变基础设施,因此我们还建议您仅在受限或例外使用场景下授权开发者通过 SSH 或 RDP 直接访问虚拟机。

对于需要远程访问的场景,我们建议您尽可能使用 OS Login 管理用户访问。此方法使用托管的 Google Cloud 服务来实施访问权限控制、账号生命周期管理、两步验证和审核日志记录。或者,如果您必须允许通过元数据中的 SSH 密钥RDP 凭据进行访问,则需负责管理凭据生命周期和在 Google Cloud外部安全存储凭据。

在任何情况下,对虚拟机具有 SSH 或 RDP 访问权限的用户都可能存在提权风险,因此您在设计访问模型时应考虑到这一点。用户可以使用关联服务账号的权限在该虚拟机上运行代码,也可以查询元数据服务器以查看用于对 API 请求进行身份验证的访问令牌。如果您不是有意让用户使用服务账号的特权操作,则此访问可能是提权行为。

通过规划预算提醒来减少超支

此蓝图实施 Google Cloud 架构框架:费用优化中引入的最佳实践来管理费用,包括:

  • 在企业基础的所有项目中使用同一个结算账号。

  • 为每个项目分配一个 billingcode 元数据标签,用于在成本中心之间分配费用。

  • 设置预算和提醒阈值。

您有责任规划预算并配置结算提醒。当预测支出将会达到预算的 120% 时,此蓝图会为工作负载项目创建预算提醒。这种方法使中心团队可以识别和缓解严重超支的突发事件。若没有明显的理由,支出大幅增加可能表明存在安全事件,应从费用控制和安全性的角度开展调查。

根据您的应用场景,您可以将预算设置为基于整个环境文件夹或与特定成本中心相关的所有项目,而不是为每个项目设置精细的预算。我们还建议您将预算和提醒设置委托给可能为日常监控设置更精细的提醒阈值的工作负载所有者。

如需了解如何构建 FinOps 功能,包括预测工作负载的预算,请参阅 Google Cloud上的 FinOps 使用入门

在内部成本中心之间分配费用

通过控制台,您可以查看结算报告,并从多个维度查看和预测费用。除了预建报告之外,我们还建议您将结算数据导出到 prj-c-billing-export 项目中的 BigQuery 数据集。借助导出的结算记录,您可以根据项目标签元数据(如 billingcode)在自定义维度(例如内部成本中心)分配费用。

请通过以下 SQL 查询示例了解按 billingcode 项目标签分组的所有项目的费用。

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

如需设置此导出,请参阅将 Cloud Billing 数据导出到 BigQuery

如需在成本中心之间建立内部记账或费用分摊,您有责任将从此查询中获得的数据整合到内部流程中。

将检测性控制中的发现结果注入到现有 SIEM 中

虽然基础资源可帮助您配置审核日志和安全发现结果的汇总目标位置,但您有责任决定如何使用这些信号。

如果您需要将所有云和本地环境中的日志汇总到现有 SIEM 中,请决定如何将 prj-c-logging 项目中的日志和 Security Command Center 中的发现结果注入到现有工具和流程中。如果由一个团队负责监控整个环境的安全性,则可以为所有日志和发现结果创建一个导出;也可以创建多个导出,为职责不同的多个团队过滤所需的一组日志和发现结果。

或者,如果日志量和费用令人望而却步,您可以仅保留 Google Cloud Google Cloud中的日志和发现结果,以避免重复。在这种情况下,请确保您的现有团队拥有正确的访问权限并经过适当培训,以便直接在Google Cloud中使用日志和发现结果。

  • 对于审核日志,请设计日志视图以向单个团队授予对集中式日志存储桶中的一部分日志的访问权限,而不是将日志复制到多个存储桶,从而增加日志存储费用。
  • 对于安全发现结果,请直接在控制台中为 Security Command Center 授予文件夹级层和项目级层角色,以便团队仅查看和管理他们所负责项目的安全发现结果。

持续开发您的控制库

此蓝图从检测和防范威胁的控制基准开始。建议您查看这些控制,并根据要求添加附加控制。下表总结了强制执行治理政策的机制以及如何根据其他要求扩展这些政策:

蓝图强制执行的政策控制 关于扩展这些控制的指南

Security Command Center 会检测来自多个安全来源的漏洞和威胁。

定义 Security Health Analytics 的自定义模块Event Threat Detection 的自定义模块

组织政策服务会对Google Cloud 服务实施一组建议的组织政策限制条件

强制执行预建的可用限制条件列表中的附加限制条件或创建自定义限制条件

Open Policy Agent (OPA) 政策会在部署之前验证基础流水线中的代码,以确认可接受的配置。

根据 GoogleCloudPlatform/policy-library 中的指导信息制定其他限制条件。

基于日志的指标和性能指标提醒会配置基于日志的指标,以针对某些敏感资源的 IAM 政策和配置更改发出提醒。

为不应在您的环境中发生的日志事件设计其他基于日志的指标和提醒政策。

用于自动日志分析的自定义解决方案会定期查询日志是否存在可疑活动,并创建 Security Command Center 发现结果。

使用安全日志分析作为参考,编写其他查询来为要监控的安全性事件创建发现结果。

用于响应资产变化的自定义解决方案会创建 Security Command Center 发现结果,并可自动采取修复措施。

创建其他 Cloud Asset Inventory Feed 来监控特定资产类型的更改,并使用自定义逻辑编写其他 Cloud Run 函数来响应违规行为。

随着您对Google Cloud 的要求和成熟度发生变化,这些控制可能也会变化。

使用 Cloud Key Management Service 管理加密密钥

Google Cloud 为所有客户内容提供默认静态加密,但也提供 Cloud Key Management Service (Cloud KMS),使您可以额外控制静态数据的加密密钥。我们建议您评估默认加密是否足够,或者是否存在让您必须使用 Cloud KMS 自行管理密钥的合规性要求。如需了解详情,请参阅确定如何满足静态加密的合规性要求

此蓝图在公共文件夹中提供一个 prj-c-kms 项目,并在每个环境文件夹中提供一个 prj-{env}-kms 项目来集中管理加密密钥。通过此方法,中心团队可以审核和管理工作负载项目中资源使用的加密密钥,以满足监管和合规性要求。

根据您的运营模式,您可能希望让一个团队控制 Cloud KMS 的一个集中式项目实例、在每个环境中单独管理加密密钥,或者采用多个分布式实例,以便将加密密钥的责任委派给相应的团队。根据需要修改 Terraform 代码示例,使之适应您的运营模式。

(可选)您可以强制执行客户管理的加密密钥 (CMEK) 组织政策,要求某些资源类型始终需要 CMEK 密钥,并且只能使用可信项目许可名单中的 CMEK 密钥。

使用 Secret Manager 存储和审核应用凭据

我们建议您切勿将敏感密文(例如 API 密钥、密码和私密证书)提交到源代码库。而应将密文提交到 Secret Manager 并向需要访问密文的用户或服务账号授予 Secret Manager Secret Accessor IAM 角色。我们建议您将 IAM 角色授予单个密文,而不是项目中的所有密文。

您应该尽可能在 CI/CD 流水线中自动生成生产密文,并保证真人用户无法访问这些密文(除非出现 Breakglass 情况)。在这种情况下,请确保您未向任何用户或群组授予查看这些密文的 IAM 角色。

此蓝图在公共文件夹中提供一个 prj-c-secrets 项目,并在每个环境文件夹中提供一个 prj-{env}-secrets 项目来集中管理密文。通过此方法,中心团队可以审核和管理应用使用的密文,以满足监管和合规性要求。

根据您的运营模式,您可能希望让一个团队控制 Secret Manager 的一个集中式实例、在每个环境中单独管理密文,或者采用 Secret Manager 的多个分布式实例,以便每个工作负载团队都可以管理自己的密文。根据需要修改 Terraform 代码示例,使之适应您的运营模式。

规划对高特权账号的 Breakglass 访问权限

虽然我们建议通过基础流水线部署的受版本控制的 IaC 来管理对基础资源的更改,但可能存在例外或紧急情况,在这些情况下,需要特权访问权限才能直接修改环境。我们建议您规划 Breakglass 账号(有时称为 firecall 或紧急账号),这些账号在发生紧急情况或自动化过程中断时对您的环境具有高度特权访问权限。

下表介绍了 Breakglass 账号的一些示例用途。

Breakglass 用途 说明

超级用户

紧急访问与 Cloud Identity 搭配使用的 Super Admin 角色,例如,解决与身份联合或多重身份验证 (MFA) 相关的问题。

组织管理员

紧急访问 Organization Administrator 角色,该角色之后可以向组织中任何其他 IAM 角色授予访问权限。

基础流水线管理员

提供紧急访问权限,以便在基础流水线的自动化功能中断时,修改Google Cloud 和外部 Git 代码库上 CICD 项目中的资源。

运营或 SRE

运营或 SRE 团队需要特权访问权限来响应中断或突发事件。这可能包括重启虚拟机或恢复数据等任务。

允许 Breakglass 访问权限的机制取决于您现有的工具和流程,但一些示例机制如下:

  • 使用现有的特权访问权限管理工具将用户临时添加到预定义了高特权 IAM 角色的群组,或使用高特权账号的凭据。
  • 预配置仅用于管理员用途的账号。例如,开发者 Dana 可能将 dana@example.com 身份用于日常用途,将 admin-dana@example.com 用于 Breakglass 访问用途。
  • 使用即时特权访问权限等应用,这些应用允许开发者自行提升为特权更高的角色。

无论您使用何种机制,都应考虑如何在运营层面解决以下问题:

  • 如何设计 Breakglass 访问权限的范围和粒度?例如,您可以为不同的业务部门设计不同的 Breakglass 机制,以确保它们之间不会相互干扰。
  • 您的机制如何防止滥用行为?是否需要批准?例如,您可能使用拆分操作,一个人保存凭据,另一个人保存 MFA 令牌。
  • 如何审核 Breakglass 访问权限并发出提醒?例如,您可以将自定义 Event Threat Detection 模块配置为在使用预定义 Breakglass 账号时创建安全发现结果。
  • 突发事件结束后,如何移除 Breakglass 访问权限并恢复正常运行?

对于常见的提权任务和回滚更改,我们建议您设计自动化工作流,以便用户无需提升其用户身份的权限即可执行相应操作。这种方法可以帮助减少人为错误并提高安全性。

对于需要定期干预的系统,自动化修复可能是最佳解决方案。Google 建议客户采用零触摸生产方法,使用自动化、安全代理或经过审核的 Breakglass 来执行所有生产更改。Google 为希望采用 Google SRE 方法的客户提供 SRE 书籍

后续步骤

部署蓝图

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

综合应用

如需根据此蓝中的最佳实践和建议部署自己的企业基础,请按照本部分总结的概要任务执行操作。部署包含必要的设置步骤、通过 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 控制台的访问。某些属性需要额外订阅 Chrome Enterprise 进阶版

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

命名规则

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

资源 命名惯例

文件夹

fldr-environment

environment 是 Google Cloud组织中的文件夹级资源的说明。例如 bootstrapcommonproductionnonproductiondevelopmentnetwork

例如:fldr-production

项目 ID

prj-environmentcode-description-randomid

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

例如:prj-c-logging-a1b2

VPC 网络

vpc-environmentcode-vpctype-vpcconfig

  • environmentcode 是环境字段的简写形式(bcpndnet 之一)。
  • vpctypesharedfloatpeer 中的一个。
  • vpcconfigbaserestricted,用于指示该网络是否应与 VPC Service Controls 一起使用。

例如:vpc-p-shared-base

子网

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

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

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

防火墙政策

fw-firewalltype-scope-environmentcode{-description}

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

例如:

fw-hierarchical-global-c-01

fw-network-uswest1-p-shared-base

Cloud Router

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

  • environmentcode 是环境字段的简写形式(bcpndnet 之一)。
  • vpctypesharedfloatpeer 中的一个。
  • vpcconfigbaserestricted,用于指示该网络是否应与 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 是环境字段的简写形式(bcpndnet 之一)。
  • vpctypesharedfloatpeer 中的一个。
  • vpcconfigbaserestricted,用于指示该网络是否应与 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-productiondevelopment 文件夹中。

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

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

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

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

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

您可能更倾向于将其他产品用于部署流水线,例如 Terraform EnterpriseGitLab RunnersGitHub ActionsJenkins。 此蓝图包含每种替代产品的说明。

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

使用您偏好的版本控制系统来管理代码库,例如 GitLabGitHubBitbucket

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

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

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

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

如果您已有身份提供方(例如 OktaPingAzure 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.googleapis.comrestricted.googleapis.com 的通用端点,而不是按环境将本地主机映射到 Private Service Connect 端点。

后续步骤