運用ワークフローに直接対応するように、ドキュメントのナビゲーション構造を再編成しました。詳しくは、リリースノートとチュートリアル動画をご覧ください。

Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

フィード UI を使用する

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

Google SecOps SIEM

このドキュメントでは、フィード管理 UI でフィードを作成、トラブルシューティング、管理する方法について説明します。フィードの変更、有効化、削除の手順も含まれています。

始める前に

各データフィードには、Google Security Operations で設定する前に満たす必要のある特定の前提条件があります。フィードの要件を確認するには、ソースタイプ別の構成で特定のデータソースを検索してください。

サポートされている圧縮形式とファイルサイズ

フィードの取り込みでサポートされている圧縮形式には、.gz、.tar.gz、.tar、solr.gz があります。次の表に、Google SecOps フィード変換がサポートするさまざまなファイルサイズを示します。

オペレーション	入力タイプ	推奨されるサイズ	予定の長さ	最大サイズ
データモデリング	CSV	5 GB 未満	7 分未満	10 GB
データモデリング	CSV	5 GB 未満	約 30 分	10 GB
データモデリング	CSV	未定	未定	2 GB
データモデリング	XML / JSON	1 GB 未満	< 10 分	2 GB
データモデリング	XLS / XLSX	50 MB 未満	約 1 分	50 MB
ファイルを統合する	任意	1 GB 未満	ファイル数によって異なります	100 GB
ファイルを解凍する	Non-ZIP	5 GB 未満	ファイル数によって異なります	10 GB（非圧縮）
ファイルを解凍する	ZIP	-	ファイル数によって異なります	4 GB（非圧縮）

ログ行の上限と区切り文字

テキストベースのログ（JSON、CSV、Syslog）を取り込む場合は、データが次の特定の取り込み上限に準拠していることを確認してください。

最大行サイズ: 単一のログ行は 4 MB を超えることはできません。1 行がこの上限を超えると、フィードはエラー MaxLogLineSize4MBExceeded で失敗します。
サポートされている区切り文字: 改行（\n）と復帰 + 改行（\r\n）の両方がサポートされています。

リンクされた Cloud プロジェクトの変更がデータフィードに与える影響

Google SecOps インスタンスに関連付けられている Google Cloud プロジェクトを更新すると、次のコネクタを使用してデータを取り込むすべてのフィードが停止し、手動で再作成する必要があります。

AMAZON_S3_V2
AMAZON_SQS_V2
GOOGLE_CLOUD_STORAGE_V2
AZURE_BLOBSTORE_V2
GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN

これらのコネクタを使用していない他のすべてのフィードでは、中断することなく取り込みが続行されます。お客様による対応は必要ありません。

移行中に行える操作

影響を受けるフィードでは、次の変更が確認されます。

フィードのステータス: 移行前に作成されたフィードは、ライブデータの取得を直ちに停止し、読み取り専用になります。
既存のデータ: 移行前に Google SecOps に転送されたデータは自動的に取り込まれ、データが失われることはありません。
エラーメッセージ: 古いフィードを編集または削除しようとすると、「This feed is read-only because this SecOps has now moved to a new Google Cloud Project (BYOP). To continue ingesting data from this source, please create a new feed」というメッセージが表示されます。

お客様に必要な対応

データの継続的な取り込みを確保するには、新しい環境でフィードを手動で再作成する必要があります。中断を最小限に抑えるには、次の手順に沿って操作します。

フィードを再作成する: 移行前に存在していたフィードを置き換えるには、新しいフィードを作成する必要があります。
最大ファイル経過時間を設定する: 新しいフィードを設定する際は、BYOP の更新が開始される約 2 時間前に [最大ファイル経過時間] を設定します。この時間バッファにより、スムーズな移行が保証されます。
重複データの管理: 選択したファイルの最大経過時間によっては、重複したデータ転送が発生する可能性があります。Google SecOps がこれらの冗長なログをフィルタリングする技術的な詳細については、重複除去を防止するをご覧ください。

注: これは、[転送後に削除] オプションが有効になっているフィードには適用されません。
既存のフィードを記録して削除する（移行前）: BYOP 移行を開始する前に、影響を受けるコネクタ（Amazon S3 V2 など）を使用する既存のすべてのフィードの構成設定を記録してから、フィードを削除します。移行前に作成したフィードを削除しないと、管理できなくなり、孤立した設定として Google SecOps ウェブインターフェースに残ります。

フィードを設定する方法

Google SecOps のお客様がプラットフォームでフィードを設定する方法は 2 つあります。環境に最適な方法を使用します。

[SIEM 設定] > [フィード]（標準）
Content Hub > Content Packs（プレミアム）

フィードを構成する

このセクションでは、標準の手順フローから始めて、フィードを全般的に設定する方法について説明します。[フィード] ページに一覧表示されるデータフィードには、ご自身が設定したフィードに加えて、Google がアカウントに設定したすべてのフィードが含まれます。

フィードを追加

Google SecOps アカウントにフィードを追加する手順は次のとおりです。

Google SecOps メニューで、[SIEM 設定] > [フィード] を選択します。
[Add New Feed] をクリックします。
次のページで、[単一のフィードを設定] をクリックします。注: この手順は、Google SecOps SIEM スタンドアロンプラットフォームを使用しているお客様には関係ありません。
フィード名を追加します。
[ソースタイプ] リストで、Google SecOps にデータをインポートするためのソースタイプを選択します。次のフィードソースタイプから選択できます。
- Amazon Data Firehose
- Amazon S3（非推奨）
- Amazon S3（V2）
- Amazon SQS（非推奨）
- Amazon SQS（V2）
- Azure Blob Storage（非推奨）
- Azure Blob Storage（V2）
- カスタム API
- Google Cloud Pub/Sub
- Cloud Storage（非推奨）
- Cloud Storage（V2）
- Cloud Storage イベントドリブン
- サードパーティ API
- Webhook
重要:
- Amazon S3（非推奨）、Amazon SQS（非推奨）、Azure Blob Storage（非推奨）、Cloud Storage（非推奨）のフィードを使用する場合は、有効なディレクトリパスがあることを確認してください。 Google Cloud
- Amazon SQS（非推奨）または Amazon SQS（V2）を使用する場合は、Amazon SQS キューからメッセージを削除する権限を Google SecOps に明示的に付与します。
- Amazon SQS（非推奨）フィードを使用する場合は、キューからメッセージを消費するフィードが 1 つだけであることを確認してください。別のアプリやフィードで読まれたメッセージは、現在のフィードに取り込まれません。
- フィードのソースタイプとして Amazon SQS（非推奨）を使用できるのは、Amazon S3 バケット内のログに限られます。
[ログタイプ] リストで、取り込むログに対応するログタイプを選択します。使用可能なログは、前に選択したソースタイプによって異なります。

注: AWS CLOUDTRAIL ログタイプの場合、ログが JSON 形式で、ファイル名が JSON ファイル（圧縮されていない）または JSON GZipped ファイル（圧縮されている）であることを確認します。
ソースタイプとして Cloud Storage を選択した場合は、サービスアカウントを取得オプションを使用して、一意のサービスアカウントを取得します。Google Cloud Storage フィードの設定例をご覧ください。
[次へ] をクリックします。
[入力パラメータ] タブで必要なパラメータを指定します。ここに表示されるオプションは、[Set Properties] タブで選択したソースとログのタイプによって異なります。各フィールドの質問アイコンの上にポインタを置くと、提供する必要がある内容に関する追加情報が表示されます。
省略可: [プロパティを設定] タブで名前空間を指定できます。名前空間の詳細については、アセットの名前空間の使用をご覧ください。
[次へ] をクリックします。
[Finalize] タブで新しいフィードの設定を確認します。
[送信] をクリックします。Google SecOps が新しいフィードの検証チェックを完了します。フィードがチェックに合格すると、フィードの名前が生成されて Google SecOps に送信され、Google SecOps でデータの取得が開始されます。

プロダクトファミリーに複数のフィードを構成する（Google SecOps のお客様のみ）

ログタイプに基づいて、プロダクトファミリーごとに複数のフィードを構成できます。

ベースラインログタイプ: 推奨としてマークされています。これらのログタイプは、コアプラットフォーム機能に推奨されます。
補足ログタイプ: 省略可としてマークされます。これらのログタイプは、追加のコンテキストを提供します。

