【実務・中級編】 ZTNAシステムの可用性担保と高可用性(HA)クラスタリング構成 – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

境界防御の幻想を捨てよ：ZTNAゲートウェイの可用性担保とステートフルHAクラスタリングの実践

こんにちは。ネットワークとセキュリティの現場を渡り歩いてきたシニアエンジニアの私だ。

「社内ネットワークに入りさえすれば、どんなリソースにもアクセスできる」——そんな牧歌的な境界防御の時代は、リモートワークの普及とクラウドシフトによって完全に終焉を迎えた。いまや「決して信頼せず、常に検証せよ（Never Trust, Always Verify）」を掲げるゼロトラストアーキテクチャ（ZTA）が、エンタープライズインフラのデファクトスタンダードである。

そのZTAの中核を担うのが ZTNA（Zero Trust Network Access） だ。ユーザーやデバイスが社内リソースにアクセスする際、その都度コンテキストに応じた厳格な認証・認可を行い、許可されたセッションのみを動的に確立する。

だが、ここで現場のインフラエンジニアとして一つ、極めて現実的な問いを投げかけたい。
「もし、そのZTNAへの門戸を叩くゲートウェイがダウンしたら、全社業務がその瞬間から完全停止するのではないか？」

境界型防御であれば、社内LANのスイッチやファイアウォールが冗長化されていれば何とかなったかもしれない。しかし、すべてのトラフィックがZTNAゲートウェイ（ポリシーエンフォースメントポイント：PEP）に集中するゼロトラストの世界では、ゲートウェイの可用性（HA）こそがビジネスの生命線だ。

今回は、単なる「動いています」レベルの冗長化ではなく、数千〜数万のセッションが瞬きする暇もなく引き継がれる 「ステートフルフェイルオーバーを伴うZTNAゲートウェイのHAクラスタリング設計」 について、現場の泥臭い知見を交えて徹底解説しよう。

—

1. なぜ「単なるロードバランサー（LBAaaS）」ではZTNAを守れないのか？

「冗長化ならお手のものだ。AWSのALBやF5 BIG-IPの裏にZTNAゲートウェイを並べればいいだろう」
そう思ったそこのあなた、ちょっと待ってほしい。L4/L7の一般的なロードバランサー構成だけでは、ZTNAの可用性担保としては不十分、というか致命的な破綻をきたすことがある。

トラフィックの非対称性とステートの喪失

ZTNAゲートウェイは、単なるリバースプロキシではない。ユーザーのアイデンティティ、デバイスポスチャ、そして確立されたトンネル（多くはHTTPSやgRPC、あるいはUDPベースのQUIC/WireGuard等）の「セッションステート」をメモリ上で緊密に管理している。

もし、アクティブ機が突然力尽き、スタンバイ機へトラフィックが切り替わったとき、スタンバイ機がそのセッションの暗号コンテキストや認証トークンのキャッシュ（JWTの検証状態など）を知らなかったらどうなるか？
ユーザーは再度、多要素認証（MFA）からやり直しか、あるいはAPIクライアントからのリクエストが突然 401 Unauthorized や 502 Bad Gateway で叩き落とされることになる。

大規模なWeb API連携システムや、自動化されたCI/CDパイプラインが稼働しているエンタープライズ環境において、この「プチ断」や「セッション断」はシステム障害に直結する。

—

2. ZTNAゲートウェイのHAクラスタリング設計解体新書

真に可用性の高いZTNA基盤を構築するためには、以下の3つの要素を完璧に同期させる必要がある。

1. 死活監視とフェイルオーバーの高速化（VRRP / BGP Anycast）
2. セッションステートのリアルタイム同期（Stateful Replication）
3. クライアント側の再接続・リトライ耐性（API設計とSDKの連携）

アクティブ・スタンバイ（A/S） vs アクティブ・アクティブ（A/A）

