Wie man ein Inventar kryptografischer Assets über Cloud, CI/CD und Geräte hinweg erstellt

Kurz gesagt: Ein Inventar kryptografischer Assets ist eine strukturierte, kontinuierlich gepflegte Aufzeichnung aller Zertifikate, Schlüssel, Algorithmen und kryptografischen Abhängigkeiten in Ihrer Cloud-Infrastruktur, Ihren CI/CD-Pipelines und auf Ihren Geräten. Es ist wichtig, da Sie Zertifikate nicht rotieren, auf die Abschaffung veralteter Algorithmen reagieren oder eine PQC-Migration für Assets planen können, deren Existenz Ihnen unbekannt ist. Compliance-Fristen wie die 47-tägige Zertifikatslebensdauer des CA/B Forums (bis März 2029) und die Abschaffung veralteter Algorithmen gemäß NIST IR 8547 für 2030/2035 machen dies jetzt dringlich. Es wird empfohlen, eine automatisierte, kontinuierliche Erkennung in allen drei Umgebungen einzurichten, anstatt sich auf periodische Scans oder Tabellenkalkulationen zu verlassen, da sich die Infrastruktur schneller ändert, als es manuelle Prozesse erfassen können.

Wichtige Erkenntnisse

• Ein vollständiges Inventar umfasst weit mehr als TLS-Zertifikate: Schlüssel, Zertifizierungsstellen, Hardware-Vertrauensanker, Verschlüsselungssammlungen, kryptografische Bibliotheken und ein CBOM für die Transparenz während des Build-Prozesses.
• Cloud-Infrastruktur, CI/CD-Pipelines und vernetzte Geräte bringen jeweils spezifische Herausforderungen bei der Erkennung mit sich und stellen die Bereiche dar, in denen die meisten Organisationen die größten blinden Flecken haben.
• Der CA/B Forum-Abstimmungsantrag SC-081v3 verkürzt die maximale Gültigkeitsdauer von TLS-Zertifikaten bis März 2029 auf 47 Tage, schrittweise über 200 Tage (März 2026) und 100 Tage (März 2027), wodurch die Automatisierung unabdingbar wird.
• Der Entwurf von NIST IR 8547 sieht vor, 112-Bit-Algorithmen wie RSA-2048 nach 2030 als veraltet zu deklarieren und RSA/ECC nach 2035 vollständig zu verbieten. Eine Migration kann nicht beginnen, ohne zu wissen, wo diese Algorithmen zu finden sind.
• Ein CBOM erfasst, welche Kryptografie in ein System integriert wurde; die Laufzeiterkennung erfasst, welche tatsächlich eingesetzt wird. Beide werden benötigt und beantworten unterschiedliche Fragen.

Die kryptografische Sichtbarkeitslücke

Die meisten Sicherheitsteams können Ihnen ihre Firewall-Regeln beschreiben. Weitaus weniger können Ihnen jedoch genau sagen, wie viele Zertifikate aktuell in ihrer Umgebung aktiv sind, welche in den nächsten 30 Tagen ablaufen, ob ihre CI/CD-Pipelines einen fest codierten privaten Schlüssel an die Produktionsumgebung senden oder wo ihre KMS-Schlüssel, SSH-Schlüssel, JWT-Signaturschlüssel und API-Authentifizierungsgeheimnisse tatsächlich gespeichert sind.

Die Lücke zwischen „Wir nutzen Kryptografie überall“ und „Wir wissen, wo sich jedes kryptografische Asset befindet“ soll ein kryptografisches Inventar schließen. Die Dringlichkeit ist real und kommt von mehreren Seiten gleichzeitig. Ohne ein vollständiges und aktuelles Inventar fehlt Unternehmen die Grundlage für ihr Handeln: Sie wissen nicht, welche Zertifikate ablaufen, welche Algorithmen wo eingesetzt werden oder welche Assets betroffen sind, wenn eine Zertifizierungsstelle kompromittiert oder ein Standard abgeschafft wird.

Neben dem operationellen Risiko läuft auch die Zeit für die Einhaltung der Vorschriften. Die im April 2025 verabschiedete CA/B Forum-Abstimmung SC-081v3 sieht eine Reduzierung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate von 398 Tagen auf 47 Tage bis März 2029 vor, mit schrittweisen Reduzierungen um jeweils 200 Tage ab dem 15. März 2026 und 100 Tage ab dem 15. März 2027.

Im Bereich der Quantenverschlüsselung sieht der NIST-IR 8547, derzeit ein erster öffentlicher Entwurf (November 2024) und noch zu überarbeiten, die Abschaffung von 112-Bit-Sicherheitsalgorithmen (z. B. RSA-2048, ECC P-224) nach 2030 vor und verbietet alle RSA- und ECC-Algorithmen, einschließlich solcher mit größeren Schlüssellängen wie RSA-3072 und ECC P-256, nach 2035. Eine Migration kann erst beginnen, wenn bekannt ist, wo diese Algorithmen eingesetzt werden. Während die Gültigkeitsdauer von Zertifikaten aufgrund von Bedenken hinsichtlich der Betriebssicherheit sinkt, stellt die Quantenfähigkeit eine deutlich langfristigere Herausforderung für die kryptografische Migration dar.

Dieser Blogbeitrag beschreibt, wie Sie ein Inventar kryptografischer Assets erstellen, das in den drei Umgebungen, in denen die meisten Unternehmen die größten Sicherheitslücken aufweisen – Cloud-Infrastruktur, CI/CD-Pipelines und vernetzte Geräte –, tatsächlich Bestand hat. In allen drei Umgebungen werden kryptografische Assets schnell und häufig außerhalb zentraler Sicherheitsaufsicht bereitgestellt und bleiben oft für herkömmliche netzwerkbasierte Erkennungsmethoden unsichtbar. Wir behandeln, was erkannt werden muss, wie die Erkennung erfolgt und wie die Daten so genau gehalten werden, dass sie für entsprechende Maßnahmen geeignet sind.

Definition des kryptographischen Inventars