設定を簡素化するため、プラットフォームでは、各構成に固有の設定手順と事前定義済みのパラメータが用意されています。たとえば、CrowdStrike Falcon の場合、[推奨] と [オプション] の両方のログタイプで複数の一意のフィードを作成して、包括的なデータ範囲を確保できます。

CrowdStrike EDR のフィードを構成する

CrowdStrike EDR のログフィードを構成する手順は次のとおりです。

[設定> フィード] で、[新しいフィードを追加] をクリックします。
1. [CrowdStrike Falcon] プロダクトをクリックします。
2. [CrowdStrike EDR] ログタイプを選択します。
または、[Content Hub > Content Packs] で、[CrowdStrike Falcon] プロダクトをクリックします。
1. [利用開始] をクリックします。
2. [CrowdStrike EDR] ログタイプを選択します。

次のフィールドに値を指定します。

フィールド	説明
`Source Type`	Amazon SQS
`Region`	URI に関連付けられている AWS S3 リージョン。
`Queue Name`	読み取り元の SQS キュー名。
`Account Number`	SQS アカウント番号。
`Source Deletion Option`	転送後にファイルとディレクトリを削除するかどうかを示します。
`Queue Access Key ID`	アカウントの 20 文字の英数字のアクセスキー（`AKIAOSFOODNN7EXAMPLE` など）。
`Queue Secret Access Key`	アカウントの 40 文字の英数字のシークレットアクセスキー（例: `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`）。

省略可: 次のパラメータを構成します。
- Feed Name: フィードの一意の名前が事前入力されています。
- アセットの Namespace: フィードに関連付けられた Namespace。
- 取り込みラベル: このフィードのイベントに適用されるラベル。
[フィードを作成] をクリックします。

このプロセスを繰り返して、同じログタイプの追加のフィードを作成できます。このページから、他の利用可能なログタイプのフィードを直接構成することもできます。完了したら、[フィード管理] ページに移動して、構成されたすべてのログタイプの詳細な概要を表示します。

IP 許可リスト

許可リストを有効にして、サードパーティ API からデータを取り込むすべてのログタイプに Google IP アドレス範囲を追加します。

ソースファイルを削除する

ソース削除オプションを使用すると、転送が完了した後に、ストレージからフィードソースオブジェクト（ファイルとフォルダ）を削除できます。このオプションは、Cloud Storage などの一部のフィードソースタイプでのみ使用できます。これらのフィードソースタイプの [新しく追加] ワークフローと [フィードを編集] ワークフローに [ソースの削除オプション] フィールドがあります。

ソース削除オプション

Cloud Storage などの、サポートされているフィードソースタイプの場合、[ソースの削除オプション] フィールドには次のオプションがあります。
- ファイルを削除しない
- 転送されたファイルと空のディレクトリを削除する
- 転送されたファイルを削除する
Microsoft Azure Blob Storage（AZURE_BLOBSTORE）は、ソースファイルの削除をサポートしていません。[SOURCE DELETION OPTION] フィールドで、[Never delete files] オプションのみを選択します。
次のフィードソース（"feedSourceType"）: GOOGLE_CLOUD_STORAGE_V2、GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN、AMAZON_S3_V2、AMAZON_SQS_V2、AZURE_BLOBSTORE_V2 の場合、[SOURCE DELETION OPTION]（ソース削除オプション）フィールドには次の 2 つのオプションがあります。
- NEVER: 転送後にファイルを削除しません。
- ON_SUCCESS: 転送後にすべてのファイルと空のディレクトリを削除します。

ソース固有の設定と権限

ソースタイプごとに、Google SecOps と通信するための特定の認証とネットワーキングの構成が必要です。このセクションでは、権限を構成してサービスアカウントを設定する方法について説明します。ここで説明する設定は、Cloud Storage の取り込み（プルベース）、マルチクラウドの取り込み（クロスクラウドプル）、プッシュベースの取り込み（API またはリアルタイム）に重点を置いています。

Google Cloud Storage フィードの設定例

Google SecOps メニューから [設定] を選択し、[フィード] をクリックします。
[Add New Feed] をクリックします。
次のページで、[単一のフィードを設定] をクリックします。Google SecOps SIEM スタンドアロンプラットフォームを使用している場合、この手順は適用されません。
[ソースタイプ] で [Cloud Storage v2] を選択します。
[ログタイプ] を選択します。たとえば、Google Kubernetes Engine 監査ログのフィードを作成するには、[ログタイプ] として [Google Kubernetes Engine 監査ログ] を選択します。
[サービスアカウントを取得する] をクリックします。Google SecOps は、Google SecOps がデータの取り込みに使用する一意のサービスアカウントを提供します。または、API を使用してこのサービスアカウントをプログラムで取得することもできます。取得サービスアカウントをご覧ください。
省略可: サービスアカウントを構成します。詳細については、Google SecOps サービスアカウントにアクセス権を付与するをご覧ください。
[次へ] をクリックします。
作成した Cloud Storage 構成に基づいて、次のフィールドの値を指定します。
- ストレージバケット URI
  
  注: ワイルドカードを使用して、ディレクトリ名全体を照合します。たとえば、gs://cs-myprod/*/more-data は有効です（* は単一のディレクトリレベルの名前全体を置き換えます）。
  注: Cloud Storage イベントドリブンフィードタイプの場合は、Pub/Sub を構成するで説明されているように、Cloud Storage の Pub/Sub サブスクリプションを設定します。
- ソース削除オプション
Cloud Storage バケットの設定方法については、バケットの作成をご覧ください。

注: Cloud Storage バケットフィードは、空のフォルダ名では機能しません。
[次へ] をクリックしてから、[送信] をクリックします。

Google SecOps サービスアカウントへのアクセス権を付与する

Google Cloud コンソールで Cloud Storage の [バケット] ページに移動します。
[バケット] に移動
サービスアカウントに、関連する Cloud Storage オブジェクトへのアクセス権を付与します。
- 特定のファイルに読み取り権限を付与するには、次の操作を行います。
  1. ファイルを選択して [アクセス権の編集] をクリックします。
  2. [プリンシパルを追加] をクリックします。
  3. [新しいプリンシパル] フィールドに、Google SecOps サービスアカウントの名前を入力します。
  4. 読み取り権限を含むロールを Google SecOps サービスアカウントに割り当てます。たとえば、Storage オブジェクト閲覧者（roles/storage.objectViewer）。これは、均一なバケットレベルのアクセス権が有効になっていない場合にのみ実行できます。
  5. [保存] をクリックします。
- 複数のファイルへの読み取り権限を付与するには、次のようにバケットレベルでアクセス権を付与します。
  - "feedSourceType": "GOOGLE_CLOUD_STORAGE":
    1. Google SecOps サービスアカウントをプリンシパルとしてストレージバケットに追加し、IAM ストレージオブジェクト閲覧者（roles/storage.objectViewer）ロールを付与します。
    2. ソースファイルを削除するようにフィードを構成する場合、Google SecOps サービスアカウントをプリンシパルとしてバケットに追加し、IAM ストレージオブジェクト管理者（roles/storage.objectAdmin）のロールを付与する必要があります。
  - "feedSourceType": "GOOGLE_CLOUD_STORAGE_V2" に次のロールを付与します。
    1. このロールを付与します。
      - Storage オブジェクト閲覧者（roles/storage.objectViewer）。別の Cloud Storage バケットに転送される場合。
    2. [ソース削除オプション] で選択した内容に応じて、次のいずれかのロールを付与します。[成功時] を選択した場合は、Storage レガシーバケット書き込みロールを付与します。[なし] を選択した場合は、Storage レガシーバケット読み取りロールを付与します。
      - ストレージのレガシーバケット書き込み（roles/storage.legacyBucketWriter）: オブジェクト削除権限が必要な場合。
      - Storage レガシーバケット読み取り（roles/storage.legacyBucketReader）: オブジェクト削除権限が必要ない場合。
  - "feedSourceType": "GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN":
    1. 次のいずれかのロールを付与します。
      - Storage オブジェクト閲覧者（roles/storage.objectViewer）。別の Cloud Storage バケットに転送される場合。
      - Storage オブジェクト作成者（roles/storage.objectCreator）: ファイルシステムに転送される場合。
    2. 次のいずれかのロールを付与します。
      - ストレージのレガシーバケット書き込み（roles/storage.legacyBucketWriter）: オブジェクト削除権限が必要な場合。
      - Storage レガシーバケット読み取り（roles/storage.legacyBucketReader）: オブジェクト削除権限が必要ない場合。

