Kryptografisches Schlüsselmanagement für ISO 27001, NIS2 und DORA

Um 08:17 Uhr an einem Montagmorgen erhält der CISO eines europäischen SaaS-Unternehmens eine Nachricht der Entwicklungsleitung: „Wir haben am Wochenende den Datenbank-Verschlüsselungsschlüssel rotiert, aber eine Integration konnte Datensätze danach nicht mehr entschlüsseln. Wir haben mit einem alten Schlüssel aus dem Vault zurückgerollt.“

Zehn Minuten später fragt der Datenschutzbeauftragte, ob die betroffenen Datensätze personenbezogene Daten aus der EU enthalten. Die Finanzabteilung fragt, ob daraus ein meldepflichtiger Betriebsstörfall für einen regulierten Kunden werden könnte. Der Einkauf fragt, ob der Cloud-Anbieter oder das Unternehmen Eigentümer des kundenseitig verwalteten Schlüssels ist. Der CEO stellt die einzige Frage, die im Leitungsorgan zählt: „Können wir belegen, dass wir das ordnungsgemäß gesteuert haben?“

Das ist der Moment, in dem „wir nutzen Verschlüsselung“ keine beruhigende Aussage mehr ist, sondern zu einem Nachweisproblem wird.

Im Jahr 2026 liegt kryptografisches Schlüsselmanagement an der Schnittstelle von ISO/IEC 27001:2022-Maßnahmen, NIS2-Cyberhygiene, DORA-IKT-Risikomanagement, Nachweisen zur Sicherheit der Verarbeitung nach GDPR Article 32, geteilter Verantwortung in der Cloud und Planung für postquantenfähige Krypto-Agilität. Die eigentliche Frage ist nicht, ob Verschlüsselung vorhanden ist. Die eigentliche Frage ist, ob die Organisation anhand von Aufzeichnungen zeigen kann, dass Schlüssel sicher erzeugt, Verantwortlichen zugewiesen, in genehmigten KMS- oder HSM-Umgebungen gespeichert, planmäßig rotiert, sicher wiederhergestellt, bei Kompromittierung widerrufen und dem Geschäftsrisiko zugeordnet werden.

Clarysec sieht in Vorbereitungsprojekten immer wieder dasselbe Muster. Verschlüsselung wird systemweise umgesetzt, aber die Schlüssel-Governance ist fragmentiert. Zertifikate werden in Tabellen geführt. Cloud-KMS-Berechtigungen stammen aus alten Projekten. Entwickler wissen, welche Geheimnisse kritisch sind, aber das ISMS weiß es nicht. Auditoren erhalten Screenshots statt Nachweise über den Lebenszyklus. NIS2- und DORA-Teams sprechen über Resilienz, Datenschutzteams über Verschlüsselung und Pseudonymisierung nach GDPR, und niemand verantwortet die kryptografische Kontrollebene durchgängig.

Eine reife Antwort besteht nicht in mehr isolierter Kryptografie. Sie besteht in gesteuertem kryptografischem Schlüsselmanagement, das mit Risikobehandlung, Cloud-Architektur, Lieferantenaufsicht, Zugriffskontrolle, Protokollierung, Incident Response und regulatorischen Nachweisen verbunden ist.

Warum Schlüsselmanagement heute ein Governance-Thema ist

NIS2 macht Kryptografie- und Verschlüsselungsrichtlinien zu einem Bestandteil der Mindestmaßnahmen des Cybersicherheitsrisikomanagements für wesentliche und wichtige Einrichtungen. Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Umgang mit Informationssicherheitsvorfällen, Kontinuität, Sicherheit der Lieferkette, sicherer Entwicklung, Cyberhygiene, Zugriffskontrolle, Asset-Management sowie Kryptografie- und Verschlüsselungsrichtlinien. Außerdem müssen Leitungsorgane Maßnahmen des Cybersicherheitsrisikomanagements genehmigen und überwachen.

