Privaat-CA-rugsteun: geënkripteerde argief teenoor HSM-sleutelrugsteun
Geënkripteerde argief of HSM-omhulde sleutel: hoe elke VPN-CA-rugsteunmodel herstel word, wat dit moet bevat, en watter fout jy werklik kan oorleef.
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.
| 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 |
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.