Google PCA: 安全、合规性与数据保护架构 — 学习指南

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

属于 Google Professional Cloud Architect — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Google Cloud 中的安全性、合规性和数据保护建立在共同责任和纵深防御的基础之上。Google 负责保护底层基础设施的安全，而您则需要构建安全的身份、网络、应用和数据处理架构。采纳零信任作为指导模型：绝不隐式信任网络，持续验证身份和情境，并严格执行最小权限。为失陷而设计：假设凭证可能泄露，端点可能被探测，内部服务可能被滥用。通过多重控制（预防性、检测性、响应性）、强大的加密和密钥管理、稳健的监控以及经过演练的事件响应来进行弥补。

权衡取舍在所难免。更强的控制可能会增加延迟、运维复杂度和成本。您的架构应在风险与可用性、性能之间进行明确权衡，同时保持可证明的合规性和取证就绪性。

身份与访问架构

• 原则与模型

  • 默认最小权限：仅授予完成任务所需的最小权限集，并优先使用预定义角色或自定义角色，而不是基本角色（Owner、Editor、Viewer）。
  • 职责分离：在构建者 (CI/CD)、部署者、运维者和安全人员之间划分角色。为紧急情况使用具有强控制和日志记录的紧急访问账号（break-glass accounts）。
  • 零信任强制执行：使用情境感知访问来验证用户、设备、位置和风险；要求强 MFA；并持续评估会话情境。
  • 组织政策和 IAM Deny：将护栏代码化（例如，禁止创建服务账号密钥、限制网域共享），并使用拒绝策略来强制执行不可协商的边界。

• IAM 实现和服务账号策略

  • 建立层级驱动的访问模型：文件夹反映业务线或环境（生产、非生产）；项目隔离爆炸半径和计费；服务账号 (SA) 代表工作负载。
  • 一个工作负载，一个服务账号：避免在不相关的服务之间共享 SA。将权限标记到部署范围（项目）和资源范围。
  • 优先通过 Service Account Impersonation 和 Workload Identity Federation 使用短期凭证。禁用用户管理的服务账号密钥；如果不可避免，请隔离使用、频繁轮换，并使用审计日志进行监控。
  • 使用 Access Boundaries 在请求时限制被模拟的 SA 可以访问的内容（例如，限制 GCS 对象路径），即使高权限 SA 被滥用，也能控制爆炸半径。
  • 条件 IAM：应用资源级条件（时间、IP、主体属性）来约束访问。示例：禁止从公司 IP 范围之外以及变更窗口之外访问生产环境。

• 故障模式与权衡

  • 权限过大的角色（例如，项目范围的 Editor）会增加风险；优先使用粒度更细的角色，并通过策略分析器进行验证。
  • CI/CD 和本地脚本中的服务账号密钥泛滥是一个常见的泄露途径；使用模拟功能时，某些旧工具可能需要进行适配。
  • IAM Deny 策略功能强大但可能难以排查；在非生产环境中通过明确的空运行（dry run）来分阶段测试变更。

示例（不创建密钥进行模拟）：

• gcloud auth print-access-token –impersonate-service-account=svc-ci@proj.iam.gserviceaccount.com

数据保护与加密

• Cloud KMS 和密钥管理模型
  • 默认启用原生静态加密。如需额外控制，请为 BigQuery、Cloud Storage、Compute Engine 磁盘、Pub/Sub 和 GKE 永久性卷等服务使用客户管理的加密密钥 (CMEK)。
  • 按环境和数据域设计密钥层次结构。每个位置使用独立的密钥环，每个应用或数据集使用独立的密钥，以限制爆炸半径。
  • 轮换：启用计划性轮换，并通过应用的信封加密平滑地弃用旧密钥版本。在提高轮换频率之前，验证消费端的兼容性。
  • 外部密钥管理器 (EKM) 和外部密钥访问 (EKA) 将密钥置于 Google Cloud 之外以满足监管控制要求。其权衡之处在于会增加延迟并依赖外部 HSM 的可用性；需为降级模式操作制定计划。
  • 对 CryptoKeys 强制执行 IAM 最小权限原则。使用密钥级别的审计日志作为访问证据。

示例（使用 CMEK 并设置轮换）：

undefined

undefined

• 应用级加密

  • 使用信封加密（例如 Tink）在应用层加密敏感字段，以实现选择性访问和租户数据隔离。派生每个租户的密钥，以最小化跨租户影响。
  • 验证完整性 (AEAD) 以防止篡改和重放攻击。

• Secret Manager 和 Secret 生命周期

  • 将凭据、令牌和 API 密钥存储为版本化的 Secret；绝不存储在镜像、Git 或实例元数据中。在 Secret 或项目级别向运行时服务账号授予 IAM 权限。
  • 轮换：使用由 Pub/Sub 触发的 Cloud Functions/Cloud Run 实现自动化，以创建新版本、更新依赖项并撤销旧版本。优先使用基于 IAM 的数据库身份验证或短期有效的令牌来替代长期有效的数据库密码。
  • 配置安全：将非机密配置（ConfigMap、环境变量）与 Secret 分开。防止 Secret 在日志和错误消息中暴露。

示例（添加新的 Secret 版本）：

undefined

• 计算服务强化与机密计算
  • Shielded VMs：启用安全启动、vTPM 和完整性监控，以防范 bootkit 和 rootkit。通过组织策略强制执行，并在 CI/CD 流水线中进行验证。
  • Confidential VMs：默认启用内存加密，以最少的配置更改保护使用中的数据；评估其对高吞吐量、加密密集型工作负载的性能影响。
  • 强化镜像：从 Google 优化的或经 CIS 强化的基线镜像开始；使用 OS Config 管理补丁，并禁用不必要的软件包和端口。

网络与边缘安全

• 网络分段与出站流量控制

  • 使用独立的 VPC、子网和分层防火墙策略，按层级和敏感度进行分段。将身份感知防火墙标记与服务到服务的约束（例如 GKE NetworkPolicy）相结合，以强制执行东西向流量控制。
  • 通过 Cloud NAT、DNS 策略和受限的 Private Google Access 来控制出站流量，以最大限度地减少数据渗漏。在合理的情况下，使用显式的出站流量白名单和代理检查。

• VPC Service Controls (VPC SC)

  • 围绕托管范围内数据的项目构建服务边界，以缓解来自 Google 管理的 API（GCS、BigQuery、Secret Manager、Pub/Sub 等）的数据渗漏风险。
  • 访问级别：定义访问边界内服务必须满足的上下文条件（用户身份、IP 范围、设备状态）。
  • 使用边界网桥实现受控的多边界工作流，并使用出站规则限制目标地址。使用试运行模式进行测试，以避免破坏流水线。
  • 限制：无法直接保护流向 Compute Engine IP 的流量；需通过防火墙和出站流量控制进行补充。某些工具和混合模式可能需要支持边界的服务账号以及通过 Private Service Connect 连接到受限 VIP。

• 边缘与应用防护

  • Cloud Armor：通过 L3/L4/L7 DDoS 缓解、IP 允许/拒绝列表、基于地理位置的控制和速率限制，保护全局外部负载均衡器后的 HTTP(S) 应用。
  • WAF 规则：针对 OWASP Top 10 应用预配置的托管规则和自定义签名；进行调优以减少误报。将规则附加到每个后端服务，以根据 API 版本或应用组件定制策略。
  • API 保护：使用 API Gateway 或 Apigee 作为 API 的前端，进行身份验证、配额管理、模式验证和威胁检测；集成 Cloud Armor 进行边缘强制执行；在适当情况下考虑使用 reCAPTCHA Enterprise 和机器人程序控制。
  • 权衡：更深度的检查可能会增加延迟和运营噪音。在预览模式下分阶段部署规则，监控日志，并逐步强制执行。

