質問とシナリオ
通常の複製ステートマシンは通常、ノードが積極的に異なるコンテンツを偽造することなく、クラッシュする、パケットを失う、または再起動することを前提としています。このコントロールプレーンは証明書、権限、およびルートを管理するため、侵害されたノードが異なるピアに矛盾するログを送信したり、別のIDになりすましたりする可能性があります。脅威モデルから始めて、Raft、認証、およびビザンチンプロトコルがそれぞれ何を解決するのかを説明してください。
面接官がテストしていること
- 候補者がクラッシュ障害、ネットワーク分断、悪意のあるノード、盗まれたIDキーを区別できるか？
- Raft の安全性に関する前提条件、クォーラムの交差性、およびビザンチンプロトコルに伴う追加の通信コストやレプリカコストを理解しているか？
- 署名、メンバーシップ、監査、キーローテーション、および復旧をシステム境界に含めることができるか？
- 暗号化や過半数投票をビザンチン耐性の証明として扱うのを避けられるか？
最初に確認すべき明確化のための質問
攻撃者がいくつのノードを制御できるか、IDを偽造できるか、ピアが信頼できるキーを持っているか、そして一貫性と可用性のどちらがより重要かを尋ねます。コントロールプレーンの状態の価値、人手による承認、メンバーシップ変更の頻度、リージョン間レイテンシを明確にします。ハードウェアで保護されたキーを持つ管理されたクラスターではクラッシュ障害耐性だけで十分な場合がありますが、信頼できないサプライチェーンや運用者が関与すると答えが変わります。
30秒の回答フレームワーク
まず障害モデルと保護対象の不変条件を書き出します。Raft は非悪意の障害を想定しており、管理されたクラスターでのクラッシュ耐性に適しています。認証はメッセージが特定のキーから送信されたことを証明しますが、保持者が誠実であることまでは証明しません。いくつかのノードが矛盾する値を送信できる場合は、定められた障害上限の下で安全なビザンチンプロトコルを選択し、より多くのレプリカ、認証付きブロードキャスト、タイムアウト、およびキー操作コストを受け入れます。分離、キー保護、人手による承認でリスクを十分に低減できる場合は、Raft を維持し、それがカバーしない内容を文書化します。
ステップバイステップの詳細解説
- 障害モデルを明示する。 クラッシュ、オミッション、ネットワーク分断、および能動的な悪意ある障害を区別します。結託、ID偽造、メッセージ遅延、またはディスクの改ざんが可能かどうかを記述します。このモデルがなければ、プロトコルの比較は無意味です。
- 安全性の不変条件を定義する。 例としては、誠実なレプリカが2つの矛盾する構成をコミットしないこと、失効のロールバックがないこと、監査可能なキー公開などがあります。可用性、ファイナリティ、および復旧目標は個別に設定します。
- 通常の合意形成の前提条件を確認する。 Raft はリーダー、ログ照合、過半数コミットを使用してクラッシュに対処します。有効なIDを持つノードが異なるピアに異なるコンテンツを送信することを防ぐことはできません。TLS はトランスポートを保護しますが、悪意のあるエンドポイントは保護しません。
- ビザンチンのコストを評価する。 認証のない古典的な口頭メッセージモデルでは、f 個のビザンチンノードを許容するためにより高いレプリカ上限が必要です。認証付きプロトコル、閾値署名、および信頼できるハードウェアはエンジニアリング上のトレードオフを変化させますが、障害上限やメンバーシップの前提条件を排除するものではありません。
- 境界を制御する。 ビザンチンプロトコルを使用する場合でも、メンバーシップの制限、キーのローテーションと失効、コントロールプレーンとデータプレーンの分離、証拠の保持、安全な復旧の準備を行います。プロトコルは参加者を制約するものであり、データベースを直接編集する管理者を制約するものではありません。
- 脅威の観点から検証する。 フォークしたメッセージ、偽造された署名、リプレイされた構成、遅延したクォーラム応答、ノードの復旧を注入します。不変条件、監査証拠、および復旧パスを確認します。障害訓練によって、選択したプロトコルが実際の制限を満たしていることを実証する必要があります。
質の高い模範解答
単にクラスターが複数リージョンにまたがっているという理由だけでビザンチン障害耐性を選択することはありません。まず攻撃者を定義します。ノードがクラッシュするかネットワーク障害を起こすだけなら、Raft のリーダー、ログ照合、過半数コミットで十分です。有効なキーを持つノードが異なるレプリカに矛盾する構成を送信できる場合、認証付きトランスポートと過半数投票だけでは誠実さは証明されません。
価値の高いコントロールプレーンの場合、f、メンバーシップルール、矛盾のないコミット、および元に戻せない失効を不変条件として定義します。次に、その f に対して安全性を保つ認証付きビザンチンプロトコルを選択します。レプリカ数、署名検証、レイテンシ、キー操作をリスクと比較検討します。分離、ハードウェアキー、2人承認、および読み取り専用の復旧によって悪意あるノードのリスクを許容範囲内に抑えられる場合は、Raft を維持し、カバーされない脅威を記録します。参考文献には Lamport のビザンチン将軍問題に関する研究、Raft の論文、およびその形式仕様が含まれます。
よくある間違い
- ノードが能動的に嘘をついているかどうかを明示せずに、分断やクラッシュをビザンチン障害と呼ぶこと。
- TLS、署名、または過半数だけで、有効な認証情報を持つ悪意のあるノードを防げると想定すること。
- 認証モデル、結託の上限、メンバーシップ、およびキー保護を無視して、単一のレプリカ数のみを回答すること。
- プロトコルのメッセージについて議論しながら、管理者、データベース、バックアップ、および復旧バイパスを無視すること。
- 不変条件、攻撃訓練、およびリスク閾値を「より安全」という曖昧な表現に置き換えること。
フォローアップ質問と回答
3ノードのクラスターで1つのビザンチンノードを許容できますか？
プロトコルと認証モデルを指定しない限り判断できません。認証のない古典的な口頭メッセージモデルでは、より高いレプリカ上限が必要です。認証付きプロトコル、信頼できるハードウェア、および部分同期によって条件が変わります。モデルを明示し、その上で f、クォーラム、および安全性の論拠を述べてください。
過半数投票が悪意のある動作を自動的に解決しないのはなぜですか？
悪意のあるノードは、異なる観察者に異なる値を送信したり、論理的な役割になりすましたりできるためです。過半数が意味を持つのは、メッセージ認証、ビュー変更、証拠の伝播、およびクォーラムの交差性がプロトコルの前提条件を満たしている場合のみです。
どのような場合に Raft を使い続けるべきですか？
ノードとキーが管理された境界内にあり、クラッシュやネットワーク障害が支配的で、手動復旧が許容される場合、Raft の方がシンプルで検証も容易です。メンバーシップの承認、キーローテーション、監査、および障害訓練を追加し、悪意のあるノードはその保証範囲外であることを明記します。