Warum SSH-Schlüssel ohne Ablaufdatum ein Sicherheitsrisiko darstellen

SSH-Schlüssel laufen standardmäßig nicht ab. Sobald ein öffentlicher Schlüssel der Datei `authorized_keys` eines Servers hinzugefügt wurde, bleibt er dauerhaft vertrauenswürdig, sofern er nicht manuell entfernt wird. Dadurch wird ein dauerhafter, nicht nachverfolgbarer Zugriff gewährleistet, der auch bei Mitarbeiterausscheiden, Rollenwechseln, Systemstilllegungen und der Abschaffung veralteter Algorithmen erhalten bleibt. Branchenstudien zeigen, dass 57 % der Unternehmen die Verwaltung von SSH-Schlüsseln als aufwendig und schwierig empfinden und dass 40 % nicht über die nötige Automatisierung verfügen, um die Entfernung bei Mitarbeiterausscheiden zu erzwingen. Empfohlen wird die Implementierung eines formalen SSH-Schlüssel-Lebenszyklusmanagements. Dieses sollte eine zentrale Bestandsverwaltung, risikobasierte Rotationspläne, die automatische Sperrung bei bestimmten Ereignissen, HSM-gestützten Schlüsselschutz, temporäre Schlüssel für die Automatisierung und mindestens vierteljährliche Zugriffsüberprüfungen umfassen.

Kurzantwort: Warum stellen SSH-Schlüssel mit unbegrenzter Gültigkeit ein Sicherheitsrisiko dar?

Unbegrenzt ablaufende SSH-Schlüssel stellen ein Sicherheitsrisiko dar, da sie einen dauerhaften, unkontrollierbaren Zugriff ermöglichen, der ohne Kenntnis der relevanten Stellen nicht widerrufen werden kann. Ein Schlüssel, der von einem ehemaligen Mitarbeiter auf einem Server hinterlegt wurde, ist heute noch genauso gültig wie am Tag seiner Erstellung. Ein in einem CI/CD-Skript eines vor zwei Jahren abgeschlossenen Projekts eingebetteter Schlüssel öffnet weiterhin jeden Server, auf dem dieser öffentliche Schlüssel verwendet wurde. SSH-Schlüssel laufen standardmäßig nicht ab (NIST NISTIR 7966 bestätigt, dass SSH keinen integrierten Ablaufmechanismus besitzt). Daher muss die Governance die Lücken des Protokolls schließen. Informationen zu den Auswirkungen unbegrenzt ablaufender Schlüssel auf die Compliance finden Sie unter „SSH Key Management Compliance“ . Informationen zu Schutzmethoden finden Sie unter „The Best Methods to Protect Your SSH Keys“.

SSH-Schlüssel verstehen

SSH-Schlüssel sind kryptografische Anmeldeinformationen, die vom SSH-Protokoll zur Authentifizierung von Clients und zum Aufbau sicherer Verbindungen verwendet werden. Man kann sie sich wie ein Vorhängeschloss und einen Schlüssel vorstellen: Der öffentliche Schlüssel ist das Schloss, das auf entfernten Rechnern in der Datei „authorized_keys“ hinterlegt ist; der private Schlüssel ist der physische Schlüssel, der es öffnet, vom Benutzer aufbewahrt und niemals über das Netzwerk übertragen wird.

Wenn ein Benutzer eine Verbindung herstellt, prüft der SSH-Server, ob der eingehende öffentliche Schlüssel in der Datei `authorized_keys` enthalten ist. Bei Übereinstimmung sendet der Server eine kryptografische Herausforderung. Der Client signiert diese Herausforderung mit seinem privaten Schlüssel, ohne diesen selbst zu übertragen. Der Server verifiziert die Signatur mithilfe des gespeicherten öffentlichen Schlüssels. Bei erfolgreicher Verifizierung wird der Client authentifiziert, ohne dass ein Passwort über das Netzwerk gesendet werden muss.

Anders als Passwörter oder digitale Zertifikate haben SSH-Schlüssel kein Ablaufdatum. Einmal erstellt, bleibt ein Schlüsselpaar unbegrenzt gültig, oft auch lange nachdem sich die Rolle des Benutzers geändert hat, er das Unternehmen verlassen hat oder das System außer Betrieb genommen wurde. Diese Eigenschaft stellt eine der hartnäckigsten und am meisten unterschätzten Schwachstellen der Unternehmenssicherheit dar.

Wie SSH-Schlüssel funktionieren

