Kryptografisches Inventar aufbauen: was zu erfassen ist, Discovery-Methoden im Vergleich, Zertifikats-Discovery, CBOM, Priorisierung und ein 90-Tage-Plan.
Ein kryptografisches Inventar ist ein gepflegtes Verzeichnis aller Stellen, an denen Ihre Organisation Kryptografie einsetzt: welche Algorithmen, Schlüssellängen, Zertifikate, Schlüssel, Bibliotheken und Protokolle verwendet werden, auf welchen Systemen, zum Schutz welcher Daten und unter wessen Verantwortung. Es entsteht durch kryptografische Discovery (das Scannen von Netzwerken, Hosts, Keystores, Schlüsselverwaltungssystemen, Code und Zertifikatsquellen) und ist der erste Schritt jedes Post-Quanten-Migrationsprogramms, denn RSA oder ECC lassen sich nicht dort ersetzen, wo man nichts von ihnen weiss.
Die meisten Organisationen glauben bereits zu wissen, wo ihre Kryptografie liegt: in den Load Balancern, in der PKI, im HSM. Die Discovery zeigt in der Regel etwas anderes. Zertifikate liegen in Java-Keystores, für die niemand zuständig ist, Anwendungen binden Bibliotheken ein, die veraltete Cipher Suites aushandeln, Cloud-KMS-Schlüssel wurden von Teams angelegt, die längst weitergezogen sind, und Appliances von Herstellern enthalten Kryptografie, die kein Scanner sieht. Die Regulatoren haben das erkannt: Die US-Bundesregierung verlangt seit 2023 ein priorisiertes kryptografisches Inventar, und europäische und Schweizer Aufsichtsbehörden erwarten heute eines als Teil des Quantenrisiko-Managements.
Dieser Leitfaden erklärt, was inventarisiert werden sollte, vergleicht die Discovery-Methoden und ihre blinden Flecken, behandelt speziell die Zertifikats-Discovery, zeigt, wie aus einem Inventar eine CBOM wird, und schliesst mit einem 90-Tage-Plan, den Sie noch in diesem Quartal beginnen können.
Das geschäftliche Problem ist schnell beschrieben. Ein kryptografisch relevanter Quantencomputer würde die Public-Key-Algorithmen (RSA, ECDH, ECDSA) brechen, die fast überall Schlüsselaustausch und Signaturen absichern. Ihr Ersatz ist ein mehrjähriges Engineering-Programm, und heute aufgezeichnete Daten können später entschlüsselt werden. Ohne zu wissen, wo diese Algorithmen eingesetzt werden, lässt sich dieses Programm weder budgetieren noch sequenzieren noch nachweisen. Deshalb stellen die wichtigsten öffentlichen Rahmenwerke das Inventar an den Anfang.
Das OMB-Memorandum M-23-02, "Migrating to Post-Quantum Cryptography" (18. November 2022) verpflichtet die Bundesbehörden, bis zum 4. Mai 2023 und danach jährlich bis 2035 ein priorisiertes Inventar der Informationssysteme und Assets, die durch einen CRQC angreifbare kryptografische Systeme enthalten, an ONCD und CISA zu übermitteln. Im Fokus stehen Systeme mit hoher Auswirkung, High Value Assets, Systeme mit Daten, die voraussichtlich auch 2035 noch missionskritisch sind, sowie PKI-basierte Zugriffskontrolle. Für jedes System müssen die Behörden unter anderem den verwendeten kryptografischen Algorithmus, den damit erbrachten Dienst, die Schlüssellänge, den Softwarehersteller, Betriebssystem und Version, das Hosting-Modell und die erforderliche Schutzdauer der Daten ("time to live") erfassen.
Diese Feldliste ist eine gute Vorlage für jede Organisation, ob reguliert oder nicht. Das Memo zählt ein kryptografisches System zudem als "aktiv genutzt", wenn es eingesetzt werden kann, auch nur für Legacy-Clients; genau diese Art von Fallback-Konfiguration fördert die Discovery typischerweise zutage. Unsere Übersicht zur US-Post-Quanten-Regulierung beschreibt den gesamten Zeitplan auf Bundesebene.
Das gemeinsame Factsheet "Quantum-Readiness: Migration to Post-Quantum Cryptography" (CISA, NSA, NIST, August 2023) fordert Organisationen auf, mit "proactive cryptographic discovery activities" (proaktiven Aktivitäten zur kryptografischen Discovery) zu beginnen und mit Discovery-Werkzeugen quantenanfällige Algorithmen an drei Stellen zu suchen:
Zwei weitere Punkte sind für den Umfang entscheidend. Discovery-Werkzeuge sehen in Produkte eingebettete Kryptografie möglicherweise nicht, deshalb sollten Sie Hersteller nach Listen der eingebetteten Kryptografie fragen. Und das Inventar sollte mit bestehenden Asset-, Identitäts- (ICAM/IdAM), EDR- und CDM-Inventaren abgeglichen werden und festhalten, wie lange die sensibelsten Datensätze geschützt werden müssen.
Das Projekt "Migration to Post-Quantum Cryptography" des National Cybersecurity Center of Excellence des NIST ist in NIST SP 1800-38 dokumentiert. Band B, "Quantum Readiness: Cryptographic Discovery", beschreibt einen funktionalen Testplan für Discovery-Werkzeuge, einen Discovery-Ansatz, mit dem die meisten Organisationen sofort beginnen können, und eine Laborarchitektur, die beigesteuerte Discovery-Werkzeuge integriert. Die neuesten Versionen, die wir auf csrc.nist.gov überprüfen konnten, sind vorläufige Entwürfe (Band A April 2023; Bände B und C Dezember 2023). Betrachten Sie das Dokument daher als praktische Orientierung und nicht als finalen Standard.
In der Schweiz erwartet die FINMA-Aufsichtsmitteilung 05/2026 von beaufsichtigten Instituten ein laufend aktualisiertes kryptografisches Inventar und eine vom Verwaltungsrat genehmigte PQC-Roadmap; siehe unseren Leitfaden zur Post-Quanten-Roadmap nach FINMA 05/2026. Für Finanzunternehmen und wesentliche Einrichtungen in der EU siehe DORA-Verschlüsselungsanforderungen und NIS2-Anforderungen an Krypto-Agilität.
Ein brauchbares kryptografisches Inventar ist keine Zertifikatsliste. Es umfasst jeden Asset-Typ, der Kryptografie enthält oder ausführt, und erfasst genügend Kontext, um eine Migrationsentscheidung zu treffen.
| Asset-Typ | Wo er sich versteckt | Was zu erfassen ist |
|---|---|---|
| TLS/X.509-Zertifikate | Load Balancer, Webserver, API-Gateways, Kubernetes Secrets, Windows-Zertifikatsspeicher, PEM-Dateien, Appliances | Subject/SANs, Aussteller, Signaturalgorithmus, Schlüsselalgorithmus und -länge, Ablaufdatum, Verantwortlicher, bediente Endpunkte, Quantenrisiko |
| Private Schlüssel und Keystores | PEM/DER-Dateien, PKCS#12/PFX, JKS/JCEKS, TPMs, Konfigurationsverzeichnisse von Anwendungen | Algorithmus, Schlüssellänge, Format, Speicherort, Schutz (Datei, HSM, KMS), Verantwortlicher, zugehöriges Zertifikat |
| KMS- und HSM-Schlüssel | Cloud-KMS (AWS, Azure, GCP), On-Premises-HSMs, Vaults | Schlüssel-ID, Algorithmus, Länge, Verwendung (Verschlüsseln, Signieren, Wrapping), Rotationsrichtlinie, geschützte Daten, Verantwortlicher |
| Protokolle und Cipher Suites | TLS-Endpunkte, IPsec/IKEv2-VPNs, SSH, internes Service Mesh | Protokollversion, Gruppe für den Schlüsselaustausch, Cipher Suite, ob ein PQC- oder hybrider Schlüsselaustausch angeboten wird |
| Bibliotheken und Verwendung im Code | OpenSSL, BoringSSL, Java JCA/JCE, .NET, Go crypto, mitgelieferte Bibliotheken, CI/CD-Abhängigkeiten | Bibliothek und Version, aufgerufene Algorithmen, fest codierte Parameter, zuständige Anwendung |
| Signaturinfrastruktur | Code Signing, Signatur von Firmware- und Software-Updates, Dokumentensignatur, interne CAs | Algorithmus, Schlüssellänge, Gültigkeit, Speicherort des Schlüssels, abhängige Artefakte |
| Eingebettete und Hersteller-Kryptografie | Netzwerk-Appliances, OT-Geräte, SaaS, COTS-Software | Herstellerangaben zu Algorithmen, PQC-Roadmap, Datum der Vertragsverlängerung |
| Ruhende Daten | Datenbanken, Backups, Speicherverschlüsselung, Archive | Algorithmus, Schlüsselreferenz, Datenklassifizierung, erforderliche Schutzdauer |
Für jeden Eintrag sind die Mindestfelder: Algorithmus, Schlüssellänge, Verantwortlicher, Ablauf- oder Rotationsdatum, Bibliothek oder Produkt, Protokoll, die geschützten Daten und eine Bewertung des Quantenrisikos. Algorithmus und Schlüssellänge zeigen, ob ein Eintrag quantenanfällig ist; der Verantwortliche zeigt, wer ihn behebt; die Lebensdauer der Daten zeigt, wie dringend es ist.
Keine einzelne Technik findet alles. Jede Methode sieht eine andere Ebene, und die Lücken sind vorhersehbar.
| Methode | Was sie findet | Stärken | Blinde Flecken |
|---|---|---|---|
| Passives oder aktives Netzwerk-/TLS-Scanning | Zertifikate, Protokollversionen, Cipher Suites und Gruppen für den Schlüsselaustausch auf erreichbaren Endpunkten | Schnell, agentenlos, deckt zuerst die externe Angriffsfläche ab | Sieht nur, was auf der Leitung ausgehandelt wird; übersieht ruhende Daten, interne Bibliotheken, nicht erreichbare Segmente |
| Host- und Dateisystem-Scanning | Zertifikats- und Schlüsseldateien, Keystores, Zertifikatsspeicher des Betriebssystems | Findet verwaiste Schlüssel und Zertifikate, die niemand registriert hat | Erfordert pro Host einen Agenten oder Zugangsdaten; zeigt nicht, welcher Code den Schlüssel verwendet |
| Keystore-, HSM- und KMS-APIs | Verwaltete Schlüssel mit Algorithmus, Länge, Verwendung und Metadaten | Massgeblich für verwaltete Schlüssel; wenig Rauschen | Deckt nur Schlüssel ab, die in verwalteten Systemen erstellt wurden; Schatten-Schlüssel bleiben unsichtbar |
| Code-, SBOM- und Bibliotheksanalyse | Aufrufe von Krypto-APIs, Bibliotheken und Versionen, fest codierte Algorithmen | Findet Kryptografie, bevor sie ausgeliefert wird; passt in CI/CD | Statische Analyse kann zu viel oder zu wenig melden; die Laufzeitkonfiguration kann abweichen |
| CA-Exporte und Certificate-Transparency-Logs | Von Ihren CAs oder für Ihre Domains ausgestellte Zertifikate | Vollständig für öffentlich vertrauenswürdige Zertifikate; kein Systemzugriff nötig | CT deckt nur öffentlich protokollierte Zertifikate ab; die Abdeckung privater CAs hängt von der Qualität der Exporte ab |
| Herstellerfragebögen | In Produkte und Dienste eingebettete Kryptografie | Der einzige Weg in geschlossene Produkte | Selbstauskunft; erfordert Nachverfolgung bei der Vertragsverlängerung |
Die praktische Antwort ist, die Methoden zu kombinieren: Netzwerk-Scanning für die Exponierung, Host- und Keystore-Scanning für das, was auf Datenträgern liegt, KMS/HSM-APIs für verwaltete Schlüssel, Codeanalyse für das, was Ihre Entwickler bauen, und Gespräche mit Herstellern für das, was Sie nicht scannen können. Anschliessend werden Duplikate bereinigt: Dasselbe Zertifikat, das auf einem Load Balancer, in einer PFX-Datei und in einem CT-Log auftaucht, ist ein Asset mit drei Fundorten.
Zertifikate sind meist der grösste und sich am schnellsten verändernde Teil des Inventars, und ein Werkzeug zur Zertifikats-Discovery ist oft der Ausgangspunkt der Teams. Vier Quellen zusammen ergeben eine gute Abdeckung:
Gleichen Sie die vier Quellen ab: Ein Zertifikat, das in CT, aber nicht im Netzwerk auftaucht, wird möglicherweise nicht genutzt (oder ist irgendwo eingesetzt, wo Sie nicht scannen); eines, das im Netzwerk, aber in keinem CA-Export auftaucht, ist nicht verwaltet. Beide verdienen ein Ticket. Gefundene Zertifikate gehören in ein Lifecycle-Management; siehe DuoKey Zertifikatsverwaltung.
Ein kryptografisches Inventar ist der Arbeitsdatenbestand; eine CBOM (Cryptography Bill of Materials) ist ein standardisierter, maschinenlesbarer Export davon. CycloneDX hat die CBOM-Unterstützung mit Version 1.6 eingeführt, die OWASP am 9. April 2024 veröffentlicht hat und die in der Ankündigung als "a structured framework for inventorying cryptographic assets" (ein strukturiertes Rahmenwerk zur Inventarisierung kryptografischer Assets) beschrieben wird. Der Unterschied ist in der Praxis wichtig. Ihr Inventar kann Verantwortliche, Tickets, Risikoentscheidungen und geschäftlichen Kontext enthalten. Die CBOM ist das, was Sie mit Auditoren, Werkzeugen für das Schwachstellenmanagement und Lieferanten austauschen und zwischen Releases vergleichen. Unser CBOM-Leitfaden für DuoKey Cockpit zeigt Schritt für Schritt, wie man eine CBOM erzeugt und liest, deshalb wiederholen wir das hier nicht.
Ein erster Discovery-Lauf liefert typischerweise Tausende von Ergebnissen. Ordnen Sie sie entlang zweier Achsen:
| Kurze Lebensdauer der Daten | Lange Lebensdauer der Daten | |
|---|---|---|
| Hohe Exponierung (Internet, Partner) | Migration planen; Laufzeiten der Zertifikate beobachten | Höchste Priorität: zuerst hybrider oder PQC-Schlüsselaustausch |
| Geringe Exponierung (intern) | Im Rahmen normaler Erneuerungszyklen migrieren | Frühzeitig einplanen; Backups und Archive prüfen |
Für Signaturen gilt eine andere Logik: Sie lassen sich nicht rückwirkend fälschen. Priorität haben deshalb langlebige Vertrauensanker wie Root-CAs, Firmware- und Code-Signing-Schlüssel, deren Ersatz am längsten dauert. Unser Leitfaden zur PQC-Migrations-Roadmap zeigt, wie aus dieser Rangfolge ein sequenzierter Plan wird.
Ein einmaliges Inventar ist innerhalb weniger Wochen veraltet: Zertifikate werden erneuert, neue Dienste gehen live, Cloud-Teams erstellen Schlüssel, Hersteller spielen Updates ein. Ein einmaliges Projekt ist zwar ein legitimer Weg, um die erste Baseline und die erste regulatorische Meldung zu erstellen, sollte aber in einen kontinuierlichen Prozess übergehen:
Diesen kontinuierlichen Kreislauf nennt der Markt Cryptographic Posture Management: erkennen, bewerten, planen und beheben, dann erneut erkennen.
Tage 1-30: Umfang und Baseline
Tage 31-60: nach innen gehen
Tage 61-90: entscheiden und operationalisieren
Der PQC Scanner von DuoKey ist die Discovery-Engine des DuoKey Cryptographic Posture Management (CPM). Gemäss der DuoKey-Dokumentation erkennt er:
Die Ergebnisse werden nach Algorithmus mit P1 bis P4 eingestuft (RSA, DSA, 3DES, RC4, ECDSA P-256 und EdDSA werden markiert; ML-KEM, ML-DSA und SLH-DSA sind P4, also informativ). Jeder Scan erzeugt einen Quantum Readiness Score (QRS) von 0 bis 100 und eine CBOM, mit Compliance-Verweisen auf CNSA 2.0 und BSI TR-02102, sowie eine ServiceNow-Integration zur Nachverfolgung der Migrationsarbeiten.
DuoKey CPM betreibt dies als kontinuierlichen Kreislauf (erkennen, bewerten, simulieren, beheben) mit einer lebenden CBOM, Drift-Alarmen, Simulationsberichten, von einem Agenten entworfenen und von einem Menschen genehmigten Remediation-Pull-Requests, ServiceNow-Synchronisation und regulatorischem Mapping auf DORA, NIS2, FINMA 05/2026, NIST IR 8547 und CNSA 2.0.
Für eine erste Einschätzung, noch bevor Sie Zugriff gewähren, beginnen Sie mit dem kostenlosen Quantum Risk Score, der keinen Zugriff auf interne Systeme benötigt. Scanner und CPM laufen auf der DuoKey Cockpit Plattform; für alles, was über das hier Beschriebene hinausgeht, kontaktieren Sie DuoKey.
Q: Was ist ein kryptografisches Inventar?
Ein kryptografisches Inventar ist ein gepflegtes Verzeichnis aller in einer Organisation eingesetzten Kryptografie: Algorithmen, Schlüssellängen, Zertifikate, Schlüssel, Bibliotheken und Protokolle, mit Speicherort, Verantwortlichem, Ablaufdatum und den Daten, die sie schützen. Es ist die Grundlage, um das Quantenrisiko zu bewerten und eine Post-Quanten-Migration zu planen.
Q: Was ist kryptografische Discovery?
Kryptografische Discovery ist das automatische Auffinden von Kryptografie durch das Scannen von Netzwerken und TLS-Endpunkten, Hosts und Keystores, KMS- und HSM-APIs, Quellcode und Abhängigkeiten sowie von Zertifikatsquellen wie CT-Logs und CA-Exporten. Ihre Ergebnisse fliessen in das kryptografische Inventar ein.
Q: Wie finde ich alle Zertifikate in meinem Netzwerk?
Kombinieren Sie vier Quellen: Certificate-Transparency-Logs für öffentlich vertrauenswürdige Zertifikate auf Ihren Domains, Netzwerk-Scans Ihrer IP-Bereiche und DNS-Namen, Exporte aus Ihren internen CAs und Host-Scans von Keystores und Zertifikatsdateien. Gleichen Sie sie anschliessend ab, denn jede Quelle übersieht Zertifikate, die die anderen finden.
Q: Was ist der Unterschied zwischen einem kryptografischen Inventar und einer CBOM?
Das Inventar ist Ihr Arbeitsdatenbestand, einschliesslich Verantwortlichkeiten, Risikoentscheidungen und Behebungsstatus. Eine CBOM ist ein standardisierter, maschinenlesbarer Export kryptografischer Assets, definiert in CycloneDX seit Version 1.6, mit dem das Inventar mit Werkzeugen, Auditoren und Lieferanten geteilt und über die Zeit verglichen wird.
Q: Ist ein Krypto-Inventar regulatorisch vorgeschrieben?
In der US-Bundesverwaltung ja: OMB M-23-02 verpflichtet die Behörden, ab dem 4. Mai 2023 bis 2035 jährlich ein priorisiertes Inventar einzureichen. In der Schweiz erwartet die FINMA-Aufsichtsmitteilung 05/2026 von beaufsichtigten Instituten, eines zu führen. In der EU machen die Pflichten von DORA und NIS2 zu Kryptografie und Asset-Management ein Inventar zum praktischen Weg, die Compliance nachzuweisen.
Q: Welche Algorithmen gelten als quantenanfällige Kryptografie?
Public-Key-Algorithmen, die auf Faktorisierung oder diskreten Logarithmen beruhen: RSA, Diffie-Hellman, ECDH, ECDSA und DSA. OMB M-23-02 nennt diese und verlangt von den Behörden, jeden asymmetrischen Algorithmus einzubeziehen, der nicht nachweislich quantenresistent ist. Post-Quanten-Algorithmen wie ML-KEM, ML-DSA und SLH-DSA sind der Ersatz.
Q: Kann ein Scanner alle Kryptografie automatisch finden?
Nein. Scanner übersehen Kryptografie, die in geschlossene Produkte und Appliances eingebettet ist, und jede Methode sieht nur ihre eigene Ebene. Das Factsheet von CISA, NSA und NIST empfiehlt, Hersteller nach Listen der eingebetteten Kryptografie zu fragen, um diese Lücke zu schliessen.
Q: Wie oft sollte ein kryptografisches Inventar aktualisiert werden?
Kontinuierlich oder zumindest bei jeder wesentlichen Änderung. Zertifikate werden erneuert, Schlüssel erstellt und Dienste ausgeliefert, und das jede Woche; ein einmaliges Inventar veraltet daher schnell. Setzen Sie geplante und durch CI/CD ausgelöste Scans, Drift-Alarme und regelmässige CBOM-Exporte ein.
Ein kryptografisches Inventar macht aus einer abstrakten Quantenwarnung eine Liste von Assets mit Verantwortlichen und Terminen. Bauen Sie es mit mehreren Discovery-Methoden auf, erfassen Sie den Kontext, der Entscheidungen bestimmt, exportieren Sie es als CBOM und halten Sie es laufend aktuell.
Geschrieben von
DuoKey Team
Verwandte Ressourcen
Sagen Sie uns, wo Kontrolle heute schwierig ist. Wir helfen Ihnen, den nächsten praktischen Schritt zu finden.
