SASE und VPN: Wie passt das zusammen?

SASE und VPN werden in vielen Unternehmen zunächst als Gegensätze wahrgenommen: Das VPN steht für den klassischen, verschlüsselten Tunnel ins Firmennetz – SASE (Secure Access Service Edge) für eine cloudbasierte Architektur, die Netzwerk- und Sicherheitsfunktionen „an den Rand“ bringt. In der Praxis passt das jedoch sehr gut zusammen, wenn man SASE nicht als Produkt, sondern als Zielbild versteht: Nutzer und Standorte sollen unabhängig vom Ort sicher, performant und kontrolliert auf Anwendungen und Daten zugreifen können – egal ob diese im Rechenzentrum, in der Cloud oder als SaaS betrieben werden. VPN bleibt dabei häufig ein Baustein, allerdings mit veränderter Rolle: Statt „VPN = internes LAN“ geht es um gezielten Zugriff, klare Policies, bessere Beobachtbarkeit und weniger Backhaul. Dieser Artikel erklärt verständlich, was SASE ist, welche Komponenten dazugehören, wo VPN weiterhin sinnvoll ist, wann ZTNA/SSE Teile des VPN ersetzt und wie Sie SASE und VPN so kombinieren, dass Sicherheit, Nutzererlebnis und Betrieb wirklich profitieren.

Was ist SASE? Kurz und sauber definiert

SASE steht für Secure Access Service Edge und beschreibt ein Architekturkonzept, das Netzwerk- und Sicherheitsfunktionen als Cloud-Service zusammenführt. Gartner beschreibt SASE als Konvergenz von Netzwerk und Sicherheit als Service, typischerweise inklusive SD-WAN, Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), Firewall-as-a-Service (FWaaS/NGFW) und Zero Trust Network Access (ZTNA). Eine kompakte Definition finden Sie im Gartner-Glossar zu Secure Access Service Edge (SASE).

Wichtig: SASE ist kein einzelnes Produkt, sondern ein Bündel von Fähigkeiten. Anbieter setzen es unterschiedlich um, und nicht jede „SASE“-Lösung ist in allen Bereichen gleich stark. Für Planung und Einkauf ist deshalb entscheidend, welche Funktionen Sie wirklich benötigen und wie diese technisch integriert sind.

SSE, ZTNA, SWG, CASB: Die Bausteine verständlich erklärt

Im Alltag taucht neben SASE oft der Begriff SSE (Security Service Edge) auf. SSE fokussiert auf die Sicherheitskomponenten (z. B. SWG, CASB, ZTNA) und lässt die WAN-Komponente (SD-WAN) als separaten Baustein zu. Eine Definition bietet das Gartner-Glossar zu Security Service Edge (SSE).

• ZTNA: Zugriff auf private Anwendungen nach Zero-Trust-Prinzipien, meist anwendungsbezogen statt netzwerkweit.
• SWG: Sicherer Webzugang, Filterung, Malware-Schutz, Policy Enforcement für HTTP/HTTPS.
• CASB: Kontrolle über SaaS-Nutzung (z. B. DLP, Shadow-IT-Erkennung, Governance).
• FWaaS/Cloud-Firewall: Firewall-Funktionen als Cloud-Service, oft inklusive IPS/Threat Prevention.
• SD-WAN: Optimierung und Steuerung von Standort-WANs (Pfadwahl, QoS, Failover, Segmentierung).

Der gemeinsame Nenner: Policies werden zentral definiert und nahe am Nutzer bzw. am Standort durchgesetzt – idealerweise über eine global verteilte Plattform.

Wo passt VPN in dieses Bild?

Ein VPN ist primär eine Transport- und Tunneltechnologie. Es verschlüsselt Verkehr zwischen Endpunkten (Client↔Gateway oder Standort↔Standort) und ermöglicht Routing in private Netze. Die IPsec-Architektur ist standardisiert (z. B. RFC 4301), und IKEv2 als gängiger Aushandlungsmechanismus ist in RFC 7296 beschrieben.

SASE ersetzt diese Tunneltechnik nicht zwangsläufig. In vielen Designs bleibt VPN relevant, aber es wird anders eingesetzt:

• VPN für Standortvernetzung: Site-to-Site IPsec bleibt häufig der Standard, besonders für Filialen, Produktionsnetze, OT und hybride Rechenzentren.
• VPN als „On-Ramp“: Ein Tunnel kann als Transport dienen, um Traffic in die SASE/SSE-Plattform zu bringen (z. B. von Filialen).
• VPN als Ausnahme: Für Legacy-Protokolle oder Spezialzugriffe (z. B. bestimmte Admin-Workflows) bleibt VPN oft die pragmatische Lösung.
• VPN wird schlanker: Statt „alles über VPN“ werden nur die wirklich notwendigen privaten Netze getunnelt, während SaaS/Web über SSE laufen.

