TLS 검사 개요

전송 계층 보안(TLS)으로 암호화된 트래픽은 웹 트래픽의 대부분을 차지합니다. 공격자는 악의적인 활동을 숨기기 위해 이러한 암호화된 채널을 사용하는 경우가 많으므로 이 트래픽이 목적지에 도달하기 전에 검사하는 것이 중요합니다.

Secure Web Proxy는 HTTPS 트래픽을 가로채고 복호화할 수 있는 통합 TLS 검사 서비스를 제공합니다. Secure Web Proxy는 암호화된 요청에 대한 가시성을 확보하여 전체 요청 경로에 대한 URL 필터링 및 HTTP 헤더 검사와 같은 고급 보안 정책을 적용하여 암호화된 터널 내에 숨겨진 위협으로부터 환경을 보호할 수 있습니다.

작동 방식

TLS 검사는 Secure Web Proxy가 보안 중개자 역할을 하는 두 개의 별도 암호화된 연결을 설정하여 작동합니다.

  • 클라이언트 핸드셰이크: 클라이언트가 www.example.com와 같은 외부 사이트에 연결하려고 하면 Secure Web Proxy가 요청을 가로챕니다.

  • 인증서 생성: Secure Web Proxy가 실시간으로 www.example.com의 임시 인증서를 생성합니다. 구성된 인증서 발급 모드에 따라 프록시는 각 도메인의 CA 서비스에서 직접 리프 인증서를 요청하거나 CA 풀의 캐시된 중간 CA 인증서를 사용하여 로컬에서 서명합니다.

  • 신뢰 검증: 클라이언트는 임시 인증서를 수신합니다.

  • 검사 지점: 트래픽이 Secure Web Proxy 인스턴스 내에서 복호화됩니다. 이 단계에서는 보안 정책이 일반 텍스트 HTTP 데이터에 적용됩니다.

  • 서버 핸드셰이크: 그런 다음 Secure Web Proxy는 실제 대상 서버에 대한 두 번째 TLS 연결을 시작합니다. 트래픽이 다시 암호화되어 대상 주소로 전송됩니다.

주요 특징

Secure Web Proxy TLS 검사 서비스는 다음 기능을 통해 암호화된 트래픽을 관리할 수 있는 유연하고 확장 가능한 프레임워크를 제공합니다.

  • 통합 비공개 트러스트: CA Service와의 기본 제공 통합은 비공개 CA를 위한 가용성이 높은 Google 관리형 저장소를 제공합니다.

  • 유연한 신뢰할 수 있는 루트: 기존 온프레미스 루트 인증 기관(CA)을 사용하여 CA Service에서 호스팅되는 하위 CA에 서명합니다. 그런 다음 CA 서비스 내에서 직접 완전히 새로운 루트 인증서를 생성하고 관리할 수 있습니다.

  • 특정 복호화: SessionMatcher를 사용하여 복호화할 트래픽을 정확하게 정의합니다. 다음 파라미터를 기반으로 TLS 검사를 트리거할 수 있습니다.

    • 웹사이트 도메인 이름: 정규 표현식과 도메인 목록을 사용하여 특정 웹사이트를 일치시킵니다.
    • 네트워크 기준: 특정 소스 IP 주소 범위 또는 클래스 없는 도메인 간 라우팅(CIDR) 블록(예: 10.0.0.0/24)을 타겟팅하여 네트워크 경계를 정의합니다.
    • 불리언 로직: 소스 IP 및 도착 URL과 같은 여러 조건을 결합하여 매우 구체적인 보안 규칙을 만듭니다.

  • 확장 가능한 정책 아키텍처:

    • 전용 정책: 엄격한 격리를 위해 각 Secure Web Proxy 정책에 고유한 TLS 검사 정책과 CA 풀을 할당합니다.

    • 공유 정책: 여러 프록시 정책에서 단일 TLS 검사 구성을 공유하여 정책 관리를 간소화합니다.

  • 전체 URI(Uniform Resource Identifier) 공개 상태: 도메인 이름뿐만 아니라 전체 URI(도메인, 경로, 쿼리 문자열(예: www.example.com/downloads/malware.exe) 포함)를 검사합니다.

  • 정확한 액세스 제어: TLS 검사를 사용하여 웹사이트의 특정 경로에 대한 정책을 시행합니다. 예를 들어 www.example.com/documentation에 대한 액세스는 허용하지만 www.example.com/uploads는 차단할 수 있습니다.

  • 중간 CA 지원: CA Service에 도메인별 요청을 직접 실행하는 대신 리프 인증서에 서명하기 위해 단일 중간 CA를 로컬로 캐시하여 CA Service 사용 요금을 줄입니다. 자세한 내용은 인증서 발급 모드를 참조하세요.

