VPN（Virtual Private Network）

1. 概要

A. 定義

公衆ネットワーク（インターネット）上に暗号化された仮想の専用通信路（トンネル）を構成し、物理的には公衆網を通過するが論理的には専用網のように安全にデータを送受信する技術である。

VPNの本質は「所有」ではなく「構成」にある。専用線が物理回線を独占所有して安全性を得るのに対し、VPNは他者と共有するインターネット回線上に暗号・認証・完全性というソフトウェア的な仕組みを被せ、独占したものと同等の信頼水準を作り出す。すなわち同じ光ケーブルを無数のパケットが共に通過しても、特定の送受信者だけが開ける「論理的な壁」を立て、事実上の専用網を模倣するのがVPNである。

B. 登場背景および必要性

拠点間通信や在宅勤務者の社内接続のために物理専用線（Leased Line）を敷設する方式は安全だが、費用が地域・距離に比例して急増する。ソウル-釜山の専用線とソウル-ニューヨークの専用線の月額賃料が数十倍も異なるのはまさにこの距離依存性ゆえであり、グローバルに散在する拠点・リモートワーカーをすべて専用線で結ぶのは大企業にとっても非現実的である。インターネットは既に全世界に敷設されており限界費用は事実上ゼロに近いが、誰もがパケットを覗ける開放網であるため、そのまま使えば盗聴・改ざん・なりすましの危険が大きい。

VPNはこの両者の長所だけを取り、安価なインターネット上に暗号化・認証・完全性を施したトンネルを載せることで、専用線水準の安全性をはるかに低い費用で実現する。距離に関係なく「インターネットに届きさえすれば」接続が成立するため、新拠点が生じても社員が海外出張に出ても回線工事なしに即座に安全な接続が可能であるという拡張性・俊敏性が専用線に対する決定的な利点である。

特に2020年代以降、リモートワークが常態化し企業資源が社内データセンターからクラウド（SaaS・IaaS）へ分散するにつれ、「いつでも・どこでも・どの端末でも安全に接続」したいという需要が急増した。かつては事務所という物理的境界の内側に資源が集まっていたが、今や利用者も資源も境界の外に散在している。この変化がVPNを企業ネットワークの選択肢から基本インフラへ押し上げ、同時に後述するZTNAのような次世代モデルへの進化圧力を生み出した。

C. 特徴

VPNを他の安全技術と区別する特徴は三つに要約される。第一は仮想化（Virtualization）であり、物理回線を新たに敷かずソフトウェア設定だけで専用経路を作り出す点である。第二は終端間保護（End-to-End Protection）であり、暗号化が特定区間ではなく両終端の間の全区間にわたって維持される。第三は透過性（Transparency）であり、いったんトンネルが立てば上位アプリケーションは自らがVPN上で動作している事実を知らなくてもそのまま通信できる。この三つが結合し「低費用・高信頼・無改修」というVPNの実務的魅力を作る。

2. VPN全体の動作構造

VPN接続は「トンネルを立て（制御プレーン）→立てたトンネルでデータを流す（データプレーン）」の二段階で理解すれば明確である。下の構造図は、リモート利用者と本社ゲートウェイの間にトンネルが形成され、その中を平文トラフィックが暗号化されて行き来する全体の流れを示す。

flowchart LR
  subgraph Client["利用者端末"]
    APP["業務アプリ(平文)"] --> VC["VPNクライアント(暗号化)"]
  end
  VC -->|"暗号化トンネル"| NET["公衆インターネット"]
  NET -->|"暗号化トンネル"| GW["VPNゲートウェイ(復号)"]
  subgraph HQ["本社内部網"]
    GW --> SRV["業務サーバ·DB"]
  end

端末で生成された平文トラフィックはVPNクライアントを経てカプセル化・暗号化され、公衆インターネットへ出る。途中経路のISP・ルータ・中継ノードは暗号文と外側ヘッダだけを見られるが、その中の宛先や内容は分からない。反対側のゲートウェイはトンネルの反対端でパケットを復号して元の平文に戻し、内部網へ転送する。したがって安全の境界が「物理回線」ではなく端末のVPNクライアントと本社ゲートウェイという二つの終端へ移り、この二終端の間の区間全体が一つの仮想専用区間となる。

