第3極SASE: 統合性とユーザ主権の両立

2026年9月25日 17:49

前編『SASEと「コネクティビティ・セキュリティ」の台頭 - 高度化したSSEベンダーの専門性』においては、SASE市場が「ネットワーク・インフラ統合」勢と「インターネット・ネイティブ」勢の二大勢力に収斂しつつあることを論じた。しかし、この二軸の対立図式が捉えきれていない構造的盲点がある。それは、「誰がデータを握っているか」という主権の問題である。本稿では、FortinetのFortiSASE Sovereignを中心に、この第三極の台頭を分析する。

Sovereign SASEを深掘りする

全体設計思想

「5つの問い」と「3層棲み分け」を、本シリーズの冒頭で回収し、「では第3層（Sovereign SASE）を具体的にどう設計・構築・運用するのか？」という問い答える。

1.コントロールプレーンとデータプレーンの物理的・論理的分離

Sovereign SASEの核心は、アーキテクチャ上の「3層構造」にある。これは単なる機能分割ではなく、「組織のデータ主権」を物理的に確保し、かつ「顧客組織が所有する暗号鍵のみで復号可能であり、ベンダーがコンテントを閲覧できない Zero-Knowledge / Bring-Your-Own-Key (BYOK) 構造」を前提とした、暗号学的主権を担保する設計思想である。

コントローラー層（Control Plane）: クラウド上に配置されるオーケストレーション層。ポリシー定義、テナント管理、デバイス構成の配信を担う。重要な点として、顧客の実際のトラフィックやビジネスコンテンツは一切通過せず、管理情報のみで構成される。
セキュリティ実行層（Data Plane）: 顧客のデータセンター内に設置されるFortiGate。SW（Security Web）、ZTNA、CASB、FWaaSなどの全セキュリティ機能を統合的に実行する。
分析・保持層（Analytics Layer）: 同様にデータセンター内に配置されるFortiAnalyzer。すべてのログ、テレメトリデータ、コンテンツをローカルで保持・分析する。

この設計の本質は、「管理の集中（効率化）」と「データ処理・保持の分散（主権・コンプライアンス）」の完全な分離にある。完全クラウド型SASEの課題である「データ流出リスクの外部依存」を、アーキテクチャレベルで解決している。

2.データフローの強制性と「インライン検査」の信頼性

Sovereign SASEが「主権（Sovereign）」を称する技術的根拠は、「トラフィックの迂回を不可能にする設計」にある。

SIA（Secure Internet Access）: ユーザからのインターネットアクセスは、必ずデータセンター内のPoPを経由して外部へ出力されます。ローカルブリッジやローカルトンネリングによる検査回避は、アーキテクチャの設計上認められない。
SPA（Secure Private Access）: プライベートアプリケーションへのアクセスも同様にPoPを経由し、IPsec/BGPトンネルを介してHubへ接続される。

なぜこのような間接的な経路が採用されているのか：その目的は「検査の強制性」を確保することにある。直接アクセスを許可すれば、コンプライアンス違反やマルウェア侵入のリスクが高まります。PoPを経由させることで、全パケットに対するリアルタイムなインライン検査を強制し、これが「主権型SASE」の信頼性の根幹となっている。

3. ルーティングとセキュリティ統合の技術的選定基準

データセンター内でのFortiGate導入において、ルーティングとセキュリティの統合の選択はネットワーク設計上の重要な意思決定要素となる。

BGP / EVPNの活用

PoPと顧客DC、クラウド間でBGPを動的に交換し、リンク品質や遅延に
基づいてトラフィックを最適化する。これにより、SD-WANの「経路制御」とSASEの「セキュリティ適用」をシームレスに統合している。

SD-WANとSASEの境界線

従来の「ルータで分割し、FWで検査」から、「PoP上で統一して検査し、SD-WANで分散化」へ。どこでローカルブリッジ（Local Breakout）を
許し、どこで集中検査（Central Inspection）を強制するかという「ポリシーベースのルーティング設計」が、ネットワーク設計の最重要課題となる。

選定にあたり、コストのみならず「トラフィック量」「冗長性要件」「既存ルータ／ファイアウォールとの整合性」を総合的に評価する必要がある。

4. マルチテナンシーとMSSP展開の可能性

Sovereign SASEは単一顧客環境に限定されない。データプレーン（FortiGate）を顧客データセンターに配置し、コントローラー層をマルチ
テナント化することで、MSSP（マネージドセキュリティサービスプロバイダ）は「主権を担保したセキュリティサービス」を提供可能である。

MSSPの課題: 従来のモデルでは、顧客データの取り扱いにおいてコンプライアンスや信頼構築が困難である。
Sovereign SASEによる解決: 顧客側でFortiGateを運用するためデータは外部に流出せず、MSSPはコントローラー経由でポリシーの管理・監視のみを行う。これにより、「データ主権の維持」と「専門的運用の外部委託」を両立できるようになる。また、「MSSPがポリシーを管理できる」だけでなく、「ポリシーの変更履歴は顧客DC内のFortiAnalyzerに不変（Immutability）として記録され、MSSP自身でも改ざん・削除できない」という「ガバナンスの自動化」が肝心である。これにより、
外部委託先であるMSSPに対しても、顧客組織が最終的な監査権限（Audit Rights）を保持できる。

5. 運用・スケーリング・意思決定フレームワーク

Sovereign SASE導入・運用においては、以下のフレームワークを考慮する。

既存資産の活用: 既存のFortinet製品（FortiGate）を保有する場合、Sovereign SASEへの移行は「新規投資」ではなく「既存資産の論理的
拡張」と位置付けられる。ハードウェア投資の保護と、クラウド統合に
よるセキュリティ効率化を両立可能となる。
スケーラビリティの検討: コントローラー層はクラウドの拡張性を活用
するため、PoP数やユーザー数の増加に伴う管理面の拡張は容易な一方、データプレーンのFortiGateはトラフィック量に応じて物理リソースの追加を要するため、コストとパフォーマンスの最適化が不可欠となる。
選定の判断基準: 「完全なデータ主権」と「クラウドの効率性」の両立が求められる場合、Sovereign SASEが唯一の選択肢となる。ただし、
データセンター内のインフラ（電力、冷却、ネットワークの冗長性）の
維持コストおよび運用負荷を自社で負担する点について、十分な評価が
必要である。

結論

Sovereign SASEは、セキュリティの「クラウド化」と「オンプレミス化」という二項対立を解消する第三の選択肢として位置づけられている。つまりデータ移動を最小化し、分析と制御を分離した次世代アーキテクチャである。

境界線を設けることで、コンプライアンス違反のリスクを最小化しつつ、
現代の分散化したワークロードに対するセキュリティを一元管理する。

技術者にとっての核心は、この「分離」をいかにして堅牢に実装し、かつ
運用コストを管理下に置くかにかかっている。

ベンダーのマーケティング用語に惑わされず、「誰がデータを握るか（主権）」と「どのように検査を強制するか（信頼性）」という2点に焦点を当てた設計思想を理解することが、分散化した現代のワークロードに適した、真に「主権型」のセキュリティアーキテクチャを選択する第一歩となる。