Für SaaS-, Cloud-, Managed-Service- und Cybersicherheitsanbieter kann der Anwendungsbereich breiter sein, als viele Teams annehmen. NIS2 erfasst Sektoren wie digitale Infrastruktur, Cloud-Computing-Dienste, Rechenzentrumsanbieter, DNS-Anbieter, Vertrauensdiensteanbieter, Managed Service Provider, Managed Security Service Provider, Online-Marktplätze, Suchmaschinen und Plattformen sozialer Netzwerke, sofern Größen- oder Kritikalitätsschwellen erreicht sind.

DORA hebt die Anforderungen für Finanzunternehmen an. Ab dem 17. Januar 2025 verlangt DORA ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken, Rechenschaftspflicht des Leitungsorgans, IKT-Geschäftskontinuitäts- sowie Reaktions- und Wiederherstellungspläne, Tests der digitalen operationalen Resilienz, IKT-Drittparteienrisikomanagement und Vorfallmeldung. Für Finanzunternehmen, die nach nationalen NIS2-Regeln erfasst sind, gilt DORA als sektorspezifischer Rechtsakt der Union für gleichwertige NIS2-Verpflichtungen. Ein Fintech sollte keine getrennte Krypto-Governance für NIS2, DORA und ISO betreiben. Es benötigt ein belastbares einheitliches Kontrollmodell.

GDPR ergänzt die Datenschutz-Nachweisdimension. GDPR Article 32 ist der Bereich, in dem Verschlüsselung häufig als Sicherheitsmaßnahme für die Verarbeitung bewertet wird; „die Daten sind verschlüsselt“ ist jedoch keine vollständige Antwort. Aufsichtsbehörden und Auditoren fragen, wer die Schlüssel kontrolliert, wie der Zugriff eingeschränkt wird, wie Kompromittierungen erkannt werden, wie Wiederherstellung funktioniert und ob das Design zum Risiko für betroffene Personen passt.

ISO/IEC 27001:2022 stellt Organisationen das Managementsystem bereit, um diese Verpflichtungen miteinander zu verbinden. Die Abschnitte 4.1 bis 4.4 verlangen Kontext, Anforderungen interessierter Parteien, ISMS-Geltungsbereich und interagierende Prozesse. Die Abschnitte 5.1 bis 5.3 verlangen Führung, Leitlinien, Ressourcen und zugewiesene Verantwortlichkeiten. Die Abschnitte 6.1.1 bis 6.1.3 verlangen Risikobeurteilung, Risikobehandlung, Maßnahmenselektion, eine Erklärung zur Anwendbarkeit und Genehmigung durch Risikoverantwortliche. Die Abschnitte 8.1 bis 8.3 verlangen kontrollierten Betrieb, Neubewertung von Risiken bei Änderungen, Umsetzung von Behandlungsplänen und Aufbewahrung dokumentierter Ergebnisse.

Für kryptografisches Schlüsselmanagement muss das ISMS fünf Fragen beantworten:

1. Welche Informationswerte, Datenflüsse und Services benötigen kryptografischen Schutz?
2. Welche Schlüssel, Zertifikate, Geheimnisse und Kryptodienste schützen sie?
3. Wer besitzt, administriert, genehmigt und überwacht diese kryptografischen Werte?
4. Wie werden Erzeugung, Speicherung, Nutzung, Rotation, Escrow, Wiederherstellung, Widerruf und Vernichtung kontrolliert?
5. Welche Nachweise belegen, dass die Kontrollen wie vorgesehen wirksam waren?

Die ISO 27001-Kontrollachse für kryptografisches Schlüsselmanagement

Clarysec behandelt kryptografisches Schlüsselmanagement als Kontrollkette, nicht als Einzelmaßnahme. In Zenith Controls: Der Leitfaden zur Cross-Compliance Zenith Controls wird das Thema primär ISO/IEC 27002:2022 Maßnahme 8.24, Einsatz von Kryptografie, zugeordnet, mit wichtigen unterstützenden Beziehungen zu 5.17, Authentifizierungsinformationen, und 5.23, Informationssicherheit für die Nutzung von Cloud-Diensten.

Diese Beziehung ist wichtig. Ein Fehler im Schlüsselmanagement ist selten nur „schlechte Verschlüsselung“. Häufig handelt es sich um ein Authentifizierungsproblem, ein Cloud-Governance-Problem, ein Lieferantenproblem, eine Protokollierungslücke oder ein Versagen im Änderungsmanagement.

