IT用語集 2023/10/20

IPSecとは？わかりやすく10分で解説

コラム

インターネットをはじめとするネットワーク通信では、メールやWeb閲覧、業務システムの利用など、日々さまざまなデータが行き交っています。ところが、通信が暗号化されていなかったり、送信元の正当性を確認できなかったりすると、盗聴や改ざん、なりすましといったリスクが現実のものになります。そこで重要になるのが、IPネットワークの“土台”で通信を保護する技術であるIPsecです。

IPsecとは?

ネットワーク通信において、私たちは日々多くのデータをやりとりしています。これらの通信は、その内容によってはさまざまなリスクを伴う場合があります。ここで注目すべきなのが、IPsecというセキュリティ技術です。

IPsecの定義

IPsecとは、Internet Protocol Securityの略で、インターネットプロトコル（IP）上での通信を安全に行うための一連の標準技術（プロトコル群）を指します。主に暗号化と認証（送信元の正当性確認）により、データの機密性・完全性・（方式によっては）送信元認証を提供します。企業の内部ネットワーク（イントラネット）や、拠点間接続・リモートアクセスなどのVPN（Virtual Private Network）で利用されることが一般的です。

IPsecはパケット単位での保護を提供します。これは、IPネットワーク上で個々のデータパケットに対して暗号化や改ざん検知を適用するという意味です。結果として、アプリケーション（メール、ファイル共有、業務アプリなど）の種類に依存せず、IP通信をまとめて保護しやすい点が特徴です。

IPsecの必要性と利点

IPsecが必要とされる理由は、ひとことで言えばネットワーク通信の安全性を底上げするためです。たとえば、インターネットを経由して拠点間を接続する場合、通信経路上には第三者が介在し得ます。IPsecを用いることで、盗聴されても内容が読めない（機密性）、途中で書き換えられても検知できる（完全性）、許可された相手とだけ通信できる（認証）といった対策をまとめて実装できます。

もう一つの利点は、運用面の柔軟性と拡張性です。IPsecはIP層（ネットワーク層）で動作するため、特定のアプリやポートに限定されず、ルール（ポリシー）に基づいて広い範囲の通信を保護できます。拠点追加や回線変更があっても、ポリシーと鍵交換の設計が整理できていれば、構成を比較的スムーズに拡張しやすいのも実務上のメリットです。

一方で、IPsecは「入れれば終わり」の仕組みではなく、暗号方式・認証方式・鍵管理・相互接続要件（NATの有無など）を含めた設計が品質を左右します。以降では、仕組みと運用の要点を整理します。

IPsecの基礎知識

ネットワークセキュリティの役割は、情報がネットワーク上を移動する過程で、盗聴・改ざん・なりすましといったリスクにさらされないようにすることです。IPsecは、その役割をIPレイヤーで実現する代表的な仕組みであり、VPN装置（ルータ、ファイアウォール）やOS（サーバー／クライアント）の実装として広く利用されています。

どのように動作するか

IPsecはインターネットプロトコル（IP）のレイヤーで動作し、通信をセキュリティ対策した形で行います。IPsecには大きく分けてトンネルモードとトランスポートモードの2つの動作モードがあります。

トランスポートモードは、送信元ホストと宛先ホスト（エンドポイント）間の通信で、主にIPパケットのペイロード（上位データ）を保護します。OS同士の直接通信などで用いられます。トンネルモードは、拠点間VPNのようにゲートウェイ装置同士でトンネルを張り、元のIPパケット全体を包んで運ぶ方式です。トンネルモードでは外側に新しいIPヘッダが付くため、構成として「拠点AのVPN装置→インターネット→拠点BのVPN装置」のような形をとれます。

実運用では、拠点間VPNやリモートアクセスVPNでトンネルモードが用いられるケースが多く、トランスポートモードは用途がやや限定的です。ただし、どちらが優れているというより、「どこを暗号化の終端にするか」（ホストかゲートウェイか）という設計の違いとして理解するのが実務的です。

主な特徴と仕組み

IPsecの要点は、単に暗号化するだけでなく、通信を成立させるための「約束事」を事前に合意してからパケットを処理する点にあります。その中心概念がセキュリティアソシエーション（SA: Security Association）です。SAには、暗号アルゴリズム、鍵、ライフタイム、相手識別、スコープ（どの通信を保護するか）などが含まれ、IPsecのパケット処理はこのSAに従って行われます。