Amazon S3 と Azure Storage の STS アクセスを有効にする

STS は、次の Google Cloud Storage フィードで使用され、Amazon S3 と Azure Storage のブロブストアから Google SecOps にデータを転送します。

Amazon S3（V2）
Amazon SQS（V2）
Azure Blob Storage（V2）

STS は、定義された STS IP アドレス範囲のセットから Amazon S3 と Azure ストレージサービスにデータ転送リクエストを送信します。これらの STS IP アドレス範囲は、次の JSON ファイルで公開されています。 IP 範囲

これらの STS フィードソースタイプを使用するには、STS が Amazon S3 と Azure ストレージサービスにアクセスできるように、IP アクセス制限を調整する必要がある場合があります。

JSON ファイルから最新の IP 範囲を pull します。

セキュリティ構成を最新の状態に保つため、少なくとも週に 1 回、この JSON ファイルからデータを読み取ることをおすすめします。ファイルに新しい範囲が追加された場合、STS からのリクエストに対してその範囲が使用されるまでに少なくとも 7 日間はかかります。

JSON ファイルから IP 範囲を取得する Python スクリプトの例については、デフォルトドメインの IP アドレスをご覧ください。
現在の IP 範囲 creationTime を、前の JSON ファイルから読み取った IP 範囲 creationTime と比較します。異なる場合は、Amazon S3 と Azure Storage の Blobstore で IP アクセス制限を更新します。
- Amazon S3 の場合
  
  Amazon S3 blobstore の IP アクセス制限を更新するには:
  
  AWS プロジェクトでストレージへのアクセスに IP 制限を使用する場合は、STS ワーカーで使用される IP 範囲を許可 IP リストに追加する必要があります。
  
  注: エージェントレス転送ではなくエージェントを使用している場合は、エージェントマシンの IP アドレスを許可リストに追加します。
  これらの範囲を許可された IP として追加するには、AWS S3 のドキュメントの特定の IP アドレスに基づいてアクセスを管理するで説明されているように、bucket policy で Condition フィールドを使用します。
- Azure Storage の場合
  
  Azure Storage blobstore の IP アクセス制限を更新するには:
  
  Azure Storage ファイアウォールを使用して Azure リソースへのアクセスを制限する場合は、STS ワーカーで使用される IP 範囲を、許可された IP のリストに追加する必要があります。
  
  これらの範囲を許可された IP として追加するには、Azure Storage ファイアウォールと仮想ネットワークを構成するの手順に沿って操作します。

Pub/Sub push フィードを設定する

Pub/Sub push フィードを設定する手順は次のとおりです。

Pub/Sub push フィードを作成します。
Pub/Sub サブスクリプションでエンドポイント URL を指定します。

Pub/Sub push フィードを作成する

Google SecOps メニューで、[設定] を選択し、[フィード] をクリックします。
[新しく追加] をクリックします。
[フィード名] フィールドに、フィードの名前を入力します。
[ソースタイプ] リストで [Google Cloud Pub/Sub Push] を選択します。
[ログタイプ] を選択します。たとえば、Open Cybersecurity Schema Framework のフィードを作成するには、[ログタイプ] として [Open Cybersecurity Schema Framework（OCSF）] を選択します。
[次へ] をクリックします。
省略可: 次の入力パラメータの値を指定します。
- Split delimiter: ログ行を区切るために使用される区切り文字。\n のみを使用できます。
- Asset namespace: アセットの名前空間。
- Ingestion labels: このフィードのイベントに適用されるラベル。
[次へ] をクリックします。
[Finalize] 画面で新しいフィードの設定を確認し、[送信] をクリックします。
[詳細] タブで、[エンドポイント情報] フィールドから、フィードのエンドポイント URL をコピーします。このエンドポイント URL は、Pub/Sub で push サブスクリプションを作成するために必要です。
省略可: [フィードを有効にする] の切り替えボタンをクリックして、フィードを無効にします。フィードはデフォルトで有効になっています。
[完了] をクリックします。

エンドポイント URL を指定する

Pub/Sub push フィードを作成したら、次のようにエンドポイント URL を指定します。

Pub/Sub で push サブスクリプションを作成します。push サブスクリプションの作成方法の詳細については、push サブスクリプションを作成するをご覧ください。
エンドポイント URL を指定します。この URL は Google Cloud Pub/Sub push フィードの中にあります。
[認証を有効にする] を選択し、サービスアカウントを選択します。
[ペイロードのアンラッピングを push] と [ペイロードのアンラッピングの書き込みメッセージメタデータを push] の両方のオプションを無効にします。

Amazon Data Firehose フィードを設定する

Amazon Data Firehose フィードを設定する手順は次のとおりです。

Amazon Data Firehose フィードを作成し、エンドポイント URL と秘密鍵をコピーします。
Google SecOps に対する認証のための API キーを作成します。既存の API キーを再利用して Google SecOps に対する認証を行うこともできます。
Amazon Data Firehose でエンドポイント URL を指定します。

Amazon Data Firehose フィードを作成する

Google SecOps メニューで、[設定] を選択し、[フィード] をクリックします。
[新しく追加] をクリックします。
[フィード名] フィールドに、フィードの名前を入力します。
[ソースタイプ] リストで、[Amazon Data Firehose] を選択します。
[ログタイプ] を選択します。たとえば、Open Cybersecurity Schema Framework のフィードを作成するには、[ログタイプ] として [Open Cybersecurity Schema Framework（OCSF）] を選択します。
[次へ] をクリックします。
省略可: 次の入力パラメータの値を指定します。
- Split delimiter: ログ行を区切るために使用される区切り文字。\n のみを使用できます。
- Asset namespace: アセットの名前空間。
- Ingestion labels: このフィードのイベントに適用されるラベル。
[次へ] をクリックします。
[Finalize] 画面で新しいフィードの設定を確認し、[送信] をクリックします。
[秘密鍵を生成する] をクリックして、このフィードを認証するためのシークレットキーを生成します。
このシークレットは再び表示できないため、秘密鍵をコピーして保存します。新しいシークレットキーを再度生成できますが、シークレットキーを再生成すると、以前のシークレットキーは無効になります。
[詳細] タブで、[エンドポイント情報] フィールドから、フィードのエンドポイント URL をコピーします。このエンドポイント URL は、Amazon Data Firehose で配信ストリームの宛先設定を指定するときに必要になります。
省略可: [フィードを有効にする] の切り替えボタンをクリックして、フィードを無効にします。フィードはデフォルトで有効になっています。
[完了] をクリックします。

Amazon Data Firehose フィード用の API キーを作成する

Amazon Data Firehose フィードの API キーを作成する手順は次のとおりです。

Google Cloud コンソールの [認証情報] ページに移動します。
[認証情報を作成] をクリックし、[API キー] を選択します。
API キーへのアクセスを Chronicle API に限定します。

エンドポイント URL を指定する

Amazon Data Firehose で、次のように HTTPS エンドポイントとアクセスキーを指定します。

フィードエンドポイント URL に API キーを追加し、次の形式でこの URL を HTTP エンドポイント URL として指定します。
```
  ENDPOINT_URL?key=API_KEY
```
以下を置き換えます。
- ENDPOINT_URL: フィードエンドポイントの URL。
- API_KEY: Google SecOps に対する認証に使用する API キー。
アクセスキーには、Amazon Data Firehose フィードの作成時に取得した秘密鍵を指定します。

HTTPS Webhook フィードを設定する

始める前に:

Google SecOps のGoogle Cloud プロジェクトが構成され、そのプロジェクトで Chronicle API が有効になっていることを確認します。
Google SecOps インスタンスを Google Cloud サービスにリンクする。

注: リクエストサイズまたは QPS の上限の設定が低すぎると、Webhook フィード経由で送信されるデータのバッチで取り込みが遅れることがあります。HTTPS プッシュエンドポイントは、リクエストあたり最大 4 MB のリクエストサイズと、Google SecOps インスタンスあたり最大 15 K QPS のスループットをサポートしています。

HTTPS webhook フィードを設定する手順は次のとおりです。

