Zum Inhalt

47-Tage-Zertifikate sind im Anmarsch. Sind Sie bereit?

Jetzt handeln →

Ein Leitfaden zum Schutz und zur Verwaltung von SSH-Schlüsseln zur Minderung von Sicherheitsrisiken

Ein Leitfaden zum Schutz und zur Verwaltung von SSH-Schlüsseln zur Minderung von Sicherheitsrisiken

Secure Shell (SSH)-Schlüssel sind kryptografische Zugangsdaten, die im SSH-Protokoll für den Zugriff auf Remote-Server, die sichere Dateiübertragung und die Server-zu-Server-Authentifizierung in modernen Infrastrukturen verwendet werden, darunter Infrastructure-as-a-Service-Plattformen wie AWS, Google Cloud und Azure. SSH-Schlüssel sind aus Sicherheitsgründen wichtig, da große Unternehmen oft mehr als eine Million SSH-Schlüssel in ihrer Umgebung verwenden. Im Gegensatz zu Passwörtern oder Zertifikaten haben SSH-Schlüssel kein integriertes Ablaufdatum und keinen standardisierten Widerrufsmechanismus. Ein nicht verwalteter SSH-Schlüssel eines ehemaligen Mitarbeiters kann als permanente Hintertür unbegrenzt gültig bleiben, sofern er nicht explizit entfernt wird. Empfohlene Vorgehensweise: Ermitteln Sie zunächst alle SSH-Server und alle autorisierten Schlüssel in Ihrer Umgebung. Ordnen Sie jeden Schlüssel einem Besitzer zu. Implementieren Sie Richtlinien für die Schlüsselgenerierung, -rotation und den Widerruf. Deaktivieren Sie die Root-Anmeldung. Nutzen Sie SSH Secure, um den Lebenszyklus der SSH-Schlüssel umfassend zu verwalten. Eine technische Erklärung zur Funktionsweise von SSH-Schlüsseln finden Sie im zugehörigen Blogbeitrag „ Wie funktionieren Secure Shell (SSH)-Schlüssel?“ . Informationen zur SSH-Schlüsselverwaltung in Unternehmen finden Sie unter SSH Secure.

Kurzantwort: Warum ist die SSH-Schlüsselverwaltung so wichtig?

SSH-Schlüssel sind Zugangsdaten ohne integriertes Ablaufdatum und ohne standardisierten Widerrufsmechanismus. Unverwaltete SSH-Schlüsselumgebungen stellen daher ein dauerhaftes Sicherheitsrisiko dar. Große Unternehmen verfügen oft über mehr als eine Million SSH-Schlüssel, viele davon ehemaligen Mitarbeitern zugehörig, von mehreren Benutzern gemeinsam genutzt, in Anwendungen eingebettet oder nach Servermigrationen schlichtweg vergessen. Jeder dieser nicht erfassten Schlüssel kann von einem Angreifer, der den zugehörigen privaten Schlüssel erlangt hat, genutzt werden, um dauerhaften Zugriff auf kritische Infrastrukturen zu erlangen – oft ohne Warnmeldungen auszulösen, da die Verbindung mit gültigen Zugangsdaten erfolgt. Die drei wichtigsten Kontrollmaßnahmen sind: alle SSH-Schlüssel ermitteln und inventarisieren; Richtlinien für die Schlüsselrotation und den Schlüsselwiderruf implementieren; und die Root-SSH-Anmeldung deaktivieren, um alle privilegierten Zugriffe nachvollziehbar zu machen.

Was sind SSH-Schlüssel?

SSH-Schlüssel sind kryptografische Schlüsselpaare, die zur Authentifizierung im Secure Shell (SSH)-Protokoll verwendet werden. Die gängigste Methode zur SSH-Schlüsselverschlüsselung ist RSA 2048-Bit, die eine Sicherheit bietet, die mit einem 617-stelligen Passwort vergleichbar ist. SSH-Schlüsselpaare bestehen aus einem öffentlichen und einem privaten Schlüssel: Der öffentliche Schlüssel befindet sich auf dem Server, der private Schlüssel auf dem Client. Die Authentifizierung ist erfolgreich, wenn der Client den Besitz des zum öffentlichen Schlüssel gehörenden privaten Schlüssels nachweist, der auf dem Server autorisiert ist. Die Generierung eines SSH-Schlüsselpaares unterscheidet sich je nach Betriebssystem: Unter Windows werden die Schlüssel mit einem SSH-Client wie PuTTY generiert; unter macOS und Linux erfolgt die Generierung in einem Terminalfenster mit dem Befehl `ssh-keygen`.

