Codelab של Cloud Secure Web Proxy (SWP)

1. מבוא

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

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

• מכונות וירטואליות (VM)
• קונטיינרים
• סביבה ללא שרת (serverless) שמשתמשת במחבר ללא שרת (serverless)
• עומסי עבודה בין רשתות שכנות (peering) של VPC
• עומסי עבודה מחוץ ל-Google Cloud שמחוברים באמצעות Cloud VPN או Cloud Interconnect

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

יתרונות

בהמשך מפורטות כמה דוגמאות להטבות שאפשר להפיק מ-Cloud SWP בארגון:

העברה ל-Google Cloud

שירות Cloud SWP עוזר לבצע את ההעברה ל-Google Cloud תוך שמירה על כללי מדיניות האבטחה והדרישות הקיימים לתעבורת נתונים יוצאת (egress). תוכלו להימנע משימוש בפתרונות של צד שלישי שמחייבים מסוף ניהול אחר או מעריכה ידנית של קובצי תצורה.

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

שירות Cloud SWP מאפשר להחיל כללי מדיניות גישה מפורטים על תעבורת הנתונים היוצאת (egress) באינטרנט, כדי לאבטח את הרשת. אתם יוצרים ומזהים זהויות של עומסי עבודה או אפליקציות ואז מחילים כללי מדיניות.

גישה למעקב לשירותי אינטרנט לא מהימנים

אפשר להשתמש ב-Cloud SWP כדי לספק גישה מנוטרת לשירותי אינטרנט לא מהימנים. שירות Cloud SWP מזהה תעבורת נתונים שלא עומדת בדרישות המדיניות ורושם אותה ביומן ב-Cloud Logging (רישום ביומן). כך תוכלו לעקוב אחרי השימוש באינטרנט, לגלות איומים על הרשת ולהגיב לאיומים.

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

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

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

שירות Cloud SWP תומך בתכונות הבאות:

שירות proxy מפורש

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

שרתי proxy של Cloud SWP Envoy להתאמה לעומס (autoscaling)

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

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

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

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

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

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

אפשר גם להשתמש בכתובות IP ציבוריות סטטיות באופן ידני למי שרוצים לקבל כתובות IP ידועות של תעבורת נתונים יוצאת (egress).

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

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

בדיקת TLS

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

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

מה תלמדו

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

למה תזדקק?

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

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

ה-Codelab הזה ישתמש ברשת VPC יחידה. משאב מחשוב בסביבה הזו יבצע תעבורת נתונים יוצאת (egress) באמצעות Cloud SWP, כפי שמוצג בתרשים הבא.

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

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

לקוח ב' לא יוגדר לשליחת בקשות HTTP/HTTPS באופן מפורש ל-SWP של Cloud, אלא ישתמש ב-Cloud NAT לתעבורת נתונים שמאוגדת לאינטרנט.

הערה: שירות Cloud SWP כן תומך ב-VPC משותף, בעומסי עבודה ברשתות VPC מקושרות ובעומסי עבודה מחוץ ל-Google Cloud שמחוברים על ידי Cloud VPN או Cloud Interconnect.

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

ב-Codelab צריך להשתמש בפרויקט אחד.

ב-Inside Cloud Shell, מוודאים שמזהה הפרויקט מוגדר

הערה: אפשר לאתר את מזהה הארגון באמצעות מסוף Cloud או gcloud projects get-ancestors [project-id].

הערה: אם עבדתם בעבר עם GCP והתקנתם את gcloud, הוא מעודכן וביצעתם כבר אימות, אתם יכולים להשתמש במחשב המקומי במקום ב-Google Cloud Shell בשיעור ה-Lab הזה. אם לא צוין אחרת, צריך להריץ את כל הפקודות של gcloud ממחשב שכבר מותקן בו gcloud או 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-$[e-mail]"

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

הפעלת ממשקי ה-API לשימוש במוצרים

gcloud services enable networksecurity.googleapis.com
gcloud services enable certificatemanager.googleapis.com
gcloud services enable networkservices.googleapis.com

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

הערה: חשוב לוודא ש-Compute Engine API מופעל. אם מופיעה הודעת שגיאה באמצעות הרצת הפקודות שבהמשך או אם אתם לא בטוחים, מריצים את gcloud services enable compute.googleapis.com ומנסים שוב.

רשת 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

רשת משנה לשרת 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 להתחבר למכונות הווירטואליות, יוצרים כלל של חומת אש:

• המדיניות חלה על כל מכונות וירטואליות שרוצים לגשת אליהן באמצעות IAP.
• תעבורת נתונים נכנסת (ingress) מטווח ה-IP 35.235.240.0/20. הטווח הזה מכיל את כל כתובות ה-IP שמשמשות להעברת TCP באמצעות IAP.

מ-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 Router עבור Cloud NAT.

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

יצירת Cloud NAT Gateway ללקוח ב'.

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"

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

הערה: הכתובת מוגדרת באופן ידני בקובץ ה-yaml הזה ל-10.10.10.50. זו הכתובת שה-SWP ישתמש בה וכל עומסי העבודה יגדירו במפורש את התנועה מסוג HTTP/HTTPS לכתובת הזו:

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. יצירת מכונות מחשוב

הערה: מטעמי אבטחה, ה-Codelab הזה מניח ששרת proxy לאימות זהויות (IAP) מופעל עבור העברת TCP, כדי לאפשר גישת SSH בלי להקצות למכונות כתובות IP ציבוריות. כדי להמשיך, צריך להגדיר אותו.

Cloud SWP הוא שרת proxy מפורש, לכן צריך לציין במפורש את כתובת ה-IP של שרת ה-proxy לתעבורת נתונים של עומסי עבודה. ב-ClientA של המופע של Compute מוגדר משתנה הסביבה. לקוח ב' לא יפעל.

יוצרים את מופעי המחשוב 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) מחשובת שנוצרה לאחרונה. למכונה הווירטואלית הזו מוגדר משתנה הסביבה שמוגדר לשימוש ב-Cloud SWP.

מ-cloudshell:

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

מריצים כמה שאילתות אינטרנט כדי לאמת את הפונקציונליות. אנחנו דורשים -proxy-לא מאובטחים כי יצרנו אישור בחתימה עצמית לשיעור ה-Lab הזה:

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

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

מ-cloudshell:

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

מריצים כמה שאילתות אינטרנט כדי לאמת את הפונקציונליות. אנחנו דורשים -proxy-לא מאובטחים כי יצרנו אישור בחתימה עצמית לשיעור ה-Lab הזה:

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 המלאה של הבקשה
• בקשת סוכן משתמש

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

לחשבון השירות הזה יהיו הרשאות ליצור אישורים לבדיקת 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 

יצירת רשות אישורים ברמה הבסיסית

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

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 ל-clienta מחשוב 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!

יציאה מ-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. הגדרת ופרסת בהצלחה את Cloud Secure Web Proxy ב-Google Cloud.

הנושאים שטיפלנו בהם

• Cloud SWP וההטבות!