SASE/SSE einführen: Der Leitfaden in fünf Phasen

Die Entscheidung für Secure Access Service Edge fällt in vielen Unternehmen inzwischen schnell: Mitarbeitende arbeiten verteilt, Anwendungen liegen in der Cloud, und die zentrale Firewall am Hauptstandort passt nicht mehr zu diesem Alltag. Die eigentliche Arbeit beginnt danach. Ein Umstieg auf SASE/SSE verändert Netzwerk und Sicherheit gleichzeitig und zieht sich über Monate, weil jeder Standort und jede Nutzergruppe einmal angefasst werden muss. Ob das Projekt Frust erzeugt oder den Betrieb am Ende vereinfacht, entscheidet sich dabei weniger am Produkt als an der Reihenfolge der Schritte.

Dieser Leitfaden geht die fünf Phasen der Einführung durch, dazu die Stolpersteine, die uns in Projekten am häufigsten begegnen. Was SASE/SSE technisch ausmacht, erklärt unser Grundlagenbeitrag Was ist SASE/SSE? .

Netzwerk und Sicherheit aus einer Hand

SASE/SSE führt Funktionen zusammen, die bisher auf einzelne Geräte und Dienste verteilt waren: SD-WAN für die Standortvernetzung, dazu Sicherheitsdienste wie Zero Trust Network Access, Secure Web Gateway, Cloud Access Security Broker und Firewall-as-a-Service. Bereitgestellt wird das Ganze über ein globales Cloud-Netz statt über Hardware im eigenen Rechenzentrum. Geprägt hat den Begriff das Analystenhaus Gartner , das darunter die Verschmelzung von Netzwerk- und Sicherheitsdiensten zu einem einheitlichen Cloud-Service versteht.

Nutzer greifen damit von jedem Ort sicher auf Anwendungen zu, ohne Umweg über die Zentrale und ohne dass die Verbindung spürbar langsamer wird. Die IT verwaltet Richtlinien an einer Stelle und baut Geräte an den Standorten ab. Damit dieser Umbau geordnet abläuft, hat sich eine Abfolge von fünf Phasen bewährt.

Phase 1: Bestandsaufnahme und Sicherheitsstrategie

Der erste Schritt hat mit Produkten noch nichts zu tun. Ältere Sicherheitsarchitekturen stoßen an Grenzen, sobald Mitarbeitende von überall arbeiten: Eine zentrale Firewall am Hauptstandort sieht den Datenverkehr einer Kollegin im Homeoffice schlicht nicht, und wer den gesamten Verkehr erst durch die Zentrale schleift, bezahlt mit Leistung. Bevor Sie solche Lücken schließen können, müssen Sie wissen, wo sie überall liegen.

Erfassen Sie deshalb systematisch, was heute im Einsatz ist:

• Anwendungen: Welche Anwendungen nutzt das Unternehmen, welche davon liegen in der Cloud, welche im eigenen Rechenzentrum? Und wer greift von wo darauf zu?
• Sicherheits- und Netzwerkdienste: Welche Anbieter und Produkte sind im Einsatz, was leisten sie, wann laufen die Verträge aus?
• Hardware: Welche Firewalls, VPN-Gateways, Proxies und Router stehen an welchen Standorten? Gerade bei mehreren Standorten summiert sich hier Technik, die ein Cloud-Dienst später ersetzen kann.
• Anforderungen: Welche Datenschutz- und Compliance-Vorgaben gelten, und wo liegen besonders sensible Daten und Prozesse?

Auf dieser Grundlage folgt eine Risikobewertung: Welche Lücken sind am gefährlichsten, welche Bereiche brauchen zuerst Schutz? Das Ergebnis ist eine Prioritätenliste, die später die Reihenfolge der Migration bestimmt. Auch die Kostenseite gehört schon hierher, denn wo heute an jedem Standort eigene Sicherheits-Hardware steht, spart eine Cloud-Architektur später Kauf und Wartung.

Phase 2: Anforderungen definieren und Lösungen bewerten

Erst mit dieser Vorarbeit beginnt die Marktsichtung. Vergleichen Sie Lösungen entlang Ihrer dokumentierten Anforderungen statt entlang von Datenblättern. Wichtig sind vor allem:

• Funktionsabdeckung: Deckt die Plattform alle benötigten Bausteine ab (ZTNA, SWG, CASB, FWaaS, SD-WAN), oder müssen einzelne Funktionen aus anderen Produkten ergänzt werden? Eine durchgängige Plattform spart Schnittstellen und doppelte Richtlinienpflege.
• Sicherheitsstandards und Compliance: Erfüllt der Anbieter die Zertifizierungen und Datenschutzanforderungen, die für Ihr Unternehmen gelten? Wo werden Daten verarbeitet?
• Skalierbarkeit und Netzabdeckung: Wie nah sind die Zugangspunkte des Anbieters an Ihren Standorten und Mitarbeitenden? Die beste Sicherheitsfunktion nützt wenig, wenn jeder Zugriff über einen weit entfernten Knoten läuft und Wartezeiten erzeugt.
• Integration: Wie gut fügt sich die Lösung in die bestehende Umgebung ein, etwa in den Identitätsanbieter und das SIEM? Was sich nicht anbinden lässt, taucht später in keiner Auswertung auf.

