FortiGate SASE ZTNA 違いを、VPN代替の検討で迷わないように整理。SASE/SSE/SD-WANとZTNAの範囲、Fortinetでの実装パターン、認証・端末状態・ログ運用・コスト感の見方、PoC→段階移行の手順を現場目線でまとめます。
用語の定義よりも「自社のVPN更改でどっちを選べば事故らないか」を知りたい人向けです。私はFortiGate中心の拠点ネットワークを運用しつつ、リモートアクセスとSaaS利用が増えたタイミングで、ZTNA寄り・SASE寄りの両方を比較してPoCしました。この記事では、そのとき私が実際に見た判断が割れるポイントだけに絞って書きます。
FortiGate SASE ZTNA 違いは、製品名だけで決めると運用で詰まりやすいです。私はまず既存構成、認証、ログ、例外運用、切り戻し条件を並べて、置き換える範囲を小さく確認します。
この記事でわかること（先に結論）
- SASEとZTNAは対立ではなく包含関係。ZTNAはSASEの構成要素になりうる
- FortiGate環境の現実解は「境界はFortiGateで握りつつ、外部アクセスだけ段階的にクラウドへ」になりやすい
- ハマりどころは機能より認証・証明書・DNS・ログの統合
現場メモ（私の体感）
“VPNをやめたい”の正体は、だいたい「ユーザ単位の例外が増えすぎて、障害時に説明できない」だった。ZTNA/SASEは銀の弾丸ではないけど、アクセス単位を小さくして、例外を見える化できると運用が楽になる。
新しい方式を入れても、既存VPN、DNS、証明書、端末管理、例外通信を同時に整理しないと、移行後の問い合わせが増えます。PoCでは成功条件だけでなく、切り戻し条件も先に決めてください。
移行前チェックの優先度
95%
90%
85%
まず用語整理：SASE/SSE/ZTNAの関係
混乱の原因は、SASEが「アーキテクチャ（概念）」で、ZTNAが「アクセス制御の方式（機能）」として語られやすい点。さらに現場では、ベンダのメニュー名がSSE/Private Access/Zero Trustなどに分かれていて、呼び方が揺れる。
私の整理（最小限）
- ZTNA：ユーザ/端末の属性で、アプリ単位にアクセスを許可する考え方（ネットワーク丸ごと開けない）
- SSE：クラウド側に寄せたセキュリティ機能群（例：SWG、CASB、DLP、ZTNAなど）
- SASE：SSEに加えて、拠点接続や経路最適化（SD-WAN等）まで含めた提供形態
# 私の結論（短い版） ZTNA = 「入れるアプリだけ入る」 SASE = 「その入口をクラウドに寄せつつ、通信経路やセキュリティもまとめて面倒みる」
FortiGate環境での選択肢：何を残して何を寄せるか
FortiGateが既に拠点境界に入っているなら、「全部クラウドに置き換え」よりも、既存の境界制御を生かしながら外部アクセスだけ変える方が現実的なことが多い。理由は、社内NWはL2/L3/冗長/監視が既に固まっていて、そこまで一気に作り直すと検証コストが跳ねるから。
注意（赤）
“ZTNAにしたのに結局フルアクセス”になりがち。最初のPoCで、従来VPNの「社内サブネット全許可」を持ち込むと、名前だけ変わって効果が薄い。アプリ単位に分割できないシステム（レガシーな共有サーバ、固定IP前提の管理ツール等）は、無理にZTNAに寄せず、分離/踏み台/既存VPN継続を含めて整理した方が安全。
比較表：SASEとZTNAとVPN（FortiGate目線）
私は意思決定の場で、細かい製品名よりも「何が増えて何が減るか」を表にした。下の表はそのまま使えるように一般化している（実装やライセンスで変わる箇所は、PoCで要確認）。
ユースケース適性（私の主観を含む）
※バーは「採用しやすさ」の目安。実際はアプリ要件、端末管理、PoPの場所、既存回線設計で上下する。
設計で見るべきポイント：認証・端末状態・ポリシー・ログ
1) 認証は「MFA導入済み」だけだと足りない
VPNからの移行でよくあるのが「MFAはあるから大丈夫」という判断。ただ、ZTNA/SASEで運用を詰めると、どのIdPを正とするか、例外ユーザをどう扱うか、アカウント停止がどこまで波及するかが後で効いてくる。ここは製品の機能差より、組織の運用設計が勝つ。
2) 端末状態（ポスチャ）は“取れるものだけ”にする
エージェントを入れて端末健全性を取る設計は強い。一方で、委託先PC、個人所有端末、現場の専用端末など、取れない端末は必ず出る。そのとき「非対応端末は踏み台」「特定アプリはWeb化」「時間帯/場所制限」など、落とし所を先に用意しておくと揉めない。
3) ポリシーは“アプリ単位”に落とすまでが仕事
ZTNA寄りの設計で効くのは、ACLの書き換えではなく、アプリごとに入口を分ける発想。例えば同じサーバ群でも、運用端末はSSHのみ、業務端末はHTTPSのみ、など用途で切る。これができないレガシーは残す、という判断も含めて「設計」だと私は思う。
4) ログは“どこで見れば答えが出るか”を決める
障害対応で詰まるのは、「FortiGateのログ」「ZTNA/SSE側のログ」「端末側ログ」が分散し、一次切り分けが遅れること。最低でも次を決める。
- 一次切り分け担当が見るダッシュボード（入口を1つ）
- ログ保持期間とエクスポート（監査/規程に合わせる）
- ユーザIDと端末IDの突合キー（メール？UPN？証明書？）
# 切り分けの型（私がPoCで固定した質問） 1) そのユーザは認証に成功している？（IdP/MFA） 2) 端末条件に引っかかっていない？（証明書/ポスチャ） 3) DNSで正しい入口を引いている？（Split DNS含む） 4) ポリシーで許可されている？（アプリ/ポート/時間） 5) ルーティング/戻り通信は成立している？（社内側の経路）
移行の進め方：棚卸し→PoC→段階移行（切り戻し条件まで）
Step 1：現状棚卸し（ここをサボると後で燃える）
- VPN利用者の分類：社員/委託/特権/緊急
- 到達している社内サブネットとポート（実ログから抽出）
- アプリの認証方式：AD連携/ローカル/証明書/固定IP依存
- DNS要件：社内FQDN、Split DNS、社内CAの配布状況
Step 2：PoCは“小さく勝つ”
私がやったのは、最初から全社展開ではなく「対象アプリを2つ」「対象ユーザを10〜20名」に絞ったPoC。成功条件は曖昧にせず、次のように数字に落とした。
- ログで「ユーザ→アプリ→許可理由」が追える
- クライアント配布/証明書配布の手順が1回で再現できる
- DNS/証明書が原因の障害が起きたとき、一次切り分けが30分以内
Step 3：段階移行と切り戻し条件
- 移行は「アプリ単位」か「ユーザ単位」どちらで刻むか決める
- 既存VPNは当面残し、切り戻し条件（いつ/誰が/どこを戻すか）を文書化
- 例外申請の窓口を作り、例外の理由をログと一緒に残す
切り戻しの現実
“切り戻し不要”は理想。実際は、特定の業務端末（古いOS、独自VPNクライアント共存不可など）で詰まることがある。PoCで「非対応端末の扱い」を見つけておかないと、本番で深夜対応になる。
チェックリスト（私がレビューで見ている項目）
まとめ：FortiGate SASE ZTNA 違いを判断に落とす
- ZTNAは「アプリ単位アクセス」。SASEは「それを含む提供形態（SSE＋接続）」
- FortiGate導入済みなら、境界/拠点側は残し、外部アクセスから段階移行が堅い
- 勝負所は機能一覧ではなく、認証・証明書・DNS・ログの“運用設計”
- 非対応端末/レガシーは必ず出る。残すものを決めるのも設計
FAQ：FortiGate SASE ZTNA 違いでよく聞かれる点
Q1. SASEとZTNAはどちらを先に検討すべき？
A. 私はまずZTNA相当の要件（誰がどのアプリに入るか）を固め、次にSASE側（Web/SaaS保護や出口統一）を広げる順が多い。最初から全トラフィックを中継すると例外が増えやすい。
Q2. FortiGateのSSL-VPN/IPsecを残しつつZTNAを追加できる？
A. 多くの現場で段階移行として成立する。ただし、認証基盤、証明書、DNS、ログの参照先が分散しないように、最初に“見る場所”を決める必要がある。
Q3. ZTNAはクライアント必須？委託先はどうする？
A. 端末状態まで見るならクライアント前提になりやすい。委託先など配布できない端末は、踏み台/VDI、公開範囲を絞ったWeb化など別案を用意しておく。
Q4. SASE移行で一番ハマりやすいのは？
A. DNSと証明書。Split DNS、社内FQDN、端末証明書、TLS復号例外の整理が弱いと、疎通は取れてもアプリが動かないケースが出る。
Q5. OT/現場端末（エージェント不可）でもZTNAは使える？
A. 難しいことがある。無理に一本化せず、セグメント分離、踏み台、既存IPsec継続などを組み合わせ、非対応領域を明記して運用するのが安全。
まとめ
FortiGate SASE ZTNA 違いは、機能名だけで比べず、認証、端末状態、通信経路、ログ、例外運用、切り戻し条件を並べて判断します。既存環境との併存期間を前提に、小さく試してログで確認する進め方が安全です。