安全运营、监控与合规

• Security Command Center (SCC) 与威胁检测

  • SCC 聚合跨项目和组织的资产清单与发现结果。使用它来基准化安全状况（例如公开的存储桶、开放的防火墙规则）、跟踪偏差并驱动修复工作流。
  • 高级版威胁检测包括 Event Threat Detection、VM Threat Detection 和 Container Threat Detection，用于识别恶意软件、加密货币挖矿和异常行为。
  • 将发现结果与工单系统和 SOAR 流水线集成；定义带有过期时间的抑制/例外策略，以避免告警疲劳。

• 漏洞与工件安全

  • 使用 Artifact Analysis 扫描容器镜像以查找 CVE；通过 Binary Authorization 和来自 CI 的签名证明来强制执行部署时策略。
  • 通过 OS Config 进行补丁管理；监控暴露窗口并通过金丝雀部署实现自动化发布。

• 审计日志、隐私与证据

  • Cloud Audit Logs 默认提供管理员活动 (Admin Activity) 和系统事件 (System Event) 日志；数据访问 (Data Access) 日志可按服务启用，并且是收费的。将日志路由到 BigQuery 进行分析，并路由到 Cloud Storage 以实现不可变保留和合规保留 (legal hold)。
  • 数据分类：使用 Cloud DLP 发现和分类个人身份信息 (PII)，应用标签，并将其映射到保护级别（CMEK、VPC SC、Confidential VMs）。
  • 隐私与数据驻留：通过组织策略限制资源位置；使 CMEK 和存储位置符合法规要求。
  • 合规保留与数据保留：启用存储桶保留策略和锁定 (holds)；在需要时使用对象版本控制 (Object Versioning)。记录取证镜像和日志的监管链，以生成可采信的证据。

• 事件响应与取证准备

  • 准备运行手册、访问路径和自动化流程。确保响应人员拥有最小权限访问，并在整个组织、文件夹和项目中启用审计。
  • 遏制：通过从负载均衡器中移除实例、应用拒绝出口流量的防火墙规则或将项目移至具有更严格组织策略的组织单元来隔离实例；禁用被入侵的服务账号并轮换密钥和凭证。
  • 取证：对磁盘进行快照并导出镜像以供离线分析；通过导出日志来保全日志。在适用的情况下使用数据包镜像 (packet mirroring)。避免修改证据；在副本上进行操作。
  • 恢复：从可信镜像重建，重新注入密钥，并通过冒烟测试和安全测试进行验证。进行事件后复盘，并将经验教训融入到护栏和检测机制中。

实践问题场景

NimbusPay 是一家金融科技 SaaS 公司，必须在 Google Cloud 上的多租户微服务中处理标记为 PCI 的数据，在欧盟强制执行数据驻留，防范 API 层攻击，并生成可审计的控制证据。他们将在保持 v1 在同一主机名下运行的同时，推出新的 v2 API。

方法：

1. 划分项目和身份

• 为每个环境和微服务层（入口、处理、报告）创建独立的项目。为每个服务分配一个唯一的工作负载服务账号。理由：隔离爆炸半径，并将最小权限原则映射到离散的工作负载。

2. 强制执行零信任和最小权限

• 向服务账号和 DevOps 团队授予预定义/自定义角色；应用条件性 IAM，将生产环境的访问限制在公司 IP 和工作时间内。理由：减少横向移动和意外更改。

3. 移除静态服务账号密钥

• 通过组织策略禁用用户管理的服务账号密钥。对 CI/CD 和运维操作使用服务账号模拟 (Service Account Impersonation)；应用访问边界 (Access Boundaries) 来限制每个租户的 GCS 路径。理由：消除了一个常见的凭证泄露途径，并且即使令牌被盗也能限制数据访问。

4. 使用 CMEK 和区域控制保护数据

