הגדרת גבולות גזרה של VPC Service Controls לרשת של ענן וירטואלי פרטי (VPC)

איך מגדירים גבולות גזרה לשירות באמצעות VPC Service Controls. במדריך הזה נעשה שימוש בהגדרות רשת כמו חומות אש, Private Service Connect והגדרות DNS שנדרשות כדי להשתמש ביעילות בפרימטר של VPC Service Controls. בהמשך המדריך מוסבר איך מאשרים או דוחים שירותים, ואיך יוצרים חריגים מפורטים לרשימת ההיתרים של שירותים ספציפיים.

מטרות

• כדי לצמצם את הסיכונים לזליגת נתונים, מגדירים גבולות גזרה לשירות באמצעות VPC Service Controls עם אמצעי בקרה נוספים על הרשת.
• לאשר או לדחות גישה לשירותים בתוך הגבולות של הגזרה מבקשות שמקורן בתוך הגבולות של הגזרה או מחוץ לגבולות של הגזרה.
• לאפשר או לחסום גישה לשירותים מחוץ לגבולות הגזרה מבקשות שמקורן בתוך גבולות הגזרה.
• להשתמש במדיניות הארגונית Restrict Resource Service Usage וב-VPC Service Controls ביחד.

עלויות

במדריך הזה השתמשנו ברכיבים הבאים של Cloud de Confiance by S3NS, והשימוש בהם כרוך בתשלום:

• Compute Engine
• Cloud Storage
• ‫Private Service Connect

כדי ליצור הערכת עלויות בהתאם לשימוש החזוי, אתם יכולים להשתמש במחשבון התמחור.

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

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

1. כדי לבצע את ההדרכה הזו, צריך פרויקט בארגון. אם עדיין אין לכם Cloud de Confiance ארגון, מומלץ לקרוא את המאמר בנושא יצירה וניהול של ארגון.

2. בדף לבחירת הפרויקט במסוף Cloud de Confiance , בוחרים פרויקט ב- Cloud de Confiance או יוצרים אותו.

   תפקידים שנדרשים כדי לבחור או ליצור פרויקט

   • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
   • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

   כניסה לדף לבחירת הפרויקט

3. מוודאים שהחיוב מופעל בפרויקט Cloud de Confiance .

4. מפעילים את ממשקי ה-API של Compute Engine,‏ Access Context Manager ו-Cloud DNS, אם הם עדיין לא מופעלים.

   התפקידים שנדרשים כדי להפעיל ממשקי API

   כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

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

5. במסוף Cloud de Confiance , מפעילים את Cloud Shell.

   הפעלת Cloud Shell

6. צריך לוודא שיש לכם בארגון את התפקיד או התפקידים הבאים: אדמין של Access Context Manager, אדמין של מדיניות הארגון

   בדיקת התפקידים

   1. נכנסים לדף IAM במסוף Cloud de Confiance .

      כניסה לדף IAM
   2. בוחרים את הארגון.

   3. בעמודה Principal, מחפשים את כל השורות שמזהות אתכם או קבוצה שאתם נכללים בה. כדי לדעת באילו קבוצות אתם נכללים, פנו לאדמין.

   4. בודקים את העמודה Role בכל השורות שבהן מצוין או מופיע השם שלכם, כדי לראות אם רשימת התפקידים כוללת את התפקידים הנדרשים.

   מתן התפקידים

   1. נכנסים לדף IAM במסוף Cloud de Confiance .

      כניסה לדף IAM
   2. בוחרים את הארגון.
   3. לוחצים על person_addGrant access.

   4. בשדה New principals, מזינים את מזהה המשתמש. ‫ בדרך כלל זה המזהה של משתמש במאגר זהויות של כוח עבודה. למידע נוסף, קראו את המאמר ייצוג המשתמשים במאגרי כוח עבודה בכללי מדיניות IAM או פנו לאדמין שלכם.

   5. לוחצים על Select a role ומחפשים את התפקיד.
   6. כדי לתת עוד תפקידים, לוחצים על add Add another role ומוסיפים אותם.
   7. לוחצים על Save.