また、多くの実装ではアンチリプレイ（同じパケットを再送して混乱させる攻撃への対策）としてシーケンス番号とウィンドウ制御を用います。暗号化方式が適切でも、鍵管理や再鍵交換（リキー）、アンチリプレイが弱いと、実運用上の安全性は損なわれます。IPsecは暗号そのものよりも、こうした「運用を含む全体設計」が重要な技術です。

IPsecのセキュリティ機能

IPsecは、主に完全性（改ざん検知）と機密性（盗聴耐性）を提供するために設計されています。実装上の中心となるのは、認証ヘッダ（AH）とカプセル化セキュリティペイロード（ESP）です。どちらを使うか、またどの暗号・認証方式を選ぶかによって、得られる保護の性質と運用上の制約が変わります。

認証ヘッダ（AH）

認証ヘッダ（AH: Authentication Header）は、主に完全性と送信元認証（なりすまし対策）を提供する仕組みです。AHは暗号化（機密性）は提供せず、パケットが途中で書き換えられていないこと、想定した相手から送られてきたことを検証する目的で使われます。

AHでは、共有した鍵に基づく認証コード（MAC）を計算し、AHフィールドとして付与します。受信側は同じ方法で計算し、値が一致すれば改ざんされていないと判断できます。ここで重要なのは、IPヘッダの一部も検証対象になり得る点です。たとえば経路上で書き換えられる可能性があるフィールド（可変部分）は対象外にするなど、仕様上の取り決めがあります。

なお、実務ではAHは利用頻度が高いとは言えません。理由の一つは、NAT（Network Address Translation）環境と相性がよくないことです。NATはIPヘッダを書き換えるため、AHの検証が成立しにくくなります。そのため、多くの構成ではESPを中心に設計することが一般的です。

暗号化ペイロード（ESP）

ESP（Encapsulating Security Payload）は、IPsecで最も一般的に用いられる方式で、主に機密性（暗号化）を提供します。さらに、設定により完全性や送信元認証（認証付き暗号／認証オプション）も追加でき、実務では「ESPで暗号化＋認証」をセットで用いるケースが多いです。

ESPは、IPパケットのペイロード（データ部分）を暗号化して送信します。許可された受信者だけが復号できます。加えて、認証機能（完全性保護）を有効にすれば、改ざん検知やなりすまし耐性も強化できます。近年は、AES-GCMのように暗号化と認証をまとめて扱える方式（AEAD）を選ぶ構成も一般的です。

ただし、ESPを使えば「すべてが絶対に安全」になるわけではありません。鍵が漏えいすれば復号のリスクが生まれますし、弱い暗号スイート選択や運用不備（PSKの管理、証明書失効管理、ログ監視不足など）があれば、技術の強度を十分に活かせません。IPsecは方式選定と運用設計がセットで初めて、期待した防御力を発揮します。

IPsecのプロトコル

IPsecを実務で理解するには、「どのパケットを、どの方式で保護するか」と「そのための鍵やパラメータをどう合意するか」を分けて考えると整理しやすくなります。前者がトンネル／トランスポートとESP/AHの設計、後者がIKEによる鍵交換と認証です。

通信方式：トンネルモードとトランスポートモード

IPsecの通信方式には、大きく分けてトンネルモードとトランスポートモードの2つがあります。両モードは用途が異なり、どちらを選ぶかで「暗号化の終端」や「保護範囲」が変わります。

トンネルモードは、元のIPパケットをESP/AHで保護し、さらに外側に新しいIPヘッダを付けて転送します。これにより、拠点間VPNのように「ネットワークAとネットワークBを安全につなぐ」構成を作りやすくなります。通信経路上では、外側ヘッダの送信元・宛先（ゲートウェイ間）は見えますが、元のパケット内容（内側のアドレスやデータ）は暗号化により秘匿されます（設定によります）。

トランスポートモードは、IPヘッダは基本的にそのまま残し、ペイロード側を保護します。ホスト間の直接通信で、上位データだけを保護したい場合に適します。反面、ネットワーク機器間VPNのような用途では設計・運用のメリットが小さく、実務ではトンネルモードが選ばれがちです。

選定の実務ポイントは、「暗号化の終端をどこに置くか」です。拠点間接続やリモートアクセスでは、終端をゲートウェイ（VPN装置）に置くことで、端末側の要件を減らし、運用を集約できます。一方、端末同士で終端を持つ場合は、端末側管理や証明書配布などが運用課題になりやすい一方で、より細かな制御が可能になります。

