セキュリティ管理と構成を検証する

注: この機能には、Google Security Operations サービス固有の規約の pre-GA サービス規約が適用されます。pre-GA の機能についてはサポートが制限されます。また、pre-GA の機能の変更は pre-GA の他のバージョンと互換性がない可能性があります。 詳細については、Google SecOps 技術サポート サービス ガイドラインと Google SecOps サービス固有の規約をご覧ください。

注: この機能は、地域によってはすべてのお客様がご利用いただけない場合があります。

このガイドは、 Google Cloud 環境で攻撃をシミュレートしてセキュリティを事前にテストしたいセキュリティ エンジニアを対象としています。継続的なセキュリティ検証の取り組みを実装する方法について説明します。

セキュリティ検証では、攻撃者の手法を模倣したアクションとスクリプトを使用して、 Google Cloud プロジェクトで検出アラートをトリガーします。継続的な運用により脆弱性が特定され、構成と制御が最新の脅威に想定どおりに対応することで、セキュリティ チームはリスクを軽減できます。

このジャーニーを完了すると、セキュリティ ポスチャーの改善を測定可能な形で証明でき、新たに実装された検出ルールやインテグレーションが手動操作なしで正しく動作することが保証されます。

一般的なユースケース

このセクションでは、Security Validation の一般的なユースケースについて説明します。

セキュリティ ポスチャーの回帰を検出する

目的: 以前にブロックされた攻撃者の動作が環境内で正常に実行された日時を特定します。

価値: セキュリティ チームと運用チームに意図しない構成のドリフトを警告し、脆弱性が悪用される前に修復できるようにします。

セキュリティ管理のチューニングを検証する

目的: 新しく実装された検出ルールまたはプロダクト統合が想定どおりに動作することを確認します。

価値: ルールの更新や環境の変更によってセキュリティ体制が改善されたことを測定可能な形で証明し、チームが自信を持って新しいベースラインを確立できるようにします。

主な用語

• セキュリティ検証コンテキスト: セキュリティ検証コンテキストは、セキュリティ テストの環境を設定します。使用するプロジェクト、テストを実行するアカウント、アクションに必要なその他の詳細を指定します。

• セキュリティ検証アクション: 実際の攻撃者の手法を模倣するように設計されたスクリプト。検出ルールをトリガーしてセキュリティ ポスチャーを検証するために使用されます。

• ベースライン実行: 今後の実行を比較するための標準的な参照として使用される、完了した特定のセキュリティ検証実行。

• モニタリング: Security Validation アクションを実行し、定義されたベースラインに対して結果を評価するスケジュール設定されたジョブ（API では SecurityValidationJob）。

• ドリフト ステータス: 最近の実行がベースラインと一致するか（正常）、逸脱を示すか（ドリフトが検出されたか）に基づいて、モニターの健全性インジケーターが表示されます。

• 関連付けウィンドウ: 実行後 12 時間の期間。この期間中、システムは実行されたアクションのメタデータにあるイベント フィルタ テンプレートに基づいて、関連するイベントと検出を検索して関連付けます。

• モニターのタイムアウト: 実行後にイベントと検出が関連付けられ、最終的なドリフト ステータスが評価されるまでシステムが待機する最大時間。このタイムアウトは、12 時間の相関ウィンドウ内で動作します。モニターが成功と見なされるには、このモニターのタイムアウトに達する前に、期待される結果が確認されている必要があります。このタイムアウト前にチェックに合格しない場合、システムはモニターを failed としてマークします。この期間のデフォルトは 8 時間ですが、15 分～ 10 時間の範囲で構成できます。

始める前に

次の設定と権限が設定されていることを確認します。

必要な設定

次の設定になっていることを確認してください。

• テナントでセキュリティ検証が有効になっている必要があります。

• セキュリティ検証は、セルフマネージド プロジェクトでのみ機能します。

