Aperçu
Pour les organisations qui envoient des données vers des systèmes pour lesquels il n'existe pas d'intégration Cato dédiée, nous proposons l'Intégration HTTP Push Personnalisée.
Utilisez l'intégration HTTP Push Personnalisée pour diffuser des événements, et éventuellement des flux, directement vers toute plateforme externe acceptant du JSON ou du JSON délimité par des sauts de ligne (NDJSON) via HTTP. Les données sont continuellement poussées au fur et à mesure de leur génération, plutôt que récupérées selon un calendrier. Cela permet aux systèmes en aval de recevoir des mises à jour quasi en temps réel sans interrogation.
Cas d'utilisation courants:
Plateformes SIEM et SOC - L'entreprise exemple utilise la fonctionnalité de Surveillance d'activité suspecte IPS, qui génère un volume élevé d'événements de sécurité. Ils décident de centraliser ces données avec leur plateforme SIEM existante, pour laquelle il n'y a pas d'intégration Cato dédiée. L'entreprise Exemple active l'Intégration des Événements et configure une Intégration HTTP Push Personnalisée pointant vers le point d'ingestion HTTP de leur SIEM, afin que tous les événements IPS soient automatiquement transmis au SIEM pour la corrélation, l'alerte et la rétention à long terme, aux côtés de leurs autres données de sécurité.
Collecte et analyses de logs personnalisés - L'entreprise Exemple souhaite alimenter les données d'événement Cato dans leur pipeline d'analyse interne pour le reporting opérationnel. Ils créent un collecteur de logs basé sur HTTP pour recevoir les données et configurent une Intégration HTTP Push Personnalisée dans leur compte Cato, afin que les événements soient envoyés en continu au collecteur dès qu'ils sont générés, sans avoir besoin d'interroger Cato pour les mises à jour.
Intégrations Natives vs. HTTP Push Personnalisé
Cato fournit des intégrations sur mesure pour exporter des événements vers les plateformes couramment utilisées, y compris Splunk, Microsoft Sentinel, CrowdStrike, et Azure Storage. Lorsqu'une intégration native est disponible pour votre destination, nous vous recommandons de l'utiliser. L'avantage est qu'elle est optimisée pour cette plateforme et peut offrir des fonctionnalités spécifiques à la plateforme.
Utilisez l'intégration HTTP Push Personnalisée lorsque votre destination ne dispose pas d'une intégration dédiée, ou lorsque vous devez transmettre des événements à une application ou un service personnalisé.
Filtres
Utilisez des filtres pour contrôler quels événements sont exportés. Cela aide à réduire les coûts d'ingestion, minimiser le bruit, et concentrer les enquêtes sur les événements les plus pertinents pour des sites spécifiques, des utilisateurs ou des régions. Vous pouvez également utiliser des filtres pour acheminer différents sous-ensembles d'événements vers différents environnements SIEM.

