Sicherheit für Microsoft Azure vWAN

Cloud-Architektur: Hub-and-Spoke liegt wieder im Trend

Die zyklische Wiederkehr bestimmter Trends in der IT zählt zu ihren interessantesten Phänomenen – das betrifft insbesondere die Architekturen. Ähnlich wie in der Mode ist immer wieder zu beobachten, dass Designs, die einst als veraltet oder passé galten, früher oder später in der einen oder anderen Form wieder brandaktuell sind – zumeist in Verbindung mit einer neuen Methode oder Technik.

Die WAN-Architektur ist ein Paradebeispiel dafür. Ursprünglich dienten Netzwerke einem einzigen Ziel: den User-Traffic ins Rechenzentrum zu leiten, wo sich die Unternehmensanwendungen befanden. Zu diesem Zweck haben wir Hub-and-Spoke-Netzwerke aufgebaut, deren Mittelpunkt das Rechenzentrum als Nabe bildete, die die einzelnen Speichen miteinander verband. Der gesamte Traffic wurde im Backhauling-Verfahren über dieses Zentrum geroutet und von dort aus an sein eigentliches Ziel  – das Internet oder eine interne Anwendung – weitergeleitet.

Nur wenige Jahre später war diese Architektur auf einmal als komplett ineffizient verschrien. Mit dem zunehmenden Trend hin zu SaaS- und IaaS-Angeboten floss ein wachsender Anteil des Traffics ins Internet. Die Umleitung dieses Traffics über einen zentralen Hub wirkte sich negativ auf die User Experience und die Performance von Anwendungen aus. Um hier Abhilfe zu schaffen, wurde das Konzept einer WAN-Architektur mit Direktverbindung zum Internet (softwaredefiniertes WAN) entwickelt, die den Internet-Traffic über lokale Breakouts routete, statt ihn über einen Hub umzuleiten. Dadurch wurde zwar die Anwendungslatenz deutlich reduziert und die User Experience insgesamt optimiert. Diese Verbesserungen gingen jedoch auf Kosten der Sicherheit, da es keinen zentralen Engpass mehr gab, an dem der Traffic sich einfach überprüfen ließ. Stattdessen mussten plötzlich Dutzende, Hunderte oder gar Tausende einzelner Internetverbindungen abgesichert werden.

Angesichts der Zunahme von Sicherheitsvorfällen suchten Organisation nach Möglichkeiten, zu einem Architekturmodell zurückzukehren, bei dem der Traffic doch wieder durch einen zentralen Engpass geleitet wird. Damit hoffte man die Durchsetzung von Richtlinien vereinfachen zu können, ohne im Gegenzug Latenzen oder Beeinträchtigungen der User Experience hinnehmen zu müssen.

Dank der Verbreitung von Colocation-Modellen erleben Hub-und-Spoke-Architekturen inzwischen ein Comeback – indes stehen heute effizientere Weiterleitungsoptionen zur Verfügung. Der Internet-bound Traffic wird über Colocation-Einrichtungen in geografischer Nähe des betreffenden Users geroutet, die Hochgeschwindigkeitsverbindungen mit führenden IaaS- und SaaS-Anbietern bereitstellen. Am besten stellt man sich diesen neuartigen kombinierten Ansatz als Hub-and-Spoke-Architektur mit mehreren Hubs vor. Die geringfügige Latenz durch Umleitung des Internet-bound Traffic über das nächstgelegene Colocation-Rechenzentrum wird ausgeglichen durch verbesserte Sicherheit, Hubs in geografischer Nähe und Hochgeschwindigkeitsverbindungen zum eigentlichen Verbindungsziel.

Was das alles mit Veränderungen der Cloud-Architektur zu tun hat? Interessanterweise haben Cloud-Architekturen eine ähnliche Entwicklung hinter sich wie herkömmliche WAN-Architekturen – wenn auch unter teilweise anderen Vorzeichen. Bis vor einigen Jahren hätte Ihre Organisation die Cloud-Migration durch den Aufbau mehrerer VNets oder VPCs unterstützt, die jeweils über einen eigenen Stack dedizierter Appliances (Firewalls, Proxys, Load Balancers usw.) verfügten. Einzelne VNets/VPCs waren jeweils voneinander unabhängige Inseln – ganz ähnlich wie Zweigstellen bzw. die Speichen einer Hub-and-Spoke-Architektur.

