レッスン5：柱③ネットワーク——VPN からの出口を設計する

このレッスンで学ぶこと

ZTNA と SDP の仕組みを説明できる
VPN との構造的な差を、全網接続とアプリ単位接続という観点で理解する
マイクロセグメンテーションによって、ポリシーの粒度がどう変わるかを説明できる
ラテラルムーブメントが止まる仕組みを、防御側の構造として理解する
SASE と SSE の構成要素を整理できる
VPN を残す判断が正解になる場面を理解する

前回のレッスンでは、アイデンティティとデバイスという 2 つの柱を扱いました。今回のレッスンは、この 2 つの柱を土台に、ネットワークの柱を扱います。中核メッセージの 4 番目、「VPN を止めることが目的ではない。止められる状態を作ることが目的である」を、具体的な設計として展開する回です。本コースの中でも、レッスン 3 と並んで最も厚みを持たせている領域です。

なぜ「VPN からの出口」なのか

多くの組織にとって、ネットワークの柱の議論は「VPN をどうするか」という問いから始まります。しかし、レッスン 1 で確認したとおり、VPN を止めること自体はゴールではありません。VPN が果たしてきた役割——社外から社内リソースへ安全に接続する手段——を、より細かい粒度で、より確かめながら提供できる仕組みに置き換えていくことが、この柱の実質的な作業です。

VPN という「入口」から、より安全な別の「出口」へと利用者を導いていく。この移行の設計こそが、レッスン名に込めた「出口を設計する」という意味です。

VPN の構造的な特徴——全網接続

VPN は、利用者の端末と社内ネットワークのあいだに、暗号化された通信トンネルを作る技術です。この技術そのものの解説は、情報セキュリティ関連の入門コースに譲りますが、本レッスンで押さえておきたいのは、VPN の構造的な特徴です。

VPN で接続すると、利用者の端末は、社内ネットワークの一部であるかのように扱われます。いったん接続が確立すれば、その利用者は、社内ネットワーク上にある多くのリソースに、追加の確認なしで到達できる状態になります。これを、全網接続と呼びます。個々のアプリケーションやシステムへのアクセスを、一つひとつ確かめて許可しているのではなく、「ネットワークに接続できた」という一点をもって、広い範囲への到達性を与えているのです。

この構造は、境界防御の発想——城の中に入れた者は仲間とみなす——と、そのまま重なります。VPN 自体は暗号化された安全な通信路を提供しますが、「一度入ったら広く動ける」という設計は、レッスン 1 で見た境界防御の限界を、そのまま引き継いでいます。

SDP——ソフトウェアで定義される境界

VPN の全網接続という発想を置き換えるために生まれたのが、SDP という仕組みです。SDP は、ネットワークの境界を物理的な機器の配置ではなく、ソフトウェアの制御によって動的に定義する仕組みです。SDP という略称の元になっている「境界」にあたる英単語がペリメータで、ソフトウェアの制御によってペリメータを動的に描き直す、という発想が SDP の名称そのものに表れています。

SDP の典型的な流れは、次のようなものです。利用者はまず、コントローラーと呼ばれる制御機能に対して認証を行います。認証が通ると、コントローラーは、その利用者がアクセスを許可されている個々のアプリケーションへの経路だけを、そのつど確立します。許可されていないアプリケーションやシステムは、そもそもネットワーク上に存在しないかのように、利用者の端末からは見えません。

この「見えない」という性質が重要です。VPN では、接続した利用者から見れば、社内ネットワークの構造がある程度見渡せてしまいます。SDP では、許可された経路以外は最初から見えないため、利用者の端末が侵害された場合でも、攻撃者が探索できる範囲そのものが狭くなります。

ZTNA——ゼロトラストの発想でリモートアクセスを実装する

SDP の考え方を土台に、ゼロトラストの原則に沿ってリモートアクセスを実装する仕組みが、ZTNA です。ZTNA は、レッスン 3 で扱った条件付きアクセスやレッスン 4 で扱ったデバイスポスチャといった判断材料を、ネットワーク接続そのものの可否に組み込みます。