HTTPS Webhook フィードを作成し、エンドポイント URL と秘密鍵をコピーします。
エンドポイント URL で指定された API キーを作成します。既存の API キーを再利用して Google SecOps に対する認証を行うこともできます。
アプリケーション内でエンドポイント URL を指定します。

1 つの Webhook リクエストで複数のイベントを送信する

次のコードサンプルは、curl --location 項目の後に複数の改行区切りの JSON オブジェクトを含む単一のリクエスト本文をフォーマットする方法を示しています。

--header 'Content-Type: application/json' \
--header 'X-goog-api-key: API_KEY' \
--header 'X-Webhook-Access-Key: SECRET' \
--data '{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}
{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}'

HTTPS Webhook フィードを作成する

Google SecOps メニューで、[設定] を選択し、[フィード] をクリックします。
[新しく追加] をクリックします。
[フィード名] フィールドに、フィードの名前を入力します。
[ソースタイプ] リストで、[Webhook] を選択します。
[ログタイプ] を選択します。たとえば、Open Cybersecurity Schema Framework のフィードを作成するには、[ログタイプ] として [Open Cybersecurity Schema Framework（OCSF）] を選択します。
[次へ] をクリックします。
省略可: 次の入力パラメータの値を指定します。
- Split delimiter: ログ行を区切るために使用される区切り文字。\n のみを使用できます。
- Asset namespace: アセットの名前空間。
- Ingestion labels: このフィードのイベントに適用されるラベル。
[次へ] をクリックします。
[Finalize] 画面で新しいフィードの設定を確認し、[送信] をクリックします。
[秘密鍵を生成する] をクリックして、このフィードを認証するためのシークレットキーを生成します。
このシークレットは再び表示できないため、秘密鍵をコピーして保存します。新しいシークレットキーを再度生成できますが、シークレットキーを再生成すると、以前のシークレットキーは無効になります。
[詳細] タブで、[エンドポイント情報] フィールドから、フィードのエンドポイント URL をコピーします。このエンドポイント URL をクライアントアプリケーション内で指定する必要があります。
省略可: [フィードを有効にする] の切り替えボタンをクリックして、フィードを無効にします。フィードはデフォルトで有効になっています。
[完了] をクリックします。

Webhook フィード用の API キーを作成する

Google Cloud コンソールの [認証情報] ページに移動します。
[認証情報を作成] をクリックして [API キー] を選択します。
API キーへのアクセスを Chronicle API に限定します。

エンドポイント URL を指定する

クライアントアプリケーション内で HTTPS エンドポイント（Webhook フィード内にあります）を指定します。
次の形式でカスタムヘッダーの一部として API キーと秘密鍵を指定して、認証を有効にします。

X-goog-api-key = API_KEY

X-Webhook-Access-Key = SECRET

API キーは URL 内で指定するのではなく、ヘッダーとして指定することをおすすめします。Webhook クライアントがカスタムヘッダーをサポートしていない場合は、次の形式のクエリパラメータを使用して API キーと秘密鍵を指定できます。
```
  ENDPOINT_URL?key=API_KEY&secret=SECRET
```
以下を置き換えます。
- ENDPOINT_URL: フィードエンドポイントの URL。
- API_KEY: Google SecOps に対する認証に使用する API キー。
- SECRET: フィードの認証用に生成した秘密鍵。

カスタム API フィードを設定する

Google Security Operations カスタム API フィード（コードレスコネクタとも呼ばれます）を使用すると、柔軟な構成ベースのモデルを使用して、サードパーティの REST API からテレメトリーを取り込むことができます。コンソールでエンドポイント、認証、ページネーション戦略、状態管理を直接定義して、データ取得を構成できます。

主なメリット

統合を加速する: バックエンドの更新を待つことなく、ガイド付きウィザードを使用して新しいテレメトリーソースを数分でオンボーディングします。
ステートフルチェックポイント: ポーリングサイクル全体でデータの重複やログの欠落がないことを確認します。
親子ファンアウト: リソースのリスト表示や関連するテレメトリーの取得など、2 階層の検出ワークフローをサポートします。
自動化された復元力とレート制限: ベンダーのスロットリングと割り当ての枯渇を防ぎます。信頼性の高い中断のない取り込みを実現するため、カスタム API フィードは、HTTP 429 レスポンスを指数バックオフで自動的に処理し、構成可能なレート制限とタスク遅延のずらしでリクエストを調整し、安全ガードレールを適用します。詳細については、レート制限とスロットリングのガードレールをご覧ください。

前提条件

カスタム API フィードを作成する前に、次の前提条件を確認してください。

権限: フィードを作成または変更するには、Chronicle API 管理者（roles/chronicle.admin）または Chronicle API 編集者（roles/chronicle.editor）のロールが必要です。
サードパーティ API の要件:
- 有効な API ベース URL（https:// を使用する必要があります）。
- API 認証情報（API キー、Basic 認証情報、OAuth 2.0 クライアント ID/シークレット）。
- エンドポイントパス、リクエストパラメータ、JSON レスポンス構造、レート制限の詳細を記載したベンダー API ドキュメント。
Secret Manager へのアクセス: 認証情報は Secret Manager 内で暗号化され、安全に管理されます。コネクタを実行するサービス ID は、Secret Manager（roles/secretmanager.secretAccessor と roles/secretmanager.admin）と自動的にやり取りします。

カスタム API フィードを設定する

カスタム API フィードを構成する手順は次のとおりです。

[SIEM Settings] > [Feeds] に移動します。
[新しいフィードを追加] をクリックします。
[単一フィードを設定] をクリックします。
[フィード名] フィールドに、一意のわかりやすい名前（1Password-Audit-Events など）を入力します。
[ソースタイプ] リストで、[カスタム API] を選択します。
[ログタイプ] リストで、ターゲットの Google SecOps ログタイプを選択します。
[次へ] をクリックします。
[全般設定] で、次のように構成します。
- ベース URL: プライマリホスト（https://events.1password.com など）を入力します。https:// で始まる必要があります。サブパスや末尾のスラッシュは追加しないでください。
- ポーリング頻度: プラットフォームが新しいテレメトリーについて API をチェックする頻度を分単位で指定します。サポートされる範囲: 5 ～ 2,880 分（デフォルト: 15 分）。標準 API（シーケンシャル）フィードの場合、10 ～ 15 分が標準です。リストと詳細（親子）フィードの場合、重複なしでファンアウトタスクを完全に実行できるように、30 ～ 60 分が推奨されます。
[認証] で、サポートされている認証方法のいずれかを選択し、必要なフィールドを構成します。
- Basic 認証: [ユーザー名]（API アカウント ID）と [シークレット]（シークレットパスワードまたはトークン）を入力します。
- OAuth 2.0 クライアント認証情報: OAuth 2.0 クライアント認証情報の権限付与フローを使用して認証します。Google SecOps は、取り込みサイクルの前にベアラーアクセストークンを自動的にリクエスト、キャッシュ保存、更新します。OAuth トークンエンドポイント（例: https://auth.vendor.com/oauth/token）、OAuth クライアント ID、OAuth クライアントシークレットを入力します。
- API キーリクエストヘッダー: リクエストヘッダーに挿入されたカスタム API キーを使用して認証します（最も一般的なエンタープライズ REST パターン）。ヘッダー名（Authorization、X-API-Key など）とヘッダー値（Bearer <SECRET_TOKEN>、<SECRET_KEY> など）を入力します。
- API キーのクエリパラメータ: URL クエリパラメータに挿入されたカスタム API キーを使用して認証します。[クエリパラメータ名]（例: api_key）と [クエリパラメータ値]（例: <SECRET_KEY>）を入力します。
注: ここで入力したすべての認証情報は、入力時に自動的にマスクされ、Secret Manager で安全に暗号化されます。顧客管理の暗号鍵（CMEK）のサポートはオプションです。
カスタム API が使用するコネクタモデルを選択します。
- 標準 API（シーケンシャル）: 各ポーリングが前のポーリングの状態に直接基づいて構築される線形ポーリングフロー。このモデルでは、次のポーリングで、前のポーリングから抽出されたカーソル、トークン、またはタイムスタンプを使用して、新しいデータのみを取得します。ベンダーがテレメトリーイベントレコードを直接返すエンドポイント（1Password、Okta、SentinelOne、GitHub、Slack など）を提供している場合は、このカードを選択します。
- リストと詳細（親子）: 2 段階の検出フロー。フィードは、リソースまたはオブジェクトのリスト（ユーザー ID やゾーンのリストなど）を取得するために、最初の呼び出し（親）を行います。フィードは、特定された各リソースの詳細なテレメトリーを取得するために、従属のフォローアップ呼び出し（子）を自動的に生成します。ベンダー API で 2 階層の検出パターンが必要な場合は、このカードを選択します。最初にエンドポイントを呼び出してエンティティ（ゾーン、アカウント、プロジェクト、デバイスなど）の動的リストを取得し、次にエンティティごとにフォローアップの詳細リクエストを実行してテレメトリー（Cloudflare、AWS CloudWatch、Tenable など）を取得します。
注: どちらのモデルもチェックポイントを使用します。これは、ポーリングから最も高いタイムスタンプまたは ID を抽出して保存し、ログの欠落や重複データの作成なしで次のサイクルで取り込みを再開する状態管理プロセスです。
[標準 API（シーケンシャル）] を選択した場合は、次の操作を行います。
1. [API エンドポイント] で、次のパラメータを構成して、リクエストの技術ルートとレートペーシングを定義します。
  - エンドポイントパス: ベース URL に追加される特定の API ルート（例: /api/v1/auditevents）。これにより、クエリする正確なテレメトリーリソースが定義されます。
  - HTTP メソッド: URL クエリパラメータを使用してデータを取得する場合は [GET] を選択し、検索ペイロードまたはフィルタ本文を送信する場合は [POST] を選択します。
2. リクエスト本文: POST リクエストの場合は、JSON データペイロードを指定します。{"limit": 100, "start_time": "{{.last_timestamp}}"} などの動的チェックポイント変数を埋め込むことができます。
3. 1 分あたりの最大リクエスト数: 1 分あたりに送信するリクエストの最大数を入力します。これは、ベンダー API のレート上限に準拠するためのクライアントサイドのレート制限です（デフォルト: 5 RPM = 12 秒ごとに 1 回のリクエスト）。この設定により、複数ページのページネーションで割り当てが枯渇するのを防ぐことができます。
4. 省略可: [カスタムヘッダー] で、[ヘッダー名] と [値] を構成し、[追加] をクリックして、ターゲット API で必要な特殊な HTTP ヘッダー（Content-Type: application/json, Accept: application/json など）を定義します。
5. 省略可: [クエリパラメータ] で、[キー] と [値] を構成し、[追加] をクリックして、URL クエリ文字列に追加される追加のフィルタまたはオプション（count=1000、status=active など）を指定するか、動的テンプレート変数（start={{.last_run_time}} など）をバインドします。
6. [ページネーション戦略:] で、サードパーティ API が複数ページの結果セットを処理するために必要なページングメカニズムを選択し、必要なフィールドを構成します。
  - なし: ページングなしで 1 回のリクエストでデータを取得します。
  - トークンページネーション: トークン（カスタムキー）を使用して次のページを取得します。[次のページトークンの JSON パス]（meta.next_cursor など）と [トークンページネーションのクエリパラメータ名]（cursor など）を入力します。
  - リンクのページネーション: 回答で提供された URL にアクセスして、より多くのデータを取得します。[次のページへのリンクの JSON パス]（links.next や @odata.nextLink など）を入力します。
  - オフセットページネーション: 次のセットを取得するために、一定数のレコードをスキップします。オフセットクエリパラメータ名（offset など）を入力します。
  - ページ番号のページネーション: 次の連番のページに移動します。ページ番号のクエリパラメータ名を入力します（例: page）。
7. [チェックポイント] で、コネクタが定期的なポーリングサイクルの間で中断した場所を記憶できるようにする設定を構成します。
  - 戦略: 次のいずれかの戦略を選択し、必要なフィールドを構成します。
    - なし: サイクル全体の進行状況をトラッキングせずに、利用可能なすべてのデータを取得します。
    - 最新のタイムスタンプ: 最新のレコードのタイムスタンプを追跡します。[チェックポイント値の JSON パス]（timestamp や event_time など）と [チェックポイント変数]（last_run_time など。後続のポーリングで {{.last_run_time}} として参照）を入力します。
    - 最新のレコード: 最新のレコード ID を追跡して、新しいレコードのみを取得します。チェックポイント値の JSON パス（id や event_id など）とチェックポイント変数（last_id など。{{.last_id}} として参照）を入力します。
    - イテレータトークン: API によって提供される永続的な継続トークンを使用します。[チェックポイント値の JSON パス] と [チェックポイント変数]（例: iterator_token、{{.iterator_token}} として参照）を入力します。
8. [レスポンスマッピング] で、プラットフォームにログの検索と抽出の方法を指示するルールを指定します。
  - ターゲットデータ JSON パス: ターゲットログエントリのリストがある API レスポンスペイロード内の正確なパスを入力します。オブジェクトでラップされた配列（{"items": [...]} など）の場合は、items と入力します。ルート JSON 配列を直接返す API（[{...}, {...}] など）の場合は、このフィールドを完全に空（[]）のままにします。
[リストと詳細（親子）] を選択した場合は、次の操作を行います。
1. 親リクエスト（検出）: アイテムのリストを返すエンドポイントを構成します。
  1. [API エンドポイント] で、次のパラメータを構成して、リクエストの技術ルートとレートペーシングを定義します。
    - エンドポイントパス: ベース URL に追加される特定の API ルート（例: /api/v1/auditevents）。これにより、クエリする正確なテレメトリーリソースが定義されます。
    - HTTP メソッド: URL クエリパラメータを使用してデータを取得する場合は [GET] を選択し、検索ペイロードまたはフィルタ本文を送信する場合は [POST] を選択します。
    - リクエスト本文: POST リクエストの場合は、JSON データペイロードを指定します。{"limit": 100, "start_time": "{{.last_timestamp}}"} などの動的チェックポイント変数を埋め込むことができます。
  2. 1 分あたりの最大リクエスト数: 1 分あたりに送信するリクエストの最大数を入力します。これは、ベンダー API のレート上限に準拠するためのクライアントサイドのレート制限です（デフォルト: 5 RPM = 12 秒ごとに 1 回のリクエスト）。この設定により、複数ページのページネーションで割り当てが枯渇するのを防ぐことができます。
  3. 省略可: [カスタムヘッダー] で、[ヘッダー名] と [値] を構成し、[追加] をクリックして、ターゲット API で必要な特殊な HTTP ヘッダー（Content-Type: application/json, Accept: application/json など）を定義します。
  4. 省略可: [クエリパラメータ] で、[キー] と [値] を構成し、[追加] をクリックして、URL クエリ文字列に追加される追加のフィルタまたはオプション（count=1000、status=active など）を指定するか、動的テンプレート変数（start={{.last_run_time}} など）をバインドします。
  5. [ページネーション戦略:] で、サードパーティ API が複数ページの結果セットを処理するために必要なページングメカニズムを選択し、必要なフィールドを構成します。
    - なし: ページングなしで 1 回のリクエストでデータを取得します。
    - トークンページネーション: トークン（カスタムキー）を使用して次のページを取得します。[次のページトークンの JSON パス]（meta.next_cursor など）と [トークンページネーションのクエリパラメータ名]（cursor など）を入力します。
    - リンクのページネーション: 回答で提供された URL にアクセスして、より多くのデータを取得します。[次のページへのリンクの JSON パス]（links.next や @odata.nextLink など）を入力します。
    - オフセットページネーション: 次のセットを取得するために、一定数のレコードをスキップします。オフセットクエリパラメータ名（offset など）を入力します。
    - ページ番号のページネーション: 次の連番のページに移動します。ページ番号のクエリパラメータ名を入力します（例: page）。
  6. [Checkpointing] で、定期的なポーリングサイクル間でコネクタが中断した場所を記憶できるようにする設定を構成します。
    - 戦略: 次のいずれかの戦略を選択し、必要なフィールドを構成します。
      - なし: サイクル全体の進行状況をトラッキングせずに、利用可能なすべてのデータを取得します。
      - 最新のタイムスタンプ: 最新のレコードのタイムスタンプを追跡します。[チェックポイント値の JSON パス]（timestamp や event_time など）と [チェックポイント変数]（last_run_time など。後続のポーリングで {{.last_run_time}} として参照）を入力します。
      - 最新のレコード: 最新のレコード ID を追跡して、新しいレコードのみを取得します。チェックポイント値の JSON パス（id や event_id など）とチェックポイント変数（last_id など。{{.last_id}} として参照）を入力します。
      - イテレータトークン: API によって提供される永続的な継続トークンを使用します。[チェックポイント値の JSON パス] と [チェックポイント変数]（例: iterator_token、{{.iterator_token}} として参照）を入力します。