Der Zenith Blueprint: 30-Schritte-Roadmap für Auditoren Zenith Blueprint operationalisiert dies in der Phase Risikomanagement, Schritt 14, Richtlinien zur Risikobehandlung und regulatorische Querverweise. Das Muster für die Kryptografierichtlinie sieht vor, dass die Organisation festlegt, wo Kryptografie erforderlich ist, Algorithmen und Protokolle genehmigt, das Schlüsselmanagement definiert, Anwendungsfälle wie Festplattenvollverschlüsselung und sichere Kommunikation abdeckt und die Richtlinie mit GDPR Article 32 verbindet.

„Verschlüsselungsschlüssel müssen sicher gespeichert werden (z. B. in einem Key Vault/HSM), und der Zugriff ist auf autorisiertes Personal zu beschränken.“
Zuordnung: Zenith Blueprint, Phase Risikomanagement, Schritt 14, Richtlinien zur Risikobehandlung und regulatorische Querverweise Zenith Blueprint

In der Phase Umsetzung der Kontrollen, Schritt 20, geht der Zenith Blueprint weiter in die Tiefe. Kryptografie bedeutet nicht, „Verschlüsselung einzuschalten“. Es geht darum, Kryptografie in Design, Richtlinie und Lebenszyklusmanagement einzubetten. Dazu gehören ruhende Daten, Daten während der Übertragung, Authentifizierung von Identitäten und Transaktionen, genehmigte Algorithmen, Key Vaults, HSMs, planmäßige Rotation, Widerruf und Validierung durch Penetrationstests und Code-Reviews.

Was Auditoren erwarten, wenn sie Nachweise zu Schlüsseln anfordern

Die meisten Audit-Feststellungen beginnen mit einer einfachen Anforderung: „Zeigen Sie mir Ihre Verschlüsselungsrichtlinie und Ihre Aufzeichnungen zum Schlüsselmanagement.“

Schwache Antworten sind zum Beispiel:

• „Der Cloud-Anbieter verschlüsselt standardmäßig alles.“
• „Wir nutzen TLS.“
• „Geheimnisse liegen im Vault.“
• „Das Engineering-Team kümmert sich um die Rotation.“
• „Der Schlüssel wird von der Anwendung verwaltet.“

Diese Aussagen können technisch zutreffen, sind aber keine vollständigen Nachweise. Ein ISO-Auditor wird Schlüsselmanagement auf Risikobeurteilung, Erklärung zur Anwendbarkeit, Richtlinienanforderungen, operative Steuerung und aufbewahrte dokumentierte Informationen zurückführen. Ein NIST CSF-Assessor wird fragen, ob kryptografische Werte identifiziert, geschützt, überwacht und wiederhergestellt werden. Ein DORA-Auditor wird nach vom Leitungsorgan genehmigter IKT-Risiko-Governance, Abhängigkeiten von Drittparteien, Vorfallmanagement und Resilienztests suchen. Ein GDPR-Prüfer wird fragen, ob Verschlüsselung und Schlüsseltrennung das Risiko für betroffene Personen reduzieren und ob der Verantwortliche Rechenschaftspflicht nachweisen kann.

Clarysecs Enterprise-Richtlinie zu kryptografischen Kontrollen Richtlinie zu kryptografischen Kontrollen adressiert die Nachweislücke direkt:

„Ein zentrales Schlüsselmanagement-Register muss geführt werden, um alle kryptografischen Schlüssel, ihren Lebenszyklusstatus, zugewiesene Verwahrer und Nutzungskontexte zu erfassen.“
Zuordnung: Unternehmensrichtlinie, Richtlinie zu kryptografischen Kontrollen, Governance-Anforderungen, Abschnitt 5.2 Richtlinie zu kryptografischen Kontrollen

Dieser Satz verändert das Auditgespräch. Statt implizites Erfahrungswissen zu suchen, kann die Organisation ein Register vorlegen, das Schlüssel mit Informationswerten, Verantwortlichen, Datenklassifizierungen, Systemen, Cloud-Konten, Rotationsdaten, Nutzungskontexten und Nachweisen verknüpft.

