Migration zu einem Cloud Proxy Service

Auch wenn es in Europa und speziell der Schweiz etwas länger gedauert hat als z.B. in den USA: Immer mehr Firmen setzen auf die «Cloud» und betreiben diverse IT-Dienstleistungen nicht mehr selber, sondern beziehen diese Services aus dem Internet. So auch Proxy Dienste, mit welchen das Surfen im Web abgesichert wird.

Ein Cloud Proxy hat gegenüber einem «eigenen» lokalen Proxy diverse Vorteile und auch Nachteile. Unter anderem:

• • Flexiblerer Einsatz
    • Ichkann in verschiedensten Ländern Proxies nutzen und nicht nur in meinem eigenen Data Center.
    • Benutzer, welche von zu Hause aus oder von unterwegs arbeiten, können direkt einen Cloud Proxy nutzen und müssen sich nicht via VPN mit der Firma verbinden.
  • Wachstum
    • Ich muss mich nicht darum kümmern, wie grosse Proxy Modelle ich an welchen Standorten installieren muss und brauche kein allfälliges Wachstum von Bandbreite und Benutzerzahl vorausplanen und budgetieren. Ich miete einfach Nutzungsrechte an einem Cloud Proxy Service und der Anbieter ist dafür verantwortlich, entsprechende Ressourcen zur Verfügung zu stellen.
  • Geringere Betriebskosten
    • Ich muss mich nicht um Updates, Redundanz, Platz im Datacenter, Strom usw. kümmern. Dadurch habe ich weniger mit diesen Arbeiten zu tun. Aber natürlich muss ich diese Kosten und Aufwände dem Service Provider vergüten. Entsprechend sind die Subscriptions eines Cloud Services höher als die Lizenzkosten eines normalen Proxies.
  • Neue Features
    • Neue Features können vom Service Provider einfach in der Cloud implementiert werden und stehen dann sofort weltweit allen Kunden zur Verfügung. Ich denke da an Browser Isolation, Sandboxing oder die Unterstützung von neuen Protokollen wie TLS 1.3 oder QUIC / HTTP/3.
  • Abhängigkeit vom Cloud Anbieter
    • Auf meinen eigenen on-premises Proxy habe ich direkten Zugriff und kann z.B. den Netzwerkverkehr zwischen Proxy und Webserver zu Debugging-Zwecken mitschneiden. Dies ist bei einem Cloud Proxy nicht möglich. Im Fehlerfall bin ich auf den Support des Service Anbieters angewiesen.
    • Wenn der Service Provider den Dienst nicht mehr anbieten kann oder will, dann bin ich aufgeschmissen. Sei es auf Grund von Fehlern oder technischen Problemen (Azure, Zscaler, Exchange Online), aus politischen Gründen (viele US Services werden aktuell in Russland nicht mehr angeboten, Beispiel Salesforce, China/Broadcom) oder weil der Hersteller einen Standort / ein Feature nicht mehr lukrativ findet (Samsung Cloud).
  • One size has to fit all
    • Cloud Proxy Services sind im Vergleich zu klassischen Proxies noch verhältnismässig neu. Entsprechend wurden zuerst die wichtigsten Features implementiert, die von praktisch allen potentiellen Kunden benötigt werden (Authentication, URL Filtering, AV, Logging). Erweiterte Features sind erst nach und nach dazu gekommen.
    • Cloud Proxy Services werden meist über ein Web Portal administriert. Dieses bietet nicht die detaillierten Einstellungsmöglichkeiten eines klassischen Proxies. Vieles ist vereinfacht und abstrahiert. Dies ist in den meisten Fällen kein Problem. Wenn ich aber jedes Bit kontrollieren möchte und sehr granulare Regelwerke bauen möchte, so geht das entweder gar nicht oder nur nach Rückfrage beim Service Anbieter.

Diese Liste der Vor- und Nachteile ist natürlich längstens nicht abschliessend.

Mir geht es im Folgenden eher darum, wie wir zu einem Cloud Proxy Service wechseln können, denn auch bei uns in der Schweiz geht der Trend immer mehr in Richtung Cloud Proxy. Wie migriere ich also von einem klassischen on-premises Proxy zu einem Cloud Service? Ich sehe da im Wesentlichen zwei Möglichkeiten.

Ich implementiere den neuen Proxy Service, teste und stelle nach kurzer Zeit den Proxy um. Dabei ist man frei in der Wahl des Anbieters. Ich baue das Proxy Ruleset neu in der Cloud und nutze optimalerweise die Gelegenheit, dieses zu vereinfachen, alte Zöpfe abzuschneiden und «Leichen» aus dem Regelwerk zu entfernen. Jeder Admin weiss, was sich im Laufe der Jahre da so ansammelt. Dies bedingt einige interne Diskussionen zum Ruleset-Design und der umzusetzenden Security Policy. Dafür hat man anschliessend wieder mal schön aufgeräumt. Dadurch wird es aber bei der Umstellung zu gewissen «Rumplern» kommen, da erfahrungsgemäss nicht alles Relevante getestet wurde, weil niemand weiss, was für wichtige Dienste überhaupt den Web-Zugang nutzen und wer für diese Dienste und Anwendungen verantwortlich wäre.

