SOAR エンドポイントを Chronicle API に移行する

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

このドキュメントでは、非推奨の SOAR API サーフェスから統合された Chronicle API に移行する手順と考慮事項について説明します。このガイドは、移行をスムーズかつ効率的に行い、中断を最小限に抑え、新機能を活用できるようにすることを目的としています。

Chronicle API サーフェスには、開発プロセスを効率化するために設計されたいくつかの改善が導入されています。また、旧 API に存在する制限事項や複雑さにも対応しています。

前提条件

SOAR API の移行を行う前に、次の操作を行う必要があります。

主な変更点と機能強化

次の表に、古い API サーフェスと新しい API サーフェスの主な違いを示します。

機能領域 以前の API 新しい API 詳細
認証 API トークン OAuth 2.0 新しい認証方法により、セキュリティが強化され、プロセスが標準化されます。
データモデル フラット構造 リソース指向の設計 この新しい設計により、データの整合性が向上し、オブジェクトの操作が簡素化されます。
エンドポイントの命名 一貫性がない RESTful で標準化されている 一貫した命名により、API がより直感的になり、統合が容易になります。

サポート終了スケジュール

SOAR の古い API サーフェスは、2026 年 6 月 30 日に完全にサポート終了となる予定です。サービスの中断を避けるため、この日までに移行を完了することをおすすめします。

移行手順

このセクションでは、アプリケーションを Chronicle API に正常に移行する手順について説明します。

ドキュメントを確認する

Chronicle API リファレンス ガイドなど、新しい API の包括的なドキュメントを確認します。

エンドポイントを新しい API サーフェスにマッピングする

アプリケーションが行う古い API 呼び出しごとに、対応する新しいエンドポイントを特定します。同様に、構造的な変更や新しいフィールドを考慮して、古いデータモデルを新しいデータモデルにマッピングします。詳細については、API エンドポイント マッピング テーブルをご覧ください。

省略可: ステージング統合を作成する

カスタム統合または商用統合のコンポーネントを編集する場合は、まず変更をステージング統合に push することをおすすめします。このプロセスにより、本番環境の自動化フローに影響を与えることなくテストできます。SOAR API を使用するカスタムビルド アプリケーションを移行する場合は、次の手順に進んでください。統合のステージングの詳細については、ステージング モードで統合をテストするをご覧ください。

サービス エンドポイントと URL を更新する

サービス エンドポイントは、API サービスのネットワーク アドレスを指定するベース URL です。1 つのサービスに複数のサービス エンドポイントを設定できます。Chronicle はリージョン サービスであり、リージョン エンドポイントのみをサポートします。

すべての新しいエンドポイントは一貫した接頭辞を使用するため、最終的なエンドポイント アドレスを予測できます。次の例は、新しいエンドポイント URL の構造を示しています。

[api_version]/projects/[project_id]/locations/[location]/instances[instance_id]/...

この構造により、エンドポイントの最終アドレスは次のようになります。

https://[service_endpoint]/[api_version]/projects/[project_id]/locations/[location]/instances/[instance_id]/...

ここで

  • service_endpoint: リージョン サービス アドレス
  • api_version: クエリする API のバージョン。v1alpha、v1beta、v1 のいずれかです。
  • project_id: プロジェクト ID（IAM 権限で定義したプロジェクトと同じ）
  • location: プロジェクトのロケーション（リージョン）。リージョン エンドポイントと同じ
  • instance_id: Google Security Operations SIEM のお客様 ID。

リージョン アドレス:

  • africa-south1: https://chronicle.africa-south1.rep.googleapis.com

  • asia-northeast1: https://chronicle.asia-northeast1.rep.googleapis.com

  • asia-south1: https://chronicle.asia-south1.rep.googleapis.com

  • asia-southeast1: https://chronicle.asia-southeast1.rep.googleapis.com

  • asia-southeast2: https://chronicle.asia-southeast2.rep.googleapis.com

  • australia-southeast1: https://chronicle.australia-southeast1.rep.googleapis.com

  • europe-west12: https://chronicle.europe-west12.rep.googleapis.com

  • europe-west2: https://chronicle.europe-west2.rep.googleapis.com

  • europe-west3: https://chronicle.europe-west3.rep.googleapis.com

  • europe-west6: https://chronicle.europe-west6.rep.googleapis.com

  • europe-west9: https://chronicle.europe-west9.rep.googleapis.com

  • me-central1: https://chronicle.me-central1.rep.googleapis.com

  • me-central2: https://chronicle.me-central2.rep.googleapis.com

  • me-west1: https://chronicle.me-west1.rep.googleapis.com

  • northamerica-northeast2: https://chronicle.northamerica-northeast2.rep.googleapis.com

  • southamerica-east1: https://chronicle.southamerica-east1.rep.googleapis.com

  • us: https://chronicle.us.rep.googleapis.com

  • eu: https://chronicle.eu.rep.googleapis.com

たとえば、米国のプロジェクトのすべてのケースのリストを取得するには:

GET 
  https://chronicle.us.rep.googleapis.com/v1alpha/projects/my-project-name-or-id/locations/us/instances/408bfb7b-5746-4a50-885a-50a323023529/cases

認証方法を更新する

新しい API は、認証に Google Cloud IAM を使用します。この新しい認証フローを実装するには、アプリケーションまたはレスポンス統合を更新する必要があります。スクリプトを実行するユーザーが、アクセスしようとしているエンドポイントに対する適切な権限を持っていることを確認します。

API ロジックを更新する

API リファレンスで提供されている新しいデータモデルとエンドポイント構造を分析します。すべてのメソッドが大幅に変更されたわけではなく、既存のコードの一部は再利用できます。主な目的は、新しいリファレンス ドキュメントを確認し、特定のユースケースごとに、アプリケーションのロジック内のフィールド名とデータ構造に必要な変更を特定して実装することです。

インテグレーションをテストする

更新したアプリケーションをステージング統合でテストしてから、本番環境にデプロイします。

  1. テスト計画を作成する: 移行されたすべての機能をカバーするテストケースを定義します。
  2. テストの実行: 自動テストと手動テストを実行して、精度と有効性を確認します。
  3. パフォーマンスをモニタリングする: 新しい API を使用してアプリケーションのパフォーマンスを評価します。

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