7. מוודאים שיש לכם את התפקידים הבאים בפרויקט: אדמין של Compute, אדמין של DNS, משתמש מנהרה באבטחת IAP, משתמש בחשבון שירות, עריכה של Service Directory

   בדיקת התפקידים

   1. נכנסים לדף IAM במסוף Cloud de Confiance .

      כניסה לדף IAM
   2. בוחרים את הפרויקט.

   3. בעמודה Principal, מחפשים את כל השורות שמזהות אתכם או קבוצה שאתם נכללים בה. כדי לדעת באילו קבוצות אתם נכללים, פנו לאדמין.

   4. בודקים את העמודה Role בכל השורות שבהן מצוין או מופיע השם שלכם, כדי לראות אם רשימת התפקידים כוללת את התפקידים הנדרשים.

   מתן התפקידים

   1. נכנסים לדף IAM במסוף Cloud de Confiance .

      כניסה לדף IAM
   2. בוחרים את הפרויקט.
   3. לוחצים על person_addGrant access.

   4. בשדה New principals, מזינים את מזהה המשתמש. ‫ בדרך כלל זה המזהה של משתמש במאגר זהויות של כוח עבודה. למידע נוסף, קראו את המאמר ייצוג המשתמשים במאגרי כוח עבודה בכללי מדיניות IAM או פנו לאדמין שלכם.

   5. לוחצים על Select a role ומחפשים את התפקיד.
   6. כדי לתת עוד תפקידים, לוחצים על add Add another role ומוסיפים אותם.
   7. לוחצים על Save.

הגדרת ההיקף של VPC Service Controls

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

הכנת רשת ה-VPC

בקטע הזה מגדירים קישוריות פרטית לממשקי Google APIs ולשירותים של Google ברשת ה-VPC כדי לצמצם את מגוון הנתיבים ליציאה מהרשת לאינטרנט.

1. מגדירים משתנים ב-Cloud Shell:

   gcloud config set project PROJECT_ID
   gcloud config set compute/region REGION
   gcloud config set compute/zone ZONE

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫PROJECT_ID: מזהה הפרויקט שבו תיצרו משאבים
   • ‫REGION: אזור שקרוב למיקום שלכם – לדוגמה, us-central1
   • ‫ZONE: אזור שקרוב למיקום שלכם – לדוגמה, us-central1-a

2. יוצרים רשת VPC ותת-רשת עם גישה פרטית ל-Google:

   gcloud compute networks create restricted-vpc --subnet-mode=custom
   gcloud compute networks subnets create restricted-subnet \
   --range=10.0.0.0/24 \
   --network=restricted-vpc \
   --enable-private-ip-google-access

3. יוצרים נקודת קצה של Private Service Connect וכלל העברה שמוגדר לשימוש בחבילת vpc-sc:

   gcloud compute addresses create restricted-psc-endpoint \
   --global \
   --purpose=PRIVATE_SERVICE_CONNECT \
   --addresses=10.0.1.1 \
   --network=restricted-vpc
   
   gcloud compute forwarding-rules create restrictedpsc \
   --global \
   --network=restricted-vpc \
   --address=restricted-psc-endpoint \
   --target-google-apis-bundle=vpc-sc

4. מגדירים את מדיניות השרת של Cloud DNS כך שתפנה שאילתות לממשקי Google Cloud API לנקודת הקצה של Private Service Connect:

   gcloud dns managed-zones create restricted-dns-zone \
     --description="Private DNS Zone to map Google API queries to the Private Service Connect endpoint for Google APIs" \
     --dns-name="googleapis.com." \
     --networks=restricted-vpc \
     --visibility=private
   
   gcloud dns record-sets create googleapis.com  \
   --rrdatas=10.0.1.1 \
   --type=A \
   --ttl=300 \
   --zone=restricted-dns-zone
   
   gcloud dns record-sets create *.googleapis.com  \
   --rrdatas="googleapis.com." \
   --type=CNAME \
   --ttl=300 \
   --zone=restricted-dns-zone

