Zugang zu externen Clouds

07.03.2019 / Dr. Behrooz Moayeri /

aus Netzwerk-Insider-Ausgabe März 2019

In einem atemberaubenden Tempo steigt die Intensität der Nutzung externer Clouds. Stellen Sie sich eine hypothetische Person vor, die bis vor zwei Jahren die IT in deutschen Unternehmen gut gekannt hat, zwei Jahre verreist war und jetzt wieder da ist. Diese Person würde die IT in vielen Unternehmen nicht wiedererkennen. Überwog bis vor zwei Jahren in Deutschland die Skepsis und Misstrauen, was die Nutzung externer Clouds betraf, wird sich unser imaginärer Wiederkehrer wie in einer Landschaft nach einem Dammbruch vorkommen. Alle Hemmung scheint verflogen. Hier und da kann man die Entwicklung nur noch als Flucht in die Cloud bezeichnen.

Hier interessiert uns weniger, was diese Massenbewegung ausgelöst hat als vielmehr die Begrenzung von Schäden durch das überstürzte Hinwenden zur Cloud.

Damit Nutzbarkeit, Beherrschbarkeit und Sicherheit von IT nicht unter die Räder kommen, ist Sorgfalt bei der Planung der Cloud-Nutzung angesagt. Ein wichtiger Aspekt ist dabei der Zugang zu externen Clouds. Auf diesen Aspekt geht der vorliegende Beitrag ein.

Cloud ist nicht gleich Cloud

Zunächst ist daran zu erinnern, dass es ganz unterschiedliche Ausprägungen der Cloud-Nutzung gibt, wie in der Abbildung 1 dargestellt. Es ist ein Unterschied, ob ein Unternehmen Software as a Service (SaaS) in der Cloud nutzt und damit nur die eigenen Clients und die Zugänge zur Cloud Gegenstand der eigenen Planung des Unternehmens sind, oder ob man auch ein Netzkonzept innerhalb der externen Cloud braucht, wie es meistens im Falle von Infrastructure as a Service (IaaS) der Fall ist. Die verschiedenen Cloud-Servicemodelle haben wesentlichen Einfluss auf das Netz- und Zugangskonzept für die Nutzung externer Clouds. Vereinfacht und mit einer nicht immer zutreffenden Verallgemeinerung lässt sich folgende Aussage formulieren: Je kleiner der Bereich der Planungshoheit des eigenen Unternehmens, desto schwerwiegender sind die Gründe, auf das Internet als Hauptkanal der Verbindung zur Cloud zu setzen. Das ist natürlich nicht immer zutreffend, aber im Großen und Ganzen gibt es diese Tendenz: je mehr SaaS, desto mehr Internet. Beispiele im Folgenden belegen diese Aussage.

Abbildung 1: Cloud-Service-Modelle

Office 365 als gängigste Art der Cloud-Nutzung

Microsoft Office 365 ist die gängigste Art der Cloud-Nutzung. Fast alle Unternehmen nutzen entweder Office 365 in der Microsoft Cloud oder haben dies vor. Deshalb lohnt es sich, einen Blick auf Office 365 als typisches Beispiel für SaaS zu werfen.

Microsoft sieht die Latenz als wichtigste „Währung“ in der Cloud-Wirtschaft. Diese Allegorie ist allerding invers zu verstehen. Bei Geld gilt: je mehr umso besser. Bei der Latenz ist es umgekehrt, nämlich je weniger desto besser. Bei der Lektüre von Empfehlungen und Anleitungen, die Microsoft für Office 365 herausgibt, fällt sofort die Betonung der Minimierung der Latenz beim Zugriff auf die Microsoft-Cloud auf. Auch wenn die Latenz eine teilweise erhebliche Auswirkung auf die Performance von Anwendungen hat, muten manche der diesbezüglichen Empfehlungen von Microsoft fast religiös an.

Ein Beispiel: Deutschland hat im globalen Vergleich eine sehr kleine Fläche. Die Round Trip Time (RTT) in einem Netz innerhalb Deutschlands ist in der Regel im einstelligen Millisekundenbereich. Ob der Zugriff auf die Microsoft-Cloud von einem Standort in Deutschland direkt erfolgt oder über ein unternehmensinternes Wide Area Network (WAN) und ein Unternehmens-RZ, macht hinsichtlich Latenz keinen großen Unterschied, denn die Microsoft-Cloud ist global. RTT-Werte zwischen Kontinenten liegen häufig im dreistelligen Millisekundenbereich. Selbst innerhalb einer relativ kleinen Weltregion wie Europa kommt es nicht selten zu RTT-Werten im zweistelligen Bereich. Nichtsdestotrotz erwägen viele Unternehmen in einer Art übertriebener Microsoft-Hörigkeit, jeden Standort mit einem direkten Internetanschluss samt Perimetersicherheit auszustatten. Der Grund: Microsoft empfiehlt mit auffallender Dringlichkeit den kürzesten Weg zur Microsoft-Cloud. Der Weg über die Unternehmenszentrale ist ja ein Umweg. Davon, dass dieser Umweg auch innerhalb Deutschlands für die Performance von Office 365 entscheidend ist, gehen viele aus. Dabei gerät das Gespür für das Verhältnismäßige aus dem Blickfeld. Wenn Ihr Unternehmen Sie fragt, ob es sich lohnt, durch eine Millioneninvestition in mehr Firewalls und Internetanschlüsse den Weg zur Microsoft-Cloud im Schnitt um 5 Millisekunden zu verkürzen, wie würden Sie antworten?

Meine Antwort wäre klar: Jemand soll mir erst nachweisen, dass diese 5 Millisekunden Gewinn auch für die Anwender spürbar sind. Wenn ja, sollte man abwägen, ob der Effizienzgewinn den Mehraufwand für die Implementierung und den Betrieb einer Mehrzahl von Internetzugängen samt Sicherheitskomponenten rechtfertigt.

Aber zurück zu den Microsoft-Empfehlungen. Der Tenor ist klar: den kürzesten Weg zur Microsoft-Cloud nehmen. Als kürzesten Weg sieht Microsoft erstens den direkten Weg über das Internet. Zweitens sollte dieser Weg laut Microsoft möglichst barrierefrei sein. Microsoft sieht Proxies auf dem Weg zu Office 365 gar nicht so gern. Für das User Datagram Protocol (UDP), das für Echtzeit-Voice und -Video zu bevorzugen sei, solle man Proxies ganz umgehen (Proxy Bypass). Und der Zugriff auf sämtliche Office-365-Anwendungen solle keine Authentisierung am Proxy involvieren. Tolerierbar sei der Weg über den Proxy nur für die nicht zum Kern der Office-365-Anwendungen gehörenden Dienste innerhalb der Microsoft-Cloud (wie zum Beispiel Windows Updates) oder im restlichen Internet.

Diese Unterscheidung bedeutet natürlich mehr Komplexität am Internet-Übergang. Der Zugriff auf die Office-365-Ziele muss anhand von URLs und Adressen erkannt werden und unter Umgehung der Proxies erfolgen. Die Liste von URLs und Adressen sind leider Gegenstand von Änderungen. Bei der Pflege der Regeln muss man daher stets auf Aktualität der Liste achten.

Hinzu kommen solche Microsoft-Empfehlungen wie Vermeidung von Middleboxes auf dem Weg zur Microsoft-Cloud. Unter Middleboxes sind solche Lösungen wie WAN-Optimierer oder SSL-Terminierung zu verstehen. Sind solche Komponenten im Einsatz, muss man diese auch umgehen.

Außerdem empfiehlt Microsoft, beim Zugriff auf Office 365 möglichst kein Virtual Private Network (VPN) zu nutzen.

Nicht zu vergessen sind die Restriktionen bezüglich Network Address Translation (NAT). Die meisten Unternehmen bilden viele interne IP-Adressen per NAT auf eine öffentliche IP-Adresse ab. Dabei führt das NAT-Gerät eine Tabelle mit der Zuordnung von verschiedenen TCP-Verbindungen zu internen IP-Adressen. Da im Internet alle diese TCP-Verbindungen dieselbe öffentliche IP-Adresse des Unternehmens nutzen, müssen sie anhand eines anderen Merkmals, nämlich des TCP-Ports, unterschieden werden. Für den TCP-Port sind im TCP-Header 2 Oktette verfügbar. Das macht 2 hoch 16 = 65536 verschiedene Werte. Ein Client nutzt gleichzeitig 10 bis 30 TCP-Verbindungen für Office 365. Das heißt, eine einzige öffentliche IP-Adresse reicht nur für ca. 2000 bis 6000 Clients.

Laut Microsoft wird die Performance von einigen Office-365-Anwendungen verbessert, wenn der Client auf das Microsoft-RZ zugreift, das ihm am nächsten liegt. Zu den Diensten, die auf verschiedene Microsoft-RZs verteilt sind, gehören zum Beispiel Front-End-Server für Exchange-Online. Auch wenn die eigentlichen Kundendaten immer in dem für den Kunden bestimmen RZ-Standort bei Microsoft liegen (im sogenannten aktiven Data Center), soll laut Microsoft der Zugriff auf diese Daten über Front-End-Server erfolgen, die dem Client am nächsten sind. Microsoft nutzt bei der Auflösung der DNS-Namen solcher Server die IP-Adresse des Clients, um dessen geografische Position zu ermitteln. Daraufhin wird als IP-Adresse für den gesuchten DNS-Namen die Adresse des dem Client am nächsten liegenden Servers übergeben.