Die SSH-Schlüsselauthentifizierung verwendet asymmetrische Kryptografie. Der private Schlüssel wird auf dem Client gespeichert, der öffentliche Schlüssel befindet sich auf dem Server in der Datei ~/.ssh/authorized_keys. Das SSH-Protokoll nutzt das Schlüsselpaar nur während der Authentifizierung zur Identitätsprüfung, nicht zur Verschlüsselung des Sitzungsverkehrs. Nach erfolgreicher Authentifizierung verwendet SSH für alle nachfolgenden Daten einen schnelleren symmetrischen Sitzungsschlüssel.

Da der private Schlüssel das Clientgerät niemals verlässt und asymmetrische Schlüsselpaare rechentechnisch resistent gegen Brute-Force-Angriffe sind, ist die SSH-Schlüsselauthentifizierung von Natur aus sicher. Die Schwäche liegt nicht in der Kryptografie, sondern darin, was mit diesen Schlüsseln im Laufe der Zeit geschieht, wenn keine Lebenszykluskontrollen vorhanden sind. Eine vollständige Erklärung der Funktionsweise der Authentifizierung finden Sie unter „ Funktionsweise von SSH-Schlüsseln“.

Warum SSH-Schlüssel nicht ablaufen und warum das ein Problem darstellt

SSH wurde für eine starke kryptografische Authentifizierung entwickelt, verfügt jedoch nicht über integrierte Mechanismen für den Ablauf, die Erneuerung oder die automatische Gültigkeitsprüfung von Schlüsseln (NISTIR 7966). Dies führt in Unternehmen zu einer unkontrollierten Anhäufung von SSH- Schlüsseln auf Servern, Konten und in verschiedenen Umgebungen. Alte, ungenutzte und verwaiste Schlüssel sammeln sich mit der Zeit an und bilden versteckte Zugriffspunkte, die schwer nachzuverfolgen und ohne spezielle Tools kaum zu überprüfen sind.

Zu den Folgen von unbegrenzt gültigen, nicht verwalteten SSH-Schlüsseln gehören:

• Dauerhafter Zugriff

  Schlüssel bleiben auch nach dem Ausscheiden von Mitarbeitern aus dem Unternehmen oder einem Rollenwechsel gültig. Ehemalige Benutzer behalten Zugriff auf kritische Systeme, wodurch erhebliche Sicherheitslücken durch Insider entstehen und das Prinzip der minimalen Berechtigungen verletzt wird. Je länger der Schlüssel nach dem Ausscheiden des autorisierten Benutzers bestehen bleibt, desto schwieriger wird es, die Sicherheitslücke zu erkennen und zu beheben.

• Veraltete Schlüssel

  Deaktivierte oder inaktive Konten können dennoch aktive öffentliche Schlüssel auf Servern besitzen, wodurch versteckte Zugriffspunkte entstehen, die von Angreifern ausgenutzt werden könnten, die die entsprechenden privaten Schlüssel durch Kompromittierung von Endpunkten, Zugriff auf Backups oder Datenlecks in Repositories entdecken.

• Schlüsselvervielfältigung

  Beim Klonen, Migrieren oder Sichern von Servern werden häufig auch die eingebetteten SSH-Schlüssel kopiert. Dadurch entstehen mehrere Kopien desselben Schlüssels auf verschiedenen Systemen, was unbeabsichtigt den Zugriff erweitert und die Gefährdung über das ursprünglich vorgesehene Maß hinaus erhöht.

• Verlust der Verantwortlichkeit

  Mit der Zeit wird unklar, wer einen Schlüssel erstellt hat, wem er gehört und ob er überhaupt noch benötigt wird. Ohne ein ordnungsgemäßes kryptografisches Inventar ist es nahezu unmöglich, Schlüssel ihren jeweiligen Besitzern, Systemen oder Anwendungen zuzuordnen, was die Reaktion auf Sicherheitsvorfälle, Audits und Zugriffsüberprüfungen extrem erschwert.

• Keine automatische Bereinigung

  Vor fünf oder zehn Jahren erstellte Schlüssel funktionieren weiterhin ohne Unterbrechung. Ohne einen festgelegten Zeitplan für Rotation oder Widerruf erhöhen ruhende Schlüssel das Risiko von Kompromittierung, schleichender Rechteausweitung und unberechtigtem Zugriff erheblich, was möglicherweise erst im Falle eines Vorfalls bemerkt wird.

