Warum ist SSH-Schlüsselmanagement in der modernen Sicherheit wichtig?

Veröffentlicht: Dezember 2025. Aktualisiert: August 2026. Geprüft vom SSH-Schlüsselmanagement-Team von Encryption Consulting.

Dieser Artikel erläutert die geschäftlichen Vorteile des SSH-Schlüsselmanagements: Warum es auf der Prioritätenliste von IT-Sicherheitsverantwortlichen stehen sollte, welche Kosten bei unzureichendem Management entstehen und wie eine angemessene Reaktion aussieht. Für die vollständige operative Anleitung, die Ermittlung, die Zuordnung von Schlüsselbesitz, die Rotationsrichtlinie, die Zugriffskontrollen und die Erstellung von Auditberichten konsultieren Sie unseren umfassenden Leitfaden zum SSH-Schlüssellebenszyklusmanagement.

Warum ist SSH-Schlüsselverwaltung eine moderne Sicherheitspriorität?

Die Verwaltung von SSH-Schlüsseln ist heutzutage eine zentrale Sicherheitsaufgabe, da SSH-Schlüssel direkten, oft unkontrollierten Zugriff auf die Server, Cloud-Workloads und Automatisierungspipelines ermöglichen, die den Geschäftsbetrieb steuern. Reale Vorfälle zeigen, welche Folgen es hat, wenn dieser Zugriff außer Kontrolle gerät. Anders als ein Passwort läuft ein SSH- Schlüssel nicht von selbst ab. Ein Schlüssel, der einem externen Dienstleister, einem ausgeschiedenen Mitarbeiter oder einem stillgelegten Automatisierungsskript ausgestellt wurde, bleibt so lange gültig, bis er explizit gefunden und entfernt wird. In den meisten Unternehmen kümmert sich niemand darum.

Was reale Vorfälle über nicht verwaltete SSH-Schlüssel aussagen

Zwei gut dokumentierte und nachweisbare Vorfälle verdeutlichen das Risiko. Im Januar 2023 infizierte sich ein Mitarbeiter von CircleCI mit Schadsoftware auf seinem privaten Laptop. Diese stahl einen aktiven Session-Cookie, wodurch der Angreifer sich als der Mitarbeiter ausgeben und auf Produktionssysteme zugreifen konnte. Der Vorfallbericht von CircleCI bestätigte, dass der Angreifer Umgebungsvariablen, Token und Schlüssel von Kunden exfiltriert hatte. Das Unternehmen empfahl daraufhin allen Kunden vorsorglich, SSH-Schlüssel, GitHub-OAuth-Token, API-Token und andere gespeicherte Geheimnisse regelmäßig zu wechseln ( CircleCI, Vorfallbericht vom 4. Januar 2023 ). Ein einziger kompromittierter Laptop führte zu einem unternehmensweiten Austausch von Zugangsdaten in Tausenden von Kundenumgebungen.

Zwei Monate später stellte GitHub fest, dass sein eigener RSA-SSH-Hostschlüssel kurzzeitig in einem öffentlichen Repository offengelegt worden war. GitHub ersetzte den Schlüssel innerhalb von etwa 30 Minuten nach der Entdeckung und veröffentlichte einen detaillierten Bericht über die Behebung des Problems. Der Vorfall verdeutlichte jedoch: Selbst einem Unternehmen mit einer sicheren Infrastruktur kann es passieren, dass ein SSH-Schlüssel unbemerkt in die Öffentlichkeit gelangt. Nur ein schneller und geübter Schlüsselwechsel konnte den Schaden begrenzen ( GitHub, 23. März 2023 ). In beiden Fällen war es nicht nötig, die SSH-Verschlüsselung zu knacken. In beiden Fällen war lediglich ein offengelegter Schlüssel erforderlich, und die Reaktionsgeschwindigkeit entschied jeweils über den Ausgang.

Was unkontrollierter SSH-Zugriff kostet