5. מגדירים כלל של חומת אש בעדיפות נמוכה כדי לחסום את כל תעבורת הנתונים היוצאת:

   gcloud compute firewall-rules create deny-all-egress \
   --priority=65534 \
   --direction=egress \
   --network=restricted-vpc \
   --action=DENY \
   --rules=all \
   --destination-ranges=0.0.0.0/0

6. מגדירים כלל של חומת אש בעדיפות גבוהה יותר כדי לאפשר לתעבורת הנתונים להגיע לכתובת ה-IP שמשמשת את נקודת הקצה של Private Service Connect:

   gcloud compute firewall-rules create allow-psc-for-google-apis \
   --priority=1000 \
   --direction=egress \
   --network=restricted-vpc \
   --action=ALLOW \
   --rules=tcp:443 \
   --destination-ranges=10.0.1.1

   כללי חומת האש האלה דוחים תעבורת נתונים יוצאת באופן נרחב, לפני שהם מאפשרים באופן סלקטיבי תעבורת נתונים יוצאת לנקודת הקצה של Private Service Connect. ההגדרה הזו דוחה תעבורת נתונים יוצאת לדומיינים שמוגדרים כברירת מחדל, שבדרך כלל אפשר להגיע אליהם כברירת מחדל באמצעות גישה פרטית ל-Google וכללי חומת האש המשתמעים.

יצירת גבול גזרה לשירות ב-VPC Service Controls

בקטע הזה, יוצרים גבולות גזרה לשירות ב-VPC Service Controls.

1. ב-Cloud Shell, יוצרים מדיניות גישה כתנאי מוקדם ליצירת אזור של VPC Service Controls:

   gcloud access-context-manager policies create \
   --organization=ORGANIZATION_ID --title "Access policy at organization node"

   הפלט אמור להיראות כך:

   "Create request issued
   Waiting for operation [operations/accessPolicies/123456789/create/123456789] to complete...done."
   

   יכול להיות רק מאגר אחד של מדיניות גישה בצומת הארגון. אם כבר נוצרה מדיניות בארגון שלכם, הפלט ייראה כך:

   "ALREADY_EXISTS: Policy already exists with parent ContainerKey{containerId=organizations/123456789012, numericId=123456789012}"
   

   אם ההודעה הזו מופיעה, ממשיכים לשלב הבא.

2. יוצרים גבול גזרה של VPC Service Controls שמגביל את השירותים Cloud Storage ו-Compute Engine.

   export POLICY_ID=$(gcloud access-context-manager policies list \
   --organization=ORGANIZATION_ID \
   --format="value(name)")
   
   gcloud access-context-manager perimeters create demo_perimeter \
   --title="demo_perimeter" \
   --resources=projects/$(gcloud projects describe PROJECT_ID --format="value(projectNumber)") \
   --restricted-services="storage.googleapis.com,compute.googleapis.com" \
   --enable-vpc-accessible-services \
   --policy=$POLICY_ID \
   --vpc-allowed-services="RESTRICTED-SERVICES"

אימות השירותים שמותרים לתנועה מחוץ לגבולות הגזרה

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

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

במדריך הזה נעשה שימוש ב-Compute Engine API, ב-Cloud Storage API וב-Cloud Resource Manager API, אבל אותם עקרונות חלים גם על שירותים אחרים.

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

בקטע הזה תאמתו שמתחם האבטחה חוסם תנועה חיצונית לשירותים מוגבלים.

בתרשים הקודם אפשר לראות איך ללקוח מורשה נחסמת הגישה לשירותים בתוך ההיקף שהגדרתם כמוגבל, אבל הלקוח מקבל גישה לשירותים שלא הגדרתם כמוגבלים.

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

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

   gcloud compute instances create demo-vm \
       --machine-type=e2-micro \
       --subnet=restricted-subnet \
       --scopes=https://www.googleapis.com/auth/cloud-platform \
       --no-address

   הפלט אמור להיראות כך:

   "ERROR: (gcloud.compute.instances.create) Could not fetch resource:
   - Request is prohibited by organization's policy."
   

   הבקשה נכשלת כי Cloud Shell נמצא מחוץ למתחם ההיקפי, ו-Compute Engine מוגדר עם הדגל --restricted-services.

