Codelab של Cloud Secure Web Proxy (SWP)

1. מבוא

שרת Proxy מאובטח בענן

Cloud SWP הוא שירות בענן שקודם כל מיועד לענן, ומספק Secure Web Proxy מאובטח כדי לעזור לכם לאבטח תנועת אינטרנט יוצאת (HTTP/S). אתם מגדירים את הלקוחות כך שישתמשו ב-Cloud SWP כשרת proxy באופן מפורש. בקשות האינטרנט יכולות להגיע מהמקורות הבאים:

מכונות וירטואליות (VM)
קונטיינרים
סביבה ללא שרת (serverless) שמשתמשת במחבר ללא שרת (serverless)
עומסי עבודה בקישור בין רשתות שכנות (peering) של 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 (Logging). לאחר מכן תוכלו לעקוב אחר השימוש באינטרנט, לזהות איומים על הרשת ולהגיב לאיומים.

אמצעי בקרה מפורטים על מדיניות ל-Google APIs

אתם יכולים להשתמש ב-Cloud SWP כדי לספק מדיניות מפורטת לממשקי Google API. לדוגמה, אפשר להגדיר מדיניות ברמת הקטגוריה או האובייקט באמצעות Common Expression Language ‏ (CEL).

תכונות נתמכות

‫Cloud SWP תומך בתכונות הבאות:

שירות proxy מפורש

צריך להגדיר את הלקוחות באופן מפורש לשימוש בשרת ה-Proxy. ה-proxy של Cloud SWP מבודד את הלקוחות מהאינטרנט על ידי יצירת חיבורי TCP חדשים בשם הלקוח.

התאמה אוטומטית לעומס של שרתי Proxy של Cloud SWP Envoy

התכונה תומכת בהתאמה אוטומטית של גודל מאגר ה-Envoy proxy ושל הקיבולת של המאגר באזור מסוים, וכך מאפשרת ביצועים עקביים בתקופות של ביקוש גבוה בעלות הנמוכה ביותר.

מדיניות מודולרית לגישה לתעבורת נתונים יוצאת

ב-Cloud SWP יש תמיכה ספציפית במדיניות תעבורת הנתונים היוצאת (egress) הבאה:

זהות המקור מבוססת על תגים מאובטחים, חשבונות שירות או כתובות IP.
יעדים שמבוססים על כתובות URL ושמות מארחים.
בקשות שמבוססות על שיטות, כותרות או כתובות URL. אפשר לציין כתובות URL באמצעות רשימות, תווים כלליים או תבניות.
הצפנה מקצה לקצה: יכול להיות שהמנהרות של הלקוח-פרוקסי יעברו דרך TLS. ‫Cloud SWP תומך גם ב-HTTP/S CONNECT לחיבורי TLS מקצה לקצה שמופעלים על ידי הלקוח לשרת היעד.

שילוב פשוט של Cloud NAT

‫Cloud NAT מקצה באופן אוטומטי כתובות IP ציבוריות נוספות כשקבוצת השרתים הפרוקסי שמשרתים תנועה של Cloud SWP גדלה.

אפשרות נוספת היא להגדיר כתובות IP ציבוריות סטטיות באופן ידני, למי שרוצה כתובות IP ידועות ליציאה.

שילוב של יומני ביקורת של Cloud וחבילת התפעול של Google Cloud

ב-Cloud Audit Logs ובחבילת התפעול של Google Cloud מתועדות פעילויות אדמין ובקשות גישה למשאבים שקשורים ל-Cloud SWP. הם גם מתעדים מדדים ויומני עסקאות לבקשות שמטופלות על ידי ה-Proxy.

בדיקת TLS

Secure Web Proxy מציע שירות בדיקת TLS שמאפשר לכם ליירט את תעבורת ה-TLS, לבדוק את הבקשה המוצפנת ולאכוף מדיניות אבטחה.

שילוב הדוק עם Certificate Authority Service (CAS), שהוא מאגר עם זמינות גבוהה וניתן להרחבה של רשויות אישורים פרטיות.
האפשרות להשתמש ב-Root of Trust משלכם, אם נדרש. אפשר גם להשתמש ב-CA בסיסי קיים כדי לחתום על רשויות אישורים משניות שנמצאות ב-CAS. לחלופין, אפשר ליצור אישור בסיס חדש ב-CAS.
קריטריונים מפורטים לפענוח באמצעות SessionMatcher ו-ApplicationMatcher בכללי המדיניות של Secure Web Proxy. הקריטריונים האלה כוללים התאמה למארחים שמופיעים ברשימות של כתובות URL, בביטויים רגולריים, בטווחי כתובות IP ובביטויים דומים. אם צריך, אפשר לשלב קריטריונים עם ביטויים בוליאניים.
אפשר להגדיר לכל מדיניות של Secure Web Proxy מדיניות משלה לבדיקת TLS ומאגר משלה של רשויות אישורים. לחלופין, כמה כללי מדיניות של Secure Web Proxy יכולים לחלוק מדיניות אחת של בדיקת TLS.

מה תלמדו

איך פורסים ומנהלים את Cloud SWP.

הדרישות

ידע בפריסת מופעים ובהגדרת רכיבי רשת
ידע בהגדרת חומות אש של VPC

2. סביבת בדיקה

ב-codelab הזה נשתמש ב-VPC יחיד. משאב מחשוב בסביבה הזו יבצע יציאה באמצעות Cloud SWP, כפי שמוצג בתרשים שלמטה.

בשיעור ה-Lab הזה יהיו 2 מכונות וירטואליות של עומסי עבודה.

