Öffentliche Schlüssel reichen für SSH-Sicherheit nicht aus

Wenn Ihre Organisation öffentliche SSH-Schlüssel verwendet, ist es durchaus möglich, dass Sie bereits einen verlegt haben. In einem Backup oder auf dem Computer eines ehemaligen Mitarbeiters kann sich eine Datei befinden, die dem Inhaber Zugriff auf Ihre Infrastruktur gewährt. Wenn Sie SSH-Schlüssel zwischen Mitarbeitern teilen, reichen wahrscheinlich nur wenige Schlüssel aus, um einem Angreifer Zugriff auf Ihr gesamtes System zu gewähren. Wenn Sie sie nicht teilen, ist es wahrscheinlich, dass Ihr Team so viele Schlüssel generiert hat, dass Sie mindestens einen davon schon lange aus den Augen verloren haben.

Wenn ein Angreifer in ein einziges Ihrer Client-Geräte eindringen kann, ist es wahrscheinlich, dass es dort eine known_hosts-Datei gibt, in der jedes Ziel aufgeführt ist, das mit den Schlüsseln, die der Rechner bereits enthält, ganz leicht erreicht werden kann. Wenn jemand in der Lage ist, den Laptop eines Teammitglieds zu kompromittieren, kann er Schlüssel auf dem Gerät verwenden, die keinen Passwortschutz haben, um sensible Ziele zu erreichen.

Sollte dies geschehen – wie würden Sie reagieren und den verlorenen SSH-Schlüssel sperren? Führen Sie Buch über die Schlüssel, die generiert worden sind? Rotieren Sie SSH-Schlüssel? Wie macht man das in einem großen Unternehmen, dessen Hauptanliegen in der Kundenbetreuung besteht und bei dem der Sicherheitsaspekt keine Probleme bereiten darf?

Cloudflare Access startete im vergangenen Jahr Unterstützung für SSH-Verbindungen, damit sich Ihre Teams bei der Verbindung mit der Infrastruktur auf Zero-Trust-Sicherheit verlassen können. Access wird in Ihren IdP integriert, um SSH-Verbindungen mit SSO-Sicherheit zu versehen, indem bei jedem Versuch eines Benutzers, eine Verbindung mit einer Zielressource herzustellen, identitätsbasierte Regeln erzwungen werden.

Sobald Access jedoch Benutzer mit dem Server verbunden hatte, mussten sie sich immer noch auf SSH-Legacyschlüssel verlassen, um ihr Konto zu autorisieren. Ab heute können wir Teams dabei helfen, diese Anforderung zu umgehen und statische SSH-Schlüssel durch kurzlebige Zertifikate zu ersetzen.

In herkömmlichen Netzwerkumkreismodellen sichern Teams ihre Infrastruktur mit zwei Gates: einem privaten Netzwerk und SSH-Schlüsseln.

Das private Netzwerk erfordert, dass sich jeder Benutzer, der versucht, eine Verbindung mit einem Server herzustellen, im selben Netzwerk oder in einem Peer-Äquivalent (z. B. einem VPN) befindet. Das bringt jedoch ein gewisses Risiko mit sich. Private Netzwerke vertrauen standardmäßig darauf, dass ein Benutzer im Netzwerk einen Computer erreichen kann. Administratoren müssen das Netzwerk proaktiv segmentieren oder jeden Teil der Infrastruktur mit Steuerungslisten sichern, um von dieser Standardeinstellung aus rückwärts vorzugehen.

Cloudflare Access sichert die Infrastruktur, indem es aus der anderen Richtung beginnt: Es darf keinem Benutzer vertraut werden. Stattdessen müssen Benutzer standardmäßig nachweisen, dass sie auf einen einzelnen Rechner oder ein einzelnes Ziel zugreifen können.

Wir haben letztes Jahr Unterstützung für SSH-Verbindungen in Cloudflare Access veröffentlicht, um Teams dabei zu helfen, dieses Netzwerkumkreismodell zu verlassen und es durch ein Netzwerk zu ersetzen, das jede Anforderung an einen Server auf Benutzeridentität auswertet. Durch die Integration mit gängigen Identitätsanbietern bietet diese Lösung Teams auch die Möglichkeit, ihre SSO-Pipeline in ihren SSH-Flow einzubringen.

Sobald ein Benutzer über SSH mit einem Server verbunden ist, muss er in der Regel seine Sitzung autorisieren. Der Rechner, den er zu erreichen versucht, verfügt über eine Reihe von Profilen, die aus Benutzer- oder Rollenidentitäten bestehen. Durch diese Profile wird festgelegt, welche Aktionen der Benutzer ausführen kann.

SSH-Prozesse stellen dem Benutzer einige Optionen zur Verfügung, um sich bei einem Profil anzumelden. In einigen Fällen können sich Benutzer mit einer Kombination aus Benutzername und Passwort anmelden. Die meisten Teams verlassen sich für diese Anmeldung jedoch auf Zertifikate mit öffentlich-privaten Schlüsseln. Als Voraussetzung zur Verwendung dieser Methode müssen Administratoren und Benutzer vorweg bestimmte Schritte ausführen.

