ഇതിൽ ഭൂരിഭാഗവും നിർണ്ണയിക്കുന്ന ചോദ്യം നിങ്ങൾ ആർക്കൈവ് എങ്ങനെ എൻക്രിപ്റ്റ് ചെയ്യുന്നു എന്നതല്ല. നിങ്ങളുടെ CA സ്വകാര്യ കീയ്ക്ക് അതിന്റെ കണ്ടെയ്നർ വിട്ടുപോകാമോ എന്നതാണ്. കീ ഒരു ഫയലാണെങ്കിൽ, മുഴുവൻ CA ഡയറക്ടറിയും ഒരു എൻക്രിപ്റ്റ് ചെയ്ത ബ്ലോബിലേക്ക് പകർത്തി മിനിറ്റുകൾക്കുള്ളിൽ തീർക്കാം. അത് HSM-ലോ കീയെ വേർതിരിച്ചെടുക്കാനാകാത്തതെന്ന് അടയാളപ്പെടുത്തുന്ന ടോക്കണിലോ ജീവിക്കുന്നുവെങ്കിൽ, ആ പകർപ്പ് നിലവിലില്ല, നിങ്ങളുടെ പ്ലാൻ വിതരണക്കാരന്റെ പൊതിയുന്നതും പുനഃസ്ഥാപിക്കുന്നതുമായ നടപടിക്രമത്തെക്കുറിച്ചുള്ള പ്ലാനാകുന്നു. രണ്ട് മോഡലുകളും പ്രവർത്തിക്കുന്നു, വ്യത്യസ്ത രീതിയിൽ പരാജയപ്പെടുന്നു, നിങ്ങൾക്ക് അതിജീവിക്കാനാകുന്ന പരാജയമാണ് രൂപകൽപ്പന ചെയ്യാൻ യോഗ്യമായത്.

രണ്ട് ബാക്കപ്പ് മോഡലുകൾ വേർപെടുന്നിടം

മോഡൽ A ഡയറക്ടറി പകർപ്പാണ്. OpenSSL ശൈലിയിലുള്ള CA ഒരു പ്രവർത്തന ഡയറക്ടറിയാണ്, ഒരു സർട്ടിഫിക്കറ്റല്ല: ca.key അല്ലെങ്കിൽ cakey.pem, ca.crt, ഇഷ്യൂവൻസ് ഡാറ്റാബേസ്, serial, crlnumber കൗണ്ടറുകൾ, openssl.cnf എന്നിവ. ആ ഡയറക്ടറി ഒരു സമമിതി സൈഫർ കൊണ്ട് മുദ്രവെക്കുക, ഫലം രണ്ടാം മീഡിയത്തിലേക്ക് മാറ്റുക, പുനഃസ്ഥാപനം എന്നാൽ അൺപാക്ക്, പരിശോധന, ഒപ്പിടൽ. ഇഷ്യൂവർക്ക് വേണ്ടതെല്ലാം ഒരുമിച്ച് സഞ്ചരിക്കുന്നു, ആരും എഴുതിയതായി ഓർക്കാത്ത ആഴ്ചകളുടെ റദ്ദാക്കൽ ചരിത്രം ഉൾപ്പെടെ.

മോഡൽ B കീ സംരക്ഷണമാണ്. കീ PKCS#11 മൊഡ്യൂളിനുള്ളിൽ സൃഷ്ടിക്കപ്പെടുകയും വേർതിരിച്ചെടുക്കാനാകാത്തതെന്ന് അടയാളപ്പെടുത്തുകയും ചെയ്യുന്നു; മൊഡ്യൂളിന് ബാക്കപ്പിനായി അത് പൊതിയാം, പക്ഷേ ഒരു പ്രക്രിയയും ഒരിക്കലും അസംസ്കൃത ബൈറ്റുകൾ വായിക്കുന്നില്ല. അപ്പോൾ നിങ്ങളുടെ ബാക്കപ്പ് ശരിയായ ക്രമത്തിൽ പുനഃസ്ഥാപിക്കേണ്ട രണ്ട് ആർട്ടിഫാക്ടുകളാണ്: ആ മൊഡ്യൂൾ കുടുംബത്തിന് മാത്രം തുറക്കാനാകുന്ന പൊതിഞ്ഞ കീ ബ്ലോബ്, കൂടാതെ ഡാറ്റാബേസ്, കോൺഫിഗറേഷൻ, സർട്ടിഫിക്കറ്റുകളുടെ സാധാരണ പകർപ്പ്.