• Versteckte Angriffsfläche

  Das Zusammenspiel von persistenten, veralteten, doppelten und unüberwachten Schlüsseln schafft eine große, verborgene Angriffsfläche im gesamten Unternehmen. Angreifer nutzen diese verwaisten oder vergessenen Schlüssel aus, um sich lateral zwischen Systemen zu bewegen und ihre Berechtigungen zu erweitern, ohne Authentifizierungsfehler oder Warnmeldungen auszulösen.

Sicherheits-, Betriebs- und Compliance-Risiken

1. Unbegrenzter Zugang

   Ein nicht ablaufender Schlüssel stellt faktisch eine permanente Hintertür dar. Wird der private Schlüssel jemals durch die Kompromittierung eines Endgeräts, ein Datenleck in einem Git-Repository, den Zugriff auf Backups oder durch alte Mitarbeitergeräte offengelegt, erhalten Angreifer uneingeschränkten und unbegrenzten Zugriff auf alle kritischen Server, auf denen dieser öffentliche Schlüssel hinterlegt ist.

2. Privilegien schleichen sich ein

   Schlüssel, die privilegierten Konten (Root-, Administrator- und Dienstkonten) zugeordnet sind, sammeln sich über Jahre an, da Mitarbeiter ihre Rollen ändern und Projekte abgeschlossen werden. Alte Schlüssel bleiben jedoch aktiv. Dies verstößt gegen das Prinzip der minimalen Berechtigungen und schafft Zugriffspfade, die nie überprüft oder bereinigt werden.

3. Verwaltungsaufwand

   Die manuelle Nachverfolgung, Verteilung, Rotation und der Widerruf von Schlüsseln in Hunderten oder Tausenden von Systemen sind zeitaufwändig und fehleranfällig. Das Onboarding verzögert sich durch die notwendige sorgfältige Zugriffsbereitstellung; das Offboarding birgt Risiken, da vergessene Schlüssel unbeaufsichtigte, offene Zugangspunkte hinterlassen.

4. Nullsicht während Zwischenfällen

   Ohne Zeitstempel für die Schlüsselnutzung, Ablaufdaten oder eine zentrale Protokollierung können die Einsatzkräfte nicht feststellen, welche Schlüssel aktiv sind, wer sie verwendet oder auf welche Systeme zugegriffen wurde. Dies erschwert die forensische Analyse und verlängert die Behebungsmaßnahmen erheblich.

5. Compliance-Fehler

   NIST 800-53, CIS Controls, ISO 27001, PCI DSS und SOX fordern die Rotation von Anmeldeinformationen, Zugriffsüberprüfungen und eine korrekte Identitätsbindung. Nicht ablaufende SSH-Schlüssel stehen im direkten Widerspruch zu diesen Anforderungen. Eine vollständige Übersicht der Compliance-Anforderungen finden Sie unter SSH-Schlüsselverwaltung.

6. Risiken unkontrollierter Automatisierung

   CI/CD-Pipelines, Cronjobs und Integrationsskripte verwenden SSH-Schlüssel, die selten geprüft, ausgetauscht oder entfernt werden. Da viele Organisationen kein zentrales Schlüsselmanagement betreiben und auf manuelle Prozesse setzen, sind Automatisierungsschlüssel ideale Ziele für laterale Angriffe: Sie sind in der Regel privilegiert, langlebig und werden nur minimal überwacht.

SSH-Schlüssellebenszyklus-Besitz

Stadium des Lebenszyklus	Aktivität	Eigentümer	vorgelegte Beweise
Generation	Schlüsselpaar mit zugelassenem Algorithmus erstellen (Ed25519 bevorzugt, RSA-3072 mindestens); im zentralen Schlüsselbestand registrieren	Benutzer- oder automatisierte SSH-Schlüsselverwaltungsplattform	Generierungsprotokoll mit Algorithmus, Fingerabdruck und Zweck
Einsatz	Öffentlichen Schlüssel nur auf autorisierten Servern bereitstellen; Zielsysteme und Zugriffsbereich dokumentieren	SSH-Schlüsselverwaltungsplattform	Bereitstellungsprotokoll mit Zielserverliste und autorisiertem Zugriffsbereich
Überwachung	Protokollieren Sie alle SSH-Sitzungen mit Schlüssel-Fingerabdruck, Quell-IP-Adresse, Zeitstempel und Zieladresse; überprüfen Sie diese auf Anomalien.	Sicherheitsoperationen; automatisierte SIEM-Alarmierung	Sitzungsprotokolle für Compliance- und Vorfallsreaktion
Regelmäßige Überprüfung	Überprüfen Sie alle SSH-Schlüsselautorisierungen mindestens vierteljährlich; widerrufen Sie verwaiste oder nicht autorisierte Schlüssel; bestätigen Sie die Inhaberschaft.	Schlüsselverantwortlicher; Zugriffsprüfer	Datum des Prüfberichts mit den ergriffenen Maßnahmen
Rotation	Ersatzschlüssel generieren; neuen öffentlichen Schlüssel bereitstellen; Zugriff überprüfen; alten öffentlichen Schlüssel von allen Servern entfernen	Automatisierte SSH-Schlüsselverwaltungsplattform	Rotationsprotokoll mit Datum, Auslösertyp und Bediener
Widerruf	Entfernen Sie den öffentlichen Schlüssel sofort nach Auslösung des Ereignisses aus allen authorized_keys-Dateien.	Automatisierter Auslöser oder Schlüsseladministrator	Widerrufsprotokoll mit Auslösedatum und Abschlussbestätigung