Laut dem IBM- Bericht „Cost of a Data Breach Report 2025“ sanken die weltweiten Durchschnittskosten eines Datenlecks auf 4.44 Millionen US-Dollar – der erste Rückgang seit fünf Jahren. Die durchschnittliche Dauer eines Datenlecks, also die Zeit von der Identifizierung bis zur Eindämmung, beträgt jedoch weiterhin 241 Tage. Derselbe Bericht stellt fest, dass gestohlene oder kompromittierte Zugangsdaten nach wie vor eine der häufigsten Methoden für Angreifer sind, sich Zugang zu verschaffen. Datenlecks, die mit gestohlenen Zugangsdaten beginnen, benötigen demnach etwa 246 Tage bis zur Identifizierung und Eindämmung – fast acht Monate unentdeckter Zugriff. Ein SSH-Schlüssel ist ein Zugangsdokument wie jedes andere, authentifiziert sich jedoch in der Regel allein durch den Besitz, ohne Passwortabfrage und ohne Warnmeldung bei fehlgeschlagener Anmeldung, die einen Missbrauch signalisiert.

NIST IR 7966, „ Security of Interactive and Automated Access Management Using Secure Shell (SSH)“ , ist die wichtigste US-Bundesrichtlinie zu diesem Risiko. Sie fordert Organisationen auf, den SSH-Zugriff über einen dokumentierten Lebenszyklus – Anfrage, Genehmigung, Bereitstellung, Überwachung und Widerruf – abzuwickeln, anstatt die Schlüsselausgabe als einmalige technische Aufgabe zu behandeln ( NIST IR 7966 ). Die CISA-Richtlinien zu schwachen Sicherheitskontrollen, die regelmäßig für den Erstzugriff ausgenutzt werden, bekräftigen diese Aussage aus Sicht der Angreifer: Vorhersehbare, unkontrollierte Anmeldeinformationen, nicht etwa gebrochene Kryptografie, sind das eigentliche Ziel von Angreifern ( CISA AA22-137A ).

Was passiert, wenn SSH-Schlüssel nicht verwaltet werden?

Nicht verwaltete SSH-Schlüssel bergen drei sich gegenseitig verstärkende Sicherheitslücken: Sie gehören niemandem, niemand rotiert sie, und niemand kontrolliert ihre Berechtigungen. Jede Lücke für sich genommen ist geringfügig. Zusammen verwandeln sie jedoch eine routinemäßige Zugangsberechtigung in ein ständiges, unkontrolliertes Risiko.

Lücken im Lebenszyklus-Vermögen

Jeder SSH-Schlüssel benötigt ab dem Zeitpunkt seiner Ausstellung einen benannten Besitzer – eine bestimmte Person oder ein bestimmtes Dienstkonto, das die weitere Verwendung des Schlüssels bestätigt. In den meisten Umgebungen werden Schlüssel lokal von den jeweiligen Zugriffsberechtigten generiert, ohne dass ein Verzeichniseintrag oder ein Genehmigungsprozess dahintersteckt. Verlässt die betreffende Person das Unternehmen, ändert sie ihre Rolle oder wird die Automatisierung, die den Schlüssel verwendet hat, außer Betrieb genommen, ist keine Überprüfung erforderlich. Der Schlüssel funktioniert einfach weiter. Unser Leitfaden zur SSH-Schlüsselverwaltung beschreibt, wie Sie die Besitzverhältnisse für eine bestehende Schlüsselpopulation vor Ihrer nächsten Zugriffsprüfung wiederherstellen.

Rotationsauslöser, die nie auslösen

Die meisten Organisationen rotieren SSH-Schlüssel, wenn überhaupt, nach einem festen Kalender. Dabei werden wichtige Ereignisse übersehen: der Verdacht auf ein Sicherheitsrisiko, der Austritt eines Mitarbeiters, eine neu entdeckte Sicherheitslücke (CVE) in der SSH-Software, gegen die der Schlüssel authentifiziert wird, oder eine Änderung der Zugriffsrechte des Schlüssels. Ereignisgesteuerte Rotation erfasst diese Lücken. Ein Schlüssel, der am Tag nach seiner letzten geplanten Rotation gestohlen wird, bleibt bei einer rein periodischen Rotation monatelang gültig.

Schwache Zugriffsrichtlinie

