Was ist Krypto-Agilität?
Krypto-Agilität ist die Fähigkeit, kryptografische Algorithmen, Schlüssel, Zertifikate und Protokollparameter kontrolliert auszutauschen, während Sicherheit, Interoperabilität und Betrieb erhalten bleiben. Für Post-Quanten-Kryptografie bedeutet das: nicht sofort überall ML-KEM einzuschalten, sondern Abhängigkeiten sichtbar zu machen, Migrationspfade zu testen und Änderungen wiederholbar zu beherrschen.
Das konkrete Problem: Niemand sieht den vollständigen kryptografischen Pfad
Eine typische Security-Organisation kennt ihre öffentlichen Zertifikate und zentralen PKI-Systeme. Weniger sichtbar sind jedoch die kryptografischen Abhängigkeiten entlang eines vollständigen Datenwegs: Client, Browser oder Agent, lokaler Proxy, Zscaler Service Edge, TLS-Inspection, Zielanwendung, API-Gateway, Load Balancer, Anwendungskomponente und angebundene Partnerdienste.
Wird an einer Stelle ein Algorithmus oder eine Schlüssellänge verändert, kann das an einer anderen Stelle zu Inkompatibilität, fehlgeschlagener Inspektion oder nicht mehr erreichbaren Anwendungen führen. Besonders kritisch sind langlebige vertrauliche Daten, deren Schutzbedarf länger besteht als die erwartete Einsatzdauer heutiger Public-Key-Verfahren.
Ein Unternehmen möchte seine Zscaler- und TLS-Architektur „PQC-ready“ machen. Es besitzt aber weder ein vollständiges Inventar der TLS-Endpunkte noch eine Zuordnung von Datenklassen, Zertifikaten, Applikationsverantwortlichen und Fremdprodukten. Ein vorschneller Rollout würde deshalb technische Risiken verschieben, nicht beherrschen.
Was muss technisch erfasst werden?
1. Schutzbedarf und Lebensdauer
Welche Daten müssen über Jahre vertraulich bleiben? Welche Kommunikationswege könnten für „Harvest now, decrypt later“ relevant sein?
2. Kryptografische Endpunkte
Wo beginnen und enden TLS, Signaturen oder Schlüsselaustausch? Welche Proxies, Gateways, Appliances und Cloud-Dienste terminieren Verbindungen?
3. Verfahren und Abhängigkeiten
Welche Algorithmen, Zertifikatstypen, Libraries, Firmwarestände und Protokollversionen sind im Einsatz? Wer kontrolliert deren Aktualisierung?
4. Austausch- und Testfähigkeit
Lassen sich Verfahren konfigurierbar wechseln? Gibt es hybride Tests, Kompatibilitätsnachweise, Telemetrie und einen belastbaren Rückfallpfad?
Was bedeutet das für eine Zscaler-Umgebung?
Zscaler ist Teil des Verkehrs- und Kontrollpfads, aber nicht automatisch Eigentümer jeder kryptografischen Abhängigkeit. Für eine belastbare Readiness-Prüfung müssen mindestens folgende Bereiche getrennt betrachtet werden:
- TLS-Inspection: Welche Verbindungen werden entschlüsselt, welche Ausnahmen bestehen und welche Anwendungen reagieren empfindlich auf veränderte Handshakes oder Zertifikatsketten?
- Client- und Browser-Kompatibilität: Unterstützen Betriebssysteme, Browser, Client-Komponenten und Zielsysteme die vorgesehenen Verfahren und hybriden Übergänge?
- Private Anwendungen: Welche ZPA-Zugriffswege, App Connector, Server und internen PKI-Abhängigkeiten sind betroffen?
- Policy und Governance: Wer darf kryptografische Parameter ändern, wer prüft Ausnahmen und wie werden Entscheidung, Test und Rollback dokumentiert?
- Herstellerabhängigkeiten: Welche konkrete PQC-Unterstützung ist für Produkt, Version, Region und Tenant tatsächlich freigegeben?
Architekturhinweis: Der Reifegrad quantensicherer Funktionen unterscheidet sich je Produkt, Datenweg und Abhängigkeit. Deshalb verbinden wir aktuelle Herstellerinformationen mit einer Prüfung der konkreten Umgebung.
Wie SourcingBlox daraus ein umsetzbares Programm macht
Traffic Readiness Sprint
Datenklassen, kritische Verkehrswege, TLS-Endpunkte und verantwortliche Systeme erfassen. Ergebnis: priorisierte Untersuchungslandkarte statt unvollständiger Produktliste.
Policy & Compatibility Review
TLS-Inspection, Ausnahmen, Zertifikatsketten, Client- und Anwendungskompatibilität sowie betriebliche Abhängigkeiten kontrolliert prüfen.
Crypto-Agility Roadmap
Umstellungswellen, Tests, Verantwortlichkeiten, Herstellerabhängigkeiten, Messpunkte und Rückfalloptionen in eine belastbare Roadmap überführen.
Prüfliste für den ersten Workshop
- Welche Daten benötigen langfristige Vertraulichkeit oder Integrität?
- Welche externen und internen Verkehrswege transportieren diese Daten?
- Wo werden Verbindungen terminiert, entschlüsselt, erneut verschlüsselt oder signiert?
- Welche Zertifikate, Libraries, Appliances und SaaS-Dienste sind beteiligt?
- Welche Zscaler-Policies, Inspection-Ausnahmen und privaten Anwendungen sind betroffen?
- Welche Komponenten lassen sich unabhängig testen und kontrolliert zurücksetzen?
- Welche Nachweise und Herstellerzusagen fehlen noch?
Was Krypto-Agilität nicht automatisch löst
Krypto-Agilität ersetzt weder Schutzbedarfsanalyse noch PKI-Governance, Schlüsselmanagement, sichere Implementierung oder Herstellerprüfung. Auch ein standardisierter Algorithmus wie ML-KEM garantiert allein keine sichere Ende-zu-Ende-Architektur. Entscheidend ist, wie das Verfahren in Protokolle, Produkte und Betriebsprozesse integriert wird.
Häufige Fragen
Ist ML-KEM dasselbe wie Krypto-Agilität?
Nein. ML-KEM ist ein von NIST standardisierter Key-Encapsulation-Mechanismus. Krypto-Agilität beschreibt die organisatorischen und technischen Fähigkeiten, Verfahren wie ML-KEM kontrolliert einzuführen, auszutauschen und zu betreiben.
Müssen Unternehmen sofort ihre gesamte Kryptografie ersetzen?
Nein. Der sinnvolle erste Schritt ist ein risikobasiertes Inventar. Schutzbedarf, Datenlebensdauer, Exposition und technische Abhängigkeiten bestimmen die Reihenfolge.
Reicht es, auf Hersteller-Roadmaps zu warten?
Hersteller-Roadmaps sind eine wichtige Eingabe, ersetzen aber nicht das eigene Inventar. Unternehmen müssen wissen, welche Datenwege und Systeme von welcher Herstellerentscheidung abhängen.
Wo beginnt SourcingBlox?
Mit einem abgegrenzten Daten- und Verkehrsweg. Dieser wird technisch aufgenommen, gegen Policies und Produktabhängigkeiten geprüft und anschließend als Pilot- und Migrationspfad beschrieben.
PQC-Readiness für einen kritischen Datenweg bestimmen.
Wir beginnen nicht mit einer abstrakten Quantenstrategie, sondern mit einem repräsentativen Verkehrsweg, seinen TLS-Endpunkten, Policies und Abhängigkeiten.
Verwandte Inhalte
Technische Primärquellen
- NIST CSWP 39: Considerations for Achieving Crypto Agility
- NIST FIPS 203: ML-KEM
- NCCoE: Migration to Post-Quantum Cryptography
- BSI: Kryptografie quantensicher gestalten
Prüfdatum: 25. Juli 2026. Produktbezogene Aussagen müssen vor Veröffentlichung zusätzlich gegen die dann aktuelle Zscaler-Dokumentation geprüft werden.