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
ファイルを解凍する	ZIP 以外	5 GB 未満	ファイル数によって異なる	10 GB（非圧縮）
ファイルを解凍する	ZIP	-	ファイル数によって異なる	4 GB（非圧縮）

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

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

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

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

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」というメッセージが表示されます。

お客様に必要な対応

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

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

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

フィードを設定する方法

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

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

IP 許可リストを設定する

Google SecOps が S3、SQS、Azure、サードパーティ API からデータを pull すると、Google インフラストラクチャは、お客様のバケットまたはサードパーティ API にアウトバウンド接続します。

ストレージバケットまたはファイアウォールで上り（内向き）許可リストを構成するには、次のリストに示すように、フィードタイプに応じて許可リストを構成する必要があります。

V2 フィード（S3_V2、SQS_V2、Azure_Blobstore_V2）: これらのフィードは、 Google Cloud Storage Transfer Service（STS）のみを使用して、お客様のストレージからデータを pull します。STS IP 範囲（ipranges.json）を許可リストに登録する必要があります。
サードパーティ API: goog.json が必要です。
以前のフィード（S3、Azure_Blobstore）: 専用の IP 範囲が必要です。詳細については、Google SecOps サポートにお問い合わせください。
Azure Event Hub: リージョン固有の IP 範囲が必要です。詳細については、Azure Event Hub フィードを作成するのネットワークセキュリティを構成する（省略可）をご覧ください。

Google サービスの IP 範囲は動的に変化するため、ファイアウォールを構成して、次のようにフィードを定期的に取得して解析することをおすすめします。

V2 フィード（S3_V2、SQS_V2、Azure_Blobstore_V2）: データ転送は、Storage Transfer Service ワーカーによってのみ実行されます。ipranges.json を定期的に取得して解析するだけで済みます。
レガシーフィード（S3、SQS、Azure_Blobstore、Azure Event Hub）とサードパーティ API: これらの接続は Google インフラストラクチャから発信されます。goog.json と cloud.json を定期的に取得して解析するだけで済みます。

フィードを構成する

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

フィードを追加

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

Google SecOps メニューで、[SIEM Settings] > [Feeds] を選択します。
[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（非推奨）、 Google Cloud Cloud Storage（非推奨）フィードを使用する場合は、有効なディレクトリパスがあることを確認してください。
- Amazon SQS（非推奨）または Amazon SQS（V2）を使用する場合は、Amazon SQS キューからメッセージを削除する権限を Google SecOps に明示的に付与してください。
- Amazon SQS（非推奨）フィードを使用する場合は、1 つのフィードのみがキューからメッセージを消費するようにしてください。別のアプリケーションまたはフィードによって読み取られたメッセージは、現在のフィードに取り込まれません。
- サードパーティ API ポーリングフィードにおけるアップストリーム API のインデックス登録のレイテンシについては、ポーリングフィードで遅れて到着するイベントをご覧ください。
- フィードのソースタイプとして Amazon SQS（非推奨）を使用できるのは、Amazon S3 バケット内のログに限られます。
[ログタイプ] リストで、取り込むログに対応するログタイプを選択します。使用可能なログは、前に選択したソースタイプによって異なります。

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

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

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

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

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

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

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

[Settings] > [Feeds] で、[Add New Feed] をクリックします。
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]: フィードの一意の名前が事前入力されています。
- アセットの名前空間: フィードに関連付けられた名前空間。
- 取り込みラベル: このフィードのイベントに適用されるラベル。
[フィードを作成] をクリックします。

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

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

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

ソース削除オプション

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

STS フィードで接頭辞を使用してオブジェクトをフィルタする

[接頭辞を含める]（include_prefixes）フィールドは、オブジェクトキーの接頭辞に基づいて、取り込み前に Storage Transfer Service（STS）によって転送されたストレージオブジェクトをフィルタします。このフィールドで指定した値は、STS ObjectConditions.include_prefixes に直接渡されます。

サポートされている STS フィードのソースタイプ

接頭辞ベースのフィルタリングは、次の STS フィードソースタイプ（feedSourceType）でサポートされています。

