SSH-Schlüsselbesitz: So ordnen Sie alle privilegierten Anmeldeinformationen vor Ihrer nächsten Zugriffsprüfung zu

Jede Zugriffsprüfung basiert auf der stillschweigenden Annahme, dass für jede Zugangsberechtigung zu einem sensiblen System drei Fragen beantwortet werden können: Wem gehört das System? Warum existiert es? Sollte es noch vorhanden sein? Bei Benutzerkonten, die mit einem Verzeichnis und einer Personalakte verknüpft sind, lassen sich diese Fragen in der Regel beantworten. Bei den privilegierten Schlüsseln, die Maschinen, Dienste und Automatisierungsprozesse zur Kommunikation untereinander verwenden – insbesondere SSH-Schlüssel –, sind sie häufig nicht beantwortbar.

Ein SSH-Schlüssel ist ein Zugangsschlüssel, der es einem Rechner oder Benutzer ermöglicht, sich über das Secure Shell (SSH) -Protokoll an einem anderen Rechner anzumelden, häufig mit Administrator- oder Root-Rechten. Im Gegensatz zu einem Passwort läuft ein SSH-Schlüssel nicht automatisch ab, speichert keine Informationen über seinen Ersteller und ist selten mit einem Verzeichnis oder einem HR-System verknüpft. Diese Kombination aus hohen Berechtigungen, langer Gültigkeitsdauer und fehlendem Eigentümer macht SSH-Schlüssel zu den am schwierigsten zu verwaltenden Zugangsschlüsseln und zum zentralen Thema dieses Artikels.

Dies ist die unangenehme Realität hinter vielen scheinbar reibungslosen Attestierungskampagnen. Prüfer zertifizieren die ihnen zugänglichen Benutzerkonten, während eine weitaus größere Anzahl von SSH-Schlüsseln, API-Tokens und Zugangsdaten für Dienstkonten völlig außerhalb der Prüfung liegt – oft mit privilegierten oder sogar Root-Zugriffsrechten. Dieser Artikel befasst sich mit der Schließung dieser Lücke. Er erklärt, warum die Inhaberschaft von SSH-Schlüsseln und anderen privilegierten Zugangsdaten so schwer zu ermitteln ist, welche Kosten entstehen, wenn eine Prüfung ohne diese Informationen durchgeführt wird, und wie die Ermittlung und Zuordnung der Inhaberschaft (die Grundlage für effektives SSH-Schlüsselmanagement ) aufgebaut wird, die die nächste Zugriffsprüfung ehrlich statt nur wünschenswert macht.

Warum ist der Besitz privilegierter Schlüssel wichtig?

Drei Entwicklungen haben die Verwaltung privilegierter Schlüssel von einer rein administrativen Angelegenheit zu einer Priorität der Governance gemacht: Maschinenidentitäten sind mittlerweile weitaus zahlreicher als menschliche, ein Großteil davon hat gar keinen Besitzer, und Aufsichtsbehörden sowie Versicherer fragen sich zunehmend, wer dafür verantwortlich ist. Diese Faktoren erklären, warum die nächste Zugriffsüberprüfung nicht-menschliche Zugangsdaten nicht außer Acht lassen darf.

Maschinenidentitäten sind mittlerweile zahlreicher als menschliche Identitäten.

Die Zugriffsverwaltung wurde für eine Welt konzipiert, in der Menschen die Mehrheit der Identitäten ausmachten. Diese Welt existiert nicht mehr. Nicht-menschliche Identitäten übertreffen die menschlichen mittlerweile deutlich. Branchenstudien zeigen, dass sich das Ungleichgewicht zwischen maschinellen und menschlichen Identitäten stetig vergrößert. Wenn eine Zugriffsprüfung nur menschliche Konten umfasst, wird lediglich ein kleiner und immer weiter schrumpfender Bruchteil derjenigen überprüft, die tatsächlich Zugriff auf Produktionsumgebungen haben.

Das eigentliche Problem ist das nicht zugeordnete Volumen

