Yksityisen CA:n varmuuskopio: salattu arkisto vai HSM-avaimen varmuuskopio

Kysymys, joka ratkaisee suurimman osan tästä, ei ole se, miten salaamisen arkiston. Se on, voiko yksityinen CA-avaimesi ylipäänsä lähteä säiliöstään. Jos avain on tiedosto, voit kopioida koko CA-hakemiston yhteen salattuun blobiin ja olla valmis minuuteissa. Jos se asuu HSM:ssä tai tokenissa, joka merkitsee avaimen ei-ulosotettavaksi, sitä kopiota ei ole, ja suunnitelmastasi tulee suunnitelma toimittajan kääre- ja palautusmenettelystä. Molemmat mallit toimivat, ne epäonnistuvat eri tavoin, ja vika, jonka voit selvitä, on se, jonka ympärille kannattaa suunnitella.

Missä kaksi varmuuskopiomallia erkanevat

Malli A on hakemistokopio. OpenSSL-tyylinen CA on työhakemisto, ei yksittäinen varmenne: ca.key tai cakey.pem, ca.crt, myöntötietokanta, serial- ja crlnumber-laskurit sekä openssl.cnf. Sinetöi hakemisto symmetrisellä salauksella, siirrä tulos toiselle medialle, ja palauttaminen tarkoittaa purkamista, tarkistamista ja allekirjoittamista. Kaikki, mitä myöntäjä tarvitsee, matkustaa yhdessä, mukaan lukien viikkojen mitätöintihistoria, jota kukaan ei muista kirjoittaneensa.

Malli B on avaimen säilytys. Avain luodaan PKCS#11-moduulin sisällä ja merkitään ei-ulosotettavaksi; moduuli voi kääriä sen varmuuskopiota varten, mutta mikään prosessi ei koskaan lue raakoja tavuja. Varmuuskopiosi on silloin kaksi artefaktia, jotka on palautettava oikeassa järjestyksessä: kääritty avainblobi, jonka vain se moduuliperhe voi avata, sekä tavallinen kopio tietokannasta, kokoonpanosta ja varmenteista.

Vertailu ei koskaan kerro, kumpi malli on vahvempi abstraktisti. Se kertoo, kumman tiimisi pystyy palauttamaan kello 2 yöllä niiden ihmisten kanssa, jotka todella ovat hereillä. Arkisto, jota kukaan ei voi purkaa, ja HSM-blobi, jota kukaan ei ole testannut, ovat yhtä hyödyttömiä. Ero on siinä, että arkiston vika näkyy salasananhallinnassa ja HSM:n vika piiloutuu tukisopimukseen.

Mitä jokaisen CA-varmuuskopion on sisällettävä

Molemmat mallit tarvitsevat saman tietuejoukon. OpenSSL-CA:ssa nämä tiedostot ovat index.txt, jossa on yksi rivi kutakin myönnettyä varmennetta kohden kattaen tilan, vanhenemisen, sarjanumeron ja subjektin, sitten index.txt.attr, serial joka pitää seuraavan myönnettävän sarjanumeron, crlnumber joka pitää seuraavan CRL-numeron, ja openssl.cnf sen dir, policy ja default_days -arvojen kanssa, joilla CA todella toimii. openssl-ca-käsikirja selittää, mitä kukin näistä laskureista ohjaa. easy-rsa pitää samat tiedot pki/:n alla, ja vars-tiedosto päättää varmenteen kentät.

Avain ja varmenne ovat ne osat, joita et voi rakentaa uudelleen. Tietokanta on se osa, jota et voi rekonstruoida muistista. index.txt:n ohittaminen jättää sinut silti pystymään allekirjoittamaan uusia varmenteita, ja juuri se on ansa: huomaat sen puuttuvan ensimmäisen kerran, kun asiakas kysyy, mitätöitiinkö varmenne. Kirjaa CA:n sormenjälki varmuuskopion ulkopuolelle, jotta palautusta verrataan arvoon, johon luotat, eikä tiedostoon, jonka juuri palautit.

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

Palautustestit, jotka eivät haarauta myöntäjää

Kaksi elävää CA:ta samalla subjektilla ja samalla avaimella näyttävät identtisiltä jokaiselle asiakkaalle, joka luottaa alkuperäiseen. Kaksi CRL:ää samalla numerolla mutta eri sisällöllä on tapa, jolla asiakkaat hiljaa hyväksyvät varmenteen, jonka mitätöit. Aja palautus isännällä, jolla ei ole reittiä asiakkaisiisi, tai kertakäyttöisessä VM:ssä, äläkä koskaan julkaise CRL:ää, jonka testi tuottaa.

