Cloudflare a annoncé l’intégration de Cloudflare Gateway et de Data Loss Prevention à la plateforme de calcul périphérique Cloudflare Workers, une étape qui fait passer la passerelle web sécurisée d’un modèle de décisions statiques, comme l’autorisation, le blocage et l’isolation, à l’exécution de code personnalisé directement dans le flux d’évaluation de la politique de sécurité.
Cette intégration est disponible pour les offres Zero Trust et propose deux méthodes principales pour appeler un Worker depuis les politiques Gateway : une nouvelle action appelée Forward, actuellement disponible en version bêta publique, et les Custom Functions, dont le lancement est prévu avant la fin de l’année 2026.
Transférer les requêtes ou exécuter une logique personnalisée
L’action Forward fonctionne comme un intermédiaire inline pour les requêtes correspondant à la politique. Le Worker reçoit les en-têtes et le corps de la requête HTTP et peut les modifier avant leur envoi au service d’origine, puis modifier la réponse avant de la renvoyer à l’utilisateur. Gateway prend en charge les connexions TCP, la terminaison TLS, le chiffrement à nouveau, la gestion des certificats et la négociation de la version HTTP, ce qui laisse au Worker uniquement la logique de transformation.
Forward peut également servir à exécuter des actions secondaires sans interrompre le flux de la requête, comme envoyer une alerte à Slack ou PagerDuty, enregistrer les données dans R2, appeler un webhook ou mettre à jour un magasin KV. Cloudflare indique que l’appel du Worker s’effectue sur l’infrastructure qui exécute Gateway, au moyen d’un appel local ne nécessitant pas de faire transiter le trafic par un réseau distinct.
Les Custom Functions appellent quant à elles un Worker pendant l’évaluation de la politique et renvoient une valeur de type texte, nombre ou booléen. Cette valeur peut être utilisée comme sélecteur dans les politiques HTTP ou réseau. Le Worker peut recevoir un contexte comprenant l’adresse IP source, l’identité de l’utilisateur, l’état de l’appareil, les en-têtes HTTP et les données de connexion, selon l’étape de la politique.
Exemples d’utilisation
Cloudflare explique qu’une fonction personnalisée peut lire une revendication JWT et extraire le rôle ou le groupe de l’utilisateur, puis utiliser le résultat pour autoriser l’accès ou ajouter un en-tête tel que X-App-Role à la requête destinée au service d’origine. Il est également possible de créer des pages d’interception demandant à l’utilisateur de justifier l’accès à une destination sensible, tout en conservant la session dans KV et le journal d’audit dans D1 ou dans une base de données interne via Hyperdrive.
Les autres cas d’utilisation comprennent l’analyse de fichiers au moyen d’un service sandbox externe, l’envoi d’alertes instantanées lorsqu’une règle DLP correspond, ainsi que l’exécution de calculs de risque reposant sur plusieurs sources internes. Cloudflare distingue clairement les deux méthodes : les Custom Functions conviennent aux évaluations rapides, ciblées et sans état, tandis que Forward vise le transfert de requêtes en direct ainsi que le traitement de la requête et de la réponse.
Étendre les capacités de DLP
Cloudflare a également annoncé la disponibilité de fonctions de validation personnalisées pour DLP. Ces fonctions permettent aux clients d’utiliser leur propre source de vérité afin de vérifier le résultat de la détection avant de prendre une décision d’application. Il peut s’agir, par exemple, de vérifier si une clé GitHub détectée est effectivement active, plutôt que de se limiter à faire correspondre un motif ressemblant à un secret ou à un jeton.
La fonction de validation reçoit un extrait des données ainsi que l’emplacement de la partie correspondante. Elle peut ensuite appeler une interface externe et renvoyer un résultat comprenant un score de correspondance ou une décision de veto. Il devient ainsi possible de faire la distinction entre la présence d’un motif sensible et le fait que le cas précis constitue une fuite réelle ou un usage non autorisé.
Qu’est-ce qui change concrètement ?
Cloudflare cherche à réduire le besoin d’une infrastructure intermédiaire gérée par les équipes de sécurité, comme des groupes NGINX utilisés uniquement pour lire des revendications JWT ou modifier des en-têtes. Cette nouvelle flexibilité transfère toutefois une partie de la responsabilité au code du client : les applications utilisant Forward doivent être conçues avec soin afin de ne pas nuire à l’expérience utilisateur, tandis que l’échec d’une Custom Function ou l’expiration de son délai d’exécution nécessite de définir à l’avance un comportement de secours.
Le trafic transféré vers Workers est comptabilisé comme des requêtes Workers ordinaires. Les fonctions fonctionnent avec Workers Free, Workers Paid et Workers for Enterprise, mais l’offre gratuite impose des limites sur la durée d’exécution et le nombre quotidien de requêtes. Cloudflare indique que la disponibilité générale des deux méthodes concernera tous les clients et tous les types d’offres, tandis que l’entreprise prévoit d’étendre les points d’intégration au sein de la suite Cloudflare One, avec Email Security comme prochaine étape.