暗号化キーを管理すべきバックアップ層はどれか：クライアント、リポジトリ、それともオフサイトターゲット？

ほとんどのホームサーバーのバックアップでは、バックアップを読み取るために必要な暗号化をバックアップアプリケーションまたはクライアントが管理し、オフサイトストレージプロバイダーの暗号化は追加レイヤーとして扱うべきです。これにより、クラウドやリモートストレージが侵害されてもバックアップ内容が自動的に露出することを防ぎながら、重複排除、検証、効率的なデータ復元を引き続き実行できるバックアップ形式を維持できます。

重要なのは、単に「クライアント側暗号化かサーバー側暗号化か」ではありません。復号用シークレットをどの障害ドメインが管理するのかを決める必要があります。キーがソースサーバーにしか存在しない場合、停止したソースやランサムウェアに暗号化されたソースによって、復旧可能性が失われるおそれがあります。オフサイトターゲットが唯一の意味のあるキーを管理している場合、ターゲットの運用者や侵害されたターゲットアカウントが、引き続き信頼境界内に留まる可能性があります。最適な設計では、バックアップデータ、リポジトリ認証情報、復旧キーを分離します。

暗号化を配置できる場所は3つある

「暗号化されたバックアップ」という表現には、複数のアーキテクチャが隠れています。バックアップツールがファイルを認識する前に、ソースファイルを暗号化できます。バックアップツールは、ローカルまたはリモートストレージにオブジェクトを送信する前に、リポジトリ形式を暗号化できます。または、保存先のストレージシステムがデータを受け取り、独自のキー管理レイヤーを使用して保存時に暗号化することもできます。

リポジトリレベルの暗号化は通常、最適なデフォルトです

最新のバックアップツールは、リポジトリ形式の一部としてデータを暗号化するよう設計されています。Resticの暗号化ドキュメントでは、暗号化をリポジトリの主要機能として扱い、複数のアクセスキーやパスワードに対応しています。同様にKopiaは、ファイルシステム、S3、クラウドオブジェクトストレージなどのストレージバックエンド上に、リポジトリが暗号化と重複排除を追加するものだと説明しています。

Borgでは、信頼モデルが特に明確に示されています。そのセキュリティドキュメントでは、クライアント環境は信頼できる一方、リポジトリは敵対的である可能性を前提としています。Borgはローカルで暗号化するため、リモートリポジトリに平文ファイルや暗号化されていないバックアップキーが送信されることはありません。

この方式は、バックアップの作成中もバックアップアプリケーションが元のファイルを参照できるため、ホームNASに適しています。暗号化の前または暗号化と同時に、チャンク分割、重複排除、圧縮、スナップショットメタデータの処理、検証、選択的な復元を実行できます。保存先には、通常の読み取り可能なファイルではなく、暗号化されたリポジトリオブジェクトが送信されます。

リポジトリキーとストレージ認証情報を混同しない

クラウドバケットのアクセスキー、SFTP秘密鍵、リモートNASのパスワード、バックアップ復号キーは、自動化スクリプトがそれらすべてを必要とする場合でも、それぞれ異なるシークレットです。ストレージ認証情報が答えるのは「このクライアントはリポジトリオブジェクトを読み書きしてよいか」です。リポジトリキーが答えるのは「これらのオブジェクトをバックアップデータに復号できるか」です。

インシデント発生時には、この2つを分離することが重要です。書き込み可能なバケット認証情報を盗んだ攻撃者が、それだけでリポジトリの復号シークレットまで入手できるべきではありません。逆に、バックアップのパスフレーズを知っていても、オフサイトストレージのアカウントに対する管理者アクセスまで必ずしも取得できるとは限りません。

暗号化された復元に必要なすべてのキーを確認するためのZimaSpaceガイドは、リポジトリへのアクセス、バックアップの暗号化、保存先ストレージ、コンテナのシークレット、アプリケーションレベルのシークレットを、それぞれ独立した復旧依存関係として整理しているため、役立つ補足資料です。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

クライアント側での暗号化は、対象が限定された高機密データに最適

バックアップアプリケーションが読み取る前にファイルを暗号化することは、特定のデータセットを通常のバックアップツールや管理者からも完全に不透明な状態に保つ必要がある場合に有効です。たとえば、小規模な法務アーカイブ、エクスポートしたパスワードデータベース、秘密鍵バンドル、またはクライアントが管理する暗号化コンテナなどが該当します。

