リモートワークが当たり前になり、「VPNでつなぐ」という言葉は社内の誰もが使うようになりました。しかしSC試験で問われるのは「VPNでつなげば安全」という曖昧な理解ではなく、何をどう守っているのかという中身です。IPsecのESPとAHはどう違うのか、トンネルモードとトランスポートモードはいつ使い分けるのか、IKEは何のためにあるのか。そしてSSL-VPNとは何がどう違うのか。さらに近年は、その「守るための装置」であるVPN機器そのものが攻撃の侵入口になっています。
私がCIOとしてセキュリティ投資の判断をしていた頃、拠点間をつなぐ手段といえば専用線かIPsec VPNでした。専用線は高く、VPNは安いが設定がシビアで、SA（Security Association）のパラメータが拠点間で一つでもずれると通信が確立しない。当時さんざん悩まされたこの仕組みは、今もSC午後試験で繰り返し問われる核心テーマです。この記事では、IPsec VPNとSSL-VPNの構造の違いを、プロトコルの中身から侵入経路としての弱点まで一気に整理します。読み終えるころには、ネットワーク構成図にVPN装置が出てきても「ここで何を暗号化しているか」を即座に説明できるようになります。
IPsec VPNの全体像｜何を守り、どこで暗号化するのか
VPN（Virtual Private Network）は、インターネットという誰でも通れる公衆網の上に、暗号化によって「自分たちだけの専用通路」を仮想的に作る技術です。その代表格がIPsecです。まずは「IPsecが何の集合体なのか」という全体像から押さえましょう。ここを曖昧にしたまま用語だけ覚えると、午後試験の穴埋めでつまずきます。
IPsecは単一のプロトコルではなくプロトコル群
学び始めの人が最初につまずくのは、「IPsec」という名前の単一プロトコルがあると思い込むことです。実際には、IPsecは複数のプロトコルを束ねた枠組み（フレームワーク）です。中心となるのは次の3つです。
- AH（Authentication Header）: 認証と完全性（改ざん検知）を提供する。暗号化はしない
- ESP（Encapsulating Security Payload）: 暗号化に加えて認証・完全性も提供する
- IKE（Internet Key Exchange）: 暗号化に使う鍵やアルゴリズムを相手と合意し、SAを確立する
ポイントは、IPsecがネットワーク層（OSI参照モデルの第3層、IPの層）で動作することです。アプリケーションが何であろうと、IPパケットそのものを保護するため、Webでもメールでもファイル共有でも、上位アプリを問わず一律に守れます。これがIPsecの強みであり、後で述べるSSL-VPNとの決定的な違いになります。
SA（Security Association）とは何か
IPsecを理解するうえで避けて通れないのがSAです。SAとは、通信する2者の間で「どの暗号アルゴリズムを使い、どの鍵で、どのプロトコル（AHかESPか）で守るか」を取り決めた合意のセットです。
重要なのは、SAは片方向だということです。AからBへの通信と、BからAへの通信は別々のSAになります。したがって双方向通信には最低2つのSAが必要です。各SAはSPI（Security Parameter Index）という識別子で区別され、受信側はパケットに付いたSPIを見て「このパケットはどのSAで処理すべきか」を判断します。私がVPN設定で苦しんだのは、まさにこのSAのパラメータ（暗号方式・鍵の有効期間など）を拠点間で完全に一致させる作業でした。片側がAES、片側が3DESを指定していれば、当然SAは確立しません。
ESPとAHの違い｜暗号化するのはどちらか
ここはSC試験の頻出ポイントであり、かつ受験生が最も混同しやすい箇所です。「AHとESP、暗号化するのはどちらか」と問われて即答できるかどうかが分かれ目になります。結論から言えば、暗号化するのはESPだけです。
AHは「改ざん検知の封蝋」、ESPは「中身を見せない封筒」
たとえるなら、AHは手紙に封蝋（ふうろう）を押すようなものです。中身は誰でも読めますが、途中で開封・改ざんされれば封蝋が壊れるので気づけます。つまりAHが提供するのは認証と完全性であって、機密性（暗号化）ではありません。
一方ESPは、中身が見えない封筒に手紙を入れる行為です。第三者は中身を読めず、さらに封筒自体に改ざん検知の仕組みも付けられます。つまりESPは機密性（暗号化）と完全性・認証の両方を提供できます。
| 観点 | AH（Authentication Header） | ESP（Encapsulating Security Payload） |
|---|---|---|
| 暗号化（機密性） | しない | する |
| 認証・完全性 | する | する（任意で有効化） |
| 保護範囲 | IPヘッダを含めて完全性を保証 | 原則ペイロード（データ部）を保護 |
| プロトコル番号 | 51 | 50 |
| NATとの相性 | 悪い（NAT通過で完全性検証が失敗） | 良い（NAT-Tで対応可能） |
なぜ今はESPばかり使われ、AHはほぼ使われないのか
一般に、AHが単独で使われることはほとんどないとされています。理由は2つあります。1つは、AHは暗号化しないため機密性が確保できず、現代のセキュリティ要件を満たさないこと。もう1つがNATとの致命的な相性の悪さです。
AHはIPヘッダ（送信元・宛先IPアドレスを含む）まで含めて完全性を検証します。ところがNATは通過時にIPアドレスを書き換えます。書き換えられた時点で完全性検証は「改ざんされた」と判定して失敗します。NATが当たり前のインターネット環境では、これは決定的な欠陥です。ESPはIPヘッダを完全性検証の対象外にできるため、NAT環境でもNAT-T（NAT Traversal、UDP 4500番でカプセル化する仕組み）を併用すれば通過できます。AHがほとんど使われなくなった主因はNATとの相性の悪さにある、と整理しておくとよいでしょう。
トンネルモードとトランスポートモード｜IPヘッダを暗号化するか
ESP・AHとは別の軸として、IPsecには2つの動作モードがあります。ここを混同すると、「どこまでが暗号化されるのか」の理解が崩れます。違いは一点、元のIPヘッダを暗号化（カプセル化）するかどうかです。
トランスポートモード：端末同士が直接守る
トランスポートモードは、通信する端末（ホスト）同士が直接IPsecを張る方式です。元のIPヘッダはそのまま残し、データ部（ペイロード）だけを保護します。IPヘッダが残るので、途中のルータは通常どおりルーティングできます。サーバ間の通信を直接暗号化したい、といった用途で使われます。
トンネルモード：VPN装置がまるごと包む
トンネルモードは、VPN装置（セキュリティゲートウェイ）同士でIPsecを張る方式です。元のIPパケットを丸ごと（IPヘッダを含めて）暗号化し、その外側に新しいIPヘッダを付け直します。新しいIPヘッダにはVPN装置同士のグローバルIPアドレスが入ります。これにより、内部の本当の送信元・宛先（プライベートIP）は外から見えなくなります。
拠点間VPN（サイト間VPN）は、ほぼ例外なくこのトンネルモードです。各拠点のVPN装置が出入口で暗号化・復号を担い、拠点内の端末はVPNを意識しません。私が拠点をつないでいたときも、現場の社員は「いつも通りファイルサーバにアクセスしているだけ」で、その裏でVPN装置がトンネルを張っていました。
つまずきポイント：モードとプロトコルは別の軸
ここで多くの人が混乱します。「トンネルモード＝ESP」「トランスポートモード＝AH」のように1対1で結びつけて覚えてしまうのです。これは誤りです。モード（トンネル／トランスポート）とプロトコル（ESP／AH）は独立した2つの軸であり、組み合わせは自由です。たとえば「ESPのトンネルモード」も「ESPのトランスポートモード」も成立します。試験では、この2軸を切り離して理解できているかを問う出題がよくあります。
IKEの役割｜鍵交換とSAの自動確立
ESPで暗号化すると言っても、暗号化には鍵が要ります。その鍵を、盗聴される可能性のあるインターネット越しに、どうやって安全に共有するのか。これを担うのがIKE（Internet Key Exchange）です。IKEがなければ、管理者が両端の装置に手動で鍵を設定して回らねばならず、現実的ではありません。
IKEの2つのフェーズ
IKE（特にIKEv1）は、2つのフェーズに分けてSAを確立します。手順の流れを押さえておきましょう。
- フェーズ1: まずIKE自身の通信を守るための安全な経路（ISAKMP SA。IKEv2ではIKE SAと呼ぶ）を確立する。ここでDiffie-Hellman鍵交換を使い、互いに鍵の素を交換して共有鍵を生成する。お互いが正規の相手かを認証するのもこのフェーズ（事前共有鍵PSKやデジタル証明書を使う）
- フェーズ2: フェーズ1で作った安全な経路を使って、実際のデータ通信を守るためのSA（IPsec SA）を確立する
この「まず安全な経路を作り、その中で本番用の鍵を取り決める」という二段構えが、IKEの基本構造です。なお現在広く使われるIKEv2は、この手順を簡略化し、メッセージ往復を減らして接続を高速化・堅牢化したものです。新規構築ではIKEv2が標準的な選択肢になっています。
Diffie-Hellman鍵交換が肝になる理由
フェーズ1で使われるDiffie-Hellman（DH）鍵交換は、SC試験でも頻出です。DHの本質は、鍵そのものをネットワークに流さずに、両者が同じ共有鍵を導出できる点にあります。盗聴者が交換されるデータを全部見ても、共有鍵は計算で導けません。これによって、暗号化していない経路の上でも安全に共有鍵を作れます。「鍵交換」と「暗号化」を別物として区別できているかが、ここでの理解度の分かれ目です。
IPsec VPNとSSL-VPNの違い｜レイヤと使い分け
ここまでがIPsecの中身です。では、もう一つの主流であるSSL-VPNとは何が違うのか。両者はSC試験で必ずと言っていいほど対比で問われます。違いの根っこは動作するレイヤにあります。
動作レイヤが根本的に違う
IPsec VPNはネットワーク層（第3層）で動きます。一方SSL-VPNは、Webでおなじみのトランスポート層〜セッション層付近、つまりより上位で動きます。なお「SSL」は歴史的名称で、現在の実体はTLSですが、製品分類としては今もSSL-VPNと呼ばれます。
この違いから、得意な使い方が分かれます。IPsec VPNは拠点間を丸ごとつなぐ（サイト間VPN）のに向き、SSL-VPNは個人がブラウザなどから社内の特定アプリへアクセスする（リモートアクセスVPN）のに向きます。SSL-VPNには大きく3つの方式があります。ブラウザだけで社内Webアプリにアクセスするリバースプロキシ型、特定のアプリケーションの通信をポート単位で中継するポートフォワーディング型、そして専用クライアントを入れてIPsecに近い全通信を通すL2フォワーディング型（SSL-VPNトンネル型）です。
| 観点 | IPsec VPN | SSL-VPN |
|---|---|---|
| 動作レイヤ | ネットワーク層（第3層） | トランスポート層以上 |
| 主な用途 | 拠点間（サイト間）接続 | 個人のリモートアクセス |
| クライアント | 専用クライアント／VPN装置が必要 | ブラウザのみでも可（型による） |
| 保護対象 | IP通信を一律に保護 | 特定アプリ中心（型により全通信も可） |
| 導入の手軽さ | 設定がシビア | 比較的手軽 |
つまずきポイント：「SSL-VPNは安全、IPsecは古い」ではない
新卒エンジニアがよく持つ誤解が、「SSL-VPNのほうが新しくて安全、IPsecは古い技術」という思い込みです。これは正しくありません。両者は優劣ではなく用途の違いです。拠点を丸ごと常時接続するならIPsecが合理的で、不特定の場所から個人が特定業務にアクセスするならSSL-VPNが手軽、という住み分けです。試験でも「この状況ではどちらが適切か」を用途から判断させる出題が出ます。
VPN機器の脆弱性｜守る装置が侵入口になる
最後に、近年のSC試験で存在感を増しているテーマを扱います。VPNは通信を守る技術ですが、そのVPN装置そのものが攻撃の入口になる事例が急増しています。10大脅威でも「ネットワーク機器の脆弱性悪用」は常連です。
なぜVPN装置が狙われるのか
VPN装置は、定義上インターネットに口を開けている機器です。社外から正規に接続させるための入口なので、当然攻撃者からも見えています。ここに未修正の脆弱性があれば、攻撃者はそれを突いて社内ネットワークの内側に一気に入り込めます。ファイアウォールの内側、つまり「境界の内側」へのワープ口になってしまうわけです。
実際に問題になってきた典型パターンは次のとおりです。
- 既知脆弱性の放置: ベンダがパッチを出しているのに、業務影響を恐れて適用が遅れ、その隙を突かれる
- 認証情報の窃取・使い回し: VPNのアカウントが漏洩・推測され、多要素認証がないために正規ログインとして侵入される
- EOL（サポート終了）機器の継続利用: パッチが提供されなくなった古い装置を使い続け、新たな脆弱性に永久に晒される
かつてはWAFすら高価で導入を見送り、Webサーバ側のアクセス制御を泥臭く工夫して境界を守るしかない時代もありました。境界の機器を「とりあえず動いているから」と放置する怖さは、その頃から変わっていません。むしろVPNが全社の生命線になった今、入口の1台の脆弱性が組織全体を沈める時代になりました。
対策の方向性とゼロトラストへの橋渡し
対策の基本は地味ですが効きます。パッチの迅速な適用、VPNアカウントへの多要素認証（MFA）の徹底、EOL機器の計画的な更改、そしてアクセスログの監視です。当たり前のことですが、この当たり前を回し続けられるかが現場の実力です。
そして、ここから先のセキュリティの潮流につながります。VPNは「境界の内側は信頼する」という境界型防御の考え方に立っています。しかし境界が一度破られればすべてが露出する。この限界への反省から生まれたのが、「内側であっても何も信頼せず、アクセスのたびに検証する」ゼロトラストの考え方であり、それを実装するSASE／SSE／ZTNAといった新しい枠組みです。本記事の境界型VPNを土台として理解しておくと、次のゼロトラストの話がすっきり腹落ちします。
SC試験での出題パターンと対策
IPsecとVPNは、SC試験では午前II・午後の両方で繰り返し問われる定番領域です。出題のされ方と対策を整理します。
午前IIでの出題傾向
午前IIでは、用語の正確な区別を問う4択が中心です。「AHとESPの機能の違い（暗号化するのはどちらか）」「トンネルモードとトランスポートモードでIPヘッダを暗号化するのはどちらか」「IKEの役割」「Diffie-Hellman鍵交換の目的」などが、表現を変えながら繰り返し出題されてきました。特にAH／ESPの暗号化の有無、SAが片方向であることは、引っかけとして頻出です。
午後での出題傾向
午後では、ネットワーク構成図にVPN装置が登場し、「拠点間をどう安全に接続するか」「どのモード・プロトコルが適切か」を文脈から判断させる出題が見られます。近年はこれに加え、VPN機器の脆弱性を起点としたインシデント対応（侵入経路の特定、再発防止策の記述）が題材になることが増えています。「VPNがあるのになぜ侵入されたのか」を説明させる流れは、まさに本記事で扱った内容そのものです。
過去問の年度を断定はしませんが、IPsecの構成要素とモードの区別、鍵交換の仕組みは、高度試験の午前IIで一般化して言えるほど繰り返し出題されている論点です。用語を丸暗記するのではなく、「なぜそうなるのか（NATとの相性、レイヤの違いなど）」まで理解しておくと、表現を変えられても対応できます。
【演習】IPsec VPNとSSL-VPN理解度チェック（全10問）
午前IIではAH／ESPの機能差やモードの区別を問う用語問題、午後ではネットワーク構成図を読んで適切なVPN方式を選ばせる応用問題として出題されます。定番の引っかけは「暗号化するのはAHかESPか」「IPヘッダごと暗号化するのはどちらのモードか」「鍵交換と暗号化を混同させる」の3点です。以下の練習問題で本記事の理解度を確認してみましょう。
まとめ：VPNは「つなぐ」より「どう守るか」で理解する
IPsec VPNとSSL-VPNの違いを、プロトコルの中身から侵入経路まで整理してきました。要点を振り返ります。IPsecはAH・ESP・IKEから成るフレームワークで、暗号化するのはESPだけ、AHは認証のみでNATと相性が悪い。動作モードはトンネルとトランスポートの2つで、違いは元IPヘッダを暗号化するかどうか。モードとプロトコルは独立した軸です。IKEは鍵交換とSA確立を担い、Diffie-Hellmanで鍵を流さずに共有鍵を導きます。SSL-VPNとの違いは動作レイヤにあり、用途で使い分けます。
私がCIOとして拠点をつないでいた頃、VPNは「安く専用線の代わりになる便利な仕組み」でした。しかし今や、VPNは全社の生命線であると同時に、入口の1台が組織全体の弱点にもなります。新卒エンジニアに教えるとき私が強調するのは、「VPNでつないだ＝安全、ではない」という一点です。何を、どのレイヤで、どう守っているのか。そして、その守る装置自身をどう守り続けるのか。この視点を持てば、午後試験のネットワーク構成図も、現場のインシデント対応も、同じ理屈で読み解けます。そして次のステップである「境界の内側も信頼しない」ゼロトラストの世界へ、自然と歩みを進められるはずです。
本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。
参考資料
- IPA（情報処理推進機構）情報処理安全確保支援士試験 公式情報: https://www.ipa.go.jp/shiken/
- RFC 4301 Security Architecture for the Internet Protocol（IPsecアーキテクチャ）: https://www.rfc-editor.org/rfc/rfc4301
- RFC 4302 IP Authentication Header（AH）: https://www.rfc-editor.org/rfc/rfc4302
- RFC 4303 IP Encapsulating Security Payload（ESP）: https://www.rfc-editor.org/rfc/rfc4303
- RFC 7296 Internet Key Exchange Protocol Version 2（IKEv2）: https://www.rfc-editor.org/rfc/rfc7296
- IPA「情報セキュリティ10大脅威」: https://www.ipa.go.jp/security/10threats/