Zscaler Blog

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:

Schritt 1: Identität

Zero Trust Exchange prüft, woher die Workloads kommen, z. B. von einem authentifizierten und registrierten Cloud Connector oder einer Kunden-VPC oder einem VNET.

Schritt 2: Ziel

Richtlinien lassen sich auf Grundlage des Ziels definieren – die Zero Trust Exchange kann prüfen, ob es sich bei dem Ziel um eine genehmigte oder inoffiziell genutzte Anwendung handelt.

Schritt 3: Risiko

Richtlinien lassen sich basierend auf Quell-VPC/-VNET festlegen. Nur unternehmenseigenen VPCs wird der Zugriff auf bestimmte Ziele gewährt, während Partner-VPCs/-VNETs, die als riskant gelten, keinen Zugriff auf diese Ziele erhalten.

Schritt 4: Mögliche Bedrohungen

Für nicht vertrauenswürdige Internet-Ziele kann ein vollständiger SSL-Proxy aktiviert werden, der alles prüft, was von der Quelle zum Ziel gelangt und umgekehrt.

Schritt 5: Herstellen der Verbindung

Handelt es sich um ein Internet-Ziel, wird über einen Proxy eine Verbindung zum Ziel hergestellt. Beim Zugriff auf private Anwendungen besteht eine Inside-Out-Verbindung über den Anwendungs-Connector am Ziel. Die Zero Trust Exchange dient der Treffpunkt und stellt diese Verbindung her.

Die wichtigsten Vorteile von Zero Trust für Cloud-Workloads

1. Schutz vor Cyberbedrohungen für alle Workloads:

Gefährdung von Workloads verhindern:
Die gesamte Kommunikation von Workloads mit dem Internet wird einer Cyberüberprüfung unterzogen, die Workloads vor Bedrohungen wie Botnets, bösartigen aktiven Inhalten und Betrug schützt.

Cloudübergreifende laterale Ausbreitung von Bedrohungen verhindern:
Bei Zero-Trust-Konnektivität ist jede Umgebung (Rechenzentrum, Cloud-Regionen usw.) isoliert und alle Ziele in anderen Umgebungen sind nicht routingfähig. So wird die laterale Ausbreitung von Bedrohungen zwischen Umgebungen verhindert.

Laterale Ausbreitung von Bedrohungen innerhalb eines Rechenzentrums oder einer Cloud-Region verhindern:
Identitätsbasierte Mikrosegmentierung auf Prozessebene verhindert jegliche laterale Ausbreitung von Bedrohungen innerhalb eines Rechenzentrums oder einer Cloud-Region.

2. Datensicherheit in SaaS und öffentlichen Clouds:

Datensicherheit in öffentlichen Clouds:
Der Zugriff auf Workloads nach dem Prinzip der minimalen Rechtevergabe kann durch eine Minimierung der Berechtigungen (CIEM) umgesetzt werden. Außerdem lässt sich das Risiko der Kompromittierung reduzieren, indem Fehlkonfigurationen behoben werden (CSPM).

Datensicherheit in SaaS:
Mithilfe von Transparenz hinsichtlich der Shadow-IT kann die Nutzung nicht genehmigter Anwendungen verhindert und der unkontrollierten Freigabe von Ressourcen vorgebeugt werden (API CASB).

Inline-DLP:
Datenschutzverletzungen oder Datenexfiltration lassen sich verhindern, indem der gesamte Workload-Traffic, der über das Internet erfolgt, von DLP überprüft wird.

3. Hyperskalierung für Leistung und Skalierbarkeit:
Zscaler verfügt über mehr als 150 Service-POPs für die Zero Trust Exchange. Diese POPs sind mit allen großen Cloud-Anbietern kompatibel und haben jeweils eine Betriebskapazität im Terabyte-Bereich. Standardmäßig verbindet sich Cloud Connector mit dem POP, der die beste Verfügbarkeit und die geringste Entfernung aufweist.
 

4. DevOps-fähig und vollständig automatisiert:
Management und Richtlinien werden zentral verwaltet und in der Cloud bereitgestellt – alle Upgrades der Cloud Connectors werden von Zscaler verwaltet. Terraform-fähige Orchestrierung kann problemlos in die DevOps-CI/CD-Pipeline integriert werden. Plattformspezifische Automatisierungen wie Vorlagen für Cloudformation und Azure Resource Manager werden ebenfalls standardmäßig bereitgestellt.
 

5. Vollständige Protokollierung und Log-Streaming:
Der gesamte ausgehende Traffic von jedem Cloud Connector – einschließlich des Traffics zur Zero Trust Exchange – wird protokolliert und kann zum gewünschten SIEM/Protokoll-Aggregator gestreamt werden. Für das Streaming an kritische Standorte sind ausgefeilte Filter verfügbar.

Bereitstellung von Cloud Connectors

Der Cloud Connector kann entweder in allen VPCs/VNETs bereitgestellt werden, wenn eine Isolierung in einer/einem VPC/VNET erforderlich ist, oder an einem zentralen Standort, wenn eine Isolierung für eine Gruppe von VPCs/VNETs benötigt wird. Die Bereitstellungsmodelle sind so flexibel, dass sowohl zentrale als auch verteilte Bereitstellungen möglich sind.

 

 

 

Zusammenfassend lässt sich sagen, dass Workloads als Spiegelbilder der User betrachtet werden. Durch den Umstieg auf eine Zero-Trust-Architektur für die Workload-Kommunikation können Daten und Workloads geschützt, Angriffsflächen beseitigt und die laterale Ausbreitung von Bedrohungen verhindert werden. Zero Trust von Zscaler ist die Zukunft der Cloud-Konnektivität. Wir sind unter [email protected] erreichbar, wenn eine Demo gewünscht wird.