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.