• 1 つまたは 2 つの Google Cloud プロジェクトが必要です。実行とターゲット設定に同じプロジェクトを使用することもできますが、セキュリティを強化し、テストをクリーンに保ち、設定の管理を容易にするために、別々のプロジェクトを使用することをおすすめします。

  • 実行プロジェクト: Security Validation は、実行プロジェクトでセキュリティ テストを実行します。これには Cloud Run と Cloud Storage を使用します。これらのジョブとバケットは、検証サービスでのみ使用されることを想定しています。他のユーザーにはアクセス権を付与しないでください。

    このプロジェクトで Cloud Run API、Resource Manager API、IAM API が有効になっている必要があります。また、このプロジェクトのセキュリティ検証コンテキストを作成するには、resourcemanager.projects.SetIamPolicy、storage.buckets.SetIamPolicy、storage.buckets.create、storage.buckets.delete の権限が必要です。この権限を提供するロールの一覧については、IAM 権限のリファレンスをご覧ください。

  • ターゲット プロジェクト: セキュリティ検証アクション スクリプトによって行われた API 呼び出しが動作する場所。アクションの成功は、アクションで使用される必要な API がこのプロジェクトで有効になっているかどうか、およびセキュリティ検証コンテキストのサービス アカウントに必要な権限が付与されているかどうかによって異なります。

• サービス アカウント: 実行プロジェクトに 1 つ以上のサービス アカウントが必要です。これらのアカウントはアクション スクリプトを実行します。特定のコンテキストでアクションを実行する必要があるユーザーは、そのコンテキストのサービス アカウントに対する iam.serviceAccounts.actAs 権限を持っている必要があります。

必要な権限

SecOps インスタンス プロジェクトで、次のいずれかの事前定義ロールを割り当てます。

• chronicle.viewer: セキュリティ検証のアクション、コンテキスト、ジョブ、実行リソースに対する読み取り専用アクセス権。

• chronicle.editor: すべての viewer 権限と、セキュリティ検証のコンテキストとジョブを作成、更新、実行、削除する権限が含まれます。

• chronicle.admin: すべての editor 権限と、カスタム セキュリティ検証アクション（API のみ）を作成、更新、削除する機能が含まれます。

上記の事前定義ロールを使用していない場合は、カスタムロールを使用するか、chronicle.admin と同じ権限を含む chronicle.securityValidationAdmin ロールを割り当てることで、同等の権限を付与できます。

注: chronicle.securityValidationAdmin ロールは gcloud CLI を使用して割り当てる必要があります。

詳細については、必要なロールをご覧ください。

継続的なセキュリティ検証を実装する

セキュリティ体制の検証には、構造化された進行が必要です。

• 環境を定義する

• シミュレーションを実行してベースラインを確立する

• シミュレーションを自動化してドリフトを検出します。

このワークフローにより、環境の変化に合わせてセキュリティ対策を有効に維持できます。

Security Validation コンテキストを作成する

セキュリティ検証コンテキストは、セキュリティ テストの環境を設定します。使用するプロジェクト、テストの実行に使用するアカウント、アクションに必要なその他の詳細を指定します。同じコンテキストをさまざまなアクションで再利用できます。

セキュリティ検証コンテキストを作成するには、次の操作を行います。

1. Google SecOps にログインします。

2. [Security Validation] に移動し、[Execution Contexts] タブに移動します。

3. [実行コンテキストを追加] をクリックします。

4. [実行コンテキストを追加] ダイアログで、次の操作を行います。

   1. [基本プロパティ] で、コンテキストの名前と説明を入力し、[次へ] をクリックします。

   2. [環境設定] で、 Google Cloud プロジェクト ID、実行サービス アカウント、クリーンアップ サービス アカウントを入力します。[Next] をクリックします。

      action profile（アクション スクリプトを実行するため）と setup/cleanup profile（一部のアクションの一部である設定スクリプトとクリーンアップ スクリプトを実行するため）に別々のサービス アカウントを使用することをおすすめします。これらのサービス アカウントには、ターゲット プロジェクトで異なる権限を付与できます。

   3. [ランタイム変数] で、1 つ以上の変数を追加して、デフォルトのパラメータを動的にオーバーライドします。key がパラメータ名、value がオーバーライド値である Key-Value ペアを追加します。

      ヒント: すべてのアクションでは、ターゲットにする Google Cloud プロジェクトを指定するために TARGET_PROJECT_ID 変数が必要です。

   4. [作成] をクリックします。

注: コンテキストを作成すると、指定したプロジェクトに Google SecOps で Cloud Run ジョブと Cloud Storage バケットを作成できるようになります。これらのワークロードに関連するリソースとサービスの料金は、プロジェクトの課金設定に従って請求されます。

セキュリティ検証アクションを実行する

セキュリティ検証コンテキストに対してセキュリティ検証アクションを実行するには、次の操作を行います。