ZTNA の接続は、多くの場合、利用者側の端末からコントローラーへの接続を起点にして確立されます。社内ネットワーク側から見て、外部からの着信を待ち受ける必要がないため、社内ネットワークの存在そのものを外部から見えにくくできます。VPN のように「サーバーが外部からの接続を待ち受ける」構成とは、根本的に異なる考え方です。

アクセスが許可されるのは、認証されたセッションの、許可された特定のアプリケーションに対してだけです。レッスン 1 で確認した NIST SP 800-207 の 3 番目の原則、「個々の企業リソースへのアクセスは、セッション単位で許可する」を、ネットワークの柱で具体化したものが ZTNA だと言えます。

VPN との構造的な差

ここまでの内容を、VPN と ZTNA・SDP という 2 つの系統で比較すると、次のように整理できます。

観点	VPN	ZTNA・SDP
接続の単位	ネットワーク全体への接続（全網接続）	個々のアプリケーションへの接続
許可されていない領域	見えてしまうことが多い	見えない設計にできる
接続の起点	サーバー側が外部からの着信を待ち受ける	利用者側の端末から接続を起点にできる
判断のタイミング	接続時に一度確認すれば、以後は広く到達可能	セッションごとに、アプリケーションごとに確認する

flowchart LR
  subgraph VPN["VPN の接続モデル"]
    U1[利用者] --> N1[社内ネットワーク全体]
    N1 --> A1[アプリ1]
    N1 --> A2[アプリ2]
    N1 --> A3[アプリ3]
  end
  subgraph ZTNA["ZTNA の接続モデル"]
    U2[利用者] --> C[コントローラー]
    C --> B1[許可されたアプリ1のみ]
  end

この図が示すとおり、VPN では、いったんネットワークに入ってしまえば、複数のアプリケーションへの到達性が同時に開かれます。ZTNA では、コントローラーが許可した個々のアプリケーションへの経路だけが、そのつど開かれます。この違いこそが、ネットワークの柱における成熟度の中心的な差です。

マイクロセグメンテーション——ポリシーの粒度を細かくする

ZTNA が主にリモートアクセスの入口を対象にするのに対し、社内ネットワークの内部でも同様の発想を適用する取り組みが、マイクロセグメンテーションです。

従来のネットワーク分割は、部門やフロアといった単位で、比較的大きな区画に分けるのが一般的でした。マイクロセグメンテーションは、この区画をさらに細かく、システムやワークロードの単位まで分割します。ある業務システムと、別の業務システムのあいだの通信であっても、あらかじめ許可されたものだけを通し、それ以外は遮断します。

区画が大きいほど、一つの区画の中で自由に到達できる範囲が広くなります。区画を細かくするほど、許可されていない通信を遮断できる範囲が広がり、結果として、後述するラテラルムーブメントを抑える効果が高まります。ただし、区画を細かくするほど、ポリシーの数も増え、設計と運用の手間が増加します。ネットワークの柱の成熟度を上げるとは、この粒度を、業務のリスクに見合った水準まで細かくしていく作業だと言えます。

💡 ポイント マイクロセグメンテーションは、「すべての通信を細かく分割すればするほどよい」という単純な話ではありません。重要度の低いシステム同士の通信まで細かく分割すると、運用の負担が投資対効果を上回ってしまいます。レッスン 2 で扱った成熟度の考え方と同様に、業務のリスクに応じて粒度を調整する視点が欠かせません。

ネットワークの柱の成熟度を段階で見る

レッスン 2 で紹介した 4 段階の成熟度を、ネットワークの柱に当てはめると、次のような姿になります。

段階	ネットワークの柱での典型的な状態
伝統的	全社員に VPN を配布し、接続後は社内ネットワーク全体を一律に信頼している
初期	一部の重要な業務システムに限り、ZTNA 経由でのアクセスを試験的に導入している
高度	主要な業務システムの多くが ZTNA 経由に切り替わり、社内でもマイクロセグメンテーションが部分的に進んでいる
最適	ネットワーク全体でアプリケーション単位の接続が標準になり、通信の可否がリアルタイムに評価・調整される

