מדיניות חומת אש היררכית עם תגים שמנוהלים על ידי IAM

1. מבוא

Cloud Next Generation Firewall ‏ (NGFW)

Cloud Next Generation Firewall הוא שירות חומת אש מבוזרת לחלוטין עם יכולות הגנה מתקדמות, מיקרו-פילוח וכיסוי נרחב, שמטרתו להגן על עומסי העבודה שלכם ב-Google Cloud מפני מתקפות פנימיות וחיצוניות.

היתרונות של Cloud NGFW:

שירות חומת אש מבוזרת: Cloud NGFW מספק אכיפה מבוססת-מארח ומבוזרת לחלוטין בכל עומס עבודה, כדי לאפשר ארכיטקטורת אבטחה של אפס אמון.
הגדרה ופריסה פשוטות: Cloud NGFW מטמיע מדיניות חומת אש היררכית ורשתית שאפשר לצרף לצומת בהיררכיית המשאבים. המדיניות הזו מספקת חוויה עקבית של חומת אש בהיררכיית המשאבים של Google Cloud.
שליטה גרנולרית ומיקרו-פילוח: השילוב של מדיניות חומת אש ותגיות שמנוהלות על ידי ניהול זהויות והרשאות גישה (IAM) מספק שליטה מדויקת בתעבורה מצפון לדרום וממזרח למערב, עד לרמת המכונה הווירטואלית הבודדת, ברשתות של ענן וירטואלי פרטי (VPC).

מדיניות חומת אש בין רשתות

מדיניות חומת אש בין רשתות פועלת כקונטיינר לכללי חומת אש. כללים שמוגדרים במדיניות חומת אש בין רשתות לא נאכפים בשום מקום עד שהמדיניות משויכת לרשת VPC. לכל רשת VPC יכולה להיות משויכת מדיניות חומת אש אחת. מדיניות חומת אש בין רשתות תומכת בתגים שמנוהלים על ידי IAM (או פשוט בתגים) בכללי חומת האש, ואפשר להשתמש בה כדי לספק זהות לעומס עבודה.

שיתוף מדיניות חומת אש בין רשתות ברשתות ושילוב עם תגים שמנוהלים על ידי IAM מפשטים מאוד את ההגדרה והניהול של חומות אש.

עם ההשקה של מדיניות חומת אש בין רשתות, מדיניות חומת האש של Google Cloud כוללת עכשיו את הרכיבים הבאים:

מדיניות חומת אש היררכית נתמכת בצמתים של ארגונים ותיקיות בהיררכיית המשאבים, בעוד שכללי חומת אש של VPC ומדיניות חומת אש בין רשתות חלים ברמת ה-VPC. ההבדל העיקרי בין כללי חומת אש של VPC לבין מדיניות חומת אש בין רשתות הוא שכללי חומת אש של VPC אפשר להחיל רק על רשת VPC אחת, בעוד שמדיניות חומת אש בין רשתות אפשר לצרף לרשת VPC אחת או לקבוצה של רשתות VPC, בין היתר כדי לבצע חבילת עדכונים.

בשיעור Lab הזה נבדוק את מדיניות חומת האש ההיררכית ואת מדיניות חומת האש הגלובלית ברשת.

בנוסף, יש לנו גם את כללי חומת האש המשתמעים שמגיעים עם כל רשת VPC:

כלל יציאה שהפעולה שלו היא 'אישור' והיעד הוא 0.0.0.0/0
כלל כניסה שהפעולה שלו היא דחייה, והמקור הוא 0.0.0.0/0

כברירת מחדל, רצף האכיפה מוצג בדיאגרמה הבאה:

תגים שמנוהלים על ידי IAM

