移行前検証ガイド

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

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

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 検証 ツール（samltool.io）に貼り付けてデコードします。

    Decode

  4. 検証:

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

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

このステップでは、認証後に IDP から に返される属性を検証します。 Google Cloud

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

    レスポンスを見つける

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

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

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

  4. 検証:

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

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

      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 のロール割り当てを確認します。ID の設定（Workforce Identity 連携または Google マネージド アカウントの 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 が code に設定されていることを確認します。
    • スコープ パラメータに注意してください。これには、openid と、必要なクレーム（メール、プロフィールなど）をリリースするために必要なその他のスコープが含まれている必要があります。

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

このステップでは、IdP から へのレスポンスを検証します Google Cloud。

  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 連携の 属性マッピングでのマッピング方法に対応している必要があります。たとえば、attribute.first_name の Google Cloud は JWT の given_name にマッピングされます。
    • IAM ロール: クレームが正しいのに、 のようなメッセージでアクセスが拒否される場合は、Cannot Authenticate user, because user does not have access to the GCP project..., IAM ロールの割り当てを確認します。正しい principalSet 形式（principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/IDP_GROUP_NAME など）を使用して、ユーザーのグループ（JWT の idp_groups）に必要なロールが付与されていることを確認します。

フェーズ 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 エラー:

  • invalid_redirect_uri from IdP: 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 トークンで必要なクレーム（WIF でマッピングされている sub、groups、email、given_name、family_name など）をリリースするように構成されていることを確認します。

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

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

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

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

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