Das Prinzip der minimalen Berechtigungen gilt für SSH genauso wie für alle anderen Anmeldeinformationen, wird aber in der Praxis selten durchgesetzt. Schlüssel werden häufig mit umfassendem, uneingeschränktem Shell-Zugriff ausgestellt, anstatt auf ein bestimmtes System, einen Befehl oder eine Quell-IP beschränkt zu sein. Derselbe Schlüssel wird oft auf mehreren Servern wiederverwendet, da die Bereitstellung eines eindeutigen Schlüssels für jede Verbindung aufwändiger ist als das Kopieren eines bereits funktionierenden Schlüssels. Ein kompromittierter Endpunkt kann dann auf alles zugreifen, was mit diesem Schlüssel verbunden ist.

Jede dieser drei Lücken – Eigentumsverhältnisse, Rotation und Zugriffsrichtlinien – wird in unserem umfassenden Leitfaden zum SSH-Schlüssellebenszyklusmanagement detailliert beschrieben, einschließlich eines schrittweisen Designprozesses für jede einzelne.

Welche Lücken in den Prüfungsnachweisen führen zum Scheitern von Compliance-Prüfungen?

Compliance-Rahmenwerke wie PCI DSS, HIPAA, SOC 2 und ISO 27001 verlangen von Unternehmen den Nachweis der Kontrolle über privilegierte Zugriffe und nicht nur die Beschreibung einer Richtlinie in einem Dokument. Für SSH bedeutet dies, auf Anfrage ein aktuelles Verzeichnis aller Schlüssel, den jeweiligen dokumentierten Eigentümer, den Zeitpunkt der letzten Schlüsselrotation und den Nachweis, dass der Zugriff umgehend widerrufen wurde, sobald er nicht mehr benötigt wurde, vorlegen zu können.

Die meisten Organisationen scheitern an diesem Test nicht etwa, weil ihnen eine Richtlinie fehlt, sondern weil diese nicht durchgesetzt wird. NIST IR 7966 empfiehlt, dass jede SSH-Zugriffsanfrage eine dokumentierte geschäftliche Begründung und eine definierte Beendigungsbedingung enthalten sollte. Ohne ein zentrales Verzeichnis erhält ein Prüfer, der fragt: „Wer hatte an diesem Datum Zugriff auf diesen Server?“, jedoch nur Vermutungen aus verstreuten Protokollen anstelle eines Berichts aus einem zentralen System. Diese Lücke verwandelt ein routinemäßiges Audit in eine mehrwöchige Beweissammlung, und genau diese Beweislücke verlangsamt auch die Untersuchung von Sicherheitsvorfällen, wenn tatsächlich etwas schiefgeht.

Warum reichen native Cloud- oder Betriebssystem-Tools bei großem Umfang nicht aus?

Native Tools funktionieren nur im kleinen Rahmen und stoßen mit zunehmender Größe der Umgebung an ihre Grenzen, da keines von ihnen für die spezifischen Fragen der SSH-Schlüsselverwaltung entwickelt wurde: Wem gehört dieser Schlüssel, wann wurde er zuletzt verwendet und überall wird ihm vertraut.

Ansatz	Was es abdeckt	Wo es kaputt geht
Native Betriebssystem-Tools (authorized_keys, Cloud-Konsolen-Schlüsselpaare)	Grundlegende Schlüsselbereitstellung auf einzelnen Hosts oder Instanzen	Keine zentrale Bestandsverwaltung, keine Eigentumsnachweise, keine automatische Rotation oder Widerrufung innerhalb der Flotte
Universelle PAM-Plattformen	Gesicherte Passwörter und vermittelte, sitzungsbasierte Anmeldungen	SSH-Schlüssel authentifizieren sich direkt gegen die authorized_keys-Datei des Servers, außerhalb des Schlüsselspeichers, sodass lokal generierte Schlüssel für PAM vollständig unsichtbar sind.
Dediziertes SSH-Schlüssel-Lebenszyklusmanagement	Erkennung, Zuordnung von Eigentumsrechten, richtliniengesteuerte Rotation, HSM-gestützte Speicherung und kontinuierliche Prüfnachweise für die gesamte Schlüsselpopulation	Erfordert eine bewusste Einführung; ersetzt weder die Härtung des Hostsystems noch die Netzwerksegmentierung.

