【入門編】ブラウザベース(エージェントレス)ZTNAにおけるリバースプロキシの書き換え限界 – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

こんにちは！ネットワークとセキュリティの世界へようこそ。
インフラやネットワークの世界に初めて触れるとき、次から次へと出てくる専門用語に圧倒されてしまいますよね。「本当にこれ全部理解できるのかな…」と不安になることもあるかもしれません。でも、安心してください！一歩ずつ、身近な例えから紐解いていけば、必ず「なるほど！」と腑に落ちる瞬間がやってきます。

今回は、現代のセキュリティの合言葉である「ゼロトラスト」の主役、ZTNA（ゼロトラストネットワークアクセス）、その中でも特に手軽な「ブラウザベース（エージェントレス）型」に潜む、ちょっとディープで面白い“限界”のお話をしてみたいと思います。

「社内のシステムに安全にアクセスしたいだけなのに、なぜか画面が崩れる！」「リアルタイムのチャットが動かない！」――そんな現場のトラブルに直面したとき、何が起きているのかを一緒に覗いてみましょう。

—

1. 境界型防御から「ゼロトラスト」へ：オフィスの鍵はもう古い？

これまでの企業セキュリティは、いわば「立派な城壁と門番がいるお城」のようなものでした。
「社内のネットワーク（お城の中）にいる人は全員信頼できる！社外（お城の外）から来る人は全員怪しいから通さない！」という考え方です。これを境界型防御と呼びます。

しかし、リモートワークが当たり前になり、私たちがカフェや自宅から会社のシステムにアクセスする現代では、この「お城の壁」が通用しなくなってきました。「社内」と「社外」の境界線が曖昧になってしまったからです。

そこで登場したのが、ゼロトラスト（何も信用しない）という考え方です。
「会社の内外に関係なく、アクセスしてきた人が誰なのか、端末は安全なのか、毎回しっかり確認してからじゃないと通さない！」というのがゼロトラストの基本姿勢になります。

そして、そのゼロトラストの思想を具現化する仕組みの一つが ZTNA（ゼロトラストネットワークアクセス） です。

—

2. 「エージェントレスZTNA」の仕組みを、郵便配達に例えてみよう

ZTNAの方式には大きく分けて2つあります。自分のパソコンに専用のアプリ（エージェント）を入れる方式と、ウェブブラウザだけで完結する「エージェントレス（ブラウザベース）方式」です。

エージェントレス方式の最大の魅力は、「会社のパソコンじゃなくても、個人のスマホや自宅のPCからでも、ブラウザを開くだけで社内システムにアクセスできる！」という手軽さにあります。

この仕組み、例えるなら「郵便の宛先書き換えサービス」のようなものです。

1. あなた（社外にいる人）が、ブラウザに https://ztna-portal.company.com/intranet と入力します。
2. このリクエストは、社内のシステムに直接届くのではなく、一度「ZTNAのリバースプロキシ（中継地点）」という受付係に届きます。
3. 受付係は、「なるほど、あの部署のシステムを見たいんだな」と理解すると、あなたの代わりに社内の本当のサーバー（例: http://internal-server.local）に手紙を取りに行きます。
4. サーバーから届いた手紙（HTMLや画像）を受け取った受付係は、宛先や中の文字を「安全な形」に書き換えてから、あなたに手渡します。

「なるほど、中継係が全部うまくやってくれるんだね！」と思いますよね。
しかし、ここに大きな落とし穴（書き換えの限界）が潜んでいるのです。

—

3. なぜ画面が壊れる？ブラウザベースZTNAの限界

受付係（リバースプロキシ）が、社内サーバーから受け取った手紙（HTML、CSS、JavaScriptなど）の文字をせっせと書き換えるとき、次のような問題が発生します。

① HTMLやCSSに「絶対パス」が書かれている悲劇

ホームページの作り方には、現在地からの相対的な場所を示す「相対パス」と、お城全体の住所をそのまま書く「絶対パス」があります。

社内サーバーのプログラムが、うっかり次のようなコードを出力したとしましょう。

<!-- 社内サーバーがそのまま出力してしまったコード例 -->
<link rel="stylesheet" href="http://internal-server.local/assets/style.css">

