【実務・中級編】 ZTNAセッションにおけるタイムアウト制御とアイドル判定のプロトコル挙動 – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

はじめに：城壁のなかで眠るな、ZTNA時代のセッション管理のリアル

こんにちは。ネットワークの配線地獄と、深夜のファイアウォール設定ミスによる障害対応で幾度となく冷や汗をかいてきたシニアエンジニアの私です。

読者の皆さんは、社内ネットワーク（LAN）にさえ繋げば、あとは安全地帯――そんな牧歌的な境界防御の時代に別れを告げ、すべてのアクセスを疑う「ゼロトラスト」の波にうまく乗れているでしょうか。

「VPNのライセンスが足りない」「リモートワークからの社内リソースへのアクセスが重い」。そんな理由で導入が進むZTNA（Zero Trust Network Access）。しかし、実際に運用を始めると、インフラエンジニアやWeb API開発者の頭を悩ませる「あの現象」に必ず直面します。

*「作業に没頭して30分ほど画面から離れて戻ってきたら、APIの叩き返しでエラーが出るようになった」*
*「スマホアプリでバックグラウンドから復帰した途端、認証画面に強制送還される」*

これらはすべて、ZTNAセッションにおけるタイムアウト制御とアイドル判定のプロトコル挙動が引き起こしている現象です。

今回は、パケットの裏側で何が起きているのか、そしてWeb API設計やインフラ運用においてどう立ち回るべきなのか。現場の泥臭い知見を交えて徹底的に解説します。

—

1. 境界型防御の「甘え」と、ZTNAが求める「常に証明せよ」の世界

かつての境界型防御（VPNや社内LAN）は、一度ゲートをくぐってしまえば、あとは「性善説」で成り立っていました。セッションは数時間、あるいは数日単位で維持され、IPアドレスが変わらない限りはパスポートフリーでした。

しかし、ZTNAの基本思想は「Never Trust, Always Verify（決して信用せず、常に検証せよ）」です。
ユーザーが認証を一度通ったからといって、そのセッションを永遠に信用するわけにはいきません。デバイスの健康状態（ポスチャ）の変化、離席による乗っ取りのリスク、トークンの盗聴リスクを常に考慮し、セッションの寿命を短く、かつ厳密にコントロールする必要があります。

ここで重要になるのが、以下の2つの時間軸です。

1. 絶対有効期限（Session Absolute Timeout / Max Lifetime）

アイドル状態かどうかにかかわらず、セッション開始から強制的に切断されるまでの上限時間。

2. アイドルタイムアウト（Idle Timeout / Inactivity Timeout）

一定期間、通信（パケットのやり取り）が途絶えた場合にセッションを無効化する基準。

特に「アイドル判定」は、クライアント・サーバー、そして間に挟まるZTNAゲートウェイ（PDP/PEP）の間で、巧妙なプロトコル制御が行われています。

—

2. アイドル判定とセッション切断のメカニズム

では、パケットレベルでは何が起きているのでしょうか。
多くのモダンなZTNAソリューション（OAuth 2.0 / OIDC、 mTLS、リバースプロキシ型アーキテクチャベース）では、アイドル判定は以下のように行われます。

[クライアント (ブラウザ/アプリ)]               [ZTNA ゲートウェイ (PEP)]            [IdP / バックエンド]
       |                                              |                                   |
       | ------ HTTPリクエスト (無通信期間 経過) ----> |                                   |
       |                                              |-- アイドルタイマー満了を確認 ------|
       |                                              |                                   |
       | <----- 401 Unauthorized / 403 Forbidden ---- |                                   |
       |        (または特定のリダイレクト指示)        |                                   |
       |                                              |                                   |
       | ====== 再認証フロー (リフレッシュトークン) ==> |                                   |

アイドル判定のトリガーと通信の罠

ZTNAゲートウェイは、各セッションごとの「最後に対象リソースへアクセスしたタイムスタンプ」を保持しています。設定されたアイドル時間（例: 15分）を超えてパケットが来ないと、ゲートウェイはセッションを「失効（Expired）」とみなします。

ここで厄介なのが、「WebSocket」や「HTTP/2のKeep-Alive」が絡む挙動です。
例えば、Web APIのポーリングやバックグラウンドでの死活監視（Heartbeat）が行われている場合、アプリケーション層では「無通信」であっても、TCPのキープアライブや定期的なGETリクエストによって、ZTNAゲートウェイ側は「アイドルではない」と判定し続けてしまうことがあります。

セキュリティ担保の観点からは、「人間が操作していない（＝キーボードやマウスの入力がない、あるいは明示的なAPIコールがない）」状態をアイドルと見なしたいのですが、ネットワーク機器やプロキシはTCP/HTTPのパケット単位でしか世界を見られません。この乖離が、実務での思わぬトラブルを生む原因になります。

—

3. 実務で役立つ設定と実装パターン

ここからは、インフラ設定とアプリケーション（APIクライアント）の両面から、このタイムアウト制御にどう向き合うべきかを見ていきましょう。

A. ゲートウェイ/プロキシ側（Nginx / OpenResty等でのタイムアウト設定例）

