SASEを丁寧に：なに者で、なにが嬉しいのか
1) 定義（Gartner）
-
SASE (Secure Access Service Edge) は、SD-WAN と セキュリティ機能（SWG, CASB, ZTNA, NGFW/FWaaS など）を “サービスとして” 統合提供するクラウド中心のアーキテクチャ。ユーザー／デバイスのアイデンティティとコンテキストに基づいてゼロトラストでアクセス制御する。
-
そのうちセキュリティ側の塊が SSE (Security Service Edge)。SWG/ZTNA/CASB（＋FWaaS） が中核で、SASEの“セキュリティ面”を担う下位概念として整理される。
2) どう変わる？（境界→ユーザー／アプリ志向）
- これまでの拠点境界FW＋プロキシの世界から、**“ユーザーがいる所＝境界”**へ。
- 典型像：ユーザー／拠点トラフィックは最寄りのクラウドPoPへ吸い上げ、SWG/IPS/DLP/CASB/ZTNAで検査し、SaaS／IaaS／社内アプリへ最適経路で到達。
3) “単一ベンダSASE”が語られる理由
- ポリシーやログを一枚の平面で統合できると、運用負荷とポリシー不整合が減る。各社「単一エージェント／単一管理」を打ち出すのはここが痛点だから。
SASEで“なくせる／縮小できる”オンプレ機器（と、残るもの）
現場観点で粒度を合わせ、置き換え先（SASE機能）と残しがちなケースまでセットで整理。
| 区分 | なくせる／縮小できるオンプレ | 置き換え先（SASE機能） | コツ／注意 | “残りがち”ケース |
|---|---|---|---|---|
| リモートアクセス | SSL-VPN / IPsec VPN装置 | ZTNA（端末ポスチャ＋アイデンティティでアプリ単位許可） | まずは私設ファイル鯖/社内Web等を ZTNA公開、レガシープロトコルは段階的 | 広帯域L3トンネル前提の運用、ジャンプサーバ依存の特殊運用 |
| Web出口 | プロキシ/SWG装置、URLフィルタ | クラウドSWG（DLP/サンドボックス連携含む） | ローカルブレイクアウトと最寄りPoPで遅延を抑制 | オフライン端末や隔離ネット |
| シャドーIT対策 | CASBゲートウェイ | CASB（API＋プロキシ型） | APIモードでSaaS内データを継続査閲、即時性はプロキシで補完 | 独自SaaSや私設クラウドの深掘り制御 |
| DNSフィルタ | DNSセキュリティ装置 | SASEのDNS/L7保護 | SWGと統一可。端末エージェントで一貫性 | 端末非管理のBYOD大量混在 |
| 支店FW | 中小拠点のUTM/NGFW | SD-WAN + FWaaS | CPEは薄いEdgeにして制御はクラウド側へ | 大規模拠点の東西分離やOT連携 |
| 検疫（NAC） | L2 NAC/802.1X/VLAN隔離 | ZTNAのポスチャで“アプリ入口”を閉める | L2ポート制御はZTNAでは代替不可。置換は“要件の再定義” | 工場/病院などL2セグメント厳格制御は継続 |
| サンドボックス | オンプレMW解析箱 | クラウドサンドボックス | メール/DLP/EDRと相互連携設計 | 帯域制限でサンプル搬送が困難 |
| DLP | Web/DLPアプライアンス | SSE内DLP + CASB | SaaS API連携の“保管データ”対策が要 | メールDLPはメール側の機能で継続 |
| IDS/IPS | 出口IPS | SSE/NGFW as a Service | 東西トラフィックは別途 | DC内の東西監視はオンプレ続投 |
| WAF | WAF機器 | （SASEの対象外） | 公開WebのWAFは別系統で考える | そのまま継続 |
| メール | メールゲートウェイ | （SASEの対象外） | M365/Googleや専用メールセキュリティで | 継続 |
| エンドポイント | EDR/XDR | （SASEの対象外／連携領域） | SASEは“ネットワーク”側、EDRは“端末”側 | 継続 |
| ログ/SOC | SIEM/ SOAR | （SASEログ連携） | SASEのログを集約、相関させる | 継続（むしろ重要度↑） |
ベンダー要点（最小限）
-
Fortinet：FortiSASE
- Fortinetは**“Unified SASE”**を掲げ、FortiClientの単一エージェントで ZTNA/URL制御/VPN を統合、FortiOS系スタックやFortiGuard脅威情報と連携できるのが売り。
-
Palo Alto Networks：Prisma Access / Prisma SASE
- クラウドネイティブのマルチクラウドPoP（GCP/AWS）でグローバル展開、可用性（“5ナイン”相当）と拠点/ユーザ伸縮性に強み。WildFire などの脅威解析やCortex連携と合わせ、SOC連動に向く。
どちらもSASEの本筋は押さえており、既存資産（FortiGate群 or PAN-OS運用/SOC）との親和性で選ぶのが現実的です。
参考アーキテクチャ（導入順序の一例）
-
IdP連携（必須）
- Entra ID / Okta などとSASEをSAML/OIDC連携、グループベースにポリシー設計。
-
リモート＆小規模拠点から着手
- 端末にエージェント配布 → SWG＋ZTNA でVPN装置を縮退。
-
中規模拠点：SD-WAN化
- インターネット二重化＋最寄りPoPでローカルブレイクアウト、FWaaSへ。
-
社内アプリの“公開”
- ZTNAでアプリ単位に公開。
-
ログ一元化と運用手順
- SASEログをSIEMへ。アラート→チケット→是正の運用を回す。
よくあるハマりどころ
- NACの誤期待：「SASEで検疫サーバは不要」→ L2ポート制御は別物。SASEのポスチャ＋ZTNAは“アプリ入口”を閉じるアプローチ。工場LANはNAC継続が現実的。
- WAF/メール/EDRはSASEではない：SASE＝“ネットワーク経路＋クラウドSWG/CASB/ZTNA”。メールや端末・公開Web保護は専用スタックで設計。
- 遅延：PoPまでの往復がボトルネックにならないよう、最寄りPoPのカバレッジとローカルブレイクアウト設計を確認。
余談：国産SASEってあるの？
- フルセットを単独ベンダで提供する純国産は限定的。一方で、IIJ Secure Access Service のようにSASE近似の自社サービスや、国内キャリアが海外SASEをOEM/マネージドで提供する形は一般的。例：IIJ × Prisma SASE連携、NTT Com とZscaler提携 等。
まとめ
- SASEは**“ユーザーとアプリに近い場所で検査・許可する”**設計思想。VPN装置／オンプレSWG／CASBゲートウェイ／中小拠点FWは撤去・縮小の本命。
- ただし、L2 NAC／WAF／メール／EDR／東西監視は別レイヤとして残る。
- FortiSASEは単一エージェントとFortinet資産統合が強み、Prisma SASEはクラウドネイティブなグローバル基盤とSOC連携が強み。
- 導入はIdP連携→リモート/小拠点→拠点SD-WAN→ZTNA公開→運用統合の順で“動く最小単位”から段階的に。
付録：用語の超速メモ
- SD-WAN：アプリ認識でWAN経路を最適化
- SWG：Webトラフィックのプロキシ検査（URL/マルウェア/DLP）
- CASB：SaaS利用の可視化・制御（API/プロキシ）
- ZTNA：ユーザー/端末を認証・評価しアプリ単位で許可
- FWaaS/NGFW：クラウド提供のFW/IPS/URL制御
- SSE：SASEのセキュリティ部分の集合（SWG/CASB/ZTNA…）