TLS 終端 (SSL ターミネーション) とは - ロードバランサーで HTTPS を復号する構成

TLS 終端とは

TLS 終端 (TLS Termination) は、ロードバランサーや CDN で TLS (HTTPS) の暗号化/復号を処理し、バックエンドサーバーとの通信を平文 HTTP にする構成パターンである。「SSL ターミネーション」「SSL 終端」「SSL オフロード」「TLS オフロード」は同じ構成を指す呼び方であり、TLS 終端との技術的な違いは無い。プロトコルの実体が SSL から TLS に置き換わった後も、旧称の「SSL〜」が慣習的に使われている。バックエンドサーバーから TLS 処理の負荷を取り除き、証明書管理を一元化する。

[クライアント] ──HTTPS──→ [ALB / CloudFront] ──HTTP──→ [バックエンド]
                          ↑ TLS 終端ポイント

なぜ TLS 終端が必要か

TLS のハンドシェイクと暗号化/復号は CPU を消費する。負荷が偏るのは接続の確立時で、鍵交換と署名の検証がここに集まる。確立後のデータ転送に使う対称暗号は相対的に軽いため、短命な接続が大量に来る面ほど終端を集約する効果が大きい。各バックエンドサーバーで TLS を処理すると、サーバーごとに証明書を配置・更新する必要があり、運用負荷が高い。TLS 終端をロードバランサーに集約することで:

• 証明書管理が 1 箇所で済む (ACM で自動更新)
• バックエンドの CPU 負荷が軽減される
• バックエンドの実装がシンプルになる (HTTP のみ対応)

終端位置別の構成図

TLS をどこで終わらせるかで構成は 3 通りに分かれる。

1. ロードバランサーで終端 (最も一般的)

[クライアント] ══HTTPS══→ [LB (ALB)] ──HTTP──→ [サーバー群]
                          証明書は LB に 1 枚

2. CDN で終端 (オリジンと合わせて 2 段終端)

[クライアント] ══HTTPS══→ [CDN エッジ] ══HTTPS══→ [オリジン LB] ──HTTP──→ [サーバー群]
                          1 段目の終端            2 段目の終端

3. 終端しない (TLS Passthrough)

[クライアント] ══HTTPS═══════════════════════→ [サーバー]
               [LB は暗号化されたまま素通し]     証明書はサーバー側

AWS での TLS 終端 - 設定例

ALB + ACM

ALB の HTTPS リスナー (ポート 443) に ACM の証明書を関連付けて終端し、ターゲットグループのプロトコルを HTTP (ポート 80) にする。ターゲットグループを HTTPS にすれば再暗号化 (Re-encryption) 構成になる。TLS バージョンと暗号スイートはリスナーのセキュリティポリシーで一括制御する。ACM の証明書は自動更新されるため、証明書の期限切れを心配する必要がない。

CloudFront + S3

CloudFront がエッジで TLS を終端し、オリジンの S3 バケットへ取得に行く。静的サイト配信の標準構成だ。ビューワープロトコルポリシーを「Redirect HTTP to HTTPS」にすればクライアントとエッジの間は HTTPS に揃う。エッジとオリジンの間は、S3 をどの形式でオリジンに指定したかで変わる。REST エンドポイントをオリジンにした場合、CloudFront はビューワーが使ったプロトコルと同じプロトコルで S3 へ転送するため、ビューワー側を HTTPS に強制すればこの区間も HTTPS になる。一方、静的ウェブサイトホスティングのウェブサイトエンドポイントをオリジンにすると、S3 がその形式では HTTPS 接続を受け付けないため、エッジとオリジンの間は HTTP のままになる。EC2 や ALB をカスタムオリジンにする場合はオリジンプロトコルポリシーを「HTTPS Only」にして暗号化する。CloudFront に関連付ける ACM 証明書はバージニア北部 (us-east-1) で発行する必要がある点に注意。

NLB (Passthrough が必要な場合)

