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

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

Jede Zugriffsprüfung basiert auf einer stillschweigenden Annahme: Für jede Zugangsberechtigung zu einem sensiblen System lassen sich drei Fragen beantworten: Wem gehört sie? Warum existiert sie? Sollte sie noch vorhanden sein? Bei Benutzerkonten, die mit einem Verzeichnis und einem Personalakt 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 bei SSH-Schlüsseln –, sind sie häufig unbeantwortet. Genau diese Lücke schließt dieser Artikel.

Ein SSH-Schlüssel ist ein Zugangsschlüssel, der es einem Rechner oder Benutzer ermöglicht, sich über das Secure Shell (SSH) -Protokoll bei einem anderen 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 dem Fehlen eines eindeutigen Besitzers macht SSH-Schlüssel zu den am schwierigsten zu verwaltenden Zugangsschlüsseln.

Dies ist die unangenehme Realität hinter vielen scheinbar reibungslosen Zertifizierungskampagnen. Prüfer zertifizieren die ihnen zugänglichen Benutzerkonten, während eine weitaus größere Anzahl von SSH-Schlüsseln, API-Tokens und Service-Account-Zugangsdaten völlig außerhalb der Prüfung liegt – oft mit privilegierten oder sogar Root-Zugriffen. Dieser Artikel erklärt, warum die Eigentümerschaft von SSH-Schlüsseln so schwer festzustellen ist, wie man ein Lifecycle-Modell für die Eigentümerschaft entwickelt, den genauen Mapping-Prozess, der vor der nächsten Prüfung durchgeführt werden sollte, und welche Prüfnachweise ein SOC-2- oder PCI-DSS-Prüfer tatsächlich anfordert. Dieser Beitrag bietet eine praktische Anleitung für die Mapping- und Prüfungsarbeit. Für das umfassendere Lifecycle-Programm, in das er eingebettet ist, siehe unseren ausführlichen Leitfaden zum SSH-Key-Lifecycle-Management . Informationen zu den Risiken nicht verwalteter Schlüssel finden Sie unter „ Warum nicht verwaltete SSH-Schlüssel Ihre größte Sicherheitslücke im Bereich privilegierter Zugriffe darstellen“.

Warum ist die Nachverfolgung der Besitzverhältnisse von SSH-Schlüsseln so schwierig?

Drei Veränderungen haben dazu geführt, dass die Verwaltung privilegierter Schlüssel von einer rein organisatorischen Angelegenheit zu einer Priorität der Unternehmensführung geworden ist: Maschinenidentitäten sind mittlerweile weitaus zahlreicher als menschliche Identitäten, ein großer Teil von ihnen hat überhaupt keinen Besitzer, und Aufsichtsbehörden und Versicherer haben begonnen zu fragen, wer für sie verantwortlich ist.

Maschinenidentitäten sind mittlerweile zahlreicher als menschliche.

Die Zugriffsverwaltung wurde für eine Welt entwickelt, in der menschliche Identitäten die Mehrheit bildeten. Diese Welt gehört der Vergangenheit an. Nicht-menschliche Identitäten, darunter SSH-Schlüssel, API-Token und Servicekonten, übertreffen menschliche Identitäten mittlerweile deutlich und stetig. Wenn eine Zugriffsprüfung nur menschliche Konten umfasst, überprüft sie lediglich einen kleinen und immer weiter schrumpfenden Bruchteil all dessen, was tatsächlich produktiv eingesetzt werden kann.

Das eigentliche Problem ist das nicht zugeordnete Volumen

Das Problem ist nicht nur die Menge, sondern vor allem die Menge an Zugangsdaten ohne Eigentümer. Ein erheblicher Teil der Unternehmenszugangsdaten ist in Personal- oder Identitätssystemen nicht registriert, weil der Ersteller das Unternehmen verlassen hat, während das Konto und die zugehörigen Zugriffsrechte bestehen blieben. Viele nicht-menschliche Identitäten werden zudem ein Jahr oder länger nicht aktualisiert. Eine Zugriffsprüfung ohne Eigentümerdaten kann keine Entscheidung über Widerruf oder Beibehaltung treffen; sie kann lediglich den bestehenden Zustand bestätigen.

Warum SSH-Schlüssel sich so stark dem Besitz 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: kein eingebetteter Benutzer, kein Ablaufdatum, keine Verknüpfung zu einem Verzeichnis. NISTIR 7966, die NIST-Richtlinie zur SSH-Zugriffsverwaltung, betont ausdrücklich die Notwendigkeit strenger Bereitstellungs-, Kündigungs- und Überwachungskontrollen, da das Protokoll selbst keine vorsieht ( NIST, „Security of Interactive and Automated Access Management Using Secure Shell (SSH)“, NISTIR 7966 ). In einer typischen Linux-Umgebung sammeln sich Benutzerschlüssel, Root-Schlüssel, Service-Schlüssel, Bereitstellungsschlüssel, Notfallschlüssel, Herstellerschlüssel und Überbleibsel von außer Betrieb genommenen Skripten an, und das Protokoll unterscheidet diese nicht.

