【Google Cloud】 Security Command Center で原因を解消したのに検出結果が「 INACTIVE 」にならない事象を確認してみた

【Google Cloud】 Security Command Center で原因を解消したのに検出結果が「 INACTIVE 」にならない事象を確認してみた

Google Cloud の Security Command Center で、検出結果を解消しても状態が変わらないと感じたことはありませんか?今回はEvent Threat Detection と Security Health Analytics では検出結果の自動更新の仕様を実際に検証してみました。
2026.10.23

皆さまこんにちは、こんばんは

コンサルティング部のみゃんです。

普段 Google Cloud の 「 Security Command Center 」を運用していると、「脅威が検知されたから原因となる事象について対処したけど、検出結果が変わらない。本当に解消したか判断できなくて困る!」ってなることはありませんか?

一方で、CIS ベンチマークのチェックのような「 Security Health Analytics 」の検出結果は、設定を直すといつの間にか一覧から消えています。
同じ 「 Security Command Center 」 の検出結果なのに、片方は残り続けて、片方は消える。
これでは、原因を解消したのかどうかを検出結果から判断できないですよね。

公式ドキュメントには、問題の修正が検出された後、自動で検出結果のステータスがActiveからInactiveに変わるのは、「 Security Health Analytics 」とVMマネージャのみと書かれています。

https://docs.cloud.google.com/security-command-center/docs/finding-states

ドキュメントに書いてあっても、自分の目で見るまでは信用できません。
というわけで今回は、同じ操作で「 Event Threat Detection 」の検出結果と「 Security Health Analytics 」の検出結果を同時に出して、原因を解消したあとの状態の違いを実際に確かめてみることにしました。

まずは結論から

忙しい人のために、まずは結論をまとめます。
詳細は、後述の「やってみた」章をご覧ください!

今回主に試したのは以下の3点です。
①組織外のアカウントをオーナーに招待して、「 Event Threat Detection 」 と 「 Security Health Analytics 」 の検出結果を出す
②権限を外して、2つの検出結果の状態を比べる
③「 Event Threat Detection 」 の検出結果を手動で無効にする

①組織外のアカウントをオーナーへの招待と承認、追加でストレージ管理者の権限を付与して、「 Event Threat Detection 」 の Persistence: IAM Anomalous Grant と、「 Security Health Analytics 」 の NON_ORG_IAM_MEMBER の検出結果が出ました。

②権限を外すと、「 Security Health Analytics 」 の検出結果は自動で INACTIVE(無効)になり、コンソールの既定の一覧から消えました。
「 Event Threat Detection 」 の検出結果は ACTIVE(有効)のまま残りました。
「 Event Threat Detection 」の検出結果は、原因を解消しても自動では無効になりません。

③「 Event Threat Detection 」 の検出結果は、手動で INACTIVE にすると既定の一覧から消えました。
state="INACTIVE" で絞り込むと、無効にした過去の検出結果も確認できます。

やってみた

前提

  • 社内の検証用組織に、新しく作ったまっさらなプロジェクトで検証
  • 「 Security Command Center 」 はプロジェクト単位で Premium ティアを有効化(無料トライアル)
  • gcloud は Cloud Shell から実行
  • テスト用アカウント : 個人の @gmail.com アカウント(検証用プロジェクトに権限を持っていない状態)

※プロジェクト ID・メールアドレスは、記事内では変数またはマスクで表記しています。

「 Security Command Center 」 の検出結果には ACTIVE(有効)と INACTIVE(無効)の2つの状態があります。

https://docs.cloud.google.com/security-command-center/docs/finding-states

今回の検証では、以下の変数を使います。

PROJECT_ID=<検証用プロジェクトID>
TEST_USER=<テスト用の@gmail.comアドレス>

検証1: 組織外のアカウントをオーナーに招待して、「 Event Threat Detection 」と 「 Security Health Analytics 」 の検出結果を出す

「 Event Threat Detection 」の Persistence: IAM Anomalous Grant は、組織外のアカウントに強いロールが付与されたことを、IAM の管理アクティビティ監査ログから検出します。

