概観
専用の Cato 統合がないシステムにデータを送信する組織のために、カスタム HTTP プッシュ統合を提供します。
イベントと任意のフローを、JSON または改行区切りの JSON (NDJSON) を受け入れる任意の外部プラットフォームに直接ストリームするためにカスタム HTTP プッシュ統合を使用してください。 データは、定期的に取得されるのではなく、生成されるとすぐに継続的にプッシュされます。 これにより、下流のシステムはポーリングせずに、ほぼリアルタイムの更新を受け取ることができます。
共通のユースケース
SIEMおよびSOCプラットフォーム - サンプル会社は疑わしい活動のモニタリング機能を使用し、高いセキュリティイベントを生成しています。 彼らはこのデータを既存のSIEMプラットフォームと集中化することを決定しましたが、専用のCato統合はありません。 サンプル会社はイベント統合を有効化し、カスタムHTTPプッシュ統合をSIEMのHTTPインジェストエンドポイントに向けて設定することで、すべてのIPSイベントが他のセキュリティデータとともに相関、アラート、長期保存のためにSIEMに自動ストリーミングされます。
カスタムログ収集とアナリティクス - サンプル会社は運用報告のためにCatoイベントデータを内部のアナリティクスパイプラインに投入したいと考えています。 彼らはHTTPベースのログコレクタを起動し、データを受け取って、彼らのCatoアカウントでカスタムHTTPプッシュ統合を設定し、イベントが生成される度に収集機に継続的にプッシュされるようにします。
配信信頼性
データはベストエフォートで送信されます。 宛先のエンドポイントが利用できなくなる、または認証エラーを返す場合、Catoは以下のスケジュールに従って自動的に再接続を試みます。
短期リトライ: 1 分、5 分、10 分、15 分、1 時間、6 時間、および 24 時間
延長リトライ: 最初の24時間後、7日間継続して毎日リトライ
統合が7日間接続できないままである場合は、エンドポイントの設定の問題が解決されるまで、統合全体の再試行が停止します。
ネイティブ統合 vs. カスタムHTTPプッシュ
Catoはイベントを一般的なプラットフォームにエクスポートするための特別な統合を提供しており、Splunk、Microsoft Sentinel、CrowdStrike、およびAzure Storageを含みます。 宛先にネイティブ統合が利用可能な場合は、それを使用することをお勧めします。 その利点は、それがそのプラットフォームに最適化されており、プラットフォーム固有の機能を提供する可能性があることです。
専用の統合がない場合や、カスタムアプリケーションやサービスにイベントを配信する必要がある場合には、カスタムHTTPプッシュ統合を使用してください。
フィルター
エクスポートするイベントを制御するためにフィルターを使用します。 これにより、インジェストコストが削減され、ノイズが最小限に抑えられ、特定のサイト、ユーザー、または地域に最も関連するイベントに調査を集中させることができます。 フィルターを使用して、異なるSIEM環境に異なるイベントのサブセットをルーティングすることもできます。

