在 Google Cloud 上缓解 OWASP Top 10:2025

本文档介绍了有助于防范 OWASP Top 10:2025 中列出的应用级攻击的 Google Cloud 服务和缓解策略。OWASP Top 10:2025 由 Open Web Application Security (OWASP) Foundation（开放式 Web 应用安全基金会）创建，列出了软件开发生命周期 (SDLC) 中的十大安全风险。虽然没有任何服务可以保证完全防范这些风险，但将合适的服务应用于您的架构有助于构建强大的多层安全解决方案。

Google 基础架构旨在帮助您构建、部署和运营具有强大安全控制措施的服务。物理和运营安全性、静态加密和传输中的数据加密以及许多其他基础架构保护措施都由 Google 进行管理。将应用部署到 Google Cloud可以天然获得上述优势，但您可能需要采取额外措施来帮助保护应用免受特定攻击。

合规性矩阵

下表中列出的 Google Cloud 服务可以帮助防范 OWASP Top 10:2025 确定的十大安全风险：

OWASP Top 10：2025 年类别 主要 Google Cloud 和 Wiz 控制

A01：访问权限控制中断

Access Context Manager、Agent Gateway、Agent Identity、Apigee、Google Cloud Armor、Firebase App Check、Firebase Security Rules、Cloud Next Generation Firewall (Cloud NGFW)、Identity-Aware Proxy (IAP)、Identity and Access Management (IAM)、Organization Policy Service、VPC Service Controls、Wiz Cloud

A02：安全配置错误

Access Context Manager、Cloud Asset Inventory、Google Security Operations、组织政策、Security Command Center 高级方案、VPC Service Controls、Wiz Cloud

A03：软件供应链故障

Artifact Registry、Assured Open Source Software (Assured OSS)、Binary Authorization、Cloud Build、Cloud Deploy、Cloud Workstations、CodeMender、Wiz Code

A04：加密失败

Apigee、Certificate Authority Service、Certificate Manager、Cloud Key Management Service、Cloud Load Balancing、Cloud Workstations、机密计算、Organization Policy、Secret Manager、Sensitive Data Protection、Wiz Cloud

A05：注入

Apigee、Cloud Armor、CodeMender、Firebase 安全规则、Cloud Next Generation Firewall (Cloud NGFW)、Model Armor、Security Command Center 高级方案、VirusTotal、Wiz Code

A06：不安全的设计

Apigee、CodeMender、Mandiant、Wiz Cloud

A07：身份验证失败

Access Context Manager、代理身份、Apigee、Cloud Armor、Cloud Identity、Firebase App Check、Firebase Authentication、Google Cloud Fraud Defense、IAM（Privileged Access Manager、工作负载身份联合和 Workforce Identity Federation）、IAP、Identity Platform、Security Command Center 高级方案、Secret Manager、Titan 安全密钥、Wiz Code

A08：软件或数据完整性失败

Artifact Analysis、Assured OSS、Binary Authorization、Cloud Armor、Cloud Build、Cloud Deploy、Firebase App Check、Security Command Center 高级方案、VirusTotal、Wiz Defend

A09：安全日志记录和提醒失败

访问审批和 Access Transparency、Apigee、Google SecOps、Cloud Logging、Cloud Monitoring、Sensitive Data Protection、Wiz Defend

A10：异常情况处理不当

Cloud Armor、Cloud Load Balancing、Error Reporting、Model Armor

Google Cloud 服务

以下部分介绍了核心Google Cloud 服务的 OWASP Top 10 最佳实践。

Access Approval 和 Access Transparency

借助 Access Transparency 和 Access Approval，您可以验证云服务商的访问权限。借助 Access Transparency，您可以记录 Google 员工每次访问的原因。借助 Access Approval，您可以批准或拒绝为您提供支持服务的 Google 人员的访问请求。

适用于 A09：安全日志记录和提醒失败。

不妨参考以下最佳实践：

  • 自动执行访问权限审批流程。为此，请配置 Access Approval，以将传入的访问审批请求元数据发送到 Pub/Sub 主题。创建 Pub/Sub 订阅，将 JSON 载荷推送到您的自定义 Webhook 端点（例如经过身份验证的 Cloud Run 服务、Cloud Run functions 或企业 API 网关）以进行处理。
  • 将 Access Transparency 日志视为关键安全遥测数据。在 Monitoring 中创建基于日志的指标和提醒政策，以便在 Google 员工在没有有效的相应支持服务工单的情况下访问敏感资源时，向您的安全运营中心 (SecOps) 发出提醒。
  • 直接将 Access Transparency 日志导出到 Google SecOps 或集中式企业 SIEM。
  • 创建合规性政策，定期审核日志流，并验证 auto_approved 紧急访问事件是否与已记录的高严重程度突发事件相关联。
  • 如需进行加密控制，请使用 Key Access Justifications 强制系统以编程方式请求密钥解密审批。

Access Context Manager

Access Context Manager 是Google Cloud的情境感知访问权限引擎。借助 Access Context Manager，您可以为 IAP、VPC Service Controls 和 IAM 定义基于属性的访问权限级别（例如客户端 IP 地址范围、设备安全状况和地理位置）。

适用于以下情况：

  • A01：访问权限控制中断
  • A02：安全配置错误
  • A07：身份验证失败

请查看以下有关 A01：访问权限控制中断的最佳实践：

  • 为组织的访问权限政策构建可重复使用的分层安全级别。创建基本访问权限级别以测试标准属性。对于复杂的多因素条件，请部署自定义访问权限级别，以评估高级设备状态和第三方端点信号。
  • 使用端点验证或 Chrome 企业核心版来强制执行设备级限制，例如全磁盘加密、有效的屏幕锁定和获批的操作系统版本。
  • 为了帮助您使用 VPC Service Controls 保护高价值数据存储库，请向 VPC Service Controls 入站流量规则添加访问权限级别。如果服务账号密钥泄露，攻击者无法仅使用该密钥从未经授权的公共 IP 地址或不受信任的机器查询 BigQuery 或 Cloud Storage。
  • 如需将零信任保护扩展到 Web 应用和虚拟机管理隧道，请直接将访问权限级别附加到受 IAP 保护的资源。

请查看以下有关 A02：安全错误配置的最佳实践：

  • 实现绑定到特定文件夹的范围限定的访问权限政策，以将本地政策管理权限委托给各个项目团队，并将其更改与组织的其余部分隔离开来。
  • 为防止孤立的入站规则成为静默后门，请定期检查并移除已停用的 IP 范围、已过期的合作伙伴子网和过时的设备属性。

请查看以下有关 A07：身份验证失败的最佳实践：

  • 使用用户访问权限绑定来设置严格的会话时长上限。配置重新身份验证政策，以要求使用 SECURITY_KEY（FIDO2 或 WebAuthn）。如需对高风险环境应用更严格的限制，请配置 scopedAccessSettings 以替换敏感应用的默认会话时长。

Agent Gateway 和代理身份

Agent Gateway 和 Agent Identity 可为 AI 智能体和智能体工作流提供专用网络政策执行、身份生命周期管理和加密身份验证。

适用于以下情况：

  • A01：访问权限控制中断
  • A07：身份验证失败

请查看以下有关 A01：访问权限控制中断的最佳实践：

  • 在具有多智能体系统、外部 MCP 工具或自主流水线的环境中，使用代理网关作为专用网络和政策执行点，有助于缓解智能体访问控制失败问题。
  • 为代理身份配置精细的授权政策，以将工具访问权限和数据检索权限限制为仅限代理特定工作流所需的资源。

