SSH-Schlüsselmanagement-Konformität: Was Auditoren erwarten und wie Sie sie gewährleisten

SSH-Schlüssel sind leistungsstarke, langlebige Zugangsdaten, deren vollständige Verwaltung, Überwachung, regelmäßige Rotation und rechtzeitige Sperrung von Auditoren erwartet wird. Da SSH-Schlüssel nicht automatisch ablaufen , muss die Organisation für sie dieselben strengen Richtlinien zur Verwaltung des Lebenszyklus anwenden wie für alle anderen privilegierten Zugangsdaten. Ohne aktive Governance sammeln sich SSH-Schlüssel zu verwaisten Hintertüren an: ohne Ablaufdatum, ohne Nachweis der Inhaberschaft und ohne Audit-Trail. Die empfohlene Vorgehensweise: Behandeln Sie jeden SSH-Schlüssel wie einen privilegierten Zugangsdaten, erstellen Sie ein Inventar, weisen Sie die Inhaberschaft zu, erzwingen Sie die Rotation und Sperrung und pflegen Sie die Sitzungsprotokolle und Zugriffsnachweise, die von PCI DSS, ISO 27001, SOC 2, NIST und CIS gefordert werden.

Kurzantwort: Was bedeutet SSH-Schlüsselmanagement-Konformität?

Die Einhaltung der Vorschriften für das SSH-Schlüsselmanagement bedeutet, Auditoren nachzuweisen, dass jeder SSH-Schlüssel in Ihrer Umgebung im Besitz des jeweiligen Unternehmens ist, kontrolliert, überwacht und rechtzeitig entfernt wird. Wichtige Rahmenwerke wie PCI DSS v4.0.1, ISO 27001, SOC 2 und NIST SP 800-53 setzen voraus, dass SSH-Schlüssel mit der gleichen Sorgfalt wie andere privilegierte Zugangsdaten verwaltet werden. Der Unterschied zwischen dem Bestehen und dem Nichtbestehen eines SSH-Schlüssel-Audits liegt fast immer in Prozess- und Nachweislücken, nicht in kryptografischen. Informationen zum grundlegenden Rahmenwerk für die SSH-Schlüsselrotation finden Sie unter „ Entwicklung einer effektiven SSH-Schlüsselrotationsrichtlinie“ . Informationen zur SSH-Schlüssel-Governance finden Sie unter „ Wie das SSH-Schlüsselmanagement die Sicherheit stärkt“.

Warum wurden SSH-Schlüssel zu einem Compliance-Problem?

Das Design des SSH-Schlüssels verursacht das Compliance-Problem. Ein SSH-Schlüssel besteht aus einem Paar: Der private Schlüssel verbleibt beim Benutzer oder Dienst; der öffentliche Schlüssel befindet sich auf dem Zielserver in einer Datei namens `authorized_keys`. Stimmen beide Schlüssel überein, wird der Zugriff ohne Passwortabfrage und ohne Ablaufdatum gewährt. Die Protokollarchitektur ist in RFC 4251 beschrieben.

Dieses Design ist zwar praktisch, aber genau das ist das Problem. Schlüssel sammeln sich unkontrolliert an, da die Bereinigung fast immer manuell erfolgt. Im Laufe der Jahre verlieren die meisten Teams den Überblick darüber, wie viele Schlüssel existieren und worauf jeder einzelne Zugriff hat. In der Branche spricht man von Schlüsselverbreitung : zu viele Schlüssel ohne klare Zuordnung zu Besitzer und Zugriffsrechten. Ein Auditor nennt es unkontrollierten Zugriff.

