ENGINEERS' COLUMN

SSLi（SSL Inspection、SSL可視化）とは

SSLiは、暗号化されているHTTPS通信を一度復号し、HTTPとして可視化する技術です。これにより、通信内容を内部で確認し、マルウェア検査や不審なアクセスの検知を行うことが可能になります。

本コラムでは、SSLiの基本動作と、実際の運用において注意すべきポイントについてご紹介します。

SSLiの動作概要

1. SSLiでは、HTTP（S）のプロキシ接続を利用します。一般的に、内部側（SSL Inside）にプロキシサーバやADCなどのプロキシ機能を備えた機器を配置し、クライアントはこれらをブラウザにプロキシとして設定します。
2. SSL Inside 機器はクライアントの代わりにSSL ServerとSSL接続を行い、必要に応じてFQDN（注1）のホスト名解決も実施します。SSLハンドシェイク完了後、内部処理のため一度接続をリセットし、内部CA局（注2）によって発行した証明書をクライアントへ提示することでHTTPS接続を確立します。
3. SSLハンドシェイク完了後、内部処理のため一度接続をリセット（注3）し、内部CA局によって発行した証明書をクライアントへ提示することでHTTPS接続を確立します。

この仕組みにより、SSL Inside機器はクライアントの暗号化通信を復号して確認でき、必要なセキュリティ処理を施したうえで、外部へ送信する際には再度SSL暗号化が行われます。

運用時に生じやすい課題

SSLiはセキュリティ強化に有用な一方、多段の通信処理を行うため、トラブル発生時に調査範囲が広くなる傾向があります。

• 解析すべきポイントが多い
• 通信経路が複雑化しやすい
• プロキシ設定や証明書設定が影響しやすい

といった特徴があります。
以下では、実際の運用で見られた代表的な事例をご紹介します。

さまざまな構成パターン

SSLiの基本構成に加え、プロキシが複数段となるケースや、Microsoft 365では一部ワークロードやエンドポイントでTLSインスペクション／認証プロキシの適用が非推奨となる場合があります（出典1）。そのようなプロキシ経由に適さない通信では、別の接続フローが用いられる場合があります。このような環境では、障害調査のためにパケットキャプチャを取得するポイントが多数発生し、最大で①から⑫までの12カ所に及ぶケースもあります。また、NATや複数のセキュリティ機器が挟まる場合、調査の難易度は高くなります。

障害事例 1：DNSに関する問題

SSLi環境では、プロキシがDNS問い合わせを行うケースが多くなり、DNSの疎通性が特に重要になります。

SSL Inside機器がDNSリクエストに同じ送信元ポートを使用し続けた結果、途中のセキュリティ機器で通信がブロックされる事例が確認されています。このような場合には、送信元ポートのランダム化などの対策が有効です。原因特定にはDNSサーバだけでなく、関連するネットワーク機器を含めたパケットキャプチャが必要になります。

障害事例 2：SSL/TLS証明書に関する問題

SSLiを用いる場合、途中機器がSSL/TLS接続を中継するために必要な内部CA局が発行したRoot CA証明書（注4）をクライアントに登録する必要があります。新しい端末を導入した際に登録を失念して接続エラーが発生するケースがよく見られます。また、証明書の有効期限切れによりSSLiが正常に動作しなくなることもあるため、証明書管理は定期的な確認が重要です。
さらに、Cert Fetch（注5）機能が関係するケースでは、証明書情報取得のためのセッションと通常のSSLリクエストが同一ポートを利用することで、セキュリティ機器により通信が遮断されることがあります。

その際は、以下のような対処が有効です：

• Cert Fetch 用セッションをバイパスする
• 送信元ポートをランダム化する
• セキュリティ機器側で通過設定を行う