התכונה החדשה תגים שמשולבים בכללים של מדיניות חומת האש היא משאבים של צמדי מפתח/ערך שמוגדרים ברמת הארגון או הפרויקט בהיררכיית המשאבים של Google Cloud. תג כזה מכיל בקרת גישה של IAM, כפי שהשם מרמז, שמציינת למי יש הרשאה לבצע פעולות בתג. לדוגמה, הרשאות IAM מאפשרות לציין אילו חשבונות משתמשים יכולים להקצות ערכים לתגים ואילו חשבונות משתמשים יכולים לצרף תגים למשאבים. אחרי שמחילים תג על משאב, כללים של מדיניות חומת האש יכולים להשתמש בו כדי לאפשר או לדחות תעבורה.

התגים פועלים לפי מודל ירושת המשאבים של Google Cloud, כלומר התגים והערכים שלהם מועברים בהיררכיה מההורים שלהם. כתוצאה מכך, יכול להיות שתגים ייווצרו במקום אחד ואז ישמשו תיקיות ופרויקטים אחרים בהיררכיית המשאבים. בדף הזה אפשר למצוא פרטים נוספים על תגים והגבלת גישה.

אין לבלבל בין תגים לבין תגים ברשת. תגים ברשת הם מחרוזות שאפשר להוסיף למכונות של Compute Engine. הם משויכים למכונה ונעלמים כשמוציאים את המכונה משימוש. כללי חומת האש של VPC עשויים לכלול תגי רשת, אבל מכיוון שהם לא נחשבים למשאבי ענן, הם לא כפופים לבקרת גישה של IAM. לפרטים על ההבדל, אפשר לעבור אל הדף הזה.

2. מה תלמדו

איך יוצרים תגים שמנוהלים על ידי IAM לשימוש ב-Cloud NGFW ועם היקף גלובלי.
איך מצרפים תגים למכונות וירטואליות.
איך יוצרים מדיניות היררכית של חומת אש ומשייכים אותה לתיקייה.
איך יוצרים כלל לחומת האש במדיניות היררכית של חומת האש ומציינים מקור ויעד באמצעות תגים שמנוהלים על ידי IAM.

3. ארכיטקטורת Lab כוללת

ארגון ותיקיות:

יוצרים שתי תיקיות, folder1 ו-folder2, ישירות מתחת לארגון.

פרויקטים:

בתוך folder1, תיצרו פרויקט מארח. הפרויקט הזה יכיל את רשת ה-VPC המשותפת.
בתוך folder2, תיצרו פרויקט שירות. הפרויקט הזה יכיל את מכונות ה-VM שמשתמשות ב-VPC המשותף.

Networking:

רשת VPC בשם mynet תיצור בפרויקט המארח ותוגדר כVPC משותף. כך משאבים בפרויקט השירות יכולים להשתמש ברשת.
שתי מכונות וירטואליות ייווצרו בפרויקט השירות ויחוברו ל-VPC המשותף mynet.

תגים שמנוהלים על ידי IAM:

תצרו תג בשם http_tags שמנוהל על ידי IAM עם שני ערכים, שמות http_server ו-http_client ברמת הארגון. התגים והערכים האלה ישמשו לזיהוי המכונות הווירטואליות ולהחלת כללי חומת האש עליהן.

מדיניות חומת אש:

תיצור מדיניות חומת אש היררכית ותשייך אותה ל-folder1. כלל במדיניות הזו ישתמש בתגים שמנוהלים על ידי IAM כדי לאפשר תעבורת נתונים מ-http-client אל http-server ביציאה 80.
מדיניות חומת אש לרשת תיצור בפרויקט המארח ותשויך ל-VPC מספר mynet. המדיניות הזו תכלול כלל שיאפשר גישת IAP SSH למכונות הווירטואליות למטרות בדיקה.

4. שלבי ההכנה

קודם צריך להגדיר את תפקידי ה-IAM הנדרשים, את תשתית הרשת ואת המופעים בארגון Google Cloud.

תפקידי IAM שנדרשים כדי לעבוד על ה-Lab

מתחילים בהקצאת תפקידי IAM הנדרשים לחשבון GCP ברמת הארגון.