Die unkontrollierte Ausbreitung von SSH-Verbindungen ist nur ein Teil des Problems. Die meisten SSH-Sitzungen werden nicht protokolliert, sodass keine Aufzeichnungen darüber existieren, wer sich wann und mit welchem ​​Netzwerk verbunden hat. Ohne diese Aufzeichnungen kann ein einziger missbräuchlich verwendeter Schlüssel zu einer Sicherheitslücke führen, die sich weder erklären, rekonstruieren noch zuordnen lässt. Maschinenidentitäten sind mittlerweile deutlich zahlreicher als menschliche Identitäten, und diese Kluft vergrößert sich mit dem Ausbau von Cloud Computing, Automatisierung und KI stetig. Viele dieser Maschinenidentitäten authentifizieren sich mit SSH-Schlüsseln. Kann ein Unternehmen nicht nachweisen, wem ein Schlüssel gehört oder welche Funktionen er freischaltet, kann es die Kontrolle im Rahmen einer Compliance-Prüfung nicht belegen.

Was bedeutet „Managed“ im Kontext von Compliance?

Prüfer verlangen keine Einsicht in private Schlüssel. Sie wollen den Prozess nachvollziehen. Die klarste Referenz liefert das NIST. Der NIST Internal Report (NISTIR) 7966 ist die offizielle Richtlinie für die Sicherung des SSH-Zugriffs. Er beschreibt den Lebenszyklus des Schlüssels: Zugriff anfordern und genehmigen, Schlüssel bereitstellen, dessen Verwendung überwachen, ihn regelmäßig rotieren und ihn entfernen, sobald er nicht mehr benötigt wird.

Ein revisionssicheres SSH-Schlüsselprogramm umfasst sechs Punkte:

• Inventar: Jeder Schlüssel ist dokumentiert, sein Standort ist bekannt und es ist festgehalten, worauf er zugreifen kann.
• Eigentümer: Jeder Schlüssel verweist auf eine namentlich genannte Person oder einen namentlich genannten Dienst.
• Geringstes Privileg: Ein Schlüssel reicht nur bis zu dem Punkt, den er für seine Aufgabe benötigt, nicht weiter.
• Drehung: Die Schlüssel werden planmäßig und sofort gewechselt, wenn jemand das Haus verlässt oder ein Kompromittierungsverdacht besteht.
• Monitoring: Jede privilegierte Sitzung wird protokolliert und die Aktivitäten werden auf anomale Muster überprüft.
• Widerruf: Der Zugriff wird schnell entfernt, und die Organisation kann dies mit datierten Aufzeichnungen belegen.

Wird auch nur eine dieser Kontrollen vernachlässigt, entsteht eine Lücke, die ein Prüfer feststellen wird. Genau diese sechs Kontrollen werden von den wichtigsten Compliance-Rahmenwerken vorausgesetzt.

Wie gehen die wichtigsten Frameworks mit SSH-Schlüsseln um?

Kaum ein Framework verwendet den Begriff „SSH-Schlüssel“. Sie beschreiben Ergebnisse. Sobald diese Ergebnisse als Regeln für Anmeldeinformationen interpretiert werden, wird die Zuordnung deutlich:

Unser Ansatz	Was es für Ihre SSH-Schlüssel erwartet	Wichtige SSH-relevante Kontrollen
PCI-DSS v4.0.1	Einzigartige Identität für jeden Benutzer, keine gemeinsam genutzten Anmeldeinformationen, strenge Kontrolle über Systemkontoschlüssel	Anforderung 8 (Benutzeridentität, Verbot der gemeinsamen Schlüsselverwendung); Anforderung 8.6 (Anwendungs-/Systemkonten, Verbot fest codierter Geheimnisse); Anforderung 7.2.4 (Zugriffsüberprüfungen alle sechs Monate)
ISO / IEC 27001: 2022	Verwaltete Identitäten, kontrollierte Zugriffsrechte, geschützter privilegierter Zugriff, korrekte Kryptografie	Anhang A 5.15 bis 5.18 (Identitäts- und Zugriffsmanagement); 8.2 (Privilegierter Zugriff); 8.24 (Verwendung von Kryptographie)
SOC 2	Logische Zugriffskontrollen, die Zugriffe mit nachweisbaren Belegen gewähren, überprüfen und entziehen	CC6.1 (logische Zugriffskontrollen); CC6.2 (Authentifizierung); CC6.3 (Zugriffsentzug)
NIST-SP 800-53	Kontoverwaltung, Zugriffsdurchsetzung und Authentifizierungsmanagement	AC-2 (Kontoverwaltung); AC-3 (Zugriffsdurchsetzung); IA-5 (Authentifikatorverwaltung)
CIS Controls v8	Konto- und Zugriffskontrollverwaltung, Entfernung veralteter oder ungenutzter Anmeldeinformationen	Control 5 (Kontoverwaltung); Control 6 (Zugriffskontrollverwaltung)

PCI DSS ist der strengste Rahmen für dieses Thema. Die Anforderungen von PCI DSS v4.0.1 mit Zukunftstermin traten am 31. März 2025 in Kraft. Anforderung 8 verlangt eindeutige Identitäten für alle Benutzer. Gemeinsam genutzte SSH-Schlüssel verstoßen gegen diese Regel, da Authentifizierungsprotokolle die Benutzer nicht unterscheiden können, wenn ein einziger Schlüssel gemeinsam genutzt wird. Anforderung 8.6.2 verlangt, dass Passwörter und Passphrasen für Anwendungs- und Systemkonten nicht fest in Skripten, Konfigurationsdateien oder Quellcode codiert werden dürfen. Dasselbe gilt direkt für private SSH-Schlüssel: Ein in ein Bereitstellungsskript eingebetteter privater Schlüssel ist genau die Art von fest codierter Anmeldeinformation, die diese Anforderung beanstandet.

ISO/IEC 27001:2022 verfolgt einen risikobasierten Ansatz. Die Kontrollen in Anhang A fordern die Verwaltung von Identitäten, die Kontrolle von Zugriffsrechten, den Schutz privilegierter Zugriffe und die korrekte Anwendung von Kryptografie. SSH-Schlüssel berühren alle vier Bereiche. SOC 2 konzentriert sich darauf, ob logische Zugriffskontrollen tatsächlich funktionieren und ob die Organisation dies nachweisen kann. Die CIS-Kontrollen sind am operativ konkretsten und beinhalten klare Schritte für die Kontoverwaltung und die Entfernung nicht mehr benötigter Zugriffe.

Auch Datenschutzbestimmungen gelten. Artikel 32 der DSGVO fordert angemessene Sicherheit für personenbezogene Daten. Ein ungeschützter SSH-Schlüssel, der Systeme mit personenbezogenen Daten offenlegt, stellt einen Sicherheitsverstoß dar. HIPAA sieht ähnliche Zugriffskontrollanforderungen für Gesundheitssysteme vor. Das Prinzip ist in allen Systemen einheitlich: Zugangsdaten kennen, beschränken, überwachen und rechtzeitig entfernen.

SSH-Schlüssellebenszyklusverwaltung für Compliance

Stadium des Lebenszyklus	Aktivität	Eigentümer	Nachweise über die Einhaltung der Vorschriften erstellt
Antrag und Genehmigung	Benutzer oder Dienst beantragen SSH-Zugriff; der Zugriff wird basierend auf dem Geschäftsbedarf und dem Prinzip der minimalen Berechtigungen genehmigt.	Zugriffsprüfer; Manager	Genehmigungsnachweis mit geschäftlicher Begründung
Provisioning	Schlüsselpaar mithilfe eines zugelassenen Algorithmus generiert (Ed25519 bevorzugt, RSA-3072 mindestens); öffentlicher Schlüssel auf autorisierten Servern bereitgestellt	SSH-Schlüsselverwaltungsplattform oder Schlüsseladministrator	Generierungsprotokoll mit Algorithmus, Schlüsselfingerabdruck und Zielsystemen
Nutzung und Überwachung	Alle SSH-Sitzungen wurden mit Fingerabdruck des Schlüssels, Zeitstempel, Quell-IP-Adresse und Zielsystem protokolliert.	Automatisierte Protokollierung; Sicherheitsoperationen	Sitzungsprotokolle für Compliance-Prüfungen und Vorfallsreaktion
Regelmäßige Zugriffsüberprüfung	Alle SSH-Schlüsselautorisierungen wurden überprüft; verwaiste oder nicht autorisierte Schlüssel wurden entfernt; die Eigentumsverhältnisse wurden bestätigt.	Schlüsselverantwortlicher; Zugriffsprüfer	Datumsbezogenes Prüfprotokoll mit den durchgeführten Maßnahmen (Schlüssel entfernt, gedreht, bestätigt)
Rotation	Schlüsselrotation nach einem im Rahmen der Richtlinien festgelegten Zeitplan (zeitbasiert) oder bei Ereignisauslösung (Abgang, Kompromiss, Außerbetriebnahme)	Automatisierte SSH-Schlüsselverwaltungsplattform	Rotationsprotokoll mit Datum, Auslösertyp und Bediener
Widerruf	Öffentlicher Schlüssel aus allen authorized_keys-Dateien entfernt; Zugriffsbestätigung entfernt	Automatischer Auslöser bei Abreise oder Kompromittierungsereignis	Widerrufsprotokoll mit Auslösedatum, Abschlussdatum und Bestätigung

