10 Best Practices für die Verwaltung von Verschlüsselungsschlüsseln in Unternehmen

Das Management von Verschlüsselungsschlüsseln in Unternehmen regelt die Generierung, Speicherung, Verteilung, Rotation und Löschung kryptografischer Schlüssel innerhalb einer Organisation. Wie NIST SP 800-57 Part 1 Rev. 5 festlegt, hängt die Sicherheit kryptografisch geschützter Informationen direkt von der Stärke der Schlüssel und dem ihnen gewährten Schutz ab. Ein kompromittierter Verschlüsselungsschlüssel erfordert nicht die Entschlüsselung des Algorithmus: Er gewährt direkten Zugriff auf alle Daten, die dieser Schlüssel schützt. Empfohlene Maßnahmen: Implementieren Sie formale Schlüsselmanagementprozesse, die den gesamten Schlüssellebenszyklus abdecken, erzwingen Sie die hardwarebasierte Speicherung hochsensibler Schlüssel, automatisieren Sie die Schlüsselrotation und dokumentieren Sie die Vorgänge kontinuierlich.

Kurzantwort: Warum ist Enterprise Key Management wichtig?

Verschlüsselung schützt Daten; Schlüsselmanagement sichert die Fähigkeit zum Ver- und Entschlüsseln. Ein kompromittierter Verschlüsselungsschlüssel ermöglicht es Angreifern, geschützte Daten zu entschlüsseln, Dokumente oder Software in Ihrem Namen zu signieren, Ihre Systeme zu imitieren oder sich unbefugt in Ihrem Netzwerk zu bewegen. Die meisten kryptografischen Fehler in der Praxis sind auf Fehler im Schlüsselmanagement und nicht auf algorithmische Fehler zurückzuführen: fest codierte Schlüssel im Quellcode, nicht rotierte Zugangsdaten, verwaiste Schlüssel ehemaliger Mitarbeiter und manuelle Verwaltungsprozesse, die nicht skalierbar sind. Die folgenden zehn Best Practices gehen systematisch auf diese Fehlerquellen ein. Weitere Informationen zu Schlüsseltypen finden Sie in unseren Beiträgen zu Best Practices für das Management öffentlicher und privater Schlüssel sowie zu HSMs und Schlüsselmanagement.

Müssen Sie Ihre Verschlüsselungsschlüssel verwalten?

Kurz gesagt: Ja. Wie in NIST SP 800-57 Teil 1, Rev. 5, angegeben:

Letztendlich hängt die Sicherheit kryptographisch geschützter Informationen direkt von der Stärke der Schlüssel, der Effektivität der damit verbundenen kryptographischen Mechanismen und Protokolle sowie dem Schutz der Schlüssel ab. Geheime und private Schlüssel müssen vor unbefugter Offenlegung geschützt werden, und alle Schlüssel müssen vor Änderungen geschützt werden.

Die Kompromittierung von Verschlüsselungsschlüsseln könnte Angreifern Folgendes ermöglichen:

• Daten, die auf Servern gespeichert sind, extrahieren oder manipulieren; verschlüsselte Dokumente oder E-Mails lesen.
• Unterzeichnen Sie Anträge oder Dokumente im Namen Ihrer Organisation, wodurch die Verbreitung von Schadsoftware ermöglicht wird.
• Erstellen Sie Phishing-Websites, die Ihre legitimen Websites unter Verwendung Ihrer TLS-Zertifikate imitieren.
• Durchqueren Sie Ihr Unternehmensnetzwerk, indem Sie sich als eine autorisierte Person ausgeben.

10 wichtige Management-Best-Practices

1. Befolgen Sie die Best Practices zur Schlüsselgenerierung

Kryptografische Sicherheit beginnt mit der Schlüsselerzeugung. Verwenden Sie für alle Schlüsselmaterialien einen hardwarebasierten, echten Zufallszahlengenerator (TRNG), der dem NIST SP 800-90A-Standard entspricht. Wählen Sie Algorithmen und Schlüssellängen, die dem Anwendungsfall und der erforderlichen Schutzdauer entsprechen: RSA-3072 oder höher für asymmetrische Schlüssel; AES-256 für symmetrische Schlüssel; Ed25519 oder ECDSA P-256 für Signaturen. Schlüssel, die mit unzureichender Entropie oder veralteten Algorithmen erzeugt wurden, sind vom Zeitpunkt ihrer Erstellung angreifbar. Wählen Sie für Schlüssel, die Daten mit langfristiger Sensibilität schützen, Algorithmen, die über die gesamte erwartete Lebensdauer der Daten sicher bleiben. Berücksichtigen Sie dabei auch mögliche Migrationszeiträume für Post-Quanten-Algorithmen.