1. Google SecOps にログインします。

2. [セキュリティ検証] に移動し、[コンテンツ ライブラリ] タブに移動します。

3. アクションを選択して [実行] をクリックします。

4. ダイアログで、作成した実行コンテキストを選択し、[今すぐ実行] をクリックします。

新しい実行が作成され、[実行履歴] タブに表示されます。

セキュリティ検証モニターを管理する

モニター機能を使用すると、成功したアクションを定期的に自動的に再実行できます。手動で介入することなく、セキュリティ ポスチャーの継続的なモニタリングが可能になります。

モニターを作成する

モニターは、正常に完了した実行からのみ作成できます。実行からモニターを作成するには、次の操作を行います。

1. Google SecOps にログインします。

2. [セキュリティ検証] に移動し、[実行履歴] タブに移動します。

3. 実行の実行 ID をクリックし、[モニターを作成] をクリックします。

4. 省略可: [モニターを作成] ウィンドウで、モニターに名前を付けます。

   モニター名を入力しない場合、モニターはモニター ID で参照されます。

   このウィンドウに表示されたベースライン実行の詳細を確認します。

5. [次へ] をクリックします。

6. モニターの設定を構成します。

   モニターは、特定の時間に実行することも、1 時間ごとに実行することもできます。

   特定の時間にモニターを実行するには、次の操作を行います。

   1. [時間] プルダウンで、[特定の時間に実行] を選択します。

   2. 隣接するテキスト ボックスで時刻を指定します。

   3. [日数] オプションで、次のいずれかを選択します。

      • 毎日: 指定した時刻に毎日実行されます。

      • 曜日: 指定した時刻に、選択した曜日（月、水、金など）にのみ実行されます。

      • 月の日: 指定された日（15 日など）の指定された時刻に月に 1 回実行されます。

   4. [月] プルダウンで、[毎月]（毎月実行）または [特定の月] を選択して、モニターを実行する月を正確に指定します（1 月、4 月、7 月など）。

   5. [タイムゾーン] プルダウンで、必要なタイムゾーンを選択します。このフィールドのデフォルトは、[ユーザー設定] で設定されているタイムゾーンです（ブラウザ設定とは異なる場合があります）。このデフォルト設定を確認または変更するには、[プロフィール] > [ユーザー設定] > [ローカライズ] > [タイムゾーン] に移動します。

   6. [次へ] をクリックします。

   1 時間間隔でモニタリングを実行するには、次の操作を行います。

   1. [時間] プルダウンで、[1 時間ごとに繰り返す] を選択します。

   2. [hour(s)] フィールドにモニター サイクルの繰り返し頻度を時間単位で設定し、[minute(s)] フィールドに特定の分単位のマークを設定します。たとえば、1 時間 30 分に設定すると、モニターは 1 時間ごとに 30 分後に実行されます（90 分ごとに実行されるわけではありません）。

   3. [営業時間] オプションで、次のいずれかを選択します。

      • 1 日のすべての時間: モニターは、指定された頻度に基づいて、1 日のすべての時間で 24 時間実行されます。

      • 開始時間と終了時間: モニターは、指定した開始時間と終了時間の範囲内でのみ実行されます（午前 8 時から午後 5 時など）。

   4. [日数] オプションで、次のいずれかを選択します。

      • 毎日: 指定した時刻に毎日実行されます。

      • 曜日: 指定した時刻に、選択した曜日（月、水、金など）にのみ実行されます。

      • 月の日: 指定した日（15 日など）の指定した時刻に、月に 1 回実行されます。

   5. [Months] プルダウンで、[Monthly]（毎月実行）または [Specific Months] を選択して、モニターを実行する月（1 月、4 月、7 月など）を指定します。

   6. [タイムゾーン] プルダウンで、必要なタイムゾーンを選択します。このフィールドのデフォルトは、[ユーザー設定] で設定されているタイムゾーンです（ブラウザ設定とは異なる場合があります）。このデフォルト設定を確認または変更するには、[プロフィール] > [ユーザー設定] > [ローカライズ] > [タイムゾーン] に移動します。

   7. [次へ] をクリックします。