クライアントからバックエンドまで一度も復号させない要件があるときは、NLB の TCP リスナーで暗号化されたまま転送する。TLS ハンドシェイクの相手はバックエンド自身になるので、証明書もバックエンドに置く。

ただし「クライアント証明書認証 (mTLS) を使うから終端できない」という理由付けは成り立たない。ALB の HTTPS リスナーには相互 TLS の設定があり、2 つのモードから選べる。信頼ストアに登録した CA を使って ALB 自身にクライアント証明書を検証させる verify モードと、検証はせずに受け取った証明書チェーンを URL エンコードした PEM として X-Amzn-Mtls-Clientcert ヘッダーでバックエンドへ渡す passthrough モードである。後者は名前に passthrough と付くが素通しするのは証明書であって、TLS 接続自体はリスナーで終端する。検証をロードバランサーへ寄せたいなら前者、アプリ側に既にある検証ロジックを使い続けたいなら後者になる。なお相互 TLS を有効にしたリスナーではセッション再開が使えないため、接続ごとに完全なハンドシェイクが走る。

TLS 終端の構成パターン

選択の分かれ目は 2 つで、バックエンドまでの経路を暗号化する義務があるか、そして TLS ハンドシェイクの相手をロードバランサーとバックエンドのどちらにするかである。復号する地点を増やすほど、鍵と証明書を管理する場所も増える。

パターン	TLS 終端	バックエンド通信	用途
TLS Termination	LB で終端	HTTP (平文)	一般的な Web アプリ
TLS Passthrough	LB は素通し	バックエンドで TLS 処理	エンドツーエンド暗号化が必要
TLS Re-encryption	LB で終端 + 再暗号化	HTTPS (再暗号化)	コンプライアンス要件

セキュリティ上の考慮

TLS 終端後のバックエンド通信が平文になるため、VPC 内のプライベートサブネットに閉じる。AWS はロードバランサーとターゲットの間の通信をパケットレベルで認証しており、この区間ではなりすましや中間者攻撃の心配は無いとしている。裏を返せば、その保護は AWS を出た通信には及ばない。オンプレミスや別環境へ平文のまま抜ける経路があるなら、終端位置そのものを見直す方が先である。

再暗号化にも誤解しやすい点がある。ターゲットグループを HTTPS にしたとき、ALB はターゲットに置かれた証明書を検証しない。自己署名証明書でも期限切れの証明書でも接続は成立する。得られるのは経路の暗号化であって、相手が正しいサーバーであることの確認ではない。

コンプライアンス要件 (PCI DSS、HIPAA) でエンドツーエンド暗号化が求められる場合は、TLS Re-encryption または TLS Passthrough を使う。

バックエンドでの X-Forwarded ヘッダー

TLS 終端後、ALB はバックエンドに以下のヘッダーを付与する。

X-Forwarded-For: 203.0.113.50      # クライアントの IP
X-Forwarded-Proto: https            # 元のプロトコル
X-Forwarded-Port: 443               # 元のポート

バックエンドは X-Forwarded-Proto を確認し、HTTPS でアクセスされたことを認識する。リダイレクト URL の生成やセキュリティヘッダーの設定に使う。

落とし穴は、これらのヘッダーをクライアントが自分で付けて送れることである。ALB は X-Forwarded-For が既に付いていれば捨てずに、観測したクライアント IP を末尾へ追記する。値がカンマ区切りで複数並んでいるとき、ALB 直下の構成で信頼できるのは末尾の 1 つだけで、先頭を「本当のクライアント IP」として扱うと、アクセス制限やレート制限をクライアント側から偽装できる穴になる。バックエンドがロードバランサーを経由せずに直接叩かれ得る配置なら、X-Forwarded-Proto を鵜呑みにした HTTPS 判定も同じ理由で危うい。

終端位置ごとの使い分けと設計判断は解説記事 TLS 終端の仕組み - SSL ターミネーションとの違いと構成パターン 3 種 で詳しく扱っている。TLS 終端の理解を深めるには関連書籍が参考になる。