Backup einer privaten CA: verschlüsseltes Archiv oder HSM-Schlüsselbackup

Die Frage, die das meiste hier entscheidet, ist nicht, wie Sie das Archiv verschlüsseln. Sie ist, ob Ihr privater CA-Schlüssel seinen Container überhaupt verlassen kann. Ist der Schlüssel eine Datei, können Sie das gesamte CA-Verzeichnis in einen verschlüsselten Blob kopieren und sind in Minuten fertig. Lebt er in einem HSM oder einem Token, das den Schlüssel als nicht extrahierbar markiert, existiert diese Kopie nicht, und Ihr Plan wird zu einem Plan über das Umhüllungs- und Wiederherstellungsverfahren des Herstellers. Beide Modelle funktionieren, sie scheitern unterschiedlich, und der Ausfall, den Sie überleben können, ist der, um den herum es sich zu entwerfen lohnt.

Wo sich die beiden Backup-Modelle trennen

Modell A ist Verzeichniskopie. Eine CA im OpenSSL-Stil ist ein Arbeitsverzeichnis, kein einzelnes Zertifikat: ca.key oder cakey.pem, ca.crt, die Ausstellungsdatenbank, die Zähler serial und crlnumber und openssl.cnf. Versiegeln Sie dieses Verzeichnis mit einer symmetrischen Chiffre, bewegen Sie das Ergebnis auf ein zweites Medium, und Wiederherstellung bedeutet entpacken, prüfen, signieren. Alles, was der Aussteller braucht, reist zusammen, einschließlich Wochen an Sperrhistorie, von der sich niemand erinnert, sie geschrieben zu haben.

Modell B ist Schlüsselbindung. Der Schlüssel wird in einem PKCS#11-Modul erzeugt und als nicht extrahierbar markiert; das Modul kann ihn für ein Backup umhüllen, aber kein Prozess liest jemals die Rohbytes. Ihr Backup sind dann zwei Artefakte, die in der richtigen Reihenfolge wiederhergestellt werden müssen: ein umhüllter Schlüsselblob, den nur diese Modulfamilie entpacken kann, plus eine einfache Kopie der Datenbank, der Konfiguration und der Zertifikate.

Der Vergleich dreht sich nie darum, welches Modell abstrakt stärker ist. Er dreht sich darum, welches Ihr Team um 2 Uhr nachts mit den Leuten wiederherstellen kann, die tatsächlich wach sind. Ein Archiv, das niemand entschlüsseln kann, und ein HSM-Blob, den niemand getestet hat, sind gleichermaßen nutzlos. Der Unterschied ist, dass der Archivausfall in einem Passwortmanager auftaucht und der HSM-Ausfall sich in einem Supportvertrag versteckt.

Was jedes CA-Backup enthalten muss

Beide Modelle brauchen denselben Datensatz. In einer OpenSSL-CA sind diese Dateien index.txt mit einer Zeile pro ausgestelltem Zertifikat, die Status, Ablauf, Seriennummer und Subject abdeckt, dann index.txt.attr, serial mit der nächsten auszustellenden Seriennummer, crlnumber mit der nächsten CRL-Nummer und openssl.cnf mit dem dir, der policy und den default_days, mit denen Ihre CA tatsächlich läuft. Das openssl-ca-Handbuch erklärt, was jeder dieser Zähler steuert. easy-rsa hält dieselben Daten unter pki/, wobei eine vars-Datei die Zertifikatsfelder bestimmt.

Schlüssel und Zertifikat sind die Teile, die Sie nicht neu bauen können. Die Datenbank ist der Teil, den Sie nicht aus dem Gedächtnis rekonstruieren können. index.txt zu überspringen lässt Sie weiterhin neue Zertifikate signieren, und genau das ist die Falle: Sie merken, dass sie fehlt, wenn ein Client zum ersten Mal fragt, ob ein Zertifikat gesperrt wurde. Notieren Sie den CA-Fingerabdruck außerhalb des Backups, damit eine Wiederherstellung gegen einen Wert verglichen wird, dem Sie vertrauen, und nicht gegen die Datei, die Sie gerade wiederhergestellt haben.

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

Wiederherstellungstests, die den Aussteller nicht aufspalten

Zwei laufende CAs mit demselben Subject und demselben Schlüssel sehen für jeden Client, der dem Original vertraut, identisch aus. Zwei CRLs mit derselben Nummer, aber unterschiedlichem Inhalt sind der Weg, auf dem Clients still ein Zertifikat akzeptieren, das Sie gesperrt haben. Führen Sie die Wiederherstellung auf einem Host ohne Route zu Ihren Clients oder in einer Wegwerf-VM aus, und veröffentlichen Sie niemals die CRL, die der Test erzeugt.