Wenn man diverse Standorte mit eigenen on-premises Proxies hat, so müssen diese alle in relativ kurzer Zeit migriert werden, da man sonst für den alten bestehenden Proxy wie auch den neuen Service über längere Zeit gleichzeitig bezahlen muss.

Parallel dazu oder anschliessend implementiert man auch die neuen Möglichkeiten, welche ein Cloud Proxy Service bietet, wie z.B. den direkten Proxy-Zugriff für Benutzer:innen im Home-Office.

Manche Proxy Hersteller bieten sowohl klassische on-premises Proxies an, aber auch Cloud Services. (Ich denke hier an die Symantec Proxies von Broadcom, auch bekannt als Blue Coat. Einfach, weil ich diese am besten kenne). Hier ist der Weg in die Cloud aus zwei Gründen sehr einfach: Das bestehende Ruleset kann praktisch 1:1 übernommen werden. Und ich kann, wenn gewünscht, die Migration über einen längeren Zeitraum durchführen (oder auch längerfristig beide Welten «hybrid» nutzen), da die Proxy-Lizenzen sowohl Cloud wie auch on-premises Instanzen beinhalten. Ich habe hier also, zumindest aus Kostengründen, keinen Zeitdruck.

Hybrid Lizenzen

Im Falle von Symantec beinhaltet die Web Protection Suite alle wichtigen Features, sowohl für on-premises Installationen wie auch für die Nutzung der Cloud Proxies. Für einen bestimmten Betrag pro User darf ich (in einem vernünftigen Rahmen) beliebig viele on-premises Proxies installieren, aber auch den Cloud Service nutzen. Je nach Bedürfnis kann ich z.B. im Datacenter für Web Zugriffe von Servern klassische Proxies installieren, die Mitarbeiter:innen benutzen den Cloud Proxy im Büro via einem VPN Tunnel zur Cloud und unterwegs oder zu Hause wird ein Client Connector verwendet. Dabei greift in allen Fällen dasselbe Regelwerk.

Universal Policy

Manche Dinge funktionieren bei einem Cloud Proxy etwas anders als gewohnt. Während z.B. «klassisch» die User mittels Kerberos authentisiert werden, wird für die Cloud üblicherweise SAML verwendet. Dazu kann das bestehende Ruleset angepasst werden. Ein Migration Wizard sagt dabei, welche Regeln in der Cloud so keinen Sinn machen und angepasst werden müssen. Weiter kann für jede Regel festgelegt werden, ob diese nur lokal, in der Cloud oder für beides aktiv sein soll. Somit kann das Ruleset sehr schnell migriert werden. Und jede Änderung ist in Zukunft auf allen Proxies aktiv, egal ob on-premises oder in der Cloud.

Wie dies im Fall von Symantec konkret aussieht, möchte ich im Folgenden kurz beschreiben. Man benötigt das (in der Web Protection Suite enthaltene) Management Center. Darauf wird das Ruleset gepflegt und von dort aus auf die Proxies installiert.

Man nimmt sein bestehendes Ruleset (oder ein neues) und wandelt dies in ein Universal Ruleset um:

Dann hat man die Möglichkeit, dieses Ruleset auf die Cloud-Tauglichkeit hin zu überprüfen:

Für das in diesem Beispiel relativ komplexe und umfangreiche Ruleset sieht das dann so aus:

Die meisten Regeln können also automatisch übernommen werden und sind «universell» anwendbar, andere müssen überprüft werden (weil z.B. der Analyzer nicht weiss, ob die benötigte Application Control Lizenz in der Cloud lizenziert ist. Sie ist es, da sie in der Web Protection Suite enthalten ist). Andere Regeln und Policy Layer machen in der Cloud keinen Sinn, da der in diesem Beispiel verwendete Proxy auch als Reverse Proxy verwendet wird, wozu der Cloud Proxy Service nicht gedacht ist. Daher können die entsprechenden Regeln nicht in die Cloud kopiert werden und gelten nur für die lokalen Proxy-Appliances.

Oder weil in der Cloud die verwendete Source IP Adresse des Proxys nicht via Regelwerk festgelegt werden kann, da der Service weltweit diverse IP Adressen verwendet und diese gegebenenfalls ändern können.

Entsprechend muss die Universal Policy angepasst werden. In jeder Regel taucht nun neu eine «Enforcement Location» auf und es kann gewählt werden, ob diese Regel auf den lokalen Appliances, im Cloud Service (WSS) oder universell (auf beiden) aktiv sein soll.

Dann bleibt nur noch, die Policy per Knopfdruck auf den lokalen Appliances und in der Cloud zu installieren und die Migration ist – was das Regelwerk betrifft – abgeschlossen.

• • Wenn man schnell die Proxy Migration durchziehen kann und bereit ist, das Regelwerk neu zu gestalten, dann kann man jederzeit zum Cloud Proxy Service seiner Wahl wechseln.
  • Wenn man aber weiss, dass die Migration etwas länger dauern wird oder aus anderen Gründen auch längerfristig noch klassische on-premises Proxies verwendet werden sollen, dann bietet sich eine hybride Lösung an.
  • Von der (längerfristig) parallelen Nutzung eines klassischen Proxies und eines Cloud Proxy Services von zwei unabhängigen Anbietern rate ich ab, da sowohl der Betriebsaufwand wie auch die Kosten praktisch verdoppelt werden.