手册

GKE 工作负载需要访问 GCP API，而无需管理服务账号密钥。

→在 GKE 集群上启用并配置 Workload Identity。将 Kubernetes 服务账号 (KSA) 映射到 Google 服务账号 (GSA)。

原因: 通过使用源自 KSA 令牌的短期、自动轮换的凭据，消除了服务账号密钥泄露的风险。

参考↗

在不使用 VPN 的情况下，根据用户身份和设备姿态，从任何网络提供对内部 Web 应用程序的访问。

→将 Identity-Aware Proxy (IAP) 与 Access Context Manager 结合使用。根据 IP、设备状态（通过 Endpoint Verification）和用户身份定义访问级别。

原因: 将访问控制从网络边界转移到单个用户和设备，强制执行零信任原则。

参考↗

CI/CD 流水线（例如 GitHub Actions、GitLab）需要访问 GCP 资源，而无需长期凭据。

→使用 Workload Identity Federation。为外部 IdP（例如 GitHub OIDC）创建提供者池，并配置属性条件以限制对特定存储库或分支的访问。

原因: 为外部工作负载提供无密钥身份验证。外部系统提供其自己的令牌，该令牌将交换为短期 GCP 令牌。

在整个组织中强制执行 IAM 安全策略，例如阻止创建服务账号密钥或将 IAM 授权限制到特定域。

→使用组织策略约束，例如 `iam.disableServiceAccountKeyCreation` 和 `iam.allowedPolicyMemberDomains`。

原因: 组织策略是继承的，不能被项目所有者覆盖，从而确保一致的安全态势。

用户因事故需要对生产环境进行临时、可审计且经批准的管理员访问。

→使用 Privileged Access Manager (PAM) 进行即时 (JIT) 访问。用户请求特定角色，并设定有限时间，该请求会通过批准工作流。

原因: 消除了长期特权这一主要安全风险。访问是有时间限制的、有理由的，并经过全面审计。

多个团队共享一个 GKE 集群。每个团队必须仅管理其自己命名空间内的资源。

→在项目级别授予 IAM 角色 `roles/container.clusterViewer`。在每个命名空间内使用 Kubernetes RBAC `Role` 和 `RoleBinding` 授予特定权限（例如，编辑、查看）。

原因: 将集群级身份验证 (IAM) 与命名空间级授权 (Kubernetes RBAC) 分离，提供细粒度的多租户控制。

必须使用短期凭据而不是静态密钥调用 API。

→使用服务账号模拟。在目标服务账号上授予主账号 `roles/iam.serviceAccountTokenCreator` 角色，以生成短期 OAuth 2.0 访问令牌。

原因: 避免分发和管理长期密钥。令牌会自动过期（默认为 1 小时），降低泄露风险。

承包商需要访问特定资源，但访问权限必须在 30 天后自动过期。

→使用基于时间的 IAM 条件授予必要的 IAM 角色，例如 `request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`。

原因: 自动化访问撤销，避免手动清理并确保访问不会被无意中延长。

只允许由 CI/CD 流水线签名的容器镜像部署到生产 GKE 集群。

→实施 Binary Authorization。在 CI 流水线中创建认证以签署镜像。在 GKE 集群上配置 Binary Authorization 策略以要求此认证。

原因: 通过阻止未经审查或篡改的镜像在生产环境中运行，强制执行安全的软件供应链。

参考↗

根据资源的分配标签而非单个资源名称授予权限。

→使用带有资源标签表达式的 IAM 条件，例如 `resource.matchTag("123456789/env", "prod")`。

原因: 实现可扩展的基于属性的访问控制 (ABAC)。权限是动态的，并且在资源被标记时自动应用。

允许服务项目在 Shared VPC 主机项目中部署 VM，而无需授予网络管理员权限。

→在主机项目中，授予服务项目的服务账号 `roles/compute.networkUser` 角色，使其能够访问需要使用的特定子网。

原因: 遵循最小特权原则。服务项目可以使用网络，但不能修改它（例如，更改防火墙规则），网络仍由中心化管理。

具有 `storage.admin` 权限的用户无法创建存储桶。您需要查明根本原因。

→检查更高级别（文件夹、组织）是否存在拒绝 `storage.buckets.create` 权限的 IAM 拒绝策略。

原因: IAM 拒绝策略总是覆盖任何允许策略。这是强制执行不可协商安全边界的强大工具。

为本地 Active Directory 用户启用 SSO 以访问 Google Cloud 控制台。

→使用 Google Cloud Directory Sync (GCDS) 将身份同步到 Cloud Identity。配置 Cloud Identity 和 AD FS（或其他 IdP）之间的联邦（SAML）。