2. Verwenden Sie ein zentrales Schlüsselverwaltungssystem.

Ein zentrales Schlüsselverwaltungssystem (KMS) bildet die Governance-Ebene für alle kryptografischen Schlüssel. Es gewährleistet unternehmensweit einheitliche Richtlinien: Standards für die Schlüsselgenerierung, Rotationspläne, Zugriffskontrollen und Audit-Protokollierung. Ohne Zentralisierung verwalten Teams Schlüssel unabhängig voneinander mit Ad-hoc-Methoden (Tabellenkalkulationen, lokale Dateien, Umgebungsvariablen), was zu einer unübersichtlichen Schlüssellandschaft führt, die sich weder systematisch prüfen noch rotieren lässt. Das KMS ersetzt nicht die HSM-Hardware zum Schutz der Schlüssel; es stellt die Verwaltungsebene dar, während das HSM die Speicher- und Ausführungsebene bildet.

3. Verwenden Sie Schlüsselverschlüsselungsschlüssel (KEKs).

Schlüsselverschlüsselungsschlüssel (KEKs) schützen andere Verschlüsselungsschlüssel und nicht direkt die Daten. In einer Schlüsselhierarchie gilt Folgendes: Daten werden mit Datenverschlüsselungsschlüsseln (DEKs) verschlüsselt; DEKs werden mit KEKs verschlüsselt (umhüllt); KEKs werden innerhalb eines HSM oder einer sicheren Hardwaregrenze gespeichert. Diese Hierarchie minimiert das Risiko: DEKs können verschlüsselt im allgemeinen Speicher vorliegen, während nur der KEK einen Schutz auf Hardwareebene benötigt. Wird ein einzelner DEK kompromittiert, sind nur die mit diesem DEK verschlüsselten Daten gefährdet; der KEK und alle anderen DEKs bleiben geschützt. Diese Isolation ist die Grundlage aller skalierbaren Architekturen für das Schlüsselmanagement in Unternehmen.

4. Wichtige Zugriffskontrollen einrichten

Zugriffskontrollen legen fest, wer (und welche Systeme) die einzelnen Schlüssel generieren, verwenden, rotieren, sichern und löschen darf. Diese Zugriffskontrollen müssen auf Schlüsselebene und nicht nur auf Systemebene implementiert werden. Zu den Kontrollen gehören: rollenbasierte Zugriffskontrolle (RBAC) zur Durchsetzung des Prinzips der minimalen Berechtigungen; Multi-Faktor-Authentifizierung für Schlüsselverwaltungsvorgänge; Funktionstrennung, die sicherstellt, dass keine einzelne Person einen sensiblen Schlüsselvorgang eigenständig durchführen kann; und die Protokollierung jedes Zugriffsereignisses. PCI DSS-Anforderung 3.7.6 fordert geteiltes Wissen und Vier-Augen-Prinzip für manuelle Schlüsselverwaltungsvorgänge; HSM-M-von-N-Quorummechanismen erfüllen diese Anforderung auf Hardwareebene.

5. Benutzerrollen und Zugriffsrechte zentralisieren

Nicht jeder Mitarbeiter oder jedes System benötigt Zugriff auf jeden Schlüssel. Definieren Sie Schlüsselverwalter, Schlüsselbenutzer und Schlüsseladministratoren als unterschiedliche Rollen mit dokumentierten Verantwortlichkeiten. Schlüsselverwalter steuern den Schlüssellebenszyklus (Generierung, Rotation, Widerruf); Schlüsselbenutzer führen kryptografische Operationen mit dem Schlüssel durch; Schlüsseladministratoren verwalten die Infrastruktur des Schlüsselverwaltungssystems. Stellen Sie sicher, dass kein einzelner Administrator exklusiven Zugriff auf Schlüsselmaterial hat: Verlässt ein Administrator das Unternehmen oder werden seine Zugangsdaten kompromittiert, muss die Organisation den Schlüsselbetrieb unabhängig von dieser Person fortsetzen können. Die zentrale Rollenverwaltung liefert zudem die für den Nachweis der Compliance notwendigen Prüfprotokolle.

