SOAR 移行の概要

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

Google SecOps SOAR

このドキュメントでは、SOAR インフラストラクチャを Google Cloudに移行するプロセスとタイムラインについて説明します。この移行は、インフラストラクチャをモダナイズし、 Google Cloud サービスとの統合を強化することを目的としています。これにより、Google Security Operations の統合されたお客様と、 Google Cloudに移行するスタンドアロン SOAR ユーザーの両方にメリットがあります。

この移行は、信頼性の向上、セキュリティの強化、コンプライアンスの強化、よりきめ細かいアクセス制御など、重要なインフラストラクチャのアップグレードを提供するために必要です。また、Model Context Protocol（MCP）の統合と、アクセス制御用の IAM、Cloud Monitoring、Cloud Audit Logs などのクラス最高のサービスを通じて、エージェント型 AI 機能にアクセスできます。

移行は、ステージ 1 とステージ 2 の 2 つのステージで実施されます。

ステージ 1 には、次の移行が含まれます。

• Google 所有の SOAR プロジェクトを Google Cloud インフラストラクチャに移行します。これは Google によって行われます。
• SOAR 認証の Google Cloud への移行（SOAR スタンドアロンのお客様にのみ適用）。

ステージ 2 には、次の移行が含まれます。

• SOAR 権限グループと権限の Google Cloud IAM への移行。
• SOAR API を新しい統合 Chronicle API に移行します。既存のスクリプトと統合の更新が必要です。
• Webhook の移行。
• リモート エージェント認証インフラストラクチャの移行。

移行が成功したことを確認する

• [SOAR Settings] > [License Management] に移動し、システム バージョン番号の後に Google.com と表示されていることを確認して、ステージ 1 が正常に完了したことを確認します。

• SOAR 権限から IAM ロールへのステージ 2 の移行が正常に完了したことを確認するには、[SOAR Settings] > [License Management] に移動し、システム バージョン番号の後に Google.com と CloudIAM Enabled が表示されていることを確認します。

Google SecOps 統合のお客様の移行ステージ 1

サービス内通知で、ステージ 1 の移行日と、時間帯を確認するための Google フォームをご確認ください。 ステージ 1 には、次の移行が含まれます。

• Google 所有の SOAR プロジェクトを Google Cloudに移行する

移行に伴い、Google SecOps プラットフォームにアクセスできないダウンタイムが最長 90 分発生します。このダウンタイム中、SIEM サービスはバックグラウンドで引き続き動作しますが、SOAR サービスは一時的に停止されます。ダウンタイムが終了すると、プラットフォームにアクセスできるようになります。SOAR サービスは、ダウンタイム中に生成された、または取り込まれたアラートの処理を再開します。

移行が完了すると、メールが届きます。

SOAR スタンドアロンのお客様の移行ステージ 1

注: SOAR 移行プロセスのステージ 1 の手順（特に SOAR スタンドアロンのお客様向け）に関する包括的なエンドツーエンドのチュートリアルについては、Google SecOps SOAR 移行の動画をご覧ください。

ニーズとユースケースに応じて、次のいずれかの移行オプションを選択できます。

• オプション 1（推奨）- SOAR インスタンスを既存の SIEM インスタンスと統合する: SOAR が有効になっていない既存の SIEM インスタンスがある場合は、可能な限り、SOAR インスタンスを既存の SIEM デプロイに統合することをおすすめします。このオプションでは、既存の SIEM インスタンスに関連付けられた Google Cloud プロジェクトを使用し、認証、アクセス制御、監査ロギングを共有する単一の Google SecOps インターフェースで両方のプロダクトを統合します。

  注意: このオプションは、既存の SIEM インスタンスで SOAR がまだ有効になっていない場合にのみ適用されます。SIEM インスタンスに Google SecOps の一部として SOAR がすでに含まれている場合は、このオプションを選択しないでください。スタンドアロン SOAR インスタンスを移行すると、既存の SOAR 構成とデータが上書きされる可能性があります。この場合は、オプション 2 を選択するか、Google SecOps サポートにお問い合わせください。
  重要: このオプションは、既存の SIEM インスタンスに、取り込みベースのライセンス（SIEM または統合 Google SecOps）がある場合にのみ使用できます。SIEM インスタンスに以前の従業員ベースのライセンスがある場合、SOAR で Google Cloud プロジェクトを再利用することはできません。代わりに、オプション 2 を選択して、SIEM と SOAR のデプロイを別々に維持します。詳細については、SOAR MSSP インスタンスを Google Cloudに移行するをご覧ください。

