【Zscaler】本番通信を止めずにPSEのDR（事業継続）検証を実施する方法
投稿者：セキュリティ＆ネットワーク事業本部 セキュリティ担当 星
皆さんこんにちは。セキュリティ担当の星です。
今回はZscaler Private Service Edge（以下、PSE）を用いたDisaster Recovery機能を実環境に影響を与えずに検証するための構成、設定手順をまとめました。
目次
1.そもそもPSEとは
Zscaler Private Service Edge（PSE）は、通常はZscalerのパブリッククラウド上で稼働する「通信の仲介役（ブローカー）」を、自社のオンプレミス環境やAWSなどのパブリッククラウド内に配置できる機能です。
Zscalerクラウドに障害が発生した際や到達不能になった際でも、自社環境のPSEを経由させることで、社内アプリへのセキュアなアクセスを継続（DR：事業継続）させることが可能になります。
2.検証概要と目的
本検証の目的は、ZPAのDR機能における各種設定手順を整理し、DNS制御によって意図通りのDR動作（ローカルPSE経由への通信切り替え）が行われるかを検証することです。
【検証の概要と環境構成】
ZPAのDR機能は、DNSのTXTレコードを書き換えることで切り替えを制御します。今回はDR機能の「テストモード」（b=test）を使用し、あらかじめ指定したDR Userおよびテスト対象アプリにおいて、意図通りローカルPSEを経由したDR通信へ切り替わるか、その動作プロセスを確認します。
なお、今回の検証では既存の本番環境（通常User ➔ ZPAクラウド ➔ 本番用App Connector）とは別に、DR検証専用の経路（DR User ➔ ローカルPSE ➔ 検証用App Connector）を構築しました。App Connectorやアプリセグメント、アクセスポリシーなどを検証用に新規作成し、本番環境の構成とは論理的に分離した環境で検証を実施しています。
3.検証準備・設定
本番通信への影響を防ぐため、以下の準備を行いました。
（１）Zscaler管理画面で通常系と分離した以下のDR用コンポーネントを新規作成
PSE
App Connector（PSE用AppConnector）
Server Group
Application Segment
Segment Group
Access Policy
ZCC App Profile
（２）以下コンポーネントで「Disaster Recovery」を有効化。
検証用Application Segment
ZPA→Resource Management→Application Management→Application Segment
- App Connector
ZPA→ Private Infrastructure → Configuration&Control →AppConnector Group
- PSE
ZPA→ Private Infrastructure → Configuration&Control →Private Service Edge Groups
- アプリケーションプロファイル（ZCC）
ZCC→App Profiles
DNS設定: 制御用のTXTレコードとして v=1, b=off （通常状態）を事前登録。
4.検証環境
今回は以下の環境にて実施しました。
仮想基盤: Hyper-V上のLinux 9.8
（スペック：4vCPU, 8GB RAM, 64GB Disk / PSEおよびApp Connector稼働用）
ネットワーク: Fortigate 60E
（バーチャルIPによるDNATと、IP PoolによるSNATを設定し、双方向NAT環境を構築）
DNS: 外部DNSホスティングサービス（TXTレコードによるDR制御用）
5.検証手順（動作確認）
DR機能の発動から復旧までの動作確認は、以下のステップで実施しました。
①事前ステータス確認
通常User端末から本番アプリへのPing監視（ping -t）を開始。
DRテストの開始に伴い、テスト用PSEが正しく自動再起動してDRモードに遷移したこと、および本番用App Connectorが再起動せず稼働し続けていることを事後に比較検証できるよう、あらかじめ事前のプロセス稼働時間（Uptime）を記録しておきます。（画像はDR発動前のPSEサーバのStatusスクリーンショット）
②DRテストモードの発動
DNSサーバー上で、TXTレコードを b=off から b=test に変更し、TTL（キャッシュ生存時間）が経過するのを待ちます。
③プロセスの再起動確認
各サーバー上でステータスを確認します。テスト用PSEとApp Connectorは設定変更を検知して自動再起動（Uptimeリセット）されること、本番用App Connectorは再起動せずそのまま稼働し続けていることを確認します。（画像はDR発動後のPSEサーバのStatusスクリーンショット）
また、PSE上で curl コマンドを叩き、対象アプリがDRモードとして認識されているか確認します。
④通信テスト
DR Userの端末から検証用アプリに接続します。ZPAログにて、通信経路がパブリッククラウドを経由せず、「端末 ➔ 検証用PSE ➔ テスト用App Connector ➔ アプリ」のローカル経路となっていることを確認します。
確認ポイント1：DR時のZCCの画面
確認ポイント2：ZPA Diagnosticsログ
対象のUser（DRUser）の通信ログを開き、通信セッション内で経由した「Service Edge」がパブリッククラウドではなく『検証用PSE』になっていること、および「App Connector」が『テスト用に立てたApp Connector』になっていることを確認します。
⑤切り戻し（復旧）
DNSのTXTレコードを b=off に戻します。ZPAログにて、テスト端末からの通信経路が通常のZPAクラウド経由に戻ったことを確認します。
6.検証結果と気づき
検証の結果、以下のことが確認できました。
- 本番環境への影響ゼロ
DR発動中も、通常UserのPingは1発も途切れることなく通信を継続し、本番用App Connectorのプロセス再起動も発生しませんでした。
- DR経路への切り替え成功
DRUserのみが、意図通りにローカルのPSEを経由するDR経路で通信できることを確認しました。
検証結果まとめ
＜気づき（注意点）＞
- DNSのTTLによるタイムラグ
レコード変更から実際にDRが発動・解除されるまでには、設定したTTL分の遅延が発生します。RTO（目標復旧時間）を考慮したTTLの設計が必要です。
- 認証期限切れリスク
DR発動時、ZCCの認証情報（ログインセッション）が有効期限切れとなっている端末はログインできなくなる仕様上の制限があります。
おわりに
ZPAのDR機能とPSEを組み合わせ、DNSレコード（b=test）で制御することで、事前の動作検証から実際の切り替え・復旧までを確実にコントロールできることが確認できました。
有事の際にスムーズなDR発動を行うためにも、事前のパラメータ設計と挙動確認が重要です。弊社ではZscalerのDR設計から導入・検証支援までトータルでサポートしております。ご構築や運用設計に関するご相談は、お気軽にお問い合わせください。
