Google PCA: 组织设计、IAM 与云治理 — 学习指南

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

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

概述

组织设计、IAM 和治理为所有 Google Cloud 架构的运行奠定了基础。良好的设计能够创建清晰的管理边界、最小化爆炸半径、实现最小权限、控制成本，并能在多个团队和环境中进行运维扩展。治理应强调护栏而非门禁：自动化安全、可衡量且可逆的默认设置，同时将日常控制权委托给最接近工作负载的团队。

资源层次结构和身份基础

Google Cloud 资源构成一个严格的树状结构：Organization → Folders → Projects → Resources（例如，Compute Engine 实例、存储桶）。IAM 政策和 Organization Policy 约束会沿树状结构向下继承。

关键设计原则：

• 使用单一 Organization 来集中化治理。为主要管理边界（例如，业务部门、区域或受监管与非受监管环境）创建顶层 Folders。
• 在每个边界内，创建环境 Folders（prod、nonprod）以应用差异化政策。尽可能保持项目以工作负载为范围且具有临时性，以减少爆炸半径并简化费用分摊。
• 继承：允许授权会累积（祖先节点和当前节点的允许绑定的并集）。如果使用 IAM Deny 政策，它将优先于允许授权，即使存在允许授权也能阻止访问。避免在层次结构的高层级放置宽泛的角色；其爆炸半径很大且难以撤销。

身份来源：

• Cloud Identity 是员工身份平面。与您的企业 IdP (SAML/OIDC) 集成，以集中化身份验证和生命周期管理（员工入职、调动、离职）。如果需要，可使用 Google Cloud Directory Sync 进行属性和群组同步。
• 群组是主要的 IAM 主体。基于群组的访问能够实现可扩展的变更和可审计的所有权。使用群组嵌套模式（例如，net-admins、sec-admins、app-team-A），并限制谁可以管理群组成员资格。
• 服务账号代表工作负载。优先使用服务账号模拟（service account impersonation）和短期凭据，而不是存储的密钥。避免使用用户管理的服务账号密钥；将其视为特例，并实施严格的审批和轮换制度。
• 工作负载身份模式：
  • GKE Workload Identity 将 Kubernetes 服务账号绑定到 Google 服务账号；从而消除了节点范围的凭据。
  • Workload Identity Federation 使外部身份（本地、其他云、GitHub Actions）无需密钥即可获取短期的 Google 访问权限。使用池/提供商范围限定和属性条件来约束访问。

常见故障模式及缓解措施：

• 在 Folder 或 Organization 级别授予基本角色（Owner/Editor/Viewer）会导致普遍的权限过高问题。仅在范围严格限定的紧急访问（break-glass）项目中使用。
• 所有权不明的群组泛滥会破坏最小权限原则。对群组强制执行命名规范、用途标签和所有者元数据。
• 孤立的服务账号和过时的绑定会累积风险。安排定期的访问审查，并使用 IAM Recommender 来减少未使用的权限。

IAM 模型、角色和访问操作

角色和绑定：

• 预定义角色是为特定服务精心设计的，应作为默认选择。
• 当预定义角色粒度过粗时，自定义角色可填补空白。基于观察到的最小必要权限集来构建自定义角色，并对其进行版本控制和测试。
• 基本角色（Viewer/Editor/Owner）是旧版角色，权限过于宽泛。避免在 Organization 和 Folder 范围使用。不要将 Owner 角色用于日常操作；应将其保留用于平台紧急访问，并配合强大的补偿性控制措施。
• 条件角色绑定（IAM Conditions）使用诸如 resource.name、resource.matchTag、request.time 或 request.auth.audiences 等属性，来约束绑定的生效时间和位置。使用条件来实现有时间限制的访问、基于标签范围的生产环境访问或基于位置限制的操作。

最小权限和权限提升：

• 分离“读取”、“操作”和“管理”的职责。例如，网络、安全和应用团队在不同的范围上获得不同的角色。
• 使用 Access Approval 工作流或由工单驱动的自动化来实现即时（just-in-time）权限提升，通过条件绑定有时间限制的角色。

拒绝策略和风险：

• IAM Deny 可以集中阻止高风险权限（例如 resourcemanager.projects.delete）。拒绝策略会覆盖允许策略，并应用于整个子树。进行彻底验证；配置错误的拒绝策略可能会锁定自动化流程或破坏部署。

可审计性和审查：

• 在 Organization 级别启用 Admin Activity 日志；默认情况下，它们会保留 400 天。对于敏感服务，启用 Data Access 日志并将其路由到 BigQuery 以进行长期保留和审计。
• 实施定期的访问审查：使用 Cloud Asset Inventory 枚举绑定，与所有权注册信息进行比较，移除 IAM Recommender 建议的未使用角色，并验证特例权限的到期时间。

