Möchten Sie die Post-Quanten-Kryptografie in Red Hat Enterprise Linux (RHEL) ausprobieren, haben aber noch kein Upgrade auf RHEL 10 durchgeführt? Wir unterstützen Sie bei der Vorbereitung Ihres Unternehmens auf den „Q-Day“. Beginnen Sie jetzt bereits mit RHEL 9.7. Wenn Sie jetzt beginnen, können Sie proaktiv Ihre Sicherheitslage verbessern und sich auf einen nahtlosen Übergang zu RHEL 10 vorbereiten.

RHEL 9 wurde 2022 veröffentlicht und war aus Sicherheitsperspektive ein wichtiger Fortschritt. Es war die erste Version von RHEL, die die FIPS 140-3-Zertifizierung erhielt und damit die aktuellen Sicherheitsanforderungen erfüllte. Allerdings hat sich seit 2022 viel getan. Die Sicherheitsanforderungen haben sich geändert, und die Ära der Post-Quanten-Kryptografie hat begonnen. Aus Gründen der Performance und Stabilität können diese neuen kryptografischen Algorithmen nicht wie von vielen Unternehmen erwartet in frühere Versionen der meisten Software zurückportiert werden. Ein Software-Upgrade ist heutzutage unerlässlich, um in der Post-Quanten-Ära kontinuierliche Stabilität, Funktionalität und Schutz zu gewährleisten. RHEL 9.7 kann Ihr erster Schritt sein.

RHEL 9.7 ist ein wichtiger Schritt für Ihren Übergang zu Post-Quanten. Sie haben die Möglichkeit, praktische Erfahrungen mit Post-Quanten-Kryptografie zu sammeln und die Auswirkungen auf Ihre spezifischen Workloads zu verstehen. Sie können auch erforderliche Anwendungs- oder Infrastrukturanpassungen ermitteln, bevor Sie ein vollständiges Upgrade auf RHEL 10 durchführen, das die umfassendste Implementierung der Post-Quanten-Kryptografie bietet. 

Kritische Libraries und Anwendungen

Ein plötzlicher, erzwungener Übergang zur Post-Quanten-Kryptografie, wenn Quantenbedrohungen unmittelbar bevorstehen (Q-Day, derzeit geschätzt auf 2030), könnte Ihre Geschäftsabläufe stören. Mithilfe gründlicher Tests können Sie Kompatibilitätsprobleme, Auswirkungen auf die Performance und Integrationsprobleme in einer kontrollierten Umgebung identifizieren und beheben, sodass Sie noch vor dem Q-Day Maßnahmen ergreifen können.

Regierungen und Aufsichtsbehörden erwägen zunehmend die Einführung von Vorschriften zur Post-Quanten-Kryptografie. Frühe Tests mit RHEL 9.7 helfen Unternehmen, zukünftige Compliance-Anforderungen zu erfüllen, ohne in letzter Minute ein umfassendes Upgrade durchführen zu müssen. Dies bietet ausreichend Zeit, um Herausforderungen zu bewältigen, die frühzeitig in Entwicklungs- und Deploymentzyklen auftreten.

RHEL 9.7 bietet eingeschränkte Funktionen für Post-Quanten-Kryptografie in einer früheren, stabilen Version von RHEL. So können Sie mit dem Experimentieren und der Überprüfung der Post-Quanten-Kryptografie in Ihren bestehenden RHEL 9-Umgebungen beginnen, um sie für RHEL 10 vorzubereiten. Ein erheblicher Teil der RHEL-Komponenten basiert auf drei wichtigen kryptografischen Libraries: NSS, GnuTLS und OpenSSL. Um PQC nutzen zu können, müssen diese Libraries aktualisiert werden.

RHEL 9.7 enthält stabile Updates für OpenSSL, das serverseitige Anwendungen unterstützt, und NSS, das in Client-Software weit verbreitet ist. Mit RHEL 9.7 können Ihre Anwendungen, die auf diesen Libraries basieren, mit der Post-Quanten-Kryptografie beginnen, was Ihnen wertvolle Testmöglichkeiten für reale Szenarien bietet.

Für NSS stellen wir die neueste relevante Version bereit, die Post-Quanten-Algorithmen unterstützt. Für OpenSSL bietet die Langzeit-Supportversion 3.5 mehrere nützliche Post-Quanten-Funktionen. 

Disruption nach Ihren Regeln