7. [Expected Outcomes] で、必要に応じて条件のチェックボックスをオンまたはオフにします。少なくとも 1 つの条件を選択する必要があります。

   • アクションの結果がベースラインと一致する: 実行状態、結果、結果の理由がベースラインと一致するかどうかを評価します。チェックが true と評価されるには、3 つのパラメータすべてが一致する必要があります。

   • 相関イベント プロダクトがベースラインと一致する:

     • 相関イベントをプロダクト別にグループ化します。

     • 現在の実行に、ベースラインに記載されているすべての商品について少なくとも 1 つのイベントがあることを確認します。

     • このチェックでは、ベースラインにイベントがないプロダクトのイベントは無視されます。

     • 基準と一致するイベントがタイムアウト前に到着しない場合は、false と評価されます。

   • 相関検出ルールのアラートがベースラインと一致する:

     • 検出をルールとアラートの状態別にグループ化します。

     • 現在の実行に、ベースライン実行で検出されたルールによる検出が少なくとも 1 つあることを確認します。

     • ベースライン実行で検出がなかったルールからの検出を無視します。

     • ベースラインに一致する検出がタイムアウト前に到着しない場合は、false と評価されます。

8. [作成] をクリックしてモニターを作成します。

モニターを表示して実行する

作成したモニターを表示する手順は次のとおりです。

1. [Security Validation] に移動し、[Monitors] タブに移動します。一部の列はデフォルトで非表示になっています。 [列マネージャー] をクリックして、列の表示 / 非表示を管理します。

2. リストで特定のモニターを見つけます。

3. モニターのリンクをクリックして、モニターの詳細ページを開きます。

4. [今すぐ実行] をクリックして、モニターを実行します。

[モニターの詳細] ページには、モニターの概要がまとめて表示されます。これにより、モニターの全体的なステータスと健全性を一目で確認できます。モニターに関する次の重要な情報が提供されます。

健康状態の概要

次の指標カードには、モニターの安定性の概要が表示されます。

• Monitor Health Status: 最終的なモニタリング結果（Healthy など）を含む最後の実行に基づいて現在の状態と、その状態が維持されている期間が表示されます。

• 最新の正常な結果または異常な結果: ベースラインから逸脱した最新の実行へのポインタを提供します。

• 結果の更新頻度: モニターのステータスが確定した最後の実行からの経過時間を示します。

想定される結果

このセクションでは、ベースライン実行から導き出された成功基準を定義します。

• アクションの結果と理由: ベースライン実行と一致するアクションの結果と理由（NOT_BLOCKED とその理由など）。

• イベントを生成したプロダクト: ベースライン実行と一致する相関イベントのプロダクトのリスト。

• アラート検出ルール: ベースライン実行と一致するアラート相関検出ルールのリスト。

[Monitor Results] テーブルには、モニターのすべての実行が表示されます。この表では、テキスト検索、フィルタリング、列の構成がサポートされています。

モニターを有効または無効にする

モニターを有効または無効にするには、次の操作を行います。

1. [セキュリティ検証] に移動し、[モニター] タブに移動します。

2. [ステータス] 切り替えボタンをクリックして、モニターを有効または無効にします。または、[モニターの詳細] ページで [モニターを一時停止] または [モニターを再起動] をクリックして、ステータスを変更することもできます。

モニターを変更または削除する

モニターを変更または削除する手順は次のとおりです。

1. [セキュリティ検証] に移動し、[モニター] タブに移動します。

2. 変更するモニターの メニューをクリックします。

3. [モニターを編集] をクリックしてモニターを変更するか、[モニターを削除] をクリックしてモニターを削除します。[モニターの詳細] ページで [モニターを編集] をクリックして変更することもできます。

4. [更新] または [確認] をクリックして変更を適用します。

モニターの結果を確認する

モニターのすべての実行を表示するには、次の操作を行います。

1. [セキュリティ検証] に移動し、[モニター] タブに移動します。

2. モニターの メニューをクリックします。

3. [すべての結果を表示] をクリックします。[実行履歴] ページが表示されます。

実行がフィルタされ、その特定のモニターに関連付けられているすべての実行が表示されます。

前回の実行結果を表示する

モニターの最後の実行結果を表示する手順は次のとおりです。

1. [セキュリティ検証] に移動し、[モニター] タブに移動します。

2. モニターの メニューをクリックします。

3. [View last run results] をクリックして、[実行の詳細] を開きます。

そのモニターで実行された最新の実行の詳細が表示されます。

実行結果を確認する

実行したセキュリティ検証アクションは、[実行履歴] タブで確認できます。実行結果を確認する手順は次のとおりです。

