Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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

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

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

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

一般的なユースケース

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

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

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

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

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

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

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

主な用語

セキュリティ検証コンテキスト: セキュリティ検証コンテキストは、セキュリティテストの環境を設定します。使用するプロジェクト、テストを実行するアカウント、アクションに必要なその他の詳細を指定します。
セキュリティ検証アクション: 実際の攻撃者の手法を模倣するように設計されたスクリプト。検出ルールをトリガーしてセキュリティポスチャーを検証するために使用されます。
ベースライン実行: 今後の実行を比較するための標準的な参照として使用される、完了した特定のセキュリティ検証実行。
モニタリング: セキュリティ検証アクションを実行し、定義されたベースラインに対して結果を評価するスケジュール設定されたジョブ（API では SecurityValidationJob）。
ドリフトステータス: 最近の実行がベースラインと一致するか（正常）、偏差を示すか（ドリフトが検出されたか）に基づいて、モニターの健全性インジケーターが表示されます。
関連付けウィンドウ: 実行後 12 時間の期間。この期間中、システムは実行されたアクションのメタデータにあるイベントフィルタテンプレートに基づいて、関連するイベントと検出を検索して関連付けます。
モニターのタイムアウト: 実行後にイベントと検出が関連付けられ、最終的なドリフトステータスが評価されるまでシステムが待機する最大時間。このタイムアウトは、12 時間の相関関係ウィンドウ内で動作します。モニターが成功と見なされるには、このモニターのタイムアウトに達する前に、期待される結果が確認されている必要があります。このタイムアウト前にチェックに合格しない場合、システムはモニターを failed としてマークします。この期間はデフォルトで 8 時間に設定されていますが、15 分～ 10 時間の範囲で構成できます。

始める前に

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

必要な設定

次の設定になっていることを確認します。

テナントで Security Validation が有効になっている必要があります。
セキュリティ検証は、セルフマネージドプロジェクトでのみ機能します。
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 ロールを割り当てることで、同等の権限を付与できます。

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

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

セキュリティポスチャーの検証には、次のような構造化された進行が必要です。

環境を定義する
シミュレーションを実行してベースラインを確立する
シミュレーションを自動化してドリフトを検出します。

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

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

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

セキュリティ検証コンテキストを作成する手順は次のとおりです。

Google SecOps にログインします。
[セキュリティ検証] に移動し、[実行コンテキスト] タブに移動します。
[実行コンテキストを追加] をクリックします。
[実行コンテキストを追加] ダイアログで、次の操作を行います。
1. [基本プロパティ] で、コンテキストの名前と説明を入力し、[次へ] をクリックします。
2. [環境設定] で、 Google Cloud プロジェクト ID、実行サービスアカウント、クリーンアップサービスアカウントを入力します。[次へ] をクリックします。
  
  action profile（アクションスクリプトを実行するため）と setup/cleanup profile（一部のアクションに含まれる設定スクリプトとクリーンアップスクリプトを実行するため）に別々のサービスアカウントを使用することをおすすめします。これらのサービスアカウントには、ターゲットプロジェクトで異なる権限を付与できます。
3. [ランタイム変数] で、1 つ以上の変数を追加して、デフォルトのパラメータを動的にオーバーライドします。key がパラメータ名、value がオーバーライド値である Key-Value ペアを追加します。
  
  ヒント: すべてのアクションでは、TARGET_PROJECT_ID 変数を使用して、ターゲットにする Google Cloud プロジェクトを指定する必要があります。
4. [作成] をクリックします。

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

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

Google SecOps にログインします。
[Security Validation] に移動し、[Content Library] タブに移動します。
アクションを選択して [実行] をクリックします。
ダイアログで、作成した実行コンテキストを選択し、[今すぐ実行] をクリックします。

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

Security Validation モニターを管理する

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

モニターを作成する

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

Google SecOps にログインします。
[Security Validation] に移動し、[Execution history] タブに移動します。
実行の実行 ID をクリックし、[モニターを作成] をクリックします。
省略可: [モニターを作成] ウィンドウで、モニターに名前を付けます。

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

このウィンドウに表示されたベースライン実行の詳細を確認します。
[次へ] をクリックします。
モニターの設定を構成します。

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

特定の時間にモニターを実行するには、次の操作を行います。
1. [時間] プルダウンで、[特定の時間に実行] を選択します。
2. 隣接するテキストボックスに時刻を指定します。
3. [日数] オプションで、次のいずれかを選択します。
  - 毎日: 指定した時刻に毎日実行されます。
  - 曜日: 指定した時刻に、選択した曜日（月、水、金など）にのみ実行されます。
  - 月の日: 指定した日（15 日など）の指定した時刻に月に 1 回実行されます。
4. [月] プルダウンで、[毎月]（毎月実行）または [特定の月] を選択して、モニターを実行する月を正確に指定します（1 月、4 月、7 月など）。
5. [タイムゾーン] プルダウンで、必要なタイムゾーンを選択します。このフィールドは、デフォルトで [ユーザー設定] で設定されているタイムゾーン（ブラウザ設定とは異なる場合があります）に設定されます。このデフォルト設定を確認または変更するには、[プロフィール] > [ユーザー設定] > [ローカライズ] > [タイムゾーン] に移動します。
6. [次へ] をクリックします。
1 時間間隔で Monitor を実行するには、次の操作を行います。
1. [時間] プルダウンで、[1 時間ごとに繰り返す] を選択します。
2. [hour(s)] フィールドにモニターサイクルの繰り返し頻度を時間単位で設定し、[minute(s)] フィールドに特定の分単位のマークを設定します。たとえば、1 時間 30 分に設定すると、モニターは 1 時間ごとに 30 分後に実行されます（90 分ごとに実行されるわけではありません）。
3. [時間] オプションで、次のいずれかを選択します。
  - 1 日のすべての時間: モニターは、指定された頻度に基づいて、1 日のすべての時間で 1 時間ごとに実行されます。
  - 開始時間と終了時間: モニタは、指定した開始時間と終了時間の範囲内（午前 8 時から午後 5 時など）でのみ実行されます。