Ein kryptografisches Inventar ist ein strukturiertes, fortlaufend aktualisiertes Verzeichnis aller kryptografischen Assets, die Ihr Unternehmen in seiner gesamten Infrastruktur einsetzt. Stellen Sie es sich wie eine dynamische Karte vor: Es zeigt nicht nur, welche kryptografischen Tools Sie aktuell verwenden, sondern auch, wo sie sich befinden, was sie schützen, wem sie gehören, wie sie konfiguriert sind, welche Funktionen von ihnen abhängen, in welcher Phase ihres Lebenszyklus sie sich befinden und ob sie noch ihren Zweck erfüllen.

Wie die NIST-PQC-Migrationsrichtlinien, NSA CNSA 2.0 und die ETSI-Empfehlungen zur Krypto-Agilität zeigen, mangelt es vielen aktuellen Systemen an Krypto-Agilität, da sie nicht für schnelle kryptografische Upgrades konzipiert wurden und Unternehmen oft nicht wissen, wo ihre gesamte Kryptografie zum Einsatz kommt. Genau diese Wissenslücke schließt eine ordnungsgemäße Bestandsaufnahme.

Ein gutes kryptografisches Inventar beantwortet für jedes darin enthaltene Asset vier Fragen:

• Was ist es, und wo befindet es sich? Der Asset-Typ, der verwendete Algorithmus und die Schlüsselparameter, sein kryptografischer Zweck (z. B. TLS-Terminierung, Datenverschlüsselung im Ruhezustand oder während der Übertragung, Codesignierung) und die Schlüsselverwendung (Verschlüsselung, Signierung, Authentifizierung), die Vertrauenskette, an der es teilnimmt, und das spezifische System, der Dienst oder das Gerät, an das es gebunden ist.
• Wem gehört es? Verantwortlichkeit ohne Verantwortlichen ist nur eine Liste von Problemen, für deren Behebung niemand zuständig ist. Jedes Asset braucht ein verantwortliches Team.
• Was hängt davon ab? Welche Geschäftsdienste oder Systeme nutzen dieses Zertifikat und wie sind sie damit verbunden? Ein Zertifikat kann Teil einer Kette sein, in der mehrere Dienste von derselben Zwischenzertifizierungsstelle abhängig sind. Das Verständnis dieser Beziehungen wandelt die Feststellung eines „schwacher Zertifikats“ in die eines „schwacher Zertifikats, dessen Ausfall sich auf abhängige Systeme auswirkt“ um.
• Ist es noch akzeptabel? Erfüllt es die aktuellen Richtlinienanforderungen hinsichtlich Schlüssellänge, Algorithmus und Gültigkeit? Läuft es bald ab? Entspricht es den Vorgaben der Konfigurationsrichtlinie?

Was umfasst eine vollständige Inventur?

Der Umfang ist größer, als die meisten Teams annehmen. Viele beginnen mit TLS-Zertifikaten und belassen es dabei. Zertifikate sind jedoch nur eine Ebene. Eine vollständige Bestandsaufnahme umfasst die folgenden Komponenten.

Zertifikate bilden die sichtbarste Ebene: TLS-Serverzertifikate, Clientzertifikate für mTLS, Codesignaturzertifikate , E-Mail-Zertifikate, OCSP-Responderzertifikate, CRL-Signaturzertifikate, Geräteidentitätszertifikate und die Truststores, die festlegen, welche Root-CAs Ihre Systeme akzeptieren. Dazu gehören auch selbstsignierte Zertifikate, die oft vergessen werden und häufig Probleme in internen Systemen verursachen.

Kryptografische Schlüssel und Schlüsselmaterial bilden die Grundlage von Zertifikaten. Private Schlüssel, die Zertifikaten zugeordnet sind, müssen hinsichtlich Eigentümer, Speicherort, Zugriffskontrollen und Rotationsstatus nachverfolgt werden. Neben Zertifikatsschlüsseln gehören auch symmetrische Schlüssel zur Datenverschlüsselung im Ruhezustand, API-Signaturschlüssel, SSH-Schlüssel, Datenbankverschlüsselungsschlüssel, Token-Signaturschlüssel, Cloud-KMS-Schlüssel und in Tresoren oder Hardware-Sicherheitsmodulen (HSMs) gespeicherte Geheimnisse in das Inventar. Der Speicherort der Schlüssel ist ebenfalls wichtig: Ein Schlüssel in einem Software-Schlüsselspeicher birgt ein anderes Risiko als ein Schlüssel in einem FIPS 140-3 Level 3-konformen Hardware-Sicherheitsmodul.

Zertifizierungsstellen selbst, sowohl interne als auch externe, denen Sie vertrauen, sind kryptografische Ressourcen. Die Schlüssellängen, Signaturalgorithmen, Gültigkeitsdauern und die CRL/OCSP-Konfiguration Ihrer ausstellenden Zertifizierungsstellen bestimmen die Sicherheitsgrundlage für jedes von ihnen ausgestellte Zertifikat. Die gesamte Zertifizierungsstellenhierarchie muss erfasst werden: Stammzertifizierungsstellen, Zwischenzertifizierungsstellen und alle darunterliegenden untergeordneten oder ausstellenden Zertifizierungsstellen. Jede Ebene der Kette verfügt über eigenes Schlüsselmaterial, eigene Gültigkeitsdauer, eigenen Signaturalgorithmus und eigene Widerrufskonfiguration.

Vertrauensanker und Hardware-Vertrauensanker vervollständigen das Bild. Dazu gehören TPMs (in Servern und Endgeräten), sichere Elemente (häufig in IoT- und Mobilgeräten), sichere Enklaven, sichere Boot-Schlüssel, die steuern, welche Firmware- und Betriebssystem-Images ein Gerät laden darf, hardwarebasierte Attestierungsmechanismen, mit denen Geräte ihre Identität und Integrität gegenüber entfernten Systemen nachweisen können, sowie in Geräte eingebettete Hardware-Vertrauensanker. Einige dieser Komponenten lassen sich nach der Herstellung nicht mehr aktualisieren, was spezifische Auswirkungen auf die Planung der Migration nach der Quantenintegration hat.

