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 は、
www.example.comの一時証明書をリアルタイムで生成します。構成された証明書発行モードに応じて、プロキシは各ドメインのリーフ証明書を CA Service に直接リクエストするか、CA プールのキャッシュに保存された中間 CA 証明書を使用してローカルで署名します。信頼検証: クライアントは、その一時的な証明書を受け取ります。
検査ポイント: トラフィックは Secure Web Proxy インスタンス内で復号されます。この段階で、セキュリティ ポリシーが書式なしテキストの HTTP データに適用されます。
サーバー handshake: 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をブロックできます。中間 CA のサポート: ドメインごとのリクエストを CA Service に直接発行するのではなく、単一の中間 CA をローカルにキャッシュしてリーフ証明書に署名することで、CA Service の使用料金を削減します。詳細については、証明書の発行モードをご覧ください。
TLS インスペクションでの認証局の役割
暗号化されたトラフィックを検査するために、Secure Web Proxy は信頼できる仲介者として機能します。これには、プロキシ、CA Service、クライアント デバイス間の調整プロセスが含まれます。
クライアントの信頼要件
TLS インスペクションは、組織がクライアント デバイス（管理対象のノートパソコン、サーバー、仮想マシン（VM）など）を管理している環境向けに設計されています。
エージェント コンテナの信頼: Cloud Run や Google Kubernetes Engine（GKE）などのコンテナ化された AI エージェントから送信ウェブ トラフィックをルーティングする場合は、CA プールまたはプライベート公開鍵基盤（PKI）からルート CA 証明書をエクスポートし、コンテナの証明書トラストストアに挿入する必要があります。たとえば、コンテナ ランタイムを構成するか、
AGENT_GATEWAY_ROOT_CERTIFICATESまたはSSL_CERT_FILE環境変数を設定します。ルート CA の構成方法については、「Secure Web Proxy を Agent Gateway としてデプロイする」の TLS 検査を設定するをご覧ください。プライベート トラスト アンカー: Secure Web Proxy は、パブリック CA ではなく内部 CA によって署名された証明書を提示するため、クライアントは、プライベート ルート CA がプリインストールされている場合にのみ接続を信頼します。
管理スコープ: 管理対象外のハードウェアからの接続では、通常、
Insecure connection警告がトリガーされます。これは、これらのデバイスに組織固有のトラスト アンカーがないためです。
インターセプトの失敗を処理する
管理対象デバイスであっても、証明書のピン留めにより、特定の接続をインターセプトできない場合があります。証明書のピン留めは、特定の公開鍵または特定の公開 CA チェーンのみを受け入れるようにアプリケーションがハードコードされている場合に発生します。
- 証明書のピン留めの例: ピン留めを使用する一般的なサービスには、Windows と macOS のシステム アップデート、Google Chrome のアップデート、特定の高セキュリティ モバイルアプリなどがあります。
- 証明書のピン留めの結果: Secure Web Proxy が署名付き証明書を提示すると、アプリケーションは証明書がハードコードされた期待値と一致しないことを検出し、接続を終了します。
緩和策と精密な制御
固定されたアプリケーションのサービスの中断を防ぐため、または機密性の高いウェブサイトのプライバシーを維持するために、SessionMatcher 属性を使用して検査をバイパスできます。次のパラメータに基づいて、検査を制限またはスキップできます。
- 宛先属性: 特定の完全修飾ドメイン名（FQDN）。
- ソース属性: セキュアタグ、サービス アカウント、IP アドレス。
- カスタム ロジック: ブール式を使用して、特定のトラフィックを除外し、残りの環境を検査します。
証明書発行モード
Secure Web Proxy は、TLS 検査プロセス中にトラフィックの復号に使用する証明書をプロビジョニングする 2 つのモードをサポートしています。どちらを選択するかは、費用、パフォーマンス、監査ロギングの要件によって異なります。
詳細については、ローカル中間 CA 署名を構成するをご覧ください。
ローカル中間 CA 署名
certificateIssuanceMode を LOCAL_INTERMEDIATE_CA_SIGNING に設定すると、Secure Web Proxy は CA プールから単一の中間 CA 証明書をリクエストします。プロキシはこの中間 CA をキャッシュに保存し、必要なドメインの個々のリーフ証明書にローカルで署名します。
ローカル中間 CA 署名証明書発行モードの機能は次のとおりです。
CA Service のコストの削減: CA Service へのリクエストは、ドメインごとに発生するのではなく、中間 CA の更新サイクル（通常は 1 日 1 回）に制限されるため、トランザクション コストが削減されます。
オブザーバビリティの低下: プロキシがローカルで署名する個々のリーフ証明書は、CA Service の監査ログに記録されません。
直接リーフ プロビジョニング
certificateIssuanceMode を DIRECT_LEAF_PROVISIONING に設定すると、Secure Web Proxy は一意のドメインごとに CA Service プールと直接通信して、リーフ証明書をリクエストします。
直接リーフ プロビジョニング証明書発行モードの機能は次のとおりです。
オブザーバビリティの向上: 生成されたすべての証明書リクエストは CA Service の監査ログに記録されるため、すべての証明書生成アクティビティを追跡して監査できます。
CA Service のコストの増加: リクエストはドメインごとに CA Service に送信されるため、このプロセスにより、複数の固有のドメインまたはプロキシタスクがある環境では、取引手数料が高くなる可能性があります。
認証局の構成方法
TLS インスペクションを有効にするには、次のいずれかの方法で認証局（CA）を設定します。
CA Service の下位 CA: 既存の外部ルート CA を使用して、 Google Cloud内に保存されている下位 CA に署名します。
外部ルート CA: 外部ルート CA を使用して、下位 CA を介して実行時に生成される証明書に署名します。
Google マネージド ルート CA: CA Service 内で新しいルート証明書を直接生成して、下位 CA に署名します。
これらの方法の詳細については、下位 CA プールを作成するをご覧ください。