Zero Trust, ZTNA, SSE und SASE gehören inzwischen zum festen Vokabular moderner IT-Sicherheitsstrategien. Unternehmen sollen klassische VPN-Strukturen ablösen, Zugriffe stärker kontrollieren und interne Systeme nicht länger pauschal für entfernte Benutzer erreichbar machen. Der grundsätzliche Gedanke ist richtig: Ein Benutzer sollte nicht deshalb Zugang zu einem Netzwerk erhalten, nur weil er eine einzelne Anwendung benötigt.
Mit Plattformen wie Zscaler lässt sich dieser Ansatz umfassend umsetzen. Zscaler bietet dafür eine weitreichende Cloud-Security- und Zero-Trust-Plattform, die insbesondere für große, verteilte und international aufgestellte Organisationen interessant ist.
Doch nicht jedes Unternehmen benötigt eine komplette Security-Plattform.
Gerade kleine und mittelständische Unternehmen stehen häufig vor einer wesentlich konkreteren Aufgabe: Ein Mitarbeiter soll von unterwegs auf einen Windows-Arbeitsplatz zugreifen. Ein Administrator benötigt SSH-Zugang zu einem Linux-System. Ein externer Dienstleister muss eine bestimmte Anwendung erreichen. Ein Maschinenbauer möchte einem Servicetechniker kontrollierten Zugriff auf ein Kundensystem ermöglichen.
Für solche Szenarien stellt sich eine andere Frage:
Wie viel Security-Plattform braucht ein sicherer Fernzugriff tatsächlich?
Genau hier unterscheiden sich Zscaler und Kyvion Secure Access grundlegend.
Zscaler und Kyvion Secure Access lösen nicht dasselbe Problem
Ein direkter Funktionsvergleich zwischen Zscaler und Kyvion Secure Access würde zu kurz greifen. Beide Lösungen verfolgen unterschiedliche Ziele.
Zscaler ist als umfassende Cloud-Security-Plattform konzipiert. Unternehmen können darüber Zugriffe auf Internet-, SaaS-, Cloud- und private Anwendungen kontrollieren und umfangreiche Sicherheitsrichtlinien innerhalb einer Zero-Trust-Architektur umsetzen. Besonders in großen Organisationen mit vielen Standorten, mobilen Mitarbeitern und komplexen Sicherheitsanforderungen kann ein solcher Plattformansatz sinnvoll sein.
Kyvion Secure Access verfolgt dagegen einen fokussierten Ansatz.
Die zentrale Aufgabe lautet:
Benutzer sicher und kontrolliert mit einer benötigten internen Ressource verbinden – ohne ihnen dafür einen klassischen Netzwerkzugang bereitstellen zu müssen.
Dabei können beispielsweise RDP-, SSH-, VNC-, Telnet- sowie interne HTTP- und HTTPS-Ressourcen über einen Browser erreichbar gemacht werden.
Der Benutzer benötigt damit nicht zwangsläufig einen klassischen VPN-Zugang zum Zielnetzwerk. Er arbeitet über den Browser mit der für ihn freigegebenen Ressource.
Das klingt zunächst nach einem kleineren Ansatz.
Und genau darin kann der Vorteil liegen.
Warum ein VPN häufig mehr Zugriff gewährt als notwendig
Das klassische VPN löst seit Jahrzehnten ein grundsätzliches Problem: Ein entfernter Benutzer wird mit einem internen Netzwerk verbunden.
Aus heutiger Security-Sicht ist genau das jedoch häufig zu viel.
Ein externer IT-Dienstleister, der lediglich einen Server administrieren soll, benötigt nicht zwangsläufig eine Netzwerkverbindung. Er benötigt eine SSH- oder RDP-Sitzung.
Ein Mitarbeiter, der eine interne Anwendung verwendet, benötigt nicht das Netzwerk. Er benötigt die Anwendung.
Ein Maschinenhersteller, der eine Anlage beim Kunden warten möchte, benötigt ebenfalls nicht zwangsläufig Zugang zum Kundennetzwerk. Der Techniker benötigt Zugriff auf ein bestimmtes Zielsystem.
Der entscheidende Perspektivwechsel lautet deshalb:
Nicht den Benutzer mit dem Netzwerk verbinden, sondern den Benutzer mit der benötigten Ressource.
Genau diese Idee steckt sowohl hinter modernen Zero-Trust-Konzepten als auch hinter Kyvion Secure Access. Die technische Umsetzung und der Umfang der dafür benötigten Infrastruktur unterscheiden sich jedoch erheblich.
Zero Trust muss nicht automatisch ein Großprojekt sein
Zero Trust wird häufig mit umfangreichen Architekturprojekten verbunden. Identity Provider, Endpoint-Komponenten, Policy Engines, Cloud-Dienste, Connectoren und Security-Plattformen werden miteinander kombiniert.
Für große Unternehmen kann dieser Aufwand gerechtfertigt sein.
Für ein Unternehmen mit 30, 100 oder 300 Mitarbeitern kann daraus jedoch schnell ein Missverhältnis zwischen eigentlichem Problem und eingesetzter Lösung entstehen.
Wenn fünf externe Mitarbeiter auf einen Terminalserver zugreifen sollen, muss dafür wirklich eine umfassende SASE-Architektur eingeführt werden?
Wenn ein Dienstleister gelegentlich einen Server administriert, benötigt das Unternehmen dafür eine unternehmensweite Zero-Trust-Transformation?
Und wenn ein Maschinenbauer seinen Servicetechnikern kontrollierten Zugriff auf einige Kundensysteme ermöglichen möchte, muss daraus zwangsläufig ein komplexes Security-Projekt werden?
Nicht unbedingt.
Kyvion Secure Access setzt genau an dieser Stelle an.
Secure Access statt Security-Großprojekt
Kyvion Secure Access kann als zentrale Zugriffsschicht zwischen Benutzer und Zielsystem eingesetzt werden.
Vereinfacht dargestellt entsteht folgende Struktur:
Benutzer → Browser → Kyvion Secure Access → Zielsystem
Das Ziel kann beispielsweise ein Windows-System über RDP, ein Linux-Server über SSH, eine interne Webanwendung über HTTPS oder ein anderes unterstütztes System sein.
Der entscheidende Unterschied zum klassischen VPN: Der Benutzer wird nicht einfach Teil des entfernten Netzwerks.
Er erhält Zugriff auf die Ressource, für die er autorisiert wurde.
Damit lässt sich das Prinzip der minimal notwendigen Berechtigung wesentlich konsequenter auf Remote-Zugriffe übertragen.
Der Browser wird zum sicheren Zugangspunkt
Ein weiterer Unterschied liegt auf dem Endgerät.
Viele Remote-Access- und ZTNA-Konzepte benötigen zusätzliche Software, Clients oder Agenten auf den Geräten der Benutzer. Das kann sinnvoll sein, insbesondere wenn Geräte umfassend bewertet und in eine zentrale Endpoint-Security-Strategie eingebunden werden sollen.
Es erhöht jedoch gleichzeitig den administrativen Aufwand.
Kyvion Secure Access verfolgt für den eigentlichen Benutzerzugriff einen anderen Ansatz: Der Browser wird zum Zugangspunkt.
Dadurch können Benutzer von unterschiedlichen Endgeräten auf freigegebene Ressourcen zugreifen, ohne dass für jedes unterstützte Zielprotokoll ein entsprechender nativer Client bereitgestellt werden muss.
RDP bleibt beispielsweise innerhalb der Zugriffskette – aber der Benutzer benötigt nicht zwingend einen lokalen RDP-Client.
Dasselbe Prinzip lässt sich auf SSH übertragen.
Gerade bei externen Mitarbeitern, Administratoren, Supportorganisationen oder wechselnden Dienstleistern kann dies die Bereitstellung erheblich vereinfachen.
Reverse Agent: Zugriff ermöglichen, ohne das Zielnetz nach außen zu öffnen
Besonders interessant wird dieser Ansatz bei abgeschotteten Netzwerken.
Mit dem Kyvion Reverse Agent kann innerhalb eines geschützten Netzsegments eine Verbindung zum Secure-Access-Gateway aufgebaut werden. Der Verbindungsaufbau erfolgt dabei aus dem geschützten Netzwerk heraus.
Damit muss für den entsprechenden Zugriff nicht einfach ein eingehender Port aus dem Internet zum Zielsystem geöffnet werden.
Die Architektur lässt sich vereinfacht so darstellen:
Browser → Kyvion Secure Access → Reverse Agent → internes Zielsystem
Der Reverse Agent kann damit insbesondere dort interessant sein, wo sensible Systeme nicht direkt von außen erreichbar sein sollen.
Das betrifft beispielsweise administrative Netze, Produktionsumgebungen, Kundensysteme, interne Server oder besonders schützenswerte Tier-0- und Tier-1-Ressourcen.
Externe Dienstleister zeigen den Unterschied besonders deutlich
Ein typisches Beispiel ist der externe IT-Dienstleister.
Traditionell erhält dieser häufig einen VPN-Account. Nach erfolgreicher Verbindung befindet sich sein Gerät zumindest technisch innerhalb eines definierten Netzwerkbereichs. Firewalls und weitere Regeln müssen anschließend dafür sorgen, dass der Dienstleister ausschließlich die tatsächlich benötigten Systeme erreicht.
Man kann das Problem jedoch auch anders lösen.
Wenn der Techniker ausschließlich eine RDP-Sitzung zu Server A benötigt, warum sollte man ihm überhaupt einen allgemeinen Netzwerkzugang bereitstellen?
Mit Kyvion Secure Access kann der Zugang auf die benötigte Ressource konzentriert werden.
Der Dienstleister meldet sich am Secure-Access-System an, wählt die für ihn freigegebene Verbindung und arbeitet über den Browser mit dem Zielsystem.
Je nach eingesetzter Konfiguration können darüber hinaus Sitzungen aufgezeichnet und Zugänge organisatorisch stärker von den eigentlichen Systemkonten getrennt werden.
Damit nähert sich Secure Access in entsprechenden Szenarien auch Anforderungen an privilegierte Zugriffe an, ohne zwangsläufig eine vollständige Enterprise-PAM-Plattform vorauszusetzen.
Weniger Komponenten können auch weniger Angriffsfläche bedeuten
In der IT-Sicherheit hält sich hartnäckig die Vorstellung, dass mehr Security-Produkte automatisch mehr Sicherheit erzeugen.
Das stimmt nicht zwangsläufig.
Jede zusätzliche Komponente muss installiert, konfiguriert, aktualisiert und überwacht werden. Schnittstellen müssen funktionieren. Richtlinien müssen gepflegt werden. Administratoren müssen verstehen, welche Komponente welche Entscheidung trifft.
Komplexität ist deshalb selbst ein Sicherheitsfaktor.
Eine falsch konfigurierte Enterprise-Security-Plattform ist nicht automatisch sicherer als eine kleinere Architektur, deren Funktionsweise vollständig verstanden und sauber administriert wird.
Gerade für kleinere IT-Abteilungen kann deshalb ein fokussierter Ansatz sinnvoll sein.
Die entscheidende Frage sollte nicht lauten:
Welche Lösung bietet die meisten Funktionen?
Sondern:
Welche Funktionen benötigen wir tatsächlich, um unser konkretes Risiko zu reduzieren?
Wann Zscaler die richtige Entscheidung sein kann
Eine faire Betrachtung muss auch klar sagen: Es gibt zahlreiche Szenarien, in denen eine umfassende Plattform wie Zscaler sinnvoller ist.
Große Unternehmen mit tausenden Mitarbeitern, vielen internationalen Standorten, umfangreichen SaaS-Strukturen, komplexen Zugriffsrichtlinien und einer unternehmensweiten SSE- oder SASE-Strategie benötigen andere Werkzeuge als ein mittelständischer Betrieb mit einer überschaubaren IT-Infrastruktur.
Wer Internetzugriffe, Cloud-Anwendungen, private Anwendungen und zahlreiche weitere Security-Funktionen innerhalb einer strategischen Plattform zusammenführen möchte, sollte eine entsprechende Enterprise-Lösung evaluieren.
Kyvion Secure Access versucht nicht, diese Plattform vollständig zu ersetzen.
Das wäre auch nicht sinnvoll.
Wann Kyvion Secure Access interessant wird
Interessant wird Kyvion Secure Access immer dann, wenn die Aufgabenstellung wesentlich konkreter ist:
Ein Unternehmen möchte interne Anwendungen sicher über den Browser bereitstellen.
Administratoren sollen per RDP oder SSH auf bestimmte Systeme zugreifen.
Externe Dienstleister benötigen kontrollierte Zugänge.
Ein Maschinenbauer möchte Remote-Service ermöglichen, ohne den Technikern pauschalen VPN-Zugang zum Kundennetz zu geben.
Eine Organisation möchte den direkten externen Zugriff auf besonders sensible Systeme reduzieren.
Oder ein Unternehmen sucht schlicht nach einer Möglichkeit, klassischen VPN-Zugriff für bestimmte Anwendungsfälle durch einen ressourcenbezogenen Zugriff zu ersetzen.
Dann kann ein fokussierter Secure-Access-Ansatz erheblich einfacher sein als die Einführung einer umfassenden Security-Plattform.
Die entscheidende Frage lautet nicht Zscaler oder Kyvion
Zscaler und Kyvion Secure Access stehen deshalb nicht zwangsläufig vor derselben Aufgabenstellung.
Die wichtigere Entscheidung lautet:
Benötigen wir eine umfassende Security-Plattform – oder benötigen wir einen sicheren Zugang zu unseren internen Ressourcen?
Wer eine globale Zero-Trust-, SSE- oder SASE-Strategie umsetzen möchte, wird andere Anforderungen stellen als ein Unternehmen, das RDP, SSH oder interne Anwendungen kontrolliert für Mitarbeiter und Dienstleister bereitstellen möchte.
Und genau deshalb kann weniger manchmal mehr sein.
Weniger Komponenten.
Weniger Client-Software.
Weniger Netzwerkfreigaben.
Weniger administrativer Aufwand.
Und vor allem: weniger Zugriff, als der Benutzer tatsächlich benötigt.
Denn gute IT-Sicherheit beginnt nicht mit möglichst vielen Funktionen.
Sie beginnt mit einer einfachen Frage:
Wer darf auf welche Ressource zugreifen – und warum sollte er Zugriff auf irgendetwas anderes bekommen?
