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 データに適用されます。
サーバー ハンドシェイク: 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 などの複数の条件を組み合わせて、非常に具体的なセキュリティ ルールを作成します。
スケーラブルなポリシー アーキテクチャ:
専用ポリシー: 厳密な分離のために、一意の TLS インスペクション ポリシーと CA プールを各 Secure Web Proxy ポリシーに割り当てます。
共有ポリシー: 複数のプロキシ ポリシー間で 1 つの TLS 検査構成を共有することで、ポリシー管理を簡素化します。
完全な URI（Uniform Resource Identifier）の可視性: ドメイン名だけでなく、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 サービス、クライアント デバイス間の調整されたプロセスが含まれます。
クライアントの信頼要件
TLS インスペクションは、組織がクライアント デバイス（管理対象のノートパソコン、サーバー、仮想マシン（VM）など）を管理している環境向けに設計されています。
- プライベート信頼アンカー: 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 プールから 1 つの中間 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 プールを作成するをご覧ください。