【ITニュース解説】AWS Networking: SSL/TLS with Load Balancers

安全なウェブ通信が現代のインターネットにおいて不可欠な要素であるという背景から、システムエンジニアとしてまず理解すべき重要な技術がSSL/TLSである。ユーザーがウェブサイトにアクセスする際、入力するパスワードやクレジットカード情報、閲覧履歴など、あらゆるデータが盗聴や改ざんから守られる必要がある。この「通信の安全」を保証する技術が、SSL/TLSと呼ばれるプロトコルだ。TLSはTransport Layer Securityの略で、SSL（Secure Sockets Layer）の後継として開発された。現在ではSSLの古いバージョンはセキュリティ上の脆弱性から使用されておらず、代わりにTLSの最新バージョンが利用されている。しかし、歴史的な経緯や多くのIT製品、設定ファイル、あるいは業界での慣習から、いまだに「SSL」や「SSL/TLS」という言葉が一般的に使われ続けている。これは、TLSがかつてSSL 3.1と呼ばれていたことや、ベンダーが「SSL証明書」という名称で製品を販売し続けていること、また多くの設定ファイルで「ssl_certificate」のような古い名称が残っていることなどが理由だ。しかし、実質的に私たちが「SSL」と呼んでいるものは、現代ではほぼ全てが「TLS」プロトコルによる通信を指すと理解するのが正しい。

TLSプロトコルは、クライアント（ウェブブラウザなど）とサーバー（ウェブサーバーなど）の間で、データを暗号化して送受信するためのルールを定める。具体的には、SHA 256のような強力なハッシュアルゴリズムを使用してデータの改ざんを防ぎ、セキュアな通信セッションを確立するための効率的なハンドシェイクプロセスを提供する。このハンドシェイクプロセスは、安全な通信を開始するための「挨拶」のようなもので、以下のステップで進行する。まず、クライアントはサーバーに対して「Client Hello」というメッセージを送る。このメッセージには、クライアントがサポートするTLSのバージョン、利用可能な暗号スイート（暗号化やハッシュ化の手法を組み合わせたもの）、そしてセッションキー生成のためのランダムな数値（クライアント乱数）が含まれる。次に、サーバーは「Server Hello」で応答し、クライアントが提示した情報の中から最適なTLSバージョンと暗号スイートを選択し、自身のSSL証明書とサーバー乱数をクライアントに送る。クライアントは、このサーバー証明書が信頼できる認証局（Certificate Authority）によって発行されたものかを検証し、サーバーが正当な相手であることを確認する。この認証が成功すると、クライアントは「プリマスターシークレット」という秘密の情報を生成し、サーバーの公開鍵でこれを暗号化してサーバーに送る。サーバーは自身の秘密鍵でこのプリマスターシークレットを復号化する。このプリマスターシークレットと、先に交換したクライアント乱数、サーバー乱数を使って、クライアントとサーバーそれぞれが、今後の通信で実際にデータを暗号化・復号化するための「セッションキー」を生成する。最後に、両者がこのセッションキーを使って暗号化されたメッセージを交換し、ハンドシェイクが完了したことを確認する。これ以降のデータ通信は、このセッションキーを使って暗号化され、安全に行われる。

このTLSによる暗号化・復号化の処理は、特に大量のアクセスを処理するウェブサービスにとって、サーバーに大きな負荷をかける要因となる。そこで登場するのが「ロードバランサー」と「TLSオフロード（SSLターミネーション）」という考え方だ。TLSオフロードとは、クライアントからのHTTPS通信を、バックエンドのウェブサーバーに直接届けるのではなく、その手前に配置されたロードバランサーが受け止め、そこでTLSの処理（ハンドシェイク、証明書の検証、データの復号化）を全て担当するという方式を指す。このプロセスを「SSLターミネーション」と呼ぶ。ロードバランサーはクライアントとの間でセキュアなTLS接続を確立し、受信した暗号化データを復号化する。その後、復号化された平文のHTTPトラフィックとして、バックエンドのウェブサーバーに転送するのだ。これにより、バックエンドサーバーはTLSの処理を行う必要がなくなり、その分のCPUやメモリのリソースを、本来のアプリケーションロジックの実行に集中させることができる。これは、特にパフォーマンスを重視するアプリケーションにおいて、大きな効果を発揮する。

AWSが提供するロードバランサーには、主にApplication Load Balancer (ALB) と Network Load Balancer (NLB) の二種類がある。今回の要件のように、URLに基づいて複数のターゲットグループにリクエストをルーティングし、TLS処理をロードバランサーにオフロードしたい場合、ALBは非常に適した選択肢となる。ALBはHTTPSリスナーをサポートし、TLSターミネーション機能を標準で提供する。さらに、バックエンドサーバーがクライアントの実際のIPアドレスを識別できるよう、「X-Forwarded-For」というHTTPヘッダーを自動的にリクエストに付与して転送してくれるため、セキュリティログの正確な記録が可能になる。

一方、NLBもTLSターミネーションをサポートできるが、ALBとは動作するネットワークレイヤーが異なる。NLBはレイヤー4（トランスポート層）で動作するため、ALBが提供するような高度なHTTPヘッダー操作やURLベースのルーティング機能は持たない。しかし、NLBには別の強みがある。もしエンドツーエンドでの厳格な暗号化が必要な場合、NLBはTLSパススルーと呼ばれる機能を提供し、暗号化されたトラフィックをそのままバックエンドサーバーに転送することができる。この場合、TLSの復号化はバックエンドサーバー自身が行うことになる。また、相互TLS（mTLS）という、クライアントとサーバーの両方が互いの証明書を検証し合う、より厳格な認証が必要なケースにおいても、NLBはこれをサポートし、ロードバランサーとバックエンドサーバー間の相互認証を実現できる。

TLSオフロードによって得られるメリットは多岐にわたる。まず最も重要なのは「パフォーマンスの最適化」だ。TLSハンドシェイクやデータ暗号化は計算負荷が高く、この処理をロードバランサーに集中させることで、バックエンドサーバーの負荷を大幅に軽減し、より多くのアプリケーションリクエストを処理できるようになる。次に、「集中型証明書管理」が可能になる点も大きい。複数のウェブサーバーそれぞれにTLS証明書をインストールし、その有効期限を管理するのは煩雑な作業だが、ロードバランサー上で一元的に証明書を管理することで、この手間を大幅に削減できる。AWS Certificate Manager (ACM) のようなサービスと組み合わせれば、証明書の自動更新やローテーションも実現でき、運用負担をさらに軽減できる。最後に、「スケーラビリティの向上」も重要なメリットだ。バックエンドサーバーはTLS設定を持たないため、トラフィックの変動に合わせてサーバーインスタンスの数を増減させる（スケールイン・アウト）のが非常に容易になる。ロードバランサーが常にセキュアな入り口として機能し続けるため、新しく追加されたサーバーも特別な設定なしにサービスに参加できるのだ。このように、ロードバランサーによるTLSオフロードは、ウェブサービスの安全性、性能、運用効率を向上させる上で不可欠な技術であると言える。