Warum Unternehmen überhaupt Richtung SASE denken

SASE ist selten ein Selbstzweck. Typische Treiber sind:

• Cloud- und SaaS-Verlagerung: Anwendungen und Daten sind nicht mehr nur im Rechenzentrum, sondern überall.
• Remote Work als Normalzustand: Nutzer sitzen in heterogenen Netzen, Latenz und Stabilität sind variabler.
• Security-Konsolidierung: Statt viele Einzellösungen (Proxy, CASB, VPN, Firewall, DLP) zu betreiben, sollen Policies zentral und konsistent sein.
• Performance: Backhaul über zentrale VPN-Gateways kann SaaS/Video spürbar verschlechtern; Edge-nahe Durchsetzung reduziert Umwege.
• Risikoreduktion: „VPN = internes Netz“ führt häufig zu zu breiten Zugriffen. Zero Trust zwingt zur feineren Zugriffskontrolle.

Zero Trust und SASE: Verwandt, aber nicht identisch

Zero Trust ist ein Sicherheitsprinzip, SASE eine Architektur, die Netzwerk- und Security-Services als Cloud-Plattform bündelt. SASE enthält oft ZTNA als Baustein, aber Zero Trust geht weiter: Identität, Gerätezustand, Kontext, kontinuierliche Bewertung und striktes Least Privilege. Eine gute konzeptionelle Grundlage liefert NIST SP 800-207 (Zero Trust Architecture). Ergänzend hilft das CISA Zero Trust Maturity Model, um Reifegrade und Roadmaps zu strukturieren.

Praxisübersetzung: Sie können SASE einkaufen und trotzdem kein Zero-Trust-Niveau erreichen, wenn Identitäts- und Geräteprozesse schwach sind. Umgekehrt können Sie Zero Trust etablieren, ohne „alles SASE“ zu machen – etwa durch starke IAM-Policies, Segmentierung und app-zentrierten Zugriff.

Typische Architekturmuster: So „passt das zusammen“

In der Praxis gibt es drei Muster, die sich besonders bewähren.

Modell A: SSE für Nutzer, VPN bleibt für Site-to-Site

• Nutzerzugriff auf SaaS/Web und private Apps über SSE/ZWG/CASB/ZTNA.
• Standorte bleiben per IPsec Site-to-Site verbunden.
• Vorteil: schnelle Verbesserung bei Remote Work und SaaS-Sicherheit, ohne Filialnetz sofort umzubauen.

Modell B: SD-WAN + SSE als SASE für Filialen, Remote Nutzer via ZTNA

• Filialen nutzen SD-WAN für Pfadsteuerung und bringen Traffic direkt in die SASE-Plattform.
• Remote Nutzer verbinden sich anwendungsbezogen via ZTNA, nicht ins ganze Netz.
• Vorteil: weniger Backhaul, konsistente Policies für Branch und Remote, bessere Skalierung.

Modell C: VPN als kontrollierter „Privileged Access“-Kanal, Rest Zero Trust

• Standardnutzer arbeiten über SSE/ZTNA und SaaS direkt.
• Admins nutzen ein gesondertes, stark gehärtetes VPN-Profil (MFA, Bastion, strikte Zielnetze).
• Vorteil: sehr klare Risikoabgrenzung, VPN wird nicht zum Allzweckzugang.

Was sich für IT-Teams ändert: Policies, Routing und Betrieb

SASE verändert nicht nur die Technik, sondern vor allem den Betriebsmodus. Typische Unterschiede zum VPN-zentrierten Betrieb:

• Policy-Design: weniger „Subnets freigeben“, mehr „Ressourcen/Apps nach Identität und Kontext erlauben“.
• DNS und Namensauflösung: Split-DNS und private Namensräume müssen sauber in ZTNA/SSE integriert werden.
• Routing wird bewusster: Internet-/SaaS-Traffic muss nicht über VPN, private Apps schon – häufig entsteht ein hybrides, selektives Routing.
• Observability: Logs und Metriken verlagern sich in die Plattform; SIEM-Integration und Korrelation mit IdP werden wichtiger.
• Change-Management: Policy-Änderungen wirken sofort global; Tests, Rollback und Versionierung werden zentral.

Sicherheit: Welche Risiken werden besser – und welche kommen neu dazu?

SASE kann typische VPN-Risiken reduzieren, bringt aber eigene Abhängigkeiten mit.

Was SASE oft verbessert