6. Schlüsselsicherung und -wiederherstellung verwenden

Der Verlust eines kryptografischen Schlüssels, der nicht wiederherstellbare Daten schützt, stellt einen Datenverlust dar. Eine ordnungsgemäße Schlüsselsicherung gewährleistet, dass verschlüsselte Daten auch dann entschlüsselt werden können, wenn der primäre Schlüsselspeicher ausfällt. Schlüsselsicherungen müssen selbst verschlüsselt sein (mittels des Sicherungsmechanismus des HSM, nicht mit einem Softwarepasswort); an einem geografisch getrennten Ort vom primären Schlüsselspeicher aufbewahrt werden; durch M-of-N-Verwahrerberechtigungen geschützt sein, sodass keine einzelne Person die Sicherung eigenständig wiederherstellen kann; und jährlich durch eine Wiederherstellungsübung auf einem Sekundärsystem getestet werden. Eine ungetestete Sicherung ist für die Notfallwiederherstellung gleichbedeutend mit keiner Sicherung.

7. Schlüsselablauf verwenden (Kryptoperiodenmanagement)

Jeder Schlüssel sollte eine definierte Gültigkeitsdauer haben: den Zeitraum, in dem seine Verwendung autorisiert ist. NIST SP 800-57 empfiehlt Gültigkeitsdauern basierend auf Algorithmus, Schlüssellänge sowie Sensibilität und Umfang der geschützten Daten. Die Ablaufzeit von Schlüsseln minimiert das Risiko: Ein nicht mehr verwendeter Schlüssel kann nicht missbraucht werden. Definieren Sie Gültigkeitsdauern in den Richtlinien vor der Bereitstellung und konfigurieren Sie das Schlüsselverwaltungssystem so, dass diese automatisch durchgesetzt werden. Für TLS-Zertifikate schreibt das CA/Browser Forum derzeit eine maximale Gültigkeitsdauer von 398 Tagen vor, die auf 200 Tage (März 2026), 100 Tage (2027) und 47 Tage (2029) reduziert wird. Daher ist eine automatisierte Lebenszyklusverwaltung unerlässlich. Informationen zur Automatisierung des Zertifikatslebenszyklus finden Sie im CertSecure Manager .

8. Schlüsselwiderruf verwenden.

Die Sperrung eines Schlüssels führt sofort zur Ungültigkeit des Schlüssels, sodass er nicht mehr zum Entschlüsseln von Daten oder zur Authentifizierung verwendet werden kann. Eine Sperrung ist erforderlich, wenn: ein Schlüssel nachweislich oder mutmaßlich kompromittiert wurde; ein Mitarbeiter mit Schlüsselzugriff das Unternehmen verlässt; ein System, das den Schlüssel verwendet, außer Betrieb genommen wird; oder der vom Schlüssel verwendete Algorithmus veraltet ist. Die Sperrung muss an alle Systeme weitergegeben werden, die dem Schlüssel vertraut haben: Bei Zertifikaten bedeutet dies die Veröffentlichung der Sperrliste (CRL) und die Aktualisierung der OCSP-Antworten; bei SSH-Schlüsseln bedeutet dies das Entfernen des öffentlichen Schlüssels aus der Datei „authorized_keys“ auf allen Servern, auf die der Benutzer Zugriff hatte; bei symmetrischen Schlüsseln bedeutet dies, den Schlüssel im KMS als gesperrt zu markieren und seine Verwendung für jegliche neue Operationen zu verhindern.

9. Nutzen Sie die Automatisierung zu Ihrem Vorteil.

Die manuelle Schlüsselverwaltung ist in Unternehmensumgebungen nicht skalierbar. Versäumte Rotationsfristen, inkonsistente Zugriffskontrollen, vergessene Widerrufe und menschliche Fehler bei der Schlüsselgenerierung sind die Hauptursachen für Fehler in der Schlüsselverwaltung. Automatisierung begegnet diesen Risiken: Die automatisierte Schlüsselrotation nach festgelegten Richtlinien stellt sicher, dass die Rotation tatsächlich stattfindet; die automatisierte Zertifikatserneuerung verhindert ausfallbedingte Ausfälle; die automatisierte Weitergabe von Widerrufen stellt sicher, dass ehemalige Mitarbeiter keinen Zugriff behalten; die automatisierte Bestandsermittlung verhindert die Ansammlung verwaister Schlüssel. Informationen zur Automatisierung der Zertifikatsverwaltung finden Sie unter CertSecure Manager ; Informationen zur Automatisierung des SSH-Schlüssellebenszyklus finden Sie unter SSH Secure.