Auslöser für Rotationsänderungen: Wann Sie sofort handeln müssen

• Ausscheiden oder Funktionswechsel des Mitarbeiters: Entziehen Sie unverzüglich alle SSH-Schlüssel, die der ausscheidende oder die Rolle wechselnde Mitarbeiter auf allen Servern besitzt, auf die er Zugriff hatte. Dokumentieren Sie die Zeitspanne von der Kündigung bis zum Abschluss des Entzugs als Nachweis der Einhaltung der Vorschriften.
• Verdacht auf oder bestätigte Kompromittierung eines Schlüssels: Der betroffene Schlüssel wird unverzüglich auf allen Servern, auf denen er autorisiert ist, widerrufen; ein Ersatzschlüssel wird generiert und bereitgestellt; das Ausmaß der Gefährdung wird untersucht.
• Archiv oder Bildveröffentlichung: Wenn ein privater Schlüssel in einem Code-Repository, einem Container-Image oder einem gemeinsam genutzten Artefakt gefunden wird, behandeln Sie ihn sofort als kompromittiert und befolgen Sie den Workflow für die Reaktion auf einen Sicherheitsvorfall.
• Algorithmus veraltet: Jeder Schlüssel, der einen veralteten Algorithmus verwendet (DSA ist kryptografisch unsicher; RSA-1024 wird nicht mehr empfohlen; ssh-rsa mit SHA-1 wurde in OpenSSH 8.8 als veraltet markiert), muss durch einen zugelassenen Algorithmus ersetzt werden. Siehe Vergleich von SSH-Schlüsseln zur algorithmischen Steuerung.
• Systemstilllegung: Alle mit den außer Betrieb genommenen Systemen verbundenen SSH-Schlüssel werden widerrufen; die verbleibenden Systeme werden überprüft, um sicherzustellen, dass sich in ihren authorized_keys-Dateien kein öffentlicher Schlüssel des außer Betrieb genommenen Hosts mehr befindet.

Anforderungen an Zugangsrichtlinien und Prüfungsnachweise

• Richtlinienanforderungen: Die SSH-Schlüsselverwaltungsrichtlinie muss Kryptoperioden nach Risikostufe definieren (Benutzerschlüssel alle 90 Tage; Service-/Automatisierungsschlüssel alle 180 Tage; Schlüssel mit hohem Risiko alle 30 bis 90 Tage); Algorithmusanforderungen (Ed25519 bevorzugt; RSA-3072 Minimum; DSA verboten); Verbot der gemeinsamen Nutzung von Schlüsseln; Verbot von fest codierten Schlüsseln in Code und Images; Zeitplan für die Zugriffsüberprüfung (mindestens vierteljährlich).
• Inventarnachweise: Ein aktuelles Inventar, das jeden Schlüssel, seinen Fingerabdruck, den Besitzer, die Bereitstellungsserver, den Zugriffsbereich, das Erstellungsdatum und das Datum der letzten Rotation auflistet, ist erforderlich. Ohne dieses Inventar lässt sich keine andere Compliance-Kontrolle nachweisen.
• Rotations- und Widerrufsregister: Datierte Protokolle, aus denen hervorgeht, dass Schlüssel planmäßig oder ereignisgesteuert rotiert wurden, sowie Widerrufsdatensätze, die die Zeit vom Auslöseereignis bis zum Abschluss für jeden widerrufenen Schlüssel angeben.
• Sitzungsprotokolle: Privilegierte SSH-Sitzungsprotokolle mit Schlüsselfingerabdruck, Quell-IP-Adresse, Zeitstempel und Zielsystem, die für den von den geltenden Compliance-Rahmenbedingungen vorgeschriebenen Zeitraum aufbewahrt werden.
• Zugriffsprüfungsprotokolle: datierte Quartalsberichte, aus denen hervorgeht, welche Schlüssel überprüft wurden, der Eigentumsstatus und die ergriffenen Maßnahmen.

