Northwind Traders führt für jede kryptografische Anwendung, die eine Geschäftsgrenze absichert, einen Inventardatensatz; jedem Datensatz ist ein namentlich genannter Systemverantwortlicher zugeordnet, der für den Migrationspfad zuständig ist. Der Datensatz erfasst Informationen zu Protokoll, Algorithmus, Zertifikat, Bibliothek und Eigentumsnachweis und liefert anstelle einer bloßen Zertifikatsliste eine entscheidungsorientierte Übersicht der quantenanfälligen Abhängigkeiten. Die Bedrohung besteht in der Strategie „Harvest Now, Decrypt Later“ (jetzt erfassen, später entschlüsseln): Dabei wird Datenverkehr (Kunden-, Zahlungs- und Verwaltungsdaten) abgegriffen, der heute durch Public-Key-Kryptografie geschützt ist, die jedoch von einem künftigen, kryptanalytisch leistungsfähigen Quantencomputer geknackt werden könnte.
Die kritischen Pfade von Northwind verlaufen über mehrere Vertrauensgrenzen hinweg. Das öffentliche Storefront und die mobile App kommunizieren mit dem EdgeGW; das EdgeGW authentifiziert sich gegenüber Orders mittels Mutual TLS; AuthN signiert die JWTs, die vom Admin-Portal und den APIs akzeptiert werden; PayBridge verbindet sich mit einem Zahlungsdienstleister; und CI/CD-Prozesse signieren bereitstellbare Artefakte. Unternehmensinterne und öffentliche Zertifizierungsstellen bilden jeweils eigene Vertrauensanker (Root-Zertifikate). Ein Auditor, der an einem Edge-Punkt ein RSA-2048-Zertifikat vorfindet, kann noch nicht beurteilen, ob dasselbe kryptografische Element auch für das Signieren von Releases, die Authentifizierung von Diensten oder die Validierung von Zugriffstokens verwendet wird.
Die Architektur macht die Erfassungsgrenze sichtbar, noch bevor wir ihr Datensätze zuordnen:
Dieses Diagramm veranschaulicht, warum eine reine Zertifikatsinventur nicht ausreicht: TLS, mTLS, JWT-Verifizierung und Paketüberprüfung weisen der Public-Key-Kryptografie unterschiedliche Protokollrollen und Verantwortliche zu.
Da derselbe RSA-2048-Schlüssel unterschiedliche Funktionen erfüllen kann, erfasst Northwind eine kryptografische Verwendung als einen Algorithmus, der für einen bestimmten Zweck an einer bestimmten Systemgrenze operiert. Ein TLS-Serverzertifikat, ein ECDH-Schlüsselaustausch und eine JWT-Signatur gelten als separate Verwendungsarten, selbst wenn sie von ein und demselben Produkt bereitgestellt werden. Diese Unterscheidung ist wichtig, da ein hybrider Schlüsselaustausch das Risiko für die Vertraulichkeit in einem unterstützten TLS-Pfad verringern kann, während eine unveränderte JWT-Signatur im Bedrohungsszenario durch Quantencomputer weiterhin fälschbar bleibt.
Jeder Datensatz enthält die Informationen, die für eine spätere Entscheidung über den Austausch erforderlich sind:
Die erforderlichen Felder trennen die Bestandsaufnahme von der Entscheidungsfindung. Die Analyse der Cipher-Suites deckt eine Anfälligkeit durch ECDH auf, doch erst die Bibliotheksversion und der Änderungspfad entscheiden darüber, ob EdgeGW eine hybride Implementierung nutzen kann. Ein Signaturdatensatz muss Informationen zu den Verifizierungsinstanzen enthalten, da ein Wechsel des Signierers ohne entsprechende Anpassung von Admin-Portal, API-Gateway und Deployment-Verifizierer die Vertrauenskette unterbricht. Der folgende Vergleich beleuchtet jene fehlenden Details, die regelmäßig verhindern, dass ansonsten präzise Bestandsaufnahmen als Grundlage für Migrations-Roadmaps dienen können:
Diese Tabelle verdeutlicht, dass die Identifizierung von Algorithmen zwar notwendig, aber nicht hinreichend ist: Zuständigkeit, Reichweite der Verifizierer und Produktversion entscheiden darüber, ob ein standardisierter Austausch tatsächlich implementiert werden kann.
Entscheidungsregel Ein Datensatz ohne Zweck und Zuständigen beschreibt ein Artefakt, keine migrierbare kryptografische Abhängigkeit.
Nachdem das Schema festgelegt ist, beginnt Northwind bei den Schnittstellen, die langlebige, sensible Daten übertragen oder kritische Integritätsentscheidungen durchsetzen. client→EdgeGW erfasst externes TLS; EdgeGW→Orders erfasst internes mTLS; AuthN erfasst die JWT-Signierung sowie alle Verifizierer; PayBridge erfasst eine Abhängigkeit von Drittanbietern; und CI/CD erfasst die Artefakt-Signierung. Das Inventar muss ECDH getrennt von AES führen, da AES weiterhin geeignet sein kann, während der ECDH-Schlüsselaustausch einen Ersatz oder einen hybriden Übergang erfordert.
Welcher Eintrag erfordert sowohl eine Migration des Signierers als auch eine Bestandsaufnahme der verteilten Verifizierer: der Datensatz für die AuthN-JWT-Signierung oder der Datensatz für EdgeGW→Orders-mTLS?
Das ausgefüllte Inventar verwendet nachweisbasierte Datensätze für acht bei Northwind identifizierte Fälle und gruppiert die Ergebnisse nach der Verwendung von RSA-2048, ECDH und ECDSA P-256: