Remote Desktop und SSH gehören zu den wichtigsten Werkzeugen für die Administration von IT-Systemen. Windows-Server werden per RDP verwaltet, Linux-Systeme per SSH, externe Dienstleister benötigen Zugriff für Wartungsarbeiten und Administratoren müssen auch von außerhalb des Unternehmens auf Systeme zugreifen können. Problematisch wird es jedoch, wenn für diesen Zugriff RDP-Port 3389 oder SSH-Port 22 direkt aus dem Internet erreichbar gemacht werden.
Die naheliegende Alternative lautet häufig VPN. Doch auch ein VPN ist nicht zwangsläufig die einzige Möglichkeit, RDP und SSH sicher von außen bereitzustellen. Moderne Zugriffskonzepte können vollständig darauf verzichten, die eigentlichen Zielsysteme über eingehende Portfreigaben erreichbar zu machen.
Das eigentliche Problem ist die Erreichbarkeit
Ein RDP- oder SSH-Dienst kann technisch sauber konfiguriert, aktuell gepatcht und mit starken Passwörtern geschützt sein. Sobald er aus dem Internet erreichbar ist, existiert dennoch eine öffentlich sichtbare Angriffsfläche. Automatisierte Scanner suchen permanent nach erreichbaren Diensten und versuchen anschließend, Informationen über Systeme und Zugangsmöglichkeiten zu gewinnen.
Die entscheidende Frage lautet deshalb nicht nur, wie gut ein RDP- oder SSH-Zugang abgesichert ist. Viel interessanter ist, ob der Dienst überhaupt direkt aus dem Internet erreichbar sein muss.
In vielen Umgebungen lautet die Antwort: nein.
Anstatt den Zugriff auf das Zielsystem freizugeben, kann eine kontrollierte Zugriffsebene zwischen Internet und interner Infrastruktur geschaltet werden. Der Anwender verbindet sich dann nicht direkt mit dem Windows- oder Linux-System. Erst die Zugriffslösung stellt innerhalb der geschützten Umgebung die eigentliche RDP- oder SSH-Verbindung her.
Keine Portfreigabe zum eigentlichen Zielsystem
Genau hier unterscheidet sich ein solcher Ansatz von der klassischen Portweiterleitung. Der interne Server muss weder über Port 3389 noch über Port 22 aus dem Internet erreichbar sein. Firewall-Regeln können eingehende Verbindungen zu diesen Systemen vollständig unterbinden.
Für einen Angreifer von außen gibt es damit keinen unmittelbar erreichbaren RDP- oder SSH-Dienst mehr, den er scannen oder direkt angreifen könnte.
Das verändert die Sicherheitsarchitektur grundlegend. Statt zahlreiche interne Systeme nach außen erreichbar zu machen, wird der externe Zugriff an einer definierten Stelle zusammengeführt. Dort können Authentifizierung, Berechtigungen und Zugriffsregeln zentral durchgesetzt werden.
RDP und SSH direkt im Browser
Mit Kyvion Secure Access lässt sich dieses Prinzip noch weiterführen. Benutzer benötigen auf ihrem Arbeitsplatz keinen RDP- oder SSH-Client. Der Zugriff erfolgt über einen aktuellen Webbrowser.
Nach erfolgreicher Anmeldung wird die Verbindung zum freigegebenen Zielsystem innerhalb der Infrastruktur hergestellt. RDP, SSH und weitere unterstützte Protokolle werden dabei über den Browser bereitgestellt. Auf dem Endgerät muss keine zusätzliche Zugriffssoftware installiert werden.
Das ist insbesondere für externe Administratoren, Dienstleister, Homeoffice-Arbeitsplätze oder wechselnde Endgeräte interessant. Statt einem Benutzer zunächst Netzwerkzugriff zu gewähren, erhält er Zugriff auf genau die Systeme und Anwendungen, die für seine Aufgabe vorgesehen sind.
Der Unterschied ist erheblich: Nicht das interne Netzwerk wird für den Benutzer geöffnet, sondern eine definierte Ressource wird kontrolliert bereitgestellt.
Auch Systeme hinter NAT müssen nicht geöffnet werden
Eine weitere Herausforderung entsteht bei Servern und Geräten in abgeschotteten Netzen, Außenstellen oder besonders geschützten Netzwerksegmenten. Klassische Fernzugriffslösungen führen hier schnell zu zusätzlichen Firewall-Regeln und Portfreigaben.
Kyvion Secure Access kann solche Umgebungen über den ReverseAgent anbinden. Die Verbindung wird dabei aus dem geschützten Netzwerk heraus aufgebaut. Eine eingehende Verbindung aus dem Internet zum Zielnetz ist nicht erforderlich.
Das ist beispielsweise für administrative Netze, Serversegmente oder besonders schützenswerte Systeme interessant. Ein SSH-Server kann intern ausschließlich erreichbar bleiben und trotzdem für einen autorisierten Administrator kontrolliert zur Verfügung gestellt werden.
Weniger Netzwerkzugriff bedeutet mehr Kontrolle
Bei einem klassischen VPN erhält ein Benutzer zunächst eine Verbindung zum Unternehmensnetz. Was er anschließend erreichen kann, muss über Firewall-Regeln, Routing, Netzwerksegmentierung und weitere Sicherheitsmechanismen eingeschränkt werden.
Bei einem ressourcenorientierten Zugriff lässt sich dieses Prinzip umdrehen. Ein Administrator benötigt beispielsweise keinen allgemeinen Zugang zum Servernetz, wenn seine Aufgabe lediglich darin besteht, einen bestimmten Linux-Server per SSH zu administrieren. Ein externer Dienstleister benötigt keinen Zugriff auf ein komplettes Subnetz, wenn er ausschließlich eine bestimmte Windows-Maschine per RDP warten soll.
Die Berechtigung kann deshalb wesentlich näher an der tatsächlichen Aufgabe vergeben werden.
Gerade bei privilegierten Zugriffen ist das ein wichtiger Unterschied. Je weniger Systeme ein Benutzer technisch erreichen kann, desto kleiner wird auch der mögliche Bewegungsraum bei kompromittierten Zugangsdaten oder einem kompromittierten Endgerät.
MFA schützt die zentrale Eingangstür
Wer direkte RDP- und SSH-Zugänge durch eine zentrale Zugriffslösung ersetzt, kann auch die Authentifizierung an einer Stelle bündeln. Multi-Faktor-Authentifizierung und vorhandene Identity-Systeme können in den Anmeldeprozess integriert werden.
Damit muss die Sicherheit nicht mehr für jeden einzelnen extern erreichbaren Server separat umgesetzt werden.
Allerdings sollte MFA nicht mit vollständiger Sicherheit gleichgesetzt werden. Eine starke Authentifizierung beantwortet zunächst nur die Frage, wer sich anmeldet. Ebenso wichtig ist, auf welche Systeme dieser Benutzer anschließend zugreifen darf und was während einer privilegierten Sitzung geschieht.
Genau an diesem Punkt beginnt der Übergang vom einfachen Remote Access zu einem modernen Privileged-Access-Konzept.
Administratoren und Dienstleister gezielt absichern
Besonders interessant ist der Ansatz deshalb für privilegierte Zugriffe. Administratoren, Softwareanbieter und externe IT-Dienstleister benötigen häufig weitreichende Berechtigungen. Gleichzeitig sollten gerade diese Zugänge möglichst eng kontrolliert werden.
Kyvion Secure Access kann solche Verbindungen zentral bereitstellen und Sitzungen nachvollziehbar machen. Je nach Konfiguration lassen sich privilegierte Zugriffe klar von normalen Benutzerzugriffen trennen und Sitzungen aufzeichnen.
Damit wird aus einem technisch notwendigen Fernzugriff ein kontrollierbarer administrativer Prozess.
Ein externer Techniker benötigt dann beispielsweise keinen VPN-Zugang zum Kundennetz und keinen direkt erreichbaren RDP-Port. Er meldet sich am zentralen Zugang an und erhält ausschließlich die für ihn freigegebene RDP-Sitzung. Nach Beendigung seiner Tätigkeit besteht kein allgemeiner Netzwerkzugriff, der zusätzlich berücksichtigt werden müsste.
Keine Cloud ist für sicheren Fernzugriff zwingend erforderlich
Browserbasierter Zugriff wird häufig automatisch mit einem externen Cloud-Dienst verbunden. Technisch ist das jedoch nicht notwendig.
Kyvion Secure Access kann innerhalb der eigenen beziehungsweise kontrollierten Infrastruktur betrieben werden. Die Verbindung zwischen Benutzer und Zielsystem muss damit nicht über einen fremden Remote-Access-Dienst vermittelt werden.
Das ist insbesondere für Unternehmen interessant, die Wert auf Datensouveränität legen oder administrative Zugriffe bewusst innerhalb ihrer eigenen Sicherheitsarchitektur halten möchten.
Die vorhandene Firewall, Netzwerksegmentierung, Identitätsverwaltung und interne Serverstruktur bleiben bestehen. Kyvion Secure Access ergänzt diese Infrastruktur um eine kontrollierte Zugriffsebene, anstatt die komplette Umgebung durch eine neue Cloud-Plattform zu ersetzen.
Der sicherste offene RDP-Port ist häufig gar kein offener RDP-Port
RDP und SSH sind nicht grundsätzlich unsichere Protokolle. Das Risiko entsteht vor allem dadurch, wie sie bereitgestellt und wer darauf zugreifen kann.
Deshalb sollte bei einem neuen Fernzugriff nicht zuerst gefragt werden, wie Port 3389 oder Port 22 möglichst sicher aus dem Internet veröffentlicht werden kann. Die bessere Frage lautet, ob diese Ports überhaupt öffentlich erreichbar sein müssen.
Mit einem zentralen, browserbasierten Zugriff können RDP- und SSH-Systeme innerhalb des geschützten Netzwerks bleiben. Benutzer erhalten trotzdem von praktisch jedem geeigneten Endgerät Zugriff auf die benötigten Ressourcen – ohne direkten Netzwerkzugriff, ohne RDP- oder SSH-Portfreigabe zum Zielsystem und auf Wunsch ohne klassische VPN-Verbindung.
Damit wird Fernzugriff nicht nur komfortabler. Vor allem wird aus einem offenen Netzwerkzugang ein gezielt kontrollierter Zugriff auf einzelne Systeme.
