Codelab สำหรับ Cloud Secure Web Proxy (SWP)

1. บทนำ

เว็บพร็อกซีที่ปลอดภัยสำหรับระบบคลาวด์

Cloud SWP เป็นบริการที่เน้นระบบคลาวด์เป็นอันดับแรกซึ่งมีพร็อกซีเว็บที่ปลอดภัยเพื่อช่วยรักษาความปลอดภัยให้กับการรับส่งข้อมูลเว็บขาออก (HTTP/S) คุณกำหนดค่าไคลเอ็นต์ให้ใช้ Cloud SWP เป็นพร็อกซีอย่างชัดเจน คำขอเว็บอาจมาจากแหล่งที่มาต่อไปนี้

  • อินสแตนซ์เครื่องเสมือน (VM)
  • คอนเทนเนอร์
  • สภาพแวดล้อมแบบ Serverless ที่ใช้เครื่องมือเชื่อมต่อแบบ Serverless
  • ภาระงานในการเพียร์ VPC
  • เวิร์กโหลดภายนอก Google Cloud ที่เชื่อมต่อด้วย Cloud VPN หรือ Cloud Interconnect

Cloud SWP ช่วยให้ใช้นโยบายที่ยืดหยุ่นและละเอียดตามข้อมูลประจำตัวแบบ Cloud-First และเว็บแอปพลิเคชัน

ข้อดี

ตัวอย่างประโยชน์บางส่วนที่ Cloud SWP มอบให้แก่องค์กรมีดังนี้

การย้ายข้อมูลไปยัง Google Cloud

Cloud SWP ช่วยให้คุณย้ายข้อมูลไปยัง Google Cloud ได้ในขณะที่ยังคงใช้นโยบายและข้อกำหนดด้านความปลอดภัยที่มีอยู่สำหรับการรับส่งข้อมูลเว็บขาออก คุณสามารถหลีกเลี่ยงการใช้โซลูชันของบุคคลที่สามที่ต้องใช้คอนโซลการจัดการอื่นหรือการแก้ไขไฟล์กำหนดค่าด้วยตนเองได้

สิทธิ์เข้าถึงบริการเว็บภายนอกที่เชื่อถือได้

Cloud SWP ช่วยให้คุณใช้นโยบายการเข้าถึงแบบละเอียดกับการรับส่งข้อมูลเว็บขาออกเพื่อรักษาความปลอดภัยของเครือข่ายได้ คุณสร้างและระบุข้อมูลประจำตัวของเวิร์กโหลดหรือแอปพลิเคชัน แล้วใช้นโยบาย

การเข้าถึงบริการเว็บที่ไม่น่าเชื่อถือที่ได้รับการตรวจสอบ

คุณสามารถใช้ Cloud SWP เพื่อให้สิทธิ์เข้าถึงบริการเว็บที่ไม่น่าเชื่อถือที่ตรวจสอบแล้ว Cloud SWP จะระบุการรับส่งข้อมูลที่ไม่เป็นไปตามนโยบายและบันทึกไว้ใน Cloud Logging (การบันทึก) จากนั้นคุณจะตรวจสอบการใช้อินเทอร์เน็ต ค้นพบภัยคุกคามต่อเครือข่าย และตอบสนองต่อภัยคุกคามได้

การควบคุมนโยบายแบบละเอียดสำหรับ Google APIs

คุณสามารถใช้ Cloud SWP เพื่อกำหนดนโยบายแบบละเอียดสำหรับ Google API เช่น คุณสามารถตั้งค่านโยบายระดับที่เก็บข้อมูล/ออบเจ็กต์โดยใช้ประโยชน์จาก Common Expression Language (CEL)

ฟีเจอร์ที่รองรับ

Cloud SWP รองรับฟีเจอร์ต่อไปนี้

บริการพร็อกซีที่ชัดเจน

ต้องกำหนดค่าไคลเอ็นต์อย่างชัดแจ้งเพื่อใช้พร็อกซีเซิร์ฟเวอร์ พร็อกซี SWP ของ Cloud จะแยกไคลเอ็นต์ออกจากอินเทอร์เน็ตโดยการสร้างการเชื่อมต่อ TCP ใหม่ในนามของไคลเอ็นต์

การปรับขนาดอัตโนมัติของพร็อกซี Envoy ของ Cloud SWP

รองรับการปรับขนาดพูลพร็อกซี Envoy และความจุของพูลในภูมิภาคโดยอัตโนมัติ ซึ่งช่วยให้มั่นใจได้ถึงประสิทธิภาพที่สม่ำเสมอในช่วงที่มีความต้องการสูงในราคาที่ต่ำที่สุด

นโยบายการเข้าถึงขาออกแบบโมดูล

