SASE でグローバル IP は不要になるのか – 外部公開点と責任分界で考える

SASE を説明する時に、「SASE を使えばグローバル IP は不要になる」と言われることがあります。

この説明は、かなり危ういです。言いたいことは分からなくはありません。従来の VPN 装置のように、自社ネットワーク側へ直接アクセス可能なグローバル IP を持たせる必要がなくなる、という意味なら理解できます。

しかし、それを「グローバル IP が不要になる」と表現すると、外部から到達するための公開点そのものが消えるかのように見えてしまいます。実際には、公開点は消えるのではなく、SASE 側、クラウドサービス側、または中継基盤側へ移ります。

この記事では、SASE とグローバル IP の関係を、外部公開点、到達性、責任分界の観点から整理します。

グローバル IP が不要になるわけではない

インターネット越しに何かへ接続する以上、どこかにはインターネットから到達可能な入口が必要です。

従来型の VPN では、その入口が企業側の VPN gateway に置かれることが多くありました。利用者はインターネットから企業のグローバル IP へ接続し、そこから社内ネットワークへ入ります。

SASE や ZTNA 型の構成では、この入口の位置が変わります。利用者は SASE provider の edge や broker に接続し、社内側は outbound connection や connector を通じてサービスへ到達させる構成になります。

つまり、なくなるのは「自社側で外部から直接待ち受けるグローバル IP」であり、グローバル IP や外部公開点という概念そのものではありません。

外部公開点がどこに移るのかを見る

ネットワーク設計として見るべきなのは、「グローバル IP があるかないか」ではなく、外部公開点がどこにあるかです。

構成	外部公開点	主な責任
従来型 VPN	企業側 VPN gateway	企業側の Firewall、VPN 装置、認証、ログ、脆弱性管理
SASE / ZTNA	SASE provider の edge / broker	Provider 側の公開基盤、企業側の policy、connector、認証連携
Reverse proxy 型公開	公開 proxy / WAF	proxy、証明書、認証、上流アプリケーション、ログ
Cloud service	クラウド事業者側 endpoint	クラウド側の公開基盤、利用者側の設定、権限、監査

公開点が企業のデータセンターから SASE provider へ移れば、攻撃面、監視対象、ログの所在、障害時の切り分け、責任分界も変わります。

ここを見ずに「グローバル IP が不要」とだけ言うと、設計の本質を見失います。

VPN と SASE で何が変わるのか

従来型 VPN と SASE の違いは、単に VPN 装置がクラウドへ移ることではありません。

従来型 VPN は、利用者を企業ネットワークへ入れる発想になりがちです。一度接続すると、社内ネットワークの一定範囲へ到達できる設計になっていることもあります。

SASE や ZTNA は、利用者をネットワークへ入れるというより、利用者、端末、認証状態、policy、対象アプリケーションを評価し、必要な通信だけを通す方向へ寄せます。

ここで変わるのは、IP アドレスの有無ではなく、接続モデルです。

• ネットワーク単位の接続から、アプリケーション単位の接続へ寄せる
• 外部からの待ち受けを企業側に置かず、provider 側へ寄せる
• 認証、端末状態、policy によって到達性を制御する
• 通信ログや制御点が SASE 側へ集まりやすくなる

この違いを理解しないまま「グローバル IP 不要」と言ってしまうと、SASE の説明ではなく、単なる営業資料の見出しになります。

Outbound connection だから安全とは限らない

SASE や ZTNA では、社内側 connector が outbound connection を張る構成があります。これにより、社内側でインターネットから直接待ち受ける必要を減らせます。

これは大きな利点です。ただし、outbound connection だから自動的に安全、というわけではありません。

connector が侵害された場合、どの範囲へ到達できるのか。provider 側の障害時にどう切り分けるのか。認証連携が壊れた時に誰が判断するのか。ログはどこに残るのか。通信経路はどこで暗号化され、どこで復号されるのか。

公開点を自社から外したとしても、責任が消えるわけではありません。責任の置き場所が変わるだけです。

SASE で設計すべき責任分界

SASE を導入する時は、製品名や機能一覧よりも先に、責任分界を整理する必要があります。

論点	確認すべきこと
外部公開点	誰の基盤がインターネットから到達されるのか
認証	IdP、MFA、端末状態、policy をどこで評価するのか
到達性	どの利用者が、どのアプリケーションへ、どの条件で到達できるのか
ログ	接続ログ、認証ログ、通信ログをどこで保管し、誰が見るのか
障害切り分け	利用者端末、SASE edge、connector、社内アプリをどう分けて見るのか
運用権限	policy 変更、例外許可、緊急遮断を誰が行うのか

これらを決めずに SASE を導入すると、見た目は近代的でも、障害時や例外対応時に責任が曖昧になります。

グローバル IP を持たないことと、公開しないことは違う

「自社側にグローバル IP を持たない」ことと、「サービスを外部へ公開していない」ことは違います。

SASE provider 経由でアクセスできるなら、そのサービスは何らかの形で外部から利用可能です。違いは、誰が公開点を持ち、どの条件で到達性を与え、どこで認証と認可を行うかです。

この違いを潰すと、ネットワーク設計とセキュリティ設計が雑になります。

重要なのは、グローバル IP を減らしたことではありません。外部からの到達性を、どの制御点で、どの責任分界で扱うかです。

まとめ

SASE を使えば、企業側で外部から直接待ち受ける VPN gateway や公開 IP を減らせる場合があります。

しかし、それは「グローバル IP が不要になる」という話ではありません。外部公開点が移動し、接続モデルが変わり、責任分界が変わるという話です。

SASE の価値は、単にグローバル IP を隠すことではありません。利用者、端末、認証、policy、アプリケーション単位で到達性を制御し、外部公開点と責任分界を再設計できることにあります。

だからこそ、SASE を説明する時に必要なのは、「グローバル IP が不要」という雑な言い方ではありません。

どこが外部から到達されるのか。誰が公開点を持つのか。どの条件でアプリケーションへ接続できるのか。障害時にどこを見るのか。

そこまで分けて説明して初めて、SASE はネットワーク設計として理解できます。

関連する記事

• 障害切り分けとは何か – 影響範囲から構造を読む
• 技術力が高いとは何か – 通信キャリア、ISP、SIer の評価軸を分けて考える
• TFTP の仕組みとファイアウォール設計 – UDP、動的ポート、PXE Boot を分けて考える