2. データ抽出（ブリッジ）: 次のように構成します。
  - アイテム識別子の JSON パス: 個々のエンティティを一意に識別する親レスポンス内の特定のフィールド（id や zone_id など）。コネクタは、親配列内の各アイテムからこの識別子を抽出します。
  - テンプレート変数名: 抽出された ID を保持するカスタム変数名（zone_id など）を指定します。UI には、子リクエストで {{.zone_id}} を使用してくださいという動的バッジが表示されます。
3. 子リクエスト（詳細）: 各アイテムの詳細ログを返すエンドポイントを構成します。
  1. [API エンドポイント] で、次のパラメータを構成して、リクエストの技術ルートとレートペーシングを定義します。
    - エンドポイントパス: ベース URL に追加される特定の API ルート（例: /client/v4/zones/{{.zone_id}}/logs/received）。これにより、クエリする正確なテレメトリーリソースが定義されます。
    - HTTP メソッド: URL クエリパラメータを使用してデータを取得する場合は [GET] を選択し、検索ペイロードまたはフィルタ本文を送信する場合は [POST] を選択します。
    - リクエスト本文: POST リクエストの場合は、JSON データペイロードを指定します。{"limit": 100, "start_time": "{{.last_timestamp}}"} などの動的チェックポイント変数を埋め込むことができます。
  2. 1 分あたりの最大リクエスト数: 1 分あたりに送信するリクエストの最大数を入力します。これは、ベンダー API のレート上限に準拠するためのクライアントサイドのレート制限です（デフォルト: 5 RPM = 12 秒ごとに 1 回のリクエスト）。この設定により、複数ページのページネーションで割り当てが枯渇するのを防ぐことができます。
  3. 省略可: [カスタムヘッダー] で、[ヘッダー名] と [値] を構成し、[追加] をクリックして、ターゲット API で必要な特殊な HTTP ヘッダー（Content-Type: application/json, Accept: application/json など）を定義します。
  4. 省略可: [クエリパラメータ] で、[キー] と [値] を構成し、[追加] をクリックして、URL クエリ文字列に追加される追加のフィルタまたはオプション（count=1000、status=active など）を指定するか、動的テンプレート変数（start={{.last_run_time}} など）をバインドします。
  5. [ページネーション戦略:] で、サードパーティ API が複数ページの結果セットを処理するために必要なページングメカニズムを選択し、必要なフィールドを構成します。
    - なし: ページングなしで 1 回のリクエストでデータを取得します。
    - トークンページネーション: トークン（カスタムキー）を使用して次のページを取得します。[次のページトークンの JSON パス]（meta.next_cursor など）と [トークンページネーションのクエリパラメータ名]（cursor など）を入力します。
    - リンクのページネーション: 回答で提供された URL にアクセスして、より多くのデータを取得します。[次のページへのリンクの JSON パス]（links.next や @odata.nextLink など）を入力します。
    - オフセットページネーション: 次のセットを取得するために、一定数のレコードをスキップします。オフセットクエリパラメータ名（offset など）を入力します。
    - ページ番号のページネーション: 次の連番のページに移動します。ページ番号のクエリパラメータ名を入力します（例: page）。
  6. [Checkpointing] で、定期的なポーリングサイクル間でコネクタが中断した場所を記憶できるようにする設定を構成します。
    - 戦略: 次のいずれかの戦略を選択し、必要なフィールドを構成します。
      - なし: サイクル全体の進行状況をトラッキングせずに、利用可能なすべてのデータを取得します。
      - 最新のタイムスタンプ: 最新のレコードのタイムスタンプを追跡します。[チェックポイント値の JSON パス]（timestamp や event_time など）と [チェックポイント変数]（last_run_time など。後続のポーリングで {{.last_run_time}} として参照）を入力します。
[Scheduling & Labels] で次の設定を行います。
- ポーリング頻度: 標準間隔（5m、1h など）を選択します。
- Namespace: 組織タグ（省略可）。
- 取り込みラベル: データ RBAC の Key-Value ペア。
[送信] をクリックします。Google SecOps は、認証情報とエンドポイントの検証チェックを自動的に実行します。検証に成功すると、フィードのポーリングが開始されます。

構成例 1: 1Password 監査イベント（標準 API（シーケンシャル）モデル）

次の宣言型 JSON 構成は、1Password のカーソルベースのチェックポイントを使用した Standard API（Sequential）モデルを示しています。

{
  "base_url": "https://events.1password.com",
  "polling_frequency": 15,
  "header_auth": {
    "header_key_values": [
      {
        "key": "Authorization",
        "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
      }
    ]
  },
  "primary_request": {
    "request_settings": {
      "endpoint_path": "/api/v1/auditevents",
      "http_method": "POST",
      
      "request_body": "{\"limit\": 1000, \"start_time\": \"{{.last_run_time}}\"}",
      
      "custom_headers": [
        {
          "key": "Content-Type",
          "value": "application/json"
        }
      ],
      "max_requests_per_minute": 5
    },
    "pagination_strategy": {
      "token": {
        "next_page_token_json_path": "additional_items_url",
        "query_param": "cursor"
      }
    },
    "checkpointing": {
      "latest_timestamp_strategy": {
        "checkpoint_value_path": "timestamp",
        "checkpoint_variable": "last_run_time"
      }
    },
    "response_mapping": {
      "target_data_path": ["items"]
    }
  }
}

具体的なサンプル構成 2: Cloudflare ゾーンのテレメトリー（リストと詳細（親子）モデル）

次の宣言型 JSON 構成は、Cloudflare のリストと詳細（親-子）ファンアウトモデルを示しています。

{
 "base_url": "https://api.cloudflare.com",
 "polling_frequency": 30,
 "header_auth": {
   "header_key_values": [
     {
       "key": "Authorization",
       "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
     }
   ]
 },

 "primary_request": {
   "request_settings": {
     "endpoint_path": "/client/v4/zones",
     "http_method": "GET"
   },
   "response_mapping": {
     "target_data_path": ["result"]
   },
   "pagination_strategy": {
     "none": {}
   },
   "checkpointing": {
     "none_strategy": {}
   },
   "dependent_requests_config": {
     "item_id_json_path": "id",
     "item_id_variable": "zone_id",
     "dependent_requests": [
       {
         "request_settings": {
           "endpoint_path": "/client/v4/zones/{{.zone_id}}/logs/received",
           "http_method": "GET",
           "query_parameters": [
             {
               "key": "start",
               "value": "{{.last_run_time}}"
             },
             {
               "key": "count",
               "value": "1000"
             }
           ],
           "max_requests_per_minute": 5
         },

         "pagination_strategy": {
           "none": {}
         },
         "checkpointing": {
           "latest_timestamp_strategy": {
             "checkpoint_value_path": "EdgeStartTimestamp",
             "checkpoint_variable": "last_run_time"
           }
         },
         "response_mapping": {
           "target_data_path": []
         }
       }
     ]
   }
 }
}

カスタム API のベストプラクティス

ポーリング頻度に関するガイダンス:
- 適度なポーリング間隔から始める: 大量のエンドポイントの場合、ベンダー API の割り当て動作を観察してから 5 分に短縮するために、初期ポーリング間隔を 15 分または 30 分に設定します。
- 大量のファンアウト用に最適化する: 数十から数百のリソースを検出する親 / 子（リストと詳細）フィードの場合、次の検出サイクルが開始される前に、すべてのペース設定された子タスクが正常に完了するように、ポーリング頻度を 30 ～ 60 分に設定することを強くおすすめします。
取り込みパスを検証する: ベンダーのドキュメントまたは API テストツールを使用して、状態チェックポイントを構成する前に、タイムスタンプの正確な JSON フィールド名を確認します。
マルチチャイルド API を分解する: サードパーティ API で単一のユーザーリストのアラートと監査ログの両方を取得する必要がある場合は、最適な分離を維持するために、2 つの個別のシングルチャイルドフィード（アラート用と監査ログ用）を作成します。