ZTNAゲートウェイの多くは、セッションのステートフル性を担保するために、厳密な アクティブ・スタンバイ（あるいはアクティブ・パッシブ）構成 を推奨している。アクティブ機がすべてのパケット処理と暗号化処理を担い、スタンバイ機は常時ホットスタンバイとして稼働しつつ、状態データをミリ秒単位で同期し続ける。

[クライアント (API / ブラウザ)]
       │
       ▼  (仮想IP: 192.168.100.10)
┌──────────────────────────────┐
│  VRRP / BGP冗長レイヤー        │
└──────┬───────────────┬───────┘
       │ (Active)      │ (Standby)
       ▼               ▼
┌──────────────┐┌──────────────┐
│  ZTNA GW 01  ││  ZTNA GW 02  │
│ (Active)     ││ (Standby)    │
└──────┬───────┴───────┬───────┘
       └─────── 🔄 ────┘
         Stateful Sync
         (セッション・暗号鍵の同期)

この構成において肝となるのが、フェイルオーバー発生時の 「心臓発作」 を防ぐためのパラメーターチューニングだ。

—

3. 実践！VRRPとステートフル同期の設定・チューニング

ここでは、Linuxベースの仮想ルーターやオープンソース/商用ZTNAゲートウェイの基盤でよく使われる、keepalived（VRRP）とステートフル同期の概念的な設定例を見てみよう。

keepalived.conf（アクティブ側の設定例）

フェイルオーバーの検知が遅すぎるとサービス停止時間が延び、逆に早すぎるとネットワークの微小な揺らぎで「スプリットブレイン（脳味噌分裂）」を起こす。絶妙なタイマー設定が腕の見せ所だ。

vrrp_sync_group VG1 {
    group {
        VI_ZTNA_EXT
        VI_ZTNA_INT
    }
}

vrrp_instance VI_ZTNA_EXT {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101           # スタンバイ側より高い優先度を設定
    advert_int 1           # 1秒ごとにVRRP広告を送信
    
    authentication {
        auth_type PASS
        auth_pass SecureZtnaClusterPass202X
    }
    
    virtual_ipaddress {
        192.168.100.10/24  # 外部向け仮想IP（VIP）
    }

    # 障害検知スクリプト：ZTNAプロセスが死んでいたら優先度を下げる
    track_script {
        chk_ztna_process
    }
}

vrrp_script chk_ztna_process {
    script "/usr/local/bin/check_ztna_health.sh"
    interval 2
    weight -20             # スクリプト失敗時に priority から 20 引く（スタンバイに負ける）
}

ステートフル同期のパラメータチューニング

ゲートウェイ間のセッション同期ネットワーク（Heartbeat専用線）は、必ず物理的に分離された高速なインターフェース（10GbE以上、低レイテンシ）を用意すべきだ。

  • sync_interval (同期頻度): デフォルトのままだと高負荷時に同期遅延が発生する。ミリ秒単位（例: 50ms〜100ms）でインメモリのデルタ（差分）同期を行うようチューニングする。
  • tcp_keeptimeout: クライアントとゲートウェイ間のTCPキープアライブを短めに設定し（例: 30秒）、死活判定を早めることで、ハーフオープンセッションがスタンバイ側にゴミとして残るのを防ぐ。

—

4. クライアント側（Web API・アプリ）の実装におけるレジリエンス

いくらインフラ側で完璧なHAクラスタリングを組んでも、数ミリ秒〜数秒のフェイルオーバー中の瞬断（パケットドロップやコネクションのリセット）をゼロにすることは物理的に不可能だ。
ここで重要になるのが、アプリケーションレイヤー（APIクライアント）の耐障害設計である。

Pythonによるリトライ＆ステート再確立のベストプラクティス

APIリクエストを送信するクライアント側では、コネクションリセット（ConnectionResetError）や、フェイルオーバー中の一時的なタイムアウトを想定した「ジッター付き指数バックオフ（Exponential Backoff with Jitter）」によるリトライロジックが必須となる。

以下のPythonコード（requests と urllib3 のカスタムアダプターを使用）は、ZTNAゲートウェイの瞬断を華麗にいなす実用的なスニペットだ。

