セキュリティ境界はネットワークから ID へ — ゼロトラスト時代の前提

🎯 はじめに：「VPN で社内に入れば安全」は今も正しいか？

本記事はシリーズ 「BtoB SaaS セキュリティ設計」の第 9 回 です。第 1 回 総覧 で軽く触れた「ゼロトラストへの段階移行」を、本記事で深掘りします。

セキュリティの世界では、長らく次の前提が支配していました。

「ファイアウォールの内側は信頼できる。だから VPN で内側に入りさえすれば安全。」

しかしこの前提は、ここ 10 年の間に 構造的に崩壊 しています。崩した主役は次の 4 つです。

1. IPv6 が NAT 前提を消し、「ローカルネットワーク」の自然な隠蔽を消した
2. SaaS の普及 が「保護すべきリソースは社内」という前提を消した
3. リモートワーク が「社員は社内ネットワークから繋ぐ」前提を消した
4. パスキー が「ネットワークではなく ID で確実に検証する」手段を提供した

セキュリティの境界は、ネットワークから ID へ移行している。

本記事ではこの転換を、技術的な根拠と実装手段に基づいて整理します。

🏰 古いモデル：ネットワーク境界モデル（Castle and Moat）

伝統的なセキュリティモデル（ネットワーク境界モデル）は 「城と堀（Castle and Moat）」 に喩えられます。

このモデルの前提：

• 物理的・論理的な 境界（ファイアウォール）が引ける
• 境界の 内側は信頼できる（社内 LAN）
• 境界の 外側は信頼できない（インターネット）
• VPN で内側に入れば、それ以降は 暗黙に信頼される

20 世紀末から 2010 年代前半までは、この前提が概ね成立していました。社員はオフィスから接続し、業務システムは社内サーバーに置かれていたからです。

🌐 IPv6 がもたらした構造変化：NAT 前提の崩壊

IPv4 時代のセキュリティは、「NAT による自然な隠蔽」 に大きく依存していました。

IPv4 + NAT が作っていた「内部の安全」幻想

IPv4 のアドレス枯渇への対処として、家庭・企業のほぼすべてが NAT（Network Address Translation） を採用しました。これにより：

• 内部のデバイスは プライベートアドレス （192.168.x.x 等）で、外部から直接到達できない
• 外部からの接続は 基本的にブロック される（NAT が「初期状態でドロップ」する）
• 結果、 「社内 LAN は外から見えない」 という自然な隠蔽が成立した

これは「セキュリティ機能ではなく副作用」ですが、 暗黙の境界防御 として実質的に機能していました。

IPv6 が消したもの

IPv6 は アドレス枯渇問題そのものを根本解決 するため、NAT を不要としました。

• アドレス長 : 128 ビット — IPv4 の 32 ビット（約 43 億個）に対し、地球上の機器すべてに固有アドレスを振っても枯渇しない規模に拡張
• 設計思想 : 各デバイスが グローバルユニキャストアドレス を持つ
• NAT は不要 : 各デバイスは 直接インターネットに到達可能
• SLAAC : 自動でグローバルアドレスを設定

IPv6 では「すべてのデバイスがインターネットから直接到達可能なアドレスを持つ」のが既定動作です。

ULA（Unique Local Addresses, fc00::/7）も存在しますが、これは「アドレスとしての private」であり、 IPv4 NAT のような「外から到達不能」は保証されません 。境界防御を IPv6 で得るには、 明示的なファイアウォール設定が必須 です。

「ローカルネットワークが自然に外部から隠蔽される」という IPv4 時代の前提は、IPv6 では 構造的に成立しません 。

詳細は別記事 IPv4 vs IPv6 — アドレス枯渇から見たインターネット設計の転換点 を参照してください。

💼 SaaS + リモートワークが壊した「内部 / 外部」の二分法

IPv6 と並行して、業務環境そのものが大きく変わりました。

SaaS への移行

業務データのほとんどが 社外の SaaS に置かれている現代、 「社内ネットワークの内側にデータがある」前提が成立しません 。VPN で社内に入っても、結局 SaaS にはインターネット経由で到達することになります。

リモートワークの常態化

リモートワークの普及で、社員は オフィスの外 から仕事をするのが当たり前になりました。「社員 = 社内 LAN にいる」前提が崩れた結果、 「VPN を全員に張る」運用 が現実的でなくなっています。

• VPN サーバーがボトルネック化（数千人規模で性能限界）
• VPN 接続後の通信が すべて VPN 経由 になり、SaaS アクセスが遅くなる
• VPN 越しに SaaS を使うのは 論理的に無意味 （結局インターネットに出る）

🚨 VPN モデルの脆弱性 — 「内部に入れば信頼」の代償

VPN ベースのモデルには 構造的な脆弱性 があります。

横展開攻撃（Lateral Movement）

VPN で「内部」に入った接続は、それ以降のすべてのアクセスが 暗黙に信頼 されます。攻撃者が 何らかの方法で 1 つのアカウント（または端末）を侵害 すれば、その接続を踏み台に 社内の他のリソースへ自由に横展開 できてしまいます。

過去の大規模インシデント（例：SolarWinds 事件、Colonial Pipeline 事件など）の多くは、 「初期侵入後の横展開で被害が拡大した」 パターンです。VPN の「内側は信頼」モデルがこの拡大を許しました。

認証情報の単点突破

VPN は通常、 ユーザー名 + パスワード（+ MFA） で認証されます。これが突破されると：

• VPN 接続後はネットワーク的に「内部」扱い
• 内部の認証は 甘い ことが多い（VPN を通った時点で信頼）
• 結果、 1 段階の認証突破 = 全社のリソースへのアクセス

これは ID ベースの認証で すべてのリクエストを毎回検証 するモデルと真逆です。

🛡️ 新しいモデル：ID 境界モデル（ゼロトラスト）

これらの問題への解として登場したのが ゼロトラスト（Zero Trust） です。

コアスローガン

「Never trust, always verify」 — 何も信頼せず、常に検証する。

ネットワーク位置（社内 / 社外）にかかわらず、 すべてのアクセスをその都度検証 します。VPN で内側に入っても、特別扱いはしません。

NIST SP 800-207 の 3 コンポーネント

NIST が 2020 年に公開した SP 800-207「Zero Trust Architecture」 は、ゼロトラストを 3 つの論理コンポーネントで定義しています。

すべてのリソースアクセスが PEP を通過 し、PE による 動的なリスク評価 に基づいて許可されます。

🔐 ゼロトラストの 3 軸：人 / デバイス / コンテキスト

ID 境界モデルが検証するのは、ネットワーク位置ではなく 以下の 3 軸 です。

① 人（Identity）

• パスキー によるフィッシング耐性のあるログイン
• OIDC + PKCE による標準プロトコル化
• SSO + MFA で 1 アカウント = 1 認証チェーン

② デバイス（Device）

• デバイス証明書 で正規端末であることを検証
• MDM（Mobile Device Management）でセキュリティポスチャを管理
• 暗号化・OS パッチ状況・マルウェア対策の有無を検証

③ コンテキスト（Context）

• IP / 地理的位置 : 普段と違う国からのアクセスは追加検証
• 時刻 : 業務時間外の異常アクセス
• 行動パターン : 不可能な移動（短時間で別大陸からアクセス）
• リスクスコア : 上記を統合した動的判定

これら 3 軸の すべて が満たされた時のみ、アクセスを許可します。

🏢 BeyondCorp — Google の VPN 廃止実装

ゼロトラストの最も有名な実装事例が、Google の BeyondCorp です。

背景

2009 年の Operation Aurora（中国を発信源とする APT 攻撃）で侵害を受けた Google は、 「ネットワーク境界はもはや守れない」 という結論に達しました。これを受けて 2011 年から開始したのが BeyondCorp プロジェクトです。

特徴

• VPN を完全に廃止
• すべての社内アプリへのアクセスを「公開 Web アプリ」として再設計
• Identity-Aware Proxy（IAP） が PEP として機能
• 社員は どこからでも、どのネットワークからでも 同じ手順でアクセス
• 内部ネットワークも外部ネットワークも 完全に非信頼 扱い

