メインコンテンツまでスキップ

DuoKey MPC クラスター — 3 サイト、サイトあたり 3 ノード

DuoKey MPC KMS は DuoKey 独自の鍵保管クラスターです。すべての鍵は各ノードにまたがる シェア に分割され、各暗号操作はそれらのノード間で 共同で計算 されます。そのため、 単一のノードが完全な鍵を保持することは決してありません。データセンターレベルの 回復性を確保するには、3 つのデータセンターそれぞれに 3 ノード、合計 9 ノード を展開します。

オプションの鍵保管バックエンド

DuoKey MPC KMS は オプション のボールトバックエンドです。鍵の保管はデフォルトで 組み込みの Software Vault が使用されます。展開に必要な場合に MPC クラスターを追加して ください。前提条件 → 鍵の保管 を参照して ください。これは DuoKey 独自 の MPC であり、サードパーティの Sepior TSM ではありません。 したがって、MongoDB、Audit Node、KMaaS ポータル、メッセージキューはいずれも不要 です。 各ノードには Cockpit API が OAuth2 経由でアクセスし、メタデータは PostgreSQL に保持されます。

トポロジーの概要​

DuoKey MPC — 3 つのデータセンターにまたがる 9 ノード
Cockpit APIOAuth2 · 解決 / 鍵操作
DC 1
MPC node 1-1
MPC node 1-2
MPC node 1-3
PostgreSQL鍵メタデータ
DC 2
MPC node 2-1
MPC node 2-2
MPC node 2-3
PostgreSQL鍵メタデータ
DC 3
MPC node 3-1
MPC node 3-2
MPC node 3-3
PostgreSQL鍵メタデータ
分散型: サイト間での共同計算 · アクティブ／パッシブ: PostgreSQL レプリケーション

Cockpit API が MPC クラスターを駆動します。3 つのデータセンターそれぞれで 3 ノードが稼働し、各サイトは鍵メタデータ用の PostgreSQL クラスターに支えられます。

2 つのトポロジー​

9 つのノードをどのように接続するかは、データセンター間の距離によって決まります。

1. 分散クラスター — 単一の 9 ノードクラスター​

  • 各データセンターに 3 ノードを配置した、単一 の論理 MPC クラスターです。
  • すべての鍵操作は 参加ノード間で共同で計算 されるため、サイト間リンクがホットパス上に 存在します。低レイテンシーのメトロ／キャンパスリンク（RTT 2 ms 以下） でのみ実用的です。
  • クラスターのしきい値の範囲内で、サイト全体の喪失 に耐えられます（残る 2 サイトに 9 ノード中 6 ノードが残ります）。
  • 3 つのデータセンターが近接している（同一メトロ圏内の）場合に 使用します。

2. サイトごとのクラスター — アクティブ／パッシブ（3 × 3 ノード）​

  • 各データセンターが 独立した 3 ノードクラスター を実行し、同時にアクティブなのは 1 つの DC のみ です。
  • 鍵メタデータは サイト間でレプリケート されます（PostgreSQL）。Geo ロードバランサー／ LB がトラフィックを次の正常なデータセンターにフェイルオーバーします。
  • 鍵操作は 同一サイト内 で完結するため、より高いサイト間レイテンシーを許容 できます （リージョナル WAN リンク）。
  • データセンターが 地理的に離れている 場合に 使用します。
分散型（9 ノード）サイトごとのアクティブ／パッシブ（3×3）
クラスター9 ノードのクラスター 1 つ3 ノードのクラスター 3 つ
アクティブなサイト3 サイトすべてが参加同時に 1 サイトのみ
サイト間レイテンシー2 ms 以下（ホットパス上）より高くても可（レプリケーションのみ）
サイト喪失への耐性あり（しきい値が許す限り）あり（フェイルオーバー）
最適な用途同一メトロ／キャンパス地理的に離れた DC
どちらを選ぶべきか

3 つのデータセンターが高速なメトロリングで接続されている場合、分散型 クラスターが 単一クラスターとして最も強い回復性を提供します。距離が離れている場合は、鍵操作が WAN を 越えないように サイトごとのアクティブ／パッシブ を使用してください。実測のレイテンシーに 基づき、DuoKey と選択を確認してください。 ネットワーク要件 を参照してください。

サイジング​

LIGHT プロファイル に準拠します。MPC ノードは合計 9 台 （サイトあたり 3 台）で、加えて鍵メタデータ用の PostgreSQL クラスターをサイトごとに配置します。

ロール数ノードあたり vCPUノードあたり RAMディスク
DuoKey MPC ノード9（3 × 3）48 GB20 GB
PostgreSQL（鍵メタデータ、サイトごと）3 / サイト616 GB100 GB SSD
MPC ノードは CPU バウンドです

各鍵操作はノード間で共同計算されるため、MPC 層は CPU バウンドなホットパスになります。 高負荷の DKE では、他の層よりも先にノードの vCPU をスケールする（またはノードを追加する） ようにしてください。

ネットワーク​

フロー送信元宛先ポート
Cockpit API → MPC クラスターCockpit APIMPC ノード（サイトごと）443/TCP（OAuth2）
MPC ノード ↔ ノードMPC ノードMPC ノードDuoKey のリリースに準拠（mTLS/TCP）
MPC ノード → データベースMPC ノードPostgreSQL5432/TCP
PostgreSQL レプリケーションプライマリ ↔ レプリカPostgreSQL ノード（サイト間）5432/TCP
  • MPC ノード間の レイテンシー は極めて重要です。 ネットワーク要件 → データセンター間レイテンシー を参照してください。
  • MPC のトラフィックは 専用のハードニング済み VLAN（セキュアゾーン）に配置してください。
  • すべてのノードで クロックを同期 してください（NTP）。時刻がずれたノードは共同計算から 拒否される可能性があります。

高可用性​

  • しきい値ベースの保管 — 単一のノードも単一の管理者も、完全な鍵を保持することは決して ありません。ノードを 1 つ失っても鍵マテリアルが露出することはありません。
  • 分散型 — データセンター全体を失っても、残る 2 サイトでクラスターの稼働が継続します （しきい値の範囲内）。
  • アクティブ／パッシブ — アクティブなデータセンターを失った場合はパッシブ側に フェイルオーバーします。鍵メタデータはすでにレプリケートされています。
  • サイト内の 3 ノードは、別々のハイパーバイザーホスト／アンチアフィニティグループ に 分散して配置してください。

関連項目​