Google Cloud Security Command Center Remediation

Google Cloud Security Command Center 安全修复

Overview

概述

A unified remediation skill for Google Cloud Security Command Center findings. It handles both single-domain findings and multi-domain Toxic Combinations.

这是一款用于处理Google Cloud Security Command Center发现问题的统一修复技能。它既支持单领域问题修复，也支持跨领域的Toxic Combinations修复。

1. Safety & Consent Gate

1. 安全与同意关卡

Security Command Center remediations modify infrastructure, access policies, or workload deployments.

Mandatory Consent Gate: NEVER execute mutating
```
gcloud
```
,
```
terraform
```
, or API commands without first presenting a structured remediation plan and the exact command/config diff to the user. STOP after presenting the plan and ALWAYS ask: "Do you approve executing this remediation plan?" before execution. Automatic mutation of security policies or resource configurations can cause unintended outages, lockouts, or compliance violations.
Confirm the Target Project: Before executing, confirm that the active
```
gcloud
```
account and project match the project of the finding's resource. Every mutating command MUST specify the target explicitly, with
```
--project
```
or a full resource path, rather than relying on the default
```
gcloud
```
project.
Verification & Rollback Required: Every proposed remediation plan MUST explicitly include, for each mutating step:
- the mutating remediation command(s),
- the verification check command(s) (
```
gcloud ... describe
```
  or
```
list
```
  ), and
- the rollback command(s) that undo the change, or an explicit statement that the step cannot be undone (for example, service account key deletion).
Use the commands from the loaded playbook where they exist. If the playbook lacks a verification or rollback command for a step, derive the command and label it as not sourced from a playbook.
Dependency & Impact Checks: Every remediation plan MUST state what could break as a result of each change and ask the user to confirm nothing depends on it. For example:
- IAM role changes or revocations: you MUST explicitly advise the user to verify cross-project dependencies and CI/CD pipeline workflows that rely on the existing permissions before revoking a project-level role binding.
- Firewall rule changes: other traffic the same rule allows (such as web traffic on ports 80 or 443).
- External IP removal: inbound access and outbound internet access for the VM.
- Public Access Prevention on a bucket: sites or users that legitimately read it publicly.
CRITICAL WORKFLOW RULE: Do NOT execute any mutating commands in the same turn that you present the remediation plan. You MUST end your turn immediately after asking for approval and wait for the user's next message.
- If there is no interactive user (for example, a scheduled or pipeline run), stop at the plan and never execute.
- If the user approves only part of the plan, or the plan changes after approval, present the updated plan and ask for approval again before executing.
Narrowly Scoped Changes: Always propose the narrowest possible fix that resolves the finding. When more than one fix would work, prefer reversible changes over irreversible ones (for example, disable a key before deleting it), resource-level changes over project, folder, or organization-level changes, and changes that affect only the finding's resource over changes that affect other resources. Do not bundle fixes for unrelated issues noticed along the way; mention them to the user separately.

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

强制同意关卡：在未向用户展示结构化修复计划及确切的命令/配置差异之前，绝对不要执行会产生变更的
```
gcloud
```
、
```
terraform
```
或API命令。展示计划后必须停止操作，且在执行前始终询问：「您是否批准执行此修复计划？」。自动修改安全策略或资源配置可能导致意外的服务中断、账号锁定或合规违规。
确认目标项目：执行前，请确认当前活跃的
```
gcloud
```
账号和项目与问题所属资源的项目一致。所有变更命令必须通过
```
--project
```
参数或完整资源路径明确指定目标，不得依赖默认的
```
gcloud
```
项目。
必须包含验证与回滚步骤：每个拟定的修复计划必须为每个变更步骤明确包含：
- 变更修复命令
- 验证检查命令（
```
gcloud ... describe
```
  或
```
list
```
  ）
