企業のWebアプリをVPNの内側へ移す：切り替え手順

変化を利用者の側から想像してください。誰かがブックマークをクリックし、見慣れたログイン画面を期待するものの、ホスト名が今ではトンネルの内側でしか応答しないため、代わりに接続エラーを受け取ります。その一瞬には、移行計画が正しく行うべきすべて——名前、経路、証明書、アカウント、そしてその背後の操作——が含まれています。以下の手順をこの順序で進めれば、切り替えは跳躍ではなくなります。

ステップ 1：利用者が今していることを書き出す

アドレスバーのホスト名、ポート、人が実行する操作、使用しているアカウントから始めます。主要な操作を三つ挙げられないなら、受け入れ時に壊れた操作を見分けられないため、公開入口を閉じる準備はできていません。

次に、非公開の利用者が誰かを決めます。社内VPN上の従業員は出発点であって、答えではありません。請負業者、サポート担当、財務チームは全員がアプリを必要とするかもしれませんし、全員が同じゲートウェイの内側にいるとは限りません。

ステップ 2：トンネルとログインを分ける

利用者がVPN経由でアプリに到達しても、ブラウザはアプリ自身のエンドポイントへTLS接続を開きます。証明書はその名前に一致しなければならず、アプリは依然としてアカウントを認証します。トンネルはどちらも置き換えません。

ここで移行は静かに失敗します。非公開アドレスにもう有効な証明書は要らないと誰かが決め、利用者は警告をクリックして通り抜けることを覚え、組織は公開露出を「セキュリティ警告を無視する訓練」と引き換えにしてしまいます。アプリが本当に内部証明書を必要とするなら、内部認証局から発行し、信頼を適切に配布してください。それは管理された変更であり、警告ページはそうではありません。

認可はすでにある場所に置いたままにします。NISTのゼロトラストアーキテクチャ要旨は要点を直接述べており、ネットワーク上の位置は機密操作を許可する理由になりません。トンネルの内側にいることが、読み取り専用アカウントを管理者に変えてよい理由にはなりません。

ステップ 3：従業員でない呼び出し元を見つける

アプリの設定を開き、アプリと通信するものをすべて列挙します——IDプロバイダーのコールバックURL、決済プロバイダーのWebhook、定期的なインポート、監視プローブ、パートナーのAPIクライアントです。それぞれが所有者を持つ依存関係であり、それぞれが別の時点で壊れます。

残すべきものそれぞれに、サポートされる経路を決めます。Webhookプロバイダーは従業員VPNに参加できないので、独自の認証を持つ範囲の狭い連携エンドポイントを公開するか、連携モデルを変えるかのどちらかです。コールバックが一つあるからといってアプリ全体を公開したままにするのは選択であり、たいていは誤った選択です。

各例外を、宛先、許可する操作、認証、所有者とともに書き留めます。連携に汎用VPNアカウントを渡すことが、例外を恒久化させる道です。連携はそれを追加したプロジェクトより長生きするため、次回のアクセスレビューで一覧を見直してください。有効期限のない例外は、誰も決めていない恒久的な設計判断です。

ステップ 4：DNSレコードだけでなく公開経路を廃止する

公開の連鎖をたどります——DNS、ロードバランサーのリスナー、リバースプロキシのルール、ホストのファイアウォール、そして古いアドレスを指したままの代替名です。両方のアドレスファミリーを確認します。古いCNAMEやIPv6リスナーがアプリを提供し続けているなら、主要なAレコードの変更はほとんど何も証明しません。

並行して、非公開名がトンネル内で解決すること、証明書が利用者の入力する名前を網羅することを確認します。数値アドレスを貼り付けざるを得ない利用者は、症状を見つけたのであって回避策を得たのではありません。

VPNの利用者をアプリの経路に限定します。オフィスネットワークへの広いアクセスは一つの露出判断をより大きなものと交換し、管理用インターフェースは利用者ルールを継承するのではなく独自の許可された接続元を必要とします。

ステップ 5：受け入れを自分で歩く

承認された利用者として接続し、ブックマークを開き、証明書を確認し、ログインして実際の操作を一つ実行します。次に、その操作を持つべきでないアカウントで試し、拒否されることを確認します。さらにVPNの外の端末から試し、アプリに到達できないことを確認します。

保持した各連携についても繰り返し、自分の試験ツールの200が同じことだと決めつけず、プロバイダーの配信ログを読みます。VPNへのログイン成功は、これらの結果のどれの証拠にもなりません。

ステップ 6：悪い日の訓練をする

トンネル障害の間に何が起きるかを決めます——作業が止まるのか、別の承認されたアクセス手段が引き継ぐのかです。どちらを選んでも、文書化されていない復旧手段としての緊急の公開再開はいずれ圧力下の誰かが実行するため、書き留めて一度は試験してください。

ゲートウェイとアプリを保守する管理者のために、所有者と削除日を添えて復旧アクセスを確保します。変更とその巻き戻し条件を同じ場所に記録し、失敗した移行が修正する人々を締め出さないようにします。

切り替え後も、パッチ適用、アカウントのライフサイクル、アプリの認可、監査はあなたの担当です。トンネルは入口を狭めましたが、これらの仕事を引き継いだわけではありません。