Wie bereits in meinem vorangegangen Blogbeitrag erwähnt, hat die hohe Popularität von SASE und SSE dazu geführt, dass inzwischen sehr viele Anbieter ihr Portfolio mit diesen Begriffen schmücken – teilweise auch unter sehr großzügiger Interpretation der ursprünglich von Gartner definierten Konzepte. Das sorgt zwar bei Interessenten für eine durchaus breite Auswahl. Gleichzeitig entsteht jedoch auch die Herausforderung, das für die individuellen Bedürfnisse optimale Angebot zu finden.
In der Praxis geht der erste Blick dann oftmals zum aktuell im Unternehmen verwendeten Firewallhersteller. Dieser Beitrag soll nun nicht nur eine Antwort auf die Frage liefern, ob dieser erste Impuls immer eine gute Idee ist, sondern auch als allgemeiner Leitfaden für diesen Auswahlprozess dienen. Dabei konzentriere ich mich ganz bewusst nicht auf die einzelnen SASE-Kernkomponenten, da diese je nach Anforderung und Bedarf bei jeder Evaluierung unterschiedlich stark gewichtet und priorisiert werden. Stattdessen fokussiere ich mich auf allgemeinere Kriterien, die erfahrungsgemäß bei jeder Implementierung eine entscheidende Rolle über Erfolg oder Misserfolg spielen und bei der Wahl des richtigen SASE- oder SSE-Providers jedenfalls berücksichtigt werden sollten.

Komponenten einer vollständigen SASE- bzw. SSE-Lösung

Fassen wir zuerst noch einmal kurz zusammen, welche Komponenten eine vollständige SASE- bzw. SSE-Lösung per Definition zwingend beinhalten muss:

• Secure Web Gateway (SWG) (SASE und SSE)
• Cloud Access Security Broker (CASB) (SASE und SSE)
• Next Gen Firewall (NGFW) (SASE und SSE)
• Zero Trust Network Access (ZTNA) (SASE und SSE)
• SD-WAN (nur SASE)

Zusätzlich müssen außerdem noch folgende Eigenschaften erfüllt werden:

• Cloud-nativ
• Zentrale Verwaltung aller Komponenten
• SaaS/fully managed

Leitfaden: Wesentliche Kriterien bei der Evaluierung

Bei jeder Evaluierung sollte ein besonders großes Augenmerk auf die Cloud-Nativität sowie die Möglichkeit zur zentralen und einheitlichen Verwaltung gelegt werden. Diese Eigenschaften sind nämlich unabhängig von der individuellen Gewichtung der einzelnen Kernkomponenten bei jedem Anwendungsfall essenziell. Außerdem hat es sich in der Praxis bewährt, die Infrastruktur und dabei insbesondere das Angebot an PoPs (Points of Presence) des jeweiligen Anbieters in die Entscheidungsfindung mit einfließen zu lassen.

Bedeutung der PoPs für SASE und SSE

PoPs stellen die nächstgelegenen Netzwerknoten dar, mit denen sich die Clients und ganze Bürostandorte mit dem globalen Netzwerk des SASE-Anbieters verbinden. Außerdem werden dort sämtliche Security- und Firewallfeatures wie SWG, CASB, etc. abgebildet. Zur Vereinfachung kann man sich PoPs wie gigantische und nahezu unbegrenzt skalierbare miteinander vernetzte Firewalls/UTMs vorstellen. Diese befinden sich aber nicht an den Perimetern der Unternehmensstandorte, sondern in der Cloud.

Konkret sollten folgende Fragen bei der Auswahl eines passenden SASE-Anbieters evaluiert werden:

Wie viele PoPs gibt es und wo befinden sich diese?

