移行前の検証ガイド

以下でサポートされています。

このドキュメントでは、SOAR の移行前に Google Security Operations インスタンスと認証設定を検証するための体系的な診断アプローチについて、手順を追って説明します。このガイドでは、ユーザーの認証と認可に使用される SAML と OIDC の標準に焦点を当てます。

Chronicle API 設定の検証

Chronicle API が Google Cloud プロジェクトで正しく構成されているかどうかを確認する手順は次のとおりです。

  1. Google Cloud コンソールにログインし、上部のナビゲーション バーにあるプロジェクト リストから正しい Google Cloud プロジェクトを選択します。
  2. ナビゲーション メニュー（≡）を開き、[API とサービス] > [有効な API とサービス] に移動します。
  3. [有効な API とサービス] のリストに移動して、Chronicle API を見つけます。

  4. 一覧に表示されている場合: API は有効になっています。

    リストに表示されていない場合: 上部にある [+ API とサービスの有効化] をクリックし、Chronicle API を検索して [有効にする] をクリックします。

サービス アカウントが作成されているかどうかを確認するには、次の操作を行います。

  1. Google Cloud コンソールで [IAM ページ] に移動します。
  2. 非表示のアカウントを表示する（重要な手順）: フィルタバーの右側にある [Google 提供のロール付与を含める] というチェックボックスをオンにする必要があります。
  3. エージェントを検索する: フィルタバーに「chronicle」と入力します。次の特定のパターンに一致するメールアドレスを検索します。 service-[PROJECT_NUMBER]@gcp-sa-chronicle.iam.gserviceaccount.com
  4. 権限を確認する: Chronicle サービス エージェントのロールが付与されていることを確認します。ロールがない場合は、[編集] 編集 をクリックして追加し直します。

Google SecOps の設定の検証

  1. Google Cloud コンソールで、リストから正しい Google Cloud プロジェクトを選択します。
  2. [セキュリティ] > [Google SecOps] に移動すると、[シングル サインオン] タブが表示されます。
  3. Google SecOps が有効になっている場合は、[シングル サインオン] というタブが表示されます。そうでない場合、見込み顧客の開始は完了していません。プロダクト内の通知に表示される Google フォームに Google Cloud プロジェクト ID を入力します。移行の日時枠を確認し、フォームを送信します。送信してから 72 時間以内に返信がない場合は、soar-migration-to-gcom@google.com にお問い合わせください。
  4. タブが存在する場合は、[SecOps に移動] をクリックします。ログインに成功すると、認証構成が正しいことが確認されます。ログインに失敗した場合は、次のセクションで構成をデバッグします。ログインに失敗した場合は、次のセクションで構成をデバッグします。

SAML フローとトラブルシューティング

このセクションでは、SAML 認証プロセスの概要と、一般的な構成の問題を診断して解決するための体系的なアプローチについて説明します。

認証ワークフローのアーキテクチャ

リクエスト フローを理解することは、障害点を特定するうえで重要です。次の図は、ログインが成功するまでの順次パスを示しています。

認証ワークフローのアーキテクチャ

トラブルシューティングの手順

SAML 認証プロセスを効果的に診断してトレースするには、次のセクションに記載されているウェブベースのユーティリティを使用します。

Google は特定のプロダクトを推奨していませんが、次のツールはプロセスのトラブルシューティングに役立つことがわかっています。

  • SAML 検証: https://www.samltool.io/
    • 目的: 未加工の SAML リクエストとレスポンスのデコードと検証に使用されます。
  • JWT の検査: https://www.jwt.io/
    • 目的: JSON ウェブトークン（JWT）のクレームとコンテンツを検査するために使用されます。

フェーズ 1: 環境の準備

始める前に、次の手順を完了して、ブラウザ環境でネットワーク トラフィックをキャプチャする準備ができていることを確認してください。

  1. 新しいブラウザタブを開くか、シークレット ウィンドウを使用します。

  2. お使いのオペレーティング システムのショートカットを使用して、デベロッパー ツールを開きます。

    • Windows: F12 キーを押します。
    • Linux: Ctrl+Shift+I キーを押します。
    • macOS: Cmd+Option+I キーを押します。

  3. [ネットワーク] タブに移動します。

  4. [ログを保持] チェックボックスをオンにして、リダイレクト中にデータが失われないようにします。

    ログを保持

  5. Google SecOps 環境の URL に移動して、ログイン フローを開始します。この URL は、SOAR スタンドアロンのお客様向けの移行ステージ 1 の手順 5 で Google SecOps の設定を完了すると、メールで届きます。メールの件名は Your Google SecOps instance is ready です。

フェーズ 2: IDP への SAML リクエストを検証する

このステップでは、 Google Cloud が ID プロバイダ（IDP）に送信した最初のメッセージを確認します。

  1. リクエストを見つける: [ネットワーク] タブのフィルタバーで、saml を検索します。

    リクエストを見つける

  2. データを抽出する: リクエストを選択し、[ペイロード] タブをクリックします。SAMLRequest というラベルの付いたクエリ文字列パラメータを見つけます。

    データの抽出

  3. デコード: リクエスト値をコピーして、SAML Validation ツール（samltool.io）に貼り付けてデコードします。

    Decode

  4. 検証:

    • [Request Destination]（リクエストの宛先）を確認します。
    • この URL が IDP 内の構成設定と一致していることを確認します。

フェーズ 3: IDP からの SAML レスポンスを検証する

この手順では、認証後に IDP から Google Cloud に返される属性を確認します。

  1. レスポンスを見つける: [ネットワーク] タブのフィルタバーで、signin-callback を検索します。

    回答を見つける

  2. データを抽出する: リクエストを選択し、[ペイロード] タブをクリックします。SAMLResponse データを特定します。

    SAML レスポンス データを見つける

  3. デコード: レスポンス値をコピーして、SAML 検証ツールに貼り付けます。

  4. 検証:

    • groups、first name、last name、email などの返されたクレーム（属性）を確認します。
    • 重要: これらの属性が Google CloudのWorkforce プールの設定と一致していることを確認します。

    • ログインしようとしている特定のユーザーに対して値が正しいことを確認します。

      Workforce プールの設定

次の図は、属性マッピングを示しています。

attribute-mapping

画像のマッピングは次のとおりです。

  • google.subject = assertion.subject
  • attribute.last_name = assertion.attributes.last_name[0]
  • attribute.user_email = assertion.attributes.user_email[0]
  • attribute.first_name = assertion.attributes.first_name[0]
  • google.groups = assertion.attributes.groups

左側は常に同じです。これは Google の構文です。右側は、SAML レスポンスに表示されるクレーム属性キーに従っています。

[0] は、指定された特定の属性（last_name、user_email、first_name）では重要ですが、subject と groups には関係ありません。

フェーズ 4: Google SecOps の認証を検証する

このステップでは、 Google Cloud が Google SecOps SOAR にログインするユーザーを認証しているかどうかを確認します。

  1. ユーザーのブラウザでトークンを見つけます。[ネットワーク] タブのフィルタバーで、エンドポイント auth/siem を検索します。

    ユーザーのブラウザでトークンを見つける

  2. データを抽出する: リクエストを選択し、[ペイロード] タブを表示します。jwt 文字列を見つけます。

  3. デコード: JWT 文字列をコピーして、JWT 検査ツール（jwt.io）に貼り付けます。

    JWT 文字列をコピーして貼り付けます。

  4. 検証:

    • given_name、family_name、email、idpgroups のデコードされたクレームを比較します。
    • 一致の確認: これらの値は、フェーズ 3（SAML レスポンス）で検証された属性と完全に一致している必要があります。
    • 値が一致してもアクセスできない場合は、IAM でロールの割り当てを確認します。すべてのユーザーに、Identity 設定（Google 管理アカウントの Workforce Identity 連携または Cloud Identity）の正しいプリンシパル形式を使用して、Chronicle の事前定義ロールのいずれかが割り当てられていることを確認します。

フェーズ 5: SOAR 権限へのアクセスを検証する

この手順では、プラットフォームの [グループ マッピング] ページで、SOAR の権限がシステムによって正しく割り当てられていることを確認します。

グループ マッピング ページでデフォルトのアクセスが有効になっているため、管理者は SOAR に自動的にアクセスできます。

この新しい SOAR インスタンスにいくつかの IDP グループ マッピングを追加することで、ユーザーのグループ アクセスを検証できます。新しいインスタンスでは、デフォルトで [グループ マッピング] ページが空になっています。他のユーザーのグループ アクセスを検証するには、新しい SOAR インスタンスに IDP グループ マッピングを追加します。手順は次のとおりです。

  1. 既存の SOAR インスタンスの [グループ マッピング] ページからグループ マッピングをコピーします。
  2. IDP グループのユーザーが新しい Google SecOps URL にアクセスできるようにリクエストします。

  3. お客様が SOAR にアクセスできない場合は、次のトラブルシューティングの手順に沿って対応します。

    a. レスポンスを検査する: フェーズ 4 の auth/siem リクエストを開き、[プレビュー] タブを選択します。

    b. 権限を確認する: JSON レスポンス内の permissions オブジェクトを見つけます。