自社でZTNAライクなリバースプロキシを構築・運用する場合、クライアントとのアイドル状態の切断は、タイムアウトパラメータのチューニングがキモになります。

http {
    # クライアントからのリクエストがない場合のアイドルタイムアウト (例: 15分)
    client_body_timeout 900s;
    client_header_timeout 900s;

    # バックエンド（APIサーバー）との通信タイムアウト
    proxy_read_timeout 900s;
    proxy_send_timeout 900s;

    server {
        listen 443 ssl;
        server_name ztna.example.internal;

        location /api/ {
            proxy_pass http://backend_cluster;
            
            # アイドルセッション切断時にカスタムヘッダーを付与する等の制御
            proxy_intercept_errors on;
            error_page 401 = @handle_auth_expired;
        }

        location @handle_auth_expired {
            # 認証切れをフロントエンドにわかりやすくJSONで返す
            default_type application/json;
            return 401 '{"error": "session_idle_timeout", "message": "長時間の無通信によりセッションが失効しました。再認証してください。"}';
        }
    }
}

B. クライアント側（Fetch API / Axiosでの401ハンドリング）

APIサーバーやZTNAゲートウェイがセッション切れを検知して 401 Unauthorized を返してきたとき、フロントエンドのコード側でこれを適切にハンドリングし、スムーズにリフレッシュトークンフローへ持ち込むか、ログイン画面へ誘導する必要があります。

以下は、JavaScriptのFetch APIを使った堅牢なラッパー関数の実装例です。

async function fetchWithZtnaHandling(url, options = {}) {
  try {
    const response = await fetch(url, options);

    // ZTNAゲートウェイまたはAPIから401（セッション切れ・アイドル失効）が返ってきた場合
    if (response.status === 401) {
      const errorBody = await response.json().catch(() => ({}));
      
      console.warn(`[ZTNA] セッションが失効しました: ${errorBody.message || '不明なエラー'}`);
      
      // リフレッシュトークンを用いたサイレント再認証を試みる、
      // または強制的にログイン画面へリダイレクトする処理をここに記述
      triggerReauthentication();
      
      throw new Error('Session expired. Redirecting to login.');
    }

    return response;
  } catch (error) {
    console.error('[Network Error] 通信中にエラーが発生しました:', error);
    throw error;
  }
}

function triggerReauthentication() {
  // 実務ではここでOAuth 2.0の刷新フロー（Refresh Token Grant）を走らせる
  // sessionStorage.clear();
  // window.location.href = '/login?reason=idle_timeout';
}

C. デバッグのための cURL コマンドTips

「今、このAPIエンドポイントを叩いたときに、ZTNAプロキシはどんなヘッダーを返しているのか？」
それを確かめるには、-i オプションをつけてHTTPヘッダーを丸裸にするのが一番早いです。

# ZTNA経由でAPIを叩き、レスポンスのステータスコードとヘッダーを詳細に確認する
curl -i -X GET "https://ztna.example.internal/api/v1/user/profile" \
  -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIs..." \
  -H "X-Client-Device-Posture: compliant"

もしここで 401 Unauthorized とともに Www-Authenticate: Bearer error="invalid_token", error_description="The token expired due to inactivity" のような親切なヘッダーが返ってくれば優秀なプロキシですが、単なる 403 Forbidden が返ってくるだけの粗削りな環境も多々あります。その場合は、プロキシのアクセスログを tail -f しながら挙動を追う根気が必要になります。

—

4. 現場の教訓：よくあるハマりどころと対策

最後に、私が現場で実際に踏み抜いた「ZTNAタイムアウトの罠」と、その対策を共有しておきます。

1. バッチ処理や長大なファイルアップロード途中の切断

現象: 数ギガバイトのファイルをアップロードしている最中に、アイドルタイムアウト（例: 10分）に引っかかり、途中でセッションが強制切断される。
対策: 大容量転送を行うエンドポイントだけは、アイドルタイマーの評価ロジックをバイパスするか、チャンク分割アップロード（Tusプロトコルなど）を採用して、定期的にTCPパケットのコンテキストをリフレッシュさせます。

2. スマホアプリのバックグラウンド遷移

現象: アプリを裏に回した瞬間からOSがネットワークを切断。復帰時に古いアクセストークンでリクエストを送り、ZTNA側でエラーの嵐になる。
対策: アプリ側で AppState（React Native等のライフサイクル）を監視し、フォアグラウンドに復帰した瞬間に、トークンの有効性を自発的にチェック（あるいは即座のリフレッシュ）する機構を実装します。

—

おわりに

ZTNAにおけるタイムアウト制御とアイドル判定は、単なる「セキュリティの厳格化」ではありません。「利便性（UX）」と「セキュリティ担保」という、常に相反する二つの要素のバランスをミリ単位で調整するエンジニアリングの芸術です。

教科書通りの設定だけでは、現場のユーザーから「すぐにログアウトされるんだけど！」とクレームの嵐になるでしょう。パケットの往来に思いを馳せ、クライアント、プロキシ、バックエンドの三位一体で適切なタイムアウト設計を行ってください。

あなたの構築したゼロトラストな要塞が、堅牢かつスムーズに稼働することを願っています。それでは、また次の現場でお会いしましょう。