Für KMU skaliert Clarysecs Richtlinie zu kryptografischen Kontrollen für KMU Richtlinie zu kryptografischen Kontrollen für KMU dieselbe Erwartung:

„Der IT-Support-Dienstleister muss ein aktuelles Inventar der verwendeten kryptografischen Werkzeuge und Zertifikate führen.“
Zuordnung: KMU-Richtlinie, Richtlinie zu kryptografischen Kontrollen für KMU, Governance-Anforderungen, Abschnitt 5.1.2 Richtlinie zu kryptografischen Kontrollen für KMU

Ein reguliertes Finanzinstitut benötigt möglicherweise HSM-Zeremonien, Split Knowledge, Dual-Control-Mechanismen, formelle Verwahrerbenennungen und vierteljährliche Berechtigungsüberprüfungen. Ein kleiner SaaS-Anbieter kann mit einem gepflegten Inventar, genehmigten Algorithmen, dokumentierter KMS-Eigentümerschaft und Rotationsnachweisen beginnen. Beide benötigen eine Governance, die dem Risiko angemessen ist.

Der Schlüssellebenszyklus, den Ihr ISMS kontrollieren sollte

Ein praktikables Programm für Schlüsselmanagement folgt dem Lebenszyklus. Jede Phase benötigt einen Verantwortlichen, ein genehmigtes Verfahren, eine technische Kontrolle, eine Änderungsaufzeichnung und Auditnachweise.

Die Unternehmens-Richtlinie zu kryptografischen Kontrollen stärkt die sichere Erzeugung:

„Schlüsselerzeugung: Erfolgt unter Verwendung sicherer Hardware- oder Softwaremodule (z. B. HSMs, FIPS 140-2-validierte Systeme).“
Zuordnung: Unternehmensrichtlinie, Richtlinie zu kryptografischen Kontrollen, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.3.1 Richtlinie zu kryptografischen Kontrollen

Sie spezifiziert außerdem die Rotation:

„Schlüsselrotation: Erforderlich in definierten Intervallen oder unverzüglich bei Kompromittierung oder Rollenänderung.“
Zuordnung: Unternehmensrichtlinie, Richtlinie zu kryptografischen Kontrollen, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.3.4 Richtlinie zu kryptografischen Kontrollen

Für KMU erscheint derselbe Grundsatz in einfacherer betrieblicher Sprache:

„Die Schlüsselrotation muss gemäß Ablaufplänen oder bei vermuteter Kompromittierung erfolgen.“
Zuordnung: KMU-Richtlinie, Richtlinie zu kryptografischen Kontrollen für KMU, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.3.4 Richtlinie zu kryptografischen Kontrollen für KMU

Diese Klauseln sind für NIS2 und DORA relevant, weil veraltete oder schlecht gesteuerte Schlüssel nicht nur Vertraulichkeitsschwächen sind. Sie können Incident-Response-Blocker, Probleme aus Lieferantenabhängigkeiten, Ausfälle der Disaster Recovery und Benachrichtigungsprobleme gegenüber Kunden verursachen.

Cloud-KMS, HSM und BYOK: die Falle der geteilten Verantwortung

Cloud-Verschlüsselung ist eine der häufigsten Quellen trügerischer Sicherheit. Ein Cloud-Anbieter kann Speicher standardmäßig verschlüsseln, aber das bedeutet nicht automatisch, dass Ihre Organisation den Schlüssel gesteuert hat.

Der Zenith Blueprint, Phase Umsetzung der Kontrollen, Schritt 23, erläutert ISO/IEC 27002:2022 Maßnahme 5.23 mit Fokus auf Cloud-Governance, Transparenz und geteilte Verantwortung. Er betont, dass der Anbieter die Infrastruktur absichern kann, der Kunde jedoch weiterhin für Daten, Konfigurationen, Zugriffsrichtlinien und Vorfallsbereitschaft verantwortlich bleibt.

„Cloud-Anbieter sichern die Infrastruktur, aber Sie bleiben weiterhin verantwortlich für Ihre Daten, Ihre Konfigurationen, Ihre Zugriffsrichtlinien und Ihre Vorfallsbereitschaft.“
Zuordnung: Zenith Blueprint, Phase Umsetzung der Kontrollen, Schritt 23, organisatorische Maßnahmen 5.19–5.37 Zenith Blueprint