Dieser Mechanismus funktioniert natürlich nur, wenn die IP-Adresse, hinter der sich der Client verbirgt, zur tatsächlichen Position des Clients zugeordnet werden kann. Nutze ich zunächst ein globales WAN, um von Amerika aus über Deutschland auf die Microsoft-Cloud zuzugreifen, verberge ich meine tatsächliche Geo-Position und werde zum „falschen“ RZ geleitet.

Manchmal gerät vor lauter Latenzbetrachtung der andere für die Performance von IT-Anwendungen wichtige Parameter in den Hintergrund, nämlich der Bedarf an Netzübertragungskapazität. Anwendungen werden immer komplexer und bunter. Ich habe zum Beispiel festgestellt, dass bei Nutzung von Microsoft Teams mein mobiles Datenvolumen schneller als sonst aufgebraucht wurde. Daraufhin habe ich mir mit Wireshark etwas genauer angeschaut, welches Verkehrsvolumen mein Zugriff auf Teams verursacht. Dabei habe ich bewusst auf Video- und Telefonkonferenzen verzichtet und nur die Datenanwendungen von Teams genutzt. Ich habe Teams gestartet und über 8 Minuten genutzt. Hier sind die Ergebnisse der Messung:

Aufzeichnungsdauer 512 Sekunden
44861 übertragene Pakete, d.h. ca. 88 Pakete pro Sekunde
Über 48 Millionen übertragene Bytes
Im Mittel ca. 762 kbit/s, das Gros von Microsoft zu meinem Client
Anteil von IPv6 an der Kommunikation mit Microsoft ca. 90 %
Spitzenlast bei der Kommunikation mit Microsoft ca. 80 Mbit/s

Von der Höhe der mittleren Netzlast (über 700 kbit/s) war ich überrascht, weil Microsoft folgende Richtwerte veröffentlicht hat:

150 kbit/s für Light User
300 kbit/s für Medium User
400 kbit/s für Power User

Demnach bin ich also ein Super-Power-User, der gar nicht in das allgemeine Schema passt. Dabei habe ich wie gesagt weder Voice noch Video genutzt.

Sie sollten daher keineswegs die Last unterschätzen, die mit der Nutzung von Microsoft-Office-Anwendungen verbunden ist. Wenn Sie mit ihrem Datenvolumen im Mobilfunk haushalten müssen, prüfen Sie bitte zuerst, ob Sie wie ich Super-Power-User sind. Aber selbst für Light User ergibt sich folgende Rechnung:

150 Kilobits pro Sekunde, d.h. ca. 20 Kilobytes (KB) pro Sekunde
72 MB pro Stunde
1 GB Datenvolumen reicht für ca. 14 Stunden, d.h. für weniger als zwei Arbeitstage

Verschiedene Wege für den Zugriff auf Office 365

Vor dem Hintergrund der erwähnten Microsoft-Empfehlungen lassen sich verschiedene Wege für den Zugriff auf Office 365 gegenüberstellen.

Der erste Weg ist der direkte. Er ist in der Abbildung 2 dargestellt.

Abbildung 2: Direkter Zugriff auf Office 365

Der direkte Weg ist der von Microsoft bevorzugte. Er hat laut Microsoft folgende Vorteile:

Der direkte Weg unterstützt die UDP-Nutzung und ermöglicht damit die Optimierung von Echtzeit-Voice und -Video für Skype bzw. Teams (ist UDP nicht möglich, nutzen solche Ströme TCP, mit Nachteilen für die Performance und Qualität von Voice und Video).
Vermeidung der Manipulation des Verkehrs und somit optimale Konnektivität zu Office 365 (keine Middelboxes, keine Änderung solcher Parameter wie TCP-Optionen, die zulasten der Performance gehen können)
Minimale Latenz durch lokale Internetzugriffe (wie gesagt geht der kürzeste Weg zur globalen Microsoft Cloud in der Regel über das Internet)
Hohe Skalierbarkeit (keine Middleboxes wie Proxies, die Grenzen für Skalierbarkeit darstellen können, was die Größe der Verbindungstabellen oder schlicht die Netzlast betrifft)

Sorgt man durch die Auswahl eines entsprechenden Internet-Service-Providers für optimales Peering zwischen dem ISP und Microsoft, ist der direkte Zugriff aus Sicht von Microsoft die optimale Methode für den Zugriff auf Office 365.

