はじめに
全社的に境界防御（ペリメータ型）から脱却し、ゼロトラスト型のネットワークへ移行しよう——そう考えて調べ始めたとき、私は次のような壁にぶつかりました。
「うちで使っている業務用VPNルーターは、拠点をスター型かメッシュ型でつなぐことしかできない。これではゼロトラストにできないのでは？」
結論から言うと、これは完全な誤解でした。原因は、本来まったく別の2つの軸を、頭の中で1つにくっつけてしまっていたことにあります。
- ネットワークトポロジ（スター型・メッシュ型…）= パケットが「どうつながり、どこを通るか」
- 信頼モデル（境界防御・ゼロトラスト）= 「誰が・何に・どこで検証されてアクセスできるか」
この2つは直交する別の軸です。本記事は、同じ誤解をしている人に向けて、この2軸を分離して整理することを目的にしています。ゼロトラスト移行の入口でつまずきやすい、定番のポイントだと思います。
私がハマった誤解の構造
最初に、自分がどう間違えていたかを言語化しておきます。誤解には2段階ありました。
誤解1: 「ルーターでできること = ネットワーク設計の全て」
業務用VPNルーターの設定画面は、基本的に「拠点をどうつなぐか」を組むための道具です。
- 本社にトラフィックを集約する → ハブ&スポーク（スター型）
- 拠点同士を直接つなぐ → フルメッシュ
設定項目がトポロジ中心なので、「ネットワーク設計＝トポロジ設計の全て」 だと錯覚してしまいました。実際には、ルーターが担うのは経路制御・VPN・NAT・基本的なフィルタリングといったL3前後のレイヤであって、ネットワークセキュリティ全体のごく一部です。
誤解2: 「トポロジを変えれば信頼モデルが変わる」
そして決定的だったのがこちら。「スター型/メッシュ型しか組めない＝ゼロトラストにできない」という発想は、トポロジを変えればセキュリティモデルが変わるという前提に立っています。
しかしゼロトラストは、トポロジをどう組むかという話とはそもそもレイヤが違うのです。
軸を分けて整理する
軸その1: ネットワークトポロジ
トポロジは「ノードがどうつながっているか」という接続形態です。
| トポロジ | 概要 |
|---|---|
| スター型 / ハブ&スポーク | 中心ノード（本社・データセンタ等）に集約 |
| メッシュ型 | ノード同士を直接相互接続（フルメッシュ／部分メッシュ） |
| バス型・リング型 | 1本の伝送路や環状に接続（現代のLANでは稀） |
ポイントは、トポロジが答えるのは「パケットがどの経路を通るか」だけだということです。誰がアクセスを許されるか、どこで認証するか、には一切踏み込みません。
軸その2: 信頼モデル
信頼モデルは「どういう前提でアクセスを許可するか」という考え方です。
| モデル | 前提 | 検証の場所 |
|---|---|---|
| 境界防御（ペリメータ型） | 境界で一度検証すれば、以後は内部を暗黙的に信頼（いわゆる Trust but verify） | ネットワークの「境界」（ゲートウェイ/FW）で1回 |
| ゼロトラスト | どこも信頼しない（Never trust, always verify） | リソースへのアクセスのたびに毎回 |
境界防御は「一度社内に入ればおおむね信頼」。だから侵入されると横移動（ラテラルムーブメント）を止めにくい。ゼロトラストは「社内/社外を問わず、アクセスのたびにアイデンティティとデバイスの状態を検証する」という発想です。
2軸は直交する
ここが本記事で一番伝えたいことです。この2軸は互いを規定しません。
信頼モデル
境界防御 ゼロトラスト
┌──────────┬──────────┐
スター型 │ ○ │ ○ │
ト ├──────────┼──────────┤
ポ メッシュ型│ ○ │ ○ │
ロ ├──────────┼──────────┤
ジ ハブ& │ ○ │ ○ │
スポーク │ │ │
└──────────┴──────────┘
どのマスも成立する = 2軸は独立
- スター型でも境界防御もゼロトラストも組める
- フルメッシュVPNでも同じく両方組める
- トポロジは信頼モデルを決めない。信頼モデルもトポロジを要求しない。
つまり「スター型/メッシュ型しか組めないからゼロトラストにできない」という推論は、独立した2軸を勝手に連動させてしまった、ということになります。
では、ゼロトラストの「本体」はどこにあるのか
トポロジでないなら、ゼロトラストの実体は何か。これは NIST SP 800-207 が定義しており、特定の製品でもトポロジでもなく、アーキテクチャ（原則の集合） です。
NIST が定める7つの原則（要約）
- すべてのデータソース・コンピューティングサービスをリソースとして扱う
- ネットワークの場所に関係なく、すべての通信を保護する
- リソースへのアクセスはセッション単位で許可する
- アクセス可否は動的なポリシー（アイデンティティ・デバイス状態・属性など）で判断する
- 全資産の整合性とセキュリティ状態を監視・測定する
- 認証・認可はアクセスのたびに動的かつ厳格に実施する
- 資産・通信・インフラの情報を可能な限り収集し、セキュリティ態勢の改善に使う
注目してほしいのは、この7原則のどこにも「トポロジをこう組め」とは書かれていないことです。書かれているのは「誰を・どう検証するか」だけです。
中核コンポーネント: PDP と PEP
NIST はゼロトラストの論理コンポーネントとして、次の2つを中心に据えています。
| コンポーネント | 役割 | たとえると |
|---|---|---|
| PDP（Policy Decision Point） | アクセス可否を判断する頭脳。ポリシーエンジン(PE)＋ポリシー管理(PA)からなる | 入館を許可するか決める警備本部 |
| PEP（Policy Enforcement Point） | リソースの手前で、PDPの決定を実行する関所 | 改札・入館ゲート |
ユーザーやデバイスがリソースにアクセスしようとするたびに、PEP が通信を止め、PDP が「このアイデンティティ・このデバイス状態・この文脈で許可してよいか」を判断する——これがゼロトラストの動作の核です。
[ユーザー/デバイス] --①アクセス要求--> [PEP(関所)]
│
②可否を問い合わせ
↓
[PDP(頭脳)]
アイデンティティ・デバイス状態
・文脈・脅威情報をもとに判断
│
③許可/拒否を返す
↓
[ユーザー/デバイス] <--④許可されたら接続-- [PEP] --> [リソース]
この PDP/PEP は、アイデンティティと認可のレイヤの話です。L3ルーターがやっている経路制御とは、そもそも階層が違います。だから「ルーターのトポロジ機能」をいくら眺めても、ゼロトラストの本体は見つからないのです。
ルーターは「無関係」なのか？ いいえ、PEPの一部になり得ます
誤解を解いた上で、もうひとつ補足が要ります。「じゃあ既存のルーターはゼロトラストと無関係なのか」と言うと、それも違います。
- ルーターやファイアウォールは、PEP（関所）の一部として機能し得ます。
- セグメント分割やフィルタリングは、ゼロトラストにおけるマイクロセグメンテーションの土台になります。
ただし重要なのは、ルーター単体ではゼロトラストにならないということです。ゼロトラストには、
- アイデンティティ基盤（IdP / SSO / MFA）
- デバイスの状態評価（ポスチャチェック）
- ポリシー判定エンジン（PDP）
- アクセスのたびの継続的検証
といった、ルーターの外側にあるコンポーネントが必要です。ルーターは「材料の一部」であって「料理そのもの」ではない、というイメージが近いです。
「○○というルーターを使っているからゼロトラストにできない」が成り立たない理由
ここまでを踏まえると、冒頭の悩みは次のように整理できます。
- ルーターが提供するのはトポロジと経路制御（＝軸その1）
- ゼロトラストは信頼モデルとアクセス制御（＝軸その2）
- 2軸は直交しているので、ルーターのトポロジ機能はゼロトラスト化を妨げない
- 既存のトポロジ（スター型でもメッシュ型でも）はそのまま残しつつ、その上に PDP/PEP・アイデンティティ基盤を載せることでゼロトラストへ移行できる
つまり、ネットワークを物理的に組み替える話ではなく、「どこで・何を根拠にアクセスを検証するか」という制御の重心を、境界からリソースの手前（＝アイデンティティ）へ移す話なのです。
混同しやすい関連用語の交通整理
ついでに、調べているうちに混ざりやすかった用語も分離しておきます。
| 用語 | 何の話か | 軸 |
|---|---|---|
| スター型 / メッシュ型 | 接続形態 | トポロジ |
| 境界防御 / ゼロトラスト | アクセス制御の前提 | 信頼モデル |
| VPN | 拠点・端末を暗号化トンネルでつなぐ手段 | 接続手段（トポロジ寄り） |
| ZTNA | ゼロトラスト原則でアプリ単位のアクセスを仲介する製品カテゴリ | 信頼モデルの実装 |
| SDP（Software Defined Perimeter） | 必要な相手にだけ動的に接続経路を開く考え方 | 信頼モデルの実装 |
| SASE | ネットワーク機能とセキュリティ機能をクラウドで統合する枠組み | 提供形態 |
特に「VPN ＝ ゼロトラスト」と思いがちですが、VPNは**つなぐ手段（トポロジ寄り）**であって、つないだ先を信頼してしまえばそれは境界防御のままです。ZTNA はそこを「アプリ単位・アクセス単位で検証する」方向に置き換える実装、という関係になります。
移行を考えるときの実務的な視点
最後に、概念整理を踏まえた移行の入口メモを残しておきます（詳細な手順は別記事のテーマにします）。
- トポロジは無理に変えない。今の接続形態は活かせる。変えるのは「検証の重心」。
- 守るリソースを棚卸しする。NISTの原則1（すべてをリソースとして扱う）の出発点。
- アイデンティティ基盤を中心に据える。IdP/MFA/デバイス評価がPDPの判断材料になる。
- PEP を段階的に挿入する。いきなり全部ではなく、重要なアプリ・リソースから。
- 「内部だから信頼」をやめる。ここが境界防御からの一番の意識転換。
おわりに
私の最初の誤解は、「ネットワークトポロジ」と「信頼モデル」という直交する2軸を、1つの軸だと思い込んでいたことに尽きました。
- トポロジは「どうつなぐか」
- 信頼モデルは「どう検証するか」
- ゼロトラストは製品でもトポロジでもなく、NIST SP 800-207 が定義するアーキテクチャ
- 既存のルーター・トポロジはそのままに、アイデンティティを中心とした検証の仕組み（PDP/PEP）を載せていく
「うちのルーターじゃ無理」と感じたら、それはたいていトポロジの話と信頼モデルの話を混同しているサインです。軸を分けて考えれば、移行の道筋はぐっと見通しが良くなります。
参考リンク
教育で世界No.1へ。 スプリックスIT戦略部の公式テックブログです🌸 渋谷本部・長岡ラボの2拠点がワンチームとなり、世界展開する教育サービスを支えています！ 生成AI活用・モダンな技術スタックへの刷新・地方での組織づくりなど、私たちが日々の開発で得た知見と挑戦の記録をオープンに発信します
Discussion