SASE verbindet die Standort- und Benutzeranbindung eines Unternehmens mit zentral bereitgestellten Sicherheitsdiensten. Statt den Datenverkehr mobiler Windows-PCs, Niederlassungen und Cloud-Anwendungen grundsätzlich durch das Rechenzentrum zu leiten, wird der Zugriff über nahegelegene Zugangspunkte eines SASE-Dienstes geprüft und zum erlaubten Ziel geführt. Ob dieses Modell passt, hängt vor allem von verteilten Arbeitsplätzen, der Anwendungslandschaft, der vorhandenen Identitätsverwaltung und den verfügbaren Zugangspunkten des Anbieters ab.
Für Unternehmen ist SASE keine einzelne Schutzfunktion und auch kein bloßer Ersatz für eine Firewall. Die Architektur kombiniert Netzwerkfunktionen wie SD-WAN mit Sicherheitsbausteinen wie Zero Trust Network Access, Secure Web Gateway, Cloud Access Security Broker und einer cloudbasierten Firewall. Auf Windows-PCs kommen meist ein Geräte-Client, Zertifikate, Identitätsdaten und Richtlinien für den Datenverkehr hinzu. Eine sichere Einführung beginnt deshalb nicht mit der Installation eines Clients, sondern mit der Erfassung von Anwendungen, Benutzergruppen, Geräten und erlaubten Kommunikationswegen.
Was SASE technisch zusammenführt
Secure Access Service Edge, kurz SASE, beschreibt eine Architektur, in der Netzwerkzugriff und Sicherheitsprüfung als gemeinsam gesteuerter Cloud-Dienst bereitgestellt werden. Die einzelnen Funktionen können je nach Plattform unterschiedlich benannt oder auf mehrere Produkte verteilt sein. Für die technische Bewertung sind daher die tatsächlichen Funktionen und ihre gemeinsame Richtliniensteuerung wichtiger als das SASE-Etikett.
- SD-WAN verbindet Standorte über mehrere mögliche Leitungen und kann Datenströme abhängig von Ziel, Anwendung und Leitungsqualität verteilen.
- Zero Trust Network Access (ZTNA) gewährt einem Benutzer oder Gerät Zugriff auf freigegebene Anwendungen, ohne ihm automatisch das gesamte interne Netzwerk zu öffnen.
- Cloud Access Security Broker (CASB) unterstützt die Kontrolle verwendeter Cloud-Dienste und kann Richtlinien für Daten und Benutzeraktionen anwenden.
- Firewall as a Service (FWaaS) verlagert Firewall-Prüfungen in die Infrastruktur des Dienstes, damit Regeln nicht nur am Unternehmensstandort gelten.
Ergänzend können DNS-Schutz, Schutz vor Datenabfluss, Malware-Prüfung, Sandbox-Analyse oder Funktionen zur Erkennung nicht freigegebener Cloud-Dienste enthalten sein. Diese Merkmale sind nicht bei jedem Produkt gleich umgesetzt. Insbesondere SSL/TLS-Entschlüsselung, Protokollunterstützung, Datenstandorte und Protokollaufbewahrung müssen anhand der Produktdokumentation und eines Tests mit den eigenen Anwendungen geprüft werden.
Der Begriff Security Service Edge, kurz SSE, bezeichnet im Wesentlichen den sicherheitsbezogenen Teil dieser Architektur. Eine SSE-Lösung kann ZTNA, SWG und CASB bereitstellen, enthält aber nicht zwingend die umfassende Standortvernetzung durch SD-WAN. Benötigt ein Unternehmen nur sicheren Zugriff für mobile Beschäftigte und Cloud-Anwendungen, kann SSE ausreichen. Sollen zusätzlich Filialen, Werke oder Büros über eine gemeinsame WAN-Architektur angebunden werden, ist der breitere SASE-Ansatz relevant.
Der Unterschied zu VPN, Standort-Firewall und klassischem MPLS
Ein herkömmliches Remote-Access-VPN baut meist einen verschlüsselten Tunnel in das Unternehmensnetz auf. Nach erfolgreicher Anmeldung bestimmt die interne Segmentierung, welche Systeme erreichbar sind. ZTNA verfolgt einen engeren Ansatz: Der Zugriff wird möglichst auf eine bestimmte Anwendung begrenzt und anhand von Identität, Gerätezustand und weiteren Signalen freigegeben. Dadurch kann die Netzwerkreichweite eines angemeldeten Benutzers kleiner ausfallen.
ZTNA ist dennoch nicht automatisch ein vollständiger VPN-Ersatz. Anwendungen mit dynamischen Ports, alten Authentifizierungsverfahren, eingebetteten IP-Adressen oder komplexen Datei- und Druckdiensten können einen netzwerkbasierten Tunnel benötigen. Vor einer Ablösung muss daher für jede Anwendung geklärt werden, welches Protokoll sie verwendet, welche Namensauflösung erforderlich ist und ob der SASE-Dienst diesen Datenverkehr unterstützt.
Eine Standort-Firewall schützt einen klaren Netzwerkrand. Bei direkten Zugriffen aus dem Homeoffice auf Cloud-Dienste liegt dieser Rand jedoch nicht mehr zwingend im Büro. SASE verschiebt die Prüfung näher an Benutzer und Ziele, ersetzt aber nicht jede lokale Sicherheitsfunktion. Produktionsnetze, lokale Server, nicht internetfähige Geräte und ausfallsensible Verbindungen können weiterhin lokale Segmentierung, Firewalls und unabhängige Schutzmaßnahmen verlangen.
Auch ein bestehendes MPLS-Netz muss nicht sofort verschwinden. SD-WAN kann private Leitungen, Breitband und Mobilfunk gemeinsam nutzen. Die geeignete Kombination richtet sich nach Verfügbarkeit, Latenz, vertraglich zugesicherter Leistung und der Kritikalität des Standorts. SASE beschreibt das Sicherheits- und Zugriffsmodell; es garantiert allein weder eine bestimmte Leitungsqualität noch eine störungsfreie Internetanbindung.
Was sich auf Windows-PCs verändert
Auf verwalteten Windows-10- und Windows-11-Geräten wird der SASE-Zugriff häufig durch einen Client oder eine Netzwerkerweiterung umgesetzt. Diese Komponente leitet ausgewählten oder gesamten Datenverkehr zum Zugangspunkt des Dienstes. Sie kann außerdem den angemeldeten Benutzer, ein Gerätezertifikat und Signale zum Gerätezustand an die Richtlinienentscheidung übermitteln.
Vor einer Verteilung sollte die IT die unterstützten Windows-Versionen und Prozessorarchitekturen in der Dokumentation des ausgewählten Produkts prüfen. Ebenso wichtig sind Konflikte mit vorhandenen VPN-Clients, lokalen Webfiltern, Endpoint-Security-Produkten und Software, die eigene Netzwerkfiltertreiber installiert. Zwei gleichzeitig aktive Filter- oder Tunnelkomponenten können DNS-Anfragen, lokale Ressourcen oder einzelne Anwendungen beeinträchtigen, ohne dass Windows selbst einen eindeutigen Fehler meldet.
Für die Identität kann eine Anbindung an einen zentralen Identitätsanbieter verwendet werden, beispielsweise Microsoft Entra ID. Die Anmeldung allein beweist jedoch nicht, dass der PC vertrauenswürdig ist. Eine Richtlinie kann zusätzlich verlangen, dass das Gerät verwaltet, verschlüsselt oder mit aktivem Endpunktschutz registriert ist. Welche Gerätesignale verfügbar und manipulationssicher auswertbar sind, hängt von der Verbindung zwischen SASE-Plattform, Geräteverwaltung und Identitätsdienst ab.
Die Windows-Diagnose sollte mindestens vier Zustände unterscheiden:
- Der Client läuft und hat einen Zugangspunkt erreicht.
- Die Benutzer- und Geräteidentität wurde erfolgreich zugeordnet.
- Die richtige Richtlinie wurde angewendet.
- Die Zielanwendung ist über den vorgesehenen Pfad erreichbar.
Ein verbundenes Client-Symbol bestätigt nur den ersten Teil und ist daher keine ausreichende Erfolgskontrolle. Für einen Pilotbetrieb braucht die IT Testfälle für Webzugriffe, interne Anwendungen, DNS-Auflösung, Microsoft-365-Dienste, lokale Netzwerkgeräte und den Wechsel zwischen Büro, Heimnetz und Mobilfunk.
Welche Datenwege vor der Einführung dokumentiert werden müssen
Die spätere Richtlinienqualität hängt von einer sauberen Bestandsaufnahme ab. Wer lediglich vorhandene Firewall-Regeln in die Cloud kopiert, übernimmt meist historisch gewachsene Freigaben und erhält keine belastbare Zero-Trust-Struktur.
- Anwendungen erfassen: Für jede Anwendung werden Standort, Besitzer, Benutzergruppen, Protokolle, Ports, DNS-Namen und Abhängigkeiten dokumentiert. Dazu gehören auch Authentifizierungsserver, Datenbanken und Update-Dienste.
- Benutzer und Geräte trennen: Beschäftigte, Administratoren, externe Dienstleister und nicht verwaltete Geräte benötigen unterschiedliche Zugriffsmodelle. Ein privater PC sollte nicht allein wegen gültiger Anmeldedaten dieselben Rechte wie ein verwalteter Firmen-PC erhalten.
- Datenverkehr klassifizieren: Cloud-Zugriffe, Internetverkehr, interne Anwendungen und lokale Standortkommunikation werden getrennt betrachtet. Daraus ergibt sich, welcher Verkehr über den SASE-Dienst, direkt zum Ziel oder weiterhin über eine lokale Verbindung laufen soll.
- Ausnahmen belegen: Jede Umgehung von Sicherheitsprüfungen benötigt einen technischen Grund, einen Verantwortlichen und eine erneute Prüfung. Dauerhafte Ausnahmen ohne Besitzer entwickeln sich sonst zu verdeckten Sicherheitslücken.
Besondere Aufmerksamkeit verdienen Dienste, die den Standort anhand der öffentlichen IP-Adresse bestimmen, sowie Anwendungen mit Zertifikatsbindung. Eine SSL/TLS-Entschlüsselung kann außerdem bei bestimmten Programmen, Datenschutzanforderungen oder sensiblen Kategorien unzulässig beziehungsweise technisch unverträglich sein. Solche Ziele benötigen gezielte Regeln statt einer pauschalen Abschaltung der Prüfung.
Eine SASE-Plattform mit einem einheitlichen Raster bewerten
Ein belastbarer Vergleich betrachtet nicht nur die Zahl der Sicherheitsmodule. Die folgenden sechs Kriterien sollten für jeden Kandidaten mit denselben Tests bewertet werden.
1. Zugangspunkte und Verkehrsführung
Entscheidend ist, ob Zugangspunkte in sinnvoller Nähe zu Beschäftigten und Standorten vorhanden sind und wie der Anbieter bei einem Ausfall umleitet. Gemessen werden sollten Latenz und Stabilität mit den tatsächlich genutzten Anwendungen, nicht nur mit einem allgemeinen Geschwindigkeitstest. Für internationale Standorte sind außerdem Datenpfade und regionale Einschränkungen relevant.
2. Einheitlichkeit der Richtlinien
Eine Plattform bietet nur dann einen betrieblichen Vorteil, wenn Identitäten, Anwendungen, Webzugriffe und Netzwerkregeln konsistent verwaltet werden können. Bestehen die Module aus getrennten Oberflächen und unabhängigen Regelwerken, bleibt ein erheblicher Abstimmungsaufwand. Prüfe im Test, ob eine Änderung nachvollziehbar versioniert, freigegeben und zurückgenommen werden kann.
3. Windows- und Geräteintegration
Der Client muss mit den eingesetzten Windows-Versionen, der Geräteverwaltung, dem Identitätsdienst und vorhandenen Sicherheitsprogrammen zusammenarbeiten. Zu testen sind Installation, automatische Aktualisierung, Benutzerwechsel, Ruhezustand, Netzwechsel und eine gestörte Verbindung zum SASE-Dienst. Ebenso wichtig ist das Verhalten vor der Windows-Anmeldung, falls Domänendienste oder andere Ressourcen schon beim Start benötigt werden.
4. Anwendungsunterstützung
Webanwendungen sind meist leichter einzubinden als ältere Client-Server-Software. Ein Pilot sollte deshalb bewusst problematische Protokolle, große Dateiübertragungen, Echtzeitkommunikation und Anwendungen mit fest hinterlegten Netzwerkzielen enthalten. Wenn nur einfache Browserzugriffe getestet werden, bleiben spätere Ausfälle vorhersehbar unentdeckt.
5. Protokolle, Auswertung und Schnittstellen
Die IT muss erkennen können, welcher Benutzer mit welchem Gerät auf welches Ziel zugreifen wollte und welche Regel die Entscheidung ausgelöst hat. Prüfe Suchmöglichkeiten, Aufbewahrung, Export und Anbindung an die vorhandene Sicherheitsüberwachung. Vollständige Protokollierung muss zugleich zu Datenschutz, Rollenmodell und Löschvorgaben des Unternehmens passen.
6. Betrieb bei Störungen
Eine zentrale Cloud-Plattform kann zu einem wichtigen Abhängigkeitspunkt werden. Benötigt werden dokumentierte Ausweichwege für ausgefallene Zugangspunkte, Identitätsdienste oder Client-Komponenten. Der Anbieter muss außerdem erkennen lassen, welche Funktionen bei einer Störung offen bleiben, blockieren oder mit zwischengespeicherten Entscheidungen weiterarbeiten. Ein undokumentierter Fail-open-Modus kann Sicherheitsregeln umgehen; ein pauschaler Fail-closed-Modus kann den gesamten Betrieb stoppen.
Einführung in kontrollierten Etappen
Eine risikoarme Migration beginnt mit einer überschaubaren Benutzergruppe und wenigen gut verstandenen Anwendungen. Der vorhandene VPN-Zugang bleibt zunächst als Rückweg bestehen. So lässt sich zwischen einem Fehler der Zielanwendung, einer falschen SASE-Regel und einem allgemeinen Verbindungsproblem unterscheiden.
- Messbaren Pilot festlegen: Wähle Benutzer aus verschiedenen Arbeitsorten sowie repräsentative Windows-Geräte. Definiere vorab, welche Anwendungen funktionieren müssen und welche Latenz- oder Stabilitätsabweichungen untersucht werden.
- Zuerst Sichtbarkeit herstellen: Falls die Plattform einen Überwachungsmodus bietet, kann die IT Datenflüsse beobachten, bevor blockierende Regeln aktiviert werden. Personenbezogene Protokolle dürfen dabei nur im festgelegten rechtlichen und organisatorischen Rahmen verarbeitet werden.
- Zugriffe an Anwendungen binden: Freigaben werden schrittweise von breiten Netzwerkbereichen auf benötigte Anwendungen und Benutzergruppen reduziert. Administrative Zugänge erhalten eigene Regeln und eine stärkere Authentifizierung.
- Windows-Client gestaffelt verteilen: Die Installation erfolgt zunächst auf Testgeräten. Erst nach bestandenen Tests für Netzwechsel, Namensauflösung und lokale Ressourcen wird die nächste Gerätegruppe aufgenommen.
- Standorte separat migrieren: Die Anbindung einer Niederlassung über SD-WAN ist ein anderer Änderungstyp als die Einführung eines Benutzer-Clients. Getrennte Wartungsfenster und Rückfallpläne verhindern, dass mehrere Fehlerquellen gleichzeitig entstehen.
- Altsysteme erst am Ende abschalten: VPN-Gateways, alte Proxy-Systeme oder Firewall-Regeln werden erst entfernt, wenn Nutzungsprotokolle und Anwendungstests bestätigen, dass keine benötigten Pfade mehr davon abhängen.
Die Erfolgskontrolle darf nicht nur prüfen, ob die Verbindung hergestellt wird. Ein erfolgreicher Pilot zeigt ebenfalls, dass unzulässige Zugriffe blockiert, Entscheidungen verständlich protokolliert und Fehlkonfigurationen ohne lange Unterbrechung zurückgenommen werden können.
Typische Beobachtungen richtig einordnen
Bei SASE-Problemen führt eine symptomorientierte Prüfung schneller zum Ziel als die Neuinstallation des Windows-Clients.
- Alle Ziele sind unerreichbar: Prüfe zuerst Client-Status, Internetzugang, Identitätsanmeldung und Erreichbarkeit eines alternativen Zugangspunkts. Betrifft der Fehler nur ein Gerät, ist eine lokale Kollision mit Netzwerk- oder Sicherheitssoftware wahrscheinlicher.
- Webseiten funktionieren, eine interne Anwendung nicht: Dann liegt der Fehler eher bei Anwendungsfreigabe, privater Namensauflösung, Routing oder Protokollunterstützung als bei der allgemeinen SASE-Verbindung.
- Nur ein Standort ist langsam: Vergleiche den verwendeten Zugangspunkt, die lokale Leitung und den Datenpfad zum Anwendungsziel mit einem funktionierenden Standort. Eine schnelle Internetleitung verhindert keinen ungünstigen Umweg.
- Die Anmeldung gelingt, der Zugriff wird verweigert: Kontrolliere die zugeordnete Benutzergruppe, den erkannten Gerätestatus und die ausgelöste Richtlinie. Eine erfolgreiche Mehrfaktor-Anmeldung ersetzt keine Anwendungsberechtigung.
- Lokale Drucker oder Geräte verschwinden: Untersuche, ob der Client den gesamten Verkehr tunnelt oder lokale Netzwerkziele sperrt. Eine Ausnahme sollte nur den benötigten lokalen Bereich und Dienst umfassen, nicht das komplette Heim- oder Büronetz freigeben.
Wo SASE allein nicht ausreicht
SASE schützt Zugriffswege und setzt zentrale Richtlinien durch, ersetzt aber weder die Absicherung des Windows-Endgeräts noch die sichere Konfiguration der Zielanwendung. Ein kompromittierter PC kann mit gültigen Anmeldedaten erlaubte Anwendungen missbrauchen. Patchmanagement, Endpoint-Schutz, sichere Basiskonfiguration, privilegierte Konten und Datensicherung bleiben eigenständige Aufgaben.
Auch interne Segmentierung verschwindet nicht. Server, Produktionssysteme und Verwaltungsnetze benötigen weiterhin passende Grenzen, selbst wenn der externe Zugriff über ZTNA erfolgt. Für Unternehmen mit überwiegend lokalen Anwendungen, wenigen Außenstellen und kaum mobiler Arbeit kann eine vollständige SASE-Umstellung mehr Komplexität als Nutzen bringen. In diesem Fall kann ein begrenzter Einstieg mit ZTNA oder SSE sinnvoller sein als die gleichzeitige Erneuerung des gesamten WAN.
Die tragfähige Entscheidung lautet daher nicht SASE oder keine Sicherheit. Sie lautet: Welche Benutzer, Geräte, Standorte und Anwendungen profitieren von identitätsbezogener Cloud-Prüfung, und welche lokalen oder älteren Systeme benötigen weiterhin andere Schutz- und Verbindungswege? Eine dokumentierte Pilotphase beantwortet diese Frage zuverlässiger als eine Funktionsliste.
Häufige Fragen zur SASE-Nutzung
Kann ein Unternehmen mehrere SASE-Anbieter gleichzeitig einsetzen?
Ein Parallelbetrieb ist technisch möglich und kann während einer Migration nötig sein. Dauerhaft entstehen jedoch leicht doppelte Clients, widersprüchliche Richtlinien und getrennte Protokolle. Soll ein zweiter Anbieter die Ausfallsicherheit erhöhen, muss vorab geklärt werden, wie Identitäten, Zertifikate, DNS, Routing und Regelstände synchron gehalten werden. Zwei unabhängige Plattformen schaffen ohne abgestimmtes Betriebsmodell keine automatische Redundanz.
Wie werden externe Dienstleister ohne verwalteten Windows-PC eingebunden?
Für browserbasierte Anwendungen kann ein clientloser ZTNA-Zugang geeignet sein, sofern die Plattform und die Zielanwendung ihn unterstützen. Bei anderen Protokollen kommen ein eingeschränkter Client, ein administrierter Sprungserver oder ein speziell verwaltetes Gerät infrage. Externe Konten sollten zeitlich begrenzt, einer verantwortlichen internen Person zugeordnet und auf die benötigte Anwendung beschränkt werden.
Kann SASE in einer Übernahme oder Unternehmensfusion schrittweise genutzt werden?
SASE kann einen kontrollierten Zugang zu ausgewählten Anwendungen bereitstellen, ohne beide Unternehmensnetze sofort vollständig zu koppeln. Das reduziert die notwendige Netzwerkreichweite während der Übergangsphase. Vorher müssen jedoch doppelte Identitäten, überlappende IP-Adressbereiche, gemeinsame DNS-Namen und unterschiedliche Gerätestandards geklärt werden. Die Plattform erleichtert die Durchsetzung von Regeln, löst diese Integrationskonflikte aber nicht selbst.
