【入門編】リバースプロキシ方式におけるURL書換えとセッションハイジャック対策 – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

こんにちは！ネットワークやセキュリティの世界へようこそ。
インフラの世界に一歩踏み入れたばかりのころは、聞き慣れないカタカナ用語や、なんだか難しそうな略語のオンパレードで、頭がクラクラしてしまいますよね。

「ゼロトラスト？ SASE？ CASB？なんだか凄そうだけど、一体私たちの日常や仕事のどこに関係あるの？」

そんな風に感じている方もご安心ください。今回は、クラウド全盛期の現代においてなくてはならないセキュリティ技術、「CASB（キャスブ）のリバースプロキシ方式におけるURL書換えとセッションハイジャック対策」について、身近な例えを交えながら、一歩ずつ優しく紐解いていきたいと思います。

難しいパケットの仕組みや細かい仕様書を開く前に、まずは私たちの世界でそれがどう動いているのか、一緒に覗いてみましょう！

—

1. 会社の外からクラウドを使うとき、何が起きている？

皆さんは普段、会社から支給されたパソコンだけでなく、自分のスマートフォンや自宅のPCから、仕事で使うクラウドサービス（例えば、Microsoft 365やGoogle Workspaceなど）にアクセスすることはありませんよね…と言いたいところですが、今の時代は「リモートワーク」や「カフェでの作業」が当たり前になっています。

ここでセキュリティ担当者が頭を悩ませるのが、「マネージドデバイス（会社の管理が行き届いた安全なパソコン）」以外の、いわゆる「野良の端末（プライベートのPCやスマホ）」からアクセスされたときのリスクです。

「会社の大切なデータをごっそり自分のスマホにダウンロードされたらどうしよう」
「画面をそのままスクショして持ち出されたら困るな」

そんな不安をパッと解決してくれるのが、今回主役として登場する CASB（Cloud Access Security Broker） というセキュリティの番人です。

郵便配達で例えてみよう！

CASBの「リバースプロキシ方式」を、身近な「郵便配達」に例えてみましょう。

想像してみてください。あなたが海外の怪しい通販サイト（社外のクラウドサービス）から直接モノを取り寄せようとしています。税関を通さないまま自宅に届くと、危険な偽物が混ざっているかもしれませんよね。
そこで、安全な「仲介業者（CASB）」を間に挟むことにしました。

1. あなた（会社の外のスマホ）が、クラウドサービス宛ての荷物を送る。
2. 一度、仲介業者（CASBのプロキシサーバー）の倉庫に荷物が届く。
3. 仲介業者は、その中身をチェックし、さらに「宛先や中身のラベルを安全なものに書き換えてから」本来のクラウドサービスへ届ける。
4. クラウドサービスからの返事も、必ず一度仲介業者の倉庫を経由して、安全を確認してからあなたの手元に届く。

この「宛先や中身をこっそり書き換えて仲介する仕組み」こそが、リバースプロキシ方式の正体なのです！

—

2. なぜ「URL書換え」が必要なの？

さて、この仲介業者（CASB）が間に入る時、一番の工夫が必要になるのが「URLの書換え」です。

例えば、あなたがブラウザに入力するクラウドサービスの本来のアドレス（URL）が https://cloud.example.com だとしましょう。
もし、マネージドデバイス外の端末から直接このアドレスにアクセスさせてしまうと、CASBのチェックをすり抜けて直接クラウドサービスに繋がってしまいます。これでは門番の意味がありません。

そこでCASBは、次のようにアドレスを魔法のように書き換えます。

本来のアドレス: https://cloud.example.com/documents
CASBが書き換えたアドレス: https://casb-gateway.mycompany.com/cloud.example.com/documents

このように、すべてのリンクやリクエストの宛先を casb-gateway.mycompany.com（CASBの玄関口）経由に向うように、HTMLやJavaScriptの中にあるURLをリアルタイムで書き換えるのです。

これにより、ユーザーがどんなリンクをクリックしても、必ずCASBという名のセキュリティチェックポイントを通過させることができます。

—

3. ここが危ない！「セッションハイジャック」の脅威

URLを書き換えて安全に通信を仲介できるようになった！……と安心したいところですが、セキュリティの世界はそんなに甘くありません。

ここで大きな問題になるのが 「セッションハイジャック」 です。

皆さんはクラウドサービスにログインするとき、一度IDとパスワードを入れたら、しばらくはログイン状態が続きますよね。あの「ログインしている状態（セッション）」を維持するために、ブラウザには Cookie（クッキー） という小さなデータが保存されます。

もし、この Cookie が悪意ある攻撃者に盗み見られてしまったらどうなるでしょうか？
攻撃者は、あなたになりすましてクラウドサービスへ自由に出入りできるようになってしまいます。これがセッションハイジャックです。

特に、リバースプロキシ方式では、ユーザーとクラウドサービスの間にCASBが入り込むため、通信の「翻訳」や「書き換え」のプロセスで Cookie の管理が複雑になりがちです。

—

4. 実務で備える！セッションハイジャックを防ぐ設定と工夫

では、インフラエンジニアやセキュリティ担当者は、このセッションハイジャックに対して現場でどのように備えているのでしょうか。具体的な設定や対策のポイントをいくつか見ていきましょう。

① Secure 属性と HttpOnly 属性の徹底

ブラウザに保存されるセッション情報の Cookie には、必ず安全のためのフラグを立てておく必要があります。

以下は、WebサーバーやCASBの設定、あるいはアプリケーション側でセッションCookieを発行する際の設定イメージ（PythonのWebフレームワークの例）です。

# セッションクッキーを発行する際の安全な設定例
response.set_cookie(
    key="session_id",
    value="random_secure_token_abc123",
    secure=True,     # 【超重要】HTTPSの暗号化された通信でのみCookieを送信する
    httponly=True,   # 【超重要】JavaScriptからのアクセスを禁止し、XSSによる盗難を防ぐ
    samesite="Lax"   # CSRF攻撃を防ぐためのモダンな設定
)

secure=True: 暗号化されていない通信（HTTP）では絶対にCookieを流さないようにします。
httponly=True: 悪意あるスクリプト（XSS）が仕込まれても、Cookieが抜き取られないようにガチガチにガードします。

② デバイスポスチャ（端末状態）の常時確認

CASBやSASEの製品では、単にURLを書き換えるだけでなく、「今アクセスしている端末は本当に安全か？」を常に監視します。

例えば、以下のようなポリシーをCASB側の管理画面で設定します。

# CASBアクセス制御ポリシーの概念設定例
access_policy:
  target_service: "Microsoft 365"
  conditions:
    - device_managed: false  # 会社の管理外デバイスからのアクセスの場合
    - client_certificate: "missing" # 有効なクライアント証明書がない場合
  actions:
    - rewrite_url: true      # URLをリバースプロキシ経由に書き換える
    - block_download: true   # データのダウンロードを禁止する
    - restrict_session_lifetime: 900 # セッションの有効期限を15分（900秒）に短縮する

このように、管理外の端末からのアクセスであれば、「セッションの寿命を極端に短くする（タイムアウトを早める）」ことで、万が一セッション情報が盗まれたとしても、攻撃者が悪用できる時間を最小限に抑えるという泥臭い、しかし極めて効果的な対策を行います。

—

まとめ

今回は、CASBのリバースプロキシ方式における「URL書換え」の仕組みと、それに伴う「セッションハイジャック対策」についてお話しました。

URL書換えは、郵便の宛先を安全な仲介業者経由に変更するようなもので、社外からのアクセスを強制的にセキュリティの網にかける技術です。
しかし、仲介を挟むことで複雑化するセッション管理には、HttpOnly や Secure 属性の付与、そしてセッション寿命の短縮化といった実務的な対策が不可欠です。

ゼロトラストやSASEの世界は、一見すると難解な用語の壁に阻まれがちですが、私たちが普段暮らしている世界やルールの仕組みに置き換えてみると、エンジニアたちが「なぜその設定を入れているのか」という意図がスッと見えてくるはずです。

日々のインフラ構築や運用の現場で、今回の知識が少しでも皆さんの頭の片隅に残り、セキュリティを意識するきっかけになれば嬉しいです。それでは、また次の技術の旅でお会いしましょう！