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

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

מטרות

• כדי לצמצם את הסיכונים לזליגת נתונים, מגדירים גבולות גזרה לשירות ב-VPC Service Controls עם אמצעי בקרה נוספים ברשת.
• אישור או דחייה של גישה לשירותים בתוך הגבולות של הגזרה מבקשות שמקורן בתוך הגבולות או מחוץ לגבולות.
• לאפשר או לחסום גישה לשירותים מחוץ לגבולות הגזרה מבקשות שמקורן בתוך גבולות הגזרה.
• מומלץ להשתמש במדיניות הארגון 'הגבלת השימוש בשירות המשאבים' וב-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 ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
   • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

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

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

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

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

   כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

   הפעלת ממשקי ה-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, משתמש בחשבון שירות, עריכה בספריית שירותים

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

   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 APIs לנקודת הקצה של 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 וכללים משתמעים של חומת אש.

יצירה של service perimeter ב-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, מריצים את הפקודה הבאה כדי לגשת לשירות מנהל המשאבים, שלא מוגדר בדגל --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) מאפשרת חריג מפורט לגבולות גזרה

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

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

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

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

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

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

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

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

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

1. מ-Cloud Shell, יוצרים כלל חומת אש שמאפשר תעבורת נתונים מסוג SSH לרשת ה-VPC, על ידי מתן הרשאה לתעבורת נתונים נכנסת (ingress) מטווח כתובות ה-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. לדוגמה, הפקודה הבאה משתמשת בשירות 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) או תעבורת נתונים שמגיעים מחוץ לגבולות הגזרה שלכם יבקשו את השירות הזה. אם רוצים למנוע שימוש בשירות מסוים בפרויקט, אפשר לעיין במאמר בנושא מדיניות השימוש במשאבי שירות מוגבלים.

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

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

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

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

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

   gcloud storage buckets create gs://PROJECT_ID-02

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

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

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

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

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

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

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

בשלבים הבאים, תאמתו את הרעיון הזה על ידי יצירת מדיניות יציאה ואז גישה לקטגוריה ציבורית של 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 למכונה הווירטואלית בתוך ההיקף, שבה שורת הפקודה מתחילה ב-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 למכונה הווירטואלית בתוך ההיקף, שבה שורת הפקודה מתחילה ב-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) מאפשרות לתנועה פנימית להגיע לקטגוריית אחסון חיצונית בתנאים מוגבלים מסוימים, אבל Organization Policy Service דוחה את שירות Cloud Storage בפרויקט שלכם, ללא קשר לתצורה של גבולות הגזרה. יכול להיות שעדיין נעשה שימוש בשירותים מחוץ לפרויקט לצורך העברת נתונים לא מורשית, אם הם מותרים על ידי גבולות הגזרה, ללא קשר לשירות מדיניות הארגון בנושא שימוש במשאבי שירות מוגבל.

   כדי למנוע תקשורת עם Cloud Storage או עם שירותים אחרים של Google מחוץ ל-perimeter, לא מספיק להשתמש רק ב-Organization Policy Service עם ההגדרה Restricted Service Resource Usage. צריך להגדיר perimeter של 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 Architecture Center.