2. ב-Cloud Shell, מריצים את הפקודה הבאה כדי לגשת לשירות Resource Manager, שלא מוגדר בדגל --restricted-services.

   gcloud projects describe PROJECT_ID

   תגובה מוצלחת מחזירה את פרטי הפרויקט. התגובה הזו מוכיחה שההיקף שלכם מאפשר תנועה חיצונית ל-Cloud Resource Manager API.

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

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

אימות של רמת גישה שמאפשרת חריגה מההיקף

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

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

בשלבים הבאים תאמתו את הרעיון הזה על ידי יצירת רמת גישה, ולאחר מכן תשלחו בקשה מוצלחת לשירות Compute Engine. הבקשה הזו מותרת גם אם הגדרתם את Compute Engine כמוגבל.

1. מ-Cloud Shell, יוצרים קובץ YAML שמתאר את ההגדרה של רמת גישה ומחילים אותה על ההיקף. בדוגמה הזו נוצרת רמת גישה לזהות המשתמש שבה אתם משתמשים כרגע כדי להריץ את ההדרכה.

   export USERNAME=$(gcloud config list account --format "value(core.account)")
   
   cat <<EOF > user_spec.yaml
   - members:
     - user:$USERNAME
   EOF
   

   gcloud access-context-manager levels create single_user_level \
   --title="single-user access level" \
   --basic-level-spec=user_spec.yaml \
   --policy=$POLICY_ID
   
   gcloud access-context-manager perimeters update demo_perimeter \
   --add-access-levels=single_user_level \
   --policy=$POLICY_ID

2. מריצים שוב את הפקודה הבאה ב-Cloud Shell כדי לנסות ליצור מכונה וירטואלית:

   gcloud compute instances create demo-vm \
   --machine-type=e2-micro \
   --subnet=restricted-subnet \
   --scopes=https://www.googleapis.com/auth/cloud-platform \
   --no-address

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

אימות שמדיניות הכניסה מאפשרת חריגה מפורטת מההיקף

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

הדיאגרמה הקודמת ממחישה איך מדיניות Ingress מאפשרת ללקוח מורשה לגשת רק לשירות ספציפי בתוך גבולות גזרה, בלי לאפשר גישה לשירותים מוגבלים אחרים.

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

1. בכרטיסייה Cloud Shell, מריצים את הפקודה הבאה כדי להסיר את רמת הגישה.

   gcloud access-context-manager perimeters update demo_perimeter \
   --policy=$POLICY_ID \
   --clear-access-levels

2. בכרטיסייה Cloud Shell, יוצרים מדיניות תעבורת נתונים נכנסת שמאפשרת לזהות המשתמש שלכם להיכנס רק לשירות Compute Engine, ומחילים את המדיניות על ההיקף.

   cat <<EOF > ingress_spec.yaml
   - ingressFrom:
       identities:
       - user:$USERNAME
       sources:
       - accessLevel: '*'
     ingressTo:
       operations:
       - methodSelectors:
         - method: '*'
         serviceName: compute.googleapis.com
       resources:
       - '*'
   EOF
   

   gcloud access-context-manager perimeters update demo_perimeter \
   --set-ingress-policies=ingress_spec.yaml \
   --policy=$POLICY_ID

3. בכרטיסייה Cloud Shell, מריצים את הפקודה הבאה כדי ליצור קטגוריה של Cloud Storage בתוך ההיקף.

   gcloud storage buckets create gs://PROJECT_ID-01

   הפלט אמור להיראות כך:

   "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is prohibited by organization's policy."
   

   ‫Cloud Shell הוא לקוח מחוץ לגבולות הגזרה, ולכן גבולות הגזרה של VPC Service Controls חוסמים את האפשרות של Cloud Shell לתקשר עם שירותים מוגבלים בתוך גבולות הגזרה.