Vor der Verbindung generiert der Benutzer ein Zertifikat und stellt den öffentlichen Schlüssel einem Administrator zur Verfügung, der dann den Server so konfiguriert, dass er dem Zertifikat vertraut und es einem bestimmten Benutzer und Berechtigungssatz zuordnet. Der Benutzer speichert dieses Zertifikat auf seinem Gerät und präsentiert es während der letzten Etappe. Dies lässt jedoch alle Probleme offen, die SSO zu lösen versucht:

• Die meisten Teams verlangen nie von Benutzern, Zertifikate zu rotieren. Und falls doch, dann höchstens einmal pro Jahr. Dadurch bleiben statische Anmeldeinformationen für die Kerninfrastruktur auf Hunderten oder Tausenden von Geräten bestehen.

• Benutzer sind selbst für die Sicherung ihrer Zertifikate auf ihren Geräten verantwortlich. Benutzer sind auch für Passwörter verantwortlich, aber Organisationen können Anforderungen und Sperrungen zentral erzwingen.

• Sperrungen sind schwierig. Teams müssen eine CRL- oder OCSP-Plattform verwalten, um sicherzustellen, dass verlorene oder gestohlene Zertifikate nicht verwendet werden.

Mit Cloudflare Access können Sie Ihre SSO-Konten zur Benutzerauthentifizierung innerhalb Ihrer Infrastruktur einsetzen. Statische Schlüssel sind nicht erforderlich.

Zu diesem Zweck wandten wir uns drei Tools zu, die wir bereits hatten: Cloudflare Access, Argo Tunnel und Workers.

Access ist ein Richtlinienmodul, das die Mitarbeiterdaten bei Ihrem Identitätsanbieter (z. B. Okta oder AzureAD) mit von Ihnen erstellten Richtlinien kombiniert. Basierend auf diesen Richtlinien ist Access in der Lage, den Zugriff auf Ihre internen Anwendungen auf die von Ihnen gewählten Benutzer zu beschränken. Es ist nicht schwer zu sehen, wie das gleiche Richtlinienkonzept verwendet werden könnte, um den Zugriff auf einen Server über SSH zu steuern. Sie schreiben eine Richtlinie und wir verwenden sie, um zu entscheiden, welche Ihrer Mitarbeiter auf welche Ressourcen zugreifen können. Dann generieren wir ein kurzlebiges Zertifikat, das ihnen den Zugriff auf diese Ressource nur für den kürzesten Zeitraum ermöglicht. Wenn Sie einen Benutzer von Ihrem IdP entfernen, wird dessen Zugriff auf Ihre Infrastruktur ebenfalls nahtlos entfernt.

Um den Datenverkehr tatsächlich durch unser Netzwerk zu leiten, verwenden wir ein anderes, bereits existierendes Cloudflare-Tool: Argo Tunnel. Argo Tunnel dreht das herkömmliche Modell der Verbindung eines Servers mit dem Internet um. Wenn Sie unseren Daemon auf einem Computer starten, stellt er ausgehende Verbindungen zu Cloudflare her, und Ihr gesamter Datenverkehr fließt dann über diese Verbindungen. Dadurch kann der Computer ein Teil des Cloudflare-Netzwerks sein, ohne dass Sie ihn direkt dem Internet aussetzen müssen.

Für HTTP-Anwendungsfälle muss Argo Tunnel nur auf dem Server ausgeführt werden. Im Fall des Access-SSH-Flows setzen wir Cloudflare als Proxy zur Weiterleitung des SSH-Datenverkehrs ein, indem wir den Argo-Tunnel-Client über Cloudflared sowohl auf dem Server als auch auf dem Laptop des Endbenutzers ausführen.

Wenn Benutzer eine Verbindung über SSH mit einer Ressource herstellen, die durch „Access for Infrastructure“ gesichert ist, verwenden sie das Befehlszeilentool Cloudflared. Cloudflared nimmt den für diesen Hostnamen bestimmten SSH-Datenverkehr und leitet ihn basierend auf SSH-Konfigurationseinstellungen über Cloudflare weiter. Pipelines oder Befehlsumbruch sind nicht erforderlich. Cloudflared startet ein Browserfenster und fordert den Benutzer auf, sich mit seinen SSO-Anmeldeinformationen zu authentifizieren.

Nach der Authentifizierung überprüft Access die Identität des Benutzers anhand der Richtlinie, die Sie für diese Anwendung konfiguriert haben. Wenn dem Benutzer der Zugriff auf die Ressource erlaubt wird, generiert Access ein JSON-Webtoken (JWT), das von Cloudflare signiert und auf den Benutzer und die Anwendung zugeschnitten wird. Access liefert dieses Token über Cloudflared an das Gerät des Benutzers, und das Tool speichert es lokal.