Die Eigentumsverhältnisse werden durch Vertrauensbeziehungen zwischen Systemen zusätzlich verkompliziert. SSH-Schlüssel stellen automatisierte Verbindungen zwischen Systemen und sogar Organisationen her, und ein nicht zugeordneter Schlüssel kann unbemerkt ein Entwicklungssystem in die Produktionsumgebung integrieren. Genau diese Vertrauensnetzwerke ermöglichen es einem Angreifer, der einen Host kompromittiert hat, sich auf viele weitere auszubreiten, und sie bleiben bei einer Überprüfung, die sich nur auf einzelne Konten konzentriert, unsichtbar.

Was ist das SSH-Schlüsselbesitz-Lebenszyklusmodell?

Die Eigentumsberechtigung ist kein Feld, das man einmalig ausfüllt. Es handelt sich um eine Rolle, die zu bestimmten Zeitpunkten im Lebenszyklus eines Schlüssels zugewiesen, bestätigt und gegebenenfalls neu zugewiesen werden muss. Andernfalls verfällt sie wieder in einen anonymen Zustand, was Zugriffsüberprüfungen unzuverlässig macht. Ein praktikables Lebenszyklusmodell ordnet jeder Phase einen verantwortlichen Eigentümer zu und definiert, welche Berechtigungen in jeder Phase wechseln.

Die fünf Stufen der Eigentumsverantwortung

• Erstellung und Bereitstellung: Der Antragsteller benennt zum Zeitpunkt der Schlüsselgenerierung – nicht nachträglich – eine geschäftliche Begründung, ein Zielsystem und einen Eigentümer. Ein Schlüssel, der ohne festgelegten Eigentümer erstellt wurde, darf auf keinem Server autorisiert werden.
• Aktive Nutzung: Der Inhaber ist der Ansprechpartner für diesen Schlüssel, solange dieser autorisiert ist. Nutzungsdaten (Zeitstempel der letzten Authentifizierung, Quellhost, Zielhost) werden dem Inhaber und nicht nur dem Fingerabdruck des Schlüssels zugeordnet.
• Drehung: Die Besitzverhältnisse werden bei einer Schlüsselrotation nicht zurückgesetzt; sie ist der Auslöser, der bestätigt, dass der Besitzer den Schlüssel weiterhin benötigt. Ein Schlüsselrotationsereignis ohne Reaktion des eingetragenen Besitzers ist an sich schon ein Befund.
• Rollenwechsel oder -versetzung: Wenn eine Person das Team wechselt oder ein Dienst auf eine neue Plattform umgestellt wird, muss die Inhaberschaft explizit übertragen werden, mit einem neuen, benannten Inhaber und einer dokumentierten Übergabe. Eine nicht bestätigte Übertragung ist funktional gleichbedeutend mit einem verwaisten Schlüssel.
• Außerdienststellung und Widerruf: Der Inhaber des Datensatzes ist dafür verantwortlich, die Entfernung aus jeder authorized_keys-Datei zu bestätigen, in der der Schlüssel als vertrauenswürdig eingestuft wurde, und zwar nicht nur aus dem primären System, und den Datensatz zu schließen, anstatt ihn inaktiv zu lassen.

Drei Eigentumsmodelle und wann man welches anwendet.

Nicht jeder Schlüssel passt zum selben Besitzmuster. Die Zuordnung des Modells zum Schlüsseltyp gewährleistet, dass die Besitzdaten korrekt sind und nicht zu einem weiteren Feld werden, das niemand aktualisiert.

• Einzeleigentum: Ideal für persönliche Administratorschlüssel. Eine namentlich genannte Person, deren Identität direkt mit ihrem Verzeichnis verknüpft ist, trägt die Verantwortung. Dies ist das am einfachsten zu prüfende Modell und die Standardeinstellung für jeden Schlüssel, der mit dem interaktiven Zugriff eines Nutzers verbunden ist.
• Team- oder rollenbasierte Verantwortung: Ideal für gemeinsam genutzte operative Zugriffsrechte, beispielsweise für den Notfallschlüssel eines Bereitschaftsdienstes. Ein bestimmtes Team besitzt den Schlüssel, und ein designierter Leiter ist für die Verantwortung zuständig, sodass die Besitzverhältnisse nie auf „das Team“ lauten, was ein Prüfer ablehnen würde.
• Eigentumsverhältnisse an Dienstleistungen oder Pipelines: Ideal für CI/CD- und Automatisierungsschlüssel. Der Eigentümer ist das Entwicklungsteam oder die Plattformgruppe, die für die Pipeline verantwortlich ist. Die geschäftliche Rechtfertigung des Schlüssels ist an die Funktion dieser Pipeline gebunden und nicht an eine einzelne Person, die ihn generiert hat.

