Die vraag wat die meeste hiervan bepaal, is nie hoe jy die argief versleutel nie. Dit is of jou CA-privaatsleutel hoegenaamd uit sy houer kan beweeg. As die sleutel ’n lêer is, kan jy die hele CA-gids in een geënkripteerde blob kopieer en binne minute klaar wees. As dit in ’n HSM of ’n token woon wat die sleutel as nie-onttrekbaar merk, bestaan daardie kopie nie, en jou plan word ’n plan oor die verskaffer se omhul-en-herstel-prosedure. Albei modelle werk, hulle faal anders, en die fout wat jy kan oorleef, is die een rondom wie dit die moeite werd is om te ontwerp.

Waar die twee rugsteunmodelle uiteengaan

Model A is gidskopie. ’n CA in OpenSSL-styl is ’n werkgids, nie ’n enkele sertifikaat nie: ca.key of cakey.pem, ca.crt, die uitreikingsdatabasis, die serial- en crlnumber-tellers, en openssl.cnf. Verseël daardie gids met ’n simmetriese syfer, skuif die resultaat na ’n tweede medium, en herstel beteken uitpak, verifieer, onderteken. Alles wat die uitreiker nodig het, reis saam, insluitend weke se herroepingsgeskiedenis wat niemand onthou hulle geskryf het nie.

Model B is sleutelbeheersing. Die sleutel word binne ’n PKCS#11-module gegenereer en as nie-onttrekbaar gemerk; die module kan dit vir rugsteun omhul, maar geen proses lees ooit die rou grepe nie. Jou rugsteun is dan twee artefakte wat in die regte volgorde herstel moet word: ’n omhulde sleutelblob wat net daardie modulefamilie kan oopmaak, plus ’n gewone kopie van die databasis, konfigurasie en sertifikate.

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

Die vergelyking gaan nooit oor watter model in die abstrakte sterker is nie. Dit gaan oor watter een jou span om 2 uur in die oggend kan herstel met die mense wat werklik wakker is. ’n Argief wat niemand kan ontsleutel nie en ’n HSM-blob wat niemand getoets het nie, is ewe nutteloos. Die verskil is dat die argieffout in ’n wagwoordbestuurder opduik, en die HSM-fout wegkruip in ’n ondersteuningskontrak.

Wat elke CA-rugsteun moet bevat

Albei modelle het dieselfde rekordstel nodig. In ’n OpenSSL-CA is daardie lêers index.txt met een ry per uitgereikte sertifikaat wat status, vervaldatum, reeksnommer en onderwerp dek, dan index.txt.attr, serial wat die volgende reeksnommer hou om uit te reik, crlnumber wat die volgende CRL-nommer hou, en openssl.cnf met die dir, policy en default_days waarmee jou CA werklik werk. Die openssl-ca-handleiding verduidelik wat elkeen van daardie tellers beheer. easy-rsa hou dieselfde data onder pki/, met ’n vars-lêer wat die sertifikaatvelde bepaal.

Die sleutel en sertifikaat is die dele wat jy nie kan herbou nie. Die databasis is die deel wat jy nie uit geheue kan rekonstrueer nie. Om index.txt oor te slaan laat jou steeds in staat om nuwe sertifikate te onderteken, en dit is presies die lokval: jy ontdek dit ontbreek die eerste keer wanneer ’n kliënt vra of ’n sertifikaat herroep is. Teken die CA-vingerafdruk buite die rugsteun aan, sodat ’n herstel teen ’n waarde vergelyk word wat jy vertrou eerder as teen die lêer wat jy pas herstel het.

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

Hersteltoetse wat nie ’n tweede uitreiker skep nie

Twee lewende CA’s met dieselfde onderwerp en dieselfde sleutel lyk identies vir elke kliënt wat die oorspronklike vertrou. Twee CRL’s met dieselfde nommer maar verskillende inhoud is hoe kliënte stilweg ’n sertifikaat aanvaar wat jy herroep het. Hardloop die herstel op ’n gasheer sonder roete na jou kliënte, of in ’n weggooi-VM, en publiseer nooit die CRL wat die toets produseer nie.

