Cloudflare One ersetzt Hardware-Firewalls

Wir freuen uns, heute neue Funktionen ankündigen zu können, die Kunden den Wechsel von Hardware-Firewall-Appliances zu einer echten cloudnativen Firewall für Netzwerke der nächsten Generation erleichtern. Cloudflare One bietet eine sichere, leistungsfähige und Zero Trust-fähige Plattform, mit der Administratoren einheitliche Sicherheitsrichtlinien für alle Benutzer und Ressourcen anwenden können. Das Beste daran ist, dass die Lösung auf unserem globalen Netzwerk aufbaut, sodass sich Unternehmen keine Gedanken über die Skalierung, Bereitstellung oder Wartung ihrer Edge-Sicherheitshardware machen müssen.

Als Teil dieser Ankündigung hat Cloudflare heute das Oahu-Programm auf den Weg gebracht, um Kunden dabei zu helfen, sich von ihrer alten Hardware zu trennen. In diesem Beitrag werden wir die neuen Funktionen aufschlüsseln, mit denen die Probleme früherer Firewall-Generationen gelöst werden und IT-Teams Zeit und Geld sparen.

Zum besseren Verständnis unseres aktuellen Stands hilft ein kurzer Blick zurück auf die Geschichte von IP-Firewalls.

Anfangs waren Netzwerk-Firewalls hauptsächlich auf die Sicherheitsanforderungen privater Netze ausgerichtet, die nach dem Perimetermodell aufgebaut waren und die wir im gestrigen Beitrag als die erste Generation definiert haben. Firewall-Administratoren konnten Richtlinien auf Grundlage von Signalen erstellen, die auf den Schichten 3 und 4 des OSI-Modells (in erster Linie IPs und Ports) verfügbar waren. Das war ideal, um beispielsweise einer Gruppe von Mitarbeitern in einem Stockwerk eines Bürogebäudes den Zugriff auf Server in einem anderen Stockwerk über ein LAN zu ermöglichen.

Diese Fähigkeit zur Paketfilterung war ausreichend, bis die Netzwerke unter anderem durch den Anschluss an das Internet komplexer wurden. Die IT-Abteilungen begannen, ihr Unternehmensnetzwerk vor externen Angreifern zu schützen, was ausgefeiltere Richtlinien erforderte.

Firewall-Hardware wurde weiterentwickelt und deckte fortan die zustandsbehaftete (Stateful) Paketinspektion und die ersten Schritte der Deep Packet Inspection ab. So wurde das Grundmodell dahingehend erweitert, dass die Firewall den Zustand der sie passierenden Verbindungen erfasst. Unter anderem haben Administratoren dadurch beispielsweise die Möglichkeit, alle eingehenden Pakete zu blockieren, die nicht mit einer bereits bestehenden ausgehenden Verbindung verknüpft sind.

Diese neuen Funktionen boten einen ausgeklügelteren Schutz vor Angreifern. Doch der Fortschritt hatte seinen Preis: Die Unterstützung dieses höheren Sicherheitsniveaus erforderte mehr Rechen- und Speicherressourcen. Somit mussten die Sicherheits- und Netzwerkteams die benötigte Kapazität für jede neue Appliance besser planen und Abwägungen zwischen Netzwerkkosten und -redundanz treffen.

Darüber hinaus boten diese neuen Firewalls nur einen beschränkten Einblick in die Art der Netzwerknutzung. Man konnte sehen, dass Benutzer über Port 80 auf 198.51.100.10 zugriffen. Um allerdings herauszufinden, worauf sie genau zugriffen, hätte eine inverse Anfrage (Reverse Lookup) zur Ermittlung des Namens der IP-Adresse durchgeführt werden müssen. Doch auch dies würde lediglich zur Startseite des Providers führen. Man wüsste weder, worauf genau zugegriffen wurde, noch würde man den Reputationsstatus der Domain/des Hosts kennen. Man würde auch keine anderen Informationen erhalten, die Aufschluss darüber geben würden, ob es sich um einen Sicherheitsvorfall handelt, dem nachgegangen werden muss. Die Ermittlung des Datenursprungs würde sich ebenfalls schwierig gestalten, da eine mittels DHCP vergebene private IP-Adresse einem Gerät und anschließend einem Benutzer zugeordnet werden müsste (sofern lange Lease-Zeiten festgelegt und Geräte niemals von mehreren Usern gemeinsam genutzt wurden).

