Transport Layer Security（TLS）で暗号化されたウェブ トラフィックは、すべてのウェブ トラフィックの大部分を占めています。脅威の行為者は、これらの暗号化されたチャネルを使用して悪意のある攻撃を開始できます。したがって、TLS で暗号化されたトラフィックを宛先に転送する前に確認することが重要です。
Secure Web Proxy には、TLS トラフィックを傍受し、暗号化されたリクエストを検査し、セキュリティ ポリシーを適用できる TLS 検査サービスが用意されています。
実装されたセキュリティ ルールと TLS インスペクションの構成に基づいて、Secure Web Proxy ソリューションは、クライアントと外部サーバーとの 2 つの安全な接続を確立します。次に、Secure Web Proxy ソリューションで、2 つの安全な接続間のトラフィックを検査します。検証が正常に完了すると、暗号化されていないトラフィックに適用するフィルタリングとセキュリティ管理を、暗号化されたトラフィックに適用できます。
TLS インスペクションでの認証局の役割
Secure Web Proxy で TLS 接続を検査する必要があるかどうかを判断するには、個々のセキュリティ ポリシー ルールで tls_inspection_enabled フラグを確認します。フラグが設定され、TLS 接続が検出されると、Secure Web Proxy は新しいサーバー証明書を生成します。この証明書は、下位認証局（CA）プールによって署名されるように、Certificate Authority Service（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 は、ランタイムで生成されたサーバー証明書の署名に使用されます。
外部（CAS 内ではない）に保持されている既存のルート CA を使用して、下位 CA に署名します。下位 CA がルート CA によって署名されている場合は、それを使用して実行時に生成されたサーバー証明書に署名できます。
CAS 内で生成されたルート証明書を使用します。ルート証明書を作成したら、新しいルート CA によって署名された下位 CA を作成します。この下位 CA は、実行時に生成されたサーバー証明書に署名するために使用されます。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[],[],null,["# TLS inspection overview\n\nTransport Layer Security (TLS)-encrypted web traffic accounts for a large\nportion of all web traffic, and threat actors can use these encrypted\nchannels to launch malicious attacks. As a result, it is critical to\ncheck the TLS-encrypted traffic before forwarding it to its destination.\n\nSecure Web Proxy offers a TLS inspection service that lets you intercept the\nTLS traffic, inspect the encrypted request, and enforce security policies.\n\nBased on the implemented security rules and the TLS inspection configuration,\nthe Secure Web Proxy solution establishes two secure connections, one with the\nclient and another with the external server. The Secure Web Proxy solution then\ninspects the traffic between the two secure connections. After successful\nverification, you can apply the same filtering and security controls to encrypted\ntraffic that you do to unencrypted traffic.\n| **Note:** If you want to use [`ApplicationMatcher`](/secure-web-proxy/docs/cel-matcher-language-reference) in your security rules, then you must [enable TLS Inspection](/secure-web-proxy/docs/enable-tls-inspection) for your Secure Web Proxy instance.\n\nRole of certificate authorities in TLS inspection\n-------------------------------------------------\n\nTo determine if the Secure Web Proxy should inspect a TLS connection, it checks\nthe `tls_inspection_enabled` flag on its individual security policy rules. If the\nflag is set, and if a TLS connection is detected, then Secure Web Proxy generates\na new server certificate. It sends this certificate to the Certificate Authority\nService (CAS) to be signed by your subordinate certificate authority (CA) pool.\nThis certificate is then presented to the client, and a TLS connection is\nestablished. The generated certificate is cached for a short time to be used\non subsequent connections to the same host.\n\nIf you want to inspect TLS traffic, you must generate a server certificate for\nthe host that the client is attempting to connect to. An organization-managed,\nprivate CA must sign this server certificate. Only clients configured to trust\nthis private CA trust these generated server certificates. These include\nbrowsers and embedded HTTP clients. As a result, TLS inspection can only be used\nto intercept and inspect TLS connections from clients that your organization\nhas administrative control over.\n\nNot all TLS connections can be successfully intercepted, even on machines over\nwhich the organization has administrative control. This is because some clients\n(particularly those embedded inside other applications) are hardcoded to only\naccept specific server certificates or those signed by specific CAs\n(a practice known as *certificate pinning*). Microsoft Windows, MacOS,\nand Google Chrome software updates are a few examples. Such connections\nfail in the presence of TLS inspection. This happens because the public key\nand the CA chain of the server certificate that Secure Web Proxy presents to\nthe client do not match with the locally stored parameters.\n\nIf a rule is configured to inspect TLS traffic, but the client does not trust the\ninspection certificates that Secure Web Proxy presents, then the connection\nfails. In these cases, TLS inspection is known to break client-server connections\neven if the server is trusted. To work around this situation, you can add rules\nto bypass TLS inspection for specific criteria. You can also restrict TLS\ninspection to specific destination hosts (by using FQDN), sources (by using\nSecure Tags, Service Account, or IP address), and by using the\n[`SessionMatcher` attribute](/secure-web-proxy/docs/cel-matcher-language-reference#available-attributes-in-sessionmatcher-and-applicationmatcher)\nof a rule.\n\nSupported features\n------------------\n\nSecure Web Proxy TLS inspection supports the following features:\n\n- Tight integration with CAS, which is a highly available and scalable repository for private CAs.\n- The ability to use your own root of trust if required. You can also use an existing root CA to sign for subordinate CAs held by CAS. If you prefer, you can generate a new root certificate within CAS.\n- Granular decryption criteria by using `SessionMatcher` within Secure Web Proxy policy rules. This criteria includes matching hosts present in URL lists, regular expressions, IP address ranges, and similar expressions. If required, criteria can be combined with boolean expressions.\n- Each Secure Web Proxy policy can be configured with its own TLS inspection policy and CA pool. Alternatively, multiple Secure Web Proxy policies can share a single TLS inspection policy.\n\nCommon use cases\n----------------\n\nTo enable TLS inspection, you can use any of the following methods:\n\n- Use an existing root CA to sign subordinate CAs held within CAS. A subordinate\n CA held within CAS is used to sign server certificates generated at runtime.\n\n- Use an existing root CA held externally (not in CAS) to sign subordinate CAs.\n When the subordinate CAs are signed by your root CA, you can use them to\n sign server certificates generated at runtime.\n\n- Use a root certificate generated within CAS. After you create the root\n certificate, you create a subordinate CA signed by your new root CA.\n That subordinate CA is used to sign server certificates generated at\n runtime.\n\nFor more information about these methods, see [Create a subordinate CA\npool](/secure-web-proxy/docs/enable-tls-inspection#create-sub-ca-pool)."]]