レート制限とスロットリングのガードレール

お客様のフィード構成がサードパーティベンダーの割り当てを圧迫したり、システムリソースを独占したりすることを防ぐため、カスタム API フィードタイプには次の自動ガードレールが実装されています。

構成可能なリクエストペーシング（レート制限）: ベンダーのレート上限を超えないように、送信 HTTP リクエストが自動的にペーシングされます。デフォルトのペース設定レートは 1 分あたり 5 件のリクエスト（12 秒ごとに 1 件のリクエスト）です。ベンダーが公開している API 割り当てに合わせて、エンドポイント設定の [1 分あたりの最大リクエスト数] フィールドを使用して、エンドポイントごとにこの値を調整できます。
子リクエストの上限: 親子（リストと詳細）フィードの場合、検出リクエストはポーリングサイクルごとに最大 500 件の子リクエストをディスパッチできます。
単一レベルのファンアウトの深さ: コネクタは、最大ファンアウトの深さを 1 レベル（親の検出 → 子の詳細）に厳密に適用します。ネストされた依存リクエスト（孫呼び出し）は対象外です。
レスポンスペイロードサイズの上限: 1 回のリクエストまたは 1 ページで許容される HTTP レスポンスの最大サイズは 50 MB です。ページネーションされていない API が 50 MB を超えるレスポンスを返すと、リソース不足エラーでフェッチが失敗します。これを防ぐには、常にページネーションクエリパラメータ（limit や page_size など）を構成して、レコードを小さなバッチで取得します。
HTTP 429 の自動バックオフ: サードパーティベンダーの API が HTTP 429（リクエストが多すぎる）で応答した場合、Google SecOps はステータスを自動的にキャプチャし、指数バックオフ期間を開始して、ベンダーの割り当てウィンドウが補充されるまでタスクの実行を一時停止します。

カスタム API の制限事項

取り込みパスを計画する際は、カスタム API フィードタイプには次の制限があることに注意してください。

厳密な JSON サポート: JSON API レスポンスのみがサポートされます。XML、CSV、Parquet、Avro などの他の形式は対象外です。
動的リクエスト署名なし: リクエストごとに動的暗号署名を必要とする API は対象外です（AWS SigV4、Akamai、Oracle OCI など）。
多段階認証なし: ポーリングの前に、一時的なセッショントークンと認証情報を交換するための最初のプログラムによるログイン呼び出しを必要とする API（Saviynt など）はサポートされていません。
WebSocket または Push 取得なし: カスタム API フィードは、標準の HTTPS プルポーリングをサポートしています。永続的なストリーミング接続（WebSocket）と受信ウェブフックはサポートされていません。
相互 TLS（mTLS）なし: 認証は、API キー、基本認証、または標準の OAuth 2.0 クライアント認証情報に依存する必要があります。クライアントサイドの証明書ハンドシェイクは対象外です。

カスタム API フィードのトラブルシューティング

Cloud Logging のログエクスプローラでカスタム API フィードのエラーを調査するには、次のクエリを使用します。

resource.type="gce_instance" OR resource.type="generic_task"
jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"

FEED_ID は、フィード ID に置き換えます。

失敗した HTTP リクエストをフィルタするには、次のクエリを使用します。

jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"
jsonPayload.http_status_code >= 400

FEED_ID は、フィード ID に置き換えます。

一般的な障害モードと解決策

症状 / エラー	根本的な原因	解決策 / 救済策
HTTP 401 Unauthorized / HTTP 403 Forbidden	API キー、パスワード、OAuth 認証情報の有効期限が切れているか、無効である。	フィードを編集し、有効な認証情報を再入力して、[送信] をクリックします。
HTTP 404 Not Found	ベース URL またはエンドポイントパステンプレートが正しくありません。	ベンダー API ドキュメントでエンドポイントを調べます。ベース URL が正しく終了し、エンドポイントパスが / で始まっていることを確認します。
HTTP 429 リクエストが多すぎます	ベンダー API のレート上限を超えました。	ポーリング頻度を増やすか、クエリパラメータの `limit` パラメータを減らします。
JSON 抽出エラー（items_path が空）	レスポンス構成パスの不一致。	API レスポンスペイロードの構造を確認し、ターゲットデータの JSON パスを更新します。
重複したデータの取り込み	状態構成のタイムスタンプまたは ID 抽出パスが無効です。	ログレコードのフィールド名でタイムスタンプを確認し、抽出パスを更新します。

フィードを管理する

データフィードを構成したら、管理ツールを使用して取り込みの健全性をモニタリングし、既存のパラメータを変更して、フィードのライフサイクルを管理します。このセクションでは、フィードのステータスを解釈し、データの可視性を継続的に確保するために必要なメンテナンスタスクを行う方法について説明します。

[フィード] ページには、構成済みのフィードのリストを操作して整理するのに役立つツールがいくつか用意されています。

検索: 検索バーを使用して、フィード名、フィード ID、またはソースタイプでフィードを検索します。
フィルタ: フィルタアイコンをクリックすると、特定のフィード属性に基づいてリストを絞り込むことができます。
CSV をダウンロード: [CSV としてダウンロード] をクリックすると、現在のフィードのリストが CSV ファイルにエクスポートされます。
ページネーション: ページネーションコントロールを使用して、次の操作を行います。
- [1 ページあたりの行数] を変更します。
- ページタブと矢印を使用して、複数のページのフィードを移動します。
最終更新日時: タイムスタンプで、フィードリストが最後に更新された日時を確認できます。

設定済みのフィードを表示する

[フィード] ページには、設定したすべてのフィードが表示されます。

[SIEM 設定] > [フィード] に移動します。メインページには、構成済みのすべてのフィードが表示されます。
各行にポインタを合わせると、 more_vert （その他）メニューが表示されます。
メニューでは、フィードの詳細を表示したり、フィードを編集、無効化、削除したりできます。

フィードのステータスをモニタリングする

最初の [フィード] ページでフィードのステータスをモニタリングできます。フィードは次のステータスになることができます。

アクティブ: フィードが構成され、Google SecOps アカウントにデータを取り込む準備が整っています。
InProgress: Google SecOps は、構成済みのサードパーティからデータを pull しようとします。
完了: このフィードによってデータは正常に取得されました。
アーカイブ済み: 無効化されたフィード。
Failed: フィードでデータを正常に取得できません。構成の問題が原因と考えられます。質問をクリックすると、構成エラーが表示されます。エラーを修正し、フィードを再送信したら、[フィード] ページに戻って、現在、フィードが機能しているかどうかを確認します。

注: [フィード] ページの [前回の成功] 列には、そのフィードで最後にデータの取得に成功した時刻を示します。新しいフィードの場合、このフィールドは空白です。Webhook や Google Cloud pubsub などのプッシュフィードでは、この列は入力されません。これらのプッシュフィードにはスケジュールがありません。つまり、データはプッシュされたときに取り込まれます。Amazon SQS（V2）フィードの場合、[前回の成功] 列はアクティブな取り込みハートビートのタイムスタンプを表します。この列の更新はスロットリングされ、最大 15 分遅延する可能性があります。

既存のフィードを編集する

[フィード] ページで、次のように既存のフィードを編集できます。

既存のフィードにポインタを合わせ、右側の列にあるその他アイコン more_vert をクリックします。
[Edit Feed] をクリックします。これで、フィードの入力パラメータを変更し、Google SecOps に再送信できるようになりました。Google SecOps は更新されたフィードの使用を試行します。

注: 既存のフィードは、[フィード] ページでフィード名として [未構成] と表示されます。フィードを編集してフィード名を追加してください。

フィードを有効（再開）または無効（一時停止）にする

フィードを無効にすると、Google SecOps はそのソースからの新しいデータの取り込みを停止します。データの取り込みを直ちに停止するには、フィードを削除する必要があります。既存のアクティブな転送またはスロットルされた転送は、完了するまで継続されます。フィードを再度有効にすると、Google SecOps はフィードが無効になっている間に見逃したデータを取得できます。この機能を「バックフィル可能性」と呼びます。

[ステータス] 列で、有効なフィードには、[有効]、[進行中]、[完了]、または [失敗] のラベルが付けられます。無効なフィールドは [アーカイブ済み] のラベルが付けられます。説明については、フィードのステータスをモニタリングするをご覧ください。

