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 アカウントとプロジェクトが、 検出結果のリソースが属するプロジェクトと一致していることを確認してください。 変更を伴うすべてのコマンドでは、デフォルトの gcloud プロジェクトに依存せず、 --project または完全なリソースパスを指定して対象を明示する必要があります。

• 検証とロールバックの必須化：提示するすべての修復計画には、変更を伴う各ステップについて、 次の内容を明示的に含める必要があります。

  • 変更を伴う修復コマンド
  • 検証用の確認コマンド（gcloud ... describe または list）
  • 変更を元に戻すロールバックコマンド、またはそのステップを元に戻せないことの明示 （サービス アカウント キーの削除など）

  該当するコマンドが読み込まれたプレイブックにある場合は、それを使用してください。 あるステップの検証コマンドまたはロールバックコマンドがプレイブックにない場合は、コマンドを作成し、 プレイブック由来ではないことを明記してください。

• 依存関係と影響の確認：すべての修復計画で、各変更によって何が影響を受ける可能性があるかを明示し、 それに依存するものがないことをユーザーに確認してください。たとえば、次のような点があります。

  • IAM ロールの変更または取り消し：プロジェクトレベルのロール バインディングを取り消す前に、 既存の権限に依存するプロジェクト間の依存関係や CI/CD パイプラインのワークフローを 必ず確認するよう、ユーザーに明示的に伝えてください。
  • ファイアウォール ルールの変更：同じルールで許可される他のトラフィック（ポート 80 や 443 のウェブ トラフィックなど）。
  • 外部 IP の削除：VM へのインバウンド アクセスと、VM からのアウトバウンド インターネット アクセス。
  • バケットでのパブリック アクセス防止：正当にパブリック読み取りを行うサイトやユーザー。

• 重要なワークフロー規則：修復計画を提示するのと同じターン内で、変更を伴うコマンドを実行してはなりません。 承認を求めた直後にターンを終了し、ユーザーの次のメッセージを待つ必要があります。

  • 対話可能なユーザーがいない場合（スケジュール実行やパイプライン実行など）は、計画の提示で停止し、 実行してはなりません。
  • ユーザーが計画の一部のみを承認した場合、または承認後に計画が変更された場合は、更新した計画を提示し、 実行前に再度承認を求めてください。

• 変更範囲の最小化：検出結果を解決するために可能な限り範囲の狭い修正を常に提案してください。 複数の修正方法がある場合は、元に戻せない変更より元に戻せる変更を優先し（たとえば、キーを削除する前に無効化する）、 プロジェクト、フォルダ、組織レベルの変更よりリソースレベルの変更を優先し、 他のリソースに影響する変更より検出結果のリソースだけに影響する変更を優先してください。 途中で気付いた無関係な問題への修正をまとめて行わず、別途ユーザーに伝えてください。

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. 最小権限の修復を策定する：草案を作成する前に、リソースが Infrastructure as Code によって管理されているか確認します（ユーザーに尋ね、goog-terraform-provisioned ラベルなどの兆候を確認します）。該当する場合は、gcloud コマンドではなく Terraform 構成への変更案を作成します。該当しない場合は、業務ワークロードを中断せずに露出を解消するために必要な、正確な CLI（gcloud）コマンドまたは IAM バインディングの変更案を作成します。
4. 計画を提示して同意を求める：Safety & Consent Gate で求められる計画をユーザーに提示します。各手順について、修復コマンド、検証コマンド、ロールバックコマンド、および発生しうる問題を示します。ここで実行を停止し、必ず明示的に次の質問をします：「この修復計画の実行を承認しますか？」
5. 承認後に実行する：ユーザーから明示的な確認を得た後に限り、修復コマンドを実行し、検証コマンドを実行してリソースが修正されたことを確認します。コマンドが失敗した場合は停止してエラーを報告し、別のコマンドを提示して再度承認を得ることなく試してはいけません。Security Command Center の検出結果の状態は、検出機能の次回スキャン時に更新されるため、時間がかかる場合があることをユーザーに伝えます。また、検出結果を手動で解決済みにしてはいけません。