原因: 保持 AD 作为身份的真相来源，同时为用户提供无缝的联邦 SSO 体验。

在 GCP 中加密数据，但加密密钥绝不能离开本地 HSM。

→使用 Cloud External Key Manager (EKM)。这允许 GCP 服务使用来自外部密钥管理系统的密钥进行 CMEK 操作。

原因: 通过将密钥材料保留在 Google Cloud 之外，提供最大程度的控制并满足严格的数据主权要求。

参考↗

自动查找和分类所有 Cloud Storage 和 BigQuery 资产中的敏感数据（PII、PHI）。

→配置 Cloud Data Loss Prevention (DLP) 发现扫描。结果可以自动使用标签填充 Data Catalog。

原因: 提供自动化的数据清单和分类，这是数据治理和保护策略的基础。

分析团队需要查询包含 PII 的数据，但不应看到原始敏感值。必须维护引用完整性。

→使用带有确定性加密或加密哈希的 Cloud DLP 去标识化模板。

原因: 将敏感数据转换为化名。确定性方法确保相同的输入始终产生相同的输出，从而允许连接和聚合。

合规性框架（例如，针对金融服务）要求加密密钥受 FIPS 140-2 Level 3 认证的 HSM 保护。

→使用保护级别为 HSM 的 Cloud KMS。这会在托管的硬件安全模块中创建密钥。

原因: 通过使用专用的认证硬件进行密钥管理，而无需管理物理 HSM，满足高级别的合规性要求。

确保新资源（例如 GCS 存储桶、BigQuery 数据集）始终使用客户管理的密钥 (CMEK) 而非 Google 管理的密钥进行加密。

→应用 `constraints/gcp.restrictNonCmekServices` 组织策略。

原因: 提供了一种预防性控制，强制指定服务使用 CMEK，确保一致的数据保护态势。

出于法律或合规原因，数据必须以不可变（WORM - 一次写入，多次读取）状态存储特定保留期。

→为 Cloud Storage 存储桶配置保留策略并启用 Bucket Lock。

原因: Bucket Lock 使保留策略不可逆转，确保对象在保留期结束之前不能被删除或修改，即使是管理员也不行。

存储为秘密的应用程序数据库凭据必须自动轮换，而不会导致应用程序停机。

→使用配置了自动轮换的 Secret Manager。轮换会触发一个 Cloud Function，该函数更新数据库中的密码并创建新的秘密版本。

原因: 托管的自动化轮换降低了凭据泄露的风险。应用程序引用 `latest` 版本以无缝获取新秘密。

工作负载处理高度敏感的数据，即使在内存中（使用中）也必须保持加密。

→通过在 Confidential VMs 上部署工作负载来使用 Confidential Computing。

原因: 提供基于硬件的内存加密，保护数据免受虚拟机监控程序和其他 VM 的影响。使用 attestation 验证环境的完整性。

限制对 BigQuery 表中特定敏感列的访问，而无需创建单独的视图。

→使用 BigQuery 列级安全性。将 Data Catalog 策略标签应用于敏感列，并向授权用户/组授予这些策略标签上的“细粒度读取者”角色。

原因: 直接在表上强制执行细粒度访问，这比维护多个授权视图更具可扩展性和可管理性。

即使 IAM 权限配置错误并授予公共访问权限，也要保护 GCS 存储桶中的敏感数据。

→使用客户管理的加密密钥 (CMEK) 加密对象，并在 Cloud KMS 中严格控制对该密钥的访问。

原因: 创建了一个双密钥系统。攻击者需要 GCS 对象和 KMS 密钥的权限才能解密数据，从而提供纵深防御。

防止意外或恶意立即删除关键的 Cloud KMS 密钥。

→创建密钥时，将 `destroy_scheduled_duration` 属性配置为 30 天等值。

原因: 在密钥永久销毁之前强制执行等待期，提供了一个从意外删除中恢复的窗口。

法律要求证明 Cloud Storage 中的文件自上传以来未被更改。

→下载时，重新计算文件的 MD5 或 CRC32C 哈希值，并将其与 Cloud Storage 对象元数据中存储的哈希值进行比较。

原因: 提供对象完整性的加密证明。Cloud Storage 在上传时自动计算并存储这些哈希值。

即使是具有 `owner` 角色的用户，也防止数据从敏感项目复制到公共存储桶。

→将敏感项目放置在 VPC Service Controls 边界内。这限制了数据移动到边界之外的其他项目。

原因: VPC Service Controls 充当以数据为中心的防火墙，覆盖数据流出的 IAM 权限，为防止数据泄露提供了强大的防御。