ここで注意したいのは、伝統的段階から初期段階への一歩が、必ずしも「VPN を全廃する」ことを意味しない点です。まずは一部の重要なシステムから ZTNA 経由に切り替え、効果と運用の負担を見極めながら範囲を広げていくのが、現実的な進み方です。

ラテラルムーブメントが止まる仕組み

ラテラルムーブメントとは、攻撃者が一つの端末やアカウントに侵入したあと、そこを足がかりに、ネットワーク内部の別のシステムへと移動を広げていく行動を指します。境界防御と全網接続の組み合わせでは、この移動が起きやすい構造になっています。

ZTNA とマイクロセグメンテーションが組み合わさると、この構造が変わります。侵入された一台の端末やアカウントから見えるのは、あらかじめ許可された特定のアプリケーションへの経路だけです。ほかのシステムへの通信は、そもそも許可されていないため、遮断されます。攻撃者は、次に進むための足がかりとなる「見える範囲」そのものを失います。

一つの侵害が、ほかのシステムへと連鎖しにくくなる。これが、ラテラルムーブメントが止まる、防御側の構造です。ランサムウェアが社内システム全体に広がる被害の多くは、このラテラルムーブメントが起点になっており、ネットワークの柱の成熟度は、被害の広がり方そのものを左右します。

SASE と SSE——構成要素を三点セットで捉える

ZTNA やマイクロセグメンテーションを含む、ネットワークとセキュリティの機能をクラウド上で統合的に提供する枠組みが、SASE と SSE です。SASE は、WAN（広域網）の機能とセキュリティの機能を統合したより広い枠組みを指し、SSE は、その中からセキュリティに関する機能だけを切り出した部分を指します。

SSE の中核となる機能は、次の三点セットとして整理されることが一般的です。

SWG：Web への通信を検査し、危険なサイトへのアクセスを制御する機能
CASB：クラウドサービスの利用状況を可視化し、制御する機能
ZTNA：これまで説明してきた、アプリケーション単位でのアクセス制御機能

これら 3 つの機能が、クラウド上で一体的に提供されることで、利用者がどこからアクセスしても、同じ水準のポリシーが適用される構成を実現します。本コースでは、特定の製品やサービスの比較には踏み込みませんが、「ネットワークの柱の成熟度を上げる手段が、こうした統合的な枠組みとして提供されている」という位置づけを押さえておいてください。

SASE と SSE の違いを整理すると、SASE は WAN の機能——拠点間をどうつなぐかという回線側の設計——まで含む、より広い枠組みです。SSE は、その中からセキュリティに関する機能だけを取り出したものにあたります。自社が拠点間の回線設計そのものから見直す必要があるのか、それとも既存の回線構成は維持しつつセキュリティの機能だけを強化したいのかによって、SASE と SSE のどちらを軸に検討するかが変わってきます。この判断も、ネットワークの柱の成熟度と、自社の業務実態を照らし合わせて行うべきものです。

📝 補足 SWG・CASB・ZTNA という三点セットのうち、CASB はクラウドサービスの利用状況を可視化する機能として、名称だけを押さえておけば十分です。特定の製品がどこまでの機能を持つかは、情シス関連の入門コースで扱う製品選定の領域にあたります。

VPN を残す判断も正解になる場面

ここまで、VPN から ZTNA・SDP への移行を中心に説明してきましたが、すべての通信を一律に置き換えることが、常に正しいわけではありません。

古い業務システムが、最新の認証方式に対応しておらず、ZTNA の仕組みに組み込めない場合
拠点間の大量データ転送など、アプリケーション単位の細かい制御になじまない通信がある場合
アイデンティティやデバイスの柱がまだ十分に成熟しておらず、判断材料が揃っていない場合

こうした場面では、無理に VPN を止めるよりも、当面は VPN を残しつつ、ほかの柱の成熟度を上げることを優先する判断が、現実的な選択になります。中核メッセージの 4 番目が「VPN を止めることが目的ではない」と述べているのは、まさにこの点を指しています。VPN を残すこと自体が失敗なのではなく、なぜ残しているのかを説明できない状態が、移行計画における本当の問題です。