Genauso wie der zentrale Access-Authentifizierungsprozess wird die Token-Validierung mit einem Cloudflare Worker erstellt, der in jedem unserer Rechenzentren läuft und somit schnell und jederzeit verfügbar ist. Workers hat es uns ermöglicht, diese SSH-Proxyfunktion in allen 194 Cloudflare-Rechenzentren bereitzustellen, was bedeutet, dass „Access for Infrastructure“ SSH-Sitzungen oft beschleunigt, anstatt sie zu verlangsamen.

Wenn kurzlebige Zertifikate aktiviert sind, führt die auf dem Client laufende Instanz von Cloudflared einen weiteren Schritt aus. Cloudflared sendet dieses Token an einen Cloudflare-Zertifikatsignatur-Endpunkt, der ein kurzlebiges Zertifikat erstellt. Der SSH-Flow des Benutzers sendet dann sowohl das Token, das zur Authentifizierung über Access verwendet wird, als auch das kurzlebige Zertifikat, das zur Authentifizierung beim Server verwendet wird. Genauso wie der zentrale Access-Authentifizierungsprozess wird die Token-Validierung mit einem Cloudflare Worker erstellt, der in jedem unserer Rechenzentren läuft und somit schnell und jederzeit verfügbar ist.

Wenn der Server die Anforderung empfängt, überprüft er das kurzlebige Zertifikat anhand dieses öffentlichen Schlüssels und autorisiert, falls es authentisch ist, die Benutzeridentität für einen zugehörigen Unix-Benutzer. Das Zertifikat ist nach der Ausstellung 2 Minuten lang gültig, aber die SSH-Verbindung kann länger dauern, sobald die Sitzung gestartet wurde.

Die SSH-Funktion von Cloudflare Access ist für den Endbenutzer vollständig transparent und erfordert keine einzelnen SSH-Befehle, Wrapper oder Flags. Stattdessen verlangt Access, dass Ihre Teammitglieder einige einmalige Schritte ausführen, um beginnen zu können:

1. Installation des Cloudflared-Daemons

Dieselbe einfache Software, die auf dem Zielserver läuft, wird verwendet, um SSH-Verbindungen von den Geräten Ihrer Teammitglieder über Cloudflare weiterzuleiten. Benutzer können sie mit gängigen Paket-Managern wie Brew oder über den hier verfügbaren Link installieren. Es handelt sich um Open-Source-Software, die alternativ auch von Ihren Administratoren erstellt und verteilt werden kann.

2. Ausgabe und Speichern des SSH-Konfigurations-Updates

Sobald ein Endbenutzer Cloudflared installiert hat, muss er einen Befehl ausführen, um neue Zeilen zu generieren, die seiner SSH-Konfigurationsdatei hinzugefügt werden:

cloudflared access ssh-config --hostname vm.example.com --short-lived-cert

Das --hostname-Feld enthält den Hostnamen oder die Platzhalter-Unterdomäne der Ressource, die hinter Access geschützt ist. Nach der Ausführung gibt Cloudflared die folgenden Konfigurationsdetails aus:

Host vm.example.com
    ProxyCommand bash -c '/usr/local/bin/cloudflared access ssh-gen --hostname %h; ssh -tt %[email protected] >&2 <&1'
    
Host cfpipe-vm.example.com
    HostName vm.example.com
    ProxyCommand /usr/local/bin/cloudflared access ssh --hostname %h
    IdentityFile ~/.cloudflared/vm.example.com-cf_key
    CertificateFile ~/.cloudflared/vm.example.com-cf_key-cert.pup

Benutzer müssen diese Ausgabe an ihre SSH-Konfigurationsdatei anfügen. Nach dem Speichern können sie eine Verbindung über SSH mit der geschützten Ressource herstellen. Access fordert sie auf, sich mit ihren SSO-Anmeldeinformationen im Browser zu authentifizieren, genauso wie sie sich bei jedem anderen browserbasierten Tool anmelden. Wenn sie bereits über eine aktive Browsersitzung mit ihren Anmeldeinformationen verfügen, wird nur eine Seite mit einer Erfolgsmeldung angezeigt.

Cloudflared richtet die Sitzung in ihrem Terminal ein und stellt das Clientzertifikat aus, das ihrer Identität entspricht.

Mit kurzlebigen Zertifikaten kann Access zu einem einzigen SSO-integrierten Gateway für Ihr Team und Ihre Infrastruktur in jeder Umgebung werden. Benutzer können sich über SSH direkt mit einem bestimmten Rechner verbinden, und Administratoren können ihre Jumphosts komplett ersetzen, wodurch dieser Overhead wegfällt. Die Funktion ist heute für alle Access-Kunden verfügbar. Um anzufangen, können Sie der Dokumentation folgen, die hier verfügbar ist.