参考↗

保护面向公众的 Web 应用程序免受容量型 DDoS 攻击和常见 Web 漏洞利用（例如 SQLi、XSS）的侵害。

→将应用程序放置在全球外部 HTTP(S) 负载均衡器后面，并附加一个带有预配置 WAF 规则的 Cloud Armor 安全策略。

原因: 负载均衡器在 Google 边缘吸收 DDoS 攻击。Cloud Armor 提供托管的 Web 应用程序防火墙以阻止 OWASP Top 10 威胁。

Dedicated Interconnect 用于本地到 GCP 的连接，但出于合规性，流量必须加密。

→在 Cloud Interconnect VLAN 附件上配置 HA VPN 隧道。

原因: 将专用连接的高带宽和低延迟与 VPN 的 IPsec 加密相结合。

本地系统需要调用 Google API（例如 BigQuery、GCS），而无需遍历公共互联网。

→为本地主机配置 Private Google Access。使用 Cloud Interconnect 或 VPN，并配置 DNS 将 `*.googleapis.com` 解析到受限 VIP 范围。

原因: 将流向 Google 服务的流量保留在 Google 的专用网络上，从而增强安全性并可能降低出口成本。

在 GKE 集群内，对所有服务到服务通信强制执行相互 TLS (mTLS)。

→部署 Anthos Service Mesh（或 Istio）并为相关命名空间启用严格的 mTLS 对等身份验证。

原因: 自动加密并验证网格内的所有流量，无需更改应用程序代码即可实现零信任网络模型。

消费者 VPC 需要私下访问在生产者 VPC 中运行的服务（例如，内部 API），而无需使用对等连接或公共 IP。

→生产者使用 Private Service Connect 发布服务。消费者在其 VPC 中创建一个终结点，该终结点私下路由到服务。

原因: 将网络连接与服务访问解耦。这是一种现代、可扩展的方式，可在 VPC 和组织之间提供对服务的私有访问。

部署一个 GKE 集群，其中节点没有公共 IP，并且控制平面不暴露给互联网。

→创建私有 GKE 集群。在子网上启用 Private Google Access，以便节点访问 GCP API。配置主授权网络以将控制平面访问限制为特定 IP（例如，公司网络）。

原因: 通过移除节点和控制平面的公共终结点，显著减小了集群的攻击面。

在 GKE 集群中，`frontend` 服务的 Pod 只能与 `backend` 服务的 Pod 通信，不能与其他任何服务通信。

→创建 Kubernetes NetworkPolicy 资源。根据 Pod 标签，将入站策略应用于 `backend` Pod，只允许来自 `frontend` Pod 的流量。

原因: 在集群内提供 Pod 级别防火墙，为微服务启用最小特权网络模型。

没有外部 IP 的 VM 需要访问互联网。所有出站流量必须源自一小组可预测的 IP 地址，以便第三方列入白名单。

→为包含 VM 的子网配置 Cloud NAT。

原因: 为来自私有实例的互联网出站流量提供托管网络地址转换，并具有集中式日志记录和 IP 分配。

在整个组织中强制执行基线防火墙规则，例如拒绝来自互联网的所有 SSH 流量，且项目团队无法覆盖。

→在组织或文件夹级别创建分层防火墙策略，并以高优先级配置拒绝来自 `0.0.0.0/0` 的端口 22 规则。

原因: 分层策略在 VPC 级别规则之前进行评估，允许中央安全团队强制执行不可协商的网络安全防护。

在 VPC 内解析内部主机名，而不会将查询泄露给公共 DNS 服务器。

→为您的内部域配置 Cloud DNS 私有托管区域，并将其与您的 VPC 相关联。

原因: 为 VPC 网络内的内部资源提供权威 DNS，提高安全性和可管理性。

当 Security Command Center 检测到威胁（例如加密挖矿）时，自动隔离受影响的 VM。

→配置 SCC 将发现发布到 Pub/Sub 主题。触发一个 Cloud Function，该函数接收发现并修改 VM 的网络标签，以应用预配置的“隔离”防火墙规则。

原因: 实现近实时、自动化的事件响应，减少攻击者在环境中停留的时间。

收集组织中所有项目的审计日志，并以不可变格式存储 7 年以满足合规性要求。

→创建组织级日志接收器到 Cloud Storage 存储桶。为目标存储桶配置 7 年保留策略和 Bucket Lock。

原因: 聚合接收器集中日志。Bucket Lock 确保日志防篡改并满足严格的合规性保留要求。

