ખાનગી 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 જે આગલું ઇશ્યુ કરવાનું 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 નંબર ફરી વપરાય છે અને serial-કી થયેલા કેશ અને CRL લુકઅપ ભ્રમિત થાય છે. રિપ્લેસમેન્ટ HSM જે લપેટાયેલ બ્લોબ નકારે છે તે હાર્ડવેર બદલીને સંપૂર્ણ પુનઃઇશ્યુમાં ફેરવે છે.
મોડલ A પ્રથમ ચારને ખરાબ પરંતુ દૃશ્યમાન રીતે સંભાળે છે. મોડલ B તેમને સારી રીતે સંભાળે છે જ્યાં સુધી મોડ્યુલ અથવા વેન્ડર પ્રક્રિયા નિષ્ફળ ન જાય. જો તમારી કી એક્સપોર્ટ કરી શકાય તેવી હોય અને ટીમ નાની હોય, તો એન્ક્રિપ્ટેડ આર્કાઇવ પ્રામાણિક પસંદગી છે, બે માધ્યમ અને લેખિત પાસફ્રેઝ પ્રક્રિયા દ્વારા સમર્થિત. જો કી બિન-એક્સટ્રેક્ટેબલ હોય તો તમારી પાસે કોઈ પસંદગી નથી, અને કામ તે દિવસ પહેલાં વેન્ડરના પુનઃસ્થાપન માર્ગને સાબિત કરવા તરફ ખસે છે જ્યારે તમને તેની જરૂર પડશે.
મોડલ પસંદ કરવું અને સમયપત્રક
ત્રણ શરતો નિર્ણય નક્કી કરે છે. વેન્ડર પ્રક્રિયા વિના કી એક્સપોર્ટ કરી શકાય છે? શું પુનઃસ્થાપન એવા હાર્ડવેર પર ઉતરવું જોઈએ જે તમારી પાસે પહેલેથી નથી? જ્યારે તમે સપોર્ટ સાથે દલીલ કરો ત્યારે ઇશ્યુ કેટલા સમય સુધી થોભી શકે? તે ત્રણનો જવાબ આપો અને મોડલ નક્કી થાય છે; તે પછીનું બધું સમયપત્રક છે.
દરેક સહી સમારંભ પછી અને કોઈપણ રૂપરેખાંકન ફેરફાર પહેલાં બેકઅપ લો, કારણ કે રૂપરેખાંકન સ્થિતિનો ભાગ છે. જુદા જુદા સ્થળોએ જુદા જુદા માધ્યમો પર બે કોપી રાખો, તેમાંની એક ઑફલાઇન, અને ડિક્રિપ્શન ગુપ્તને કોપીઓ કરતાં જુદા વિશ્વાસ ડોમેનમાં રાખો. બેકઅપ રેકોર્ડ પર છેલ્લા સફળ પુનઃસ્થાપનની તારીખ લખો. જે બેકઅપ ક્યારેય પુનઃસ્થાપિત થયું નથી તે પરિકલ્પના છે, નિયંત્રણ નહીં.
ટિકિટ બંધ કરતા પહેલાં, આ પાંચ મુદ્દા ખાતરી કરો:
- ca.crtની ફિંગરપ્રિન્ટ બેકઅપની બહાર ક્યાંક રેકોર્ડ થયેલી છે.
- index.txt, serial, crlnumber અને openssl.cnf બધા આર્કાઇવ અથવા બ્લોબ સેટની અંદર છે.
- પાસફ્રેઝ અથવા લપેટાયેલ કીની સંભાળ દસ્તાવેજીકૃત છે અને આર્કાઇવ માલિક સિવાયના કોઈની પાસે છે.
- એક ઇશ્યુ અને એક રિવોકેશન સાથે અલગ હોસ્ટ પર પુનઃસ્થાપનનું પરીક્ષણ કરાયું છે.
- તમારા બેકઅપ અંતરાલ સૂચવે છે તે રિવોકેશન ગેપ લેખિતમાં સ્વીકારાયો છે અથવા ટૂંકાવાયો છે.