AttributeEncrypted archiveHSM key backup
What you storeone encrypted filewrapped blob plus CA records
Who can restore itanyone holding the passphraseholder of the module and the blob, often vendor support
If a copy leaksattacker with the passphrase becomes the CAblob is inert without the matching module
What usually breaks itforgotten passphrase, one damaged copyreplacement module rejects the blob, contract gap

താരതമ്യം എപ്പോഴും ഏത് മോഡൽ അമൂർത്തമായി ശക്തമാണ് എന്നതിനെക്കുറിച്ചല്ല. നിങ്ങളുടെ ടീമിന് രാത്രി 2 മണിക്ക് യഥാർത്ഥത്തിൽ ഉണർന്നിരിക്കുന്ന ആളുകളോടൊപ്പം ഏതിനെ പുനഃസ്ഥാപിക്കാം എന്നതിനെക്കുറിച്ചാണ്. ആർക്കും ഡീക്രിപ്റ്റ് ചെയ്യാനാകാത്ത ആർക്കൈവും ആരും പരീക്ഷിക്കാത്ത HSM ബ്ലോബും ഒരുപോലെ നിഷ്പ്രയോജനമാണ്. വ്യത്യാസം എന്തെന്നാൽ ആർക്കൈവ് പരാജയം പാസ്വേഡ് മാനേജരിൽ പ്രത്യക്ഷപ്പെടുന്നു, HSM പരാജയം പിന്തുണാ കരാറിൽ ഒളിക്കുന്നു.

എല്ലാ CA ബാക്കപ്പിലും എന്ത് ഉണ്ടായിരിക്കണം

രണ്ട് മോഡലുകൾക്കും ഒരേ റെക്കോർഡ് സെറ്റ് വേണം. OpenSSL CA-യിൽ ആ ഫയലുകൾ index.txt ആണ്, ഓരോ ഇഷ്യൂ ചെയ്ത സർട്ടിഫിക്കറ്റിനും സ്റ്റാറ്റസ്, കാലഹരണം, serial, വിഷയം എന്നിവ ഉൾക്കൊള്ളുന്ന ഒരു വരി, തുടർന്ന് index.txt.attr, അടുത്ത ഇഷ്യൂ ചെയ്യേണ്ട serial സൂക്ഷിക്കുന്ന serial, അടുത്ത CRL നമ്പർ സൂക്ഷിക്കുന്ന crlnumber, നിങ്ങളുടെ CA യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന dir, policy, default_days ഉള്ള openssl.cnf. 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 -nextupdate

HSM-ൽ അതേ പരിശോധന മൊഡ്യൂളിലൂടെ കടന്നുപോകുന്നു. ബ്ലോബ് പകരം ഉപകരണത്തിൽ തുറക്കുക, മൊഡ്യൂൾ റിപ്പോർട്ട് ചെയ്യുന്ന CA സർട്ടിഫിക്കറ്റ് നിങ്ങളുടെ രേഖപ്പെടുത്തിയ ഫിംഗർപ്രിന്റുമായി ഒത്തുപോകുന്നുവെന്ന് ഉറപ്പാക്കുക, അതിനുശേഷം മാത്രം ഒപ്പിടാൻ അനുവദിക്കുക. മൊഡ്യൂളിന് സ്വന്തം ഒബ്ജക്ട് സ്റ്റോർ ഉണ്ടെങ്കിൽ, പൊതിയൽ കീ ഒബ്ജക്ടും അതിന്റെ ലേബലും ഉൾക്കൊള്ളണം, കാരണം മറ്റൊരു ലേബലിന് കീഴിൽ കീ പുനഃസ്ഥാപിക്കുന്നത് അതിലേക്ക് ചൂണ്ടുന്ന കോൺഫിഗറേഷനെ തകർക്കുന്നു.

