Cloudflare Gateway führt jetzt Ihren Code inline für benutzerdefinierte Sicherheitslogik aus

Cloudflare hat eine wesentliche Erweiterung seiner Zero-Trust-Plattform angekündigt, die es Entwicklern ermöglicht, benutzerdefinierten Code direkt innerhalb des Auswertungspfads der Secure Web Gateway-Richtlinie auszuführen. Dieses Update, veröffentlicht am 15. Oktober 2026, integriert Cloudflare Workers mit den Diensten Gateway und Data Loss Prevention (DLP), sodass beliebige Logik an der Netzwerkkante inline ausgeführt werden kann.

Was passiert ist

Seit Jahrzehnten arbeiten Secure Web Gateways nach einem starren Modell: Der Verkehr entspricht einer vordefinierten Bedingung, und das System führt eine finale Aktion wie Zulassen, Blockieren oder Protokollieren aus. Obwohl dies für Standardanwendungsfälle effektiv ist, stößt dieser Ansatz bei komplexen, umgebungsspezifischen Anforderungen an seine Grenzen. Sicherheitsteams stehen oft vor der binären Wahl zwischen der Wartung kostspieliger, benutzerdefinierter Proxy-Infrastrukturen für maximale Flexibilität oder der Akzeptanz von Anbieterbeschränkungen, die ihre Fähigkeit einschränken, einzigartige Probleme zu lösen.

Um dies anzugehen, führt Cloudflare zwei neue Funktionen ein: die Forward-Aktion und Custom Functions. Die Forward-Aktion, die heute in der öffentlichen Beta verfügbar ist, leitet abgeglichene HTTP-Anfragen an einen Cloudflare Worker weiter, der als Inline-Middleware fungiert. Dies ermöglicht es Entwicklern, Header zu ändern, Anfragekörper zu transformieren oder asynchrone Aktionen wie die Protokollierung in externe Systeme auszulösen, bevor der Traffic sein Ziel erreicht. Custom Functions, deren Veröffentlichung noch vor Jahresende geplant ist, werden es Workers ermöglichen, typisierte Werte während der Richtlinienauswertung zurückzugeben, wodurch dynamische Selektoren basierend auf internen Daten oder komplexer Logik erstellt werden.

Diese Integration nutzt die bestehende Infrastruktur von Cloudflare, auf der Gateway und Workers auf denselben Maschinen in über 330 globalen Standorten laufen. Da die Weiterleitung ein lokaler Funktionsaufruf ist und kein Netzwerk-Hop, entsteht keine zusätzliche Latenz durch das Umleiten des Traffics in eine separate Cloud-Umgebung. Diese Architektur zielt darauf ab, die Anpassungsmöglichkeiten selbst gehosteter Proxies ohne den operativen Aufwand der Infrastrukturverwaltung bereitzustellen.

Wie es funktioniert

Die Forward-Aktion verwandelt einen Cloudflare Worker in einen programmierbaren Proxy. Wenn eine Gateway-Richtlinie eine Anfrage abgleicht, leitet sie den vollständigen HTTP-Kontext – einschließlich Header und Body – an den angegebenen Worker weiter. Der Worker kann die Anfrage untersuchen, sie modifizieren und sie dann über die Funktion next() nach upstream weitergeben. Er kann auch die Antwort ändern, bevor sie an den Benutzer zurückgegeben wird. Gateway übernimmt die zugrunde liegenden TCP-Verbindungen, die TLS-Terminierung und das Zertifikatsmanagement, während sich der Worker ausschließlich auf die Anwendungslogik konzentriert.

Custom Functions funktionieren anders, indem sie sich direkt in die Entscheidungsengine der Richtlinie integrieren. Ein Worker erhält Kontextinformationen wie Quell-IP, Benutzeridentität und Gerätezustand und gibt dann eine einfache Zeichenkette, Zahl oder einen booleschen Wert zurück. Dieser Rückgabewert wird zu einem neuen Selektor im Gateway-Richtlinien-Builder. Beispielsweise könnte eine Funktion ein JSON Web Token parsen, um die Rolle eines Benutzers zu extrahieren und sie als Zeichenkette zurückzugeben. Administratoren können dann Regeln wie "Zulassen, wenn Custom Function Role gleich finance_contractor" schreiben, wobei eingebaute Selektoren mit benutzerdefinierten, berechneten Daten kombiniert werden.

