Frei nach dem Motto „Vertrauen ist gut, Kontrolle ist besser“ schützen sich Unternehmen neben der reinen Mitarbeitersensibilisierung selbstredend auch in technischer Hinsicht vor dem größten Angriffsvektor auf sensible Daten und die interne Infrastruktur: dem Internet. Hierzu bietet der Markt eine große Vielfalt verschiedener Lösungen an, die sich über unterschiedliche Appliances wie Secure Web/Mail Gateways bis hin zu ausgewachsenen Next Generation Firewalls mit zustandsorientierter Paketinspektion erstrecken. Die Absicherung des gen Internet gerichteten Verkehrs gewinnt zusätzlich zunehmend Bedeutung durch die Verlagerung von lokal installierter Software hin zu „Cloud-based Applications“ bzw. Software-as-a-Service Produkten, deren Datenhaltung und Verarbeitung ins Internet, sprich: die Cloud, ausgelagert wird. Einige Sicherheitsunternehmen nahmen diesen Trend zum Anlass, um ihre Sicherheitslösungen ebenfalls teilweise oder komplett in die Cloud zu verlagern und dadurch Abstand von der klassischen Hub-and-Spoke Topologie zu nehmen (siehe Abbildung 1).
Abbildung 1: Simplifizierte Netzwerktopologie einer Web-Sicherheitslösung in der Cloud
Ein weiterer Grund ist der in den vergangenen Jahren stark fortgeschrittene Wandel des Arbeitsalltags von Unternehmensmitarbeitern: Ein Unternehmen kann nicht mehr davon ausgehen, dass Zugriffe seiner Mitarbeiter auf das Internet ausschließlich aus dem internen Firmennetzwerk erfolgen. Mitarbeiter sind deutlich mobiler unterwegs und arbeiten häufiger im Sinne eines „Road -Warriors“ aus dem Home Office oder unterwegs. Zusätzlich nutzen sie mobile Geräte wie Smartphone oder Tablets, um mit Unternehmensanwendungen zu arbeiten, die ggf. gar keinen direkten Zugriff auf das Firmennetz erfordern. Nichtsdestotrotz werden dort unter Umständen sensible Daten verarbeitet, und ein Unternehmen hat daher ein Eigeninteresse daran, auch solche Geräte bzw. Zugriffe abzusichern. Ein Perimeterschutz alleine ist also nicht mehr ausreichend.
Wir möchten in diesem Artikel das Phänomen „Web Security in der Cloud“ genauer beleuchten, um zu prüfen, ob Unternehmen einen echten Vorteil daraus ziehen können oder ob es sich dabei womöglich nur um einen Trend handelt, der sich auf langfristige Sicht ggf. als das falsche Zugpferd herausstellen könnte.
Sehen wir uns den aktuellen Markt genauer an, erkennen wir, welchen disruptiven Effekt Cloud-basierte Web Security Lösungen erzeugen, siehe Abbildung 2. Der Großteil der im Gartner Report über Secure Web Gateways [1] genannten Unternehmen bietet „konventionelle“ On-Premises Secure Web Gateways an. Darunter mischen sich jedoch auch Hybrid-Lösungen (bspw. Symantec) sowie Unternehmen, die nahezu ausschließlich Cloud-basierte Lösungen anbieten (bspw. Zscaler). Diese „Cloud-only“-Lösungen mischen den Markt stark auf: So wurde Zscaler bspw. im Gartner Report von 2018 zum 8. Mal in Folge als „Leader“ im Segment der Secure Web Gateways benannt.
Der Status Quo
Gehen wir einen Schritt zurück und blicken auf das Gefahrenpotenzial und den Zustand der gegenwärtigen Internetnutzung, um Anforderungen an die Sicherheit identifizieren zu können: Vergangenes Jahr entschloss sich Google dazu, auf die besondere Kennzeichnung von TLS-verschlüsselten Webseiten zu verzichten, da „Nutzer erwarten sollen, dass das Web standardmäßig sicher ist“ [2]. Die Statistiken geben Google zumindest in der Hinsicht Recht, dass der absolute Löwenanteil der Webseiten, welche ein Nutzer täglich aufruft, über TLS verschlüsselt sind: Gemäß Google Transparency Report [3] waren beispielsweise 90 % der Webseiten, die deutsche Chrome-Nutzer am 17. August 2019 aufriefen, via TLS verschlüsselt, siehe Abbildung 3.
Abbildung 2: Gartner Magic Quadrant „Secure Web Gateways“ 2018 [1]
Die Aussage von Google bezogen auf die Sicherheit des Internets als solches ist jedoch mit Vorsicht zu genießen: Dass eine Webseite ausschließlich über einen verschlüsselten Kanal Inhalte vermittelt, ist grundsätzlich zwar die richtige Richtung hin zu einem Internet, welches ein größeres Augenmerk auf den Datenschutz und die Privatsphäre des Nutzers legt. Jedoch bedeutet dies nicht, dass die publizierten Inhalte per se keinen Schadcode enthalten können. Bei wenig technikversierten Nutzern erzeugt die zitierte Maxime den Eindruck, dass eine Seite grundsätzlich vertrauenswürdig ist, wenn ihr Browser sie als „sicher“ kennzeichnet. Das ist aber keineswegs der Fall: Laut Auswertungen des Herstellers Zscaler verbirgt sich über 50% der Malware mittlerweile hinter SSL-/TLS-Verschlüsselung (siehe [4]). Zudem steige die Verbreitung der Malware über diesen Kanal rasant an (30% mehr Malware in einem Zeitraum von 6 Monaten, siehe [5]).
Dieser Zustand ist jedoch logisch bedingt durch die Weiterentwicklung des Mediums „Internet“: Nutzer werden sensibilisiert und angehalten, sich von nicht vertrauenswürdigen Webseiten (sprich: regulären HTTP-Seiten) fernzuhalten. Also entwickeln Angreifer Methoden, um ihren Schadcode über vermeintlich vertrauenswürdige Wege zu verbreiten. Der Aufwand ist bspw. dank „Domain-validierten Zertifikaten“ und kostenfreier Zertifizierung (bspw. durch Anbieter wie „Let’s Encrypt“) nicht sonderlich groß.
Ein verschlüsselter Kanal bewirkt, dass die Kommunikation zwischen Client und Server nicht abgehört, aber auch nicht auf Schadcode inspiziert werden kann. Unternehmen haben selbstverständlich dennoch ein großes Interesse daran, diesen Angriffsvektor abzusichern. An dieser Stelle kommt die Technik der „SSL/TLS Inspection/Interception“ ins Spiel: Vor der Etablierung der TLS-Session mittels HTTP CONNECT Header öffnet das Secure Web Gateway bzw. der Proxy das Paket, um als „friendly Man-in-the-Middle“ zu agieren und dies auch gegenüber dem Client zu kommunizieren (Einsatz eines vertrauenswürdigen Zertifikats).
Prozentsatz der in Chrome über HTTPS geladenen Seiten nach Land [3]
Wir schließen aus den obigen Aussagen zum verschlüsselten Verkehr, dass ein erheblicher Sicherheitsgewinn auf dem Transportweg aus dem Einsatz von TLS/SSL Inspection geschöpft werden kann. Für TLS in den Versionen 1.0 – 1.2 trifft diese Aussage auch vollkommen zu, und die Implementierung ist aus technischer Sicht durchführbar. TLS in der Version 1.3 kann die Hersteller jedoch vor Herausforderungen stellen: Wie in Artikel [6] beschrieben, ist der „Kampf“ um Aufschlüsselungsoptionen aus Provider- und Strafverfolgersicht für TLS 1.3 verloren gegangen. Solange ein Proxy jedoch als explizites Gateway den Zugang zu Webseiten bereitstellt, kann er weiterhin als „friendly Man-in-the-Middle“ agieren, da die HTTPS Session entkoppelt wird. Auch zukünftig kann also eine zusätzliche Transportsicherheit gewährleistet werden.
Das Potenzial der Cloud
Dieses Aufbrechen von TLS-verschlüsseltem Verkehr ist sehr rechenintensiv. Dementsprechend lassen sich Hersteller die Funktionalität gut bezahlen. Beim Einsatz von On-Premises Hardware ist hierbei zudem eine Abwägung zu treffen: Welche Hardware schaffe ich heute an, um auch in Zukunft gegenüber skalierenden Bedingungen in Form von Schwankungen der Nutzeranzahl oder Verbreitung von Malware in verschlüsseltem Verkehr gewappnet zu sein? So oder so: In der Regel ist die Hardware bei Anschaffung überdimensioniert, und Ressourcen bleiben ungenutzt.
Eine Web-Security-Lösung aus der Cloud löst diese Probleme sehr flexibel: Für eine Sicherheitsanalyse von Paketen kann auf die geteilten Ressourcen im Cloud-Rechenzentrum zurückgegriffen werden. Die Kosten beschränken sich dadurch i.d.R. auf die tatsächlich genutzten Ressourcen. Eine Skalierbarkeit bei Änderungen des Nutzungsvolumens ist ebenfalls gegeben, ohne dass eine Anschaffung und Integration weiterer Hardware notwendig wäre. Dies ist insbesondere in den heutigen Zeiten von Vorteil, in denen stetig neue Applikationen in die Cloud ausgelagert werden, deren Nutzungsfälle bisher meist durch On-Premises-Applikationen abgedeckt wurden und dadurch keinen oder ausschließlich internen Datenverkehr erzeugt haben (Stichwort: Office 365), der bisher keine Sicherheitsanalyse des Nachrichtenverkehrs verlangte.
Die Skalierbarkeit bezieht sich jedoch nicht ausschließlich auf das verarbeitete Volumen: Viele Sicherheitsanbieter in der Cloud zielen darauf ab, weitere Sicherheitsfunktionalitäten, die bisher primär von On-Premises-Appliances angeboten wurden, als zusätzliche Funktionalität im ggf. bereits eingesetzten Cloud Service bereitzustellen (natürlich i.d.R. gegen Einwurf zusätzlicher Münzen). Der Haupteinsatzzweck der Web Security Cloud zum Entkoppeln und Filtern des Verkehrs wird dadurch bspw. durch „Value Added Features“ ergänzt, wie bspw. Sandboxing, Intrusion Prevention System (IPS), Data Loss Prevention (DLP) oder Bandbreitenkontrolle.
Flexible Skalierbarkeit ist jedoch nur einer der Aspekte, bei denen Unternehmen von einem Cloud-Deployment der Websicherheit profitieren können. Durch das Bereitstellen der Sicherheitsfunktionalitäten in der Cloud verlagert sich natürlich auch die Administration in die Cloud. Diese kann auf einfachem Wege weltweit standortübergreifend und zentral umgesetzt werden, falls vom Unternehmen gewünscht. Auf diesem Weg kann bspw. auch ein Governance-Konzept umgesetzt werden, welches vorsehen könnte, dass IT-Administratoren der Zweigstellen des Unternehmens beschränkte Administrationsrechte erhalten, um aus administrativer Hinsicht teilweise oder ganz unabhängig vom Hauptstandort zu sein. Das gegenteilige Konzept kann selbstredend auch umgesetzt werden: Die administrative Hoheit über sämtliche Unternehmensstandorte könnte auf einfachem Wege an einen Managed Service Provider abgegeben werden, um bspw. ein standardisiertes unternehmensweites Sicherheitskonzept durchzusetzen.
Eine Wartung und Instandhaltung der bisherigen Security Appliances vor Ort kann ebenfalls entfallen, da sie nicht mehr vorhanden sind. Funktions- und Sicherheitsupdates werden zentral durch den jeweiligen Hersteller eingespielt – so wie Nutzer es bereits von Software-as-a-Service gewohnt sind. Die Bereitstellung von Web Security in der Cloud wird daher auch als „Security-as-a-Service“ bezeichnet. Gesamtbetriebskosten können dadurch im Idealfall komfortabel bedarfsgerecht klein gehalten werden.
Eine Georedundanz ist durch verteilte Rechenzentren der Service Provider i.d.R. auf einfachem Wege umsetzbar. Je nach Service Provider kann man hier zusätzlich ggf. vom guten Peering profitieren, z.B. für Office-365-Transaktionen zu Microsoft-Rechenzentren.