Die Administratoren hatten jedoch schnell kapiert, dass dieses Modell mit hohen Betriebskosten verbunden war und sich schlecht skalieren ließ, um die expandierende Cloud-Migration zu unterstützen. Die naheliegende Lösung bestand in der Umstellung auf ein Hub-and-Spoke-Konzept, das den Organisationen ermöglichte, Firewalls und andere gemeinsam genutzte Ressourcen zentral über Hub-VNets/VPCs zu verwalten und so den betrieblichen Aufwand und die Komplexität zu reduzieren. Aber selbst dies war mit Herausforderungen verbunden, da Spoke-to-Hub-Peerings häufig mit Bandbreitenbeschränkungen und zusätzlichen Kosten oder Komplexität einhergingen – erst recht bei Organisationen mit Standorten in mehreren Cloud-Regionen.

Die Cloud-Anbieter wiederum sahen in dieser Herausforderung eine Chance zur Verbesserung. Daraus entstand das Modell dedizierter Interconnection-Services wie AWS Transit Gateway und Microsoft Azure vWAN. Dieses Modell weist frappierende Ähnlichkeiten mit den oben erwähnten Hub-and-Spoke-Architekturen mit mehreren Hubs auf. Beim Cloud-Modell können Kunden virtuelle Hubs instanziieren, die sich in geografischer Nähe zu den betreffenden Workloads befinden. Sämtliche Hubs werden dann mit anderen Hubs sowie dem globalen Backbone des Cloud-Anbieters vernetzt, was die weltweite Bereitstellung von Hochgeschwindigkeitsverbindungen sowie skalierbaren Sicherheitskontrollen vereinfacht.

Viele Zscaler-Kunden stellen aktuell im Zuge ihrer Cloud-Transformation auf derartige Modelle um. Wie kann man in solchen Architekturen jedoch skalierbare Zero-Trust-Sicherheit implementieren?

Zero-Trust-Schutz mit Zscaler Workload Communications

Zscaler Workload Communications wird in Form von Konnektor-Appliances implementiert. Dabei handelt es sich um ressourcenschonende VMs innerhalb von Cloud-Umgebungen oder On-Premise-Netzwerken, die hochgradig zuverlässige Verbindungen zwischen Clouds bzw. Zweigstellen und der Zscaler Zero Trust Exchange herstellen. Aufgrund ihrer einfachen Bereitstellung und hohen Skalierbarkeit und Effizienz eignen sie sich hervorragend als Gateway für die intelligente Weiterleitung von Workload-Traffic. Die Konnektoren können überall im Cloud-Netzwerk bereitgestellt werden. In der Praxis gewährleistet die Bereitstellung über ein Shared-Services-Modell (Hub-and-Spoke) in der Regel das beste Preis-Leistungs-Verhältnis .

Die Bereitstellung verteilter Cloud Connectors ist ebenfalls möglich und eignet sich insbesondere für Kunden, die noch am Anfang der Transformation stehen und Unterstützung für eine entsprechend kleinere Cloud-Präsenz bzw. sehr spezifische Anwendungsfälle benötigen:

In beiden Modellen bauen Konnektoren dynamische UDP/443- bzw. DTLS-Tunnel von Cloud-Umgebungen/Zweigstellen zur Zero Trust Exchange auf. Der Traffic, der bei den Appliances eingeht, wird mit AES-256 verschlüsselt, gekapselt und zur Verarbeitung an das nächstgelegene Zscaler-Rechenzentrum weitergeleitet. In diesem Beitrag geht es hauptsächlich um Internet-bound Traffic. Dabei ist zu beachten, dass die beschriebenen Konnektoren auch sehr häufig für laterale Verbindungen innerhalb des Netzwerks eingesetzt werden. In letzterem Szenario wird der Traffic zwischen Workloads in Cloud- oder Zweigstellen-Umgebungen nicht über Direktverbindungen, sondern über Konnektor-Appliances geroutet. In einem späteren Blogbeitrag wird die Bereitstellung von Zscaler Private Access (ZPA) in Kombination mit Cloud- bzw. Zweigstellen-Konnektoren als richtliniengesteuerte, stark segmentierte End-to-End-Sicherheitslösung für diesen Traffic erläutert.