Algorithmen, Verschlüsselungssammlungen und Protokollkonfigurationen sind die Ebene, die die meisten Organisationen völlig außer Acht lassen. Es reicht nicht aus zu wissen, dass ein System TLS verwendet. Welche Version läuft? Welche Verschlüsselungssammlungen sind tatsächlich aktiviert? Welche Schlüsselaustauschmechanismen kommen zum Einsatz? Ob ein System so konfiguriert ist, dass es TLS 1.0 als Fallback akzeptiert oder 1024-Bit-RSA verwendet, lässt sich durch einen einfachen Zertifikatsscan nicht ermitteln. Diese Daten stammen aus einer umfassenden Konfigurationsanalyse, die die in jedem System verwendeten Signaturalgorithmen (RSA, ECDSA, EdDSA), Schlüsselaustauschalgorithmen (ECDH, DHE und ihre quantensicheren Äquivalente) sowie Hash-Algorithmen (SHA-1, SHA-256 , SHA-384) abdeckt.

Kryptografische Bibliotheken müssen versioniert und hinsichtlich bekannter Sicherheitslücken erfasst werden. OpenSSL, Bouncy Castle, wolfSSL, Botan und Microsoft CNG bilden die Grundlage kryptografischer Implementierungen in Anwendungen und Diensten. Veraltete oder nicht mehr unterstützte Versionen dieser Bibliotheken bergen Sicherheitsrisiken, selbst bei Verwendung starker Algorithmen. Da jede Bibliothek ihre eigene Sicherheitslückenhistorie, ihren eigenen Funktionsumfang und ihren eigenen Support-Lebenszyklus aufweist, sollte das Inventar erfassen, welche kryptografischen Bibliotheken und Versionen in den verschiedenen Anwendungen und Diensten verwendet werden.

Eine kryptografische Stückliste (CBOM) ist ein strukturiertes Protokoll der in einem Softwaresystem, einer Firmware oder einem Gerät vorhandenen Kryptografie. Sie listet die verwendeten Algorithmen, Schlüssellängen, kryptografischen Bibliotheken, Zertifikate und Protokolle auf. Eine CBOM ermittelt keine Assets selbstständig. Sie erfasst die in einem Softwareartefakt vorhandenen Komponenten basierend auf der Build-Zeit oder statischer Analyse. Dies unterscheidet sich von der Laufzeiterkennung, die verfolgt, was tatsächlich in Ihrer Umgebung ausgeführt wird. Sie benötigen beides: Die CBOM zeigt Ihnen, was integriert wurde; die Laufzeiterkennung zeigt Ihnen, was aktiv ist.

Warum die Lagerhaltung an erster Stelle steht

Die Bestandsaufnahme ist keine vorbereitende Aufgabe, die vor Beginn der eigentlichen Sicherheitsarbeit erfolgt. Sie ist die Voraussetzung für jede nachfolgende Maßnahme.

Sie können ein Zertifikat nicht rotieren, dessen Existenz Ihnen unbekannt ist. Sie können nicht auf die Abschaffung eines Algorithmus reagieren, wenn Sie nicht wissen, welche Systeme diesen Algorithmus verwenden. Sie können keine PQC-Migration planen , ohne eine Übersicht der RSA- und ECC-Bereitstellungen zu haben. Und während eines 47-tägigen Zertifikatserneuerungszeitraums können Sie die manuelle Erneuerung Tausender Zertifikate nicht ohne ein präzises, aktuelles Inventar zur Automatisierung durchführen.

Um das zu verdeutlichen: Bei einer Kompromittierung einer Zertifizierungsstelle (CA) lautet die erste Frage stets: „Welche Zertifikate haben wir über diese CA ausgestellt?“ Organisationen ohne aktuelles Zertifikatsinventar verbringen die ersten 24 Stunden damit, diese Frage zu beantworten, anstatt die Zertifikate zu widerrufen und neu auszustellen. Wenn OpenSSL eine kritische Sicherheitslücke auslöst, reagieren die Teams am schnellsten, die sofort abfragen können, welche Anwendungen die betroffene Version verwenden. Als SHA-1 als veraltet galt, waren die Organisationen, die keine systematische Methode zur Identifizierung aller SHA-1-Zertifikate in ihrer Umgebung hatten, völlig unvorbereitet. In beiden Fällen war das Zertifikatsinventar kein Luxus, sondern der entscheidende Faktor für eine überlegte Reaktion und hektisches Handeln.

Aus diesem Grund versagen statische Tabellenkalkulationen. Eine Umgebung, die sich durch neue Bereitstellungen, Konfigurationsaktualisierungen, Cloud-Provisionierung und Software-Releases ständig verändert, wird jede manuell gepflegte Liste innerhalb weniger Wochen überholen. Das Inventar muss kontinuierlich und automatisiert aktualisiert werden, um weiterhin nützlich zu sein.

Wie Sie Ihr Krypto-Asset-Inventar aufbauen

Zu wissen, was in ein kryptografisches Inventar gehört, ist das eine. Ein solches Inventar zu erstellen, das in einer realen Unternehmensumgebung Bestand hat, ist jedoch eine ganz andere Sache. Die meisten Organisationen verfügen über kryptografische Assets, die über Cloud-Workloads, Entwicklungspipelines und physische Geräte verteilt sind, und oft hat kein einzelnes Team den Überblick über alle drei. Die folgenden Schritte beschreiben, wie Sie in jeder Umgebung vorgehen, die Daten zusammenführen und daraus verwertbare Informationen gewinnen und wie Sie verhindern, dass sie veralten.

Schritt 1: Kryptografische Transparenz in der Cloud-Infrastruktur herstellen

In der Cloud-Infrastruktur breitet sich die kryptografische Infrastruktur am schnellsten aus. Zertifikate und Schlüssel werden von Compute-Instanzen, verwalteten Datenbanken, API-Gateways, Container-Plattformen, Load Balancern, Service Meshes und Cloud-nativen CA-Diensten ausgestellt und verwendet.

Was es zu entdecken gibt:

• Zertifikate und Schlüssel für IaaS- und PaaS-Ressourcen, einschließlich solcher, die von Cloud-nativen CA-Diensten verwaltet werden.
• Cloud-KMS-Ressourcen, einschließlich AWS-KMS-Schlüssel, Azure Key Vault-Geheimnisse und -Zertifikate, Google Cloud KMS-Schlüsselringe und verwaltete HSMs, werden oft als undurchsichtige Infrastruktur und nicht als kryptografische Vermögenswerte behandelt, die ein Inventar erfordern.
• Kryptografische Konfiguration auf Load Balancern, Gateways und Service Meshes, die häufig unabhängige Zertifikatsspeicher verwalten.
• Zertifikate, die direkt über Cloud-Anbieter-Zertifikatdienste ausgestellt werden und möglicherweise nicht über Ihre interne PKI geleitet werden.

