Sichere Workloads in Multicloud-Umgebungen mit der Zero Trust Exchange von Zscaler

Die Cloud ist für die meisten Unternehmen das neue Rechenzentrum, wobei Multicloud-Umgebungen zunehmend zur Norm werden. Cloud-Workloads müssen sicher miteinander und mit dem Internet kommunizieren. Leider werden für sichere Cloud-to-Cloud- und Cloud-to-Internet-Konnektivität Firewalls und VPNs zur Erweiterung des unternehmenseigenen WAN in die Cloud verwendet. Dies führt zu Sicherheitsrisiken, betrieblicher Komplexität und Leistungsproblemen.

Herausforderungen bei der Erweiterung des unternehmenseigenen WAN in die Cloud

Üblicherweise werden zwei verschiedene Umgebungen mithilfe von Routern verbunden. Da diese Router verwendet werden, um VPN- oder IPSec-Tunnel zu beenden und Routen auszutauschen, hat jede dieser Umgebungen Zugriff auf alle IP-Adressen in den anderen Umgebungen. Um den Zugriff zwischen diesen Umgebungen zu steuern, werden Firewalls verwendet. Diese bieten statische Zugriffskontrollen und stellen sicher, dass nur bestimmte IPs in einer Umgebung Zugriff auf bestimmte IPs in anderen Umgebungen haben. Die meisten Unternehmen haben diesen alten IP & Firewall-Ansatz zwangsläufig übernommen. 

 

Der IP & Firewall-Ansatz führt zu Sicherheitsrisiken, da sich Bedrohungen in Netzwerken mit flacher Full-Mesh-IP-Konnektivität leichter lateral ausbreiten können.

Außerdem führt der Ansatz zu betrieblicher Komplexität , da sich Workloads vorübergehend in der Cloud befinden. Jede neue IP muss von Routern weitergegeben werden. Zudem muss jede neue IP in die Firewall programmiert werden. Wenn sich diese IPs überschneiden, muss dies gelöst werden, bevor eine Verbindung zum Netzwerk hergestellt werden kann.

Schließlich beinhaltet dieser Ansatz Herausforderungen in Bezug auf Skalierung und Leistung wie z. B. Skalierung von Routen, Engpässe beim Datendurchsatz und höhere Latenz.

Diese Herausforderungen werden umso größer, je mehr Anwendungen über mehrere Clouds verteilt sind und je mehr Cloud-native Services wie Container, PaaS und serverlose Dienste eingesetzt werden.

Mit einem Legacy-Ansatz muss der gesamte Traffic, der an das Internet oder andere Workloads in einer anderen Cloud gebunden ist, einen zentralen Hub durchlaufen, und dieser Hub verfügt über Firewalls, Squid-Proxys, Router usw. – ähnlich wie eine Architektur nach Festung-mit-Burggraben-Prinzip in einem Rechenzentrum. Die Einschränkungen umfassen:

 

 

1. Eingeschränkte Security Posture:

Für eine vollständige Security Posture sind zusätzliche Funktionen wie Proxy und Datenschutz erforderlich, da eine umfassende SSL-Überprüfung mit virtuellen Firewalls nicht möglich ist. Dies führt zu zusätzlichen virtuellen Appliances für Squid-Proxys, Sandboxing usw.

2. Risiken bei Full-Mesh-Netzwerken:

Damit Workloads in einer Multicloud-Umgebung kommunizieren können, verteilt die herkömmliche IP-Architektur Routen und teilt IP- und Subnetzinformationen umgebungsübergreifend, wodurch ein flaches Netzwerk und statische Firewall-Regeln entstehen. Diese können leicht umgangen werden, wodurch Bedrohungen sich lateral ausbreiten können.

3. Leistungsbeschränkungen von Appliances:

Der Datendurchsatz wird durch das schwächste Glied bestimmt – in diesem Fall die Skalierbarkeit und Leistung der Firewall. Je mehr Sicherheitsdienste auf Firewalls aktiviert werden, beispielsweise die SSL-Prüfung von Inhalten, desto schlechter wird die Leistung.

4. Mehraufwand von Orchestrierung und Management:

Herkömmliche Firewalls benötigen zusätzliche VMs für Orchestrierung, Richtlinien-, Betriebs- und Lizenzmanagement, wodurch Kosten und Komplexität steigen. Dies gilt für jeden Cloud-Anbieter, wodurch ein zusätzlicher Aufwand für den Betrieb in mehreren Clouds entsteht.

5. Tote Winkel aufgrund von Multi-Hops zu einem Ziel:

Für IP-basierte Legacy-Ansätze benötigt man mehrere Tools wie Firewalls, SD-WAN-Router, NACLs und Sicherheitsgruppen. Für jedes dieser Tools ist eine separate Protokollierung erforderlich. Wenn Protokolle unsachgemäß korreliert werden, führt das zu toten Winkeln für Netzwerk- und Sicherheitsteams.

Zero Trust auf Cloud-Workloads ausweiten

