Identity-Aware Proxy を使うなら、まだ VPN は必要ですか？

前提は、ID を認識するプロキシが社内アプリの前に立てば、VPN は飾りでクライアントは不要になる、というものです。これが当てはまるのは、人がブラウザで使う対話型 HTTPS アプリという狭い一例だけで、それ以外のどこでも静かに破絢します。プロキシはリソースに対するリクエストを認可し、VPN はクライアントをネットワーク範囲に受け入れますが、この二つの境界が一致することはほとんどありません。トンネルを廃止する前に、図の製品名ではなく、現場が実際に行っている操作を比較してください。

二つのゲートは別のものを認可する

アプリゲートは、この ID からのこのリクエストがこの保護されたリソースに届いてよいかを決めます。Google の Identity-Aware Proxy の概要 が説明するのはまさにこの形で、HTTPS アプリの前に置かれた中央の認可層を IAM ロールが動かします。境界はリソースであり、アクセスの単位はリクエストです。ルーティングされた VPN はもっと粗く広いことをし、クライアントを定義されたネットワーク範囲に受け入れ、その後にアプリがそのクライアントに何を許すかを決めます。

どちらのモデルも他方を含意しません。ゲートを通ることは特定のレコードを読むことを何も語らず、ネットワーク上にいることは行動の許可を何も語りません。

プロキシが覆わず、VPN が覆うもの

SSH セッション、データベースクライアント、メッセージブローカー、そしてどのブラウザも開かない社内ホスト名は、Web プロキシがあるからといって到達可能にはなりません。それぞれが独自のプロトコルを話し、それぞれが独自の認証済み経路か、それを運ぶネットワークを必要とします。これが移行初日に人が見つけるギャップで、たいていはホスト名を解決できなくなったノート PC を持つオンコールのエンジニアから分かります。

逆のギャップも同じだけ現実です。クライアントをサブネットに受け入れる VPN は、その中の人を認証しませんし、そのサブネット上の侵害された端末はネットワークが許すものを継承します。要件が監査可能な ID によるリクエスト単位の認可なら、ルーティングだけでは実現できません。多くの組織は結局両方を運用し、興味深い問いは、どのリソースをどちらが前に置けるかです。

クライアントのワークフローがアーキテクチャ図より多くを決める

リダイレクトと時折の MFA チャレンジを伴うブラウザサインインは、ブックマークをクリックする人にとって良い体験です。cron ジョブ、CLI、ビルドエージェントにはブラウザがなく、対話的なプロンプトに答えられないので、文書化された非対話の経路かトンネルが必要です。その要件の発見は、たいてい設計が承認された後に起きます。

アプリを数える前にクライアントを数えてください。一つのダッシュボードは 百人に使えますが、一つのデータベースポートはチーム全体を止められます。

端末の状態はどちらのゲートの性質でもない

VPN クライアントの導入はコンプライアンス検査ではなく、ブラウザベースの設計が管理端末ポリシーを守れないと自動的に決まるわけでもありません。どちらも状態シグナルと統合でき、どちらもそれなしで展開できます。製品の形から推測するのではなく、どんな強制があるのか、ポリシーは誰のものか、それに失敗した端末はどうなるのかを尋ねてください。

同じ注意はアクセスの削除にも当てはまります。プロキシでグループメンバーシップを削除することと、トンネルの証明書を失効させることは、遅延の異なる別の操作であり、片方は退職時にたいてい忘れられます。

何かを廃止する前に代替経路を見つける

プロキシ背後の保護されていないオリジン、それを迂回する 二つ目のホスト名、以前の設計から残った広いプライベートルートが、どのゲートが実際に有効かを決めます。許可される操作と拒否される操作を、コンソールではなく実際のクライアントで試し、一度も登録されていない端末から試してください。拒否のケースこそ、ゲートが何かをしているかを教えてくれます。

次に、登録、更新、アクセス削除、そして深夜 2 時に締め出された人の復旧経路という引き継ぎを書きます。プロンプトやクライアントアプリを外すことは、チーム間で責任を移すだけで、責任を消すわけではありません。

今週決めるなら、製品の一覧ではなく操作の一覧から始め、ブラウザでできるものを印し、残りに生き残るネットワークアクセスを正当化させてください。