Ein Test, der nur beweist, dass das Archiv aufgeht, beweist nichts über die Ausstellung. Die Sequenz, auf die es ankommt: Vergleichen Sie den Fingerabdruck der wiederhergestellten ca.crt mit dem notierten Wert, bestätigen Sie, dass die Seriennummer zu dem passt, was Ihr zuletzt ausgestelltes Zertifikat impliziert, stellen Sie ein Zertifikat für ein Wegwerf-CN aus und beobachten Sie, wie index.txt eine Zeile gewinnt, sperren Sie dann dieses Zertifikat und erzeugen Sie die CRL neu.

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

Mit einem HSM läuft derselbe Test durch das Modul. Entpacken Sie den Blob in das Ersatzgerät, bestätigen Sie, dass das vom Modul gemeldete CA-Zertifikat zu Ihrem notierten Fingerabdruck passt, und lassen Sie es erst dann signieren. Hat das Modul einen eigenen Objektspeicher, muss die Umhüllung das Schlüsselobjekt und sein Label abdecken, denn die Wiederherstellung des Schlüssels unter einem anderen Label bricht die Konfiguration, die darauf zeigt.

Fehlermodi, die die Wahl entscheiden

Fünf Fehler erklären die meisten realen Verluste. Eine vergessene Archiv-Passphrase ohne unabhängige Kopie des Geheimnisses macht das Archiv zu einem Ziegelstein. Eine einzelne Kopie auf einer Platte stirbt mit dieser Platte, und eine Prüfsumme sagt Ihnen nie, ob die Entschlüsselung noch funktioniert. Nach dem Backup-Datum gesperrte Zertifikate sehen nach einer Wiederherstellung wieder gültig aus, also ist Ihr Backup-Intervall auch Ihr blinder Fleck bei Sperrungen. Die Wiederherstellung eines älteren Serienzählers verwendet Seriennummern erneut und verwirrt Caches und CRL-Abfragen, die auf die Seriennummer schlüsseln. Ein Ersatz-HSM, das den umhüllten Blob ablehnt, macht einen Hardwaretausch zu einer vollständigen Neuausstellung.

Modell A bewältigt die ersten vier schlecht, aber sichtbar. Modell B bewältigt sie gut, bis das Modul oder der Herstellerprozess ausfällt. Sind Ihre Schlüssel exportierbar und ist das Team klein, ist das verschlüsselte Archiv die ehrliche Wahl, gestützt auf zwei Medien und ein schriftliches Passphrase-Verfahren. Ist der Schlüssel nicht extrahierbar, haben Sie gar keine Wahl, und die Arbeit verlagert sich darauf, den Wiederherstellungspfad des Herstellers zu belegen, bevor Sie ihn brauchen.

Das Modell wählen und einplanen

Drei Bedingungen entscheiden. Lässt sich der Schlüssel ohne Herstellerprozess exportieren? Muss eine Wiederherstellung auf Hardware landen, die Sie noch nicht besitzen? Wie lange kann die Ausstellung stehen, während Sie mit dem Support streiten? Beantworten Sie diese drei, und das Modell ist entschieden; alles danach ist Planung.

Machen Sie ein Backup nach jeder Signaturzeremonie und vor jeder Konfigurationsänderung, denn die Konfiguration ist Teil des Zustands. Halten Sie zwei Kopien auf verschiedenen Medien an verschiedenen Orten, eine davon offline, und bewahren Sie das Entschlüsselungsgeheimnis in einer anderen Vertrauensdomäne als die Kopien auf. Schreiben Sie das Datum der letzten erfolgreichen Wiederherstellung auf den Backup-Datensatz. Ein Backup, das nie wiederhergestellt wurde, ist eine Hypothese, keine Kontrolle.

Bevor Sie das Ticket schließen, bestätigen Sie diese fünf Punkte:

• Der Fingerabdruck der ca.crt ist irgendwo außerhalb des Backups notiert.
• index.txt, serial, crlnumber und openssl.cnf liegen alle im Archiv oder im Blob-Satz.
• Die Verwahrung der Passphrase oder des umhüllten Schlüssels ist dokumentiert und liegt bei jemand anderem als dem Eigentümer des Archivs.
• Eine Wiederherstellung wurde auf einem isolierten Host mit einer Ausstellung und einer Sperrung getestet.
• Die Sperrlücke, die Ihr Backup-Intervall impliziert, ist schriftlich akzeptiert oder verkürzt.