SSLとパススルーの違いを徹底解説！安全な通信設計のポイント

はじめに

目的

このドキュメントは「SSLパススルー」について技術的に分かりやすく解説することを目的とします。用語や仕組み、実装方法、運用上の注意点をまとめ、設計の選択肢を比較できるようにします。

想定読者

ネットワークやサーバ運用に関わるエンジニアを主な対象とします。基礎的なTCP/IPやHTTPSの知識があると読みやすいですが、初めての方にもイメージしやすいよう具体例を交えて説明します。

本書の範囲

• SSL/TLSパススルーの基本概念と、ロードバランサーでのSSL終端（オフロード）との違い
• パススルーを使うべき場面と、セキュリティ設計の考え方
• VPNパススルーの概要と代表的プロトコル（IPsec など）
• IPsecの仕組みと通信フローの解説
• ロードバランサーでの証明書管理とSSL終端の実装例

読み方の目安

章ごとに独立して読むこともできますが、順に読むと概念から実装、運用まで自然に理解できます。本章では全体像を示すにとどめ、次章以降で詳しく説明します。

SSL/TLSパススルーの基本概念とSSL終端との違い

概要

バックエンドTLSパススルーは、クライアントとサーバー間の暗号化通信（主にTLS/HTTPS）をそのままロードバランサーやプロキシを通過させる方式です。ロードバランサーはTCPレベルで接続を中継し、暗号化の解除（復号）はバックエンドサーバー側で行います。一方、SSL終端（TLS終端）はロードバランサー側で暗号化を解除して内部へ平文や再暗号化した通信を渡します。

仕組みの違い（簡単な例）

• パススルー: クライアント→LB（そのまま暗号化）→バックエンドで復号。LBはTLSの中身を見ません。ポート443のTCP中継に近い動作です。
• SSL終端: クライアント→LB（ここで復号）→LBがHTTPで振り分け→必要ならLB→バックエンドで再暗号化（再暗号）。

メリット・デメリット

• TLSパススルーの利点: エンドツーエンドの暗号化が保たれ、クライアント証明書検証などバックエンドで扱えます。秘密鍵をサーバー側に限定できます。短所はLBでHTTPレベルの処理（ヘッダ操作、WAF、パスに基づく細かい振り分け）ができない点です。
• SSL終端の利点: 負荷分散装置でTLS処理をオフロードでき、証明書管理が集中します。HTTPヘッダやURLに基づく高度なルーティング、WAFやログ解析が容易です。短所はLBに秘密鍵が置かれる点と、必要ならバックエンドへ再暗号化する追加設定が必要な点です。

選び方の目安

• 規制や相互認証で完全なエンドツーエンド暗号化が求められる場合はパススルーを選びます。
• 高負荷やアプリ層での制御、WAF運用、証明書の一元管理が優先ならSSL終端を検討します。両方の利点を得たい場合は、ロードバランサーで終端後にバックエンドへ再暗号化する構成もあります。

SSLパススルーの適用シーンとセキュリティ設計の選択肢

適用シーン

• セキュリティ要件が厳しい環境
• 金融や医療などでロードバランサーで復号させずにサーバー側で終端したい場合に有効です。バックエンドで証明書を一元管理できない組織にも向きます。
• マルチテナントや異なる証明書を使う環境
• 複数サービスが各自で独自の証明書を持つ場合、パススルーでそのまま転送すると運用が簡単になります。
• 内部ネットワークのサービス間通信
• 社内のマイクロサービス間で通信の復号を避け、エンドツーエンドの暗号化を保ちたいときに適します。

SSL終端との使い分け

• ロードバランサーで終端する利点
• 負荷分散装置でTLSを終了すると、負荷軽減やHTTPレイヤーでの処理（リライト、ヘッダー挿入）が可能です。
• パススルーの利点
• 復号はバックエンド側で行うため、証明書管理や内部ポリシーに柔軟に対応できます。監査要件でエンドツーエンド暗号化が必要な場合に有利です。

設計時の考慮点

• 証明書管理
• 発行・更新の責任をどこに置くか決めます。自動更新が必要ならLet’s EncryptやACMEを使う運用を検討します。
• 可視性と検査
• パススルーではロードバランサーで中身が見えません。WAFやログ解析が必要なら終端を検討します。
• 性能
• TLS復号をバックエンドに分散するとロードバランサーの負荷を減らせますが、バックエンドに負荷が集中します。

具体例（運用ケース）

• 金融機関：監査要件でエンドツーエンドを維持するためパススルーを採用
• SaaS事業者：テナント毎に独自証明書があるためパススルーで運用
• 一方、トラフィック解析やWAFが重要な公開サイトはロードバランサーで終端する運用が多いです。

VPNパススルーの概要と対応プロトコル

概要

VPNパススルーは、家庭用ルータや企業の境界機器が、内部のVPNクライアントから送られるVPN用パケットをインターネット側へそのまま通過させる機能です。機器がパケット内容を復号せず通すため、VPNサーバで暗号化終端が行われます。例えば、自宅のPCから社内VPNへ接続するとき、ルータでパススルーを有効にしておけば接続が成立します。

主な対応プロトコルとポイント

