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