Glücklicherweise haben wir in den letzten Jahren bereits gesehen, wie sich Herausforderungen hinsichtlich des unternehmenseigenen WAN auf den Mitarbeiterzugriff auswirken. Um die Sicherheits- und Leistungsmängel des IP- und Firewall-Ansatzes zu überwinden, verfolgen immer mehr Unternehmen eine Zero-Trust-Strategie. Die bekannten Zero-Trust-Prinzipien, die an die spezifischen Anforderungen von Cloud-Workloads angepasst wurden, sind die Zukunft des Multicloud-Networking.

Bei Zero Trust wird Netzwerken niemals vertraut, sodass IP- und Routing-Informationen nicht ausgetauscht werden. Die Konnektivität wird auf granularer Ebene für Workloads auf der Grundlage von Identität und Kontext aktiviert, sodass keine statischen Firewall-Regeln erstellt werden müssen, um den IP-Zugriff zwischen den Umgebungen zu beschränken.

 

Zscaler Internet Access (ZIA) und Zscaler Private Access (ZPA) sind die führenden Produkte für sicheren User-Zugriff auf Internet und private Anwendungen. Durch Zscaler Workload Communications auf Basis von Cloud Connector werden diese Lösungen erweitert, um den Workload-Zugriffs auf das Internet (ZIA für Workloads) und den privaten Zugriffs auf private Remote-Workloads (ZPA für Workloads) zu schützen. Dieser bahnbrechende neue Ansatz verbessert gleichzeitig die Sicherheit, reduziert die betriebliche Komplexität und optimiert die Anwendungsleistung.

 

Anwendungsfall 1: Zero Trust für Workload-to-Internet-Kommunikation

Mithilfe von Cloud Connector können sich Workloads direkt mit der Zscaler Cloud verbinden, um auf das Internet zuzugreifen. Alle Sicherheitsdienste wie SSL-Proxy, Datenschutz und Advanced Threat Protection werden nativ in Zero Trust Exchange ausgeführt. Mit dieser Architektur können dieselben Sicherheitsrichtlinien für alle Workloads angewendet werden, die über eine Cloud auf das Internet zugreifen. Dieses Konzept unterscheidet sich deutlich von Legacy-Architekturen, bei denen man eine Architektur nach Festung-mit-Burggraben-Prinzip mit Firewalls und Squid-Proxies in jeder Cloud errichten muss.

 

Anwendungsfall 2: Zero Trust für Workload-to-Workload-Kommunikation in einer Multicloud-Umgebung

Mithilfe von Cloud Connector können sich Workloads direkt mit der Zscaler Cloud verbinden. Workloads aus jeder Cloud (AWS, Azure, Rechenzentrum) können über Zero Trust Exchange miteinander kommunizieren. Zero Trust Exchange verwendet Identität und Kontext, um den Workload zu überprüfen und dann die Verbindung herzustellen. Diese Vorgehensweise unterscheidet sich deutlich von Legacy-Architekturen, bei denen IP-Routing zwischen diesen Cloud-Umgebungen erforderlich ist.

 

Anwendungsfall 3: Zero Trust für Workload-to-Workload-Kommunikation innerhalb von VPC/VNET

Zscaler Workload Segmentation bietet granulare Segmentierung innerhalb einer virtuellen Maschine auf einer individuellen Anwendungs- oder Prozessebene. Ein Agent zur Workload-Segmentierung stellt mithilfe von Fingerprinting auf Prozessebene Software-Identität bereit. Automatisiertes maschinelles Lernen erkennt alle verfügbaren Pfade zu einem bestimmten Prozess oder einer bestimmten Anwendung und gibt Empfehlungen für zulässige Pfade. Alle unnötigen Pfade, die das Risiko lateraler Ausbreitung von Bedrohungen erhöhen, werden nicht berücksichtigt. Dies steht im Gegensatz zu Legacy-Architekturen, in denen statische Zugriffskontrolllisten und Sicherheitsgruppen verwendet werden, die ein Angreifer leicht umgehen kann, indem er eine bestehende Regel ausnutzt.

Wie Zero Trust die Einschränkungen von Firewall & IP aufhebt         

 

 

Bei der Untersuchung von Legacy-Architekturen haben wir festgestellt, dass IP-Konnektivität das häufigste Problem ist. Üblicherweise werden Netzwerk und Sicherheit als getrennte Funktionen betrachtet. Zunächst wird die Konnektivität (IP-Routing) aktiviert und dann die Sicherheit (Firewall-Filter) dazugeschaltet. Einige Anbieter haben beide Funktionen in einer Appliance kombiniert, aber Ansatz und Architektur unterscheiden sich nicht.

Die Zero Trust Exchange von Zscaler verfolgt einen vollkommen anderen Ansatz: Sicherheit kommt an erster Stelle, Konnektivität erst danach. Warum unnötige Konnektivität schaffen, die man später blockieren muss?

Beim Zero-Trust-Ansatz von Zscaler gilt niemand als vertrauenswürdig. Die Quelle kann sich standardmäßig nur mit der Zero Trust Exchange verbinden, nicht mit der Zielanwendung. Der gesamte Workload-Traffic wird an Cloud Connector weitergeleitet, der diese Workloads dann mit der Zero Trust Exchange verbindet.

Die Zero Trust Exchange hält sich an die folgenden Schritte, bevor Quelle und Ziel verbunden werden: