IT用語集 2023/10/31

SASEとは？わかりやすく10分で解説

コラム

はじめに

クラウドサービスの利用拡大やリモートワークの定着により、「社内ネットワークの内側なら安全」「インターネット側は危険」と分ける境界型の前提は維持しにくくなっています。ユーザーは社外からSaaSへ直接アクセスし、拠点は分散し、保護対象はネットワークだけでなく、ID、端末、クラウド上のデータ、業務アプリケーションまで及びます。

この変化に対応するために検討されるのが、SASE（Secure Access Service Edge）です。SASEは、ネットワーク機能とセキュリティ機能を統合し、ユーザーの場所や接続元に左右されにくいアクセス制御を実現するアーキテクチャです。導入可否を判断するには、機能名だけでなく、既存の認証基盤、端末管理、通信経路、例外運用、段階的な移行計画まで合わせて確認します。

SASEの基本

SASEとは何か

SASEは、ネットワーク接続とセキュリティ制御を別々に設計するのではなく、クラウドを中心とした基盤で統合して提供する考え方です。拠点、在宅勤務者、外出先のユーザー、クラウド上の業務アプリケーションを対象に、通信経路の最適化とアクセス制御をまとめて扱います。

中核になるのは、接続元の場所ではなく、誰が、どの端末で、どのアプリケーションやデータにアクセスしようとしているかを評価する点です。ユーザーID、端末状態、アクセス先、通信内容、リスク情報を組み合わせて、許可、遮断、追加認証、検査強化などを判断します。

従来の境界型セキュリティとの違い

従来の設計では、本社やデータセンターにセキュリティ機器を集約し、拠点や社外ユーザーはVPNで社内ネットワークへ接続してから業務システムを利用する構成が一般的でした。この方式は、社内システム中心の業務では管理しやすい一方、SaaS利用が増えると通信をいったん本社へ戻す経路が増え、遅延、回線負荷、運用の複雑化を招きやすくなります。

SASEでは、ユーザーや拠点から最寄りのクラウド上の接続ポイントへ通信を集め、そこで認証、ポリシー適用、脅威検査、データ保護を行います。社内ネットワークへ入ることを前提にせず、アクセス先ごとに必要な制御を適用するため、リモートワーク、出張、複数拠点、クラウド利用が混在する環境に適用しやすくなります。

SASEを構成する主な機能

SASEは単一機能ではありません。ネットワーク側の機能と、クラウド型セキュリティ機能を組み合わせて構成します。代表的な要素は次の通りです。

SD-WAN	SD-WANは、複数回線を使い分けながら通信経路を最適化する機能です。拠点間通信、クラウド接続、インターネット接続の品質を管理します。
SWG	Secure Web Gatewayは、Webアクセスを検査し、不審なサイト、マルウェア、ポリシー違反の通信を制御します。
CASB	CASBは、SaaS利用状況の可視化、許可されていないクラウド利用の把握、データ持ち出し制御などを担います。
ZTNA	ZTNAは、ユーザーや端末の状態を評価し、業務アプリケーション単位で必要な範囲だけアクセスを許可する仕組みです。
FWaaS	Firewall as a Serviceは、クラウド型のファイアウォール機能です。拠点やユーザーの場所に依存せず、通信制御を統一しやすくします。
DLP	DLPは、機密情報や個人情報の送信、アップロード、共有を検査し、不適切な持ち出しを抑制します。

SASEが注目される背景

SASEが検討される背景には、業務アプリケーションのクラウド移行、リモートワーク、拠点分散、外部委託、モバイル利用の増加があります。業務の多くがクラウド上で完結するようになると、すべての通信を社内ネットワークへ戻して検査する構成は、性能面でも運用面でも負担が大きくなります。

また、VPNで社内ネットワークへ接続した後に広い範囲へ到達できる設計では、認証情報の侵害時に横展開の余地が残ります。SASEは、アクセスをアプリケーション単位で制御し、ユーザーと端末の状態を継続的に評価するため、ゼロトラストの実装方針と組み合わせやすい領域です。

SASEと関連技術の違い

SASEとVPNの違い

VPNは、離れた場所から社内ネットワークへ安全に接続するための仕組みです。社内システムへの接続手段として有用ですが、接続後にどのアプリケーションへ到達できるか、端末状態をどう評価するか、SaaSへの通信をどう検査するかは、別の設計が必要になります。

SASEは、VPN単体の置き換えではありません。リモートアクセス、Webアクセス保護、SaaS可視化、データ保護、WAN最適化をまとめて設計する枠組みです。社内システムへの接続だけでなく、SaaSやインターネット、拠点間通信も含めて統一的に扱います。