10. Vorbereitung auf den Umgang mit Zwischenfällen

Trotz korrekter Richtlinien und Kontrollen kommt es immer wieder zu Sicherheitslücken. Organisationen müssen daher vor einem solchen Vorfall einen dokumentierten Notfallplan bereithalten. Häufige Vorfälle sind beispielsweise:

• Der Benutzer verliert die Zugangsdaten zu seinen Schlüsseln.
• Der Mitarbeiter scheidet aus oder wird entlassen, während noch eine Schlüsselzugangsberechtigung besteht.
• Fehlerhafter Verschlüsselungsalgorithmus als veraltet oder defekt identifiziert.
• Menschliches Versagen: Privater Schlüssel versehentlich in einem öffentlichen Code-Repository veröffentlicht.
• Verdacht auf unbefugten Schlüsselzugriff in den Überwachungsprotokollen festgestellt.

Der Notfallplan muss Folgendes umfassen: sofortiger Entzug des mutmaßlich kompromittierten Schlüssels; Erstellung und Verteilung von Ersatzschlüsselmaterial; Folgenabschätzung zur Ermittlung der durch den kompromittierten Schlüssel geschützten Daten oder Systeme; Benachrichtigung der Beteiligten; und Nachbereitung des Vorfalls zur Ermittlung der Ursache und Aktualisierung der Kontrollmaßnahmen. Überprüfen Sie Ihre Sicherheitsinfrastruktur regelmäßig, um die Häufigkeit und die Auswirkungen von Vorfällen zu minimieren.

Wichtige Verantwortlichkeiten im Lebenszyklus: Wer ist in welcher Phase verantwortlich?

Stadium des Lebenszyklus	Aktivität	Eigentümer	Kontrolle
Generation	Erstelle ein Schlüsselpaar mithilfe eines TRNG; wähle Algorithmus und Schlüssellänge	Schlüsseladministrator oder automatisiertes KMS	Algorithmusrichtlinie; HSM-Grenzwertanforderung
Vertrieb	Öffentliche Schlüssel an vertrauenswürdige Systeme übermitteln; symmetrische Schlüssel sicher mithilfe von KEK-Wrapping verteilen.	KMS; PKI für zertifikatsbasierte öffentliche Schlüssel	Sicherer Kanal; Zertifikatsvalidierung
Lagerung	Schützen Sie private und symmetrische Schlüssel innerhalb eines HSM oder eines zugelassenen sicheren Tresors.	HSM-Bediener; Schlüsselverwalter	Hardware gemäß FIPS 140-2 Level 3+; kein Klartext außerhalb der Grenze
Arbeiten jederzeit weiterbearbeiten können. Jede Präsentation und jeder KI-Avatar, den Sie von Grund auf neu erstellen oder hochladen,	Kryptografische Operationen durchführen (verschlüsseln, entschlüsseln, signieren, verifizieren)	Anwendung oder Dienst, der von KMS autorisiert wurde	rollenbasierte Zugriffskontrolle (RBAC); Audit-Protokoll aller Vorgänge
Rotation	Ersetzen Sie den Schlüssel; verteilen Sie ihn; verschlüsseln oder signieren Sie ihn bei Bedarf neu; widerrufen Sie den alten Schlüssel.	Automatisiertes KMS oder Schlüsselverwalter	Richtliniendefinierter Kryptoperioden- oder Ereignisauslöser
Widerruf	Schlüssel bei Kompromittierung, Ausscheiden aus dem Unternehmen oder veraltetem Algorithmus sofort ungültig machen	Schlüsselverwalter oder automatisierter Auslöser	Weitergabe an alle abhängigen Systeme; Prüfprotokoll
Zerstörung	Sicheres Löschen durch FIPS 140-konforme Nullsetzung; Prüfnachweis der Vernichtung	Schlüsselverwalter; KMS	Nullstellung gemäß NIST SP 800-88; Vernichtungsprotokoll

Auslöser für Rotationen: Wann sollte außerhalb des Zeitplans rotiert werden?