Unabhängig vom verwendeten Modell muss ein nutzbarer Eigentümerdatensatz dieselben Kernfelder enthalten: den verantwortlichen Eigentümer, den Speicherort des privaten Schlüssels, die Zugriffsrechte, das Datum der letzten Verwendung, sein Alter und Rotationsstatus sowie die geschäftliche Begründung für seine Existenz. Im SSH-Kontext umfasst dies die Zuordnung zwischen einem privaten Schlüssel auf einem Benutzerrechner oder in einer Pipeline und jedem Eintrag in der Tabelle „authorized_keys“, den er erfüllen kann.

Wie ordnet man alle privilegierten SSH-Schlüssel zu? Ein vierstufiger Prozess

Im Kern besteht die Zuordnung von Eigentumsrechten aus vier Schritten. Alles andere in einem SSH-Governance-Programm unterstützt einen dieser Schritte.

1. Inventar: Ermitteln Sie alle SSH-Schlüssel auf Servern, Cloud-Instanzen, Containern und Benutzerrechnern mithilfe agentenbasierter und agentenloser Methoden. Achten Sie dabei zunächst auf Vollständigkeit; eine unvollständige Bestandsaufnahme bietet nur teilweise Sicherheit, und für jeden nicht gescannten Host können Sie keine Bestätigung abgeben.
2. Bezug zur Identität: Ordnen Sie jeden privaten Schlüssel dem entsprechenden Benutzerkonto, Dienstkonto oder der Pipeline zu, die ihn tatsächlich enthält. Nutzen Sie dazu Verzeichnisdaten, Personalakten und Telemetriedaten der letzten Verwendung, um aktive von inaktiven Schlüsseln zu unterscheiden. Ein Schlüssel, der keiner Identität zugeordnet werden kann, ist ein wichtiger Befund und darf nicht ignoriert werden.
3. Eigentümer zuweisen: Weisen Sie dem Schlüssel einen namentlich genannten und verantwortlichen Verantwortlichen gemäß dem entsprechenden Modell (Einzelperson, Team oder Dienst) zu und dokumentieren Sie die geschäftliche Begründung für die Existenz des Schlüssels. Die Zuweisung der Verantwortlichkeit ist erst abgeschlossen, wenn der Verantwortliche sie bestätigt hat.
4. Bestätigen: Prüfen Sie den resultierenden Zugriff anhand der Richtlinien: Berechtigungsstufe, Umgebung (erreicht ein Nicht-Produktionsschlüssel die Produktionsumgebung?), Rotationsdauer und fortbestehender Geschäftsbedarf. Schlägt die Validierung fehl, werden die erforderlichen Maßnahmen dokumentiert und nicht stillschweigend toleriert.

Wenn in Schritt 3 kein Eigentümer gefunden werden kann, ist diese Abwesenheit selbst ein Befund, der an die Sicherheitsleitung eskaliert werden muss, und kein Eintrag, der leer gelassen und ignoriert werden kann.

Wie sollte die Zugriffsrichtlinie mit dem Schlüsselbesitz verknüpft sein?

Eigentumsdaten sind nur dann nützlich, wenn sie durch Richtlinien durchgesetzt und nicht nur zu Referenzzwecken erfasst werden. Eine SSH-Zugriffsrichtlinie, die tatsächlich an Eigentumsverhältnisse gebunden ist, sollte festlegen, wer einen Schlüssel anfordern kann, welche Genehmigung vor der Bereitstellung erforderlich ist, wie lange er gültig bleibt, bevor er obligatorisch rotiert oder neu begründet werden muss, und für welche Umgebungen strengere Kontrollen gelten.

In der Praxis bedeutet dies, dass der Zugriff in der Produktionsumgebung anders geregelt ist als in der Entwicklungsumgebung, Dienstkonten anderen Regeln folgen als menschliche Benutzer und ein Schlüssel, der Umgebungen verbindet – beispielsweise ein Schlüssel, der sowohl in der Staging- als auch in der Produktionsumgebung gültig ist –, einer expliziten, dokumentierten Genehmigung bedarf, anstatt standardmäßig zulässig zu sein. Die Richtlinie sollte auch festlegen, was geschieht, wenn sich während der Validierung kein Besitzer für einen Schlüssel meldet: Automatische Quarantäne (Blockierung weiterer Authentifizierungen während der Untersuchung) ist eine sicherere Standardeinstellung als die automatische Löschung, die das Risiko birgt, eine unerkannte, aber legitime Abhängigkeit zu unterbrechen, oder die stillschweigende Aufbewahrung, durch die sich verwaiste Schlüssel überhaupt erst ansammeln.

Die Verknüpfung von Richtlinien mit Verantwortlichkeiten bedeutet auch, dass die Richtlinien einen Verantwortlichen haben: jemanden, der dafür zuständig ist, den Rotationsplan, den Genehmigungsworkflow und die Umgebungsbeschränkungen bei Änderungen der Infrastruktur aktuell zu halten, anstatt ein Dokument zu sein, das einmal geschrieben und nie wieder überprüft wird.

Welche Rotationsauslöser sollten an Eigentümerwechsel gekoppelt sein?

Eine rein kalenderbasierte Rotation erfasst nicht die Ereignisse, die das Risiko tatsächlich verändern. Eigentümerdaten ermöglichen es, dass die Rotation auf die Geschehnisse beim Eigentümer reagiert und nicht nur auf den Zeitablauf. Die wichtigsten Auslöser:

• Offboarding: Verlässt der eingetragene Inhaber das Unternehmen oder wird seine Rolle beendet, müssen alle ihm zugeordneten Schlüssel unverzüglich widerrufen werden und dürfen nicht bis zum nächsten Rotationszyklus zwischengespeichert werden. Die Deaktivierung eines Verzeichniskontos widerruft nicht die von dieser Person auf verschiedenen Servern verteilten SSH-Schlüssel; jeder einzelne muss gefunden und entfernt werden, sofern die Suche und der Widerruf nicht automatisiert sind.
• Rollen- oder Teamwechsel: Ein Rollenwechsel sollte eine erneute Überprüfung aller Schlüssel, die der Person gehören, erforderlich machen. Benötigt die neue Rolle den Zugriff nicht mehr, wird der Schlüssel widerrufen und nicht stillschweigend übernommen.
• Verdacht auf Kompromittierung: Jedes Anzeichen einer Kompromittierung, einer Infektion eines Endpunkts, eines durchgesickerten Repositorys oder eines anomalen Authentifizierungsmusters löst eine sofortige Rotation aller Schlüssel aus, die diesem Eigentümer oder Host zugeordnet werden können, und zwar nicht nur des spezifischen Schlüssels, der betroffen ist.
• Beendigung des Vertragsverhältnisses mit dem Anbieter oder Dritten: Die Schlüssel von Auftragnehmern und Lieferanten werden unmittelbar nach Abschluss eines Auftrags mit dem Eigentumsnachweis abgeglichen, da diese Schlüssel überproportional häufig vergessen werden.
• Alter und Ablaufdatum der Police: Schlüssel, deren Gültigkeitsdauer die maximale Kryptoperiode der Organisation überschreitet, werden planmäßig rotiert, wobei die Intervalle für Schlüssel mit hohen Berechtigungen und Servicekonten kürzer sind als für Standardbenutzerschlüssel, in Übereinstimmung mit den allgemeinen Richtlinien für das Schlüsselmanagement in NIST SP 800-57 zu Kryptoperioden.NIST SP 800-57 Teil 1 Rev. 5).

Jeder der oben genannten Auslöser setzt voraus, dass Eigentumsdaten überhaupt vorhanden sind. Ohne diese Daten können weder das Ausscheiden von Mitarbeitern noch ein Rollenwechsel stattfinden, da kein Datensatz existiert, der die ausscheidende Person mit den von ihr gehaltenen Schlüsseln verknüpft.

Welche Prüfungsnachweise benötigen Sie für eine formelle Zugriffsprüfung?

Dieser Abschnitt entscheidet darüber, ob Ihre Überprüfung erfolgreich ist. Beide wichtigen Frameworks legen ausdrücklich fest, dass nicht nur Benutzeranmeldungen, sondern auch privilegierte Konten und Dienstkonten in den Geltungsbereich fallen, und beide erwarten eine dokumentierte, regelmäßige Überprüfung anstelle einer einmaligen Bereinigung.

Was PCI DSS 4.0.1 erfordert

PCI DSS 4.0.1, Anforderung 7.2.4, schreibt vor, dass alle Benutzerkonten und Zugriffsrechte, einschließlich Konten von Drittanbietern und Lieferanten, mindestens alle sechs Monate überprüft werden müssen, um sicherzustellen, dass der Zugriff weiterhin angemessen ist und nicht angemessene Zugriffe zu entfernen. Anforderung 7.2.5 erweitert das Prinzip der minimalen Rechtevergabe speziell auf Anwendungs- und Systemkonten und beschränkt diese auf die Systeme, Anwendungen oder Prozesse, die sie benötigen. Anforderung 7.2.5.1 schreibt vor, dass diese Konten in regelmäßigen Abständen, die das Unternehmen anhand einer gezielten Risikoanalyse festlegt, überprüft werden müssen. Die Ergebnisse müssen vom Management genehmigt werden. Im Bereich der Dienstkonten verlangt Anforderung 8.6.1, dass jedes System- oder Anwendungskonto, das interaktives Anmelden ermöglicht, mit denselben Sicherheitsvorkehrungen wie Benutzerkonten verwaltet wird. Anforderung 8.6.2 verbietet das Festcodieren dieser Anmeldeinformationen in Skripten oder Konfigurationsdateien, und Anforderung 8.6.3 schreibt die regelmäßige Rotation der Anmeldeinformationen gemäß einem auf der Risikoanalyse basierenden Zeitplan vor (siehe PCI DSS v4.0 Anforderung 7: Leitfaden zur Kontoprüfung ; PCI DSS-Anforderungen an Dienstkonten, Schellman ; vollständiger Standard in der Dokumentenbibliothek des PCI Security Standards Council ). Ein SSH-Schlüssel ohne benannten Besitzer erfüllt keine dieser Anforderungen, da er von niemandem überprüft werden kann.

Was SOC 2 erfordert

Gemäß den Trust Services Criteria des AICPA fordern SOC 2 CC6.2 und CC6.3 die regelmäßige Überprüfung von Zugangsdaten und Zugriffsrollen, um deren Angemessenheit zu bestätigen und nicht mehr benötigte Zugriffe zu entfernen. Zudem ist die unverzügliche Entfernung von Zugriffen erforderlich, sobald eine Person diese nicht mehr benötigt ( SOC 2 CC6: Logische und physische Zugriffskontrollen ). Prüfer betrachten die Zugriffskontrolle als einen der beweisintensivsten Bereiche einer SOC-2-Prüfung und erwarten, dass die Nachweise aus einem dokumentierten System stammen und nicht aus einer unmittelbar vor der Feldarbeit erstellten Rekonstruktion.

Fünf Artefakte, nach denen Prüfer tatsächlich fragen

In beiden Rahmenwerken reduziert sich die vom Gutachter angeforderte spezifische Nachweismenge auf fünf Artefakte:

• Eine vollständige Schlüsselinventur mit Fingerabdruck, Host und Entdeckungsdatum, zeitgestempelt auf den Überprüfungszeitraum.
• Ein eingetragener Eigentümer Für jeden Schlüssel, der einer bestimmten Person, einem Team oder einer Pipeline zugeordnet ist, nicht einem generischen Konto.
• Ein Protokoll für Richtlinienausnahmen Jede Abweichung von den Standardrichtlinien, wie z. B. ein umgebungsübergreifender Schlüssel, wird dokumentiert, wobei der Genehmiger und die geschäftliche Begründung festgehalten werden.
• Rotations- und Widerrufshistorie Anzeige des Zeitpunkts der letzten Schlüsselrotation und Bestätigung, dass die Schlüssel ausgeschiedener Mitarbeiter beim Ausscheiden aus dem Unternehmen und nicht erst beim nächsten planmäßigen Zyklus widerrufen wurden.
• Eine unterzeichnete Überprüfungsbestätigung In diesem Dokument bestätigt der verantwortliche Eigentümer oder Manager für den Überprüfungszeitraum, dass der Zugriff überprüft wurde und weiterhin angemessen ist.

Über die beiden oben genannten Rahmenwerke hinaus definiert NIST SP 800-192 Verifikations- und Testmethoden, um zu bestätigen, dass eine Zugriffskontrollrichtlinie tatsächlich wie vorgesehen durchgesetzt wird. Dies ist eine nützliche Referenz, wenn der Validierungsschritt des Mapping-Prozesses so gestaltet wird, dass ein Prüfer ihn unabhängig überprüfen kann, anstatt ihn einfach blind zu akzeptieren ( NIST SP 800-192, Verifikations- und Testmethoden für Zugriffskontrollrichtlinien/-modelle ).

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.

Manuelle Tabellenkalkulationsverfolgung vs. automatisierte Erkennung und Zuordnung: Welche Methode ist die richtige für Sie?

Studien zeigen, dass 60 bis 90 Prozent der Unternehmen keine vollständige Übersicht ihrer aktiven SSH-Schlüssel besitzen und viele immer noch manuelle Prozesse wie Tabellenkalkulationen zur Schlüsselverwaltung nutzen. Dieser Ansatz stößt jedoch schon bei den hohen Datenmengen, die die meisten Unternehmen verarbeiten, an seine Grenzen.

Abmessungen	Manuelle Tabellenkalkulationsverfolgung	Automatisierte Erkennung und Zuordnung
Abdeckung	Beruht auf selbst gemeldeten Schlüsseln; nicht gescannte Hosts sind unsichtbar.	Sowohl agentenbasierte als auch agentenlose Scans finden Schlüssel unabhängig davon, ob sie jemand gemeldet hat.
Eigentumsgenauigkeit	Verliert innerhalb weniger Wochen an Wert, da sich Personal und Produktionsabläufe ändern.	Wird kontinuierlich anhand von Verzeichnis- und Nutzungsdaten aktualisiert.
Zeit für eine Überprüfung	Tage bis Wochen manueller Abgleich pro Zyklus.	Prüffertige Berichte werden auf Anfrage erstellt.
Offboarding-Reaktion	Hängt davon ab, dass jemand daran denkt, die Tabelle zu überprüfen.	Automatischer Widerruf, der direkt durch ein Ereignis im Personalwesen oder im Verzeichnis ausgelöst wird, das zum Ausscheiden aus dem Arbeitsverhältnis führt.
Prüfnachweis	Die Zusammenstellung erfolgte manuell vor Beginn der Feldarbeit; es ist schwer nachzuweisen, dass sie den tatsächlichen Untersuchungszeitraum widerspiegelt.	Zeitgestempelte Bestands-, Rotations- und Bestätigungsaufzeichnungen, die als Nebenprodukt des normalen Betriebs entstehen.
Skalierbar auf Tausende von Tasten	Nein; das reicht bei weitem nicht für Unternehmenskunden.	Ja, das ist der Hauptgrund, warum Unternehmen es einsetzen.