Die Anzahl der PoPs ist aus mehreren Gründen von signifikanter Bedeutung. Zum einen hängt die Latenz entscheidend von der Distanz zum nächsten PoP ab und auch die Ausfallsicherheit erhöht sich durch eine größere Anzahl an PoPs. Eine weitere wichtige Frage ist, ob der jeweilige Anbieter über einen PoP im Land des Unternehmens inklusive nationaler IP-Adresse verfügt. Gerade in kleineren Ländern wie Österreich ist das oftmals nicht der Fall. Wird man stattdessen über einen PoP im Ausland geroutet, kommt es unweigerlich zu unerwünschten Nebeneffekten wie Geoblocking oder falscher Länder- und Spracherkennung auf Websites. Solche Phänomene sollten gerade vor dem Hintergrund einer möglichst hohen Akzeptanz bei den Endbenutzern unbedingt vermieden werden. Eine gute Übersicht über die Anzahl und Standorte der PoPs der populärsten SASE-Anbieter bietet folgende Website: https://sasecloudmap.com/.

Wie bzw. wo werden die PoPs bereitgestellt?

Es gibt drei Möglichkeiten für SASE-Anbieter, um PoPs bereitzustellen.

Public Cloud
Der Public Cloud Ansatz hat den Vorteil für SASE-Anbieter, dass die Implementierungs- und Bereitstellungskosten von allen drei Varianten am geringsten ausfallen. Außerdem kann auf das globale Netzwerk des jeweiligen Public Cloud Anbieters zurückgegriffen werden, ohne sich selbst mit dem Aufbau und der Architektur eines solchen beschäftigen zu müssen. Deshalb wird dieser Ansatz häufig von traditionellen Netzwerk- und Firewallherstellern gewählt, die sich damit schnell und kostengünstig ein globales Netzwerk an PoPs aufbauen wollen.
Es gibt jedoch auch erhebliche Nachteile. Zwar sind die Bereitstellungskosten niedrig, dafür ist aber der Betrieb der PoPs verhältnismäßig teuer, da nicht nur die Compute-Ressourcen, sondern auch der Ingress- und Egress-Traffic teuer bezahlt werden müssen. Außerdem gibt es wenig Transparenz auf der „Middle Mile“, da sich die Public Cloud Anbieter bei ihrem globalen Routing nicht in die Karten schauen lassen. Zu guter Letzt können PoPs auch nur an Standorten angeboten werden, an denen der Public Cloud Anbieter über ein Rechenzentrum verfügt. In Österreich ist das derzeit bei keinem der drei führenden Provider Amazon (AWS), Microsoft (Azure) und Google (GCP) der Fall.

Transit Provider
Der Einsatz von Transit Providern ist ein Mittelweg zwischen Public Cloud und eigener Infrastruktur. Durch das Zurückgreifen auf mehrere Transit Provider und Rechenzentren in Kombination mit eigener Hardware besteht eine höhere Flexibilität bei den Standorten der PoPs. Außerdem ist der Betrieb im Vergleich zur Public Cloud meist günstiger.
Die größten Herausforderungen bestehen bei der initialen Implementierung der PoPs. Zum einen ist der Aufbau im Vergleich zur Public Cloud deutlich kapitalintensiver, da eine gewisse Mindestanzahl an PoPs notwendig ist, damit Latenz und Backhauling nicht zu einem Problem werden. Zum anderen müssen auch komplexe Architekturentscheidungen selbst getroffen werden.

Eigene Infrastruktur
Diese Variante stellt meiner Meinung nach den Königsweg für die Bereitstellung von PoPs dar. Sie ermöglicht die höchste Flexibilität, was die Standorte der PoPs betrifft und bietet volle Transparenz auf der „Middle Mile“. Zusätzlich hat der SASE-Anbieter die alleinige Kontrolle über das Netzwerk, was in der Regel Troubleshooting deutlich vereinfacht und beschleunigt.
Die Nachteile liegen aber ebenso auf der Hand. Der Aufbau ist nicht nur mit sehr hohen Kapital- und Planungsaufwand verbunden, sondern ist auch äußerst zeitintensiv.

Wer ist für den Betrieb der PoPs verantwortlich?