实用示例（有时间限制、基于标签范围的绑定）：

• gcloud projects add-iam-policy-binding PROJECT_ID –member=“group:prod-ops@example.com” –role=“roles/compute.instanceAdmin.v1” –condition=‘title=ProdOnlyTemp,expression=resource.matchTag(“organizations/1234567890/env”,“prod”) && request.time < timestamp(“2026-01-01T00:00:00Z”)’

财务治理与组织策略护栏

结算架构：

• 将一个或多个结算账号集中归属于财务部门。仅在法律或运营要求时（例如，独立的法人实体或经销商模式）才使用多个结算账号。
• 通过自动化将项目关联到结算账号；不允许在已批准的工作流之外进行手动关联。

成本分摊与成本可见性：

• 一致地使用标签 (labels) 和费用分摊标记 (cost allocation tags)。标签是用于筛选和报告的自由格式元数据；标记是分层的，可用于 IAM 条件和策略。为选定的标记启用费用分摊，使其出现在结算导出数据中。
• 将结算数据导出到 BigQuery 进行分析；按所有者、成本中心和环境构建信息中心。要求每个项目都有一个责任所有者和预算。

预算和异常检测：

• 在文件夹 (Folder) 和项目级别创建预算并设置提醒。添加程序化响应（例如，通知待命人员、创建工单或禁止新的配额增加）以遏制失控的支出。
• 根据预期用量使用配额 (Quotas) 和承诺使用折扣 (CUD)；监控利用率。

组织策略限制（默认安全）：

• 在组织 (Organization) 或文件夹 (Folder) 级别强制执行护栏，并仅在有正当理由时才放宽。常见的限制：
  • constraints/iam.disableServiceAccountKeyCreation = true
  • constraints/compute.requireOsLogin = true
  • constraints/compute.trustedImageProjects 限制虚拟机镜像
  • constraints/sql.restrictPublicIp = true
  • constraints/storage.uniformBucketLevelAccess = true
  • constraints/compute.disableSerialPortAccess = true
• 使用 VPC Service Controls 降低跨敏感边界的受支持服务的数据渗漏风险。

策略例外处理：

• 例外必须是可请求、经批准、有时间限制且可审计的。优先使用 IAM 条件按标签/时间来限定例外范围。通过策略即代码 (policy-as-code) 流水线定期核对例外情况并使其自动过期。

组织策略示例 (YAML)，用于停用服务账号密钥：

• name: organizations/1234567890/policies/iam.disableServiceAccountKeyCreation spec: rules:
  • enforce: true 然后应用：gcloud org-policies set-policy policy.yaml

着陆区、共享服务、自动化与运营模型

着陆区 (Landing zone):

• 提供一个预先加固的基线：包括 Organization Policies、日志接收器、CMEK 策略、共享 VPC、私有 DNS、Cloud NAT、Private Service Connect、审计和安全项目，以及受限的镜像目录。
• 为每个环境的共享 VPC 分离宿主项目。网络管理员控制宿主项目；应用团队在附加到正确宿主的服务项目中进行部署。

项目工厂 (Project factory):

• 通过基础设施即代码 (IaC) 自动化项目创建。标准化地创建项目，使其具备：
  • 正确的文件夹放置和结算链接
  • 预绑定的组和角色
  • 默认服务账号被禁用或受限
  • 指向中央项目和保留存储桶的日志接收器
  • 预定义的预算、标签和标记
• 使用 Terraform 模块或 Cloud Config Controller 将工厂代码化。在应用变更前，在 CI 中强制执行策略验证。

共享服务与隔离:

• 在专用项目中集中管理身份、网络、CI/CD、制品库和安全工具。通过文件夹 (Folder) 和 VPC 隔离环境；使用防火墙策略、独立的服务边界以及每个环境不同的 Cloud KMS 密钥环来阻止横向移动。
• 使用 Private Service Connect 和生产者项目向消费者发布共享服务，而无需暴露公共端点。

审计日志记录与治理自动化:

• 将管理员活动 (Admin Activity) 日志和数据访问 (Data Access) 日志路由到审计项目。为日志存储桶配置 CMEK 和符合合规性要求的保留策略。
• 使用 Cloud Asset Inventory Feed 将数据发送到 Pub/Sub，再结合 Cloud Functions/Cloud Run 来检测偏差（例如，公开的存储桶），并自动修复或创建工单。
• 策略即代码 (Policy-as-code) 技术栈：
  • 将作为代码的 Org Policies 和 IAM 存储在代码仓库中
  • 针对 KRM 资源的 Config Validator/Policy Controller
  • 在 CI/CD 中进行部署前策略检查
  • 使用计划的协调作业来重新应用期望的状态