その代償として、暗号化を早い段階で行うと、バックアップシステムが本来活用できる構造が隠れてしまう可能性があります。変更されたファイルがすべて完全に異なる暗号化済みの出力になると、圧縮や重複排除の効果が低下することがあります。ファイルを細かく閲覧する場合も、まず暗号化されたオブジェクトを復元し、その後別のツールでロックを解除するという 2 段階の復元になる可能性があります。

そのため、データセット全体を事前に暗号化する方式は、ネイティブで認証付きリポジトリ暗号化に対応したバックアップツールを使う方式に比べ、一般的なホームバックアップの構成としては通常弱くなります。データの一部に対して第 2 の信頼境界を意図的に設ける必要がある場合に使用してください。

オフサイトのサーバー側暗号化が保護するのはストレージであり、バックアップ全体の信頼モデルではない

クラウドオブジェクトストレージでは、通常、保存データを暗号化します。たとえば Amazon S3 はデフォルトでサーバー側暗号化を適用し、AWS 管理または顧客管理の KMS キーに対応しています。そのSSE-KMS のドキュメントでは、S3 が保存先で暗号化を実行し、AWS KMS がキーと権限を管理する仕組みが説明されています。

Backblaze B2 も、プロバイダー管理の SSE-B2 と顧客管理の SSE-C に対応しています。そのサーバー側暗号化のドキュメントでは、SSE が保存中のファイルデータを保護すること、また顧客管理の SSE-C キーを失うとデータを復元できなくなることが説明されています。

サーバー側暗号化には価値があります。物理メディアやストレージインフラの保護に役立ち、顧客管理の KMS ポリシーによって強力な組織的制御を実現できます。しかし、認証済みのストレージリクエストが届くたびに対象サービスがデータを復号できるのであれば、その対象サービスは依然として機密性の境界内にあります。これは、プロバイダーに届く前にすでに暗号化されていた Borg、restic、Kopia のリポジトリをアップロードする場合とは異なります。

多層防御としてオフサイト暗号化を使用する

実際の答えは、多くの場合「両方」です。バックアップアプリケーションでアップロード前にリポジトリの内容を暗号化し、そのうえで保存先の通常の保存時暗号化も別の管理手段として有効にしておきます。2つの層は異なる事象から保護します。

キーは保護対象のマシンより長く存続しなければならない

キーの配置に関する最も重要なルールは単純です。バックアップ対象のサーバー上に、暗号化秘密情報の唯一の復旧コピーを保管しないでください。 Borgの最新のリポジトリ初期化ガイドでは、Borgキーのバックアップをリポジトリとバックアップを作成するシステムの両方の外部に保管することを明示的に推奨しています。

同じ考え方は、resticのパスワード、Kopiaのリポジトリパスワード、ageキー、LUKSの復旧情報、クラウドKMSの管理情報、アプリケーションのマスターキーにも当てはまります。暗号化されたリポジトリが完全でも、復号に必要な唯一の秘密情報が故障したブートドライブとともに失われれば役に立ちません。

家庭や小規模ラボでは、NASが稼働していなくても依存しない、オフラインまたは別の認証情報システムに少なくとも1つの復旧コピーを保管してください。そのうえで、クリーンなマシンへの復元をテストします。リポジトリを開くために一度も使われていない、書き留めただけのパスワードは、文書化の証拠であって、復旧可能性の証拠ではありません。

一般的なホームサーバー構成では、どの層がキーを管理すべきか

ホームNASからオブジェクトストレージへのバックアップ

データがNASから出る前に、restic、Borg、Kopia、または同等のバックアップツールでネイティブのリポジトリ暗号化を使用します。リポジトリのキーやパスフレーズはNASの外部に保管してください。多層防御として、バケット暗号化は有効にしておきます。これにより、クラウド側の保存先が唯一の機密性管理手段になることを防げます。

ホームNASから友人のリモートサーバーへのバックアップ

平文キーが友人のサーバー上に存在しない、クライアント側またはリポジトリ側の暗号化を優先してください。リモートホストには、内容を判別できないリポジトリオブジェクトを保存させ、書き込み権限を限定できます。リモートマシンの物理的・管理上の制御が別の障害ドメインに属するため、これは特に有効です。

