Schlüsselverwaltung – Empfehlungen und Best Practices

Das Schlüsselmanagement umfasst alle Verfahren zur Generierung, Speicherung, Rotation und Außerkraftsetzung kryptografischer Schlüssel und stellt die zentrale Schwachstelle jedes darauf aufbauenden Verschlüsselungssystems dar. Ein kompromittierter oder falsch verwalteter Schlüssel macht die schützende Verschlüsselung vollständig wirkungslos, unabhängig von der Stärke des Algorithmus. Empfohlene Vorgehensweise: Befolgen Sie die aktuellen Richtlinien zu Kryptoperioden und Algorithmen gemäß NIST SP 800-57 Teil 1 Revision 5, verwenden Sie für jeden Zweck einen eigenen Schlüssel und planen Sie bereits jetzt für die bevorstehenden Änderungen in Revision 6.

Veröffentlicht: September 2020. Aktualisiert: August 2026. Geprüft vom Cloud Key Management Team von Encryption Consulting.

Eine grundlegende Definition von Schlüsselmanagement finden Sie in unserem Artikel „ Was ist Schlüsselmanagement? Wie funktioniert Schlüsselmanagement?“ im Education Center . Informationen zur Anwendung dieser Praktiken bei verschiedenen Cloud-Anbietern finden Sie unter „Was ist Multi-Cloud-Schlüsselmanagement?“ und „Was ist ein hybrides Schlüsselmanagementsystem (KMS)?“ . Cloud-spezifische Implementierungen finden Sie unter „AWS KMS vs. Azure Key Vault vs. GCP KMS“ , „ Datenverschlüsselungstools der Google Cloud Platform“ und „Google Cloud Security – Schlüsselmanagementdienste“.

Was ist Schlüsselmanagement und warum ist es wichtig?

Schlüsselmanagement ist der Prozess der Festlegung von Standards für die Erstellung, den Austausch, die Speicherung, die Löschung und die Rotation kryptografischer Schlüssel innerhalb einer Organisation sowie für die Zugriffsberechtigungen. Kryptografische Schlüssel werden für Verschlüsselung , Entschlüsselung und Benutzerauthentifizierung eingesetzt. Ein kompromittierter Schlüssel kann Angreifern ermöglichen, sensible Daten zu entschlüsseln, sich als privilegierter Benutzer zu authentifizieren oder auf andere vertrauliche Ressourcen zuzugreifen. Ein ordnungsgemäßes Schlüsselmanagement minimiert dieses Risiko.

Wie unterscheiden sich symmetrische und asymmetrische Schlüsselsysteme?

Symmetrische Schlüssel schützen im Allgemeinen ruhende Daten, während asymmetrische Schlüsselpaare im Allgemeinen Daten während der Übertragung schützen. Der Grund dafür ist, dass die symmetrische Verschlüsselung schnell genug für den wiederholten Zugriff auf gespeicherte Daten ist, während die asymmetrische Verschlüsselung einen sicheren Austausch zwischen Parteien ohne vorher vereinbartes Geheimnis ermöglicht.

System	Typische Verwendung	Warum
Symmetrische Schlüssel	Ruhende Daten (Datenbanken, Speicher)	Schnell und effizient für wiederholte Verschlüsselungs-/Entschlüsselungsvorgänge durch dieselbe Partei.
Asymmetrische Schlüsselpaare	Datenübertragung (TLS, digitale Signaturen, Schlüsselaustausch)	Ermöglicht es zwei Parteien, sicher zu kommunizieren, ohne vorher ein Geheimnis ausgetauscht zu haben.

Ein typischer Ablauf einer symmetrischen Schlüsselanforderung funktioniert wie folgt:

1. Ein Benutzer kontaktiert das Speichersystem (eine Datenbank oder einen Objektspeicher) und fordert verschlüsselte Daten an.
2. Das Speichersystem fordert den Datenverschlüsselungsschlüssel (DEK) von der Schlüsselmanager-API an, welche die Zertifikate sowohl der Schlüsselmanager-API als auch des Schlüsselmanagers selbst überprüft.
3. Ein sicheres TLS Die Verbindung wird hergestellt, und der Schlüsselmanager verwendet einen Schlüsselverschlüsselungsschlüssel (KEK), um den DEK zu entschlüsseln, der über die Schlüsselmanager-API zurückgegeben wird.
4. Die Daten werden entschlüsselt und dem Benutzer als Klartext zurückgegeben.

Ein typischer asymmetrischer Schlüsselaustausch funktioniert anders, da er auf Schlüsselpaaren anstatt auf einem einzigen gemeinsamen Schlüssel basiert:

1. Absender und Empfänger validieren die Zertifikate des jeweils anderen über einen privaten Server. Zertifizierungsstelle (CA) oder einer externen Validierungsstelle (VA).
2. Der Empfänger sendet seinen öffentlichen Schlüssel an den Absender, der die Daten mit einem einmaligen symmetrischen Schlüssel verschlüsselt, der seinerseits mit dem öffentlichen Schlüssel des Empfängers verschlüsselt ist, und beides an den Empfänger sendet.
3. Der Empfänger entschlüsselt den einmalig generierten symmetrischen Schlüssel mit seinem eigenen privaten Schlüssel und verwendet diesen dann zur Entschlüsselung der Daten.

Was empfiehlt das NIST aktuell für das Schlüsselmanagement?

NIST SP 800-57 Teil 1 Revision 5, veröffentlicht im Jahr 2020, ist der aktuelle, offizielle Standard für Schlüsselmanagement. Er wurde zum Schutz sensibler, aber nicht klassifizierter Informationen der US-Bundesregierung entwickelt und gilt auch für Nichtregierungsorganisationen als Best-Practice-Grundlage. Ein nachfolgender Entwurf der Revision 6 wurde zur öffentlichen Kommentierung freigegeben; die Kommentierungsfrist endete am 5. Februar 2026. Da Revision 6 zum jetzigen Zeitpunkt noch nicht finalisiert ist, bleibt Revision 5 der maßgebliche Standard. Organisationen, die heute ein Schlüsselmanagementprogramm aufbauen, sollten die Projektseite der NIST-Richtlinien für Schlüsselmanagement im Auge behalten , um über die Finalisierung von Revision 6 informiert zu bleiben, anstatt Empfehlungen aus Entwürfen als endgültige Leitlinien zu übernehmen.

Welche kryptografischen Algorithmen werden vom NIST anerkannt?

Die NIST-Standards genehmigen eine spezifische, begrenzte Anzahl von Algorithmen anstatt jeder in Gebrauch befindlichen symmetrischen oder asymmetrischen Option.

• Blockchiffrenbasierte symmetrische Algorithmen wie beispielsweise AES, das eine Reihe von Bits (Blöcken) durch Operationen wie XOR über mehrere Runden iteriert, um einen Chiffretext zu erzeugen.
• Hashfunktionsbasierte Algorithmen wie beispielsweise SHA-256, die Einwegfunktionen verwenden, um Hash-Daten zu generieren (SHA-1 ist für die meisten Sicherheitsanwendungen veraltet und sollte nicht für neue Systeme ausgewählt werden).
• Asymmetrische Algorithmen Im Allgemeinen gilt die Voraussetzung, dass der private Schlüssel ausschließlich unter der Kontrolle derjenigen Entität bleibt, der das Schlüsselpaar gehört.
• Zufallsbitgeneratoren (RBGs), Sie werden zur Generierung von Schlüsselmaterial und für kryptografische Hashfunktionen verwendet, die selbst keine kryptografischen Schlüssel verwenden. Vollständige Listen der zugelassenen Algorithmen finden sich in FIPS 180 (Hashfunktionen) und SP 800-90 (RBGs).

Wie sollten Kryptoperioden festgelegt werden?