Um diesen Herausforderungen zu begegnen, führte die Branche Firewalls der nächsten Generation (Next Generation Firewall – NGFW) ein. Diese Geräte waren lange Zeit und sind in einigen Fällen auch heute noch Standard für die Edge-Sicherheit von Unternehmen. Sie umfassten alle Funktionen der vorherigen Generationen und wurden um Anwendungserkennung ergänzt, damit Administratoren über eine bessere Kontrolle darüber verfügen, was ihren Sicherheitsperimeter durchläuft. NGFWs führten das Konzept der vom Hersteller oder extern bereitgestellten Anwendungsinformationen ein, was die Identifizierung einzelner Anwendungen anhand von Traffic-Merkmalen erlaubt („Application Awareness”). Diese Informationen können dann in Richtlinien einfließen, anhand derer festgelegt wird, was Benutzer mit einer bestimmten Anwendung tun können und was nicht.

Mit zunehmender Verlagerung von Anwendungen in die Cloud begannen die NGFW-Anbieter, virtualisierte Versionen ihrer Appliances bereitzustellen. Die Administratoren mussten sich so keine Gedanken mehr über die Auslieferungszeiten der nächste Hardwareversion machen und waren bei Implementierungen an mehreren Standorten flexibler.

Im Lauf der Jahre entwickelte sich die Bedrohungslandschaft weiter und die Netzwerke wurden immer komplexer. Daher wurden NGFWs um Sicherheitsfunktionen erweitert, von denen einige die Konsolidierung von Appliances erleichtern. Dazu gehören je nach Anbieter VPN-Gateways, IDS/IPS, Web Application Firewalls und sogar Optionen wie Bot-Management und DDoS-Schutz. Aber selbst mit diesen Funktionen hatten NGFWs ihre Nachteile. Administratoren mussten immer noch Zeit für das Entwickeln und Konfigurieren redundanter (zumindest primärer/sekundärer) Appliances aufwenden. Außerdem mussten sie entscheiden, welche Standorte mit Firewalls ausgestattet werden und somit durch das Umleiten des Traffics von anderen Standorten Performance-Einbußen erleiden. Darüber hinaus war beim Erstellen von Richtlinien zur Pseudonymisierung weiterhin eine sorgfältige Verwaltung der IP-Adressen erforderlich.

Mit der Einführung immer raffinierterer Firewall-Kontrollen vollzog sich ein Paradigmenwechsel im Bereich Netzwerkarchitektur, um Sicherheitsbedenken Rechnung zu tragen, die sich aus der Verlagerung von Anwendungen und Benutzern vom Unternehmensperimeter in das Internet ergaben. Zero Trust-Sicherheit bedeutet, dass niemandem innerhalb oder außerhalb des Netzwerks blindes Vertrauen geschenkt wird und jeder überprüft werden muss, der versucht, auf Ressourcen im Netzwerk zuzugreifen. Zunehmend hielten Zero Trust-Grundsätze bei Firewalls Einzug, da Identitätsanbieter (Identity Providers – IdPs) integriert wurden und man den Usern die Erstellung von Richtlinien für Benutzergruppen ermöglichte, um beispielsweise die Zugriffsrechte für die Gehaltsabrechnungssysteme auf die Finanz- und Personalabteilung zu beschränken. Dies erlaubte eine präzisere Kontrolle und verringerte die Abhängigkeit von IP-Adressen zur Eingrenzung der Identität.

Diese Richtlinien haben Unternehmen dabei geholfen, ihre Netzwerke abzusichern und sich dem Zero Trust-Ideal anzunähern. Damit sind aber noch längst nicht alle Probleme der CIOs gelöst: Was passiert etwa, wenn der Identitätsanbieter eines anderen Unternehmens integriert werden muss? Wie gewähren sie Auftragnehmern sicheren Zugang zu Unternehmensressourcen? Solche neuen Kontrollen bieten auch keine Antwort auf die grundlegenden Probleme bei der Verwaltung von Hardware. Diese bestehen nach wie vor und werden immer komplexer, wenn Unternehmen Standorte hinzufügen oder entfernen, hybride Arbeit einführen oder andere geschäftliche Veränderungen vornehmen. Gefragt sind zukunftsfähige Gesamtkonzepte für Firmennetzwerke anstelle eines Flickwerks von Einzellösungen, die jeweils die Anforderungen nur in Teilen erfüllen.

