「SASEを導入したのに、思ったほど安全にも、運用しやすくもなっていない」。この声は、いまの情シスやセキュリティ担当にとって珍しいものではありません。むしろ、ここ数年でクラウド活用が一気に進んだ企業ほど、同じ壁にぶつかりやすくなっています。オンプレミス中心だった頃は、社内と社外を分けるだけで成立していた判断が、SaaS、モバイル、外部委託の増加によって急に通用しなくなったからです。
背景にあるのは、製品の出来不出来よりも、言葉の混線です。SASEはアーキテクチャ実装の選択肢であり、ゼロトラストは信頼の置き方を変える設計思想です。この違いが曖昧なまま導入を急ぐと、VPNの置き換えはできても、アクセス制御の整合性や運用判断が追いつかず、結果的に「便利になったのに複雑」という状態に陥ります。とくに、認証ルール、端末準拠性、データ保護方針が別々に管理されている組織では、例外申請の調整コストが急増しやすく、運用担当の負荷が見えない形で積み上がります。
この記事では、IT技術者の実務視点で「どこから設計し直すと前に進むか」を整理します。NISTやCISAの一次情報と、実際のインシデント事例をつなぎながら、明日から現場で使える判断軸に落とし込みます。読み終えた時点で、少なくとも「いま詰まっている理由」と「次に確認する順番」が明確になるように、少し丁寧に分解していきます。なお本稿は、SASE導入後に運用が詰まる構造と、その解消に向けた設計思想の整理に焦点を当てています。
「製品を入れたのに進まない」正体は、思想と実装の取り違え
ゼロトラストの参照点として最初に押さえたいのは、NIST SP 800-207です。ここで示されているのは、特定ベンダー製品の導入手順ではなく、次の原則です。
- 暗黙の信頼を置かない
- 都度検証する
- 最小権限で許可する
つまり、ゼロトラストはツール名ではなく、アクセス判断を継続的に行うための設計原理です。アクセス可否を一度決めて終わりにするのではなく、ユーザー属性、端末状態、接続元、操作内容などのコンテキスト変化に応じて評価を更新する発想が中核にあります。
引用: NIST SP 800-207 Zero Trust Architecture
一方でSASEは、ネットワークとセキュリティ機能をクラウドで統合し、拠点・在宅・モバイルを横断して接続体験を整える実装モデルです。実務では非常に有効ですが、導入しただけでゼロトラストが完成するわけではありません。ここを混同すると、認証基盤、端末状態、データ分類、権限設計が分断されたまま運用が始まり、後から例外ルールが増殖していきます。たとえば「特定SaaSだけ緊急で許可」「古い端末だが役員案件なので通す」といった判断が積み重なると、最初に想定したポリシーの一貫性が崩れ、監査時に説明しづらい構成になります。
この「後から増える例外」が、現場の疲弊を生みます。最初はVPNの課題解消として合理的に始めたはずが、気づけば部門ごとにポリシーが枝分かれし、誰も全体を説明できない構成になります。ゼロトラストが進んでいないというより、進めるための土台が揃っていない状態です。ここで重要なのは、例外を禁止することではなく、例外が発生した理由を設計に戻して、恒久的な判断基準に変換することです。
境界防御の時代が終わったあとに、何を起点に再設計するか
かつては「社内は信頼、社外は不信頼」という境界防御が機能しやすい時代でした。しかし、SaaSとIaaSの普及で業務システムとデータは外部に分散し、端末はモバイル化し、委託先や自動化連携も増えました。いまは“内側”そのものが固定できません。だからこそ、ネットワーク境界ではなく、ID・端末状態・データ重要度・行動コンテキストで判断する設計が必要になります。言い換えると、社内LANにいるかどうかよりも、「そのアクセスが業務として妥当か」を機械的に説明できることが大切です。
この点で参考になるのが、CISAのZero Trust Maturity Model 2.0です。Identity、Devices、Networks、Applications and Workloads、Dataという複数ピラーを同時に成熟させる考え方が示されており、単一領域の最適化だけでは不十分だと明確にされています。現場でよく起きるのは、Identityだけ先行して多要素認証を強化したものの、端末衛生やデータ分類が追いつかず、実質的に広い権限を維持したままになるケースです。成熟度モデルは、この偏りを可視化するための共通言語として有効です。
引用: CISA Zero Trust Maturity Model 2.0
実際の事例を見ると、この前提の重みがよくわかります。たとえばMGM Resortsの2023年インシデントでは、報道ベースでソーシャルエンジニアリング起点とされ、認証運用と業務停止の連鎖が大きな経営インパクトを生みました。強力な単一製品の有無だけでなく、ID運用、ヘルプデスク手順、権限昇格フローの設計が被害規模を左右する典型です。ここでの学びは、攻撃手法の高度さだけに注目しないことです。本人確認手順や特権ID払い出しルールのような「地味な運用」が、最終的には防波堤になります。
引用: SEC Form 8-K (MGM Resorts International, 2023-09-05)
さらにランサムウェア領域でも、「払えば戻る」前提は崩れています。CISAは支払いが完全復旧や再発防止を保証しないと明示し、FBIも支払いを推奨していません。ここから言えるのは、SASE導入の議論より先に、復旧可能性と業務継続性を設計しないと意思決定が不安定になる、ということです。復号の可否だけでなく、漏えいデータの二次被害、規制報告、顧客対応まで含めた全体設計が必要になります。
引用: CISA Ransomware Guidance
引用: FBI Ransomware Resources
「ゼロトラストを運用できる組織」に変える、三つの設計順序
ここからは、導入論ではなく運用設計としての順序です。
まず必要なのは、守る対象の定義です。データ分類が曖昧なままでは、どれだけ高度なアクセス制御を入れても、重要情報と一般情報を同じ重さで扱うことになります。業務プロセスと結びついたデータライフサイクルを可視化し、どのデータに厳格な制御が必要かを決めるところが出発点です。実務では、最初から完璧な分類を目指すより、機密性・完全性・可用性の観点で主要データを先に三段階程度へ仮分類し、運用しながら精度を上げる進め方が現実的です。
次に、リスクアセスメントの起点をシステムから業務へ戻します。NIST SP 800-37 Rev.2が示すRMFの考え方でも、ミッションと業務プロセスに紐づいたリスク評価が中核です。ここでまず押さえたい前提は、セキュリティにおいてリスクを完全にゼロにすることは現実的ではない、という点です。重要なのは、リスクを特定し、影響度と発生可能性を踏まえて、組織として受容できるレベルに管理することです。サーバーや回線の脆弱性一覧だけを見ても、経営に効く優先順位は作れません。どの業務停止がどの売上・法令対応・信用毀損につながるかを前提にして、対策の順番を組み立てることが重要です。さらに、リスク受容基準をあらかじめ決めておくと、インシデント時に「止めるか継続するか」を感覚ではなく基準で判断できるようになります。
具体化すると、基準は次の三つで定義すると運用に落ちやすくなります。
- 止まってよい時間
- 失ってよいデータ量
- 許容できない法令・契約違反
たとえば、評価基準を業務に当てはめると次のようになります。
- 受注システム: 平日日中に2時間以上停止したら受容不可
- 財務・請求データ: 前日終業時点まで復元できなければ受容不可
- 個人情報を扱う業務: 漏えい疑義が出た時点で法務・広報・経営報告を即時起動
ここまで決めておくと、障害や侵害が起きた瞬間に現場が迷わず動けますし、SASEやEDRのアラートも「何を守るための通知か」を一貫して解釈できるようになります。
引用: NIST SP 800-37 Rev.2 Risk Management Framework
最後に、SASEは「導入完了」ではなく「撤廃可能性まで含むライフサイクル」で評価します。クラウド化が進むほど、接続要件も統制要件も変わるため、最初に決めた構成が永続するとは限りません。将来の更改で外せない設計は、短期的に便利でも長期の柔軟性を削ります。契約・ログ可搬性・ポリシー移行性まで含めて評価すると、ベンダーロックインを抑えながら現実的に前進できます。評価時には「緊急時に必要ログを何分で取り出せるか」「運用委託先が変わっても同じ判断を再現できるか」まで確認しておくと、机上の設計で終わりにくくなります。
読み終えたあとに残してほしい問いは一つです。「うちのゼロトラストは、製品名で説明していないか」。もし説明が製品中心になっているなら、設計思想と運用判断をつなぐ余地がまだあります。SASEを否定する必要はありません。むしろ、SASEを活かすためにこそ、データガバナンスとリスクアセスメントを先に置く。この順序が、現場を疲弊させないゼロトラストへの最短距離です。導入可否の議論で止まるより、「誰が、どの条件で、どこまで許可するか」を言語化するところまで進めると、組織全体の判断品質が上がっていきます。
次の一歩を軽くするために
ゼロトラストは「新しい箱を入れる施策」ではなく、信頼の判断を運用に埋め込む継続設計です。だから、最初の成功条件は派手な刷新ではなく、組織内で共通言語を作れることにあります。SASEの導入を検討している企業ほど、先に「何を守り、誰が判断し、どのログで説明責任を果たすか」を言語化してみてください。そこで初めて、製品選定が技術判断として機能し始めます。遠回りに見えても、ここを丁寧に固めることが、結果的には導入失敗と運用破綻を最も減らす近道になります。
作成日: 2026-04-22