Secure Web Gateway Migration: Checkliste für die Umstellung und den Rollback

Bei einer Migration von „ secure web gateway “ werden die Überprüfung des Webdatenverkehrs und die Richtlinien von einer Proxy-Plattform auf eine andere übertragen – sei es von einer lokalen Appliance auf eine neue Appliance, auf einen Cloud-Dienst oder auf ein Hybridmodell. Diese Checkliste deckt den gesamten Ablauf ab: Bestandsaufnahme, Zielkonzeption, Richtlinienumsetzung, Vorbereitung des Rollbacks, Pilotprojekt, Tests, schrittweise Umstellung und Abnahme.

Dieser Artikel ist Teil des Leitfadens zur Hybrid-Cloud-Sicherheit. Spezifische Informationen zu „ Blue Coat “, „ProxySG“ und „Symantec Edge SWG“ finden Sie unter „Blue Coat “ und „ProxySG End of Life: Migration Planning“.

Phase 1: Bestandsaufnahme

In Phase 1 werden vor Beginn der Entwurfsarbeiten der aktuelle Gateway-Bestand, die Verkehrssteuerung, die Identitätsprüfung, die TLS-Prüfung, die Richtlinien sowie die Integrationen dokumentiert.

Infrastruktur

• Jedes Gateway: Modell, Softwareversion, Standort, Funktion und Termine für das Ende des Lebenszyklus (für ProxySG und Edge SWG beachten Sie bitte den Artikel von Broadcom zum Lebenszyklus)
• Datenverkehrsvolumen und Spitzen-Durchsatz pro Standort, mit Anteil der TLS-Entschlüsselung
• Benutzerzahlen pro Standort und für den Fernzugriff
• Proxy-Verkettung vor und nach dem Server, Lastverteiler und Failover-Konzeption

Verkehrslenkung

• Explizite Proxy-Einstellungen, PAC-Dateien und WPAD
• Transparente Abfangpunkte (WCCP, richtlinienbasiertes Routing)
• Tunnel von Zweigstellen (IPsec, GRE)
• Agenten auf Endgeräten
• Ausnahmen bei der direkten Veröffentlichung im Internet

Identität

• Authentifizierungsbereiche (SAML, Kerberos/IWA, LDAP, Client-Zertifikate)
• In der Richtlinie verwendete Gruppenzuordnungen
• Nicht authentifizierter Datenverkehr (Server, IoT, OT) und dessen Handhabung

TLS-Prüfung

• Prüfung des Zertifikats, des Schlüsselstandorts, des Ablaufdatums und der Verteilungsmethode
• Liste der Ausnahmen bei der Entschlüsselung mit Begründungen und Verantwortlichen

Richtlinie

• Vollständiger Export der Richtlinie, einschließlich der Reihenfolge der Regeln, der Kategorien, der benutzerdefinierten Listen und der Ausnahmen
• Regeln, die in den letzten 90 Tagen keine Treffer verzeichnet haben (Kandidaten für die Stilllegung)

Integrationen

• ICAP-Verbindungen zu DLP, Antiviren-Software und Sandboxing
• Weiterleitung von Protokollen an SIEM- und Berichtstools
• Überwachung und Alarmierung

Phase 2: Zielentwurf

In Phase 2 wird festgelegt, an welchen Standorten und für welche Benutzergruppen Überprüfungen durchgeführt werden und wie der Datenverkehr, die Zertifikate und die Protokolle behandelt werden.

• Legen Sie fest, wo die einzelnen Standorte und Benutzergruppen überprüft werden sollen: vor Ort, in der Cloud oder in einer Hybridumgebung
• Legen Sie für jeden Fall die Methode zur Datenverkehrssteuerung fest: expliziter Proxy oder PAC für verwaltete Netzwerke, Agenten oder Browsersteuerungen für Roaming-Benutzer, Tunnel für Zweigstellen
• Stellen Sie sicher, dass die TLS-Prüfung so platziert ist, dass jeder Datenfluss nur einmal entschlüsselt wird. Die NSA empfiehlt, die Prüfung einmalig innerhalb des Unternehmensnetzwerks durchzuführen und redundante Prüfungen durch hintereinander geschaltete Proxys zu vermeiden (NSA)
• Kapazität für den entschlüsselten Spitzen-Durchsatz sowie für künftiges Wachstum
• Hochverfügbarkeit und Ausfallverhalten konzipieren
• Legen Sie fest, wo Protokolle und DLP-Beweismittel gespeichert werden sollen
• Planen Sie die neue CA-Prüfung oder die Übertragung der bestehenden CA und vergewissern Sie sich, dass die Schlüsselverwaltung unterstützt wird und eine erforderliche HSM-Integration vorhanden ist