Durch die Bündelung von Netzwerkkonnektivität und Zero Trust-Sicherheit unterstützt Cloudflare Kunden beim Aufbau zukunftsfähiger Firmennetzwerke. Kunden, die sich für die Plattform Cloudflare One entscheiden, können ihre Hardware-Firewalls abschaffen und stattdessen einen cloudnativen Ansatz verfolgen. So beseitigen sie die Probleme der vorherigen Generation und machen ihren IT-Abteilungen das Leben leichter.

Anstatt verschiedene Geräte für unterschiedliche Anwendungsfälle zu verwalten, sollte der gesamte Traffic in einem Netzwerk – von Rechenzentren, Büros, cloudbasierten Websites und Anwendungen sowie Endnutzergeräten – durch eine einzige umfassende Firewall geleitet werden können. Cloudflare One bietet eine Vielzahl flexibler Methoden, um sich mit dem Cloudflare-Netzwerk zu verbinden, unter anderem über Tunnel auf Netzwerkschicht (per GRE- oder IPsec) oder Anwendungsschicht, über direkte Verbindungen oder mit BYOIP und einem Geräte-Client. Die Anbindung an Cloudflare bedeutet Zugang zu unserem gesamten globalen Netzwerk, wodurch viele der mit physischer oder virtualisierter Hardware einhergehenden Hindernisse beseitigt werden.

• Keine Kapazitätsplanung: Die Kapazität Ihrer Firewall entspricht der des globalen Cloudflare-Netzwerks (derzeit mehr als 100 Tbit/s, Tendenz steigend).

• Keine Standortplanung: Dank der Anycast-Netzwerkarchitektur von Cloudflare wird der Traffic automatisch an den Standort geleitet, der seinem Ursprung am nächsten liegt. Unternehmen müssen keine Regionen mehr auswählen oder sich Gedanken darüber machen, wo sich ihre Primär-/Backup-Appliances befinden – Redundanz und Failover sind standardmäßig integriert.

• Keine wartungsbedingten Ausfallzeiten: Verbesserungen der Firewall-Funktionen von Cloudflare werden, wie bei allen unseren Produkten, kontinuierlich in unserem globalen Netzwerk implementiert.

• Integrierter DDoS-Schutz: Es besteht keine Gefahr, dass DoS-Angriffe die Firewalls einreißen. Das Netzwerk von Cloudflare blockiert Attacken automatisch in der Nähe ihres Ursprungs und leitet nur unverdächtigen Traffic an sein Ziel weiter.

Cloudflare One-Richtlinien können verwendet werden, um den Datenverkehr von Unternehmen für sämtliche Verbindungsmöglichkeiten abzusichern und zu routen. Diese Richtlinien können mit denselben Attributen erstellt werden, die auch bei einer herkömmlichen NGFW verfügbar sind. Sie werden durch Zero Trust-Merkmale ergänzt, etwa die Integration von einem oder mehreren IdP oder Anbietern von Endpunktsicherheit.

Konzentriert man sich ausschließlich auf die Schichten 3 bis 5 des OSI-Modells, können Richtlinien anhand von IP, Port, Protokoll und anderen Merkmalen sowohl auf zustandslose als auch auf zustandsbehaftete Weise angewandt werden. Diese Attribute können in Kombination mit einem der Identitätsattribute und dem Geräte-Client von Cloudflare auch verwendet werden, um ein privates Netzwerk auf Cloudflare aufzusetzen.

Zur leichteren Verwaltung von IP-Zulassungs-/Blockierlisten bietet Cloudflare außerdem eine Reihe von verwalteten Listen, die sowohl auf zustandslose als auch auf zustandsbehaftete Richtlinien angewendet werden können. Es können aber auch anspruchsvollere Aufgaben wie Deep Packet Inspection und das Erstellen programmierbarer Paketfilter ausgeführt werden, um ein positives Sicherheitsmodell durchzusetzen und die größten Angriffe zu durchkreuzen.

