SASE und VPN: Übergangsarchitektur für hybride Remote Access Modelle

SASE und VPN zusammenzudenken ist für viele Unternehmen der realistischste Weg, um Remote Access in hybriden IT-Landschaften sicher, performant und betrieblich beherrschbar zu gestalten. Denn die meisten Organisationen können (und sollten) klassische VPN-Tunnel nicht „über Nacht“ abschalten: Es gibt Legacy-Anwendungen, nicht proxyfähige Protokolle, Standortvernetzung, Sonderfälle für Adminzugriffe sowie Abhängigkeiten von Routing, DNS und Identity. Gleichzeitig steigen die Anforderungen an Zero-Trust-Prinzipien, kontextbasierte Policies, cloudnahe Security-Services und eine bessere User Experience – genau hier setzt SASE an, indem Netzwerk- und Security-Funktionen als verteilte Cloud-Services näher an den Nutzer rücken. Eine gute Übergangsarchitektur verbindet beide Welten: VPN bleibt für bestimmte Workloads und als Fallback, während SASE-/ZTNA-Pfade schrittweise den Standardzugang für SaaS, Web-Apps und definierte interne Services übernehmen. Dieser Artikel zeigt, wie Sie hybride Remote-Access-Modelle entwerfen, ohne User-Friktion zu erzeugen, und wie Sie Policies, Identity, Logging, Egress-Controls und Betriebsprozesse so strukturieren, dass der Übergang auditierbar, skalierbar und kontrolliert bleibt.

SASE, ZTNA und VPN: Begriffsklärung für eine saubere Architektur

Bevor Sie eine Übergangsarchitektur entwerfen, lohnt sich eine saubere Abgrenzung. „SASE“ (Secure Access Service Edge) ist kein einzelnes Produkt, sondern ein Architekturansatz: Security-Funktionen (z. B. Secure Web Gateway, CASB, Firewall as a Service, DLP) und Netzwerkzugang (z. B. ZTNA) werden als cloudbasierte, verteilte Services bereitgestellt und nahe an Nutzer und Standorte gebracht. „ZTNA“ ist dabei häufig der Remote-Access-Kern: Zugriff wird auf Applikationen gewährt, nicht auf Netze. VPN (Remote-Access-VPN) liefert dagegen meist eine Tunnelverbindung (Layer 3/4) und damit generische Netzwerkkonnektivität.

• VPN (Tunnel): Netzwerkzugang mit Routen, Split-/Full-Tunnel-Entscheidung, häufig hohe Flexibilität für Legacy-Protokolle.
• ZTNA: Applikationszentrierter Zugriff, identitäts- und kontextbasiert, reduziert Standard-Exposition.
• SASE: Rahmen, in dem ZTNA plus Web-/Cloud-Security-Controls und Policy-Orchestrierung zusammenlaufen.

Für Zero-Trust-Prinzipien als Leitplanke ist NIST SP 800-207 (Zero Trust Architecture) eine gute Referenz, weil es das Denken „Zugriff pro Request und Kontext“ strukturiert beschreibt.

Warum eine Übergangsarchitektur nötig ist

Der Umstieg auf SASE-/ZTNA-Modelle scheitert selten an Technologie, sondern an Realitäten im Anwendungsportfolio und im Betrieb. Typische Gründe, warum VPN nicht sofort verschwinden kann:

• Legacy- und Spezialprotokolle: Nicht alle Anwendungen sind proxyfähig oder ZTNA-kompatibel (z. B. bestimmte Client/Server-Apps, OT/IoT, proprietäre Tools).
• Standortvernetzung und Routingdomänen: Net-to-Net bleibt häufig ein VPN-/SD-WAN-Thema, unabhängig von User-to-App-Zugriff.
• Privileged Access: Adminzugriffe sind oft mit Bastion-/Jump-Host-Designs verbunden, die nicht immer sofort umgebaut werden können.
• Regulatorik und Audit-Readiness: Änderungen am Access-Modell müssen nachvollziehbar, kontrolliert und rezertifizierbar erfolgen.
• User Experience: Ein „Big Bang“ erzeugt Friktion, Tickets und Akzeptanzprobleme; schrittweiser Übergang ist meist stabiler.

Zielbild: Hybride Remote Access Modelle mit klarer Rollenverteilung

Eine gute Übergangsarchitektur definiert von Anfang an, wofür VPN weiterhin genutzt wird und wofür SASE/ZTNA der Standard wird. Ein praxistaugliches Zielbild ist:

• SASE/ZTNA als Standardpfad: Für SaaS, interne Webanwendungen, APIs, Entwickler-Tools, Partnerportale, definierte Admin-Oberflächen (mit Step-up).
• VPN als Spezialpfad: Für nicht proxyfähige Legacy-Workloads, bestimmte Verwaltungsszenarien, Notfall-/Break-Glass-Fallback und Net-to-Net-Anforderungen.
• Klare Profile: Standard User, Entwickler, Admin/Privileged, Partner/Contractor – jeweils mit separaten Policies und möglichst separaten Pfaden.

Die wichtigste Leitplanke lautet: VPN darf nicht mehr der Default für „alles“ sein, wenn Sie wirklich SASE-Vorteile (Least Privilege, weniger laterale Bewegung, bessere Auditierbarkeit) erreichen wollen.

Architekturbausteine einer Übergangslösung

Damit SASE und VPN parallel funktionieren, brauchen Sie klare, wiederverwendbare Bausteine. In Enterprise-Projekten haben sich folgende Komponenten als „Must-haves“ bewährt:

• Identity Provider (IdP) als Policy-Anker: SSO, MFA, Conditional Access, risikobasierte Entscheidungen.
• Device Management: MDM/Endpoint-Management für Gerätezustand, Zertifikate, Compliance und Client-Konfiguration.
• ZTNA-/SASE-Connectoren: „Outbound“ aus internen Netzen zu SASE-PoPs, um interne Apps ohne inbound Öffnungen zu veröffentlichen (produktabhängig).
• VPN-Gateways mit klarer Segmentierung: VPN terminiert in definierten Zonen/VRFs, nicht „im Core“.
• DNS- und Egress-Design: Split DNS, Resolver-HA, Proxy/SWG, DLP – je nach Full-/Split-/Hybrid-Modell.
• Logging/Telemetry Pipeline: Einheitliche Korrelation über User-, Device- und Session-IDs.

Identity und MFA: Gemeinsame Grundlage für beide Welten

Die sauberste Übergangsarchitektur nutzt einen gemeinsamen Identity-Backbone: egal ob der Nutzer über VPN oder über ZTNA zugreift, die Identität wird konsistent geprüft, und Policies sind nachvollziehbar. Best Practices:

• MFA verpflichtend: Für Remote Access grundsätzlich, für privilegierte Aktionen als Step-up.
• Phishing-resistente Methoden bevorzugen: Wo möglich FIDO2/WebAuthn oder vergleichbare starke Faktoren.
• Conditional Access: Kontextsignale (Standort, Risk Score, Device Compliance) steuern, ob ZTNA/VPN überhaupt erlaubt ist.
• Trennung von Nutzer- und Geräteidentität: Managed Devices können mehr Vertrauen bekommen als BYOD – aber nur mit klarer Governance.

Device Posture: Warum SASE ohne Managed Devices oft enttäuscht

Ein großer Teil des SASE-Nutzens entsteht durch kontextbasierte Policies. Wenn Sie Geräte nicht verwalten, verlieren Sie wichtige Signale: Patchlevel, EDR-Status, Disk Encryption, Jailbreak/Root. Übergangsarchitekturen sollten daher mindestens zwei Posture-Klassen unterstützen:

• Managed & compliant: Zugriff auf definierte interne Services und SaaS, ggf. breitere Reichweite (aber immer noch least-privileged).
• Unmanaged oder non-compliant: Stark eingeschränkter Zugriff (z. B. nur Web-Apps mit zusätzlicher MFA, nur Remediation-Services, kein Netzwerktunnel).

Damit reduzieren Sie User-Friktion, weil das Gerät nicht „einfach kaputt“ wirkt, sondern automatisch in ein Restrict-/Remediation-Profil fällt.

Traffic-Steuerung: Split, Full und Hybrid in der Übergangsphase

Während der Übergangsphase existieren meist zwei Datenpfade: VPN-Tunnel und SASE-Pfad (Proxy/ZTNA). Ohne klare Regeln kommt es zu Inkonsistenzen, DNS-Leaks, asymmetrischen Pfaden und schwer debugbaren Effekten. Bewährte Muster:

Hybrid als Default für Managed Devices

• SaaS/Web über SASE: SWG/CASB/DLP greifen zentral, ohne Backhaul über VPN.
• Interne Webapps über ZTNA: App-spezifischer Zugriff, geringe Exposition.
• Legacy-Netze über VPN: Nur die Subnetze, die wirklich L3 brauchen, werden über den Tunnel geroutet.

Policy-Prinzip: „Erst App, dann Netz“

