プライベートCAのバックアップ：暗号化アーカイブかHSM鍵バックアップか

暗号化アーカイブかHSMでラップした鍵か。各VPN CAバックアップモデルの復元方法、含めるべき内容、そして実際に耐えられる障害を比較します。

これを大きく左右する問いは、アーカイブをどう暗号化するかではありません。CAの秘密鍵がそもそもコンテナから出られるかです。鍵がファイルなら、CAディレクトリ全体を一つの暗号化ブロブにコピーして数分で終わります。鍵がHSMや、鍵を抽出不可と印すトークンの中にあるなら、そのコピーは存在せず、計画はベンダーのラップとリストアの手順に関する計画になります。どちらのモデルも機能し、失敗の仕方が異なり、耐えられる方の失敗を中心に設計する価値があります。

二つのバックアップモデルが分かれるところ

モデルAはディレクトリのコピーです。OpenSSL形式のCAは作業ディレクトリであり、単一の証明書ではありません：ca.keyまたはcakey.pem、ca.crt、発行データベース、serialとcrlnumberのカウンター、そしてopenssl.cnfです。そのディレクトリを対称暗号で封じ、結果を別の媒体へ移せば、復元は展開・検証・署名です。発行者が必要とするものはすべて一緒に移動し、誰も書いたことを覚えていない何週間分もの失効履歴も含まれます。

モデルBは鍵の封じ込めです。鍵はPKCS#11モジュール内で生成され、抽出不可と印されますが、モジュールはバックアップ用にラップできても、どのプロセスも生のバイトを読むことはありません。バックアップは、正しい順序で復元すべき二つの成果物になります：そのモジュールファミリーだけが開けるラップされた鍵ブロブと、データベース・設定・証明書の平文コピーです。

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

比較の対象は、どちらが抽象的に強いかではありません。実際に起きている人たちとともに、午前2時にチームが復元できるのはどちらかです。誰も復号できないアーカイブと、誰も試していないHSMブロブは同じくらい役に立ちません。違いは、アーカイブの失敗はパスワードマネージャーに現れ、HSMの失敗はサポート契約の中に隠れることです。

すべてのCAバックアップに含めるべきもの

どちらのモデルも同じレコード群を必要とします。OpenSSL CAでは、index.txtが発行済み証明書ごとに一行、状態・有効期限・serial・サブジェクトを記録し、続いてindex.txt.attr、次に発行するserialを保持するserial、次のCRL番号を保持するcrlnumber、そして実際にCAが動くdir・policy・default_daysを持つopenssl.cnfです。openssl-caのマニュアルが、各カウンターが何を制御するかを説明しています。easy-rsaは同じデータをpki/の下に置き、varsファイルが証明書のフィールドを決めます。

鍵と証明書は再構築できない部分です。データベースは記憶から再現できない部分です。index.txtを省いても新しい証明書には署名できますが、それがまさに罠で、証明書が失効したかを顧客が初めて尋ねたときに、欠けていることに気づきます。CAのフィンガープリントをバックアップの外に記録し、復元を復元したばかりのファイルではなく信頼できる値と比較してください。

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

発行者を分岐させない復元テスト

同じサブジェクトと同じ鍵を持つ二つの稼働中のCAは、原本を信頼するすべてのクライアントから同一に見えます。同じ番号で内容の異なる二つのCRLは、クライアントが失効させた証明書を静かに受け入れる仕組みです。復元はクライアントへの経路がないホストか使い捨てのVMで実行し、テストが生成したCRLは決して公開しないでください。

アーカイブが開くことだけを示すテストは、発行について何も証明しません。意味のある順序は次のとおりです：復元したca.crtのフィンガープリントを記録した値と比較し、serialが最後に発行した証明書の示す値と一致することを確認し、使い捨てのCN用に証明書を一枚発行してindex.txtに行が増えるのを見届け、その証明書を失効させてCRLを再生成します。

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

HSMでは同じテストをモジュール経由で行います。ブロブを交換装置に展開し、モジュールが報告するCA証明書が記録したフィンガープリントと一致することを確認し、それから初めて署名させます。モジュールが独自のオブジェクトストアを持つ場合、ラップは鍵オブジェクトとそのラベルを覆う必要があります、別のラベルで鍵を復元すると、それを指す設定が壊れるからです。

選択を決める故障モード

五つの故障が実際の損失の大半を説明します。秘密の独立したコピーがないままアーカイブのパスフレーズを忘れると、アーカイブはレンガになります。一台のディスク上の単一コピーはそのディスクとともに死に、チェックサムは復号がまだ機能するかを教えてくれません。バックアップ日以降に失効した証明書は、復元後に再び有効に見えるので、バックアップ間隔は失効の盲点でもあります。古いserialカウンターを復元するとserial番号が再利用され、serialでキー付けされたキャッシュやCRL検索が混乱します。ラップされたブロブを拒否する交換用HSMは、ハードウェア交換を完全な再発行に変えます。

モデルAは最初の四つに下手だが目に見える形で対処します。モデルBはモジュールやベンダーのプロセスが失敗するまでうまく対処します。鍵がエクスポート可能でチームが小さければ、暗号化アーカイブが正直な選択で、二つの媒体と書面のパスフレーズ手順に支えられます。鍵が抽出不可なら選択の余地はまったくなく、作業は必要になる日より前にベンダーの復元経路を証明することへ移ります。

モデルの選択とスケジュール

三つの条件が決定を下します。鍵はベンダーのプロセスなしでエクスポートできますか。復元はまだ所有していないハードウェアに着地させる必要がありますか。サポートと議論している間、発行をどれだけ止められますか。この三つに答えればモデルは決まり、その後のすべてはスケジュールです。

署名セレモニーの後、および設定変更の前にバックアップを取ってください、設定は状態の一部だからです。異なる場所の異なる媒体に二つのコピーを置き、一つはオフラインにし、復号秘密はコピーとは別の信頼ドメインで保管します。最後に復元が成功した日付をバックアップ記録に書きます。一度も復元されていないバックアップは仮説であり、統制ではありません。

チケットを閉じる前に、次の五つを確認してください：

  • ca.crtのフィンガープリントがバックアップの外のどこかに記録されている。
  • index.txt、serial、crlnumber、openssl.cnfがすべてアーカイブまたはブロブ集合の中にある。
  • パスフレーズまたはラップされた鍵の保管が文書化され、アーカイブの所有者以外が保持している。
  • 隔離されたホストで一回の発行と一回の失効を伴う復元がテストされている。
  • バックアップ間隔が示す失効の空白が書面で受け入れられるか、短縮されている。

関連記事