https://docs.cloud.google.com/security-command-center/docs/findings/threats/iam-anomalous-grant

付与する前に、同じカテゴリの検出結果が出ていないことを確認しておきます。

gcloud scc findings list projects/${PROJECT_ID} --location=global \
  --filter="category=\"Persistence: IAM Anomalous Grant\" OR category=\"NON_ORG_IAM_MEMBER\"" \
  --format="table(finding.category,finding.state,finding.eventTime,finding.createTime)"

招待前に対象カテゴリの検出結果が無いことを確認した実行結果

組織外のユーザーにプロジェクトのオーナーを付与するときは、gcloud ではなくコンソールから招待する必要があります。
招待された側が招待メールを承認して、はじめてオーナーになります。

https://docs.cloud.google.com/resource-manager/reference/rest/v1/projects/setIamPolicy

コンソールの IAM ページで「アクセスを許可」を押し、新しいプリンシパルにテスト用アカウント、ロールに「オーナー」を指定して保存します。
アクセス許可を押下
オーナーロールを追加して、プリンシパルを追加

テスト用アカウントに届いた招待メールを開いて、承認します。

承認したら、数分おきに先ほどの gcloud scc findings list を実行してみます。
オーナー権限で招待すると、「 Security Health Analytics 」は検知されましたが、ETDのPersistence: IAM anomalous grantは検知されなかったので、追加でroles/storage.adminを付与したところ無事検知されました。

「 Event Threat Detection 」と 「 Security Health Analytics 」 の検出結果が ACTIVE で出ている実行結果

「 Event Threat Detection 」の Persistence: IAM Anomalous Grant と、「 Security Health Analytics 」 の NON_ORG_IAM_MEMBER が ACTIVE で出ました。

コンソールの検出結果ページでも見てみましょう。
「 Security Health Analytics 」コンソール画面

ETDコンソール画面

「 Event Threat Detection 」の検出結果の詳細も開いてみます。
付与したロールとメンバーが記録されていますね。

検証2: 権限を外して、「 Event Threat Detection 」と 「 Security Health Analytics 」 の検出結果の状態を比べる

次に、付与した権限を外します。

gcloud projects remove-iam-policy-binding ${PROJECT_ID} \
  --member="user:${TEST_USER}" \
  --role="roles/owner"
gcloud projects remove-iam-policy-binding ${PROJECT_ID} \
  --member="user:${TEST_USER}" \
  --role="roles/storage.admin"

招待したテスト用アカウントが消えました。
消えたアカウント

「 Security Health Analytics 」 の NON_ORG_IAM_MEMBER はリアルタイムスキャンに対応している検出器なので、設定の変更を検知すると検出結果が更新されます。

https://docs.cloud.google.com/security-command-center/docs/concepts-vulnerabilities-findings

少し時間をおいて、もう一度 gcloud scc findings list を実行してみます。

権限を外したあと、「 Security Health Analytics 」 の検出結果が INACTIVE、「 Event Threat Detection 」の検出結果が ACTIVE になっている実行結果

「 Security Health Analytics 」 の検出結果は INACTIVE に変わりました。
「 Event Threat Detection 」の検出結果は ACTIVE のままです。

コンソールの検出結果ではどう見えるでしょうか。
ACTIVE でフィルターをかけた状態で見てみます。

コンソール画面

「 Security Health Analytics 」 の検出結果は消えて、「 Event Threat Detection 」の検出結果だけが残っています。
設定を直したら一覧から消えたように見えるのは、「 Security Health Analytics 」 が自動で INACTIVE にして、既定のクエリの対象から外れたためですね。

INACTIVE でフィルターをかけて、検出結果を表示すると、「 Security Health Analytics 」 の検出結果が出てきます。

「 Security Health Analytics 」が出てきた

消えたのではなく、INACTIVE として残っていることが分かります。

検証3: 「 Event Threat Detection 」の検出結果を手動で無効にする