אדמין ארגוני (roles/resourcemanager.organizationAdmin) התפקיד הזה מאפשר לכם לנהל מדיניות IAM ולצפות במדיניות ארגונית עבור ארגונים, תיקיות ופרויקטים.
אדמין לניהול תגים(roles/resourcemanager.tagAdmin) התפקיד הזה מאפשר ליצור, לעדכן ולמחוק תגים מאובטחים.
התפקיד 'משתמש בתג' (roles/resourcemanager.tagUser) מאפשר לכם לגשת לרשימת התגים המאובטחים ולנהל את השיוכים שלהם למשאבים.
התפקיד 'אדמין של מדיניות חומת אש בארגון' ב-Compute ‏ (roles/compute.orgFirewallPolicyAdmin) – התפקיד הזה מאפשר לכם שליטה מלאה במדיניות חומת האש בארגון ב-Compute Engine.
התפקיד 'אדמין של משאב ארגוני של Compute' ‏ (roles/compute.orgSecurityResourceAdmin) – התפקיד הזה מעניק לכם שליטה מלאה בשיוכים של מדיניות חומת האש של Compute Engine לארגון או לתיקייה.
אדמין של רשת מחשוב (roles/compute.networkAdmin) התפקיד הזה מעניק לכם שליטה מלאה במשאבי הרשת של Compute Engine.
אדמין מכונות של Compute ‏( beta) (roles/compute.instanceAdmin) התפקיד הזה מעניק לכם שליטה מלאה במשאבי מכונות של Compute Engine.
אדמין של רישום ביומן (roles/logging.admin) התפקיד הזה מעניק גישה לכל ההרשאות שקשורות לרישום ביומן, ולהרשאות שתלויות בהן.
אדמין של חשבון שירות (roles/iam.serviceAccountAdmin) התפקיד הזה מאפשר ליצור ולנהל חשבונות שירות.
אדמין בממשק 'שימוש בשירות' (roles/serviceusage.serviceUsageAdmin) התפקיד הזה מאפשר להפעיל, להשבית ולבדוק את מצבי השירות, לבדוק פעולות ולצרוך מכסות וחיובים בפרויקט צרכן.
אדמין של VPC משותף ב-Compute ‏ (roles/compute.xpnAdmin) התפקיד הזה מאפשר לכם לנהל רשת VPC משותפת (XPN).

יצירת תיקיות ופרויקטים

ב-Cloud Shell, מבצעים את הפעולות הבאות כדי ליצור את folder1 ואת folder2:

gcloud auth login

export org_id=$(gcloud organizations list --format='value(ID)')
export BILLING_ACCOUNT_ID=$(gcloud billing accounts list --format='value(ACCOUNT_ID)')
export folder1=[FOLDER1 NAME]
export folder2=[FOLDER2 NAME]
export hostproject=[HOST PROJECT NAME]
export serviceproject=[SERVICE PROJECT NAME]
export regionname=[REGION NAME]
export zonename=[COMPUTE ZONE NAME]

gcloud resource-manager folders create --display-name=$folder1 --organization=$org_id
export folder1_id=$(gcloud resource-manager folders list --organization=$org_id --filter="displayName=$folder1" --format="value(ID)")
gcloud resource-manager folders create --display-name=$folder2 --organization=$org_id
export folder2_id=$(gcloud resource-manager folders list --organization=$org_id --filter="displayName=$folder2" --format="value(ID)")

ב-Cloud Shell, מבצעים את הפעולות הבאות כדי ליצור את פרויקט המארח בקטע folder1:

gcloud projects create  --name=$hostproject --folder=$folder1_id

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

No project ID provided.

Use [NEW-PROJECT-ID] as project ID (Y/n)?

רושמים את מזהה הפרויקט. ב-Cloud Shell, מבצעים את הפעולות הבאות כדי לייצא אותו אל hostproject_id:

export hostproject_id=[HOSTPROJECT ID]

ב-Cloud Shell, מבצעים את הפעולות הבאות כדי לקשר את פרויקט המארח לחשבון לחיוב:

gcloud billing projects link $hostproject_id \
--billing-account=$BILLING_ACCOUNT_ID