import time
import random
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

def create_resilient_ztna_session():
    """
    ZTNAゲートウェイのフェイルオーバー（瞬断）に耐える
    リトライロジックを組み込んだセッションオブジェクトを生成する
    """
    session = requests.Session()

    # リトライ戦略の定義
    retries = Retry(
        total=5,                        # 最大リトライ回数
        backoff_factor=0.5,             # 待機時間係数 (0.5秒, 1秒, 2秒...)
        status_forcelist=[502, 503, 504], # ゲートウェイ起因のエラーコード
        raise_on_status=False,
        allowed_methods=["GET", "POST"] # 冪等性を考慮したメソッド指定
    )

    adapter = HTTPAdapter(max_retries=retries)
    session.mount("https://", adapter)
    session.mount("http://", adapter)
    
    return session

# 使用例
if __name__ == "__main__":
    ztna_client = create_resilient_ztna_session()
    target_api_url = "https://internal-api.enterprise.local/v1/secure-data"
    
    headers = {
        "Authorization": "Bearer eyJhbGciOi...", # ZTNA環境で検証済みのトークン
        "Content-Type": "application/json"
    }

    try:
        # フェイルオーバー直後のリクエストであっても、
        # アダプターが自動的にリトライし、ステートフルセッションの再確立を待つ
        response = ztna_client.get(target_api_url, headers=headers, timeout=5.0)
        
        if response.status_code == 200:
            print("APIリクエスト成功:", response.json())
        else:
            print(f"予期せぬステータスコード: {response.status_code}")
            
    except requests.exceptions.RequestException as e:
        print(f"ZTNAゲートウェイへの接続に完全に失敗しました（障害の可能性）: {e}")

—

5. 現場のトラブルシューティング：フェイルオーバー不全の罠

最後に、私が過去の現場で実際に遭遇した「HAがうまく機能せず、夜中に叩き起こされた」悪夢のようなトラブル事例を共有しよう。

トラブル事例：「フェイルオーバーするたびに全セッションが強制ログアウトされる」

  • 症状: アクティブ機を強制停止（シャットダウン）してVRRPの切り替わりを確認したところ、VIPは瞬時にスタンバイ機へ移ったが、接続中の全ユーザーのWebセッションが切れ、再認証画面に飛ばされた。
  • 原因:

1. ステートフル同期のデータ構造の中に、ローカルの暗号鍵生成用ランダムシード（セッション固有の動的ソルト）が含まれており、スタンバイ側がそれを引き継いだ際に「不正なセッション」と誤判定して破棄していた。
2. ファイアウォール（内部セグメント）が、アクティブ・スタンバイ間の同期ポート（TCP/UDPの特定ポート）をステートフル検査（Inspection）しており、マスター交代時に同期パケットを一時的にドロップしていた。

  • 教訓:
  • ベンダーのHA仕様書を鵜呑みにせず、必ず「本番同等のトラフィックを流した状態でのハードフェイルオーバー試験（カオスエンジニアリング）」を検証環境で実施すること。
  • 同期用トラフィックは、ファイアウォールのインスペクション対象外（バイパス設定）にするか、信頼された専用セグメント内ですべて完結させよ。

—

まとめ

ゼロトラストアーキテクチャの導入において、セキュリティポリシーの厳格さ（誰に何を許可するか）ばかりに目が向きがちだが、それを支えるインフラストラクチャの可用性設計を疎かにすれば、セキュリティの向上と引き換えに「極めて脆弱な可用性」という本末転倒な事態を招く。

ZTNAゲートウェイのHAクラスタリングとステートフルフェイルオーバーの設計は、ネットワーク、暗号技術、そしてアプリケーションのレジリエンスが交差するエンジニアリングの醍醐味だ。
「落ちないゼロトラスト」をデザインし、経営陣やエンドユーザーから信頼される強靭なインフラを構築してほしい健闘を祈る。

スポンサーリンク

コメント

タイトルとURLをコピーしました