「 Event Threat Detection 」の検出結果は自動では無効にならないので、自分で状態を変えます。
公式ドキュメントでも、「 Event Threat Detection 」の検出結果は調査と対処が終わってから手動で INACTIVE にする流れになっています。

https://docs.cloud.google.com/security-command-center/docs/how-to-investigate-threats

事前準備で付与したセキュリティ センター管理者のアカウントで実行します。
gcloud では、検出結果の名前を指定して --state=INACTIVE を付けます。

「 Event Threat Detection 」の検出結果の名前は、コンソールの検出結果を押下した、以下の画面の箇所で確認できます。
検出結果の名前の確認箇所

ETD_FINDING=<ETDの検出結果の名前(projects/〜/sources/〜/findings/〜)>

gcloud scc findings update ${ETD_FINDING} --state=INACTIVE

INACTIVEになった

※コンソールで行う場合は、検出結果を選んで「アクティブ状態を変更」から無効を選びます。
コンソールからの無効化

https://docs.cloud.google.com/sdk/gcloud/reference/scc/findings/update

最後に、state="INACTIVE" で絞り込んでみます。

gcloud scc findings list projects/${PROJECT_ID} --location=global \
  --filter="state=\"INACTIVE\" AND (category=\"Persistence: IAM Anomalous Grant\" OR category=\"NON_ORG_IAM_MEMBER\")" \
  --format="table(finding.category,finding.state,finding.eventTime,finding.createTime)"

state="INACTIVE" で絞り込み、「 Event Threat Detection 」と 「 Security Health Analytics 」 の検出結果が表示されている実行結果

「 Event Threat Detection 」と 「 Security Health Analytics 」 の検出結果が INACTIVE で表示されました。
無効にした検出結果も、状態で絞り込めば過去の分を確認できますね。

まとめ

今回は、「 Security Command Center 」 で原因を解消したあとに、検出結果の状態がどう変わるのかを 「 Event Threat Detection 」と 「 Security Health Analytics 」 で比べてみました。

「 Security Health Analytics 」 の検出結果は、設定を直すと自動で INACTIVE になります。
「 Event Threat Detection 」の検出結果は、原因を解消しても ACTIVE のまま残るので、調査と対処が終わったら自分で INACTIVE にする必要があります。
どちらも、一覧から消えたあとも INACTIVE として残っているので、状態で絞り込めば追跡できます。

「検出結果がいつまでも消えない」と感じたら、まずはその検出結果がどの検出サービスから出ているかを確認するのが良さそうです。
脅威の検出結果を無効にする作業を運用手順に入れておかないと、有効な検出結果が増え続けて、未対応のものを見分けにくくなります。

「 Security Command Center 」 の運用の参考になれば幸いです!

最後まで読んでいただきありがとうございました!
以上、コンサルティング部のみゃんでした!

参考リンク

https://docs.cloud.google.com/security-command-center/docs/finding-states

https://docs.cloud.google.com/security-command-center/docs/finding-lifecycle-overview

https://docs.cloud.google.com/security-command-center/docs/how-to-investigate-threats

https://docs.cloud.google.com/security-command-center/docs/how-to-remediate-security-health-analytics-findings

https://docs.cloud.google.com/security-command-center/docs/activate-scc-for-a-project

https://docs.cloud.google.com/security-command-center/docs/activate-scc-project-level-limitations

https://docs.cloud.google.com/security-command-center/docs/activate-premium-tier

https://docs.cloud.google.com/security-command-center/docs/how-to-test-event-threat-detection

https://docs.cloud.google.com/security-command-center/docs/findings/threats/iam-anomalous-grant

https://docs.cloud.google.com/security-command-center/docs/concepts-vulnerabilities-findings

https://docs.cloud.google.com/security-command-center/docs/review-manage-findings

https://docs.cloud.google.com/resource-manager/reference/rest/v1/projects/setIamPolicy

https://docs.cloud.google.com/iam/docs/roles-permissions/securitycenter

https://docs.cloud.google.com/sdk/gcloud/reference/scc/findings/update

この記事をシェアする

関連記事