Um eine sofortige Unterbrechung zu vermeiden, aktiviert RHEL 9.7 Algorithmen für Post-Quanten-Kryptografie nicht standardmäßig. Sie können sich jedoch für Krypto-Richtlinien für Post-Quanten-Kryptografie entscheiden, was kontrollierte Tests und die schrittweise Integration in Ihre Systeme ermöglicht und den ähnlichen Ansatz von RHEL 10 widerspiegelt. Dies hilft Ihnen, zu verstehen, wie Sie die Post-Quanten-Kryptografie innerhalb des Crypto-Policy-Frameworks von Red Hat verwalten, bevor Sie sie in RHEL 10 vollständig aktivieren müssen. Wir empfehlen, die Post-Quanten-Kryptografie für den Schlüsselaustausch (hybride ML-KEM-Algorithmen) zu aktivieren, um Systeme vor „Harvest now, decrypt later“-Angriffen zu schützen und den kritischen Schutz zu bieten, der in regulierten Umgebungen erforderlich ist. Diese Funktion bietet ein frühzeitiges Testfeld für Organisationen mit strengen Compliance-Anforderungen.

Um die Funktionalität zu gewährleisten und Unterbrechungen in Kundenumgebungen beim Deployment zu reduzieren, verfügt OpenSSH in RHEL 9.7 aufgrund mangelnder breiter Nutzung noch nicht über einen post-quanten-sicheren, ML-KEM-basierten Schlüsselaustausch. Für die ersten Schritte mit Post-Quanten-OpenSSH sollten Sie ein Upgrade auf RHEL 10 in Betracht ziehen.

Die FIPS-Anforderungen ermöglichen die Kombination der Ausgabe eines FIPS-zertifizierten Algorithmus mit zusätzlichen Daten für hybride Schlüsselaustauschmechanismen. Dies ist entscheidend, um einen validierten und zertifizierten Anbieter zu gewährleisten. Zum Schutz vor Bedrohungen des Typs „Harvest now, decrypt later“ und zur Unterstützung der Anforderungen für FIPS-Umgebungen können Komponenten, die auf OpenSSL in RHEL 9.7 basieren, selbst im FIPS-Modus einen hybriden ML-KEM-Schlüsselaustausch verwenden, wenn sie ein zertifiziertes Modul nutzen.

Erste Schritte

Aus der Perspektive des Post-Quanten-Übergangs ist RHEL 9.7 ein guter erster Schritt für den Übergang von klassischer Kryptografie zu Post-Quantum. Sie erhalten die gleiche Stabilität (eine der Haupterwartungen an Nebenversionen) und verbessern Ihre Sicherheitslage über das hinaus, was derzeit verfügbar ist. Die Bemühungen, eine begrenzte Unterstützung für Post-Quanten-Kryptografie in RHEL 9.7 zu integrieren, sollen Ihnen den Übergang erleichtern und Ihr Unternehmen auf die erfolgreiche Einführung umfassender Post-Quanten-Kryptografie in RHEL 10 vor dem Q-Day vorbereiten.

Produktsicherheit bei Red Hat

Red Hat ist der Meinung, dass jeder Mensch, unabhängig vom Standort, ein Recht auf qualitativ hochwertige Informationen (und auf den Zugang zu ihnen) hat, die zur Minderung von Sicherheits- und Datenschutzrisiken erforderlich sind.

Über die Autoren

Dived into OpenSSL in 2005. Red Hatter since late 2020.

Emily Fox is a DevOps enthusiast, security unicorn, and advocate for Women in Technology. She promotes the cross-pollination of development and security practices.

UI_Icon-Red_Hat-Close-A-Black-RGB

Nach Thema durchsuchen

automation icon

Automatisierung

Das Neueste zum Thema IT-Automatisierung für Technologien, Teams und Umgebungen

AI icon

Künstliche Intelligenz

Erfahren Sie das Neueste von den Plattformen, die es Kunden ermöglichen, KI-Workloads beliebig auszuführen

open hybrid cloud icon

Open Hybrid Cloud

Erfahren Sie, wie wir eine flexiblere Zukunft mit Hybrid Clouds schaffen.

security icon

Sicherheit

Erfahren Sie, wie wir Risiken in verschiedenen Umgebungen und Technologien reduzieren

edge icon

Edge Computing

Erfahren Sie das Neueste von den Plattformen, die die Operations am Edge vereinfachen

Infrastructure icon

Infrastruktur

Erfahren Sie das Neueste von der weltweit führenden Linux-Plattform für Unternehmen

application development icon

Anwendungen

Entdecken Sie unsere Lösungen für komplexe Herausforderungen bei Anwendungen

Virtualization icon

Virtualisierung

Erfahren Sie das Neueste über die Virtualisierung von Workloads in Cloud- oder On-Premise-Umgebungen