തിരഞ്ഞെടുപ്പ് തീരുമാനിക്കുന്ന പരാജയ മോഡുകൾ

അഞ്ച് പരാജയങ്ങൾ യഥാർത്ഥ നഷ്ടങ്ങളിൽ ഭൂരിഭാഗവും വിശദീകരിക്കുന്നു. രഹസ്യത്തിന്റെ സ്വതന്ത്ര പകർപ്പില്ലാതെ മറന്ന പാസ്ഫ്രേസ് ആർക്കൈവിനെ ഇഷ്ടികയാക്കുന്നു. ഒരു ഡിസ്കിലെ ഒരൊറ്റ പകർപ്പ് ആ ഡിസ്കിനൊപ്പം മരിക്കുന്നു, ചെക്സം ഡീക്രിപ്ഷൻ ഇപ്പോഴും പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് ഒരിക്കലും പറയുന്നില്ല. ബാക്കപ്പ് തീയതിക്ക് ശേഷം റദ്ദാക്കിയ സർട്ടിഫിക്കറ്റുകൾ പുനഃസ്ഥാപനത്തിന് ശേഷം വീണ്ടും സാധുവായി തോന്നുന്നു, അതിനാൽ നിങ്ങളുടെ ബാക്കപ്പ് ഇടവേള തന്നെ റദ്ദാക്കലിന്റെ അന്ധമായ സ്ഥലവുമാണ്. പഴയ serial കൗണ്ടർ പുനഃസ്ഥാപിക്കുന്നത് serial നമ്പറുകൾ വീണ്ടും ഉപയോഗിക്കുകയും serial അടിസ്ഥാനമാക്കിയ കാഷുകളും CRL തിരച്ചിലുകളും കുഴയ്ക്കുകയും ചെയ്യുന്നു. പൊതിഞ്ഞ ബ്ലോബ് നിരസിക്കുന്ന പകരം HSM ഹാർഡ്വെയർ മാറ്റത്തെ പൂർണ പുനർഇഷ്യൂവാക്കി മാറ്റുന്നു.

മോഡൽ A ആദ്യ നാലെണ്ണത്തെ മോശമായി എന്നാൽ ദൃശ്യമായി കൈകാര്യം ചെയ്യുന്നു. മോഡൽ B അവയെ മൊഡ്യൂളോ വിതരണക്കാരന്റെ പ്രക്രിയയോ പരാജയപ്പെടുന്നതുവരെ നന്നായി കൈകാര്യം ചെയ്യുന്നു. നിങ്ങളുടെ കീകൾ എക്സ്പോർട്ട് ചെയ്യാവുന്നതും ടീം ചെറുതുമാണെങ്കിൽ, എൻക്രിപ്റ്റ് ചെയ്ത ആർക്കൈവാണ് സത്യസന്ധമായ തിരഞ്ഞെടുപ്പ്, രണ്ട് മീഡിയത്തിന്റെയും എഴുതിയ പാസ്ഫ്രേസ് നടപടിക്രമത്തിന്റെയും പിന്തുണയോടെ. കീ വേർതിരിച്ചെടുക്കാനാകാത്തതാണെങ്കിൽ നിങ്ങൾക്ക് തിരഞ്ഞെടുപ്പില്ല, ജോലി അത് ആവശ്യമാകുന്ന ദിവസത്തിന് മുമ്പ് വിതരണക്കാരന്റെ പുനഃസ്ഥാപന പാത തെളിയിക്കുന്നതിലേക്ക് മാറുന്നു.