1. Google SecOps にログインします。

2. [セキュリティ検証] に移動し、[実行履歴] タブに移動して、実行ステータスをモニタリングします。

   [実行ステータス] 列には、実行が成功したか、エラーが発生したかが表示されます。成功すると、Google SecOps で、セキュリティ検証アクションによってトリガーされた生成イベントと検出を確認できます。

3. 実行 ID をクリックして、実行の詳細を表示します。

[アクション実行の詳細] ページには、検証アクションのステータス、結果、詳細な分析が表示されます。このページでは、アクションのアクティビティによってトリガーされた検出ルールを把握して、セキュリティ ポスチャーを検証します。

相関の進行状況には、実行のリアルタイムの相関ワークフローの進行状況が表示されます。相関関係の実行中は、タスクが完了するまでイベントの合計数が増加する可能性があります。

注: [ 更新 ] 更新 をクリックしてテーブルデータを再読み込みするか、ページを再読み込みしてイベントの合計数を更新します。

[Correlated Rules] テーブルを分析する

[関連ルール] テーブルには、アクションの実行中にトリガーされた検出ルール（カスタムルールとキュレートされたルールの両方）が一覧表示されます。

表には、カスタムルールとキュレートされたルールの両方が表示されます。これには、次の 2 つのグループが含まれます。 * アクションのメタデータで明示的に定義されたルール * 関連イベントによってトリガーされる追加のルール

これにより、期待どおりに動作したルールと、さらに調査が必要なルールを特定できます。

表には次の列が含まれています。

• ルール名: 検出ルールの名前。ルール名をクリックして、ルール定義とその検出履歴を表示します。

• 検出数: ルールによってトリガーされた検出の数。値 0 は、一致するイベントが見つからなかったことを示します。

• 検出: この実行でトリガーされた検出を表示する [検出] ページへのリンク。

• [アクションに関連付けられている]: ルールがアクションのメタデータの一部であったかどうかを示します。

  • はい: アクションのメタデータにルールが含まれています。システムは、アクションの実行時にトリガーされることを想定しています。

  • いいえ: このアクションのメタデータにはルールは含まれていませんが、そのロジックが生成されたイベントと一致し、トリガーされました。

この表は、結果を特定するのに役立ちます。

[アクションへの関連付け] 列	検出数を示す列	意味
YES	1 以上	成功: 予期されたルールが 1 つ以上の検出を正常にトリガーしました。
NO	1 以上	アクティビティによって予期しないルールがトリガーされました。
YES	0	想定されるルールで検出がトリガーされませんでした。

関連付けられたイベントを分析する

セキュリティ検証アクションを実行したら、相関イベントを使用して、環境とセキュリティ管理がシミュレートされた脅威にどのように対応したかを評価します。

分析には、相関関係ワークフローのリアルタイム ステータスと、生成されたすべてのイベントの詳細なテーブルという 2 つのコンポーネントが含まれます。

[イベント相関ステータス] に、現在のワークフローの状態が次のいずれかで表示されます。

• 実行中: システムは関連するイベントを積極的に検索しています。

• 完了: すべてのイベント相関アクティビティが正常に完了しました。

• エラー: 相関ワークフローでエラーが発生し、完了できませんでした。

[相関ワークフローの完了] には、相関関係が完了すると予想される時刻または完了した時刻の推定値が表示されます。

イベント テーブルには、アクションによって生成されたすべてのイベントが一覧表示されます。このデータを使用して、環境とセキュリティ コントロールの個々のレスポンスを分析します。

表には次の列が含まれています。

• Event: イベント ID。クリックすると、UDM 検索でイベントの詳細が表示されます。

• イベントのタイムスタンプ: ソースシステム（サーバーやファイアウォールなど）でイベントが発生した時刻。

• 観測されたタイムスタンプ: セキュリティ検証サービスがイベントを検出し、実行と関連付けた時刻。

• 商品: イベントを生成した商品。

• セキュリティ結果のアクション: UDM イベントの security_result.action フィールドに基づくイベントの結果（Blocked または Not blocked）。

アクションの対象が、実行されている Google SecOps インスタンス以外のリージョンに設定されている場合があります。実行結果には、実行プロジェクトから取得したログが表示されます。

高度なアセットと参照にアクセスする

構成例と参照データ マッピングについては、次のアセットをご覧ください。