Das Problem ist nicht nur die schiere Menge, sondern vor allem die Menge an nicht zugeordneten Konten. Ein erheblicher Anteil der Unternehmensidentitäten hat in den HR-Systemen keinen Verantwortlichen, weil der Ersteller das Unternehmen verlassen hat, während das Konto und die zugehörigen Zugriffsrechte bestehen blieben. Viele nicht-menschliche Identitäten sind zudem älter als ein Jahr und wurden nicht aktualisiert. Eine Zugriffsprüfung ohne Eigentümerdaten kann keine Entscheidung über Widerruf oder Beibehaltung treffen; sie kann lediglich eine formale Bestätigung liefern.

Aufsichtsbehörden und Versicherer erwarten es nun.

Die Anforderungen haben sich verschärft. Rahmenwerke wie das NIST Cybersecurity Framework 2.0 und die EU-Richtlinie NIS2 beziehen sich zunehmend auf die Verwaltung von Maschinenidentitäten, und Analysten stellen fest, dass Unternehmen einem erhöhten Compliance-Druck im Zusammenhang mit Berechtigungen ausgesetzt sind, da Versicherer strengere Berechtigungskontrollen fordern. Prüfer können nicht länger unbefugte privilegierte Schlüssel als Problem anderer betrachten.

Warum ist der Besitz privilegierter Schlüssel so schwierig?

Wenn die Notwendigkeit, privilegierte Schlüssel einzubeziehen, nun geklärt ist, stellt sich die schwierigere Frage, warum dies so schwierig ist. Die Schwierigkeit liegt in der Struktur, nicht im Aufwand. Ein privilegierter Schlüssel ist lediglich eine Berechtigung, die erweiterte Zugriffsrechte gewährt. SSH-Schlüssel hingegen besitzen keine integrierte Identität, laufen nie von selbst ab und schaffen stillschweigende Vertrauensbeziehungen zwischen Systemen. Zu verstehen, warum sie sich einer eindeutigen Zuordnung entziehen und was ein brauchbarer Eigentümernachweis tatsächlich enthalten muss, ist die Grundlage für alles Folgende.

Was gilt als privilegierter Schlüssel?

In diesem Kontext bezeichnet ein privilegierter Schlüssel jede nicht-menschliche Anmeldeinformation, die erweiterten Zugriff auf ein System gewährt: ein privater SSH-Schlüssel zur Authentifizierung an einem Server, ein API-Token, ein OAuth-Client-Geheimnis, ein Dienstkontopasswort oder Anmeldeinformationen für Cloud-Workloads. SSH-Schlüssel stellen den klassischen Sonderfall dar, da sie gleichzeitig hohe Berechtigungen besitzen und strukturell undurchsichtig sind. SSH-Berechtigungen verleihen typischerweise erhöhte und oft Root-Rechte, doch der Schlüssel selbst enthält nahezu keine Identitätsinformationen.

Warum SSH-Schlüssel sich der Besitznahme widersetzen

Ein öffentlicher SSH-Schlüssel auf einem Server ist eine permanente, unkontrollierte Zugriffsentscheidung. Das Betriebssystem legt fest, dass sich jeder, der den zugehörigen privaten Schlüssel besitzt, mit diesem Konto authentifizieren kann. Für den SSH-Daemon sehen ein gültiger administrativer Schlüssel und ein verwaister Schlüssel identisch aus. Es gibt keinen eingebetteten Benutzer, kein Ablaufdatum und keine Verknüpfung zu einem Verzeichnis. In einer typischen Linux-Umgebung sammeln sich verschiedene Schlüssel an: Benutzerschlüssel, Root-Schlüssel, Service-Schlüssel, Bereitstellungsschlüssel, Notfallschlüssel, Herstellerschlüssel und Überbleibsel von außer Betrieb genommenen Skripten. Das Protokoll bietet keine Möglichkeit, diese zu unterscheiden.

Die Hauptursache liegt in der Diskrepanz zwischen Gültigkeitsdauer und Nutzung. Passwörter laufen ab und Single-Sign-On-Konten werden deaktiviert, SSH-Schlüssel hingegen bleiben, sofern sie nicht gezielt verwaltet werden, unbegrenzt gültig. Sie lassen sich einfach und ohne Genehmigung generieren. Daher betont das NIST in seinen Richtlinien ausdrücklich die Notwendigkeit einer strikten Bereitstellung, Kündigung und Überwachung des SSH-Zugriffs.