Die besondere Herausforderung in Cloud-Umgebungen liegt in der Zuständigkeit und dem Geltungsbereich. Ein von einem Entwickler über eine Cloud-API bereitgestelltes Zertifikat erscheint möglicherweise in keiner zentralen Datenbank, und ein zur Datenverschlüsselung verwendeter KMS-Schlüssel verfügt unter Umständen über keine zugehörigen Metadaten, die ihn mit der Anwendung oder dem Team verknüpfen, dem er gehört. Die automatisierte, kontinuierliche Erkennung von Zertifikaten und kryptografischen Diensten ist der einzig praktikable Ansatz, um mit der rasanten Entwicklung cloudnativer Infrastrukturen Schritt zu halten. Momentaufnahmen veralten schnell. Ziel ist ein Echtzeit-Feed, keine Momentaufnahme.

Schritt 2: Erweiterung der Discovery-Phase in die Softwarebereitstellungspipeline

CI/CD-Pipelines zählen zu den größten Schwachstellen in der kryptografischen Bestandsverwaltung und stellen gleichzeitig ein hohes Risiko dar. Sie sind zudem ein Hauptangriffspunkt für Software-Lieferkettenangriffe. Kompromittierte Build-Pipelines wurden bereits genutzt, um Schadcode in signierte Artefakte einzuschleusen, denen nachgelagerte Nutzer implizit vertraut haben. Dadurch wird das kryptografische Material in Ihrer Build-Infrastruktur sowohl zu einer Bestandslücke als auch zu einer aktiven Angriffsfläche.

Das während des Build-Prozesses in Anwendungen eingebettete kryptografische Material wird bei Zertifikatsscans auf Netzwerkebene nicht angezeigt, wodurch die Pipeline-Erkennung eine eigenständige Disziplin darstellt, die sich vom Infrastruktur-Scanning unterscheidet.

Wonach schauen:

• In Build-Konfigurationen, Dockerfiles und Infrastructure-as-Code-Vorlagen eingebettete Zertifikate und Schlüssel.
• Kryptografische Bibliotheken, die im Quellcode enthalten oder in Anwendungsbinärdateien kompiliert wurden, mit Versionsnummer und CVE-Status.
• Fest codierte oder wiederverwendete Schlüssel und Geheimnisse, die in die Versionskontrolle eingecheckt wurden, einschließlich historischer Commits, die im aktuellen Branch möglicherweise nicht mehr vorhanden sind, aber über die Repository-Historie weiterhin zugänglich bleiben.
• Code-Signatur-Zertifikate und -Schlüssel, die zum Signieren von Build-Artefakten verwendet werden, einschließlich Integrationen mit Build-Signaturdiensten wie Sigstore und Cosign.
• Workflows zur Artefaktsignatur und die dazugehörigen Schlüssel.
• SBOM- und CBOM-Generierungspipelines, die selbst als kryptografische Infrastruktur betrachtet werden sollten.

Das CBOM- Konzept ist hier hilfreich. Die Generierung eines CBOM für jede Anwendungsversion liefert eine strukturierte Aufzeichnung der integrierten kryptografischen Funktionen und ermöglicht es Unternehmen, kryptografische Abhängigkeiten im Zuge der Anwendungsentwicklung nachzuverfolgen. Allerdings muss das CBOM mit der Laufzeiterkennung kombiniert werden, um die Diskrepanz zwischen den im Binärprogramm definierten Funktionen und dem tatsächlichen Verhalten der bereitgestellten Instanz zu schließen.

Die Integration von Verfahren zur kryptografischen Bestandsaufnahme direkt in die CI/CD-Pipeline, anstatt sie erst nach der Bereitstellung zu behandeln, ist der praktikable Ansatz. Die Überprüfung von Geheimnissen vor dem Commit und Merge erkennt fest codierte Elemente, bevor sie in die Produktion gelangen. Die Bibliotheksprüfung während des Build-Prozesses kennzeichnet veraltete oder anfällige kryptografische Abhängigkeiten, bevor diese ausgeliefert werden.

Schritt 3: Behebung kryptografischer Sicherheitslücken in Geräten und Firmware

Bei diesen Geräten entsteht eine Kategorie kryptografischer Risiken, die in Cloud- oder Pipeline-Umgebungen nicht existiert: Die Assets sind schwer zugänglich, schwer zu aktualisieren und laufen oft noch Jahre oder Jahrzehnte nach der ersten Bereitstellung.

Langlebige Geräte häufen kryptografische Altlasten an, die leicht übersehen werden können. Ein mit einer bestimmten Version einer kryptografischen Bibliothek ausgeliefertes Firmware-Image aktualisiert sich nicht automatisch. Ein bei der Herstellung ausgestelltes Geräteidentitätszertifikat hat möglicherweise eine Gültigkeitsdauer von 10 Jahren und keinen automatischen Verlängerungsmechanismus. Die bei der Entwicklung des Geräts getroffenen kryptografischen Entscheidungen entsprechen unter Umständen nicht mehr den aktuellen Standards. Bei bereits im Einsatz befindlichen Geräten kann die Behebung der Probleme ein vollständiges Firmware-Update oder einen physischen Austausch erfordern.

Was inventarisiert werden sollte:

• Geräteidentitätszertifikate und die Vertrauensgrundlagen, die sie untermauern.
• Secure-Boot-Schlüssel und Firmware-Signaturzertifikate sind häufig betriebskritischer als TLS-Zertifikate auf demselben Gerät. Ein kompromittierter Firmware-Signaturschlüssel bedeutet kompromittierte Geräte in großem Umfang.
• Geräteattestierungsschlüssel, die in Remote-Attestierungs-Workflows verwendet werden.
• Private Schlüssel werden in spezieller Hardware wie TPMs und Secure Elements gespeichert.
• Langlebige Codesignaturschlüssel werden zur Authentifizierung von Firmware- und Software-Updates verwendet.
• Kryptografische Bibliotheken und Algorithmenkonfigurationen in Firmware-Images.