• 在 europe-west 区域创建 Cloud KMS 密钥环和密钥；为 BigQuery 数据集、GCS 存储桶和 Persistent Disks 启用 CMEK。配置计划性轮换和版本监控。理由：提供与欧盟数据驻留和 PCI 要求一致的可验证加密控制。

5. 对卡数据采用应用层加密

• 使用信封加密 (Tink AEAD)，其中每个租户的数据密钥由 CMEK 包装；在数据库中仅存储密文。理由：实现字段级保护，并在事件分类期间最小化影响范围。

6. 集中管理密钥并自动轮换

• 将数据库凭证和 API 令牌存储在 Secret Manager 中，并为每个服务配置 IAM。实施由 Pub/Sub 触发的轮换作业，以创建新版本并更新部署。在可能的情况下，切换到使用 Cloud SQL 的 IAM 数据库身份验证。理由：实现可审计的密钥生命周期，且停机时间最短。

7. 分段网络并控制出口流量

• 使用分层防火墙策略强制执行 web→API→DB 的流量流向；直接拒绝 web→DB 的访问。为 Google API 启用带有出口白名单的 Cloud NAT 和 Private Google Access (restricted)。理由：限制东西向流量并阻止未经授权的数据外泄。

8. 使用 VPC Service Controls 包裹数据服务

• 将 BigQuery、GCS 和 Secret Manager 项目放入一个服务边界内；定义要求公司 IP 和受管设备的访问级别。先使用试运行 (dry-run) 模式进行测试，然后强制执行。理由：减轻因令牌被盗或客户端配置错误导致的数据外泄风险。

9. 保护边缘和 API

• 在全局 HTTPS 负载均衡器前端部署 Cloud Armor 托管规则和速率限制。使用基于路径的路由将 /v1 和 /v2 分离到不同的后端服务，并为每个版本应用量身定制的 WAF 策略。集成 Apigee 以进行身份验证、配额管理和模式验证。理由：实现分层的 API 保护、平滑的 v1→v2 过渡以及最小化的误报。

10. 加固计算资源并验证工件

• 为处理节点启用 Shielded VMs 和 Confidential VMs；采用经过 CIS 加固的基础镜像。在 Artifact Registry 中扫描镜像，并通过 Binary Authorization 要求 GKE 使用经过签名的证明。理由：保护启动链和使用中的数据，并强制执行供应链信任。

11. 使用 SCC 监控安全状况和威胁

• 启用 SCC Premium 以检测有风险的配置和运行时威胁；与工单系统集成以满足 SLA 要求。对已接受的风险设置带有过期日期的抑制规则。理由：提供持续的保障和可操作的信号。

12. 记录、保留并生成证据

• 将管理员活动 (Admin Activity)、数据访问 (Data Access) 和 VPC 流日志路由到设置了保留策略和合规保留 (legal holds) 的 BigQuery 和 Cloud Storage。为数据集标记驻留地和敏感度标签。理由：通过范围受限的访问支持调查和外部审计。

13. 准备事件响应和取证

• 创建运行手册，通过将受感染的服务所在项目移至具有更严格策略的隔离文件夹、禁用相关 SA 并对磁盘进行快照以供离线分析，来隔离这些服务。理由：在保全证据的同时快速遏制。

支持此部署的简短命令：

• gcloud kms keyrings create pci-ring –location=europe-west1
• gcloud kms keys create tenant-wrap –keyring=pci-ring –location=europe-west1 –purpose=encryption –rotation-period=90d
• gcloud access-context-manager levels create corp-devices –title=corp-devices –basic-level-spec=‘ipSubnetworks: [“203.0.113.0/24”]’

通过这些步骤，NimbusPay 实现了分层保护（身份、加密、网络和边缘）、可验证的合规性、在单一主机名下受控的 API 演进，并为检测、遏制和从事件中恢复做好了准备。

← 网络、混合连接与流量架构 · 所有领域 · 可靠性、灾难恢复与业务连续性 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Google →