请查看以下有关 A07：身份验证失败的最佳实践：

  • 如需对自主代理和工具集成进行身份验证，而无需嵌入静态 API 密钥或密码，请为每个代理生成并分配代理身份。
  • 配置代理身份以颁发 X.509 证书作为代理的凭据。这些证书有助于防止令牌被盗，这样一来，即使访问令牌被拦截，该令牌也无法在其他环境中使用。

Apigee

Apigee 提供集中式网关级机制，使用 API 代理来强制执行加密标准、验证签名载荷，以及加密传输中和静态的应用数据。Apigee 充当 API 流量的反向代理网关，用于运行边界和结构检查，以帮助验证载荷。Apigee 提供内置的 API 身份验证、OAuth 和 JSON Web 令牌 (JWT) 验证政策，以建立强大的身份边界。Apigee 提供了多种方法可供您执行日志记录、监控、错误处理和审核日志记录。

适用于以下情况：

  • A01：访问权限控制中断
  • A04：加密失败
  • A05：注入
  • A06：不安全的设计
  • A07：身份验证失败
  • A09：安全日志记录和提醒失败

请查看以下有关 A01：访问权限控制中断的最佳实践：

  • 使用 API 代理完成以下操作：

    • 拦截攻击者尝试通过操纵 API 请求路径中的 ID 变量来访问其他用户记录的请求。

    • 阻止标准客户端执行受限的管理方法或高权限操作。

  • 对于 API 管理平面，请使用加密的键值映射、Secret Manager 或 Kubernetes Secret（仅限混合部署）强制执行访问控制、身份验证和 Secret 存储。

  • 使用 OAuth 政策和 JWT 令牌验证签名。将敏感端点和操作映射到高权限的精细 OAuth 范围（例如 delete:account 或 write:billing）。使用 OAuthV2 政策在 API 入口点验证这些范围，并向任何没有正确权限的客户端返回 HTTP 403 Forbidden 状态代码。

  • 启用 Advanced API Security 以分析流量中的异常行为模式，并开始执行安全操作。

请查看以下有关 A04：加密失败的最佳实践：

  • 在流量到达后端应用之前，加密应用中的敏感数据并强制执行严格的加密验证。使用 Cloud KMS，通过客户管理的加密密钥 (CMEK) 配置 Apigee 环境。
  • 使用单向和双向 TLS 在协议级别加密敏感信息。对于服务器到服务器或高风险业务集成，请在 Apigee 入站流量网关上配置双向 TLS (mTLS)。
  • 使用 VerifyJWT 和 VerifyJWS 政策要求传入的令牌在请求处理之前具有有效的加密签名。使用标准的 OAuth 技术，并考虑实现 HMAC、载荷哈希、状态或 nonce 验证，以及用于代码交换的证明密钥 (PKCE)，以加密方式强化每个请求。
  • 遮盖敏感数据，以便在使用 Apigee 调试工具时对数据进行加密和隐藏。

请查看以下有关 A05：注入的最佳实践：

请查看以下有关 A06：不安全的设计的最佳实践：

请查看以下有关 A07：身份验证失败的最佳实践：

  • 为面向开发者的 API 实现 API 密钥验证，以便 Apigee 检查客户端应用的 API 密钥是否存在、是否有效，以及是否已获授权来访问所请求的 API 资源。
  • 为帮助防止会话令牌被盗和重放攻击，请实现所有权证明 (DPoP)。DPoP 将令牌绑定到发送者的公钥，以缓解令牌重放攻击。
  • 通过将 SpikeArrest 速率限制与 reCAPTCHA Enterprise 集成相结合，防御针对令牌生成和登录端点的自动化暴力攻击。

请查看以下有关 A09：安全日志记录和提醒失败的最佳实践：

  • 以异步方式将结构化 API 交易元数据流式传输到 Logging 或第三方 SIEM。将 MessageLogging 政策附加到 PostClientFlow，该政策会在响应传递给客户端后运行。
  • 集中管理平台审核日志，以跟踪对 API 代理、凭据和部署环境的修改。为防止未经授权的代理修改被忽略，请将 Apigee 与 Cloud Audit Logs 集成。如需了解详情，请参阅 Apigee 审核日志记录和 Apigee API 管理审核日志记录。
  • 在 Monitoring 中配置 Advanced API Security 提醒，以便在出现自动化抓取活动、凭据滥用和安全得分回归时通知 SecOps 团队。
  • 通过将用户提供的变量封装在 escapeJSON() 函数中，对日志消息模板中的这些变量进行清理。
  • 如果您将日志元数据流式传输到外部 SIEM，请将 MessageLogging 政策配置为使用 Syslog over TLS（TCP 端口 6514）来加密传输中的数据。

Artifact Registry 和 Artifact Analysis

Artifact Registry 让组织可以在一个位置管理容器映像及语言软件包。Artifact Analysis 为存储在 Artifact Registry 中的制品提供集成的漏洞扫描、软件物料清单 (SBOM) 生成和元数据存储功能。

适用于以下情况：

  • A03：软件供应链故障
  • A08：软件或数据完整性失败

请查看以下有关 A03：软件供应链故障的最佳实践：

  • 通过配置清理政策，在预定义的保留期限过后删除未指定版本、未添加标记或过时的候选版本映像，从而减少攻击面并有助于防止部署存在漏洞的旧版映像。
  • 通过配置具有上游代码库优先级的虚拟代码库来防范依赖项混淆攻击，这些优先级可确保内部制品代码库优先于公共注册表。
  • 强制执行不可变的映像标记或严格按加密摘要 (sha256:...) 进行部署，以防止标记突变攻击。

请查看以下有关 A08：软件和数据完整性失败的最佳实践：

Assured OSS

借助 Assured OSS，您可以将 Google 验证和使用的 OSS 软件包纳入您自己的开发者工作流中。

适用于以下情况：

  • A03：软件供应链故障
  • A08：软件或数据完整性失败

请查看以下有关 A03：软件供应链故障的最佳实践：

  • 配置远程代码库以指向 Assured OSS 上游。
  • 验证 build 中的开源库是否包含有效的 Google 签名和可验证的 SLSA build 出处记录。在 Cloud Build 中配置质量关卡，以在编译应用二进制文件之前验证这些证明。
  • 将 Cloud Workstations 基础映像中的软件包管理器（例如 pip.conf、settings.xml 或 build.gradle）配置为仅指向您的内部 Assured OSS 软件仓库。
  • 使用 Assured OSS 生成的元数据来确定新披露的开源软件包中的 CVE 是否可在您的特定部署环境中被利用。

请查看以下有关 A08：软件和数据完整性失败的最佳实践：

Binary Authorization

Binary Authorization 会验证容器的完整性，以便仅部署受信任的容器映像。您可以创建政策以根据是否存在证明来允许或拒绝部署。Binary Authorization 在集群级层应用政策，因此您可以为不同的环境配置不同的政策。

适用于以下情况：

  • A03：软件供应链故障
  • A08：软件或数据完整性失败

请查看以下有关 A03：软件供应链故障的最佳实践：

  • 配置部署流水线，以通过容器映像的唯一且不可变的 SHA-256 加密摘要（例如 @sha256）来引用和强制执行容器映像。
  • 在 GKE 集群上部署Binary Authorization Continuous Validation，以根据平台政策监控活跃的 Pod，并在运行的容器不再合规时在日志记录中生成提醒。

请查看以下有关 A08：软件和数据完整性失败的最佳实践：

  • 在 Cloud Build 或 GitHub Actions 流水线中强制执行自动生成证明。创建逐步证明要求，以便映像在越来越接近生产环境时通过一系列验证关卡。
  • 对于严重程度较高的生产环境突发事件，请启用 breakglass 紧急部署。针对紧急情况下的审核日志事件配置 Monitoring 提醒政策，以便在发生准入绕过时通知您的 SecOps 团队。

CA Service 和 Certificate Manager

