SSLとロードバランサーの連携で実現する安全な通信環境の構築法

目次

はじめに

本記事では、SSL対応のロードバランサー周りを中心に、実務で直面しやすい課題と設計の考え方を分かりやすく解説します。読者はネットワークやサーバ運用の基礎を持つ方を想定していますが、専門用語はできるだけ減らして説明します。

  • この記事の目的
  • ロードバランサーとSSL/TLSの関係を整理します。
  • IISでのWindows認証を含む環境で発生するSSL終端の問題点と構成例を示します。
  • TLSパススルーの仕組みとメリットを具体例で説明します。
  • ロードバランサーにおける証明書の選び方と管理方法を分かりやすく伝えます。

  • 読み方のポイント

  • まず第2章で実務的な構成を見ながら理解を深めてください。次に第3章で別の方式を比較し、第4章で証明書運用の注意点を学べます。実例中心に説明しますので、運用設計にすぐ役立ちます。

今後の章で具体的な構成図や設定の考え方を順に示します。どうぞ気軽に読み進めてください。

ロードバランサー + SSL環境でのIIS統合Windows認証構成

問題の整理

L7(HTTP)ロードバランサーでSSLを終端すると、クライアントとIIS間のネゴシエーション(NTLM/Negotiate)が切れて認証情報が失われることがあります。社内ポータルなどでAD連携を使う場合、この点が障害になります。

構成①:L7でSSL終端+IISへHTTP転送

  • 概要:ロードバランサーで証明書を終端し、バックエンドへは平文(HTTP)で転送します。
  • メリット:ロードバランサーでアクセス制御やヘルスチェックが柔軟にでき、証明書管理が集中します。
  • デメリット:IISでWindows認証は基本的に動きません(認証の再ネゴが不可)。内部ネットワークでも平文は注意が必要です。
  • Windows認証:非対応(追加対策が必要)

構成②:L4でTLSパススルー

  • 概要:ロードバランサーはTCP層で転送し、SSLは各IISで終端します。
  • メリット:クライアントからIISまでのエンドツーエンド暗号化を維持でき、Windows認証(Kerberos/NTLM)が動作します。
  • デメリット:LB側での詳細なHTTP処理や証明書の集中管理ができません。
  • Windows認証:対応可

構成③:L7でSSL終端+HTTP 302でIISへリダイレクト

  • 概要:LBが一旦終端し、認証が必要なパスは302でブラウザをIISのホスト名へ誘導します。
  • メリット:証明書管理とWindows認証を両立しやすいケースがあります。例:内部専用のFQDNにリダイレクトする。
  • デメリット:UXが変わる(リダイレクトが見える)、構成が複雑になります。
  • Windows認証:対応可(リダイレクト先が正しいホスト名とSPNを持つことが前提)

設定上の注意点

  • Kerberosを使う場合はSPN設定とホスト名整合性が重要です。適切なFQDNでサービスアカウントにSPNを登録してください。
  • NTLMは接続保持の仕組みに依存します。L7で接続が終端されると継続しません。
  • 内部ネットワークでも暗号化やアクセス制御を忘れないでください。

おすすめは運用と安全性のバランスで選ぶことです。証明書集中管理を重視するなら①か③、Windows認証を確実に動かしたいなら②を検討してください。

TLSパススルーとは?負荷を抑えてセキュアに通信する仕組み

概要

TLSパススルーはロードバランサーが暗号化されたTLS通信を復号せず、そのままバックエンドサーバーに転送する仕組みです。ロードバランサーは第4層(L4)でパケットを扱い、暗号化の処理は各サーバーに任せます。

なぜ使うか(メリット)

  • ロードバランサーのCPU負荷を下げられます。証明書の復号処理を行わないためです。
  • サービス側で証明書を一元管理したい場合に便利です。例えば、各サーバーで個別の証明書を使う場面に適します。
  • エンドツーエンドの暗号化が保たれます。中間で平文に戻らないためセキュリティが高いです。

実例と設定のポイント

  • AWSのNetwork Load Balancer(NLB)は代表的な例で、TLSパススルー向けに設計されています。
  • バックエンドで証明書を配置し、サーバー側でTLS終端を行います。ポートは通常443をそのまま渡します。

注意点

  • ロードバランサーでHTTPヘッダー操作やWAFのTLS検査ができません。アプリ層の制御が必要な場合はTLS復号(オフロード)を検討してください。
  • ヘルスチェックやセッション管理は工夫が必要です。TCPベースのヘルスチェックを使うか、別途ヘルス用のエンドポイントを用意します。

運用上の留意点

証明書更新はサーバー側で個別に必要です。自動化ツールを使って更新を統一すると運用が楽になります。

SSL証明書の概要 – Load Balancing

TLSネゴシエーションと証明書選択

ロードバランサーはクライアントが送る暗号リスト(cipher list)とSNI(Server Name Indication)を受け取ります。SNIで指定されたホスト名に合う証明書を選び、TLSのハンドシェイクを完了させます。例えば「shop.example.com」が来れば、その名前に合う証明書を返します。

SNIの役割

SNIがあると1台のロードバランサーで複数ドメインを扱えます。ワイルドカードやSAN(Subject Alternative Name)証明書を使えば管理が楽になります。

運用の実例

  • 各ドメインに個別証明書:鍵管理は厳格にします。
  • ワイルドカード/SAN:更新はまとめて行えます。

注意点

TLS終了(SSLオフロード)する場合はロードバランサーで鍵を保持します。パススルーする場合はバックエンドで証明書を扱います。証明書の有効期限管理、チェーンの正しさ、OCSP/CRL対応を忘れないでください。

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

目次