9. August 2026

ZTNA ohne Cloud – Zero Trust funktioniert auch im eigenen Rechenzentrum

Zero Trust gehört inzwischen zu den wichtigsten Konzepten moderner IT-Sicherheit. Die Grundidee ist einfach: Ein Benutzer oder Gerät erhält nicht deshalb Vertrauen, weil es sich innerhalb eines bestimmten Netzwerks befindet. Jeder Zugriff muss kontrolliert, authentifiziert und möglichst genau auf die tatsächlich benötigten Ressourcen beschränkt werden. In der Praxis wird Zero Trust Network Access, kurz ZTNA, jedoch häufig mit einer weiteren Entscheidung verbunden: dem Wechsel zu einer Cloud-basierten Security-Plattform.

Doch Zero Trust bedeutet nicht automatisch Cloud.

Unternehmen können zentrale Zero-Trust-Prinzipien auch in der eigenen Infrastruktur, im eigenen Rechenzentrum oder in einer Private Cloud umsetzen. Gerade für kleine und mittelständische Unternehmen, Kommunen, Kanzleien, Industrieunternehmen oder Organisationen mit besonders sensiblen Daten kann das eine interessante Alternative sein. Denn nicht jedes Unternehmen möchte seinen gesamten Remote-Zugriff über die Infrastruktur eines externen Cloud-Anbieters führen.

ZTNA ist ein Sicherheitsprinzip – kein Cloud-Betriebsmodell

Der Begriff ZTNA wird heute häufig gemeinsam mit SASE, SSE und großen Cloud-Security-Plattformen verwendet. Dadurch entsteht schnell der Eindruck, Zero Trust müsse zwangsläufig als Cloud-Service eingekauft werden.

Technisch sind das jedoch zwei unterschiedliche Fragen.

Zero Trust beschreibt zunächst, wie Zugriff gewährt wird. Cloud oder On-Premises beschreibt dagegen, wo die dafür benötigte Infrastruktur betrieben wird.

Genau diese Trennung ist wichtig. Ein Unternehmen kann seine Anwendungen und Server weiterhin im eigenen Rechenzentrum betreiben und trotzdem verhindern, dass externe Benutzer oder Mitarbeiter einen weitreichenden Netzwerkzugriff erhalten. Statt ein komplettes Netzwerk verfügbar zu machen, wird nur der tatsächlich benötigte Dienst bereitgestellt.

Damit verändert sich die grundsätzliche Architektur des Fernzugriffs.

Das Problem des klassischen VPN

Ein VPN baut typischerweise einen verschlüsselten Tunnel zwischen einem Endgerät und einem Unternehmensnetzwerk auf. Das ist technisch bewährt, führt aber zu einer grundsätzlichen Herausforderung: Der entfernte Arbeitsplatz wird zumindest teilweise mit dem internen Netzwerk verbunden.

Anschließend müssen Firewall-Regeln, Netzwerksegmente, Routing und Berechtigungen dafür sorgen, dass der Benutzer nur auf diejenigen Systeme zugreifen kann, die er tatsächlich benötigt.

Zero Trust dreht diesen Ansatz um.

Die zentrale Frage lautet nicht mehr: „In welches Netzwerk darf dieser Benutzer?“

Sie lautet vielmehr: „Auf welche Anwendung oder welches System darf dieser Benutzer zugreifen?“

Dieser kleine Unterschied verändert die Sicherheitsarchitektur erheblich.

Ein Servicetechniker benötigt beispielsweise vielleicht lediglich Zugriff auf eine bestimmte Maschine. Ein externer IT-Dienstleister muss ausschließlich einen administrativen Server erreichen. Ein Mitarbeiter im Homeoffice benötigt eine bestimmte Windows-Anwendung. Ein Administrator braucht SSH-Zugriff auf einen Linux-Server.

Warum sollte man diesen Benutzern dafür ein Netzwerk zur Verfügung stellen?

ZTNA ohne Cloud setzt genau hier an

Ein Zero-Trust-orientierter Remote-Zugriff kann auch ohne zentrale Security-Cloud umgesetzt werden. Anwendungen und Systeme bleiben dort, wo sie bereits betrieben werden. Gleichzeitig wird der Zugriff davor kontrolliert und auf konkrete Ressourcen beschränkt.

Genau an dieser Stelle setzt Kyvion Secure Access an.

Kyvion Secure Access ermöglicht den browserbasierten Zugriff auf interne Systeme und Anwendungen. Unterstützt werden unter anderem RDP, SSH, VNC, Telnet sowie HTTP- und HTTPS-Anwendungen. Auf dem Arbeitsplatz muss dafür kein spezieller Remote-Access-Client installiert werden.

Der Browser wird zum kontrollierten Zugangspunkt.

Ein Benutzer erhält damit nicht zwangsläufig Zugriff auf ein internes Netzwerk, sondern auf die für ihn freigegebene Ressource. Das kann beispielsweise ein Windows-Desktop, ein Server, eine interne Webanwendung, eine Managementoberfläche oder ein administratives System sein.