SSH-Schlüssel sind immer paarweise verfügbar. Es gibt drei verschiedene Arten von SSH-Schlüsseln, die sich dadurch unterscheiden, wer oder was sie besitzt:

  • Benutzerschlüssel

    Wenn privater und öffentlicher Schlüssel einem bestimmten Benutzer gehören, spricht man von Benutzerschlüsseln. Der öffentliche Schlüssel wird in der Datei „authorized_keys“ auf dem Remote-Server gespeichert; der private Schlüssel verbleibt auf dem System des Benutzers. Benutzerschlüssel dienen der Authentifizierung einzelner Benutzer gegenüber Remote-Servern.

  • Host-Schlüssel

    Befinden sich die privaten und öffentlichen Schlüssel auf dem entfernten System (dem Server), spricht man von Host-Schlüsseln. Host-Schlüssel identifizieren den Server gegenüber Clients, die sich verbinden, und ermöglichen es dem Client zu überprüfen, ob er sich mit dem richtigen Server und nicht mit einem Angreifer (Man-in-the-Middle) verbindet. Wenn Sie sich zum ersten Mal mit einem neuen SSH-Server verbinden und Ihnen zur Bestätigung ein Fingerabdruck angezeigt wird, überprüfen Sie den Host-Schlüssel.

  • Sitzungsschlüssel

    Sitzungsschlüssel sind symmetrische Verschlüsselungsschlüssel, die bei der Übertragung großer Datenmengen während einer aktiven SSH-Sitzung verwendet werden. Im Gegensatz zu Benutzer- und Hostschlüsseln werden Sitzungsschlüssel für jede Verbindung neu generiert und nicht dauerhaft gespeichert. Dadurch beschränkt sich der Schaden bei Kompromittierung eines Sitzungsschlüssels auf die Dauer der jeweiligen Sitzung, in der der Schlüssel verwendet wurde.

Wie funktioniert die SSH-Schlüsselauthentifizierung?

Nachdem ein Schlüsselpaar generiert und der öffentliche Schlüssel auf dem Remote-Server hinterlegt wurde, läuft die SSH-Authentifizierung wie folgt ab: Der Benutzer initiiert eine Verbindung und gibt dabei den SSH-Benutzernamen und die IP-Adresse des Remote-Systems an. Das SSH-Protokoll ermittelt anhand des angegebenen Benutzernamens den zu verwendenden öffentlichen Schlüssel. Der Remote-Server verschlüsselt eine Challenge-Nachricht mit dem öffentlichen Schlüssel des Clients und sendet diese an den Client. Der Client entschlüsselt die Challenge mit dem auf seinem System gespeicherten privaten Schlüssel. Die entschlüsselte Challenge wird mit der Sitzungs-ID kombiniert und an den Server zurückgesendet. Stimmt der zurückgegebene Wert mit dem erwarteten Wert des Servers überein, ist die Authentifizierung erfolgreich und der Zugriff wird gewährt.

Die Sicherheit dieses Prozesses hängt vollständig davon ab, dass der private Schlüssel geheim bleibt. Sollte ein Angreifer den privaten Schlüssel erlangen, kann er sich ohne Passwort und ohne dass eine Warnung über die Authentifizierung eines anderen Benutzers ausgelöst wird, an jedem Server authentifizieren, der den zugehörigen öffentlichen Schlüssel besitzt.

Maßgeschneiderte Beratungsleistungen

Wir bewerten, entwickeln Strategien und implementieren Verschlüsselungsstrategien und -lösungen, die auf Ihre Anforderungen zugeschnitten sind.

Verwalten von SSH-Schlüsseln