Diese Variante hat allerdings auch Nachteile, nämlich diese:

Auf den Firewalls zwischen dem internen Netz und dem Internet sind Freischaltungen für sämtliche Netze von Microsoft erforderlich, in denen sich die Office-365-Server befinden.
Die IP-Adressen der Microsoft-Cloud müssen im internen Netz erreichbar sein. Viele Unternehmen haben bisher öffentliche IP-Adressen in ihrem Netz nicht geroutet, auch nicht per Default-Route, vor allem aus Sicherheitsgründen.
Die Auflösung der DNS-Namen der Cloud-Ressourcen muss im internen Netz möglich sein. Ebenfalls aus Sicherheitsgründen ist in einigen Unternehmensnetzen die DNS-Auflösung externer Namen nicht möglich.
Eine hohe Anzahl von externen Flows muss unterstützt werden, insbesondere durch Firewalls.

Bei vielen Unternehmen erfolgt bisher jeglicher Internet-Zugriff über einen On-Premise-Proxy. Abbildung 3 zeigt ein Szenario, in dem ein solcher Proxy auch für den Zugriff auf die Cloud genutzt wird.

Abbildung 3: Zugriff über On-Premise-Proxy

Die Vorteile der Proxy-Nutzung sind die folgenden:

Da es sich beim Proxy-basierenden Internet-Zugriff in vielen Unternehmen um die Standardmethode für den Internetzugriff handelt, sind in solchen Unternehmen Konfigurationsänderungen nicht notwendig, wenn bisher alle Internet-Zugriffe über den Proxy geleitet werden. Die Cloud-Ziele werden nicht besonders behandelt.
Nur wenige IP-Adressen müssen von Clients aus erreichbar sein, nämlich die Adressen der Proxies.
Firewall-Konfigurationen müssen nicht angepasst werden. Nur der Proxy braucht eine Freischaltung für den Zugriff auf das Internet.
Externe IP-Adressen müssen im internen Netz nicht geroutet werden.
Die Überwachung der Kommunikation ist einfach, sowohl auf den Firewalls als auch auf den Proxies.
Es gibt in Gestalt des Proxy eine Sicherheitsbarriere zwischen den Clients und dem Internet.

Microsoft führt für dieses Szenario folgende Nachteile an:

Wenn der Proxy UDP nicht überträgt, wird die TCP-Nutzung für Echtzeit-Voice/-Video erzwungen, was mit Qualitätseinbußen einhergehen kann. Denn Voice und Video haben über TCP in der Regel eine schlechtere Performance als über UDP.
Es kommt zu zusätzlicher Latenz durch den Proxy.
Langlebige intensive Flows wie bei Office 365 genutzt können für einige Proxies ein Problem sein.
Eine mögliche Manipulation von TCP-Parametern durch den Proxy kann die Performance von Office-365-Anwendungen beeinträchtigen.
Weitere Probleme können durch das Aufbrechen von SSL durch den Proxy entstehen.
Proxies können Skalierbarkeitsprobleme haben.
Es kommt zu zusätzlichen Kosten für Proxies, insbesondere wenn sie die hohe Last für Office 365 übertragen sollen.

Daher rät Microsoft davon ab, den Zugriff auf Office 365 über On-Premise-Proxies zu leiten. Wenn dies jedoch unvermeidbar ist, zum Beispiel aufgrund von Sicherheitsrichtlinien einer Organisation, werden folgende Maßnahmen empfohlen:

Abbildung 4: Zugriff auf SaaS über Web Security Cloud

Das Unternehmen sollte ein verstärktes Augenmerk auf das Monitoring der Proxy-Ressourcen richten, zum Beispiel was die Speicherbelegung und die Prozessorlast betrifft.
Nach Möglichkeit sind verteilte Proxies zu nutzen, um die Latenz zu minimieren und Umwege über entfernte Standorte zu meiden.
Auf die Nutzung von Proxies in derselben Region wie der Client ist zu achten.
Cloud Proxies als Alternative zu On-Premise-Proxies sollen in Erwägung gezogen werden.
Es sollte kein Aufbruch von SSL durch Proxies erfolgen.
Durch UDP Proxy Bypass soll der UDP-Verkehr den Proxy umgehen.

Eine der Empfehlungen, die Erwägung der Nutzung von Cloud Proxies, läuft darauf hinaus, dass anstelle von On-Premise-Proxies die Dienste von Anbietern wie Zscaler, Symantec und McAfee in deren Clouds genutzt wird. Diese Anbieter betreiben weltweite Netze von Proxies, über die ein Client auf Applikationen im Internet, darunter natürlich Anwendungen in anderen Clouds, zugreifen kann. der Ansatz ist in der Abbildung 4 dargestellt.