4. בכרטיסייה Cloud Shell, מריצים את הפקודה הבאה כדי לשלוח בקשה לשירות Compute Engine בתוך ההיקף.

   gcloud compute instances describe demo-vm --zone=ZONE

   תגובה מוצלחת מחזירה את הפרטים של demo-vm. התגובה הזו מוכיחה שהמתחם ההיקפי מאפשר תעבורה חיצונית שעומדת בתנאים של מדיניות התעבורה הנכנסת (ingress) לשירות Compute Engine.

אימות השירותים שמותרים לתנועה בתוך ההיקף

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

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

במדריך הזה נעשה שימוש ב-Compute Engine API, ב-Cloud Storage API וב-Cloud Resource Manager API, אבל אותם עקרונות חלים גם על שירותים אחרים.

מוודאים שגבולות האבטחה מאפשרים תנועה פנימית לשירותים מוגבלים בתוך גבולות האבטחה

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

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

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

1. מ-Cloud Shell, יוצרים כלל חומת אש שמאפשר תעבורת נתוני SSH לרשת ה-VPC על ידי מתן הרשאה לתעבורת נתונים נכנסת מטווח כתובות ה-IP ‏35.235.240.0/20 שמשמש את השירות IAP להעברת TCP:

   gcloud compute firewall-rules create demo-allow-ssh \
   --direction=INGRESS \
   --priority=1000 \
   --network=restricted-vpc \
   --action=ALLOW \
   --rules=tcp:22 \
   --source-ranges=35.235.240.0/20 

2. מתחילים סשן SSH למופע הזה:

   gcloud compute ssh demo-vm --zone=ZONE

   מוודאים שהתחברתם בהצלחה למופע demo-vm. לשם כך, בודקים שההנחיה בשורת הפקודה השתנתה ומוצג בה שם המארח של המופע:

   username@demo-vm:~$
   

   אם הפקודה הקודמת נכשלת, יכול להיות שתופיע הודעת שגיאה שדומה לזו:

   "[/usr/bin/ssh] exited with return code [255]"
   

   במקרה כזה, יכול להיות שהמכונה של Compute Engine לא סיימה את תהליך האתחול. חכו דקה ונסו שוב.

3. מתוך סשן ה-SSH בתוך ה-perimeter, בודקים את השירותים שה-perimeter מאפשר באופן פנימי באמצעות שירות Cloud de Confiance שהוגדר ברשימת ההיתרים של שירותים נגישים ב-VPC. לדוגמה, אפשר לנסות להריץ פקודה כלשהי באמצעות שירות Compute Engine.

   gcloud compute instances describe demo-vm --zone=ZONE

   תגובה מוצלחת מחזירה את הפרטים של demo-vm. התגובה הזו מראה שההיקף שלכם מאפשר לתנועה פנימית לגשת אל Compute Engine API.

4. בסשן ה-SSH בתוך ההיקף, מוודאים שהשירותים שלא נכללים ברשימת ההיתרים של השירותים הנגישים ל-VPC לא מורשים מה-VM. לדוגמה, הפקודה הבאה משתמשת בשירות Resource Manager, שלא מוגדר ברשימת ההיתרים של השירותים שאפשר לגשת אליהם ב-VPC.

   gcloud projects describe PROJECT_ID

   הפלט אמור להיראות כך:

   "ERROR: (gcloud.projects.list) PERMISSION_DENIED: Request is prohibited by organization's policy."
   

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

אימות לכך שהגבולות מונעים תנועה פנימית לשירותים מוגבלים מחוץ לגבולות

בקטע הזה מוודאים שגבולות האבטחה חוסמים את התקשורת משירותים בתוך גבולות האבטחה לשירותי Cloud de Confiance מחוץ לגבולות האבטחה.

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

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