Diese Kategorie verdient im Kontext von PQC besondere Aufmerksamkeit aufgrund der Bedrohung durch „Ernte jetzt, entschlüssele später“ (HNDL). Gemäß diesem Bedrohungsmodell können Angreifer verschlüsselten Datenverkehr sammeln und speichern, in der Erwartung, dass zukünftige Fortschritte im Quantencomputing die Entschlüsselung von Daten ermöglichen, die durch aktuell eingesetzte Public-Key-Kryptografiealgorithmen geschützt sind.

Systeme und Geräte, die voraussichtlich viele Jahre im Einsatz bleiben, geben besonderen Anlass zur Sorge, da sie möglicherweise auch lange nach ihrer Inbetriebnahme noch auf quantenanfällige kryptografische Algorithmen angewiesen sind. Die Identifizierung solcher Anlagen mit langer Betriebsdauer und langfristigen Vertraulichkeitsanforderungen ist daher unerlässlich, um das zukünftige kryptografische Risiko zu bewerten und die Migrationsbemühungen im Bereich der Quantenverschlüsselung (PQC) zu priorisieren.

Schritt 4: Konsolidierung und Normalisierung der Bestandsdaten

Die Datenanalyse in drei Umgebungen erzeugt Daten in drei Formaten aus drei verschiedenen Toolsets. Die Rohdaten stellen kein Inventar dar, sondern dienen als Grundlage dafür. Erst im Normalisierungsschritt werden die verstreuten Datensätze so strukturiert, dass sie abfragefähig sind, Berichte erstellt und Maßnahmen ermöglicht werden können.

Die Normalisierung ist wichtig, da inkonsistente Daten selbst nach Abschluss der Erkennung zu blinden Flecken führen. Beispielsweise kann eine Quelle einen Algorithmus als „RSA-2048“ erfassen, während eine andere „RSA 2048“ oder einfach „2048“ aufzeichnet. Ohne Normalisierung könnten diese als unterschiedliche Assets behandelt werden. Ebenso kann dasselbe Zertifikat, das über verschiedene Scanpfade gefunden wurde, mehrfach im Inventar erscheinen, wenn Zertifikatsfingerabdrücke nicht konsistent erfasst werden.

Inkonsistente Namenskonventionen und Metadaten verschiedener Cloud-Anbieter und Managementplattformen können die Zuordnung von Eigentumsrechten und die Korrelation von Assets erschweren. Konkret bedeutet Normalisierung die Standardisierung der RSA-Schlüssellängen auf eine einheitliche Darstellung über alle Quellen hinweg, die Verwendung von Zertifikatsfingerabdrücken (SHA-256-Fingerabdrücken) als kanonischen Identifikator zur Deduplizierung und das Entfernen doppelter Asset-Datensätze.

Einige Faktoren, die dazu beitragen, dass Zentralisierung in der Praxis funktioniert:

• Einheitliche Metadaten: Jeder Anlagendatensatz sollte mindestens Anlagentyp, Algorithmus und Parameter, Ablaufdatum, zuständiges Team, Umgebung und zugehörigen Compliance-Bereich enthalten. Ohne Eigentümerdaten können die Ergebnisse nicht an die richtigen Personen zur Behebung weitergeleitet werden.
• Integration mit bestehenden Tools: Das Inventar sollte Daten aus und an CLM-Plattformen (Certificate Lifecycle Management), CMDB-Einträge (Configuration Management Database) und Sicherheitsworkflows senden und abrufen. Ein Inventar, das isoliert von den tatsächlich verwendeten Tools existiert, bleibt nicht aktuell.
• Einheitliche Datenquelle: Auch in Umgebungen, in denen lokale Vorschriften oder Architekturen föderierten Speicher erfordern, ist eine einheitliche Sicht auf oberster Ebene notwendig. Ein föderierter Ansatz ohne konsolidierte Transparenz ist zweckentfremdet.

Schritt 5: Anreicherung des Inventars mit Risiko- und Compliance-Kontext

Eine Liste von Vermögenswerten ist kein Inventar im eigentlichen Sinne. Das Inventar wird erst dann zu einem Entscheidungsinstrument, wenn jedem Vermögenswert ein Risikokontext zugeordnet wird. Die Risikoanalyse lässt sich in drei Dimensionen unterteilen. Jede Dimension deckt unterschiedliche Problemtypen auf und führt zu unterschiedlichen Lösungsansätzen.

Sicherheitsrisikokennzeichnungen kennzeichnen Assets mit direkter technischer Gefährdung: Zertifikate, deren Ablaufdatum bald erreicht ist und für die keine Automatisierung vorhanden ist, selbstsignierte Zertifikate in Produktionsumgebungen, in denen ein von einer Zertifizierungsstelle ausgestelltes Zertifikat erforderlich ist, veraltete oder für aktuelle Standards unzureichend verschlüsselte Algorithmen, Bibliotheken mit bekannten CVEs, schwache Schlüsselgenerierungspraktiken, nicht autorisierte Vertrauensanker, fehlender Hardwareschutz für Schlüssel, die sich in HSMs oder TPMs befinden sollten, und verwaiste Schlüssel ohne aktive Anwendungsabhängigkeit.

Bei der Kennzeichnung von Compliance-Risiken handelt es sich um Abweichungen von regulatorischen oder politischen Anforderungen: Algorithmen, die gemäß NIST IR 8547 zur Nichtzulassung vorgesehen sind; Zertifikate oder Schlüssel außerhalb genehmigter Schlüsselverwaltungsrichtlinien ; und Assets, die in den Geltungsbereich bestimmter Frameworks (PCI DSS, FedRAMP usw.) fallen und diese Anforderungen nicht erfüllen.

Das operationelle Risiko kennzeichnet Vermögenswerte, die wahrscheinlich zu Zwischenfällen führen werden: Zertifikate, die innerhalb von 30 Tagen ablaufen, Vermögenswerte ohne identifizierten Eigentümer und Systeme, für die es keinen automatisierten Prozess zur Erneuerung oder Rotation gibt.