Cloud SWP รองรับนโยบายขาออกต่อไปนี้โดยเฉพาะ

  • ข้อมูลระบุแหล่งที่มาตามแท็กที่ปลอดภัย บัญชีบริการ หรือที่อยู่ IP
  • ปลายทางตาม URL, ชื่อโฮสต์
  • คำขอตามวิธีการ ส่วนหัว หรือ URL โดยสามารถระบุ URL ได้โดยใช้รายการ ไวลด์การ์ด หรือรูปแบบ
  • การเข้ารหัสจากต้นทางถึงปลายทาง: อุโมงค์ไคลเอ็นต์พร็อกซีอาจส่งผ่าน TLS นอกจากนี้ Cloud SWP ยังรองรับ HTTP/S CONNECT สำหรับการเชื่อมต่อ TLS จากต้นทางถึงปลายทางที่ไคลเอ็นต์เริ่มต้นไปยังเซิร์ฟเวอร์ปลายทางด้วย

การผสานรวม Cloud NAT ที่ง่ายขึ้น

Cloud NAT จะจัดสรรที่อยู่ IP สาธารณะเพิ่มเติมโดยอัตโนมัติเมื่อชุดพร็อกซีที่ให้บริการการรับส่งข้อมูล Cloud SWP เพิ่มขึ้น

นอกจากนี้ ที่อยู่ IP สาธารณะแบบคงที่ที่กำหนดเองยังเป็นอีกตัวเลือกหนึ่งสำหรับผู้ที่ต้องการมี IP ขาออกที่ทราบ

การผสานรวมบันทึกการตรวจสอบ Cloud และชุดเครื่องมือการดำเนินการของ Google Cloud

บันทึกการตรวจสอบของ Cloud และชุดเครื่องมือการดำเนินการของ Google Cloud จะบันทึกกิจกรรมการดูแลระบบและคำขอเข้าถึงทรัพยากรที่เกี่ยวข้องกับ Cloud SWP นอกจากนี้ ยังบันทึกเมตริกและบันทึกธุรกรรมสำหรับคำขอที่พร็อกซีจัดการด้วย

การตรวจสอบ TLS

Secure Web Proxy มีบริการตรวจสอบ TLS ที่ช่วยให้คุณสกัดกั้นการรับส่งข้อมูล TLS ตรวจสอบคำขอที่เข้ารหัส และบังคับใช้นโยบายความปลอดภัยได้

  • การผสานรวมอย่างใกล้ชิดกับ Certificate Authority Service (CAS) ซึ่งเป็นที่เก็บข้อมูลที่มีความพร้อมใช้งานสูงและปรับขนาดได้สำหรับ CA ส่วนตัว
  • ความสามารถในการใช้รูทของความน่าเชื่อถือของคุณเองหากจำเป็น นอกจากนี้ คุณยังใช้ CA ระดับรูทที่มีอยู่เพื่อลงนามสำหรับ CA ระดับรองที่ CAS ถือครองได้ด้วย หรือจะสร้างใบรับรองรูทใหม่ภายใน CAS ก็ได้หากต้องการ
  • เกณฑ์การถอดรหัสแบบละเอียดโดยใช้ SessionMatcher และ ApplicationMatcher ภายในกฎนโยบาย Secure Web Proxy เกณฑ์นี้รวมถึงการจับคู่โฮสต์ที่อยู่ในรายการ URL, นิพจน์ทั่วไป, ช่วงที่อยู่ IP และนิพจน์ที่คล้ายกัน หากจำเป็น คุณสามารถรวมเกณฑ์กับนิพจน์บูลีนได้
  • นโยบาย Secure Web Proxy แต่ละรายการสามารถกำหนดค่าด้วยนโยบายการตรวจสอบ TLS และพูล CA ของตัวเองได้ หรือนโยบาย Secure Web Proxy หลายรายการจะแชร์นโยบายการตรวจสอบ TLS รายการเดียวก็ได้

สิ่งที่คุณจะได้เรียนรู้

  • วิธีติดตั้งใช้งานและจัดการ Cloud SWP

สิ่งที่คุณต้องมี

  • ความรู้เกี่ยวกับการติดตั้งใช้งานอินสแตนซ์และการกำหนดค่าคอมโพเนนต์เครือข่าย
  • ความรู้เกี่ยวกับการกำหนดค่าไฟร์วอลล์ VPC

2. สภาพแวดล้อมการทดสอบ

Codelab นี้จะใช้ประโยชน์จาก VPC เดียว ทรัพยากรการประมวลผลในสภาพแวดล้อมนี้จะส่งข้อมูลขาออกโดยใช้ Cloud SWP ตามที่แสดงในแผนภาพด้านล่าง

1264e30caa136365.png

ใน Lab นี้ เราจะมี VM ภาระงาน 2 รายการ

ไคลเอ็นต์ A จะได้รับการกำหนดค่าให้ส่งคำขอ HTTP/HTTPS ทั้งหมดไปยัง Cloud SWP

ไคลเอ็นต์ B จะไม่ได้รับการกำหนดค่าให้ส่งคำขอ HTTP/HTTPS ไปยัง Cloud SWP อย่างชัดเจน แต่จะใช้ประโยชน์จาก Cloud NAT สำหรับการรับส่งข้อมูลที่มุ่งหน้าไปยังอินเทอร์เน็ตแทน

3. ก่อนเริ่มต้น

Codelab ต้องใช้โปรเจ็กต์เดียว

