TLS 終端の仕組み - SSL ターミネーションとの違いと構成パターン 3 種を図解

この記事は約 7 分で読めます。

TLS 終端の仕組みを一言で - 暗号化通信を「どこで終わらせるか」の設計

TLS 終端 (TLS Termination) とは、クライアントとの間で張られた TLS (HTTPS) の暗号化通信を、ロードバランサーや CDN などの中継地点で復号し、そこから先のバックエンドへは別の通信として転送する構成のことです。「終端」という言葉のとおり、暗号化されたコネクションをどの装置で終わらせるかがこの設計の本質です。

[クライアント] ══HTTPS (暗号化)══▶ [終端ポイント] ──HTTP (平文)──▶ [バックエンド]
                                   ここで復号する

TLS のハンドシェイク (鍵交換) と暗号化・復号は CPU を消費する処理です。これを各バックエンドサーバーに分散して持たせる代わりに、手前の 1 点に集約するのが TLS 終端の狙いで、次の 3 つの利点があります。

• サーバー証明書の配置・更新が終端ポイント 1 箇所で済む
• バックエンドは TLS 処理から解放され、アプリケーションの処理に CPU を使える
• バックエンドの実装は HTTP のみ対応すればよく、シンプルになる

用語としての定義や X-Forwarded ヘッダーの扱いは用語集の TLS 終端 (SSL ターミネーション) とは にまとめてあります。この記事では、仕組みと構成パターンの使い分けを掘り下げます。

SSL ターミネーションと TLS 終端の違いは無い

先に検索されやすい疑問に答えておくと、SSL ターミネーション、SSL 終端、TLS ターミネーション、TLS 終端、SSL/TLS オフロードは、すべて同じ構成を指す呼び方であり、技術的な違いはありません。

呼び方が分かれているのは、プロトコルの歴史に理由があります。暗号化プロトコルとしての SSL は 1990 年代に Netscape 社が開発したもので、その後継として 1999 年に TLS 1.0 (RFC 2246) が標準化されました。SSL 2.0 は 2011 年 (RFC 6176)、SSL 3.0 は 2015 年 (RFC 7568) にそれぞれ使用禁止・非推奨とされ、以降の実務で実際に使われているのは TLS です。しかし「SSL 証明書」「SSL 終端」という呼び名だけが慣習として残ったため、同じものを指す用語が併存しています。

• 厳密なプロトコル名で呼ぶなら「TLS 終端」
• 負荷の肩代わりに着目した呼び方が「TLS (SSL) オフロード」
• 慣習的な呼び名が「SSL ターミネーション」「SSL 終端」

ドキュメントやクラウドの管理画面ではこれらが混在して登場しますが、読み替えて問題ありません。

なぜ「終端」に処理を集めるのか - ハンドシェイクのコスト

TLS 通信の開始時には、クライアントとサーバーの間でハンドシェイクと呼ばれる手続きが走ります。使用する暗号スイートの合意、サーバー証明書の検証、セッション鍵の共有までを行ってから、はじめてアプリケーションデータの暗号化通信が始まります。

このハンドシェイクには公開鍵暗号の演算が含まれ、通信のたびに発生するとサーバーの CPU を無視できない割合で消費します。TLS 1.3 (RFC 8446、2018 年) でハンドシェイクの往復回数は削減されましたが、処理そのものが消えるわけではありません。

さらに運用面では、証明書の期限管理が問題になります。バックエンドサーバーが 10 台あれば、証明書の更新作業も 10 箇所に発生します。終端を 1 点に集約すれば、証明書の更新も暗号スイートの設定変更 (古い TLS バージョンの無効化など) も 1 箇所の変更で済みます。TLS 終端は性能対策であると同時に、証明書運用の一元化という管理上の設計でもあります。

構成パターン 3 種 - 終端位置で何が変わるか

TLS をどこで終わらせるかによって、代表的な構成は 3 つに分かれます。

パターン 1: ロードバランサーで終端する (最も一般的)

[クライアント] ══HTTPS══▶ [ロードバランサー] ──HTTP──▶ [サーバー群]
                          証明書はここに 1 枚

Web アプリケーションの標準構成です。ロードバランサー (AWS なら ALB) に証明書を置き、バックエンドへは平文 HTTP で転送します。バックエンドとの通信はプライベートネットワーク内に閉じるため、平文であってもインターネットを経由しません。

パターン 2: CDN で終端する (2 段終端を含む)

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

CDN (AWS なら CloudFront) を使う構成では、まず世界各地のエッジサーバーがクライアントとの TLS を終端します。エッジからオリジンへの通信は改めて HTTPS を張り直すのが一般的で、この場合は「CDN で終端し、オリジンで再度終端する」2 段構成になります。エッジで終端することで、クライアントから見たハンドシェイクの往復距離が短くなり、TLS 接続の確立自体が速くなるのがこのパターンの利点です。

パターン 3: 終端せずに通す (TLS パススルー)

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

