操作最佳实践

Last reviewed 2023-12-20 UTC

本部分介绍在 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-logs 项目中的 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 Functions 函数来响应违规行为。

随着您的 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 可能将 [email protected] 身份用于日常用途，将 [email protected] 用于 Breakglass 访问用途。
  • 使用即时特权访问权限等应用，这些应用允许开发者自行提升为特权更高的角色。

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

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

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

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

后续步骤