Die Priorisierung sollte sich nach der geschäftlichen Kritikalität und der Datensensibilität richten, nicht allein nach der technischen Schwere. Ein schwacher Algorithmus auf einem Entwicklungsserver birgt ein anderes Risikoprofil als derselbe Algorithmus, der ein produktives Zahlungssystem schützt. Die Bestandsaufnahme sollte diese Unterscheidung berücksichtigen.

Schritt 6: Aufrechterhaltung der Bestandsgenauigkeit bei sich weiterentwickelnder Infrastruktur

Ein Inventar, das vor sechs Monaten korrekt war, ist kein aktuelles Inventar mehr. Es ist lediglich ein historischer Datensatz. Cloud-Umgebungen, CI/CD-Pipelines und Geräteflotten verändern sich ständig, und das Inventar muss Schritt halten.

In der Praxis bedeutet dies:

• Ereignisgesteuerte Erkennung, nicht nur geplante Scans. Cloud-Bereitstellungsereignisse, Benachrichtigungen zur KMS-Schlüsselerstellung, Git-Hooks bei Repository-Änderungen und Zertifikatslebenszyklusereignisse sollten allesamt Bestandsaktualisierungen auslösen. Neue Assets werden bei ihrer Bereitstellung erfasst, nicht erst beim nächsten geplanten Scan.
• Integration mit Ereignissen im Zertifikatslebenszyklus: Wenn ein Zertifikat erneuert, widerrufen oder ersetzt wird, sollte der Inventardatensatz automatisch aktualisiert werden.
• Überwachung externer Änderungen, die sich auf bestehende Assets auswirken: neue CVEs gegen Bibliotheken im Inventar, Aktualisierungen der Algorithmus-Richtlinien, CA-Disrust-Ereignisse und Änderungen der Compliance-Anforderungen.
• Regelmäßige Überprüfungen sollten als Teil des Sicherheitsbetriebs und nicht nur zur Erfüllung von Compliance-Vorgaben erfolgen. Das Inventar ist besonders wertvoll, wenn Teams es regelmäßig konsultieren, nicht nur im Vorfeld eines Audits.

Der Zustand des Inventars selbst sollte messbar sein. Nützliche KPIs sind beispielsweise der Anteil der gefundenen Assets mit bestätigten Eigentümern, der Anteil der Umgebung, der durch aktive Erkennung abgedeckt ist, die Anzahl der Zertifikate, die innerhalb von 30, 60 oder 90 Tagen ablaufen, und der Anteil der Assets, die veraltete Algorithmen verwenden. Diese Kennzahlen geben Ihnen ein konkretes Signal dafür, ob sich der Zustand des Inventars verbessert oder verschlechtert.

Häufige zu vermeidende Fehler

Das Durchlaufen aller sechs Schritte bedeutet nicht, dass die Arbeit getan ist. Es bedeutet, dass Sie die Grundlage geschaffen haben. Der Nutzen wächst mit der Zeit: Je länger die Bestandsführung läuft, desto genauer werden die Eigentumsdaten, desto zuverlässiger kann die Automatisierung darauf reagieren und desto besser ist das Unternehmen gerüstet, wenn die nächste Algorithmusabschaffung, das nächste Misstrauensereignis in Kalifornien oder die nächste Compliance-Frist ansteht. Allerdings tappen selbst gut gemeinte Bestandsführungsbemühungen in vorhersehbare Fallen. Hier sind die häufigsten Fehler, die Sie beim Aufbau und der Pflege Ihrer Bestandsführung vermeiden sollten.

1. Sich nur auf Zertifikate zu konzentrieren, ist nicht ausreichend. Zertifikate stellen zwar die sichtbarste Ebene dar, doch auch Schlüssel, Algorithmen, kryptografische Bibliotheken, Cloud-KMS-Ressourcen und andere Assets bergen reale Risiken. Eine Bestandsaufnahme, die sich ausschließlich auf Zertifikate beschränkt, liefert daher nur ein unvollständiges Bild.
2. Fehlende Abhängigkeitszuordnung. Es genügt nicht, nur zu wissen, dass ein Zertifikat existiert; man muss wissen, welche Anwendungen und Dienste davon abhängen. Ohne diese Abhängigkeitsdaten lässt sich das Ausmaß eines Fehlers weder abschätzen noch die Behebung zwischen den beteiligten Teams koordinieren.
3. Alle Ergebnisse werden als gleich dringlich behandelt. Ohne Daten zur Kritikalität von Anlagen erscheinen alle markierten Elemente gleich. Dies führt zu einer Überlastung durch Warnmeldungen und dazu, dass kritische Probleme ohne Priorität angegangen werden. Für eine Priorisierung ist ein Berücksichtigung der geschäftlichen Kritikalität erforderlich.
4. Ausgenommen sind Cloud-Umgebungen, CI/CD-Pipelines und Endgeräte. Diese gehören heute zur Kerninfrastruktur. Lücken in diesem Bereich sind keine Sonderfälle, sondern betreffen die Bereiche, in denen sich die meisten unkontrollierten Assets befinden.
5. Die Erkennung sollte nicht als einmalige oder periodische Maßnahme durchgeführt werden. Die Infrastruktur ändert sich jedoch auch zwischen den Scans ständig. Nur eine kontinuierliche Erkennung kann mit diesen Veränderungen Schritt halten.
6. Sich auf manuelle Nachverfolgung zu verlassen, ist problematisch. Tabellenkalkulationen veralten schnell. In dynamischen Umgebungen veralten sie besonders schnell.
7. Die Führung von Aufzeichnungen ohne Eigentümerdaten ist problematisch. Die Identifizierung eines Assets ist nur der erste Schritt. Für die Sanierung ist ein verantwortliches Team für jedes Asset erforderlich.
8. Die CBOM-Daten werden getrennt vom Laufzeitinventar verwaltet. CBOM gibt Auskunft über die in einer Anwendung integrierten kryptografischen Funktionen. Das Laufzeitinventar zeigt an, welche Funktionen tatsächlich in der Produktion verwendet werden. Sie benötigen beides.

Diese Fehler haben eines gemeinsam: Sie behandeln den Lagerbestand als einmalige Leistung und nicht als ein dynamisches, operatives System. Die richtige Grundlage von Anfang an zu schaffen, entscheidet darüber, ob ein Lagerbestand dauerhaft nützlich bleibt oder innerhalb weniger Monate veraltet.