Wie Vertrauensbeziehungen das Risiko verbreiten

Die Eigentumsverhältnisse werden durch Vertrauensbeziehungen zwischen Systemen zusätzlich verkompliziert. SSH-Schlüssel dienen der automatisierten Verbindung von Systemen und sogar Organisationen. Unverwaltete SSH-Schlüssel können diese Vertrauensbeziehungen zu Richtlinienverstößen führen, beispielsweise durch einen Schlüssel, der unbemerkt eine Verbindung zwischen einem Entwicklungssystem und dem Produktivsystem herstellt. Genau diese Vertrauensnetzwerke ermöglichen es einem Angreifer, der einen Host kompromittiert hat, auf viele weitere Systeme überzugreifen. Sie bleiben bei einer Überprüfung, die sich nur auf einzelne Konten konzentriert, unsichtbar.

Was ein nutzbarer Eigentumsnachweis erfassen muss

Die Feststellung der Eigentumsverhältnisse bedeutet mehr als nur die Namenszuordnung. Ein aussagekräftiger Eigentumsnachweis für einen privilegierten Schlüssel sollte den verantwortlichen Eigentümer oder das zuständige Team, den Speicherort des privaten Schlüssels, die Zugriffsrechte des Schlüssels, das Datum der letzten Verwendung, sein Alter und seinen Rotationsstatus sowie die geschäftliche Begründung für seine Existenz erfassen. Speziell für SSH umfasst dies die Zuordnung eines privaten Schlüssels auf einem Benutzerrechner oder in einer Pipeline zu jedem Eintrag in der Datei `authorized_keys`, den er erfüllen kann. Tools zur Erkennung, die Dateipfade und den Erkennungskontext protokollieren, sind hier besonders wertvoll, da sie es einem Prüfer ermöglichen, einen Befund bis zu seinem Ursprung zurückzuverfolgen und ihn zu beheben.

Was geht kaputt, wenn die Eigentumsverhältnisse unklar sind?

Wenn eine Zugriffsprüfung ohne Kenntnis der Eigentumsverhältnisse privilegierter Schlüssel durchgeführt wird, sind die Konsequenzen konkret.

Fehlermodus	Was schief läuft	Auswirkungen auf das Geschäft
Verwaister Zugriff überlebt	Schlüssel von ausgeschiedenen Mitarbeitern werden nie markiert, da kein Besitzer die Entfernung auslöst.	Permanente, unauffindbare Hintertüren zu privilegierten Systemen.
Rezensenten beugen sich der Angst	Teams vermeiden es, Tasten zu entfernen, die sie nicht verstehen.	Veraltete, zu weit gefasste Zugriffsrechte bleiben auf unbestimmte Zeit bestehen.
Langsame Reaktion auf Vorfälle	Kompromittierte Schlüssel können nicht schnell lokalisiert oder widerrufen werden.	Größerer Explosionsradius und längere Verweildauer des Angreifers.
Prüfungs- und Compliance-Lücken	Kein dokumentierter Eigentümer oder Begründung für den privilegierten Zugriff.	Feststellungen und Strafen gemäß PCI DSS, HIPAA, Datenschutzund ähnliche Regime.
Falsche Zusicherung	Die Bestätigung bezieht sich nur auf Personen und wurde als abgeschlossen unterschrieben.	Die Führungsebene geht fälschlicherweise davon aus, dass der Zugang geregelt ist.

Rezensenten lassen unberührt, was sie nicht erklären können.

Eine der schädlichsten Dynamiken ist rationale Vorsicht. Da Produktionssysteme oft auf schlecht dokumentierter Automatisierung basieren, vermeiden Sicherheitsteams aus Angst vor Betriebsunterbrechungen schlichtweg die Rotation und Löschung von Schlüsseln. Die Folge: Gerade die Schlüssel, die am dringendsten überprüft werden müssen – die, deren Funktionsweise niemand erklären kann –, bleiben von einem vorsichtigen Prüfer unberührt. Besitzdaten durchbrechen diese Lähmung, indem sie Angst durch Fakten ersetzen.

