クラウド環境でもオンプレミス環境でも大規模なWebアプリケーションを構築・運用する際にはロードバランサー（負荷分散装置）の導入が欠かせません。特に企業間での情報のやり取りに用いられるB2B向けアプリケーションにおいてセキュリティ要件が高まる中で、mTLS（相互TLS）を用いた通信の保護が求められるケースも増えています。

※mTLSの基本的な仕組みを知りたい方は、まずこちらの記事をご参照ください。

しかし、ロードバランサーを挟んだ構成でmTLSを導入する際には「クライアント証明書の検証はどこで行うのか？」「オリジンサーバーに証明書情報をどう渡すのか？」といった疑問がよく寄せられます。

この記事ではそうした疑問に答えるべく、mTLSの検証ポイントやオリジンサーバーへの証明書情報の渡しかたについて紹介します。

ロードバランサーの役割の違い

ロードバランサーには主に2種類あります。

L4ロードバランサー

TCP/IPレベルで動作し、TLSの終端は行わず、通ってきた通信を目的のオリジンサーバーに切り替えるしくみです。例えると、出発した列車を目的の線路へ切り替える転車台のような働きをします。 TLS通信はクライアントからそのままオリジンサーバーまで届くため、クライアント証明書の検証はオリジンサーバー側で行われます。

L7ロードバランサー

HTTPレベルで動作し、リバースプロキシとして機能します。 訪問者（クライアント）からのリクエストを受付係として一旦受け取り、内容を確認してから代わりに目的地（オリジンサーバー）へ届けます。 つまり、L4ロードバランサーとは異なり、クライアントとのTLS通信は受付（ロードバランサー）でいったん終端されるということになります。そのため、クライアントとロードバランサー間だけではなく、ロードバランサーとオリジンサーバ間も別途、TLSによる暗号化通信を行うことがセキュリティのベストプラクティスになります。

現在のクラウド環境では、L7ロードバランサーが主流です。 その理由は以下の通りです。

• ●ルーティングの柔軟性：URLパスやHTTPヘッダー、クエリパラメータなどに基づいて、きめ細かいルールでリクエストを振り分け可能。
• ●セキュリティ強化：WAF（Web Application Firewall）やレート制限、IPフィルタリングなどのセキュリティ機能を統合しやすい。
• ●監視とトレーシング：リクエストのログやメトリクスを収集しやすく、可観測性の向上に貢献。

 

これらのメリットから、mTLSのような高度な認証を実装するシステムにおいては、多くのケースでL7ロードバランサーが選択されていると想定されます。

 

mTLSにおけるクライアント証明書の検証（正当性確認）はどこで行われる？

mTLSでは、クライアントが証明書を提示しサーバがそれを検証します。

L7ロードバランサーを使う場合、TLSセッションはロードバランサーで終端されるため、クライアント証明書の検証もロードバランサー側で行われます。オリジンサーバーでもそれを行う必要はないため、オリジンサーバーの負荷軽減、認証ポリシーの一括管理が可能となるメリットがあります。また、 クライアント証明書の失効確認設定（CRLダウンロードやOCSP）もmTLSの処理の一部としてロードバランサーでおこないます。
※なお、失効確認をどのように実装しているかは、ロードバランサー製品・サービスによって異なるので、サービスごとでの確認が必要です。

このように、オリジンサーバーはクライアントとのTLSセッションをおこなっているわけではないため、証明書の情報を直接取得することはできません。そのため、ロードバランサーがクライアント証明書の情報をHTTPヘッダーに追加して、オリジンサーバーに渡す流れが一般的です。

オリジンサーバーが受け取る情報の形式は、ロードバランサーの実装によって主に2つのパターンがあります。

証明書全体を渡す形式

クライアント証明書そのものが、テキスト形式（PEM形式）でエンコードされて単一のHTTPヘッダーに格納されます。この場合、オリジンサーバーのアプリケーションは、ヘッダーの値から証明書内容をデコードし、その内容（サブジェクト、シリアル番号、有効期限など）を解析する必要があります。

証明書の特定の情報を抽出して渡す形式

ロードバランサーが証明書を解析し、サブジェクトのDN（Distinguished Name）やシリアル番号といった、よく使われる情報だけを個別のヘッダーに格納して渡す形式です。この場合、オリジンサーバーのアプリケーション側の処理は簡潔になります。

どちらの形式が使われるかは利用するロードバランサーの仕様に依存するため、アプリケーションを実装する際には、まずその仕様を確認することが不可欠です。

オリジンサーバーは、ロードバランサーから渡されたHTTPヘッダーを参照してクライアント証明書に基づいた処理を行えます。 これにより、例えば、グローバルサインのクライアント証明書管理サービス「マネージドPKI Lite byGMO」での専用BaseDN（企業独自に設定したサブジェクトO/OU）に基づいたアクセス制限をおこなったり、証明書のシリアル番号を取得して詳細なアクセスログを残すなど、アクセスの許可/拒否以上の処理を行うことが可能となります。

セキュリティ上の注意点として、オリジンサーバーはこれらのヘッダーが改ざんされていないことを保証する必要があります。一般的には、上記の通りバランサーとの通信をTLS化したり、ロードバランサーからのリクエストのみをオリジンサーバーでは許可するようにネットワーク制御を行うことで、攻撃者がロードバランサーを迂回して偽のヘッダーを持つリクエストをオリジンサーバーに直接送信することを防ぎます。

まとめ

mTLSの導入は、単なるセキュリティ強化にとどまらず、企業システム全体の信頼性と統制力を高める鍵です。ロードバランサーの役割を正しく理解し、「どこで証明書を検証し、どう安全にオリジンサーバーへ情報を渡すか」を明確にすることで、運用負荷を抑えつつ堅牢な通信基盤を構築できます。特にL7ロードバランサーを採用する環境では、TLS終端とクライアント証明書検証を集約することで、認証ポリシーの一元管理と可視化が可能になります。さらに、証明書情報をHTTPヘッダーで連携する構成を適切に設計すれば、既存アプリケーションとの連携もスムーズです。

まずは自社のロードバランサーで、mTLS対応機能やヘッダー連携仕様を確認してみてください。検証環境で試すだけでも、設計上のポイントや制約が具体的に見えてきます。なお、グローバルサインの「マネージドPKI Lite byGMO」では、検証時に使えるテスト用の証明書を提供しておりますので、お気軽にお問い合わせください。

自社のロードバランサー環境でmTLSを検討し、ゼロトラスト時代に対応する堅牢な通信設計を始めましょう。