Utilisez des groupes de filtres pour définir des filtres basés sur tout Champ d'Événement ou combinaison de champs. Les conditions au sein de chaque groupe utilisent la logique ET. La logique OU est appliquée entre les groupes. Les filtres dans la capture d'écran configurent l'intégration pour exporter :
Les événements qui proviennent de Paris ou Madrid, sont de sous-type Pare-feu Internet, et ont pris des actions autres que Surveiller ou Inviter.
Le Nom d'utilisateur contient Test
Prérequis
Avant de configurer une intégration HTTP Push Personnalisée, vérifiez que la plateforme de destination prend en charge toutes les caractéristiques suivantes :
Requêtes HTTP POST ou PUT
JSON ou JSON délimité par des nouvelles lignes (NDJSON)
La charge utile Cato standard sans nécessiter de corps de requête personnalisé, d'enveloppe spécifique au fournisseur ou de directive supplémentaire
La structure de la charge utile est fixe. Les champs ne peuvent pas être ajoutés, supprimés ou réarrangés.
En résumé :
Une plateforme de destination est généralement compatible si elle peut ingérer des objets JSON simples ou un flux d'événements NDJSON exactement comme Cato les envoie. Les exemples incluent SentinelOne, Securonix, et Trend AI.
Une plateforme n'est pas compatible si son API d'ingestion nécessite une structure de charge utile propriétaire, telle qu'une enveloppe, un emballage ou une ligne de contrôle, à ajouter au corps de la requête. Les exemples incluent Elastic et Datadog.
Configurer une Intégration HTTP Push Personnalisée
Étape 1 : Recueillir les Paramètres
Depuis votre plateforme cible, obtenez :
URL d'Ingestion : le point de terminaison HTTP(S) qui accepte des événements
Détails d'authentification : l'intégation supporte En-tête(s) Personnalisé(s), Clé API, Jeton Porteur, ou Authentification Basique. Si votre fournisseur attend une valeur préfixée (par ex. Bearer <token>), vous entrerez toute la chaîne — préfixe inclus — en tant que valeur unique. Elle est stockée chiffrée sur le côté Cato.
Étape 2 : Tester avec curl
Validez la destination indépendamment à l'aide d'une commande en ligne curl. Cela isole les problèmes côté fournisseur (auth, point de terminaison, acceptation de la charge utile) et vous donne une requête fonctionnelle que vous pouvez réutiliser directement dans la configuration du connecteur.
L'exemple suivant montre une requête curl pour Elastic qui ne réussit pas :
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":"test event from curl","event_type":"test","timestamp":"2026-07-05T12:00:00Z"}\n'Cela ne satisfait pas les exigences du connecteur, même si l'appel curl lui-même peut réussir contre Elastic. La charge utile nécessite une ligne de directive create avant chaque ligne d'événement ; l'intégration ne peut pas injecter cette ligne supplémentaire, car le format du corps est fixe.
L'exemple suivant montre une requête curl pour SentinelOne qui réussit :
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'Cela fonctionne parce que le point de terminaison brut HEC de SentinelOne accepte un objet événement simple par ligne — sans enveloppe, ni directive supplémentaire — ce qui est exactement ce que le connecteur envoie. Lorsqu'un test curl de ce type réussit, vous pouvez l'utiliser tel quel dans la configuration du connecteur :
URL : collez le point de terminaison complet, y compris les paramètres de requête (par exemple, ?sourcetype=cato_events)
Auth : En-têtes Personnalisés → nom de l'en-tête Authorization, valeur définie sur votre véritable jeton (stocké en Secret)
Corps : définissez le type de contenu pour correspondre à ce que vous avez testé (application/x-ndjson ici)
Si votre test curl réussit, passez à l'étape 3.
Étape 3 : Configurer le Connecteur
Dans le CMA, allez à Resources > Integrations > Configured Integrations, et cliquez sur Nouveau.
Sous Intégration, sélectionnez Intégration HTTP Personnalisée.
Sous Capacité, choisissez Exportation de Données.
Sous Auth, sélectionnez la méthode qui correspond à ce que vous avez validé avec curl (En-têtes Personnalisés, Clé API, Jeton Porteur ou Authentification Basique).
Entrez un Nom et une Description facultative.
Entrez l'URL — le même point de terminaison que vous avez testé avec curl.
Ajoutez vos En-têtes Personnalisés (ou champs d'auth équivalents) — recopiez exactement les noms et valeurs des en-têtes de votre commande curl réussie. Chaque valeur peut être stockée en tant que Secret ou Plain.
Sous Corps, confirmez le type de contenu (par défaut, c'est
application/json; NDJSON est également pris en charge).
Le corps de la requête envoyé par le connecteur est non configurable : vous ne pouvez pas ajouter de champs personnalisés ou restructurer la charge utile.
Sous Sources de Données, sélectionnez Événements, Flux, ou les deux.
Optionnellement, délimitez ce qui est envoyé en utilisant le Filtre des Événements et le Filtre des Flux (correspondance AVEC l'un des groupes de filtres configurés). Pour plus d'informations, voir Filtres ci-dessus.
Choisissez si vous souhaitez suivre les erreurs avec les événements du connecteur. Il est recommandé de le faire pour que les échecs de livraison apparaissent comme des événements sur lesquels vous pouvez alerter.
Enregistrez la configuration et confirmez que le statut affiche Connecté.
Dépannage
Curl réussit, mais Cato affiche une Erreur de Connectivité : Vérifiez que les en-têtes/auth saisis dans Cato correspondent exactement à ce que vous avez utilisé dans curl, y compris tout préfixe requis (par exemple, Bearer) dans le cadre de la valeur chiffrée.
Aucun événement n'arrive sur ma plateforme externe : Vérifiez votre Filtre d'Événements/Filtre de Flux. Un filtre trop étroit peut tout exclure silencieusement.
Le fournisseur rejette la charge utile : Consultez les prérequis. Votre fournisseur requiert probablement une structure de corps personnalisée que ce connecteur ne peut produire.
Journal des modifications des articles
Date d'insertion | Description |
|---|---|
04 août 2026 |
|
FAQ
Q : Puis-je pousser vers plusieurs points de terminaison en même temps ?
R : Vous devez configurer une intégration HTTP Push Personnalisée distincte par destination.
Q : Est-ce que cela remplace les intégrations natives (Splunk, Sentinel, CrowdStrike, etc.) ?
R : Non. Où existe une intégration native de Cato, utilisez-la. Les intégrations HTTP Push Personnalisées sont destinées aux plateformes sans intégration dédiée, ou pour les destinations non-SIEM.
Q : Que faire si mon fournisseur n'est pas dans la liste prise en charge ?
R : Vérifiez si leur API d'ingestion HTTP accepte des objets JSON simples ou NDJSON sans structure de wrapper requise. Si c'est le cas, testez d'abord avec curl, puis configurez le connecteur comme décrit sur cette page.
Q : Puis-je personnaliser le corps JSON ou ajouter des champs ?
R : Non. Le schéma de la charge utile est fixe.