SASEとSSEの違い

SSE（Security Service Edge）は、SASEからセキュリティ機能に焦点を当てた領域です。SWG、CASB、ZTNA、DLPなどが中心で、ユーザーがWeb、SaaS、社内アプリケーションへアクセスする際の保護を担います。

SASEは、SSEのようなセキュリティ機能に加えて、SD-WANなどのネットワーク機能も含みます。すでにSD-WANを整備済みで、まずクラウド型セキュリティを強化したい場合はSSEから検討する場合があります。拠点ネットワークの再設計も含める場合は、SASEとして全体を見直す方が判断しやすくなります。

SASEとゼロトラストの関係

ゼロトラストは、「社内だから信頼する」という前提を置かず、アクセス要求ごとにユーザー、端末、アプリケーション、データ、通信状況を評価する考え方です。SASEは、この考え方をネットワークとセキュリティの実装に反映するための選択肢になります。

ただし、SASEを導入するだけでゼロトラストが完成するわけではありません。ID管理、多要素認証、端末管理、ログ分析、権限管理、データ分類が未整備のままでは、SASEの制御も十分に機能しません。SASEは、ゼロトラストを支える構成要素の一つとして扱います。

SASEのビジネス上のメリット

リモートワーク時のアクセス制御を統一しやすい

リモートワークでは、ユーザーが社内ネットワークの外から業務アプリケーションへアクセスします。SASEを使うと、在宅勤務、出張先、サテライトオフィスなど接続元が変わっても、同じポリシーで認証、検査、遮断を行いやすくなります。

たとえば、管理下端末からのアクセスは許可し、未管理端末では閲覧のみに制限し、機密データのダウンロードを禁止するといった制御を適用できます。場所ではなく、ID、端末、アクセス先、操作内容で判断できる点が利点です。

拠点ネットワークの運用を標準化しやすい

拠点ごとに異なる機器、設定、回線、例外ルールを抱えると、変更作業と障害対応が属人化しやすくなります。SASEでは、ネットワークとセキュリティのポリシーを中央で管理し、拠点やユーザーに同じ基準を適用しやすくなります。

新しい拠点を開設する場合も、従来のように多数の機器を個別設計するのではなく、標準化した接続方式とポリシーを適用できます。ただし、回線品質、利用アプリケーション、地域ごとの通信条件は確認対象として残ります。

SaaS利用の可視化と制御に役立つ

SaaSの利用が増えると、部門ごとに契約されたサービスや、管理部門が把握していないクラウド利用が発生しやすくなります。SASEにCASBやDLPを組み合わせることで、利用されているSaaS、アップロードされるデータ、共有設定、利用者の行動を把握しやすくなります。

これにより、許可済みSaaSは業務利用を認め、未承認サービスは警告や遮断を行い、機密情報のアップロードは制限するといった運用が可能になります。すべてを禁止するのではなく、業務上必要な利用と危険な利用を分けて扱う設計が必要です。

コスト判断の軸を整理しやすい

SASEは「導入すれば必ず安くなる」ものではありません。クラウド型サービスの利用料、既存機器の契約、回線費用、移行作業、運用体制によって総コストは変わります。

一方で、拠点ごとの機器更改、個別設定、複数製品の運用、VPN増強、ログ管理の分散にかかる負担を整理できます。コストを評価する際は、製品費だけでなく、運用工数、障害対応、ポリシー変更、監査対応、将来の拠点追加まで含めて比較します。

SASEが適しているケース

リモートワークとSaaS利用が定着しているケース

在宅勤務、出張、外部委託、モバイル利用が常態化し、業務の中心がSaaSやクラウドアプリケーションへ移っている組織では、SASEを検討しやすくなります。社内ネットワークへ戻す前提よりも、アクセス先に応じてクラウド上で制御する設計の方が実態に合いやすいためです。

拠点が多く、ネットワーク運用が複雑なケース

国内外に複数拠点があり、拠点ごとに異なる機器や回線を運用している場合、ポリシーの統一と変更管理が難しくなります。SASEは、拠点ごとの個別最適を減らし、共通の接続方式とセキュリティ基準を適用しやすくします。

VPNの負荷や運用限界が見えているケース

利用者増加によるVPN装置の負荷、通信遅延、接続トラブル、ライセンス増強、認証後の到達範囲の広さが課題になっている場合、SASEやZTNAへの移行を検討する余地があります。特に、社内ネットワーク全体へ接続させる必要がない業務では、アプリケーション単位のアクセス制御へ切り替える効果が出やすくなります。

SASEが適していないケース