省略可: 時間を節約するには、これらのマッピングを既存の Google SecOps インスタンスの [設定] > [詳細] > [グループ マッピング] にコピーします。

OIDC フローとトラブルシューティング

このセクションでは、OIDC 認証プロセスの概要と、一般的な統合の問題を診断して解決するための体系的なアプローチについて説明します。

認証ワークフローのアーキテクチャ

リクエスト フローを理解することは、障害点を特定するうえで重要です。次の図は、ログインが成功するまでの順次パスを示しています。

認証ワークフローのアーキテクチャ

OIDC のトラブルシューティングの手順

OIDC 認証プロセスを効果的に診断してトレースするには、ブラウザのデベロッパー ツールとオンライン JWT デコーダを使用します。

  • JWT の検査: https://www.jwt.io/
    • 目的: JSON ウェブトークン（JWT）のクレームとコンテンツを検査するために使用されます。

フェーズ 1: 環境の準備

始める前に、次の手順を完了して、ブラウザ環境でネットワークをキャプチャする準備ができていることを確認してください。

  1. 新しい空白のブラウザタブまたはシークレット ウィンドウを開きます。

  2. お使いのオペレーティング システムのショートカットを使用して、デベロッパー ツールを開きます。

    • Windows: F12 キーを押します。
    • Linux: Ctrl+Shift+I キーを押します。
    • macOS: Cmd+Option+I キーを押します。

  3. [ネットワーク] タブに移動します。

  4. [ログを保持] チェックボックスをオンにして、リダイレクト中にデータが失われないようにします。

    ログを保持

  5. Google SecOps 環境の URL に移動して、ログイン フローを開始します。この URL は、SOAR スタンドアロンのお客様向けの移行ステージ 1 の手順 5 で Google SecOps の設定を完了すると、メールで届きます。メールの件名は YourGoogle SecOps instance is ready です。

フェーズ 2: OIDC プロバイダへの認可リクエストを検証する

このステップでは、 Google Cloud から OpenID Connect プロバイダ（IdP）への最初のリダイレクトを検証します。

  1. リクエストを見つける: [ネットワーク] タブで、OIDC プロバイダの認証エンドポイントへの最初のリダイレクトを探します。通常、URL には client_id、redirect_uri、scope、response_type、state などのパラメータが含まれています。

    リクエストを見つける

  2. 検証:

    • client_id が OIDC プロバイダで構成されているものと一致することを確認します。
    • redirect_uri が https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID と完全に一致していることを確認します。POOL_ID と PROVIDER_ID は、Workforce Identity 連携のプールとプロバイダに置き換えます。
    • response_type がコードに設定されていることを確認します。
    • スコープ パラメータに注意してください。このパラメータには、必要なクレーム（メール、プロフィールなど）をリリースするために必要な openid とその他のスコープが含まれている必要があります。

フェーズ 3: コールバックとトークンの交換を検証する

このステップでは、 Google Cloudへの IdP のレスポンスが検証されます。

  1. コールバックを見つける: [ネットワーク] タブで、signin-callback URL（.../signin-callback/...）へのリクエストを見つけます。

    コールバックを見つける

  2. データを確認: このリクエストの URL パラメータを確認します。これには、OIDC IdP から提供されたコード パラメータが含まれている必要があります。

  3. 舞台裏: Workforce Identity 連携は、このコードを OIDC プロバイダのトークン エンドポイントからトークン（ID トークン、アクセス トークン）と交換します。この段階のエラーは、Workforce Identity 連携の Cloud Logging で確認できることがよくあります。

    • 属性の伝播と完全なトークンを確認する: Workforce Identity 連携の属性マッピングで期待どおりの結果が得られることを確認するには:
      • Workforce Identity 連携プロバイダ構成で指定されたリダイレクト URI を、プロバイダのリダイレクト URI に追加します（例: https://auth.cloud.google/signin-callback/locations/global/workforcePools/POOL_ID/providers/PROVIDER_ID）。
      • Workforce Identity 連携プロバイダに移動して、IdP トークンをデバッグします。完全なトークンを確認することもできます。詳細については、プロダクト構成を確認するをご覧ください。

    トークン全体を表示 属性を検証する

