移行前検証ガイド

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

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

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 サービス エージェント のロールが付与されていることを確認します。 ロールがない場合は、編集アイコン [編集] [**編集**] をクリックして追加します。

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 認証プロセスを効果的に診断して追跡するには、次のセクションに記載されているウェブベースのユーティリティを使用します。

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

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

フェーズ 1: 環境の準備

開始する前に、ブラウザ環境でネットワーク トラフィックをキャプチャできるように、次の操作を行います。

  1. 新しい空白のブラウザタブを開きます。
  2. [デベロッパー ツール] （F12 または Ctrl+Shift+I （Windows /Linux）または Cmd+Option+I （macOS）を押す）を開き、[ネットワーク] タブに移動します。

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

    ログを保持

  4. Google SecOps 環境の URL に移動して、ログイン フローを開始します。この URL は、SOAR スタンドアロンのお客様向けに、移行ステージ 1 のステップ 5 で Google SecOps の設定を完了した後にメールで届きます。メールの件名は YourGoogle 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 インスタンスの [設定] > [詳細] > [グループ マッピング] にコピーします。

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