VPN を残す判断をするときは、「残す・置き換える」の二択で終わらせず、次のような観点を記録しておくと、後から振り返りやすくなります。

観点	記録しておく内容の例
対象	どの業務システム、どの拠点の通信が VPN 経由のままか
理由	認証方式が対応していない、改修に生産停止が必要など、残している具体的な理由
補完策	VPN 経由の通信であっても、接続元の制限や監視の強化など、リスクを抑えるために追加している対策
見直し時期	次にいつ、置き換えの可否を再検討するか

この記録は、レッスン 8 で扱う移行ロードマップの中でも、経営への説明資料として活きてきます。「なぜ全面移行していないのか」という問いに、根拠を持って答えられる状態を作ることが、VPN を残す判断そのものよりも重要です。

⚠️ 注意 「VPN が残っている＝ゼロトラストが未完成」という単純な評価は避けるべきです。成熟度モデルの視点では、VPN を残しながらも、残された通信の範囲を限定し、監視を強化している状態であれば、それも一つの成熟度の到達点として説明できます。

講師の現場メモ②：ZTNA を入れたのに VPN を止められなかった話

私（相良）が製造業でネットワークの柱に着手したときの話です。移行計画では、主要な業務システムへのリモートアクセスを、2 年目のうちに ZTNA へ全面的に切り替え、VPN は廃止する予定でした。

実際に ZTNA の導入は、想定より順調に進みました。主要な業務システムの大半は、ZTNA 経由でのアクセスに切り替わり、利用者からの評判も悪くありませんでした。「アプリごとに接続する感覚が新鮮だ」という声もありました。しかし、VPN の廃止は、計画の期限が来ても実現できませんでした。

原因は、ごく一部の古い業務システムでした。工場の設備を制御するシステムの一つが、ZTNA が前提とする認証方式に対応しておらず、置き換えには設備側の改修が必要でした。改修には、生産ラインを止める必要があり、年に数回しかない計画停止のタイミングでしか実施できません。結果として、この一つのシステムのためだけに、VPN を残さざるを得ませんでした。

さらに厄介だったのは、「一つのシステムのために VPN を残す」という判断が、なし崩し的に広がっていったことです。「あのシステムも VPN 経由の方が楽だから」という声が現場から上がり、気づけば当初の想定より多くの通信が VPN 経由のまま残っていました。私はこの状況に危機感を覚え、残った VPN 経由の通信を一覧化し、それぞれに「なぜ残っているか」「いつまでに置き換えるか」を明記した台帳を作りました。理由のない延命を止め、期限を区切って管理する。この地道な作業によって、VPN は「なんとなく残っている」状態から、「管理された残存」に変わりました。

この経験から私が学んだのは、VPN の廃止を計画のゴールに置くと、廃止できなかったことが失敗に見えてしまうということです。本当に必要なのは、VPN に頼らなくてもよい状態を、柱ごとの成熟度として着実に積み上げることであり、最後まで残る通信があるなら、それを管理された形で残す判断も、立派な設計の一部です。

まとめ

このレッスンでは、以下のことを学びました。

ネットワークの柱の作業は、VPN を「止めること」ではなく「止められる状態を作ること」に主眼がある
VPN は全網接続の構造を持ち、いったん接続すれば広い範囲への到達性が開かれる
SDP はソフトウェアの制御で境界を動的に定義し、許可されていない領域を見えなくする
ZTNA は SDP の考え方を土台に、アプリケーション単位でのアクセス制御をゼロトラストの原則に沿って実装する
マイクロセグメンテーションは、ネットワークの分割単位をシステムやワークロードの粒度まで細かくする
ラテラルムーブメントは、侵入された端末から見える範囲が狭いほど止まりやすくなる
SASE と SSE は、SWG・CASB・ZTNA という三点セットを中心に、ネットワークとセキュリティの機能をクラウド上で統合的に提供する
古い業務システムなどの事情で VPN を残す判断も、理由を説明できるなら正解になりうる

次のレッスンでは、アプリケーションとデータという 2 つの柱をまとめて扱います。データ分類が、どのように権限の設計へとつながっていくかを見ていきます。

確認クイズ

このレッスンの理解度をチェックしましょう。