Die Ausgangsdaten sind bereits fehlerhaft.

Die Ausgangslage ist schlecht. Studien zeigen, dass 60 bis 90 Prozent der Unternehmen keine vollständige Übersicht ihrer aktiven SSH-Schlüssel besitzen und viele diese manuell, beispielsweise mithilfe von Tabellenkalkulationen, verwalten. Mit einer Tabellenkalkulation lässt sich die Inhaberschaft von Zehntausenden von Schlüsseln nicht feststellen, und eine Überprüfung, die auf unvollständigen Daten basiert, übernimmt jede Lücke dieser Daten.

Wie lässt sich die Eigentumsfrage vor der nächsten Überprüfung klären?

Wenn fehlende Zuständigkeiten eine Überprüfung verhindern, besteht die Lösung darin, diese gezielt wiederherzustellen. Das Schließen der Zuständigkeitslücke ist ein schrittweiser Prozess, der größtenteils vor dem nächsten Überprüfungszyklus abgeschlossen werden kann, wenn er gezielt begonnen wird.

1. Umfassende Entdeckung über alle Schlüssel und Hosts hinweg: Nutzen Sie sowohl agentenbasierte als auch agentenlose Erkennung, um alle SSH-Schlüssel auf Servern und Benutzerrechnern zu finden, und wenden Sie dieselbe Vorgehensweise auch auf API-Token und Service-Account-Anmeldeinformationen an. Streben Sie zunächst Vollständigkeit an; eine unvollständige Erkennung führt zu unvollständiger Sicherheit.
2. Schlüssel mithilfe mehrerer Signale Besitzern zuordnen: Ordnen Sie private Schlüssel den Konten und Pipelines zu, die sie verwenden, gleichen Sie diese mit Verzeichnis- und Personaldaten ab und verwenden Sie die Daten zur letzten Verwendung, um aktive von inaktiven Schlüsseln zu unterscheiden. Wenn kein Inhaber gefunden werden kann, ist dies ein Grund zur Eskalation und kein zu ignorierender Eintrag.
3. Klassifizierung nach Privilegien und Exposition, nicht nur nach Alter: Priorisieren Sie Schlüssel mit Root- oder Administratorrechten, Schlüssel, die Vertrauensgrenzen wie zwischen Nicht-Produktions- und Produktionsumgebungen überbrücken, und Schlüssel, die nicht innerhalb der Richtlinie rotiert wurden. Ein ein Jahr alter Schlüssel, der nichts schützt, ist weniger wichtig als ein eine Woche alter Schlüssel mit Administratorrechten.
4. Trennung von Ermittlung und Behebung: Beginnen Sie die Bereinigung niemals mit dem Löschen unbekannter Schlüssel. Führen Sie die Entfernung über die Konfigurationsverwaltung während eines Wartungsfensters durch und überwachen Sie das Anwendungsverhalten unmittelbar danach, da das Entfernen des falschen Schlüssels Backups, Bereitstellungen oder den Notfallzugriff beeinträchtigen kann.
5. Ersetzen Sie Aktivitätskennzahlen in der Berichterstattung durch Expositionskennzahlen: Anstatt die Anzahl der geprüften Elemente zu melden, sollten Identitäten ohne Inhaber, Anmeldeinformationen, die älter als die Richtlinien sind, und privilegierte Schlüssel, die außerhalb der üblichen Muster auf sensible Systeme zugreifen, erfasst werden. Für das Management-Reporting sollten Kennzahlen zur Gefährdungslage Vorrang vor der Anzahl der Prüfungen haben.
6. Verringern Sie die Anzahl der verfügbaren Rezensionen, damit zukünftige Überprüfungen kleiner werden: Wo immer möglich, sollten Sie von langlebigen Schlüsseln auf kurzlebige, automatisch rotierte Anmeldeinformationen umsteigen, um den dauerhaften Zugriff auf Attribute zu reduzieren. Leitlinien zur nicht-menschlichen Identität priorisieren die vollständige Abschaffung langlebiger Anmeldeinformationen gegenüber deren regelmäßiger Rotation.
7. Sorgen Sie für kontinuierliches, nicht jährliches Eigentum: Die Erkennung und Besitzverwaltung erfolgt über ein fortlaufendes Inventar, sodass neue Schlüssel bei ihrer Erstellung einen Besitzer erhalten und verwaiste Schlüssel sofort nach ihrem Auftreten gekennzeichnet werden, anstatt auf die nächste Kampagne zu warten.

