Lokale ZTNA-Lösung für private Anwendungen

Bei einer lokalen ZTNA-Bereitstellung handelt es sich um eine Implementierung von „ zero trust network access “, bei der der Policy Enforcement Point für private Anwendungen auf der Infrastruktur in den unternehmenseigenen Rechenzentren und Niederlassungen betrieben wird. Nutzer und Systeme werden – wie bei jeder ZTNA – pro Anwendung authentifiziert und autorisiert, doch der Datenverkehr zwischen lokalen Nutzern und lokalen Anwendungen muss nicht über die Cloud eines Anbieters und zurück geleitet werden.

Dieser Artikel ist Teil des Leitfadens zur Hybrid-Cloud-Sicherheit.

So funktioniert ZTNA

ZTNA überprüft die Identität, das Gerät und den Kontext jedes Nutzers und stellt anschließend eine Verbindung zu einer einzelnen Anwendung statt zu einem Netzwerk her.

Die Zero-Trust-Architektur des NIST, SP 800-207, trennt den Punkt der Richtlinienentscheidung (an dem entschieden wird, ob ein Subjekt auf eine Ressource zugreifen darf) vom Punkt der Richtlinienumsetzung (an dem die Verbindung hergestellt, überwacht und beendet wird). ZTNA-Produkte setzen dieses Modell für private Anwendungen um:

1. Ein Benutzer oder ein System fordert den Zugriff auf eine Anwendung an.
2. Die Anfrage gelangt an einen Durchsetzungspunkt, in der Regel ein Gateway, einen Broker oder einen Proxy.
3. Die Richtlinie bewertet die Identität, die Gruppe, den Gerätestatus, den Standort, das Risiko sowie die konkret angeforderte Anwendung.
4. Sofern dies zulässig ist, verbindet der Durchsetzungspunkt den Nutzer ausschließlich mit dieser Anwendung. Der Rest des Netzwerks bleibt unsichtbar.
5. Die Sitzung wird überwacht und kann beendet werden, falls sich die Bedingungen ändern.

Der im Juni 2025 veröffentlichte Praxisleitfaden SP 1800-35 des NIST mit dem Titel „Implementierung einer Zero-Trust-Architektur“ dokumentiert 19 Beispielimplementierungen, die mit 24 Anbietern sowohl in lokalen als auch in Cloud-Umgebungen realisiert wurden, und dient als nützliche Referenz dafür, wie diese Komponenten in der Praxis zusammenwirken.

Cloud-basiertes ZTNA im Vergleich zu lokalem ZTNA

Der Unterschied besteht darin, wo die Durchsetzung erfolgt: bei jeder Sitzung in der Cloud des Anbieters oder bei lokalen Sitzungen auf den eigenen Gateways des Kunden.

In einem typischen Cloud-Broker-Modell läuft eine schlanke virtuelle Maschine (Connector) neben der Anwendung und eröffnet einen ausgehenden Tunnel zum Gateway des Anbieters, sodass keine eingehenden Firewall-Ports erforderlich sind. Skyhigh Private Access funktioniert beim Fernzugriff auf diese Weise: Der Client-Datenverkehr wird am SSE-Präsenzpunkt geleitet und über TLS-Tunnel zu Connectors weitergeleitet, die im selben Rechenzentrum, in derselben privaten Cloud oder in derselben öffentlichen Cloud wie die Anwendung bereitgestellt sind.

Bei einer lokal installierten ZTNA-Lösung wird ein lokaler Durchsetzungsweg hinzugefügt, sodass Benutzer und Systeme innerhalb des Netzwerks dieselbe anwendungsspezifische Kontrolle erhalten, ohne das Gebäude verlassen zu müssen.

Warum die lokale Durchsetzung wichtig ist

Durch die lokale Umsetzung wird ein „Hairpinning“ vermieden, der interne Datenverkehr sowie der Datenverkehr der KI-Agenten wird erreicht, und der Betrieb bleibt auch bei Cloud-Ausfällen gewährleistet.

Hairpinning. Die Weiterleitung des Datenverkehrs eines Büronutzers an einen Cloud-Broker und zurück zu einem Server am Ende des Flurs führt zu zusätzlicher Latenz und einer erhöhten Abhängigkeit vom Internet, ohne dass dadurch ein Sicherheitsvorteil entsteht.

Interner Datenverkehr. Ein Großteil des Datenverkehrs, der durch das Zero-Trust-Konzept geregelt werden sollte, verlässt die Internetgrenze nie: Administratorsitzungen, Aufrufe zwischen Anwendungen, Zugriff für die OT-Technik. Bei einer ausschließlich in der Cloud erfolgenden Durchsetzung wird dieser Datenverkehr nicht erfasst.

