VPN 背後の SaaS 管理エリア：どのアドレスを信頼すべきか

公開 SaaS ページは誰にでも開いたままにできる一方、その背後の管理操作は VPN の外にいる全員を拒否します。それを可能にする仕組みは、隠しメニューでも別のログインページでもなく、リクエストを届けたネットワーク経路の検査です。アドレスの証拠を間違えると、検査は本物の管理者を締め出すか、ヘッダーを打ち込める誰でも通してしまいます。まずオリジンが実際に何を受け取るかから始めましょう。

トンネル後にオリジンが実際に受け取るもの

ブラウザがインターネット通信も運ぶ VPN 経由で公開サイトに到達すると、ゲートウェイは出ていく前に接続を変換します。SaaS が見るのはゲートウェイの公開出口アドレスで、通常は単一のアドレスか小さな範囲であり、 ノート PC のトンネルアドレスを見ることはありません。だからこそ 10.90.0.42 を許可リストに入れても失敗し、RFC 1918 全体を入れるとさらに大きく失敗します。後者はあなたに到達できるあらゆるプライベートネットワークを通してしまい、条件を付ける価値がある唯一のアドレスは組織が出口で実際に所有しているアドレスだからです。

curl -s https://ifconfig.me
dig +short admin.example.com

スプリットトンネリングはこの前提を静かに壊します。VPN が社内のプライベートルートだけを運ぶ場合、公開管理ホスト名へのリクエストはローカル ISP から出て、オリジンには住宅用アドレスが見えます。接続中の VPN アイコンはこの特定の宛先について何も証明しないので、トンネルではなく宛先を検証してください。

出口アドレスがユーザーごとに変わるなら、ポリシーを書く前に立ち止まってルーティングを直してください。一部の管理者にしか一致しない条件は、インシデントが起きるまで問題を隠すため、条件がないより悪いものです。

アドレスを書き換えるプロキシだけを信頼する

ほとんどの公開サイトは CDN かリバースプロキシの背後にあるため、オリジンのソケットアドレスは訪問者ではなくそのフロントエンドのものです。フロントエンドは通常、元のアドレスをヘッダーで転送し、 そのヘッダーは、オリジンが既知のプロキシからのみ受け入れるのでなければ攻撃者に制御されます。信頼するソースの一覧を明示的に設定し、オリジンを他のどこからも到達不能にしてください。その後半がなければ、攻撃者はプロキシを飛ばしてヘッダーを直接送ります。

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

同じ理屈は PROXY プロトコルにも当てはまり、信頼できるのはリスナーがプロキシだけが到達できるインターフェースに束縛されている場合だけです。アドレスの文脈が欠けているときは、既定の許可に落とすのではなく、保護された検査を失敗させなければなりません。存在しないヘッダーは信頼された経路の証拠になりません。

条件をすべての保護操作に結び付ける

検査は、すべての保護操作が通る認可境界に置き、メニューを描画するページには置かないでください。ルートグループ、ミドルウェア、ポリシー層はいずれも機能しますが、ハンドラーごとのコピーは、来四半期に誰かが追加するハンドラーにそれが備わらないため機能しません。

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

同じ境界は、どれも最初に HTML ページを要求されない JSON API、エクスポート、署名付きダウンロード URL、WebSocket のハンドシェイクも覆う必要があります。VPN が稼働中に発行されたダウンロードリンクは、ダウンロードのエンドポイントが再検査しない限り、その後も有効なままです。長寿命のセッションにも再評価の規則が必要で、さもなければ一度の認証済みリクエストが恒久的な例外になります。既定の拒否だけが職員の入れ替わりを生き延びる設定です。

共有キャッシュは検査を回り込むもう一つの道です。保護された応答をすでに保持しているキャッシュは、オリジンに問い合わせずにそれを配信できるため、管理用の応答はプライベートと印を付け、共有ストレージから外してください。キャッシュがどうしても配信する必要があるなら、アクセス検査を配信の前に実行しなければならず、それは通常、共有キャッシュではありえないことを意味します。

たった今ふさいだバイパスを検証する

ハッピーパスではなく、VPN 経由の管理者、VPN なしの同じ管理者、経由する非管理者、偽造したアドレスヘッダーというマトリクスを練習してください。フロントエンドを完全に飛ばすオリジンへの直接リクエストとキャッシュ済み応答のリクエストも加えてください。

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

各リクエストはポリシーが約束する状態を返すべきで、ログにはどのアドレス証拠を使ったかを記録すべきです。デュアルスタックのオリジンは検証したものと異なるソースファミリーを見る可能性があるため、IPv6 は別に覆ってください。顧客が最初に苦情を言った時点で変更が巻き戻されないよう、通常の顧客操作は VPN の外でも動くようにしてください。驚くような合格が見えるよう、実行する前に各行の期待結果を書いておいてください。

出口アドレスが証明するのは許可されたネットワーク経路であり、人でも管理端末でもありません。認証と権限の隣のひとつの条件として保ち続ければ、製品全体を VPN 専用サービスにすることなく管理エリアは狭いままでいられます。その分離こそが設計であり、その制限ではありません。