Certificate Authority Service (CA Service) 可简化私有证书授权机构 (CA) 的部署和管理。Certificate Manager 可为 Cloud Load Balancing 和 Cloud CDN 集中配置、续订和管理 TLS 证书。

适用于 A04：加密失败。

不妨参考以下最佳实践：

  • 使用 CA Service 自动执行私有证书的颁发和生命周期管理。 部署由 Cloud HSM 支持的根 CA 和中间 CA 来保护私钥，并使用证书模板来强制执行加密政策（例如最低密钥长度和允许的扩展密钥用途）。
  • 启用 Cloud Audit Logs，以监控高风险管理事件（例如 CA 撤消、政策更新或证书申请突然激增）。将提醒路由到 Google SecOps，以检测潜在的内部人员威胁或遭到入侵的 CI/CD 流水线。
  • 将 Certificate Manager 配置为使用与 DNS 授权配对的 Google 管理的证书。 Certificate Manager 会验证网域所有权、颁发 X.509 证书，并在证书失效前 30 天处理续订事宜。
  • 将证书映射附加到目标 HTTPS 代理，以实现动态证书选择和证书轮换，而无需重新启动代理或重新配置负载均衡器。
  • 对于内部微服务或混合负载均衡，请配置证书映射，以便直接从私有 CA Service CA 池颁发私有证书。
  • 配置证书映射，以将传入的服务器名称指示 (SNI) 请求与特定证书相匹配。

Cloud Asset Inventory

借助 Cloud Asset Inventory，您可以监控 Google Cloud 上的基础架构，以查找孤立或未经授权的 IT 基础架构。

适用于 A02：安全配置错误。

不妨参考以下最佳实践：

  • 设置通知以提醒您意外运行了可能受到不当保护或使用了过期软件的资源。
  • 使用 IAM Policy Analyzer 发现配置错误的访问权限控制，例如具有 allUsers 权限的公共存储分区、特权过高的服务账号角色或孤立的身份。
  • 将资产快照导出到 BigQuery，以便随着时间的推移审核基础架构配置，并在多项目环境中维护基准合规性记录。

Cloud Armor

Cloud Armor 是一种自适应 Web 应用防火墙 (WAF)，可部署在 Google Cloud 网络边缘，帮助防范 DDoS 攻击并阻止 SQLi 或 XSS 注入载荷。Cloud Armor 包含预配置的 WAF 规则，可用于防御 OWASP 十大风险漏洞、限制身份验证端点的攻击面，以及屏蔽遭入侵的凭据。

适用于以下情况：

  • A01：访问权限控制中断
  • A05：注入
  • A07：身份验证失败
  • A08：软件或数据完整性失败
  • A10：异常情况处理不当

请查看以下有关 A01：访问权限控制中断的最佳实践：

  • 应用预配置的 WAF 规则（例如 evaluatePreconfiguredWaf('lfi-stable')）来阻止本地文件包含和路径遍历攻击。
  • 通过配置安全政策规则来强制执行地理位置访问权限控制（也称为地理围栏），该规则使用 origin.region_code 属性根据传入流量的来源国家/地区代码来匹配流量。
  • 使用威胁情报 Feed 阻止已知的恶意 IP 地址。
  • 通过编写匹配规则，限制对敏感网址（例如 /admin、/login 或 /config）的外部访问。
  • 在负载均衡器上启用 Cloud Armor 路径规范化，强制 Cloud Armor 在评估安全政策之前对传入的网址进行解码和标准化处理。

请查看以下有关 A05：注入的最佳实践：

请查看以下有关 A07：身份验证失败的最佳实践：

请查看以下有关 A08：软件和数据完整性失败的最佳实践：

  • 使用如下所示的拒绝规则，将接受来自不可信来源的高风险序列化对象的端点限制为一组可信 IP 地址：

    request.path.contains('/endpoint') && !inIpRange(origin.ip, '192.0.2.1/32')

  • 部署自定义规则，以检查请求正文关键字是否存在特定于语言的执行模式和不安全的反序列化签名。

请查看以下有关 A10：异常情况处理不当的最佳实践：

  • 在安全政策中启用 Google Cloud Armor Adaptive Protection，以便确定正常流量模式的基准、针对第 7 层异常情况配置提醒，并生成包含攻击签名的有针对性的 WAF 规则。
  • 在关键端点（例如 /login、/checkout 或搜索 API）上配置 Cloud Armor 速率限制规则。速率限制规则会根据每个客户端 IP 或 HTTP 标头来限制请求（例如，将客户端限制为每分钟 100 个请求），并返回 HTTP 429 Too Many Requests 状态代码。
  • 将 Cloud Armor 安全政策中的最低优先级默认规则设置为 Deny（状态代码：403 或 404）。

Cloud Build 和 Cloud Deploy

Cloud Build 和 Cloud Deploy 在Google Cloud上提供了一个集成式安全持续集成和持续交付 (CI/CD) 流水线。Cloud Build 可构建具有可验证 SLSA provenance和加密证明的制品，而 Cloud Deploy 可管理 GKE 和 Cloud Run 中的渐进式发布、目标审批和自动化验证。

适用于以下情况：

  • A03：软件供应链故障
  • A08：软件或数据完整性失败

请查看以下有关 A03：软件供应链故障的最佳实践：

  • 在 cloudbuild.yaml 文件中设置 requestedVerifyOption: VERIFIED，以要求提供可验证的出处。
  • 部署与专用 VPC 网络对等互连的 Cloud Build 专用池，以用于敏感的企业 build。
  • 配置构建触发器，使其在专用用户代管式服务账号下运行。仅向这些服务账号授予所需的最低 IAM 允许权限（例如 Artifact Registry Writer (roles/artifactregistry.writer) 和 Logs Writer (roles/logging.logWriter)）。
  • 要求对以预演或生产环境为目标的 Cloud Build 触发器进行手动审批。
  • 将 CI 构建工具（例如 Cloud Build、GitHub Actions 或 GitLab）限制为仅具有 Cloud Deploy Releaser (roles/clouddeploy.releaser) 角色，以便构建流水线只能创建版本。
  • 如需要求手动审批，请在您的交付流水线清单 (delivery-pipeline.yaml) 中，为您的预发布和生产目标配置 requireApproval: true。
  • 使用特定于目标的服务账号（例如，一个服务账号的权限仅限于暂存命名空间，而另一个服务账号用于生产环境，并经过审核）配置执行环境。
  • 部署自定义钩子，以便在发布生命周期内运行带外安全断言。使用部署前钩子验证目标集群是否满足合规性基准，并使用部署后钩子针对实时容器端点启动自动漏洞扫描。

请查看以下有关 A08：软件和数据完整性失败的最佳实践：

  • 将 Cloud Build 与 Cloud KMS 和 Artifact Analysis 集成，以便在单元测试和静态分析测试成功完成后创建并签署加密证明。
  • 在 cloudbuild.yaml 的构建器步骤中使用不可变的加密 SHA-256 摘要（例如 golang@sha256:...）。
  • 将 build 配置存储在受分支保护规则（例如强制要求对拉取请求进行双人审核）保护的版本控制代码库中。使用用户代管式服务账号将触发器修改权限限制为授权的平台管理员。
  • 在各个目标阶段之间提升相同的预渲染部署清单和不可变的容器映像摘要，而不允许 CI 流水线在暂存阶段和生产阶段之间更改清单。
  • 在 skaffold.yaml 清单中定义自动化的部署验证任务。 Cloud Deploy 会在部署 pod 后运行这些验证容器，以执行动态健康检查、集成测试和 API 契约断言。
  • 使用 Canary 部署策略。如果 Skaffold 验证测试失败，或者在 Canary 阶段，监控功能检测到异常阈值，Cloud Deploy 会暂停发布，并将流量回滚到上次已知良好的版本。
  • 配置 GKE 集群和 Cloud Run 以强制执行 Binary Authorization 政策。当 Cloud Deploy 应用清单时，目标准入控制器会以加密方式验证容器映像摘要，并拒绝不受信任的工件。