ロードバランサーが TLS を復号せず、暗号化されたバイト列のまま L4 (TCP) で転送する構成です。クライアントとバックエンドの間でエンドツーエンドの暗号化が維持されるため、中継装置にも通信内容を見せたくない場合や、クライアント証明書認証 (mTLS) をバックエンド自身で検証したい場合に使います。代償として、負荷分散装置は HTTP レベルの情報 (パス、ヘッダー) を見られなくなり、パスベースのルーティングや Cookie ベースの振り分けは使えません。

3 パターンの比較表

観点	LB 終端	CDN 終端 (2 段)	パススルー
証明書の置き場所	LB のみ	CDN とオリジンの 2 箇所	各サーバー
バックエンドの TLS 負荷	なし	なし	あり
L7 ルーティング	可能	可能	不可 (L4 のみ)
エンドツーエンド暗号化	されない	されない	される
主な用途	一般的な Web アプリ	静的配信 + 動的 API	mTLS・高コンプライアンス要件

なお、LB で終端した後にバックエンドへ HTTPS を張り直す「TLS 再暗号化 (Re-encryption)」という中間形もあります。内部ネットワークでも平文を流さないという社内基準やコンプライアンス要件 (PCI DSS など) がある場合に選択されます。

AWS での設定例 - ALB と CloudFront

概念を AWS の実際の設定項目に対応させると次のようになります。

ALB (Application Load Balancer) で終端する場合は、HTTPS リスナー (ポート 443) に ACM (AWS Certificate Manager) の証明書を関連付けます。ACM の証明書は自動更新されるため、期限切れの運用リスクがほぼなくなります。バックエンド (ターゲットグループ) のプロトコルを HTTP にすれば LB 終端、HTTPS にすれば再暗号化構成です。TLS のバージョンや暗号スイートはリスナーのセキュリティポリシーで一括制御します。

CloudFront で終端する場合は、ビューワー (クライアント側) とオリジン側で設定が分かれます。ビューワープロトコルポリシーで HTTP → HTTPS リダイレクトを強制し、オリジンプロトコルポリシーを HTTPS Only にすればエッジとオリジン間も暗号化されます。CloudFront に関連付ける ACM 証明書はバージニア北部 (us-east-1) リージョンで発行する必要がある、という制約は実務でつまずきやすいポイントです。

パススルーが必要な場合は、ALB ではなく NLB (Network Load Balancer) の TCP リスナーを使い、復号せずにバックエンドへ流します。

設計判断のポイント - どこで終端すべきか

構成を選ぶときの判断基準を整理します。

1. 迷ったら LB (または CDN) 終端。証明書運用の一元化と L7 ルーティングの恩恵が大きく、大半の Web アプリケーションはこれで足ります。
2. 「内部でも平文を流さない」という要件が明文化されているなら再暗号化。性能コストは増えますが、要件への適合が優先です。
3. 通信内容を中継装置にすら見せられない場合だけパススルー。L7 機能を全部手放すことになるため、消去法ではなく要件から選ぶ構成です。

また、どのパターンでも共通する注意点として、終端した装置から先のバックエンドは「クライアントの IP アドレス」や「元のプロトコル」を直接は知れなくなります。X-Forwarded-For / X-Forwarded-Proto ヘッダーをアプリケーション側で正しく解釈する実装が必要です。

よくある質問

Q. SSL ターミネーションと TLS 終端はどちらの表記が正しい?

同じ構成を指すため、どちらでも通じます。実際に使われているプロトコルは TLS なので、新しく書くドキュメントでは「TLS 終端」と表記し、検索や過去資料の読解では「SSL ターミネーション」も同義語として扱うのが実務的です。

Q. TLS 終端をするとセキュリティは下がる?

終端後の内部通信が平文になる点だけを切り出せばそうですが、プライベートネットワーク内に閉じていればインターネット上の盗聴リスクとは別物です。一方で、証明書と TLS 設定を 1 箇所で管理できることは、古い暗号設定の放置を防ぐという意味でセキュリティ向上に働きます。要件に応じて再暗号化・パススルーを選べばよく、「終端 = 危険」ではありません。

Q. 終端の設定を体系的に学ぶには?

ネットワークの教科書で TCP/IP と TLS の位置付けを押さえたうえで、使っているクラウドの公式ドキュメントに当たるのが最短です。書籍では マスタリング TCP/IP 入門編 第 6 版 がプロトコル階層の全体像に、Web 配信の技術 が CDN・リバースプロキシを含む配信経路の設計に対応しています。HTTP プロトコル側から掘り下げたい場合は Real World HTTP 第 3 版 が該当します。

関連記事

• TLS 終端 (SSL ターミネーション) とは - 用語集
• セキュリティ本ガイド - Web 開発者が読むべき技術書の選び方
• インフラ・クラウド本ガイド - AWS や Docker を本で学ぶ

まとめ

TLS 終端は「暗号化通信をどこで終わらせるか」という設計判断であり、SSL ターミネーションとの違いはありません。基本は LB / CDN での終端で、証明書運用の一元化と負荷の集約が得られます。内部も暗号化したいなら再暗号化、エンドツーエンドの暗号化が必須ならパススルー。この 3 パターンの比較表を手元に置いて、要件から逆算して選んでください。