中継係（プロキシ）は、この http://internal-server.local/ という部分を、自分宛ての https://ztna-portal.company.com/ に書き換えようと頑張ります。しかし、JavaScriptの中や、CSSの複雑な記述の中に埋め込まれたURLだと、中継係のプログラムが「あ、ここもURLだな！」と気づけず、そのまま素通りさせてしまうことがあります。

結果として、あなたのブラウザには次のような現象が起きます。

「あれ？デザインが完全に崩れて、ただの文字の羅列になった！」
「リンクをクリックしたら、存在しない社内アドレスに飛ばされてエラーになった！」

これこそが、動的コンテンツの破損問題です。すべてのURLを完璧に、1ミリの狂いもなく書き換えるのは、中継係にとっても至難の業なのです。

—

② WebSocketのリアルタイム通信が途切れる呪縛

もう一つの大きな制約が、WebSocket（ウェブソケット）通信の維持です。

通常のWebアクセスの世界は、「質問したら答えが返ってくる（リクエストとレスポンス）」の繰り返しです。しかし、チャットアプリやリアルタイムの株価ボードなどは、サーバー側から「ねえねえ、新しいメッセージが来たよ！」と一方的に話しかけてほしいですよね。これを実現するのがWebSocketという技術です。

WebSocketの通信は、最初に普通のHTTP通信で「お互いにつながりましょう（ハンドシェイク）」と約束を交わしたあと、専用のパイプラインを繋ぎっぱなしにしてデータをリアルタイムで流し続けます。

しかし、エージェントレスZTNAのリバースプロキシは、「一度きりの手紙の受け渡し」を想定して作られていることが多く、この「繋ぎっぱなしのパイプライン（WebSocketのコネクション）」をうまく維持できないケースがあるのです。

// リバースプロキシの設定例（Nginxなどのイメージ）
server {
    listen 443 ssl;
    server_name ztna-portal.company.com;

    location /chat {
        proxy_pass http://internal-server.local;
        
        # WebSocketを維持するための魔法の呪文（これが抜けると通信がプツリと切れる）
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

上記の設定コードにあるように、プロキシ側で「WebSocketのアップグレード要求をちゃんと後ろのサーバーに引き渡すよ」という設定を明示的にしてあげないと、チャット画面が固まったり、「接続が切れました」というエラーが頻発したりします。

—

4. 現場のエンジニアとして、どう向き合うべきか？

ここまで、ブラウザベースZTNAのちょっぴり切ない限界についてお話ししてきました。「じゃあ、エージェントレスなんて使えない技術なんじゃ…」と思われるかもしれませんが、決してそんなことはありません。

それぞれの方式には、適材適所があります。

エージェントレス方式（ブラウザベース）
向いているもの： 社外の協力会社や、個人のスマホから、既存の一般的なWebアプリ（社内ポータルやWikiなど）にサクッとアクセスさせたい場合。
向いていないもの： 独自のバリバリ動くJavaScriptで作られたモダンなWebアプリ、リアルタイム通信が命のコラボレーションツール、または普通のWebではないシステム。

もしあなたがシステムの構築や導入を担当していて、「どうしてもこの社内システムはエージェントレスだと画面が崩れる！」という壁にぶぶつかったら、以下の選択肢を検討してみてください。

1. アプリ側のコードを修正する： 可能であれば、絶対パスを相対パスに書き換えてもらう。
2. ZTNAのプロキシ設定をチューニングする： パスの書き換えルール（置換ルール）や、WebSocketの転送設定を細かく調整する。
3. エージェント型（クライアントアプリ型）への切り替えを検討する： 画面の書き換えを無理に行うのではなく、端末自体をトンネルで結んでしまうエージェント型に変えることで、パケットの見た目をそのまま安全に運ぶ。

—

最後に：一歩ずつ、技術の本質に近づこう

ネットワークやセキュリティの世界は、一見すると複雑怪奇なルールの集まりに見えます。でも、その裏側にあるのは「どうやって安全に、正確に情報を届けるか」という、人間社会の郵便や通信の仕組みとまったく同じ泥臭い工夫の積み重ねです。

「なぜここで画面が崩れるんだろう？」
「あ、中継係が書き換えに失敗しているんだな！」

そんな風に、パケットの旅路や中継係の奮闘を頭に思い浮かべられるようになると、トラブルシューティングもぐっと楽しく、ワクワクするものに変わっていきます。

焦らず、一歩ずつ、一緒にエンジニアとしての引き出しを増やしていきましょう！それではまた次回の技術コラムでお会いしましょう！