DORA Artikel 7: Schlüsselmanagement und Zertifikatsregister

Artikel 7 der Delegierten Verordnung (EU) 2024/1774 der Kommission, der technischen Regulierungsstandards (RTS) zum IKT-Risikomanagement unter DORA, verlangt zweierlei: ein Management kryptografischer Schlüssel über den gesamten Schlüssellebenszyklus und ein Register der Zertifikate für IKT-Assets, die kritische oder wichtige Funktionen unterstützen. Das Register ist ein Compliance-Artefakt, aber auch die operative Liste, die Sie an dem Tag benötigen, an dem Sie Schlüsselaustausch und Signaturen auf Post-Quanten-Algorithmen migrieren. Dieser Leitfaden beschreibt die zu erfassenden Felder, die rein lesenden Befehle zum Auffinden von Zertifikaten und die Verbindung des Registers mit dem umfassenderen kryptografischen Inventar, das DORA Artikel 6 verlangt. Er dient der Information und ist keine Rechtsberatung.

Was Artikel 7 wörtlich verlangt

Der RTS-Text ist kurz und konkret. Finanzunternehmen müssen über Richtlinien und Verfahren für das Management kryptografischer Schlüssel verfügen, die Erzeugung, Erneuerung, Speicherung, Sicherung, Archivierung, Abruf, Übertragung, Außerbetriebnahme, Widerruf und Vernichtung von Schlüsseln abdecken. Davon getrennt müssen sie ein Register der Zertifikate und der zertifikatspeichernden Geräte für IKT-Assets führen, die kritische oder wichtige Funktionen unterstützen, und die Zertifikatserneuerung so steuern, dass ein Ablauf diese Funktionen nicht unterbricht. Der maßgebliche Text ist auf EUR-Lex abrufbar: Delegierte Verordnung (EU) 2024/1774 der Kommission.

Aus diesem Wortlaut ergeben sich unmittelbar drei Konsequenzen, noch vor jeder Auslegung.

• Der Geltungsbereich richtet sich nach Funktionen, nicht nach Infrastruktur. Auslöser ist die Unterstützung einer kritischen oder wichtigen Funktion, daher folgt das Register Ihrer eigenen Klassifizierung der Funktionen und nicht einer Netzwerkgrenze.
• Geräte gehören dazu, nicht nur Dateien. Zertifikatspeichernde Geräte sind Hardware-Sicherheitsmodule (HSMs), Smartcards, Trusted Platform Modules und Keystores von Appliances; inventarisieren Sie daher den Träger ebenso wie den Berechtigungsnachweis.
• Erneuerung ist eine Verfügbarkeitskontrolle. Ein abgelaufenes Zertifikat auf einem Zahlungsgateway ist ein IKT-Vorfall; deshalb verbindet Artikel 7 das Register mit dem Erneuerungsmanagement.

Ebenso wichtig ist, was Artikel 7 nicht sagt. Er nennt keine Post-Quanten-Algorithmen, legt kein Migrationsdatum fest und schreibt kein bestimmtes Dateiformat vor. Artikel 6 ist der Artikel, der Vorkehrungen für die Aktualisierung oder Änderung kryptografischer Technologie entsprechend den Entwicklungen der Kryptoanalyse verlangt; dort setzt Krypto-Agilität an. Unsere Lesart, ausdrücklich als Interpretation gekennzeichnet: Ein Register, das Algorithmus und Schlüssellänge jedes Zertifikats erfasst, macht aus Artikel 6 statt einer schriftlichen Absichtserklärung etwas Umsetzbares, denn Sie können in wenigen Minuten jedes Asset auflisten, das noch auf RSA- oder ECDSA-Signaturen beruht.

Zu erfassende Felder pro Zertifikat

Halten Sie das Register maschinenlesbar (eine Zeile pro Zertifikat, aus Ihren Quellen exportiert statt von Hand eingetippt). Die folgenden Spalten decken die Pflichten aus Artikel 7 ab und enthalten die Daten, die eine Post-Quanten-Migration benötigt.

Zwei Felder lohnen den Aufwand, obwohl kein Text sie verlangt: die Einsatzfläche (welcher Load Balancer, welcher Ingress, welcher Broker oder welche Mutual-TLS-Gegenstelle das Zertifikat präsentiert) und ein Post-Quanten-Bereitschaftskennzeichen pro Asset, das auf Messung statt auf Absicht beruht.

Schlüssellebenszyklus: was Sie für Schlüssel festhalten, nicht für Zertifikate

Ein Zertifikat ist ein öffentliches Objekt mit Ablaufdatum. Die Pflicht zum Schlüssellebenszyklus betrifft Material, das Sie niemals exportieren dürfen; das Register erfasst daher Fakten über den Schlüssel, nicht den Schlüssel selbst. Erfassen Sie für jeden Schlüssel oder, bei Tausenden von Schlüsseln, für jede Schlüsselklasse: Erzeugungsverfahren und Entropiequelle, zugelassenen Algorithmus und Parameter, Speichergrenze (Software, HSM, Cloud-Keystore mit seiner Schutzstufe), Inhaber der Administrations- und Wiederherstellungsrechte, Regelungen zu Sicherung und Hinterlegung, Archivierungsdauer für Schlüssel, mit denen alte Signaturen weiterhin verifiziert werden müssen, Kriterien für die Außerbetriebnahme, Vernichtungsverfahren und Nachweis sowie das Playbook für den Kompromittierungsfall mit der Stelle, die darüber entscheidet.

Trennen Sie drei Kategorien, denn ihre Migrationspfade unterscheiden sich. Schlüssel für die Schlüsselvereinbarung schützen die Vertraulichkeit bei der Übertragung, und aufgezeichneter Datenverkehr kann später entschlüsselt werden, wenn die Schlüsselvereinbarung gebrochen wird; deshalb macht Harvest now, decrypt later den Schlüsselaustausch zum ersten Migrationsziel. Signaturschlüssel dienen der Authentifizierung, und eine 2035 gefälschte Signatur kann eine heutige Sitzung nicht rückwirkend brechen; Zertifikate können daher nach dem Schlüsselaustausch migriert werden. Langlebige Signaturschlüssel sind die Ausnahme: Firmware- und Software-Signaturschlüssel, die ein Jahrzehnt lang vertrauenswürdig bleiben müssen, verdienen schon jetzt Aufmerksamkeit, und NIST hat genau für diesen Fall in SP 800-208 zustandsbehaftete hashbasierte Signaturen standardisiert (LMS und XMSS, siehe SP 800-208).

Discovery: wie Sie das Register befüllen

Keine einzelne Quelle enthält alle Zertifikate. Kombinieren Sie mindestens vier und betrachten Sie jede als unvollständig.

1. Fragen Sie die Zertifizierungsstellen

Interne CA-Datenbanken und Ihre Konten bei öffentlichen CAs listen alles auf, was sie ausgestellt haben. Öffentliche Ausstellungen sind zudem in den Certificate-Transparency-Logs sichtbar; dies ist der schnellste Weg, Zertifikate zu finden, die für Ihre Domains von Teams beantragt wurden, von deren Existenz Sie nichts wussten.

2. Scannen Sie, was tatsächlich auf Verbindungen wartet

Rein lesende Prüfungen gegen einen Host zeigen das Zertifikat in der Produktion, und das ist manchmal nicht das Zertifikat, das Sie bereitgestellt zu haben glauben. Testen Sie zunächst in einer Nicht-Produktionsumgebung und vergewissern Sie sich, dass Sie zum Scannen berechtigt sind.

# Inspect the presented chain and the key algorithm
openssl s_client -connect host.example.com:443 -servername host.example.com -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -serial -fingerprint -sha256 -text \
  | grep -E "Subject:|Issuer:|Not (Before|After)|Public Key Algorithm|Public-Key|Signature Algorithm|DNS:"

# Which key agreement group was negotiated (OpenSSL 3.5 or later for the ML-KEM groups)
openssl s_client -connect host.example.com:443 -servername host.example.com \
  -groups X25519MLKEM768:X25519 </dev/null 2>/dev/null | grep -E "Negotiated|Protocol"

3. Durchsuchen Sie Dateisysteme und Keystores

# Certificates and keys on disk, with expiry, for one host
find /etc /opt /srv -type f \( -name "*.pem" -o -name "*.crt" -o -name "*.cer" \) 2>/dev/null \
  | while read -r f; do
      printf '%s\t' "$f"
      openssl x509 -in "$f" -noout -subject -enddate 2>/dev/null || echo "not a certificate"
    done

# Java keystore contents (read-only listing)
keytool -list -v -keystore /path/to/keystore.jks | grep -E "Alias name|Valid from|Signature algorithm"

4. Fragen Sie die Plattformen ab, die Zertifikate für Sie verwalten

Kubernetes-Secrets und cert-manager-Ressourcen, Zertifikatsmanager der Cloud-Anbieter, Cloud-Key-Vaults und HSM-Partitionen, Service Meshes, die kurzlebige Mutual-TLS-Zertifikate ausstellen, API-Gateways, Message Broker, TLS-Konfiguration von Datenbanken, VPN-Konzentratoren und Codesignaturdienste. Kurzlebige Mesh-Zertifikate werden in der Regel besser als Richtlinienzeile erfasst (Aussteller, Algorithmus, Laufzeit, Rotationsmechanismus) statt als Millionen einzelner Zeilen; vermerken Sie dies ausdrücklich im Register, damit Prüfende erkennen, dass die Entscheidung bewusst getroffen wurde.

# cert-manager inventory across a cluster (read-only)
kubectl get certificates -A \
  -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,ISSUER:.spec.issuerRef.name,SECRET:.spec.secretName,RENEWAL:.status.renewalTime,EXPIRY:.status.notAfter

Am ersten Tag ist Automatisierung wichtiger als Vollständigkeit. Die US-Bundesvorgaben gemäß OMB M-26-15 verlangen ein automatisiertes, kontinuierlich aktualisiertes kryptografisches Inventar, und dieses Prinzip lässt sich gut übertragen: Ein Register, das ein geplanter Job aktualisiert, hat Bestand; eine Tabelle, deren Aktualisierung vom guten Willen abhängt, nicht.

