보안 웹 프록시에서 프런트엔드 상호 TLS (mTLS)를 구성하여 AI 에이전트와 같은 워크로드의 보안을 강화할 수 있습니다. 보안 웹 프록시는 프런트엔드 mTLS를 사용하여 인증서를 통해 클라이언트 ID를 확인합니다.
이 통합을 사용하면 보안 웹 프록시 승인 정책에서 검증된 클라이언트 ID를 사용하여 아웃바운드 트래픽에 대한 세분화된 액세스 제어를 적용할 수 있습니다.
작동 방식
다음 단계에서는 Secure Web Proxy가 프런트엔드 mTLS를 사용하여 아웃바운드 트래픽을 보호하는 방법을 설명합니다.
명시적 프록시 연결: Secure Web Proxy를 명시적 프록시로 사용하도록 클라이언트를 구성할 수 있습니다. 클라이언트는 인터넷에 직접 연결하는 대신 Secure Web Proxy 프런트엔드에 HTTPS CONNECT 요청을 시작합니다.
상호 TLS 핸드셰이크: 연결 설정 중에 Secure Web Proxy와 클라이언트는 프록시 프런트엔드에서 mTLS 핸드셰이크를 실행합니다. 프록시는 구성된
TrustConfig리소스를 사용하여 클라이언트의 인증서를 검증하고 클라이언트는 프록시의 서버 인증서를 검증합니다.ID 추출: 핸드셰이크가 성공하면 Secure Web Proxy가 검증된 클라이언트 인증서에서 직접 고유 ID 속성(예:
URI_SAN)을 추출합니다.ID 기반 승인: Secure Web Proxy는 구성된 승인 정책에 대해 아웃바운드 요청을 평가합니다. 요청이 승인되었는지 확인하기 위해 프록시는 mTLS 핸드셰이크 중에 암호화 방식으로 확인된 클라이언트의 ID를 사용합니다.
아웃바운드 트래픽 보안: 승인이 완료되고 외부 대상에 일치하는 규칙이 있는 경우 Secure Web Proxy가 대상에 대한 요청을 처리합니다.
주요 이점
보안 웹 프록시에서 프런트엔드 mTLS를 구성하면 다음과 같은 보안 및 운영상의 이점이 있습니다.
보안 강화: 모든 아웃바운드 트래픽에 프런트엔드 mTLS 인증을 요구하여 제로 트러스트 액세스를 달성합니다. 이렇게 하면 인증된 ID가 있는 워크로드만 프록시와 연결하여 외부 서비스에 액세스할 수 있습니다.
간소화된 워크로드 구성: Secure Web Proxy에 명시적 프록시 라우팅 모드를 사용하여 요청을 가로채고 인증하는 프록시의 기능을 활용합니다.
세부적인 제어: 세부적인 ID 인식 정책을 적용하여 각 특정 워크로드가 액세스할 수 있는 외부 서비스를 결정합니다.
사용 사례 예: 워크로드의 ID 검증
은행 부문과 같이 규제가 심한 업종에서는 요청의 네트워크 위치를 확인하는 것만으로는 무단 데이터 액세스를 방지하기에 충분하지 않습니다. Secure Web Proxy에서 프런트엔드 mTLS를 구성하면 조직에서 암호화 방식으로 확인된 ID 모델로 전환할 수 있습니다. 이를 통해 가상 머신 (VM) 인스턴스든 AI 에이전트든 모든 워크로드가 신뢰할 수 있는 인증서를 사용하여 특정 ID를 증명해야 합니다.
이 접근 방식을 사용하면 관리자가 민감한 아웃바운드 경로를 보호하는 ID 기반 가드레일을 적용할 수 있습니다. 예를 들어 은행은 인증된 특정 결제 처리 워크로드만 외부 금융 게이트웨이에 도달할 수 있도록 할 수 있습니다.
Secure Web Proxy용 프런트엔드 mTLS 인증 구성
이 섹션에서는 Secure Web Proxy 인스턴스의 프런트엔드 mTLS 인증을 구성하는 단계를 설명합니다.
시작하기 전에
트러스트 구성 관리 페이지를 검토합니다.
Identity and Access Management 관리자에게 다음 역할을 부여해 달라고 요청하세요.
- 인증서 관리자 소유자 역할(
roles/certificatemanager.owner) - Compute 네트워크 관리자 역할(
roles/compute.networkAdmin) - Compute 보안 관리자 역할(
roles/compute.securityAdmin) - 네트워크 보안 관리자 역할(
roles/networksecurity.admin)
- 인증서 관리자 소유자 역할(
루트 및 중간 인증서 만들기
이 섹션에서는 OpenSSL을 사용하여 루트 인증 기관 (CA) 인증서 (신뢰 앵커)와 선택적 중간 CA 인증서를 생성하는 방법을 보여줍니다. Secure Web Proxy는 이러한 인증서를 사용하여 워크로드가 프런트엔드 mTLS 핸드셰이크 프로세스 중에 제공하는 클라이언트 인증서를 확인합니다. 이 수동 프로세스는 Secure Web Proxy가 클라이언트 인증서를 확인하는 데 필요한 신뢰 앵커를 제공하기 위해 테스트 및 개발 환경을 대상으로 합니다.
루트 인증서는 인증서 체인의 맨 위에 있는 반면 중간 인증서는 루트로 돌아가는 신뢰 체인의 브리지 역할을 합니다. 중간 인증서는 루트 인증서에서 암호화 방식으로 서명됩니다. 보안 웹 프록시는 클라이언트 인증서를 수신하면 클라이언트 인증서에서 구성된 신뢰 앵커로 돌아가는 신뢰 사슬을 설정하여 ID를 검사합니다.
다음 명령어를 사용하여 루트 및 중간 인증서를 만듭니다. 중간 인증서는 선택사항이지만 이 구성에서는 다중 계층 인증서 계층 구조를 보여주기 위해 중간 인증서를 사용하여 클라이언트 인증서에 서명합니다.
OpenSSL 구성 파일을 만듭니다.
cat > example.cnf << EOF [req] distinguished_name = empty_distinguished_name [empty_distinguished_name] # Kept empty to allow setting via -subj command-line argument. [ca_exts] basicConstraints=critical,CA:TRUE keyUsage=keyCertSign extendedKeyUsage=clientAuth EOF자체 서명된 X.509 루트 인증서 (
root.cert)와 비공개 키(root.key)를 만듭니다.openssl req -x509 \ -new -sha256 -newkey rsa:2048 -nodes \ -days 3650 -subj '/CN=root' \ -config example.cnf \ -extensions ca_exts \ -keyout root.key -out root.cert중간 인증서에 대해 인증서 서명 요청(
int.req)를 만듭니다.openssl req -new \ -sha256 -newkey rsa:2048 -nodes \ -subj '/CN=int' \ -config example.cnf \ -extensions ca_exts \ -keyout int.key -out int.req인증서 서명 요청 (CSR)에 서명하여 X.509 중간 인증서 (
int.cert)를 만듭니다.openssl x509 -req \ -CAkey root.key -CA root.cert \ -set_serial 1 \ -days 3650 \ -extfile example.cnf \ -extensions ca_exts \ -in int.req -out int.cert
테스트용 클라이언트 인증서 만들기
테스트 클라이언트 워크로드의 리프 인증서와 비공개 키를 만듭니다. 보안 웹 프록시 인스턴스와의 mTLS 핸드셰이크 프로세스 중에 클라이언트는 ID를 증명하기 위해 이 리프 인증서를 제공합니다.
다음 예에서는 OpenSSL을 사용하여 클라이언트 키와 CSR을 생성한 다음 루트 및 중간 인증서 만들기 섹션에서 만든 중간 CA 키로 CSR에 서명합니다.
다음 OpenSSL 명령어를 실행하여
client.key라는 RSA 비공개 키를 생성합니다.openssl genpkey -algorithm RSA -out client.key주체 대체 이름 (SAN)의 DNS 이름을 지정하는
client.cnf이라는 구성 파일을 만듭니다. 이렇게 하면 인증서가 최신 보안 요구사항과 호환되는지 확인할 수 있습니다.cat > client.cnf << EOF [req] distinguished_name = req_distinguished_name req_extensions = v3_req prompt = no [req_distinguished_name] CN = my-client.example.com [v3_req] keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth subjectAltName = @alt_names [alt_names] DNS.1 = my-client.example.com EOF테스트에 필요한 경우
CN및DNS.1값을 수정할 수 있습니다.생성한 비공개 키와 구성 파일을 사용하여 OpenSSL 요청 명령어를 실행하여
client.req파일을 생성합니다.openssl req -new -key client.key -out client.req -config client.cnfOpenSSL
x509명령어를 사용하여 중간 인증서(int.cert)와 키(int.key)를 사용하여 요청에 서명합니다. 유효 기간(예: 365일)을 설정하고 구성 파일의 확장 프로그램이 생성된client.cert파일에 적용되는지 확인합니다.openssl x509 -req -in client.req -CA int.cert -CAkey int.key \ -set_serial 02 -days 365 -out client.cert \ -extfile client.cnf -extensions v3_req이 프로세스를 통해
client.cert파일이 생성됩니다. DNS SAN에 사용된 값 (예:my-client.example.com)을 클라이언트 ID로 기록합니다. 이 값을 사용하여 Secure Web Proxy 승인 정책을 만들 때 워크로드를 식별할 수 있습니다.
인증서 형식 지정
trust_config.yaml 파일에서 사용할 수 있도록 루트 및 중간 인증서를 환경 변수로 포맷합니다.
export ROOT_CERT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
export INTERMEDIATE_CERT=$(cat int.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
트러스트 구성 리소스 만들기
트러스트 구성은 인증서 관리자에서 공개 키 인프라 (PKI)를 나타냅니다. 트러스트 구성은 프런트엔드 mTLS 핸드셰이크 중에 제공된 클라이언트 인증서를 확인할 때 신뢰할 인증 기관 (CA) 인증서를 Secure Web Proxy 인스턴스에 나타냅니다.
이 샘플 트러스트 구성 리소스에는 신뢰 앵커 (루트 CA)와 중간 CA가 있는 단일 트러스트 저장소가 포함된 트러스트 저장소가 포함됩니다. 이 섹션에서는 이전 인증서 형식 지정 섹션에서 만든 환경 변수의 인증서 콘텐츠를 사용합니다.
trust_config.yaml파일을 만듭니다.cat << EOF > trust_config.yaml trustStores: TRUST_CONFIG_NAME: trustAnchors: - pemCertificate: | -----BEGIN CERTIFICATE----- <certificate content> -----END CERTIFICATE----- intermediateCAs: - pemCertificate: | -----BEGIN CERTIFICATE----- <certificate content> -----END CERTIFICATE----- EOFTRUST_CONFIG_NAME을 트러스트 구성 리소스의 이름으로 바꿉니다.gcloud certificate-manager trust-configs import명령어를 사용하여trust config.yaml파일을 가져옵니다.gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME\ --source=trust_config.yaml \ --location=LOCATION
다음을 바꿉니다.
TRUST_CONFIG_NAME: 트러스트 구성 리소스의 이름LOCATION: 트러스트 구성 리소스가 저장된 리전
ServerTlsPolicy 리소스 만들기
ServerTlsPolicy 리소스(클라이언트 인증 리소스라고도 함)는 Secure Web Proxy가 클라이언트 인증서를 검증하는 방법을 정의합니다. 이를 통해 인증서 확인을 위한 서버 측 TLS 모드와 트러스트 구성 리소스를 지정할 수 있습니다.
clientValidationMode 속성은 클라이언트가 잘못된 인증서를 제공하거나 인증서를 전혀 제공하지 않을 때 연결이 처리되는 방식을 결정합니다.
자세한 내용은 프런트엔드 mTLS 클라이언트 검증 모드를 참고하세요.
clientValidationMode 속성의 값은 다음과 같습니다.
REJECT_INVALID: Secure Web Proxy는 트러스트 구성의 CA가 서명한 유효한 인증서를 제시하는 클라이언트의 연결만 허용합니다. 인증서가 잘못되었거나 누락된 연결은 거부됩니다.ALLOW_INVALID_OR_MISSING_CLIENT_CERT: Secure Web Proxy는 클라이언트 인증서가 유효하지 않거나, 신뢰 구성에 대해 검증할 수 없거나, 완전히 누락된 경우에도 연결 요청을 허용합니다.
ServerTlsPolicy 리소스를 만들려면 다음 단계를 따르세요.
server_tls_policy.yaml파일을 만듭니다.clientValidationMode에 대해 다음 옵션 중 하나를 선택합니다.- 옵션 1: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
name: SERVER_TLS_POLICY_NAME mtlsPolicy: clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT clientValidationTrustConfig: projects/PROJECT_ID/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME- 옵션 2: REJECT_INVALID
name: SERVER_TLS_POLICY_NAME mtlsPolicy: clientValidationMode: REJECT_INVALID clientValidationTrustConfig: projects/PROJECT_ID/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME다음을 바꿉니다.
SERVER_TLS_POLICY_NAME:ServerTlsPolicy리소스의 이름PROJECT_ID: Google Cloud 프로젝트 IDTRUST_CONFIG_NAME: 트러스트 구성 리소스의 이름LOCATION: Secure Web Proxy 인스턴스가 구성된 리전
gcloud network-security server-tls-policies import명령어를 사용하여ServerTlsPolicy리소스를 가져옵니다.gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME\ --source=server_tls_policy.yaml \ --location=LOCATION
다음을 바꿉니다.
SERVER_TLS_POLICY_NAME:ServerTlsPolicy리소스의 이름LOCATION: Secure Web Proxy 인스턴스가 구성된 리전
선택사항: 모든
ServerTlsPolicies리소스를 나열하려면gcloud network-security server-tls-policies list명령어를 사용합니다.gcloud network-security server-tls-policies list \ --location=LOCATION
LOCATION을 Secure Web Proxy 인스턴스가 구성된 리전으로 바꿉니다.
ServerTlsPolicy 리소스를 Secure Web Proxy 인스턴스와 연결합니다.
Secure Web Proxy 인스턴스의
gateway.yaml파일에ServerTlsPolicy리소스를 추가합니다.echo "serverTlsPolicy: //networksecurity.googleapis.com/projects/PROJECT_ID/locations/ LOCATION/serverTlsPolicies/SERVER_TLS_POLICY_NAME" >> gateway.yaml다음을 바꿉니다.
PROJECT_ID: Google Cloud 프로젝트 IDLOCATION: Secure Web Proxy 인스턴스가 구성된 리전
gcloud network-services gateways import명령어를 사용하여gateway.yaml파일에서 Secure Web Proxy 인스턴스의 구성을 가져옵니다.gcloud network-services gateways import GATEWAY_NAME\ --source=gateway.yaml \ --location=LOCATION다음을 바꿉니다.
GATEWAY_NAME: Secure Web Proxy 인스턴스의 이름LOCATION: Secure Web Proxy 인스턴스가 구성된 리전
승인 정책 구성
자세한 내용은 Secure Web Proxy의 승인 정책 설정을 참고하세요.
로깅
자세한 내용은 프런트엔드 mTLS 오류 처리 및 로깅을 참고하세요.
제한사항
Secure Web Proxy는 명시적 프록시 라우팅 모드에서만 프런트엔드 mTLS 구성을 지원합니다.
프런트엔드 mTLS 기반 보안 규칙을 만들려면 Secure Web Proxy에 승인 정책을 사용하세요. 게이트웨이 보안 정책 규칙은 지원되지 않습니다.
자세한 내용은 프런트엔드 mTLS 제한사항을 참고하세요.