Post-Quantum-Kryptografie im Unternehmen vorbereiten: Krypto-Inventar und TLS-Migration planen

Ein Lieferant kündigt ein neues VPN Gateway an, deine Entwicklungsabteilung plant ein API Gateway Upgrade und gleichzeitig läuft die Erneuerung mehrerer TLS Zertifikate. Genau in solchen Projekten entscheidet sich, ob Post Quantum Kryptografie später kontrolliert eingeführt werden kann oder ob sie zur hektischen Sonderaufgabe wird. Die wichtigste Vorbereitung ist nicht der sofortige Austausch aller Verfahren. Du brauchst zuerst einen belastbaren Überblick darüber, wo Kryptografie eingesetzt wird, welche Systeme voneinander abhängen und welche Daten besonders lange vertraulich bleiben müssen.

Post Quantum Kryptografie, oft auch PQC genannt, bezeichnet kryptografische Verfahren, die auch gegen leistungsfähige Quantencomputer widerstandsfähig sein sollen. Das betrifft besonders Verfahren für den Schlüsselaustausch und digitale Signaturen. Heutige TLS Verbindungen, VPNs, Zertifikate und viele interne Vertrauensbeziehungen beruhen noch auf klassischen Public Key Verfahren. Diese gelten gegen heutige Angreifer als sicher, könnten aber durch einen ausreichend leistungsfähigen Quantencomputer angreifbar werden.

Für Unternehmen ist vor allem ein Szenario relevant: Angreifer können verschlüsselte Daten heute abgreifen, speichern und erst später entschlüsseln. Dieses Risiko wird häufig als „Harvest now, decrypt later“ beschrieben. Es betrifft nicht jede Information gleich stark. Es ist jedoch relevant, wenn Vertraulichkeit über viele Jahre erhalten bleiben muss.

Infografik zu Post-Quantum-Kryptografie im Unternehmen vorbereiten: Krypto-Inventar und TLS-Migration planen (KI-generiert).

Nicht mit einem Algorithmusprojekt beginnen

Eine Umstellung auf quantensichere Verfahren ist kein reines Kryptografieprojekt. Sie berührt Netzwerke, Identitätsmanagement, Anwendungen, Lieferanten, Endgeräte und Betriebsprozesse. Wenn du nur prüfst, ob ein Webserver eine neue TLS Cipher Suite unterstützt, übersiehst du meist die schwierigen Teile: alte Appliances, fest verdrahtete Zertifikatspfade, nicht dokumentierte Schnittstellen oder externe Partner, die nur bestimmte Protokolle akzeptieren.

Starte deshalb mit drei Fragen:

• Welche Systeme nutzen asymmetrische Kryptografie für Verschlüsselung, Schlüsselaustausch, Signaturen oder Zertifikate?
• Welche Informationen müssen länger vertraulich bleiben als die erwartete Nutzungsdauer der eingesetzten Systeme?
• Welche Komponenten kannst du selbst ändern, und bei welchen bist du von Herstellern, Cloud Anbietern oder Geschäftspartnern abhängig?

Diese Fragen verbinden technische Bestandsaufnahme und Risikobewertung. Sie verhindern auch, dass Teams eine Migration nach dem Gießkannenprinzip planen. Nicht jedes interne Testsystem hat dieselbe Priorität wie ein Kundenportal, eine Produktions VPN Verbindung oder eine Schnittstelle zu einem regulierten Partner.

Das Krypto Inventar sinnvoll aufbauen

Ein Krypto Inventar ist mehr als eine Liste von TLS Zertifikaten. Es dokumentiert, an welchen Stellen kryptografische Verfahren genutzt werden, wofür sie dienen und wer Änderungen verantwortet. Du kannst mit einer einfachen Tabelle beginnen, solange sie regelmäßig gepflegt wird und klare Verantwortlichkeiten enthält.

Erfasse pro Eintrag mindestens diese Informationen:

Feld	Wofür du es brauchst
System und Dienst	Eindeutige Zuordnung, etwa Webportal, VPN, API oder Verzeichnisdienst
Eigentümer	Zuständigkeit für Entscheidung, Test und Umsetzung
Datenklasse	Einschätzung, ob Daten kurzzeitig, mittel- oder langfristig vertraulich bleiben müssen
Protokoll	Beispielsweise TLS, IPsec, SSH, S/MIME oder proprietäres Protokoll
Kryptografische Funktion	Schlüsselaustausch, Serverauthentisierung, Signatur, Verschlüsselung oder Integritätsschutz
Zertifikate und Schlüssel	Aussteller, Laufzeit, Algorithmus, Schlüssellänge, Speicherort und Erneuerungsweg
Abhängigkeiten	Load Balancer, Web Application Firewall, Proxy, Client Bibliothek, HSM oder Partnerzugang
Migrationsfähigkeit	Unterstützt, geplant, unbekannt oder voraussichtlich nicht unterstützbar
Risiko und Priorität	Geschäftsauswirkung, Angriffsfläche und Schutzdauer der Daten