フェーズ 4: Google SecOps の認証を検証する

このステップでは、 Google Cloud が Google SecOps SOAR にログインするユーザーを認証しているかどうかを確認します。

  1. ユーザーのブラウザでトークンを見つけます。[ネットワーク] タブのフィルタバーで、エンドポイント auth/siem を検索します。

    ユーザーのブラウザでトークンを見つける

  2. データを抽出する: リクエストを選択し、[ペイロード] タブを表示します。jwt 文字列を見つけます。

  3. デコード: JWT 文字列をコピーして、JWT 検査ツール（jwt.io）に貼り付けます。

    JWT 文字列をコピーして貼り付ける

  4. 検証:

    • sub、given_name、family_name、email、idpgroups のデコードされたクレームを比較します。
    • 一致の確認: これらの値は、OIDC プロバイダによってリリースされた属性と、Workforce Identity 連携の属性マッピングでのマッピング方法に対応している必要があります。たとえば、 Google Cloud の attribute.first_name は JWT の given_name にマッピングされます。
    • IAM ロール: クレームが正しいにもかかわらず、Cannot Authenticate user, because user does not have access to the GCP project..., のようなメッセージでアクセスが拒否された場合は、IAM ロールの割り当てを確認します。ユーザーのグループ（JWT の idp_groups）に、正しい principalSet 形式（principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/IDP_GROUP_NAME など）を使用して必要なロールが付与されていることを確認します。

フェーズ 5: SOAR 権限へのアクセスを検証する

この手順では、プラットフォームの [グループ マッピング] ページで、SOAR の権限がシステムによって正しく割り当てられていることを確認します。

グループ マッピング ページでデフォルトのアクセスが有効になっているため、管理者は SOAR に自動的にアクセスできます。

この新しい SOAR インスタンスにいくつかの IDP グループ マッピングを追加することで、ユーザーのグループ アクセスを検証できます。新しいインスタンスでは、デフォルトで [グループ マッピング] ページが空になっています。他のユーザーのグループ アクセスを検証するには、新しい SOAR インスタンスに IDP グループ マッピングを追加します。手順は次のとおりです。

  1. 既存の SOAR インスタンスの [グループ マッピング] ページからグループ マッピングをコピーします。
  2. IDP グループのユーザーが新しい Google SecOps URL にアクセスできるようにリクエストします。

  3. お客様が SOAR にアクセスできない場合は、次のトラブルシューティングの手順に沿って対応します。

    a. レスポンスを検査する: フェーズ 4 の auth/siem リクエストを開き、[プレビュー] タブを選択します。

    b. 権限を確認する: JSON レスポンス内の permissions オブジェクトを見つけます。

省略可: 時間を節約するには、これらのマッピングを既存の Google SecOps インスタンスの [設定] > [詳細] > [グループ マッピング] にコピーします。

一般的な OIDC エラー:

  • IdP からの invalid_redirect_uri: IdP で構成されたリダイレクト URI が、https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID と完全に一致していることを確認します。POOL_ID と PROVIDER_ID は、Workforce Identity 連携のプールとプロバイダに置き換えます。末尾のスラッシュや http と https の不一致も、このエラーの原因となります。

  • JWT にクレームがない:

    1. IdP 側: OIDC クライアントが、ID トークンで必要なクレーム（sub、groups、email、given_name、family_name など、WIF でマッピングされているクレーム）をリリースするように構成されていることを確認します。

    2. WIF 側: WIF の [Attribute Mapping] セクションで、これらの受信クレームが正しくマッピングされていることを確認します（例: google.groups=assertion.groups）。トークンにクレームが存在するが、WIF でマッピングされていない場合、SOAR プラットフォームでユーザーの承認に失敗することがあります。属性マッピングが想定どおりの結果を生成することを確認するには、プロバイダの構成を確認するをご覧ください。

移行後のグループ マッピング

移行が完了した後も、Google SecOps でグループ マッピングは重要です

移行後、移行されたインスタンスはグループ マッピングを保持します。これらは、SOAR へのユーザー アクセスを決定するための基準として機能します。Google SecOps にアクセスするには、このページですべてのユーザーがマッピングされていることを確認する必要があります。詳細については、インスタンスにアクセスするをご覧ください。

さらにサポートが必要な場合 コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。