• Bevorzugen Sie ZTNA, wo möglich: Für webfähige Apps und APIs.
• Nutzen Sie VPN als Ausnahme: Für Protokolle/Apps, die nicht sauber als App-Zugriff abbildbar sind.
• Verhindern Sie Doppelwege: Eine Ressource sollte möglichst genau einen Standardpfad haben, sonst werden Incidents schwer.

Segmentierung: VPN darf nicht zum „Backdoor-Netz“ werden

In Übergangsarchitekturen ist ein häufiger Fehler, VPN als „alles geht noch darüber“-Fallback zu behalten. Damit unterlaufen Sie die Zero-Trust-Ziele und schaffen ein Shadow-Bypass. Best Practices:

• VPN-Termination in dedizierter Zone/VRF: Strikte Policies, keine direkte Core-Integration.
• Rollenbasierte VPN-Profile: Standard-User bekommen keine Admin-Netze, Adminzugriffe getrennt (Bastion).
• ZTNA-first für Partner: Partnerzugänge möglichst nicht per Tunnel ins Netz, sondern app-spezifisch und zeitlich begrenzt.
• Rezertifizierung: Jede VPN-Subnetzfreigabe hat Owner, Zweck, Ablaufdatum.

Privileged Access: Bastion statt „Admin-VPN ins Admin-Subnetz“

Adminzugriffe sind in hybriden Remote-Access-Modellen ein Spezialfall. Ein robustes Pattern ist: ZTNA (oder clientless Zugriff) bis zu einem Bastion-/Jump Host, von dort aus weiter in kritische Netze, mit Session Recording und strikter MFA/Step-up.

• Minimale Exposition: Admin-Subnetze werden nicht pauschal über VPN geroutet.
• Auditierbarkeit: Session IDs, Recording, klare Trennung von Standard- und Privileged Sessions.
• Break-Glass: Definierte Notfallwege, aber mit strengen zeitlichen Begrenzungen und Nachkontrolle.

Performance und User Experience: Das häufig unterschätzte Entscheidungskriterium

SASE kann UX verbessern, weil Traffic zu cloudnahen Services nicht mehr über zentrale VPN-Hubs backhauled. Gleichzeitig kann die Übergangsphase UX verschlechtern, wenn Pfade inkonsistent sind oder DNS/Egress nicht sauber modelliert ist.

• Backhaul reduzieren: SaaS über SASE statt über Full-Tunnel-VPN.
• Region-Affinität: Nutzer sollten „in ihrer Region“ landen; Umschaltungen während Sessions vermeiden.
• Service-orientierte Health Checks: Nicht nur „PoP erreichbar“, sondern Auth, DNS, Proxy-Funktionen müssen gesund sein.
• Captive Portals berücksichtigen: Besonders bei Always-On-/Managed-Device-Modellen muss Internet-First funktionieren.

MTU/MSS und PMTUD: Die Klassiker verschwinden nicht automatisch

Auch in SASE-Architekturen gibt es Encapsulation (z. B. Tunnel zum PoP, Proxy-Ketten, zusätzliche Header). In hybriden Designs kommt hinzu, dass VPN-Tunnel weiterhin existieren. Ohne klare MTU/MSS-Standards entstehen „nur manche Apps“-Fehlerbilder. Grundlagen: RFC 1191 (PMTUD IPv4) und RFC 8201 (PMTUD IPv6).

• Konservative MTU-Defaults: Pro Profil/Unterlay-Klasse standardisieren, statt Einzelfall-Fixes.
• MSS-Clamping: Für VPN-Pfade weiterhin wichtig, besonders bei TLS-/Web-Workloads.
• ICMP gezielt erlauben: PMTUD braucht Feedback, sonst entstehen Blackholes.

Logging und Audit-Readiness: Eine einheitliche Sicht über beide Pfade

Der Übergang auf SASE ist nur dann auditierbar, wenn Sie VPN- und ZTNA/SASE-Events konsistent korrelieren können. Ziel ist: ein gemeinsames Sicherheitsbild, egal ob der Zugriff über Tunnel oder App-Pfad erfolgt.

• IdP/MFA-Logs: Auth-Erfolg/-Fehler, Step-up, Risk Signals.
• ZTNA-/SASE-Access-Logs: App, Policy, User, Device, Session-ID, Allow/Deny.
• VPN-Logs: Session Start/Ende, Profil, zugewiesene IP, Gateway-Knoten, Fehlergründe.
• Proxy/SWG/DNS-Logs: Kategorien, Block-Events, DLP, Resolver-Latenz.
• Korrelation: Stabile User-ID, Device-ID, Session-ID, NTP überall.