TLS 검사에서 인증 기관 역할

암호화된 트래픽을 검사하기 위해 Secure Web Proxy는 신뢰할 수 있는 중개자 역할을 합니다. 여기에는 프록시, CA Service, 클라이언트 기기 간의 조정된 프로세스가 포함됩니다.

클라이언트 신뢰 요구사항

TLS 검사는 조직이 관리형 노트북, 서버, 가상 머신(VM)과 같은 클라이언트 기기에 대한 관리 제어 권한을 가진 환경을 위해 설계되었습니다.

  • 에이전트 컨테이너 트러스트: Cloud Run 또는 Google Kubernetes Engine(GKE)과 같은 컨테이너화된 AI 에이전트에서 아웃바운드 웹 트래픽을 라우팅할 때는 CA 풀 또는 비공개 공개 키 인프라(PKI)에서 루트 CA 인증서를 내보내고 컨테이너의 인증서 트러스트 저장소에 삽입해야 합니다. 예를 들어 컨테이너 런타임을 구성하거나 AGENT_GATEWAY_ROOT_CERTIFICATES 또는 SSL_CERT_FILE 환경 변수를 설정할 수 있습니다. 루트 CA를 구성하는 방법에 관한 자세한 내용은 'Agent Gateway로 Secure Web Proxy 배포'의 TLS 검사 설정을 참조하세요.

  • 비공개 신뢰 앵커: Secure Web Proxy는 공개 CA가 아닌 내부 CA에서 서명한 인증서를 제공하므로 비공개 루트 CA가 사전 설치된 경우에만 클라이언트가 연결을 신뢰합니다.

  • 관리 범위: 관리되지 않는 하드웨어의 연결은 일반적으로 Insecure connection 경고를 트리거합니다. 이러한 기기에는 조직의 특정 신뢰 앵커가 없기 때문입니다.

가로채기 실패 처리

관리 기기에서도 인증서 고정으로 인해 특정 연결을 가로챌 수 없습니다. 인증서 고정은 애플리케이션이 특정 공개 키 또는 특정 공개 CA 체인만 허용하도록 하드코딩된 경우에 발생합니다.

  • 인증서 고정의 예: 고정을 사용하는 일반적인 서비스에는 Windows 및 macOS 시스템 업데이트, 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 Service 비용 절감: CA Service에 대한 요청은 모든 도메인에 대해 발생하는 것이 아니라 중간 CA의 새로고침 주기(일반적으로 하루에 한 번)로 제한되므로 트랜잭션 비용이 절감됩니다.

  • 모니터링 가능성 감소: 프록시가 로컬에서 서명하는 개별 리프 인증서는 CA Service 감사 로그에 기록되지 않습니다.

직접 리프 프로비저닝

certificateIssuanceMode를 DIRECT_LEAF_PROVISIONING로 설정하면 Secure Web Proxy가 각 고유 도메인의 CA Service 풀과 직접 통신하여 리프 인증서를 요청합니다.

직접 리프 프로비저닝 인증서 발급 모드의 기능은 다음과 같습니다.

  • 모니터링 가능성 향상: 생성된 모든 인증서 요청이 CA Service 감사 로그에 기록되므로 모든 인증서 생성 활동을 추적하고 감사할 수 있습니다.

  • CA 서비스 비용 증가: 모든 도메인에 대해 요청이 CA 서비스로 전송되므로 이 프로세스로 인해 고유 도메인 또는 프록시 태스크가 여러 개 있는 환경에서 거래 수수료가 증가할 수 있습니다.

인증 기관 구성 방법

TLS 검사를 사용 설정하려면 다음 방법 중 하나를 사용하여 인증 기관(CA)을 설정합니다.

  • CA Service의 하위 CA: 기존 외부 루트 CA를 사용하여 Google Cloud내에 저장된 하위 CA에 서명합니다.

  • 외부 루트 CA: 외부 루트 CA를 사용하여 하위 CA를 통해 런타임에 생성되는 인증서에 서명합니다.

  • Google 관리형 루트 CA: CA 서비스 내에서 직접 새 루트 인증서를 생성하여 하위 CA에 서명합니다.

이러한 방법에 대한 자세한 내용은 하위 CA 풀 만들기를 참조하세요.

다음 단계