Ein praktischer Ausgangspunkt

Wenn Ihre Organisation bei der Erfassung kryptografischer Daten ganz von vorn beginnt, ist der erste praktische Schritt die Festlegung des Umfangs. Definieren Sie die Grenzen: Welche Umgebungen sind für die erste Erfassung relevant, welche Teams müssen einbezogen werden und wie sieht ein vollständiges Inventar für Phase eins aus?

Ein schrittweises Vorgehen macht dies machbar:

• Phase 1 – Kritische Dienste: Beginnen Sie mit den Assets, bei denen das Risiko eines Ablaufs oder einer Fehlkonfiguration am höchsten ist. Internetseitige HTTPS-Endpunkte, VPN-Gateways und API-Gateways sind in der Regel der richtige Ausgangspunkt; hier führt ein kryptografischer Fehler zu einem sofortigen Vorfall. Interne Dienste der Authentifizierungsinfrastruktur (LDAP über TLS, RADIUS, AD CS OCSP/CRL-Dienste) und alle Dienste, die an Zero-Trust-Netzwerkzugriffsrichtlinien teilnehmen, gehören ebenfalls hierher.
• Phase 2 – CI/CD: Integrieren Sie die CBOM-Generierung in Ihre Build-Pipelines und das Scannen von Geheimnissen in Ihre Pre-Commit- und PR-Workflows. Dadurch schließen Sie die Lücke in der Transparenz Ihrer Software-Lieferkette, bevor Sie expandieren.
• Phase 3 – Cloud: Erweiterung auf Cloud-Umgebungen mittels API-basierter Erkennung, die sowohl Zertifikatsspeicher als auch KMS-Ressourcen anbieterübergreifend abdeckt.
• Phase 4 – Geräte: Geräte- und OT-Umgebungen können mittels passiver Netzwerküberwachung und Firmware-Analyse weiterverfolgt werden, wobei die Priorisierung nach Betriebsdauer und Datensensibilität erfolgt.

Die Bestandsaufnahme ist kein Projekt mit einem festgelegten Fertigstellungstermin, sondern eine operative Infrastruktur. Nach ihrer Erstellung muss sie gepflegt, bei Bedarf um neue Umgebungen erweitert und mit den Behebungsworkflows verknüpft werden, die die Daten nutzbar machen. Organisationen, die dies erfolgreich umsetzen, behandeln kryptografische Transparenz genauso wie Schwachstellenmanagement: als kontinuierliche operative Disziplin und nicht als periodische Prüfung.

Wie Verschlüsselungsberatung helfen kann

Für die meisten Organisationen ist der Aufbau eines vollständigen kryptografischen Inventars und die Migration zu Post-Quanten-Kryptografie mit den vorhandenen Tools und internen Kapazitäten allein nicht möglich. Encryption Consulting begleitet Unternehmen in jeder Phase dieses Prozesses – von der ersten Bedarfsanalyse bis zur vollständigen PQC-Migration – mit Dienstleistungen und speziell entwickelten Tools, die auf die Komplexität realer PKI-Umgebungen in Unternehmen zugeschnitten sind.

PQC-Beratungsdienste

Das erhalten Sie von unserem strukturierten Beratungsangebot:

• Ein kryptografisches Asset-Register, das durch systematische Ermittlung Ihrer Endpunkte, Anwendungen, APIs und Infrastruktur erstellt wird. Dies ist die Grundlage, die jeden nachfolgenden Schritt ermöglicht.
• Ein Risikobewertungsbericht, der Ihr Risiko gegenüber Quantenbedrohungen, identifizieren RSA und ECC-abhängige Systeme sowie die Bereitstellung priorisierter Ergebnisse mit Risikoschweregradbewertungen nach Kategorie: Sicherheit, Compliance und Betrieb.
• Ein PQC-Migrationsfahrplan, ein phasenweiser Plan, der auf Ihre Risikobereitschaft, regulatorische Anforderungen und NIST-Zeitpläne abgestimmt ist, einschließlich kryptografischer Agilität, damit sich Ihre Systeme an die Weiterentwicklung der Standards anpassen können.
• Unterstützung bei der Anbieterbewertung und Pilotprojekten, damit Sie die richtigen Tools auswählen, Machbarkeitsstudien durchführen und die Interoperabilität vor einer flächendeckenden Einführung validieren können.
• Vollständige Implementierung, einschließlich der Bereitstellung hybrider klassischer und quantensicherer Modelle, der Einführung von PQC in Ihrer PKI und Infrastruktur sowie der Einrichtung des Monitorings für die langfristige kryptografische Integrität.

CBOM Secure

Ein wichtiger Hinweis: CBOM Secure ist nicht dasselbe wie ein CBOM. Ein CBOM (Cryptographic Bill of Materials) ist ein strukturiertes Artefakt, eine Aufzeichnung der kryptografischen Komponenten einer Anwendung oder eines Systems. CBOM Secure generiert und verarbeitet CBOM-Daten und führt darüber hinaus eine kontinuierliche Erkennung und Laufzeit-Inventarverwaltung in der gesamten Unternehmensumgebung durch. Diese Unterscheidung ist wichtig, da ein CBOM allein Auskunft darüber gibt, welche Komponenten zu einem bestimmten Zeitpunkt in eine Anwendung integriert waren. CBOM Secure hingegen zeigt an, welche Komponenten aktuell ausgeführt werden, wo sie ausgeführt werden und wie sie sich verändern.

Ein erfolgreicher Übergang zur Post-Quanten-Technologie beginnt mit Transparenz. Unternehmen können ihre Kryptografie nicht modernisieren, wenn sie nicht wissen, wo Zertifikate, Schlüssel, Algorithmen und kryptografische Abhängigkeiten in ihrer Umgebung zu finden sind.

CBOM Secure von Encryption Consulting bietet einen kontinuierlichen Überblick über kryptografische Ressourcen in der gesamten Unternehmensinfrastruktur, Cloud-Umgebungen, Anwendungen und kryptografischen Diensten. Anstatt eine Momentaufnahme zu erstellen, hilft es Unternehmen zu verstehen, wie Kryptografie eingesetzt wird, wo sie implementiert ist und wie sie sich im Laufe der Zeit verändert.