Cloud Storage（V2）（GOOGLE_CLOUD_STORAGE_V2）と Cloud Storage イベントドリブン（GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN）
Amazon S3（V2）（AMAZON_S3_V2）と Amazon SQS（V2）（AMAZON_SQS_V2）
Azure Blob Storage（V2）（AZURE_BLOBSTORE_V2）と Azure Blob Storage イベントドリブン（AZURE_BLOBSTORE_EVENT_DRIVEN）

接頭辞の構文と検証ルール

包括接頭辞（include_prefixes）を構成する場合は、次の構文と検証ルールに従ってください。

先頭にスラッシュを付けない: 接頭辞はバケットまたはコンテナのルートを基準とするため、先頭にスラッシュ（/）を付けないでください。たとえば、/logs/audit/ ではなく logs/audit/ と入力します。
末尾のスラッシュと部分一致: 末尾のスラッシュは、接頭辞が特定のフォルダ内のオブジェクトのみに一致するか、接頭辞で始まるオブジェクトキーに一致するかを制御します。
- 末尾にスラッシュがある場合: / で終わる接頭辞（logs/app/ など）は、一致するオブジェクトをそのフォルダ内のオブジェクトに厳密に制限します。ディレクトリレベルのスコープ設定には、末尾にスラッシュを付けます。
- 末尾のスラッシュなし: 末尾に / がない接頭辞（例: logs/app）は、その文字列で始まるすべてのオブジェクト（logs/app_old/ や logs/application/ など）と一致します。
大文字と小文字の区別: オブジェクトキーの接頭辞では、大文字と小文字が厳密に区別されます。
ワイルドカードや正規表現は使用できない: パターンマッチングはサポートされていません。* や ? などの文字はリテラル文字として扱われます。
空の値は不可: 個々のプレフィックスエントリを空にしたり、空白のみにしたりすることはできません。バケットまたはコンテナ全体を取り込むには、[接頭辞を含める] フィールドを空白のままにします。
重複しない個別の名前空間: 接頭辞を同じリスト内の別の接頭辞の接頭辞にすることはできません。たとえば、["logs/", "logs/audit/"] は無効ですが、["logs/audit/", "logs/vpc/"] などの兄弟プレフィックスは有効です。
上限: フィードでサポートされるプレフィックスは最大 1,000 個です。各接頭辞の長さは、UTF-8 でエンコードした場合に最大 1,024 バイトにする必要があります。また、復帰（\r）文字や改行（\n）文字を含めることはできません。

ソース固有の設定と権限

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

Google Cloud Storage フィードの設定例

Google SecOps メニューから [Settings] を選択し、[Feeds] をクリックします。
[Add New Feed] をクリックします。
次のページで、[単一のフィードを構成する] をクリックします。Google SecOps SIEM スタンドアロンプラットフォームを使用している場合、この手順は適用されません。
[ソースタイプ] で [Cloud Storage v2] を選択します。
[ログタイプ] を選択します。たとえば、Google Kubernetes Engine 監査ログのフィードを作成するには、[ログタイプ] として [Google Kubernetes Engine 監査ログ] を選択します。
[サービスアカウントを取得する] をクリックします。Google SecOps は、Google SecOps がデータの取り込みに使用する一意のサービスアカウントを提供します。または、API を使用してこのサービスアカウントをプログラムで取得することもできます。サービスアカウントを取得するをご覧ください。
省略可: サービスアカウントを構成します。詳細については、Google SecOps サービスアカウントにアクセス権を付与するをご覧ください。
[次へ] をクリックします。
作成した Cloud Storage 構成に基づいて、次のフィールドの値を指定します。
- Storage バケット URI
  
  注: ワイルドカードを使用して、ディレクトリ名全体を一致させます。たとえば、gs://cs-myprod/*/more-data は有効です（* は単一のディレクトリレベルの全体の名前に置き換えられます）。
  注: Cloud Storage イベントドリブンフィードタイプの場合は、Pub/Sub を構成するの説明に沿って、Cloud Storage の Pub/Sub サブスクリプションを設定します。