Risikominderung bei SSH-Schlüsseln mit unbegrenzter Gültigkeit

1. Zentralisierte Schlüsselverwaltung

   Eine zentrale SSH-Schlüsselverwaltungsplattform bietet: vollständige Transparenz aller Schlüssel, einschließlich Eigentümer, Zweck und Nutzungshistorie; Durchsetzung von Richtlinien für Rotationsintervalle, zulässige Schlüsseltypen und Mindestschlüssellängen; automatisierte Bereitstellung und Deaktivierung; sowie Auditierung und Berichterstellung zur Überprüfung der Compliance. Die Zentralisierung wandelt SSH-Schlüssel von unkontrollierten Datenträgern in nachvollziehbare und auditierbare Zugangsdaten um. Weitere Informationen zum Plattformansatz finden Sie unter SSH Secure .

2. Wichtige Rotation gemäß Zeitplan und Veranstaltung

   Regelmäßige Rotation gewährleistet, dass SSH-Schlüssel im Verhältnis zu ihrem Risikopotenzial nur kurz gültig sind. Empfohlener Zeitplan: Benutzerschlüssel alle 90 Tage; Schlüssel für Service- und Automatisierungskonten alle 180 Tage. Ereignisse (z. B. Ausscheiden, Kompromittierung, Außerbetriebnahme) haben Vorrang vor diesem Zeitplan. Automatisieren Sie die Rotation mithilfe zentralisierter Tools, anstatt sich auf manuelle Prozesse zu verlassen, die schlecht skalieren und Inkonsistenzen erzeugen, die zu Beanstandungen bei Audits führen können.

3. Schlüsselsperrung

   Schlüssel, die mit ausscheidenden Mitarbeitern, stillgelegten Systemen oder mutmaßlichen Kompromittierungen verknüpft sind, müssen umgehend widerrufen werden. Der Widerruf umfasst das Entfernen öffentlicher Schlüssel aus allen autorisierten Schlüsseldateien, die Aktualisierung des zentralen Schlüsselinventars und die Protokollierung des Vorgangs für Prüfungszwecke. Der manuelle Widerruf auf Hunderten von Servern ist die häufigste Fehlerquelle für Unternehmen beim Ausscheiden von Mitarbeitern. Der automatisierte Widerruf, ausgelöst durch HR-Systeme oder Ereignisse von Identitätsanbietern, stellt die zuverlässige Alternative dar.

4. Ephemere SSH-Schlüssel verwenden

   Statt statischer Schlüssel werden SSH-Zugangsdaten bedarfsgesteuert generiert und sind nur kurzzeitig (Minuten oder Stunden) gültig. Ephemere Schlüssel verhindern die langfristige Offenlegung statischer Schlüssel, laufen automatisch ab und lassen sich in Identitätsanbieter und Just-in-Time-Zugriffsprozesse integrieren. Selbst im Falle einer Offenlegung ist das Zugriffsfenster für Angreifer begrenzt. Den vollständigen Implementierungsansatz finden Sie unter „Statische SSH-Schlüssel in kurzlebige Workload-Identitäten umwandeln“ .

5. Umstellung auf kurzlebige SSH-Zertifikate

   Organisationen mit ausgereiften Sicherheitsprogrammen ersetzen statische Schlüssel durch kurzlebige SSH-Zertifikate einer vertrauenswürdigen Zertifizierungsstelle. Vorteile: Integriertes Ablaufdatum auf Protokollebene; starke Identitätsbindung für jeden Benutzer oder Dienst; zentralisiertes Vertrauensmodell, das die Verwaltung von autorisierten Schlüsseln pro Server überflüssig macht; und automatisch generierte Compliance-Nachweise aus dem Ausstellungsprotokoll der Zertifizierungsstelle. Einen Vergleich finden Sie unter „SSH-Schlüssel vs. SSH-Zertifikate“ .