’n Toets wat net bewys die argief oopmaak, bewys niks oor uitreiking nie. Die volgorde wat tel: vergelyk die herstelde ca.crt-vingerafdruk met die waarde wat jy aangeteken het, bevestig die reeksnommer stem ooreen met wat jou laas uitgereikte sertifikaat impliseer, reik een sertifikaat vir ’n weggooi-CN uit en kyk of index.txt ’n ry bykry, herroep dan daardie sertifikaat en genereer die CRL opnuut.

openssl verify -CAfile ca.crt -CRLfile crl.pem -crl_check client.crt
openssl crl -in crl.pem -noout -lastupdate -nextupdate

Met ’n HSM loop dieselfde toets deur die module. Maak die blob in die vervangingsapparaat oop, bevestig die CA-sertifikaat wat die module rapporteer stem ooreen met jou aangetekende vingerafdruk, en laat dit eers dan onderteken. As die module sy eie objekstoor het, moet die omhulling die sleutelobjek en sy etiket dek, want om die sleutel onder ’n ander etiket te herstel, breek die konfigurasie wat daarheen wys.

Foutmodusse wat die keuse bepaal

Vyf foute veroorsaak die meeste werklike verliese. ’n Vergete argiefwagfrase sonder ’n onafhanklike kopie van die geheim maak die argief ’n baksteen. ’n Enkele kopie op een skyf sterf saam met daardie skyf, en ’n kontrolesom vertel jou nooit of ontsleuteling nog werk nie. Sertifikate wat ná die rugsteundatum herroep is, lyk weer geldig ná ’n herstel, so jou rugsteuninterval is ook jou herroepingsblinde kol. Om ’n ouer reeksnommerteller te herstel, hergebruik reeksnommers en verwar kasgeheues en CRL-opsoektings wat op die reeksnommer gesleutel is. ’n Vervangings-HSM wat die omhulde blob weier, maak van ’n hardeware-ruil ’n volledige heruitreiking.

Model A hanteer die eerste vier sleg maar sigbaar. Model B hanteer hulle goed totdat die module of die verskafferproses faal. As jou sleutels uitvoerbaar is en die span klein is, is die geënkripteerde argief die eerlike keuse, gerugsteun deur twee media en ’n geskrewe wagfrase-prosedure. As die sleutel nie-onttrekbaar is, het jy geen keuse nie, en die werk verskuif na die bewys van die verskaffer se herstelpad voordat die dag aanbreek waarop jy dit nodig het.

Kies die model en beplan die tyd

Drie voorwaardes beslis die saak. Kan die sleutel uitgevoer word sonder ’n verskafferproses? Moet ’n herstel op hardeware beland wat jy nie reeds besit nie? Hoe lank kan uitreiking stil staan terwyl jy met ondersteuning stry? Beantwoord daardie drie en die model is beslis; alles daarna is beplanning.

Neem ’n rugsteun ná elke ondertekeningseremonie en voor enige konfigurasieverandering, want die konfigurasie is deel van die toestand. Hou twee kopieë op verskillende media op verskillende plekke, een daarvan vanlyn, en hou die ontsleutelingsgeheim in ’n ander vertrouensdomein as die kopieë. Skryf die laaste suksesvolle hersteldatum op die rugsteunrekord. ’n Rugsteun wat nog nooit herstel is nie, is ’n hipotese, nie ’n beheer nie.

Voordat jy die kaartjie sluit, bevestig hierdie vyf punte:

  • Die ca.crt-vingerafdruk is êrens buite die rugsteun aangeteken.
  • index.txt, serial, crlnumber en openssl.cnf is almal binne die argief of blobstel.
  • Die bewaring van die wagfrase of omhulde sleutel is gedokumenteer en word deur iemand anders as die argiefeienaar gehou.
  • ’n Herstel is op ’n geïsoleerde gasheer getoets met een uitreiking en een herroeping.
  • Die herroepingsgaping wat jou rugsteuninterval impliseer, word skriftelik aanvaar of verkort.

Verwante artikels