ตรวจสอบว่าได้ตั้งค่ารหัสโปรเจ็กต์ใน Cloud Shell แล้ว

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 ให้สร้างกฎไฟร์วอลล์ที่มีลักษณะดังนี้

  • มีผลกับอินสแตนซ์ VM ทั้งหมดที่คุณต้องการให้เข้าถึงได้โดยใช้ IAP
  • อนุญาตการรับส่งข้อมูลขาเข้าจากช่วง IP 35.235.240.0/20 ช่วงนี้มีที่อยู่ IP ทั้งหมดที่ IAP ใช้สำหรับการส่งต่อ TCP

จาก Cloud Shell

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 Router สำหรับ Cloud NAT

gcloud compute routers create ${prefix}-cr \
--region=$region \
--network=${prefix}-vpc

สร้างเกตเวย์ Cloud NAT สำหรับไคลเอ็นต์ B

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) ใน Lab นี้จะใช้กฎง่ายๆ ที่จะอนุญาตการเข้าชมไปยังโดเมน .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 อ้างอิงใบรับรองในนโยบายเกตเวย์ความปลอดภัยได้

gcloud certificate-manager certificates create ${prefix}-cert --location=${region} --private-key-file=/tmp/key.pem --certificate-file=/tmp/cert.pem

11. สร้างเกตเวย์ SWP

สร้างไฟล์ YAML สำหรับเกตเวย์ SWP เพื่ออ้างอิงข้อมูลก่อนหน้า เช่น ใบรับรอง นโยบายความปลอดภัยของเกตเวย์ เครือข่าย และเครือข่ายย่อย

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 พร็อกซีสำหรับการเข้าชมของภาระงานอย่างชัดเจน ไคลเอ็นต์ A ของอินสแตนซ์ Compute จะมีการตั้งค่าตัวแปรสภาพแวดล้อม แต่ ClientB จะไม่ทำ

สร้างอินสแตนซ์การประมวลผล 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. การจับคู่เซสชันการทดสอบ

SSH เข้าสู่ VM การประมวลผล "clienta" ที่สร้างขึ้นเมื่อเร็วๆ นี้ VM นี้มีการตั้งค่าตัวแปรสภาพแวดล้อมให้ใช้ Cloud SWP

จาก Cloud Shell

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>

ดังที่คุณเห็น คำขอ "สำเร็จ" เราคาดว่าจะเห็นการเปลี่ยนเส้นทาง 301 เนื่องจากเว็บไซต์เปลี่ยนเส้นทางไปยัง https://www.google.com

การเรียกใช้คำสั่งต่อไปนี้จะแสดงบันทึกแบบละเอียดพร้อมรายละเอียดเกี่ยวกับการเชื่อมต่อ

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

คุณลองใช้โดเมนอื่นๆ เพื่อยืนยันลักษณะการทำงานได้เช่นกัน

ออกจากเซสชัน SSH ไปยัง "clienta" แล้วเริ่มการเชื่อมต่อ SSH ใหม่ไปยัง "clientb"

gcloud compute ssh clientb --zone=$zone --tunnel-through-iap

เรียกใช้คำสั่ง curl เพื่อตรวจสอบลักษณะการทำงาน

curl https://google.com

ซึ่งควรทำงานได้ตามที่คาดไว้ใน 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>

การทดสอบกับโดเมน org

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

เราพบว่าการเข้าชมนี้ถูกปฏิเสธผ่านนโยบาย SWP ของ Cloud

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 และปฏิเสธปลายทางอื่นๆ ทั้งหมด

ออกจากไคลเอ็นต์ B

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

SSH เข้าสู่ VM ของ Compute สำหรับไคลเอ็นต์ VM นี้มีการตั้งค่าตัวแปรสภาพแวดล้อมให้ใช้ Cloud SWP

จาก Cloud Shell

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>

เราคาดว่าจะเห็นการเปลี่ยนเส้นทาง 301 เนื่องจากเว็บไซต์เปลี่ยนเส้นทางไปยัง http://www.google.com/index.html

โปรดทราบว่านี่คือคำขอ HTTP จากนั้นคุณจะต้องเปิดใช้ SWP เพื่อให้มีความสามารถในการตรวจสอบ TLS

จากนั้นเรียกใช้คำค้นหาเดียวกันผ่าน 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 คำขอแบบเต็ม
  • ขอ User-Agent

สร้างบัญชีบริการ

บัญชีบริการนี้จะมีสิทธิ์สร้างใบรับรองสำหรับการตรวจสอบ TLS ของ SWP

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

สร้างไฟล์ yaml ของการตรวจสอบ TLS

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 Pool เพื่อใช้นโยบายการออกใบรับรอง

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

อัปเดตไฟล์ YAML ของนโยบายให้รวมการตรวจสอบ TLS

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

SSH เข้าสู่ VM ของ Compute สำหรับไคลเอ็นต์ VM นี้มีการตั้งค่าตัวแปรสภาพแวดล้อมให้ใช้ Cloud SWP

จาก Cloud Shell

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>

เราตั้งค่า Cloud SWP เพื่อตรวจสอบ TLS และประเมินตรรกะของ ApplicationMatcher เรียบร้อยแล้ว

ออกจาก clienta

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 และสิทธิประโยชน์