- 可撤销变更的回滚命令，或明确说明该步骤无法撤销（例如，服务账号密钥删除）
优先使用已加载的参考操作手册中的命令。如果操作手册中缺少某个步骤的验证或回滚命令，需自行推导命令并标注其并非来自操作手册。
依赖与影响检查：每个修复计划必须说明每项变更可能导致的故障，并要求用户确认没有业务依赖该配置。例如：
- IAM角色变更或撤销：必须明确建议用户在撤销项目级角色绑定前，核实依赖现有权限的跨项目依赖和CI/CD流水线工作流。
- 防火墙规则变更：同一规则允许的其他流量（例如80或443端口的Web流量）。
- 外部IP移除：虚拟机的入站访问和出站互联网访问。
- 存储桶公共访问阻止：合法公开读取该存储桶的站点或用户。
关键工作流规则：绝对不要在展示修复计划的同一轮对话中执行任何变更命令。请求用户批准后必须立即结束本轮回复，等待用户的下一条消息。
- 如果没有交互式用户（例如，定时任务或流水线运行），停留在计划阶段，绝对不要执行。
- 如果用户仅批准部分计划，或计划在批准后发生变更，需展示更新后的计划并再次请求批准，然后才能执行。
最小范围变更：始终提议能够解决问题的最小范围修复方案。当有多种修复方案可行时，优先选择可回滚变更而非不可回滚变更（例如，先禁用密钥再删除），优先选择资源级变更而非项目、文件夹或组织级变更，优先选择仅影响问题所属资源的变更而非影响其他资源的变更。不要将过程中发现的不相关问题的修复打包在一起；需单独向用户说明这些问题。

2. Intent Router & Progressive Disclosure

2. 意图路由与渐进式加载

Do not load all reference playbooks into memory at once. Analyze the Security Command Center finding's

category

,

findingClass

, or attack path, then read ONLY the relevant reference document(s).

Match on the finding's

category

first, and fall back to

findingClass

only when no category matches. Routing on

findingClass

alone misroutes IAM findings: Security Health Analytics IAM findings are

MISCONFIGURATION

class, and IAM recommender findings are

Vulnerability

class, so neither would ever reach the IAM playbook.