SSH-Schlüssel werden sofort nach dem Hinzufügen zu einem Server als vertrauenswürdig eingestuft, unabhängig von Tresoren, Verzeichnissen oder Genehmigungssystemen. Genau das macht SSH so effizient für die Automatisierung und gleichzeitig unsichtbar für Tools, die auf einem anderen Vertrauensmodell basieren. Unser Leitfaden zu nicht verwalteten SSH-Schlüsseln als Sicherheitslücke im privilegierten Zugriff erläutert, warum diese Schwachstelle selbst in Unternehmen mit ausgereiften PAM-Programmen weiterhin besteht. Unser Leitfaden zur Multi-Cloud-SSH-Schlüsselverwaltung geht auf die spezifischen Unterschiede zwischen der nativen Schlüsselverwaltung von AWS, Azure und Google Cloud ein.

Wie sieht die Reaktion auf einen Sicherheitsvorfall aus, wenn die SSH-Schlüsselverwaltung fehlschlägt?

Wenn ein SSH-Schlüssel offengelegt oder missbraucht wird, entscheidet die Reaktionsgeschwindigkeit darüber, ob es zu einem Beinahe-Unfall oder einem Sicherheitsvorfall kommt. CircleCIs eigener Bericht über den Vorfall im Jahr 2023 verdeutlicht dieses Muster: Die Offenlegung wurde erkannt, der Zugriff eingeschränkt, alle betroffenen Zugangsdaten auf allen betroffenen Systemen ausgetauscht und die vollständige Aktualisierung überprüft, bevor der Vorfall als abgeschlossen erklärt wurde. GitHubs Reaktion auf den offengelegten Host-Schlüssel folgte demselben Muster und dauerte nur etwa 30 Minuten, da das Ausmaß des potenziellen Sicherheitsvorfalls bereits bekannt war.

Organisationen ohne Schlüsselinventar scheitern oft nicht an der Schlüsselrotation selbst, sondern daran, jeden Host zu finden, der dem offengelegten Schlüssel vertraut. Ohne eine zentrale Datenbank muss diese Suche manuell, Host für Host, erfolgen, was die Reaktionszeit von Minuten auf Tage verlängert. Den vollständigen Prozess von der Erkennung bis zur Wiederherstellung, einschließlich der in jedem Schritt zu erfassenden Prüfnachweise, finden Sie in unserem Leitfaden zur Reaktion auf Sicherheitsvorfälle mit offengelegten SSH-Schlüsseln.

Wie behält man die Kontrolle über die SSH-Schlüsselverwaltung?

Die Verwaltung von SSH-Schlüsseln erfolgt in einem wiederholbaren Ablauf. Jeder der folgenden Schritte wird in unserem umfassenden Leitfaden zum SSH-Schlüssellebenszyklus detailliert beschrieben, inklusive spezifischer Tools und Richtlinien. Dieser Leitfaden dient Sicherheitsverantwortlichen als Orientierungshilfe.

1. Entdecke jeden Schlüssel. Scannen Sie jeden Server, jede Cloud-Instanz, jeden Container und jedes CI/CD-System nach SSH-Schlüsseln mithilfe agentenbasierter und agentenloser Methoden, da keine der beiden Methoden allein alle Bereiche erfasst.
2. Weisen Sie jedem Schlüssel einen Besitzer zu. Kein Schlüssel verbleibt in der Umgebung, ohne dass eine namentlich genannte Person oder ein Servicekonto dafür verantwortlich ist.
3. Legen Sie Rotationsauslöser fest, nicht nur einen Kalender. Kombinieren Sie eine definierte Kryptoperiode mit ereignisbasierten Auslösern wie Offboarding, Verdacht auf Gefährdung und einer neuen CVE, damit die Rotation dann erfolgt, wenn es wirklich darauf ankommt.
4. Das Zugriffsprinzip der minimalen Berechtigungen durchsetzen. Weisen Sie den Schlüsseln die spezifischen Systeme und Befehle zu, die eine Rolle erfordert, und vermeiden Sie die Wiederverwendung desselben Schlüssels auf nicht verwandten Hosts.
5. Zentralisierung der Protokollierung und der Prüfnachweise. Erfassen Sie Eigentumsverhältnisse, Rotationshistorie und Nutzung in einem System, damit ein Prüfer oder ein Incident Responder einen Bericht erhält und nicht suchen muss.
6. Wo immer möglich, sollten kurzlebige SSH-Zertifikate verwendet werden. Ein Zertifikat, das von selbst abläuft, beseitigt das Problem der verwaisten Schlüssel an der Wurzel, anstatt sich darauf zu verlassen, dass jemand an die Bereinigung denkt.