Cloud Identity 和 Titan 安全密钥

Cloud Identity 可在 Google Cloud和 Google Workspace 中集中管理身份、凭据生命周期和访问权限。Titan 安全密钥是基于硬件的防钓鱼式攻击安全设备，使用基于 FIDO2 或 WebAuthn 标准的公钥加密技术。

适用于 A07：身份验证失败。

不妨参考以下最佳实践：

  • 为了帮助防范中间人 (PITM) 钓鱼式攻击，请配置两步验证 (2SV)，并将允许的方法设置为仅限安全密钥（FIDO2、WebAuthn 或 Titan 安全密钥）。
  • 配置基于 SAML 2.0 或 OIDC 的单点登录 (SSO)，同时使用公司身份提供方进行自动化配置。
  • 将Google Cloud 会话时长政策设置为较低的上限，以强制用户定期重新进行身份验证。
  • 将 Titan 安全密钥注册为通行密钥，以启用无密码身份验证，从而显著降低暴力破解和凭据泄露风险。
  • 通过在 Cloud Identity 中强制执行安全密钥政策，要求您的特权身份（例如项目所有者、结算管理员和 SecOps 团队）使用 Titan 安全密钥进行双重身份验证。让高风险用户加入高级保护计划。

Cloud KMS

Cloud KMS 可为兼容的 Google Cloud 服务和您自己的应用管理对称和非对称加密密钥。您可以为对称加密、非对称签名、非对称加密和 MAC 签名生成、使用、轮替和销毁加密密钥。

适用于 A04：加密失败。

不妨参考以下最佳实践：

  • 使用 Cloud KMS Autokey 自动执行预配和分配。借助 Autokey，您无需提前预配密钥环、密钥和服务账号。而是会在创建资源时按需生成密钥和密钥环。
  • 在将敏感载荷发送到存储分区或数据库之前，使用 Cloud KMS 密钥对其进行加密。您可以使用 Cloud KMS API 或客户端库，将 Cloud KMS 密钥用于客户端加密。
  • 通过在传输过程中验证校验和，验证端到端数据完整性。
  • 对于需要严格遵守合规性要求的工作负载，请使用 Cloud HSM 存储和运行加密操作。Cloud HSM 会将您的密钥存储在经过 FIPS 140-3 3 级验证的硬件安全模块中。
  • 在设定的时间范围内（例如每 90 天）配置自动密钥轮替时间表。

Cloud Load Balancing

Cloud Load Balancing 是一项完全分布式、软件定义的代管式服务，可在多个后端实例和区域之间分配用户流量。

适用于以下情况：

  • A04：加密失败
  • A10：异常情况处理不当

请查看以下有关 A04：加密失败的最佳实践：

请查看以下有关 A10：异常情况处理不当的最佳实践：

Google Cloud Observability（日志记录、监控和 Error Reporting）

Google Cloud Observability 提供全栈日志管理（通过 Logging 实现）、指标和提醒（通过 Monitoring 实现），以及实时应用崩溃跟踪（通过 Error Reporting 实现）。

适用于以下情况：

  • A09：安全日志记录和提醒失败
  • A10：异常情况处理不当

请查看以下有关 A09：安全日志记录和提醒失败的最佳实践：

  • 为存储敏感数据的高价值数据存储区（例如 Cloud Storage、BigQuery 和 Spanner）启用数据访问日志。借助数据访问日志，您可以审核每项敏感数据的读取、写入和查询事件。
  • 为自定义日志记录存储桶强制执行存储桶锁定和保留政策，以帮助防止攻击者或未经授权的管理员删除日志来掩盖其踪迹。
  • 使用汇总接收器来整理日志条目并将其路由到 SecOps 团队的单个中央代码库。配置拦截汇总接收器，以避免将数据访问日志等大容量日志存储在多个位置。
  • 针对严重的安全漏洞指示器（例如“权限遭拒”IAM 错误、意外的 API 密钥创建或突然的防火墙配置更改）配置基于日志的提醒政策。
  • 在 Logs Explorer 或 Monitoring 中部署基于日志的提醒政策。指定针对高严重程度事件（例如未经授权的 IAM 政策修改或 KMS 密钥撤消）的确切过滤条件，以便在系统接收到匹配的日志条目时生成突发事件通知。
  • 在 Logging 中构建基于日志的计数器指标，将匹配的日志条目转换为时间序列数据。然后，在 Monitoring 中构建一个基于指标的提醒政策，当该速率超过特定阈值（例如，在 5 分钟内登录失败次数超过 50 次）时，该政策会启动突发事件。
  • 配置基于日志的提醒政策，以监控对 Cloud Logging API 的管理调用，并在出现意外的日志导出接收器修改或存储桶删除时发出提醒。
  • 使用清晰的文档模板配置通知渠道。包含指向Logs Explorer 查询的直接深层链接、值班工程师的标准操作程序 (SOP) 以及明确的补救措施，有助于快速控制突发事件。

请查看以下有关 A10：异常情况处理不当的最佳实践：

  • 将 Error Reporting SDK 直接集成到应用代码中，或配置 Logging 以解析结构化 JSON 异常格式。
  • 配置 Error Reporting 通知渠道或监控提醒政策，以便在出现新的异常类时通知您的 SecOps 团队。

Cloud NGFW

Cloud NGFW 是一项托管式防火墙服务，可针对南北向流量和东西向流量实现有状态检查和第 7 层应用控制。

适用于以下情况：

  • A01：访问权限控制中断
  • A05：注入

请查看以下有关 A01：访问权限控制中断的最佳实践：

  • 使用全球网络防火墙政策和 IAM 治理的资源标记强制执行网络微细分，以隔离后端应用层并限制子网之间的东西向通信。
  • 在防火墙规则中使用 Google 维护的威胁情报列表，以阻止来自已知恶意行为者、C2 服务器和被盗用僵尸网络的入站连接。

请查看以下有关 A05：注入的最佳实践：

  • 配置入侵检测和防御服务，并使用安全配置文件组来拒绝与 SQL 注入、操作系统命令注入和远程代码执行漏洞利用签名相匹配的威胁。
  • 配置 Cloud NGFW TLS 检查以解密入站和出站 HTTPS 流量，对明文载荷应用 IPS 注入签名检查，并在交付到后端之前重新加密会话。
  • 在后端数据库和计算子网上强制执行基于 FQDN 的出站流量防火墙规则。将出站连接限制为已获批准的预定义外部网域，以帮助防止易受攻击的应用创建未经授权的反向 shell。
  • 在威胁防护配置文件中启用防火墙规则日志记录，并将这些日志路由到 Google SecOps，以将遭屏蔽的网络注入签名与主机级遥测数据相关联，从而确定需要优先修补的目标工作负载。

Cloud Workstations

Cloud Workstations 在 Google Cloud 上提供托管式开发环境，内置安全机制和自定义功能。

适用于以下情况：

  • A03：软件供应链故障
  • A04：加密失败

请查看以下有关 A03：软件供应链故障的最佳实践：

  • 创建存储在 Artifact Registry 中的自定义基础容器映像，其中预安装了安全工具、受信任的开发者扩展程序和获批的语言运行时。
  • 部署具有专用 IP 入站流量和出站流量的工作站集群，并将其置于 VPC Service Controls 边界内。
  • 配置 Cloud Workstations 以通过 IAP 路由会话流量。要求开发者使用公司凭据进行身份验证，并启用多重身份验证 (MFA)，同时强制执行最低权限角色（例如 Cloud Workstations User [roles/workstations.user]）。
  • 配置具有较低超时限制的工作站配置（例如，在非活跃状态持续两小时后自动停止）。工作站重启时，Cloud Workstations 会拉取最新的安全补丁容器映像，以便开发者可以在干净的环境中工作。