In Unternehmensumgebungen sind mehrere Millionen SSH-Schlüssel im Einsatz, vorwiegend in Organisationen, die Infrastructure-as-a-Service-Plattformen und umfangreiche Serverinfrastrukturen nutzen. Ein effektives SSH-Schlüsselmanagementsystem ist unerlässlich, um Sicherheitsrisiken in Entwicklungs- und Produktionsumgebungen zu minimieren. Effektives Management erfordert die Kontrolle des SSO-Anbieters, der Verzeichnisdienste und der Systemverwaltungslösungen sowie die Integration der SSH-Schlüsselverwaltung in das umfassendere Identitäts- und Zugriffsmanagementprogramm.

Risiken im Zusammenhang mit SSH-Schlüsseln

Es gibt viele Risiken und Sicherheitslücken im Zusammenhang mit SSH-Schlüsseln. Die folgenden fünf sind kritisch und sollten nicht ignoriert werden:

Probleme bei der SSH-Schlüsselverfolgung

Große Unternehmen verfügen oft über mehr als eine Million SSH-Schlüssel, deren Nachverfolgung und Verwaltung ohne automatisierte Tools praktisch unmöglich ist. Im Gegensatz zu Zertifikaten oder Passwörtern, die eine Zertifizierungsstelle oder einen Verzeichnisdienst erfordern, können Endbenutzer neue SSH-Schlüssel erstellen oder bestehende duplizieren – ohne zentrale Genehmigung oder formellen Ausstellungsprozess. Sobald sich eine große Anzahl unkontrollierter SSH-Schlüssel angesammelt hat, wird deren Nachverfolgung entscheidend, beispielsweise bei der Migration von Entwicklungsservern in die Produktionsumgebung, beim Ausscheiden von Mitarbeitern ohne Widerruf ihrer Schlüssel oder beim Einbetten von Schlüsseln in Skripte durch Anwendungen. Nicht erfasste SSH-Schlüssel können Angreifern langfristigen privilegierten Zugriff auf Unternehmensressourcen ermöglichen, und verlassene Schlüssel ehemaliger Mitarbeiter können als permanente Hintertüren fungieren.

Die gemeinsame Nutzung von SSH-Schlüsseln ist problematisch.

Aus Effizienzgründen werden SSH-Schlüssel häufig zwischen Mitarbeitern oder Servern geteilt oder dupliziert. Ein einzelner SSH-Schlüssel kann mehrere Instanzen haben, die Zugriff auf alle Rechner im Unternehmen gewähren. Die Duplizierung von Schlüsseln erzeugt komplexe Viele-zu-Viele-Beziehungen zwischen privaten Schlüsseln und Servern, was die Sicherheit beeinträchtigt, da das Rotieren und Widerrufen geteilter Schlüssel ohne Beeinträchtigung aller Benutzer, die sie teilen, operativ schwierig ist. Die gemeinsame Nutzung von Schlüsseln verringert zudem die Nachvollziehbarkeit und Nichtabstreitbarkeit: Wenn mehrere Benutzer einen privaten Schlüssel gemeinsam nutzen, lassen sich Protokolleinträge Aktionen nicht zuverlässig einer bestimmten Person zuordnen.

Statische SSH-Schlüssel

Die Rotation von über einer Million SSH-Schlüsseln ist betriebsintensiv. Viele IT-Administratoren ändern oder verteilen Schlüssel nur selten, aus Sorge, dass kritische Systeme oder Benutzer während der Rotation den Zugriff verlieren könnten. Diese Bedenken führen zu einer Ansammlung statischer SSH-Schlüssel, die monate- oder jahrelang nicht rotiert wurden. Statische Schlüssel geben Angreifern mehr Zeit, einen kompromittierten Schlüssel zu entdecken und auszunutzen. So können sie sich innerhalb der Organisation ausbreiten und mithilfe dieses Schlüssels auf sensible Daten zugreifen, ohne dass Warnmeldungen zur Schlüsselrotation ausgelöst werden.

Eingebettete SSH-Schlüssel

