SSL/TLS終端の基礎と設計パターン：エッジ終端・再暗号化・パススルーを活用した運用ガイド
エバープレイ編集部はじめに — 「SSL終端」とは何か
「SSL終端（SSL/TLS終端）」とは、インターネット上のクライアントとサーバー間で暗号化される通信（通常はHTTP over TLS、すなわちHTTPS）の暗号処理（復号および暗号化）を特定の中間装置で行う構成を指します。一般にはロードバランサ、リバースプロキシ、CDN、ファイアウォールなどが「終端」を担当し、そこまででTLSセッションを確立・終了（terminate）します。
用語整理：SSL と TLS の違い
歴史的には「SSL（Secure Sockets Layer）」という名称が使われてきましたが、現在はプロトコルとしては改良版のTLS（Transport Layer Security）が標準です。実務では「SSL終端」という表現が広く定着していますが、技術的にはTLS終端と読むのが正確です。本稿でも慣用に従い「SSL終端」を用いますが、TLSが対象である点を念頭に置いてください。
終端のパターン
- SSL/TLS終端（Termination）：エッジ（ロードバランサやCDNなど）でTLSを復号し、その後は平文（HTTP）でバックエンドサーバへ転送する方式。CPU負荷をオフロードし、中央で証明書管理を行えるメリットがある。
- SSL/TLSパススルー（Passthrough）：TCPレベルでTLSを通過させ、バックエンドが直接TLSを終端する方式。バックエンドに証明書が必要で、エンドツーエンドの暗号化が保たれる。
- SSL/TLSブリッジ（Re-encryption / SSL bridging）：エッジで一度復号して検査やルーティング判断を行い、その後再びバックエンドへTLSで再暗号化して送る方式。検査とエンドツーエンド保護の折衷。
- 相互TLS（mTLS）：クライアント証明書による相互認証を行う方式。APIゲートウェイやサービス間通信で用いられる。
なぜ終端を使うのか（メリット）
- 暗号化処理のオフロード：TLSの暗号化／復号はCPU負荷が高い。専用装置（ハードウェアアクセラレータ）や最適化されたプロキシに処理を集約できる。
- 証明書管理の中央化：証明書の発行・更新・撤回を一元化し、複数サーバの作業を減らせる。
- 機能の実装が容易：OCSPステープリング、ALPN（HTTP/2/HTTP/3対応）、TLS設定更新、WAFやリクエストの検査がエッジで容易に実装できる。
- パフォーマンス改善：HTTP/2やHTTP/3（QUIC）のサポートをエッジで提供し、クライアント体験を向上させられる。
終端のリスクと考慮点（デメリット）
- 内部ネットワークで平文が流れる場合、ネットワーク内部での盗聴や横移動に弱くなる。特にクラウド環境やマルチテナント環境では注意が必要。
- 証明書・秘密鍵の集中管理は利便性向上だが、鍵の漏洩リスクは集中する。HSMやクラウドKMSの利用が推奨される。
- コンプライアンス要件（PCI-DSS, HIPAAなど）やセキュリティポリシーによっては、内部でも暗号化（エンドツーエンド）を要求することがある。
実運用での設計パターンと推奨
どの方式を採るかは要件次第だが、よく使われる設計パターンを挙げる。
- エッジ終端 + バックエンドは平文（非推奨だが単純）：社内閉域ネットワークかつセキュリティ境界が確保されている場合のみ。ただし規模が大きくなるとリスクが高まる。
- エッジ終端 + バックエンド再暗号化（推奨）：エッジで復号した後、バックエンドへは内部証明書で再暗号化する方式。検査と内部暗号化の両立ができる。
- パススルー（バックエンドで終端）：厳密なエンドツーエンド暗号化が必要な場合。各サーバで証明書管理が必要になる。
運用上のベストプラクティス
- TLSバージョンはTLS 1.2以上を許可、可能ならTLS 1.3を優先。TLS 1.0/1.1やSSLv3は無効化する。
- 鍵長とアルゴリズム：RSAは2048ビット以上、推奨はECDSA（P-256/P-384）やRSA 4096。ECDHEを使ったPFS（Perfect Forward Secrecy）を必須にする。
- 強い暗号スイートを利用：AEAD（AES-GCM、CHACHA20-POLY1305）を優先。古いCBCモードやRC4は無効化。
- OCSPステープリング、証明書透過（CT）ログの活用、定期的な証明書のローテーション。
- 秘密鍵の保護：可能な限りHSMやクラウドKMSを利用し、アクセスログと監査を行う。
- 自動化：ACME（Let's Encrypt）などで証明書発行・更新を自動化し、人為的ミスを減らす。
- 監査とテスト：SSL Labs、testssl.sh、sslyze、nmapのsslスクリプト、openssl s_client等で定期的に検査する。
設定例（概念的）
実際のTLS終端は使用するソフト／サービスによって設定が異なります。例えばNGINXでは ssl_certificate と ssl_certificate_key を使い、HAProxyでは crt-list/ssl parameters を使って終端を行います。クラウド（AWS ALB/ELB、Google Cloud Load Balancer、Azure Application Gateway）やCDN（Cloudflare、Fastly）はマネージドでTLS終端を提供します。Cloudflareの「Flexible」モードはエンドツーエンド暗号化を行わないため危険で、「Full (strict)」の利用が推奨されます。
パフォーマンス面の留意点
- TLSハンドシェイク回数が多いとCPU負荷が高まる。セッション再開（TLS session resumption）やTLS1.3の0-RTT（慎重な運用が必要）を検討。
- ハードウェアTLSオフロード（NICや専用カード）や、エッジキャッシュ（CDN）によりスケーラビリティを向上させられる。
セキュリティ事故時の考え方
もし秘密鍵が漏洩した疑いがある場合はただちに証明書の失効（CRL/OCSP）と置換を行い、関連するログやアクセスを調査します。鍵の取り扱いポリシー（最小権限、鍵ローテーション、監査）を整備しておくことが重要です。
まとめ
「SSL終端」はTLS暗号処理をエッジで行うことで運用効率と機能性を高める有効な手法ですが、内部平文化のリスクと鍵管理の集中リスクを理解して運用設計する必要があります。要件に応じて「終端のみ」「再暗号化」「パススルー」などの方式を選択し、TLSバージョン・暗号スイートの強化、秘密鍵保護、自動化と定期検査を組み合わせることが安全でスケーラブルな構成を実現する鍵です。
参考文献
- IETF TLS ワーキンググループ資料（RFC 等）
- Mozilla Server Side TLS 推奨設定
- Qualys SSL Labs（サーバ評価ツール）
- Let's Encrypt（ACME 証明書自動化）
- Cloudflare SSL/TLS ドキュメント
- PCI DSS（暗号化に関する要件）
- OWASP（一般的なセキュリティ注意点）
- testssl.sh（TLS 診断ツール）
投稿者プロフィール