1. מפעילים את הפקודה הבאה בסשן ה-SSH בתוך ההיקף כדי ליצור קטגוריית אחסון בתוך ההיקף. הפקודה הזו פועלת כי שירות Cloud Storage מוגדר גם ב-restricted-services וגם ב-accessible-services.

   gcloud storage buckets create gs://PROJECT_ID-02

   תגובה מוצלחת יוצרת את קטגוריית האחסון. התשובה הזו מראה שההיקף מאפשר תנועה פנימית לשירות Cloud Storage.

2. בסשן ה-SSH בתוך ההיקף, מריצים את הפקודה הבאה כדי לקרוא מקטגוריה שנמצאת מחוץ להיקף. בדלי הציבורי הזה יש הרשאת קריאה בלבד ל-allUsers, אבל ה-perimeter חוסם תנועה מתוך ה-perimeter לשירות מוגבל מחוץ ל-perimeter.

   gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

   הפלט אמור להיראות כך:

   "ERROR: (gcloud.storage.objects.describe) HTTPError 403: Request is prohibited
   by organization's policy."
   

   התשובה הזו מדגימה שאפשר להשתמש בשירותים מוגבלים בתוך ה-perimeter, אבל משאב בתוך ה-perimeter לא יכול לתקשר עם שירותים מוגבלים מחוץ ל-perimeter.

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

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

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

בשלבים הבאים, תאמתו את הרעיון הזה על ידי יצירת מדיניות יציאה ואז גישה לקטגוריה ציבורית של Cloud Storage מחוץ לגבולות הגזרה שמותרים על ידי מדיניות היציאה.

1. פותחים סשן חדש ב-Cloud Shell על ידי לחיצה על add open a new tab ב-Cloud Shell. בשלבים הבאים תעברו בין הכרטיסייה הראשונה עם סשן ה-SSH בתוך ההיקף שלכם, לבין הכרטיסייה השנייה ב-Cloud Shell מחוץ להיקף שלכם, שבה שורת הפקודה מתחילה ב-username@cloudshell.

2. בכרטיסייה Cloud Shell, יוצרים מדיניות תעבורת נתונים יוצאת שמאפשרת תעבורת נתונים יוצאת מהזהות של חשבון השירות המצורף של demo-vm באמצעות השיטה google.storage.objects.get לקטגוריה ציבורית בפרויקט חיצוני. מעדכנים את ההיקף עם מדיניות התעבורה היוצאת.

   export POLICY_ID=$(gcloud access-context-manager policies list \
   --organization=ORGANIZATION_ID \
   --format="value(name)")
   
   export SERVICE_ACCOUNT_EMAIL=$(gcloud compute instances describe demo-vm \
   --zone=ZONE \
   --format="value(serviceAccounts.email)")

   cat <<EOF > egress_spec.yaml
   - egressFrom:
       identities:
         - serviceAccount:$SERVICE_ACCOUNT_EMAIL
     egressTo:
       operations:
       - methodSelectors:
         - method: 'google.storage.objects.get'
         serviceName: storage.googleapis.com
       resources:
       - projects/950403849117
   EOF
   

   gcloud access-context-manager perimeters update demo_perimeter \
   --set-egress-policies=egress_spec.yaml \
   --policy=$POLICY_ID

3. חוזרים לכרטיסייה עם סשן ה-SSH למכונת ה-VM בתוך ההיקף, שבה שורת הפקודה מתחילה ב-username@demo-vm.

4. מתוך סשן ה-SSH בתוך ההיקף, שולחים בקשה נוספת לקטגוריה של Cloud Storage ומוודאים שהיא פועלת.

   gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

   הפלט אמור להיראות כך:

   "Hello world!
   This is a sample file in Cloud Storage that is viewable to allUsers."
   

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

5. מתוך סשן ה-SSH בתוך ההיקף, אפשר גם לבדוק שיטות אחרות שלא אושרו במפורש על ידי חריגת מדיניות היציאה. לדוגמה, הפקודה הבאה דורשת את ההרשאה google.storage.buckets.list, שנדחית על ידי ההיקף.

   gcloud storage ls gs://solutions-public-assets/vpcsc-tutorial/*

   הפלט אמור להיראות כך:

   "ERROR: (gcloud.storage.cp) Request is prohibited by organization's policy."
   

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

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