- ソース削除オプション
- 省略可: 接頭辞を含めます（省略可）。これは現在、限定プレビュー版です。構文ルールと許可リストの詳細については、STS フィードで接頭辞を使用してオブジェクトをフィルタするをご覧ください。
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 blob ストアから 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 メニューから [Settings] を選択し、[Feeds] をクリックします。
[新しく追加] をクリックします。
[フィード名] フィールドに、フィードの名前を入力します。
[ソースタイプ] リストで、[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 メニューから [Settings] を選択し、[Feeds] をクリックします。
[新しく追加] をクリックします。
[フィード名] フィールドに、フィードの名前を入力します。
[ソースタイプ] リストで、[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 エンドポイントとアクセスキーを指定します。

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

注意: クライアントアプリケーションを構成するときは、[エンドポイント情報] フィールドからコピーした完全なエンドポイント URL（:importPushLogs で終わる）を貼り付ける必要があります。一般的な Google SecOps コンソールの URL を貼り付けないでください。HTTP 404 Not Found エラーが発生します。

図 1: Webhook フィードのエンドポイント情報
省略可: [フィードを有効にする] の切り替えボタンをクリックして、フィードを無効にします。フィードはデフォルトで有効になっています。
[完了] をクリックします。

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 からテレメトリーを取り込むことができます。エンドポイント、認証、ページネーション戦略、状態管理をコンソールで直接定義して、データ pull を構成できます。

主なメリット

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

前提条件

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

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

カスタム API フィードを構成する

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

[SIEM Settings] > [Feeds] に移動します。
[新しいフィードを追加] をクリックします。
[単一フィードを設定] をクリックします。
[Feed name] フィールドに、一意のわかりやすい名前（1Password-Audit-Events など）を入力します。
[ソースタイプ] リストで、[カスタム API] を選択します。
[ログタイプ] リストで、ターゲットの Google SecOps ログタイプを選択します。
[次へ] をクリックします。
[全般設定] で、次の構成を行います。
- ベース URL: プライマリホスト（例: https://events.1password.com）を入力します。https:// で始まる必要があります。サブパスや末尾のスラッシュは追加しないでください。
- ポーリング頻度: プラットフォームが API で新しいテレメトリーをチェックする頻度を分単位で指定します。サポートされる範囲: 5 ～ 2,880 分（デフォルト: 15 分）。標準 API（順次）フィードの場合、10 ～ 15 分が標準です。リストと詳細（親子）フィードの場合、重複せずにファンアウトタスクを完全に実行できるように、30 ～ 60 分にすることをおすすめします。
[認証] で、サポートされている認証方法のいずれかを選択し、必須フィールドを構成します。
- 基本認証: [ユーザー名]（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 回のリクエストでデータを取得します。
  - トークンのページ分け: トークン（カスタムキー）を使用して次のページを取得します。[Next page token JSON path]（例: meta.next_cursor）と [Token pagination query parameter name]（例: cursor）を入力します。
  - リンクのページネーション: レスポンスで提供された URL に従って、より多くのデータを取得します。次のページのリンクの JSON パス（例: links.next、@odata.nextLink）を入力します。
  - オフセットページネーション: 設定した数のレコードをスキップして、次のセットを取得します。オフセットクエリパラメータ名（例: offset）を入力します。
  - ページ番号によるページ分け: 次のページ番号に移動します。ページ番号のクエリパラメータ名を入力します（例: page）。
7. [Checkpointing] で、コネクタが定期的なポーリングサイクル間で中断した場所を記憶できるように設定を構成します。
  - 戦略: 次のいずれかの戦略を選択し、必須フィールドを構成します。
    - なし: サイクル間の進行状況を追跡せずに、利用可能なすべてのデータを取得します。
    - 最新のタイムスタンプ: 最新のレコードのタイムスタンプを追跡します。[Checkpoint value JSON path]（例: timestamp、event_time）と [Checkpoint variable]（例: last_run_time、後続のポーリングで {{.last_run_time}} として参照される）を入力します。
    - 最新のレコード: 最も高いレコード ID を追跡して、新しいレコードのみを取得します。[チェックポイント値の JSON パス]（例: id、event_id）と [チェックポイント変数]（例: last_id、{{.last_id}} として参照）を入力します。
    - イテレータトークン: API が提供する永続的な継続トークンを使用します。[チェックポイント値の JSON パス] と [チェックポイント変数]（例: iterator_token、{{.iterator_token}} として参照）を入力します。
8. [Response Mapping] で、ログの検索方法と抽出方法をプラットフォームに指示するルールを指定します。
  - ターゲットデータの JSON パス: ターゲットログエントリのリストが配置されている API レスポンスペイロードの正確なパスを入力します。オブジェクトでラップされた配列（{"items": [...]} など）の場合は、「items」と入力します。ルート JSON 配列を直接返す API（[{...}, {...}] など）の場合、このフィールドは完全に空（[]）のままにします。
[List & Detail (Parent-Child)] を選択した場合は、次の操作を行います。
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 回のリクエストでデータを取得します。
    - トークンのページ分け: トークン（カスタムキー）を使用して次のページを取得します。[Next page token JSON path]（例: meta.next_cursor）と [Token pagination query parameter name]（例: cursor）を入力します。
    - リンクのページネーション: レスポンスで提供された URL に従って、より多くのデータを取得します。次のページのリンクの JSON パス（例: links.next、@odata.nextLink）を入力します。
    - オフセットページネーション: 設定した数のレコードをスキップして、次のセットを取得します。オフセットクエリパラメータ名（例: offset）を入力します。
    - ページ番号によるページ分け: 次のページ番号に移動します。ページ番号のクエリパラメータ名を入力します（例: page）。
  6. [Checkpointing] で、コネクタが定期的なポーリングサイクル間で中断した場所を記憶できるように設定を構成します。
    - 戦略: 次のいずれかの戦略を選択し、必須フィールドを構成します。
      - なし: サイクル間の進行状況を追跡せずに、利用可能なすべてのデータを取得します。
      - 最新のタイムスタンプ: 最新のレコードのタイムスタンプを追跡します。[Checkpoint value JSON path]（例: timestamp、event_time）と [Checkpoint variable]（例: 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 には、動的バッジ「Use {{.zone_id}} in your child request below」が表示されます。
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 回のリクエストでデータを取得します。
    - トークンのページ分け: トークン（カスタムキー）を使用して次のページを取得します。[Next page token JSON path]（例: meta.next_cursor）と [Token pagination query parameter name]（例: cursor）を入力します。
    - リンクのページネーション: レスポンスで提供された URL に従って、より多くのデータを取得します。次のページのリンクの JSON パス（例: links.next、@odata.nextLink）を入力します。
    - オフセットページネーション: 設定した数のレコードをスキップして、次のセットを取得します。オフセットクエリパラメータ名（例: offset）を入力します。
    - ページ番号によるページ分け: 次のページ番号に移動します。ページ番号のクエリパラメータ名を入力します（例: page）。
  6. [Checkpointing] で、コネクタが定期的なポーリングサイクル間で中断した場所を記憶できるように設定を構成します。
    - 戦略: 次のいずれかの戦略を選択し、必須フィールドを構成します。
      - なし: サイクル間の進行状況を追跡せずに、利用可能なすべてのデータを取得します。
      - 最新のタイムスタンプ: 最新のレコードのタイムスタンプを追跡します。[Checkpoint value JSON path]（例: timestamp、event_time）と [Checkpoint variable]（例: last_run_time、後続のポーリングで {{.last_run_time}} として参照される）を入力します。
次の [スケジュールとラベル] の設定を構成します。
- ポーリング頻度: 標準の間隔（5m、1h など）を選択します。
- Namespace: オプションの組織タグ。
- 取り込みラベル: データ RBAC の Key-Value ペア。
[送信] をクリックします。Google SecOps は、認証情報とエンドポイントの検証チェックを自動的に実行します。検証が成功すると、フィードはポーリングを開始します。

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

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

{
  "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 のベストプラクティス

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

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

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

構成可能なリクエストペーシング（レート制限）: 送信 HTTP リクエストは、ベンダーのレート制限を超えないように自動的にペーシングされます。デフォルトのペーシングレートは 1 分あたり 5 件のリクエスト（12 秒ごとに 1 件のリクエスト）です。これは、エンドポイント設定の [1 分あたりの最大リクエスト数] フィールドを使用して、ベンダーが公開している API 割り当てに合わせてエンドポイントごとに調整できます。
子リクエストの上限: 親子（リストと詳細）フィードの場合、検出リクエストはポーリングサイクルごとに最大 500 個の子リクエストをディスパッチできます。
単一レベルのファンアウト深度: コネクタは、ファンアウト深度を最大 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 pull ポーリングをサポートしています。永続的なストリーミング接続（WebSocket）と受信 Webhook はサポートされていません。
相互 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 見つかりません	ベース URL またはエンドポイントパステンプレートが正しくありません。	ベンダーの API ドキュメントでエンドポイントを調べます。ベース URL が正しく終了し、エンドポイントパスが / で始まっていることを確認します。
HTTP 429 Too Many Requests	ベンダーの API レート制限を超えました。	ポーリング頻度を増やすか、クエリパラメータの `limit` パラメータを減らします。
JSON 抽出エラー（items_path が空）	レスポンス構成パスが一致しません。	API レスポンスのペイロード構造を確認し、ターゲットデータの JSON パスを更新します。
重複データの取り込み	状態構成のタイムスタンプまたは ID 抽出パスが無効です。	ログレコードのフィールド名でタイムスタンプを確認し、抽出パスを更新します。

フィードを管理する

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

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

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

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

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

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

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

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

アクティブ: フィードが構成され、Google SecOps アカウントにデータを取り込む準備が整っています。

注: ステータスが「アクティブ」の場合、フィード構成が有効であることを示しますが、ランタイム認証や収集の健全性は反映されません。アクティブなサードパーティフィードからログが届かない場合は、Health Hub で、期限切れのシークレットや無効なトークンなどの運用エラーを確認します。
InProgress: Google SecOps は、構成済みのサードパーティからデータを pull しようとします。
完了: このフィードによってデータは正常に取得されました。
アーカイブ済み: 無効化されたフィード。
Failed: フィードでデータを正常に取得できません。構成の問題が原因と考えられます。質問をクリックすると、構成エラーが表示されます。エラーを修正し、フィードを再送信したら、[フィード] ページに戻って、現在、フィードが機能しているかどうかを確認します。

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

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

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

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

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

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

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

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

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

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

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

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

pull ベースのフィード

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

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

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

push ベースのフィード

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

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

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

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

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

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

フィードの削除

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

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

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

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

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

取り込み率を制御する

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

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

失敗したフィードのトラブルシューティング

[フィード] ページでは、次のように、ソースタイプ、ログタイプ、フィード ID、既存のフィードのステータスなどの詳細を確認できます。
1. 既存のフィードにポインタを合わせ、右側の列にある more_vert をクリックします。
2. [フィードを表示] をクリックします。フィードの詳細を示すダイアログが表示されます。失敗したフィードについては、[詳細] > [ステータス] でエラーの詳細を確認できます。
失敗したフィードについては、詳細にエラーの原因と修正手順が含まれます。
データフィードの操作中に発生する可能性のあるエラーメッセージについては、ソースと取り込みのエラーの表をご覧ください。
フィードアクティビティの詳細な分析とトラブルシューティングを行うには、Cloud Logging でログを表示します。Cloud Logging でフィードアクティビティを分析するをご覧ください。
Generic::failed_precondition エラー:

エラー: Generic::failed_precondition: include_prefixes is not enabled for this customer

このエラーは、[接頭辞を含める]（include_prefixes）フィールドに値を指定して STS フィードを保存したときに、Google SecOps テナントが接頭辞ベースのフィルタリングの許可リストに登録されていない場合に発生します。

このエラーを解決するには、以下のいずれかを行います。
1. [プレフィックスを含める]（include_prefixes）フィールドからすべてのプレフィックスを削除し、フィードを再度保存して、バケットまたはコンテナ全体を取り込みます。
2. Google Cloud アカウントチーム、テクニカルアカウントマネージャー（TAM）、または Cloud カスタマーケアに連絡して、テナントの include_prefixes（enable_feed_include_prefixes）機能へのアクセスをリクエストします。詳細については、STS フィードで接頭辞でオブジェクトをフィルタするをご覧ください。

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

フィード UI を操作する

始める前に

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

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

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

移行中に行える操作

お客様に必要な対応

フィードを設定する方法

IP 許可リストを設定する

フィードを構成する

フィードを追加

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

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

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

ソース削除オプション

STS フィードで接頭辞を使用してオブジェクトをフィルタする

サポートされている STS フィードのソースタイプ

接頭辞の構文と検証ルール

ソース固有の設定と権限

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 のベストプラクティス