Zeitbasierte Rotationspläne bilden die Basis; ereignisbasierte Auslöser dienen als Sicherheitsnetz. Jedes der folgenden Ereignisse sollte unabhängig vom aktuellen Stand des Schlüssels innerhalb seiner geplanten Kryptoperiode eine sofortige Schlüsselrotation auslösen:

• Ausscheiden oder Funktionswechsel des Mitarbeiters: Bei jedem Mitarbeiter, der über Schlüsselmaterial verfügte oder Zugriff darauf hatte, sollten diese Schlüssel ausgetauscht und der Zugriff darauf bei Ausscheiden aus dem Unternehmen oder einem Stellenwechsel unverzüglich widerrufen werden.
• Verdacht auf Kompromittierung oder bestätigte Kompromittierung: Jeglicher Hinweis darauf, dass wichtiges Material offengelegt wurde (z. B. durch Weitergabe an ein Code-Repository, Zugriff durch Unbefugte oder Auffinden in einem Speicherauszug), erfordert die sofortige Aufhebung und Ersetzung.
• Algorithmus veraltet: Wenn ein kryptografischer Algorithmus von NIST als veraltet eingestuft wird (z. B. SHA-1 für Signaturen, RSA-1024, DSA), müssen alle Schlüssel, die diesen Algorithmus verwenden, ersetzt werden.
• Systemstilllegung: Wenn ein System, das einen Schlüssel verwendet hat, außer Betrieb genommen wird, widerrufen Sie den Schlüssel und stellen Sie sicher, dass er in keinem anderen System wiederverwendet wird.
• Beendigung des Zugriffs durch Dritte: Wenn ein Lieferant, Auftragnehmer oder Partner, dessen Systeme den Schlüssel verwendeten, die Geschäftsbeziehung beendet, widerrufen Sie den Zugriff und wechseln Sie den Schlüssel.

Plattformvergleich: KMS vs. HSM vs. Cloud-Schlüsseldienst

Abmessungen	Software KMS	Lokales HSM	Cloud Key Service (KMS)	Cloud HSM (HSMaaS)
Sicherheit der Schlüsselaufbewahrung	Softwaregeschützt; anfällig für Kompromittierung des Betriebssystems	Hardwaregrenze nach FIPS 140-2 Level 3; Schlüssel niemals im Klartext außerhalb	Vom Anbieter verwaltete Software oder gemeinsam genutzte Hardware	FIPS 140-2 Level 3 dedizierte Hardware; kundenexklusive Partition
Zugriff auf den Anbieterschlüssel	Nicht zutreffend (vor Ort)	Nicht zutreffend (vor Ort)	Der Anbieter hat möglicherweise Zugriff auf wichtiges Material	Der Anbieter hat keinen Zugriff auf die Kundenschlüssel.
Compliance	Hängt von Softwaresteuerungen ab	FIPS 140-3-validiert; erfüllt PCI HSM- und staatliche PKI-Anforderungen	Für die meisten kommerziellen Arbeitslasten ausreichend	FIPS 140-3-validiert; erfüllt hohe Sicherheitsanforderungen
Betriebsaufwand	Niedrig (softwareverwaltet)	Hoch (Hardware, Firmware, physikalisch)	Sehr niedrig (vom Anbieter verwaltet)	Mittel (Anbieter verwaltet Hardware; Kunde verwaltet Schlüssel)
Am besten geeignet,	Richtlinien- und Lebenszyklusmanagementebene (Verwendung mit HSM)	CA-Root-Schlüssel, Zahlungs-HSM, klassifizierte Umgebungen	Die meisten Cloud-Workloads verwenden Verschlüsselung ruhender Daten.	Hochsichere Cloud-Schlüsselverwaltung ohne lokale Hardware

Praktischer Implementierungsablauf

