FortiGate SASEとZTNAの違い｜VPN移行前の設計整理

2026年6月3日

ネットワーク

FortiGateでVPN更改を考える前に、SASEとZTNAの違い、認証、端末条件、ログ、既存VPNを残す判断を整理します。移行時に詰まりやすい運用分担、対象アプリの棚卸し、障害時の切り戻し条件まで、現場で確認する順番で具体的に説明します。

SASEやZTNAという言葉は便利ですが、実際の移行では「今のFortiGate VPNを何に置き換えるのか」「誰の通信をどこまで制御するのか」「障害時に誰がどのログを見るのか」が決まっていないと、構成図だけ新しくなって運用が重くなります。私はVPN更改の相談では、最初に機能比較ではなく業務アプリ、認証方式、端末管理、例外運用を書き出します。

あわせて読みたい

SASEとZTNAの比較表

まず言葉の違いを表に落とします。SASEは通信全体の設計、ZTNAはアプリ単位のアクセス制御として分けると、FortiGate VPN更改の会話が整理しやすくなります。

項目	SASE	ZTNA	VPN移行での見方
主な範囲	拠点、ユーザー、クラウド通信全体	特定アプリへの接続	全体構想と個別移行を分ける
設計単位	通信経路とセキュリティ機能	ユーザー、端末、アプリ	棚卸しの粒度を合わせる
失敗しやすい点	全体更改で範囲が広がる	例外アプリが残る	段階移行にする

判断の目安

既存VPNを残しながら対象アプリ単位で移行する方式は、切り戻しや問い合わせ対応の面で扱いやすいです。

全面更改は短期的には速く見えますが、失敗時の影響範囲が大きくなります。

現場での体験談

以前、VPN更改の相談で最初に製品比較表を作ったことがあります。しかし打ち合わせで詰まったのは機能ではなく、誰がどのアプリへ入るのか、例外ユーザーを誰が承認するのか、障害時にどのログを見るのかでした。そこからは、FortiGateの設定表より先に利用者とアプリの棚卸しを作るようにしています。

注意点

SASEやZTNAを導入しても、既存VPNの利用実態を見ないまま移行すると、未対応アプリや緊急保守の導線が残ります。VPN廃止を先に決めるのではなく、VPNを使う理由を一つずつ減らす設計にしてください。

FortiGateで見るCLIとログ

Step 1: 既存VPNの利用を確認する

Step 1: VPN利用者と接続時間を確認
get vpn ssl monitor

Step 2: 対象ポリシーのログ有効化を確認
show firewall policy

Step 3: 認証失敗と接続失敗を分けて確認
diagnose debug authd fsso list
diagnose vpn ssl list

Step 4: 移行対象アプリ単位で許可範囲を記録
config firewall address
show

SASEとZTNAの違いを最初に分ける

SASEはネットワークとセキュリティ機能をクラウド側でまとめて扱う考え方です。拠点のインターネット出口、クラウドアプリへの接続、Webフィルタ、CASB、SWG、SD-WANの制御まで含めて、全体の通信経路をどう整理するかが主題になります。

ZTNAは、ユーザーや端末が特定アプリへアクセスするときに、VPNのようにネットワークへ広く入れるのではなく、必要なアプリだけを認証・認可してつなぐ考え方です。つまりSASEは全体設計の箱、ZTNAはリモートアクセスやアプリ公開の具体的な制御方式として見ると迷いにくくなります。

FortiGateを中心に考える場合、既存のIPsec VPNやSSL-VPNをいきなり全部なくす話にすると失敗します。管理用アクセス、緊急保守、古い業務アプリ、端末管理外の利用者が残るからです。最初は対象ユーザーと対象アプリを絞り、VPNを残したままZTNAへ寄せる判断が現実的です。

VPN更改前に棚卸しする通信

VPN移行で最初にやることは、製品比較ではなく通信の棚卸しです。誰が、どの端末から、どのアプリへ、どの時間帯に、どの認証で接続しているかを見ます。ここを飛ばすと、ZTNAへ移した後に「一部の委託先だけ入れない」「古い管理ツールだけ動かない」という相談が増えます。

棚卸しでは、業務アプリを三つに分けます。一つ目はクラウドアプリ、二つ目は社内Webアプリ、三つ目はRDPやSSHのような管理系アクセスです。クラウドアプリはSASE側の制御、社内WebアプリはZTNA、管理系アクセスは例外または段階移行として扱うと、移行範囲が説明しやすくなります。

現場で試したところ、既存VPNの利用者一覧だけでは足りませんでした。実際にはVPNへ接続しているがほとんど通信していないユーザー、特定月だけ使う保守ユーザー、退職や異動で残ったアカウントが混ざります。ログから実利用を見ることで、移行対象をかなり減らせます。