Rotationsauslöser: Wenn eine geplante Rotation nicht ausreicht

Zeitbasierte Rotationspläne bilden die Grundlage für die Einhaltung der Vorschriften. Ereignisbasierte Auslöser dienen als Sicherheitsnetz, um schwerwiegendste Prüfungsfeststellungen zu verhindern.

• Ausscheiden oder Funktionswechsel des Mitarbeiters: Alle SSH-Schlüssel der ausscheidenden oder die Rolle wechselnden Person sind unverzüglich zu rotieren und zu widerrufen. Die Zeitspanne zwischen Austrittsmitteilung und Abschluss des Widerrufs ist zu dokumentieren; Prüfer achten auf diese Zeitspanne.
• Verdacht auf oder bestätigte Kompromittierung eines Schlüssels: Der betroffene Schlüssel wird umgehend widerrufen; ein Ersatzschlüssel wird generiert und bereitgestellt; der zeitliche Ablauf des Vorfalls wird dokumentiert.
• Algorithmus veraltet: Jeder SSH-Schlüssel, der einen veralteten Algorithmus (DSA, RSA-1024) verwendet, muss umgehend durch einen zugelassenen Algorithmus ersetzt werden. Einen Algorithmenvergleich finden Sie hier: Vergleich von SSH-Schlüsseln: RSA, DSA, ECDSA oder EdDSA.
• Systemstilllegung: Alle mit außer Betrieb genommenen Systemen verbundenen SSH-Schlüssel müssen widerrufen werden; Schlüssel dürfen nicht systemübergreifend wiederverwendet werden.
• Beendigung des Auftragsverhältnisses mit Dritten oder Auftragnehmern: Bei Beendigung der Geschäftsbeziehung werden sämtliche SSH-Zugriffsrechte, die externen Parteien gewährt wurden, widerrufen.

Welche SSH-Schlüsselfehler führen zum Scheitern bei Audits?

Die meisten Prüfungsergebnisse sind nichts Besonderes. Sie wiederholen sich in verschiedenen Organisationen:

• Verwaiste Schlüssel: Ein Teammitglied verlässt das Unternehmen, sein Schlüssel bleibt jedoch auf den Servern aktiv. PCI DSS-Anforderung 8 und NIST AC-2 fordern die zeitnahe Entfernung nicht mehr benötigter Zugriffsrechte.
• Gemeinsame Schlüssel: Mehrere Personen verwenden einen Schlüssel, sodass keine Protokolle Aktionen einer einzelnen Person zuordnen können. PCI DSS-Anforderung 8 verlangt eindeutige Identitäten; gemeinsam genutzte Schlüssel verstoßen direkt dagegen.
• Fest codierte Tasten: Private Schlüssel, die in Skripten, Container-Images oder Konfigurationsdateien eingebettet sind, sind nicht zulässig. Die PCI-DSS-Anforderung 8.6.2 verbietet ausdrücklich fest codierte Geheimnisse für Systemkonten.
• Keine Drehung: Die vor Jahren bereitgestellten Schlüssel funktionieren auch heute noch ohne dokumentierte Rotation. Jedes Framework benötigt eine Form des Credential-Lifecycle-Managements.
• Keine Prüfspur: Es gibt keine Aufzeichnungen darüber, wer sich wann mit welchem ​​System verbunden hat. SOC 2 CC6 und NIST AC-3 fordern den Nachweis, dass die Zugriffskontrollen tatsächlich funktionieren.
• Kein Lagerbestand: Die Organisation kann auf Anfrage keine aktuelle Liste der SSH-Schlüssel bereitstellen. Die Bestandsaufnahme ist Voraussetzung für alle anderen Kontrollmaßnahmen; ohne sie lässt sich keine Rahmenwerksanforderung nachweisen.

Wie erstellt man ein revisionssicheres SSH-Schlüsselprogramm?

Ein stetiger, wiederholbarer Prozess ist die Voraussetzung für das Bestehen von Audits. Der folgende 7-stufige Implementierungsablauf schafft die von den Prüfern geforderten Nachweise:

1. Inventar erstellen: Scannen Sie jeden Server und lesen Sie jede Datei mit autorisierten Schlüsseln. Erstellen Sie ein zentrales Verzeichnis der Schlüssel, ihrer Besitzer und der Systeme, auf die sie zugreifen können. Was man nicht sieht, kann man nicht kontrollieren; ohne ein solches Verzeichnis lässt sich keine Compliance-Kontrolle nachweisen.
2. Weisen Sie jedem Schlüssel die Besitzrechte zu: Schlüssel ohne Besitzer haben keine Zuständigkeit. Entfernen Sie alle Schlüssel, die niemand beansprucht. Dokumentieren Sie die Besitzverhältnisse im Inventar mit Rolle, Geschäftsbereich und Zugriffsberechtigung.
3. Verfassen Sie eine kurze, klare Richtlinie: Rotationsperioden nach Risikostufe definieren (hohes Risiko alle 30 bis 90 Tage, mittleres Risiko alle 90 bis 180 Tage, niedriges Risiko alle 180 bis 365 Tage); eindeutige Schlüssel pro Person und Zweck vorschreiben; gemeinsam genutzte Schlüssel verbieten; fest im Code codierte private Schlüssel untersagen. Siehe Entwicklung einer effektiven SSH-Schlüsselrotationsrichtlinie für das vollständige Framework.
4. Rotation und Widerruf automatisieren: Manuelles Offboarding und Rotationsprozesse können zu Compliance-Lücken führen. Die automatisierte Rotation schließt die Lücke zwischen dem Ausscheiden eines Mitarbeiters und dem Entzug seiner Zugriffsrechte. Jede Rotation sollte mit Datum und Bearbeiter protokolliert werden, um Prüfungsnachweise zu ermöglichen.
5. Sitzungsprotokollierung aktivieren und zentralisieren: Jede privilegierte SSH-Sitzung wird mit Schlüssel-Fingerabdruck, Quell-IP-Adresse, Zeitstempel und Zielsystem protokolliert. Die Protokolle werden an ein SIEM-System weitergeleitet. Die Nachweise müssen vor der Anfrage des Auditors vorliegen.
6. Führen Sie regelmäßige Zugriffsüberprüfungen durch: PCI DSS schreibt halbjährliche Überprüfungen vor, CIS Controls vierteljährliche. Vierteljährliche Überprüfungen erfüllen beide Anforderungen und decken potenzielle Schwachstellen auf, bevor sie zu Beanstandungen führen. Jede Überprüfung ist mit Datum und durchgeführten Maßnahmen zu dokumentieren.
7. Erwägen Sie kurzlebige SSH-Zertifikate: Der stärkste Endpunkt für die Einhaltung der Vorschriften. Anstelle von permanenten Schlüsseln stellt eine vertrauenswürdige Zertifizierungsstelle Zertifikate aus, die nach wenigen Stunden ablaufen. Der Zugriff erlischt automatisch; es müssen keine alten Schlüssel später gelöscht werden. Dieses Modell entspricht dem Grundgedanken aller oben genannten Frameworks. Siehe SSH-Schlüssel vs. SSH-Zertifikate und Statische SSH-Schlüssel in kurzlebige Workload-Identitäten umwandeln für Anleitungen zur Implementierung.

