Google PCD: 身份、认证与应用安全 — 学习指南

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

概述

身份是 Google Cloud 的新边界。应用程序必须对主体（principal）（用户、服务）进行身份验证，并授权他们以最小权限访问数据和 API，同时保护密钥、凭证和软件供应链。本节概述了端到端的设计和运营实践，这些实践结合了 Google Cloud IAM、现代身份验证协议、网络和 API 防御、加密、日志记录和响应流程。重点在于短期凭证、集中式策略以及可安全失效的分层控制。

身份、认证与访问控制

• IAM 角色和服务账号
  • 使用资源层级（组织 > 文件夹 > 项目）和预定义角色，而非基本角色。仅当预定义角色过于宽泛时，才优先考虑使用自定义角色。
  • 为工作负载分配服务账号 (SA)。不要重复使用默认的 Compute Engine 或 App Engine SA。每个工作负载边界使用一个 SA，可以简化最小权限的实现和信任的轮换。
  • 通过在最窄的资源范围内授予最小权限集来强制执行最小权限原则。
  • 模拟 (Impersonation)：优先通过 Service Account Token Creator 使用短期凭证，让人类、CI/CD 或其他服务无需存储密钥即可获得临时访问权限：
    • 将 roles/iam.serviceAccountTokenCreator 角色授予目标 SA 上的调用方身份。
    • 示例：

undefined

• Workload Identity

  • GKE：使用 Workload Identity 将 Kubernetes 服务账号绑定到 Google 服务账号；令牌会自动投射和交换，无需 JSON 密钥。
  • 外部工作负载：使用 Workload Identity Federation 将 OIDC/SAML 凭证（例如，来自 GitHub Actions 或本地环境）交换为 Google 访问令牌，而无需存储长期有效的密钥。

• 失效模式与权衡

  • 过于宽泛的角色或范围过大的授权会导致横向移动。缺少 Token Creator 权限会阻塞模拟流程。JSON 密钥文件会增加泄露的爆炸半径。

• 使用 OAuth 2.0、OpenID Connect 和 Google Identity 进行用户认证

  • 对于最终用户认证，使用 OIDC，并以 Google 或企业 IdP 作为身份提供商；在服务器端验证 ID 令牌。对于 API 访问，使用具有适当范围 (scope) 的 OAuth 2.0 访问令牌。
  • 验证令牌：使用 IdP 的 JWK 验证 iss、aud、exp、iat 和签名；缓存 JWK 并强制执行密钥轮换。
  • 对于移动/单页应用 (SPA) 后端，推荐采用 PKCE 的授权码流程 (Authorization Code flow with PKCE)。避免使用隐式流程 (implicit flows)。
  • 对于服务到服务通信，使用 OAuth 2.0 服务账号 JWT 流程或 mTLS；避免使用静态 API 密钥。
  • 示例（使用 gcloud 进行令牌模拟）：

undefined

• 失效模式

  • 不验证 aud/iss 会导致令牌混淆攻击。接受过期的令牌或不轮换 JWK 会增加风险。在移动应用中使用刷新令牌 (refresh tokens) 会暴露长期有效的凭证。

• 使用 Identity-Aware Proxy (IAP) 进行浏览器访问

  • 使用 IAP 为 Cloud Run、GKE 或 Compute Engine 上的 HTTP 应用提供前端代理，而无需在应用中嵌入认证逻辑。为访问强制执行 “IAP-secured Web App User” 角色。
  • 应用会收到一个签名的标头 (header) (x-goog-iap-jwt-assertion)。验证此 JWT 以信任用户身份和电子邮件；不要依赖 X-Forwarded-* 标头进行认证。
  • 常见陷阱：存在未通过 IAP 路由的绕行路径、后端防火墙配置错误，或在没有 Cloud Load Balancing 完整性保护的情况下信任客户端 IP 标头。

密钥、凭证和加密

