マルチテナントVPN：共有ゲートウェイ、テナント単位かホスト単位か

誰が顧客を収容し、何がその顧客を別テナントのリソースへ届かせないのかを決めます。これは二つの判断であり、IPsec、WireGuard、メッシュ製品のどれを選んでもどちらにも答えになりません。完璧に確立するトンネルでも、全テナントが互いに到達できる状態を残しかねず、両者を同じものとして扱うレビューは誤った設計を承認してしまいます。まず顧客からリソースへの対応表を書きます：管理者、サポートのアクセス、共有サービス、そして拒否したままにすべき経路です。

製品ではなく対応表から始める

その対応表が最初の成果物であり、以下のどの選択も、それを強制する境界をどこに置くかという判断にすぎません。レビューできる形に保ちます：顧客ごとに一行、共有サービスごとに一行、拒否する経路は明記します。

誰も読めない対応表は、誰も強制しない対応表です。

単一の収容点とそのマッピング問題

各配置は一つの運用上の問いで決まり、表が比較のすべてです。

共有ゲートウェイは収容を集中させ、リスクを一か所に集めます：すなわち、テナントIDとそのポリシーの結び付きです。グループやトンネルアドレスは正しいリソース権限に解決される必要があります、また顧客ごとに異なるラベルを付けても、それ自体では何も防げません。分離したルーティングコンテキストは、基盤が対応し設計が完全であれば、重複するプレフィックスを保持できます。単純な共有ルーティングテーブルは、背後の利用者が別アカウントだからという理由だけで、同一の宛先プレフィックス二つを区別できません。

これがほとんどの設計にとっての試験です。内部で10.0.0.0/8を用いて番号を振る二つのテナントには、命名規則ではなく分離されたルーティング状態が必要です。

テナント単位のゲートウェイは境界とシステムを買う

顧客ごとに一つのゲートウェイを置くと、その顧客の収容とポリシーが同居するため、管理境界のいくつかは説明しやすくなります。一方で、資格情報、パッチ、監視、所有者を必要とするシステムを倍増させます。また、特定の公開アドレス構成を強制するものではありません：エンドポイントの共有、変換、プロトコルの分離は、実装が実際に何を支えるかによります。

セキュリティ上の利得を数える前に、システムと人を数えます。チームがパッチを当てられる数を四つ超えるゲートウェイを持つ設計は、実際にはより分離されていません。

テナント数が毎月動くなら、そのモデルにはテンプレートではなく自動化の筋書きが必要です。

ホスト単位の接続は作業を移す

ホストする各マシンに接続を置いても運用作業は消えず、マシンのライフサイクルへ移ります。登録、マシン単位のポリシー、鍵のローテーション、交換はすべてプロビジョニングの一部になり、マシン自体と同じ時間帯に失敗します。個別ネットワーク上の少数の長寿命ホストにはしばしば正しく、どのイメージがどこで動くかの把握をすでに失った群れにはめったに正しくありません。

各選択肢について、ID発行、更新、アクセス削除、監視、復旧の役割を名指しします。そのうえで、ある顧客が去る日に何が起きるかを問います。

廃止も比較に含める

ほとんどの比較は廃止を飛ばします。テナントの削除は、その資格情報を無効にし、ポリシーを落とし、アドレスとルーティング状態を解放し、他のすべてを無傷に保つべきです。NISTのゼロトラストアーキテクチャ指針がここでの正しい参照であり、ネットワーク上の位置を信頼するのではなく認証と認可をリソースに置くため、顧客自身のセグメント内にも当てはまります。

プロトコルのベンチマークを量る前に、許可・拒否するフロー、重複アドレスの扱い、廃止手順を量ります。そのうえで、選んだ境界に合うトランスポートと認証方式を選びます。古い製品名や、あらゆる企業が一つのプロトコルに標準化すべきだという主張は、そのどれも決めません。最初に書いた対応表が決めます。