Was bedeutet das für die einzelnen Sicherheitsakteure?

Die Festlegung der Besitzverhältnisse ist nicht Aufgabe eines einzelnen Teams. Der Besitz privilegierter Schlüssel ist eine gemeinsame Verantwortung, und jede Funktion ist in unterschiedlicher Weise davon abhängig.

• CISOS Es bedarf einer rechtssicheren Bestätigung. Die Unterzeichnung einer Zugriffsprüfung, die den Großteil der privilegierten Zugangsdaten ausschließt, stellt ein Governance- und Haftungsrisiko dar, das durch Eigentumsdaten direkt gemindert wird.
• IAM-Teams Die Governance muss über menschliche Konten hinaus erweitert werden. Dieselben Lebenszykluskontrollen, die für neue Mitarbeiter, Versetzungen und Austritte gelten, müssen auch für Servicekonten, Token und Schlüssel gelten, die sich anders verhalten und oft länger bestehen.
• Sicherheitsarchitekten Mithilfe von Eigentums- und Expositionsdaten lassen sich Rückschlüsse auf den Wirkungsradius ziehen, wodurch begrenzt wird, wie weit sich eine einzelne Berechtigung verbreiten kann und wie lange sie ohne Überprüfung bestehen bleibt.
• PKI- und Kryptographie-Teams sind natürliche Eigentümer des Schlüsselinventars und können SSH-Schlüssel in dieselbe Governance integrieren, die für Zertifikate.
• DevSecOps- und Plattformteams Sie enthalten den Kontext für Pipeline- und Service-Anmeldeinformationen und sind unerlässlich für die Zuordnung von Schlüsseln zu den Automatisierungen, die diese verwenden.
• Audit- und Compliance-Teams Ermitteln Sie den nachweisbaren Eigentümer und die Begründung, die eine Überprüfung von einer Formalität in einen Kontrollnachweis verwandelt.

Wie kann Verschlüsselungsberatung helfen?

Die manuelle Durchführung dieses Programms ist im Unternehmensmaßstab schwierig. Hier kommen speziell entwickelte Tools ins Spiel. Wir von Encryption Consulting verstehen die Herausforderungen, vor denen Unternehmen bei der Verwaltung von SSH-Schlüsseln in großem Umfang stehen. Unsere Lösung SSH Secure bietet umfassende Sicherheit über den gesamten Schlüssellebenszyklus, zentrale Transparenz und HSM-gestützten Schutz. So können Unternehmen ihre Schlüssel sicher und ohne zusätzliche Komplexität verwalten.

Zu den wichtigsten Funktionen von SSH Secure gehören:

