「社外から社内へ」の魔法：クライアントレスZTNAとHTML重畳の仕組みを紐解く
ネットワークエンジニアの皆さん、こんにちは。突然ですが、皆さんは「境界防御」という言葉にどんなイメージを持っていますか？
かつてのセキュリティは、会社という「城」を高い壁で囲み、門番（VPNゲートウェイ）が通行証をチェックするスタイルでした。でも、今の時代は働き方も多様化し、個人のスマホやカフェのWi-Fiから社内システムにアクセスしたいというニーズが当たり前になりましたよね。
そこで登場したのが「ゼロトラスト」という考え方。中でも、専用アプリを入れられない端末からでも安全に社内リソースへアクセスできる「クライアントレスZTNA」は、まさに救世主のような技術です。今回は、その裏側で行われている「HTML重畳（ちょうじょう）」というちょっと不思議な魔法について、一緒に学んでいきましょう！
—
郵便配達で例える「リバースプロキシ」の仕事
まず、クライアントレスZTNAの心臓部である「リバースプロキシ」の動きをイメージしてみましょう。
皆さんが手紙（Webページ）を出すとき、宛先が直接書かれていると、中継地点の郵便局（プロキシ）はそれを見てどこへ送るか判断しますよね。でも、社内アプリの宛先（例えば http://internal-app.local ）なんて、社外のインターネットからは見えません。
そこで、リバースプロキシはこんな「翻訳」をしてくれます。
1. 宛先の書き換え：社内アプリのURLを、プロキシが管理する「公開用URL（例：https://proxy.company.com/app1/）」に変換してくれます。
2. 中身の書き換え（HTML重畳）：ここが今回の肝です。ページの中にある「次のページへのリンク」や「画像へのパス」も、すべて「プロキシ経由でアクセスするように」書き換えてしまうんです。
郵便局員さんが、封筒の中に入っている手紙の「ここにある地図を、私の案内ルートに全部描き直す」ような作業。これがHTML重畳の正体です。
—
なぜ「重畳」が必要なのか？
もし、HTMLの中身を書き換えなかったらどうなるでしょうか？
Webページの中には、「/images/logo.png」といった相対パスや、「http://internal-app.local/login」といった絶対パスが大量に埋め込まれています。これらをそのままブラウザに返すと、ブラウザは直接そのパスへアクセスしようとしてしまい、「そんな宛先知りません！」とエラーになってしまいます。
これを防ぐために、プロキシがブラウザにデータを渡す直前、HTMLのコードをリアルタイムで読み取り、リンク先を「自分（プロキシ）経由のURL」にパッチを当てていく。これが、あたかも本来のサイトが表示されているかのように見せる「HTML重畳」の技術です。
—
設定サンプルで見る「書き換え」の現場
実際に、Nginxなどのリバースプロキシでこの書き換えを行うイメージをコードで見てみましょう。といっても、難しく考える必要はありません。テキストの置換ルールを決めるだけです。
# リバースプロキシの設定イメージ
location /app1/ {
# 接続先は社内のプライベートなサーバー
proxy_pass http://internal-app.local/;
# 【重要】HTMLの中身を書き換えるための設定
# サーバーから帰ってきたHTML内のURLを、プロキシ経由のURLに書き換える
sub_filter 'http://internal-app.local/' 'https://proxy.company.com/app1/';
# 複数のリンクをまとめて書き換えるために「全て」を対象にする
sub_filter_once off;
# 書き換え対象のデータ形式を指定
sub_filter_types text/html text/css application/javascript;
}この sub_filter という命令が、いわば「翻訳マニュアル」です。「 http://internal-app.local/ を見つけたら、 https://proxy.company.com/app1/ に書き換えろ！」という指示を出すことで、ブラウザはプロキシ経由で正しくコンテンツを取得し続けられるようになるわけですね。
—
注意点：すべてがうまくいくわけではない
「なんだ、これだけで万事解決じゃないか！」と思うかもしれませんが、現場はそんなに甘くありません。
- JavaScriptの壁：最近のWebアプリは、HTMLの中に直接URLを書かず、JavaScriptの中で動的にURLを組み立てることがあります。これだと、単純な「テキスト置換」では太刀打ちできません。
- 暗号化（HTTPS）の壁：データが暗号化されていると、プロキシは中身を覗いて書き換えることができません。一度プロキシでSSL/TLSを終端（復号）し、書き換えた後に再暗号化して届けるという、手間のかかる処理が必要になります。
—
最後に：一歩ずつ理解を深めよう
クライアントレスZTNAは、境界型防御から脱却するための非常に強力な武器です。今回解説したHTML重畳技術は、その裏側にある「泥臭い翻訳作業」を自動化する仕組みに過ぎません。
「パケットがどこで書き換えられているんだろう？」「ブラウザが受け取ったレスポンスヘッダーはどうなっているんだろう？」と、開発者ツール（F12キー）を眺めながらパケットの流れを追いかけてみると、ネットワークの世界がもっと面白く見えてくるはずです。
最初は難しく感じるかもしれませんが、まずは「URLの書き換え」というシンプルな概念から押さえてみてください。皆さんのインフラ構築の現場で、少しでもこの知識が役に立てば嬉しいです！
それでは、また次回の記事でお会いしましょう！
コメント