请查看以下有关 A04：加密失败的最佳实践：

CodeMender

CodeMender 是一款专业的自主 AI 工程智能体。CodeMender 可以修补新发现的漏洞，并重写现有的旧版代码来解决现有漏洞。您可以在 Gemini Enterprise Agent Platform 中安装和配置 CodeMender。

适用于以下情况：

  • A03：软件供应链故障
  • A05：注入
  • A06：不安全的设计

请查看以下有关 A03：软件供应链故障的最佳实践：

  • 将 CodeMender CLI 集成到本地开发者工作区和 CI/CD 流水线中，以扫描目标模块、验证可利用性，并在提交代码之前发现安全漏洞。
  • 将软件成分分析 (SCA) 和依赖项漏洞报告导入 CodeMender，以运行概念验证漏洞利用验证，并在开发者审核之前过滤掉误报。

请查看以下有关 A05：注入的最佳实践：

  • 在隔离的本地沙盒中运行自动化补丁生成，以重写存在漏洞的逻辑（例如清理输入）。在创建拉取请求之前，请验证单元测试是否通过，以及 PoC 是否不再可被利用。

请查看以下有关 A06：不安全的设计的最佳实践：

  • 使用 CodeMender 的迭代补丁引擎重构旧版或不安全的架构代码逻辑，提供明确的编码限制，以在应用模块中强制执行安全的设计模式。
  • 对 CodeMender 生成的拉取请求和差异保持人工在环审核，以验证建议的更改是否符合您的安全编码准则。

机密计算

机密计算有助于保护使用中的数据，方法是在处理数据时对内存中的数据进行加密。机密计算使用基于硬件的可信执行环境 (TEE)，有助于确保您的敏感数据和加密密钥无法被 Hypervisor、宿主操作系统或基础设施管理员访问。

适用于 A04：加密失败。

不妨参考以下最佳实践：

Firebase（Firebase Authentication、Firebase App Check 和 Firebase 安全规则）

Firebase 提供以开发者为中心的安全控制，涵盖身份、客户端证明和数据库访问权限。Firebase Authentication 处理用户身份和会话管理，App Check 验证客户端应用完整性，而 Firebase 安全规则针对 Firestore 和 Cloud Storage 强制执行基于属性的访问控制和架构验证。

适用于以下情况：

  • A01：访问权限控制中断
  • A05：注入
  • A07：身份验证失败
  • A08：软件或数据完整性失败

请查看以下有关 A01：访问权限控制中断的最佳实践：

  • 在 Firebase 安全规则中，将读取和写入范围限定为经过身份验证的用户的 ID。切勿使用 allow read, write: if true; 等宽松的默认规则。
  • 对于管理角色，请使用 Firebase Admin SDK 在用户的 ID 令牌上设置自定义声明，并在安全规则中验证这些声明，而不是允许客户端写入个人资料。
  • 在 Firebase 安全规则中强制执行 App Check，以在数据库层阻止未经身份验证或伪造的客户端访问。

请查看以下有关 A05：注入的最佳实践：

  • 通过检查传入的文档字段类型、字符串长度和对象大小，在数据库接收之前拒绝格式错误或恶意写入载荷，从而在安全规则中强制执行结构化载荷验证。

请查看以下有关 A07：身份验证失败的最佳实践：

  • 升级到 Firebase Authentication with Identity Platform，即可启用企业级保护功能，例如 MFA with TOTP 和屏蔽函数。
  • 在授予对敏感应用数据的访问权限之前，请使用 Firebase Admin SDK 在后端验证 Firebase ID 令牌。
  • 使用调试提供程序在预演环境中为开发者和 CI/CD 流水线生成临时、有范围的调试令牌。

请查看以下有关 A08：软件和数据完整性失败的最佳实践：

Fraud Defense

Fraud Defense 是一个统一的欺诈和滥用防护平台，可为网站提供聊天机器人、账号和交易防护。 reCAPTCHA 是 Fraud Defense 的一部分，可通过对访问尝试的风险等级进行评分，从而针对聊天机器人和其他形式的自动化和批量流量提供过滤。

适用于 A07：身份验证失败。

不妨参考以下最佳实践：

Google SecOps

Google Security Operations 是一个安全运维平台，可将安全遥测分析 (SIEM)、安全编排、自动化和响应 (SOAR) 以及前沿的 Mandiant 威胁情报整合到一个平台中。

适用于以下情况：

  • A02：安全配置错误
  • A09：安全日志记录和提醒失败

请查看以下有关 A02：安全错误配置的最佳实践：

  • 将 Security Command Center 中的发现结果注入到 Google SecOps 中，以将静态配置错误发现结果（例如 PUBLIC_BUCKET_ACL 或 CMEK_DISABLED）与实时网络和防火墙遥测数据相结合。
  • 构建自动化的 SOAR 响应 playbook 以运行遏制操作。
  • 使用 Gemini 加快错误配置的初步诊断，并接收错误配置的资产、附加的 IAM 角色和分步补救指南的合成摘要。

请查看以下有关 A09：安全日志记录和提醒失败的最佳实践：

  • 将日志遥测数据标准化为统一数据模型 (UDM)，以便快速、标准化地进行多云搜索和关联，而无需原始日志解析开销。
  • 编写 YARA-L 2.0 检测规则，以监控高风险的配置更改，例如停用 OS Login、删除日志接收器或修改 VPC Service Controls 边界。
  • 使用精选的应用威胁情报检测，根据 Mandiant 威胁情报数据评估您的事件数据。
  • 使用 Google SecOps 中的 Gemini 根据自然语言描述生成 YARA-L 检测规则，并将复杂的多阶段突发事件时间轴汇总为高管突发事件摘要。

Identity-Aware Proxy

IAP 为通过 HTTPS 和管理 TCP 连接访问的应用创建一个中央授权层。IAP 会先验证用户身份和情境，然后才授予对 Cloud Run、App Engine、Compute Engine、GKE 和本地资源的访问权限。

适用于以下情况：

  • A01：访问权限控制中断
  • A07：身份验证失败

请查看以下有关 A01：访问权限控制中断的最佳实践：

  • 您可以根据用户的身份、群组成员身份和请求的情境，对 Web 应用、虚拟机、 Google Cloud API 和 Google Workspace 应用实施精细的访问权限控制。
  • 与 Agent Gateway 集成，以针对代理身份强制执行访问权限控制。
  • 使用 IAP TCP 转发功能可与后端实例建立加密的 HTTPS 隧道，并移除面向互联网的 SSH（端口 22）和 RDP（端口 3389）端点。

请查看以下有关 A07：身份验证失败的最佳实践：

  • 使用 IAM 或 Cloud Identity 中预配的身份，通过 IAP 对访问管理界面和 Web 应用的用户进行身份验证。
  • 在应用层验证 x-goog-iap-jwt-assertion 标头内的已签名的 JWT 断言。根据 Google 的公钥验证签名，并验证目标对象 (aud) 声明是否与您的后端服务 ID 相匹配。
  • 为防止攻击者绕过 IAP 身份验证，请配置 Cloud Run 入站流量设置，以仅允许内部流量和 Cloud Load Balancing 流量，从而阻止对后端容器网址的直接公开访问。对于虚拟机或 GKE 节点，请配置 VPC 防火墙规则，以仅接受源自负载均衡器 IP 范围的入站流量。

Identity and Access Management