Tabellenkalkulationen sind an sich kein Problem der Governance; sie scheitern an ihrer Skalierbarkeit. Ein Team kann fünfzig Schlüssel in einer Tabellenkalkulation einigermaßen gut verwalten. Kein Team kann jedoch manuell eine genaue und fortlaufend aktualisierte Besitzdokumentation für Zehntausende von Schlüsseln in einer verteilten Umgebung führen. Deshalb ist die automatisierte Erkennung und Zuordnung der Besitzdaten erst dann verlässlich, wenn sie überprüft werden können.

Wie reagieren Sie, wenn während einer Überprüfung ein verwaister Schlüssel auftaucht?

Das Auffinden eines nicht zugeordneten, privilegierten Schlüssels während einer Überprüfung ist keine Seltenheit, und Ihre Reaktion darauf ist genauso wichtig wie die Entdeckung selbst. Behandeln Sie dies als einen abgeschlossenen Vorfall und nicht als routinemäßige Bereinigung: Löschen Sie den Schlüssel auf keinen Fall. Das Entfernen des falschen Schlüssels kann Backups, Bereitstellungen oder einen nicht dokumentierten Notfallzugriffspfad beschädigen. Setzen Sie ihn stattdessen unter Quarantäne (blockieren Sie die weitere Authentifizierung, lassen Sie ihn aber an seinem Platz) und überprüfen Sie seine zuletzt verwendeten Telemetriedaten, um festzustellen, ob er aktiv genutzt wird.

Zweitens: Verfolgen Sie alle Hosts, denen der Schlüssel vertraut, nicht nur den, auf dem er gefunden wurde. Ein auf einem Server entdeckter Schlüssel ist häufig über dieselbe Vertrauensbeziehung auf mehreren anderen Servern autorisiert. Drittens: Planen Sie die spätere Entfernung über die Konfigurationsverwaltung während eines Wartungsfensters und überwachen Sie das Verhalten von Anwendung und Pipeline unmittelbar danach. Viertens: Dokumentieren Sie den Befund, die Untersuchung und die Lösung in derselben Dokumentation, die auch für die umfassendere Überprüfung verwendet wird. Ein Auditor wird nämlich fragen, wie mit einem während des Zyklus entdeckten verwaisten Schlüssel umgegangen wurde, und nicht nur, ob ein solcher existierte. Schließlich: Geben Sie die Ursache wieder in den Besitzverwaltungsprozess ein: Wenn der Schlüssel auftauchte, weil der Zugriff eines ausscheidenden Mitarbeiters nie widerrufen wurde, handelt es sich um eine Lücke im Offboarding-Prozess und nicht um eine einmalige Ausnahme.

Was bedeutet das für die einzelnen Sicherheitsakteure?

Die Festlegung der Eigentumsverhältnisse ist nicht die Aufgabe eines einzelnen Teams. 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 sieht der praktische Implementierungsablauf aus?

Die Schließung der Eigentumslücke ist ein sequenzielles Programm, das größtenteils vor dem nächsten Überprüfungszyklus abgeschlossen werden kann, wenn es gezielt begonnen wird. Dies baut direkt auf dem oben beschriebenen vierstufigen Mapping-Prozess auf und macht ihn zu einer ständigen Routine.

1. Umfassende Entdeckung über alle Schlüssel und Hosts hinweg: Nutzen Sie sowohl agentenbasierte als auch agentenlose Erkennung, um jeden SSH-Schlüssel auf Servern und Benutzerrechnern zu finden, und dehnen Sie die gleiche Vorgehensweise auf API-Token und Service-Account-Anmeldeinformationen aus.
2. Schlüssel mithilfe mehrerer Signale Besitzern zuordnen: Ordnen Sie private Schlüssel den Konten und Pipelines zu, die sie verwenden, korrelieren Sie diese mit Verzeichnis- und HR-Daten und verwenden Sie die zuletzt verwendete Telemetrie, um aktive Schlüssel von inaktiven zu unterscheiden.
3. Klassifizierung nach Privilegien und Exposition, nicht nur nach Alter: Priorisieren Sie Schlüssel mit Root- oder administrativer Reichweite, Schlüssel, die Vertrauensgrenzen wie Nicht-Produktions- und Produktionsumgebungen überbrücken, und Schlüssel, die innerhalb der Richtlinie nicht rotiert wurden.
4. Trennung von Ermittlung und Behebung: Beginnen Sie die Bereinigung niemals mit dem Löschen unbekannter Schlüssel. Führen Sie die Entfernung schrittweise über die Konfigurationsverwaltung während eines Wartungsfensters durch und überwachen Sie das Anwendungsverhalten unmittelbar danach.
5. Ersetzen Sie Aktivitätskennzahlen in der Berichterstattung durch Expositionskennzahlen: Anstatt zu melden, wie viele Elemente überprüft wurden, sollten Identitäten ohne Eigentümer, Anmeldeinformationen, die älter als die Richtlinien sind, und privilegierte Schlüssel, die außerhalb der normalen Muster auf sensible Systeme zugreifen, verfolgt werden.
6. Verringern Sie die Anzahl der verfügbaren Rezensionen, damit zukünftige Überprüfungen kleiner werden: Wo immer möglich, sollte man von langlebigen Schlüsseln auf kurzlebige, automatisch rotierte Anmeldeinformationen umsteigen, damit der dauerhafte Zugriff auf Attribute reduziert wird.
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.

