전송 계층 보안(TLS)으로 암호화된 웹 트래픽은 모든 웹 트래픽의 상당 부분을 차지하며, 위협자는 이러한 암호화된 채널을 사용하여 악의적인 공격을 시작할 수 있습니다. 따라서 TLS로 암호화된 트래픽을 대상으로 전달하기 전에 이 트래픽을 확인하는 것이 중요합니다.
보안 웹 프록시는 TLS 트래픽을 가로채고, 암호화된 요청을 검사하며, 보안 정책을 시행할 수 있는 TLS 검사 서비스를 제공합니다.
구현된 보안 규칙과 TLS 검사 구성에 따라 보안 웹 프록시 솔루션은 클라이언트와의 보안 연결 1개와 외부 서버와의 보안 연결 1개를 설정합니다. 그러면 보안 웹 프록시 솔루션이 두 보안 연결 간의 트래픽을 검사합니다. 확인에 성공하면 암호화되지 않은 트래픽과 동일한 방식으로 암호화된 트래픽에 필터링 및 보안 제어를 적용할 수 있습니다.
TLS 검사에서 인증 기관 역할
보안 웹 프록시에서 TLS 연결을 검사해야 하는지 확인하기 위해 개별 보안 정책 규칙에서 tls_inspection_enabled 플래그를 확인합니다. 플래그가 설정되어 있고 TLS 연결이 감지되면 보안 웹 프록시에서 새 서버 인증서를 생성합니다. 하위 인증 기관(CA) 풀에서 서명하도록 이 인증서를 Certificate Authority Service(CAS)로 보냅니다.
그런 다음 이 인증서가 클라이언트에 제공되고 TLS 연결이 설정됩니다. 생성된 인증서는 같은 호스트에 대한 이후 연결에 사용하기 위해 잠시 동안 캐시됩니다.
TLS 트래픽을 검사하려면 클라이언트가 연결하려는 호스트의 서버 인증서를 생성해야 합니다. 조직에서 관리하는 비공개 CA가 이 서버 인증서에 서명해야 합니다. 이 비공개 CA를 신뢰하도록 구성된 클라이언트만 생성된 서버 인증서를 신뢰합니다. 여기에는 브라우저와 삽입된 HTTP 클라이언트가 포함됩니다. 따라서 TLS 검사는 조직에서 관리하는 클라이언트의 TLS 연결을 가로채고 검사하는 데만 사용할 수 있습니다.
조직에서 관리 권한을 보유한 머신에서도 일부 TLS 연결은 가로채지 못할 수 있습니다. 이는 일부 클라이언트(특히 다른 애플리케이션 내에 삽입된 클라이언트)가 특정 서버 인증서 또는 특정 CA에서 서명한 인증서만 수락하도록 하드코딩되기 때문입니다(인증서 고정이라고 함). 여기에는 Microsoft Windows, MacOS, Chrome 소프트웨어 업데이트가 포함됩니다. 이러한 연결은 TLS 검사가 있는 경우 실패합니다. 이는 보안 웹 프록시가 클라이언트에 제공하는 서버 인증서의 공개 키와 CA 체인이 로컬에 저장된 매개변수와 일치하지 않기 때문에 발생합니다.
규칙이 TLS 트래픽을 검사하도록 구성되었지만 클라이언트가 보안 웹 프록시에서 제공하는 검사 인증서를 신뢰하지 않으면 연결이 실패합니다. 이러한 경우 TLS 검사는 서버가 신뢰할 수 있는 경우에도 클라이언트-서버 연결을 중단하는 것으로 알려져 있습니다. 이 문제를 해결하려면 특정 기준에 대해 TLS 검사를 우회하는 규칙을 추가하면 됩니다. 또한 규칙의 SessionMatcher 속성을 사용하여 특정 대상 호스트(FQDN 사용), 소스(보안 태그, 서비스 계정 또는 IP 주소 사용)에 대한 TLS 검사를 제한할 수 있습니다.
지원되는 기능
보안 웹 프록시 TLS 검사는 다음 기능을 지원합니다.
비공개 CA를 위한 가용성이 높고 확장 가능한 저장소인 CAS와의 긴밀한 통합
필요한 경우 자체 신뢰할 수 있는 루트 사용. 기존 루트 CA를 사용하여 CAS에 있는 하위 CA에 서명할 수도 있습니다. 원하는 경우 CAS 내에서 새 루트 인증서를 생성할 수 있습니다.
보안 웹 프록시 정책 규칙 내에서 SessionMatcher를 사용한 상세 복호화 기준. 이 기준에는 URL 목록, 정규 표현식, IP 주소 범위, 유사 표현식에 있는 일치하는 호스트가 포함됩니다. 필요한 경우 불리언 표현식과 기준을 결합할 수 있습니다.
각 보안 웹 프록시 정책은 자체 TLS 검사 정책 및 CA 풀로 구성할 수 있습니다. 또는 여러 보안 웹 프록시 정책에서 단일 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)."]]