借助 Identity and Access Management (IAM)，您可以精细管理对 Google Cloud中服务和资源的访问权限。IAM 包含以下功能：

适用于以下情况：

  • A01：访问权限控制中断
  • A07：身份验证失败

请查看以下有关 A01：访问权限控制中断的最佳实践：

  • 使用预定义角色或自定义角色（而非基本角色）将权限限制为满足特定资源或用户需求。
  • 限制授予 Service Account User (roles/iam.serviceAccountUser) 和 Service Account Token Creator (roles/iam.serviceAccountTokenCreator) 角色的权限。
  • 使用 IAM Recommender分析组织的有效使用情况日志，并移除权限过高的账号。
  • 在角色绑定中编写 IAM 条件，以添加情境感知授权，并按日期、时间或来源 IP 地址限制访问权限。
  • 部署Principal Access Boundary (PAB) 政策，以定义正文集可以访问的组织、文件夹或项目。如果攻击者窃取了有效会话，或者服务账号被意外授予了广泛的 IAM 角色，那么当指定资源超出身份的指定边界时，PAB 会阻止访问。
  • 在组织级或文件夹级层附加 IAM 拒绝政策，以阻止高风险权限（例如 iam.serviceAccountKeys.create 或 resourcemanager.projects.delete）。
  • 配置 IAM 拒绝规则时，请在 exceptionPrincipals 列表中声明一个专用紧急情况安全组。在拒绝条件中使用资源标记（例如 resource.matchTag('env', 'prod')），以便在生产资源上阻止破坏性操作，同时允许开发者在开发沙盒项目中灵活地进行操作。

请查看以下适用于 Privileged Access Manager 的 A07：身份验证失败最佳实践：

  • 将关键管理角色（例如所有者 (roles/owner)、Organization Administrator (roles/resourcemanager.organizationAdmin) 和 Security Admin (roles/iam.securityAdmin)）从静态 IAM 绑定转换为 Privileged Access Manager 使用权。配置这些授权，使其在授予提升权限之前需要提供操作理由。
  • 对于生产环境，请配置 Privileged Access Manager 使用权政策，并指定强制审批者，例如中央 SecOps 群组或团队主管。
  • 将 Privileged Access Manager 使用权的时长上限配置为最短的实际操作时间窗口（例如，标准维护为 2 小时，紧急情况操作为 30 分钟）。当计时器到期后，Google Cloud 会移除临时 IAM 角色绑定。
  • 使用非权威性 IAM 资源（例如 google_project_iam_member 或 google_folder_iam_member，而不是 google_project_iam_policy 或 google_project_iam_binding）管理 Terraform 基础架构。这种做法可避免在管理员积极补救突发事件时覆盖 Terraform 流水线或取消同步临时 Privileged Access Manager 角色绑定。
  • 在 Privileged Access Manager 上启用 Cloud Audit Logs，以记录使用权操作和过期事件。 将这些日志提取到 Google SecOps 中，以便在出现可疑的权限提升模式时发出提醒，例如在非工作时间多次请求提升权限，或从意外的地理位置重复请求提升权限。

请查看以下适用于员工身份联合的 A07：身份验证失败的最佳实践：

  • 使用 SAML 2.0 或 OpenID Connect (OIDC) 部署员工身份池，以将外部身份提供方与Google Cloud联合。
  • 在员工身份池中配置会话时长，以限制联合用户令牌的有效期。
  • 在员工身份提供方上强制执行属性条件，以缓解多租户 IdP 令牌伪造或跨组织冒充问题。
  • 映射外部群组成员资格，以便为联合群组主账号集（例如 principalSet://iam.googleapis.com/.../attribute.group/security-engineers）分配 IAM 角色。

请查看以下适用于工作负载身份联合的 A07：身份验证失败最佳实践：

  • 为外部工作负载创建工作负载身份池和提供方。使用短期有效的 OIDC 令牌，并使用 Security Token Service 动态交换这些令牌，以获取在几分钟后过期的临时访问令牌。
  • 对工作负载身份提供方强制执行属性条件，以便外部多租户平台无法从未经授权的代码库或账号向您的池进行身份验证。
  • 将 IAM 角色直接绑定到通过自定义映射的属性过滤的特定主账号集。
  • 配置工作负载访问权限时，请直接向目标资源上的联合 principalSet:// 标识符授予 IAM 角色。
  • 如需强制执行工作负载身份联合，请在组织上设置 constraints/iam.disableServiceAccountKeyCreation 限制。

Identity Platform

Identity Platform 是面向 Google Cloud 客户的客户身份和访问权限管理 (CIAM) 平台。Identity Platform 通过使用 SDK 和 API 提供多协议支持的身份验证。Identity Platform 支持 MFA、与第三方身份验证服务的集成以及可审核的活动跟踪功能。

适用于 A07：身份验证失败。

不妨参考以下最佳实践：

  • 在整个用户群中启用MFA。 优先考虑可防范钓鱼式攻击的方法，例如 TOTP（身份验证器应用）或 WebAuthn（生物识别和安全密钥）。
  • 使用 beforeCreate 和 beforeSignIn 触发器部署阻塞型 Cloud Run 函数，以便在保存用户或向用户发放令牌之前运行自定义安全代码。通过这种方式，您可以屏蔽临时电子邮件网域、限制 IP 地址或强制执行电子邮件验证。
  • 与 reCAPTCHA Enterprise 集成，以评估登录、注册和重设密码请求是否存在漫游器流量、撞库尝试和自动化滥用行为。
  • 配置密码政策，以强制执行最小字符长度、要求特定的字符复杂性（例如数字和符号），并阻止可预测的序列。
  • 如果使用基于手机的 MFA，请配置短信区域并启用 reCAPTCHA SMS Defense，以将验证消息限制为目标用户所在的国家/地区代码。

Mandiant AI 安全咨询解决方案

Mandiant AI 安全咨询解决方案可在开发生命周期的早期评估您拟议的软件架构、业务流程和云部署。通过将一线威胁情报应用于系统设计，Mandiant 顾问可在编写任何代码之前帮助发现隐藏的逻辑缺陷、缺失的信任边界和架构风险。

适用于 A06：不安全的设计。

不妨参考以下最佳实践：

  • 在开发开始之前聘请 Mandiant 顾问，完成架构研讨会并从一开始就实施安全控制措施。
  • 与威胁建模专家协作，绘制应用的数据流图。确定敏感数据跨越信任边界的位置，以确定必须强制执行严格的身份验证、加密和验证控制措施的位置。
  • 在架构研讨会期间，使用结构化威胁建模框架（例如 STRIDE）。Mandiant 顾问可以根据实际可利用性和业务影响来确定发现的设计缺陷的优先级。
  • 为智能体工作流和 LLM 部署建立安全的 AI 治理基准，明确定义 AI 智能体、MCP 服务器和企业后端数据源之间的信任边界。

Model Armor

Model Armor 旨在过滤 LLM 提示、回答和 MCP 工具调用。Model Armor 会检查生成式 AI 载荷，以帮助检测和阻止提示注入、越狱尝试、恶意网址、恶意内容和敏感数据泄露。

适用于以下情况：

  • A05：注入
  • A10：异常情况处理不当

请查看以下有关 A05：注入的最佳实践：

  • 使用 Apigee 集成或 Agent Gateway 在 API 网关层内联部署 Model Armor 政策，以便在流量到达推理引擎或工具运行时之前，筛查传入的提示和传出的模型回答。
  • 在组织或文件夹级层配置下限设置，以创建强制性的基准安全防护栏，确保各个项目团队无法绕过这些防护栏。
  • 构建自定义的 Model Armor 模板，并针对公共端点上的提示注入和越狱检测调整置信度阈值（例如 LOW_AND_ABOVE 或 MEDIUM_AND_ABOVE）。
  • 在 Model Armor 模板中启用恶意网址检测以及 PDF 和文件扫描，以根据 Google 的威胁情报数据库检查嵌入式网址。在执行之前，舍弃包含恶意软件或钓鱼式攻击向量的提示。
  • 在 Model Armor 模板中启用 Sensitive Data Protection，以检查模型出站流量。配置自动去标识化或遮盖功能，以便在回答离开边界之前，使用占位符替换检测到的敏感数据。

