Passer au contenu principal

Présentation

Wirespeed se connecte à Cloudflare à l’aide d’un jeton API de compte afin de pouvoir :
  • ingérer les journaux d’authentification Access : chaque connexion autorisée ou refusée à une application protégée par Cloudflare Access, y compris les connexions via WARP ;
  • ingérer les journaux d’audit du compte : les modifications de membres, de paramètres et de configuration effectuées dans le tableau de bord ou l’API Cloudflare ;
  • recevoir depuis Cloudflare Logpush les journaux Gateway DNS, HTTP et réseau, les sessions réseau Zero Trust, les activations et modifications de configuration de WARP et les événements de pare-feu des zones ;
  • synchroniser les utilisateurs Zero Trust afin de pouvoir les cibler par des actions de confinement ;
  • révoquer les sessions Access d’un utilisateur compromis, y compris ses appareils inscrits et sa session WARP.
Pendant la bêta, les événements Cloudflare sont ingérés uniquement pour la recherche et la corrélation. Ils ne génèrent pas encore de détections.

Prérequis

Avant de connecter Cloudflare dans Wirespeed, rassemblez :
  • l’Account ID de votre compte Cloudflare ;
  • un jeton API Cloudflare disposant des autorisations ci-dessous.

Créer un jeton API

  1. Dans le tableau de bord Cloudflare, ouvrez Manage Account > Account API Tokens. Vous pouvez aussi créer un jeton utilisateur sous My Profile > API Tokens.
  2. Sélectionnez Create Token, puis Create Custom Token.
  3. Ajoutez ces autorisations Account :
  1. Facultatif : pour collecter les événements de pare-feu, ajoutez aussi ces autorisations Zone :
  1. Sous Account Resources, incluez uniquement le compte que vous connectez. Si vous avez ajouté des autorisations de zone, réglez Zone Resources sur All zones from an account et sélectionnez le même compte.
  2. Créez le jeton et copiez-le. Cloudflare n’affiche le jeton qu’une seule fois.
Wirespeed a besoin de l’accès Edit sur Access: Organizations, Identity Providers, and Groups uniquement pour révoquer les sessions Access d’un utilisateur. L’API revoke user de Cloudflare n’accepte aucune autorisation en lecture seule. Wirespeed ne modifie ni les paramètres de votre organisation Zero Trust, ni vos fournisseurs d’identité, ni vos groupes Access. Si vous souhaitez uniquement ingérer des journaux, omettez l’autorisation Access: Organizations, Identity Providers, and Groups et activez Lecture seule lorsque vous connectez l’intégration. Cloudflare exige à la fois Logs: Edit et Zero Trust: PII Read pour gérer les tâches Logpush des jeux de données Zero Trust tels que Gateway. Le rôle Administrator du compte inclut Logs: Edit, mais pas Zero Trust: PII Read. Consultez les autorisations Logpush de Cloudflare. Si vous omettez l’une de ces autorisations, créez vous-même les tâches Logpush comme indiqué dans Configurer Logpush manuellement. Pour plus de détails, consultez la référence des autorisations des jetons API de Cloudflare.

Trouver votre Account ID