この構造で核心は終端での暗号・復号の位置である。暗号化が端末で始まりゲートウェイで解かれるため、途中のどこでパケットが奪われても平文は露出しない。ただしゲートウェイの「内側」は復号された平文が流れるため、ゲートウェイ自体が攻撃されれば内部がそのまま露出するという構造的な弱点も同時に内包する。この弱点が後述する境界ベースの信頼モデルの限界につながる。

3. IPSec VPN vs SSL VPN

flowchart LR
  subgraph IPSec["IPSec VPN · L3"]
    A["本社"] --- B["拠点"]
  end
  subgraph SSL["SSL VPN · L4~7"]
    U["リモート利用者"] --- W["Web/アプリ"]
  end

両方式の違いはトンネルをネットワークスタックのどの層に穿つかに由来し、その選択が用途を分ける。IPSec VPNはネットワーク層（L3）でIPパケット自体を暗号化するため、いったんトンネルが立てばその上のすべてのアプリケーショントラフィックが透過的に保護される。利用者が意識しなくてもネットワーク全体が接続されるため拠点-本社の常時接続（Site-to-Site）に適するが、専用クライアントの導入と設定が必要である。

一方SSL VPNは伝送〜応用層（L4〜7）でTLSにより保護し、Webブラウザだけで接続できるため無導入・利便性が大きい。その代わり特定のアプリケーション単位でアクセスを開く方式のため細かいアクセス制御が容易で、不特定の場所から接続するリモート利用者（Remote Access）に適する。要するに「ネットワーク全体を接続するか（IPSec）、必要なアプリだけを開くか（SSL）」が選択基準である。

層の違いは安全管理の細かさ（Granularity）にも直結する。IPSecはトンネルに入った利用者にネットワーク全体を開くため管理は単純だが、一度破られれば露出範囲が広い。SSL VPNは「この利用者はグループウェアと会計Webアプリだけ」のようにアプリ単位で権限を狭められるため、協力会社・外部人員のように最小限だけ開くべき対象に有利である。実務では「拠点間バックボーンはIPSec、個別の在宅・協力会社接続はSSL VPN」と併用運用する事例が一般的である。

区分	IPSec VPN	SSL VPN
動作層	ネットワーク（L3）	伝送〜応用（L4〜7）
接続方式	専用クライアント必要	Webブラウザ（無導入）
主用途	拠点間常時接続（Site-to-Site）	リモート利用者接続（Remote Access）
アクセス範囲	ネットワーク全体	特定アプリケーション単位
安全プロトコル	ESP/AH, IKE	TLS/SSL
長所	広範・透過的な接続	細かいアクセス制御・利便性

4. VPN核心技術要素とIPSec詳細

flowchart LR
  T["トンネリング"] --> E["暗号化"]
  E --> A["認証"]
  A --> I["完全性"]
  I --> K["鍵管理"]

VPNの安全性は五つの要素が鎖のように噛み合うときに成立する。どれか一つでも欠ければ全体が崩れる構造であるため、各要素を「なぜ必要か」の観点で押さえねばならない。

トンネリング（Tunneling）は元のパケットを新しいヘッダで包み（カプセル化）公衆網を通過させる骨格であり、L2TP・PPTPやIPSecのESP/AH、SSL/TLSが用いられる。カプセル化は「アドレス体系の異なる私設網パケットを公衆網に載せて運ぶ」役割を担うが、それ自体では内容を隠せない。そこで暗号化（Confidentiality）がデータの機密性を担い、AESのような対称鍵でペイロードを覆う。対称鍵を使う理由は大量トラフィックを高速に処理する必要があるためで、非対称鍵は遅いため鍵交換のみに限定的に使う。

しかし相手がなりすました攻撃者であれば暗号化も無意味であるため、認証（Authentication）がIKE・電子署名・証明書で通信両端を検証する。「今暗号化して送っている相手が本当に本社ゲートウェイか」を確認しなければ、攻撃者が途中でゲートウェイのふりをして横取りする中間者攻撃（MITM）にそのまま晒される。伝送中にビットが改変されたかは完全性（Integrity）がHMAC・ハッシュで検知し、攻撃者が暗号文を任意にかき混ぜて誤動作を誘発するのを防ぐ。

