Transport Layer Security（TLS）で暗号化されたトラフィックは、ウェブ トラフィックの大部分を占めています。脅威アクターは、多くの場合、これらの暗号化されたチャネルを使用して悪意のあるアクティビティを隠蔽するため、このトラフィックが宛先に到達する前に検査することが重要です。
Secure Web Proxy には、HTTPS トラフィックをインターセプトして復号できる統合 TLS インスペクション サービスが用意されています。暗号化されたリクエストを可視化することで、Secure Web Proxy は、暗号化されたトンネルに隠された脅威から環境を保護するために、リクエスト パス全体の URL フィルタリングや HTTP ヘッダー検査などの高度なセキュリティ ポリシーを適用できます。
仕組み
TLS インスペクションは、2 つの別々の暗号化された接続を確立することで機能します。Secure Web Proxy は安全な仲介役として機能します。
クライアント ハンドシェイク: クライアントが
www.example.comなどの外部サイトに接続しようとすると、Secure Web Proxy がリクエストをインターセプトします。証明書の生成: Secure Web Proxy はプライベート Certificate Authority Service（CA Service）と通信します。プロキシは、組織のプライベート サブ CA によって署名された
www.example.comの一時証明書をリアルタイムで生成します。信頼の検証: クライアントは一時証明書を受け取ります。
検査ポイント: トラフィックは Secure Web Proxy インスタンス内で復号されます。この段階で、セキュリティ ポリシーがプレーン テキストの HTTP データに適用されます。
サーバー ハンドシェイク: Secure Web Proxy は、実際の宛先サーバーへの 2 番目の TLS 接続を開始します。トラフィックは再暗号化され、宛先アドレスに送信されます。
主な機能
Secure Web Proxy の TLS インスペクション サービスは、次の機能を通じて暗号化されたトラフィックを管理するための柔軟でスケーラブルなフレームワークを提供します。
統合されたプライベート トラスト: CA Service との組み込み統合により、プライベート CA 用の高可用性の Google マネージド リポジトリが提供されます。
柔軟な信頼のルート: 既存のオンプレミス ルート認証局（CA）を使用して、CA Service でホストされている下位 CA に署名します。その後、CA Service 内で完全に新しいルート証明書を直接生成して管理できます。
特定の復号:
SessionMatcherを使用して、復号するトラフィックを正確に定義します。次のパラメータに基づいて TLS インスペクションをトリガーできます。- ウェブサイトのドメイン名: 正規表現とドメイン リストを使用して特定のウェブサイトを照合します。
- ネットワーク条件: 特定の送信元 IP アドレス範囲またはクラスレス ドメイン間ルーティング（CIDR）ブロック（
10.0.0.0/24など）をターゲットにして、ネットワーク境界を定義します。 - ブール論理: 送信元 IP や宛先 URL などの複数の条件を組み合わせて、非常に具体的なセキュリティ ルールを作成します。
スケーラブルなポリシー アーキテクチャ:
専用ポリシー: 厳格な分離のために、各 Secure Web Proxy ポリシーに一意の TLS インスペクション ポリシーと CA プールを割り当てます。
共有ポリシー: 複数のプロキシ ポリシー間で 1 つの TLS インスペクション構成を共有することで、ポリシー管理を簡素化します。
完全な Uniform Resource Identifier（URI）の可視性: ドメイン名だけでなく、URI 全体（ドメイン、パス、クエリ文字列など、
www.example.com/downloads/malware.exe）を検査します。正確なアクセス制御: TLS インスペクションを使用して、ウェブサイトの特定のパスにポリシーを適用します。たとえば、
www.example.com/documentationへのアクセスは許可するが、www.example.com/uploadsはブロックすることができます。
TLS インスペクションでの認証局の役割
暗号化されたトラフィックを検査するために、Secure Web Proxy は信頼できる仲介者として機能します。これには、プロキシ、CA サービス、クライアント デバイス間の調整されたプロセスが含まれます。
クライアントの信頼要件
TLS インスペクションは、組織がクライアント デバイス（管理対象のノートパソコン、サーバー、仮想マシン（VM）など）を管理している環境向けに設計されています。
- プライベート信頼アンカー: Secure Web Proxy は、公開 CA ではなく内部 CA によって署名された証明書を提示するため、プライベート ルート CA がプリインストールされている場合にのみ、クライアントは接続を信頼します。
- 管理スコープ: 管理対象外のハードウェアからの接続は、通常、
Insecure connection警告をトリガーします。これは、これらのデバイスに組織固有の信頼アンカーがないためです。
インターセプトの失敗を処理する
管理対象デバイスでも、証明書のピン留めにより、特定の接続をインターセプトできないことがあります。証明書のピン留めは、特定の公開鍵または特定の公開 CA チェーンのみを受け入れるようにアプリがハードコードされている場合に発生します。
- 証明書ピン留めの例: ピン留めを使用する一般的なサービスには、Windows と macOS のシステム アップデート、Google Chrome のアップデート、特定の高セキュリティ モバイル アプリケーションなどがあります。
- 証明書のピン留めの結果: Secure Web Proxy が署名付き証明書を提示すると、アプリケーションは証明書がハードコードされた期待値と一致しないことを検出し、接続を終了します。
緩和策と正確な制御
ピン留めされたアプリケーションのサービス中断を防ぐため、または機密性の高いウェブサイトのプライバシーを保護するために、SessionMatcher 属性を使用して検査をバイパスできます。次のパラメータに基づいて、検査を制限またはスキップできます。
- 宛先属性: 特定の完全修飾ドメイン名（FQDN）。
- 送信元属性: セキュアタグ、サービス アカウント、または IP アドレス。
- カスタム ロジック: ブール式を使用して、環境の残りの部分を検査しながら、特定のトラフィックを除外します。
認証局の構成方法
TLS インスペクションを有効にするには、次のいずれかの方法で認証局（CA）を設定します。
CA Service の下位 CA: 既存の外部ルート CA を使用して、 Google Cloud内に保存されている下位 CA に署名します。
外部ルート CA: 外部ルート CA を使用して、下位 CA を介して実行時に生成される証明書に署名します。
Google マネージド ルート CA: CA Service 内で新しいルート証明書を直接生成して、下位 CA に署名します。
これらの方法の詳細については、下位 CA プールを作成するをご覧ください。