Verlassen Sie sich dabei nicht auf Präsentationen. In Demo-Sessions und einem technischen Proof of Concept mit den eigenen Anwendungen zeigt sich schnell, ob eine Lösung im Alltag trägt. Zwei oder drei Kandidaten in der engeren Auswahl reichen für eine belastbare Entscheidung.

Phase 3: Migration planen und budgetieren

Mit der Entscheidung für eine Lösung beginnt die eigentliche Planungsarbeit. In diese Phase gehören:

• Migrationspfade: Legen Sie fest, in welcher Reihenfolge Standorte, Nutzergruppen und Anwendungen umziehen. 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-Umstieg über Nacht ist bei einer Architektur, die jeden Zugriff betrifft, selten eine gute Idee.
• Stakeholder: SASE/SSE verbindet zwei Bereiche, die in vielen Organisationen getrennt arbeiten: das Netzwerk-Team und das Security-Team. Beide müssen von Anfang an am Tisch sitzen, dazu je nach Unternehmen Datenschutz, Betriebsrat und die Fachbereiche, deren Anwendungen zuerst migrieren.
• Zeitrahmen, Budget, Ressourcen: Definieren Sie Meilensteine mit realistischen Puffern und klären Sie, wer die Migration neben dem Tagesgeschäft stemmt. An dieser Stelle zeigt sich oft, dass externe Unterstützung günstiger kommt als ein Projekt, das sich über Jahre zieht.

Ein oft übersehener Punkt ist das Vertragsmanagement. Wer auf eine SASE/SSE-Plattform wechselt, macht bestehende Verträge etwa für VPN-Lösungen oder Standort-Firewalls nach und nach überflüssig. Kündigungsfristen und Laufzeiten gehören deshalb in den Migrationsplan, sonst zahlen Sie in der Übergangszeit doppelt und länger als nötig.

Phase 4: Pilotierung

Vor dem unternehmensweiten Rollout kommt der Test unter realen Bedingungen. Wählen Sie eine begrenzte, aber aussagekräftige Umgebung, etwa einen Standort oder eine Abteilung, deren Arbeitsalltag den Rest des Unternehmens gut abbildet. Der Pilot prüft zweierlei: Greifen die Zugriffsrichtlinien wie geplant, und bleibt der Zugriff für die Nutzer schnell? Besondere Aufmerksamkeit verdienen die unbequemen Fälle, etwa Altanwendungen oder Standorte mit schwacher Anbindung.

Damit der Pilot mehr ist als ein Gefühl, legen Sie 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 strenge Zugriffsregel bei fünfzig Pilotnutzern zu korrigieren ist deutlich billiger, als sie bei fünftausend Mitarbeitenden im Wirkbetrieb einzufangen.

Phase 5: Rollout und laufende Optimierung

Nach erfolgreicher Pilotphase folgt die Skalierung auf das gesamte Unternehmen, weiterhin schrittweise entlang der geplanten Migrationspfade. Mit jedem Standort und jeder Nutzergruppe wächst die Plattform. Alte Systeme werden abgeschaltet, sobald ihre Aufgaben vollständig übernommen sind.

Fertig ist die Architektur damit nicht. Im laufenden Betrieb braucht sie Monitoring für Leistung und Sicherheitsereignisse, und die Richtlinien müssen mit neuen Anwendungen und Arbeitsweisen Schritt halten. Auch die Zufriedenheit der Nutzer gehört auf den Zettel: Wenn der Zugriff hakt, entstehen schnell inoffizielle Wege an der Plattform vorbei. Angreifer ändern ihre Methoden laufend, und der Vorteil einer Cloud-Architektur liegt gerade darin, dass neue Schutzfunktionen ohne Hardware-Tausch verfügbar werden. Genutzt werden müssen sie trotzdem.

Die häufigsten Stolpersteine

Aus Projekten, die wir begleitet oder übernommen haben, kennen wir wiederkehrende Muster:

• Unvollständige Bestandsaufnahme: Anwendungen und Datenflüsse, die niemand dokumentiert hat, tauchen mitten in der Migration auf und werfen den Plan um.
• Produkt vor Strategie: Die Lösung wird gekauft, bevor Anforderungen und Prioritäten klar sind. Danach richtet sich das Projekt nach dem Produkt statt umgekehrt.
• Getrennte Teams: Netzwerk und Security planen aneinander vorbei, Zuständigkeiten für die neue Plattform bleiben ungeklärt.
• Vergessene Verträge: Altsysteme laufen aus Vertragsgründen weiter, die erhoffte Kostenentlastung verschiebt sich um Jahre.
• Pilot ohne Messlatte: Ohne vorab definierte Kriterien wird 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.

Mit KAEMI von der Bestandsaufnahme bis zum Betrieb

Als Managed Service Provider begleiten wir bei KAEMI genau diesen Weg. Wir übernehmen Bestandsaufnahme und Risikobewertung, planen die Migration und betreiben die SASE/SSE-Plattform anschließend im Managed-Modell weiter, mit Monitoring und festen Ansprechpartnern. Für einzelne Phasen, etwa die Bestandsaufnahme oder die Pilotierung, unterstützen unsere Professional Services auch punktuell.

Wenn Sie am Anfang dieses Wegs stehen oder ein laufendes Projekt wieder in die Spur bringen wollen, sprechen Sie mit uns . Der erste Schritt ist ohnehin immer derselbe: ein ehrlicher Blick auf den Ist-Zustand.