Für TLS solltest du nicht nur den öffentlich erreichbaren Webserver inventarisieren. Prüfe auch interne TLS Verbindungen zwischen Microservices, Datenbanken, Message Brokern, Monitoring Komponenten und Verwaltungsoberflächen. Gerade intern werden Zertifikate häufig manuell verteilt, lange genutzt oder ohne zentrale Überwachung erneuert.

Die Inventarisierung passt gut zu einem allgemeinen Asset und Angriffspfad Management. Wie du Protokolle und Auffälligkeiten für den Betrieb nutzbar machst, erläutern wir auch in unserem Beitrag Angriffe früh erkennen: Logging und Monitoring. Für die PQC Vorbereitung gilt ähnlich: Was nicht sichtbar ist, lässt sich nicht gezielt absichern oder migrieren.

Langfristig schützenswerte Daten priorisieren

Nicht jede verschlüsselte Verbindung ist gleich dringlich. Entscheidend ist, wie lange die übertragenen oder gespeicherten Daten ihren Schutzwert behalten. Eine Statusabfrage eines öffentlichen Dienstes ist anders zu bewerten als Forschungsunterlagen, personenbezogene Daten, Vertragsdaten, Zugangsdaten oder strategische Planungen.

Ordne Daten deshalb nach ihrer erforderlichen Vertraulichkeitsdauer:

• Kurzfristig: Informationen, die nach Wochen oder Monaten kaum noch sensibel sind.
• Mittelfristig: Geschäftsdaten, Supportfälle oder Projektdaten mit mehrjährigem Schutzbedarf.
• Langfristig: Gesundheitsdaten, Identitätsdaten, Entwicklungsunterlagen, Schlüsselmaterial, vertrauliche Verträge und Daten mit gesetzlichen oder vertraglichen Aufbewahrungsfristen.
• Besonders kritisch: Daten, deren Offenlegung auch nach vielen Jahren erheblichen Schaden verursachen kann, etwa Betriebsgeheimnisse oder Sicherheitsarchitekturen.

Berücksichtige dabei auch verschlüsselte Backups und Archivdaten. Post Quantum Risiken entstehen nicht nur bei Datenübertragung. Wenn Schlüsselmaterial, verschlüsselte Archive oder signierte Dokumente lange gültig bleiben sollen, gehören sie in die Planung.

Eine belastbare Priorisierung braucht außerdem eine fachliche Risikobewertung. Der Beitrag Schwachstellen bewerten und priorisieren zeigt, warum technische Schwere allein nicht genügt. Für PQC gilt das besonders: Die Dringlichkeit ergibt sich aus Schutzdauer, Exponiertheit und Abhängigkeiten, nicht allein aus dem verwendeten Verfahren.

Hybride TLS Verfahren realistisch einplanen

Bei einer TLS Migration wird häufig von „quantensicheren Zertifikaten“ gesprochen. Technisch solltest du genauer unterscheiden. TLS schützt verschiedene Vorgänge: den Aufbau eines gemeinsamen Sitzungsschlüssels, die Authentisierung des Servers und gegebenenfalls des Clients sowie die Verschlüsselung der laufenden Verbindung. Diese Bausteine können sich in unterschiedlichen Geschwindigkeiten weiterentwickeln.

Hybride TLS Verfahren kombinieren typischerweise einen klassischen Schlüsselaustausch mit einem postquantensicheren Verfahren. Die Verbindung soll damit nur dann kompromittierbar sein, wenn beide Bestandteile gebrochen werden. Das ist für die Übergangsphase attraktiv, weil klassische Sicherheit und quantensichere Vorsorge parallel berücksichtigt werden.

Für deine Planung bedeutet das:

• Prüfe, welche TLS Bibliotheken, Reverse Proxys, Load Balancer und Browser in deiner Umgebung hybride Gruppen unterstützen.
• Plane Tests für externe Clients, mobile Anwendungen, automatisierte Schnittstellen und ältere Betriebssysteme.
• Miss mögliche Auswirkungen auf Verbindungsaufbau, Paketgrößen, MTU Probleme und Last auf besonders ausgelasteten Endpunkten.
• Trenne Tests für den Schlüsselaustausch von Tests für Zertifikate und Signaturketten.
• Halte einen getesteten Rückfallweg bereit, falls einzelne Partner oder Altgeräte hybride Verfahren nicht verarbeiten können.

Vermeide den Fehler, TLS Einstellungen global ohne abgestimmten Kompatibilitätstest zu ändern. Ein API Client in einer alten Java Laufzeitumgebung, eine Appliance mit fest eingebauter TLS Bibliothek oder ein industrielles Gerät kann schon an geänderten Aushandlungsparametern scheitern. Genau solche Schnittstellen gehören früh in ein Pilotprojekt.

Sichere Schnittstellen brauchen ohnehin mehr als starke Transportverschlüsselung. Autorisierung, Datenvalidierung und Fehlermanagement bleiben entscheidend. Lies dazu auch unseren Beitrag BOLA und IDOR in REST-APIs erkennen und verhindern: Autorisierung richtig testen.