资源命名与标签:

• 强制执行简短、可读的命名模式，该模式应包含环境、应用、区域和序列等信息（例如，appA-prd-usw2-web-01）。保留标签 (tags) 用于治理（例如，env=prod, pii=true, owner=team-x）。在项目创建时验证所需标签/标记是否存在。

多团队运营与委派管理:

• 建立具有明确范围和角色的平台、安全和网络团队。将项目级管理委派给其文件夹 (Folder) 边界内的应用团队。通过目录和模板在护栏内提供自助服务。
• 通过将爆炸半径小的决策下放给团队，并集中处理影响多个项目或共享基础设施的决策，来平衡自主性与风险。

实际问题场景

Contoso Retail 计划在三个月内将八个产品团队引入 Google Cloud。每个团队都需要生产和非生产环境、隔离的网络、集中的安全日志记录以及成本问责。平台团队必须防止服务账号密钥泛滥，限制虚拟机镜像，并为事件响应启用有时限的提升访问权限。

方法：

1. 建立层次结构和文件夹

• 为部门创建顶层文件夹 (Folders)，并为生产和非生产环境创建嵌套文件夹。理由：清晰的管理边界允许设置有针对性的护栏和预算，同时能够向产品团队委派管理权限，而无需授予组织范围的权力。

2. 部署带有共享 VPC 的着陆区

• 为由网络团队管理的生产和非生产网络创建宿主项目。通过共享 VPC 附加团队的服务项目。理由：集中管理路由、NAT 和防火墙策略，同时按项目隔离工作负载；防止导致泛滥和安全不一致的临时性网络配置。

3. 实施组织策略护栏

• 强制执行约束：禁用服务账号密钥创建、要求使用 OS Login、限制 Cloud SQL 的公共 IP、将虚拟机镜像限制为来自可信项目，以及启用统一的存储桶级访问。理由：默认安全减少了高频的错误配置；必要时，例外可以是有时限的。

4. 建立身份和群组

• 将 Cloud Identity 与企业 IdP 集成；为每个团队的开发、运维和管理角色创建群组，并为网络管理员和安全管理员创建平台级群组。理由：基于群组的 IAM 易于扩展，并与职责分离原则保持一致；其生命周期跟随人力资源事件。

5. 定义具有最小权限和条件性提权的 IAM

• 在文件夹或项目范围将预定义角色绑定到群组；通过条件绑定启用事件响应提权，该提权仅限于带有 prod 标签的资源，并在 24 小时后过期。理由：日常操作采用最小权限原则，并在需要时提供安全、可审计的权限升级途径。

6. 构建项目工厂流水线

• 使用 Terraform 模块创建项目，使其具备必需的标签/标记（env、owner、cost-center）、链接结算账户、附加到正确的共享 VPC、创建指向中央审计项目的日志接收器，并设置预算。理由：大规模的一致性、合规性预配消除了手动偏差，并加快了团队引入速度。

7. 集中化审计日志记录和访问审查

• 将管理员活动 (Admin Activity) 和数据访问 (Data Access) 日志路由到使用 CMEK 的 BigQuery 中；安排每月查询以枚举 IAM 绑定，并与群组所有权以及来自 IAM Recommender 的最后访问数据进行比较。理由：持久的审计跟踪和持续的访问权限合理调整可降低风险和成本。

8. 成本治理与警报

• 启用成本分配标签和标记，将结算数据导出到 BigQuery，并为每个文件夹和每个项目设置预算，同时向财务和团队负责人发送通知。理由：透明的成本分摊可推动问责制；早期警报可遏制失控的支出。

9. 工作负载身份与无密钥自动化

• 对于 GKE，启用 Workload Identity；对于外部 CI (GitHub)，设置范围限定于特定代码仓库并带有条件的 Workload Identity Federation。理由：消除了长期有效的密钥，并将使用范围限制在预期的工作负载内。

10. 例外流程与自动化

• 实施一个请求工作流，该工作流通过 CI 创建带有自动过期的条件性 IAM 绑定或临时策略放宽。理由：在不牺牲控制权的情况下赋能团队；每个例外都是有时限且可审计的。

技术成果：

• 团队可以在 15 分钟内自助创建具有合规默认设置的新项目。
• 不允许使用用户管理的服务账号密钥；事件响应的权限提升是有时限且受标签范围限制的。
• 成本按团队和环境进行汇总，并配有自动化的预算和异常警报。
• 审计日志和访问审查持续验证权限和策略是否与预期一致。

所有领域 · 计算、应用平台与工作负载架构 →

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

浏览 Google →