Die Erkenntnisse von Cloudflare fließen in die Anwendungs- und Inhaltskategorien für unsere Layer-7-Richtlinien ein, mit denen Benutzer vor Sicherheitsbedrohungen geschützt, Datenexfiltrationen verhindert und die Nutzung von Unternehmensressourcen überprüft werden können. Dies beginnt mit unserem geschützten DNS-Resolver, der auf unserem leistungsstarken 1.1.1.1-Service für Verbraucher aufbaut. Mit dem geschützten DNS können Administratoren ihre Benutzer davor bewahren, bekannte oder potenzielle Sicherheitsrisiken anzusteuern oder sich ihnen durch DNS-Auflösung auszusetzen. Nach einer Domain-Auflösung können Administratoren mithilfe von HTTP-Richtlinien den Traffic eines Benutzers abfangen, überprüfen und filtern. Wenn es sich um selbst gehostete oder SaaS-fähige Webanwendungen handelt, können diese sogar mit einer Cloudflare-Zugangsrichtlinie geschützt werden, die als webbasierter Identitätsproxy fungiert.

Zu guter Letzt können Administratoren den Zugriff auf externe HTTP-Anwendungen mithilfe der Remote-Browserisolierung sperren, um Datenexfiltrationen einen Riegel vorzuschieben. In Kürze werden Administratoren außerdem in der Lage sein, die Befehle zu protokollieren und zu filtern, die ein Benutzer bei einer SSH-Sitzung ausführen kann.

Bei herkömmlichen Firewalls mussten zur Unterstützung dieses Prozesses Richtlinien auf jedem Gerät implementiert oder Orchestrierungstools konfiguriert und gepflegt werden. Im Gegensatz dazu können bei Cloudflare Richtlinien für unser gesamtes Netzwerk über ein einfaches Dashboard oder eine API verwaltet werden. Außerdem lässt sich mithilfe von Terraform Infrastruktur als Code bereitstellen. Änderungen werden dank unserer Quicksilver-Technologie in Sekundenschnelle über das Netzwerk verbreitet. Benutzer erhalten anhand von Protokollen, die jetzt konfigurierbar sind, Einblick in den die Firewall passierenden Datenverkehr.

Firewalls müssen eine Vielzahl von Aufgaben ausführen, um unterschiedlichen Sicherheitsanforderungen gerecht zu werden. Dazu gehören das Blockieren von unerwünschtem eingehendem Traffic, das Filtern von ausgehenden Verbindungen, um sicherzustellen, dass Mitarbeiter und Anwendungen nur auf sichere Ressourcen zugreifen, und die Überprüfung interner („Ost/West“) Traffic-Ströme zur Durchsetzung des Zero Trust-Prinzips. Unterschiedliche Hardware deckt oft einen oder mehrere Anwendungsfälle an verschiedenen Standorten ab; wir halten es für sinnvoll, diese so weit wie möglich zu konsolidieren, um die Benutzerfreundlichkeit zu verbessern und eine Single Source of Truth für Firewall-Richtlinien zu schaffen. Im Folgenden wird auf einige traditionelle Anwendungsfälle für Hardware-Firewalls eingegangen und erläutert, wie IT-Teams ihnen mit Cloudflare One gerecht werden können.

Traditionell mussten IT-Teams mindestens eine Hardware-Firewall pro Bürostandort (und mehrere zur Gewährleistung von Redundanz) bereitstellen. Dies machte es erforderlich, das Volumen des Datenverkehrs in einer bestimmten Filiale vorherzusagen und Geräte zu bestellen, zu installieren und zu warten. Jetzt können Kunden den Traffic von Zweigstellen an Cloudflare übertragen, unabhängig davon, welche Hardware sie bereits einsetzen – jeder GRE oder IPsec unterstützende Standard-Router ist dafür geeignet. Außerdem haben sie die Möglichkeit, die Filterrichtlinien für das gesamte Datenaufkommen über das Cloudflare-Dashboard zu steuern.

Schritt 1: Einrichten eines GRE- oder IPsec-TunnelsDie meisten gängigen Hardware-Anbieter unterstützen GRE und/oder IPsec als Tunneling-Methode. Cloudflare stellt eine Anycast-IP-Adresse zur Verfügung, die von uns als Tunnelendpunkt verwendet wird. Auf der Gegenseite wird ein Standard-GRE- oder IPsec-Tunnel ohne zusätzliche Schritte konfiguriert – die Anycast-IP bietet eine automatische Anbindung an jedes Cloudflare-Rechenzentrum.