SSH-Schlüssel werden häufig in Anwendungen und Skripte eingebettet, um die automatisierte Server-zu-Server-Authentifizierung zu ermöglichen. Eingebettete Schlüssel lassen sich besonders schwer rotieren, da Anwendungscode und Schlüssel koordiniert aktualisiert werden müssen, um Serviceausfälle zu vermeiden. Diese Koordinationsschwierigkeit führt dazu, dass eingebettete Schlüssel dauerhaft statisch bleiben und so persistente Hintertüren im Anwendungscode entstehen, die ausgenutzt werden können, sobald ein Angreifer Zugriff darauf erlangt.

Schwache SSH-Konfiguration

SSH-Client- und Serverimplementierungen wie OpenSSH enthalten Konfigurationsparameter, die viele IT-Administratoren auf den Standardwerten belassen. Standardeinstellungen wie Portweiterleitung, Root-Zugriff und die Akzeptanz von Passwort- und Schlüsselauthentifizierung erhöhen das Sicherheitsrisiko. Eine schwache SSH-Konfiguration kann den Server Brute-Force-Angriffen aussetzen und Angreifern ermöglichen, ihre Berechtigungen zu erweitern oder sich lateral im Netzwerk zu bewegen, sobald sie über gültigen SSH-Zugriff verfügen.

Sicherheitslücken von SSH

  • Brute-Force- und Malware-Angriffe

    Angreifer zielen auf SSH-Schlüssel ab, um sich innerhalb eines Unternehmensnetzwerks lateral zu bewegen, führen Brute-Force-Angriffe auf SSH-Dienste durch, die eine Passwortauthentifizierung ermöglichen, und installieren Schadsoftware, indem sie mithilfe kompromittierter SSH-Schlüssel oder falsch konfigurierter SSH-Server Hintertüren einrichten. Sobald ein Angreifer einen gültigen privaten SSH-Schlüssel besitzt oder ein schwaches Passwort auf einem SSH-Server per Brute-Force-Angriff geknackt hat, verfügt er über einen authentifizierten Zugriff, der sich in den Serverprotokollen nicht von legitimen Zugriffen unterscheidet.

  • SSH-Session-Hijacking und unbefugter Zugriff

    Angreifer können eine aktive SSH-Sitzung übernehmen, indem sie die zwischen Systemen etablierte vertrauenswürdige Kommunikation ausnutzen und Zugriff auf den SSH-Socket des Benutzers erlangen. Dies geschieht durch Ausnutzung von Standardkonfigurationen, die Socket-Weiterleitung erlauben, oder durch Kompromittierung des Client-Systems und Zugriff auf den SSH-Agent-Socket. Die Vermeidung von Standardkonfigurationen und die Beschränkung der SSH-Agent-Weiterleitung auf bestimmte vertrauenswürdige Hosts reduzieren dieses Risiko erheblich.

Wie man SSH-Sicherheitsangriffe abwehrt

  1. Schlüssel entdecken und zuordnen

    Ermitteln Sie alle SSH-Server, öffentlichen und privaten Schlüssel, die zur Gewährung von SSH-Zugriff berechtigt sind. Führen Sie regelmäßig Netzwerkscans mit SSH-Erkennungstools durch, um alle autorisierten Schlüssel zu finden und zu erfassen. Erstellen Sie ein zentrales Repository, das jeden öffentlichen Schlüssel dem entsprechenden Benutzer oder System zuordnet, das den privaten Schlüssel besitzt, und aktualisieren Sie diese Zuordnung kontinuierlich. Die Zuordnung der Schlüssel-Benutzer- und Schlüssel-Server-Beziehungen bildet die Grundlage für alle weiteren SSH-Schlüsselverwaltungsmechanismen.

  2. Steuern Sie SSH-Schlüssel und Zugriff

    Implementieren Sie Richtlinien für das SSH-Schlüsselmanagement, die Standards für die Schlüsselgenerierung, die maximale Schlüssellebensdauer, Rotationspläne und Widerrufsverfahren für ausscheidende Mitarbeiter und stillgelegte Systeme umfassen. Weisen Sie jedem Schlüsselpaar die minimal erforderliche Zugriffsebene zu: Benutzerschlüssel sollten nur Zugriff auf die vom Benutzer benötigten Server gewähren; eingebettete Schlüssel sollten nur Zugriff auf die von der Anwendung benötigten Systeme haben. Verwenden Sie Verzeichnisdienste, um die erforderlichen Zugriffsberechtigungen durchzusetzen und Entscheidungen zur Schlüsselautorisierung zu zentralisieren. Informationen zur automatisierten Verwaltung des SSH-Schlüssellebenszyklus finden Sie unter SSH Secure .

  3. Root-Login deaktivieren

    Das Root-Konto auf UNIX-basierten Systemen hat uneingeschränkten Zugriff auf alle Systemressourcen. Angreifer zielen gezielt auf die Root-Anmeldung ab, um uneingeschränkten Zugriff auf kritische Systeme zu erlangen. Konfigurieren Sie alle SSH-Server so, dass `PermitRootLogin` auf `no` gesetzt ist. Dadurch müssen sich Benutzer mit benannten Benutzerkonten authentifizieren und `sudo` oder `su` zur Rechteausweitung verwenden. Dies stellt sicher, dass alle privilegierten Aktionen einem benannten Benutzerkonto zugeordnet sind und erstellt einen Prüfpfad, der die forensische Untersuchung unautorisierter privilegierter Aktionen ermöglicht.