認証と端末条件を先に決める

ZTNAで一番先に決めるべきなのは、認証方式と端末条件です。ユーザー認証だけで許可するのか、多要素認証を必須にするのか、管理端末だけに絞るのか、証明書や端末状態を使うのかで運用は大きく変わります。

FortiGate側のポリシーだけを作っても、認証基盤のグループ設計が曖昧だと運用で崩れます。部署、委託先、保守ベンダー、管理者、一般ユーザーを同じグループで扱うと、あとから例外だらけになります。移行前に、少なくとも業務ロール単位のグループを作る方が安全です。

端末条件も先に決めます。会社管理端末、個人端末、踏み台経由、モバイル端末を同じ扱いにすると、ZTNAの価値が薄くなります。最初は会社管理端末だけを対象にして成功パターンを作り、未管理端末はVPNまたは別の例外導線として残す方が、切り戻しもしやすくなります。

ログと障害切り分けを設計に入れる

SASEやZTNAで見落とされがちなのがログです。VPNではFortiGateの接続ログとポリシーログを見れば切り分けられたものが、ZTNAでは認証、端末、アプリ、クラウド側のログに分かれます。障害時に見る順番を決めていないと、ユーザー影響の説明が遅くなります。

移行前に、最低限の切り分け手順を作ります。ユーザー認証が通っているか、端末条件で落ちていないか、アプリ単位の許可に入っているか、名前解決や経路で止まっていないか、アプリ側が正常か。この順番を運用メモとして残すだけで、初期トラブルの対応時間が短くなります。

ログ保管期間も確認します。月次で利用状況を確認するなら30日以上は見たいですし、監査や事故対応を考えるならさらに長く必要です。ログが短すぎると、移行後の改善判断が感覚頼りになります。

移行パターンは三つに分ける

移行パターンは、全面更改、対象アプリ単位の移行、ユーザー群単位の移行の三つに分けると考えやすいです。全面更改は早く見えますが、失敗時の影響が大きいです。対象アプリ単位の移行は時間がかかりますが、失敗しても範囲を限定できます。

おすすめは、利用者が少なく業務影響が読みやすいアプリから始めることです。たとえば社内Webポータルや検証環境のアクセスから始め、認証・ログ・問い合わせ導線を確認します。いきなり基幹系や全社員向けアプリを移すと、原因切り分けより問い合わせ対応が先に詰まります。

ユーザー群単位で進める場合は、情報システム部門や一部の技術部門から始めるとよいです。トラブルの説明を理解しやすく、ログ採取にも協力してもらいやすいためです。一般部門へ広げる前に、FAQと戻し方を整えます。

既存VPNを残すべきケース

既存VPNを残すべきケースは明確にあります。ネットワーク機器の緊急保守、古いクライアントソフト、プロトコル依存の管理ツール、委託先の一時利用、災害時の代替導線などです。これらを無理にZTNAへ押し込むと、セキュリティより運用事故の方が大きくなります。

VPNを残す場合でも、何も変えないわけではありません。接続できるユーザーを減らす、接続先ネットワークを絞る、多要素認証を必須にする、未使用アカウントを削除する、ログ監視を強化する。この整理だけでも、移行前のリスクを下げられます。

VPN廃止をゴールにするより、VPNを使う理由を毎月減らす方が進めやすいです。対象アプリがZTNAへ移ったら、そのアプリに必要だったVPN許可を外します。これを積み上げると、最後に残る例外が見えます。

FortiGate側で確認する設定観点

FortiGate側では、既存のSSL-VPN、IPsec VPN、ファイアウォールポリシー、ユーザーグループ、ログ設定を見ます。特に、VPN接続後に広い宛先へ到達できる設定になっている場合は、ZTNA移行の効果が出やすいです。

設定確認では、許可ポリシーだけでなく拒否ログも見ます。今のVPNで何が落ちているかを見ておくと、移行後に同じ問い合わせが出たときに比較できます。移行前の正常ログと失敗ログを残しておくと、切り戻し判断が速くなります。

Fortinetの資料やリリース情報では、SASE、SD-WAN、AIを含むセキュアネットワークが継続して強調されています。ただし、公式情報の方向性と現場の移行順序は別です。新機能を使う前に、既存VPNの利用実態を小さく分解する方が失敗しにくいです。

移行前チェックリスト

移行前チェックリストは、経路、認証、端末、アプリ、ログ、戻し方の六つで作ります。経路は通信の入口と出口、認証はユーザーと多要素、端末は管理状態、アプリは対象範囲、ログは障害時の見方、戻し方はVPNへ戻す条件です。