6. Betriebliche Härtung des SSH-Zugriffs

   Die Serverhärtung schränkt die Möglichkeiten eines Angreifers selbst mit einem gültigen Schlüssel ein: Root-Login deaktivieren; Passwortauthentifizierung deaktivieren; MaxAuthTries begrenzen; Zugriff nach Benutzer, Gruppe oder Quell-IP beschränken; starke kryptografische Algorithmen in sshd_config erzwingen; Agent-Weiterleitung deaktivieren, sofern nicht ausdrücklich erforderlich. Die vollständige Checkliste zur Serverhärtung finden Sie unter „Die besten Methoden zum Schutz Ihrer SSH-Schlüssel“ .

7. Politik und Überwachung

   Eine formale SSH-Schlüsselverwaltungsrichtlinie muss Folgendes beinhalten: die Führung eines aktuellen Verzeichnisses aller Schlüssel; die Definition des sofortigen Entzugs bei Kompromittierung; die Überwachung auf durchgesickerte oder offengelegte private Schlüssel; und die Durchführung regelmäßiger vierteljährlicher Zugriffsüberprüfungen, um verwaiste, veraltete, doppelte oder unautorisierte Schlüssel zu erkennen und zu entfernen. Die Sitzungsüberwachung muss so konfiguriert sein, dass sie bei anomalen Zugriffsmustern Alarm auslöst.

Reaktion auf einen Vorfall bei Kompromittierung eines SSH-Schlüssels

1. Sofortiger Widerruf: Den kompromittierten Schlüssel auf allen Servern, auf denen er autorisiert ist, widerrufen; die vollständige Widerrufung auf jedem Server bestätigen; den Zeitstempel des Abschlusses protokollieren.
2. Generierung und Bereitstellung von Ersatzschlüsseln: Generieren Sie nach Möglichkeit innerhalb eines HSM ein neues Schlüsselpaar mithilfe eines zugelassenen Algorithmus (Ed25519 bevorzugt; RSA-4096 für ältere Systeme); stellen Sie den neuen öffentlichen Schlüssel auf allen autorisierten Servern bereit; überprüfen Sie, ob der Zugriff für den rechtmäßigen Benutzer wiederhergestellt wurde.
3. Untersuchung des Belichtungsumfangs: Identifizieren Sie alle Systeme, die mit dem kompromittierten Schlüssel erreichbar waren; überprüfen Sie die SSH-Sitzungsprotokolle auf Aktivitäten während des vermuteten Kompromittierungszeitraums; ermitteln Sie, ob ein unberechtigter Zugriff stattgefunden hat und welche Daten oder Systeme betroffen waren.
4. Benachrichtigung der Interessengruppen: Benachrichtigen Sie die Sicherheitsleitung, die betroffenen Systemverantwortlichen und, falls regulierte Daten über den kompromittierten Schlüssel zugänglich waren, gegebenenfalls die Aufsichtsbehörden oder betroffene Personen gemäß den Meldepflichten bei Datenschutzverletzungen.
5. Aktualisierung der Ursachenanalyse und Kontrollmaßnahmen: Dokumentieren Sie, wie der Schlüssel offengelegt wurde (Dateispeicherung auf kompromittiertem Host, fest im Code codiert, verwaister Schlüssel wurde beim Ausscheiden nicht widerrufen); aktualisieren Sie die Kontrollen, um die Lücke zu schließen (Migration zu HSM-Speicher, Implementierung eines automatisierten Offboardings, Hinzufügen von Secret-Scanning zu CI/CD-Pipelines).

Wie Verschlüsselungsberatung helfen kann

Wir von Encryption Consulting verstehen die Herausforderungen, denen sich Unternehmen bei der Verwaltung von SSH-Schlüsseln in großem Umfang gegenübersehen. SSH Secure bietet umfassende Sicherheit für den gesamten Schlüssellebenszyklus und vollständige Transparenz:

1. Zentralisierte Sichtbarkeits- und Eigentumszuordnung

   Die agentenbasierte und agentenlose Erkennung findet jeden SSH-Schlüssel auf Servern und Benutzerrechnern. Alle Schlüssel werden in einem einheitlichen Inventar mit Eigentümer- und Nutzungsdetails gespeichert, wodurch verwaiste Schlüssel vermieden und die vollständige Nachvollziehbarkeit in der gesamten Umgebung gewährleistet wird.

2. Schlüsselrotation auf Abruf und nach Zeitplan

   SSH Secure ermöglicht sowohl die bedarfsgesteuerte als auch die zeitgesteuerte Schlüsselrotation. Mit einem einzigen Klick lassen sich Schlüssel automatisch rotieren, wodurch ihre kurze Lebensdauer gewährleistet und das Risiko eines Angriffs minimiert wird. Gleichzeitig behalten Sie jederzeit die volle Transparenz über die aktiven Zugangsdaten.

