Funktion eines Secure Web Gateway
Zunächst ist es angebracht, die grundlegenden Funktionen eines Proxys zu klären. Die Aufgabe eines Proxys, vom englischen „proxy“=Vertreter, steht im Namen. Er fungiert als Vermittler zwischen Client und Server, dabei vertritt er den einen Kommunikationspartner jeweils vor dem anderen. Als Secure Web Gateways bezeichnet man hier Proxys, die für Clients den Internetzugriff bereitstellen und mindestens den HTTP(S)-Verkehr auf TCP-Ebene entkoppeln. So können Inhalte gezielt gefiltert und Bedrohungen abgewehrt werden, sodass sie es gar nicht erst bis zum Client schaffen. Proxys im Netz des Servers werden auch als „reverse Proxy“ bezeichnet und sind für diesen Artikel nicht relevant. Daher ist mit Proxy ab hier immer ein klassisches SWG gemeint. Ein Proxy kann vom Client direkt angesprochen oder durch reines Routing im eigenen Netz zwischen Client und Zieladresse geschaltet werden. Im direkten Fall spricht man vom „expliziten Proxy“, ansonsten vom „transparenten“. Gerade ein „transparenter Proxy“ ähnelt dabei in der Art seines Einsatzes einer Next Generation Firewall, mit dem Unterschied, dass er auf HTTP(S)-Verkehr spezialisiert ist, also „das Internet“ im Sinne der User Experience absichert. In den letzten Jahren haben sich in Zusammenhang mit dem Vormarsch der Cloud zunehmend Proxys als Software as a Service in der Cloud durchgesetzt und zu weitreichenden Veränderungen im Markt geführt.
Abbildung 1: Die ersten Ergebnisse einer Google-Suche nach „Secure Web Gateway“ am 19.10.2020.
Cloud Proxys
Mittlerweile ist das Arbeiten in der Cloud nicht nur etabliert, sondern gar nicht mehr aus der modernen Arbeitswelt wegzudenken. Zwar gibt es neben Datenschutzaspekten auch Gründe der IT-Sicherheit, die gegen den Einsatz von Cloud-Produkten sprechen, doch ebenso kann die IT-Sicherheit davon profitieren, wenn der Einsatz solcher Produkte mit dem Einsatz von Sicherheitslösungen für die Cloud einhergeht. Wie der Cloud Proxy hier ins Bild passt, lässt sich leicht herleiten, wenn man sich folgende Ausgangssituation vorstellt: Ein Unternehmen hat einen großen Teil seiner geschäftsrelevanten Anwendungen in die Cloud migriert und dort entsprechend abgesichert. Dies führt dazu, dass der Hauptverkehr aus den Unternehmensstandorten nicht mehr innerhalb des eigenen Netzes, sondern zwischen dem Office-Netz und der Cloud stattfindet. Dadurch, dass nun der Großteil aller Anfragen der Clients in Richtung Internet zeigt, ist es besonders wichtig, diese Zugriffe abzusichern, also durch ein Secure Web Gateway zu leiten. Hier spricht nichts dagegen, einen On-premises-Proxy einzusetzen, denn irgendwo muss der Internetverkehr abgesichert sein und die Grenze zwischen Office-Netz und Internet ist hierfür ein offensichtlicher Kandidat. Doch auf der anderen Seite spricht nicht nur aus der Sicht der Proxy-Anbieter einiges dafür, einen Cloud Proxy einzusetzen. Hierfür gibt es vor allem zwei Argumente, die im Folgenden näher beschrieben werden: erstens eine Verschlankung der Architektur und zweitens die Integration mit anderen Cloud-Security-Produkten.
Einsatz der Cloud zur Leistungssteigerung
Die Sicherheit steckt beim Proxy als Secure Web Gateway schon im Namen. Er hat eine klare Funktion, nämlich das Absichern des Internetzugangs durch die Analyse und Kategorisierung von Inhalten. Doch der Proxy hat noch eine damit einhergehende Eigenschaft: Er steht in der oben beschriebenen Architektur (nach Traffic bewertet) an der zentralsten Stelle. Jeglicher Internetverkehr muss durch den Proxy fließen, was einerseits eine flexible Skalierbarkeit nötig macht, schließlich wird die Menge an verarbeiteten Daten mit den Jahren selten kleiner. Andererseits eröffnet dies auch architektonische Möglichkeiten, wenn man im obigen Beispiel einen größeren Bildausschnitt des Unternehmens betrachtet (Abbildung 3). Zusätzlich zu eventuellen Nebenstandorten eines Unternehmens wächst die Akzeptanz von Homeoffice, was sich, beschleunigt durch epidemiologische Gründe, zuletzt sogar in Gesetzesvorhaben zur Zementierung des Anspruchs auf mobiles Arbeiten niedergeschlagen hat. Geht man von einem nicht zu vernachlässigenden Anteil des Homeoffice-Traffics am Gesamtdurchsatz aus, zwängt sich der Gedanke geradezu auf, das Bild zu entzerren und den Proxy „in die Cloud zu ziehen“ (Abbildung 4). Nicht zuletzt, da die Internetbandbreite eines Unternehmens durch Homeoffice-Nutzer doppelt belastet wird.
Abbildung 2: Internetverkehr aus dem Firmennetz
Nun ist der Proxy plötzlich nicht mehr nur Sicherheitskomponente, sondern ein Ansatzpunkt, um massiv an der Architektur des gesamten Unternehmensnetzes zu schrauben. Dies ist das erste große Verkaufsargument für Cloud Proxys und es wird nur noch verstärkt, wenn man es weiterspinnt. Denn „Cloud-Produkte“ stehen nicht einfach irgendwo in einer Internet-Wolke, sondern in, zumeist verteilten, Rechenzentren an großen Internet-Knotenpunkten. Im Zweifel steht also der Cloud Proxy, sobald er keine Wolke mehr, sondern eine fest auf dem Boden stehende Maschine ist, neben dem Cloud-Dokumentenspeicher. Diese Nähe spiegelt sich ebenfalls in der Geschwindigkeit wider und so dehnt sich der Vorteil bezüglich der Auslastung der Internetverbindung des Unternehmensstandortes auf die User Experience der Heimarbeiter aus. Denn deren Anfragen hören dann nicht nur auf, durch doppelte Belastung den Internetzugang der Firmen zu verlangsamen, sondern müssen auch nicht mehr zweimal durch den langsamen Firmenanschluss laufen.
Im Regelwerk von Cloud Proxys finden sich Einstellungen, die den Verkehr zu großen Cloud-Anwendungen besonders schnell abwickeln. Gewisse Anwendungen kann man etwa als für die Nutzer sicher deklarieren, sodass eine (ggf. Latenz erzeugende) Inhaltsanalyse entfällt. Dies kann man damit rechtfertigen, dass die entsprechende Anwendung entweder selbst schon abgesichert ist, oder aber die Anwendung mit einer Lizenz- oder Produkterweiterung direkt mit abgesichert werden kann.
Secure Web Gateway als „Gateway Drug”
Gerade bei der Absicherung des Zugriffs von Nutzern auf eigene Cloud-Anwendungen ist oft weniger entscheidend, dass der Nutzer vor den Anwendungen geschützt wird, sondern vielmehr, dass die Anwendungen und Daten geschützt werden, auf die zugegriffen wird. Hiermit ist man eher bei der Beschreibung von Funktionen eines Cloud Access Security Broker (CASB). Da mit dem Proxy schon ein Punkt im eigenen Netz (oder zumindest unter eigener Hoheit) existiert, durch den solche Zugriffe auf jeden Fall geleitet werden, bietet er sich an, um diese Funktionalität zu integrieren. Hierbei hört es jedoch nicht auf. Je kreativer man bei der Betrachtung der Architektur um den Cloud Proxy wird, desto mehr Sicherheitsfunktionen bieten sich, die dort vereint werden können. Die Anbieter von Proxy-Lösungen in der Cloud haben das schon lange erkannt und stellen oft eine große Palette an hinzubuchbaren Features zur Verfügung. Hierzu gehören neben den CASB-Funktionen unter anderem Data Loss Prevention, eine Cloud-Firewall, oder das Sandboxing von aus dem Internet heruntergeladenen Dateien.
Abbildung 3: Firmennetz und Homeoffice
Eine zweite Art, wie ein Secure Web Gateway als Einstiegsdroge in die Cloud Security genutzt werden kann, ist der Cloud-hybride Proxy. Hierzu soll wieder ein Beispiel zur Anschauung dienen. Angenommen, ein Unternehmen entwickelt sich, wie oben schon beschrieben, hin zu mehr mobilem Arbeiten sowie parallel dazu zu mehr Einsatz von Office-Lösungen in der Cloud, möchte aber seine bestehende Proxy-Lösung nicht aufgeben, dann kann es hierfür verschiedene Gründe geben. Etwa kann gewünscht sein, die Hoheit über die eigenen Daten zu behalten, oder Nutzerdaten aus Datenschutzgründen nicht in der Cloud zu halten. Auch ganz pragmatisch betrachtet ist der Austausch einer kompletten Proxy-Lösung nichts, was auf die leichte Schulter genommen werden darf. Der Proxy betrifft den Internetzugriff jedes einzelnen Nutzers, und bei Nichtverfügbarkeit ist die Kommunikation nach außen so gut wie nicht mehr möglich. Schon allein dieser Umstand macht deutlich, wie gut geplant ein eventueller Austausch sein muss und dass dies keineswegs kurzfristig erfolgen kann. Doch die Tragweite der Nichtverfügbarkeit des Internetzugriffs wird noch deutlicher, wenn man sich die zweite Voraussetzung des beschriebenen Unternehmens in Erinnerung ruft: den vermehrten Einsatz von Office-Produkten in der Cloud. Jetzt bedeutet ein Internetausfall im schlimmsten Fall nicht mehr nur keine Außenkommunikation, sondern auch Arbeitsunfähigkeit großer Teile der Belegschaft.
Glücklicherweise muss die Entscheidung für oder gegen einen Austausch der Proxy-Infrastruktur durch eine Cloud-Lösung oft gar nicht getroffen werden. Viele Anbieter klassischer On-Premises-Proxys haben bei der Erweiterung ihrer Produktpalette um das Cloud-Pendant auch hybride Ansätze möglich gemacht. Diese Hybridlösungen können beispielsweise so aussehen, dass das nutzerbasierte Hauptregelwerk On-Premises gepflegt und zum Cloud Proxy synchronisiert wird. Dorthin können sich dann Homeoffice-Nutzer verbinden, für die gegebenenfalls spezielle Regeln gelten. Dabei kann es sein, dass der Funktionsumfang des Cloud Proxys eingeschränkter ist, weil der Cloud Proxy in der Produktpalette eine Doppelrolle einnimmt. Einerseits ist er der beschriebene verlängerte Arm der On-Premises-Proxy-Lösung. Andererseits kann er auch Teil eines größeren Portfolios von Cloud-basierten Produkten sein.
Abbildung 4: Entzerrung durch Cloud-Proxy
Fazit
In der Welt der Cloud können die Grenzen zwischen einzelnen Produkten leicht verschwimmen, nicht zuletzt, weil man keine einzelnen Appliances mehr beschaffen und betreiben muss. Mit wenig Aufwand lassen sich nicht nur bestehende Features skalieren, sondern neue hinzubuchen. Das ist keine Besonderheit des Secure Web Gateway, wird in diesem Zusammenhang aber besonders deutlich, da jenes das Tor zur Cloud bildet. Vor allem die Abgrenzung zum Cloud Access Security Broker fällt hier zuweilen schwer.
Ist damit die Eingangsfrage beantwortet? Ein Secure Web Gateway ist Stand 2020 nichts als ein Schritt zum CASB oder sogar bald dasselbe? Das wäre wiederum zu weit gedacht. Erstens gibt es weiterhin Unternehmen, die ihre Anwendungen nicht in die Cloud auslagern und einen Proxy lieber On-Premises betreiben. Zweitens wird es wohl in der Cloud in Zukunft reine Secure Web Gateways geben nicht trotz, sondern gerade wegen der Einfachheit, Funktionen bei Bedarf hinzuzubuchen. Einerseits zahlen Unternehmen ungern für Features, die sie nicht brauchen. Andererseits verkauft sich ein kleineres Produkt mit der Option auf spätere Erweiterung wesentlich leichter als das Komplettpaket. Fürs Erste bleibt ein Secure Web Gateway also ein Proxy, allerdings einer, der bei Bedarf und entsprechendem Einwurf von Münzen immer interessanter und vielfältiger wird.