Wichtige Details

• Forward Action: Leitet abgeglichenen HTTP-Traffic an einen Worker zur Inline-Transformation weiter, verfügbar in der öffentlichen Beta ab dem 15. Oktober 2026.
• Custom Functions: Ermöglicht es Workers, typisierte Werte für die Verwendung in Richtlinienbedingungen zurückzugeben; erwartetet Launch vor Ende 2026.
• Keine Latenz-Overhead: Die Weiterleitung an einen Worker ist ein lokaler Funktionsaufruf auf derselben Maschine, was Netzwerk-Roundtrips vermeidet.
• Universelle Verfügbarkeit: Beide Funktionen werden in allen Zero-Trust-Plänen verfügbar sein, einschließlich Free-, Paid- und Enterprise-Tiers.
• Abrechnung: Traffic, der an Workers weitergeleitet wird, wird als standardmäßige Worker-Anfragen abgerechnet, unterliegt den bestehenden Limits für Ausführungszeit und tägliche Anfragen.
• Fallback-Sicherheit: Custom Functions erfordern Standardwerte, um deterministisches Verhalten sicherzustellen, falls der Code fehlschlägt oder ein Timeout auftritt.

Warum es wichtig ist

Für Software-Ingenieure und Security-Leads eliminiert diese Verschiebung die Notwendigkeit, separate NGINX-Proxies oder komplexe Webhook-Pipelines für geringfügige Traffic-Transformationen bereitzustellen und zu warten. Aufgaben, die früher den Aufbau dedizierter Infrastruktur erforderten – wie das Injizieren von HTTP-Headern basierend auf JWT-Claims oder das Erstellen von Audit-Trails für sensiblen Zugriff – können nun mit wenigen Zeilen TypeScript in einem Worker erledigt werden. Dies reduziert operative Schulden und beschleunigt die Implementierung von Sicherheitsrichtlinien, die spezifisch auf die internen Tools und Workflows einer Organisation zugeschnitten sind.

Die Möglichkeit, beliebigen Code inline auszuführen, verbessert auch die Echtzeit-Reaktionsfähigkeit. Anstatt sich auf verzögerte Logs zu verlassen, die zur Alarmierung an ein SIEM gesendet werden, kann eine Forward-Aktion sofortige Benachrichtigungen an Slack oder PagerDuty auslösen, wenn eine DLP-Regel ausgelöst wird. Darüber hinaus ermöglichen Custom Functions differenziertere Zugriffssteuerungen, indem externe Datenquellen, wie interne Risikobewertungssysteme, direkt in den Entscheidungsprozess der Firewall einbezogen werden, ohne diese Systeme dem öffentlichen Internet auszusetzen.

Was Sie tun können

• Evaluieren Sie die öffentliche Beta der Forward-Aktion, um Inline-Header-Injektion oder Anfrage-Modifikation für Ihre internen Anwendungen zu testen.
• Identifizieren Sie aktuelle manuelle Proxy-Aufgaben, wie JWT-Parsing oder benutzerdefiniertes Logging, die zu Cloudflare Workers migriert werden könnten.
• Entwerfen Sie Custom Functions, die sich mit internen Datenbanken oder APIs integrieren, um dynamische Richtlinien-Selektoren basierend auf Echtzeit-Benutzerkontext zu erstellen.
• Überprüfen Sie Ihre bestehenden DLP-Richtlinien, um festzustellen, wo benutzerdefinierte Validierungslogik False Positives reduzieren kann, indem die Datenrelevanz gegen interne Aufzeichnungen geprüft wird.
• Überwachen Sie Worker-Ausführungslimits und Kosten, insbesondere wenn Sie planen, hochvolumigen Traffic über Forward-Aktionen zu routen.
• Bereiten Sie sich auf die Veröffentlichung von Custom Functions zum Jahresende vor, indem Sie komplexe Auswertungslogik kartieren, die derzeit externe Nachverarbeitung erfordert.