16.4. 障害復旧に関する考慮事項
本項では、発生する可能性のある障害状況と、それぞれの状況に対応する手順について説明します。その他の状況は、検出または想定される可能性の高い状況として追加されます。
16.4.1. クライアントマシンの損失
Tang サーバーを使用してディスクパーティションを復号化するクラスターノードが失われた場合は、障害ではありません。マシンの盗難、ハードウェアの障害、別の損失のシナリオが発生したのかは重要ではありません。ディスクは暗号化されて、回復不能とみなされます。
ただし、盗難が発生した場合は、Tang サーバーのキーを予防的にローテーションし、残りのすべてのノードのキーを再設定して、後で Tang サーバーに不正アクセスできた場合に備え、ディスクが回復不能なままにしておくことが懸命です。
この状況から回復するには、ノードを再インストールするか、置き換えます。
16.4.2. クライアントネットワーク接続が失われた場合のプランニング
個々のノードに対してネットワーク接続が失われると、無人で起動できなくなります。
ネットワーク接続が失われる可能性のある作業を計画している場合には、オンサイトの技術者に、手動で使用するパスフレーズを公開し、その後にキーを無効にしてローテーションすることができます。
手順
ネットワークが利用できなくなる前に、以下のコマンドでデバイス
/dev/vda2の最初のスロット-s 1で使用されているパスワードを表示します。$ sudo clevis luks pass -d /dev/vda2 -s 1
以下のコマンドでその値を無効にし、新しい起動時のパスフレーズを無作為に再生成します。
$ sudo clevis luks regen -d /dev/vda2 -s 1
16.4.3. ネットワーク接続の予期しない損失
ネットワークが予期せず中断され、ノードが再起動する場合には、以下のシナリオを検討してください。
- いずれかのノードがまだオンラインのままである場合は、ネットワーク接続が復元されるまで再起動しないようにしてください。これは単一ノードクラスターには適用されません。
- ノードは、ネットワーク接続が復元されるまで、またはコンソールで設定したパスフレーズを手動で入力するまでノードはオフラインのままになります。このような状況では、ネットワーク管理者はアクセスを再確立するためにネットワークセグメントを再設定できる可能性がありますが、これは NBDE の意図に反します。つまり、ネットワークアクセスがないと起動できなくなります。
- ノードへのネットワークアクセスがないと、ノードの機能およびブート機能に影響を与えることが予想されます。ノードが手動の介入で起動されたとしても、ネットワークアクセスがないため、ノードは事実上役に立たなくなります。
16.4.4. ネットワーク接続の手動による回復
オンサイト技術者は、ネットワーク回復のために、やや複雑で手動での作業を多用するプロセスも利用できます。
手順
- オンサイト技術者は、ハードディスクから Clevis ヘッダーを抽出します。BIOS のロックダウンによっては、ディスクを削除してラボマシンにインストールする必要がある場合があります。
- オンサイトの技術者は、Tang ネットワークへの正当なアクセス権があるスタッフに Clevis ヘッダーを送信し、そのスタッフが復号化を実行します。
- Tang ネットワークへのアクセスを制限するる必要があるため、技術者は VPN または他のリモート接続経由でそのネットワークにアクセス不可にする必要があります。同様に、技術者はこのネットワーク経由でリモートサーバーにパッチを適用して、ディスクを自動的に復号化できません。
- ファイルシステムはディスクを再インストールし、それらが提供するプレーンテキストのパスフレーズを手動で入力します。
- マシンは、Tang サーバーに直接アクセスしなくても、正常に起動します。インストールサイトからネットワークアクセスのある別のサイトにキー情報を転送する場合は注意して行ってください。
- ネットワーク接続が回復すると、暗号鍵がローテーションされます。
16.4.5. ネットワーク接続の緊急復旧
ネットワーク接続を手動で回復できない場合には、以下の手順を検討してください。ネットワーク接続を回復する他の方法が利用できる場合には、これらの手順は推奨されないことに注意してください。
- この方法は、信頼性の高い技術者のみが実行する必要があります。
- Tang サーバーキー鍵情報をリモートサイトに送付することは、キー情報の違反とみなされ、すべてのサーバーでキーをもう一度生成して再暗号化する必要があります。
- この方法は、それ以外方法がない究極の場合に利用するようにしてください。あるいは、その実行可能性を実証するための概念実証の回復方法として使用する必要があります。
- 同様に極端で、理論的には可能ですが、問題のサーバーに無停電電源装置 (UPS) で電力を供給し、サーバーをネットワーク接続のある場所に転送してディスクを起動および復号化し、サーバーをバッテリー電源のある元の場所に復元して操作を続行します。
- バックアップの手動パスフレーズを使用する場合は、障害が発生する前にこれを作成する必要があります。
- 攻撃シナリオが TPM と Tang とスタンドアロンの Tang インストールと比較すると、より複雑になるので、同じ方法を使用する場合には、障害復旧プロセスも複雑になります。
16.4.6. ネットワークセグメントの喪失
ネットワークセグメントが失われ、Tang サーバーが一時的に使用できなくなると、次のような結果になります。
- OpenShift Container Platform ノードは、他のサーバーが利用可能な場合に通常通りに起動を続けます。
- 新規ノードは、ネットワークセグメントが復元されるまでその暗号化キーを確立できません。この場合は、高可用性および冗長性を確保するために、地理的に離れた場所への接続を確保します。これは、新規ノードのインストールや既存ノードの再割り当て時に、その操作で参照している Tang サーバーがすべて利用できる必要があるためです。
5 つの地理的リージョンに各クライアントが最寄りの 3 つのクライアントに接続されている場合など、幅広いネットワークのハイブリッドモデルを検討する価値があります。
このシナリオでは、新規クライアントが到達可能なサーバーのサブセットを使用して暗号鍵を設定できます。tang1、tang2 および tang3 サーバーのセットで、tang2 が到達できなくなった場合にクライアントは tang1 および tang3 で暗号鍵を設定して、後ほど完全なセットを使用して再確立できます。これには、手動による介入、またはより複雑な自動化のいずれかが必要になる場合があります。
16.4.7. Tang サーバーの喪失
同じキー情報が使用されている負荷分散サーバー内の個別の Tang サーバーがなくなると、クライアントからも透過的に確認できます。
同じ URL に関連付けられているすべての Tang サーバー (負荷分散されたセット全体) で一時的に障害が発生すると、ネットワークセグメントの損失と同じと考えることができます。既存クライアントには、事前に設定された Tang サーバーが利用可能な限り、ディスクパーティションを復号化できます。これらのサーバーのいずれかが再びオンラインになるまで、新規クライアントは登録できません。
サーバーを再インストールするか、バックアップからサーバーを復元して、Tang サーバーの物理的な損失を軽減できます。キー情報のバックアップおよび復元プロセスが、権限のないアクセスから適切に保護されていることを確認します。
16.4.8. 危険キー情報の再設定
Tang サーバーの物理的な移動や関連データなど、承認されていないサードパーティーにキーが公開される可能性のある場合は、キーをすぐにローテーションします。
手順
- 影響を受けた情報を保持する Tang サーバーのキーを再生成します。
- Tang サーバーを使用してすべてのクライアントのキーを再生成します。
- 元のキー情報を破棄します。
- マスター暗号化キーが公開されてしまうという意図しない状況を精査します。可能な場合は、ノードをオフラインにし、ディスクを再暗号化します。
同じ物理ハードウェアへの再フォーマットおよび再インストールは時間がかかりますが、自動化およびテストが簡単です。