鍵交換プロトコル：IKE

IPsecを安全に運用するうえで欠かせないのが、鍵交換プロトコルであるIKE（Internet Key Exchange）です。IKEは、IPsec通信に必要な鍵や暗号方式などのパラメータを相手と合意し、SAを確立するための仕組みです。

IKEでは、まず「相手は本当に正しい通信相手か」を確認します。認証方式としては、事前共有鍵（PSK）やデジタル証明書（公開鍵基盤）などが使われます。そのうえで、Diffie-Hellman（DH）などの手法により鍵素材を交換し、実際の暗号通信で使う鍵を生成します。こうして確立したSAに基づき、以後のESP/AHのパケット処理が行われます。

なお、運用ではIKEv2を選ぶケースが一般的です（接続維持や再接続、NAT環境への配慮などが整理されています）。また、一定時間や一定量の通信で鍵を更新するリキーや、前方秘匿性（PFS: Perfect Forward Secrecy）を意識したDHグループ選定なども、セキュリティと安定運用の両面で重要な検討事項です。

IPsecの実装と設定

IPsecは強力な仕組みですが、実装と設定の品質で結果が大きく変わります。暗号方式の選び方だけでなく、相互接続要件（NAT、MTU、拠点追加）、認証・鍵管理（PSK／証明書）、運用監視（ログ、障害切り分け）まで含めて設計することで、初めて「業務で使えるVPN」になります。

IPsecを用いるべき状況

IPsecが特に適しているのは、次のように「IP通信をまとめて保護したい」ケースです。

リモートアクセスVPN：従業員が自宅や外出先から社内ネットワークへ安全に接続する。端末認証・ユーザー認証、端末の紛失時対応なども含め、運用設計が重要です。

サイト間VPN（拠点間VPN）：本社と支社、データセンターとクラウド環境など、ネットワーク同士を常時接続する。IPsecはネットワーク層で広範囲の通信を保護でき、ルーティング設計や冗長化設計と組み合わせやすい点が利点です。

特定通信の保護（システム間連携など）：特定のサーバー同士の通信を保護したい場合にも使えます。ただし、この用途ではTLS（アプリ層暗号）のほうが運用しやすい場面もあるため、要件（どこまで透過的に守りたいか、管理主体は誰か）に応じて選び分けます。

個人用途の「パーソナルVPNサービス」としてIPsecが使われることもありますが、企業利用とは目的と責任分界（ログ、監査、認証強度）が異なります。業務用途であれば、組織のポリシーに沿った認証方式と監視体制を前提に選定すべきです。

基本的な設定方法と手順

IPsecの設定は、製品やOSにより画面や用語が異なるものの、概念的には次の要素を決める作業です。

1) IKEの設定（相手認証と鍵合意）
・相手の識別：IPアドレス、FQDN、証明書のサブジェクトなど
・認証方式：PSKまたは証明書（できれば証明書を優先する設計が一般的）
・暗号スイート：暗号（例：AES）、ハッシュ／認証（例：SHA-2系）、DHグループ
・ライフタイム、再接続、DPD（死活監視）など

2) ESP/AHの設定（実際に保護する方式）
・ESPまたはAH（多くはESP）
・暗号方式：AES-GCMなど（組織ポリシーに準拠）
・完全性保護（認証）の有無（ESPで暗号＋認証が一般的）
・アンチリプレイの設定

3) 対象トラフィック（ポリシー）の定義
・どの送信元／宛先（サブネット、ホスト）をIPsec対象にするか
・どのプロトコル／ポートを含めるか（フル／限定）
・スプリットトンネルの可否（リモートアクセスの場合）

4) 相互接続の現実条件への対応
・NAT環境であればNAT-T（UDP 4500）を考慮
・MTU低下による断片化や性能影響を確認（特に拠点間で大きいパケットが流れる場合）
・冗長化（回線二重化、装置HA）時のフェイルオーバー要件を整理

例（概念整理のための簡略例）：
- 方式：ESP（暗号＋認証）
- 暗号：AES（例：GCM）
- 認証／ハッシュ：SHA-2系（方式により不要の場合あり）
- 相手認証：証明書（または強度の高いPSK）
- 鍵交換：IKEv2
- 対象：拠点Aの10.0.0.0/24 ↔ 拠点Bの10.1.0.0/24

