Ստուգեք VPN-ի FIPS պնդման հետևում գտնվող CMVP վկայականը
Վավերացված մոդուլը վկայականի համար է, տարբերակ և շահագործման պայմանների հավաքածու։ Գտեք երեքն էլ նախքան արտադրանքի FIPS պնդումն ընդունելը։
FIPS validated գրող մատակարարների էջերը արխիվ դնելու ապացույց չեն։ Ապացույցը վկայականի համարն է, մոդուլի անվանումը, վավերացված տարբերակը և դրան կցված շահագործման պայմանները, և դրանք պետք է համապատասխանեն ձեր տեղակայվող build-ին։ NIST CMVP FAQ-ը հստակ նկարագրում է համատեղելիություն պնդող արտադրանքի և վավերացված մոդուլի տարբերությունը։ Կատարեք ներքևի չորս քայլերը հերթականությամբ և գրառումը պահեք տեղակայման հետ։
Քայլ 1. ստացեք վկայականի համարը, ոչ թե կրծքանշանը
Մատակարարից պահանջեք այն CMVP վկայականի համարը, որը ծածկում է այն արտադրանքի գաղտնագրային մոդուլը, որը պատրաստվում եք գործարկել։ Վկայականի համարը կոնկրետ, ստուգելի օբյեկտ է, իսկ կրծքանշանը՝ մարքեթինգ։ Եթե պատասխանը նկարագրում է ալգորիթմ՝ մոդուլի փոխարեն, ապա պատասխանը պատասխանել է այլ հարցի։ Մեկ անգամ ևս պնդեք համարի վրա՝ կրծքանշանի PDF ընդունելու փոխարեն։ Համարի հետևում գտնվող գրառումն այն է, ինչին աուդիտորը կարող է հետևել։
Ապա գտեք այդ համարը վավերացված մոդուլների պաշտոնական որոնման մեջ և կարդացեք գրառումը, ոչ թե դրա ամփոփումը։ Գրառումը նշում է մատակարարին, մոդուլը, վավերացված տարբերակը և կարգավիճակը, և հղում է անվտանգության քաղաքականության փաստաթղթին, որը նկարագրում է, թե ինչպես պետք է աշխատի մոդուլը։
Գրի առեք այդ հինգ դաշտերը, քանի որ հաջորդ քայլը դրանք համեմատում է build-ի հետ։ Աղյուսակում մեկ սյունակը բավական է։
Քայլ 2. համապատասխանեցրեք մոդուլի տարբերակը build-ին
VPN հաճախորդի տարբերակը և ներկառուցված մոդուլի տարբերակը հազվադեպ են կիսում նույն համարը, և դա նորմալ է։ Կարևորն այն է՝ արդյոք ձեր build-ում մոդուլի տարբերակը հայտնվում է վավերացված գրառման մեջ։ Թարմացումը կարող է փոխել մոդուլը՝ չփոխելով արտադրանքի անվանումը, ինչը լուռ դուրս է բերում տեղակայումը վավերացված կոնֆիգուրացիայից։
Հարցրեք, թե որ բաղադրիչն է օգտագործում մոդուլը և ինչպես է ընտրվում հաստատված ռեժիմը աջակցվող կոնֆիգուրացիայում։ Այն build-ը, որը կարող է աշխատել չհաստատված ռեժիմում, նույն ապացույցը չէ, ինչ հաստատված ռեժիմի համար կազմաձևված build-ը։
Կարդացեք տեղական build-ը, որպեսզի համեմատությունն օգտագործի արտեֆակտը, ոչ թե ներբեռնման էջը։ Ներքևի հրամանները տպում են հենց դա։
openssl version -a
openssl list -providers -verbose
cat /proc/sys/crypto/fips_enabledԵրբ մոդուլը հաղորդում է վկայականից տարբեր տարբերակ, պնդումը շեղվել է, և գրառումը պետք է թարմացվի նախքան որևէ մեկը ինչ-որ բան ստորագրելը։
Քայլ 3. կարդացեք շահագործման պայմանները
Վկայականը կրում է պայմաններ, որոնք նկարագրում են վավերացմամբ ծածկված միջավայրը։ Այդ պայմանները կարող են նշել հարթակը, կոնֆիգուրացիան, թույլատրված բանալու չափերը և այն ծառայությունները, որոնք պետք է սահմանափակվեն։ Սովորական տեղադրումը, որը անտեսում է դրանք, վավերացված սահմանից դուրս տեղակայում է, նույնիսկ երբ բինարը նույնական է։ Այդ պատճառով անվտանգության քաղաքականության փաստաթուղթը նույնքան կարևոր է, որքան վկայականի համարը։
Մատակարարի ուղեցույցը պահեք վկայականի կողքին, քանի որ այն բացատրում է, թե որ կարգավորումներն են ընտրում հաստատված ռեժիմը և որոնք են արտադրանքը դուրս բերում դրանից։
Եթե պայմանները հնարավոր չէ կատարել ձեր միջավայրում, ազնիվ պնդումն այն է, որ այս տեղակայումը գտնվում է վավերացված կոնֆիգուրացիայից դուրս։ Անհնար պայմանի անվանումը այդ պնդումը դարձնում է մի բան, որը թիմը կարող է ուղղել կամ ընդունել։
Քայլ 4. հաստատեք այսօրվա կարգավիճակը
CMVP գրառումն ունի կարգավիճակ, և կարգավիճակը մշտական չէ։ NIST-ի FAQ-ը նկարագրում է FIPS 140-2-ի անցումային ամսաթվերը 2026 թվականին, որից հետո ակտիվ ցանկում մնում են միայն FIPS 140-3 վավերացումները։ Վկայականը, որը ակտիվ էր գնման հաստատման պահին, այսօր կարող է պատմական լինել։
Պատմականը և չեղարկվածը տարբեր վիճակներ են, և յուրաքանչյուրն ունի իր նշանակությունը գնումների համար։ Ստուգեք կենդանի գրառումը, ոչ թե նախագծի պանակի էկրանի պատկերը, և նշեք ստուգման ամսաթիվը։
Ապա հարցրեք համապատասխանության կամ գնումների պատասխանատուին, թե որ կարգավիճակն է ընդունում իրենց պահանջը, քանի որ դա քաղաքական որոշում է, ոչ տեխնիկական հայտնագործություն։ Գրանցեք պատասխանը ամսաթվով։
Ստուգեք գրառումը տեղակայման դեմ
Համեմատեք հավաքված չորս արժեքները՝ վկայականի համարը, build-ից մոդուլի տարբերակը, գործող շահագործման պայմանները և ընթացիկ կարգավիճակը։ Ցանկացած անհամապատասխանություն հայտնագործություն է, և հայտնագործությունը պատկանում է տեղակայման գրառմանը, ոչ թե սլայդին։
Ապացույցը պահեք build-ի հետ՝ ներառյալ ամսաթիվը և ստուգող անձը։ Մեկ պանակ յուրաքանչյուր թողարկման համար բավական է։
date -u +%FT%TZ
openssl version -a | head -3
cat /proc/sys/crypto/fips_enabledՊնդումը պահեք նաև իր սահմանի ներսում։ Մոդուլի վավերացումը ոչինչ չի ասում VPN-ի արձանագրությունների մշակման, դրա լիազորման որոշումների կամ գրանցման քաղաքականության մասին։ Դա կոնկրետ ապացույց է մեկ սահմանված գաղտնագրային բաղադրիչի մասին, և այն որպես արտադրանքի գնահատական դիտարկելը հենց այն ուղին է, որով համապատասխանության գործը սկսում է նկարագրել մի բան, որը ոչ ոք չի տեղակայել։