Für Secure Access Service Edge entscheiden sich viele Unternehmen inzwischen zügig: Die Belegschaft arbeitet verteilt, die Anwendungen liegen in der Cloud, und die zentrale Firewall am Hauptsitz passt zu diesem Alltag nicht mehr. Die eigentliche Arbeit folgt nach der Entscheidung. Ein Umstieg auf SASE/SSE verändert Netzwerk und Sicherheit zur gleichen Zeit und erstreckt sich über Monate, weil jeder Standort und jede Nutzergruppe einmal angefasst wird. Ob am Ende Frust steht oder ein einfacherer Betrieb, hängt weniger vom Produkt ab als von der Reihenfolge der Schritte. Dieser Leitfaden beschreibt die fünf Phasen der Einführung und die Stolpersteine, die in Projekten immer wieder auftreten.
Netzwerk und Sicherheit aus einer Plattform
SASE/SSE vereint Funktionen, die bislang über einzelne Geräte und Dienste verstreut waren: SD-WAN für die Standortvernetzung sowie Sicherheitsdienste wie Zero Trust Network Access (ZTNA), Secure Web Gateway (SWG), Cloud Access Security Broker (CASB) und Firewall-as-a-Service (FWaaS). Ausgeliefert wird das über ein globales Cloud-Netz statt über Hardware im eigenen Rechenzentrum. Eingeführt hat den Begriff das Analystenhaus Gartner; gemeint ist die Zusammenführung von Netzwerk- und Sicherheitsdiensten in einem einheitlichen Cloud-Service.
Für die Nutzer bedeutet das: sicherer Zugriff auf Anwendungen von jedem Ort, ohne Umweg über die Zentrale und ohne spürbare Verzögerung. Die IT pflegt Richtlinien an einer Stelle und baut Geräte an den Standorten ab. Damit dieser Umbau geordnet gelingt, hat sich eine Abfolge von fünf Phasen bewährt.
Phase 1: Bestandsaufnahme und Sicherheitsstrategie
Der erste Schritt kommt ganz ohne Produkte aus. Ältere Sicherheitsarchitekturen geraten an ihre Grenzen, sobald von überall gearbeitet wird: Eine zentrale Firewall am Hauptstandort sieht den Datenverkehr aus dem Homeoffice schlicht nicht, und wer sämtlichen Verkehr erst durch die Zentrale leitet, bezahlt das mit Leistung. Bevor sich solche Lücken schließen lassen, muss klar sein, wo sie überall liegen.
Systematisch zu erfassen ist deshalb der Ist-Zustand:
- Anwendungen: Welche Anwendungen sind im Einsatz, welche laufen in der Cloud, welche im eigenen Rechenzentrum? Und wer greift von wo darauf zu?
- Sicherheits- und Netzwerkdienste: Welche Produkte und Anbieter sind vorhanden, was leisten sie, wann enden die Verträge?
- Hardware: Welche Firewalls, VPN-Gateways, Proxies und Router stehen an welchen Standorten? Gerade bei vielen Standorten sammelt sich Technik an, die ein Cloud-Dienst später ablösen kann.
- Anforderungen: Welche Datenschutz- und Compliance-Vorgaben gelten, und wo liegen besonders sensible Daten und Prozesse?
Darauf setzt die Risikobewertung auf: Welche Lücken wiegen am schwersten, welche Bereiche brauchen zuerst Schutz? Das Ergebnis ist eine Prioritätenliste, die später die Reihenfolge der Migration vorgibt. Auch die Kostenseite gehört bereits in diese Phase, denn wo heute jeder Standort eigene Sicherheits-Hardware trägt, entfallen mit einer Cloud-Architektur später Anschaffung und Wartung.
Phase 2: Anforderungen definieren und Lösungen bewerten
Erst nach dieser Vorarbeit beginnt der Blick auf den Markt. Bewertet wird entlang der dokumentierten Anforderungen, nicht entlang von Datenblättern. Vier Punkte stehen im Vordergrund:
- Funktionsabdeckung: Bringt die Plattform alle benötigten Bausteine mit (ZTNA, SWG, CASB, FWaaS, SD-WAN), oder müssen einzelne Funktionen aus anderen Produkten ergänzt werden? Eine durchgängige Plattform erspart Schnittstellen und doppelte Richtlinienpflege.
- Sicherheitsstandards und Compliance: Erfüllt der Anbieter die Zertifizierungen und Datenschutzanforderungen, die für das Unternehmen gelten? Wo verarbeitet er die Daten?
- Skalierbarkeit und Netzabdeckung: Wie nah liegen die Zugangspunkte des Anbieters an Standorten und Mitarbeitenden? Die beste Sicherheitsfunktion hilft wenig, wenn jeder Zugriff über einen weit entfernten Knoten läuft und Wartezeiten entstehen.
- Integration: Wie gut dockt die Lösung an die bestehende Umgebung an, etwa an den Identitätsanbieter und das SIEM? Was sich nicht anbinden lässt, fehlt später in jeder Auswertung.
Präsentationen ersetzen dabei keinen Nachweis. Ob eine Lösung im Alltag trägt, zeigt sich in Demo-Sessions und in einem technischen Proof of Concept mit den eigenen Anwendungen. Für eine belastbare Entscheidung genügen zwei bis drei Kandidaten in der engeren Wahl.
Phase 3: Migration planen und budgetieren
Mit der Produktentscheidung startet die eigentliche Planungsarbeit. Dazu gehören:
- Migrationspfade: In welcher Reihenfolge ziehen Standorte, Nutzergruppen und Anwendungen um? Die Prioritäten aus Phase 1 geben die Richtung vor: zuerst die Bereiche mit dem größten Risiko oder dem größten Nutzen. Ein Big Bang über Nacht ist bei einer Architektur, die jeden Zugriff berührt, selten ratsam.
- Stakeholder: SASE/SSE verbindet zwei Bereiche, die vielerorts getrennt arbeiten: das Netzwerk-Team und das Security-Team. Beide gehören von Beginn an an den Tisch, je nach Organisation außerdem Datenschutz, Betriebsrat und die Fachbereiche, deren Anwendungen zuerst migrieren.
- Zeitrahmen, Budget, Ressourcen: Meilensteine brauchen realistische Puffer, und es muss geklärt sein, wer die Migration neben dem Tagesgeschäft trägt. Häufig ist externe Unterstützung, etwa durch Anbieter von Managed-SASE/SSE-Services, wirtschaftlicher als ein Projekt, das sich über Jahre hinzieht.
Oft übersehen wird das Vertragsmanagement. Der Wechsel auf eine SASE/SSE-Plattform macht bestehende Verträge, etwa für VPN-Lösungen oder Standort-Firewalls, Schritt für Schritt überflüssig. Kündigungsfristen und Laufzeiten gehören deshalb in den Migrationsplan, sonst zahlt das Unternehmen in der Übergangszeit doppelt und länger als nötig.
Phase 4: Pilotierung
Vor dem unternehmensweiten Rollout steht der Test unter realen Bedingungen. Geeignet ist eine begrenzte, aber aussagekräftige Umgebung: ein Standort oder eine Abteilung, deren Arbeitsalltag den Rest der Organisation gut widerspiegelt. Der Pilot beantwortet zwei Fragen: Greifen die Zugriffsrichtlinien wie vorgesehen, und bleibt der Zugriff für die Nutzer schnell? Besondere Aufmerksamkeit verdienen die unbequemen Fälle: Altanwendungen etwa oder Standorte mit schwacher Anbindung.
Damit der Pilot mehr liefert als ein Bauchgefühl, stehen die Erfolgskriterien vorher fest: messbare Werte für Verfügbarkeit und Antwortzeiten, dazu strukturiertes Feedback der Pilotnutzer. Die Erkenntnisse fließen zurück in Richtlinien und Konfiguration. Eine zu strikte Zugriffsregel bei fünfzig Pilotnutzern zu korrigieren kostet deutlich weniger, als sie bei fünftausend Beschäftigten im Wirkbetrieb einzufangen.
Phase 5: Rollout und laufende Optimierung
Nach erfolgreichem Pilot folgt die Ausweitung auf das gesamte Unternehmen, weiterhin schrittweise entlang der geplanten Migrationspfade. Mit jedem Standort und jeder Nutzergruppe wächst die Plattform, und Altsysteme werden abgeschaltet, sobald ihre Aufgaben vollständig übernommen sind.
Abgeschlossen ist die Architektur damit nicht. Der laufende Betrieb verlangt Monitoring für Leistung und Sicherheitsereignisse, und die Richtlinien müssen mit neuen Anwendungen und Arbeitsweisen Schritt halten. Auch die Zufriedenheit der Nutzer bleibt ein Thema: Hakt der Zugriff, entstehen rasch inoffizielle Wege an der Plattform vorbei. Angreifer wiederum passen ihre Methoden fortlaufend an. Der Vorteil einer Cloud-Architektur ist gerade, dass neue Schutzfunktionen ohne Hardware-Tausch bereitstehen. Aktiviert und gepflegt werden müssen sie trotzdem.
Die häufigsten Stolpersteine
Erfahrungen aus Einführungsprojekten zeigen wiederkehrende Muster:
- Unvollständige Bestandsaufnahme: Nirgends dokumentierte Anwendungen und Datenflüsse tauchen mitten in der Migration auf und werfen den Plan um.
- Produkt vor Strategie: Die Lösung wird beschafft, bevor Anforderungen und Prioritäten feststehen. Danach richtet sich das Projekt nach dem Produkt statt umgekehrt.
- Getrennte Teams: Netzwerk und Security planen aneinander vorbei, die Zuständigkeit für die neue Plattform bleibt offen.
- Vergessene Verträge: Altsysteme laufen aus Vertragsgründen weiter, die erwartete Kostenentlastung verschiebt sich um Jahre.
- Pilot ohne Messlatte: Ohne vorab definierte Kriterien gerät der Testlauf zur Geschmacksfrage, und Probleme zeigen sich erst im Rollout.
- Unterschätzter Betrieb: Nach dem Projekt fehlt das Team, das Richtlinien pflegt und Sicherheitsereignisse auswertet. Diese Daueraufgabe lässt sich auch an einen Managed-Service-Anbieter vergeben.
Passende Managed Services
- Managed SASE/SSE – Zero-Trust-Zugriff (ZTNA), Secure Web Gateway, CASB und DLP als betriebene Plattform, von der Einführung bis zum Dauerbetrieb.
- Managed SD-WAN – software-gesteuerte, sichere Standortvernetzung, die WAN-Seite einer SASE/SSE-Architektur.