3. Schlüsselwiderruf auf Anfrage

   SSH Secure eliminiert das Risiko nicht ablaufender SSH-Schlüssel durch einen zuverlässigen Widerruf. Schlüssel, die mit ausscheidenden Mitarbeitern, stillgelegten Systemen oder mutmaßlich kompromittierten Systemen verknüpft sind, können sofort deaktiviert werden, wobei die Weitergabe auf allen Servern bestätigt wird. Der zentrale Widerruf stellt sicher, dass keine vergessenen oder verwaisten Schlüssel im Produktivbetrieb verbleiben.

4. Automatisierte Orchestrierung des Schlüssellebenszyklus

   Über Rotation und Widerruf hinaus automatisiert SSH Secure den gesamten Lebenszyklus: sichere Generierung, richtlinienbasierte Rotation, geplantes Ablaufdatum und Widerruf. Dies reduziert den manuellen Aufwand, gewährleistet die kontinuierliche Einhaltung von Sicherheitsstandards und beseitigt operative Sicherheitslücken aufgrund menschlicher Fehler.

5. Ephemere und sitzungsgebundene Schlüssel

   Für sensible Vorgänge verwendet SSH Secure temporäre, sitzungsgebundene Schlüssel, die automatisch ablaufen. Dieser Ansatz gewährleistet den Zugriff nach dem Prinzip der minimalen Berechtigungen, reduziert die Auswirkungen kompromittierter Anmeldeinformationen und eliminiert die langfristige Gefährdung durch statische Schlüssel.

6. HSM-integrierter Schutz

   Alle privaten Schlüssel sind innerhalb der HSMs gesichert : nicht exportierbar und manipulationssicher. Die Schlüssel werden mit RSA, ECDSA und Ed25519 generiert. Selbst ein Angriff auf Betriebssystemebene oder das Auslesen des Arbeitsspeichers können die Schlüssel nicht von der HSM-Hardwaregrenze extrahieren.

7. Richtliniengesteuerte Kontrolle für wichtige operative Abläufe

   Alle wichtigen Vorgänge (Erstellung, Genehmigung, Rotation, Widerruf) werden durch richtlinienbasierte Kontrollen durchgesetzt, um Konsistenz in der gesamten Umgebung zu gewährleisten, manuelle Fehler zu reduzieren und Sicherheitsstandards aufrechtzuerhalten, die an regulatorische Anforderungen anpassbar sind.

8. Kontinuierliche Überwachung, Prüfung und Bereitschaft zur Einhaltung von Vorschriften

   Echtzeitüberwachung mit detaillierter Ereignisprotokollierung und Anomalieerkennung. Splunk- und Loki-Grafana-Integration für Visualisierung und Alarmierung. Herunterladbare Protokolle und detaillierte Compliance-Berichte zur Überprüfung durch den Gutachter. Zentralisierte Überwachung mit richtlinienbasierten Warnmeldungen ermöglicht proaktives Management und schnellere Reaktion auf Vorfälle.

Fazit

SSH-Schlüssel ohne Ablaufdatum stellen ein verstecktes, aber ernstes Sicherheitsrisiko für Unternehmen dar. Vergessene, verwaiste und nicht verwaltete Schlüssel ermöglichen dauerhaften Zugriff, fördern die Ausweitung von Berechtigungen und schaffen unkontrollierte Einfallstore in der Infrastruktur, die weder für Sicherheitsteams noch für Compliance-Prüfer sichtbar sind. Die Lösung besteht darin, die systembedingten Schwächen von SSH zu beheben: Ablaufdatum, Rotationspläne, zentrale Schlüsselverwaltung und automatische Sperrung bei bestimmten Ereignissen im Lebenszyklus.

Ein formales SSH-Schlüssel-Lebenszyklusmanagement-Programm, das eine zentrale Bestandsverwaltung, risikobasierte Rotation, automatisierten Widerruf, HSM-gestützten Schlüsselschutz, temporäre Schlüssel für die Automatisierung und kontinuierliche Sitzungsprotokollierung kombiniert, wandelt den SSH-Zugriff von einem unkontrollierten Risiko in einen auditierbaren, kontrollierten und konformen Authentifizierungsmechanismus um. Weiterführende Informationen finden Sie unter „ Die besten Methoden zum Schutz Ihrer SSH-Schlüssel“ , „SSH-Schlüsselmanagement-Compliance“ und „Statische SSH-Schlüssel in kurzlebige Workload-Identitäten umwandeln“.