[フィード] ページで、既存のフィードを有効（再開）または無効（一時停止）にできます。

既存のフィードにポインタを合わせ、右側の列にあるその他アイコン more_vert をクリックします。
省略可: [フィードを有効にする] 切り替えボタンをクリックして、フィードを有効にします。
省略可: [フィードを無効にする] の切り替えボタンをクリックして、フィードを無効にします。これで、フィードに [アーカイブ済み] というラベルが付けられました。

フィードを再度有効にした場合のデータ復元（バックフィル可能性）

Google SecOps がデータをバックフィルできるかどうかは、フィードがプルベース（サポートされている）かプッシュベース（対象外）かによって異なります。

プルベースのフィード

これらのフィードを使用して、Google SecOps は外部ソースからデータを取得します。プルフィードには次のものがあります。

Amazon S3、 Google Cloud Storage、Azure Blob Storage などのクラウドストレージバケット
SFTP サーバー
Microsoft 365、Okta、Proofpoint などのサードパーティ API

プルベースのフィードを再度有効にすると、Google SecOps はフィードが無効になっている間に生成されたデータを取得できます。

プッシュベースのフィード

これらのフィードを使用すると、外部システムから Google SecOps にデータが「プッシュ」されます。プッシュフィードには次のものがあります。

HTTPS Webhook
Google Cloud Pub/Sub
Amazon Kinesis Data Firehose
Bindplane などの直接 API/エージェント取り込み

Google SecOps は、プッシュベースのフィードからデータバックフィルを自動的に開始できません。フィードが無効になっている間にシステムがデータを push すると、Google SecOps は HTTP 403 Forbidden エラーまたは一般的な 4xx エラーを送信します。

システムがデータを保存して Google SecOps への送信を再試行しない場合、データは失われます。また、システムが「失敗時にドロップ」またはバッファのクリアに設定されている場合、データはそれぞれの期間にわたって完全に失われます。データ損失を防ぐため、フィードが再度有効になったらデータをバッファリングして再送信するようにシステムを構成する必要があります。フィードが再開されると、Google SecOps は欠落したデータを取り込むことができます。

バックフィルに関する考慮事項

ソースシステムの制限: Google SecOps がプルベースのフィードからバックフィルできる過去のデータ量は、ソースシステムがデータを保持する期間と、その API で許可される内容によって制限されます。たとえば、一部の API では過去 7 日間のデータにのみアクセスできます。
Google SecOps バッファ: 自動復元のため、Google SecOps のプルベースフィードの内部バッファには、データが最大 90 日間保持されます。その後、データは削除されます。
テナントの制限: コンセプト実証などの有料テナント以外のテナントでは、古いデータのバックフィルに制限がある場合があります。
データの取り込み割り当て: リアルタイムデータ取り込みへの影響を避けるため、バックフィルデータはライブデータよりも低い優先度で処理されます。プルベースのデータバックフィルもレート制限されます。通常、ログタイプごとにテナントのバースト上限の 3 分の 1（33%）に制限されます。これにより、EDR エージェントなどの重要なプッシュベースのフィードが悪影響を受けないようにします。
動的レート制限: バックフィルが使用可能なすべての pull 割り当てを消費すると、取り込みは 5 分間の残りの間一時停止し、間隔が再開すると自動的に再開します。
クラウドストレージ: フィード設定を使用して、新しいファイルや更新されたファイルのフィルタ、または「ファイルの最大経過日数」などの期間フィルタなど、バックフィルを制御できます。
大きなバックログ: プルベースのフィードの大きなバックログが原因で再有効化時に問題が発生する場合は、Google サポートにお問い合わせのうえ、バックログをクリアしてください。つまり、フィードは今後新しいデータのみを取り込み、欠落したデータはバックフィルされません。
無効なフィードの編集: フィードが無効になっている間にフィードに対して行われた構成の変更は、フィードが再度有効になるとすぐに適用されます。

フィードの削除

[フィード] ページから、任意の既存のフィードを削除することもできます。

既存のフィードにポインタを合わせ、右側の列にあるその他アイコン more_vert をクリックします。
[Delete Feed]（フィードを削除）をクリックします。[フィードの削除] ウィンドウが開きます。フィードを完全に削除するには、[はい、削除します] をクリックします。

注: フィードを削除すると、新しいデータは取り込まれなくなります。すでにキューに存在するデータは、この場合も処理されます。

カスタム API フィードの場合、[保留中のバックログデータを削除する] というチェックボックスが表示されたダイアログウィンドウが開きます。

オフ（デフォルト）: フィード構成と認証情報は削除されますが、キューに登録されたバックログデータは取り込みまで処理されます。
オンの場合: フィード構成、認証情報、保留中のバックログデータがすべて完全に削除されます。

取り込みレートを制御する

テナントのデータの取り込みレートが特定のしきい値に達すると、Google Security Operations は新しいデータフィードの取り込みレートを制限して、取り込みレートが高いソースが別のデータソースの取り込みレートに影響を与えないようにします。この場合、遅延は発生しますが、データが失われることはありません。しきい値は取り込み量とテナントの使用履歴によって決まります。

レート上限の引き上げをリクエストするには、Cloud カスタマーケアにお問い合わせください。

フィードの失敗に関するトラブルシューティング

[フィード] ページでは、次のように、既存のフィードのソースタイプ、ログタイプ、フィード ID、ステータスなどの詳細を確認できます。

既存のフィードにポインタを合わせ、右側の列にあるその他アイコン more_vert をクリックします。
[View Feed] をクリックします。フィードの詳細を示すダイアログが表示されます。失敗したフィードについては、[詳細] > [ステータス] でエラーの詳細を確認できます。

失敗したフィードについては、詳細にエラーの原因と修正手順が含まれます。

データフィードの操作中に発生する可能性のあるエラーメッセージについては、ソースと取り込みのエラーの表をご覧ください。

フィードアクティビティの詳細な分析とトラブルシューティングを行うには、Cloud Logging でログを表示します。Cloud Logging でフィードアクティビティを分析するをご覧ください。

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

フィード UI を使用する

始める前に

サポートされている圧縮形式とファイルサイズ

ログ行の上限と区切り文字

リンクされた Cloud プロジェクトの変更がデータフィードに与える影響

移行中に行える操作

お客様に必要な対応

フィードを設定する方法

フィードを構成する

フィードを追加

プロダクト ファミリーに複数のフィードを構成する（Google SecOps のお客様のみ）

CrowdStrike EDR のフィードを構成する

IP 許可リスト

ソースファイルを削除する

ソース削除オプション

ソース固有の設定と権限

Google Cloud Storage フィードの設定例

Google SecOps サービス アカウントへのアクセス権を付与する

Amazon S3 と Azure Storage の STS アクセスを有効にする

Pub/Sub push フィードを設定する

Pub/Sub push フィードを作成する

エンドポイント URL を指定する

Amazon Data Firehose フィードを設定する

Amazon Data Firehose フィードを作成する

Amazon Data Firehose フィード用の API キーを作成する

エンドポイント URL を指定する

HTTPS Webhook フィードを設定する

1 つの Webhook リクエストで複数のイベントを送信する

HTTPS Webhook フィードを作成する

Webhook フィード用の API キーを作成する

エンドポイント URL を指定する

カスタム API フィードを設定する

主なメリット

前提条件

カスタム API フィードを設定する

構成例 1: 1Password 監査イベント（標準 API（シーケンシャル）モデル）

具体的なサンプル構成 2: Cloudflare ゾーンのテレメトリー（リストと詳細（親子）モデル）

カスタム API のベスト プラクティス

レート制限とスロットリングのガードレール

カスタム API の制限事項

カスタム API フィードのトラブルシューティング

フィードを管理する

設定済みのフィードを表示する

フィードのステータスをモニタリングする

既存のフィードを編集する

フィードを有効（再開）または無効（一時停止）にする

フィードを再度有効にした場合のデータ復元（バックフィル可能性）

フィードの削除

取り込みレートを制御する

フィードの失敗に関するトラブルシューティング

プロダクトファミリーに複数のフィードを構成する（Google SecOps のお客様のみ）

Google SecOps サービスアカウントへのアクセス権を付与する

カスタム API のベストプラクティス