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

境界線の消失と「見えない鎖」：ZTNAセッション制御の深淵

「境界線（ペリメータ）は死んだ」。この言葉を耳にしてから久しいが、現場のインフラアーキテクトが直面するのは、物理的なファイアウォールを撤去した後に残された「目に見えないセッションの残骸」の処理だ。

ゼロトラストネットワークアクセス（ZTNA）において、最も頭を悩ませるのは「いつセッションを殺すべきか」という問いだ。従来のVPNなら、物理的なリンクダウンやIKEのデッドピア検出（DPD）という明確なトリガーがあった。しかし、HTTPSやgRPCの上で構築されるZTNAセッションでは、TCPのタイムアウトとアプリケーション層のトークン寿命という、二重の鎖が複雑に絡み合っている。

今日は、パケットレベルの挙動からLinuxのネットワークスタックの深淵まで、ZTNAにおけるアイドル判定と切断制御の最適解を紐解いていこう。

—

1. アイドル判定の二重構造：TCPキープアライブ vs アプリケーション層の疎通確認

ZTNAのコネクタとクライアント間には、しばしば複数のプロキシが介在する。ここで発生するのが「TCPセッションは生きているが、認証トークンは期限切れ」という典型的な不整合だ。

多くの設計ミスは、OS標準の tcp_keepalive に依存しすぎることにある。

# Linuxカーネルパラメータの最適化例
# アイドル状態から何秒後にプローブを送るか
sysctl -w net.ipv4.tcp_keepalive_time=300
# 75秒間隔で最大9回までプローブ送信（計約11分で切断判定）
sysctl -w net.ipv4.tcp_keepalive_intvl=75
sysctl -w net.ipv4.tcp_keepalive_probes=9

しかし、この設定だけでは 401 Unauthorized を返すアプリケーション層の「トークン失効」を検知できない。ZTNAの実装において真に重要なのは、HTTP/2 の PING フレームや、gRPC の Keepalive 設定だ。

gRPCにおけるアイドル制御の実装例

Go言語でバックエンドを構築する場合、以下のパラメーターを疎かにしてはならない。

// サーバーサイドでのgRPC keepalive設定
var kaep = keepalive.EnforcementPolicy{
    MinTime:             5 * time.Minute, // クライアントからのping間隔の最低値
    PermitWithoutStream: true,            // ストリームがなくても許可
}

var kasp = keepalive.ServerParameters{
    MaxConnectionIdle:     15 * time.Minute, // アイドル状態が続けば切断
    MaxConnectionAge:      30 * time.Minute, // 総寿命
    MaxConnectionAgeGrace: 5 * time.Minute,  // 猶予期間
    Time:                  5 * time.Minute,  // pingの送信間隔
    Timeout:               1 * time.Second,  // pingの応答待ち時間
}

—

2. RTT削減とTLSハンドシェイクの「泥臭い」現実

ZTNAのパフォーマンスボトルネックの9割は、認証シーケンスにおけるRTT（Round Trip Time）の累積にある。特に TLS 1.3 を採用している場合、0-RTT（Early Data）の活用が鍵となるが、これはセキュリティとのトレードオフを生む。

0-RTT はリプレイ攻撃のリスクを孕んでいる。これを回避するためには、サーバーサイドで一意のチケットIDをキャッシュし、検証する仕組みが不可欠だ。

Nginx/OpenRestyでの対策例

# 0-RTTを有効にしつつ、リプレイ攻撃を防ぐ設定
ssl_early_data on;

# リクエストヘッダーに早期データであるかを明示し、アプリケーション層で検証する
proxy_set_header Early-Data $ssl_early_data;

ここで重要なのは、TCPバッファチューニング だ。クライアントがモバイル回線経由である場合、BDP（Bandwidth Delay Product） を考慮し、初期のウィンドウサイズを広げる必要がある。

# 送信ウィンドウの拡大（TCP Window Scalingを前提）
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

—

3. なぜセッションは「ゾンビ化」するのか

現場で最も厄介なのは、切断通知（FIN/RST）がパケットロスによって届かず、コネクタ側がセッションを保持し続ける「ゾンビセッション」だ。

これを解決する唯一の道は、「受信側からの心拍」を厳格化することだ。クライアント側での TCP Fast Open の無効化や、ヘッダー圧縮（HPACK）における動的テーブルのサイズ制限など、プロトコルスタックの細部を制御することで、ネットワークの揺らぎを吸収する。

究極の回避策：アプリケーション層でのトークン・ローテーション

インフラに依存しすぎない堅牢なアーキテクチャを目指すなら、コネクタの状態管理に頼らず、以下の戦略をとるべきだ。

1. トークンの短命化: 有効期限を15分に設定し、Refresh Token によるサイレント更新を強制する。
2. イベント駆動のクローズ: ブラウザの visibilitychange APIを利用し、タブが非アクティブになった瞬間にクライアント側から CLOSE_NOTIFY を発行させる。

// クライアント側でのセッション破棄トリガー
document.addEventListener('visibilitychange', () => {
    if (document.hidden) {
        // サーバーに明示的なログアウト通知（またはセッション無効化のシグナル）を送信
        navigator.sendBeacon('/api/v1/auth/session-suspend', JSON.stringify({ts: Date.now()}));
    }
});

—

最後に：ネットワークを「信頼」しないということ

ゼロトラストの真髄は、プロトコルが正常に完了することを期待しないことにある。パケットは必ず途中で消えるし、TLSハンドシェイクは必ず中断される。

私たちが構築すべきは、切断を「異常」として扱うシステムではなく、切断が常に発生することを前提とした「ステートレスに近いステートフル」な接続基盤だ。コネクタの Keepalive 設定一つを取っても、それがネットワークの安定性のためなのか、セキュリティの即時性のためのものなのか――その意図を一行一行のコードに込めること。それが、真のネットワークエンジニアの矜持であるはずだ。

さて、あなたのサーバーのログには、今日も意図しない「ゾンビ」が彷徨っていないだろうか？ 今一度、netstat や ss コマンドで、接続時間とプローブの相関関係を可視化することから始めてみてほしい。