Anforderungen an Zugangsrichtlinien und Prüfungsnachweise

Die Prüfer fordern bestimmte Nachweisarten an. Konfigurieren Sie die SSH-Schlüsselverwaltung so, dass diese vor Beginn der Prüfung erstellt werden:

• Aktueller SSH-Schlüsselbestand: Auflistung aller Schlüssel, ihres Fingerabdrucks, Besitzers, Bereitstellungsserver, Zugriffsbereichs, Erstellungsdatums, Datums der letzten Rotation und Datums der letzten beobachteten Nutzung.
• Zugriffsprüfungsprotokolle: datierte Aufzeichnungen über regelmäßige Überprüfungen, einschließlich der überprüften Schlüssel, der ergriffenen Maßnahmen (widerrufen, Rotation ausgelöst, Eigentum bestätigt) und der Identität des Prüfers.
• Rotationsnachweise: Protokolle, die zeigen, dass Schlüssel planmäßig oder ereignisgesteuert rotiert wurden, mit Datum, Auslösertyp und Bedieneridentität.
• Widerrufsnachweise: Aufzeichnungen über die Entfernung des SSH-Zugangs ausgeschiedener Mitarbeiter einschließlich Austrittsdatum, Datum des Abschlusses des Widerrufs und Bestätigung, dass die öffentlichen Schlüssel von allen autorisierten Servern entfernt wurden.
• Sitzungsprotokolle: Privilegierte SSH-Sitzungsprotokolle mit Angabe des Schlüsselfingerabdrucks, der Quell-IP-Adresse, des Zeitstempels und des Zielsystems, die für den vom jeweiligen Framework vorgeschriebenen Zeitraum aufbewahrt werden.
• Richtliniendokumentation: Die schriftliche SSH-Schlüsselverwaltungsrichtlinie definiert Kryptoperioden, Algorithmusanforderungen, Verbot der gemeinsamen Schlüsselverwendung, Verbot der Verwendung fest codierter Schlüssel und das Vorgehen bei Verdacht auf Schlüsselkompromittierung.

Notfallplan für SSH-Schlüsselkonformitätsereignisse

1. Sofortiger Widerruf: Den mutmaßlich kompromittierten Schlüssel auf allen Servern, auf denen er autorisiert ist, widerrufen; die vollständige Widerrufung bestätigen und den Zeitpunkt des Abschlusses protokollieren.
2. Generierung und Bereitstellung von Ersatzschlüsseln: Generieren Sie ein neues Schlüsselpaar mithilfe des genehmigten Algorithmus; 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 Sitzungsprotokolle auf Zugriffe während des vermuteten Kompromittierungszeitraums; stellen Sie fest, ob unautorisierte Aktivitäten stattgefunden haben.
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 geltenden Meldepflichten bei Datenschutzverletzungen.
5. Compliance-Dokumentation: Dokumentieren Sie den zeitlichen Ablauf des Vorfalls, die Ursache (wie der Schlüssel offengelegt wurde), den Zeitpunkt des Entzugs, den Ersatz und den Umfang der Zugriffe. Diese Dokumentation erfüllt die Anforderungen an den Nachweis der Reaktion auf Sicherheitsvorfälle gemäß PCI DSS, HIPAA und ISO 27001.
6. Richtlinienaktualisierung nach dem Vorfall: Ermitteln Sie, welche Kontrollmechanismen versagt haben (fehlendes Inventar, verzögerte Abmeldung, fest codierter Schlüssel) und aktualisieren Sie die SSH-Schlüsselverwaltungsrichtlinie, um die Lücke zu schließen.