לקוח א' יוגדר לשליחת כל בקשות ה-HTTP/HTTPS אל Cloud SWP.

לקוח ב' לא יוגדר לשליחת בקשות 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, רשת משנה ורשת משנה של שרת proxy בלבד

רשת VPC

יוצרים VPC בשם codelab-swp-vpc:

gcloud compute networks create $prefix-vpc --subnet-mode=custom

Subnet

יוצרים את רשתות המשנה המתאימות באזור שנבחר:

gcloud compute networks subnets create $prefix-vpc-subnet \
   --range=10.10.10.0/24 --network=$prefix-vpc --region=$region

תת-רשת ל-Proxy בלבד

יוצרים תת-רשת של שרת proxy בלבד באזור שנבחר:

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.
מאפשר תנועה נכנסת מטווח כתובות ה-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 עבור לקוח ב'.

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. יצירת אישור והעלאה שלו ל-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"

מעלים את האישור אל 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 Gateway כדי להפנות למידע הקודם, כמו אישור, מדיניות אבטחה של שער, רשת ורשת משנה.

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 הוא proxy מפורש, צריך לציין במפורש את כתובת ה-IP של ה-proxy לתנועת עומס העבודה. במכונת הלקוח A של Compute, משתנה הסביבה יהיה מוגדר. הלקוח 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. בדיקת התאמה של ביקורים

מתחברים ב-SSH למכונה וירטואלית (VM) של Compute שנוצרה לאחרונה בשם clienta. במכונה הווירטואלית הזו משתנה הסביבה מוגדר לשימוש ב-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

הדגשה של חלק מהפלט כדי להציג את פרטי החיבור לשרת ה-proxy, האישורים והיעד.

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

הפעולה הזו אמורה לפעול כצפוי במכונה הווירטואלית clientb:

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

מתחברים באמצעות SSH למכונה וירטואלית של Compute בתור clienta. במכונה הווירטואלית הזו משתנה הסביבה מוגדר לשימוש ב-Cloud SWP.

מ-Cloud Shell:

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.

יציאה מ-clenta.

16. הפעלת בדיקת TLS

בלי בדיקת TLS, הפונקציה applicationMatcher לא תתאים לתנועת HTTPS.

המסנן applicationMatcher מאפשר סינון לפי:

מיפוי של כותרות הבקשות
שיטת בקשה
בקשת אירוח
נתיב הבקשה
שאילתה של הבקשה
סכימת בקשה
כתובת ה-URL המלאה של הבקשה
בקשת סוכן משתמש

יצירת חשבון שירות

לחשבון השירות הזה יהיו הרשאות ליצירת אישורים לבדיקת TLS של SWP.

gcloud beta services identity create \
    --service=networksecurity.googleapis.com \
    --project=$project_id

מוודאים ש-CAS מופעל

gcloud services enable privateca.googleapis.com

יצירת מאגר של רשויות אישורים

gcloud privateca pools create $prefix-ca-pool \
    --tier=devops \
    --project=$project_id \
    --location=$region

יצירת רשות אישורים (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 Inspection 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

מתן הרשאות

כך חשבון השירות יכול להשתמש במאגר רשויות האישורים כדי ליצור אישורים.

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

מ-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

מסירים את תת-הרשתות, כללי חומת האש ורשתות ה-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 והיתרונות!

Codelab של Cloud Secure Web Proxy (SWP) קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

1. מבוא

שרת Proxy מאובטח בענן

יתרונות

העברה ל-Google Cloud

גישה לשירותי אינטרנט חיצוניים מהימנים

גישה מפוקחת לשירותי אינטרנט לא מהימנים

אמצעי בקרה מפורטים על מדיניות ל-Google APIs

תכונות נתמכות

שירות proxy מפורש

התאמה אוטומטית לעומס של שרתי Proxy של Cloud SWP Envoy

מדיניות מודולרית לגישה לתעבורת נתונים יוצאת

שילוב פשוט של Cloud NAT

שילוב של יומני ביקורת של Cloud וחבילת התפעול של Google Cloud

בדיקת TLS

מה תלמדו

הדרישות

2. סביבת בדיקה

3. לפני שמתחילים

4. הפעלת ממשקי ה-API

5. יצירת רשת VPC, רשת משנה ורשת משנה של שרת proxy בלבד

6. יצירת כללים לחומת האש

7. יצירה של Cloud Router ו-Cloud NAT

8. יצירה של מדיניות אבטחה לשער

9. יצירת כלל מדיניות אבטחה של שער

10. יצירת אישור והעלאה שלו ל-Certificate Manager בענן

11. יצירת שער SWP

12. יצירת מכונות וירטואליות

13. בדיקת התאמה של ביקורים

14. עדכון כלל במדיניות אבטחה של שער עבור ApplicationMatching

15. בדיקת כלל ApplicationMatcher

16. הפעלת בדיקת TLS

יצירת חשבון שירות

מוודאים ש-CAS מופעל

יצירת מאגר של רשויות אישורים

יצירת רשות אישורים (CA) בסיסית

יצירת קובץ מדיניות להנפקת אישורים

יצירת קובץ TLS Inspection yaml

יצירת מדיניות לבדיקת TLS

עדכון מאגר אישורי ה-CA לשימוש במדיניות הנפקת האישורים

מתן הרשאות

עדכון קובץ ה-YAML של מדיניות העדכון כך שיכלול בדיקת TLS

עדכון הכללים כך שיכללו בדיקת TLS

17. בדיקת בדיקת TLS

18. שלבי הניקוי

19. מעולה!

מה נכלל

Codelab של Cloud Secure Web Proxy (SWP)