Checkliste zur Behebung von SSH-Schlüsselproblemen

  • Führen Sie einen vollständigen Erkennungsscan aller SSH-Server und aller authorized_keys-Einträge in der Umgebung durch.
  • Ordnen Sie jeden öffentlichen Schlüssel einem Besitzer (Benutzer oder System) zu; kennzeichnen Sie Schlüssel ohne identifizierbaren Besitzer zur sofortigen Untersuchung und zum Widerruf.
  • Alle SSH-Schlüssel ehemaliger Mitarbeiter, die im Zuge der Ermittlungen identifiziert wurden, sind zu widerrufen.
  • Identifizieren und dokumentieren Sie alle eingebetteten SSH-Schlüssel im Anwendungscode und in Skripten; beginnen Sie mit der Planung eines Rotationsplans, der Anwendungsaktualisierungen koordiniert.
  • Implementieren Sie eine SSH-Schlüsselverwaltungsrichtlinie mit definierter maximaler Schlüssellebensdauer und obligatorischen Rotationsperioden.
  • Konfigurieren Sie alle SSH-Server mit der Einstellung „PermitRootLogin no“; überprüfen Sie, ob die Änderung angewendet wurde und wirksam ist.
  • Passwortbasierte Authentifizierung auf allen SSH-Servern deaktivieren; nur schlüsselbasierte Authentifizierung erzwingen
  • Die Weiterleitung des SSH-Agenten auf bestimmte vertrauenswürdige Hosts beschränken; standardmäßig deaktivieren.
  • Deaktivieren Sie die standardmäßige Portweiterleitung auf Servern, auf denen sie nicht erforderlich ist.
  • Richten Sie eine kontinuierliche SSH-Schlüsselerkennung und -überwachung ein, um die Bestandsgenauigkeit bei der Erstellung oder Änderung von Schlüsseln zu gewährleisten.
  • Integrieren Sie die Sperrung von SSH-Schlüsseln in den Austrittsprozess von Mitarbeitern, um eine sofortige Schlüsselsperrung zu gewährleisten.
  • Überprüfen und aktualisieren Sie das SSH-Schlüsselinventar vierteljährlich.

Fazit

Wenn IT-Administratoren ordnungsgemäße Prüfprotokolle führen und sicherstellen, dass alle verwendeten SSH-Schlüssel den definierten Richtlinien entsprechen, bietet dies die notwendige Transparenz, um unautorisierte Schlüssel zu erkennen, auf kompromittierte Anmeldeinformationen zu reagieren und entsprechende Anpassungen für die Schlüsselgenerierung, -rotation und -sperrung vorzunehmen. Die SSH-Schlüsselverwaltung erfordert dieselbe systematische Governance, die Unternehmen auch für die Zertifikatslebenszyklusverwaltung anwenden: Ermittlung, Inventarisierung, Zugriffskontrolle und automatisierte Rotation. Informationen zur SSH-Schlüssellebenszyklusverwaltung in Unternehmen finden Sie unter SSH Secure . Eine technische Erklärung der Funktionsweise von SSH-Schlüsseln finden Sie unter Funktionsweise von Secure Shell (SSH)-Schlüsseln.