An dieser Stelle wird Verantwortung für Cloud-Schlüssel zu einem Risiko auf Ebene des Leitungsorgans. Ein SaaS-Unternehmen kann anbieterseitig verwaltete Verschlüsselung für risikoarme Protokolldaten, kundenseitig verwaltete Schlüssel für Kundendatenbanken, BYOK für regulierte Mandanten und HSM-gestützte Root-Schlüssel für Signaturen oder Tokenisierung nutzen. Jede Wahl hat Auswirkungen auf die Compliance.

Clarysecs Unternehmens-Richtlinie zur Nutzung von Cloud-Diensten Richtlinie zur Nutzung von Cloud-Diensten gibt eine klare Kontrollrichtung vor:

„Kundenseitig verwaltete Schlüssel (CMKs) oder Bring Your Own Key (BYOK) sind zu verwenden, sofern dies vom Cloud-Anbieter unterstützt wird.“
Zuordnung: Unternehmensrichtlinie, Richtlinie zur Nutzung von Cloud-Diensten, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.4.2 Richtlinie zur Nutzung von Cloud-Diensten

Das bedeutet nicht, dass jeder Cloud-Dienst BYOK nutzen muss. Es bedeutet, dass die Organisation bewusst entscheiden muss – auf Grundlage von Risiko, Kundenzusagen, vertraglichen Anforderungen und Wiederherstellbarkeit.

DORA Article 28 und Article 30 machen dies für Finanzunternehmen besonders relevant. Sie verlangen IKT-Drittparteienrisikomanagement, Register der vertraglichen IKT-Vereinbarungen, Due Diligence, Audit- und Inspektionsrechte, Unterstützung bei Vorfällen, Datenschutz und Zugriff sowie Wiederherstellungs- und Rückgaberegelungen. Wenn ein Cloud-Anbieter oder SaaS-Lieferant Verschlüsselungsschlüssel für eine kritische oder wichtige Funktion verwaltet, muss diese Beziehung im IKT-Drittparteienregister und in den vertraglichen Kontrollen sichtbar sein.

NIS2 verlangt außerdem Sicherheit der Lieferkette, einschließlich lieferantenspezifischer Schwachstellen, Cybersicherheitspraktiken und sicherer Entwicklungsverfahren. Wenn ein kritischer Lieferant Ihre Schlüssel hält, Ihr KMS betreibt, Ihr HSM bereitstellt, Ihren Zertifikatslebenszyklus verwaltet oder verschlüsselte Backups hostet, ist der Lieferant Teil Ihres kryptografischen Kontrollumfelds.

Algorithmusfreigabe und Krypto-Agilität 2026

Eine Richtlinie zum Schlüsselmanagement im Jahr 2026 sollte nicht nur „AES-256“ und „TLS 1.2 oder höher“ aufführen. Sie sollte einen Freigabe- und Überprüfungsprozess etablieren, der Krypto-Agilität unterstützt. Krypto-Agilität bedeutet, dass die Organisation identifizieren kann, wo Algorithmen, Protokolle, Zertifikate und Schlüssellängen verwendet werden, die Exposition gegenüber Schwächen oder Abkündigungen bewerten und ohne Panik migrieren kann.

Clarysecs KMU-Richtlinie legt fest:

„Es dürfen nur vom IT-Support-Dienstleister genehmigte Algorithmen und Protokolle nach Best Practices der Branche verwendet werden (z. B. AES-256, RSA 2048, TLS 1.2 oder höher).“
Zuordnung: KMU-Richtlinie, Richtlinie zu kryptografischen Kontrollen für KMU, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.2.1 Richtlinie zu kryptografischen Kontrollen für KMU

Sie verlangt außerdem Dokumentation:

„Alle Verschlüsselungsverfahren (z. B. AES-256, TLS 1.2+) und Schlüsselmanagementprozesse müssen dokumentiert werden.“
Zuordnung: KMU-Richtlinie, Richtlinie zu kryptografischen Kontrollen für KMU, Governance-Anforderungen, Abschnitt 5.3.1 Richtlinie zu kryptografischen Kontrollen für KMU