Phase 3: Umsetzung der Richtlinien

In Phase 3 werden bestehende Richtlinien nicht durch eine direkte Dateikonvertierung, sondern mittels einer strukturierten, validierten Zuordnung in die neue Plattform übertragen.

• Ordnen Sie jede Quellregel ihrem entsprechenden Zieläquivalent zu oder kennzeichnen Sie sie als zu entnehmen
• Ordnen Sie die URL-Kategorien den Anbietern zu und prüfen Sie die Unterschiede bei den besonders wichtigen Kategorien
• Benutzerdefinierte Listen, Zulassungslisten und Sperrlisten neu erstellen
• Übersetzen Sie authentifizierungsabhängige Regeln und bestätigen Sie die Gruppenzuordnungen
• Erstellen Sie die Umgehungsmöglichkeiten für die Entschlüsselung neu und prüfen Sie jede einzelne daraufhin, ob sie weiterhin erforderlich ist
• Ersetzen Sie ICAP-basierte DLP-Übergaben nach Möglichkeit durch den plattformeigenen Datenschutzdienst, wobei Sie bestätigen müssen, wo die Überprüfung stattfindet, oder stellen Sie die Integrationen wieder her
• Erfassen Sie jede Änderung und jede außer Kraft gesetzte Regel unter Angabe eines Grundes gemäß Ihrem Prozess zur Kontrolle von Konfigurationsänderungen (NIST SP 800-128 beschreibt sicherheitsorientierte Verfahren zum Konfigurationsmanagement).

Einige Plattformen bieten einen assistierten Import bestehender Richtlinien an. Betrachten Sie jeden Import als Ausgangspunkt, der noch einer Überprüfung und eines Tests bedarf.

Phase 4: Vorbereitung des Rollbacks

In Phase 4 werden vor Beginn der Pilotphase die Auslöser und Abläufe für Rollbacks festgelegt. Testen Sie die Rollback-Funktionen während der Pilotphase und überprüfen Sie die Betriebsbereitschaft vor jeder Produktionswelle.

Rollback-Trigger (Beispiele)

• Authentifizierungsfehler, die einen vereinbarten Schwellenwert überschreiten
• Eine geschäftskritische Anwendung, die länger als eine vereinbarte Zeitspanne nicht verfügbar ist
• Helpdesk-Tickets, die ein festgelegtes Vielfaches des Basiswerts überschreiten
• Es wurde bestätigt, dass die Sicherheitsmaßnahmen nicht durchgesetzt werden

Mechanismen zur Rücknahme

• Halten Sie die alten Gateways bis zur endgültigen Abnahme in Betrieb und sorgen Sie dafür, dass sie stets auf dem neuesten Stand sind.
• Verwalten Sie Änderungen an PAC-Dateien, DNS und Routing in Versionen, damit diese rückgängig gemacht werden können
• Berücksichtigen Sie die DNS- und PAC-Caching-Zeiten bei der Schätzung der Rollback-Dauer
• Stellen Sie sicher, dass die alte Prüf-Zertifizierungsstelle während der Umstellung auf den Geräten weiterhin als vertrauenswürdig eingestuft wird.
• Legen Sie fest, wer ein Rollback genehmigen darf, und dokumentieren Sie die einzelnen Schritte
• Führen Sie während der Pilotphase einen Test-Rollback durch und überprüfen Sie vor jeder Umstellungswelle die Betriebsbereitschaft.

Phase 5: Pilotprojekt

In Phase 5 wird eine repräsentative Pilotgruppe auf dem neuen Portal betrieben, und zwar parallel zum alten Portal über einen Zeitraum von mindestens einem Geschäftszyklus.

• Wählen Sie Pilotnutzer aus, die wichtige Abteilungen, Gerätetypen und Standorte repräsentieren, darunter IT-Mitarbeiter und einige erfahrene Nutzer aus den Fachabteilungen
• Betreiben Sie das neue Gateway parallel zum alten.
• Leiten Sie den Pilotverkehr über Änderungen an PAC, Agenten oder Routen, die sich schnell rückgängig machen lassen, zum neuen Gateway um
• Bieten Sie den Pilotnutzern eine klare Möglichkeit, Probleme zu melden
• Führen Sie das Pilotprojekt über mindestens einen vollständigen Geschäftszyklus durch, gegebenenfalls einschließlich des Monatsendes.