Zwei Optionen zur Implementierung von Zscaler Workload Communications in Microsoft vWAN

Seit kurzem empfiehlt Microsoft vielen Kunden die Umstellung auf vWAN, da es mittlerweile einen Reifegrad und Funktionsumfang erreicht hat, der den Einsatz in der Produktion rechtfertigt. Für die Mehrzahl der Kunden bedeutet dies, dass sie die vWAN- Services instanziieren und vHubs in sämtlichen Regionen erstellen, in denen sich ihre Cloud-Workloads befinden. Anschließend werden die jeweiligen VNets über Speichenverbindungen an ihren regionalen vHub angebunden.

Die Implementierung von Zscaler Workload Communications innerhalb dieser Architektur kann auf zwei verschiedenen Wegen erfolgen. Bei beiden Modellen werden Cloud-Connector-Appliances nicht direkt im vHub, sondern über VNet-Peering instanziiert.

Beim ersten Modell (das dem zuvor beschriebenen verteilten WAN-Modell ähnelt) werden Cloud-Connector-Appliances nahe an den Workloads platziert, die sie innerhalb des VNets bedienen:

Dieses Modell eignet sich insbesondere dann, wenn eine granulare Kontrolle auf der Ebene der einzelnen VNets erforderlich ist, etwa zur Kontrolle des lateralen Traffics oder Durchsetzung einer granularen Richtlinie für den Zugriff aufs Internet. Wir empfehlen Ihnen außerdem, sich über die verfügbaren Optionen bei der Implementierung von VNet-Peering informieren, um zu entscheiden, wie bzw. ob cloudbasierte Workloads Cloud Connector zur Kommunikation mit anderen VNet-Ressourcen nutzen sollen. Darüber hinaus sollte die Skalierung dieses Modells sorgfältig geplant werden, da Rechenkapazitäten und native Ressourcen (wie Standard Load Balancer, NAT-Gateway usw.) bei der Implementierung in Dutzenden oder Hunderten von VNets schnell überlastet werden können.

Für dieses Modell müssen zudem in aller Regel zwei separate Routingtabellen erstellt werden: eine für die Workload(s), deren Standardroute zum Load Balancer verläuft, und eine für den Cloud Connector, dessen Standardroute zum Internet bzw. NAT-Gateway verläuft:

Beim zweiten Modell erfolgt die Bereitstellung im Rahmen eines Shared-Services-Konzepts mit einer Hub-and-Spoke-Architektur. Dieses Bereitstellungsmodell hat den Vorteil, dass es effizienter, kostengünstiger und besser skalierbar ist, und kommt daher am häufigsten zum Einsatz:

Bei diesem Modell wird der Traffic über VNets zum zentralen vHub geroutet, der ihn dann zum Cloud Connector weiterleitet. In der Regel wird anhand der vHub-Routingtabelle eine Standardroute für den Traffic zum Cloud Connector festgelegt. Im Unterschied zum ersten Modell sind jedoch keine Routingtabellen für die einzelnen VNets erforderlich. Stattdessen werden Standardrouten verwendet, die (für die Speichen) von der vHub-Routingtabelle übernommen bzw. (für das zentrale Shared-Services-VNet) direkt von Microsoft installiert werden. Dabei ist jedoch zu beachten, dass Sie die automatische Übernahme der Standardroute für das Shared-Services-VNet deaktivieren müssen. Andernfalls entsteht eine Routenasymmetrie, indem die vHub-Standardroute die von Microsoft installierte Standardroute überschreibt.

Alternativ ist auch eine Kombination beider Architekturen möglich und wird in vollem Umfang unterstützt. Dabei werden einige Cloud-Connector-Appliances im Workload-VNet platziert (um spezifische Anwendungsfälle zu ermöglichen), während andere Cloud-Connector-Appliances im Shared-Services-VNet platziert werden:

HINWEIS: Zscaler hat die Unterstützung für die Legacy-Lösung Secure vHub eingestellt. Wir empfehlen Ihnen, stattdessen Cloud Connector einzusetzen. Cloud Connector fällt zwar streng genommen nicht unter die von Microsoft entwickelte Definition eines Secure vHub, weist jedoch im Vergleich zur Legacy-Lösung eine bessere Performance und Resilienz auf.

Spezifische Hinweise zur Implementierung:

Unabhängig von der jeweils gewählten Microsoft vWAN-Architektur gibt es ein paar Punkte zu beachten, die zu Problemen führen können:

• Routingtabellen – Beim Colocation-Modell sind Routingtabellen für die Weiterleitung des VNet-Traffics über die lokalen Cloud-Connector-Appliances erforderlich. Beim Shared-Services-Modell sind benutzerdefinierte Routingtabellen nicht erforderlich, werden jedoch unterstützt. Wenn Sie eigene Routingtabellen definieren möchten, ist beim Installieren der Routen Vorsicht geboten, da die vordefinierten Standardrouten durch benutzerdefinierte Routen überschrieben werden.
• Routenverteilung – Beim Konfigurieren der Standardroute auf vHub in einem Hub-and-Spoke-Modell müssen Sie darauf achten, dass diese Route nicht vom zentralen Cloud-Connector-VNet übernommen werden darf, da dies zur Entstehung einer Routenschleife führen könnte.
• Auswahl der Region – Ihr vHub sollte sich in derselben Region befinden wie die standardmäßigen Load Balancer und Cloud-Connektor-Appliances, an die er den Traffic weiterleitet. Microsoft verhindert Peering zwischen unterschiedlichen Regionen nicht, jedoch wird der Traffic über die Standardroute in diesem Fall nicht mehr korrekt zum Load Balancer weitergeleitet.
• Netzwerksicherheitsgruppen – Standardmäßig beschränken Cloud-Connector-NSGs eingehenden Traffic von Remote-VNets und lassen nur lokalen VNet-Traffic zu. Beim Colocation-Modell ist das unproblematisch, da sich die Cloud-Connector-Appliances im selben VNet befinden wie die Workloads. Beim Hub-and-Spoke-Modell führt es jedoch zu Konflikten. Entsprechend müssen die NSGs so angepasst werden, dass sie Traffic von den VNets (also den Speichen in der Hub-and-Spoke-Architektur) zum Cloud Connector zulassen.
• Domain Name System (DNS) – Die Verarbeitung ausgehender DNS-Anfragen ist ebenfalls ein wichtiger Punkt. Das DNS spielt für Zscaler Private Access eine entscheidende Rolle beim Routen des Traffics zwischen Workloads über den Cloud Connector. Voraussetzung dafür ist, dass der Cloud Connector Einblick in die ursprüngliche DNS-Anfrage der betreffenden Workload hat. Beim Colocation-Modell ist dies sozusagen vorprogrammiert, da die DNS-Anfrage auf dem Weg zum Cloud-DNS-Server den Cloud Connector durchläuft. Beim Hub-and-Spoke-Modell kann hingegen die Implementierung nativer Tools zur DNS-Auflösung wie Azure DNS Private Resolver erforderlich sein.

Fazit

In diesem Beitrag haben wir einige gängige Cloud-Architekturen vorgestellt, die unsere Kunden in ihren Cloud-Umgebungen bereitstellen. Speziell für Microsoft AZURE vWAN empfehlen wir zwei Alternativen (bzw. drei, wenn man die kombinierte Option mitzählt): Cloud-Connector-Appliances können entweder im Rahmen eines Colocation-Modells oder zentral bereitgestellt werden. Welche Option die bessere ist, hängt stark von den Anwendungsfällen und Sicherheitsanforderungen des jeweiligen Kunden ab. Am besten sehen Sie sich unsere Informationsvideos an und probieren Cloud Connector im Rahmen unserer praxisbezogenen Lab-Sessions selbst aus. Weitere Informationen zum Thema finden Sie hier.