セキュリティ

SASEの導入を検討する際のCheck Point

2026.08.24

Image of SASE

はじめに

VPNの脆弱性を発端とするセキュリティインシデントについては断続的に耳にします。
VPNの脆弱性を顧みると、VPNを構成するハードウェアやソフトウェアに起因するもの、ID/Password管理に起因するもの、境界型防御の限界、VPNへの入口が常にインターネットに晒されている物理的条件等々と色々ありますが、VPNの構成上対応しきれない面もあるように思います。

この1-2年で、VPNからZero Trust Network Access(以下ZTNA)を前提としたネットワーク環境に移行する事例が増えているようです。
VPNからSASEへリプレイスする機会を頂いた事がありますので、その際に押さえておくべきポイントを共有します。

SASEについて

SASEは2019年にGartnerが言及したネットワーク機能とセキュリティ機能が一体になっているサービスですが、改めてSASEが提供する機能を確認します。
(一般論であり、提供される機能はSASE製品により異なる場合があります)

ネットワーク系

SD-WAN

拠点間を繋ぐネットワーク機能です。VPNの代替となる機能ですね。拠点間通信の最適化を行い、レイテンシの減少や帯域不足の解消といった従来のVPNでは解決が難しかった機能を実現出来ます。

ZTNA

ゼロトラストネットワークアクセス機能が提供されます。
ゼロトラスト自体は指針や考え方、理念となりますので、具体的にどういった機能があればZTNAと言えるのかは中々難しくなりますが、

リソース単位での利用可否のコントロール機能
コンテキストに応じたアクセス制御機能

が期待されるものかと思います。

セキュリティ系

SWG

Webトラフィックの監視機能となります。
URLのカテゴリフィルタリングやマルウェア検知/ダウンロード防止が代表的な機能でWebトラフィックを経由したリスクへの対策となります。

CASB

SaaSの利用状況の可視化、制御を行う機能となります。
平たく言うとシャドウITへの対策機能ですね。
上記のSWGとの違いは、こちらはSaaSに特化したもので、可視化およびガバナンスにフォーカスしたものとなります。

FWaaS

SASEを経由するトラフィックに対してのファイアウォール機能となります。
SWG、CASBとはレイヤーが異なり、ネットワーク層を担当します。

DLP

機密情報や重要なデータの流出を防いでくれます。
DLP自体が独立した機能ではなく上記の機能と統合して触れられる事が多いように思えます。
クレジットカード番号やマイナンバーの流出を一定フォーマットで検知したり、社外秘やConfidentialといった文言で検知したり、またAIのカテゴライズ機能を利用して検知を行ってくれるSASEサービスもあります。

SASEを導入するに当たって

そもそもの目的は何か

SASEは多くの機能を提供しています。リプレイスするにあたり、

絶対必要な機能
あれば嬉しい機能

を再整理しておきませんか。
検討を進めていく上で、想定していた機能の実現が困難な事が発覚するシーンもあるかと思います。
その際の大きな判断軸になりますので。

利用者の特定

現在使っているVPNのユーザーと同じになりますか。
SASEの導入をきっかけに、より多くのユーザーに使ってもらいますか。
既にローカルブレイクアウトな環境があるなら、社員全員を対象にZTNAを前提とした環境の構築も導入スコープに入るかと思います。
SASEが提供する機能と、現在の状況、あるべきネットワーク環境を鑑み、SASEの利用者を改めて検討するのも良いかと思います。

SASEインターフェイス

ユーザーや拠点とSASEとの接続はどういったネットワークインターフェイスになりますか。エージェント式でしょうか。ブラウザ経由でしょうか。専用の機器が必要でしょうか。こちらはSASEの仕様によりますので、事前に確認しておくのが良いかと思います。
またSASEと各リソースはどういった方式で接続予定でしょうか。
リソースは、社内LAN/WAN、データセンター、AWSやAzureといったIaaS、SaaSが想定されます。
Global IPで制限をかけますか。VPNトンネルを作成予定でしょうか。回線はどういったものでしょうか。インターネット回線で仮想トンネルを作成するのでしょうか。
これらも事前に確認しておくべきポイントかと思います。

リソースに接続して良いのは誰か

VPNからの単純なリプレイスであればこちらは飛ばしてください。
ZTNAを前提とした環境を構築する場合はネットワークのマイクロセグメンテーション化がスコープに入ってきます。

現状、IDaaSやPAMを導入済なら、それらとSASEとの連携仕様を確認しないといけません。
連携が可能であっても、そのACL情報をどうSASEに適用するかは充分に確認、検討しないといけないかと思います。
マイクロセグメンテーション化は将来的な検討事項になっている場合でも、誰がどのリソースに接続すべきかの見直しは必要かと思いますので、良い機会になるのではないでしょうか。

セキュリティ機能について

SASEのセキュリティ機能として、Webアクセスに関するソリューションが提供されるのが一般的かと思います。
昨今では、シャドウAIやSaaS系の接続制御がターゲットになってくるかと思います。

必要となっている機能を確認し、導入をご検討ください。

どのSASEを導入するか

有名どころでいきますとNetskope、Palo Alto Networks、Zscaler、Cato Networksになるでしょうか。 Gartnerでも高い評価を受けていますよね。

SASEは多数あります。国産のものもありますし、上記以外でも検討する余地があるSASEサービスも多くあるはずです。
広く情報を集めて、ベンダーに相談し提案を受けてみるのが良いかと思います(弊社でも承ります)。

機能面の他に、

PoCは行えるか
PoCを行う際の構築コストはどうなるか
PoC環境をそのまま本番に適用出来るか
ライセンス費用が発生するタイミングは
1ライセンスあたりの利用可能PC/スマホ数
1度に多数のユーザーが接続した場合の挙動
SLA
ライセンス調達時の最低数/リードタイム
運用保守はどのような作業があるか
運用に入ってからのサポートはどういった内容なのか

も確認ポイントになるかと思います。

また、SASEは海外製品が多いわけですが、契約時と更新時で担当部署が異なり、更新時のライセンス費用が契約時と全く異なる場合もあるそうです。

ですので、契約する際は、

更新の場合はどういった条件で行われるか。価格はどう決定されるのか。
複数年の契約は出来るか

は確認すべきかと思います。

想定外の更新条件へのリスクヘッジとして

更新する際にも見積は余裕を持って行う
SASEの仕様は必ずドキュメント化しておく
他SASEの情報には常に収集しておく

はやっておいて良いかと思います。

テストを行うにあたり

テスト計画を立てるところから始めるわけですが、SASEと個々のリソースとの接続を確認した後、業務観点から導き出した総合テストを進める場合が多いかと思います。

ポイントは既存のネットワーク環境やサーバー類へ影響を与える事なく、SASEとの接続をどう実現するかになります。
とあるIaaS環境では、戻り(IaaS内部からインターネット向け)のルーティングが1つしか作成出来ず、SASEから接続しても既存の外部向けGatewayからのルートになってしまい、検証が困難となってしまいました。

このケースでは、(切り戻しの手順を確立して、)休日にルーティングをSASEに変更して検証を行いました。

接続方式が明確になれば、検証対象のサーバーやリソースに対して接続プロトコルやネットワーク経路の網羅性、リソースの重要度を勘案して実施していくことになるかと思います。

移行をどう行うか

こちらも移行計画からスタートする事になるかと思います。

ポイントとなるのは、前の章でも触れていますが、接続対象拠点がSASEと現在利用している接続方式とのパラレル接続が可能かにあります。

パラレル接続が困難なら、一度に全ユーザーを切り替えることになります。
テスト時に明確になっているかと思いますが、トラブルに備えて従来のネットワークへの切り戻し方法を確認した上で臨む事になるかと思います。

パラレル接続が可能でしたら、まずは関係者数人からSASEの利用に切り替えた上で従来の業務を行って、問題がないかを確認した後、順次SASE利用ユーザーを増やし、最終的には全社員が切り替えます。

既に総合テストを行っていますので、大きな問題は生じないかと思いますが、

想定していない独自VPNサービスを使っていて、そちらと競合した。
拠点独自のFirewallでSASEに接続出来ない

といった想定外の事象は起こると思います。
こういった場合に備えて、

全く繋がらない場合の対応方法
特定のサイト/サービスに繋がらない場合の対応方法

を事前に検討しておくのが良いと思います。
パッと思いつくのが、

従来のVPNを使う
テザリングといった他のネットワーク方式でSASE接続が出来ないか試みる

となります。

運用保守をどうしていくか

一般的なサービスやシステムとあまり変わらないかと思います。体制を決め、作業一覧を作成し、運用フローを決めて、既存の運用フレームワークで進めていく事になるかと思われます。
運用フローを決める際に、自社で行う作業/委託する作業や関係者とのコミュニケーション方式、対応する時間帯、SLA等が決まっていきます。

私が携わったケースでのサポートフローは、エンドユーザー様 → 弊社 → 代理店 → SASEサービス会社となっていて、伝言ゲーム状態になった事もありました。エンドユーザー様と弊社とは課題管理を行っていましたが、弊社と代理店様との間で課題管理が曖昧になったのは反省点となっております。

運用で発生するであろう作業と思いつく内容を記載していきます。

アカウント管理

SASEはIDaaSとの連携機能を備えているものが多いかと思います(詳細は各SASEサービスをご確認ください)。
この場合は連携プロトコルにもよりますが、グループ情報といったIDaaSでの管理内容がそのまま連携されてくるかと思われます。

IDaaSが未導入でしたら、現状使っているID管理システムとの連携やSASE独自データベースでのアカウント管理になります。
その際は、入社、退社、部署変更等に伴う異動情報をどう反映するかを検討しないといけません。

問い合わせ対応

リリース直後はある程度発生するかと思います。時間の経過につれ、収束していくかと思われます。

問い合わせを管理し、緊急度、重要度を判断して対応を進めていく事になると思われますが、運用の主体が自社なのか委託会社なのかで運用が変わってくるかと思います。
他のシステム運用で使っている運用のフレームワークに依存するところかと思われます。

SASEの設定変更

Staging環境やテスト環境といった事前に検証が出来る環境がSASEにあるようでしたら、そちらで検証した後本番に反映することが出来ますが、ない場合はいきなり本番環境を変更する事になります。
業務影響がない時間帯や休日に変更した上でリリースする等、業務影響なく、本番反映する方式を事前に関係者と合意を取っておきたいところです。

終わりに

対象の人数、既存のVPN関係のネットワーク環境、接続対象の拠点やサービス/サイト数、ステークホルダーの多寡等、企業ごとにSASEを取り巻く環境は変わると思います。
今回お手伝いさせてもらったのは、比較的シンプルな環境だったとは思いますが、貴重な体験になりました。

SASEはVPNをリプレイスする有効な選択肢となっております。
インフラ環境はフルマネージドなクラウドの利用が選択肢に挙がるのが当たり前になりつつあります。フルマネージドなVPNに加えて、ZTNA環境やセキュリティ機能を備えたSASEがネットワーク環境構築の選択肢となるのも自然な流れかと思います。

SASEの導入を検討中の方々の何らかの参考になりましたら嬉しく思います。

本記事は、執筆時点で入手可能な情報および筆者の知見に基づき作成したものであり、その正確性・完全性・特定目的への適合性を保証するものではありません。
掲載内容は一般的な情報提供を目的としており、個別の環境や状況における最適な対応を示すものではない点をあらかじめご了承ください。
本記事の内容を参考に実施された設定変更、運用、その他の行為により生じたいかなる損害についても、執筆者および掲載主体は責任を負いかねます。
なお、掲載している情報は技術動向や関連サービスの仕様変更等により、予告なく修正・更新される場合があります。