Zertifikate, VPNs und Legacy Systeme getrennt betrachten

Zertifikate sind ein guter Einstieg, aber kein vollständiges Krypto Inventar. Dokumentiere bei jeder Zertifikatskette, welche Zertifizierungsstelle sie ausstellt, wie die Erneuerung läuft, ob Client Zertifikate verwendet werden und welche Anwendungen die Kette prüfen. Automatisierte Erneuerung reduziert Betriebsrisiken, löst aber keine Kompatibilitätsprobleme bei neuen Algorithmen.

Bei VPNs musst du zusätzlich die Gegenstellen betrachten. Bei Standortkopplungen gehören Router, Firewalls, Carrier Netze und externe Partner in die Analyse. Bei Remote Access VPNs musst du Clients auf verwalteten und nicht verwalteten Geräten unterscheiden. Prüfe, ob dein Anbieter eine PQC Roadmap veröffentlicht hat, welche Softwarestände erforderlich sind und ob hybride Verfahren für deinen konkreten VPN Modus vorgesehen sind.

Legacy Systeme benötigen eine eigene Strategie. Wenn ein System keine modernen Kryptoverfahren unterstützt, gibt es nicht automatisch eine schnelle technische Lösung. Mögliche Maßnahmen sind Netzwerksegmentierung, vorgeschaltete Gateways, streng begrenzte Zugriffe, zusätzliche Überwachung und ein verbindlicher Ablöseplan. Solche Kompensationsmaßnahmen sind kein Ersatz für Modernisierung, können aber Risiken während einer Übergangszeit reduzieren. Die Grundlagen dafür findest du in unserem Beitrag Netzwerksicherheit: Grundlagen für den Schutz.

Lieferanten verbindlich einbeziehen

Viele kritische Kryptografieabhängigkeiten liegen außerhalb deiner direkten Kontrolle. Frage Hersteller und Dienstleister deshalb nicht nur pauschal nach „Quantum Readiness“. Bitte um konkrete Informationen:

• Welche Produkte und Versionen unterstützen hybride TLS oder andere PQC Übergangsverfahren?
• Welche Algorithmen und Protokolle sind vorgesehen?
• Welche Einschränkungen, Leistungsfolgen und bekannten Inkompatibilitäten bestehen?
• Wann sind Unterstützung, Updates und Sicherheitswartung geplant?
• Wie lassen sich Verfahren konfigurieren, überwachen und bei Problemen zurücknehmen?
• Betrifft die Roadmap auch Managementschnittstellen, Agenten, APIs und mobile Clients?

Halte Antworten im Krypto Inventar fest. Aussagen wie „zukünftig geplant“ reichen für kritische Dienste nicht aus. Du brauchst Versionsbezug, Verantwortlichkeiten und eine realistische Terminplanung für Tests. Berücksichtige auch Vertragslaufzeiten: Ein zentraler Dienstleisterwechsel kann langsamer sein als ein technisches Upgrade.

Ein praxistauglicher 90 Tage Plan

Du musst nicht auf vollständige Standardisierung oder eine einzige Herstellerlösung warten. In den nächsten 90 Tagen kannst du eine belastbare Grundlage schaffen:

• Benenne eine fachübergreifende Verantwortung aus Infrastruktur, Entwicklung, Security und Einkauf.
• Erfasse zuerst öffentlich erreichbare Dienste, VPNs, zentrale APIs, Identitätsdienste und Zertifikatsstellen.
• Bewerte Daten nach Schutzdauer und ordne besonders schützenswerte Verbindungen einer hohen Priorität zu.
• Frage bei kritischen Herstellern die konkrete PQC und Hybrid Roadmap ab.
• Wähle einen abgegrenzten TLS Pilot mit überschaubaren Clients und guter Beobachtbarkeit.
• Teste Kompatibilität, Performance, Monitoring und Rückfallverfahren.
• Ergänze Beschaffungsanforderungen um kryptografische Agilität, dokumentierte Roadmaps und unterstützte Updatewege.
• Aktualisiere das Inventar nach jedem Architekturwechsel, Zertifikatswechsel und Lieferantenwechsel.

Ein kontrollierter Pilot schafft Erkenntnisse, ohne die Produktionslandschaft unnötig zu gefährden. Falls dabei Schwachstellen oder unerwartete Vertrauensbeziehungen sichtbar werden, solltest du sie nachvollziehbar dokumentieren und nachhalten. Wie aus technischen Befunden konkrete Maßnahmen werden, erklären wir in Einen Pentest Bericht lesen und umsetzen.

Post Quantum Kryptografie ist damit kein isoliertes Zukunftsthema. Sie ist ein Anlass, Kryptografie, Zertifikate und Abhängigkeiten endlich als steuerbaren Teil deiner IT Architektur zu behandeln. Passende Seminare und Termine findest du bei uns auf cmt.de.