Match On	Values	Target Reference Playbook
`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 recommender) : `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` (CVEs, OS : :
: : patch, container base image upgrade, : :
: : vulnerable package, GKE node pool upgrade). : :
: : Note: Web Security Scanner (WSS) findings : :
: : fall through to no match below. : :
`findingClass`	`TOXIC_COMBINATION` — attack path	Sequential Load: Identify each exposed facet in the attack path and load
: : exposure, multi-domain attack vector : the matching reference playbooks sequentially. :
no match	Any other category or finding class	See Findings Without Dedicated Playbooks below. Do not force a finding
: : : into a playbook that does not cover it. :

不要一次性将所有参考操作手册加载到内存中。先分析Security Command Center问题的

category

、

findingClass

或攻击路径，然后仅读取相关的参考文档。

优先匹配问题的

category

，仅当没有匹配的category时才回退到

findingClass

。仅通过

findingClass

路由会导致IAM问题被错配：Security Health Analytics的IAM问题属于

MISCONFIGURATION

类，而IAM推荐器的问题属于

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 recommender) : `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` (CVEs, OS : :
: : patch, container base image upgrade, : :
: : vulnerable package, GKE node pool upgrade). : :
: : 注意：Web Security Scanner（WSS）的问题会落入下方的无匹配分类。 : :
`findingClass`	`TOXIC_COMBINATION` —— 攻击路径暴露、跨领域攻击向量	顺序加载：识别攻击路径中的每个暴露面，依次加载匹配的参考操作手册。
: : : :
无匹配	任何其他类别或问题分类	参见下文无专用操作手册的问题。不要强行将问题归入不覆盖它的操作手册。
: : : :

Findings Without Dedicated Playbooks & Runtime Threat Detections

无专用操作手册的问题与运行时威胁检测

When presented with Security Command Center findings that do not have automated configuration remediation playbooks—such as runtime threat detections (e.g., Cloud Run Threat Detection, Agent Platform Threat Detection, Event Threat Detection, Container Threat Detection):

Do NOT execute automated mutation commands: Runtime threat detections represent active alerts or behavioral anomalies rather than static resource misconfigurations.
Provide Documentation & Containment Guidance:
- Refer the user to the relevant Security Command Center documentation (e.g., Cloud Run Threat Detection, Agent Platform Threat Detection).
- Recommend manual investigation steps: analyzing audit logs in Cloud Logging, identifying compromised service accounts or API keys, and isolating affected workloads.
- Advise the user on containment options (e.g., revoking active credentials, blocking malicious IPs at Cloud Armor/firewall).

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

不要执行自动化变更命令：运行时威胁检测属于活跃告警或行为异常，而非静态资源配置错误。
提供文档与遏制指导：
- 引导用户查阅相关的Security Command Center文档（例如： Cloud Run Threat Detection、 Agent Platform Threat Detection）。
- 推荐手动调查步骤：分析Cloud Logging中的审计日志，识别被入侵的服务账号或API密钥，隔离受影响的工作负载。
- 为用户提供遏制方案建议（例如：撤销活跃凭证、在Cloud Armor/防火墙中封禁恶意IP）。

3. Standard Remediation Workflow

3. 标准修复工作流

Inspect Finding Details & Intentionality:
- If the finding's details are not already in the conversation, retrieve them using the
```
google-cloud-scc-query
```
  skill. Verify the finding name, affected resource (
```
resourceName
```
  ), category, and attack exposure score.
- Before planning a fix, ask the user whether the flagged configuration is intentional (for example, a bucket serving a public website, or a VM that must accept public traffic). If it is, do not propose a remediation. Suggest muting the finding with a documented justification instead; muting changes the finding's state, so it also requires the user's approval.
Route & Load Reference: Read the matching reference playbook(s) from the routing table above.
Formulate Least-Privilege Remediation: Before drafting, check whether the resource is managed by infrastructure as code (ask the user, and check for signals such as the
```
goog-terraform-provisioned
```
label). If it is, draft the change to the Terraform configuration rather than a
```
gcloud
```
command. Otherwise, draft the exact CLI (
```
gcloud
```
) or IAM binding change needed to close the exposure without disrupting business workloads.
Present Plan & Seek Consent: Show the user the plan required by the Safety & Consent Gate: for each step, the remediation command, the verification command, the rollback command, and what could break. STOP execution here and ALWAYS ask the explicit question: "Do you approve executing this remediation plan?"
Execute on Approval: ONLY after receiving explicit user confirmation, execute the remediation commands and run the verification commands to confirm the resource is fixed. If a command fails, stop and report the error; do not try a different command without presenting it and getting approval again. Tell the user that the finding's state in Security Command Center updates on the detector's next scan, which may take some time, and do not manually mark the finding as resolved.

检查问题详情与配置意图：
- 如果对话中尚未包含问题详情，使用
```
google-cloud-scc-query
```
  技能获取。核实问题名称、受影响资源（
```
resourceName
```
  ）、类别以及攻击暴露评分。
- 在制定修复计划前，询问用户被标记的配置是否为有意设置（例如，用于托管公共网站的存储桶，或必须接受公共流量的虚拟机）。如果是有意设置，则不要提议修复。建议用户通过书面说明将问题静音；静音操作会更改问题状态，因此也需要获得用户批准。
路由并加载参考资料：从上方的路由表中读取匹配的参考操作手册。
制定最小权限修复方案：在起草方案前，检查资源是否由基础设施即代码（Infrastructure as Code）管理（可询问用户，或检查
```
goog-terraform-provisioned
```
标签等标识）。如果是，则起草Terraform配置变更，而非
```
gcloud
```
命令。否则，起草确切的CLI（
```
gcloud
```
）或IAM绑定变更，在不中断业务工作负载的前提下消除暴露风险。
展示计划并请求同意：向用户展示「安全与同意关卡」要求的计划：每个步骤的修复命令、验证命令、回滚命令以及可能的故障影响。在此处停止执行，始终明确询问用户：「您是否批准执行此修复计划？」
获批后执行：仅在收到用户明确确认后，执行修复命令并运行验证命令，确认资源已修复。如果命令执行失败，立即停止并上报错误；在未展示新命令并再次获得批准前，不要尝试其他命令。告知用户Security Command Center中的问题状态会在检测器下次扫描时更新，可能需要一定时间，不要手动将问题标记为已解决。

google-cloud-scc-remediation

Original

Translation