google-cloud-scc-remediation

Google Cloud Security Command Center 修复

使用归因

必须阅读：执行任何 gcloud、REST API 或 MCP 命令前，必须阅读并遵循 使用归因中的说明。

概述

用于修复 Google Cloud Security Command Center 发现项的统一技能。 可处理单一领域的发现项和跨多个领域的 Toxic Combinations。

1. 安全与同意关卡

Security Command Center 修复会修改基础设施、访问策略或工作负载部署。

• 强制同意关卡：未经事先向用户展示结构化修复计划以及准确的命令／配置差异，绝不执行会修改状态的 gcloud、terraform 或 API 命令。展示计划后立即停止，并始终询问：“您是否批准执行此修复计划？”然后才能执行。自动修改安全策略或资源 配置可能会导致意外停机、访问锁定或违反合规要求。

• 确认目标项目：执行前，确认当前的 gcloud 账号和项目与发现项资源所属项目一致。 每条会修改状态的命令都必须明确指定目标，使用 --project 或完整资源路径，而不能依赖默认的 gcloud 项目。

• 必须提供验证与回滚：每份拟议的修复计划都必须明确列出每个会修改状态的步骤所需的：

  • 修复命令；
  • 验证检查命令（gcloud ... describe 或 list）；以及
  • 用于撤销更改的回滚命令，或明确说明该步骤无法撤销（例如，删除服务账号密钥）。

  如果已加载的操作手册中提供了相应命令，请使用这些命令。如果操作手册缺少某一步骤的验证或回滚命令，请推导出相应命令，并标注其并非来自操作手册。

• 依赖项与影响检查：每份修复计划都必须说明每项更改可能导致哪些功能失效，并询问用户确认没有任何内容依赖这些功能。例如：

  • IAM 角色更改或撤销：撤销项目级角色绑定前，必须明确建议用户核实跨项目依赖，以及依赖现有权限的 CI/CD 工作流。
  • 防火墙规则更改：同一规则允许的其他流量，例如 80 或 443 端口上的 Web 流量。
  • 移除外部 IP：VM 的入站访问和出站互联网访问。
  • 对存储桶启用 Public Access Prevention：合法公开读取该存储桶的网站或用户。

• 关键工作流规则：不得在展示修复计划的同一轮中执行任何会修改状态的命令。询问用户是否批准后，必须立即结束本轮，并等待用户的下一条消息。

  • 如果没有可交互的用户（例如，定时或流水线运行），则停留在计划阶段，绝不执行。
  • 如果用户只批准了计划的一部分，或计划在批准后发生变化，则必须再次展示更新后的计划并请求批准，然后才能执行。

• 严格限定变更范围：始终提出能够解决发现项的最小范围修复。如果有多种可行修复方案，应优先选择可逆而非不可逆的更改（例如，先停用密钥而不是删除密钥）、资源级而非项目、文件夹或组织级更改，以及仅影响发现项资源而非其他资源的更改。不要顺带处理无关问题；应另行告知用户。

2. 意图路由器与渐进式披露

不要一次性将所有参考手册加载到内存中。分析 Security Command Center 发现项的 category、findingClass 或攻击路径，然后仅阅读相关参考文档。

首先按发现项的 category 匹配，仅在没有匹配的类别时才回退到 findingClass。仅按 findingClass 路由会导致 IAM 发现项路由错误：Security Health Analytics 的 IAM 发现项属于 MISCONFIGURATION 类别，IAM recommender 发现项属于 Vulnerability 类别，因此都无法进入 IAM 手册。

匹配字段	值	目标参考手册
category	PRIMITIVE_ROLES_USED，	references/remediation_iam.md
: （Security Health : OVER_PRIVILEGED_SERVICE_ACCOUNT_USER， : :
: Analytics） : ADMIN_SERVICE_ACCOUNT， : :
: : SERVICE_ACCOUNT_ROLE_SEPARATION， : :
: : KMS_ROLE_SEPARATION， : :
: : USER_MANAGED_SERVICE_ACCOUNT_KEY， : :
: : SERVICE_ACCOUNT_KEY_NOT_ROTATED : :
category	IAM_ROLE_HAS_EXCESSIVE_PERMISSIONS，	references/remediation_iam.md
: （IAM 推荐工具） : UNUSED_IAM_ROLE， : :
: : SERVICE_AGENT_GRANTED_BASIC_ROLE， : :
: : SERVICE_AGENT_ROLE_REPLACED_WITH_BASIC_ROLE : :
category	PUBLIC_BUCKET_ACL，PUBLIC_IP_ADDRESS，	references/remediation_misconfig.md
: （Security Health : OPEN_FIREWALL，OPEN_SSH_PORT， : :
: Analytics） : OPEN_RDP_PORT，KMS_KEY_NOT_ROTATED : :
category	OS_VULNERABILITY，SOFTWARE_VULNERABILITY，	references/remediation_vuln.md
: : GKE_RUNTIME_OS_VULNERABILITY（CVE、OS : :
: : 补丁、容器基础映像升级、易受攻击的软件包、 : :
: : GKE 节点池升级）。 : :
: : 注意：Web Security Scanner（WSS）的发现项 : :
: : 将归入下方的不匹配项。 : :
findingClass	TOXIC_COMBINATION — 攻击路径	顺序加载：识别攻击路径中每个暴露面，并依次加载
: : 暴露、多域攻击向量 : 匹配的参考手册。 :
不匹配	任何其他类别或发现类别	请参阅下文的没有专用手册的发现项。不要将发现项强行归入
: : : 未涵盖该问题的手册。 :

没有专用操作手册的发现项与运行时威胁检测

当遇到没有自动化配置修复操作手册的 Security Command Center 发现项时，例如运行时威胁检测（如 Cloud Run Threat Detection、Agent Platform Threat Detection、Event Threat Detection、Container Threat Detection）：

1. 不要执行自动化变更命令：运行时威胁检测代表的是正在发生的警报或行为异常，而不是静态资源配置错误。
2. 提供文档与遏制指导：
   • 引导用户查阅相关的 Security Command Center 文档（例如， Cloud Run Threat Detection、 Agent Platform Threat Detection）。
   • 建议手动调查步骤：分析 Cloud Logging 中的审计日志，识别已遭入侵的服务账号或 API 密钥，并隔离受影响的工作负载。
   • 向用户说明遏制选项（例如，撤销有效凭据，或在 Cloud Armor／防火墙中屏蔽恶意 IP）。

3. 标准修复工作流

1. 检查发现项详情与配置意图：
   • 如果对话中尚未包含发现项详情，请使用 google-cloud-scc-query 技能获取。核实发现项名称、受影响资源（resourceName）、类别和攻击暴露评分。
   • 在规划修复之前，询问用户被标记的配置是否为有意设置（例如，用于提供公共网站的存储桶，或必须接受公共流量的 VM）。如果是，则不要提出修复方案。建议改为添加有文档记录的说明并将该发现项静音；静音会更改发现项的状态，因此也需要用户批准。
2. 确定处理路径并加载参考资料：从上方的路由表中读取匹配的参考操作手册。
3. 制定最小权限修复方案：起草方案前，检查资源是否由基础设施即代码管理（询问用户，并检查 goog-terraform-provisioned 标签等迹象）。如果是，应修改 Terraform 配置，而不是使用 gcloud 命令。否则，起草所需的确切 CLI（gcloud）或 IAM 绑定变更，在不影响业务工作负载的前提下消除暴露风险。
4. 提交计划并征求同意：向用户展示 Safety & Consent Gate 要求的计划：每个步骤都要列出修复命令、验证命令、回滚命令以及可能造成的影响。此处停止执行，并务必明确询问：“您是否批准执行此修复计划？”
5. 获批后执行：只有在收到用户的明确确认后，才能执行修复命令并运行验证命令，以确认资源已修复。如果命令失败，请停止并报告错误；未经再次说明并获得批准，不要尝试其他命令。告知用户，Security Command Center 中的发现项状态会在检测器下次扫描时更新，这可能需要一些时间；不要手动将发现项标记为已解决。