第17章 Network-Bound Disk Encryption (NBDE)
17.1. ディスクの暗号化技術について
Network-Bound Disk Encryption(NBDE) を使用すると、マシンの再起動時にパスワードを手動で入力しなくても、物理マシンおよび仮想マシン上のハードドライブのルートボリュームを暗号化できます。
17.1.1. ディスク暗号化技術の比較
エッジサーバーにあるデータのセキュリティーを保護するための Network-Bound Disk Encryption (NBDE) のメリットを理解するには、キー Escrow と Clevis を使用しない TPM ディスク暗号化と、Red Hat Enterprise Linux (RHEL) を実行するシステム上の NBDE を比較します。
以下の表は、脅威モデルや各暗号化ソリューションの複雑さに関して考慮すべきトレードオフを示しています。
| シナリオ | キー Escrow | TPM ディスク暗号化 (Clevis なし) | NBDE |
|---|---|---|---|
| 単一ディスクの盗難からの保護 | X | X | X |
| サーバー全体に対する保護 | X | X | |
| システムはネットワークから独立して再起動できます。 | X | ||
| 定期的なキーの再生成なし | X | ||
| キーはネットワーク経由で送信されることはありません。 | X | X | |
| OpenShift にサポート | X | X |
17.1.1.1. キー Escrow
キー Escrow は、暗号鍵を格納するための従来のシステムです。ネットワーク上の鍵サーバーは、暗号化されたブートディスクがあるノードの暗号化キーを保存して、クエリーされると返します。キー管理、トランスポートの暗号化、および認証が複雑であるため、ブートディスク暗号化は妥当な選択肢ではありません。
Red Hat Enterprise Linux(RHEL) で利用可能ですが、主要な escrow ベースのディスク暗号化の設定および管理は手動のプロセスであり、ノードの自動追加など OpenShift Container Platform 自動化操作には適しておらず、現在 OpenShift Container Platform でサポートされていません。
17.1.1.2. TPM 暗号化
Trusted Platform Module (TPM) ディスク暗号化は、リモートから保護された場所のデータセンターまたはインストールに適しています。dm-crypt and BitLocker などの完全なディスク暗号化ユーティリティーは、TPM バインドキーでディスクを暗号化し、TPM に TPM バンドキーを保存し、ノードのマザーボードにアタッチします。この方法の主な利点は、外部の依存関係がなく、ノードは外部の対話なしにブート時に独自のディスクを復号化できることです。
TPM ディスク暗号化は、ディスクがノードから盗まれて外部で分析される場合に、データが復号化されないように保護んします。ただし、セキュアではない場所では、これは不十分です。たとえば、攻撃者がノード全体を盗んだ場合に、ノードは自身のディスクを復号化するので、ノードの電源を投入した時点でデータを傍受できてしまいます。これは、物理 TPM2 チップを備えたノードと、Virtual Trusted Platform Module(VTPM) アクセスのある仮想マシンに適用されます。
17.1.1.3. Network-Bound Disk Encryption (NBDE)
Network-Bound Disk Encryption(NBDE) は、ネットワーク全体で安全かつ匿名の方法で、暗号鍵を外部サーバーや、サーバーのセットに効果的に関連付けます。これは、ノードが暗号化キーの保存や、ネットワークでの転送を行わない点でキー escrow とは異なりますが、同じように動作します。
Clevis および Tang は、一般的なクライアントおよびサーバーのコンポーネントで、ネットワークがバインドされた暗号化を提供します。Red Hat Enterprise Linux CoreOS(RHCOS) は、Linux Unified Key Setup-on-disk-format(LUKS) と合わせて、これらのコンポーネントを使用して、Network-Bound Disk 暗号化を実現するために root および root 以外のストレージボリュームを暗号化および復号化します。
ノードが起動すると、暗号化ハンドシェイクを実行して事前に定義された Tang サーバーのセットへのアクセスを試みます。必要な数の Tang サーバーに到達できる場合は、ノードはディスクの復号化キーを作成し、ディスクのロックを解除して起動を続行できます。ネットワークが停止したり、サーバーが利用できなくなったりしたことが原因で、ノードが Tang サーバーにアクセスできない場合に、ノードは起動できず、Tang サーバーが再び利用可能になるまで無限に再試行し続けます。この鍵は実質的にはネットワーク内のノードに関連付けられるため、攻撃者が使用されていないデータへのアクセス権を取得しょうとすると、ノードのディスクと、Tang サーバーへのネットワークアクセスを取得する必要があります。
以下の図は、NBDE のデプロイメントモデルを示しています。
以下の図は、リブート時の NBDE の動作を示しています。
17.1.1.4. シークレット共有の暗号化
Shamir のシークレット共有 (sss) は、キーを安全に分割、配布、および再構築するための暗号化アルゴリズムです。このアルゴリズムを使用すると、OpenShift Container Platform は、より複雑なキー保護の組み合わせをサポートすることができます。
複数の Tang サーバーを使用するようにクラスターノードを設定する場合には、OpenShift Container Platform は、sss を使用して指定されたサーバーが 1 つ以上利用可能になると正常に実行される復号化ポリシーを設定します。追加でセキュリティー階層を作成できます。たとえば、OpenShift Container Platform でディスクの復号化に TPM と Tang サーバーの指定リストの 1 つを必要とするポリシーを定義できます。
17.1.2. Tang サーバーディスク暗号化
以下のコンポーネントおよびテクノロジーは、Network-Bound Disk Encryption(NBDE) を実装します。
図17.1 LUKS1 で暗号化したボリュームを使用する場合の NBDE スキーム(luksmeta パッケージは、LUKS2 ボリュームには使用されません)
Tang は、ネットワークのプレゼンスにデータをバインドするためのサーバーです。これにより、ノードが特定のセキュアなネットワークにバインドされると、データが含まれるノードが利用可能になります。Tang はステートレスであり、Transport Layer Security(TLS) または認証は必要ありません。エスクローベースのソリューション (鍵サーバーが暗号鍵をすべて保存し、すべての鍵に関する情報を有する) とは異なり、Tang はノードの鍵と対話することはないため、ノードから識別情報を得ることがありません。
Clevis は、自動復号化用のプラグ可能なフレームワークで、Linux Unified Key Setup-on-disk-format(LUKS) ボリュームの自動ロック解除機能が含まれます。Clevis パッケージはノードで実行され、クライアント側の機能を提供します。
Clevis ピン は、Clevis フレームワークへのプラグインです。ピニングには、以下の 3 つのタイプがあります。
- TPM2
- ディスク暗号化を TPM2 にバインドします。
- Tang
- ディスク暗号化を Tang サーバーにバインドし、NBDE を有効にします。
- Shamir のシークレット共有 (ss)
より複雑な他のピニングの組み合わせを可能にします。これにより、以下のような冗長なポリシーが可能になります。
- これらの 3 つの Tang サーバーのいずれかに到達できる必要があります。
- これら 5 つの Tang サーバーのうち 3 つに到達できる必要があります
- TPM2 と、これらの 3 つの Tang サーバーのいずれかに到達できる必要があります。
17.1.3. Tang サーバーロケーションのプランニング
Tang サーバー環境を計画する時には、Tang サーバーの物理ネットワークおよびネットワークの場所を検討してください。
- 物理的な場所
Tang サーバーの地理的な場所は、不正アクセスや盗難から適切に保護されており、重要なサービスを実行するために必要な可用性があり、アクセスできる場合には、比較的重要ではありません。
Clevis クライアントを使用するノードには、Tang サーバーが常に利用可能である限り、ローカルの Tang サーバーは必要ありません。障害復旧には、その場所に関係なく、Tang サーバーに対して電源とネットワーク接続がいずれも冗長設定されている必要があります。
- ネットワークの場所
Tang サーバーにネットワークアクセスできるノードは、独自のディスクパーティション、または同じ Tang サーバーで暗号化されたその他のディスクを復号化できます。
Tang サーバーのネットワークの場所を選択し、指定のホストからネットワーク接続の有無によって復号化のパーミッションが許可されるようにします。たとえば、ファイアウォール保護を適用して、あらゆるタイプのゲストネットワークやパブリックネットワーク、またはセキュリティーで保護されていない建物のエリアにあるネットワークジャックからのアクセスを禁止できます。
また、実稼働ネットワークと開発ネットワークの間でネットワークを分離します。これにより、適切なネットワークの場所を定義し、セキュリティーの層を追加するのに役立ちます。
ロック解除を行う Tang サーバーを同じリソース (例: 同じ
rolebindings.rbac.authorization.k8s.ioクラスター) にデプロイしないでください。ただし、Tang サーバーおよび他のセキュリティーリソースのクラスターは、複数の追加クラスターおよびクラスターリソースのサポートを有効にする、便利な設定である場合があります。
17.1.4. Tang サーバーのサイジング要件
可用性、ネットワーク、および物理的な場所に関する要件をもとに、サーバー容量の懸念点が決まるのではなく、使用する Tang サーバー数を決定できます。
Tang サーバーは、Tang リソースを使用して暗号化されたデータの状態を維持しません。Tang サーバーは完全に独立しているか、キー情報のみを共有するので、スケーリングが可能です。
以下の 2 つの方法を使用して、Tang サーバーで重要な情報を処理できます。
複数の Tang サーバーが重要な情報を共有します。
- 同じ URL の背後にあるキーを共有する Tang サーバーを負荷分散する必要があります。この設定はラウンドロビン DNS と同様に簡単に実行することも、物理ロードバランサーを使用することもできます。
- 単一の Tang サーバーから複数の Tang サーバーにスケーリングできます。Tang サーバーのスケーリングでは、Tang サーバーがキー情報と同じ URL を共有する場合にノードのキー変更やクライアントの再設定は必要ありません。
- クライアントノードの設定とキーローテーションには Tang サーバー 1 台のみが必要です。
複数の Tang サーバーは独自のキー情報を生成します。
- インストール時に複数の Tang サーバーを設定できます。
- ロードバランサーの背後では個別の Tang サーバーをスケーリングできます。
- クライアントノードの設定またはキーのローテーション時に全 Tang サーバーが利用可能である必要があります。
- クライアントノードがデフォルト設定を使用して起動すると、Clevis クライアントはすべての Tang サーバーに接続します。復号化を続行するには、オンラインにしておく必要のある Tang サーバーはn台のみです。n のデフォルト値は 1 です。
- Red Hat では、Tang サーバーの動作を変更するインストール後の設定をサポートしません。
17.1.5. ロギングに関する考慮事項
Tang トラフィックの集中ロギングは、予期しない復号化要求などを検出できる可能性があるため、便利です。以下に例を示します。
- ブートシーケンスに対応しないパスフレーズの復号化を要求するノード
- 既知のメンテナンスアクティビティー外の復号化を要求するノード (例: 繰り返しキー)