• Secret Manager
  • 将 API 密钥、数据库密码和 webhook 密钥存储在 Secret Manager 中。依赖其版本控制、IAM 控制和审计日志。
  • 访问模式
    • 在启动时获取并缓存在内存中；根据密钥变更信号（Pub/Sub 通知）刷新。
    • 避免将密钥烘焙到镜像或环境变量中。如果使用环境变量，请确保它们永远不会被记录或转储到崩溃报告中。
  • 轮换
    • 使用 Cloud Scheduler + Cloud Functions/Run 实现自动化，以创建新版本、更新依赖项并弃用旧版本。
    • 示例：

undefined

• 失效模式

  • 每次请求对 Secret Manager 的调用过多会增加延迟并有耗尽配额的风险。缺少 roles/secretAccessor 角色会导致运行时 403 错误。

• Cloud KMS 和应用加密

  • 使用信封加密：一个本地生成的数据加密密钥 (DEK) 用于加密数据；Cloud KMS 客户管理的密钥 (CMEK) 用于加密 DEK（作为 KEK）。
  • 定期轮换密钥；为重新加密做好规划。优先采用“写入时用新密钥加密，读取时用旧密钥解密”的策略；对静态数据进行批量重新加密作业的成本更高。
  • 当合规性要求时，为相关服务（BigQuery、GCS、Pub/Sub、Cloud SQL 等）启用 CMEK。将 KMS 密钥与数据保存在同一区域。
  • CLI 示例：
    • 加密：

undefined

- 解密：

undefined

• 使用经过充分审查的加密库（例如 Tink）以避免实现错误。
• 失效模式
  • 位置不匹配会阻止使用 CMEK。每次请求都进行 KMS 解密会增加延迟；应在内存中缓存 DEK，并感知其轮换。缺少 roles/cloudkms.cryptoKeyEncrypterDecrypter 角色会导致 403 错误。

授权、API 和边界安全

• 应用授权

  • 基于角色的检查：简单、快速，但粒度粗。基于属性的访问控制 (ABAC) 使用用户属性、资源属性和上下文（时间、设备状态）来进行细粒度决策。
  • 集中进行策略评估或使用 sidecar/OPA；在微服务之间一致地传播身份和租户声明。
  • 多租户模式
    • 在身份验证令牌中嵌入 tenant_id，并在每个数据访问路径中强制执行；使用行级过滤或为每个租户分离数据集以实现严格隔离。
    • 如果法规要求隔离，请考虑为每个租户使用专用的服务账号或 KMS 密钥。
  • 失败模式
    • 因缺少租户检查而导致不安全的直接对象引用 (IDOR)。跨服务的授权逻辑分散导致执行不一致。

• 安全的 API 设计

  • 验证并规范化所有输入；拒绝超大负载。强制使用强内容类型。对文件上传进行威胁建模；对大对象使用签名 URL。
  • 速率限制和配额：使用 Cloud Armor 速率限制或 Apigee 来缓解滥用和 429 错误。在客户端上实现带抖动的指数退避。
  • CORS
    • 返回最小化的 Access-Control-Allow-*；在凭据请求中避免使用通配符源。预检缓存可降低延迟。
  • CSRF 防御
    • 优先选择在 Authorization 标头中使用 bearer token 的无状态 API。对于基于 cookie 的会话，使用 SameSite=strict 或 lax、安全 cookie 以及 CSRF 令牌（双重提交或同步器模式）。
  • 示例 (Cloud Armor 规则):
    • gcloud compute security-policies rules create 1000 –security-policy web-policy –expression “request.path.matches(’/api/’)” –action rate_based_ban –rate-limit-threshold-count 100 –rate-limit-threshold-interval-sec 60
  • 失败模式
    • 简单的基于 IP 的限制可被 IPv6 或代理绕过。过于宽松的 CORS 会导致令牌泄露。缺少 CSRF 令牌的 cookie 会话允许会话劫持。