Die auditfähige Variante ist ein genehmigter kryptografischer Standard mit:

• Zulässigen Algorithmen und Protokollen für ruhende Daten, Daten während der Übertragung, Signaturen, Passwort-Hashing, Tokenisierung und Backups.
• Nicht zulässigen Algorithmen, Protokollen und Bibliotheken.
• Mindestschlüssellängen und Gültigkeitsdauern von Zertifikaten.
• Genehmigten KMS-, HSM-, Zertifizierungsstellen- und Geheimnismanagement-Plattformen.
• Anforderungen an sichere Zufallszahlengenerierung.
• Entwicklerleitlinien für kryptografische Bibliotheken.
• Ausnahmeprozess für Altsysteme.
• Prüfauslöser für Schwachstellen, regulatorische Änderungen, Lieferantenänderungen und Planung der Post-Quantum-Umstellung.

Post-Quantum-Planung verlangt nicht, dass jede Organisation sofort sämtliche Kryptografie ersetzt. Sie verlangt jedoch ein Inventar. Ohne kryptografisches Inventar können Sie nicht wissen, welche Systeme langlebige Public-Key-Verschlüsselung verwenden, welche Zertifikate kritische Services schützen, wo Signaturschlüssel liegen oder welche Anbieter Migration unterstützen müssen. Das Schlüsselmanagement-Register ist keine Bürokratie. Es ist die Grundlage der Krypto-Agilität.

Ein 90-minütiger Nachweis-Sprint für Schlüsselmanagement

Clarysec nutzt häufig einen kurzen Nachweis-Sprint mit Führung, Sicherheit, Cloud- und Compliance-Teams. Ziel ist es, verteiltes Schlüsselwissen schnell in Auditnachweise zu überführen.

Schritt 1: Einen kritischen Service auswählen

Wählen Sie ein System, das für NIS2, DORA oder GDPR relevant ist. Beispiele sind Kundenidentität, Zahlungsabwicklung, Transaktionsüberwachung, Produktivdatenbank mit Kundendaten, verschlüsselte Backup-Plattform oder kundenbezogene API.

Schritt 2: Das Schlüsselmanagement-Register öffnen

Nutzen Sie die Anforderung der Richtlinie zu kryptografischen Kontrollen an ein zentrales Register als Struktur. Wenn noch keines vorhanden ist, erstellen Sie ein einfaches Register mit diesen Feldern:

Schritt 3: Zugriff und Dual Control nachvollziehen

Für kryptografische Vorgänge mit hoher Auswirkung sind Dual-Control-Mechanismen und das Prinzip der minimalen Berechtigung anzuwenden. Die Unternehmens-Richtlinie zu kryptografischen Kontrollen legt fest:

„Dual-Control-Mechanismen und das Prinzip der minimalen Berechtigung müssen auf sensitive kryptografische Vorgänge angewendet werden (z. B. Root-Key-Importe, HSM-Administration).“
Zuordnung: Unternehmensrichtlinie, Richtlinie zu kryptografischen Kontrollen, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.6.2 Richtlinie zu kryptografischen Kontrollen

Fragen Sie:

• Wer kann den Schlüssel deaktivieren oder löschen?
• Wer kann die Schlüsselrichtlinie ändern?
• Wer kann Daten direkt entschlüsseln?
• Werden Break-Glass-Rollen überwacht und zeitlich begrenzt?
• Wird MFA für privilegierte Schlüsselvorgänge durchgesetzt?
• Werden privilegierte Aktionen protokolliert und überprüft?

Schritt 4: Fünf Nachweisaufzeichnungen abrufen

Sammeln Sie fünf Aufzeichnungen, die belegen, dass die Kontrolle funktioniert:

1. Protokoll zur Schlüsselerzeugung oder zum Schlüsselimport.
2. Aktuelle Zugriffsrichtlinie für KMS oder HSM.
3. Letztes Änderungsticket zur Schlüsselrotation.
4. SIEM-Abfrage, die Schlüsselnutzung oder administrative Aktionen zeigt.
5. Nachweis eines Wiederherstellungs- oder Restore-Tests.

Schritt 5: Risiko und Regulierung zuordnen