• Least Privilege: ZTNA erlaubt Zugriff auf Apps statt Netzsegmente, reduziert laterale Bewegung.
• Konsistente Web/SaaS-Security: SWG/CASB setzen Policies auch außerhalb des Firmennetzes durch.
• Bessere Kontrolle bei BYOD: Zugriff kann stärker an Identität, Device Posture und App-Ebene gekoppelt werden.

Neue Abhängigkeiten und Risiken

• IdP als kritischer Pfad: Wenn SSO/MFA ausfällt, kann Zugriff global beeinträchtigt sein.
• Plattform-/Provider-Risiko: Verfügbarkeit und Routing der Cloud-Plattform werden zentral.
• Fehlkonfigurationen skalieren stärker: Eine zu breite Policy wirkt sofort für viele Nutzer.
• Datenschutz und Datenpfade: Inspektion (SWG/DLP) bedeutet, dass Traffic über bestimmte Regionen laufen kann; Governance ist wichtig.

Performance: Warum SASE nicht automatisch schneller ist

SASE verspricht oft bessere Performance durch Edge-Nähe. Das stimmt häufig, aber nicht garantiert. Entscheidend ist:

• PoP-Abdeckung: Gibt es nahe Punkte of Presence für Ihre Nutzerstandorte?
• Traffic-Steuerung: Was wird lokal breakoutet, was muss zur Plattform, was bleibt im VPN?
• Echtzeittraffic: VoIP/Video profitieren von niedriger Latenz und stabilem Pfad; QoS-Strategien bleiben relevant.
• MTU/NAT-Effekte: Tunnel-Overhead (VPN oder Plattform-Tunnel) bleibt ein Thema, besonders in Mobilfunk-/NAT-Umgebungen.

Entscheidungshilfe: Wann SASE plus VPN ein guter Schritt ist

Ein SASE/SSE-Ansatz passt besonders gut, wenn folgende Rahmenbedingungen zutreffen:

• Hoher Anteil an SaaS und Cloud-Anwendungen, die heute durch Full-Tunnel-VPN ausgebremst werden.
• Viele Remote Worker und heterogene Netze, in denen konsistente Web-/SaaS-Policies fehlen.
• Partner/Dienstleister, die nur Zugriff auf wenige Anwendungen benötigen (ZTNA statt Netz-Zugang).
• Ein reifes Identity- und Device-Management (SSO, MFA, MDM/EDR, Compliance-Checks).
• Der Wunsch nach Konsolidierung von Proxy, CASB, DLP, Firewall-Funktionen und Remote Access.

Wann VPN (noch) im Zentrum bleiben sollte

• Viele Legacy-Anwendungen benötigen echten Layer-3-Zugriff oder sprechen Protokolle, die schwer ZTNA-fähig sind.
• OT/Industrie und standortbasierte Netzwerke erfordern stabile, deterministische Vernetzung (Site-to-Site IPsec).
• Sehr strenge Anforderungen an Autonomie oder Offline-Fähigkeit (Abhängigkeiten von Cloud-Plattformen sind unerwünscht).
• Ein starkes, bereits ausgereiftes Segmentierungs- und Policy-Modell existiert, das VPN-Zugriff sehr granular begrenzt.

Praktische Umsetzung: Die wichtigsten Schritte für eine saubere Kombination

• Use Cases priorisieren: SaaS/Web zuerst (SSE), private Apps danach (ZTNA), VPN nur für Spezialfälle.
• Identität härten: MFA verpflichtend, Conditional Access, sauberes Offboarding, Rollenmodell.
• Device Posture definieren: welche Mindeststandards braucht Zugriff auf sensible Apps?
• DNS- und Namenskonzept: Split-DNS, interne Zonen, Zertifikatsketten, private FQDNs sauber abbilden.
• Logging & SIEM: VPN- und SASE-Logs korrelieren (IdP↔Access↔App), klare Alarmregeln definieren.
• Failover planen: Provider-Ausfall, PoP-Ausfall, IdP-Ausfall – mit getesteten Fallbacks (ggf. konservatives VPN-Profil als Backup).
• Migration iterativ: nicht „Big Bang“, sondern Gruppenweise (Pilot, Standardnutzer, Partner, dann Sonderfälle).

Outbound-Links zur Vertiefung

• Gartner Glossary: Secure Access Service Edge (SASE)
• Gartner Glossary: Security Service Edge (SSE)
• NIST SP 800-207: Zero Trust Architecture
• CISA: Zero Trust Maturity Model
• BSI: Zero Trust (Überblick)
• RFC 4301: IPsec Architecture
• RFC 7296: IKEv2

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.