• 网络控制和数据边界

  • 使用分层防火墙策略和 VPC 防火墙规则；当服务位于 HTTP(S) 负载均衡之后时，允许来自 Google 前端的健康检查。
  • 示例:
    • gcloud compute firewall-rules create allow-lb –network prod –allow tcp:80,tcp:443 –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
  • Cloud Armor 提供 WAF、机器人防御和地理位置/IP 限制；调整规则并审查误报。
  • Private Service Access 提供与 Google 托管服务（例如 Cloud SQL、Memorystore）的私有 IP 连接；避免公共出口和 IP 允许列表。
  • VPC Service Controls 通过在受支持的服务周围创建边界来降低数据渗漏风险；与 Access Context Manager 结合使用以获取设备/位置上下文。
  • 失败模式
    • 配置错误的边界会阻塞 CI/CD 或破坏服务间调用。缺少 PSA 分配会阻止私有 IP 连接。过于严格的 WAF 规则可能导致可用性事件。

供应链安全、日志记录与响应

• 软件供应链安全

  • 将构建产物存储在 Artifact Registry 中；强制执行漏洞扫描。当出现高危/严重 CVE 时构建失败，并跟踪策略例外情况。
  • 固定依赖项和基础镜像的版本；避免使用 “latest” 标签。生成并验证 SBOM。使用 Binary Authorization，要求在部署前必须使用经过签名的镜像。
  • 使用 Cosign 对镜像进行签名并记录来源；采用符合 SLSA 的构建实践。为 CI 使用 Workload Identity Federation，以消除 JSON 密钥。
  • 失效模式
    • 未固定的依赖项会拉取到含漏洞的版本。跳过来源验证会允许镜像被篡改。在 CI 日志中存储注册表凭证或服务账号密钥会导致密钥泄露。