1. Inventarisierung aller vorhandenen Schlüssel: Ermitteln Sie alle im Unternehmen verwendeten Schlüssel. Ordnen Sie jeden Schlüssel seinem Besitzer, Algorithmus, seiner Schlüssellänge, seinem Erstellungsdatum, seinem Ablaufdatum (falls festgelegt) sowie den Systemen und Daten zu, die er schützt. Schlüssel ohne Besitzer oder ohne Dokumentation stellen ein unmittelbares Risiko dar.
2. Schlüssel nach Risiko klassifizieren: Segmentieren Sie die Schlüssel nach Sensibilität (CA-Root-Schlüssel, Zahlungsschlüssel, TLS-Privatschlüssel, SSH-Schlüssel, Datenbank-DEKs) und weisen Sie jeder Klasse Schutzanforderungen und Rotationspläne zu.
3. Ein zentralisiertes KMS einsetzen: Implementieren Sie ein Schlüsselverwaltungssystem, das Richtlinien durchsetzt, Lebenszyklusphasen verfolgt und eine Protokollierung aller Schlüsselvorgänge ermöglicht.
4. Schutz hochsensibler Tasten in HSM-Hardware: Migrieren Sie CA-Schlüssel, KEKs, Zahlungsschlüssel und Codesignaturschlüssel zu einem HSM-Speicher gemäß FIPS 140-2 Level 3 oder höher. Siehe HSM als Service für verwaltete HSM-Optionen.
5. Wichtige Zugriffskontrollen definieren und implementieren: Schlüsselverantwortliche benennen; Rollen und Verantwortlichkeiten dokumentieren; rollenbasierte Zugriffskontrolle (RBAC) und Multi-Faktor-Authentifizierung (MFA) für alle Schlüsselverwaltungsvorgänge durchsetzen; Funktionstrennung implementieren.
6. Automatisierung der Rotation und des Zertifikatslebenszyklus: Konfigurieren Sie das KMS so, dass es Kryptoperioden erzwingt und eine automatische Rotation auslöst; integrieren Sie es mit einer automatisierten CLM-Plattform zur Erneuerung von TLS-Zertifikaten, bevor die Gültigkeitsdauer von 47 Tagen in Kraft tritt.
7. Einrichtung von Audit-Protokollierung und -Überwachung: Alle Schlüsselvorgänge (Erzeugung, Zugriff, Verwendung, Rotation, Widerruf, Vernichtung) werden in einem zentralen System protokolliert; bei anomalen Mustern (unerwartete Zugriffszeiten, ungewöhnliches Vorgangsvolumen, Zugriff von nicht autorisierten Systemen) wird eine Warnung ausgegeben.
8. Den Notfallplan dokumentieren und testen: Erstellen Sie die Vorgehensweise zur Reaktion auf einen Sicherheitsvorfall; testen Sie sie mindestens einmal jährlich in einer Planspielübung; bestätigen Sie, dass der Widerruf korrekt an alle abhängigen Systeme weitergegeben wird.

Prüfungsnachweise: Was wichtige Managementprüfungen erfordern

Compliance-Rahmenwerke wie PCI DSS, HIPAA, NIST und ISO/IEC 27001 verpflichten Organisationen, nachzuweisen, dass wichtige Managementkontrollen vorhanden und wirksam sind – und nicht nur zu behaupten. Zu den prüfbaren Nachweisen gehören:

• Wichtiges Inventar: eine aktuelle Aufzeichnung aller relevanten Schlüssel, ihres Algorithmus, ihrer Schlüssellänge, ihres Erstellungsdatums, ihres Ablaufdatums, ihres Besitzers und der Systeme, die sie verwenden.
• Dokumentation der Schlüsselzeremonie: Unterzeichnete Protokolle der Root-CA- und HSM-Masterkey-Generierungszeremonien einschließlich der Anwesenheit der Verantwortlichen, der Validierung der Hardware und der durchgeführten Schritte.
• Nachweise zur Zugangskontrolle: Dokumentation der Rollenzuweisungen, der RBAC-Konfiguration und der Protokolle der Zugriffskontrollprüfungen.
• Rotationsnachweise: Protokolle, die belegen, dass die Schlüssel planmäßig rotiert wurden; Aufzeichnungen über ereignisgesteuerte Rotationen mit Begründung.
• Widerrufsnachweise: Prüfprotokolle über wichtige Widerrufe, den jeweiligen Grund und die Zeitspanne vom Auslösen bis zum Abschluss.
• Testprotokolle für Datensicherung und -wiederherstellung: datierte Aufzeichnungen von HSM-Backup-Wiederherstellungstests, die bestätigen, dass die Backups gültig sind und die Wiederherstellungsverfahren funktionieren.

Fazit