ב-Cloud Shell, מבצעים את הפעולות הבאות כדי ליצור את פרויקט השירות ב-folder2:

gcloud projects create  --name=$serviceproject --folder=$folder2_id

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

No project ID provided.

Use [NEW-PROJECT-ID] as project ID (Y/n)?

רושמים את מזהה הפרויקט. ב-Cloud Shell, מבצעים את הפעולות הבאות כדי לייצא אותו אל serviceproject_id:

export serviceproject_id=[SERVICEPROJECT ID]

ב-Cloud Shell, מבצעים את הפעולות הבאות כדי לקשר את פרויקט השירות לחשבון לחיוב:

gcloud billing projects link $serviceproject_id \
--billing-account=$BILLING_ACCOUNT_ID

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

תג הוא צמד מפתח/ערך שאפשר לצרף לארגון, לתיקייה או לפרויקט. מידע נוסף זמין במאמרים בנושא יצירה וניהול של תגים וההרשאות הנדרשות.

אנחנו יוצרים תג אחד ברמת הארגון, http-tags. מטרת התג היא שימוש ב-Cloud NGFW. אנחנו לא מגבילים את ההיקף לרשת אחת – התג הוא בהיקף גלובלי. בהמשך נחיל את התג על מכונות וירטואליות שנוצרו בפרויקט השירות בקטע folder2.

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud resource-manager tags keys create http_tags \
    --parent=organizations/$org_id \
    --purpose GCE_FIREWALL \
    --purpose-data organization=auto

נשתמש במזהה מפתח התג כדי להוסיף הערה למכונה הווירטואלית במהלך היצירה. ב-Cloud Shell, מבצעים את הפעולות הבאות כדי לקבל את מזהה מפתח התג:

export http_tags_id=$(gcloud resource-manager tags keys describe $org_id/http_tags --format="value(name)")
echo $http_tags_id

ב-Cloud Shell, מבצעים את הפעולות הבאות כדי ליצור שני ערכי תגים חדשים, http_server ו-http_client:

 gcloud resource-manager tags values create http_server \
      --parent $org_id/http_tags
 gcloud resource-manager tags values create http_client \
      --parent $org_id/http_tags

אנחנו נשתמש במזהה התג ובמזהה ערך התג כדי להוסיף הערות למכונה הווירטואלית במהלך היצירה. ב-Cloud Shell, מבצעים את הפעולות הבאות כדי לקבל את מזהה ערך התג של http_server ושל http_client:

export http_tags_http_server_id=$(gcloud resource-manager tags values describe $org_id/http_tags/http_server --format="value(name)")
echo $http_tags_http_server_id

export http_tags_http_client_id=$(gcloud resource-manager tags values describe $org_id/http_tags/http_client --format="value(name)")
echo $http_tags_http_client_id

הפעלת ממשקי API בפרויקט המארח ובפרויקט השירות

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud services enable compute.googleapis.com --project=$serviceproject_id
gcloud services enable compute.googleapis.com --project=$hostproject_id

יצירת VPC בפרויקט המארח

בפרויקט המארח, יוצרים רשת VPC עם מצב תת-רשת מותאם אישית. כדי לעשות זאת, מריצים את הפקודות הבאות ב-Cloud Shell:

gcloud compute networks create mynet \
    --subnet-mode=custom \
    --project=$hostproject_id

יצירת רשתות משנה בפרויקט המארח

ב-Cloud Shell, מבצעים את הפעולות הבאות כדי ליצור תת-רשת IPv4:

gcloud compute networks subnets create mysubnet \
    --network=mynet \
    --range=10.0.0.0/28 \
    --region=$regionname \
    --project=$hostproject_id

הפעלת VPC משותף בפרויקט המארח

ב-Cloud Shell, מבצעים את הפעולות הבאות כדי להפעיל VPC משותף בפרויקט המארח:

gcloud compute shared-vpc enable $hostproject_id

צירוף פרויקט שירות ל-VPC משותף בפרויקט המארח

ב-Cloud Shell, מבצעים את הפעולות הבאות כדי לצרף פרויקט שירות ל-VPC משותף בפרויקט המארח:

gcloud compute shared-vpc associated-projects add $serviceproject_id --host-project=$hostproject_id

יצירת Cloud Router ו-Cloud NAT בפרויקט המארח

משתמשים ב-Cloud NAT כדי לאפשר יציאה של מכונות וירטואליות לאינטרנט, כדי להוריד ולהתקין אפליקציות.

gcloud compute routers create $regionname-cr \
   --network=mynet \
   --region=$regionname \
   --project=$hostproject_id
gcloud compute routers nats create $regionname-nat \
    --router=$regionname-cr \
    --region=$regionname \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips \
    --project=$hostproject_id

יצירת מופעים בפרויקט השירות

בפרויקט השירות, יוצרים שתי מכונות וירטואליות בתת-הרשתות שיצרתם ב-VPC המשותף בפרויקט המארח. מופע אחד נקרא http-server, ואנחנו מוסיפים לתג של http_tags את הערך של http_server. המופע השני נקרא http-client ואנחנו מוסיפים הערה לתג של http_tags עם הערך של http_client. מריצים את הפקודות הבאות ב-Cloud Shell:

gcloud compute instances create http-client \
    --project=$serviceproject_id \
   --subnet=projects/$hostproject_id/regions/$regionname/subnetworks/mysubnet \
    --zone=$zonename \
    --no-address \
    --resource-manager-tags=$http_tags_id=$http_tags_http_client_id

gcloud compute instances create http-server \
    --project=$serviceproject_id \
    --subnet=projects/$hostproject_id/regions/$regionname/subnetworks/mysubnet \
    --zone=$zonename \
    --no-address \
    --resource-manager-tags=$http_tags_id=$http_tags_http_server_id \
    --metadata startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    a2enmod ssl
    sudo a2ensite default-ssl
    echo "I am a Http Server." | \
    tee /var/www/html/index.html
    systemctl restart apache2'

רושמים את כתובת ה-IP הפנימית של http-server. נשתמש בו בשלב הבא של בדיקת כלל חומת האש.

export http_server_ip=$(gcloud compute instances describe http-server --zone $zonename --format='value(networkInterfaces[0].networkIP)' --project $serviceproject_id)
echo $http_server_ip

5. יצירת מדיניות חומת אש גלובלית ברשת בפרויקט המארח

ניצור מדיניות חומת אש גלובלית ברשת בפרויקט המארח ונשייך אותה ל-VPC המשותף בפרויקט המארח.

gcloud config set project $hostproject_id
gcloud compute network-firewall-policies create  mynet-fw-policy \
--global \
--project=$hostproject_id
gcloud compute network-firewall-policies associations create \
    --firewall-policy=mynet-fw-policy \
    --network=mynet \
    --name=mynet-fw-policy \
    --global-firewall-policy \
    --project=$hostproject_id

כדי לאפשר ל-IAP להתחבר למכונות הווירטואליות, יוצרים כלל חומת אש במדיניות חומת האש של הרשת:

רלוונטי לכל מכונות ה-VM שרוצים לגשת אליהן באמצעות IAP.
מאפשר תנועה נכנסת מטווח כתובות ה-IP‏ 35.235.240.0/20. הטווח הזה מכיל את כל כתובות ה-IP שמשמשות את IAP להעברת TCP.

gcloud compute network-firewall-policies rules create 1000 \
    --action=ALLOW \
    --firewall-policy=mynet-fw-policy \
    --description="mynet-allow-iap" \
    --direction=INGRESS \
    --src-ip-ranges=35.235.240.0/20 \
    --layer4-configs=tcp:22  \
    --global-firewall-policy \
    --project=$hostproject_id

במסוף, אפשר לעבור לפרויקט המארח ולמצוא את מדיניות חומת אש בין רשתות הגלובלית החדשה שנוצרה בקטע Firewall Policy (מדיניות חומת אש). אפשר לבדוק את כלל חומת האש החדש שנוצר במדיניות חומת האש של הרשת. זה הקישור למסוף. חשוב לוודא ששיניתם את הפרויקט בכלי לבחירת פרויקטים לפרויקט המארח במסוף.

6. בדיקת הגישה ממכונה וירטואלית של לקוח HTTP למכונה וירטואלית של שרת HTTP

מתחברים ל-VM בשם http-client באמצעות SSH ובודקים אם יש לו גישה ל-http-server ביציאה 80 של HTTP.

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute ssh \
    --zone=$zonename "http-client" \
    --tunnel-through-iap \
    --project=$serviceproject_id

משתמשים ב-curl כדי לגשת לשרת האינטרנט.

curl -m 10 [http_server_ip]

תוצג לכם התוצאה של פקודת curl. אין כלל חומת אש לתעבורת נתונים נכנסת (ingress) שמאפשר יציאה 80 עבור http-server.

תם הזמן הקצוב לתפוגה של החיבור אחרי 10,000 אלפיות השנייה.

כדי לחזור ל-Cloud Shell, יוצאים מסשן ה-SSH.

exit

7. יצירה של מדיניות היררכית של חומת אש וכללים לחומת האש

ניצור מדיניות היררכית של חומת אש ב-folder1 ונשייך את המדיניות ל-folder1. כללי חומת האש במדיניות יחולו על פרויקט המארח בקטע folder1.

יצירת מדיניות היררכית של חומת אש

gcloud compute firewall-policies create \
  --folder=$folder1_id \
  --short-name=my-folder1-fw-policy

יצירת כלל לחומת האש במדיניות היררכית של חומת האש

הכלל מאפשר למכונות וירטואליות עם ערך תג של http_tags/http_client לגשת למכונות וירטואליות עם ערך תג של http_tags/http_server ביציאת TCP‏ 80.

gcloud compute firewall-policies rules create 100 \
  --organization=$org_id \
  --firewall-policy my-folder1-fw-policy \
  --direction=INGRESS \
  --layer4-configs=tcp:80 \
  --action=allow \
  --src-secure-tags=$org_id/http_tags/http_client \
  --target-secure-tags=$org_id/http_tags/http_server \
  --description=folder1-allow-http

שיוך מדיניות חומת אש היררכית לתיקייה folder1

gcloud compute firewall-policies associations create \
   --firewall-policy=my-folder1-fw-policy \
   --folder=$folder1_id \
   --name=my-folder1-fw-policy\
   --organization=$org_id

במסוף, אפשר לעבור אל folder1 ולמצוא את מדיניות חומת האש ההיררכית החדשה בקטע Firewall Policy (מדיניות חומת אש). מדיניות חומת האש מוצגת בקטע 'מדיניות חומת האש שנמצאת בתיקייה הזו'. אפשר לבדוק את כלל חומת האש החדש שנוצר במדיניות ההיררכית של חומת האש. זה הקישור למסוף. צריך לוודא שמשנים את בורר הפרויקטים ל-folder1 במסוף.

8. בדיקת הגישה ממכונה וירטואלית של לקוח HTTP למכונה וירטואלית של שרת HTTP

בודקים את מדיניות חומת האש האפקטיבית שחלה על ה-VPC המשותף בפרויקט המארח.

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute networks get-effective-firewalls mynet --project=$hostproject_id

מדיניות חומת האש ההיררכית שמועברת בירושה תיראה כך:

TYPE: org-firewall
FIREWALL_POLICY_NAME: <NUMBER_FOR_YOUR_FW_POLICY>
FIREWALL_POLICY_PRIORITY: 
PRIORITY: 100
ACTION: ALLOW
DIRECTION: INGRESS
DISABLED: False
IP_RANGES:

You will see the network firewall policy to the VPC like this:
TYPE: network-firewall-policy
FIREWALL_POLICY_NAME: mynet-fw-policy
FIREWALL_POLICY_PRIORITY: 1000
PRIORITY: 1000
ACTION: ALLOW
DIRECTION: INGRESS
DISABLED: False
IP_RANGES: 35.235.240.0/20