Funktionen, die in einer Web Security Cloud genutzt werden können, sind u.a.:

Intrusion Prevention System (IPS)
Schutz vor Distributed Denial of Service (DDoS)
Proxy-Funktion
Kategoriebasierende URL Filter
White-/ Black-Listing
Content-Analyse
SSL-Terminierung und damit verbunden Content-Analyse für SSL-Verkehr
Virus Scanning
Sandboxes
Benutzerauthentisierung, auch im Abgleich mit einem internen Verzeichnis wie Active Directory (AD) bzw. Abgleich mit einem Verzeichnis in der Cloud wie Azure AD
Feingranulare Benutzerauthentisierung, in der Regel anhand von Gruppen
Reporting über Internet-Nutzung
Logging mit Haltung der Log-Daten in der Cloud oder Übermittlung der Logs zu internen Systemen wie zum Beispiel Security Information and Event Management (SIEM)
Schutz für Geräte außerhalb des Unternehmensnetzes, vor allem Schutz mobiler Endgeräte, indem diese auch bei Anschluss an externe Netze die Cloud Proxy nutzen
Mandantenfähige Administration, indem verschiedene administrative Rollen in der Cloud angelegt werden

Wie in der Abbildung 4 dargestellt besteht eine mögliche Variante der Nutzung von Web Security Clouds darin, zwischen dem internen Netz des Unternehmens und der Web Secuirty Cloud einen Tunnel aufzubauen. Sämtlicher Internet-Verkehr nutzt diesen Tunnel; ungeschützten Internet-Verkehr gibt es nicht. Ein weiterer Vorteil dieser Variante ist, dass der Cloud Proxy die internen Client-Adressen „sieht“ und daher die Logs mit diesen Adressen versehen kann. Der Tunnel braucht keine Verschlüsselung, handelt es sich doch um Verkehr, der ohnehin in das Internet geht. Andere kritische Daten wie zum Beispiel Kommunikation für Authentisierung und Autorisierung werden durch Verfahren wie Security Assertion Markup Language (SAML) geschützt.

Die Motivation von Unternehmen, Web Security Clouds zu nutzen, ist unterschiedlich:

Für einige steht die Vermeidung der Abhängigkeit von Herstellern im Vordergrund. On-Premise-Proxies müssen in regelmäßigen Abständen ausgetauscht werden, weil der Support durch Hersteller endet. Mit der Nutzung der Web Security Cloud überlässt man solche Updates dem Cloud-Betreiber.
Einige Organisationen wollen mit der Nutzung von Cloud Proxies die Komplexität der eigenen IT-Infrastruktur minimieren. Gerade beim Perimeterschutz hat sich in den letzten Jahren durch Sicherheitsvorfälle die Notwendigkeit von einigen Zusatzkomponenten wie Sandboxes ergeben, deren Eigenbetrieb immer komplexer und kostspieliger wird.
Weltweit operierende Unternehmen nutzen die Web Security Clouds, um den Zugriff auf das Internet und externe Clouds möglichst auf kurzem Wege zwischen Clients und den Zielen im Internet und in Clouds zu ermöglichen. Damit wird die Latenz minimiert und das teure private WAN entlastet. Von einem weltweit agierenden Unternehmen habe ich erfahren, dass mit der Umleitung des Internet-Verkehrs auf lokale Internetanschlüsse und eine Web Security Cloud zum ersten Mal seit zwei Jahrzehnten demnächst für das WAN niedrigere Bitraten gefordert werden als vor drei Jahren, in der letzten WAN-Ausschreibung.
Lokale Internetanschlüsse und die Web Security Clouds weisen häufig eine höhere Skalierbarkeit auf als die Kombination aus zentralem Internetanschluss, On-Premise-Proxies und dem eigenen WAN.
Speziell für die Nutzung von Office 365 entledigt man sich bei der Nutzung von Web Security Clouds solcher Probleme wie die Pflege von O365-URLs auf Proxies. Diese URLs müssen von Proxies anders behandelt werden als der Restverkehr, zum Beispiel indem der Zugriff auf O365 ohne Verzögerung durch Authentisierung am Proxy erfolgt, bzw. UDP-Verkehr am Proxy vorbeigeführt wird. Dies alles übernimmt der Security-Cloud-Anbieter.
Durch die Größe der Community der Nutzer einer Web Security Cloud erhofft man sich größere Sicherheit vor Day-Zero-Angriffen, weil man dem Betreiber einer Cloud eine schnellere Reaktion auf solche Ereignisse zutraut als der eigenen Organisation.