Der Unterschied zum klassischen VPN ist entscheidend: Die Anwendung kommt zum Benutzer – nicht das Unternehmensnetzwerk.

Zero Trust ohne Infrastrukturverlagerung

Für viele Unternehmen ist genau dieser Punkt interessant. Eine moderne Zugriffssicherheit sollte nicht automatisch bedeuten, bestehende Anwendungen umzubauen oder komplette Infrastrukturen zu einem Cloud-Anbieter zu verlagern.

Gerade im Mittelstand existieren zahlreiche Anwendungen, die weiterhin lokal betrieben werden. ERP-Systeme, Produktionssoftware, Branchenlösungen, Terminalserver, Managementsysteme, Linux-Server oder ältere Fachanwendungen verschwinden nicht deshalb, weil moderne Security-Konzepte zunehmend aus der Cloud angeboten werden.

Diese Systeme müssen trotzdem sicher erreichbar sein.

Kyvion Secure Access kann dabei als kontrollierte Zugriffsebene vor bestehenden Systemen eingesetzt werden. Die eigentliche Anwendung muss dafür nicht zwangsläufig verändert werden. Auch auf dem Zielsystem ist für den browserbasierten Zugriff keine klassische Remote-Access-Clientinstallation erforderlich.

Damit lässt sich moderne Zugriffssicherheit mit vorhandener Infrastruktur verbinden.

Der Browser ersetzt den Netzwerkzugang

Dieser Ansatz verändert auch die Rolle des Endgeräts.

Bei klassischen Remote-Access-Konzepten muss das Notebook oder der PC häufig zunächst technisch in die Zugriffsinfrastruktur integriert werden. VPN-Clients, ZTNA-Agenten, Zertifikate oder zusätzliche Softwarekomponenten können erforderlich sein.

Bei einem browserbasierten Ansatz ist die Trennung deutlicher.

Der Browser stellt die Benutzeroberfläche bereit, während Kyvion Secure Access die Verbindung zum freigegebenen Zielsystem vermittelt. Der Benutzer arbeitet beispielsweise per RDP oder SSH, ohne dass das entsprechende Protokoll direkt vom Arbeitsplatz bis zum Zielsystem durchgereicht werden muss.

Das reduziert die unmittelbare Netzwerkexposition und schafft eine klare Grenze zwischen Benutzergerät und interner Infrastruktur.

Besonders interessant für externe Dienstleister

Ein typisches Beispiel sind externe Administratoren, Hersteller oder Servicetechniker.

Viele Unternehmen stehen vor einem unangenehmen Problem: Ein Dienstleister benötigt Zugriff auf ein internes System, soll aber selbstverständlich keinen allgemeinen Zugang zum Unternehmensnetzwerk erhalten.

Mit klassischen VPN-Konzepten muss diese Trennung anschließend über Netzwerke, Firewall-Regeln und Berechtigungen umgesetzt werden.

Ein anwendungsbezogener Zugriff verfolgt einen anderen Ansatz.

Der Dienstleister authentifiziert sich am Secure-Access-System und erhält ausschließlich die für ihn freigegebene Verbindung. Dadurch kann beispielsweise nur eine bestimmte RDP-Sitzung oder ein bestimmter SSH-Zugang bereitgestellt werden.

Der Zugang wird damit vom Netzwerk entkoppelt.

Gerade bei privilegierten Zugriffen ist das interessant, weil sich Remote Access und Elemente eines Privileged-Access-Konzepts miteinander verbinden lassen. Sitzungen können kontrolliert und – abhängig von der Konfiguration – aufgezeichnet werden. Zudem können Benutzerzugänge von den eigentlichen Systemkonten getrennt werden.

Der externe Benutzer muss damit nicht zwangsläufig die Zugangsdaten des Zielsystems kennen.

Auch geschützte Netze müssen nicht geöffnet werden

Besonders interessant wird dieser Ansatz bei stark abgeschotteten Netzwerkbereichen.

Mit dem Reverse Agent von Kyvion Secure Access kann die Kommunikation aus einem geschützten Netzwerk heraus aufgebaut werden. Dadurch muss für den Zugriff nicht zwangsläufig eine eingehende Verbindung aus dem Internet in dieses Netzwerk freigeschaltet werden.

Der Reverse Agent initiiert die Verbindung nach außen zum Secure-Access-Gateway.

Das Prinzip eignet sich beispielsweise für besonders geschützte administrative Bereiche, Produktionsnetze, Maschinenzugänge oder andere Netzwerksegmente, bei denen eingehende Verbindungen möglichst vermieden werden sollen.

Damit lässt sich eine weitere wichtige Zero-Trust-Idee praktisch umsetzen: Systeme werden nicht allgemein erreichbar gemacht, sondern Zugriffe werden über eine definierte und kontrollierbare Verbindung vermittelt.