「Googler の全員が、信頼できないネットワークから VPN なしで仕事する」 — これが BeyondCorp の到達点です。

商用版 BeyondCorp Enterprise として GCP で提供されており、Identity-Aware Proxy（IAP）と組み合わせて他組織でも採用可能です。

🛠️ CTS-EC での適用 — ネットワーク境界に依存しない設計

当社の BtoB マルチテナント SaaS でも、ゼロトラストの考え方を 段階的に取り込んでいます 。本記事冒頭で挙げた 4 つの転換に対応する形で、以下の構成を採用しています。

「内部ネットワーク」という概念に頼らない設計 を貫くことで、リモートワーク・SaaS・IPv6 環境のいずれでも 同じセキュリティモデル で守れます。

🚀 ゼロトラストへの段階的移行ロードマップ

ゼロトラストは 「明日 VPN を切る」 という単発の決断ではなく、 多年にわたる段階的移行 が現実です。NIST SP 800-207 も「成熟度モデル」を提唱しています。

当社は現状 Phase 1 〜 2 を完了し、Phase 3 への移行を計画中 です。「全社で一斉に VPN を切る」ことを目指すのではなく、 新規構築する基盤を最初からゼロトラスト前提で作る ことで、移行コストを抑えています。

🤔 なぜ VPN は今も使われ続けるのか（過渡期の現実）

ゼロトラストへの移行が「正解」だとして、なぜ VPN は今も広く使われているのか？ 主な理由：

1. レガシーシステム : 認証を VPN に外注している社内システムは、 アプリ自体を改修しない限り ID ベース化できない
2. ベンダー支配 : VPN 機器・ソフトウェアの保守契約が長期化している
3. 理解の遅れ : 経営層・情シスに「VPN = セキュリティの当たり前」が染み付いている
4. 代替コスト : IAP / SSO / デバイス管理を全面導入するコストが大きい

VPN 自体が悪ではなく、 「VPN 接続後の暗黙信頼」 が問題です。VPN を 「安全なトンネル」として使う 一方で、 VPN を抜けた先のリソースアクセスを毎回検証する ハイブリッド運用が、現実的な過渡期の解です。

🧭 まとめ

• セキュリティの境界は ネットワークから ID へ 移行している
• IPv4 + NAT が作った「自然な境界」は、 IPv6 では構造的に成立しない
• SaaS + リモートワーク + パスキーが、 「内部 = 信頼」前提を実質的に廃止 した
• 解は ゼロトラスト：ネットワーク位置を見ず、すべてのアクセスを ID とコンテキストで検証
• Google BeyondCorp が VPN 廃止の参照実装、商用版が他組織でも利用可能
• 当社の BtoB SaaS は WIF / Cognito + パスキー / mTLS / Cloud Run で、最初からゼロトラスト前提の設計
• 移行は 段階的 が現実、新規構築から導入するのが摩擦が少ない

VPN への過剰な信頼は、 過去のネットワーク前提に最適化された判断 です。現代のクラウド・SaaS・モバイル・IPv6 時代では、 ID と毎回の検証 こそが新しい境界です。

📚 シリーズ記事

📖 関連用語

• ゼロトラスト — 本記事のテーマ。NIST SP 800-207 が標準仕様
• ネットワーク境界モデル — ゼロトラストが置き換える古いモデル
• BeyondCorp — Google の VPN 廃止型ゼロトラスト実装
• IPv6 — NAT 前提を消し、ID 境界への移行を後押し
• 多層防御 — 独立した複数の層で重ねて防御する設計思想
• パスキー — フィッシング耐性が極めて高いパスワードレス認証
• Workload Identity Federation — 静的な鍵を使わないクラウド権限付与
• AWS Cognito — マネージド認証・認可サービス
• Adaptive Authentication — リスクベース認証

🔗 参考リンク

• NIST SP 800-207 — Zero Trust Architecture
• BeyondCorp — Google Cloud
• IPv4 vs IPv6（当社ナレッジベース）