Suriin ang CMVP Certificate sa Likod ng FIPS Claim ng isang VPN

Ang mga pahina ng vendor na nagsasabing FIPS validated ay hindi ebidensya na maaari mong isumite. Ang ebidensya ay isang certificate number, isang pangalan ng module, isang validated na version at ang mga kondisyon sa pagpapatakbo na nakakabit dito, at kailangang tumugma ang mga ito sa build na ipinapakalat mo. Malinaw ang NIST CMVP FAQ tungkol sa pagkakaiba ng isang produktong nagsasabing compatible at isang module na na-validate. Gawin ang apat na hakbang sa ibaba nang sunod-sunod, at itago ang rekord kasama ng deployment.

Hakbang 1: kunin ang certificate number, hindi ang badge

Hilingin sa vendor ang CMVP certificate number na sumasaklaw sa cryptographic module sa produktong balak mong patakbuhin. Ang certificate number ay isang partikular at napapatunayang bagay, habang ang badge ay marketing. Kung inilalarawan ng sagot ang isang algorithm sa halip na isang module, ibang tanong ang sinagot nito. Hilingin muli ang numero sa halip na tanggapin ang PDF ng isang badge. Ang rekord sa likod ng numero ang bagay na masusubaybayan ng isang auditor.

Pagkatapos hanapin ang numerong iyon sa opisyal na paghahanap ng mga validated na module at basahin ang rekord, hindi ang buod nito. Binabanggit ng rekord ang vendor, ang module, ang validated na version at ang status, at iniuugnay nito ang dokumento ng security policy na naglalarawan kung paano dapat gumana ang module.

Isulat ang limang field na iyon, dahil inihahambing ng susunod na hakbang ang mga ito sa build. Sapat na ang isang column sa spreadsheet.

Hakbang 2: itugma ang version ng module sa build

Ang version ng VPN client at ang version ng naka-embed na module ay bihirang magbahagi ng parehong numero, at normal iyon. Ang mahalaga ay kung ang version ng module sa loob ng iyong build ay lumalabas sa validated na rekord. Maaaring baguhin ng isang update ang module nang hindi binabago ang pangalan ng produkto, na tahimik na naglalabas sa deployment sa labas ng validated na configuration.

Itanong kung aling component ang gumagamit ng module at paano pinipili ang approved mode sa sinusuportahang configuration. Ang build na maaaring tumakbo sa isang hindi approved na mode ay hindi parehong ebidensya sa build na naka-configure para sa approved.

Basahin ang lokal na build, upang ang paghahambing ay gumamit ng artefact at hindi ng page ng download. Ang mga command sa ibaba ay nagpi-print ng eksaktong iyon.

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

Kapag nag-ulat ang module ng ibang version kaysa sa certificate, gumalaw na ang claim at kailangang i-update ang rekord bago may pumirma ng anuman.

Hakbang 3: basahin ang mga kondisyon sa pagpapatakbo

May mga kondisyon ang certificate na naglalarawan sa kapaligirang saklaw ng validation. Maaaring banggitin ng mga kondisyong iyon ang platform, ang configuration, ang mga pinapayagang laki ng key at ang mga serbisyong dapat limitahan. Ang ordinaryong installation na hindi pinapansin ang mga ito ay deployment sa labas ng validated na hangganan, kahit magkapareho ang binary. Iyon ang dahilan kung bakit ang dokumento ng security policy ay kasinghalaga ng certificate number.

Itago ang gabay ng vendor sa tabi ng certificate, dahil ipinapaliwanag nito kung aling mga setting ang pumipili ng approved mode at alin ang naglalabas sa produkto sa labas nito.

Kung hindi matugunan ang mga kondisyon sa iyong kapaligiran, ang tapat na pahayag ay nasa labas ng validated na configuration ang deployment na ito. Ang pagbanggit ng kondisyong hindi matugunan ay ginagawang isang bagay na maaaring ayusin o tanggapin ng isang team ang pahayag na iyon.

Hakbang 4: kumpirmahin ang status ngayon

May status ang CMVP record, at ang status ay hindi permanente. Inilalarawan ng FAQ ng NIST ang mga petsa ng transition ng FIPS 140-2 sa 2026, at pagkatapos noon ay mga validation ng FIPS 140-3 na lamang ang natitira sa aktibong listahan. Ang certificate na aktibo noong inaprubahan ang pagbili ay maaaring historical na ngayon.

Ang historical at revoked ay magkaibang estado, at may sariling kahulugan ang bawat isa para sa procurement. Suriin ang live na rekord sa halip na screenshot mula sa folder ng proyekto, at itala ang petsang sinuri mo.

Pagkatapos itanong sa may-ari ng compliance o procurement kung aling status ang tinatanggap ng kanilang requirement, dahil desisyon sa patakaran iyon at hindi teknikal na natuklasan. Itala ang sagot na may petsa.

Suriin ang rekord laban sa deployment

Ihambing ang apat na nakolektang halaga: ang certificate number, ang version ng module mula sa build, ang mga kondisyon sa pagpapatakbo na may bisa, at ang kasalukuyang status. Anumang hindi pagtutugma ay isang natuklasan, at ang natuklasan ay nabibilang sa rekord ng deployment at hindi sa slide.

Itago ang ebidensya kasama ng build, kabilang ang petsa at ang taong sumuri nito. Sapat na ang isang direktoryo bawat release.

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

Panatilihin din ang claim sa loob ng hangganan nito. Walang sinasabi ang validation ng module tungkol sa paghawak ng protocol ng VPN, sa mga desisyon nito sa authorization o sa patakaran nito sa logging. Partikular itong ebidensya tungkol sa isang tinukoy na cryptographic component, at ang pagtrato dito bilang marka ng produkto ay ang paraan kung paano nagtatapos ang isang file ng compliance sa paglalarawan ng isang bagay na walang nag-deploy.