请查看以下有关 A10：异常情况处理不当的最佳实践：

  • 配置应用代码以拦截 MATCH_FOUND 判定并返回通用响应，这样系统就不会默认执行提示或公开原始异常轨迹。
  • 在应用代码中实现故障关闭（故障安全）架构，以便在 Model Armor API 调用遇到网络超时、速率限制或未处理的 HTTP 5xx 错误时拒绝传入的生成式 AI 提示。

组织政策

借助组织政策，您可以对组织的 Google Cloud 资源进行集中式程序化控制。

适用于以下情况：

  • A01：访问权限控制中断
  • A02：安全配置错误
  • A04：加密失败

请查看以下有关 A01：访问权限控制中断的最佳实践：

请查看以下有关 A02：安全错误配置的最佳实践：

请查看以下有关 A04：加密失败的最佳实践：

  • 如需强制使用 CMEK，请在组织或顶级文件夹中应用 constraints/gcp.restrictNonCmekServices，将政策类型设置为 Deny，并列出受支持的 Google Cloud 服务。在强制执行限制之前，请验证每个目标服务的服务代理是否存在，以及是否已在相关密钥环上向其授予 Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) 角色。
  • 强制执行 constraints/gcp.restrictCmekCryptoKeyProjects 以将密钥选择限制为专用 Cloud KMS 项目。

Secret Manager

Secret Manager 可让应用和流水线根据使用 IAM 授予的权限访问指定 Secret 的值。启用后，与 Secret Manager 的交互会创建审核跟踪记录，您可以使用这些记录来帮助满足取证和合规性需求。

适用于以下情况：

  • A04：加密失败
  • A07：身份验证失败

请查看以下有关 A04：加密失败的最佳实践：

请查看以下有关 A07：身份验证失败的最佳实践：

  • 从源代码、.env 文件和容器 build 配置中移除 API 密钥等敏感值，并将凭据存储在 Secret Manager 中。在运行时使用 Google Cloud 客户端库、GKE Secret Store CSI 驱动程序或 Cloud Run Secret 绑定来提取解密后的值。
  • 将 IAM 政策绑定直接应用于特定的个人密令，仅向微服务授予其所需的特定密令的 Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) 角色。
  • 在 Secret Manager 上配置自动轮替时间表。当轮替间隔开始时，Secret Manager 会向指定的 Pub/Sub 主题发布 SECRET_ROTATE 通知。配置 Cloud Run functions 或 Cloud Run 服务，以读取通知、生成新的 Secret 值、将新版本添加到 Secret Manager 并销毁已弃用的版本。
  • 在 Secret Manager 上启用 Cloud Audit Logs，以跟踪 Secret 版本创建、销毁和载荷访问事件。将这些日志路由到 Google SecOps，以便在发生可疑访问事件时发出提醒，例如遭到入侵的服务账号在标准运营时间之外访问 Secret 或尝试读取未经批准的 Secret 资源。

Security Command Center 高级方案

借助 Security Command Center 高级方案，您可以查找并解决 Google Cloud环境和 Web 应用中的安全配置错误和主动运行时威胁，包括识别和身份验证失败问题。Web Security Scanner 服务可以通过扫描来监控应用漏洞，包括 XML 外部实体 (XXE) 漏洞，这些扫描旨在涵盖 OWASP 十大风险控制措施。

适用于以下情况：

  • A02：安全配置错误
  • A05：注入
  • A07：身份验证失败
  • A08：软件或数据完整性失败

请查看以下有关 A02：安全错误配置的最佳实践：

请查看以下有关 A05：注入的最佳实践：

请查看以下有关 A07：身份验证失败的最佳实践：

请查看以下有关 A08：软件和数据完整性失败的最佳实践：

  • 配置 Web Security Scanner 以扫描 Web 端点，查找基于签名的执行 bug，并在应用运行易受攻击的 Apache Struts 版本时生成严重程度为“高”的 STRUTS_INSECURE_DESERIALIZATION 发现结果。
  • 通过升级存在漏洞的框架库版本或部署 Assured OSS 来拉取经过 Google 验证的替代项，从而修复 STRUTS_INSECURE_DESERIALIZATION 发现结果。

敏感数据保护

借助 Sensitive Data Protection，您可以扫描存储在存储分区、数据库、生成式 AI 提示或流式应用载荷中的任何潜在敏感数据，以帮助防止意外泄露信息。如果发现禁止使用的数据，Sensitive Data Protection 可以标记或隐去这些数据。

适用于以下情况：

  • A04：加密失败
  • A09：安全日志记录和提醒失败

请查看以下有关 A04：加密失败的最佳实践：

  • 启用敏感数据发现功能，以持续扫描存储和数据库资产、生成数据分析结果，并报告审核报告的指标。
  • 使用保留格式加密、加密哈希或基于密钥的令牌化来对敏感数据进行去标识化。
  • 部署可重用的集中式管理去标识化模板，以在各个开发团队中强制执行一致的加密遮盖和检查政策。
  • 分析提示载荷，以帮助防止敏感的公司数据或个人身份信息泄露到生成式 AI 训练流水线中。

请查看以下有关 A09：安全日志记录和提醒失败的最佳实践：

  • 配置 Logging 接收器，以将应用日志发送到 Pub/Sub 主题。附加一个使用 Sensitive Data Protection API 的 Cloud Run 订阅者，以扫描日志载荷并对其进行去标识化处理，然后再将清理后的日志写入最终的 Logging 存储桶。
  • 在日志接收器中使用排除过滤器，以仅通过清理流水线路由高风险的非结构化日志（例如原始应用错误、用户注册载荷和交易日志）。

VirusTotal

VirusTotal API 是一个威胁情报和文件扫描平台，用于分析可疑文件、网址、网域和 IP 地址，以检测恶意软件、特洛伊木马和恶意载荷。将 VirusTotal API 集成到文件提取流水线中，可让您在应用系统处理文件之前扫描不受信任的上传内容。

适用于以下情况：

  • A08：软件或数据完整性失败
  • A05：注入

请查看以下有关 A08：软件和数据完整性失败的最佳实践：

  • 部署自定义 YARA-X 签名匹配规则，以扫描传入的文件结构中已知的恶意二进制模式和文本模式，从而检测变异的恶意软件变体。

请查看以下有关 A05：注入的最佳实践：

  • 使用 VirusTotal Private Scanning 模块可单独扫描敏感上传内容，而不会与第三方分享上传的文件。
  • 在提取代码中实现 API 速率限制和异常处理，以捕获 HTTP 429 Too Many Requests 状态代码。

VPC Service Controls

借助 VPC Service Controls，您可以围绕 Google Cloud 资源创建边界，以帮助防范数据渗漏并缓解服务器端请求伪造 (SSRF) 攻击。除非入站和出站规则明确允许，否则 VPC Service Controls 会拒绝跨边界的 API 调用。

适用于以下情况：

  • A01：访问权限控制中断
  • A02：安全配置错误

请查看以下有关 A01：访问权限控制中断的最佳实践：

  • 在服务边界中包含关键服务（例如 Cloud Storage、BigQuery、Spanner 和 Agent Platform），以将 API 访问权限限制为仅限授权的 VPC 网络和可信身份。
  • 在无服务器资源上配置出站边界规则，以阻止因向外部非边界目的地发出出站 API 调用而导致未经授权的数据渗漏。
  • 使用明确的入站和出站规则来限制跨边界和跨组织的 API 访问权限，这些规则指定了获批的项目来源、目标 API 和调用方身份。

