直列に置かれた二つのVPNゲート：それぞれが実際に何を決めるのか
VPNを二段直列に置くなら、権限判断も二つに分かれるべきです。各ゲートが何を確認するのかを名づけ、内側のゲートが何を拒否するのかを試します。
二つのVPNを直列につなぐことは、たいてい追加の暗号化として売られますが、それはこの構成がいちばん面白くない部分です。本当の成果物は、別の所有者が別の資源群に対して下す二つ目の認可判断です。両方の段が同じ資格情報を受け入れ、同じ宛先に届くなら、内側のゲートは遅延だけを増やす飾りです。その二つ目の判断が運用コストに見合うかを決めることは、各ゲートが実際に何を検証するのかを名づけることから始まります。
一本のトンネル、そのあとに二つ目の判断
外側のゲートは広い問いに答えます。これは承認済みの従業員端末であり、一般の社内ネットワークに到達してよいか。内側のゲートはより狭い問いに答えます。この主体は保守の権利を持ち、これらの特定の管理エンドポイントに到達してよいか。これは所有者の異なる別々の問いであり、どちらも他方を含意しません。両方の段を通る経路が存在することは、二つ目の背後にあるものを使う権限ではありません。遠い入口に届くことは、経路が機能することを示すだけで、それ以上ではありません。
この原則は古く、いまも無視されています。ネットワーク上の位置は、それ自体では何の根拠にもなりません。 NISTのゼロトラストアーキテクチャ要旨 はそれを明確に述べ、接続の出所やネットワークの所有者から生じる暗黙の信頼を退けています。ここに当てはめれば、内側の入口に到達することはその資源の前提条件であり、それを使う許可では決してありません。
各ゲートが何を検証するのかを書き出す
各段について、確認する主体、許可する宛先、省略できる条件を記録します。外側のゲートは、通常の社内サービスと内側ゲートのリスナーだけを正当に許可してよい。内側のゲートは、役割の主張を要求し、変更記録に記載された管理アドレスだけを許可してよい。遠端のアプリケーションは、その役割が実行できる操作について最終的な発言権を持ちます。したがって連鎖は、アプリケーションの認可を置き換えずにゲートを一つ追加するだけです。
| Gate | Identity it checks | Destinations it permits | How it could be skipped | When it is removed |
|---|---|---|---|---|
| Outer gateway | Employee account plus a managed device posture | General internal services and the inner gateway's listener | Any alternate path to the same destinations, including a public listener | Ordinary work stops and the inner stage becomes unreachable |
| Inner gateway | A maintenance entitlement or role claim on that identity | The named management addresses in the change record | Direct routes from the outer domain to those addresses | Maintenance access ends while general access stays as it was |
二つの見落としが設計を静かに壊します。外側のドメインがすでにすべての機密宛先へ直接届いているなら、内側のゲートは必須ではなく任意です。公開リスナーや二つ目の専用経路が同じアクセスを提供しているなら、意図した経路は複数ある選択肢の一つにすぎません。各ルール群に所有者を割り当て、その契約に宛先サービス、許可する送信元主体、専用DNS、アドレス変換、受け渡しが失敗したときに誰が応答するかを明記させます。外側ネットワークで信頼されるアドレスが、内側ドメインの認可の代わりになることは決してありません。
拒否のケースを試すのであって、うまくいく経路を試すのではない
両方のゲートを通る成功した接続はほとんど何も証明しません。それは展開時に全員が試したケースだからです。興味深いのは、片方の段が通り、もう片方が拒否するケースです。そのうち三つでリスクの大半を覆うことができ、それぞれに、議論ではなく確認できる期待結果があります。
一般アクセスが承認され、機密の役割がない状態では、機密宛先が拒否されるあいだも通常業務は続かなければなりません。両方の段を承認すれば、到達可能な集合は変更記録に記載された保守エンドポイントだけであるべきで、それより広くてはいけません。権利がセッション途中で取り消された場合、合意されたセッション方針は、無関係な一般アクセスを切り離さずに有効にならなければなりません。その取り消しが既存セッションを即座に終えるのか、次の再認証時に終えるのかは、契約にすでに含まれているべき方針判断です。受け入れケースを書いた人が、インシデントの最中にそれを解釈する人であるべきではありません。
curl --fail --silent --max-time 5 https://maint.corp.internal/health || echo "denied as expected"追加した依存関係を数える
余分な段はそれぞれ、故障しうる構成要素と、外側のトンネルの中に正しく入れ子にならなければならない経路を一つずつ増やします。部分的な故障のあいだ、外側の経路は生きているのに内側は到達不能になるので、利用者には、決して応答しないサービスの隣に健全なVPNアイコンが見えます。
正常時だけでなく、故障時の経路と遮断ルールを確認します。外側のトンネルが押し込む既定経路は、内側ゲート自身のアドレスを奪うことがあり、それによって二段目は、確立したあとに落ちる接続になります。内側のトンネルがないあいだ何が遮断されたままであるべきかを記録します。その周りでの偶発的なフォールバックは、きれいな停止より悪いからです。両方のホップで同じ検査の形を使い、それぞれを仮定ではなく測定します。接続済みの表示が二つあっても、入れ子も分離も証明しません。
二つ目のゲートが買えないもの
二つのゲートが資格情報、認証局、管理プレーンを共有しているかどうかを問います。共有している場合、最も重要な故障モードも共有しており、二段目は見かけ上追加する独立性以上のコストがかかります。別々の暗号セッションは、別々の管理統制を生みません。
内側のゲートは、外側のドメインが決して確認しない役割のように、述べて試せる要件を強制しているあいだは残します。同じ主体を同じ宛先に対して再認証することだけが仕事になったら外します。いずれにせよ、要件、所有者、故障時の振る舞いをまとめて記録し、次の見直しが図ではなく要件について議論できるようにします。