מתחברים ל-VM בשם http-client באמצעות SSH ובודקים אם יש לו גישה ל-http-server ביציאה 80 של HTTP.

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute ssh \
    --zone=$zonename "http-client" \
    --tunnel-through-iap \
    --project=$serviceproject_id

משתמשים ב-curl כדי לגשת לשרת האינטרנט.

curl [http_server_ip]

פקודת curl תחזיר תשובה מ-http-server בהצלחה.

I am a Http Server.

כלל חומת אש לתעבורת נתונים נכנסת (ingress) ממדיניות חומת אש היררכית מאפשר גישה מ-http-client אל http-server ביציאה 80.

כדי לחזור ל-Cloud Shell, יוצאים מסשן ה-SSH.

exit

9. הסרת המשאבים

פינוי מקום במכונות הווירטואליות בפרויקט השירות

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute instances delete http-server --zone $zonename --project=$serviceproject_id
gcloud compute instances delete http-client --zone $zonename --project=$serviceproject_id

ניקוי מדיניות חומת אש היררכית

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute firewall-policies associations delete my-folder1-fw-policy \
   --firewall-policy=my-folder1-fw-policy \
   --organization=$org_id
gcloud compute firewall-policies rules delete 100 \
  --organization=$org_id \
  --firewall-policy=my-folder1-fw-policy
gcloud compute firewall-policies delete my-folder1-fw-policy \
  --organization=$org_id

ניקוי תגים ברמת הארגון

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud resource-manager tags values delete $http_tags_http_server_id
gcloud resource-manager tags values delete $http_tags_http_client_id
gcloud resource-manager tags keys delete $http_tags_id

ניקוי פרויקט המארח

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute shared-vpc associated-projects remove $serviceproject_id --host-project=$hostproject_id 
gcloud compute shared-vpc disable $hostproject_id
gcloud projects delete $hostproject_id

פינוי מקום בפרויקט

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud projects delete $serviceproject_id

ניקוי התיקיות

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud resource-manager folders delete $folder1_id
gcloud resource-manager folders delete $folder2_id

10. מזל טוב

הצלחתם לבדוק מדיניות חומת אש היררכית עם תגים שמנוהלים על ידי IAM.

מדיניות חומת אש היררכית עם תגים שמנוהלים על ידי IAM קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

1. מבוא

Cloud Next Generation Firewall ‏ (NGFW)

מדיניות חומת אש בין רשתות

תגים שמנוהלים על ידי IAM

2. מה תלמדו

3. ארכיטקטורת Lab כוללת

4. שלבי ההכנה

תפקידי IAM שנדרשים כדי לעבוד על ה-Lab

יצירת תיקיות ופרויקטים

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

הפעלת ממשקי API בפרויקט המארח ובפרויקט השירות

יצירת VPC בפרויקט המארח

יצירת רשתות משנה בפרויקט המארח

יצירת Cloud Router ו-Cloud NAT בפרויקט המארח

יצירת מופעים בפרויקט השירות

5. יצירת מדיניות חומת אש גלובלית ברשת בפרויקט המארח

6. בדיקת הגישה ממכונה וירטואלית של לקוח HTTP למכונה וירטואלית של שרת HTTP

7. יצירה של מדיניות היררכית של חומת אש וכללים לחומת האש

יצירת מדיניות היררכית של חומת אש

יצירת כלל לחומת האש במדיניות היררכית של חומת האש

שיוך מדיניות חומת אש היררכית לתיקייה folder1

8. בדיקת הגישה ממכונה וירטואלית של לקוח HTTP למכונה וירטואלית של שרת HTTP

9. הסרת המשאבים

פינוי מקום במכונות הווירטואליות בפרויקט השירות

ניקוי מדיניות חומת אש היררכית

ניקוי תגים ברמת הארגון

ניקוי פרויקט המארח

פינוי מקום בפרויקט

ניקוי התיקיות

10. מזל טוב

מדיניות חומת אש היררכית עם תגים שמנוהלים על ידי IAM