Einschränkungen

Die Zuordnung von Eigentumsrechten schließt eine bestimmte Lücke; sie löst jedoch nicht jedes SSH-Governance-Problem allein, und es ist wichtig, offen zu benennen, was sie ungelöst lässt.

• Es ersetzt nicht das Privileged Access Management (PAM). Die Besitzverhältnisse geben an, wer für einen permanenten Schlüssel verantwortlich ist; sie ermöglichen jedoch nicht von sich aus einen bedarfsgerechten Zugriff oder die Abschaffung permanenter Anmeldeinformationen, wie es sitzungsbasierte PAM-Kontrollen können.
• Um die Genauigkeit zu gewährleisten, ist die Zustimmung der gesamten Organisation erforderlich. Ein Eigentumsnachweis, den die Eigentümer nicht anerkennen oder der bei der Erstellung neuer Schlüssel umgangen wird, verfällt wieder in denselben anonymen Zustand, den das Programm eigentlich beheben sollte.
• Das Risiko durch legitime, ordnungsgemäß besessene Schlüssel wird dadurch nicht beseitigt. Ein korrekt zugeordneter Root-Schlüssel ist nach wie vor ein wertvolles Ziel; die Eigentümerschaft macht ihn nachvollziehbar und widerrufbar, aber nicht unverwundbar.
• Der Discovery-Bereich hängt davon ab, was Sie scannen können. Systeme ohne Air-Gap, nicht verwaltete persönliche Geräte und Schatteninfrastrukturen, die außerhalb der Sichtweite der IT liegen, werden in einem Inventar, das nur aus bekannten Hosts erstellt wurde, nicht angezeigt.
• Es ist ein Teil eines umfassenderen Programms zur Verwaltung von Qualifikationsnachweisen. API-Tokens, OAuth-Geheimnisse und Cloud-Workload-Anmeldeinformationen benötigen die gleiche Eigentumsdisziplin, und die isolierte Behandlung von SSH-Schlüsseln führt dazu, dass diese anderen privilegierten Anmeldeinformationen genauso unkontrolliert bleiben wie zuvor.

Was würde Encryption Consulting empfehlen?

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. So wird der Zugriff bei einem Ausscheiden aus dem Unternehmen oder einem Rollenwechsel sofort gesperrt, anstatt auf den nächsten geplanten Zyklus zu warten.
• 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 in der gesamten Umgebung, reduziert manuelle Fehler und sichert unternehmensweite Sicherheitsstandards.
• Kontinuierliche Überwachung, Prüfung und Bereitschaft zur Einhaltung von Vorschriften: SSH Secure bietet Echtzeitüberwachung wichtiger Aktivitäten mit detaillierter Ereignisprotokollierung und integrierter Anomalieerkennung. Die Protokolle lassen sich in Splunk- oder Grafana-Loki-Dashboards integrieren, um erweiterte Visualisierungen, Korrelationen und Warnmeldungen zu ermöglichen. Herunterladbare Prüfberichte entsprechen direkt den Nachweisdokumenten, die ein SOC-2- oder PCI-DSS-Prüfer anfordert.