• オプション 2 - 新しい Google SecOps インスタンスをデプロイする: 既存の SIEM インスタンスがない場合や、SOAR と SIEM のデプロイを別々に維持する必要がある場合は、専用の Google Cloud プロジェクトに新しい Google SecOps インスタンスをデプロイできます。

ステージ 1 を開始する準備が整うと、サービス内通知メッセージが届きます。 その際は、必ず次のようにしてください。

1. 選択した移行オプションに基づいて、 Google Cloud プロジェクトを特定または設定します。
   • オプション 1（既存の SIEM と統合する）: SIEM インスタンスにリンクされている既存の Google Cloud プロジェクトを使用します。
   • オプション 2（新しい Google SecOps インスタンスをデプロイする）: Google Cloud プロジェクトを設定します。Google SecOps サポートにアクセスするように設定されているものの、Google Security Operations インスタンスがまだない Google Cloud プロジェクトを使用することもできます。
2. Google Cloud プロジェクトで Chronicle API を有効にします（まだ有効になっていない場合）。
3. SOAR にアクセスするための Google Cloud 認証を設定します。SOAR にアクセスするための Google Cloud 認証を設定するをご覧ください。
4. サービス内通知の Google フォームに Google Cloud プロジェクト ID を入力し、移行の日時を確認してからフォームを送信します。
5. 「Google Security Operations ページを取得する」への招待メールを承諾し、設定を完了します（新しい Google SecOps インスタンスをデプロイする場合）。地域情報が正確であることを確認してください。
6. 移行前の検証ガイドを参照して、上記の手順が正しく設定されていることを確認します。

手順を完了すると、Google はスケジュールされた日時に移行を実行します。移行に伴い、SOAR サービスで約 2 時間のダウンタイムが発生します。完了すると、SOAR プラットフォームにアクセスするための新しい URL が記載されたメールが届きます。古い URL は 2026 年 6 月 30 日まで機能し、新しい URL にリダイレクトされます。

SOAR にアクセスするための Google Cloud 認証を設定する

使用する ID のタイプに応じて、次のいずれかのオプションを構成します。これらの手順を完了するには、 Google Cloud と ID または IdP 管理者のサポートが必要になる場合があります。

オプション 1: Google Cloud （Google 管理アカウント）で Cloud Identity 認証を構成する

このシナリオは、Google が管理するユーザー名とパスワードを使用して、Cloud Identity 内でユーザー アカウントを直接管理する場合に適用されます。Okta や Azure AD などのサードパーティの ID プロバイダで SSO に Cloud Identity を使用している場合は適用されません。

次の手順を行います。

1. Google Cloudで Cloud Identity を設定する。

   Google が管理するユーザー名とパスワードを使用して Cloud Identity をすでに設定している場合は、この手順をスキップできます。

2. 既存のすべての SOAR ユーザーが Cloud Identity 管理コンソールで構成されていることを確認します。

3. Google アカウントのロール割り当て形式に従って、IAM で必要なロールを付与します。

   1. Google Cloud で次の IAM 事前定義ロールをオンボーディング SME に割り当てます。

      • Chronicle API 管理者
      • Chronicle サービス管理者
      • Chronicle SOAR 管理者
      • プロジェクト IAM 管理者
      • Service Usage 管理者

   2. 既存のすべての SOAR ユーザーに、次のいずれかの事前定義された IAM ロールを割り当てます。

      • Chronicle API 管理者
      • Chronicle API 編集者
      • Chronicle API 閲覧者
      • Chronicle API 制限付き閲覧者

