SASE導入で直面する「3つの誤算」 情シスの思惑違いとは：「一元管理できる」と「楽になる」は別の話
ネットワークとセキュリティを統合するアーキテクチャとして注目されるSASE（Secure Access Service Edge）。多くの企業が導入を検討しているが、期待とは裏腹に、情シスが直面する「3つの誤算」がある。
「SASE」（Secure Access Service Edge）は、ネットワークとセキュリティの機能をクラウドで統合するというコンセプトだ。複数ベンダーの製品の管理負荷を解消できると期待されている。
一方、フォーティネットジャパンが2025年3月に公開した調査結果によると、SASEやSSE（Security Service Edge）製品の導入で得られた効果として「ネットワークとセキュリティの一元管理ができた」と回答した企業は28.6％だった。運用課題で最も多かった回答は「運用負担と運用コストが大きい」だった。同調査は、2024年11月1〜11日、国内のセキュリティやネットワークの担当者513人に実施したものだ。
情報システム部門（以下、情シス）としては、一元管理を実現できるのがSASEを導入する上でのメリットだ。しかし、調査結果からは、運用自体は軽くならない恐れが見え隠れする。この背景には「3つの誤算」がある。
SASEで直面する3つの誤算
併せて読みたいお薦め記事
情シス向け関連記事
SASEは2019年にGartnerが提唱したフレームワークで、SD-WAN（ソフトウェア定義型WAN）、ZTNA（ゼロトラストネットワークアクセス）、CASB（Cloud Access Security Broker）、SWG（Secure Web Gateway）などをクラウドから統合し、提供する。バラバラに導入してきたネットワーク製品とセキュリティ製品を一元化できると期待されている。
誤算1．ツールはすぐには減らない
SASEを入れてもツールはすぐには減らない。その理由は、移行の構造的な問題にある。
SASEへ移行すれば、VPN（仮想プライベートネットワーク）機器、プロキシ、ファイアウォールを即日廃止できる訳ではない。業務継続の観点から、新旧のシステムを並行して稼働させる期間が発生するため、管理する対象は増える局面がある。レガシーシステムを使っている場合、SASEの自動化や最適化の恩恵を受けにくい。複数ベンダーのシステムを組み合わせるデュアルベンダー型で構成している場合も、管理対象が想定より多くなる可能性がある。
そこで、「SASEを入れて管理対象を減らす」よりも先に、「最終的に何を集約するか」を明確にしておくことが大切だ。集約する対象や最終的なゴールを定め、そこに向かう移行計画を段階的に設計することが、ツールが増加する期間を最短にする条件になる。
誤算2．ネットワークの刷新が大規模になる
SASEはセキュリティだけでなく、ネットワークの設計を変えるものでもある。
SASEの構成要素であるSD-WANを導入するということは、拠点のルーター、回線、エッジ機器の見直しが必要だ。拠点数が多い企業では、この移行だけで年単位の計画が必要になる場合もある。
「セキュリティ製品を入れ替えるつもりで検討を始めたら、ネットワーク工事の話になっていた」という情シスの声もある。SASEの導入は、既存の回線契約、拠点インフラ、ベンダー保守契約まで影響が波及する。
全てを一度に刷新しようとすると計画が頓挫しやすい。ZTNA、CASB、SWGのようにネットワーク刷新を伴わない機能から先に導入し、既存設備の更新タイミングに合わせてSD-WANを取り込む段階的なアプローチが現実的だ。「どこから入るか」の優先順位を明確にすることが、大規模刷新リスクを回避する第一歩になる。
誤算3．情シスも変わらないといけない
SASEは技術の話であると同時に、情シスの業務の中身を変える変化でもある。変わるのは担当範囲だけでなく、判断の性質だ。
情シスの業務は、ネットワーク機器の設定、監視、保守が中心にある。しかしSASEを導入すると、管理の主眼は機器からポリシー、ID、SaaSのガバナンスへ移行する。この変化は具体的に3つに分けられる。
1．IDガバナンスが情シスの中核業務になる
SASEのアーキテクチャは「誰が」「どこから」「何に」「どんな条件で」アクセスできるかをポリシーとして定義することを前提にしている。これはネットワークの設定作業とは性質が異なる。従来はAD（Active Directory）管理者、人事、総務が担っていた「誰が何にアクセスできるか」の定義と情シスのセキュリティ業務の境界が曖昧になり、ビジネス側の組織構造、役職、雇用形態まで把握した上でポリシーを設計する視点が必要になる。
2．SaaSのガバナンスが日常業務になる
CASBが機能し始めると、社内で使われているSaaSの可視化、リスク評価、利用許可判断が情シスの日常業務に加わる。「この部署が使いたいSaaSを許可すべきか」という判断は、機器の設定変更とは異なる。セキュリティリスクだけでなく、業務効率、コスト、他ツールとの重複まで踏まえた業務部門との調整が発生する。技術の知識だけでなく、ビジネス判断を伴うガバナンス業務の性質を持つ。
3．インシデント対応の性質が変わる
機器障害への対応から、「誰がいつどこから何にアクセスしたか」というIDログベースの調査、対応にシフトする。ネットワークパケットの解析よりも、大量のアクセスログを横断して振る舞いの異常を見つけるログ分析やフォレンジック調査（サイバー攻撃の原因や経路を突き止めるための鑑識調査）的な思考が中心になる。
情シスが持つべき視点
SASEを検討するとき、「どの製品を選ぶか」と同時に「誰が何を担うか」を問う必要がある。「機器担当」「IDガバナンス担当」「SaaSガバナンス担当」という役割の整理が、SASE導入計画の前提条件になる。製品が動き始めてから組織の問題が噴出しないよう、運用体制の再設計を計画段階に組み込むことが重要だ。
Copyright © ITmedia, Inc. All Rights Reserved.