Problematisch könnte der Kostenaspekt werden. Mein Eindruck ist, dass nach anfänglicher Anlockung von Kunden mit relativ niedrigen Preisen die Anbieter von Web Security Clouds nun die Preise anziehen. Die Gesamtkosten bestehen aus den monatlichen Gebühren pro User und den Kosten für den Betrieb der Tunnel-Endpunkte, die man nach wie vor braucht.

Eine andere Frage ist, wie weit verzweigt das Netz der Proxy-Cloud ist. Nicht in jedem Land der Welt sind die Cloud-Proxies vertreten. Wenn zum Beispiel eine Cloud in ganz Südamerika nur einen Proxy-Standort hat, sagen wir in Brasilien, müssten alle Benutzer in Südamerika diesen Proxy nutzen. Damit kann es einige Probleme geben. Einige Staaten lassen den Zugriff auf solche Seiten wie die der Behörden (Zoll, Finanzamt etc.) nur zu, wenn anhand der IP-Adresse eine Quelle aus dem Inland erkennbar ist. Ferner nutzen einige Web Sites die IP-Quelladresse zur Anpassung der Sprache und der Werbung. Mit Befremden würde eine argentinische Nutzerin auf Webseiten in Portugiesisch mit Werbung für brasilianischen Fußball stoßen.

Es stellt sich die Frage, wie ein Unternehmen das Internet sowohl für den Zugriff auf externe Clouds als auch für den Zugang zu internen Applikationen nutzen kann. Viele Unternehmen setzten für Letzteres statt teurer Dienste wie MPLS das Internet ein, indem sie verschlüsselte Tunnels über das Internet aufbauen, sogenannte Virtual Private Networks (VPNs), in der Regel mittels IPsec.

Abbildung 5 zeigt, dass eine solche Kombination durchaus möglich ist.

Abbildung 5: Kombination aus VPN für interne Kommunikatin und Tunnels zu einer Web Security Cloud

Wie in der Abbildung 5 dargestellt kann an jedem Standort eine Komponente zum Einsatz kommen, die sowohl in das interne VPN eingebunden ist als auch den Tunnel zur Web Security Cloud unterhält. Diese Komponente muss lediglich die Intelligenz besitzen, Pakete an interne Ziele anhand ihrer Zieladresse zu erkennen und in den IPsec-Tunnel für das VPN zu routen. Andere Pakete werden über einen anderen Tunnel, zum Beispiel einen GRE-Tunnel, zur Web Security Cloud geführt, wo sich der Cloud-Proxy befindet. Komplexe Sicherheitsfunktionen wie Content-Analysen sind auf dieser relativ einfachen Komponente nicht erforderlich, denn sie lässt keinen direkten Internet-Zugriff zu. Ein preiswerter Router reicht aus. Auch der Betrieb eines solchen Routers ist nicht aufwändig. Er hat ja eine relativ statische, einfache Konfiguration. Zur einfachen VPN-Konfiguration kommt nicht viel hinzu, nur der zusätzliche GRE-Tunnel.

Das Internet ist nicht der einzige Weg für den Zugriff auf externe Clouds. Es gibt auch die Möglichkeit, eine dedizierte, vom Internet unabhängige Verbindung zur Cloud zu nutzen. Da ist zum Beispiel der Dienst ExpressRoute von Microsoft. Die Nutzung von ExpressRoute würde der Abbildung 2 entsprechen mit dem Unterschied, dass die dedizierte Verbindung nicht über das Internet geführt wird, sondern eine direkte Leitung zur Microsoft-Cloud nutzt. Microsoft selbst erwähnt in den Anleitungen für Office 365 diese Möglichkeit und führt dafür folgende Vorteile auf:

Existenz eines Service Level Agreement (SLA) mit garantierter Verfügbarkeit
Vorhersehbare Performance durch dedizierte Leitung
Unterstützung von QoS (Quality of Service)
Vermeidung der Übertragung kritischer Daten über das Internet
Vermeidung der Nutzung von Sicherheitskomponenten und dadurch Entlastung derselben sowie Vermeidung eventueller Flaschenhälse
UDP-Unterstützung für Echtzeit-Voice/-Video

Andererseits weist Microsoft selbst auf einige Nachteile dieser Lösung hin:

Einige für Office 365 relevante Inhalte müssen weiterhin über das Internet (z.B. über Conent Delivery Networks, CDNs) erreichbar sein.
Es kommt je nach Konstellation zu höherer Latenz durch eine zentral geführte ExpressRoute.
ExpressRoute ist mit höheren Kosten im Vergleich zum Zugriff über das Internet verbunden.
Für die Einrichtung der ExpressRoute ist längere Zeit einzuplanen, als die Bereitstellung einer Internetverbindung an Zeit kostet.
Die IP-Adressen der Microsoft-Cloud müssen im internen Netz geroutet werden.
Die DNS-Namen der Cloud müssen im internen Netz aufgelöst werden.
Es stellt sich die Frage der Skalierbarkeit der ExpressRoute, wenn sie nur an einer Stelle vorgesehen wird.