• PPTP：TCPポート1723とGRE（プロトコル番号47）が必要です。GREはポートではなく専用プロトコルなので、ルータでの対応が必須です。セキュリティ面で脆弱なため、可能なら使用を避けます。
• L2TP/IPsec：L2TP自体はUDP1701、IPsecはUDP500（IKE）とESP（プロトコル番号50）、NAT環境ではUDP4500（NAT-T）も使います。IPsec対応ルータではNATトラバーサル（NAT-T）設定を確認してください。
• SSTP：TCP443を使うため、通常のHTTPSと同じ経路で通ります。ファイアウォール越しの接続に強いです。
• OpenVPN：既定ではUDP1194ですがTCPや他ポートにも設定可能です。UDP/TCPどちらでも動くためNAT越えに柔軟です。

実装上の注意

• ESPやGREなど、ポート番号ではないプロトコルを透過するにはルータが対応している必要があります。
• 同時接続やポート競合に注意し、必要なポートやプロトコルだけ開ける運用を心がけてください。

運用の勧め

安全性や管理性を重視するなら、PPTPよりIPsecやOpenVPNを選び、ルータでは最小限のパススルー設定にとどめ、認証・暗号の強化を行ってください。

IPsecの仕組みと通信フロー

概要

IPsecは、ネットワーク上の通信を暗号化し改ざんを防ぐ仕組みです。リモートアクセスやサイト間接続でよく使われます。鍵や認証情報を交換して安全な通信路を作る点が特徴です。

Security Association（SA）とは

SAは、暗号方式や鍵など一対の通信条件をまとめた情報です。送信側と受信側がそれぞれSAを持ち、双方向の保護を行います。SAはIPアドレス、プロトコル（AH/ESP）、暗号アルゴリズムなどを含みます。

IKEの役割とフェーズ

IKE（Internet Key Exchange）はSAの交渉と鍵交換を行います。一般的に2段階のフェーズに分かれます。最初に認証や鍵交換をして暗号化トンネルの基盤を作り、次に実際のIPsec SAを確立します。IKEv2ではこれらを効率化しています。

AHとESPの違い

• AH（Authentication Header）：パケットの完全性と送信元認証を提供します。暗号化は行いません。
• ESP（Encapsulating Security Payload）：データの暗号化と認証を提供します。機密性を確保する場合はこちらを使います。

トランスポートモードとトンネルモード

• トランスポートモード：元のIPヘッダを残し、ペイロードだけを保護します。ホスト間の通信に向きます。
• トンネルモード：元のパケットを丸ごとカプセル化し新しいIPヘッダで送ります。ネットワーク間接続（サイト間VPN）でよく使われます。

通信フローの具体例

1. 端末AとゲートウェイBがIKEで相互認証と鍵交換を行う。
2. IKEで得た情報を基に各方向のSAを作成する。
3. データ送信時、ESPでペイロードを暗号化して送る。
4. 受信側はSAで復号・認証し、元のパケットを復元する。

運用上の注意点

• 鍵の有効期限と自動更新（リキー）を設定してください。
• NATを越える場合はNAT-T（NAT Traversal）対応が必要です。
• 並列で複数のSAが存在するため、管理を簡潔にしてください。

ロードバランサーでのSSL証明書管理とSSL終了の設定

概要

ロードバランサーでSSL終了（SSLオフロード）を行うと、暗号化の処理をロードバランサー側で受け持ち、バックエンドは平文または別途暗号化で受け取れます。証明書の形式やチェーンの扱いに注意が必要です。

証明書形式と変換

多くの機器はPEM形式（テキスト形式）を使います。Windowsや一部の管理画面ではDERやPFX（PKCS#12）形式を扱うことがあります。代表的な変換例：
– DER→PEM: openssl x509 -inform der -in cert.der -out cert.pem
– PFX→PEM（鍵含む）: openssl pkcs12 -in cert.pfx -out bundle.pem -nodes
– 鍵だけ抽出: openssl pkcs12 -in cert.pfx -nocerts -out key.pem -nodes

証明書バンドル（チェーン）の作り方

ブラウザと正しく信頼関係を結ぶにはサーバ証明書に中間証明書をつなげます。順序は「サーバ証明書→中間証明書…」の順で連結して1つのファイルにします。ルート証明書は通常省略します。

ロードバランサーでの設定手順（例）

1. 443番ポートでリスナーを作成します。
2. 変換済みの証明書（および中間チェーン）をアップロードまたは指定します。
3. リスナーに証明書バンドルを関連付け、必要であればSNIで複数証明書を割り当てます。
4. バックエンドとの通信方式（HTTPSまたはHTTP）を選び、ヘルスチェックを設定します。

セキュリティと運用の注意点

• 秘密鍵はアクセス制御し、パーミッションを厳しくします（例: chmod 600）。
• TLSバージョンと暗号スイートを最新の安全なものに限定します。
• 証明書の有効期限を監視し、自動更新（ACME/Let’s Encryptなど）やローテーションを導入します。
• 証明書差し替え時はロードバランサーの設定反映と接続影響を確認します。

以上がロードバランサーでの証明書管理とSSL終了の基本です。具体的な手順は製品ごとに異なるため、導入先のマニュアルを合わせてご確認ください。