Die Verwaltung von Verschlüsselungsschlüsseln in Unternehmen ist keine einmalige Konfiguration. Sie erfordert kontinuierliche Prozesse, die die Qualität der Schlüsselgenerierung, die zentrale Steuerung, hardwaregestützte Speicherung hochsensibler Schlüssel, Zugriffskontrolle, Schlüsselrotation, -widerruf, Datensicherung, Automatisierung und die Vorbereitung auf Sicherheitsvorfälle umfassen. Die zehn oben genannten Best Practices behandeln die Fehlerursachen, die in der Praxis zu kryptografischen Vorfällen führen. Die meisten dieser Vorfälle sind keine Algorithmusfehler, sondern Fehler in der Schlüsselverwaltung. Weiterführende Informationen finden Sie in unseren Beiträgen zu Public- und Private-Key-Management , HSMs und Schlüsselverwaltung sowie SSH-Schlüsselrotationsrichtlinien.

Häufig gestellte Fragen

Was ist Enterprise-Verschlüsselungsschlüsselmanagement?

Die Gesamtheit der Prozesse, Richtlinien und technischen Kontrollen, die regeln, wie kryptografische Schlüssel innerhalb einer Organisation generiert, verteilt, gespeichert, verwendet, rotiert und gelöscht werden. NIST SP 800-57 legt fest, dass die Sicherheit verschlüsselter Daten direkt vom Schutz der Schlüssel abhängt, mit denen sie verschlüsselt werden.

Wie oft sollten Verschlüsselungsschlüssel rotiert werden?

Die Rotationshäufigkeit sollte risikobasiert sein. Hochsensible Schlüssel (CA-Root, Signaturschlüssel) sollten alle 1–3 Jahre oder bei organisatorischen Ereignissen rotiert werden. Datenverschlüsselungsschlüssel sollten jährlich oder häufiger rotiert werden. TLS-Zertifikate werden voraussichtlich bis 2029 eine Gültigkeitsdauer von 47 Tagen haben. Ereignisbasierte Auslöser (Kompromittierung, Ausscheiden aus dem Unternehmen, veralteter Algorithmus) sollten die Rotationszeiten außer Kraft setzen.

Was ist ein KEK und wozu wird es verwendet?

Ein Schlüsselverschlüsselungsschlüssel (KEK) verschlüsselt andere kryptografische Schlüssel (DEKs) anstatt Daten direkt. Daten werden durch DEKs verschlüsselt; DEKs werden durch KEKs geschützt; KEKs sind in der HSM-Hardware geschützt. Wird ein DEK kompromittiert, sind nur die mit diesem DEK verschlüsselten Daten gefährdet; der KEK und andere DEKs bleiben geschützt. Diese Hierarchie begrenzt das Risiko und ist auch für große Schlüsselanzahlen skalierbar.

Worin besteht der Unterschied zwischen einem KMS und einem HSM?

Ein KMS (Key Management System) ist eine Software, die den Lebenszyklus von Schlüsseln verwaltet: Richtlinien, Zugriffskontrolle, Rotationsplanung und Audit-Protokollierung. Ein HSM (Hardware Storage Management) ist Hardware, die Schlüssel innerhalb einer FIPS-konformen, manipulationssicheren Umgebung speichert und verwendet. Beide ergänzen sich: KMS sorgt für Governance, HSM für hardwarebasierten Schlüsselschutz. Die beste Vorgehensweise ist die Kombination beider Systeme: KMS für das Lebenszyklusmanagement und HSM-Hardware für die Schlüsselspeicherung.

Welche Compliance-Rahmenwerke erfordern ein formelles Schlüsselmanagement?

PCI DSS v4.0 Anforderung 3.7 (geteiltes Wissen, Vier-Augen-Prinzip, Rotation, verschlüsselte Speicherung); HIPAA-Sicherheitsregel: Technische Schutzmaßnahmen für ePHI-Verschlüsselungsschlüssel; NIST SP 800-57 (referenziert von FedRAMP, FISMA, DoD); DSGVO Artikel 32 (geeignete technische Maßnahmen); ISO/IEC 27001:2022 Kontrolle 8.24 (Verwendung von Kryptographie).

Was sollte ein Notfallplan für den Fall einer kritischen Kompromittierung beinhalten?

Sofortige Sperrung des Schlüssels; Generierung und Verteilung eines Ersatzschlüssels; Bewertung der Auswirkungen auf die Daten (welche Daten wurden durch den kompromittierten Schlüssel geschützt?); Benachrichtigung der Beteiligten; und Nachbesprechung des Vorfalls zur Ermittlung der Ursache und Aktualisierung der Kontrollmaßnahmen. Der Plan sollte mindestens jährlich vor einem tatsächlichen Vorfall dokumentiert und getestet werden.