最後に、疎通確認（どの経路が暗号化されているか、期待どおりのトラフィックがSAに載っているか）と、監視（ログ、アラート、失敗回数、再ネゴの頻度）を整備します。設定作業そのものより、運用・障害時の切り分け手順まで作っておくことが、長期安定運用の差になります。

IPsecと他のセキュリティ技術との比較

IPsecを選ぶべきかどうかは、「何を守りたいのか」「どこで暗号化を終端するのか」「運用を誰が担うのか」で決まります。ここでは代表的な比較として、SSL/TLSとVPN（方式）との関係を整理します。

SSL/TLSとの比較

SSL/TLS（現在はTLSが主流）は、暗号化された通信路を作り、データを安全に送受信するためのプロトコルです。一般的にWeb（HTTPS）やメール、API通信など、アプリケーションが直接TLSを利用します。

違いの要点はレイヤーです。TLSは概ねトランスポート層～アプリケーション層寄りで、アプリケーション単位に暗号化・認証を適用します。一方、IPsecはネットワーク層で動作し、パケット単位で保護します。そのため、IPsecは「アプリがTLS対応していない」「複数アプリをまとめて守りたい」といった場合に有利です。

反対に、TLSは「特定アプリだけを守ればよい」「証明書運用をアプリ側で完結できる」「インターネット越しの公開サービスとして標準的に使いたい」という場面に向きます。つまり、IPsecとTLSは競合というより、適用対象と運用単位が異なる補完関係として捉えるほうが実務的です。

VPN技術との比較

VPN（Virtual Private Network）は、公開ネットワーク上に仮想的なプライベート網を構築する考え方・技術の総称です。ここで混同しやすい点として、IPsecは「VPNの方式（実装）としてよく使われるプロトコル群」であり、VPNそのものと同義ではありません。

代表例として、IPsec VPNはネットワーク層で広範囲の通信を保護できます。一方、いわゆるSSL VPNはTLSを利用し、アプリケーションやポータル経由でアクセスを提供する方式が多く、ユーザー体験や導入のしやすさが評価される場面があります。

実務での選定軸は、次のように整理できます。

保護範囲：すべてのIP通信をまとめて守るならIPsec、特定アプリ中心ならTLS系が適する場合がある
運用：拠点間の常時接続・ルーティング連携はIPsecが得意、ユーザー単位の柔軟なアクセスは方式によって得意不得意がある
相互接続：NATや回線事情、機器間互換性、暗号スイートの合意が実装差として効いてくる

どちらが優れているかではなく、「何を守るべきか」「運用が回るか」という観点で選び分けることが重要です。

IPsecの限界と対策

セキュリティ技術に「完全無欠」はありません。IPsecも多くの長所を持つ一方で、設計・実装・運用の条件によっては弱点が表面化します。ここでは、誤解しやすいポイントと、現場で効く対策に絞って整理します。

知られている脆弱性

IPsecそのものの理論が弱いというより、現実の運用ではIKE設定・認証方式・鍵管理に起因する問題が多くなります。特に注意したいのは以下です。

PSK（事前共有鍵）の弱さ：PSKが短い、推測されやすい、使い回している場合、総当たり（辞書）攻撃で突破されるリスクが高まります。さらに、設定やモードによっては、オフライン解析の足がかりを与える可能性もあるため、PSK運用は慎重に扱う必要があります。

暗号スイートの不適切な選定：古いアルゴリズムや弱いパラメータを選ぶと、理論上の安全性が損なわれます。組織の暗号ポリシー（推奨アルゴリズム、鍵長、DHグループ）に従い、機器の対応状況も含めて合意することが重要です。

相互接続とNAT環境：IPsecはNATやファイアウォールの影響を受けやすく、UDP 500/4500（NAT-T）やESP（IPプロトコル50）の通過可否、タイムアウトなどが問題になりがちです。通信できない原因が暗号ではなくネットワーク側にあるケースも多く、切り分け手順が必要です。

IPsecで守れない領域がある：IPsecは通信の機密性・完全性を高めますが、端末が侵害されていれば平文の段階で情報が抜かれます。また、アプリケーションの脆弱性や認証不備、権限設定ミスなどを直接解決するものではありません。IPsecは「通信路の防御」であり、ゼロトラストや端末防御、ID管理と併せて設計すべき領域です。