everythingpossible - stock.adobe
Wie Sie eine skalierbare SASE-Architektur sicherstellen
SASE-Architekturen unterscheiden sich durchaus, insbesondere in puncto Skalierbarkeit. So gilt es etwa, die Entfernung zu Anbieter-PoPs und das Agent Onboarding zu berücksichtigen.
Wir leben in einer Zeit, in der sich unser traditioneller Perimeter – Büro, Firewalls, VPN-Konzentratoren, Switches, Router und Hochverfügbarkeit – langsam auflöst. Es kommt zu einer Verlagerung hin zu Remote-Arbeit und Home-Office, die durch die COVID-19-Pandemie und eine beschleunigte Transformation zur Gig-Ökonomie erzwungen wird.
Wir sind mit einer tektonischen Verschiebung im Bereich der IT- und Unternehmenssicherheit konfrontiert. Daher benötigen Unternehmen jetzt eine alternative, vertrauenswürdige und skalierbare Möglichkeit, um den Zugriff auf digitale Ressourcen am Arbeitsplatz zu gewährleisten. Diese Umstände bieten die Chance, eine wachsende Marktlücke mit einfachen, innovativen und flexiblen Optionen zu füllen.
An dieser Stelle kommt Secure Access Service Edge (SASE) ins Spiel. Sehen wir uns zunächst einige Grundlagen für die SASE-Architektur an.
Da sich bei SASE alles um Cloud-Transformation und As-a-Service-Modelle dreht, müssen Kunden dem Anbieter vertrauen und den Betrieb, die Sicherheit, Service Level Agreements (SLA), Redundanz und Skalierbarkeit an die Plattform des Anbieters delegieren. Dazu gehört ebenfalls die Einhaltung aller für sie relevanten Vorschriften.
SASE-Plattformen bestehen aus den folgenden vier Hauptkomponenten:
- Cloud Access Security Broker (CASB) oder Data Leak Prevention;
- Cloud-Web-Gateway oder Firewall as a Service für die Kontrolle des ausgehenden Datenverkehrs;
- Zero-Trust-Netzwerkzugriff für Remote Access; und
- Software-defined WAN (SD-WAN), das in vielen Fällen die physische durch eine virtuelle Verbindung ersetzt.
Die ersten drei Komponenten der SASE-Architektur sind Services, während die letzte, SD-WAN, dafür verantwortlich ist, den Traffic zu diesen Diensten zu transportieren.
Aufbau einer skalierbaren SASE-Architektur
Aber wie bauen Anbieter SASE-Plattformen auf, um die erforderliche Skalierbarkeit zu erreichen? Wir betrachten nachfolgend sieben Faktoren, die eine skalierbare SASE-Architektur unterstützen.
1. Points of Presence (PoP)
Anbieter nutzen Points of Presence, um eine geografische Verteilung von Data Centern zu erreichen, wo auch immer sich die PoPs befinden. Anbieter können private PoPs besitzen oder Public-Cloud-Services nutzen, wie AWS, Azure und Google Cloud Platform. Jeder Typ bietet unterschiedliche Vorteile. In einem Private Data Center zum Beispiel entscheidet der SASE-Anbieter über Computing, Hardware, Virtualisierungstechnologie, Kosten und SLAs. In einer Public Cloud ist der SASE-Anbieter stärker an Public-Cloud-SLAs und die vom Provider eingesetzte Art der Virtualisierungstechnologie gebunden sowie durch dessen Standorte eingeschränkt.
2. Technologie-Stack des Anbieters
In den meisten Fällen verwenden SASE-Anbieter zwei populäre Technologie-Stacks:
- Cloud-VMs, die sowohl vertikal mithilfe größerer Compute-Instanzen als auch horizontal über die Lastverteilung mehrerer kleiner Instanzen skalieren können; und
- Container für die Skalierung pro Kunde.
SASE-Anbieter, die im CASB-Bereich tätig sind und API-Verbindungen zu SaaS-Providern herstellen müssen, werden wahrscheinlich die Container-Methode nutzen.
Die Anbieter routen den Traffic von ihrem Data Center aus, indem sie einen Backbone verwenden oder den Datenverkehr nach Überprüfung an das Ziel weiterleiten. Bestimmte Anbieter nutzen die Architektur ihres globalen Backbones, um den Traffic über das Web zu leiten und das Routing zu optimieren. Auf ähnliche Weise verwenden ISPs ihre Internet-Backbones. Bei dieser Methode kümmert sich der Anbieter ab dem Moment um den Traffic, in dem ein Benutzer den nächstgelegenen PoP erreicht. Dieser Ansatz kann je nach Ziel des Traffics die Latenz verringern und die Geschwindigkeit bestimmter Vorgänge, etwa Dateiübertragungen, verbessern. Er kann aber auch das Routing und die Skalierbarkeit dieser Funktionalität erschweren.
Jeder Provider bietet seine eigenen SLAs und Geschwindigkeiten an. Es liegt somit in der Verantwortung der Kunden, die SLAs zu überprüfen und sicherzustellen, dass diese ihre Anforderungen erfüllen.
3. Entfernung des Benutzers zum PoP
Bei der traditionellen Netzwerkkonnektivität für Outbound Browsing wird der Benutzer-Traffic direkt zum Ziel geroutet, nachdem er die Firewall oder das Web-Gateway am Unternehmensstandort durchlaufen hat. Bei einem Cloud-basierten Service wird der Benutzer-Traffic hingegen zunächst an das Data Center des SASE-Anbieters – als PoP bezeichnet – weitergeleitet und gelangt erst danach zum Ziel.
Deshalb ist die Lage dieser PoPs in Netzwerknähe zum Standort des Benutzers entscheidend für eine optimale Latenz und Geschwindigkeit. Die Routing-Optimierung, wie im vorherigen Abschnitt beschrieben, kann ebenfalls die Latenz und Geschwindigkeit verbessern.
4. Entfernung zu den Anwendungen des Benutzers
Einer der gängigsten Anwendungsfälle für SASE ist der Zugriff auf Microsoft 365. Viele SASE-Anbieter bringen ihre Backbone-Infrastruktur in den gleichen physischen Data Centern unter wie die großen SaaS-Unternehmen, beispielsweise Microsoft, Salesforce und andere.
Diese Strategie ermöglicht es SASE-Providern, eine schnellere Performance anzubieten, indem sie die Anzahl der Netzwerk-Hops reduzieren und die Routing-Pfade von ihren PoPs zu den SaaS-Standorten optimieren. Bei diesem Verfahren wird der Traffic vom Computer eines Benutzers zum nächstgelegenen PoP des Anbieters geroutet. Dann wird er direkt zum Backbone des SASE-Anbieters weitergeleitet, der sich in unmittelbarer Nähe zum Service befindet.
5. Bürostandorte
Kunden können ein Büro auf verschiedene Weise mit einem SASE-Anbieter verbinden. Wir werden uns auf die drei wichtigsten konzentrieren.
- GRE- und IPsec-Tunnel von bestehenden Routern und Firewalls: Diese Tunnel und Geräte verbinden zwei SASE-PoP-Standorte, um eine hohe Verfügbarkeit zu erreichen. Ein automatischer Failover der Tunnel oder die Anzahl der gleichzeitigen Tunnel hängt von den Funktionen der lokalen Hardware ab.
- SD-WAN-Hardwaregeräte, die dem Kunden von SASE-Anbietern bereitgestellt werden, um eine bessere Konnektivität und Verfügbarkeit zu erreichen: Einige SASE-Anbieter ohne eigene dedizierte Hardware gehen Partnerschaften mit SD-WAN-Providern ein und lassen die Anwender entscheiden, welche Hardware sie nutzen wollen.
- Proxy Chaining: Diese Methode kommt zum Einsatz, wenn der Kunde bereits über einen Web-Proxy-Service verfügt und es vorzieht, den Traffic an den SASE-Anbieter weiterzuleiten. Proxy Chaining kann in Umgebungen verwendet werden, in denen das interne Routing unterschiedliche Anforderungen und Komplexitäten mit sich bringt.
6. Endnutzergerät
Kunden haben mehrere Möglichkeiten, wie sich ein Endbenutzer mit der SASE-Architektur verbinden kann, darunter die folgenden drei Ansätze:
- Proxy Auto-Configuration (PAC): PAC bestimmt, ob Anfragen des Webbrowsers direkt zum Ziel gelangen oder ob der Traffic an einen SASE-Anbieter weitergeleitet wird.
- Ein Agent: Agenten sind heutzutage eine gängige Methode, da sie bessere Optionen zur Steuerung des Traffics bieten, mehrere Protokolle unterstützen (was eine bessere Skalierbarkeit erlaubt) und einen generischeren Ansatz bieten. Ein Agent kann auch verschiedene andere Kontrollen einbeziehen, zum Beispiel Gerätestatus und Compliance vor der Konnektivität sowie Logging und Reporting. Darüber hinaus nutzen einige Anbieter den Agenten-Cache zur Geschwindigkeitsoptimierung.
- Remote Access: Die Remote-Access-Architektur verwendet einen ähnlichen Mechanismus wie das Outbound Browsing, indem sie einen Reverse Proxy oder einen Agenten für die Konnektivität nutzt. Es gibt weitere Optionen, bei denen kein Agent installiert werden muss. Diese greifen für die Verbindung auf die nativen Fähigkeiten eines Browsers zurück. In diesem Fall melden sich die Endnutzer beim SASE-Portal an. Nachdem sie den Authentifizierungs- und Autorisierungsprozess durchlaufen haben, können sie die Anwendung auswählen, auf die sie zugreifen möchten.
7. Agent Onboarding
Um die Verteilung eines Agenten auf Remote-Endpunkten zu vereinfachen, können die Kunden ihre vorhandenen Patch-Management-Tools nutzen, wie Mobile Device Management (MDM), den Microsoft Endpoint Manager oder Gruppenrichtlinien. Die meisten SASE-Anbieter stellen einen Agenten zur Verfügung, der sich remote, automatisch und möglichst ohne Neustart installieren lässt.
Eine Möglichkeit, die Kunden wählen können, besteht darin, die Nutzer über einen Link, eine E-Mail oder andere Benachrichtigungssysteme zu bitten, die App herunterzuladen. Ein anderer beliebter Ansatz ist es, die Agenten als Teil eines Golden Image zu installieren. Für PAC-Dateien erfolgt das Onboarding in erster Linie über Konfigurationsmanagementsysteme.