Schritt 2: Firewall-Regeln für die Netzwerkschicht konfigurierenDer gesamte IP-Traffic kann durch die Magic Firewall gefiltert werden, mit der sich Richtlinien auf Grundlage beliebiger Paketmerkmale erstellen lassen, z. B. Ursprungs- oder Ziel-IP, Port, Protokoll, Land oder Bitfeld-Zuordnung. Außerdem können IP-Listen in die Magic Firewall integriert werden, die darüber hinaus erweiterte Funktionen wie programmierbare Paketfilterung bietet.

Schritt 3: Traffic auf Anwendungsebene für Firewall-Regeln „aufrüsten“Hat TCP- und UDP-Traffic die Magic Firewall erst einmal passiert, kann er für eine gründlichere Filterung durch Cloudflare Gateway „aufgerüstet“ werden. Dieses Upgrade schaltet ein ganzes Spektrum an Filterfunktionen frei, darunter Anwendungs- und Inhaltserkennung, Identitätsdurchsetzung, SSH-/HTTP-Proxying und DLP.

Firewalls, die für die Verarbeitung von Daten bei einem Firmensitz oder Rechenzentrum mit hohem Traffic eingesetzt werden, können zu den größten Posten im Budget einer IT-Abteilung gehören. Traditionell wurden Rechenzentren durch leistungsstarke Appliances geschützt, die zwar umfangreiche Volumina problemlos bewältigen können, aber auch höhere Kosten verursachen. Bei der Architektur von Cloudflare kann sich jeder Server in unserem Netzwerk die Verantwortung für die Verarbeitung des Kunden-Traffics mit anderen teilen, sodass einzelne Geräte weder Engpässe verursachen können noch teure Spezialkomponenten benötigen. Kunden können den Traffic mit BYOIP, einem Standard-Tunnel-Mechanismus oder Cloudflare Network Interconnect an Cloudflare weiterleiten und Datenverkehr mit bis zu einem Terabit pro Sekunde anhand von Firewall-Regeln reibungslos verarbeiten.

Bei herkömmlichen Netzwerkarchitekturen bauen Benutzer mit ihren Geräten eine VPN-Verbindung zu einem zentralen, durch Firewalls geschützten Standort auf, um auf Firmenressourcen zuzugreifen oder einen sicheren Internetzugang zu erhalten. Dort wird ihr Traffic verarbeitet, bevor er an sein endgültiges Ziel weitergeleitet wird. Dieses Modell bringt jedoch Performance-Einbußen mit sich. Außerdem ermöglichen moderne Firewalls zwar Kontrollen auf Benutzerebene, die Anforderungen des Zero Trust-Prinzips erfüllen sie damit aber nicht unbedingt. Cloudflare ermöglicht es Kunden, einen Geräte-Client als Einstieg in Zero Trust-Richtlinien zu verwenden. Achten Sie im Laufe dieser Woche auf weitere Beiträge dazu, wie Sie den Client auch in großem Maßstab reibungslos einsetzen können.

Wir können es kaum erwarten, diese Plattform für neue Anwendungsfälle weiterzuentwickeln. Bei uns haben sich Kunden gemeldet, die Interesse an einer Erweiterung der NAT-Gateway-Funktion durch Cloudflare One, tiefergehenden Analysen, Berichten und einer Überwachung der Benutzererfahrung für alle unsere Firewall-Funktionen haben und sich darauf freuen, das vollständige Spektrum von DLP-Funktionen für ihren gesamten durch das Cloudflare-Netzwerk geleiteten Traffic zu implementieren. Updates zu diesen und weiteren Themen folgen in Kürze – halten Sie also am Besten die Augen offen.

Ab heute sind neue Firewall-Funktionen für Firmenkunden verfügbar. Sie können sich hier näher informieren und einen Blick auf das Oahu-Programm werfen, um zu erfahren, wie die Umstellung von Hardware-Firewalls auf ein Zero Trust-Modell gelingt. Sie möchten gleich heute loslegen? Dann wenden Sie sich an Ihren Kundenbetreuer.