(אופציונלי) הגדרת המדיניות "שימוש מוגבל במשאבי שירות"

יכול להיות שיש לכם גם דרישות פנימיות או דרישות תאימות שמאפשרות שימוש בסביבה שלכם רק בממשקי API שאושרו בנפרד. במקרה כזה, אפשר גם להגדיר את שירות מדיניות הארגון Restricted Service Resource Usage. כשמחילים את מדיניות הארגון על פרויקט, מגבילים את השירותים שאפשר ליצור בפרויקט הזה. עם זאת, מדיניות הארגון לא מונעת משירותים בפרויקט הזה לתקשר עם שירותים בפרויקטים אחרים. לעומת זאת, באמצעות VPC Service Controls אפשר להגדיר גבולות גזרה כדי למנוע תקשורת עם שירותים מחוץ לגבולות הגזרה.

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

1. עוברים לכרטיסייה Cloud Shell, שבה ההנחיה בשורת הפקודה מתחילה ב-username@cloudshell.

2. בכרטיסייה Cloud Shell, יוצרים קובץ YAML שמתאר את שירות מדיניות הארגון, שיאפשר שימוש רק בשירות Compute Engine וידחה את כל השירותים האחרים, ואז מחילים אותו על הפרויקט.

   cat <<EOF > allowed_services_policy.yaml
   constraint: constraints/gcp.restrictServiceUsage
   listPolicy:
     allowedValues:
     - compute.googleapis.com
     inheritFromParent: true
   EOF
   

   gcloud resource-manager org-policies set-policy allowed_services_policy.yaml \
   --project=PROJECT_ID

3. חוזרים לכרטיסייה עם סשן ה-SSH למכונת ה-VM בתוך ההיקף, שבה שורת הפקודה מתחילה ב-username@demo-vm.

4. מתוך סשן ה-SSH בתוך ההיקף, מריצים את הפקודה הבאה כדי להציג את אותה קטגוריית אחסון שיצרתם קודם בתוך הפרויקט הזה.

   gcloud storage buckets describe gs://PROJECT_ID

   הפלט אמור להיראות כך:

   "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is disallowed by organization's constraints/gcp.restrictServiceUsage constraint for 'projects/123456789' attempting to use service 'storage.googleapis.com'."
   

   התגובה הזו מראה ששירות מדיניות הארגון דוחה את שירות Cloud Storage בפרויקט, בלי קשר להגדרת ההיקף.

5. מתוך סשן ה-SSH בתוך ההיקף, מריצים את הפקודה הבאה כדי לראות קטגוריית אחסון מחוץ להיקף שמותרת על ידי מדיניות היציאה.

   gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

   הפלט אמור להיראות כך:

   "Hello world!
   This is a sample file in Cloud Storage that is viewable to allUsers."
   

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

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

הסרת המשאבים

כדי למחוק Cloud de Confiance פרויקט:

gcloud projects delete PROJECT_ID

למרות שגבולות הגזרה של VPC Service Controls לא מייצרים עלויות נוספות, כדאי לנקות אותם כדי למנוע עומס ומשאבים לא מנוצלים בארגון.

1. בכלי לבחירת פרויקטים בחלק העליון של מסוף Cloud de Confiance , בוחרים את הארגון שבו השתמשתם במהלך ההדרכה הזו.

2. נכנסים לדף VPC Service Controls במסוף Cloud de Confiance .

   מעבר אל VPC Service Controls

3. מתחת לרשימת ההיקפים, בוחרים את ההיקף שרוצים למחוק ולוחצים על מחיקה.

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

המאמרים הבאים

• מידע ולמידה על שיטות מומלצות להפעלת VPC Service Controls
• מידע על השירותים שנתמכים ב-VPC Service Controls
• איך מפעילים שירותים עם גישה ל-VPC
• אפשר לקרוא על ההגדרה של Private Service Connect לגישה ל-Google APIs.

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