Մասնավոր CA-ի պահուստավորում՝ գաղտնագրված արխիվ ընդդեմ HSM բանալու պահուստի
Գաղտնագրված արխիվ կամ HSM-ով փաթաթված բանալի. ինչպես է վերականգնվում VPN CA-ի պահուստավորման յուրաքանչյուր մոդելը, ինչ պետք է պարունակի և որ ձախողումը կարող եք իրականում վերապրել։
Հարցը, որը որոշում է սրա մեծ մասը, այն չէ, թե ինչպես եք գաղտնագրում արխիվը։ Այն է, թե արդյոք ձեր CA մասնավոր բանալին կարող է ընդհանրապես լքել իր տարան։ Եթե բանալին ֆայլ է, կարող եք պատճենել ամբողջ CA գրացուցակը մեկ գաղտնագրված բլոբի մեջ և ավարտել րոպեների ընթացքում։ Եթե այն ապրում է HSM-ում կամ նշանի մեջ, որը բանալին նշում է որպես չարտահանվող, այդ պատճենը գոյություն չունի, և ձեր պլանը վերածվում է մատակարարի փաթաթման և վերականգնման ընթացակարգի մասին պլանի։ Երկու մոդելներն էլ աշխատում են, ձախողվում են տարբեր կերպ, և այն ձախողումը, որը կարող եք վերապրել, այն է, որի շուրջ արժե նախագծել։
Որտեղ են բաժանվում պահուստավորման երկու մոդելները
Մոդել A-ն գրացուցակի պատճենումն է։ OpenSSL ոճի CA-ն աշխատանքային գրացուցակ է, ոչ թե մեկ վկայական. ca.key կամ cakey.pem, ca.crt, թողարկման տվյալների բազան, serial և crlnumber հաշվիչները, և openssl.cnf։ Կնքի՛ր այդ գրացուցակը սիմետրիկ գաղտնագրով, տեղափոխի՛ր արդյունքը երկրորդ կրիչ, և վերականգնումը նշանակում է բացել, ստուգել, ստորագրել։ Ամեն ինչ, ինչ թողարկողին պետք է, ճամփորդում է միասին, ներառյալ շաբաթների չեղարկման պատմությունը, որը ոչ ոք չի հիշում, թե գրել է։
Մոդել B-ն բանալու պահումն է։ Բանալին ստեղծվում է PKCS#11 մոդուլի ներսում և նշվում որպես չարտահանվող. մոդուլը կարող է փաթաթել այն պահուստի համար, բայց ոչ մի գործընթաց երբեք չի կարդում հում բայթերը։ Ձեր պահուստն այնուհետև երկու արտեֆակտ է, որոնք պետք է վերականգնվեն ճիշտ հերթականությամբ. փաթաթված բանալու բլոբ, որը կարող է բացել միայն այդ մոդուլների ընտանիքը, գումարած տվյալների բազայի, կարգավորումների և վկայականների սովորական պատճեն։
| Attribute | Encrypted archive | HSM key backup |
|---|---|---|
| What you store | one encrypted file | wrapped blob plus CA records |
| Who can restore it | anyone holding the passphrase | holder of the module and the blob, often vendor support |
| If a copy leaks | attacker with the passphrase becomes the CA | blob is inert without the matching module |
| What usually breaks it | forgotten passphrase, one damaged copy | replacement module rejects the blob, contract gap |
Համեմատությունը երբեք այն մասին չէ, թե որ մոդելն է ավելի ուժեղ վերացական առումով։ Այն այն մասին է, թե որն է ձեր թիմը կարող վերականգնել գիշերվա ժամը 2-ին նրանց հետ, ովքեր իրոք արթուն են։ Արխիվ, որը ոչ ոք չի կարող ապակոդավորել, և HSM բլոբ, որը ոչ ոք չի փորձարկել, հավասարապես անօգուտ են։ Տարբերությունն այն է, որ արխիվի ձախողումը հայտնվում է գաղտնաբառերի կառավարչում, իսկ HSM-ի ձախողումը թաքնվում է աջակցության պայմանագրում։
Ինչ պետք է պարունակի ամեն CA պահուստ
Երկու մոդելներին էլ պետք է նույն գրառումների հավաքածուն։ OpenSSL CA-ում այդ ֆայլերն են index.txt՝ մեկ տողով յուրաքանչյուր թողարկված վկայականի համար, որը ծածկում է կարգավիճակը, ժամկետը, serial-ը և սուբյեկտը, այնուհետև index.txt.attr, serial-ը, որը պահում է թողարկվելիք հաջորդ սերիական համարը, crlnumber-ը, որը պահում է հաջորդ CRL համարը, և openssl.cnf-ը՝ dir, policy և default_days արժեքներով, որոնցով ձեր CA-ն իրականում աշխատում է։ openssl-ca ձեռնարկը բացատրում է, թե այդ հաշվիչներից յուրաքանչյուրը ինչ է կառավարում։ easy-rsa-ն նույն տվյալները պահում է pki/ տակ, և vars ֆայլը որոշում է վկայականի դաշտերը։
Բանալին և վկայականը այն մասերն են, որոնք չեք կարող նորից կառուցել։ Տվյալների բազան այն մասն է, որը չեք կարող վերստեղծել հիշողությունից։ index.txt-ը բաց թողնելը ձեզ դեռ թողնում է նոր վկայականներ ստորագրելու ունակություն, և հենց դա է ծուղակը. դուք իմանում եք, որ այն բացակայում է, առաջին անգամ, երբ հաճախորդը հարցնում է՝ վկայականը չեղարկվե՞լ է։ Գրանցեք CA-ի մատնահետքը պահուստից դուրս, որպեսզի վերականգնումը համեմատվի ձեր վստահած արժեքի հետ, այլ ոչ թե այն ֆայլի, որը հենց նոր վերականգնել եք։
openssl x509 -in ca.crt -noout -fingerprint -sha256
tar czf ca-state.tar.gz ca.crt ca.key index.txt* serial* crlnumber* openssl.cnf
openssl enc -aes-256-cbc -pbkdf2 -iter 200000 -salt -in ca-state.tar.gz -out ca-state.tar.gz.enc
openssl ca -config openssl.cnf -gencrl -out crl.pemՎերականգնման փորձարկումներ, որոնք չեն ճյուղավորում թողարկողին
Նույն սուբյեկտով և նույն բանալիով երկու գործող CA-ներ նույնական են թվում յուրաքանչյուր հաճախորդի, որը վստահում է բնագրին։ Նույն համարով, բայց տարբեր բովանդակությամբ երկու CRL-ներ այն ձևն են, որով հաճախորդները հանգիստ ընդունում են ձեր չեղարկած վկայականը։ Գործարկեք վերականգնումը հոսթի վրա, որտեղից ձեր հաճախորդներին երթուղի չկա, կամ մեկանգամյա VM-ում, և երբեք չհրապարակեք այն CRL-ը, որը ստեղծում է փորձարկումը։
Փորձարկումը, որը միայն ապացուցում է, որ արխիվը բացվում է, ոչինչ չի ապացուցում թողարկման մասին։ Հաջորդականությունը, որ հաշվի է առնվում. համեմատեք վերականգնված ca.crt-ի մատնահետքը ձեր գրանցած արժեքի հետ, հաստատեք, որ serial-ը համապատասխանում է ձեր վերջին թողարկած վկայականի ենթադրածին, թողարկեք մեկ վկայական մեկանգամյա CN-ի համար և հետևեք, թե ինչպես index.txt-ը տող է ստանում, ապա չեղարկեք այդ վկայականը և վերագեներացրեք CRL-ը։
openssl verify -CAfile ca.crt -CRLfile crl.pem -crl_check client.crt
openssl crl -in crl.pem -noout -lastupdate -nextupdateHSM-ով նույն փորձարկումն անցնում է մոդուլով։ Բացեք բլոբը փոխարինող սարքում, հաստատեք, որ մոդուլի հաղորդած CA վկայականը համապատասխանում է ձեր գրանցած մատնահետքին, և միայն դրանից հետո թույլ տվեք ստորագրել։ Եթե մոդուլն ունի իր օբյեկտների պահոցը, փաթաթումը պետք է ծածկի բանալու օբյեկտը և դրա պիտակը, որովհետև բանալին այլ պիտակի տակ վերականգնելը կոտրում է դրան ուղղված կարգավորումը։
Ձախողման ռեժիմներ, որոնք որոշում են ընտրությունը
Հինգ ձախողում բացատրում է իրական կորուստների մեծ մասը։ Մոռացված արխիվային գաղտնաբառը՝ առանց գաղտնիքի անկախ պատճենի, արխիվը վերածում է աղյուսի։ Մեկ սկավառակի վրա մեկ պատճենը մահանում է այդ սկավառակի հետ, և ստուգիչ գումարը երբեք չի ասում՝ արդյոք ապակոդավորումը դեռ աշխատում է։ Պահուստի ամսաթվից հետո չեղարկված վկայականները վերականգնումից հետո կրկին վավեր են թվում, ուստի ձեր պահուստավորման միջակայքը նաև ձեր չեղարկման կույր կետն է։ Ավելի հին serial հաշվիչի վերականգնումը կրկնօգտագործում է սերիական համարները և շփոթեցնում serial-ով բանալիավորված քեշերն ու CRL որոնումները։ Փոխարինող HSM-ը, որը մերժում է փաթաթված բլոբը, ապարատային փոխարինումը վերածում է ամբողջական վերաթողարկման։
Մոդել A-ն առաջին չորսին վատ, բայց տեսանելի կերպով է դիմանում։ Մոդել B-ն լավ է դիմանում նրանց մինչև մոդուլի կամ մատակարարի գործընթացի ձախողումը։ Եթե ձեր բանալիները արտահանվող են և թիմը փոքր է, գաղտնագրված արխիվը ազնիվ ընտրությունն է՝ հենված երկու կրիչի և գրավոր գաղտնաբառի ընթացակարգի վրա։ Եթե բանալին չարտահանվող է, ընտրություն ընդհանրապես չունեք, և աշխատանքը տեղափոխվում է մատակարարի վերականգնման ուղու ապացուցմանը այն օրից առաջ, երբ այն ձեզ պետք կգա։
Մոդելի ընտրությունը և ժամանակացույցը
Երեք պայման է որոշում։ Կարելի՞ է բանալին արտահանել առանց մատակարարի գործընթացի։ Պե՞տք է վերականգնումը վայրէջք կատարի ապարատի վրա, որը դեռ չեք ունեցել։ Որքա՞ն կարող է թողարկումը կանգնել, մինչ դուք վիճում եք աջակցության հետ։ Պատասխանե՛ք այդ երեքին, և մոդելը որոշված է. մնացած ամեն ինչ ժամանակացույց է։
Պահուստ արեք յուրաքանչյուր ստորագրման արարողությունից հետո և ցանկացած կարգավորման փոփոխությունից առաջ, որովհետև կարգավորումը վիճակի մասն է։ Պահեք երկու պատճեն տարբեր կրիչների վրա տարբեր վայրերում, դրանցից մեկը՝ անցանց, և ապակոդավորման գաղտնիքը պահեք պատճեններից տարբեր վստահության տիրույթում։ Գրեք վերջին հաջող վերականգնման ամսաթիվը պահուստի գրառման վրա։ Պահուստը, որը երբեք չի վերականգնվել, վարկած է, ոչ թե վերահսկողություն։
Նախքան տոմսը փակելը, հաստատեք այս հինգ կետերը.
- ca.crt-ի մատնահետքը գրանցված է ինչ-որ տեղ պահուստից դուրս։
- index.txt, serial, crlnumber և openssl.cnf բոլորը արխիվի կամ բլոբ հավաքածուի ներսում են։
- Գաղտնաբառի կամ փաթաթված բանալու պահումը փաստաթղթավորված է և գտնվում է արխիվի տիրոջից բացի մեկ ուրիշի մոտ։
- Վերականգնումը փորձարկվել է մեկուսացված հոսթի վրա՝ մեկ թողարկմամբ և մեկ չեղարկմամբ։
- Ձեր պահուստավորման միջակայքից բխող չեղարկման բացը գրավոր ընդունված է կամ կրճատված։