フィルターグループを使用して、イベントフィールドまたはフィールドの組み合わせに基づいてフィルターを定義します。 各グループ内の条件はANDロジックが使用されます。 ORロジックはグループ間で適用されます。 スクリーンショットのフィルターでは、以下をエクスポートするように統合を構成します:
ニースまたはマドリード発で、サブタイプがインターネットファイアウォールで、結果がモニターやプロンプト以外のアクションだったイベント
ユーザ名にTestが含まれる
前提条件
カスタムHTTPプッシュ統合を設定する前に、宛先プラットフォームが以下のすべてをサポートしていることを確認してください:
HTTP POSTまたはPUTリクエスト
JSONまたは改行区切りJSON(NDJSON)
独自のリクエストボディ、ベンダー固有のラッパー、または追加の指示が不要な標準的なCatoペイロード
ペイロード構造は固定されています。 フィールドを追加、削除、再配置することはできません。
要約:
宛先プラットフォームは、Catoが送信するそのままのプレーンJSONオブジェクトまたはNDJSONイベントストリームをインジェストできる場合に通常、互換性があります。 例としては、SentinelOne、Securonix、Trend AIがあります。
プラットフォームのAPIが、リクエストボディに追加されるべきプロプライエタリなペイロード構造(エンベロープ、ラッパー、制御ラインなど)を要求する場合、互換性がないとみなされます。 例としては、ElasticやDatadogがあります。
カスタムHTTPプッシュ統合を設定
ステップ1: パラメータを収集する
ターゲットプラットフォームから取得:
インジェスションURL: イベントを受け入れるHTTP(S)エンドポイント
認証の詳細: 統合はカスタムヘッダー、APIキー、Bearerトークン、またはBasic 認証をサポートします。 もしベンダーが接頭辞を期待する場合(例: Bearer <token>)、接頭辞を含む全体を一つの値として入力してください。 それはCato側で暗号化されて保存されています。
ステップ2: curlでテスト
コマンドラインcurlリクエストを使用して、宛先を独立して検証してください。 これにより、ベンダー側の問題(認証、エンドポイント、ペイロード受け入れ)がある場合は隔離され、コネクタセットアップで直接再利用可能なリクエストを得ることができます。
次の例では、Elastic が非成功のcurlリクエストを示しています。
curl -X POST "https://<your-elastic-endpoint>/_bulk" \
-H "Authorization: ApiKey <KEY>" \
-H "Content-Type: application/x-ndjson" \
--data-binary $'{"create":{"_index":"logs-cato.events-default"}}\n{"message":"curlからのテストイベント","event_type":"test","timestamp":"2026-07-05T12:00:00Z"}\n'これはコネクタの要件を満たさないことになりますが、curl呼び出し自体はElasticに対して成功することもあります。 ペイロードには、イベントラインごとに「create」指示行が必要であり、統合はその追加行を挿入する方法を持っていません。なぜなら、ボディフォーマットが固定されているからです。
以下にSentinelOneの成功するcurlリクエストを示します。
curl -i "https://ingest.us1.sentinelone.net/services/collector/raw?sourcetype=cato_events" \
-H "Authorization: <token>" \
-H "Content-Type: application/x-ndjson" \
--data-binary $'{"event_type":"test"}\n'これは、SentinelOneのHEC生エンドポイントが行ごとのプレーンイベントオブジェクトを受け入れるため機能し、コネクタが送信するのとまったく同じです。 このようにcurlテストが成功した場合、その内容をそのままコネクタセットアップに使用できます:
URL: クエリパラメーターを含めたエンドポイント全体を貼り付けてください(例: ?sourcetype=cato_events)
Auth: カスタムヘッダー → ヘッダー名 Authorization、値を実際のトークン(秘密として保存)に設定
Body: コンテンツタイプをテストしたものに一致させます(application/x-ndjson ここに)
curlテストが成功した場合は、ステップ3に進みます。
ステップ3: コネクタを設定
CMAで、リソース > 統合 > 統合済み統合に移動し、新規をクリックします。
統合の下で、カスタムHTTP統合を選択します。
機能の下で、データエクスポートを選択します。
Authの下で、curlで検証したものと一致するメソッド(カスタムヘッダー、APIキー、Bearerトークン、またはBasic Auth)を選択します。
名前とオプション説明を入力します。
URLを入力します — curlでテストしたのと同じエンドポイントです。
カスタムヘッダー(または同等の認証項目)を追加します — 成功したcurlコマンドからヘッダー名と値を正確に引き継ぎます。 各値は秘密またはプレーンとして保存できます。
本文の下で、コンテンツタイプを確認してください(デフォルトは
application/json; NDJSONもサポートされます)。
コネクタによって送信されるリクエストボディは構成不可です:カスタムフィールドを追加したり、ペイロードを再構築することはできません。
データソースの下で、イベント、フロー、または両方を選択します。
オプションとして、送信される内容をイベントフィルターおよびフローフィルター(設定されたフィルターグループのいずれかに一致)を使用して絞ることができます。 詳細は上記のフィルターを参照してください。
コネクタイベントでエラーを追跡するかどうかを選択します。 これを推奨するのは、配信の失敗がアラート可能なイベントとして露呈することになるからです。
構成を保存し、ステータスに接続済みと表示されていることを確認します。
トラブルシューティング
Curlが成功しましたが、Catoに接続エラーが表示されます: Headers/AuthがCatoで入力した内容がcurlで使用したものと完全に一致することをダブルチェックしてください(例: Bearerのような必須接頭辞を含みます)。
外部プラットフォームにイベントが届かない: イベントフィルタ/フローフィルタを確認してください。 あまりにも狭いフィルタは、すべてを静かに除外する可能性があります。
ベンダーがペイロードを拒否: 前提条件を確認してください。 ベンダーはおそらくこのコネクタで対応できないカスタムボディ構造を要求しています。
記事への変更履歴
日付 | "説明" |
|---|---|
2026年8月04日 |
|
FAQ
Q: 複数のエンドポイントに一度にプッシュできますか?
A: 宛先ごとに別々のカスタムHTTPプッシュ統合を構成する必要があります。
Q: これはネイティブ統合(Splunk、Sentinel、CrowdStrikeなど)に取って代わりますか?
A: いいえ。 ネイティブCato統合が存在する場合は、それを使用してください。 カスタムHTTPプッシュ統合は、専用の統合がないプラットフォーム、またはSIEM以外の宛先用です。
Q: ベンダーがサポートリストにない場合はどうしますか?
A: ベンダーのHTTPインジェスションAPIが、ラッパー構造が必要ないプレーンなJSONまたはNDJSONを受け入れるかどうかを確認してください。 もしそうなら、まずcurlでテストし、このページの説明に従ってコネクタを構成してください。
Q: JSONボディをカスタマイズしたりフィールドを追加できますか?
A: いいえ。 ペイロードスキーマは固定されています。