Ergänzen Sie eine kurze Risikoaussage: „Unbefugte Nutzung oder Verlust dieses Schlüssels könnte personenbezogene Daten aus der EU offenlegen, den Kundenservice stören und die Wiederherstellung kritischer Systeme beeinträchtigen.“ Ordnen Sie dies anschließend den relevanten Verpflichtungen zu.

In 90 Minuten kann das Team in der Regel erkennen, ob Schlüssel-Governance tatsächlich besteht oder nur angenommen wird.

Vorfallmeldung: Wenn Schlüsselkompromittierung die Uhr startet

Eine vermutete Schlüsselkompromittierung ist nicht automatisch ein meldepflichtiger Verstoß, kann aber die regulatorische Uhr starten.

Nach NIS2 müssen wesentliche und wichtige Einrichtungen erhebliche Vorfälle, die die Leistungserbringung beeinträchtigen, unverzüglich melden. Das gestufte Modell umfasst eine Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung, eine Vorfallmeldung innerhalb von 72 Stunden, Statusaktualisierungen auf Anforderung und einen Abschlussbericht spätestens einen Monat nach der Vorfallmeldung.

Nach DORA müssen Finanzunternehmen IKT-bezogene Vorfälle erkennen, steuern und melden, Vorfälle und erhebliche Cyberbedrohungen aufzeichnen, Vorfälle nach Schweregrad und Kritikalität betroffener Services klassifizieren, mit Interessenträgern kommunizieren, schwerwiegende Vorfälle an Senior Management und zuständige Behörden melden, Ursachenanalysen durchführen und Abhilfe schaffen. Die Auslagerung der Berichterstattung kann möglich sein, die Verantwortung verbleibt jedoch beim Finanzunternehmen.

Nach GDPR stellt sich die Frage, ob eine Verletzung des Schutzes personenbezogener Daten eingetreten ist, also unbeabsichtigte oder unrechtmäßige Vernichtung, Verlust, Veränderung, unbefugte Offenlegung von oder unbefugter Zugang zu personenbezogenen Daten. Starke Verschlüsselung mit nicht kompromittierten Schlüsseln kann die Risikoanalyse zu Verstößen wesentlich verändern. Schwaches Schlüsselmanagement kann dieses Argument untergraben.

Playbooks zur Schlüsselkompromittierung müssen definieren:

• Wie eine vermutete Offenlegung von Schlüsseln erkannt wird.
• Wer einen kryptografischen Vorfall ausruft.
• Wie betroffene Daten, Services, Kunden und Rechtsräume identifiziert werden.
• Wie Schlüssel widerrufen oder rotiert werden.
• Wie abhängige Systeme wiederhergestellt werden.
• Wie die Integrität von Nachweisen gewahrt wird.
• Wie rechtliche, regulatorische und kundenbezogene Benachrichtigungsentscheidungen getroffen werden.

Das Schlüsselmanagement-Register wird in diesem Prozess wesentlich. Ohne Register verlieren Incident Handler Zeit damit, zu identifizieren, was ein Schlüssel geschützt hat. Mit Register können sie den Umfang der Auswirkungen schnell eingrenzen.

Die Auditperspektive: ein Kontrollsatz, viele Nachweisnutzer

Verschiedene Auditoren betrachten kryptografisches Schlüsselmanagement aus unterschiedlichen Blickwinkeln, kommen aber bei denselben Nachweisen zusammen.

Ein belastbares Auditpaket für kryptografisches Schlüsselmanagement enthält üblicherweise:

• Genehmigte Richtlinie zu kryptografischen Kontrollen.
• Genehmigte Richtlinie zur Nutzung von Cloud-Diensten, sofern Cloud-Verschlüsselung relevant ist.
• Kryptografischer Standard und Algorithmusliste.
• Schlüsselmanagement-Register.
• Inventar von Zertifikaten und Geheimnissen.
• KMS-, HSM- und Vault-Architektur.
• IAM- und Nachweise aus Überprüfungen privilegierter Zugriffe.
• Aufzeichnungen zu Rotation und Widerruf.
• Nachweise zu Backup-, Escrow- und Wiederherstellungstests.
• Regeln zur Protokollierung und Überwachung von Schlüsselaktivitäten.
• Zuordnung von Lieferanten und geteilter Verantwortung in der Cloud.
• Vorfall-Playbook für vermutete Schlüsselkompromittierung.
• Ausnahmen und Risikoakzeptanzen.
• Managementbewertung und Aufzeichnungen zur Behebung von Audit-Feststellungen.