Die ExpressRoute ist aber eine typische Lösung für die Verlängerung des eigenen Rechenzentrums in die Azure-Cloud.

Software-Defined WAN

In den letzten Jahren wurde in einigen Beiträgen im Netzwerk Insider auf den Ansatz Software-Defined WAN (SD-WAN) eingegangen. Eine wichtige Funktion von SD-WAN ist die Bündelung verschiedener standortübergreifender Netze (Internet, MPLS) zu einem Overlay-Netz, das von der Mehrzahl der Verbindungen in Form höherer Verfügbarkeit und Leistung profitiert.

Ein SD-WAN kann man selbst aufbauen. Möglich ist aber auch die Nutzung eines SD-WAN-Dienstes, wie zum Beispiel Ngena. Dieser Dienst basiert auf der Kooperation zwischen Providern, die in verschiedenen Ländern unterschiedlich dichte Netze betreiben. Zusammen werden sie in die Lage versetzt, weltweit eine stärkere Präsenz zu erreichen als ohne Kooperation möglich ist. Für Ngena nutzen die Provider die Cisco-Viptela-Technologie.

Cisco hat in 2017 den SD-WAN-Pionier Viptela akquiriert und ist seitdem dabei, die Viptela-Lösung mit den traditionellen WAN-Lösungen auf Basis von Cisco-Routern zu kombinieren.

Ein Vorteil der Viptela-Lösung besteht in der Intelligenz, die darin für die Erkennung von Cloud-Verkehr wie Kommunikation mit Office 365 enthalten ist. Sind verschiedene Wege zur Cloud verfügbar, kann die Performance der Anwendungen über diese Verbindungen gemessen werden. Die Ergebnisse dieser Messungen berücksichtigt die SD-WAN-Komponente an einem Standort für die Wahl der optimalen Route zur Cloud.

Neben der SD-WAN-Ausprägung von solchen Lösungen wie Cisco/Viptela gibt es andere Wege, WAN-Overlays für optimale Wege zur Cloud zu bilden. Eine neue Lösung dafür ist Microsoft Virtual WAN.

Die Idee hinter Virtual WAN von Microsoft besteht darin, dass das weltweite Microsoft-Netz sowohl für Verbindungen zur Microsoft-Cloud als auch für die Vernetzung von Standorten eines Unternehmens genutzt wird. Die Voraussetzung dafür ist ein Internetanschluss an jedem Standort, der an das Virtual WAN angeschlossen wird. Der Internet Service Provider (ISP) sollte ein möglich gutes Peering zum Microsoft-Netz haben. Virtual WAN ist umso effizienter, je kürzer der Weg jedes Standorts zum weltweiten Microsoft-Backbone ist.

Zwischen jedem Standort und Microsoft Azure wird für den Aufbau von Virtual WAN ein IPsec-Tunnel aufgebaut. Dieser Tunnel kann manuell aufgebaut werden, indem zum Beispiel physische VPN-Gateways an jedem Standort und virtuelle in Azure genutzt werden. Microsoft empfiehlt jedoch die Nutzung der Azure-Bedienoberfläche, um Virtual WAN aufzubauen. Voraussetzung hierfür ist, dass der Kunde Komponenten eines dieser Microsoft-Partner für die Tunnels einsetzt:

Barracuda Networks,
Check Point
Citrix
Netfoundry
Palo Alto Networks
Riverbed Technology
128 Technology

Bisher sind leider einige führende VPN-Gateway-Anbieter wie Cisco oder Fortinet in der Liste nicht vertreten.

Natürlich ist die Nutzung des Microsoft-Backbones mit Kosten verbunden, die zu den Kosten für die Internetanschlüsse hinzukommen. Deshalb ist Microsoft Virtual WAN teurer als ein simples Internet-VPN. Es bietet ja auch mehr, vor allem die Optimierung der Kommunikation mit der Microsoft-Cloud. Die Kosten für Virtual WAN setzen sich zusammen aus:

sogenannten VPN-Skalierungseinheiten (zum Zeitpunkt der Verfassung dieser Zeilen 0,305 € pro 500 Mbit/s und Stunde),
sogenannten VPN-Einheiten für Site-zu-Site-Verbindungen (zum Zeitpunkt der Verfassung dieser Zeilen 0,068 € pro Site-to-Site-Verbindung und Stunde) und
regulären Datenübertragungssätzen in Azure für Datenübertragungen über VPN-Verbindungen mit den Standorten oder mit dem Internet.