最後に対称鍵を安全に分け合い周期的に変える鍵管理（Key Management）がなければ、前のすべてが崩れる。同じ鍵を長く使えばトラフィックが蓄積し暗号解析に脆弱になるため、IKE（Internet Key Exchange）がディフィー・ヘルマン（DH）交換でセッション鍵を安全に合意し周期的に再交渉（Rekeying）する。

要素	説明	代表技術
トンネリング（Tunneling）	元パケットのカプセル化	L2TP·PPTP·IPSec(ESP/AH)·SSL/TLS
暗号化（Confidentiality）	データ機密性	対称鍵（AES等）
認証（Authentication）	両端の身元検証	IKE·電子署名·証明書
完全性（Integrity）	改ざん検知	HMAC·ハッシュ
鍵管理	セッション鍵交換·更新	IKE

IPSecには二つのカプセル化モードがある。トランスポート（Transport）モードはペイロードのみ暗号化し元のIPヘッダは維持して終端間（ホスト-ホスト）通信に用いられ、トンネル（Tunnel）モードは元のIPヘッダまで含む全パケットを暗号化し新しいヘッダで包むためゲートウェイ間のSite-to-Site接続に用いられる。トンネルモードが元のIPヘッダまで隠す理由は、ゲートウェイの背後でどの内部ホストが通信しているか（内部トポロジ）を外部に露出しないためである。

IPSec接続はIKEの二段階で樹立される。下のシーケンスは、第1段階で管理用の安全チャネル（IKE SA）を立て、第2段階で実データ用のトンネル（IPSec SA）を合意する流れを表す。

sequenceDiagram
  participant A as 開始者 (拠点GW)
  participant B as 応答者 (本社GW)
  A->>B: "IKE第1段階: DH交換·相互認証"
  B-->>A: "IKE SA樹立 (管理チャネル)"
  A->>B: "IKE第2段階: ESPパラメータ交渉"
  B-->>A: "IPSec SA樹立 (データトンネル)"
  A->>B: "暗号化データ伝送 (ESP)"

第1段階で両者はDH交換で秘密を共有し証明書・事前共有鍵（PSK）で互いを認証してIKE SAという安全な管理チャネルを作る。第2段階ではそのチャネル上で実データ保護用の暗号スイートと鍵を交渉してIPSec SAを結ぶ。このように「交渉用チャネルとデータ用チャネルを分離」する設計のおかげで、データ鍵は頻繁に更新しつつも毎回重い認証をやり直さず、性能と安全性を同時に確保する。

5. 比較・事例

具体的な適用様相を見れば両方式の選択論理が明確になる。あるグローバル製造社が全世界30余りの拠点を結ぶときは、各拠点ルータにIPSecトンネルモードを常時設定し互いを一つの社内網のように使う。社員はVPNを意識せず社内ERPに接続し、接続が切れても自動で再交渉される。一方、同じ会社は在宅・外注人員にはSSL VPNポータルを提供し、ブラウザログインだけで許可された数個のWebシステムにのみアクセスさせる。ノートPCに専用ソフトを入れられない外注環境で無導入接続は大きな利点である。

性能面の数値感覚も重要である。暗号・復号演算はCPUを消費するため、専用の暗号加速ハードウェアなしにソフトウェアだけで処理すると高帯域区間で数百Mbps〜数Gbps水準で詰まりが生じうる。そのため本社ゲートウェイ級の機器は概ねAES-NIのようなハードウェア加速を内蔵する。また攻撃事例として、かつてPPTPはMS-CHAPv2認証の脆弱性で事実上数時間以内にクラック可能であると知られ現在は使用が推奨されず、新規構築はIPSec（IKEv2）や最新のWireGuard系へ収束しつつある。

6. 深化: ZTNA·SASEへの進化

伝統的VPNの最も根本的な限界は境界ベースの信頼（Perimeter-based Trust）モデルにある。「トンネルに入れば即ち内部者」とみなすため、ある社員のアカウント・端末が奪われれば攻撃者はそのトンネルを辿り内部網全体を横方向に移動（Lateral Movement）できる。実際に多数の大型侵害事故が「奪取したVPNアカウントで初期侵入→内部拡散」の経路を辿り、「一度信じれば最後まで信じる」モデルの構造的欠陥を露呈した。