Wie Verschlüsselungsberatung helfen kann

Eine wirksame SSH-Schlüsselverwaltung erfordert mehr als nur Richtlinien: Sie erfordert Automatisierung, die die von Prüfern erwarteten Nachweise liefert. SSH Secure von Encryption Consulting deckt alle sechs Compliance-Kontrollen ab:

• Zentralisierte Echtzeit-Bestandsverwaltung: Die agentenbasierte und agentenlose Erkennung findet jeden SSH-Schlüssel mit Eigentümer- und Nutzungsdaten und erfüllt so die Inventar- und Eigentümeranforderungen jedes Frameworks.
• Richtlinienbasierte RBAC: Jeder Schlüssel ist nur für die Systeme zugänglich, die seine Funktion erfordert, wodurch das Prinzip der minimalen Berechtigungen erfüllt wird. Genehmigungsworkflows erzeugen die von den Prüfern angeforderten Zugriffsbegründungen.
• Automatisierte Rotation und Widerrufung: Richtliniengesteuerte Rotation nach Zeitplan und sofortiger Widerruf bei bestimmten Ereignissen (Abreise, Kompromittierung) schließen das Zugriffsfenster. Jeder Rotations- und Widerrufsvorgang wird mit Datum, Auslösertyp und Bedieneridentität als Nachweis der Compliance protokolliert.
• Sitzungsprotokollierung und SIEM-Integration: Sämtliche Aktivitäten privilegierter SSH-Sitzungen werden protokolliert und in Splunk- oder Loki-Grafana-Dashboards integriert, wodurch die Überwachungs- und Audit-Trail-Anforderungen von PCI DSS, SOC 2 und NIST erfüllt werden.
• Ephemere und sitzungsgebundene Schlüssel: Private Schlüssel sind in FIPS 140-3 validierten HSMs geschützt; für sensible Operationen ausgegebene temporäre Schlüssel laufen automatisch ab, wodurch das Bereinigungsproblem vollständig entfällt.
• Herunterladbare Compliance-Berichte: Prüfungsfertige Exporte von Schlüsselinventar, Rotationshistorie, Widerrufsdatensätzen und Sitzungsprotokollen in Formaten, die für die Überprüfung durch den Gutachter geeignet sind.

Just-in-Time (JIT) SSH-Zugriff geht noch einen Schritt weiter: Er gewährt Zugangsdaten nur bei Bedarf und widerruft sie automatisch, sodass nach Beendigung der Sitzung kein dauerhafter Zugriff mehr ausgenutzt werden kann.

Fazit

SSH-Schlüssel sind leistungsstark, unauffällig und werden leicht vergessen. Diese Kombination macht sie zu einem Compliance-Risiko. Die Lösung ist einfach: Kennen Sie jeden Schlüssel, weisen Sie ihm einen Besitzer zu, beschränken Sie den Zugriff, rotieren und widerrufen Sie ihn rechtzeitig, protokollieren Sie die Sitzungen und überprüfen Sie die Zugriffsrechte regelmäßig. Wenn Sie diese sechs Punkte konsequent umsetzen, erfüllen Sie die meisten Anforderungen von PCI DSS, ISO 27001, SOC 2, NIST und CIS. Behandeln Sie SSH-Schlüssel als die privilegierten Zugangsdaten, die sie sind, und das nächste Audit wird zu einer Überprüfung gut dokumentierter Kontrollen anstatt zu einer hektischen Rekonstruktion der Zugriffshistorie. Weiterführende Informationen finden Sie unter „ Designing an Effective SSH Key Rotation Policy“ , „Securing SSH Keys with HSMs“ und „Passing SSH key audits“.

Häufig gestellte Fragen

Welche Anforderungen gelten für die Einhaltung der SSH-Schlüsselverwaltungsrichtlinien?

