Wasp 官网隐私政策与数据收集实践：从 Cookie 同意机制到 PostHog 分析的完整解析
2026/9/14 19:35:13
Google Cloud Foundation Builder 组织策略实战指南：17 项基线安全约束的配置与部署
【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills
本文是
google-cloud-recipe-foundation-builder技能（Agent Skill）配套的组织策略（Organization Policies）参考指南。它详细列出该技能在组织根节点强制执行的 17 项基线安全约束（13 项 Boolean 约束 + 4 项 List 约束），给出每一项的约束名称、约束类型、目标配置以及可直接用于gcloud org-policies set-policy部署的标准 YAML 模板。读完本文，你将掌握如何为 Google Cloud 组织快速建立"默认安全、最小暴露"的治理基线，并能在实际落地时安全地按顺序应用这些策略。
一、约束全景：17 项基线安全策略的构成
google-cloud-recipe-foundation-builder技能在为 Google Cloud 组织搭建企业级着陆区（landing zone）基础时，会在组织根节点依次应用 17 项基线组织策略，作为整个环境的第一道安全护栏。其完整定位与部署流程参见 Foundation Builder 技能主文档 中的Phase 3: Security Guardrails (Org Policies)章节。
从类型上划分，这 17 项策略分为两大类：
- Boolean 约束（13 项）：二进制策略，统一设置为
enforce: true，即强制启用； - List 约束（4 项）：通过
allowedValues/denyAll限定允许或拒绝的具体取值。
从作用域看，它们覆盖了四类核心风险面：
- 身份与密钥管理（IAM）：默认服务账号自动授权、服务账号密钥的创建与上传、IAM 策略成员域限制；
- 存储安全（Cloud Storage）：公共访问预防、统一存储桶级访问；
- 计算与网络（Compute Engine）：外部 IP 分配、串口访问、OS Login、区域 DNS、嵌套虚拟化、VPC 外部 IPv6、协议转发、Shared VPC 项目 lien 移除；
- 数据服务（Cloud SQL）：公网 IP 限制、授权网络限制。
二、Boolean 约束：统一 YAML 模板与 13 项策略明细
所有 Boolean 约束均采用同一套 YAML 结构，只需替换[ORGANIZATION_ID]（组织 ID）与[CONSTRAINT_NAME]（约束名称）：
name: organizations/[ORGANIZATION_ID]/policies/[CONSTRAINT_NAME] spec: rules: - enforce: true说明：
spec.rules[0].enforce: true表示该约束在组织层级被强制开启，组织内的所有下级文件夹与项目将继承该策略。若需在下级层级放行，可另行在对应层级设置豁免（此处基线不涉及）。
以下 13 项策略均使用上述模板，逐一说明其约束名称与安全意图：
2.1 身份与密钥管理类
1. Disable Automatic IAM Grants for Default Service Accounts
- 约束名：
iam.automaticIamGrantsForDefaultServiceAccounts - 作用：阻止 App Engine 与 Compute Engine 的默认服务账号在项目创建时被自动授予 Editor 角色，避免默认账号权限过大。
2. Disable Service Account Key Creation
- 约束名：
iam.disableServiceAccountKeyCreation - 作用：禁止用户为服务账号创建新的外部（用户管理）密钥，从源头降低长期凭据泄露风险，倒逼使用 Workload Identity Federation 等短期凭据方案。
3. Disable Service Account Key Upload
- 约束名：
iam.disableServiceAccountKeyUpload - 作用：禁止用户向服务账号上传公钥，阻断外部密钥与服务账号的关联，与上一条形成"创建、上传双禁用"闭环。
2.2 存储安全类
4. Public Access Prevention
- 约束名：
storage.publicAccessPrevention - 作用：对组织内所有 Cloud Storage 存储桶强制执行公共访问预防，通过 IAM 策略授予的公共访问（allUsers / allAuthenticatedUsers）将被阻止，防止数据意外公开。
5. Uniform Bucket-Level Access
- 约束名：
storage.uniformBucketLevelAccess - 作用：对所有存储桶强制执行统一桶级访问，禁用细粒度的对象级 ACL，访问控制完全交由 IAM 统一管理，显著降低 ACL 配置错误的攻击面。
2.3 计算与网络安全类
6. Set New Project Default to Zonal DNS Only
- 约束名：
compute.setNewProjectDefaultToZonalDNSOnly - 作用：确保新建项目仅使用 Compute Engine 实例的区域（zonal）DNS 名称，防止内部 DNS 名称跨区域泄露。
7. Disable Serial Port Access
- 约束名：
compute.disableSerialPortAccess - 作用：禁用所有 Compute Engine 虚拟机的串口（Serial Port）访问。串口访问无法通过 IAM 精细审计，禁用后控制台访问通道更安全。
8. Restrict Shared VPC Project Lien Removal
- 约束名：
compute.restrictXpnProjectLienRemoval - 作用：限制移除 Shared VPC 宿主项目上的 lien（留置权），防止关键网络项目被意外删除，保护共享网络的稳定性。
9. Disable VPC External IPv6
- 约束名：
compute.disableVpcExternalIpv6 - 作用：禁止向 VPC 子网与资源分配外部 IPv6 地址，收窄对外暴露面；有 IPv6 需求的环境需在受控子网单独评估放行。
10. Disable Nested Virtualization
- 约束名：
compute.disableNestedVirtualization - 作用：禁用 Compute Engine 虚拟机上的硬件辅助嵌套虚拟化，缓解侧信道攻击向量（如基于虚拟化指令的逃逸面扩大）。
11. Require OS Login
- 约束名：
compute.requireOsLogin - 作用：对所有 Compute Engine 实例强制启用 OS Login，将虚拟机 SSH 访问与用户 Google 身份绑定，实现 SSH 密钥的统一管理与审计，替代分散的实例级 SSH 密钥。
2.4 Cloud SQL 数据服务类
12. Restrict Public IP Access for Cloud SQL
- 约束名：
sql.restrictPublicIp - 作用：阻止 Cloud SQL 实例以公网 IP 地址创建，强制通过私有 IP 连接数据库，从架构上消除数据库直接暴露在公网的可能。
13. Restrict Authorized Networks for Cloud SQL
- 约束名：
sql.restrictAuthorizedNetworks - 作用：阻止向 Cloud SQL 实例的授权网络（authorized networks）列表中添加非私有 IP 网段，进一步收紧数据库的入站来源。
三、List 约束：四条策略的专用 YAML 模板
List 约束需要按各自语义使用denyAll或allowedValues，不能套用 Boolean 模板。
3.1 VM External IP Access（Deny All）
- 约束名：
compute.vmExternalIpAccess - 作用：禁止 Compute Engine 虚拟机被分配外部（公网）IP 地址。此处采用"全部拒绝"语义（
denyAll: true），即默认不允许任何 VM 拥有公网 IP。
name: organizations/[ORGANIZATION_ID]/policies/compute.vmExternalIpAccess spec: rules: - denyAll: true3.2 Restrict Protocol Forwarding Creation（Allow INTERNAL）
- 约束名：
compute.restrictProtocolForwardingCreationForTypes - 作用：将协议转发规则（protocol forwarding rule）的创建限制为仅允许内部目标，阻止面向公网的转发规则创建。
name: organizations/[ORGANIZATION_ID]/policies/compute.restrictProtocolForwardingCreationForTypes spec: rules: - values: allowedValues: - INTERNAL3.3 Allowed Policy Member Domains（Allow Customer ID）
- 约束名：
iam.allowedPolicyMemberDomains - 作用：将可被添加到 IAM 策略的域身份限定为组织专属的 Google Workspace 或 Cloud Identity 客户 ID，防止外部域身份被误加进组织级 IAM 策略。
name: organizations/[ORGANIZATION_ID]/policies/iam.allowedPolicyMemberDomains spec: rules: - values: allowedValues: - [DIRECTORY_CUSTOMER_ID] # Replace with your numeric customer ID (e.g., C01234567)替代写法：也可以使用 principal set 格式
principalSet://iam.googleapis.com/organizations/[ORGANIZATION_ID]，将范围限定到整个组织内的身份集。
如何获取
DIRECTORY_CUSTOMER_ID：在 Phase 1 预检阶段，Foundation Builder 技能会执行gcloud organizations describe [ORGANIZATION_ID]，输出中的owner.directoryCustomerId字段即为该值；displayName字段对应组织域名。详见 Foundation Builder 技能主文档 的 Phase 1。
3.4 Allowed Contact Domains（Allow Org Domain）
- 约束名：
essentialcontacts.allowedContactDomains - 作用：将可注册为组织 Essential Contacts 的邮箱域限定为组织官方域名，确保安全通知、公告类邮件只发送到受控邮箱，防止通知被劫持到外部域。
name: organizations/[ORGANIZATION_ID]/policies/essentialcontacts.allowedContactDomains spec: rules: - values: allowedValues: - @[YOUR_DOMAIN] # Replace with your organization's domain (e.g., @example.com)注意：此处的取值需携带
@前缀（如@example.com），与 IAM 域约束（纯C01234567客户 ID）的书写格式不同。
四、部署指令：顺序应用与执行要求
4.1 核心命令
为每项策略生成对应的 YAML 文件后，使用gcloud org-policies set-policy按顺序逐条应用：
gcloud org-policies set-policy [POLICY_FILE_NAME].yaml在 Foundation Builder 技能的整体流程中，该命令属于Phase 3: Security Guardrails，与后续的文件夹/项目创建（Phase 4）、集中式日志与监控（Phase 5）构成完整落地顺序，详见 Foundation Builder 技能主文档。
4.2 权限要求与失败自愈
执行gcloud org-policies set-policy需要orgpolicy.policy.set权限。若命令因Permission Denied失败，技能会按"懒修复（lazy role remediation）"策略尝试为部署身份授予整个Organization Admin Group（9 个角色，含roles/orgpolicy.policyAdmin）后重试；若授权命令本身失败，则暂停执行并请求组织管理员人工介入。完整的角色清单与可复制脚本见 Administrative IAM 参考。
4.3 部署顺序的安全警示
[!CAUTION] 务必先确认部署身份所在域已被允许，再应用
iam.allowedPolicyMemberDomains。 该策略会立即限制可被加入 IAM 策略的域身份。如果当前执行部署的身份属于未允许的域，执行策略本身或后续步骤时可能将部署身份自身锁在管理范围之外。因此必须最后应用或先确保部署身份处于允许域内再执行。
五、验证与后续检查
部署完成后，可通过以下方式确认 17 项策略均已正确落地：
# 列出组织下所有组织策略，核对 17 项目标策略均已配置 gcloud org-policies list --organization=[ORGANIZATION_ID]在 Foundation Builder 的 Validation Logic & Checklist 中，该项对应 "Security Policies" 检查点：验证全部 17 项策略已 enforce 或正确配置，其余检查点（文件夹、账单、日志桶、日志 sink、指标作用域）参见 Foundation Builder 技能主文档 与 集中式日志与监控参考。
六、实践要点小结
- 两类模板不可混用：Boolean 约束统一
enforce: true；List 约束按需使用denyAll: true或allowedValues。 - 先算好两个占位值：
[ORGANIZATION_ID]与[DIRECTORY_CUSTOMER_ID]，后者来自gcloud organizations describe输出的owner.directoryCustomerId。 - 顺序敏感：
iam.allowedPolicyMemberDomains必须谨慎排序，避免锁定部署身份。 - 权限兜底：策略失败时优先通过 Organization Admin Group（含
roles/orgpolicy.policyAdmin）完成自愈，而不是中断整个着陆区部署。 - 可追溯验证：用
gcloud org-policies list --organization=...留存证据，作为合规审计基线。
这 17 项约束共同构成了 Foundation Builder 着陆区的"最小安全基线"：身份侧杜绝默认授权与静态密钥，存储侧杜绝公共暴露与细粒度 ACL，计算网络侧收窄公网面并统一身份化登录，数据库侧强制私有网络连接。对于新建的 Google Cloud 组织，这套策略组合可以低成本地建立与 Google Cloud 企业级安全基线对齐的治理起点。
【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考