• 安全日志记录与监控

  • 为关键项目和服务启用管理员活动和数据访问审核日志。将日志路由到一个访问受限的专用项目中。
  • 为身份验证失败、权限拒绝和策略评估错误创建 Cloud Logging 指标；通过 Cloud Monitoring 发出警报。
  • 示例（自定义计数器指标思路）：统计 /api/* 路径的 401/403 错误率，并在偏离基线时发出警报。
  • 威胁分类与修复
    • 使用 Security Command Center 汇总发现结果；为关键场景（密钥泄露、暴力破解、IAM 异常变更）创建应急预案 (playbook)。
    • 自动化常见修复操作（撤销令牌、禁用密钥、轮换密钥、隔离服务账号）。
  • 注重隐私的设计
    • 最小化个人身份信息 (PII)；在可能的情况下进行令牌化处理。从日志中隐去敏感值；使用 Cloud DLP 进行分类。
    • 应用最短保留时间和区域性存储策略。
  • 失效模式
    • 禁用数据访问日志会使数据外泄检测失效。高基数标签会导致成本激增。记录密钥会造成持久的风险暴露。

实践问题场景

Acme Retail 公司正在 Cloud Run 上构建一个多租户分析门户，该门户包含一个 React 前端、一个 Python API，并为每个租户使用一个 BigQuery 数据集。需求包括：为员工和客户提供 SSO，租户隔离，密钥和凭证管理，私有数据库访问，WAF 和速率限制，以及一个不使用长期密钥的强大 CI/CD 体系。

方法：

1. 建立身份和最小权限

• 为每个微服务（api-sa, ingest-sa）创建一个专用的 Google 服务账号。在项目或数据集级别授予最小权限角色（例如，在租户数据集上授予 roles/bigquery.dataEditor）。
• 理由：每个服务使用独立 SA 可以限定爆炸半径并简化轮换；范围狭窄的角色可以减少横向移动的风险。

2. 为 CI/CD 使用 Workload Identity Federation

• 配置 GitHub Actions OIDC，通过 roles/iam.workloadIdentityUser 和 roles/iam.serviceAccountTokenCreator 角色来模拟 deployer-sa。使用模拟的令牌部署到 Cloud Run。
• 理由：从 CI 中移除了 JSON 密钥；短期有效的凭证降低了被盗风险。

3. 前端和用户身份验证

• 在 Cloud Run 服务前端的 HTTPS 负载均衡器上配置 IAP。将 Google 作为员工的 IdP，并通过联合身份集成客户的 IdP。使用 “IAP-secured Web App User” 角色将访问权限限制在授权的组。
• 理由：为浏览器应用提供集中式身份验证；服务中无需包含身份验证逻辑；支持 SSO。

4. 在 API 中验证 IAP 身份

• 在 API 中验证 x-goog-iap-jwt-assertion 标头；强制要求存在 tenant_id 声明（从组或自定义声明映射而来）。
• 理由：IAP 提供了强有力的身份保证；在每个请求中嵌入租户上下文可确保下游授权的一致性。

5. 实现租户感知的授权

• 存储每个租户的策略，并将用户映射到角色（查看者、分析师、管理员）。在每个请求上，检查角色和 ABAC 条件（tenant_id 匹配、功能标志）。
• 理由：结合了 RBAC 的简单性和 ABAC 的灵活性；通过强制执行租户范围来消除 IDOR 风险。

6. 密钥和数据库访问

• 将数据库密码和第三方 API 令牌存储在 Secret Manager 中；仅向 API SA 授予 roles/secretmanager.secretAccessor 角色。在启动时访问密钥，并通过 Pub/Sub 轮换通知进行刷新。
• 理由：避免硬编码凭证；访问可审计；无需重启即可及时轮换。

7. 数据加密和 CMEK

• 为每个环境创建一个 Cloud KMS 密钥环和密钥。在 BigQuery 数据集和 Cloud Storage 存储桶上启用 CMEK。对任何应用程序存储的敏感二进制大对象 (blob) 使用信封加密。
• 理由：客户管理的密钥满足合规性要求，并提供了职责分离。

8. 私有连接和服务边界

• 为 Cloud SQL 私有 IP 使用私有服务访问。为托管 BigQuery 和 GCS 的项目创建 VPC Service Controls 边界；为公司管理员访问添加访问上下文策略。
• 理由：消除了公共出口路径；降低了数据外泄的风险。

9. API 安全、速率限制、CORS 和 CSRF

• 将带有 WAF 托管规则和速率限制的 Cloud Armor 安全策略应用于外部 HTTP(S) LB；为合作伙伴 IP 调整允许列表。为 API 配置严格的 CORS（明确的源站），并使用 Authorization bearer 令牌；不使用 cookie。
• 理由：缓解 OWASP Top 10 风险和滥用行为；防止跨源凭证泄露；通过不使用 cookie 来避免 CSRF。

10. 供应链加固

• 将镜像存储在 Artifact Registry 中。启用漏洞扫描，并在发现严重 CVE 时使构建失败。使用 Cosign 对镜像进行签名，并强制执行 Binary Authorization，要求在生产环境中使用 Acme 签名。
• 理由：防止未经审查的构建产物运行；维护来源信息。

11. 日志、监控和警报

• 启用审核日志并将其路由到集中式项目。为 401/403 峰值、来自 BigQuery 的 permissionDenied 错误以及 Secret Manager 访问创建基于日志的指标。对异常情况发出警报，并为公共端点设置 Cloud Monitoring 正常运行时间检查。
• 理由：及早发现身份验证失败和滥用行为；进行可用性监控。

12. 事件应急预案和轮换演练

• 记录撤销受损 SA（禁用、轮换密钥、使令牌失效）、轮换密钥以及使用新的 KMS 版本重新加密的步骤。每季度进行测试。
• 理由：有准备的、可重复的响应可以最大限度地减少停机时间和数据暴露。

此设计确保了每一跳都有短期有效、可验证的身份，一致的租户感知授权，受保护的密钥和凭证，私有数据路径，以及加固的供应链，并通过可观测性和响应工作流，使系统在攻击和日常操作中保持弹性。

← 应用数据、状态和存储模式 · 所有领域 · 持续交付、配置和基础设施自动化 →

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

浏览 Google →