മോഡൽ തിരഞ്ഞെടുക്കലും ഷെഡ്യൂളിംഗും

മൂന്ന് വ്യവസ്ഥകൾ തീരുമാനം പരിഹരിക്കുന്നു. വിതരണക്കാരന്റെ പ്രക്രിയയില്ലാതെ കീ എക്സ്പോർട്ട് ചെയ്യാമോ? നിങ്ങൾക്ക് ഇതിനകം ഇല്ലാത്ത ഹാർഡ്വെയറിൽ പുനഃസ്ഥാപനം ഇറങ്ങണമോ? പിന്തുണയുമായി തർക്കിക്കുമ്പോൾ ഇഷ്യൂവിംഗ് എത്ര കാലം നിൽക്കാം? ആ മൂന്നിന് ഉത്തരം നൽകുക, മോഡൽ തീരുമാനമാകും; അതിനുശേഷമുള്ളതെല്ലാം ഷെഡ്യൂളിംഗാണ്.

ഓരോ സിഗ്നിംഗ് ചടങ്ങിനും ശേഷം ഏതെങ്കിലും കോൺഫിഗറേഷൻ മാറ്റത്തിനും മുമ്പ് ബാക്കപ്പ് എടുക്കുക, കാരണം കോൺഫിഗറേഷൻ അവസ്ഥയുടെ ഭാഗമാണ്. വ്യത്യസ്ത സ്ഥലങ്ങളിലെ വ്യത്യസ്ത മീഡിയങ്ങളിൽ രണ്ട് പകർപ്പുകൾ സൂക്ഷിക്കുക, ഒന്ന് ഓഫ്ലൈൻ, ഡീക്രിപ്ഷൻ രഹസ്യം പകർപ്പുകളിൽ നിന്ന് വ്യത്യസ്ത വിശ്വാസ ഡൊമെയ്നിൽ സൂക്ഷിക്കുക. അവസാന വിജയകരമായ പുനഃസ്ഥാപന തീയതി ബാക്കപ്പ് റെക്കോർഡിൽ എഴുതുക. ഒരിക്കലും പുനഃസ്ഥാപിക്കാത്ത ബാക്കപ്പ് സിദ്ധാന്തമാണ്, നിയന്ത്രണമല്ല.

ടിക്കറ്റ് അടയ്ക്കുന്നതിന് മുമ്പ് ഈ അഞ്ച് കാര്യങ്ങൾ ഉറപ്പാക്കുക:

  • ca.crt-യുടെ ഫിംഗർപ്രിന്റ് ബാക്കപ്പിന് പുറത്ത് എവിടെയോ രേഖപ്പെടുത്തിയിട്ടുണ്ട്.
  • index.txt, serial, crlnumber, openssl.cnf എല്ലാം ആർക്കൈവിലോ ബ്ലോബ് സെറ്റിലോ ഉണ്ട്.
  • പാസ്ഫ്രേസിന്റെയോ പൊതിഞ്ഞ കീയുടെയോ സൂക്ഷിപ്പ് രേഖപ്പെടുത്തിയിട്ടുണ്ട്, ആർക്കൈവ് ഉടമയല്ലാത്ത ഒരാളുടെ കൈവശമാണ്.
  • ഒരു ഇഷ്യൂവും ഒരു റദ്ദാക്കലും ഉള്ള പുനഃസ്ഥാപനം ഒറ്റപ്പെട്ട ഹോസ്റ്റിൽ പരീക്ഷിച്ചിട്ടുണ്ട്.
  • നിങ്ങളുടെ ബാക്കപ്പ് ഇടവേള സൂചിപ്പിക്കുന്ന റദ്ദാക്കൽ വിടവ് എഴുത്തിൽ സ്വീകരിച്ചിട്ടുണ്ട് അല്ലെങ്കിൽ ചുരുക്കിയിട്ടുണ്ട്.

അനുബന്ധ ലേഖനങ്ങൾ