4. 各ユーザー（管理者を含む）をメール ユーザー グループにマッピングして、SOAR で認証設定を完了します。

   1. [SOAR 設定] > [詳細] > [グループ マッピング] に移動します。

   2. [add 追加] をクリックして、次の情報を入力します。

      • IdP / ユーザー グループ: メール ユーザー グループの名前（T1 アナリストなど）。
      • 権限グループ: 権限グループを選択します。
      • SOC ロール: SOC ロールを選択します。
      • 環境: 環境（[すべての環境] など）を選択します。
      • グループ メンバー: 必要なユーザーのメールアドレスを入力します。メールアドレスを追加するごとに Enter キーを押します。
      注: [外部認証] ページに既存のメール ユーザー グループ マッピングがある場合は、既存の SOAR 認証をオーバーライドしないように、そのままにしておく必要があります。新しい Google Cloud 認証で SOAR にアクセスするには、[SOAR 設定] > [詳細] > [グループ マッピング] ページでメール ユーザー グループ マッピングを設定する必要があります。

   3. [追加] をクリックします。

      ユーザーがプラットフォームにログインするたびに、[SOAR 設定] > [組織] > [ユーザー管理] ページに自動的に追加されます。移行されたインスタンスはこれらのマッピングを保持し、SOAR へのユーザー アクセスを決定する際の基準として使用します。Google SecOps にアクセスするには、すべてのユーザーがこのページでマッピングされている必要があります。

オプション 2: Google Cloudで Workforce Identity 連携認証を構成する

このシナリオは、Microsoft Azure Active Directory、Okta、Ping Identity、AD FS などのサードパーティ IdP を使用してユーザー ID を管理する場合に適用されます。

1. Google Cloudで Workforce Identity 連携を設定する。すでに設定されている場合は、この手順をスキップできます。
2. SOAR の既存のユーザーがすべて、Workforce Identity 連携で設定された Workforce プールグループに含まれていることを確認します。

3. Workforce Identities のロール割り当て形式に従って、IAM で必要なロールを付与します。

   1. オンボーディング SME に、次の事前定義 IAM ロールをすべて割り当てます。

      • Chronicle API 管理者
      • Chronicle サービス管理者
      • Chronicle SOAR 管理者
      • プロジェクト IAM 管理者
      • Service Usage 管理者

   2. 既存のすべての SOAR ユーザーに、IAM で次のいずれかのロールを割り当てます。

      • Chronicle API 管理者
      • Chronicle API 編集者
      • Chronicle API 閲覧者
      • Chronicle API 制限付き閲覧者

4. SOAR へのアクセスが必要なすべての IdP グループをマッピングして、SOAR で認証設定を完了します。

   既存のユーザーが少なくとも 1 つの IdP グループにマッピングされていることを確認します。

   1. [SOAR 設定] > [詳細] > [グループ マッピング] に移動します。
   2. [add 追加] をクリックして、次の情報を入力します。
      • IdP / ユーザー グループ: IdP のグループ名を入力します。
      • 権限グループ: 権限グループを選択します。
      • SOC ロール: SOC ロールを選択します。
      • 環境: 環境（[すべての環境] など）を選択します。
   3. 権限グループ、SOC ロール、[すべての環境] の管理者権限を持つ管理者 IdP グループを追加していることを確認します。
   4. [External Authentication] ページに既存の IdP グループ マッピングがある場合は、既存の SOAR 認証をオーバーライドしないように、そのままにしておく必要があります。 新しい Google Cloud 認証で SOAR にアクセスするには、[設定] > [SOAR 設定] > [詳細] > [グループ マッピング] ページで IdP グループ マッピングを設定する必要があります。
   5. [追加] をクリックします。ユーザーがプラットフォームにログインするたびに、[設定] > [組織] > [ユーザー管理] ページに自動的に追加されます。移行されたインスタンスはこれらのマッピングを保持し、SOAR へのユーザー アクセスを決定する際の基準として使用します。Google SecOps にアクセスするには、すべてのユーザーがこのページでマッピングされている必要があります。
   注: この手順は、統合に Workforce Identity 連携を使用している場合に適用されます。サービス アカウント トークン作成者の IAM ロールを Python サービス アカウント [e-mail] に付与している場合は、移行後に同じサービス アカウント トークン作成者の IAM ロールを新しい Python サービス アカウント [e-mail] に付与する必要があります。新しいサービス アカウントは、移行後にメールで送信されます。

すべてのお客様を対象としたステージ 2 の移行

重要: ステージ 2 の移行を開始する前に、ステージ 1 を完了する必要があります。

ステージ 2 の移行は、2026 年 1 月 26 日からすべてのお客様に一般提供されます。

IAM ロールへのステージ 2 の移行を完了する最終期限は 2026 年 11 月 30 日です。API の移行期限が 2027 年 3 月 31 日まで延長されました。

注: これらの手順は、Google SecOps SOAR スタンドアロンのお客様と Google SecOps のお客様の両方に適用されます。

SOAR 権限グループを Google Cloud IAM に移行する

