หน้านี้ได้รับการแปลโดย Cloud Translation API

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 SWP อาจมีต่อองค์กรมีดังนี้

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

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

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

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

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

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

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

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

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

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

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

ต้องกำหนดค่าไคลเอ็นต์ให้ใช้พร็อกซีเซิร์ฟเวอร์อย่างชัดเจน พร็อกซี Cloud SWP จะแยกไคลเอ็นต์ออกจากอินเทอร์เน็ตโดยการสร้างการเชื่อมต่อ 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 และนิพจน์ที่คล้ายกัน หากจำเป็น คุณสามารถรวมเกณฑ์กับนิพจน์บูลีนได้
นโยบายพร็อกซีเว็บที่ปลอดภัยแต่ละนโยบายสามารถกำหนดค่าได้ด้วยนโยบายการตรวจสอบ TLS และพูล CA ของตนเอง อีกทางเลือกหนึ่งคือ นโยบายพร็อกซีเว็บที่ปลอดภัยหลายนโยบายสามารถแชร์นโยบายการตรวจสอบ TLS รายการเดียวได้

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

วิธีทำให้ Cloud SWP ใช้งานได้และจัดการ

สิ่งที่ต้องมี

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

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

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

ในห้องทดลองนี้ เราจะมี VM ภาระงาน 2 รายการ

ไคลเอ็นต์ ก จะได้รับการกำหนดค่าให้ส่งคำขอ 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

จาก 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

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

สร้างใบรับรองเพื่อสิ้นสุดการรับส่งข้อมูลภาระงาน ดังนี้

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"

อัปโหลดใบรับรองไปยัง Cloud Certificate Manager เพื่อให้ 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. สร้างอินสแตนซ์การประมวลผล

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

สร้างอินสแตนซ์การประมวลผล 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 ไปยัง "clienta" 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>

คุณจะเห็นได้ว่า คำขอนี้ "สำเร็จแล้ว" เราคาดว่าเราเห็นการเปลี่ยนเส้นทาง 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 ใหม่กับ "ไคลเอ็นต์"

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>

การทดสอบกับโดเมนขององค์กร:

curl https://wikipedia.org

ซึ่งเป็นไปตามที่คาดไว้เนื่องจากไคลเอ็นต์ไม่ได้ใช้ประโยชน์จาก 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 และปลายทางอื่นๆ ทั้งหมดถูกปฏิเสธ

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

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 การประมวลผลของไคลเอ็นต์ VM นี้มีตัวแปรสภาพแวดล้อมที่ตั้งค่าให้ใช้ Cloud SWP

จาก Cloudshell:

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

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

ออกจาก Claenta

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

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 การประมวลผลไคลเอ็นต์ 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>

เราตั้งค่า Cloud SWP เพื่อตรวจสอบ TLS และประเมินตรรกะ applicationMatcher สำเร็จแล้ว

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

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

นำซับเน็ต กฎเฟิร์มแวร์ และ 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 จนจบ คุณกำหนดค่าและติดตั้งใช้งาน Cloud Secure Web Proxy ใน Google Cloud เรียบร้อยแล้ว

สรุปประเด็นที่ได้พูดถึง

Cloud SWP และประโยชน์ต่างๆ