はじめに
本書の目的
本ドキュメントは、SSL Passthroughの基本概念から運用上の注意点までを分かりやすく解説します。暗号化された通信を中継して復号化せずにバックエンドに渡す方式を中心に、実務で役立つ視点を提供します。
どんな場面で使うか（具体例）
たとえば、会社内で独自証明書を使う複数のWebサービスがあり、ロードバランサーで負荷分散したい場合です。ロードバランサーが暗号化を解除せずにそのまま各サーバーへ転送すると、各サーバー側で証明書管理やアクセス制御を一元化できます。
読者像と前提知識
ネットワークやWebサーバーの基本（IP、ポート、TLSの概念）が分かれば読み進められます。専門用語は最小限に留め、具体例を交えて説明します。
本書の構成
次章からは定義、仕組み、他方式との比較、メリット・デメリット、mTLSとの関係、ロードバランサー固有の特性へと順に解説します。実運用での判断材料を得たい方に向けた構成です。
SSL Passthroughの基本定義
概要
SSL Passthroughとは、ロードバランサーやネットワーク機器が受け取ったSSL/TLSで暗号化された通信を復号化せず、そのままバックエンドサーバーに転送する方式です。ロードバランサーは単純にデータを通すだけで、復号化と証明書の処理はバックエンドで行います。
具体的なイメージ
例えば、利用者がhttps://example.comにアクセスすると、ブラウザからの暗号化された接続がロードバランサーへ届きます。ロードバランサーはTCPレベルでその接続を選んだサーバーに渡し、最終的にバックエンドのWebサーバー（nginxやApache）がTLSを終端して復号化します。
証明書の配置
この方式では、SSL証明書はバックエンドサーバーへだけインストールすれば足ります。ロードバランサー側に証明書を入れないため、証明書管理を集中させたい場合や、エンドツーエンドの暗号化を維持したい場合に有効です。
注意点（簡潔に）
- ロードバランサーは暗号化内容を見ないため、HTTPヘッダーやクッキーを使った振り分けや書き換えができません。
- アプリケーション層の処理（リダイレクトやWAFなど）はバックエンド側で行う必要があります。
- SNI（TLS拡張）を使ったホスト名ベースの振り分けは、ロードバランサーがTLSハンドシェイクの一部を参照できる場合に限り可能です。
以上がSSL Passthroughの基本的な定義とイメージです。次章では、内部の仕組みをもう少し詳しく見ていきます。
SSL Passthroughの仕組み
概要
SSL Passthroughはロードバランサーが暗号化されたままのTLS接続をそのままバックエンドに中継する方式です。ロードバランサーはパケットを復号せず、TCPレベルで転送します。結果として暗号化はサーバー側でのみ解除されます。
転送の流れ（ステップ）
- クライアントがTLSで接続要求を送る（例：ブラウザ→ロードバランサー）。
- ロードバランサーはパケットを受け取り、TCPモードでバックエンドサーバーに転送します。
- バックエンドサーバーがTLSハンドシェイクを行い、自身の証明書で接続を確立します。
SNIによるルーティング
ロードバランサーはTLSのClientHello内のSNI（サーバ名）だけを参照してルーティングできます。SNIは暗号化される前に送られるため、ロードバランサーはペイロードに触れずにドメインごとの振り分けが可能です。
バックエンドでの復号化と管理
バックエンドは証明書と秘密鍵を持ち、ここで初めてデータを復号します。証明書更新や失効対応は各サーバー側で行います。運用面では証明書管理の集中化はできませんが、エンドツーエンドの暗号化が保たれます。
具体例
例として、ブラウザが「www.example.com」に接続すると、ロードバランサーはSNIで振り分けて適切なサーバーへTCPで転送し、そのサーバーがTLS接続を終了します。
SSL Passthroughと他のSSL処理方式の比較
概要
SSL処理には主に3つの方式があります。SSL bridging、SSL offloading（SSL termination）、SSL passthroughです。それぞれ暗号化の扱い方が異なり、負荷・可視性・機能性に違いが出ます。
各方式の違い（わかりやすい例で）
- SSL bridging
- ロードバランサーが受け取った暗号化通信を復号化し、一部処理した後で再暗号化してバックエンドに送ります。例えると、郵便局で中身を確認してから別封筒で配送するイメージです。アプリ層（レイヤー7）の処理が可能です。
- SSL offloading（SSL termination）
- ロードバランサーで復号化し、バックエンドへは平文で送信します。復号の負荷をロードバランサーに移せます。バックエンドで暗号の管理を省けますが、内部ネットワークでの平文通信に注意が必要です。
- SSL passthrough
- ロードバランサーは暗号をそのまま通します。復号せず終端もしないのでオーバーヘッドが最小限です。暗号化はサーバ側で一貫して行われます。
選び方の目安
- セキュリティ最優先でサーバ側で鍵管理したい場合はSSL passthroughが適します。
- レイヤー7のルーティングやヘッダ操作が必要ならSSL bridgingを検討します。
- ロードバランサーに復号処理を任せてバックエンドを軽くしたいならSSL offloadingが向きます。
実運用での留意点
- ログやトラフィック解析を行う場合は復号が必要になります。パケット内容を見たいときはbridgingかoffloadingが必要です。
- mTLSやクライアント証明書を使う場合は、パススルー時にサーバ側で正しく扱えるか確認してください。
- 運用負荷とセキュリティのバランスを考えて選ぶとよいです。
SSL Passthroughのメリット
1. 通信が常時暗号化される（エンドツーエンド）
SSL Passthroughでは、クライアントからサーバーまでの通信が途中で復号されません。たとえば、クレジットカード情報を扱うサイトでは、途中で平文に戻らないため情報漏えいリスクが小さくなります。暗号化の範囲が明確で、安全性が高まります。
2. オーバーヘッドが小さく、高スループット・低遅延
プロキシやロードバランサが暗号化を解除しないため、CPU負荷が減ります。動画配信や大量リクエストをさばくAPIでは、復号・再暗号化の処理がないぶん速く応答できます。実運用でレスポンス改善が期待できます。
3. 証明書管理がバックエンドに集約される
証明書や秘密鍵をバックエンドサーバーだけで管理できます。証明書を入れ替える際も、負荷分散層に手を入れる必要が少なく、運用が楽になります。例として、各アプリケーションサーバーで個別に更新でき、細かなロールアウトが行えます。
4. 鍵の秘匿性が高い
秘密鍵を中間機器に置かないため、鍵の漏えいや不正取得のリスクが低くなります。規制の厳しい業界や内部ポリシーが厳格な組織で有利です。
SSL Passthroughのデメリットと制限
レイヤー7（アプリ層）の処理ができない
SSL Passthroughは暗号化されたまま通信を転送します。そのためロードバランサーやプロキシでHTTPヘッダーやURLを読み取れません。例として、特定のURLに基づくルーティングやリダイレクト、ヘッダーの書き換えが行えません。
クッキーやセッション管理の制約
クッキーベースのスティッキーセッション（同一ユーザーを同じサーバへ割り当てる仕組み）が使えません。ショッピングカートやログイン状態をサーバ側のセッションに依存するアプリでは、セッションが失われる可能性があります。代替としてはサーバ側で共有セッションやトークン方式を採用します。
証明書管理とサーバ負荷
暗号化を終端しないため、各バックエンドに証明書を配置し更新する必要があります。SSL/TLSの処理はバックエンドで行うためCPU負荷が増えます。小規模なサーバ群や証明書管理が難しい環境では運用コストが上がります。
監視・ログ収集・障害対応の難しさ
ロードバランサー側で通信内容を解析できないため、リクエスト単位の詳細ログやWAFの導入が難しいです。問題発生時はバックエンド側での調査が中心になり、原因特定に時間がかかる場合があります。
適用判断のポイント
セキュリティで暗号化の保持が最優先で、かつサーバ側で対応できる運用体制があるならPassthroughは有効です。逆にアプリレベルの細かな処理や簡単なセッション固定を期待する場合は別の方式を検討してください。
mTLS認証とセキュリティ強化
概要
mTLS（相互TLS）はクライアントとサーバーがそれぞれ証明書で相互に認証する仕組みです。SSL Passthroughは暗号化をロードバランサーで終端せずにバックエンドで終了させるため、mTLSの実装に適しています。
なぜSSL Passthroughが有効か
たとえば内部のマイクロサービス間で、クライアント側（サービスA）とサーバー側（サービスB）が双方証明書で身元を確認したい場合、ロードバランサーがTLSを終端するとエンドツーエンドの証明が切れてしまいます。Passthroughでは暗号化を保ったままバックエンドで検証するため、真正性を維持できます。
AWS VPC Latticeなどの例
VPC LatticeでTLS Passthroughを使うと、クラウドとオンプレミスなど異なる環境にあるサービス間でmTLSをバックエンド側で完結できます。これによりロードバランサーの認証負荷を減らしつつ、サービス間の認証を確実に行えます。
運用上の注意
- 証明書管理：バックエンドで信頼するCAや証明書の配布・更新を丁寧に行ってください。例として、自動更新（短寿命証明書）を導入すると安全です。
- ヘルスチェック：TLS終端しないため健康チェックはTCPや専用のTLSヘルスチェックを使います。
- ロギングと障害対応：認証失敗はバックエンドで発生するため、詳細ログをバックエンド側で取得・監視してください。
実用的なポイント
- SNI（サーバーネーム）を利用すると複数サービスを同一IPで扱いやすくなります。
- コネクションの再利用やキープアライブ設定でパフォーマンス改善します。
Pass-Through Load Balancerの特性
概要
Pass-through（透過）型のロードバランサは、受信したTCP/TLSパケットをそのままバックエンドに転送します。ロードバランサ自身でTLSを終端せず、新しい接続を作りません。結果としてクライアントの元の情報がそのまま残ります。
動作の特徴
- コネクションを再確立しないため、パケットのヘッダ（送信元IPやポート）が保持されます。バックエンドは直接クライアント情報を受け取れます。
- レイヤー4（TCP）で動作することが多く、HTTPヘッダなどアプリ層の内容は見ません。
保持される情報と利点
送信元IP、送信元ポート、TLSクライアント証明書（mTLSを使う場合）などがそのまま届きます。これにより正確なアクセスログ記録やクライアント認証をサーバ側で行えます。
運用上の注意点
- ロードバランサ側でTLSを解析できないため、WAFやHTTPヘッダベースのルーティングは使えません。プロキシプロトコル対応や適切なヘルスチェックを用意する必要があります。
- セッション維持はコネクション単位で扱われます。必要ならバックエンドでの持続化設計が必要です。
よく使われる場面
社内システムでクライアントIPを厳格に管理する場合や、サーバ側でmTLSを終端して強い認証をしたい場合に選ばれます。