4. [日数] オプションで、次のいずれかを選択します。
  - 毎日: 指定した時刻に毎日実行されます。
  - 曜日: 指定した時刻に、選択した曜日（月、水、金など）にのみ実行されます。
  - 月の日: 指定した日（15 日など）の指定した時刻に月に 1 回実行されます。
5. [Months] プルダウンで、[Monthly]（毎月実行）または [Specific Months] を選択して、モニターを実行する月を正確に指定します（例: 1 月、4 月、7 月）。
6. [タイムゾーン] プルダウンで、必要なタイムゾーンを選択します。このフィールドは、デフォルトで [ユーザー設定] で設定されているタイムゾーン（ブラウザ設定とは異なる場合があります）に設定されます。このデフォルト設定を確認または変更するには、[プロフィール] > [ユーザー設定] > [ローカライズ] > [タイムゾーン] に移動します。
7. [次へ] をクリックします。
[Expected Outcomes] で、必要に応じて条件のチェックボックスをオンまたはオフにします。条件を 1 つ以上選択する必要があります。
- アクションの結果がベースラインと一致する: 実行状態、結果、結果の理由がベースラインと一致するかどうかを評価します。チェックが true と評価されるには、3 つのパラメータすべてが一致する必要があります。
- 相関イベントプロダクトがベースラインと一致する:
  - 相関イベントをプロダクト別にグループ化します。
  - 現在の実行に、ベースラインに記載されているすべてのプロダクトのイベントが少なくとも 1 つ含まれていることを確認します。
  - このチェックでは、ベースラインにイベントがないプロダクトのイベントは無視されます。
  - 基準と一致するイベントがタイムアウト前に到着しない場合は、false と評価されます。
- 相関検出ルールのアラートがベースラインと一致する:
  - 検出をルールとアラートの状態別にグループ化します。
  - 現在の実行に、ベースライン実行で検出されたルールによる検出が少なくとも 1 つあることを確認します。
  - ベースライン実行で検出がなかったルールからの検出を無視します。
  - ベースラインと一致する検出がタイムアウト前に到着しない場合は、false と評価されます。
[作成] をクリックしてモニターを作成します。

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

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

[セキュリティ検証] に移動し、[モニタ] タブに移動します。一部の列はデフォルトで非表示になっています。 [列マネージャー] をクリックして、列の表示 / 非表示を管理します。
リストで特定のモニターを見つけます。
モニターのリンクをクリックして、モニターの詳細ページを開きます。
[今すぐ実行] をクリックして、モニターを実行します。

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

健康状態の概要

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

ヘルスステータスのモニタリング: 最終的なモニタリング結果（Healthy など）を含む最後の実行に基づいて、現在の状態と、その状態が維持されている期間が表示されます。
最新の正常な結果または異常な結果: ベースラインから逸脱した最新の実行へのポインタを提供します。
結果の更新頻度: モニターのステータスが確定した最後の実行からの経過時間を示します。

期待される結果

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

アクションの結果と理由: ベースライン実行と一致するアクションの結果と理由（NOT_BLOCKED とその理由など）。
イベントを生成したプロダクト: ベースライン実行と一致する相関イベントのプロダクトのリスト。
アラート検出ルール: ベースライン実行と一致するアラート相関検出ルールのリスト。

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

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

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

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

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

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

[セキュリティ検証] に移動し、[モニタ] タブに移動します。
変更するモニターのメニューをクリックします。
[モニターを編集] をクリックしてモニターを変更するか、[モニターを削除] をクリックしてモニターを削除します。[モニターの詳細] ページで [モニターを編集] をクリックして変更することもできます。
[更新] または [確認] をクリックして変更を適用します。

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

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

[セキュリティ検証] に移動し、[モニタ] タブに移動します。
モニターのメニューをクリックします。
[すべての結果を表示] をクリックします。[実行履歴] ページが表示されます。

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

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

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

[セキュリティ検証] に移動し、[モニタ] タブに移動します。
モニターのメニューをクリックします。
[View last run results] をクリックして、[実行の詳細] を開きます。

その Monitor で実行された最新の実行の詳細が表示されます。

実行結果を確認する

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

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

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

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

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

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

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

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

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

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

ルール名: 検出ルールの名前。ルール名をクリックすると、ルールの定義とその検出履歴が表示されます。
検出数: ルールによってトリガーされた検出の数。値 0 は、一致するイベントが見つからなかったことを示します。
検出: この実行でトリガーされた検出を表示する [検出] ページへのリンク。
アクションに関連付けられている: ルールがアクションのメタデータの一部であったかどうかを示します。
- はい: アクションのメタデータにルールが含まれています。システムは、アクションの実行時にトリガーされることを想定しています。
- いいえ: このアクションのメタデータにはルールは含まれていませんが、そのロジックが生成されたイベントと一致し、トリガーされました。

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

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

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

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

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

signJWT 権限アクションを使用してアクセストークンを生成する例を考えてみましょう。この例では、セキュリティ検証コンテキストがすでに設定されており、そのコンテキスト内でアクションが実行されていることを前提としています。このアクションは、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 か月ごと（2 月、4 月、6 月、8 月、10 月、12 月）の 15 日の午前 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` 権限があることを確認します。

検証とテスト

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