• Zentralisierte Sichtbarkeits- und Eigentumszuordnung: Durch eine Kombination aus agentenbasierter und agentenloser Erkennung lokalisiert SSH Secure jedes SSH-Schlüssel Server- und benutzerseitig werden alle Schlüssel in einem einheitlichen Inventar mit Besitz- und Nutzungsdetails gespeichert. Dadurch werden verwaiste Schlüssel vermieden und die vollständige Nachvollziehbarkeit in der gesamten Umgebung sichergestellt.
• Automatisierte Orchestrierung des Schlüssellebenszyklus: SSH Secure automatisiert den gesamten Schlüssellebenszyklus, von der sicheren Generierung über die richtlinienbasierte Rotation bis hin zum Widerruf. Schlüssel können bedarfsgesteuert oder gemäß den Unternehmensrichtlinien rotiert oder widerrufen werden. Für sensible Vorgänge kann SSH Secure temporäre, sitzungsgebundene Schlüssel ausgeben, die automatisch ablaufen. Dieses zentrale Lebenszyklusmanagement gewährleistet den Zugriff nach dem Prinzip der minimalen Berechtigungen, reduziert das Risiko von Kompromittierungen und stellt sicher, dass Schlüssel nicht über ihren vorgesehenen Verwendungszweck hinaus gültig bleiben.
• HSM-integrierter Schutz: Alle privaten Schlüssel werden innerhalb von HSMs generiert und gespeichert. Die Schlüssel werden mithilfe starker kryptografischer Algorithmen wie RSA-4096 generiert. ECDSAund Ed25519, wodurch ein starker kryptografischer Schutz, Widerstandsfähigkeit gegen kryptanalytische Angriffe und eine effiziente Leistung gewährleistet werden.
• Richtlinienbasierte Steuerung wichtiger Abläufe: Alle wichtigen Vorgänge wie Generierung, Genehmigungsworkflows, Rotation und Widerruf werden durch richtlinienbasierte Kontrollen gesteuert. Dies gewährleistet Konsistenz im gesamten System, reduziert manuelle Fehler und sichert unternehmensweite Sicherheitsstandards. Richtlinien können an regulatorische Anforderungen angepasst oder individuell auf interne Governance-Modelle zugeschnitten werden.
• Kontinuierliche Überwachung, Prüfung und Bereitschaft zur Einhaltung von Vorschriften: SSH Secure bietet Echtzeitüberwachung wichtiger Aktivitäten mit detaillierter Ereignisprotokollierung und integrierter Anomalieerkennung. Protokolle lassen sich in Splunk- oder Grafana-Loki-Dashboards integrieren, um erweiterte Visualisierungen, Korrelationen und Warnmeldungen zu ermöglichen. Flexible Audit-Funktionen umfassen herunterladbare Protokolle und detaillierte Berichte, die Sicherheitsteams klare Einblicke in die Schlüsselnutzung und den allgemeinen Sicherheitsstatus bieten. Zentralisiertes Auditing mit richtlinienbasierten Warnmeldungen ermöglicht proaktives Sicherheitsmanagement, schnelle Anomalieerkennung und eine zügigere Reaktion auf Sicherheitsvorfälle.

Die Implementierung von HSM-gestütztem SSH-Schlüsselmanagement im Unternehmensmaßstab erfordert mehr als nur die Auswahl der passenden Hardware. Sie bedarf der Erkennung, der Orchestrierung des gesamten Schlüssellebenszyklus, der Durchsetzung von Richtlinien und der kontinuierlichen Transparenz in einer komplexen Umgebung. Bei Encryption Consulting haben wir SSH Secure genau für diese Anforderungen entwickelt: Es bietet umfassende Sicherheit für den gesamten Schlüssellebenszyklus und HSM-gestützten Schutz ohne zusätzliche betriebliche Komplexität.

Fazit

Eine Zugriffsprüfung, die nicht für jeden privilegierten Schlüssel einen Besitzer benennen kann, ist keine wirkliche Prüfung; sie ist lediglich eine unvollständige Bestandsaufnahme mit einer angehängten Signatur. Die Anmeldeinformationen, die am ehesten Schaden anrichten – die verwaisten, übermäßig privilegierten und unerklärten Schlüssel – sind genau diejenigen, die bei einer rein manuellen Überprüfung durchrutschen und die ein vorsichtiger Prüfer höchstwahrscheinlich ignorieren wird. Die Lösung liegt nicht in einer sorgfältigeren Bestätigung, sondern in besseren Daten, die der Bestätigung zugrunde liegen.

Um vor Ihrer nächsten Zugriffsprüfung die Inhaber aller privilegierten Schlüssel zu ermitteln, gehen Sie wie folgt vor: Ermitteln Sie umfassend alle Schlüssel, ordnen Sie sie mithilfe von Verzeichnis-, Pipeline- und Nutzungsdaten den jeweiligen Inhabern zu, priorisieren Sie nach Berechtigung und Zugriffsdauer statt nach Alter und pflegen Sie die Daten in einem kontinuierlichen Inventar. So wird die Inhaberschaft bei der Erstellung festgelegt und nicht erst unter Zeitdruck rekonstruiert. Dadurch wird die nächste Zugriffsprüfung nicht mehr zu einer Glücksspielübung, sondern zu einer verlässlichen Aussage darüber, wer worauf und warum Zugriff hat.