1. 소개
클라우드 보안 웹 프록시
Cloud SWP는 이그레스 웹 트래픽 (HTTP/S)을 보호하는 데 도움이 되는 보안 웹 프록시를 제공하는 클라우드 중심 서비스입니다. Cloud SWP를 명시적으로 프록시로 사용하도록 클라이언트를 구성합니다. 웹 요청은 다음 소스에서 시작될 수 있습니다.
- 가상 머신(VM) 인스턴스
- 컨테이너
- 서버리스 커넥터를 사용하는 서버리스 환경
- VPC 피어링 전반의 워크로드
- Cloud VPN 또는 Cloud Interconnect로 연결된 Google Cloud 외부의 워크로드
Cloud SWP는 클라우드 중심 ID 및 웹 애플리케이션을 기반으로 유연하고 세분화된 정책을 지원합니다.
이점
다음은 Cloud SWP가 조직에 제공할 수 있는 이점의 몇 가지 예시입니다.
Google Cloud로의 마이그레이션:
Cloud SWP를 사용하면 이그레스 웹 트래픽에 대한 기존 보안 정책과 요구사항을 유지하면서 Google Cloud로 마이그레이션할 수 있습니다. 다른 관리 콘솔이 필요한 타사 솔루션을 사용하거나 구성 파일을 수동으로 수정하지 않아도 됩니다.
신뢰할 수 있는 외부 웹 서비스 액세스
Cloud SWP를 사용하면 이그레스 웹 트래픽에 세분화된 액세스 정책을 적용하여 네트워크를 보호할 수 있습니다. 워크로드 또는 애플리케이션 ID를 만들고 식별한 다음 정책을 적용합니다.
신뢰할 수 없는 웹 서비스 액세스 모니터링
Cloud SWP를 사용하여 신뢰할 수 없는 웹 서비스에 대한 모니터링 액세스를 제공할 수 있습니다. Cloud SWP는 정책을 준수하지 않는 트래픽을 식별하고 이를 Cloud Logging (Logging)에 로깅합니다. 그런 다음 인터넷 사용을 모니터링하고, 네트워크에 대한 위협을 발견하고, 위협에 대응할 수 있습니다.
Google API를 위한 세밀한 정책 제어
Cloud SWP를 사용하여 Google API에 세분화된 정책을 제공할 수 있습니다. 예를 들어 Common Expression Language (CEL)를 활용하여 버킷/객체 수준 정책을 설정할 수 있습니다.
지원되는 기능
Cloud SWP는 다음 기능을 지원합니다.
명시적 프록시 서비스
프록시 서버를 사용하도록 클라이언트를 명시적으로 구성해야 합니다. Cloud SWP 프록시는 클라이언트를 대신하여 새 TCP 연결을 만들어 클라이언트를 인터넷에서 격리합니다.
Cloud SWP Envoy 프록시 자동 확장
리전에서 Envoy 프록시 풀 크기와 풀 용량을 자동으로 조정할 수 있어 수요가 많은 기간 동안 최저 비용으로 일관된 성능을 유지할 수 있습니다.
모듈식 이그레스 액세스 정책
Cloud SWP는 특히 다음과 같은 이그레스 정책을 지원합니다.
- 보안 태그, 서비스 계정 또는 IP 주소를 기반으로 한 소스 ID
- URL, 호스트 이름 기반의 대상입니다.
- 메서드, 헤더 또는 URL에 기반한 요청입니다. 목록, 와일드 카드 또는 패턴을 사용하여 URL을 지정할 수 있습니다.
- 엔드 투 엔드 암호화: 클라이언트 프록시 터널이 TLS를 통해 전송될 수 있습니다. 또한 Cloud SWP는 대상 서버에 대한 클라이언트에서 시작한 엔드 투 엔드 TLS 연결을 위해 HTTP/S CONNECT를 지원합니다.
간소화된 Cloud NAT 통합
Cloud NAT는 Cloud SWP 트래픽을 제공하는 프록시 집합이 증가할 때 추가 공개 IP 주소를 자동으로 프로비저닝합니다.
알려진 이그레스 IP를 원하는 사용자는 수동 고정 공개 IP 주소를 사용할 수도 있습니다.
Cloud 감사 로그 및 Google Cloud 운영 제품군 통합
Cloud 감사 로그 및 Google Cloud 운영 제품군은 Cloud SWP 관련 리소스에 대한 관리 활동 및 액세스 요청을 기록합니다. 또한 프록시에서 처리한 요청의 측정항목과 트랜잭션 로그를 기록합니다.
TLS 검사
보안 웹 프록시는 TLS 트래픽을 가로채고 암호화된 요청을 검사하고 보안 정책을 적용할 수 있는 TLS 검사 서비스를 제공합니다.
- 비공개 CA를 위한 가용성과 확장성이 뛰어난 저장소인 Certificate Authority Service (CAS)와 긴밀하게 통합됩니다.
- 필요한 경우 자체 신뢰할 수 있는 루트 사용. 기존 루트 CA를 사용하여 CAS에서 보유한 하위 CA에 서명할 수도 있습니다. 원하는 경우 CAS 내에서 새 루트 인증서를 생성할 수 있습니다.
- 보안 웹 프록시 정책 규칙 내에서 SessionMatcher 및 ApplicationMatcher를 사용하여 세분화된 복호화 기준입니다. 이 기준에는 URL 목록에 있는 일치하는 호스트, 정규 표현식, IP 주소 범위, 유사 표현식이 포함됩니다. 필요한 경우 기준을 불리언 표현식과 결합할 수 있습니다.
- 각 보안 웹 프록시 정책은 자체 TLS 검사 정책과 CA 풀로 구성할 수 있습니다. 또는 여러 보안 웹 프록시 정책이 단일 TLS 검사 정책을 공유할 수 있습니다.
학습할 내용
- Cloud SWP를 배포하고 관리하는 방법
필요한 항목
- 인스턴스 배포 및 네트워킹 구성요소 구성에 관한 지식
- VPC 방화벽 구성 지식
2. 테스트 환경
이 Codelab에서는 단일 VPC를 활용합니다. 이 환경의 컴퓨팅 리소스는 아래 다이어그램에 표시된 것처럼 Cloud SWP를 사용하여 이그레스됩니다.
이 실습에서는 2개의 워크로드 VM을 사용합니다.
클라이언트 A는 모든 HTTP/HTTPS 요청을 Cloud SWP로 전송하도록 구성됩니다.
클라이언트 B는 Cloud SWP에 HTTP/HTTPS 요청을 명시적으로 전송하도록 구성되지 않고 대신 인터넷 연결 트래픽에 Cloud NAT를 활용합니다.
3. 시작하기 전에
Codelab에는 단일 프로젝트가 필요합니다.
Cloud Shell 내에서 프로젝트 ID가 설정되어 있는지 확인합니다.
export project_id=`gcloud config list --format="value(core.project)"` export project_number=`gcloud projects describe $project_id --format="value(projectNumber)"` export region=us-west1 export zone=us-west1-a export prefix=codelab-swp export member="serviceAccount:service-$project_number@gcp-sa-networksecurity.iam.gserviceaccount.com"
4. API 사용 설정
제품을 사용하려면 API를 사용 설정하세요.
gcloud services enable networksecurity.googleapis.com gcloud services enable certificatemanager.googleapis.com gcloud services enable networkservices.googleapis.com
5. VPC 네트워크, 서브넷, 프록시 전용 서브넷 만들기
VPC 네트워크
codelab-swp-vpc VPC를 만듭니다.
gcloud compute networks create $prefix-vpc --subnet-mode=custom
서브넷
선택한 리전에 각 서브넷을 만듭니다.
gcloud compute networks subnets create $prefix-vpc-subnet \ --range=10.10.10.0/24 --network=$prefix-vpc --region=$region
프록시 전용 서브넷
선택한 리전에 프록시 전용 서브넷을 만듭니다.
gcloud compute networks subnets create $prefix-proxy-only-subnet --purpose=REGIONAL_MANAGED_PROXY --role=ACTIVE --region=$region --network=$prefix-vpc --range=172.16.0.0/23
6. 방화벽 규칙 만들기
IAP에서 VM 인스턴스에 연결할 수 있도록 허용하려면 다음과 같은 방화벽 규칙을 만듭니다.
- IAP를 사용하여 액세스할 수 있게 하려는 모든 VM 인스턴스에 적용됩니다.
- IP 범위 35.235.240.0/20에서 들어오는 인그레스 트래픽을 허용합니다. 이 범위에는 IAP가 TCP 전달에 사용하는 모든 IP 주소가 포함됩니다.
cloudshell에서:
gcloud compute firewall-rules create $prefix-allow-iap-proxy \ --direction=INGRESS \ --priority=1000 \ --network=$prefix-vpc \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=35.235.240.0/20
7. Cloud Router 만들기 및 Cloud NAT
Cloud NAT용 Cloud Router 만들기
gcloud compute routers create ${prefix}-cr \
--region=$region \
--network=${prefix}-vpc
클라이언트 B에 대한 Cloud NAT 게이트웨이를 만듭니다.
gcloud compute routers nats create $prefix-nat-gw-$region \ --router=$prefix-cr \ --router-region=$region \ --auto-allocate-nat-external-ips \ --nat-all-subnet-ip-ranges
8. 게이트웨이 보안 정책 만들기
정책과 관련된 정보가 포함된 yaml 파일을 만듭니다.
cat > /tmp/policy.yaml << EOF
description: Policy to allow .com traffic, then (/index.html), and finally TLS.
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
EOF
gcloud 명령어를 실행하여 yaml 파일에서 정책을 만듭니다.
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
9. 게이트웨이 보안 정책 규칙 만들기
규칙이 포함된 yaml 파일을 생성합니다. 이러한 규칙은 Common Expression Language (CEL)로 표현됩니다. 이 실습에서는 다음과 같이 .com 도메인으로 가는 트래픽을 허용하고 다른 모든 도메인을 차단하는 간단한 규칙을 사용합니다.
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
EOF
이제 규칙을 게이트웨이 보안 정책에 결합할 수 있습니다.
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
10. 인증서를 만들고 Cloud Certificate Manager에 업로드합니다.
인증서를 만들어 워크로드 트래픽을 종료합니다.
openssl req -x509 -newkey rsa:2048 -keyout /tmp/key.pem -out /tmp/cert.pem -days 365 -subj '/CN=www.codelab-swp.com' -nodes -addext \ "subjectAltName = DNS:www.codelab-swp.com"
SWP가 보안 게이트웨이 정책에서 인증서를 참조할 수 있도록 인증서를 Cloud Certificate Manager에 업로드합니다.
gcloud certificate-manager certificates create ${prefix}-cert --location=${region} --private-key-file=/tmp/key.pem --certificate-file=/tmp/cert.pem
11. SWP 게이트웨이 만들기
인증서, 게이트웨이 보안 정책, 네트워크, 서브넷과 같은 이전 정보를 참조할 수 있도록 SWP Gateway용 yaml 파일을 만듭니다.
cat > /tmp/gateway.yaml << EOF
name: projects/${project_id}/locations/${region}/gateways/${prefix}-gateway
type: SECURE_WEB_GATEWAY
addresses: [10.10.10.50]
ports: [443]
certificateUrls: [projects/${project_id}/locations/${region}/certificates/${prefix}-cert]
gatewaySecurityPolicy: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
network: projects/${project_id}/global/networks/${prefix}-vpc
subnetwork: projects/${project_id}/regions/${region}/subnetworks/${prefix}-vpc-subnet
EOF
게이트웨이를 만듭니다.
gcloud network-services gateways import ${prefix}-swp --source=/tmp/gateway.yaml --location=${region}
게이트웨이가 생성되었는지 확인합니다.
gcloud network-services gateways describe ${prefix}-swp --location ${region}
12. Compute 인스턴스 만들기
Cloud SWP는 명시적 프록시이므로 워크로드 트래픽의 프록시 IP를 명시적으로 지정해야 합니다. Compute 인스턴스 clientA에는 환경 변수가 설정됩니다. 클라이언트 B는 그렇지 않습니다.
컴퓨팅 인스턴스 ClientA와 ClientB를 만듭니다.
gcloud compute instances create clienta \ --subnet=$prefix-vpc-subnet \ --no-address \ --private-network-ip=10.10.10.10 \ --zone $zone \ --metadata startup-script='#! /bin/bash apt-get update sudo echo http_proxy=https://10.10.10.50:443/ >> /etc/environment sudo echo https_proxy=https://10.10.10.50:443/ >> /etc/environment '
gcloud compute instances create clientb \ --subnet=$prefix-vpc-subnet \ --no-address \ --private-network-ip=10.10.10.200 \ --zone $zone \ --metadata startup-script='#! /bin/bash apt-get update '
13. 세션 매칭 테스트
'clienta'에 SSH로 연결 최근에 만든 컴퓨팅 VM입니다 이 VM에는 Cloud SWP를 사용하도록 환경 변수가 설정되어 있습니다.
cloudshell에서:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
웹 쿼리를 실행하여 기능을 확인합니다. 이 실습에서는 자체 서명 인증서를 만들었으므로 –proxy-insecure가 필요합니다.
curl https://google.com --proxy-insecure
예상 출력:
davidtu@clienta:~$ curl https://google.com --proxy-insecure <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/">here</A>. </BODY></HTML>
보시다시피 요청이 '성공'했습니다. 웹사이트가 https://www.google.com으로 리디렉션 중이기 때문에 301 리디렉션이 표시될 수 있습니다.
다음 명령어를 실행하면 연결에 대한 세부정보가 포함된 상세 로그가 제공됩니다.
curl https://google.com --proxy-insecure -v
프록시 연결 세부정보, 인증서, 대상을 보여주는 일부 출력을 강조 표시합니다.
davidtu@clienta:~$ curl https://google.com --proxy-insecure -v * Uses proxy env variable https_proxy == 'https://10.10.10.50:443/' * Trying 10.10.10.50:443... * Connected to 10.10.10.50 (10.10.10.50) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Proxy certificate: * subject: CN=www.codelab-swp.com * start date: Dec 12 17:16:35 2022 GMT * expire date: Dec 12 17:16:35 2023 GMT * issuer: CN=www.codelab-swp.com * SSL certificate verify result: self signed certificate (18), continuing anyway. * allocate connect buffer! * Establish HTTP proxy tunnel to google.com:443 > CONNECT google.com:443 HTTP/1.1 > Host: google.com:443 > User-Agent: curl/7.74.0 > Proxy-Connection: Keep-Alive > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/1.1 200 OK < date: Mon, 12 Dec 2022 19:22:04 GMT < * Proxy replied 200 to CONNECT request * CONNECT phase completed! ...
다른 .com 도메인을 사용하여 기능을 확인해 보세요.
이제 .com 이외의 도메인을 사용하여 기본 차단 동작을 확인해 보겠습니다.
curl https://wikipedia.org --proxy-insecure
예상 출력:
curl: (56) Received HTTP code 403 from proxy after CONNECT
마찬가지로 상세 출력 로깅을 살펴보고 Cloud SWP가 이 트래픽을 차단하고 있는지 확인합니다.
curl https://wikipedia.org --proxy-insecure -v
davidtu@clienta:~$ curl https://wikipedia.org --proxy-insecure -v * Uses proxy env variable https_proxy == 'https://10.10.10.50:443/' * Trying 10.10.10.50:443... * Connected to 10.10.10.50 (10.10.10.50) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Proxy certificate: * subject: CN=www.codelab-swp.com * start date: Dec 12 17:16:35 2022 GMT * expire date: Dec 12 17:16:35 2023 GMT * issuer: CN=www.codelab-swp.com * SSL certificate verify result: self signed certificate (18), continuing anyway. * allocate connect buffer! * Establish HTTP proxy tunnel to wikipedia.org:443 > CONNECT wikipedia.org:443 HTTP/1.1 > Host: wikipedia.org:443 > User-Agent: curl/7.74.0 > Proxy-Connection: Keep-Alive > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/1.1 403 Forbidden < content-length: 13 < content-type: text/plain < date: Mon, 12 Dec 2022 19:35:09 GMT < connection: close < * Received HTTP code 403 from proxy after CONNECT * CONNECT phase completed! * Closing connection 0 curl: (56) Received HTTP code 403 from proxy after CONNECT
다른 도메인도 확인해 보시기 바랍니다.
'clienta'에 대한 SSH 세션을 종료합니다. 'clientb'에 대한 새로운 SSH 연결을 시작합니다.
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
몇 가지 curl 명령어를 실행하여 동작을 확인합니다.
curl https://google.com
이 명령어는 예상 clientb VM으로 작동합니다.
davidtu@clientb:~$ curl https://google.com <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/">here</A>. </BODY></HTML>
조직 도메인을 대상으로 테스트:
curl https://wikipedia.org
clientb가 Cloud SWP를 활용하지 않기 때문에 이는 예상대로 작동합니다.
davidtu@clientb:~$ curl https://wikipedia.org <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://www.wikipedia.org/">here</a>.</p> </body></html>
Cloud SWP를 통해 명시적으로 트래픽 전송을 테스트합니다.
curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure
이 트래픽은 Cloud SWP 정책을 통해 거부됩니다.
davidtu@clientb:~$ curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure curl: (56) Received HTTP code 403 from proxy after CONNECT
확인한 바와 같이, Cloud SWP를 활용하는 트래픽은 구성된 보안 정책에 따라 시행되고 있습니다. .com을 대상으로 하는 트래픽은 허용되며 다른 모든 대상은 거부됩니다.
clientb를 종료합니다.
14. ApplicationMatching을 위한 게이트웨이 보안 정책 규칙 업데이트
애플리케이션 수준 세부정보와 일치하도록 규칙을 업데이트해 보겠습니다. 요청 경로를 살펴보고 index.html과 일치하는 경우에만 허용하는 규칙을 만들어 보겠습니다.
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic with path index.html
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
applicationMatcher: request.path.matches('index.html')
EOF
이제 업데이트된 규칙을 게이트웨이 보안 정책에 결합할 수 있습니다.
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
15. ApplicationMatcher 규칙 테스트
클라이언트 컴퓨팅 VM에 SSH로 연결합니다. 이 VM에는 Cloud SWP를 사용하도록 환경 변수가 설정되어 있습니다.
cloudshell에서:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
웹 쿼리를 실행하여 기능을 확인합니다. 이 실습에서는 자체 서명 인증서를 만들었으므로 –proxy-insecure가 필요합니다.
curl http://google.com --proxy-insecure
이 쿼리는 이전에 전달되면 실패합니다.
Access denied
'index.html' 이외의 요청 경로 403으로 차단되어야 합니다. 이 부분을 추가로 테스트해 보세요.
/index.html 경로를 포함하도록 쿼리를 수정합니다.
curl http://google.com/index.html --proxy-insecure
이 요청은 성공해야 합니다.
davidtu@clienta:~$ curl http://google.com/index.html --proxy-insecure <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/index.html">here</A>. </BODY></HTML>
웹사이트가 http://www.google.com/index.html로 리디렉션 중이므로 301 리디렉션이 표시될 수 있습니다.
HTTP 요청임을 알 수 있습니다. 다음으로 TLS 검사 기능을 사용하려면 SWP를 사용 설정해야 합니다.
다음으로 동일한 쿼리를 TLS를 통해 실행합니다.
curl -k https://google.com/index.html --proxy-insecure
예상 출력:
curl: (56) Received HTTP code 403 from proxy after CONNECT
SWP가 TLS를 검사하도록 구성되어 있지 않고 applicationMatcher 규칙을 기준으로 경로를 평가할 수 없으므로 이 요청은 실패합니다.
clenta를 종료합니다.
16. TLS 검사 사용 설정
TLS 검사가 없으면 applicationMatcher가 HTTPS 트래픽과 매칭되지 않습니다.
"applicationMatcher" 다음을 필터링할 수 있습니다.
- 요청 헤더 맵
- 요청 메소드
- 호스트 요청
- 요청 경로
- 요청 쿼리
- 요청 스키마
- 전체 요청 URL
- useragent 요청
서비스 계정 만들기
이 서비스 계정에는 SWP TLS 검사를 위한 인증서를 생성할 권한이 부여됩니다.
gcloud beta services identity create \
--service=networksecurity.googleapis.com \
--project=$project_id
CAS가 사용 설정되어 있는지 확인하세요.
gcloud services enable privateca.googleapis.com
CA 풀 만들기
gcloud privateca pools create $prefix-ca-pool \
--tier=devops \
--project=$project_id \
--location=$region
루트 CA 만들기
인증서 서명에 사용되는 CA입니다.
gcloud privateca roots create $prefix-root-ca --pool=$prefix-ca-pool \ --location=$region \ --auto-enable \ --subject="CN=my-swp-ca, O=SWP LLC"
인증서 발급 정책 파일 만들기
cat > /tmp/tls-issuance-policy.yaml << EOF
maximumLifetime: 1209600s
baselineValues:
caOptions:
isCa: false
keyUsage:
extendedKeyUsage:
serverAuth: true
EOF
TLS 검사 YAML 파일 만들기
cat > /tmp/tls-inspection-policy.yaml << EOF caPool: projects/$project_id/locations/$region/caPools/$prefix-ca-pool name: projects/$project_id/locations/$region/tlsInspectionPolicies/$prefix-tls-inspection EOF
TLS 검사 정책 만들기
gcloud network-security tls-inspection-policies import $prefix-tls-inspection \
--source=/tmp/tls-inspection-policy.yaml \
--location=$region
인증서 발급 정책을 사용하도록 CA 풀을 업데이트하세요.
gcloud privateca pools update $prefix-ca-pool --issuance-policy=/tmp/tls-issuance-policy.yaml --location=$region
권한 부여
이렇게 하면 서비스 계정에서 CA 풀을 사용하여 인증서를 생성할 수 있습니다.
gcloud privateca pools add-iam-policy-binding $prefix-ca-pool \
--member=$member \
--role='roles/privateca.certificateManager' \
--location=$region
TLS 검사를 포함하도록 정책 yaml 업데이트
cat > /tmp/policy.yaml << EOF
description: some policy description
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
tlsInspectionPolicy: projects/${project_id}/locations/${region}/tlsInspectionPolicies/${prefix}-tls-inspection
EOF
명령어를 실행하여 업데이트된 정책을 적용합니다.
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
TLS 검사를 포함하도록 규칙 업데이트
다음으로 TLS 검사 'enabtlsInspectionEnabled: true'를 포함해야 하는 규칙을 지정합니다. 플래그.
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic with path index.html
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
applicationMatcher: request.path.matches('index.html')
tlsInspectionEnabled: true
EOF
명령어를 실행하여 업데이트된 규칙 적용
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
17. TLS 검사 테스트
클라이언트 컴퓨팅 VM에 SSH로 연결합니다. 이 VM에는 Cloud SWP를 사용하도록 환경 변수가 설정되어 있습니다.
cloudshell에서:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
이전 웹 쿼리를 실행하여 SWP가 TLS 검사를 실행하여 경로를 가져오는지 확인
curl -k https://google.com/index.html --proxy-insecure
이번에는 SWP가 ApplicationMatcher를 평가할 수 있으므로 성공합니다.
예상 출력:
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/index.html">here</A>. </BODY></HTML>
TLS를 검사하고 applicationMatcher 로직을 평가하기 위해 Cloud SWP를 성공적으로 설정했습니다.
클라이언트 종료
18. 정리 단계
Cloud Shell에서 SWP 게이트웨이, 보안 정책, 인증서, 인스턴스, Cloud NAT, Cloud Router를 삭제합니다.
gcloud -q network-services gateways delete ${prefix}-swp --location=${region}
gcloud -q network-security gateway-security-policies rules delete rule-com --location=${region} --gateway-security-policy=${prefix}-policy
gcloud -q network-security gateway-security-policies delete ${prefix}-policy --location=${region}
gcloud -q certificate-manager certificates delete ${prefix}-cert --location=${region}
gcloud -q network-security tls-inspection-policies delete $prefix-tls-inspection --location=$region
gcloud -q privateca roots disable $prefix-root-ca --pool=$prefix-ca-pool --location=$region
gcloud -q privateca roots delete $prefix-root-ca --pool=$prefix-ca-pool --location=$region --ignore-active-certificates --skip-grace-period
gcloud -q privateca pools delete $prefix-ca-pool --location=$region
gcloud -q compute instances delete clienta --zone=$zone
gcloud -q compute instances delete clientb --zone=$zone
gcloud -q compute routers nats delete ${prefix}-nat-gw-${region} \
--router=$prefix-cr --router-region=$region
gcloud -q compute routers delete `gcloud compute routers list --regions=$region --format="value(NAME)" | grep -e swg-autogen -e codelab-swp` --region=$region
서브넷, FW 규칙, VPC를 삭제합니다.
gcloud -q compute networks subnets delete $prefix-vpc-subnet \
--region $region
gcloud -q compute networks subnets delete $prefix-proxy-only-subnet \
--region=$region
gcloud -q compute firewall-rules delete $prefix-allow-iap-proxy
gcloud -q compute networks delete $prefix-vpc
19. 축하합니다.
축하합니다. Codelab을 완료했습니다. Google Cloud에 클라우드 보안 웹 프록시를 구성하고 배포했습니다.
학습한 내용
- Cloud SWP와 그 이점