Häufig gestellte Fragen

Welche drei Arten von SSH-Schlüsseln gibt es und wie unterscheiden sie sich?

Es gibt drei Arten: Benutzerschlüssel (vom Benutzer verwaltet, dienen der Authentifizierung von Benutzern gegenüber Servern); Hostschlüssel (vom Server verwaltet, ermöglichen es Clients, die Serveridentität zu überprüfen und Man-in-the-Middle-Angriffe zu verhindern); und Sitzungsschlüssel (symmetrische Schlüssel, die für jede Verbindung neu generiert werden, zur Verschlüsselung des Sitzungsverkehrs verwendet werden und nicht dauerhaft gespeichert werden).

Warum ist die Nachverfolgung von SSH-Schlüsseln in großen Unternehmensumgebungen so schwierig?

Im Gegensatz zu Zertifikaten oder Passwörtern können SSH-Schlüssel von Endbenutzern ohne zentrale Genehmigung, formelles Ausstellungsverfahren oder Speicherung in einem zentralen System erstellt und dupliziert werden. Große Unternehmen verfügen mitunter über mehr als eine Million SSH-Schlüssel, viele davon stammen von ehemaligen Mitarbeitern oder sind in Anwendungen eingebettet. Ohne automatisierte Erkennungstools nimmt die Transparenz mit zunehmender Anzahl an Schlüsseln rapide ab, wodurch ein dauerhaftes Risiko unberechtigten Zugriffs entsteht.

Was ist SSH-Schlüsselteilung und warum stellt sie ein Sicherheitsrisiko dar?

Die gemeinsame Nutzung von SSH-Schlüsseln bedeutet, dass ein einzelnes Schlüsselpaar von mehreren Benutzern oder Servern verwendet wird. Ein gemeinsam genutzter Schlüssel kann vielen Rechnern gleichzeitig Zugriff gewähren; seine Rotation oder sein Widerruf beeinträchtigt alle Benutzer, die darauf angewiesen sind. Die gemeinsame Nutzung von Schlüsseln verschlechtert zudem die Nachvollziehbarkeit und Nichtabstreitbarkeit von Aktionen, da Protokolle Aktionen nicht zuverlässig einer bestimmten Person zuordnen können, wenn mehrere Personen einen privaten Schlüssel gemeinsam nutzen.

Welche Schritte sind am effektivsten, um eine Umgebung mit nicht verwalteten SSH-Schlüsseln zu bereinigen?

Die vier effektivsten Schritte sind: (1) Vollständiger Discovery-Scan zur Identifizierung aller SSH-Server und autorisierten Schlüssel; (2) Zuordnung jedes öffentlichen Schlüssels zu einem bestimmten Besitzer oder System; (3) Widerruf aller Schlüssel ehemaliger Mitarbeiter und Schlüssel ohne identifizierbaren Besitzer; und (4) Implementierung von Richtlinien, die Standards für die Schlüsselgenerierung, die maximale Lebensdauer von Schlüsseln, Rotationspläne und obligatorische Widerrufsverfahren für ausscheidende Mitarbeiter abdecken.

In welchem ​​Zusammenhang steht die SSH-Schlüsselverwaltung mit PKI und Zertifikatsverwaltung?

Sowohl SSH-Schlüssel als auch PKI-Zertifikate sind kryptografische Anmeldeinformationen, die ein Lebenszyklusmanagement erfordern. SSH-Schlüssel verfügen jedoch weder über ein integriertes Ablaufdatum noch über einen standardisierten Widerrufsmechanismus. Daher stellen unkontrollierte SSH-Schlüssel ein größeres Risiko dar als abgelaufene Zertifikate, deren Gültigkeit automatisch ungültig wird. SSH-Zertifikate (die öffentliche SSH-Schlüssel mit Identitäten und Ablaufdaten verknüpfen) sind ein hybrider Ansatz, der PKI-ähnliche Governance auf SSH überträgt. Organisationen mit ausgereiftem Zertifikatslebenszyklusmanagement sollten vergleichbare Bestandsführungs- und Zugriffskontrollverfahren auch auf SSH-Schlüssel anwenden.