Sichere Web-Gateways: Cloud vs. lokale Lösungen
- Sichere Web-Gateways in der Cloud und vor Ort unterscheiden sich hauptsächlich darin, wo der Datenverkehr entschlüsselt und überprüft wird.
- Cloud-SWGs eignen sich für Remote-Benutzer und SaaS; lokale SWGs eignen sich für regulierten, internen und OT-Datenverkehr.
- Latenz, Souveränität, Ausfallsicherheit und Kosten bei hohen Stückzahlen sind wichtiger als immer ähnlicher werdende Funktionslisten.
- Ein Hybrid- secure web gateway -System überprüft jeden Nutzer und jede Website am optimalen Punkt im Rahmen einer einheitlichen Richtlinie.
- Werden beide Modelle ohne eine gemeinsame Richtlinien-Engine betrieben, kommt es zu Abweichungen zwischen den Nutzern im Büro und den Remote-Nutzern.
Ein lokal installiertes „ secure web gateway “ ist ein physisches oder virtuelles Proxy-Gerät, das in Ihrem eigenen Rechenzentrum oder Ihrer Niederlassung betrieben wird und den Webdatenverkehr vor Ort überprüft. Ein „Cloud- secure web gateway “ erfüllt dieselbe Funktion von den Standorten des Anbieters aus. Viele Unternehmen benötigen mittlerweile beides, weshalb sich hybride SWG-Lösungen zu einer gängigen Architektur für regulierte Unternehmen entwickelt haben.
Dieser Artikel ist Teil des Leitfadens zur Hybrid-Cloud-Sicherheit.
Was ein „ secure web gateway “ macht
Ein „ secure web gateway “ ist zwischen den Benutzern und dem Internet geschaltet, um Bedrohungen abzuwehren, die zulässige Nutzung durchzusetzen und Datenverluste zu verhindern – unabhängig davon, wo er betrieben wird.
In der Regel umfasst dies:
- Filterung nach URL und Kategorie
- TLS-Entschlüsselung und -Überprüfung
- Malware-Prüfung, Sandboxing und „ remote browser isolation “ für risikobehaftete Websites
- Data loss prevention für Uploads und Formularübermittlungen
- Transparenz und Kontrolle bei Cloud-Anwendungen
- Protokollierung zu Ermittlungs- und Compliance-Zwecken
In der NIST SP 800-215 werden SWGs als Teil der punktuellen Sicherheitslösungen aufgeführt, die moderne Unternehmensnetzwerke mit ZTNA, CASB und anderen Kontrollmaßnahmen kombinieren, da die traditionelle Perimeter-Sicherheit zunehmend an Bedeutung verliert.
Cloud-basierte vs. lokal installierte SWG: Direktvergleich
Der wesentliche Unterschied zwischen Cloud-basierten und lokal installierten SWGs besteht darin, wo die Überprüfung stattfindet und wer für deren Durchführung verantwortlich ist.
| Faktor | Wolke SWG | Lokale SWG |
|---|---|---|
| Ort der Inspektion | Präsenzstandorte der Anbieter | Ihre Rechenzentren und Niederlassungen |
| Am besten geeignet für | Benutzer an entfernten Standorten und mobile Benutzer, Datenverkehr direkt zu SaaS-Diensten | Nutzer in Büros, Werken und Rechenzentren; interner Datenverkehr |
| Latenz | Hängt von der Entfernung zum nächstgelegenen Standort ab | Minimale zusätzliche Hop-Anzahl für Nutzer vor Ort |
| Wo sich entschlüsselte Daten befinden | Anbieterinfrastruktur | Ihre Infrastruktur |
| Speicherort des Protokolls | Vom Anbieter ausgewählte oder konfigurierbare Regionen | Wo auch immer Sie es aufbewahren |
| Abhängigkeit von externen Verbindungen | Erforderlich | Für die unterstützte lokale Überprüfung nicht erforderlich; für Cloud-basierte Dienste ist eine Internetverbindung erforderlich |
| Kapazitätsplanung | Verantwortung des Anbieters | Ihre Verantwortung |
| Betriebsaufwand | Geringerer Hardware-Aufwand; Richtlinien und Ausnahmen bleiben in Ihrer Hand | Der Lebenszyklus der Hardware, die Installation von Patches und die Skalierung liegen in Ihrer Verantwortung |
| Kostenmodell | Pro Nutzer oder nach Verbrauch, skaliert mit der Nutzerzahl | Hardware und Lizenzen, skalierbar je nach Durchsatz |
| Air-Gapped-Netzwerke | Nicht geeignet | Nur dort, wo dies ausdrücklich unterstützt wird und alle Abhängigkeiten berücksichtigt sind |
Ort der Inspektion
Der Ort der Überprüfung bestimmt, wer die entschlüsselten Inhalte bearbeitet.
Für viele Datenverkehrsklassen kann ein Cloud-SWG mit entsprechenden Kontrollmechanismen und Zertifizierungen die Anforderungen erfüllen. Bei regulierten Dateninhalten kann eine lokale Überprüfung die externe Verarbeitung reduzieren; prüfen Sie jedoch vor der Wahl des Überprüfungsortes die weitergeleiteten Dienste, die Protokollierung, die Nachweismöglichkeiten, den Zugriff sowie die geltenden Anforderungen.
Die NSA-Leitlinien zum Risikomanagement bei der TLS-Überprüfung empfehlen, die TLS-Überprüfung einmalig innerhalb des Unternehmensnetzwerks durchzuführen und Ketten von Proxys zu vermeiden, die jeweils denselben Datenverkehr entschlüsseln. Bei hybriden Konzepten sollte sichergestellt werden, dass ein bestimmter Datenfluss entweder vom lokalen Gateway oder vom Cloud-Gateway entschlüsselt wird, nicht von beiden. Siehe „Lokale vs. Cloud-TLS-Überprüfung: Abwägungen bei der Bereitstellung“.
Latenz und Benutzererlebnis
Die Latenz hängt vom tatsächlichen Routing, der Entfernung zum Point-of-Presence, der Gateway-Kapazität und der Überprüfungslast ab.
Für Remote-Benutzer kann ein Cloud-SWG das Nutzererlebnis verbessern, indem der VPN-Backhaul zur Zentrale entfällt. Für Benutzer vor Ort kann eine lokale Überprüfung den Datenweg über die Cloud vermeiden, während eine Überprüfung in der Cloud je nach Zielort und Netzwerkdesign weiterhin sinnvoll sein kann. Messen Sie den Unterschied für:
- Echtzeitanwendungen wie Sprach-, Video- und Handelsplattformen
- Übertragung großer Dateien und Software-Updates
- Standorte, die weit vom nächstgelegenen Standort des Anbieters entfernt sind
- OT- und industrielle Systeme mit strengen zeitlichen Anforderungen
Richtliniensteuerung
Beide Modelle setzen eine detaillierte Richtlinie durch; die eigentliche Frage ist, ob Cloud- und lokale Gateways dieselbe Richtlinie verwenden.
Unternehmen, die neben einem separaten Cloud-Dienst auch eine Flotte älterer Geräte betreiben, verwalten häufig zwei Regelsätze, zwei Ausnahmelisten und zwei DLP-Konfigurationen. Im Laufe der Zeit werden ein Benutzer im Büro und derselbe Benutzer zu Hause unterschiedlich behandelt, und niemand bemerkt dies, bis es zu einem Audit oder einem Vorfall kommt.
Ein hybrides SWG mit einheitlicher Richtlinienverwaltung ermöglicht es Teams, eine Regel einmal festzulegen und sie an jedem Gateway anzuwenden. Skyhigh SWG for Hybrid unterstützt beispielsweise eine einheitliche Richtlinienverwaltung über lokale und Cloud-basierte Durchsetzungspunkte hinweg, wobei die Richtlinien einmalig in der Cloud-Konsole erstellt werden.
Betriebsaufwand
Cloud-SWGs reduzieren den Hardware-Aufwand, doch die Verwaltung von Richtlinien, Ausnahmen und Zertifikaten bleibt in beiden Modellen Aufgabe Ihres Teams.
Cloud-SWGs machen die Beschaffung von Hardware, die Kapazitätsplanung und die Installation von Patches für Appliances überflüssig. Sie entfallen jedoch nicht die Ausarbeitung von Richtlinien, die Behandlung von Ausnahmen, die Zertifikatsverwaltung oder die Triage von Vorfällen. Diese Aufgaben bleiben in beiden Modellen weiterhin Aufgabe Ihres Teams.
Lokale SWGs erfordern ein Lebenszyklusmanagement: Hardware-Erneuerungen, Betriebssystem-Upgrades und Skalierung zur Bewältigung des steigenden Datenverkehrs. Virtuelle und containerisierte Appliances reduzieren diesen Aufwand teilweise. Ein Wechsel der Anbieterplattform kann ungeplante Betriebskosten verursachen. Kunden von Symantec Edge SWG (ehemals „ Blue Coat “ ProxySG) sehen sich beispielsweise mit dem Ende des Supports für SGOS 7.3 und der Entfernung der Java-basierten Verwaltungskonsole in SGOS 7.4 konfrontiert. Siehe „Blue Coat “ und „ProxySG End of Life: Migration Planning“.
Resilienz
Lokale SWGs führen ihre Überprüfungen auch dann fort, wenn die Verbindung nach außen ausfällt, während Cloud-SWGs vom Anbieter und dem Netzwerkpfad zu diesem abhängig sind.
Ein Cloud-SWG ist auf die Verbindung zum Anbieter und auf dessen Verfügbarkeit angewiesen. Die meisten Unternehmen akzeptieren dies für Remote-Benutzer. Für eine Fabrik, ein Krankenhaus, einen Handelsraum oder eine staatliche Einrichtung kann es jedoch inakzeptabel sein, wenn während eines Ausfalls die Webüberprüfung ausfällt oder der „Failing Open“-Modus aktiviert wird. Lokale Gateways setzen die Überprüfung des Webverkehrs vor Ort fort, wenn externe Verbindungen ausfallen. Dienste, die von der Anbieter-Cloud abhängig sind, wie beispielsweise Datensicherung und „ remote browser isolation “, stehen erst wieder zur Verfügung, wenn die Verbindung wiederhergestellt ist. Siehe „Hybrid-SSE-Ausfallsicherheit: Failover und Wiederherstellung“.
Migrationsanforderungen
Jede SWG-Migration – sei es zwischen verschiedenen Modellen oder zwischen verschiedenen Anbietern – umfasst dieselben sechs Schritte:
- Aktuelle Richtlinien zur Bestandserfassung, Ausnahmen, Authentifizierungsbereiche und Integrationen wie ICAP und DLP.
- Legen Sie fest, welche Benutzer und Standorte zu welchem Durchsetzungspunkt verlagert werden sollen.
- Stellen Sie die Datenverkehrssteuerung wieder her: explizite Proxy- oder PAC-Dateien, Agenten, Tunnel oder Browsersteuerungen.
- Erneuern und verteilen Sie die Zertifizierungsstelle für TLS-Prüfzertifikate.
- Führen Sie dies vor der Umstellung parallel mit einer Pilotgruppe durch.
- Führen Sie die Umstellung schrittweise durch und legen Sie dabei einen erprobten Rollback-Plan fest.
Siehe „Secure Web Gateway -Migration: Checkliste für die Umstellung und den Rollback“.
Welches Modell ist das richtige für Sie?
Treffen Sie Ihre Entscheidung danach, wo sich Ihre Nutzer, Anwendungen und regulierten Daten befinden, und nicht anhand von Funktionslisten.
Entscheiden Sie sich vorrangig für die Cloud, wenn die meisten Nutzer remote arbeiten, die meisten Anwendungen als SaaS bereitgestellt werden und keine gesetzlichen Vorschriften oder vertraglichen Bestimmungen eine lokale Verarbeitung des entschlüsselten Datenverkehrs vorschreiben.
Entscheiden Sie sich vorrangig für eine lokale Lösung, wenn für ausgewählten Datenverkehr eine lokale Verarbeitung oder Kontinuität erforderlich ist. Bei Air-Gapped-, klassifizierten oder OT-Umgebungen überprüfen Sie bitte die ausdrückliche Produktunterstützung sowie alle Abhängigkeiten in Bezug auf Verwaltung, Identitätsmanagement, Updates, Lizenzierung und Überwachung.
Entscheiden Sie sich für eine Hybridlösung, wenn Sie sowohl Nutzer im Büro als auch im Homeoffice haben, regulierte Daten neben dem allgemeinen Datenverkehr übertragen werden oder Sie über eine bestehende Gateway-Infrastruktur vor Ort verfügen, die Sie modernisieren möchten, ohne dabei zwangsläufig in die Cloud wechseln zu müssen. Dies trifft auf die meisten Großunternehmen in regulierten Branchen zu.
Der Hybrid secure web gateway
Eine hybride SWG vereint lokale Appliances und Cloud-Präsenzpunkte unter einer einzigen Richtlinien-Engine, einer einzigen Konsole und einem einzigen Protokollsatz.
Der interne Datenverkehr wird vor Ort überprüft, der externe Datenverkehr in der Cloud, und der regulierte Datenverkehr wird dort kontrolliert, wo dies gemäß den Richtlinien erforderlich ist.
Skyhigh Hybrid SSE Mesh erweitert dieses Modell über Web-Gateways hinaus und integriert lokale ZTNA, sichere Browsersteuerungen sowie Cloud-basierte CASB-, DSPM-, DLP- und RBI-Funktionen unter ein und derselben Richtlinie.
Quellen
- NIST. SP 800-215: Leitfaden für eine sichere Unternehmensnetzwerkinfrastruktur (November 2022). https://csrc.nist.gov/pubs/sp/800/215/final
- NSA. Umgang mit Risiken durch die Überprüfung der Transportschicht-Sicherheit (November 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
- Skyhigh Security. Secure Web Gateway für Hybrid. https://www.skyhighsecurity.com/products/secure-web-gateway-for-hybrid.html
- Skyhigh Security. „Skyhigh Security belegt Platz 1 im Bereich ‚Advanced SSE Use Case‘ im Gartner-Bericht ‚ Critical Capabilities ‘ für 2026 Security Service Edge“ (5. August 2026). https://www.globenewswire.com/news-release/2026/08/05/3339504/0/en/skyhigh-security-ranked-1-in-advanced-sse-use-case-in-2026-gartner-critical-capabilities-for-security-service-edge.html
- Broadcom. Ende der Unterstützung und Produktlebenszyklus für Edge SWG (ProxySG) und Advanced Secure Gateway (KB 151102). https://knowledge.broadcom.com/external/article/151102/end-of-life-and-product-lifecycle-for-pr.html