KI-Agenten und Dienstkonten. Autonome Agenten und Dienstkonten können über Zugriffsrechte auf Benutzerebene verfügen und Daten mit maschineller Geschwindigkeit zwischen internen Systemen übertragen. Skyhigh vertritt die Ansicht, dass die Kontrolle dieser Datenflüsse innerhalb des Netzwerks erfolgen muss, aus dem der Datenverkehr stammt (Skyhigh Security).

Kontinuität. Sollte die Cloud des Anbieters oder die Internetverbindung ausfallen, werden lokale Sitzungen gemäß den lokal geltenden Richtlinien fortgesetzt. Klären Sie mit Ihrem Anbieter, wie lange ein Verbindungsausfall unterstützt wird und wie sich dies auf die Sicherheits- und Identitätsprüfungen auswirkt.

Souveränität. Der lokale Anwendungsdatenverkehr kann in der Infrastruktur des Kunden verbleiben. Es wird protokolliert, wo Richtlinienentscheidungen, Identitätsprüfungen und Sitzungsmetadaten verarbeitet und gespeichert werden. Wenn eine Skyhigh-Sitzung einen in der Cloud angewandten Datenschutz erfordert, werden die entsprechenden Inhalte zur Überprüfung gemäß derselben Richtlinie an die Skyhigh-Cloud weitergeleitet.

Identitätskontrollen

Bei einer lokal installierten ZTNA-Lösung sollten dieselben strengen Identitätsprüfungen gelten wie beim Fernzugriff:

• Authentifizierung über den Identitätsanbieter des Unternehmens mit Phishing-resistenter MFA
• Gerätezustand: Verwaltungsstatus, Betriebssystemversion, Festplattenverschlüsselung, Endgeräteschutz
• Gruppe und Rolle, zugeordnet zu anwendungsspezifischen Berechtigungen
• Kontext: Ort, Zeit, Risikowert aus der Verhaltensanalyse
• Arbeitslast und Identität des Agenten bei nicht-menschlichem Zugriff
• Kontinuierliche Überwachung mit Beendigung der Sitzung bei Veränderungen der Körperhaltung oder des Risikos

Eine häufige Lücke besteht darin, dass Nutzer vor Ort von der Überprüfung des Gerätestatus ausgenommen werden. Die Anwesenheit im Unternehmens-LAN ist kein Indikator für den Gerätestatus.

Platzierung von Anschlüssen und Gateways

Platzieren Sie Gateways in der Nähe der Anwendungen, die sie schützen, in redundanten Gruppen und mit einer Segmentierung um sie herum.

• Platzieren Sie Gateways in der Nähe der Anwendungen, die sie schützen, entweder im selben Segment oder in einem angrenzenden Segment, sodass die geschützte Anwendung ausschließlich über das Gateway erreichbar ist.
• Stellen Sie die Systeme in Gruppen bereit, um Kapazität und Verfügbarkeit zu gewährleisten, und ordnen Sie Anwendungen Gruppen zu, anstatt sie einzelnen Gateways zuzuordnen.
• Behalten Sie bei Cloud-vermittelten Pfaden ausschließlich ausgehende Verbindungen bei, damit Anwendungen keinen eingehenden Verbindungen ausgesetzt sind.
• Nutzen Sie die vom Kunden verwaltete Netzwerksegmentierung, um zu verhindern, dass ein kompromittiertes Gateway auf nicht betroffene Systeme zugreifen kann.
• Planen Sie die Zweigstellen. Legen Sie fest, ob jede Zweigstelle über ein lokales Gateway verfügt oder an ein regionales Gateway angebunden ist.

Lokale Zugriffspfade

Ein hybrides ZTNA-Konzept erfordert drei explizite Zugriffspfade, die alle einer einzigen Richtlinie unterliegen:

1. Vom lokalen Benutzer zur lokalen Anwendung: lokales Gateway, kein Hin- und Rückweg über die Cloud.
2. Von einem Remote-Benutzer zur Anwendung vor Ort: vom Cloud-Broker zum lokalen Connector oder Gateway.
3. Vom lokalen Benutzer zur in der Cloud gehosteten Anwendung: lokales Gateway oder Cloud-Broker zu einem Konnektor in der Cloud-Umgebung.

Alle drei sollten eine einheitliche Richtliniendefinition verwenden, damit sich die Berechtigungen eines Benutzers nicht je nach Standort ändern.

Ein Beispiel für eine Zero-Trust-Architektur in einer Hybrid-Cloud

Eine hybride Zero-Trust-Architektur vereint lokale und cloudbasierte Durchsetzungsmaßnahmen unter einer einzigen Identitäts- und Richtlinienebene, wie dieses Beispiel zeigt.

Nehmen wir ein Finanzdienstleistungsunternehmen mit einem Rechenzentrum am Hauptsitz, 40 Niederlassungen, einer IaaS-Umgebung und Mitarbeitern im Homeoffice.

• Identität: Ein Identitätsanbieter mit MFA; Gerätestatus aus dem Endpunktmanagement.
• Hauptsitz: Lokale ZTNA-Gateways dienen als Schnittstelle zu den Verwaltungsschnittstellen des Kernbankensystems und den internen Tools. Die Mitarbeiter vor Ort stellen eine direkte Verbindung über das lokale Gateway her.
• Filialen: Filial-Gateways regeln den Zugriff auf Filialsysteme und leiten Anfragen an die Gateways der Zentrale weiter, um zentrale Anwendungen aufzurufen.
• IaaS: Connectors in der Cloud-Umgebung dienen als Schnittstelle für Workloads; Benutzer – sowohl remote als auch vor Ort – greifen über den entsprechenden Broker darauf zu.
• Mitarbeiter an entfernten Standorten: Cloud-Präsenzpunkte ermöglichen den Zugriff sowohl auf Rechenzentrums- als auch auf IaaS-Anwendungen.
• KI-Agenten: Service-Identitäten für interne KI-Assistenten erhalten anwendungsspezifische Berechtigungen, die lokal durchgesetzt werden.
• Richtlinie: Für alle Pfade gilt ein einheitlicher Regelkatalog, der von einer einzigen Konsole aus bereitgestellt wird.

Sollte die Internetverbindung ausfallen, arbeiten die Mitarbeiter in der Zentrale und in den Niederlassungen weiterhin mit lokalen Anwendungen, und die lokale Durchsetzung wird für den vorgesehenen Zeitraum ohne Internetverbindung fortgesetzt.

Zu bewertende Anforderungen an die Bereitstellung

Prüfen Sie die lokalen ZTNA-Lösungen anhand dieser Anforderungen, bevor Sie eine Vorauswahl an Anbietern treffen.

• Lokale Ausführung für lokale Benutzer ohne Cloud-Hairpinning
• Gleiche Richtlinien und Berechtigungen für lokale und Remote-Pfade
• Durchsetzung von Geräte-Richtlinien für Benutzer vor Ort
• Unterstützung für nicht-menschliche Identitäten und KI-Agenten
• Unterstützte Protokolle: Web, SSH, RDP, Datenbanken sowie ältere TCP/UDP-Protokolle
• Hochverfügbarkeit und Anschlussgruppen
• Vorgeschriebenes Verhalten, wenn die Anbieter-Cloud oder der Identitätsanbieter nicht erreichbar ist
• Protokollierung des Standorts und SIEM-Integration
• Integration mit dem Web-Gateway und DLP, damit Sitzungen in privaten Anwendungen datenschutzkonform sind

Software für eine Zero-Trust-Architektur in der Hybrid-Cloud

ZTNA ist eine Komponente einer hybriden Zero-Trust-Architektur.

Es arbeitet mit Identitätsanbietern, Endpunktmanagement, Web-Gateways, CASB, DLP und Segmentierung zusammen. Bewerten Sie ZTNA als Teil der Plattform, die die übrigen Aspekte Ihrer Richtlinien durchsetzen wird, und nicht als eigenständigen VPN-Ersatz. Siehe „Hybrid-Cloud-Sicherheitslösungen: So vergleichen Sie Anbieter“.

Wie Skyhigh ZTNA vor Ort bereitstellt

Skyhigh stellt ZTNA vor Ort über lokale Gateways im Hybrid-SSE-Mesh bereit, ergänzt durch die cloudvermittelte „ Private Access “.

In Skyhigh Hybrid SSE Mesh läuft das lokale ZTNA auf den unternehmenseigenen Gateways vor Ort und in den Zweigstellen – auf einer Infrastruktur, die sich im Besitz des Unternehmens befindet und unter dessen eigener Kontrolle geändert wird –, anstatt auf einem vom Anbieter betriebenen lokalen Knoten. Dadurch wird die Zero-Trust-Durchsetzung auf interne Benutzer, Ressourcen und KI-Agenten ausgeweitet. Skyhigh „ Private Access “ vermittelt weiterhin den Fernzugriff über die Skyhigh-Präsenzpunkte, und beide Lösungen werden gemeinsam mit SWG, CASB und DLP über eine einzige Konsole und Policy-Engine verwaltet.

Quellen

1. NIST. SP 800-207: Zero-Trust-Architektur (August 2020). https://csrc.nist.gov/pubs/sp/800/207/final
2. NIST NCCoE. SP 1800-35: Implementierung einer Zero-Trust-Architektur (Juni 2025). https://csrc.nist.gov/pubs/sp/1800/35/final
3. CISA. Zero-Trust-Reifegradmodell, Version 2.0. https://www.cisa.gov/zero-trust-maturity-model
4. Skyhigh Security. „So funktioniert Skyhigh Private Access .“ https://success.skyhighsecurity.com/docs/how-skyhigh-private-access-works
5. Skyhigh Security. „Modernisierung Ihrer Symantec Edge- Secure Web Gateway s mit Skyhigh Hybrid SSE Mesh“ (15. Juli 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html