Dieses Paket macht aus einer Kontrollbehauptung einen belastbaren Nachweis.

Häufige Feststellungen in Audits zum Schlüsselmanagement

Die häufigsten Feststellungen sind vermeidbar:

1. Kein einheitliches Inventar von Schlüsseln, Zertifikaten und kryptografischen Werkzeugen.
2. Standardverschlüsselung durch Cloud-Anbieter wird als vollständige Schlüssel-Governance behandelt.
3. Produktivschlüsseln ist kein Verantwortlicher oder Verwahrer zugewiesen.
4. Rotation existiert für Zertifikate, aber nicht für Anwendungsschlüssel oder Datenbank-CMKs.
5. Geheimnisse und Schlüssel werden ohne Klassifizierung im selben Vault vermischt.
6. Entwickler können Schlüssel außerhalb genehmigter Muster erstellen.
7. Es gibt keinen Nachweis, dass KMS-Administratoren überprüft werden.
8. Wiederherstellungsverfahren existieren, wurden aber nie getestet.
9. Schlüsselkompromittierung ist nicht in Incident-Response-Playbooks enthalten.
10. Legacy-Algorithmen verbleiben in internen Services, weil niemand die Abhilfemaßnahmen verantwortet.
11. BYOK-Zusagen werden in Kundenverträgen gemacht, aber nicht im Betrieb abgebildet.
12. Anbieterseitig verwaltete Verschlüsselung ist nicht in Lieferantenrisikoprüfungen enthalten.

Jede Feststellung führt auf Governance zurück. Deshalb darf Kryptografie nicht als rein technisches Engineering-Projekt behandelt werden. Sie muss mit ISMS-Geltungsbereich, Risikobehandlung, Richtlinie, Lieferanten, Cloud, Zugriff, Protokollierung, Vorfällen und Kontinuität verbunden sein.

Schlüssel-Governance vor dem nächsten Vorfall auditfähig machen

Wenn sich Ihre Organisation auf NIS2, DORA, Nachweise zu GDPR Article 32, ISO/IEC 27001:2022-Zertifizierung oder postquantenfähige Krypto-Agilität vorbereitet, beginnen Sie mit einer Frage: Können Sie heute ein vollständiges Schlüsselmanagement-Register vorlegen?

Wenn nicht, kann Clarysec Ihnen helfen, das Kontrollsystem darum herum aufzubauen.

Nutzen Sie den Zenith Blueprint Zenith Blueprint, um die Arbeit über die Phase Risikomanagement, Schritt 14, und die Phase Umsetzung der Kontrollen, Schritt 20, zu strukturieren. Nutzen Sie Zenith Controls Zenith Controls, um ISO/IEC 27002:2022 Maßnahmen 8.24, 5.17 und 5.23 über NIS2, DORA, GDPR, NIST und Auditerwartungen hinweg zuzuordnen. Nutzen Sie Clarysecs Richtlinie zu kryptografischen Kontrollen Richtlinie zu kryptografischen Kontrollen, Richtlinie zu kryptografischen Kontrollen für KMU Richtlinie zu kryptografischen Kontrollen für KMU und Richtlinie zur Nutzung von Cloud-Diensten Richtlinie zur Nutzung von Cloud-Diensten, um Anforderungen in betriebliche Regeln zu überführen.

Der praktische nächste Schritt ist einfach: Wählen Sie einen kritischen Service, inventarisieren Sie seine Schlüssel, belegen Sie die Eigentümerschaft, prüfen Sie den Zugriff, ziehen Sie Rotationsnachweise und testen Sie die Wiederherstellung. Wenn das länger als einen Tag dauert, benötigt Ihre kryptografische Governance Aufmerksamkeit, bevor Aufsichtsbehörde, Auditor oder Incident-Response-Team dieselbe Frage unter Druck stellt.