戻し方を決めていない移行は危険です。どの障害なら切り戻すのか、誰が判断するのか、切り戻し後にどのログを保存するのかを先に決めます。これがないと、移行当日に判断が属人化します。

チェックリストは一度作って終わりではなく、第一弾の移行後に更新します。実際に出た問い合わせ、認証失敗、端末条件の不足、アプリ側の制限を反映し、第二弾以降の移行精度を上げます。

問い合わせ対応まで含めて設計する

ZTNAやSASEの移行では、技術的な疎通確認だけでなく問い合わせ対応も設計対象です。ユーザーから見ると、VPNへ接続できないのか、アプリへ入れないのか、認証で止まっているのかは区別できません。問い合わせ窓口が最初に聞く項目を決めておかないと、ネットワーク担当へ全部流れてきます。

問い合わせテンプレートには、利用者、端末種別、接続元、対象アプリ、発生時刻、エラー表示、直前に成功した操作を入れます。これだけでログ検索の精度が上がります。特に発生時刻が曖昧だと、認証ログと通信ログを突き合わせるのに時間がかかります。

移行初期は、問い合わせを障害として扱う前に分類します。認証失敗、端末条件不一致、未許可アプリ、名前解決、アプリ停止、ユーザー操作の六つに分けると、改善すべき設定と周知すべき内容が見えます。問い合わせの分類表は、第二弾の展開計画にも使えます。

運用分担を曖昧にしない

FortiGate、認証基盤、端末管理、クラウドアプリ、ヘルプデスクが別チームの場合、責任分界を先に書かないと移行後に必ず揉めます。通信が止まったときにネットワークチームだけで完結しないためです。どのログを誰が確認し、どの条件で次のチームへ渡すのかを決めます。

たとえば認証ログに成功があり、端末条件も満たしていて、FortiGate側の許可ログもあるのにアプリへ入れない場合、アプリ側の権限やセッション制御を見る必要があります。逆に認証前で落ちているなら、ネットワークよりID管理側の確認が先です。この順番を文書化しておくと、障害時の押し戻しが減ります。

運用分担の表は細かすぎる必要はありません。一次受付、認証確認、端末確認、FortiGateログ確認、アプリ確認、切り戻し判断の六つに分ければ十分です。大事なのは、担当部署名ではなく判断条件を書くことです。

段階展開の成功条件を決める

段階展開では、第一弾が成功したかどうかを感覚で決めないようにします。対象ユーザーの接続成功率、問い合わせ件数、認証失敗の件数、切り戻し件数、未対応アプリの件数を見ます。数値を決めておくと、次の部門へ広げる判断が説明しやすくなります。

成功条件は厳しすぎても進みません。初回は問い合わせが出る前提で、重大障害がないこと、業務停止がないこと、切り戻し手順が機能したことを重視します。問い合わせ件数そのものより、原因分類ができて次の設定改善に反映できたかを見ます。

展開後のレビューでは、VPNを残す理由がどれだけ減ったかを確認します。対象アプリの移行が完了したのにVPN許可が残っていると、セキュリティ面の改善が見えません。アプリ単位でZTNAへ移したら、関連するVPN許可を縮小するところまでを一つの作業単位にします。

公式情報と現場判断の差を埋める

Fortinetの公式情報では、SASE、SD-WAN、セキュアネットワーキング、AI活用といった方向性が示されています。これは製品選定では確認したい材料ですが、現場の移行作業では、公式の大きな方向性をそのまま作業順にしない方が安全です。まず既存VPNの利用実態を見て、どの通信を新しい方式へ移すかを決めます。

公式情報で確認するのは、対応機能、サポート範囲、ライセンス、ログの取得方法、既存構成との関係です。一方、現場で確認するのは、利用者、端末、業務アプリ、問い合わせ導線、切り戻し条件です。この二つを混ぜると、機能はあるのに運用できない構成になります。

最終的な判断は、製品ができることではなく、運用チームが継続できることを基準にします。SASEやZTNAは便利な選択肢ですが、例外管理が増えすぎるとVPNより複雑になります。小さく始めて、ログで効果を見て、VPNの許可を減らす。この順番が一番堅いです。

また、移行後に古いVPN設定を残し続けると、せっかくアプリ単位の制御へ寄せても入口が二重になります。残すVPN、縮小するVPN、廃止するVPNを一覧にし、変更日と担当者を記録します。ここまで決めておくと、次回の監査や障害対応で説明しやすくなります。

移行方式の比較

方式	向いている場面	注意点
全面更改	利用者とアプリが少ない	失敗時の影響が大きい
アプリ単位	社内Webやクラウド連携が多い	棚卸しに時間がかかる
ユーザー群単位	部門ごとに運用差がある	例外管理が増えやすい