Post-Quantum Cryptography wird häufig als Austausch einzelner Algorithmen dargestellt. Für eine produktive Security-Umgebung ist die Aufgabe größer: Anwendungen, Clients, TLS-Bibliotheken, Zertifikate, Proxies und Inspektionspunkte müssen dieselbe Veränderung vertragen.
NIST hat 2024 die ersten Standards für Post-Quantum Cryptography veröffentlicht. ML-KEM ist dabei ein standardisierter Mechanismus zur Schlüsselvereinbarung. Daraus folgt jedoch nicht, dass jede vorhandene Verbindung sofort und ohne Nebenwirkungen umgestellt werden kann.
Für Unternehmen mit Zscaler-Umgebungen ist deshalb eine Traffic- und Compatibility-Prüfung der pragmatische Startpunkt.
Warum TLS-Inspektion Teil der PQC-Frage ist
Bei TLS-Inspektion endet eine verschlüsselte Verbindung am Inspektionsdienst und wird anschließend neu aufgebaut. Der Inspektionspunkt muss Protokolle und Verfahren auf beiden Seiten unterstützen. Gleichzeitig beeinflussen Zertifikate, Anwendungen und Ausnahmeregeln, welche Verbindungen tatsächlich geprüft werden.
Eine PQC-Roadmap muss daher nicht nur Server und Browser betrachten. Sie muss den gesamten Datenweg abbilden:
- Client und verwendete Kryptobibliothek,
- Zscaler Client Connector oder anderer Weiterleitungspfad,
- ZIA- beziehungsweise SSE-Inspektionspunkt,
- Zielanwendung und deren Frontend,
- Zertifikatskette und Trust Store,
- bestehende Ausnahmen und Bypass-Regeln,
- private Anwendungen und ZPA-Pfade,
- Monitoring und Fehlerdiagnose.
Schritt 1: Kryptografisch relevante Wege inventarisieren
Eine vollständige Inventur jedes Systems ist selten der beste erste Schritt. Sinnvoller ist ein priorisiertes Inventar aus Datenwert, Aufbewahrungsdauer und Exposition.
Besondere Aufmerksamkeit verdienen Daten, die heute abgegriffen und später entschlüsselt werden könnten, sowie geschäftskritische Verbindungen mit langer technischer Lebensdauer. Dazu gehören je nach Organisation Verwaltungsprozesse, geistiges Eigentum, Identitätsdaten, Maschinenkommunikation oder langfristig sensible Kundendaten.
Für jeden priorisierten Weg wird dokumentiert, welche TLS-Version, welche Gegenstellen und welche Inspektions- oder Proxy-Komponenten beteiligt sind. Unbekannte Werte werden nicht geschätzt, sondern als Prüfschritt erfasst.
Schritt 2: Sichtbarkeit und tatsächliche Nutzung trennen
Herstellerberichte und Telemetrie können sichtbar machen, wo PQC-Verfahren beobachtet werden. Zscaler dokumentiert dafür unter anderem einen Post-Quantum-Cryptography-Visibility-Report.
Sichtbarkeit beantwortet jedoch noch nicht alle Fragen. Ein beobachteter Handshake bedeutet nicht automatisch, dass die gesamte Anwendungskette kompatibel ist. Umgekehrt kann eine nicht sichtbare Verbindung ausgenommen, anders geroutet oder außerhalb des betrachteten Pfads liegen.
Deshalb werden Berichtsdaten mit Policy, SSL-Inspektionsregeln, Ausnahmen und repräsentativen Verbindungstests abgeglichen.
Schritt 3: Kompatibilität kontrolliert testen
Ein Testplan sollte positive und negative Fälle enthalten:
- unterstützter Client zu unterstützter Anwendung,
- Verbindung mit aktiver TLS-Inspektion,
- begründete Ausnahme ohne Inspektion,
- ältere Client- oder Serverkomponente,
- Zertifikatsfehler,
- Fallback-Verhalten,
- private Anwendung über ZPA,
- Diagnose im Service- und Security-Prozess.
Dabei geht es nicht darum, möglichst schnell überall PQC zu aktivieren. Ziel ist zu erkennen, an welchen Punkten Unterstützung, Konfiguration oder Austausch erforderlich ist.
Schritt 4: Policy und Ausnahmebestand bereinigen
Gewachsene SSL-Inspection-Ausnahmen erschweren jede Krypto-Migration. Eine Ausnahme ohne Owner, Grund und Review-Datum ist nicht nur ein Sicherheitsrisiko, sondern auch ein blinder Fleck für die Readiness-Bewertung.
Vor einer größeren Umstellung sollten Ausnahmen klassifiziert werden:
- technisch zwingend,
- geschäftlich begründet,
- nur historisch vorhanden,
- derzeit ungeklärt.
Für ungeklärte Fälle werden Anwendungseigner, Datenweg und Kompatibilität in einem kontrollierten Test verifiziert.
Schritt 5: Crypto-Agility als Betriebsfähigkeit etablieren
Crypto-Agility bedeutet nicht, Algorithmen beliebig umzuschalten. Sie beschreibt die Fähigkeit, eingesetzte Verfahren zu kennen, Auswirkungen zu bewerten, Änderungen kontrolliert auszurollen und Rückfälle zu beherrschen.
Ein belastbares Arbeitsprodukt enthält:
- priorisiertes Krypto- und Datenflussinventar,
- Risiko- und Kompatibilitätsmatrix,
- dokumentierte Policy- und Ausnahmebewertung,
- Pilot- und Migrationspfad,
- Owner, Messpunkte und Wiedervorlage,
- konkrete Prüfschritte für offene Fakten.
SourcingBlox fokussiert dabei auf vorhandene Zscaler-Datenwege, TLS-Inspektion, Policies und eine umsetzbare Crypto-Agility-Roadmap. PKI-, HSM-, Rechts- oder kryptografische Detailfragen werden bei Bedarf mit spezialisierten Partnern bearbeitet.
So wird aus einem abstrakten Quantenthema ein kontrollierbarer Modernisierungspfad.
Ein praktisches Prüfraster pro Datenweg
Damit das Inventar nicht zu einer unverbundenen Tabelle wird, erhält jeder priorisierte Datenweg dieselben Fragen:
- Welche Daten werden übertragen und wie lange bleiben sie schutzwürdig?
- Welche Clients, Bibliotheken und Gegenstellen bauen die Verbindung auf?
- Durch welche Zscaler- und anderen Proxy-Komponenten läuft der Verkehr?
- Wird TLS inspiziert, ausgenommen oder außerhalb der Plattform geführt?
- Welche Zertifikate und Trust Stores sind beteiligt?
- Welche PQC- beziehungsweise Hybridverfahren werden heute beobachtet?
- Was passiert bei Inkompatibilität oder Fallback?
- Wer verantwortet Test, Entscheidung und erneute Prüfung?
Dieses Raster verbindet Business-Risiko mit technischer Nachweisbarkeit. Es verhindert, dass eine lange Systemliste ohne Priorität entsteht.
Typische Befunde und ihre Konsequenz
In der Praxis können sehr unterschiedliche Befunde auftreten. Eine moderne Browseranwendung unterstützt ein neues Verfahren, während ein vorgeschaltetes System oder eine ältere Bibliothek Probleme verursacht. Eine Verbindung ist kompatibel, wird aber wegen einer historischen Ausnahme gar nicht inspiziert. Ein Bericht zeigt PQC-Nutzung, doch der fachliche Owner kennt den zugrunde liegenden Datenweg nicht.
Die Reaktion ist jeweils anders:
- Bei fehlender Kompatibilität wird ein Test- und Upgradepfad benötigt.
- Bei unbekannten Ausnahmen folgt eine Policy- und Owner-Prüfung.
- Bei fehlender Sichtbarkeit muss Routing oder Telemetrie verstanden werden.
- Bei langfristig sensiblen Daten kann eine frühere Priorisierung nötig sein.
- Bei rechtlichen oder kryptografischen Detailfragen wird spezialisierte Expertise eingebunden.
Eine pauschale Ampel „PQC-ready“ wäre für diese Unterschiede zu grob.
Pilot und Rollback gehören zusammen
Ein Pilot definiert nicht nur, was aktiviert wird, sondern auch, wie ein Problem erkannt und zurückgenommen wird. Testgruppe, Zeitraum, betroffene Datenwege, Monitoring und Erfolgskriterien müssen vor der Änderung feststehen.
Bei jeder Abweichung wird dokumentiert, ob Client, Inspektionspunkt, Zielanwendung, Zertifikat oder Policy ursächlich war. Dadurch entsteht Wissen, das sich in weitere Rolloutwellen übertragen lässt. Ohne diese Fehlerklassifikation bleibt jeder neue Test ein Einzelereignis.
Was der Vorstand wissen muss – und was nicht
Eine Entscheidungsübersicht braucht keine Liste aller Cipher Suites. Sie sollte zeigen, welche langfristig sensiblen Datenwege priorisiert sind, wo Abhängigkeiten bestehen, welche Maßnahmen im nächsten Zeitraum anstehen und wer die Risiken trägt.
Die technische Anlage darf detaillierter sein. Die Managementsicht bleibt jedoch an Entscheidungen gebunden: Budget, Owner, Migrationsfenster und akzeptierte Übergangsrisiken.