Back-up van een privé-CA: versleuteld archief versus HSM-sleutelback-up

De vraag die het meeste hiervan bepaalt, is niet hoe u het archief versleutelt. Het is of uw privésleutel van de CA zijn container überhaupt kan verlaten. Als de sleutel een bestand is, kunt u de hele CA-map naar één versleutelde blob kopiëren en binnen enkele minuten klaar zijn. Als hij in een HSM of een token woont dat de sleutel als niet-extraheerbaar markeert, bestaat die kopie niet, en wordt uw plan een plan over de inpak- en herstelprocedure van de leverancier. Beide modellen werken, ze falen verschillend, en de storing die u kunt overleven is degene waaromheen het de moeite loont te ontwerpen.

Waar de twee back-upmodellen zich splitsen

Model A is een mapkopie. Een CA in OpenSSL-stijl is een werkmap, niet één certificaat: ca.key of cakey.pem, ca.crt, de uitgiftedatabase, de tellers serial en crlnumber, en openssl.cnf. Verzegel die map met een symmetrisch cijfer, verplaats het resultaat naar een tweede medium, en herstellen betekent uitpakken, verifiëren, ondertekenen. Alles wat de uitgever nodig heeft, reist mee, inclusief weken aan intrekkingsgeschiedenis waarvan niemand zich herinnert die te hebben geschreven.

Model B is sleutelinsluiting. De sleutel wordt binnen een PKCS#11-module gegenereerd en als niet-extraheerbaar gemarkeerd; de module kan hem voor de back-up inpakken, maar geen enkel proces leest ooit de onbewerkte bytes. Uw back-up bestaat dan uit twee artefacten die in de juiste volgorde moeten worden hersteld: een ingepakte sleutelblob die alleen die modulfamilie kan uitpakken, plus een gewone kopie van de database, de configuratie en de certificaten.

De vergelijking gaat nooit over welk model in abstracte zin sterker is. Ze gaat over welk model uw team om 2 uur 's nachts kan herstellen met de mensen die echt wakker zijn. Een archief dat niemand kan ontsleutelen en een HSM-blob die niemand heeft getest, zijn even nutteloos. Het verschil is dat de archieffout opduikt in een wachtwoordbeheerder, en de HSM-fout zich verstopt in een supportcontract.

Wat elke CA-back-up moet bevatten

Beide modellen hebben dezelfde recordset nodig. In een OpenSSL-CA zijn die bestanden index.txt met één regel per uitgegeven certificaat die status, vervaldatum, serial en subject dekt, dan index.txt.attr, serial met de volgende uit te geven serienummer, crlnumber met het volgende CRL-nummer, en openssl.cnf met de dir, policy en default_days waarmee uw CA echt draait. De openssl-ca-handleiding legt uit wat elk van die tellers bestuurt. easy-rsa bewaart dezelfde gegevens onder pki/, waarbij een vars-bestand de certificaatvelden bepaalt.

De sleutel en het certificaat zijn de delen die u niet opnieuw kunt opbouwen. De database is het deel dat u niet uit het geheugen kunt reconstrueren. index.txt overslaan laat u nog steeds nieuwe certificaten ondertekenen, en dat is precies de valkuil: u ontdekt dat het ontbreekt de eerste keer dat een klant vraagt of een certificaat is ingetrokken. Leg de vingerafdruk van de CA buiten de back-up vast, zodat een herstel wordt vergeleken met een waarde die u vertrouwt en niet met het bestand dat u zojuist hebt hersteld.

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

Hersteltests die de uitgever niet vertakken

Twee live CA's met hetzelfde subject en dezelfde sleutel lijken identiek voor elke klant die het origineel vertrouwt. Twee CRL's met hetzelfde nummer maar andere inhoud is hoe klanten stilzwijgend een certificaat accepteren dat u hebt ingetrokken. Voer het herstel uit op een host zonder route naar uw klanten, of in een wegwerp-VM, en publiceer nooit de CRL die de test produceert.

Een test die alleen bewijst dat het archief opent, bewijst niets over uitgifte. De volgorde die telt: vergelijk de vingerafdruk van de herstelde ca.crt met de waarde die u hebt vastgelegd, bevestig dat de serial overeenkomt met wat uw laatst uitgegeven certificaat impliceert, geef één certificaat uit voor een wegwerp-CN en kijk hoe index.txt een regel krijgt, trek dat certificaat vervolgens in en genereer de CRL opnieuw.

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

Met een HSM loopt dezelfde test via de module. Pak de blob uit in het vervangende apparaat, bevestig dat het CA-certificaat dat de module rapporteert overeenkomt met uw vastgelegde vingerafdruk, en laat hem pas daarna ondertekenen. Als de module een eigen objectopslag heeft, moet de inpakking het sleutelobject en zijn label dekken, want het herstellen van de sleutel onder een ander label breekt de configuratie die ernaar wijst.

Storingsmodi die de keuze bepalen

Vijf storingen verklaren het meeste echte verlies. Een vergeten archiefwachtwoordzin zonder onafhankelijke kopie van het geheim maakt het archief tot een baksteen. Eén kopie op één schijf sterft met die schijf, en een controlesom vertelt u nooit of ontsleuteling nog werkt. Certificaten die na de back-updatum zijn ingetrokken, lijken na een herstel weer geldig, dus uw back-upinterval is ook uw blinde vlek voor intrekking. Het herstellen van een oudere serialteller hergebruikt serienummers en verwart caches en CRL-zoekopdrachten die op serial zijn gesleuteld. Een vervangende HSM die de ingepakte blob weigert, maakt van een hardwarewissel een volledige heruitgifte.

Model A gaat slecht maar zichtbaar om met de eerste vier. Model B gaat er goed mee om tot de module of het leveranciersproces faalt. Als uw sleutels exporteerbaar zijn en het team klein is, is het versleutelde archief de eerlijke keuze, gesteund door twee media en een schriftelijke wachtwoordzinprocedure. Als de sleutel niet-extraheerbaar is, hebt u helemaal geen keuze, en het werk verschuift naar het bewijzen van het herstelpad van de leverancier vóór de dag dat u het nodig hebt.

Het model kiezen en plannen

Drie voorwaarden beslechten de beslissing. Kan de sleutel worden geëxporteerd zonder leveranciersproces? Moet een herstel landen op hardware die u nog niet bezit? Hoe lang kan de uitgifte stilstaan terwijl u met de supportdiscussieert? Beantwoord die drie en het model is beslist; al het daarna is planning.

Maak een back-up na elke ondertekeningsceremonie en vóór elke configuratiewijziging, want de configuratie is deel van de toestand. Houd twee kopieën op verschillende media op verschillende plaatsen, één ervan offline, en bewaar het ontsleutelingsgeheim in een ander vertrouwensdomein dan de kopieën. Schrijf de datum van het laatst geslaagde herstel op het back-uprecord. Een back-up die nooit is hersteld, is een hypothese, geen beheersmaatregel.

Bevestig deze vijf punten voordat u het ticket sluit:

• De vingerafdruk van de ca.crt is ergens buiten de back-up vastgelegd.
• index.txt, serial, crlnumber en openssl.cnf zitten allemaal in het archief of de blobsets.
• De bewaring van de wachtwoordzin of de ingepakte sleutel is gedocumenteerd en berust bij iemand anders dan de eigenaar van het archief.
• Een herstel is getest op een geïsoleerde host met één uitgifte en één intrekking.
• De intrekkingskloof die uw back-upinterval impliceert, is schriftelijk aanvaard of verkort.