Ouvrez le compte dans le tableau de bord Cloudflare. L’Account ID de 32 caractères figure sur la page d’accueil du compte et dans l’URL du tableau de bord (https://dash.cloudflare.com/<account-id>/...).

Connecter Cloudflare dans Wirespeed

  1. Dans Wirespeed, accédez à Intégrations > Ajouter une intégration.
  2. Sélectionnez Cloudflare Zero Trust.
  3. Saisissez votre Account ID et votre jeton API.
  4. Facultatif : dans les options avancées, activez Lecture seule pour empêcher la révocation des sessions.
  5. Enregistrez l’intégration.

Validation

Lorsque vous enregistrez l’intégration, Wirespeed demande une entrée du journal d’authentification Access. La connexion de l’intégration échoue si le jeton n’est pas valide, appartient à un autre compte ou ne dispose pas de Access: Audit Logs Read. Une fois l’intégration activée, Wirespeed vérifie chaque autorisation liée aux journaux et affiche le résultat sur la page de l’intégration : L’autorisation de révocation des sessions ne peut pas être vérifiée sans révoquer un utilisateur. Si elle manque, la révocation échoue et l’erreur apparaît dans les journaux de l’intégration.

Collecte des journaux

Wirespeed interroge les journaux d’authentification Access et d’audit du compte selon une planification, et enregistre sa position après chaque page : après un redémarrage ou une panne, la collecte reprend là où elle s’était arrêtée au lieu de repartir de zéro. La première synchronisation collecte les 7 jours précédents. Chaque interrogation relit les 10 dernières minutes pour récupérer les événements que Cloudflare indexe tardivement, et ignore ceux qu’elle a déjà ingérés. Si la collecte s’arrête après l’ingestion d’une page mais avant l’enregistrement de sa position, cette page peut être ingérée de nouveau.

Journaux Logpush

Cloudflare exporte les journaux Gateway, de sessions réseau Zero Trust, de modification WARP et d’événements de pare-feu uniquement via Logpush. Wirespeed les reçoit depuis une destination HTTP Logpush : une tâche Logpush par jeu de données envoie les journaux vers l’URL de webhook de votre intégration. Les événements de pare-feu appartiennent à une zone et non au compte : ils nécessitent donc une tâche par zone.

Configuration automatique

Lorsque le jeton API dispose de Logs: Edit et de Zero Trust: PII Read, Wirespeed crée une tâche par jeu de données à chaque activation de l’intégration. Ces tâches sont nommées wirespeed-<dataset> (par exemple wirespeed-gateway_dns) et utilisent les paramètres décrits dans Configurer Logpush manuellement.
  • Si une tâche existe déjà pour cette intégration, Wirespeed la met à jour au lieu d’en créer un doublon, y compris sa destination : un secret de webhook renouvelé prend donc effet lorsque vous réactivez l’intégration.
  • Cloudflare ne propose chaque jeu de données que dans les offres qui l’incluent. Les jeux de données absents de l’offre du compte sont ignorés, et leur droit Logpush reste désactivé. À chaque activation de l’intégration, les journaux de l’intégration indiquent sur une ligne les jeux de données envoyés et ceux qui ne font pas partie de l’offre.
  • Si un jeu de données échoue pour une autre raison, l’erreur apparaît dans les journaux de l’intégration et les autres jeux de données sont tout de même configurés.
  • Si le jeton ne dispose pas de l’une des deux autorisations, le droit Configuration de Logpush affiche un avertissement et l’intégration est activée sans les tâches. Les journaux de l’intégration nomment l’autorisation manquante et incluent l’erreur de Cloudflare. Cloudflare signale l’absence de Zero Trust: PII Read par reading job for product '<product>' is not allowed (1004).
  • Pour firewall_events, Wirespeed liste les zones du compte et crée une tâche wirespeed-firewall_events dans chaque zone Enterprise. Les zones relevant d’autres offres sont ignorées. La ligne de synthèse indique le nombre de zones qui envoient des événements, par exemple firewall_events (2 of 5 zones). Les zones ajoutées ultérieurement sont prises en compte à la prochaine activation de l’intégration.
  • La désactivation ou la suppression de l’intégration supprime les tâches wirespeed-* dont la destination est cette intégration. Wirespeed ne modifie ni ne supprime jamais les autres tâches Logpush.
Lorsqu’il crée une tâche, Cloudflare valide chaque destination en téléversant un fichier de test vers Wirespeed : l’API Wirespeed doit donc être accessible depuis Internet.

Configurer Logpush manuellement

Suivez ces étapes si le jeton ne dispose pas de Logs: Edit et de Zero Trust: PII Read, ou si vous souhaitez gérer les tâches vous-même.

Obtenir l’URL et le secret du webhook

  1. Dans Wirespeed, ouvrez l’intégration Cloudflare Zero Trust et sélectionnez Détails du webhook.
  2. Copiez l’URL du webhook Recevoir les journaux Logpush. Elle ressemble à ceci :
  3. Copiez le Secret du webhook. Wirespeed rejette les requêtes Logpush qui ne l’envoient pas sous la forme Authorization: Bearer <WEBHOOK_SECRET>.

Construire la destination

Logpush transforme chaque paramètre header_* de l’URL de destination en en-tête de requête, et conserve les autres paramètres dans l’URL. Ajoutez deux paramètres à l’URL du webhook :
  • dataset=<DATASET>, l’un des noms de jeux de données du tableau ci-dessus, qui indique à Wirespeed à quelle table appartiennent les journaux ;
  • header_Authorization=Bearer%20<WEBHOOK_SECRET>, qui envoie le secret. Conservez l’espace encodé sous la forme %20.
Pour Gateway DNS, la valeur de destination_conf est :
Chaque tâche a besoin de sa propre valeur destination_conf avec le dataset correspondant.

Créer les tâches Logpush

Créez les tâches avec l’API Cloudflare, à l’aide d’un jeton disposant des autorisations de compte Logs: Edit (Logs Write) et Zero Trust: PII Read. Le jeton API de l’intégration elle-même n’en a pas besoin. Logpush valide la destination à la création de la tâche en téléversant un fichier de test : Wirespeed doit donc être accessible et le secret doit être correct, sans quoi la création de la tâche échoue.
Répétez l’opération pour chaque jeu de données, en remplaçant name par wirespeed-<dataset> et en adaptant dataset, le paramètre dataset de destination_conf et field_names.
  • max_upload_bytes : réglez-le sur 5000000 (5 Mo de journaux non compressés, le plus petit lot autorisé par Logpush). Wirespeed accepte des livraisons d’au plus 5 Mio compressés : un lot de 5 Mo non compressés au maximum tient donc toujours dans cette limite. Logpush autorise une valeur de max_upload_bytes allant jusqu’à 1 Go, mais Wirespeed rejette les livraisons plus volumineuses avec le code 413 et enregistre un avertissement dans les journaux de l’intégration : conservez donc 5000000. Les tâches que Wirespeed crée automatiquement utilisent déjà cette valeur. Wirespeed met chaque livraison en file d’attente telle qu’il la reçoit, encore compressée, et la transmet en un seul bloc à son pipeline de journaux, qui la décompresse et enregistre chaque enregistrement. Si cette transmission échoue, Wirespeed relance le lot complet, et une livraison renvoyée par Cloudflare n’est enregistrée qu’une seule fois.
  • timestamp_format : les tâches créées via l’API utilisent unixnano par défaut. Wirespeed lit tous les formats, mais rfc3339 est plus lisible dans la recherche.
  • field_names : Logpush envoie uniquement les champs que vous listez. Utilisez les listes complètes ci-dessous pour que Wirespeed reçoive tous les champs.
Vous pouvez aussi créer les tâches dans le tableau de bord Cloudflare : ouvrez la page Logpush du compte, sélectionnez Create a Logpush job, choisissez HTTP destination et collez la valeur de destination_conf comme point de terminaison. Sélectionnez tous les champs du jeu de données. Le tableau de bord ne définit pas max_upload_bytes : définissez-le ensuite avec l’API update job. Cet appel remplace entièrement output_options : incluez-les donc de nouveau.
Listes de champs
Copiez la liste de chaque tâche dans output_options.field_names. Les champs obsolètes sont omis.
gateway_dns
gateway_http
gateway_network
zero_trust_network_sessions
warp_toggle_changes
warp_config_changes
firewall_events
Pour plus de détails, consultez les références de Cloudflare sur la destination HTTP, les options de sortie et les champs des jeux de données.

Synchronisation des utilisateurs

Wirespeed synchronise vos utilisateurs Zero Trust depuis l’API users de Cloudflare : ils apparaissent ainsi comme utilisateurs de l’annuaire et peuvent être ciblés par Révoquer les sessions Access. La synchronisation utilise l’autorisation Access: Audit Logs Read et ne nécessite rien de plus. Cloudflare ajoute un utilisateur à cette liste lors de sa première authentification, lorsqu’il se connecte à une application Access ou connecte un appareil WARP. Les utilisateurs qui existent dans votre fournisseur d’identité, y compris ceux provisionnés par SCIM, mais qui ne se sont jamais authentifiés n’y figurent pas. Ils n’ont aucune session Access ou WARP à révoquer. Wirespeed associe les utilisateurs synchronisés à la même personne dans vos autres intégrations d’identité grâce à leur adresse e-mail. Lorsqu’un utilisateur est également synchronisé depuis un fournisseur d’identité comme Okta, Wirespeed exécute chaque action de remédiation via un seul fournisseur : révoquez donc les sessions Cloudflare de l’utilisateur depuis l’utilisateur de l’annuaire Cloudflare lorsque vous devez aussi mettre fin à ses sessions Access et WARP.

Révocation des sessions

Révoquer les sessions Access appelle l’API revoke user de Cloudflare avec l’adresse e-mail de l’utilisateur et, s’il a été synchronisé, avec son ID utilisateur Cloudflare. Cette action :
  • met fin à toutes les sessions Cloudflare Access actives de l’utilisateur ;
  • révoque les appareils inscrits de l’utilisateur ;
  • oblige l’utilisateur à se réauthentifier auprès de WARP pour les stratégies Gateway qui imposent une durée de session WARP.
Cloudflare ne peut pas annuler une révocation : il n’existe donc pas d’action de libération. L’utilisateur peut se reconnecter dès que votre fournisseur d’identité le permet. Pour empêcher un utilisateur compromis de revenir, désactivez aussi son compte dans votre fournisseur d’identité.

Dépannage