ID管理と端末管理が整っていないケース

SASEは、ユーザーIDと端末状態を判断材料にします。IDの棚卸しができていない、退職者や委託先アカウントが残っている、端末の管理状態を判定できない、といった環境では、SASEの制御精度が上がりません。

この場合は、SASE製品の導入より先に、ID管理、認証、端末管理、権限管理の最低ラインを整えます。基盤が弱いままSASEを導入すると、例外設定が増え、結果として統制が崩れやすくなります。

特殊な通信要件が多いケース

業務アプリケーションによっては、プロキシ非対応、固定IP制限、低遅延要件、特定ポート利用、専用線接続などの制約があります。すべての通信をSASE経由にしようとすると、性能劣化や接続不具合が発生する場合があります。

特殊要件が多い組織では、対象通信を分類し、SASE経由にする通信、既存経路を維持する通信、個別検証が必要な通信を分けます。完全統一を急ぐよりも、業務影響の小さい範囲から段階的に移行します。

検出後の運用体制がないケース

SASEはログ、アラート、ポリシー違反、SaaS利用状況を可視化します。しかし、検出後に誰が確認し、誰がポリシーを変更し、誰が例外を承認するのかが決まっていなければ、情報が蓄積するだけになります。

導入前に、セキュリティ部門、ネットワーク部門、端末管理部門、業務部門の責任分担を決めます。特に、例外申請、緊急時対応、ログ確認、ポリシー変更の権限は明確にしておきます。

SASE導入の進め方

対象通信と保護対象を棚卸しする

最初に、ユーザー、拠点、利用SaaS、社内システム、重要データ、既存VPN、回線、認証基盤、端末管理の状況を棚卸しします。SASEで制御したい通信を先に決めないと、導入範囲が広がりすぎ、移行リスクが高くなります。

棚卸しでは、すべての通信を同時に扱うのではなく、リモートアクセス、Webアクセス、SaaSアクセス、拠点間通信、社内システム接続に分けて確認します。業務影響が大きい通信からではなく、効果が見えやすく、切り戻しやすい範囲から始めると移行しやすくなります。

既存のID・端末管理と接続する

SASEは、IDaaS、ディレクトリ、MFA、端末管理、EDRなどと連携して制御精度を高めます。ユーザーが正規かどうかだけでなく、端末が管理下にあるか、セキュリティ設定が満たされているか、リスクの高い操作をしていないかを評価します。

連携前には、アカウントの棚卸し、グループ設計、端末台帳、証明書や認証方式の整理を行います。古いアカウントや不明端末が残ったままでは、SASE側のポリシーも例外だらけになります。

移行範囲を段階的に広げる

SASE導入は、全社一斉切り替えよりも段階移行の方が管理しやすくなります。例えば、最初にWebアクセスの検査を統一し、次にSaaS制御を強化し、その後に社内アプリケーションへのアクセスをZTNAへ移す方法があります。

段階移行では、対象部門、対象アプリケーション、対象拠点、検証期間、切り戻し手順を決めます。ログを確認しながら、誤検知、通信遅延、業務影響、例外の発生状況を見て範囲を広げます。

例外運用を最初から設計する

SASE導入で失敗しやすいのは、例外を後から個別に増やす運用です。例外が増えると、どの通信がどのポリシーから外れているのか分かりにくくなり、監査や障害対応にも影響します。

例外は、対象アプリケーション、理由、承認者、期限、代替策、見直し日を記録します。期限のない例外を増やさず、定期的に削減できるものを確認します。

SASE運用で確認すべき指標

SASEの成果は、導入完了だけでは判断できません。通信品質、セキュリティ検知、ポリシー適用、例外削減、ユーザー影響を継続的に確認します。

通信品質	遅延、パケットロス、アプリケーション応答時間、拠点ごとの通信経路を確認します。SASE経由化によって業務アプリケーションの体感性能が落ちていないかを見ます。
遮断・警告件数	不審サイト、マルウェア、ポリシー違反、未承認SaaS、データ持ち出しの検出件数を確認します。件数だけでなく、業務影響と誤検知率も合わせて判断します。
例外設定の数	期限のない例外、理由が不明な例外、特定部門だけに残る例外を確認します。例外が増え続ける場合は、設計か業務要件のどちらかを見直します。
VPN依存度	VPN接続数、同時接続数、VPN経由の通信量、VPNでしか利用できないアプリケーションを確認します。ZTNAやSASEへ移行できる範囲を判断する材料になります。
ポリシー変更時間	新しいSaaS利用、拠点追加、ユーザー追加、例外申請に対して、どの程度の時間でポリシーを反映できるかを確認します。