Herstellerseiten mit der Angabe FIPS validated sind kein Beleg, den Sie ablegen können. Der Beleg ist eine Zertifikatsnummer, ein Modulname, eine validierte Version und die dazugehörigen Betriebsbedingungen, und diese müssen zum ausgerollten Build passen. Die NIST CMVP FAQ ist deutlich, was den Unterschied zwischen einem Produkt mit Kompatibilitätsangabe und einem validierten Modul betrifft. Arbeiten Sie die vier Schritte unten der Reihe nach ab und verwahren Sie den Nachweis beim Deployment.

Schritt 1: die Zertifikatsnummer holen, nicht das Abzeichen

Fragen Sie den Hersteller nach der CMVP-Zertifikatsnummer, die das kryptografische Modul in dem Produkt abdeckt, das Sie betreiben wollen. Eine Zertifikatsnummer ist ein konkretes, prüfbares Objekt, ein Abzeichen ist Marketing. Wenn die Antwort einen Algorithmus statt eines Moduls beschreibt, hat sie eine andere Frage beantwortet. Bestehen Sie noch einmal auf der Nummer, statt eine PDF eines Abzeichens anzunehmen. Der Nachweis hinter der Nummer ist das, was ein Prüfer nachvollziehen kann.

Suchen Sie diese Nummer dann in der offiziellen Suche validierter Module und lesen Sie den Eintrag statt einer Zusammenfassung. Der Eintrag nennt Hersteller, Modul, validierte Version und Status und verlinkt das Sicherheitsrichtliniendokument, das beschreibt, wie das Modul betrieben werden soll.

Notieren Sie diese fünf Felder, denn der nächste Schritt vergleicht sie mit dem Build. Eine Spalte in einer Tabelle genügt.

Schritt 2: die Modulversion mit dem Build abgleichen

Eine VPN-Client-Version und eine eingebettete Modulversion tragen selten dieselbe Nummer, und das ist normal. Entscheidend ist, ob die Modulversion in Ihrem Build im validierten Eintrag auftaucht. Ein Update kann das Modul ändern, ohne den Produktnamen zu ändern, und schiebt das Deployment damit still aus der validierten Konfiguration.

Fragen Sie, welche Komponente das Modul nutzt und wie der zugelassene Modus in der unterstützten Konfiguration gewählt wird. Ein Build, der in einem nicht zugelassenen Modus laufen kann, ist nicht derselbe Beleg wie ein für den zugelassenen Modus konfigurierter Build.

Lesen Sie den lokalen Build aus, damit der Vergleich das Artefakt nutzt und nicht die Download-Seite. Die Befehle unten geben genau das aus.

openssl version -a
openssl list -providers -verbose
cat /proc/sys/crypto/fips_enabled

Meldet das Modul eine andere Version als das Zertifikat, ist die Angabe abgedriftet und der Eintrag muss aktualisiert werden, bevor jemand etwas unterschreibt.

Schritt 3: die Betriebsbedingungen lesen

Das Zertifikat trägt Bedingungen, die die Umgebung beschreiben, die die Validierung abdeckt. Diese Bedingungen können Plattform, Konfiguration, erlaubte Schlüssellängen und die einzuschränkenden Dienste nennen. Eine gewöhnliche Installation, die sie ignoriert, ist ein Deployment außerhalb der validierten Grenze, selbst wenn das Binary identisch ist. Deshalb ist das Sicherheitsrichtliniendokument so wichtig wie die Zertifikatsnummer.

Halten Sie die Herstelleranleitung neben dem Zertifikat bereit, denn sie erklärt, welche Einstellungen den zugelassenen Modus wählen und welche das Produkt aus ihm herausführen.

Lassen sich die Bedingungen in Ihrer Umgebung nicht erfüllen, lautet die ehrliche Aussage, dass dieses Deployment außerhalb der validierten Konfiguration liegt. Die Bedingung zu benennen, die nicht erfüllbar ist, macht aus dieser Aussage etwas, das ein Team beheben oder akzeptieren kann.

Schritt 4: den heutigen Status bestätigen

Der CMVP-Eintrag trägt einen Status, und der Status ist nicht dauerhaft. Die FAQ von NIST beschreibt die Übergangsdaten von FIPS 140-2 im Jahr 2026, danach bleiben nur FIPS 140-3-Validierungen auf der aktiven Liste. Ein Zertifikat, das beim Kaufbeschluss aktiv war, kann heute historisch sein.

Historisch und widerrufen sind verschiedene Zustände, und jeder hat seine eigene Bedeutung für die Beschaffung. Prüfen Sie den Live-Eintrag statt eines Screenshots aus dem Projektordner, und notieren Sie das Prüfdatum.

Fragen Sie dann den Verantwortlichen für Compliance oder Beschaffung, welchen Status seine Anforderung akzeptiert, denn das ist eine politische Entscheidung und kein technischer Befund. Halten Sie die Antwort mit Datum fest.

Den Eintrag gegen das Deployment prüfen

Vergleichen Sie die vier erhobenen Werte: Zertifikatsnummer, Modulversion aus dem Build, geltende Betriebsbedingungen und aktueller Status. Jede Abweichung ist ein Befund, und der Befund gehört in den Deployment-Nachweis, nicht auf eine Folie.

Bewahren Sie den Beleg beim Build auf, einschließlich Datum und prüfender Person. Ein Verzeichnis pro Release genügt.

date -u +%FT%TZ
openssl version -a | head -3
cat /proc/sys/crypto/fips_enabled

Halten Sie die Angabe auch in ihrer Grenze. Eine Modulvalidierung sagt nichts über die Protokollbehandlung des VPN, seine Autorisierungsentscheidungen oder seine Logging-Richtlinie. Sie ist ein konkreter Beleg über eine definierte kryptografische Komponente, und sie als Produktnote zu behandeln, ist der Weg, auf dem eine Compliance-Akte etwas beschreibt, das niemand ausgerollt hat.

Ähnliche Artikel