Google Cloudの移行スクリプトをワンクリックして、SOAR 権限グループと権限を IAM に移行します。このスクリプトは、権限グループごとに新しいカスタムロールを作成し、Cloud Identity のお客様の場合はユーザーに、Workforce Identity 連携のお客様の場合は IdP グループに割り当てます。Terraform を使用して SOAR 権限を移行することもできます。

移行スクリプトと Terraform コマンドの詳細については、SOAR 権限を Google Cloud IAM に移行するをご覧ください。

権限の設定方法の詳細については、機能アクセスを構成するをご覧ください。

権限の移行後、次のようになります。

• [SOAR 設定] > [組織] > [権限] ページは、2027 年 3 月 31 日まで引き続き利用できます（以前の API との下位互換性のため）。このページは変更しないでください。権限はすべて IAM で管理されます。
• [Group Mapping] ページの [Permission Group] 列は、以前の SOAR API との下位互換性のために表示されます。これらの割り当ては削除しないでください。この列は 2027 年 3 月 31 日までに自動的に削除されます。お客様への影響はありません。
• [権限] ページの制限付きアクション セクションが [グループ マッピング] ページに移動します。

注: 移行スクリプトが表示されない場合は、移行のステージ 1 が完了していない可能性があります。Google の担当者にお問い合わせください。

SOAR API を Chronicle API に移行する

API 呼び出しまたは統合を使用して SOAR API をプログラムで使用している場合は、Chronicle API の一部として利用可能な新しい SOAR v1 ベータ版エンドポイントに移行できます。

スクリプトと統合を更新して、SOAR API エンドポイントを対応する Chronicle API エンドポイントに置き換える必要があります。以前の SOAR API と API キーは 2027 年 3 月 31 日まで利用できます。それ以降は機能しなくなります。詳細については、エンドポイントを Chronicle API に移行するをご覧ください。

Webhook を移行する

2027 年 3 月 31 日までに、次の手順で SOAR Webhook を Chronicle API に移行する必要があります。

新しいリクエスト形式を使用して、以前の siemplify-soar.com ドメインを新しい googleapis.com ドメインに置き換えて、クライアント側の Webhook URL を更新します。以前の siemplify-soar.com ドメインは、2027 年 3 月 31 日まで引き続き機能します。

たとえば、https://xxxx.siemplify-soar.com/api/external/v1/webhooks/{webhook_id}?api_key=xxxx で定義された Webhook は、

を https://us-chronicle.googleapis.com/v1alpha/projects/{project_id}/locations/{location}/instances/{instance/{instance_id}/webhooks/{webhook_id}?api_key=xxxx に更新する必要があります。

Webhook の認証は変更されません。Webhook は、Webhook リンクとともに最初に作成された API キーを引き続き使用します。

リモート エージェント認証インフラストラクチャを移行する

次の手順では、リモート エージェントの認証インフラストラクチャを Google Cloud サービス アカウント認証に移行する方法について説明します。このプロセスでは、Remote Agent インスタンスまたはホストの移行や交換は必要ありません。

1. リモート エージェント用の API キーの代わりにサービス アカウントを作成します。
2. リモート エージェントのメジャー バージョンのアップグレードを実行します。

既存のリモート エージェントは 2026 年 11 月 30 日まで利用できますが、それ以降は機能しなくなります。詳細な手順については、リモート エージェントを Google Cloud に移行するをご覧ください。

SOAR 監査ログへの影響

IAM への権限の移行が完了すると、SOAR ログが Google Cloud で利用可能になります。2027 年 3 月 31 日までに従来の SOAR API に対して行われた呼び出しは、SOAR 監査ログで引き続きアクセスできます。Google SecOps のお客様は、Google SecOps SOAR ログを収集するをご覧ください。SOAR スタンドアロンのお客様については、SOAR のログを収集するをご覧ください。

移行後のその他の変更:

ライセンスの種類 ライセンスの種類は、IAM でユーザーに割り当てられた権限によって決まるようになりました。

ランディング ページ ランディング ページは、[権限] ページから [ユーザー設定] メニューに移動します。このメニューには、アバターからアクセスできます。

次のステップ

• SOAR 移行の事前検証ガイド
• MSSP の SOAR スタンドアロン インスタンスを移行する
• SOAR エンドポイントを Chronicle API に移行する
• リモート エージェントの認証インフラストラクチャを移行する
• SOAR 権限を Google Cloud IAM に移行する
• よくある質問

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