Zero Trust muss nicht kompliziert sein

Eine der größten Herausforderungen moderner Security-Architekturen ist ihre zunehmende Komplexität.

SASE, SSE, ZTNA, CASB, SWG, DLP und zahlreiche weitere Komponenten können technisch sinnvoll sein. Für einen internationalen Konzern mit zehntausenden Benutzern kann eine umfassende Cloud-Security-Plattform deshalb genau die richtige Lösung darstellen.

Aber nicht jedes Unternehmen ist ein internationaler Konzern.

Ein mittelständischer Maschinenbauer mit 150 Mitarbeitern hat möglicherweise ein wesentlich konkreteres Problem: Zehn Servicetechniker müssen von außen auf bestimmte Systeme zugreifen.

Eine Kommune möchte externen Administratoren kontrollierten Zugriff ermöglichen.

Eine Kanzlei möchte Mitarbeitern einen sicheren Zugang zu einer internen Fachanwendung bereitstellen.

Ein IT-Dienstleister möchte mehrere Kundensysteme erreichen, ohne dafür eine Sammlung unterschiedlicher VPN-Clients verwalten zu müssen.

Für solche Szenarien kann eine kleinere, klar definierte Zugriffslösung sinnvoller sein als der Aufbau einer umfassenden Cloud-Security-Architektur.

On-Premises ist kein Widerspruch zu Zero Trust

Cloud-Dienste sind ein wichtiger Bestandteil moderner IT-Infrastrukturen. Trotzdem gibt es gute Gründe, bestimmte Systeme weiterhin selbst zu betreiben.

Datensouveränität, regulatorische Anforderungen, vorhandene Infrastruktur, spezielle Anwendungen oder schlicht wirtschaftliche Überlegungen können dafür sprechen.

Zero Trust verlangt nicht, diese Systeme abzuschaffen.

Im Gegenteil: Gerade vorhandene On-Premises-Systeme benötigen moderne Zugriffskonzepte.

Deshalb sollte die Diskussion nicht „Cloud oder Zero Trust?“ lauten. Die entscheidende Frage ist vielmehr, wie sich vorhandene Anwendungen so bereitstellen lassen, dass Benutzer möglichst genau die Ressourcen erhalten, die sie tatsächlich benötigen – und nicht automatisch Zugang zu einem ganzen Netzwerk.

Kyvion Secure Access: Zero-Trust-Prinzipien ohne Cloud-Zwang

Kyvion Secure Access versteht sich dabei nicht als Ersatz für jede Funktion einer großen ZTNA-, SSE- oder SASE-Plattform. Unternehmen, die beispielsweise umfassende Device-Posture-Prüfungen, weltweite Cloud-PoPs, Secure Web Gateways oder komplexe Cloud-Security-Policies benötigen, haben andere Anforderungen.

Für viele Unternehmen besteht die eigentliche Aufgabe jedoch an einer wesentlich konkreteren Stelle: Interne Systeme müssen sicher von außen erreichbar sein, ohne dafür unnötig Netzwerke zu öffnen oder jedem Benutzer einen klassischen VPN-Zugang bereitzustellen.

Genau dafür bietet Kyvion Secure Access einen pragmatischen Ansatz.

Die Lösung kann in der eigenen Infrastruktur, im Rechenzentrum, auf virtuellen Maschinen, physischen Systemen oder in containerisierten Umgebungen betrieben und in bestehende IT-Landschaften integriert werden. Der Zugriff erfolgt über den Browser und kann gezielt auf die benötigten Systeme und Anwendungen begrenzt werden.

Damit entsteht eine Alternative zwischen zwei Extremen: dem klassischen Netzwerkzugang per VPN auf der einen und einer umfassenden Cloud-Security-Plattform auf der anderen Seite.

Zero Trust beginnt nicht in der Cloud – sondern beim Zugriff

Die wichtigste Frage einer modernen Remote-Access-Architektur lautet deshalb nicht, bei welchem Cloud-Anbieter eine Security-Plattform betrieben wird.

Sie lautet:

Wer darf wann auf welches System zugreifen – und warum muss dieser Benutzer dafür überhaupt Zugang zum Netzwerk erhalten?

Wenn sich die zweite Frage mit „muss er eigentlich nicht“ beantworten lässt, lohnt es sich, den klassischen VPN-Ansatz zu überdenken.

Zero Trust kann in der Cloud umgesetzt werden. Es kann aber ebenso vor Anwendungen im eigenen Rechenzentrum beginnen.

ZTNA ohne Cloud ist deshalb kein Widerspruch. Es ist die Rückbesinnung auf die eigentliche Idee von Zero Trust: möglichst wenig Vertrauen, möglichst wenig Netzwerkzugriff und möglichst genau kontrollierte Verbindungen zu den Ressourcen, die tatsächlich benötigt werden.

Mehr erfahren!

Zurück zur Übersicht