Phase 6: Testphase

In Phase 6 werden alle Bereiche getestet, in denen die Benutzer einen Unterschied bemerken werden – von der Authentifizierung über die Leistung bis hin zum Failover.

Phase 7: Schrittweise Umstellung

In Phase 7 werden Benutzer und Standorte schrittweise auf das neue Gateway umgestellt, wobei mit den Standorten mit dem geringsten Risiko begonnen wird.

• Gruppieren Sie Benutzer und Standorte nach Risiko und Komplexität in Phasen, beginnend mit Standorten mit geringem Risiko
• Teilen Sie jede Welle im Voraus mit und geben Sie einen Ansprechpartner für Unterstützung an
• Planen Sie Wellen außerhalb kritischer Geschäftszeiten ein
• Besetzen Sie für die ersten Stunden jeder Welle eine Einsatzzentrale mit Personal
• Überwachen Sie Helpdesk-Tickets, Sperrquoten und Fehlerquoten im Vergleich zum Referenzwert
• Machen Sie zwischen den Phasen eine Pause, um Probleme zu lösen, bevor Sie fortfahren

Phase 8: Abnahme und Außerbetriebnahme

In Phase 8 wird überprüft, ob die Abnahmekriterien erfüllt sind; anschließend werden die alten Gateways, Zertifikate und Verträge außer Betrieb genommen.

Abnahmekriterien (Beispiele)

• Alle Benutzer und Websites wurden migriert
• Das Helpdesk-Aufkommen hat sich seit zwei Wochen wieder auf das Ausgangsniveau eingependelt
• Alle Testfälle werden in der Produktionsumgebung erfolgreich bestanden
• Von der Sicherheitsabteilung und der Compliance-Abteilung überprüfte Protokolle und Berichte
• Die Ausnahmeliste wurde geprüft und genehmigt

Stilllegen

• Entfernen Sie alte Gateways aus PAC-Dateien, dem Routing und dem DNS
• Widerrufen und entfernen Sie die alte Inspektions-Zertifizierungsstelle von den Geräten, falls diese ersetzt wurde
• Archivieren Sie alte Protokolle gemäß den Aufbewahrungsrichtlinien
• Hardware sicher löschen und entsorgen
• Lizenzen und Supportverträge abwickeln

Typischer Zeitplan

Die Bearbeitungsdauer hängt von der Größe des Nachlasses und der Komplexität der Police ab.

Ein Unternehmen mit nur einem Standort kann eine Migration innerhalb weniger Wochen abschließen. Große Unternehmen mit mehreren Standorten führen laut Skyhigh Security.

Wie Skyhigh die SWG-Migration unterstützt

Skyhigh unterstützt die SWG-Migration durch parallele Bereitstellung, den validierten Import von CPL-Richtlinien und flexible Bereitstellungsmodelle.

Skyhigh Hybrid SSE Mesh wird parallel zu bestehenden Gateways bereitgestellt, sodass Richtlinien bereits vor einer Umstellung anhand des parallelen Datenverkehrs validiert werden können. Skyhigh wandelt bestehende CPL-Richtlinien von „ Blue Coat “ im Rahmen eines validierten Importprozesses in seiner einheitlichen Richtlinienkonsole um, und die Richtlinien werden in der Skyhigh-Cloud-Konsole erstellt. Richtlinien für Web- und private Anwendungen können auf dem lokalen Gateway durchgesetzt werden, während Datenverkehr, der einen in der Cloud angewandten Datenschutz erfordert, an die Skyhigh-Cloud weitergeleitet wird. Remote-Benutzer werden über Cloud-Präsenzpunkte bedient. Skyhigh SWG läuft vor Ort, in einer Hybridumgebung oder in der Cloud, sodass die Migration keine Änderung des Bereitstellungsmodells erfordert. Das „Blue Coat -Modernisierungsprogramm“ bietet berechtigten Kunden zusätzliche Serviceunterstützung und eine kommerzielle Vergütung.

Quellen

1. 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
2. NIST. SP 800-128: Leitfaden für ein sicherheitsorientiertes Konfigurationsmanagement von Informationssystemen. https://csrc.nist.gov/pubs/sp/800/128/upd1/final
3. 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
4. Skyhigh Security. „Modernisierung Ihrer Symantec Edge- Secure Web Gateway s mit Skyhigh Hybrid SSE Mesh“ (15. Juli 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
5. Skyhigh Security. „Die Einführung von Hybrid-Lösungen ist mit der Skyhigh SSE-Plattform jetzt noch einfacher“ (3. Oktober 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html