Ohne Korrelation entstehen „zwei Welten“: SASE-Teams sehen App-Zugriffe, VPN-Teams sehen Tunnelzustände, aber niemand sieht End-to-End.

Betrieb und Change-Management: Der Übergang ist ein Produkt, kein Projekt

Hybride Remote-Access-Modelle sind über Monate oder Jahre Realität. Deshalb braucht der Übergang Produktdisziplin:

• Policy-Blueprints: Standardprofile, Adminprofile, Partnerprofile – versioniert und rezertifizierbar.
• Drift Detection: VPN-Subnetzlisten, Split-Tunnel-Ausnahmen und App-Katalog dürfen nicht unkontrolliert wachsen.
• Canary-Rollouts: Änderungen zuerst für kleine Gruppen, danach Ausweitung.
• Runbooks: Troubleshooting für „App down“, „SASE down“, „VPN down“, „DNS kaputt“, inklusive Fallback-Entscheidungen.

Migrationspfad: Von „VPN für alles“ zu „ZTNA/SASE als Standard“

Eine erfolgreiche Übergangsarchitektur hat einen klaren Migrationspfad, der messbar und rückbaubar ist. Ein praxistauglicher Ablauf:

Inventarisierung und Klassifizierung

• Applikationskatalog: Welche Apps werden über VPN genutzt? Webfähig, API-basiert, Legacy, Admin, Partner?
• Risikoklassen: Welche Apps brauchen Step-up, welche dürfen auf unmanaged Geräten laufen?
• Traffic-Profile: Bandbreite, Latenzempfindlichkeit, Protokolle.

ZTNA-first für „Low Hanging Fruit“

• Interne Webapps/APIs: Erste Kandidaten, weil sie gut proxyfähig sind.
• Developer-Tools: Häufig klar definierbar und gut auditierbar.
• Partnerzugriffe: App-spezifisch statt Tunnel, mit Timeboxing.

VPN-Scope schrittweise reduzieren

• Split-Tunnel-Ausnahmen abbauen: Wenn Apps über ZTNA laufen, verschwinden ihre VPN-Routen.
• Legacy-Inseln definieren: Was wirklich L3 braucht, bekommt ein klar begrenztes VPN-Profil.
• Decommission-Prozess: Alte VPN-Policies und Subnetze entfernen, nicht nur „nicht mehr kommunizieren“.

Typische Anti-Patterns in Übergangsarchitekturen

• „ZTNA daneben“ ohne Rückbau: Wenn VPN-Scope nicht reduziert wird, bleibt Exposition unverändert und Kosten steigen.
• Unkontrollierter App-Katalog: Apps werden veröffentlicht, aber Ownership und Rezertifizierung fehlen.
• VPN als Bypass: Jede ZTNA-Störung führt dazu, dass Teams VPN-Reichweite erweitern – Zero Trust wird unterlaufen.
• Identity als Single Point of Failure: Wenn alles am IdP hängt, braucht es Resilienz und Notfallpfade.
• Logging ohne End-to-End-Korrelation: Zwei getrennte Welten, keine belastbare Forensik.

Checkliste: Übergangsarchitektur für hybride Remote Access Modelle

• Zielbild definieren: ZTNA/SASE als Standardpfad, VPN als Ausnahme mit klarer Begründung.
• Identity vereinheitlichen: SSO/MFA/Conditional Access für beide Pfade konsistent.
• Device Posture nutzen: Managed/Unmanaged trennen, Restricted/Remediation Profile vorsehen.
• Traffic-Steuerung sauber planen: Hybrid-Modelle mit klaren Regeln, keine Doppelpfade pro Ressource.
• VPN segmentieren: Termination in VRF/Zone, minimale Routen, Rezertifizierung mit Enddatum.
• Privileged Access modernisieren: ZTNA + Bastion + Step-up + Recording statt Admin-Subnetz über VPN.
• DNS/Egress konsistent: Split DNS, Resolver-HA, Proxy/SWG-Policies, Logging.
• Observability aufbauen: IdP-, ZTNA-, VPN-, DNS- und Proxy-Logs korrelieren (User/Device/Session).
• Migration messbar machen: VPN-Nutzung pro App reduzieren, Legacy-Inseln klar begrenzen, Rückbau konsequent.

• NIST SP 800-207: Zero Trust Architecture
• TLS 1.3 Spezifikation (RFC 8446)
• PMTUD IPv4 (RFC 1191)
• PMTUD IPv6 (RFC 8201)

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.