実装例: signJWT を使用してアクセス トークンを生成する

signJWT 権限アクションを使用したアクセス トークンの生成の例を考えてみましょう。この例では、Security Validation コンテキストがすでに設定されており、そのコンテキスト内でアクションが実行されていることを前提としています。このアクションは、Cloud Audit Logs を生成し、signJWT 脅威検出ルールでアクセス トークンの生成をトリガーすることが想定されています。

次の設定が必要です。

• 有効な API: ターゲット プロジェクトと実行プロジェクトの両方で、Identity and Access Management（IAM）サービス アカウント認証情報 API が有効になっている必要があります。

• サービス アカウントの権限: セキュリティ検証コンテキストの profile フィールドで指定されたサービス アカウントには、ターゲット プロジェクトに対する iam.serviceAccounts.signJwt 権限が必要です。これは、サービス アカウント トークン作成者のロール（roles/iam.serviceAccountTokenCreator）を介して付与できます。このロールは、プロジェクトまたはターゲット サービス アカウント（このアクションでは、ターゲット プロジェクトのデフォルトの Compute Engine サービス アカウント）に付与できます。

• IAM 監査ロギング: このアクションによって生成されたイベントをキャプチャするには、ターゲット プロジェクトで IAM 監査ロギング（ADMIN_READ）を有効にする必要があります。

• カスタム エクスポート フィルタ: このアクションによって生成されたイベントを SecOps Google Cloud 取り込みで取り込むには、log_id("cloudaudit.googleapis.com/data_access") を含むカスタム エクスポート フィルタを設定する必要があります。

• ルールセット: Cloud Threats -> [Google Cloud] IAM Abuse ルールセットを有効にしてアラートに設定すると、検索ビューと調査ビューで検出を確認できます。

モニタリング スケジューリングの例

これらの例は、継続的モニタリングの定期的なスケジュールを構成する際の参考として使用してください。

構成	実行されるタイミング
時間: 特定の時間（午後 10 時）に実行 曜日: 曜日（月曜日） 月: 毎月 タイムゾーン: EST	毎週月曜日の午後 10 時（東部標準時）に実行されます。
時間: 特定の時間（01:00）に実行 曜日: 月の日（1） 月: 指定（1 月、4 月、7 月、10 月） タイムゾーン: PST	1 月、4 月、7 月、10 月の初日の午前 1 時（太平洋標準時）に実行されます。
時間: 特定の時間（14:00）に実行 曜日: 毎日 月: 毎月 タイムゾーン: UTC	毎日午後 2 時（協定世界時）に実行されます。
時間: 特定の時間（09:30）に実行 曜日: 月の日付（15） 月: 指定（2 月、4 月、6 月、8 月、10 月、12 月） タイムゾーン: EST	2 か月ごとの 15 日（2 月、4 月、6 月、8 月、10 月、12 月）の午前 9 時 30 分（米国東部標準時）に実行されます。
時間: 1 時間ごとに繰り返す インターバル: 1 時間ごと 時間: すべての時間	ノンストップで実行されます。1 日 24 時間、毎時 0 分に正確に実行されます（1:00、2:00、3:00 など）。
時間: 1 時間ごとに繰り返す インターバル: 4 時間ごと 時間: 開始時間と終了時間（午後 10 時～午前 6 時）	夜間のみ実行されます。午後 10 時、午前 2 時、午前 6 時に実行され、トラフィックの少ない時間帯のサーバー ステータスをキャプチャします。

トラブルシューティング

レイテンシと上限

相関ウィンドウのため、新しくトリガーされたモニター実行の結果には、検出データとイベントデータがすぐに反映されません。

エラーの修復

エラー	問題の説明	修正
IAM 権限エラー	サービス アカウントで権限 iam.serviceaccounts.actAs が拒否されました。	アクションを実行する直前にコンテキストを作成または更新した場合は、数分待ってからもう一度お試しください。IAM の変更は一貫していますが、ロールの割り当てがシステム全体に反映されるまでに時間がかかることがあります。 アクションを実行する ID に、指定されたサービス アカウントに対する `iam.serviceaccounts.actAs` 権限があることを確認します。

検証とテスト

次のスケジュールされた間隔を待たずにモニタが正しく構成されていることを確認するには、モニタの詳細ページの [今すぐ実行] ボタンを使用します。相関ウィンドウが経過したら、ページを更新して実行ステータスを確認します。