Transport Layer Security（TLS）で暗号化されたウェブ トラフィックは、すべてのウェブ トラフィックの大部分を占め、脅威アクターはこれらの暗号化されたチャネルを使用して悪意のある攻撃を開始できます。したがって、TLS で暗号化されたトラフィックを宛先に転送する前に、確認する必要があります。
Secure Web Proxy には、TLS トラフィックを傍受し、暗号化されたリクエストを検査し、セキュリティ ポリシーを適用できる TLS 検査サービスが用意されています。
実装されたセキュリティ ルールと TLS 検査構成に基づいて、Secure Web Proxy ソリューションが 2 つの安全な接続を確立します。1 つはクライアントによる接続で、もう 1 つは外部サーバーによる接続です。次に、Secure Web Proxy ソリューションで、2 つの安全な接続間のトラフィックを検査します。検証が成功すると、暗号化されていないトラフィックに応用されるのと同じフィルタリングとセキュリティ コントロールを、暗号化されたトラフィックに適用できます。
TLS インスペクションでの認証局の役割
Secure Web Proxy で TLS 接続を検査する必要があるかどうかを判断するには、個々のセキュリティ ポリシー ルールで tls_inspection_enabled フラグを確認します。このフラグが設定されていて、TLS 接続が検出されると、Secure Web Proxy が新しいサーバー証明書を生成します。この証明書は、下位認証局（CA）のプールによって署名されるように、認証局（CAS）に送信します。この証明書がクライアントに提示され、TLS 接続が確立されます。生成された証明書は短時間、キャッシュに保存され、同じホストへの後続の接続で使用されます。
TLS トラフィックを検査するには、クライアントが接続しようとしているホストのサーバー証明書を生成する必要があります。組織が管理するプライベート CA は、このサーバー証明書に署名する必要があります。このプライベート CA を信頼するように構成されているクライアントのみが、生成されたサーバー証明書を信頼します。これには、ブラウザと埋め込み HTTP クライアントが含まれます。そのため、TLS 検査は、組織で管理権限のあるクライアントからの TLS 接続をインターセプトして検査するためにのみ使用できます。
組織が管理制御を行うマシンでも、すべての TLS 接続を正常にインターセプトできるわけではありません。これは、一部のクライアント（特に他のアプリケーション内に埋め込まれたクライアント）は、特定のサーバー証明書または特定の CA によって署名されたクライアントのみを受け入れるようにハードコードされているためです（証明書の固定と呼ばれる手法）。Microsoft Windows、MacOS、Google Chrome ソフトウェアの更新例です。このような接続は、TLS 検査が存在する場合は失敗します。これは、Secure Web Proxy がクライアントに提示するサーバー証明書の公開鍵と CA チェーンが、ローカルに保存されているパラメータと一致しないためです。
TLS トラフィックを検査するようにルールが構成されているものの、Secure Web Proxy が提供する検査証明書をクライアントが信頼していない場合、接続は失敗します。この場合、サーバーが信頼されている場合でも、TLS 検査ではクライアント サーバー接続が切断されることがわかっています。この状況を回避するには、特定の基準で TLS 検査をバイパスするルールを追加します。TLS 検査を特定の宛先ホスト（FQDN を使用）、送信元（セキュアタグ、サービス アカウント、または IP アドレスを使用）またはルールのSessionMatcher属性を使用することによって制限することもできます。
サポートされている機能
Secure Web Proxy の TLS 検査は、次の機能をサポートしています。
- 高可用性とスケーラビリティを備えたプライベート CA のリポジトリである CAS との緊密な統合。
- 必要に応じて独自のルート オブ トラストを使用する機能。既存のルート CA を使用して、CAS に保持されている下位 CA に署名することもできます。必要に応じて、CAS 内で新しいルート証明書を生成できます。
- Secure Web Proxy のポリシールール内で
SessionMatcherを使用してきめ細かい復号基準。この条件には、URL リスト、正規表現、IP アドレス範囲などの式で一致するホストが含まれます。必要に応じて、条件をブール式と組み合わせることができます。 - 各 Secure Web Proxy ポリシーは、独自の TLS 検査ポリシーと CA プールを使用して構成できます。また、複数の Secure Web Proxy ポリシーで 1 つの TLS 検査ポリシーを共有することもできます。
一般的なユースケース
TLS 検査を有効にするには、次のいずれかの方法を使用します。
既存のルート CA を使用して、CAS に格納されている保持 CA に署名します。CAS 内に保持されている下位 CA は、実行時に生成されたサーバー証明書に署名するために使用されます。
外部 CA（CAS ではない）に保持されている既存のルート CA を使用して、下位 CA に署名します。下位 CA がルート CA によって署名されている場合、それらを使用して実行時に生成されたサーバー証明書に署名できます。
CAS 内で生成されたルート証明書を使用します。ルート証明書を作成したら、新しいルート CA によって署名された下位 CA を作成します。下位 CA は、実行時に生成されたサーバー証明書に署名するために使用されます。
これらのメソッドの詳細については、下位 CA プールの作成をご覧ください。