Trotz dieser relativ komplexen Kostenstruktur kann Microsoft Virtual WAN je nach Konstellation mit niedrigeren Kosten als MPLS verbunden sein. Je höher die Kosten für die sogenannten Local Loops (Stichleitungen zum MPLS-Backbone eines Providers), desto wahrscheinlicher sind Kosteneinsparungen durch Nutzung von Virtual WAN im Vergleich zu MPLS.

Somit steht Microsoft Virtual WAN in Konkurrenz zu den MPLS-Diensten der klassischen internationalen WAN-Provider wie AT&T, Verizon, BT und Orange. Interessant ist, dass einige große Internet-affine Konzerne wie Microsoft und Google in 2017 gegen die Aufhebung des Netzneutralitätsgebots in den USA Stellung bezogen. Große Service-Provider wie Verizon hatten sich Vorteile vom Ende der Netzneutralität versprochen. Nun wird Microsoft selbst zum WAN Service Provider und greift das Geschäft von Firmen wie Verizon an. Die Zukunft wird zeigen, wie weit dieser neue Microsoft-Dienst den WAN-Markt verändern wird. Microsoft selbst hat dies in der Hand, indem sie die Preise für Virtual WAN bestimmt. Noch sind sie für mein Empfinden zu hoch.

Die Cloud-Welt besteht nicht nur aus Microsoft

Auch wenn die Microsoft-Cloud in den letzten zwei Jahren in der Akzeptanz durch Unternehmen immens aufgeholt hat, steht sie für IaaS und PaaS an zweiter Stelle hinter Amazon. Insofern besteht die Cloud-Welt nicht nur aus Microsoft. Microsoft Virtual WAN ist zwar eine geeignete Lösung für ein Unternehmen, dessen Cloud-Strategie sich weitgehend an Microsoft orientiert, aber Virtual WAN hat keine Vorteile beim Zugriff auf andere Clouds wie die von Amazon, IBM oder Google.

Je größer ein Unternehmen, desto größer ist dessen Tendenz, die Cloud-Strategie neutral zu gestalten. Solche Unternehmen suchen die optimale Möglichkeit kurzer Wege zu mehr als nur einer Cloud.

Eine denkbare Lösung geht aus der Abbildung 6 hervor.

Abbildung 6: Nutzung von Colocations für Cloud-Verbindungen

Abbildung 6 zeigt ein Szenario, in dem ein Unternehmen zusätzlich zu den eigenen Standorten auch zwei sogenannte Co-Locations an das eigene WAN anbindet oder direkt mit dem eigenen RZ verbindet. Eine Co-Location ist ein RZ-Standort eines darauf spezialisierten Anbieters wie Equnix oder NTT. Die Rechenzentren dieser Anbieter, zum Beispiel im Frankfurter Raum, haben durch das rasante Wachstum in den letzten Jahren eine solche „Gravitationskraft“ entwickelt, dass es viele Unternehmen da hinzieht, neben Unternehmen, die die Clouds nutzen wollen, natürlich auch die Cloud-Anbieter, aber auch Internet Exchanges, WAN-Provider etc. In diesen Rechenzentren können kurze und leistungsfähige Verbindungen zu mehreren Clouds genutzt werden. Natürlich ist die Nutzung einer Co-Location mit Kosten verbunden. Diese Kosten können aber je nach Szenario niedriger sein als die Summe der Kosten der Verbindungen zu allen Clouds, die man nutzen will.

Fazit

Es gibt verschiedene Varianten des Zugriffs auf externe Clouds. Ein wesentlicher Aspekt bei der Auswahl einer dieser Varianten ist der Servicetyp, den man in der Cloud nutzen will. Lösungen für SaaS einerseits und PaaS/IaaS andererseits können unterschiedlich sein. Da Microsoft Office 365 fast jedes Unternehmen betrifft, muss fast jede Organisation einen Weg für den sicheren und performanten Zugriff auf Office 365 finden. Der Weg kann sowohl über das Internet als auch über dedizierte Verbindungen sein. Microsoft bietet mit Virtual WAN einen neuen Ansatz, der jedoch nur den Zugriff auf die Microsoft Cloud optimiert. Die Anbindung über Co-Locations empfiehlt sich vor allem als Provider- und Cloud-unabhängiges Netzdesign für den Zugriff auf verschiedene externe Clouds.

Zugang zu externen Clouds

Kontakt

Services

Rechtliches

Zugang zu externen Clouds

Teile diesen Eintrag

Kontakt

Services

Rechtliches