Sechs Kontrollmechanismen für jeden Schlüssel: Inventarisierung (jeder Schlüssel wird mit seinem Standort und Zugriffsbereich dokumentiert), Besitz (jeder Schlüssel ist mit einer namentlich genannten Person oder einem Dienst verknüpft), Prinzip der minimalen Berechtigungen (jeder Schlüssel greift nur auf die erforderlichen Systeme zu), Rotation (planmäßig und sofort bei Ausscheiden oder Kompromittierung), Überwachung (jede privilegierte Sitzung wird protokolliert und überprüft) und Widerruf (Zugriff wird umgehend mit datiertem Nachweis entfernt).

Welche Compliance-Rahmenwerke befassen sich speziell mit SSH-Schlüsseln?

Kein Framework erwähnt SSH-Schlüssel explizit. Sie beschreiben die Ergebnisse der Authentifizierung: PCI DSS v4.0.1 Anforderung 8 (eindeutige Identitäten, keine gemeinsam genutzten Schlüssel, Verbot fest codierter Geheimnisse in Anforderung 8.6.2); ISO 27001:2022 Anhang A 5.15–5.18, 8.2, 8.24 (Identitätsmanagement, privilegierter Zugriff, Kryptografie); SOC 2 CC6.1–CC6.3 (logische Zugriffskontrollen mit Nachweis); NIST SP 800-53 AC-2, AC-3, IA-5; CIS Controls v8 Kontrollen 5 und 6.

Welche SSH-Schlüsselprobleme verursachen am häufigsten Auditfehler?

Verwaiste Schlüssel (Schlüssel ehemaliger Mitarbeiter sind noch aktiv); gemeinsam genutzte Schlüssel (keine benutzerbezogene Prüfbarkeit); fest codierte Schlüssel in Skripten oder Images (verstößt gegen PCI DSS 8.6.2); keine Dokumentation zur Schlüsselrotation; kein Sitzungsprotokoll; keine Inventarliste (Schlüsselliste kann nicht auf Anfrage erstellt werden). Jeder dieser Punkte ist einer bestimmten Framework-Kontrolle zugeordnet.

Wie häufig sollten SSH-Schlüssel auf Konformität überprüft werden?

PCI DSS-Anforderung 7.2.4 verlangt Zugriffsüberprüfungen mindestens alle sechs Monate; CIS Control 5 fordert vierteljährliche Überprüfungen. Vierteljährliche Überprüfungen erfüllen beide Anforderungen. Ereignisbasierte Überprüfungen sind ebenfalls erforderlich: Ausscheiden eines Mitarbeiters oder der Verdacht auf eine Kompromittierung erfordern den sofortigen Entzug der Zugriffsberechtigung, nicht erst im nächsten planmäßigen Überprüfungszyklus.

Welche Nachweise muss eine Organisation für ein SSH-Schlüssel-Compliance-Audit vorlegen?

Aktuelles Schlüsselinventar; datierte Zugriffsprüfungsprotokolle mit den ergriffenen Maßnahmen; Rotationsnachweise mit Datum und Auslöserart; Widerrufsnachweise mit Austrittsdatum und Widerrufsabschlussdatum; Sitzungsprotokolle mit Schlüsselfingerabdruck, Quell-IP, Zeitstempel und Ziel; und schriftliche SSH-Schlüsselverwaltungsrichtlinie mit Kryptoperioden und Verfahren zur Reaktion auf Sicherheitsvorfälle.

Wie trägt SSH Secure zur Einhaltung der SSH-Schlüssel-Compliance-Anforderungen bei?

SSH Secure bietet: Echtzeit-Inventarisierung mit Eigentümerdaten; RBAC-Durchsetzung für minimale Berechtigungen; automatisierte, richtlinienbasierte Rotation und ereignisgesteuerte Sperrung mit Audit-Logs; Sitzungsprotokollierung mit SIEM-Integration; Ausstellung temporärer Schlüssel; und herunterladbare Compliance-Berichte zur Überprüfung durch den Gutachter. Private Schlüssel werden in FIPS 140-3-validierten HSMs geschützt.