请查看以下有关 A02：安全错误配置的最佳实践：

  • 将项目分组到按环境安全层级（例如生产环境边界）整理的专用边界中。使用 VPC 可访问服务来限制可在边界内调用的内部 Google API。
  • 通过 VPC 网络路由来自无服务器工作负载的出站 API 请求。配置 Cloud Run 服务和 Cloud Run functions 以使用直接 VPC 出站流量或无服务器 VPC 访问通道连接器，并将入站流量严格设置为仅限内部。
  • 将 Access Context Manager 访问权限级别绑定到您的边界入站规则，这些规则会评估公司 IP 子网、经过身份验证的身份声明和端点验证设备运行状况信号的组合。
  • 针对紧急突发事件响应，维护预先批准的紧急情况管理流程，并针对任何意外的边界违规事件设置监控提醒。

Wiz 服务

以下部分介绍了与Google Cloud集成的 Wiz 服务的 OWASP Top 10 最佳实践。

Wiz 代码

Wiz Code 将云安全扩展到开发者工作流和 CI/CD 流水线。Wiz Code 可将代码到云的遥测数据相关联，扫描基础设施即代码 (IaC)，分析依赖项 (SCA)，检测暴露的凭据，并执行静态应用安全保障测试 (SAST)。

适用于以下情况：

  • A03：软件供应链故障
  • A05：注入
  • A07：身份验证失败

请查看以下有关 A03：软件供应链故障的最佳实践：

  • 将 Wiz CLI 集成到 CI/CD 流水线中，以阻止合并引入了严重 CVE、暴露的密钥或严重的 IaC 错误配置的拉取请求。
  • 为每个 build 生成并导出 SBOM，以便在 Wiz Cloud 中持续了解供应链情况。
  • 部署 Wiz Code IDE 扩展程序，以提供实时开发者反馈，在代码提交之前捕获易受攻击的软件包、硬编码的 API 密钥和语法错误。
  • 在 CI/CD 流水线中将 Wiz Code 与 CodeMender 集成，以便在检测到存在漏洞的第三方依赖项时生成、测试和提交拉取请求。

请查看以下有关 A05：注入的最佳实践：

  • 如果 SAST 扫描器检测到不受信任的用户输入在未经过适当清理的情况下流入数据库查询或操作系统命令，则阻止合并拉取请求。
  • 将 Wiz Code 插件集成到开发者 IDE 中，以便在开发者输入不安全的串联 SQL 查询或命令执行模式时提供实时提醒。
  • 当 Wiz Code 标记出注入漏洞时，将数据流轨迹路由到 CodeMender 以起草经过验证的补救补丁。

请查看以下有关 A07：身份验证失败的最佳实践：

  • 在开发者 IDE、本地预提交钩子和 CI/CD 流水线中实现自动化密钥扫描，以捕获暴露的凭据。
  • 为防范凭据盗窃，请将静态的长期凭据替换为动态的短期令牌和与身份绑定的访问权限（例如工作负载身份联合或基于 OIDC 的身份验证）。
  • 实施自动化的突发事件响应 playbook，以从代码、环境变量和 build 日志中移除检测到的密钥。

Wiz Cloud

Wiz Cloud 可分析多云环境，以识别安全错误配置、敏感数据暴露和身份风险。借助 Wiz 安全图谱，Wiz Cloud 可关联各个基础设施层中的风险因素，从而突出显示关键攻击路径。

适用于以下情况：

  • A01：访问权限控制中断
  • A02：安全配置错误
  • A04：加密失败
  • A06：不安全的设计

请查看以下有关 A01：访问权限控制中断的最佳实践：

  • 跟踪并标记 IAM 角色和政策中复杂的、多跳的权限升级路径，以确定攻击者可能横向移动或提升权限的位置。
  • 将用户账号、服务账号和 AI 代理对关键数据存储区的有效访问权限进行映射，并撤消过度授予的权限。
  • 将身份授权发现结果与编排平台集成，以使用即时 (JIT) 访问权限替换永久性管理角色绑定。
  • 监控和直观呈现数据移动情况，以便检测生产环境中的个人身份信息何时被复制或同步到不安全的预演或开发环境中。

请查看以下有关 A02：安全错误配置的最佳实践：

  • 使用 Wiz 安全图将配置错误与多种攻击因素相关联，从而评估云配置风险并确定其优先级。
  • 应用内置的合规性框架（例如 OWASP Top 10、CIS 基准和 NIST），根据行业标准衡量云配置。
  • 将 Wiz CLI 扫描器集成到 CI/CD 流水线中，以便在部署之前检查 build 或修正 IaC 错误配置。

请查看以下有关 A04：加密失败的最佳实践：

  • 优先修复包含以下内容的数据库和存储分区：明文凭据、未经过哈希处理的密钥或未经加密就存储的敏感数据。
  • 在 AI 训练目录、向量数据库和 RAG 流水线中运行 Wiz Cloud 数据发现，以验证专有数据和 PII 在 LLM 提取之前是否已隐去。
  • 扫描环境以识别非受管数据资产，并删除冗余数据以最大限度地减少受攻击面。

请查看以下有关 A06：不安全的设计的最佳实践：

  • 指示 Wiz Red Agent 分析逻辑架构接口并模拟攻击路径，以便在部署到生产环境之前发现不安全的设计缺陷。
  • 将经过验证的攻击链上下文从 Wiz Red Agent 传递给 CodeMender，以确定根本原因并生成经过测试的架构拉取请求。

Wiz Defend

Wiz Defend 提供云检测和响应 (CDR)、工作负载运行时保护和 Kubernetes 准入安全。Wiz Defend 会监控控制平面活动、检测运行时异常情况、强制执行容器准入政策，并触发自动隔离。

适用于以下情况：

  • A08：软件或数据完整性失败
  • A09：安全日志记录和提醒失败

请查看以下有关 A08：软件和数据完整性失败的最佳实践：

  • 配置 Wiz Defend 准入规则，以检查并拒绝尝试以 root 权限运行容器、请求主机网络命名空间或启用 privileged: true 的 Kubernetes 部署清单。
  • 在生产环境中，将关键安全准入 webhook 配置为 failurePolicy: Fail（故障关闭），以便在 webhook 无法访问时阻止不受信任的容器。

请查看以下有关 A09：安全日志记录和提醒失败的最佳实践：

  • 使用日志接收器将 Google Cloud 审核日志导出到 Pub/Sub 主题，以便 Wiz Defend 可以注入和分析控制平面活动和工作负载事件。
  • 在 GKE 集群和高价值 Compute Engine 虚拟机上部署 Wiz 运行时传感器，以检测运行时威胁、内存中的漏洞利用和主动入侵。
  • 自动执行遏制 playbook，立即停用遭入侵的 IAM 服务账号或隔离遭入侵的工作负载。
  • 使用 Wiz Blue Agent 调查运行时检测结果，关联实时进程遥测数据和身份上下文，以确定根本原因和受影响的资产。

保持对 OWASP Top 10:2025 的合规性

Wiz 包含 OWASP Top 10 2025 合规性框架，可用于评估和监控您的安全状况。OWASP Top 10 2025 合规性框架会将内置的 Wiz 政策映射到相关的 OWASP 风险类别，并在控制措施不合规时创建发现。您可以跟踪合规性得分随时间变化的趋势。如果需要，您可以自定义 OWASP Top 10 2025 合规性框架，以满足您的业务需求。

后续步骤

如需了解更多最佳实践，请查看安全性最佳实践目录。