Risikoszenario, Konsequenz und erster Minderungsschritt

Nutzen Sie diese Tabelle, um ein tatsächliches Risiko in Ihrer Organisation der ersten, direktesten Maßnahme zuzuordnen, nicht dem gesamten Sanierungsprojekt.

Risikoszenario	Folge	Erster Minderungsschritt
Verwaister Schlüssel eines ausgeschiedenen Mitarbeiters oder Auftragnehmers	Der Zugriff bleibt unbegrenzt bestehen, ohne dass jemand auf Missbrauch achtet.	Führen Sie eine vollständige Schlüsselermittlung durch und widerrufen Sie alle Schlüssel ohne bestätigten Besitzer.
Keine Rotationsrichtlinie, oder eine Richtlinie, die niemand durchsetzt.	Ein vor Monaten gestohlener Schlüssel ist oft auch heute noch gültig.	Definieren Sie zeit- und ereignisbasierte Rotationsauslöser und automatisieren Sie diese anschließend.
Derselbe Schlüssel wird auf vielen Servern wiederverwendet.	Ein kompromittierter Endpunkt führt zu einem Flottenvorfall.	Wechseln Sie zu identitätsbezogenen Schlüsseln oder kurzlebigen SSH-Zertifikaten.
Keine zentrale SSH-Schlüsselverwaltung oder Protokollierung	Die Frage „Wer hatte während einer Prüfung oder eines Vorfalls Zugriff?“ kann nicht beantwortet werden.	Zentralisierung wichtiger Metadaten, Besitzverhältnisse und Sitzungsprotokolle in einem System
Sich ausschließlich auf native Cloud-IAM- oder Betriebssystem-Tools zu verlassen	Keine Transparenz über hybride oder Multi-Cloud-Flotten hinweg; manuelles, fehleranfälliges Offboarding	Verwenden Sie eine dedizierte Plattform für den SSH-Schlüssellebenszyklus.

Einschränkungen

Einige wichtige Punkte sollten vorab klargestellt werden. Die Zahlen im IBM-Bericht zu den Kosten von Datenpannen sind globale Durchschnittswerte über alle Arten von Datenschutzverletzungen und Branchen hinweg; sie stellen keine spezifischen Kosten für SSH dar, da IBM SSH nicht als eigene Angriffsvektorkategorie betrachtet. Die hier erwähnten Vorfälle bei CircleCI und GitHub sind anschauliche, gut dokumentierte Beispiele und kein Beweis dafür, dass jedes Unternehmen dem gleichen Angriffspfad oder dem gleichen Ergebnis ausgesetzt ist. Die Roadmap in diesem Artikel ist ein erster Schritt, kein vollständiger Implementierungsplan; die spezifischen Tools, Richtlinien und die Reihenfolge der Einführung für Ihre Umgebung werden in unserem umfassenden Leitfaden zum Lebenszyklus beschrieben. Und keine noch so ausgefeilte SSH-Schlüsselverwaltung ersetzt die Härtung von Hosts, die Netzwerksegmentierung oder einen getesteten Notfallplan; sie schließt lediglich eine spezifische, häufige Sicherheitslücke, nicht aber alle möglichen Angriffswege.

Was würde Encryption Consulting empfehlen?

