Kontrolu la CMVP-atestilon malantaŭ la FIPS-aserto de VPN

Paĝoj de vendistoj, kiuj diras FIPS validated, ne estas pruvo, kiun vi povas arkivi. La pruvo estas atestila numero, modula nomo, validigita versio kaj la operaciaj kondiĉoj ligitaj al ĝi, kaj tiuj devas kongrui kun la konstruaĵo, kiun vi deplojas. La NIST CMVP FAQ estas klara pri la diferenco inter produkto, kiu asertas kongruecon, kaj modulo, kiu estis validigita. Trapasu la kvar paŝojn sube laŭorde kaj konservu la rikordon kun la deplojo.

Paŝo 1: prenu la atestilan numeron, ne la insignon

Petu de la vendisto la CMVP-atestilan numeron, kiu kovras la kriptografian modulon en la produkto, kiun vi intencas ruli. Atestila numero estas konkreta, kontrolebla objekto, dum insigno estas merkatado. Se la respondo priskribas algoritmon anstataŭ modulon, la respondo respondis al alia demando. Insistu ankoraŭfoje pri la numero anstataŭ akcepti PDF de insigno. La rikordo malantaŭ la numero estas tio, kion revizoro povas sekvi.

Poste serĉu tiun numeron en la oficiala serĉo de validigitaj moduloj kaj legu la rikordon, ne resumon de ĝi. La rikordo nomas la vendiston, la modulon, la validigitan version kaj la staton, kaj ĝi ligas la sekurec-politikan dokumenton, kiu priskribas kiel la modulo devas funkcii.

Skribu tiujn kvin kampojn, ĉar la sekva paŝo komparas ilin kun la konstruaĵo. Unu kolumno en kalkultabelo sufiĉas.

Paŝo 2: kongruigu la modulan version kun la konstruaĵo

Versio de VPN-kliento kaj versio de enkonstruita modulo malofte havas la saman numeron, kaj tio estas normala. Gravas ĉu la modula versio en via konstruaĵo aperas en la validigita rikordo. Ĝisdatigo povas ŝanĝi la modulon sen ŝanĝi la produktan nomon, kio silente movas la deplojon ekster la validigitan agordon.

Demandu, kiu komponanto uzas la modulon kaj kiel la aprobita reĝimo estas elektita en la subtenata agordo. Konstruaĵo, kiu povas ruliĝi en neaprobita reĝimo, ne estas la sama pruvo kiel konstruaĵo agordita por la aprobita.

Legu la lokan konstruaĵon, por ke la komparo uzu la artefakton anstataŭ la elŝutan paĝon. La komandoj sube presas ĝuste tion.

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

Kiam la modulo raportas alian version ol la atestilo, la aserto driviĝis kaj la rikordo bezonas ĝisdatigon antaŭ ol iu subskribos ion.

Paŝo 3: legu la operaciajn kondiĉojn

La atestilo portas kondiĉojn, kiuj priskribas la medion, kiun la validigado kovras. Tiuj kondiĉoj povas nomi la platformon, la agordon, la permesitajn ŝlosilgrandojn kaj la servojn, kiuj devas esti limigitaj. Ordinara instalado, kiu ignoras ilin, estas deplojo ekster la validigita limo, eĉ kiam la dunuma dosiero estas identa. Tial la sekurec-politika dokumento same gravas kiel la atestila numero.

Tenu la gvidadon de la vendisto apud la atestilo, ĉar ĝi klarigas, kiuj agordoj elektas la aprobitan reĝimon kaj kiuj kondukas la produkton ekster ĝin.

Se la kondiĉoj ne povas esti plenumitaj en via medio, la honesta aserto estas, ke ĉi tiu deplojo staras ekster la validigita agordo. Nomi la kondiĉon, kiu ne povas esti plenumita, igas tiun aserton io, kion teamo povas ripari aŭ akcepti.

Paŝo 4: konfirmu la hodiaŭan staton

La CMVP-rikordo portas staton, kaj la stato ne estas permanenta. La FAQ de NIST priskribas la transirajn datojn de FIPS 140-2 en 2026, post kiuj restas en la aktiva listo nur validigoj FIPS 140-3. Atestilo, kiu estis aktiva kiam la aĉeto estis aprobita, povas esti historia hodiaŭ.

Historia kaj revokita estas malsamaj statoj, kaj ĉiu havas sian propran signifon por aĉetado. Kontrolu la vivan rikordon anstataŭ ekrankopion el la projekta dosierujo, kaj notu la daton, kiam vi kontrolis.

Poste demandu la posedanton de konformeco aŭ aĉetado, kiun staton ilia postulo akceptas, ĉar tio estas politika decido, ne teknika trovaĵo. Registru la respondon kun dato.

Kontrolu la rikordon kontraŭ la deplojo

Komparu la kvar kolektitajn valorojn: la atestilan numeron, la modulan version el la konstruaĵo, la validajn operaciajn kondiĉojn kaj la nunan staton. Ĉiu miskongruo estas trovaĵo, kaj la trovaĵo apartenas al la deploj-rikordo, ne al lumbildo.

Konservu la pruvon kun la konstruaĵo, inkluzive de la dato kaj la persono, kiu kontrolis ĝin. Unu dosierujo por eldono sufiĉas.

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

Tenu la aserton ankaŭ ene de ĝia limo. Modula validigado diras nenion pri la protokola traktado de la VPN, ĝiaj rajtigaj decidoj aŭ ĝia registra politiko. Ĝi estas konkreta pruvo pri unu difinita kriptografia komponento, kaj trakti ĝin kiel produktonotorojn estas kiel konformeca dosiero finas priskribante ion, kion neniu deplojis.