Da die Public Clouds in der Regel getrennt nach Weltregionen organisiert sind, stellt sich die Frage, wie die überregionale Nutzung einer Cloud aussehen muss.
Andere relevante Fragen, auf die im Folgenden eingegangen wird, beziehen sich auf die Nutzung von Netz- und Sicherheitsfunktionen in der Cloud, wie zum Beispiel Zonen- und VPN-Bildung.
Ferner wird auf Authentisierung, Autorisierung und Verschlüsselung beim Cloud-Zugriff eingegangen.
Typen von Cloud Services
Es wird zwischen verschiedenen Typen von Cloud Services unterschieden:
- Software as a Service (SaaS): Bei diesem Servicemodell ermöglicht der Cloud Provider dem Kunden die Nutzung einer Anwendung in der Cloud. Die Applikation ist über einen Web Browser oder eine andere Software auf dem Endgerät des Benutzers erreichbar. Der Cloud Provider administriert und betreibt die gesamte für die Anwendung erforderliche Infrastruktur, einschließlich des Netzes, der Server, der Betriebssysteme und des Speichers. Der Kunde kann höchstens eingeschränkte kundenspezifische Einstellungen der Anwendung vornehmen.
- Platform as a Service (PaaS): Dieses Servicemodell befähigt den Kunden zur Bereitstellung von eigenen Applikationen in der Cloud. Dabei kann der Kunde Programmierwerkzeuge, Bibliotheken und Dienste nutzen, die der Cloud Provider zur Verfügung stellt. Dieser administriert und steuert die zugrundliegende Cloud-Infrastruktur, einschließlich des Netzes, der Server, der Betriebssysteme und des Speichers. Der Kunde hat die administrative Hoheit über die auf diesem Servicetyp basierenden Anwendungen und kann möglicherweise die Umgebung, die von der Applikation genutzt wird, konfigurieren.
- Infrastructure as a Service (IaaS): Der IaaS Provider setzt den Kunden in die Lage, Prozessor-, Speicher- und Netz-Ressourcen in der Cloud in Betrieb zu nehmen. Der Kunde kann beliebige Software in der Cloud zur Ausführung bringen. Das schließt Applikationen und möglicherweise auch Betriebssysteme ein. Der Kunde hat keine Kontrolle über die Cloud-Infrastruktur, kann aber die eigenen Instanzen der Betriebssysteme, des Speichers und die eigene Anwendung steuern. Der Kunde hat möglicherweise auch eingeschränkten Zugriff auf Netz- und Sicherheitskomponenten wie Firewalls.
Die drei oben genannten verschiedenen Cloud-Servicemodelle sind in der Abbildung 1 dargestellt.
Je nachdem, welches der oben genannten Modelle genutzt wird, gibt es unterschiedliche Anforderungen an den Netzzugang zur Cloud. Diese Anforderungen sind in der Regel bei SaaS am einfachsten und bei IaaS am komplexesten. Bei SaaS kann der Kunde nicht viel in der Cloud steuern und benötigt daher einen relativ einfachen Zugang zur Cloud. Meistens reicht eine Internet-Verbindung zur Cloud. Dagegen kann ein IaaS-Kunde zum Beispiel die Anforderung haben, administrative Aufgaben wie Bereitstellung von Diensten und Applikationen sowie Datensicherung über einen anderen Netzkanal wahrzunehmen als der Kanal, der für Zugriffe der Benutzer auf die Applikationen in der Cloud eingesetzt wird.
Cloud Exchange
Damit die Nutzung einer Public Cloud nicht zu einer Einbahnstraße wird, auf der es kein Zurück mehr gibt, muss ein Unternehmen den Zugang zu Public Clouds möglichst offen gestalten. Im Falle eines reinen Internet-Zugangs ohne jegliche auf die Cloud zugeschnittene Besonderheit ist dies gegeben. In diesem Fall kann man von einer Cloud zur anderen wechseln, ohne den Netzzugang zur Cloud zu ändern. Andere Voraussetzungen müssen natürlich erfüllt werden. Insbesondere ist die Frage zu klären, wie man die Unternehmensdaten von einer zur anderen Cloud bewegen kann. Diese Frage ist kein Gegenstand des vorliegenden Beitrags, dessen Schwerpunkt der Netzzugang zur Cloud ist.
Der Netzzugang zur Cloud ist im Falle der reinen Internet-Nutzung maximal offen und Proivder-unabhängig. Was aber, wenn auf der Verbindung zur Public Cloud Bedingungen zu erfüllen sind, die eine Internet-Verbindung nicht erfüllen kann? Solche Bedingungen können zum Beispiel sein: Sicherstellung von Verfügbarkeits- und anderen Garantien im Rahmen eines Service Level Agreement (SLA) von Ende zu Ende, Quality of Service (QoS) oder Realisierung eines Übertragungskanals, der aus Sicherheitsgründen völlig unabhängig vom Internet sein soll?
Abbildung 1: Cloud-Servicemodelle
Je stärker die Public Cloud einer Private Cloud ähneln soll, umso wahrscheinlicher ist es, dass man mit einer ausschließlichen Internet-Verbindung nicht auskommt. In einigen Fällen wird in einer Public Cloud zum Beispiel eine Virtual Private Cloud (VPC) gebildet. Eine VPC ist eine logisch getrennte Umgebung in der Public Cloud. Sie wird typischerweise im Zusammenhang mit IaaS genutzt. In einer VPC können in der Regel auch private IP-Adressen des Kunden eingesetzt werden. Der Zugang zu einer VPC muss ein zumindest logisch dedizierter Zugang sein, denn private IP-Adressen werden im Internet bekanntlich nicht geroutet (sonst wären sie nicht privat).
Man kann natürlich auch für den Zugang zu einer VPC das Internet nutzen, indem man im Internet ein Virtual Private Network (VPN) nutzt. Cloud Provider unterstützen solche Zugänge. In einigen Fällen will man aber die Nutzung einer VPC auch mit mehr SLA, QoS und Sicherheit verbinden als im Internet möglich ist. Dann entscheidet man sich für einen vom Internet unabhängigen Cloud-Zugang. Man kann zum Beispiel zu dem Standort des Cloud-Providers, an dem die VPC gebildet wird, eine Punkt-zu-Punkt-Verbindung aufbauen, oder diesen Standort in das eigene private Wide Area Network (WAN) einbinden. In beiden Fällen braucht man natürlich die Dienste eines WAN-Providers.
Nun stelle man sich vor, das Unternehmen möchte zu einer anderen Cloud wechseln oder eine andere Cloud zusätzlich nutzen. Bei einer dedizierten WAN-Anbindung pro Cloud werden viele teure WAN-Verbindungen erforderlich. Außerdem kennt man ja die relativ langen Bereitstellungszeiten für Anbindungen von Standorten an das WAN. Man kann nicht einfach, schnell und kostengünstig von einer Cloud zur anderen wechseln oder zusätzlich eine bisher nicht genutzte Public Cloud hinzufügen, wenn jedes Mal eine neue WAN-Verbindung erforderlich wird.
Das Problem wird noch komplexer, wenn die neue WAN-Verbindung aufgrund ihrer Kritikalität auch noch redundant sein muss.
Und es gibt einen weiteren Nachteil, wenn die Nutzung einer Public Cloud nicht isoliert erfolgt, sondern in Verbindung mit der Nutzung anderer Clouds. Man stelle sich zum Beispiel vor, dass in einer bestimmten Applikation auf die Daten einer anderen Applikation zugegriffen wird. Wenn sich die beiden Applikationen in verschiedenen Clouds befinden, dann werden für diese Kommunikation die WAN-Verbindungen zu beiden Clouds belastet. Außerdem entsteht eine höhere Latenz aufgrund der Nutzung von zwei WAN-Verbindungen.
Solche Probleme würden gar nicht entstehen, wenn es Standorte gäbe, an denen möglichst viele Cloud-Infrastrukturen zusammenkämen. Man baut einfach Verbindungen zu solchen Standorten auf, und nutzt diese Verbindungen gleich für den Zugriff auf mehrere Clouds. Innerhalb solcher Standorte könnten zwischen den Clouds direkte Verbindungen genutzt werden.
Die gute Nachricht ist, dass es solche Standorte gibt. Die Cloud Provider haben nämlich das gleiche Problem. Sie müssen ihre Standorte auch unter Rücksicht auf möglichst kurze Wege zu möglichst vielen Kunden und anderen Clouds auswählen. Also haben sich Knotenpunkte gebildet, nicht zufällig in räumlicher Nähe zu einem Internet-Knoten (Internet Exchange). Das nennt sich dann Cloud Exchange. Einige Firmen haben sich darauf spezialisiert, an solchen interessanten Standorten Flächen für Rechenzentren (RZs) anzubieten, mit allem was dazu gehört: Zutrittsschutz, redundante Stromversorgung mit skalierbarer Leistung, ausfallsichere Klimatisierung, Überwachung rund um die Uhr und eben auch redundante Netzzugänge. Anbieter wie Equinix, E-Shelter und Interxion betreiben solche Standorte, die man auch Co-Location nennt.
Die Nutzung von zwei Co-Locations für den Zugriff auf Public Clouds ist in der Abbildung 2 dargestellt.
Abbildung 2: Nutzung von Co-Locations für den Zugang zu Public Clouds
Wie aus der Abbildung 2 hervorgeht, können aus Redundanzgründen zwei Co-Locations für den Zugang zu Public Clouds genutzt werden. An diesen Standorten gibt es jeweils die Möglichkeit, kurze Verbindungen zu verschiedenen Clouds zu nutzen, weil Betreiber dieser Clouds an denselben Standorten Teile ihrer Infrastruktur betreiben. Zur Herstellung der Verbindung zu allen diesen Clouds reicht es aus, Verbindungen zu den zwei Co-Locations aufzubauen. Zum Beispiel können diese beiden Standorte in das private WAN des Unternehmens aufgenommen werden.
In der Abbildung 2 ist angedeutet, dass Firewalls die Verbindungen zu den Public Clouds absichern. Solche Sicherheits-
elemente können dedizierte Komponenten des Unternehmens sein, die an den beiden Standorten aufgestellt werden. Dazu muss man dort natürlich RZ-Flächen bzw. Einbauplätze in RZ-Schränken mieten.
Zugang zur Cloud, aber wohin?
Das Bild „Cloud“, das für die Darstellung eines in der Realität viel komplexeren Gebildes aus Server-, Speicher- und Netzkomponenten sowie den Verbindungen dazwischen verwendet wird, verleitet oft zu dem Trugschluss, Cloud sei Cloud, und es sei egal, wo man sich mit der Infrastruktur eines bestimmten Cloud-Providers verbindet. Dem ist leider nicht so.
Die Cloud Provider kochen auch nur mit Wasser. Sie setzen Server, Speichersysteme, Switches, Router, Firewalls, Load Balancer etc. ein, die auf verschiedene RZ-Standorte des Betreibers der Cloud verteilt sind. Der Virtualisierung sind auch in dieser Infrastruktur Grenzen gesetzt. Man kennt es zum Beispiel aus einigen Angeboten für Unified Communications (UC) aus der Cloud: Wenn man die volle Funktionalität nutzen will, muss man dafür sorgen, dass sich alle Benutzer mit demselben RZ oder zumindest mit derselben Region des Cloud-Betreibers verbinden. Cloud-Betreiber teilen ihre weltweite Infrastruktur häufig in regionale Einheiten auf. Dabei befinden sich die von einem Kunden genutzten Ressourcen in einer bestimmten Region, und nur dort.
Das kann in bestimmter Hinsicht ein Vorteil sein. So kann ein Provider einem Kunden zum Beispiel zusichern, dass dessen Daten die Grenzen der Europäischen Union nicht verlassen.
Diese regionale Zuordnung kann aber zum Problem werden, wenn der Kunde weltweit operiert und dieselben Cloud-Dienste überall in seiner weltweiten Organisation nutzen will. Dann gilt nicht mehr, dass Cloud eben Cloud sei. Denn es stellt sich die Frage, zu genau welchem Standort bzw. welcher Region in der Cloud man die Netzverbindung herstellen soll.
Abbildung 3: Vermaschung der VPCs in verschiedenen Regionen
Zum Beispiel werden VPCs bei Amazon in der Regel einer bestimmten Region zugeordnet bzw. unter Nutzung der Amazon-Ressourcen in einer bestimmten Region gebildet. Nutzt ein Unternehmen VPCs in verschiedenen Regionen und werden Verbindungen zwischen diesen VPCs benötigt, müssen solche Verbindungen explizit hergestellt werden. Zum Beispiel zeigt Abbildung 3 ein Szenario mit drei VPCs in zwei Regionen.
Im Szenario gemäß Abbildung 3 ist zusätzlich zu den drei VPCs noch das RZ im eigenen Gebäude des Kunden zu berücksichtigen. Zwischen diesem und den drei VPCs werden VPN-Verbindungen genutzt. Auf der Seite des Unternehmens-RZs werden diese VPN-Tunnels auf Komponenten des Unternehmens terminiert, auf der Cloud-Seite sind die Tunnelenden VPN-Instanzen der VPCs. Diese können Instanzen sein, die man auch als Cloud-Dienst bezieht. Auch zwischen zwei VPCs in verschiedenen Regionen kann ein VPN-Tunnel aufgebaut werden. Zwei VPCs in derselben Region können innerhalb der Cloud mittels VPC Peering verbunden werden. So entsteht eine Vermaschung der drei VPCs und des RZs des Unternehmens.
Alternativ kann eine sogenannte Transit-VPC zum Einsatz kommen, wie in der Abbildung 4 dargestellt.
Ein Transit-VPC wie in der Abbildung 4 gezeigt dient als zentraler Knotenpunkt, mit dem alle anderen VPCs eines Unternehmens, aber auch Netze außerhalb der Cloud, verbunden werden können. Auch die Verbindung des unternehmenseigenen RZs mit der Cloud erfolgt über die Transit-VPC.
In der Transit-VPC befinden sich die zentralen VPN-Gateways, an denen die VPN-Tunnels zu allen anderen VPCs, aber auch zu Zielen außerhalb der Cloud, terminiert werden. Aus Redundanzgründen sind in der Abbildung 4 zwei zentrale VPN Gateways dargestellt. Die beiden zentralen Gateways befinden sich in unterschiedlichen Availability Zones (AZs) des Cloud-Betreibers. Eine Availability Zone ist hinsichtlich der Verfügbarkeit weitgehend von anderen AZs unabhängig. Sie befindet sich in einem eigenen Brandabschnitt. Es ist sehr unwahrscheinlich, dass zwei AZs gleichzeitig ausfallen.
Abbildung 4: Transit-VPC
Die Anordnung gemäß Abbildung 4 ist ein Doppelstern. Während die Transit-VPC der zentrale Knotenpunkt des Doppelsterns ist, sind die anderen VPCs sowie andere angeschlossene Knoten die dezentralen Punkte in der Topologie. An jedem dezentralen Punk, zum Beispiel in jeder VPC, befindet sich ein VPN Gateway, an dem Tunnels zur Transit-VPC terminiert sind. Die peripheren VPCs können sich in unterschiedlichen Regionen der Cloud befinden.
Natürlich sind die Kosten für die Transit-VPC zu berücksichtigen. Diese umfassen die Mietgebühren für die Transit-VPC selbst, Lizenzen für Gateways und zusätzliche Kosten pro angeschlossene VPC.
Die Nutzung einer Transit-VPC erhöht die Skalierbarkeit einer Anordnung, die aus mehreren VPCs besteht.
Neben den hier dargestellten „Bordmitteln“ in der Cloud, die die Nutzung von Grundfunktionen zum Beispiel im Zusammenhang mit der Bildung von VPCs erlauben, ist es möglich, für Netz- und Sicherheitsfunktionen in der Cloud auch Lösungen von Drittherstellern zu nutzen.
So bietet zum Beispiel Cisco Systems den Cloud Services Router (CSR) 1000V an, der in einer Public Cloud eingesetzt werden kann. Der CSR 1000V unterstützt einige Funktionen, die man von anderen Cisco-Komponenten kennt, so zum Beispiel Dynamic Multipoint Virtual Private Network (DMVPN). DMVPN unterstützt die automatische Einrichtung von VPN-Tunnels. Auf jedem VPN Gateway mit DMVPN-Unterstützung muss man lediglich die Adresse des sogenannten Next Hop Server (NHS) konfigurieren. Der NHS kommuniziert über das Next Hop Resolution Protocol (NHRP) mit allen anderen VPN Gateways. So ist der NHS in der Lage, Informationen über die Erreichbarkeit von IP-Netzen jenseits aller VPN Gateways zu unterhalten. Soll mit einem solchen IP-Netz kommuniziert werden, liefert der NHS jedem Next Hop Client (NHC), d.h. jedem VPN Gateway, die IP-Adresse, mit der ein entsprechender Tunnel aufgebaut werden muss. Dabei handelt es sich um die IP-Adresse des VPN-Gateways, über den das Ziel-IP-Netz erreichbar ist. Dann kann der direkte VPN-Tunnel dynamisch aufgebaut werden.
Eine ähnliche Funktion bietet Palo Alto Networks mit Large Scale VPN (LSVPN) an. LSVPN ist wie DMVPN ein Verfahren für die Einrichtung einer hohen Anzahl von VPN-Tunnels. Dazu wird ein sogenanntes Portal genutzt, das die Managementinstanz für LSVPN darstellt. Mittels des Portals werden die notwendigen Informationen für die Bildung der VPN-Tunnels gepflegt. LSVPN wird auf den Firewalls unterstützt, die als Virtuelle Maschine (VM) in einer Public Cloud eingesetzt werden können und daher als Firewalls der VM-Serie bezeichnet werden.