同じ家に保管されたローカルバックアップディスク

ディスクを紛失・盗難された場合でも、リポジトリの暗号化によって機密性は保護されます。バックアップディスクのフルディスク暗号化は有用な第2層になり得ますが、ディスクのロック解除キーがバックアップリポジトリへの唯一のアクセス手段にならないようにしてください。

プロバイダーの復旧機能を備えたマネージドクラウドバックアップ

プロバイダー管理の暗号化は、平文の信頼境界の外にプロバイダーを置くことよりも、簡便さやベンダー支援による復旧を重視する場合には合理的です。ただし、これはゼロ知識型のクライアント側暗号化とは異なるセキュリティ上の判断です。

すべてのバックアップ用シークレットを1つの自動化ファイルに入れない

自動実行のバックアップジョブには認証情報が必要ですが、利便性によってセキュリティ境界が崩れる可能性があります。Resticの自動化に関するガイダンスでは、パスワードの提供方法によって認証情報が露出する可能性があると警告し、パスワードファイルを慎重に保護することを推奨しています。

ホームサーバーでは、実用上可能な範囲で、少なくとも次の役割を分離します。

• バックアップ先にアクセスできる、権限を限定した認証情報。
• リポジトリの復号パスワードまたはキー。
• そのパスワードまたはキーのオフライン復旧用コピー。
• 保持ポリシー、バケット、リモートアカウントを削除できる管理者認証情報。

この切り分けは、特定の1つのシークレットをファイル、環境変数、パスワードマネージャー、ハードウェアトークン、KMSのどれに保存するかを決めることより重要です。アーキテクチャでは、盗まれた自動化用認証情報1つによって、平文の読み取り、リポジトリの削除、唯一の復旧キーの破棄が同時に行われないようにする必要があります。

暗号化は不変性や復元テストの代わりにはなりません

機密性、完全性、削除耐性、復旧可能性は、それぞれ別の目標です。暗号化されたリポジトリでも削除される可能性があります。不変バケットにも、復号キーを失ったバックアップが含まれる可能性があります。正常に完了したバックアップジョブでも、復元時に失敗する可能性があります。

ZimaSpaceによる、VMバックアップ向けリモートバックアップサーバーとクラウドオブジェクトストレージの比較も同じ運用上の結論に達しています。実際の復旧がテストされているかどうかに比べれば、ターゲットの呼び方は重要ではありません。

意思決定マトリックス

最終結論

ほとんどのセルフホスト型バックアップシステムでは、コンテンツ暗号化の境界をバックアップクライアントまたはリポジトリ形式に担わせ、オフサイトターゲットには保存時の暗号化を追加で行わせるのがよいでしょう。これにより、重複排除や検証などのバックアップ機能を維持しながら、リモートストレージシステムに平文を信頼して預ける必要性を減らせます。

鍵管理計画が完了するのは、ソースサーバー、ストレージターゲット、通常使用する管理者ワークステーションを失っても、復号用の秘密情報が残る場合だけです。バックアップを復元可能と判断する前に、クリーンなマシンからその前提をテストしてください。

よくある質問

ホームバックアップには、クラウドのサーバー側暗号化で十分ですか？

保存データを保護できますが、通常はストレージサービスを復号の信頼境界内に置くことになります。プロバイダーや盗まれたストレージ認証情報だけで平文にアクセスできる状態を避けたい場合は、バックアップ固有の暗号化も使用してください。

リポジトリの鍵をリポジトリ内に保管すべきですか？

一部のバックアップ形式では、暗号化された鍵オブジェクトをリポジトリに保存しますが、復旧には強力なパスフレーズなど、別の秘密情報が必要です。リポジトリとソースシステムの両方の外部に、独立した復旧用マテリアルを保管してください。

バックアップ前にファイルを暗号化すると、セキュリティは向上しますか？

機密性の高い一部のデータに対して、追加の信頼境界を設けられます。ただし、バックアップツールがデータを認識する前にすべてを暗号化すると、重複排除、圧縮、メタデータの可視性、復元の利便性が低下する可能性があります。

最も重要な鍵管理テストは何ですか？

元のNASが完全に利用できないものとして、クリーンなマシンから復元します。すべての認証情報を見つけて代表的なデータを復号できないなら、鍵の計画は不完全です。