Eigentlich existiert noch eine vierte Variante, wie PoPs bereitgestellt werden können. Und zwar, dass dem Kunden die Verantwortung übertragen wird, seinen eigenen PoP zu hosten. Oftmals wird diese Strategie von SASE-Anbietern als Vorteil verkauft, der zu mehr Flexibilität und Datenschutz führt. Ich persönlich halte davon aber wenig, da ich der Meinung bin, dass SASE und SSE ein cloud-natives „as-a-service“ Produkt sein sollte und Anbieter mit diesem Ansatz oftmals von ihrer eigenen infrastrukturellen Schwäche ablenken wollen.

Sind alle Services in allen PoPs verfügbar?

Es sollte unbedingt abgeklärt werden, ob alle Funktionen und Services in allen PoPs verfügbar sind. Da das nicht bei allen Anbietern der Fall ist.

Gibt es Abhängigkeiten zu bestimmter Hardware?

Insbesondere bei den führenden Firewallherstellern ist es nicht unüblich, dass der volle Funktionsumfang ihrer SASE-Suites nur im Zusammenspiel mit den eigenen Firewall-Appliances zur Verfügung steht. Das ist aus der Sicht der Hersteller natürlich nachvollziehbar, da sie sich nur ungern selbst den eigenen Hauptumsatztreiber abgraben werden wollen. Gleichzeitig ist aber auch unbestritten, dass der klassischen Firewall/UTM am Firmenstandort in der SASE-Vision immer weniger Priorität zukommt. Weitere nicht zu unterschätzende Faktoren bei etwaiger Hardwareabhängigkeit sind höhere initiale Implementierungskosten sowie ein verstärkter Vendor Lock-in-Effekt.

Welches Abrechnungsmodell kommt zur Anwendung?

Am Markt gibt es eine Vielzahl von Abrechnungsmodellen, die sich aus unterschiedlichen Parametern wie Anzahl der Benutzer, Geräte und Standorte, Bandbreite, Datenvolumen, etc. zusammensetzen. Als Faustregel gilt, je weniger Parameter und je geringer die Komplexität, desto einfacher und zuverlässiger ist die Kostenkalkulation und -vorhersage für den Kunden. Im Idealfall erfolgt die Abrechnung ausschließlich auf Basis der Benutzeranzahl. Erfahrungsgemäß tun sich damit Anbieter besonders schwer, die auf eine Public Cloud setzen, da sie selbst mit deutlich dynamischeren Kosten konfrontiert sind.

Kategorien von SASE-Anbietern: Traditionell vs. Cloud-Nativ

Anbieter können grob in eine von zwei Kategorien eingeteilt werden.

Traditionelle Netzwerk- und Firewallhersteller (Cisco, Fortinet, Check Point, etc.)

Die meisten traditionellen Netzwerk- und Firewallhersteller verfolgen SASE- und SSE-Konzepte erst, seitdem Gartner den Begriff definiert und im Markt populär gemacht hat. Aus diesem Grund kämpfen auch alle mit ähnlichen Herausforderungen und Schwächen, denen sie entweder mit dem Zukauf von kleineren Anbietern oder mit dem Ausbau ihrer Infrastruktur in Public Clouds begegnen.

Cloud-native Anbieter (Zscaler, Netskope, Cato, etc.)

Im Gegensatz zu den traditionellen Herstellern haben cloud-native Anbieter viele Ideen und Konzepte von SASE quasi vorweggenommen, bevor der Begriff überhaupt existiert hat. Sie haben somit weniger Schwierigkeiten bei der allgemeinen Umsetzung und konzentrieren sich erfahrungsgemäß mehr um das Ausmerzen von Schwächen bei einzelnen Kernkomponenten in ihrem Angebot sowie den Ausbau ihrer Infrastruktur.

Cloudflare: Ein unterschätzter Player im SSE- und SASE-Umfeld

