전송 계층 보안 (TLS)으로 암호화된 트래픽은 웹 트래픽의 대부분을 차지합니다. 공격자는 이러한 암호화된 채널을 사용하여 악의적인 활동을 숨기는 경우가 많으므로 트래픽이 대상에 도달하기 전에 검사하는 것이 중요합니다.
Secure Web Proxy는 HTTPS 트래픽을 가로채고 복호화할 수 있는 통합 TLS 검사 서비스를 제공합니다. 보안 웹 프록시는 암호화된 요청을 파악하여 전체 요청 경로의 URL 필터링 및 HTTP 헤더 검사와 같은 고급 보안 정책을 적용하여 암호화된 터널 내에 숨겨진 위협으로부터 환경을 보호할 수 있습니다.
작동 방식
TLS 검사는 Secure Web Proxy가 보안 중개자 역할을 하는 두 개의 별도 암호화된 연결을 설정하여 작동합니다.
클라이언트 핸드셰이크: 클라이언트가
www.example.com과 같은 외부 사이트에 연결하려고 하면 보안 웹 프록시가 요청을 가로챕니다.인증서 생성: Secure Web Proxy는 임시 인증서를
www.example.com실시간으로 생성합니다. 구성된 인증서 발급 모드에 따라 프록시는 각 도메인의 CA 서비스에서 리프 인증서를 직접 요청하거나 CA 풀의 캐시된 중간 CA 인증서를 사용하여 로컬에서 서명합니다.트러스트 검증: 클라이언트는 임시 인증서를 수신합니다.
검사 지점: 트래픽은 Secure Web Proxy 인스턴스 내에서 복호화됩니다. 이 단계에서는 보안 정책이 일반 텍스트 HTTP 데이터에 적용됩니다.
서버 핸드셰이크: Secure Web Proxy는 실제 대상 서버에 대한 두 번째 TLS 연결을 시작합니다. 트래픽은 다시 암호화되어 대상 주소로 전송됩니다.
주요 특징
Secure Web Proxy TLS 검사 서비스는 다음과 같은 기능을 통해 암호화된 트래픽을 관리하기 위한 유연하고 확장 가능한 프레임워크를 제공합니다.
통합 비공개 트러스트: CA 서비스와의 기본 제공 통합 은 비공개 CA를 위한 Google 관리형 고가용성 저장소를 제공합니다.
유연한 트러스트 루트: 기존 온프레미스 루트 인증서 기관 (CA)을 사용하여 CA 서비스에서 호스팅되는 하위 CA에 서명합니다. 그런 다음 CA 서비스 내에서 완전히 새로운 루트 인증서를 직접 생성하고 관리할 수 있습니다.
특정 복호화:
SessionMatcher복호화할 트래픽을 정확하게 정의하는 데 사용합니다. 다음 매개변수를 기반으로 TLS 검사를 트리거할 수 있습니다.- 웹사이트 도메인 이름: 정규 표현식 및 도메인 목록을 사용하여 특정 웹사이트를 일치시킵니다.
- 네트워크 기준:
10.0.0.0/24와 같은 특정 소스 IP 주소 범위 또는 클래스 없는 도메인 간 라우팅 (CIDR) 블록을 타겟팅하여 네트워크 경계를 정의합니다. - 불리언 로직: 소스 IP 및 도착 URL과 같은 여러 조건을 결합하여 매우 구체적인 보안 규칙을 만듭니다.
확장 가능한 정책 아키텍처:
전용 정책: 엄격한 격리를 위해 각 Secure Web Proxy 정책에 고유한 TLS 검사 정책 및 CA 풀을 할당합니다.
공유 정책: 여러 프록시 정책에서 단일 TLS 검사 구성을 공유하여 정책 관리를 간소화합니다.
전체 URI (Uniform Resource Identifier) 가시성: 도메인 이름뿐만 아니라 도메인, 경로, 쿼리 문자열( 예:
www.example.com/downloads/malware.exe)을 포함한 전체 URI를 검사합니다.정확한 액세스 제어: TLS 검사를 사용하여 웹사이트의 특정 경로에 대한 정책을 적용합니다. 예를 들어
www.example.com/documentation에 대한 액세스를 허용하지만www.example.com/uploads는 차단할 수 있습니다.중간 CA 지원: 도메인별 요청을 CA 서비스에 직접 발급하는 대신 단일 중간 CA를 로컬에 캐시하여 리프 인증서에 서명함으로써 CA 서비스 사용료를 줄입니다. 자세한 내용은 인증서 발급 모드를 참조하세요.
TLS 검사에서 인증 기관 역할
암호화된 트래픽을 검사하기 위해 Secure Web Proxy는 신뢰할 수 있는 중개자 역할을 합니다. 여기에는 프록시, CA 서비스, 클라이언트 기기 간의 조정된 프로세스가 포함됩니다.
클라이언트 트러스트 요구사항
TLS 검사는 조직에서 관리형 노트북, 서버 또는 가상 머신 (VM)과 같은 클라이언트 기기를 관리할 수 있는 환경을 위해 설계되었습니다.
- 비공개 트러스트 앵커: Secure Web Proxy는 Public CA가 아닌 내부 CA에서 서명한 인증서를 제공하므로 클라이언트는 비공개 루트 CA가 사전 설치된 경우에만 연결을 신뢰합니다.
- 관리 범위: 관리되지 않는 하드웨어의 연결은 일반적으로
Insecure connection경고를 트리거합니다. 이러한 기기에 조직의 특정 트러스트 앵커가 없기 때문입니다.
가로채기 실패 처리
관리형 기기에서도 인증서 고정 으로 인해 특정 연결을 가로챌 수 없습니다. 인증서 고정은 애플리케이션이 특정 공개 키 또는 특정 공개 CA 체인만 수락하도록 하드코딩될 때 발생합니다.
- 인증서 고정 예: 고정을 사용하는 일반적인 서비스에는 Windows 및 macOS 시스템 업데이트, Google Chrome 업데이트, 특정 보안 수준이 높은 모바일 애플리케이션이 포함됩니다.
- 인증서 고정 결과: Secure Web Proxy가 서명된 인증서를 제공하면 애플리케이션은 인증서가 하드코딩된 예상과 일치하지 않는 것을 감지하고 연결을 종료합니다.
완화 및 정확한 제어
고정된 애플리케이션의 서비스 중단을 방지하거나 민감한 웹사이트의 개인 정보 보호를 유지하려면 SessionMatcher 속성을 사용하여 검사를 우회할 수 있습니다. 다음 매개변수를 기반으로 검사를 제한하거나 건너뛸 수 있습니다.
- 대상 속성: 특정 정규화된 도메인 이름 (FQDN).
- 소스 속성: 보안 태그, 서비스 계정 또는 IP 주소.
- 커스텀 로직: 불리언 표현식을 사용하여 나머지 환경을 검사하는 동안 특정 트래픽을 제외합니다.
인증서 발급 모드
Secure Web Proxy는 TLS 검사 프로세스 중에 트래픽을 복호화하는 데 사용하는 인증서를 프로비저닝하는 두 가지 모드를 지원합니다. 선택은 비용, 성능, 감사 로깅 요구사항에 따라 다릅니다.
자세한 내용은 로컬 중간 CA 서명 구성을 참조하세요.
로컬 중간 CA 서명
certificateIssuanceMode를 LOCAL_INTERMEDIATE_CA_SIGNING으로 설정하면 Secure Web Proxy가 CA 풀에서 단일 중간 CA 인증서를 요청합니다. 프록시는 이 중간 CA를 캐시하고 필요한 도메인의 개별 리프 인증서에 로컬로 서명합니다.
로컬 중간 CA 서명 인증서 발급 모드의 기능은 다음과 같습니다.
CA 서비스 비용 절감: CA 서비스에 대한 요청은 모든 도메인에서 발생하는 것이 아니라 중간 CA의 새로고침 주기 (일반적으로 하루에 한 번)로 제한되므로 거래 비용이 절감됩니다.
관찰 가능성 감소: 프록시가 로컬에서 서명하는 개별 리프 인증서는 CA 서비스 감사 로그에 기록되지 않습니다.
직접 리프 프로비저닝
certificateIssuanceMode를 DIRECT_LEAF_PROVISIONING으로 설정하면 Secure Web Proxy가 각 고유 도메인에 대해 CA 서비스 풀과 직접 통신하여 리프 인증서를 요청합니다.
직접 리프 프로비저닝 인증서 발급 모드의 기능은 다음과 같습니다.
관찰 가능성 향상: 생성된 모든 인증서 요청은 CA 서비스 감사 로그에 기록되므로 모든 인증서 생성 활동을 추적하고 감사할 수 있습니다.
CA 서비스 비용 증가: 모든 도메인에 대해 CA 서비스로 요청이 전송되므로 이 프로세스는 고유한 도메인 또는 프록시 작업이 여러 개 있는 환경에서 거래 수수료를 높일 수 있습니다.
인증 기관 구성 방법
TLS 검사를 사용 설정하려면 다음 방법 중 하나를 사용하여 인증 기관 (CA)을 설정합니다.
CA 서비스의 하위 CA: 기존 외부 루트 CA를 사용하여 내에 저장된 하위 CA에 서명합니다 Google Cloud.
외부 루트 CA: 외부 루트 CA를 사용하여 하위 CA를 통해 런타임에 생성되는 인증서에 서명합니다.
Google 관리형 루트 CA: CA 서비스 내에서 직접 새 루트 인증서를 생성하여 하위 CA에 서명합니다.
이러한 방법에 대한 자세한 내용은 하위 CA 풀 만들기를 참조하세요.