Häufig gestellte Fragen

Warum laufen SSH-Schlüssel nicht standardmäßig ab?

SSH wurde entwickelt, um eine starke kryptografische Authentifizierung ohne Passwort über das Netzwerk zu ermöglichen. Das Ablaufdatum wurde als operative Richtlinie und nicht als Protokollkontrolle behandelt. NIST NISTIR 7966 bestätigt, dass SSH keine integrierten Mechanismen für den Ablauf, die Erneuerung oder die automatische Gültigkeitsprüfung von Schlüsseln besitzt. Die Governance muss die vom Protokoll nicht bereitgestellten Ablaufkontrollen implementieren.

Welche Sicherheitsrisiken bergen SSH-Schlüssel, die nie ablaufen?

Sechs Kategorien: uneingeschränkter Zugriff (die Offenlegung des privaten Schlüssels gewährt unbegrenzten Zugriff auf alle autorisierten Server); schleichende Rechteausweitung (Schlüssel, die dem Root- oder Admin-Benutzer zugeordnet sind, häufen sich bei Rollenwechseln an); Verwaltungsaufwand (manuelle Nachverfolgung ist schlecht skalierbar); fehlende Transparenz bei Vorfällen (keine Zeitstempel oder zentralisierte Protokolle); Compliance-Verstöße (NIST 800-53, ISO 27001, PCI DSS, CIS erfordern alle Rotation und Zugriffsüberprüfungen); und Automatisierungsrisiken (CI/CD-Pipeline-Schlüssel werden selten geprüft oder rotiert).

Wie oft sollten SSH-Schlüssel rotiert werden?

Benutzer-SSH-Schlüssel alle 90 Tage; Service- und Automatisierungskontoschlüssel alle 180 Tage; Schlüssel mit Root- oder Produktionszugriff alle 30 bis 90 Tage. Ereignisse wie Mitarbeiterausscheiden, Verdacht auf Kompromittierung, Algorithmus-Altstellung und Systemstilllegung erfordern sofortiges Handeln.

Worin besteht der Unterschied zwischen SSH-Schlüsselrotation und SSH-Schlüsselwiderruf?

Bei der Schlüsselrotation wird ein bestehender Schlüssel durch einen neuen ersetzt, wobei der Zugriff erhalten bleibt (neuer Schlüssel generiert, neuer öffentlicher Schlüssel bereitgestellt, alter Schlüssel entfernt). Dies ist ein geplanter Vorgang im Lebenszyklus. Die Widerrufung hingegen ist die sofortige Entfernung eines Schlüssels als Reaktion auf ein auslösendes Ereignis (Ausscheiden, Kompromittierung, Richtlinienverstoß), wodurch der Zugriff für denselben Benutzer beendet wird, ohne dass ein Ersatzschlüssel generiert wird.

Worin unterscheiden sich ephemere SSH-Schlüssel von langlebigen SSH-Schlüsseln?

Langlebige Schlüssel bleiben unbegrenzt erhalten, bis sie manuell von jedem Server entfernt werden. Ephemere Schlüssel werden bedarfsgesteuert für eine bestimmte Sitzung oder ein bestimmtes Zeitfenster generiert und laufen automatisch ab. Selbst wenn sie offengelegt werden, endet der Zugriff eines Angreifers mit dem Ende des Zeitfensters. Besonders effektiv ist diese Methode in CI/CD-Pipelines, wo sich statische, eingebettete Schlüssel ansammeln und selten ausgetauscht werden.

Welche Nachweise benötigen Compliance-Auditoren für das SSH-Schlüssel-Lebenszyklusmanagement?

Aktuelles Schlüsselinventar (jeder Schlüssel mit Eigentümer, Speicherort, Erstellungsdatum, Datum der letzten Rotation); Zugriffsprüfungsprotokolle (vierteljährlich, mit ergriffenen Maßnahmen); Rotationsnachweise (Datum, Auslösertyp, Bediener); Widerrufsnachweise (Auslösedatum, Abschlussdatum pro ausgeschiedenem Mitarbeiter); Sitzungsprotokolle (Schlüssel-Fingerabdruck, Quell-IP, Zeitstempel, Ziel); und schriftliche SSH-Schlüsselverwaltungsrichtlinie mit Kryptoperioden und Verfahren zur Reaktion auf Sicherheitsvorfälle.