これに対する代案がZTNA（Zero Trust Network Access）である。ZTNAは「ネットワークに接続した」事実を信頼の根拠とせず、資源にアクセスするたびに利用者・端末・状況（位置・時間・端末の安全状態）を再評価する。アクセス単位もネットワーク全体ではなく特定アプリケーションに狭め、たとえ一つのアカウントが破られてもそのアプリ以外への横移動は不可能である。さらにアクセス前は資源の存在自体を隠す（Dark Cloud）方式で攻撃面を減らす。

flowchart TB
  subgraph Legacy["伝統的VPN: 境界信頼"]
    L1["トンネル進入"] --> L2["内部網全体を信頼"]
  end
  subgraph ZT["ZTNA: 持続検証"]
    Z1["アクセス要求"] --> Z2["アクセスごとに再評価"]
    Z2 --> Z3["特定アプリのみ許可"]
  end

さらにSASE（Secure Access Service Edge）はZTNA・SWG・CASB・FWaaS等の安全機能とSD-WANのネットワーキングをクラウドエッジで統合提供するモデルで、利用者がどこにいても最も近いPoP（接続点）で安全検査と最適経路ルーティングを共に受けさせる。VPNが「本社へ一旦引き込んでから出る」バックホール構造であれば、SASEは「エッジで検査しすぐクラウドへ」送り遅延を減らす。ただしVPNが直ちに消えるわけではなく、相当数の企業はSite-to-Site バックボーンはIPSecで維持しつつ利用者のリモート接続だけを段階的にZTNAへ転換するハイブリッド戦略を取っている。

7. 考慮事項および示唆点

• 性能と安全の均衡（スプリットトンネリング）: 暗号・復号はCPU・帯域のオーバーヘッドを招くため、全トラフィックをトンネルで送る代わりに社内宛先のみトンネリングし一般インターネットは直接出すスプリットトンネリングで性能を折衷できる。ただし分離区間は安全検査を迂回するため、機微業務はフルトンネルを強制するなど政策的な線引きが必要である。
• 境界ベースの信頼の限界とゼロトラストの結合: VPNを維持しても「接続=信頼」の等式を崩さねばならない。利用者・端末・状況を毎アクセス評価するゼロトラスト原則と結合し、アクセス単位をネットワークからアプリケーションへ狭めて横移動を遮断する方向で運用すべきである。
• 認証強化とアカウント奪取への備え: VPNアカウント奪取が侵害の主な初期経路であるため、パスワード単独認証から脱しMFA（多要素認証）と端末の信頼性検証（端末証明書・EDR連携）を必須化せねばならない。
• 暗号スイート・プロトコルの最新化: PPTP等の脆弱なプロトコルを除去し、IKEv2・TLS 1.3等の現行標準と十分な鍵長（AES-256等）を維持し、耐量子暗号（PQC）への移行ロードマップも先制的に検討すべきである。
• 可用性・拡張性の設計: リモートワークの常態化でVPNが必須インフラとなった以上、ゲートウェイ二重化・負荷分散と同時接続セッション容量の算定を通じ、特定時点のアクセス殺到でもサービスが途切れないよう設計せねばならない。

参考資料

• IETF RFC 4301, "Security Architecture for the Internet Protocol (IPsec)", https://www.rfc-editor.org/rfc/rfc4301
• IETF RFC 7296, "Internet Key Exchange Protocol Version 2 (IKEv2)", https://www.rfc-editor.org/rfc/rfc7296
• NIST SP 800-77 Rev.1, "Guide to IPsec VPNs", https://csrc.nist.gov/pubs/sp/800/77/r1/final
• Gartner, "Market Guide for Zero Trust Network Access (ZTNA)", https://www.gartner.com/en/documents/zero-trust-network-access

---

一言まとめ: VPNは公衆網上に暗号化トンネルで仮想専用網を構成する低費用の安全技術であり、ネットワーク層のIPSec（拠点間）と応用層のSSL（リモート接続）に分かれ、トンネリング・暗号化・認証・完全性・鍵管理を核心要素とし、境界信頼の限界を越えて毎アクセスを検証するZTNA・SASEへ進化している。