CBOM Secure erkennt und verfolgt kontinuierlich Zertifikate, Schlüssel, Algorithmen und kryptografische Abhängigkeiten im gesamten Unternehmen. Es bietet Einblick in die Eigentümerschaft von Assets, Zertifikats- und Schlüsselbeziehungen, die Algorithmusnutzung, Lebenszyklusereignisse und kryptografische Risiken und unterstützt Teams so bei der Identifizierung nicht verwalteter Assets, veralteter Algorithmen und Systeme, die möglicherweise modernisiert werden müssen.

Die Plattform unterstützt zudem eine richtlinienbasierte Governance, indem sie kryptografische Konfigurationen anhand von Organisationsstandards validiert und Abweichungen hervorhebt, bevor diese zu Betriebs- oder Compliance-Risiken werden.

Für Organisationen, die sich auf die Post-Quanten-Kryptographie vorbereiten , identifiziert CBOM Secure Systeme, die auf quantenanfälligen Algorithmen basieren, und bietet die notwendige Transparenz, um Abhilfemaßnahmen und Migrationsaktivitäten zu priorisieren.

Ob Ihr Unternehmen ganz von vorn beginnt und noch kein formales Inventar geführt hat oder eine bestehende Analyse in ein kontinuierliches Governance-Programm überführen möchte – Encryption Consulting bietet Ihnen sowohl umfassende Beratungskompetenz als auch die nötige Plattform, um Sie voranzubringen. Um mehr über unsere PQC-Beratungsleistungen oder CBOM Secure zu erfahren, besuchen Sie encryptionconsulting.com oder kontaktieren Sie unser Team direkt.

Fazit

Ein kryptografisches Inventar ist keine bloße Pflichterfüllung oder ein einmaliges Auditergebnis. Es bildet die operative Grundlage für das Zertifikatslebenszyklusmanagement , die Migration von Algorithmen und die Planung der Quanten-Bereitschaft. Die drei hier behandelten Umgebungen – Cloud-Infrastruktur, CI/CD-Pipelines und vernetzte Geräte – bieten den meisten Unternehmen derzeit die geringste Transparenz und haben daher die gravierendsten Folgen.

Organisationen können Kryptografie, die sie nicht einsehen können, weder automatisieren noch beheben oder migrieren. Der Ausgangspunkt ist unabhängig von der Umgebung derselbe: Man muss wissen, was man hat, wo es gespeichert ist und dieses Wissen stets aktuell halten. Quantenbereitschaft beginnt mit kryptografischer Transparenz. Alles Weitere ergibt sich daraus.

Häufig gestellte Fragen

Worin besteht der Unterschied zwischen CBOM und kryptografischer Laufzeiterkennung?

Eine CBOM (Cryptographic Bill of Materials) erfasst die in ein Softwareartefakt integrierten kryptografischen Funktionen basierend auf der Build-Zeit oder statischer Analyse. Die Laufzeiterkennung verfolgt, was tatsächlich in Ihrer Umgebung bereitgestellt und ausgeführt wird. Sie benötigen beides: Die CBOM zeigt Ihnen, was integriert wurde, und die Laufzeiterkennung zeigt Ihnen, was aktiv ist.

Warum kann eine Tabellenkalkulation nicht als kryptografisches Inventar dienen?

Umgebungen, die sich durch neue Bereitstellungen, Konfigurationsaktualisierungen, Cloud-Provisionierung und Software-Releases ständig verändern, überholen jede manuell gepflegte Liste innerhalb weniger Wochen. Um weiterhin nützlich zu sein, muss das Inventar kontinuierlich und automatisiert sein, mit ereignisgesteuerter Erkennung, die durch Bereitstellungsereignisse, Git-Hooks und Änderungen im Zertifikatslebenszyklus ausgelöst wird.

Mit welcher Umgebung sollten Organisationen beim Aufbau eines Inventars beginnen?

Beginnen Sie mit kritischen Diensten: HTTPS-Endpunkte mit Internetzugang, VPN-Gateways und API-Gateways, da ein kryptografischer Fehler dort einen sofortigen Vorfall verursacht. Erweitern Sie die Sicherheitsmaßnahmen anschließend auf CI/CD-Pipelines, Cloud-Umgebungen und schließlich auf Endgeräte und OT-Systeme, priorisiert nach Betriebsdauer und Datensensibilität.

Warum stellen CI/CD-Pipelines eine erhebliche kryptografische Schwachstelle dar?

Kryptografisches Material, das während des Build-Prozesses in Anwendungen integriert wird – fest codierte Schlüssel, eingebettete Zertifikate, Codesignaturschlüssel – wird bei Zertifikatsscans auf Netzwerkebene nicht angezeigt. Kompromittierte Build-Pipelines wurden zudem genutzt, um Schadcode in signierte Artefakte einzuschleusen, denen nachgelagerte Nutzer implizit vertrauen. Dies stellt sowohl eine Sicherheitslücke als auch eine aktive Angriffsfläche dar.

Warum bergen langlebige Geräte ein besonderes kryptografisches Risiko?

Geräte, die über Jahre oder Jahrzehnte im Einsatz sind, häufen kryptografische Schulden an: Die Firmware wird mit einer festen Bibliotheksversion ausgeliefert, Geräteidentitätszertifikate haben möglicherweise eine Gültigkeit von 10 Jahren ohne automatische Verlängerung, und die Behebung kann ein vollständiges Firmware-Update oder einen physischen Austausch erfordern. In Verbindung mit dem Risiko, Daten erst später zu sammeln und zu entschlüsseln, haben langlebige Geräte, die quantenanfällige Algorithmen verwenden, besondere Priorität bei der Planung der PQC-Migration.

Welche KPIs geben Aufschluss darüber, ob ein kryptografisches Inventar in einem guten Zustand ist?

Prozentsatz der gefundenen Assets mit bestätigten Eigentümern, Prozentsatz der Umgebung, die von der aktiven Erkennung abgedeckt wird, Anzahl der Zertifikate, die innerhalb von 30, 60 oder 90 Tagen ablaufen, und Prozentsatz der Assets, die veraltete Algorithmen verwenden. Diese Kennzahlen geben einen konkreten Hinweis darauf, ob sich der Bestand verbessert oder verschlechtert.