Behandeln Sie die Verwaltung von SSH-Schlüsseln als eine budgetierte Sicherheitspriorität und nicht als eine Aufgabe, die erst nach einem Audit-Befund oder einem Sicherheitsvorfall angegangen wird. Organisationen, die innerhalb von Minuten auf eine Sicherheitslücke reagieren – wie GitHub im März 2023 –, verfügen bereits vor dem Vorfall über ein vollständiges Schlüsselinventar und klare Zuständigkeiten. Organisationen, die Wochen verlieren, suchen diese Informationen erst während des Vorfalls.

Unsere SSH Secure- Plattform schließt diese Lücke direkt. Sie kombiniert agentenbasierte und agentenlose Erkennung, um ein vollständiges und stets aktuelles Inventar aller SSH-Schlüssel in Ihrer Umgebung zu erstellen, jeden Schlüssel einem verantwortlichen Besitzer zuzuordnen und die Rotation und den Widerruf von Schlüsseln per Richtlinie statt manueller Prozesse durchzusetzen. Private Schlüssel werden mithilfe anerkannter Algorithmen wie RSA-4096, ECDSA und Ed25519 generiert und in Hardware-Sicherheitsmodulen gespeichert. Für sensible oder temporäre Zugriffe kann SSH Secure kurzlebige, sitzungsgebundene Schlüssel ausgeben, die automatisch ablaufen. Echtzeitüberwachung und herunterladbare Audit-Logs mit Integration in Splunk oder Grafana Loki liefern Sicherheits- und Compliance-Teams die von Auditoren geforderten Nachweise – ohne dass bei jedem Prüfzyklus eine manuelle Datenerfassung erforderlich ist.

Wenn Ihre Organisation noch nicht weiß, wie viele SSH-Schlüssel produktiv im Einsatz sind, ist diese Unsicherheit an sich schon ein Erkenntnisgewinn. Setzen Sie hier an und nutzen Sie unseren umfassenden Leitfaden zum SSH-Schlüssel-Lebenszyklusmanagement als operative Referenz für die nächsten Schritte.

Fazit

Die Verwaltung von SSH-Schlüsseln ist von entscheidender Bedeutung, da SSH-Schlüssel privilegierte Zugangsdaten darstellen, die selten ablaufen, häufig die Person oder das System, dem sie ausgestellt wurden, überdauern und Zugriff gewähren, ohne dass eine Warnung bei fehlgeschlagenen Anmeldeversuchen auf Missbrauch hinweist. Dies ist kein theoretisches Risiko. Der Sicherheitsvorfall bei CircleCI im Jahr 2023 erzwang eine unternehmensweite Rotation der Zugangsdaten, GitHub musste einen offengelegten Host-Schlüssel ersetzen, um eine Ausnutzung zu verhindern, und laut einem Bericht von IBM aus dem Jahr 2025 belaufen sich die durchschnittlichen Kosten eines Fehlers in diesem Bereich auf 4.44 Millionen US-Dollar und die Dauer der Sicherheitslücke auf 241 Tage.

Um die Sicherheitslücke zu schließen, ist kein perfektes Programm von Anfang an erforderlich. Wichtig ist, den vorhandenen Bestand zu kennen, jedem Schlüssel einen Verantwortlichen zuzuweisen, die Schlüsselrotation anhand realer Ereignisse statt nach einem Kalender durchzuführen und dies im Falle eines Audits oder Sicherheitsvorfalls nachweisen zu können. Sicherheitsverantwortliche, die das SSH-Schlüsselmanagement jetzt als Priorität mit ausreichenden finanziellen Mitteln behandeln, können innerhalb von Minuten auf die nächste Sicherheitslücke reagieren. Die vollständige operative Anleitung zu jedem Schritt in diesem Artikel finden Sie in unserem umfassenden Leitfaden zum SSH-Schlüssellebenszyklusmanagement.

Häufig gestellte Fragen

Warum ist SSH-Schlüsselmanagement wichtig, wenn sich unsere Server bereits hinter einer Firewall befinden? Eine Firewall kontrolliert die Netzwerkreichweite, nicht aber, wer sich nach der Verbindungszulassung authentifiziert. Ein SSH-Schlüssel gewährt einem Angreifer, der ihn erlangt, dieselben Zugriffsrechte wie der rechtmäßige Besitzer. Dieser Zugriff funktioniert sowohl innerhalb als auch außerhalb des Netzwerks, beispielsweise von einem kompromittierten Endgerät, einem gestohlenen Laptop oder dem Rechner eines externen Dienstleisters, den Sie nicht im Blick hatten. Netzwerkkontrollen und Schlüsselverwaltung decken unterschiedliche Aspekte der Angriffskette ab; das Auslassen des einen macht das andere nicht überflüssig.

Was kostet ein nicht verwalteter SSH-Schlüssel ein Unternehmen konkret? Es gibt keine pauschale Kostenangabe für SSH-Schlüssel, aber die Kosten zeigen sich an zwei Stellen: Laut dem IBM-Bericht „Cost of a Data Breach Report 2025“ kostet ein weltweiter Datenverstoß durchschnittlich 4.44 Millionen US-Dollar, und die Identifizierung und Eindämmung von Datenverstößen, die mit gestohlenen Zugangsdaten beginnen, dauert etwa 246 Tage. Ein nicht verwalteter Schlüssel verlängert diesen Zeitraum erheblich, da die Einsatzkräfte nicht schnell feststellen können, wem er gehört oder welche Systeme damit erreichbar sind.

Was sollte ein Sicherheitsteam als Erstes tun, wenn es seine SSH-Schlüssel noch nie inventarisiert hat? Zunächst eine Erkennung durchführen. Man kann weder die Besitzrechte zuweisen noch Rotationsrichtlinien festlegen oder Prüfberichte für Schlüssel erstellen, deren Existenz man nicht kennt. Nutzen Sie sowohl agentenbasierte als auch agentenlose Erkennung, um Server, Cloud-Instanzen und CI/CD-Systeme zu erreichen, und betrachten Sie das resultierende Inventar als Ausgangspunkt für alle weiteren Schritte – nicht als einmaliges Projekt.

Ersetzen SSH-Zertifikate die Notwendigkeit der Schlüsselverwaltung vollständig? Nein. Kurzlebige, von einer Zertifizierungsstelle signierte SSH-Zertifikate reduzieren zwar das Risiko einzelner Anmeldeinformationen, da sie automatisch ablaufen, dennoch muss ein Unternehmen wissen, welche Systeme der Zertifizierungsstelle vertrauen, welche älteren Systeme noch keine Zertifikate unterstützen und ob ältere statische Schlüssel weiterhin aktiv sind. Zertifikate stellen eine sinnvolle architektonische Verbesserung dar, sind aber kein Ersatz für Inventarisierung und Governance.

Ist die Verwaltung von SSH-Schlüsseln für Compliance-Rahmenwerke wie PCI DSS oder ISO 27001 erforderlich? Diese Rahmenwerke verlangen von Unternehmen den Nachweis der Kontrolle über privilegierte Zugriffe auf Systeme, die regulierte Daten speichern, verarbeiten oder übertragen. SSH-Schlüssel stellen dabei eine Form privilegierter Zugriffe dar. Gewähren SSH-Schlüssel Zugriff auf Systeme, die unter den Geltungsbereich fallen, erwartet ein Auditor ein Inventar, dokumentierte Eigentumsverhältnisse, einen Rotationsverlauf und Widerrufsprotokolle – dieselben Nachweise, die auch für Passwörter und andere Zugangsdaten verlangt werden.

Referenzen

• IBM, Bericht über die Kosten eines Datenschutzverstoßes 2025: ibm.com/reports/data-breach
• CircleCI, Sicherheitsvorfallbericht vom 4. Januar 2023: circleci.com/blog/jan-4-2023-incident-report
• github, Wir haben unseren RSA-SSH-Hostschlüssel aktualisiert. (23. März 2023): github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key
• NIST IR 7966, Sicherheit der interaktiven und automatisierten Zugriffsverwaltung mittels Secure Shell (SSH): nvlpubs.nist.gov/nistpubs/ir/2015/nist.ir.7966.pdf
• CISA AA22-137A, Schwache Sicherheitskontrollen und -praktiken werden routinemäßig für den Erstzugriff ausgenutzt: cisa.gov/news-events/cybersecurity-advisories/aa22-137a