Die Gültigkeitsdauer eines Schlüssels ist der Zeitraum, in dem er für seinen vorgesehenen Zweck verwendet werden darf, bevor er erneuert oder, besser noch, durch einen neuen Schlüssel ersetzt werden muss. Die zentrale Empfehlung des NIST lautet, für jeden Verwendungszweck einen eindeutigen Schlüssel zu erstellen; ein zur Authentifizierung verwendeter Schlüssel sollte niemals auch zur Entschlüsselung verwendet werden. Bei asymmetrischen Schlüsselpaaren hat jeder Schlüssel seine eigene Gültigkeitsdauer: Die Gültigkeitsdauer für den Urheber bestimmt den Schlüssel, der zur Erstellung einer digitalen Signatur verwendet wird, und die Gültigkeitsdauer für den Empfänger bestimmt den zugehörigen Verifizierungsschlüssel. Das NIST empfiehlt, dass beide Gültigkeitsdauern gleichzeitig beginnen, die Gültigkeitsdauer für den Empfänger jedoch über die Gültigkeitsdauer für den Urheber hinausgehen kann, niemals umgekehrt, da eine Signatur auch nach Ablauf der Gültigkeitsdauer des Signaturschlüssels verifizierbar bleiben muss.

Wie verändert sich das Schlüsselmanagement in Multi-Cloud- und Hybridumgebungen?

Die NIST-Richtlinien sind bewusst herstellerneutral, doch Multi-Cloud- und Hybrid-Bereitstellungen werfen praktische Fragen auf, die das NIST nicht direkt beantwortet: Welches native KMS der Cloud hält den maßgeblichen Schlüssel? Wie werden Schlüsselhierarchien zwischen Anbietern abgebildet, die keine gemeinsame Vertrauensbasis nutzen? Und wie bleiben Zugriffsrichtlinien konsistent, wenn dieselben Daten zwischen verschiedenen Umgebungen verschoben werden? In den Artikeln „ Was ist Multi-Cloud-Schlüsselmanagement?“ und „Was ist ein hybrides Schlüsselmanagementsystem (KMS)?“ erfahren Sie, wie diese Fragen in der Praxis beantwortet werden. Unser Vergleich von AWS KMS, Azure Key Vault und GCP KMS zeigt Ihnen, wie sich die drei großen Cloud-Anbieter insbesondere hinsichtlich Rotation, IAM und Kosten unterscheiden.

Welche Grenzen hat die alleinige Befolgung der NIST-Richtlinien?

• NIST SP 800-57 legt Empfehlungen für Kryptoperioden und Algorithmen fest, schreibt aber keine spezifischen IAM-, Protokollierungs- oder Kostenkompromisse für eine bestimmte Cloud-KMS-Implementierung vor.
• Revision 6 befindet sich noch im Entwurfsstadium; Organisationen, die Empfehlungen aus dem Entwurfsstadium als endgültig übernehmen, riskieren, ihr Schlüsselmanagementprogramm nach Veröffentlichung von Revision 6 erneut überarbeiten zu müssen.
• Die NIST-Richtlinien behandeln weder die Multi-Cloud-Schlüsselhierarchie noch die anbieterübergreifende Konsistenz der Zugriffsrichtlinien; diese müssen separat konzipiert werden.
• Die Einhaltung der NIST-Standards befasst sich mit der Auswahl von Algorithmen und Kryptoperioden; sie umfasst jedoch nicht von sich aus operative Verfahren wie die Rotationsautomatisierung oder die Reaktion auf Vorfälle im Zusammenhang mit einem kompromittierten Schlüssel.

Entscheidungscheckliste: Anwendung der NIST-Empfehlungen zum Schlüsselmanagement