Testi, joka todistaa vain arkiston avautuvan, ei todista mitään myöntämisestä. Järjestys, jolla on merkitystä: vertaa palautetun ca.crt:n sormenjälkeä kirjaamaasi arvoon, varmista että sarjanumero vastaa sitä, mitä viimeksi myöntämäsi varmenne edellyttää, myönnä yksi varmenne kertakäyttöiselle CN:lle ja katso index.txt:n saavan rivin, mitätöi sitten kyseinen varmenne ja luo CRL uudelleen.

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

HSM:n kanssa sama testi kulkee moduulin kautta. Pura blobi korvaavaan laitteeseen, varmista että moduulin ilmoittama CA-varmenne vastaa kirjattua sormenjälkeäsi, ja vasta sitten anna sen allekirjoittaa. Jos moduulilla on oma objektivarastonsa, kääreen on katettava avainobjekti ja sen tunniste, koska avaimen palauttaminen eri tunnisteen alle rikkoo siihen osoittavan kokoonpanon.

Valinnan ratkaisevat vikamuodot

Viisi vikaa selittää suurimman osan todellisista menetyksistä. Unohdettu arkiston salasana ilman itsenäistä kopiota salaisuudesta muuttaa arkiston tiileksi. Yksi kopio yhdellä levyllä kuolee levyn mukana, eikä tarkistussumma kerro koskaan, toimiiko salauksen purku vielä. Varmuuskopion päivämäärän jälkeen mitätöidyt varmenteet näyttävät palautuksen jälkeen jälleen kelvollisilta, joten varmuuskopiointiväli on myös mitätöinnin sokea piste. Vanhemman sarjalaskurin palauttaminen käyttää sarjanumerot uudelleen ja sekoittaa välimuistit ja sarjanumeroon avaimetut CRL-haut. Korvaava HSM, joka hylkää kääritün blobin, muuttaa laitteistovaihdon täydelliseksi uudelleenmyönnöksi.

Malli A hoitaa neljä ensimmäistä huonosti mutta näkyvästi. Malli B hoitaa ne hyvin siihen asti, kunnes moduuli tai toimittajan prosessi pettää. Jos avaimesi ovat vietävissä ja tiimi on pieni, salattu arkisto on rehellinen valinta, kahden median ja kirjallisen salasanamenettelyn tukemana. Jos avain on ei-ulosotettava, sinulla ei ole lainkaan valintaa, ja työ siirtyy toimittajan palautuspolun todistamiseen ennen sitä päivää, jolloin tarvitset sitä.

Mallin valinta ja aikataulutus

Kolme ehtoa ratkaisee. Voidaanko avain viedä ilman toimittajan prosessia? Täytyykö palautuksen laskeutua laitteistolle, jota sinulla ei vielä ole? Kuinka kauan myöntäminen voi seisahtua, kun väittelet tuen kanssa? Vastaa noihin kolmeen ja malli on päätetty; kaikki sen jälkeen on aikataulutusta.

Ota varmuuskopio jokaisen allekirjoitusseremonian jälkeen ja ennen mitä tahansa kokoonpanomuutosta, koska kokoonpano on osa tilaa. Pidä kahta kopiota eri medioilla eri paikoissa, toinen niistä offline-tilassa, ja pidä salauksenpurku-salaisuus eri luottamusdomainissa kuin kopiot. Kirjoita viimeisimmän onnistuneen palautuksen päivämäärä varmuuskopiotietueeseen. Varmuuskopio, jota ei ole koskaan palautettu, on hypoteesi, ei valvontakeino.

Ennen kuin suljet tiketin, vahvista nämä viisi kohtaa:

• ca.crt:n sormenjälki on kirjattu jonnekin varmuuskopion ulkopuolelle.
• index.txt, serial, crlnumber ja openssl.cnf ovat kaikki arkistossa tai blobijoukossa.
• Salasanan tai käärityn avaimen säilytys on dokumentoitu ja jollakin muulla kuin arkiston omistajalla.
• Palautus testattiin eristetyllä isännällä yhdellä myönnöllä ja yhdellä mitätöinnillä.
• Varmuuskopiointivälistä johtuva mitätöintiaukko on hyväksytty kirjallisesti tai lyhennetty.