Das Register mit dem kryptografischen Inventar verknüpfen

Das Zertifikatsregister ist eine Ebene eines umfassenderen Inventars. Halten Sie beide verknüpft, statt sie zusammenzuführen: Das Zertifikatsregister beantwortet, welche Berechtigungsnachweise existieren und wann sie ablaufen, während das kryptografische Inventar beantwortet, welche Algorithmen Ihre Software und Ihre Protokolle tatsächlich verwenden, einschließlich Schlüsselvereinbarung, symmetrischer Verschlüsselung ruhender Daten, Hashing und Bibliotheken. Eine Cryptography Bill of Materials (CBOM) ist ein praktikabler Weg, die Softwareebene abzubilden, wie in Was ist eine CBOM beschrieben; das ist unsere Interpretation guter Praxis, keine DORA-Anforderung.

Dieselben Artefakte dienen mehreren Regelwerken; das spricht dafür, sie nur einmal aufzubauen.

Bei den Daten sollten Sie präzise unterscheiden. Anforderung 12.3.3 von PCI DSS v4.0.1 ist seit dem 31. März 2025 verpflichtend. Die EU Coordinated Implementation Roadmap v1.1, veröffentlicht am 23. Juni 2025, ist eine koordinierte Leitlinie für die Mitgliedstaaten und keine für Unternehmen verbindliche Verordnung: Sie sieht kryptografische Inventare und nationale Roadmaps bis Ende 2026 vor, die Migration von Anwendungsfällen mit hohem Risiko bis Ende 2030 und von solchen mit mittlerem Risiko bis Ende 2035. NIST IR 8547 ist weiterhin ein erster öffentlicher Entwurf (Initial Public Draft); er schlägt vor, quantenverwundbare Algorithmen mit 112-Bit-Sicherheit nach 2030 als veraltet einzustufen und quantenverwundbare Public-Key-Algorithmen nach 2035 nicht mehr zuzulassen, und er sollte als Entwurf zitiert werden. Alle datierten Meilensteine finden Sie in unserem Regulierungsüberblick.

Häufige Fallstricke

• Nur öffentliche Webzertifikate erfassen. Zertifikate für Mutual TLS zwischen internen Diensten, Datenbank-Clients, Message Broker, Codesignatur und Geräteidentität sind in der Regel zahlreicher als die öffentlichen.
• Den Speicherort des privaten Schlüssels weglassen. Ohne ihn können Sie bei einer Kompromittierung die einzige Frage nicht beantworten, auf die es ankommt: Wo liegt der Schlüssel, und wer hat Zugriff darauf?
• Den Ablauf als einziges Lebenszyklusereignis behandeln. Ein Widerruf, der nie geübt wurde, ist eine ungetestete Kontrolle.
• Den Geltungsbereich unbemerkt abdriften lassen. Wird eine Funktion als kritisch oder wichtig neu eingestuft, fallen ihre Zertifikate in den Geltungsbereich. Wenden Sie die Scope-Regel regelmäßig erneut an und bewahren Sie das datierte Ergebnis auf.
• Zertifikatsmigration mit der Migration des Schlüsselaustauschs verwechseln. Hybride Schlüsselvereinbarung schützt heute aufgezeichneten Datenverkehr und ist bereits einsetzbar; Post-Quanten-Zertifikate hängen von der Unterstützung durch CAs und Clients ab. Beginnen Sie mit dem Schlüsselaustausch, wie unter Krypto-Agilität erläutert.
• Veraltete vorstandardisierte Algorithmen mitschleppen. Die TLS-Gruppen aus dem Kyber-Entwurf sind durch die standardisierten ML-KEM-Gruppen abgelöst; die hybride Gruppe, auf die Sie achten sollten, ist X25519MLKEM768.

Nächster Schritt: erst messen, dann dokumentieren

Ein Register, das auf Absichten beruht, altert schlecht; befüllen Sie die Spalten für Algorithmus und Bereitschaft daher auf Basis von Messungen. Für jedes von außen erreichbare Asset, das eine kritische oder wichtige Funktion unterstützt, scannen Sie Ihre Domain mit PQC Status, um die ausgehandelten TLS-Versionen, die angebotenen Gruppen für die Schlüsselvereinbarung, die Cipher Suites und die Zertifikatskette auszulesen, und übernehmen Sie diese Werte direkt in das Register. Der Scan beschreibt ausschließlich die von außen sichtbare TLS-Konfiguration: Er ist weder eine Zertifizierung noch eine Konformitätsbestätigung, und unsere Methodik-Seite legt genau dar, was er belegt und was nicht. Sobald die externe Angriffsfläche erfasst ist, wiederholen Sie die oben genannten Discovery-Befehle für interne Listener, weisen jeder Zeile eine verantwortliche Person zu und planen den Export so, dass sich das Register selbst aktualisiert.