Cloudflare ist wahrscheinlich vielen bisher ausschließlich als führender Anbieter von Web Application Firewalls (WAF), DDoS-Protection und Content Delivery Networks (CDN) bekannt. Mir ging es persönlich nicht anders. Obwohl ich schon früh von der SASE- und SSE-Idee überzeugt war und deshalb unzählige Lösungen verschiedenster Anbieter getestet habe, bin ich 2021 nur durch einen Zufall (ein Kunde hatte mich auf eine passwordless Promotion von Cloudflare in Kombination mit YubiKeys aufmerksam gemacht) auf das SASE-Angebot von Cloudflare gestoßen. Die anfängliche Neugier ist schnell in Begeisterung umgeschwungen und für mich stand nach kurzer Zeit fest, dass Cloudflare unser bevorzugter SASE-Partner werden muss.

Technische Stärken von Cloudflare

Die Gründe dafür liegen unter anderem in einer einzigartigen technischen Positionierung, die vor allem auf die Wurzeln der Firma in den Bereichen Web Application Security und Performance zurückzuführen sind. Der große Erfolg von Produkten wie CDN und DDoS-Protection haben nämlich dazu geführt, dass Cloudflare über eines der weltweit größten globalen Anycast Netzwerke verfügt mit über 300 PoPs, einer Gesamtbandbreite von 280 Tbit/s und der Möglichkeit, 95% des Internets in unter 50ms zu erreichen. Das sind unglaubliche Zahlen, die vielleicht ein wenig durch dieses Bild veranschaulicht werden können.

Die Positionierung von Cloudflare als SASE-Anbieter

Eine der schwierigsten Grundvoraussetzungen, nämlich der kapitalintensive Aufbau eines eigenen globalen Netzwerkes, wurde somit bereits von Beginn an erfüllt – und zwar in einer Größenordnung, die sich für einen reinen SASE-Anbieter wahrscheinlich nur schwer rechnen würde. Ein weiterer Vorteil ist, dass Cloudflare bei der Entwicklung nie auf interne Altlasten oder eigene Hardwareverkäufe Rücksicht nehmen musste. Mit dem Ergebnis, dass eine Lösung entstanden ist, die auf den modernsten Technologien (WireGuard, MASQUE) basiert und außerdem keinerlei Abhängigkeiten zu bestimmter Hardware mitbringt. Somit steht mit Cloudflare ein herstelleragnostischer Anbieter zur Verfügung, der außerdem noch die am Markt ungewöhnliche Möglichkeit bietet, seine Lösung dauerhaft für bis zu 50 Benutzer kostenfrei zu testen und zu benutzen (mit lediglich leichten Einschränkungen bei den Funktionen).

Vorteile von Cloudflare im Überblick:

• Eines der größten globalen Anycast Netzwerke inklusive österreichischen PoP
• Volle Funktionalität in allen PoPs
• Cloud-nativ
• Moderne Technologien wie WireGuard und MASQUE
• Volle Transparenz auf der „Middle Mile“
• API-first Ansatz
• Keine Abhängigkeiten zu spezifischer Hardware
• Dauerhaft kostenfreie Version für bis zu 50 Benutzer

Fazit: Worauf bei der Auswahl des richtigen SASE-Anbieters geachtet werden sollte

Eine pointierte Zusammenfassung könnte lauten: Nicht überall, wo heute SASE draufsteht, ist auch wirklich SASE drinnen, denn es gibt teilweise große Unterschiede bei der Auslegung des Begriffs zwischen einzelnen Anbietern. Neben den SASE-Kernkomponenten sollte bei einer Evaluierung deshalb unbedingt auch verstärkt auf allgemeine Kriterien wie Infrastruktur und Anzahl der PoPs, zentrale und einheitliche Verwaltung sowie Abrechnungsmodell geachtet werden. Außerdem empfiehlt es sich jedenfalls über den Tellerrand des eigenen Netzwerk- und Firewallherstellers hinauszuschauen und zumindest einen Vergleich mit einem cloud-nativen Anbieter zu wagen.