VM 疑似遭到入侵。必须立即将其下线，但必须保留证据以进行取证分析。

→停止 VM 实例（以停止活动）并立即创建其持久磁盘的快照。然后，使用防火墙规则隔离它。

原因: 停止实例可遏制威胁，而快照可创建磁盘的时间点副本以供分析，而不会有证据篡改的风险。

检测服务账号何时从异常地理位置使用或执行异常活动。

→启用 Security Command Center 高级版，其中包括事件威胁检测。此服务分析日志以查找异常行为。

原因: 利用 Google 的威胁情报和机器学习来检测难以通过基于规则的警报发现的威胁，例如受损凭据。

中央安全团队需要在单个平台中分析和关联来自 GCP、AWS 和本地系统的安全信号。

→将所有相关日志和遥测数据摄取到 Chronicle Security Operations (SIEM) 中。

原因: Chronicle 是专为 PB 级分析而设计的云原生 SIEM，具有用于多云和混合环境的内置解析器和检测规则。

检测 Terraform 管理的 GCP 资源何时通过控制台手动修改，从而产生配置漂移。

→配置 Cloud Asset Inventory 订阅源，将实时资产更改通知发送到 Pub/Sub 主题。然后，服务可以将这些更改与 Terraform 状态进行比较。

原因: 提供对所有资源更改的实时可见性，从而实现带外修改的自动检测。

一个组织有数千个 SCC 发现，需要专注于对关键资产构成最直接风险的那些。

→在 SCC 高级版中使用攻击路径模拟。定义高价值资产，模拟将识别并优先处理形成通往这些资产的直接路径的发现。

原因: 从基于漏洞的优先级转向基于风险的优先级。它突出了攻击者可能利用的发现的有害组合。

检测正在运行的 GKE 容器内的恶意活动，例如意外的 shell 或反向 shell 连接。

→在 Security Command Center 中启用容器威胁检测。

原因: 提供对容器行为的运行时可见性，检测漏洞扫描（在运行时之前发生）无法发现的威胁。

网络取证调查需要捕获和分析两个特定 VM 之间流量的完整数据包内容。

→配置 Packet Mirroring 以克隆源 VM 的流量，并将其发送到运行 Wireshark 或 Zeek 等检查工具的收集器 VM。

原因: 提供完整的数据包捕获以进行深度分析，这与仅包含元数据的 VPC 流日志不同。

防止不安全的 Terraform 配置（例如公共 GCS 存储桶）被部署。

→将 `tfsec` 或 Checkov 等静态分析安全测试 (SAST) 工具集成到 CI/CD 流水线中。如果发现安全违规，则使构建失败。

原因: 通过在部署前捕获错误配置来实现“左移”安全，减少了反应式补救的需要。

公司必须确保出于合规性原因，某些数据和处理只能在欧盟地区进行。

→应用 `gcp.resourceLocations` 组织策略约束，只允许指定的欧盟地区。

原因: 这是一种技术性的预防性控制，在资源创建级别强制执行数据驻留，这是 GDPR 等法规所要求的。

金融机构要求 Google 支持工程师在访问其数据以进行支持案例之前，必须获得明确的、有时间限制的批准。

→启用 Access Approval 并配置批准者。所有来自 Google 的访问请求都将生成一个必须获得批准的请求。

原因: 提供客户控制的 Google 管理访问权限，这是高度监管行业的一项关键要求。

审计员需要验证 Google 人员在被授予您的环境访问权限时具体执行了哪些操作。

→启用并审查 Access Transparency 日志。这些日志提供 Google 员工所执行操作的近实时反馈。

原因: 提供 Google 管理员操作的不可变审计跟踪，提供可见性并支持合规性要求。

持续监控 GCP 环境，查找违反特定合规标准（例如 PCI DSS 或 HIPAA）的配置。

→在 Security Command Center 中使用 Security Health Analytics，并在仪表板中启用相关的合规标准。

原因: 根据行业基准自动执行合规性检查，提供持续可见性并为任何检测到的错误配置生成发现。

审计员请求 Google 的 SOC 2 Type II 报告和 PCI DSS 合规证明。

→使用 Google Cloud 控制台中的 Compliance Reports Manager 访问和下载审计报告和认证。

原因: 为客户提供自助服务门户，以获取必要的合规性文档，支持其自身的审计流程。

美国政府机构需要部署符合 FedRAMP High 合规性要求的工作负载。

→在为 FedRAMP High 合规制度配置的 Assured Workloads 环境中部署应用程序。

原因: Assured Workloads 自动应用必要的控制和防护措施（例如数据位置、人员访问限制），以帮助满足特定的合规标准。