Die Implementierung eines HSM-gestützten SSH-Schlüsselmanagements im Unternehmensmaßstab erfordert mehr als nur die Auswahl der richtigen Hardware. Sie bedarf der Erkennung, der Orchestrierung des gesamten Lebenszyklus, der Durchsetzung von Richtlinien und der kontinuierlichen Transparenz in einer komplexen Umgebung – genau das, wofür SSH Secure entwickelt wurde.

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 die Schlüssel, korrelieren Sie sie mithilfe von Verzeichnis-, Pipeline- und Nutzungssignalen mit den jeweiligen Inhabern, weisen Sie ihnen anhand des passenden Modells einen benannten Inhaber zu und validieren Sie das Ergebnis anhand der Richtlinien, bevor der Auditor dies für Sie übernimmt. Verknüpfen Sie die Schlüsselrotation mit den tatsächlichen Inhaberwechseln, insbesondere mit dem Offboarding, und halten Sie Nachweise, Inventar, Inhaberverzeichnis, Ausnahmeprotokoll, Rotationsverlauf und Attestierung als Nebenprodukt des normalen Betriebs aktuell, anstatt sie erst kurz vor der Feldprüfung in aller Eile zusammenzutragen. So wird die nächste Zugriffsprüfung nicht länger zu einer Glücksspielübung, sondern zu einer verlässlichen Aussage darüber, wer auf welche Schlüssel zugreifen darf und warum. Für das vollständige Lebenszyklusprogramm, das diese Zuordnung unterstützt, lesen Sie unseren umfassenden Leitfaden zum SSH-Schlüssellebenszyklusmanagement . Was passiert, wenn diese Zuordnung nicht durchgeführt wird, erfahren Sie unter „ Warum nicht verwaltete SSH-Schlüssel Ihre größte Sicherheitslücke im Bereich privilegierter Zugriffe darstellen“.

Häufig gestellte Fragen

Worin besteht der Unterschied zwischen dem Besitz eines SSH-Schlüssels und dem SSH-Schlüsselinventar?
Eine Bestandsaufnahme zeigt Ihnen, ob ein Schlüssel existiert und wo er sich befindet. Die Eigentümerstruktur klärt, wer dafür verantwortlich ist, warum er existiert und wer bestätigt, ob er bleiben soll. Für eine Überprüfung sind beide Aspekte notwendig; eine Bestandsaufnahme ohne Eigentümerstruktur zeigt Ihnen lediglich, worüber Sie sich Sorgen machen sollten, nicht aber, wie Sie weiter vorgehen.

Wie oft sollten SSH-Schlüssel im Rahmen eines Compliance-Audits überprüft werden?
PCI DSS 4.0.1 Anforderung 7.2.4 schreibt eine Mindestprüfung alle sechs Monate für allgemeine Benutzer- und privilegierte Konten vor, während System- und Servicekonten in einer vom Unternehmen im Rahmen der Risikobewertung gemäß Anforderung 7.2.5.1 festgelegten Häufigkeit geprüft werden. SOC 2 legt kein spezifisches Intervall fest, aber die Prüfer erwarten einen dokumentierten, wiederholbaren Prüfungsrhythmus und keine einmalige Ad-hoc-Prüfung.

Was sollen wir mit einem Schlüssel tun, den wir keinem Besitzer zuordnen können?
Setzen Sie die Datei unter Quarantäne, anstatt sie sofort zu löschen. Ermitteln Sie alle Hosts, auf denen sie als vertrauenswürdig eingestuft wird, und melden Sie den Vorfall als relevanten Befund. Dokumentieren Sie die Untersuchung und deren Ergebnis, da ein im Rahmen einer Überprüfung entdeckter und behobener nicht zugeordneter Schlüssel ein stärkerer Nachweis für die Auditierung ist als eine Überprüfung, bei der er gar nicht erst aufgetaucht ist.

Macht die regelmäßige Rotation der SSH-Schlüssel die Zuordnung der Besitzverhältnisse überflüssig?
Nein. Die Rotation ersetzt lediglich das Schlüsselmaterial; sie gibt aber keine Auskunft darüber, wer für den neuen Schlüssel verantwortlich ist oder ob der Zugriff noch benötigt wird. Ohne Verantwortlichkeit erzeugt die Rotation lediglich einen neuen Schlüssel, der dieselben offenen Fragen aufwirft.

Kann eine Tabellenkalkulation zur Verwaltung der SSH-Schlüsselverwaltung in einer kleinen Umgebung verwendet werden?
Für eine Handvoll Server und ein kleines, stabiles Team kann eine gut gepflegte Tabellenkalkulation vorübergehend ausreichen. Sie stößt jedoch an ihre Grenzen, sobald die Anzahl der Schlüssel in die Hunderte oder Tausende steigt, sich die Zuständigkeiten aufgrund von Personalwechseln ändern und ein Prüfer genau dann Nachweise verlangt, die den tatsächlichen Prüfungszeitraum widerspiegeln und nicht eine kurz vor der Feldarbeit erstellte Rekonstruktion.

Referenzen

• NIST, „Sicherheit der interaktiven und automatisierten Zugriffsverwaltung mittels Secure Shell (SSH)“, NISTIR 7966 (2015)
• NIST SP 800-192, Verifizierungs- und Testmethoden für Zugriffskontrollrichtlinien/-modelle
• NIST SP 800-57 Teil 1 Rev. 5, Empfehlung für das Schlüsselmanagement
• PCI Security Standards Council, PCI DSS v4.0.1 Dokumentenbibliothek
• PCI DSS v4.0 Anforderung 7: Überprüfung von Konten und Zugriffen
• PCI-DSS-Dienstkontoanforderungen, Schellman
• SOC 2 CC6: Logische und physische Zugriffskontrollen