アプリがmTLSとSSOを使うなら、サイトVPNはもう不要なのか

mTLSでサインインし、ダッシュボードが読み込まれると、サイトVPNはもう冗長だという主張は、深夜二時にデータベースの復元が必要になるまでの間だけ、もっともらしく聞こえる。アプリケーションのTLS境界が表すのは、一つの経路にすぎない。ホスト、データベース、バックアップ先、クラウドアカウントはそれぞれ独自の入口と、独自のIDと、独自の承認者を持っており、そのどれもログインの成功では試されない。

ログイン画面から外へたどる

一般の利用者と同じようにサインインし、リクエストが触れるすべてのホップ——ブラウザ、エッジ、アプリケーションのリスナー、セッションストア、バックエンドAPI——を書き出す。各ホップには所有者と認証の判断がある。次に、ホストにパッチを当てる人のために、そして夜間バックアップを書くジョブのために、同じたどり方を繰り返す。これらの道はたいてい最初のホップで分かれる。

その分岐こそが答える価値のある問いだ。サイトVPNが冗長なのは、その二度目の道のすべての経路が、自立した入口と認可のポリシーを持っているときだけだ。

アプリのログインが決してカバーしない五つの経路

下の表は棚卸しのテンプレートであり、配備のチェックリストではない。二列目は、あなたの環境が今日実際に強制している内容で埋めてほしい。

一つのIDプロバイダーを共有しても、これらの認可が統合されるわけではない。APIリクエストを送信できる利用者が、それによってVMディスクを交換したり、アプリケーションの資格情報でデータベースを復元したりできるわけではない。NISTはゼロトラストアーキテクチャの概要で、まさにこの理由から、リソースの認証と認可をネットワーク上の位置から切り離している。

チケットを読めるサポートエンジニアが、それによってその背後のホストでコンソールを開けるわけではない。

経路が実在するのは、代替が閉じたままのときだけ

到達可能性をプライベートな管理用リスナーに限ることは、その制限が実際に強制され、絵に描かれただけではないなら、サイトVPNの正当な代替になる。よくある失敗は、すべてのインターフェースに束縛されたままのサービス、請負業者のために開かれたセキュリティグループのルール、インターネットから届く管理ポートといった、誰も覚えていない代替リスナーだ。

図ではなくリスナーを確認する。ホスト上でss -ltnpを使って実際に何が束縛されているかを一覧し、管理用ポートがプライベートアドレスにあることを確かめる。クラウドのコンソールでは、ワークロードサブネットの受信ルールを読み、管理用のものに0.0.0.0/0がないか探す。そのうえで、プライベート経路の外から接続を試すことが、この問いに答える唯一の試験になる。

SSHに対する世界開放のルールが一つあるだけで、トンネル設計のあらゆる論拠が台無しになる。

設計を比べる前に地図を書く

棚卸しの各行について、誰がIDを承認し、誰がアクセスルールを更新し、誰が退職時に資格情報を削除し、経路そのものが壊れたときに誰が復旧を担うのかを記録する。一行につき四つの名前があれば、答えが共有アカウントと三年前のwikiページである行をあぶり出せる。

次に、経路ごとに許可を一つと拒否を一つ検証する。許可は、想定したIDが想定した経路でリソースに届くことを証明する。拒否は、同種のIDでは届かないことを証明するもので、これこそ人が見落とす試験であり、だから代替リスナーが監査を生き延びる。提案する設計はこれらの結果と比べるべきで、どれも試したことのないアプリケーションのTLS設定と比べてはいけない。

サイトVPNがまだ場所を稼ぐところ

トンネルや狭いゲートウェイが正解になるのは、データベースの保守ポート、バックアップ先、ハイパーバイザーのコンソール、帯域外管理のように、リソースがリクエストごとの独自の認証を持たない場合だ。それらのリスナーはネットワークを信頼しているので、呼び出し元を認証するのはネットワークでなければならない。

それが唯一の答えではない。リソースごとの認可を終端するゲートウェイは、サブネット全体のトンネルより狭くでき、共有ジャンプホストより良い監査証跡を残す。

作業の順序は、棚卸しを終え、代替を閉じ、行ごとに拒否を一つ検証し、それから初めてトンネルを廃止する。ある行が拒否を作れないなら、作れるようになるまでプライベート経路を保つ。