オンプレミスとクラウドのTLSインスペクション：導入におけるトレードオフ
- TLSインスペクションでは、トラフィックを復号化し、検査を行い、再暗号化するため、その処理が行われる場所では、一時的に平文が存在することになります。
- ローカルでの検査により、ローカルの平文や鍵を管理できます。クラウド上で提供されるサービスとその処理については、別途評価を行ってください。
- NSAのガイダンスでは、チェーン化されたプロキシを使用せず、企業ネットワーク内で各セッションを1回ずつ検査することを推奨しています。
- 固定されたアプリ、プライバシーに配慮が必要なカテゴリ、および検査中に通信が中断されるトラフィックについて、審査済みの例外リストを管理する。
- RFC 9849として公開された暗号化された「Client Hello」は、受動的な可視性を制限するため、慎重な取り扱いが必要です。
TLSインスペクション（現在でもSSLインスペクションと呼ばれることが多い）とは、TLSセッションを傍受し、企業が信頼する証明書を用いて復号し、内容を検査した後、宛先へ転送する前に再暗号化を行うプロセスです。これがなければ、セキュアWebゲートウェイ、DLPエンジン、サンドボックスは宛先のメタデータしか確認できません。これを利用することで、暗号化されたセッション内でマルウェアを検知し、データの流出を阻止し、利用規定を適用することが可能になります。
問題は「検査を行うかどうか」ではなく、「どこで検査を行うか」です。このガイドでは、復号化パス、証明書の責任範囲、例外処理、ログ記録、運用といった観点から、オンプレミス型とクラウド型のTLS検査を比較しています。
この記事は、「ハイブリッドクラウドのセキュリティ」ガイドの一部です。
TLSインスペクションの仕組み
TLSインスペクションでは、信頼できるプロキシがクライアントの暗号化されたセッションを終了させ、その内容を検査した後、宛先への新しい暗号化されたセッションを開くという仕組みになっています。
プロキシは、クライアントに対してはサーバーとして、宛先に対してはクライアントとして機能します：
- クライアントは、ウェブサイトまたはアプリケーションに対してTLSセッションを開始します。
- プロキシは接続を傍受し、クライアントデバイスが信頼するエンタープライズ検査認証局（CA）によって署名された、宛先用の証明書を提示します。
- プロキシは、実際の宛先に対して独自のTLSセッションを開き、そのサーバーの証明書を検証します。
- 2つのセッション間のトラフィックは復号化され、検査された後、再暗号化されます。
つまり、プロキシは非常に強力な鍵を保持しており、検査対象となるすべてのセッションの平文を処理することになります。NSAの勧告「Transport Layer Security Inspectionによるリスク管理」では、こうした処理が行われる場面を最小限に抑えることを推奨しています。具体的には、企業ネットワーク内で一度だけ検査を行い、複数のフォワードプロキシによる重複した検査を避けることです。CISAが以前発表したHTTPS傍受に関する警告では、実装が不十分な検査製品は、例えばアップストリームの証明書を適切に検証できないなどして、TLSのセキュリティを弱体化させる恐れがあると指摘されていました。
オンプレミスとクラウドのTLS検査の比較概要
オンプレミスでの検査では、平文と鍵はお客様のインフラストラクチャ上に保持されますが、クラウドでの検査では、これらがプロバイダーのPoP（接続拠点）に移されます。
| 因子 | ローカル（オンプレミス）でのTLS検査 | クラウドTLS検査 |
|---|---|---|
| 平文が存在する場所 | お客様のデータセンターまたは支店のアプライアンス | プロバイダーの接続拠点 |
| 検査用CAの秘密鍵を誰が保持しているのか | あなた（必要に応じて、ご自身のHSMを使用しても構いません） | プロバイダー、またはプロバイダーがサポートするキーオプションを介してユーザー自身 |
| こんな方に最適 | 規制対象データ、内部トラフィック、オンサイトユーザー、OT | リモートユーザー、SaaSへの直接トラフィック |
| オンサイトユーザーの遅延 | 現地の処理能力やトラフィックの経路によって異なります | 接続地点までの距離やルーティングによって異なります |
| キャパシティプランニング | ご参考までに、復号処理には多大な計算リソースを要します | プロバイダーの |
| 外部接続への依存 | ローカルでのWebポリシーの適用には不要ですが、データ保護などのクラウド適用サービスでは必須です。 | 必須 |
| ログおよび証拠の保存場所 | ローカルログは設定可能です。クラウドサービスのログについては、そのサービスのストレージポリシーに従います。 | プロバイダー地域（設定による） |
| 運用上の取り組み | ハードウェアのサイジング、パッチ適用、証明書のライフサイクル | 証明書の配布、例外、プロバイダーの設定 |
ほとんどのハイブリッド組織では、特定のオンサイトトラフィックや規制対象のトラフィックに対してはローカルでの検査を、リモートユーザーに対してはクラウドでの検査を併用しています。各パスにわたってTLSターミネーションをマッピングし、ローカルゲートウェイがクラウド適用型サービス向けにトラフィックを転送する場合を含め、冗長な復号化を回避します。
復号パス
すべてのハイブリッド設計では、各TLS終端点および再暗号化点をマッピングし、冗長な検査を回避する必要があります。
一般的なパスには次のようなものがあります：
- Officeユーザーからインターネットへの接続：ローカルゲートウェイ、またはクラウドのPoPへのトンネル接続
- リモートユーザーからインターネットへの接続：クラウドの接続拠点、またはローカルゲートウェイへのバックホール
- ユーザーからプライベートアプリへ：選択したZTNAパスがTLSインスペクションをサポートしているかどうか、およびサポートしている場合はどこでサポートされているかを確認する
- ブラウザセッション：ネットワーク上の復号化を行わずにコンテンツを閲覧できる、ブラウザレベルの制御機能
- エンドポイント：デバイス上でのエージェントベースの検査
ハイブリッド環境におけるリスクの一つは、予期せぬ重複した復号化です。支店では、トラフィックをローカルプロキシを経由させた後、さらにTLSを再度終了させるクラウドサービスを経由させる場合があります。必要な各検査段階を文書化し、各平文境界を保護するとともに、セキュリティリスクを高めたりトラブルシューティングを複雑にしたりする冗長な段階を排除してください。
証明書に関する責任
TLSの検証は、その基盤となる証明書の信頼性次第であるため、証明書のライフサイクルの各段階について、責任の所在を明確に定義してください：
- CAの作成と保護の確認。秘密鍵の保管場所、アクセス権限、およびHSMが必要かどうかを文書化してください。各ローカルゲートウェイまたはクラウドサービス、およびその製品バージョンについて、サポートされているHSM連携を確認してください。サポートされていると勝手に想定しないでください。
- 配布。管理対象デバイスにおいて、CAがオペレーティングシステムおよびブラウザの信頼ストアにどのようにインストールされるか、また、非管理対象デバイスではどのような処理が行われるか。
- ローテーション。停電を伴わずに検査担当CAを交代させるためのスケジュールと手順。
- 上流側の検証。プロキシが、無効、有効期限切れ、または失効した宛先証明書をユーザーから隠蔽するのではなく、確実に拒否することを確認します。
- プロトコルのサポート。TLS 1.3 (RFC 8446) は、ダウングレードすることなく、ネイティブに処理されるべきである。
交通規制の例外
どの組織もすべてのデータを復号化すべきではないため、文書化され、定期的に見直される例外リストを維持してください：
| 例外の種類 | 理由 | 一般的な取り扱い方法 |
|---|---|---|
| 証明書がピン留めされたアプリケーション | 検査により接続が切断されます | 宛先ごとのバイパス；レピュテーションおよびカテゴリに基づく制御を適用する |
| 健康、金融、およびプライベートに関するカテゴリ | 従業員のプライバシー、法的要件および従業員代表機関の要件 | 復号化をバイパスし、カテゴリポリシーを引き続き適用する |
| 相互TLSおよびクライアント証明書による認証 | プロキシはクライアント証明書を提示できません | バイパスするか、サポートされているパススルー機能を使用してください |
| 更新サービスおよび一部のOTプロトコル | 安定性とベンダーによるサポート | アクセスが制限されている宛先によるバイパス |
| QUIC および HTTP/3 (RFC 9000) | 多くのプロキシはQUICを検査できない | QUICをブロックして、ブラウザがTCP上のTLSにフォールバックするようにするか、ネイティブサポートを確認してください |
四半期ごとに例外事項を見直してください。古くなったバイパスは、見落としがちな点です。
暗号化された「Client Hello」とその影響
暗号化された「Client Hello」は、受動的な観察者から宛先のホスト名を隠してしまうため、SNI に基づく可視性や一部のバイパス判断については再考が必要となる。
「Encrypted Client Hello」は2026年にRFC 9849として公開されました。ECHは、従来は宛先のホスト名（サーバー名指示：SNI）やその他のフィールドが露見していたTLSハンドシェイクの一部を暗号化します。SNIを読み取ってトラフィックを分類するパッシブ型ツールは、ECHが有効になっているサイトについては、その情報を把握できなくなります。
TLSを終了させる明示的なプロキシは、宛先との間で独自のセッションを確立するため、状況が異なります。とはいえ、ECHには運用上の影響があります：
- ブラウザは、ECHが使用されていない場合でもECHに類似した拡張情報を送信することがあるため、検査製品ではそれらを適切に処理する必要があります。
- RFCでは、管理された企業環境において、グループポリシーを通じてECHを無効にし、クライアントがその設定を順守することに依存するというアプローチがあることが指摘されています。
- バイパスされたトラフィックについてSNIに依存していたカテゴリ判定やレピュテーション判定については、DNSレイヤーでの制御や明示的なプロキシ設定など、代替手段が必要となります。
検査ベンダーのECHロードマップを確認し、最新のブラウザバージョンでの動作をテストしてください。
ログ記録
検査ログにはURL、ID、DLPの証拠などが含まれる可能性があるため、その内容、保存場所、およびアクセスについては、明確な判断が必要です：
- 復号されたトラフィックとバイパスされたトラフィックについて、どのフィールドがログに記録されるのか
- ログがどこに保存されているか、またそれらが管轄区域外へ持ち出される可能性があるかどうか
- 保存期間、およびコンテンツの証拠資料の全文にアクセスできる者
- どのイベントがSIEMに転送されるか
オンプレミスでの検査であれば、ログや証拠を国内で保管しやすくなります。クラウドでの検査を行う場合は、プロバイダーのログ保存地域やアクセス制御を確認する必要があります。「ハイブリッドクラウドセキュリティにおけるデータ主権」を参照してください。
運用上のトレードオフ
ローカル型検査は制御のために運用上の労力を要し、クラウド型検査は簡便さのために制御を犠牲にし、ハイブリッド型検査では1つのポリシーエンジンで動作する必要があります。
ローカル検査を実施するには、ピーク時の復号処理に対応できるよう機器の容量を確保し、検査エンジンに常に最新のパッチを適用し、ハードウェアまたは仮想リソースの拡張計画を立てる必要があります。その見返りとして、ローカルで検査されるトラフィックに関する平文、鍵、ログを完全に制御できるほか、WANやクラウドの接続が途絶えた場合でも、Webおよびプライベートアプリケーションのポリシーをローカルで継続して適用できます。一方、ベンダーのクラウドで適用されるサービスは、接続が回復するまで一時停止されます。
クラウドインスペクションでは、キャパシティプランニングやエンジンの更新がプロバイダー側に移管されます。それでも、証明書の配布、例外管理、ポリシーの調整は必要であり、プロバイダーの可用性や接続性に依存することになります。
ハイブリッド検査は両方を組み合わせたものですが、1つのポリシーエンジンでのみ適切に機能します。ローカルゲートウェイとクラウドゲートウェイで例外リストやDLPルールが別々になっている場合、ユーザーは場所によって異なる扱いを受けることになります。
Skyhighによるオンプレミスおよびクラウド環境の検査への取り組み
Skyhighは、コンプライアンスで求められている場合はローカル環境で、リモートユーザーの場合はクラウド上で、単一のポリシーに基づいてTLSの検査を行います。
Skyhigh Hybrid SSE Meshは、コンプライアンス要件に応じて組織独自のアプライアンス上でSSL/TLSの復号と検査をローカルに実行し、リモートユーザーに対してはSkyhighクラウドのPoP（接続拠点）で実行します。これら両環境では単一のポリシーエンジンが使用されます。Secure Web Gateway およびZero Trust Accessはゲートウェイ上でネイティブに適用される一方、データ保護ポリシーは、ゲートウェイが転送するトラフィックに対してSkyhighクラウド上で適用されます。 オンプレミスのゲートウェイで復号化されたWebトラフィックは、そこで検査され、ローカルのWebポリシーを適用するために再暗号化されます。データ保護など、クラウドで適用されるサービスを利用するポリシーの場合、ゲートウェイは関連するトラフィックをSkyhighクラウドに転送し、そこで同じポリシーが適用されます。エージェントレス・セキュア・ブラウザ・コントロールは、ブラウザセッション内のAIおよびメッセージングトラフィックに対して、WebSocketに対応した検査機能を追加します。
出典
- NSA. 「トランスポート層セキュリティ（TLS）検査に伴うリスクの管理」（2019年11月）。https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
- CISA. 「HTTPSの傍受はTLSのセキュリティを弱体化させる」（アラート TA17-075A、2017年3月）。https://www.cisa.gov/news-events/alerts/2017/03/16/https-interception-weakens-tls-security
- IETF.RFC 8446: トランスポート層セキュリティ（TLS）プロトコル バージョン 1.3. https://www.rfc-editor.org/rfc/rfc8446.html
- IETF.RFC 9849: TLS 暗号化クライアント・ハロー。 https://www.rfc-editor.org/rfc/rfc9849.html
- IETF.RFC 9000: QUIC: UDP ベースの多重化およびセキュアなトランスポート。 https://www.rfc-editor.org/rfc/rfc9000.html
- Skyhigh Security. 「Skyhigh SSEプラットフォームにより、ハイブリッド環境の導入がさらに容易に」（2024年10月3日）。https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html
- Skyhigh Security. 「Skyhigh Hybrid SSE Mesh による Symantec EdgeSecure Web Gateway の近代化」（2026年7月15日）。https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html