1. Jeder Schlüssel ist nur einem Zweck zugeordnet; ein Schlüssel darf niemals sowohl für die Authentifizierung als auch für die Entschlüsselung wiederverwendet werden.
2. Wählen Sie für jedes neue System ausschließlich NIST-zugelassene Algorithmen (AES für symmetrische Verschlüsselung, SHA-256 oder stärkere Verschlüsselung für Hash-Funktionen).
3. Legen Sie für jeden Schlüssel eine dokumentierte Kryptoperiode fest, mit separaten Nutzungsperioden für Absender und Empfänger bei asymmetrischen Schlüsselpaaren.
4. Revision 5 sollte als aktueller Standard gelten, und es sollte jemand damit beauftragt werden, die Fertigstellung von Revision 6 zu überwachen, anstatt sie zu ignorieren.
5. Erweitern Sie die NIST-Baseline um cloudspezifische IAM-, Protokollierungs- und Rotationsverfahren für jede Multi-Cloud- oder Hybridbereitstellung.

Was würde Encryption Consulting empfehlen?

Die meisten von uns analysierten Organisationen verfügen zwar über eine formale Schlüsselmanagementrichtlinie, diese entspricht jedoch nicht der tatsächlichen Implementierung. Häufig liegt dies daran, dass sie sich noch auf eine veraltete NIST-Revision bezieht oder nie für eine Multi-Cloud-Umgebung aktualisiert wurde. Die Cloud-Key-Management-Services von Encryption Consulting vergleichen Ihre aktuellen Schlüsselmanagementpraktiken mit NIST SP 800-57 Part 1 Revision 5, entwerfen Kryptoperioden und Zugriffstrennung für Ihre spezifische Umgebung und unser HSM-as-a-Service- Angebot ermöglicht Ihnen die hardwaregestützte Schlüsselverwaltung, ohne dass Sie HSMs direkt betreiben müssen.

Häufig gestellte Fragen

Ist NIST SP 800-57 Teil 1 Revision 6 jetzt der aktuelle Standard?

Nein. Revision 6 ist noch ein erster öffentlicher Entwurf; die Kommentierungsfrist endete am 5. Februar 2026, die Revision ist aber noch nicht finalisiert. Revision 5, veröffentlicht im Jahr 2020, bleibt der aktuelle offizielle Standard.

Was ist eine Kryptoperiode?

Die Kryptoperiode ist die Zeitspanne, in der ein bestimmter Schlüssel für seinen vorgesehenen Zweck verwendet werden darf, bevor er erneuert oder, vorzugsweise, durch einen neuen Schlüssel ersetzt werden sollte.

Sollte jemals derselbe Schlüssel sowohl für die Authentifizierung als auch für die Entschlüsselung verwendet werden?

Nein. NIST empfiehlt einen eindeutigen Schlüssel für jeden einzelnen Zweck; die Verwendung eines Schlüssels für mehrere Zwecke erhöht die Auswirkungen, falls dieser einzelne Schlüssel kompromittiert wird.

Warum haben asymmetrische Schlüsselpaare zwei unterschiedliche Kryptoperioden?

Die Nutzungsperiode des Urhebers umfasst den Signaturschlüssel, während die Nutzungsperiode des Empfängers die Verifizierungsseite umfasst; die Nutzungsperiode des Empfängers kann über die Nutzungsperiode des Urhebers hinausgehen, sodass eine Signatur auch dann noch verifiziert werden kann, wenn der Signaturschlüssel selbst nicht mehr gültig ist.

Beinhaltet der NIST-Leitfaden speziell die Schlüsselverwaltung in Multi-Cloud-Umgebungen?

Nicht direkt. NIST SP 800-57 legt herstellerneutrale Algorithmen und Kryptoperioden fest; die spezifischen Fragen der Cloud-übergreifenden Schlüsselhierarchie und der Konsistenz der Zugriffsrichtlinien müssen durch ein hybrides und Multi-Cloud-Schlüsselmanagement-Design auf Basis dieser Grundlage gelöst werden.

Benötigen Sie Unterstützung bei der Bewertung Ihres Schlüsselverwaltungsprogramms anhand der aktuellen NIST-Richtlinien? Sprechen Sie mit dem Cloud Key Management Team von Encryption Consulting.

Referenzen

Projektseite der NIST-Richtlinien für das Schlüsselmanagement – ​​csrc.nist.gov

NIST SP 800-57 Teil 1 Revision 5 (endgültige Veröffentlichung) – csrc.nist.gov