VPC Service Controls – BigQuery Protection Codelab I

1. מבוא

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

בשלב הבא, נגדיר גבולות גזרה לשירות כדי להגן על פרויקט הנתונים. במאמר הזה נסביר איך לתקן הפרות שנצפו באמצעות כללי תעבורת נתונים נכנסת (ingress) וכללי תעבורת נתונים יוצאת (egress), ובהמשך נסביר איך להוסיף רמת גישה כדי להגביל את הגישה באמצעות כתובות IP פנימיות. המטרות של ה-Codelab הזה הן:

• הסבר על תיקון הפרות של תעבורת נתונים נכנסת (ingress) ויוצאת (egress) באמצעות כללים לתעבורת נתונים נכנסת ויוצאת, בהתאמה.
• הסבר על הפרה ספציפית.
• לנתח את היקף התיקון של הפרת המדיניות.
• משנים את התיקון (כלל תעבורת נתונים נכנסת (ingress) / תעבורת נתונים יוצאת (egress)) כדי לשנות את ההיקף שלו באמצעות האפשרות לאפשר תעבורת נתונים מכתובות IP פנימיות ברשת VPC באמצעות רמות גישה.

2. הגדרה ודרישות של משאבים

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

ב-codelab הזה אנחנו מניחים שאתם כבר יודעים:

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

הגדרה

ההגדרה הראשונית שלנו מתוכננת באופן הבא:

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

• ארגון ב-Google Cloud.
• תיקייה בארגון. ב-codelab הזה נקרא לו codelab-folder.
• שני פרויקטים ב-Google Cloud שנמצאים באותה תיקייה, codelab-folder. ב-Codelab הזה אנחנו קוראים להם project-1 ו-project-2
  • אם עדיין לא יצרתם את התיקייה והפרויקטים, במסוף Google Cloud, צרו תיקייה מתחת לארגון וצרו שני פרויקטים חדשים מתחת לתיקייה שיצרתם.
• ההרשאות הנדרשות:
  • תפקידי IAM לניהול תיקיות: מוקצים ברמת התיקייה
  • תפקידי IAM לניהול פרויקטים: מוקצים ברמת הפרויקט
  • תפקידי IAM שנדרשים להגדרת VPC Service Controls: מוקצים ברמת הארגון
  • תפקידי IAM לניהול BigQuery: מוקצים ברמת הפרויקט
  • תפקידי IAM לניהול מכונות של Compute Engine: מוקצים ברמת הפרויקט
• החשבון לחיוב בשני הפרויקטים, project-2 ו-project-1.

לצורך ה-codelab הזה, אתם יכולים להקצות לעצמכם את התפקידים המוגדרים מראש הבאים: אדמין תיקיות ויצירת פרויקטים (ברמת התיקייה), בעלים (ברמת הפרויקט), אדמין BigQuery (ברמת הפרויקט) ואדמין של Access Context Manager (ברמת הארגון). כך יהיו לכם התפקידים הנדרשים להגדרת המשאבים שדרושים ל-codelab הזה.

יצירה של גבולות גזרה רגילים לשירות

ב-Codelab הזה נשתמש בגבולות גזרה רגילים לשירות שמגן על project-1.

• יוצרים גבולות גזרה רגילים, perimeter-1, ומוסיפים את project-1.

בגבולות גזרה, אל תגבילו עדיין אף שירות. נעשה את זה אחר כך.

יצירת מכונה וירטואלית ב-Compute Engine

ב-Codelab זה נשתמש במופע Compute Engine אחד ב-project-2, שנמצא ב-us-central1 ומשתמש ברשת VPC שמוגדרת כברירת מחדל בשם default.

• אפשר להיעזר בתיעוד כדי ליצור מכונה של Compute Engine מתמונה ציבורית.

ב-Codelab הזה נשתמש ברשת VPC שמוגדרת כברירת מחדל, בשם default. אפשר גם להשתמש בכל רשת אחרת, בתנאי שיש לרשת לפחות רשת משנה אחת.

עלות

כדי להשתמש במשאבי ענן או בממשקי API, צריך להפעיל את החיוב במסוף Google Cloud. מומלץ להשבית את המשאבים שבהם השתמשתם כדי להימנע מחיובים נוספים אחרי סיום ה-codelab. משתמשים חדשים ב-Google Cloud זכאים לתוכנית תקופת הניסיון בחינם בשווי 300$.

המשאבים שצוברים עלויות הם BigQuery ומכונת Compute Engine. אפשר להשתמש במחשבון התמחור של BigQuery ובמחשבון התמחור של Compute Engine כדי להעריך את העלות.

3. גישה ל-BigQuery ללא הגבלות של VPC Service Controls

הרצת שאילתות במערך נתונים ציבורי ושמירת התוצאות ב-project-1

1. כדי לוודא שיש לכם גישה ל-BigQuery API, נכנסים לדף BigQuery Studio.project-2project-1 אפשר לעשות זאת כי גם אם project-1 נמצא בגבולות גזרה לשירות, גבולות הגזרה עדיין לא מגנים על אף שירות.
2. מתוך project-2, מריצים את השאילתה הבאה כדי להריץ שאילתה על מערך נתונים ציבורי.

SELECT  name, SUM(number) AS total
FROM  `bigquery-public-data.usa_names.usa_1910_2013`
GROUP BY   name
ORDER BY total DESC
LIMIT 10;

אחרי שמריצים את השאילתה במערך הנתונים הציבורי (כשנשארים ב-project-2):

1. לוחצים על שמירת התוצאות ובוחרים באפשרות טבלה ב-BigQuery. (ראו צילום מסך בהמשך).
2. בוחרים את פרויקט היעד project-1.
3. נותנים למערך הנתונים את השם codelab_dataset. (בוחרים באפשרות יצירת מערך נתונים חדש, אלא אם משתמשים במערך נתונים קיים).
4. נותנים לטבלה את השם: codelab-table.
5. לוחצים על שמירה.

הנתונים של מערך הנתונים הציבורי אוחסנו בהצלחה ב-project-1 כתוצאה מהרצת השאילתה מ-project-2.

השאילתה Query Dataset נשמרה ב-project-1 מ-project-2

ב-project-2 BigQuery Studio, מריצים את השאילתה הבאה כדי לבחור נתונים מתוך:

• פרויקט: project-1
• מערך נתונים: codelab_dataset
• טבלה: codelab-table

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

השאילתה אמורה לפעול בהצלחה, כי לא הוגבלו ההרשאות של project-2 ושל project-1 לשימוש ב-BigQuery. הגישה אל BigQuery מותרת מכל מקום ואל כל מקום, כל עוד למשתמש יש הרשאות IAM מתאימות.

דיאגרמה זו ממחישה את התהליך שמתרחש כאשר ישות מורשית שולחת שאילתה למערך נתונים ב-BigQuery. כל שאילתת BigQuery מפעילה משימת BigQuery, שמבצעת את הפעולה בפועל, ובמקרה הזה, אחזור נתונים. הגישה של הגורם המורשה מוצגת ממכונת Compute Engine ומהאינטרנט, בזמן שליחת שאילתה ממערך נתונים ציבורי ומפרויקט נפרד ב-Google Cloud. תהליך השאילתה של הנתונים (GetData) הושלם בהצלחה, בלי שנחסם על ידי VPC Service Controls.

4. הגנה על BigQuery API בפרויקט של מערך נתונים של מקור

משנים את ההגדרה של ההיקף perimeter-1 ומגבילים את השירות BigQuery API יחד עם המשאב המוגן project-1.

אימות האכיפה של service perimeter

מתוך project-2, מריצים את השאילתה הבאה ב-BigQuery Studio, כמו בשלב הקודם:

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

תתרחש הפרה של RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER VPC Service Controls

יומן הביקורת של ההפרה ימוקם ב-project-1, כי שם התרחשה ההפרה של חציית הגבול. אפשר לסנן את היומנים לפי הערך שנצפה vpcServiceControlsUniqueId (מחליפים את VPC_SC_DENIAL_UNIQUE_ID במזהה הייחודי שנצפה).

severity=ERROR
resource.type="audited_resource"
protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="[*VPC_SC_DENIAL_UNIQUE_ID*]"

ההפרה היא egressViolations עם:

• ‫principalEmail: [חשבון המשתמש שמריץ את השאילתה]
• ‫callerIp: [כתובת ה-IP של סוכן המשתמש שמריץ את השאילתה]

     "egressViolations": [
       {
         "targetResource": "projects/project-2",
         "sourceType": "Resource",
         "source": "projects/project-1",
         "servicePerimeter": "accessPolicies/REDACTED/servicePerimeters/perimeter-1",
         "targetResourcePermissions": [ "bigquery.jobs.create"]
       }      ],

5. תיקון ההפרה כדי ליצור משימה ב-BigQuery

ההפרה של VPC Service Controls מציינת את bigquery.jobs.create כהרשאת היעד בגלל אופן הפעולה של BigQuery. כשמשתמשים במסוף Google Cloud (או בכלי שורת הפקודה של BigQuery) כדי לנהל נתונים ב-BigQuery, המערכת יוצרת משימות שמשמשות להשלמת הפעולות הרצויות. בינתיים, האירוע הראשון הוא יצירת משימה ב-BigQuery.

בדיאגרמה הזו מוצג תרחיש שבו יש למשתמש הרשאה להריץ שאילתה מ-project-2 על מערך נתונים ב-project-1. הפעולה ליצירת משימת BigQuery, ממערך נתונים בפרויקט (project-1) בפרויקט שממנו מופעלת השאילתה (project-2), נכשלת בגלל הפרה של תעבורת נתונים יוצאת (egress) ב-VPC Service Controls, כי גבולות גזרה לשירות perimeter-1 מגן על BigQuery API. אחרי שמגדירים את גבולות הגזרה, אי אפשר ליזום בקשות API ל-BigQuery מ-project-1 אל מחוץ לגבולות הגזרה, או ליזום בקשות מחוץ לגבולות הגזרה אל הפרויקט המוגן, אלא אם הוגדרו הרשאות לכך בהגדרות גבולות הגזרה לשירות.

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

• מקור (FROM): כלומר כתובת האימייל של המשתמש וההקשר (לדוגמה: כתובת ה-IP של המתקשר, מצב המכשיר, המיקום וכו')
• יעד (TO): כלומר משאב היעד, השירות והשיטה או ההרשאה.

כדי לתקן את ההפרה של תעבורת הנתונים היוצאת, צריך ליצור כלל תעבורת נתונים יוצאת שמאפשר תעבורה לכיוון targetResource ‏ (project-2) על ידי חשבון המשתמש שמריץ את השאילתה ([e-mail]) בשירות BigQuery והשיטה/ ההרשאה bigquery.jobs.create.

ההתנהגות הצפויה של כלל היציאה שהוגדר:

• FROM | Identities: רק לזהות שצוינה [e-mail] צריכה להיות הרשאה לחצות את גבול ההיקף.
• ‫TO | פרויקטים: הזהות שצוינה יכולה לחצות את גבולות גזרה רק אם היעד הוא הפרויקט שצוין project-2.
• ‫TO | שירותים: הזהות שצוינה יכולה ליזום תעבורה מחוץ לגבולות הגזרה, לכיוון הפרויקט שצוין, רק אם קריאת ה-API היא עבור השירות והשיטה שצוינו. אחרת, למשל אם הם ינסו להשתמש בשירות אחר שמוגן על ידי גבולות גזרה לשירות, הפעולה תיחסם כי אסור להשתמש בשירותים אחרים.

בדיקת התיקון: כלל לתעבורת נתונים יוצאת (egress)

אחרי שמוסיפים את כלל היציאה, מריצים את אותה שאילתה.

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

תתרחש הפרה נוספת, הפעם הפרה של NO_MATCHING_ACCESS_LEVEL. ההפרה החדשה שונה מההפרה הראשונה מבחינת פרויקט היעד והשיטה.

תיקון הפרה אחת של VPC Service Controls לא אומר שלא יתרחשו הפרות אחרות. קריאה חדשה ל-API עם הקשר שונה מההקשרים שמותרים על ידי מדיניות שכבר הוגדרה תגרום להפרה שונה.

ההפרה החדשה היא הפרה של תעבורת נתונים נכנסת (ingress) עם

• ‫principalEmail: [חשבון המשתמש שמריץ את השאילתה]
• ‫callerIp: [כתובת ה-IP של סוכן המשתמש שמריץ את השאילתה]

ingressViolations: [
0: {
 servicePerimeter: "accessPolicies/REDACTED/servicePerimeters/perimeter-1"
 targetResource: "projects/project-1"
 targetResourcePermissions: [0: "bigquery.tables.getData"]}
 ]

ההפרה בשיטה bigquery.tables.getData נובעת מקריאה ל-API שהופעלה על ידי משימת BigQuery בניסיון לקבל נתונים מטבלה ב-BigQuery.

כדי לצפות להפרות אפשריות, חשוב להבין איך שירות API מסוים פועל.

6. פתרון הפרה כדי לקבל נתונים מטבלת BigQuery

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

הפרה של תעבורת נתונים נכנסת (ingress) מתוקנת על ידי כלל תעבורת נתונים נכנסת (ingress) שמוגדר עם:

• מקור (FROM): כלומר כתובת האימייל של המשתמש וההקשר (לדוגמה: כתובת ה-IP של המתקשר, מצב המכשיר, המיקום וכו')
• יעד (TO): כלומר משאב היעד, השירות והשיטה או ההרשאה.

כלל הכניסה יאפשר תעבורת נתונים אל project-1 על ידי המשתמש שצוין בשירות ובשיטה שצוינו.

ההתנהגות הצפויה מכלל הכניסה שהוגדר:

• FROM | Identities: רק לזהות שצוינה [e-mail] צריכה להיות הרשאה לחצות את גבול ההיקף.
• TO | projects: הזהות שצוינה יכולה לחצות את גבולות גזרה רק אם היעד הוא הפרויקט שצוין project-1.
• ‫TO | שירותים: הזהות שצוינה יכולה ליזום תעבורת נתונים בתוך גבולות הגזרה רק אם קריאת ה-API היא עבור BigQuery API והשיטה שצוינה bigquery.tables.getData.

ההרצה של השאילתה הזהה אמורה לפעול מעכשיו בצורה תקינה ללא הפרות של VPC Service Controls.

הגבלנו בהצלחה את BigQuery API ב-project-1 כך שאפשר להשתמש בו רק על ידי [e-mail] ולא על ידי [e-mail].

דיאגרמה זו ממחישה כיצד שתי ישויות מורשות שונות מנסות לשלוח שאילתה לאותה קבוצת נתונים. הגישה של [e-mail] (קווים כחולים מנוקדים) נדחית על ידי VPC Service Controls, כי לא מותר להם להפעיל פעולות ב-BigQuery מ-project-1 או אל project-1 בהתאם להגדרת גבולות הגזרה לשירות. הגישה של [e-mail] (קו ירוק מלא) הצליחה, כי ההגדרות של VPC Service Controls מאפשרות לו לבצע פעולות מ-project-1 ואליו.

7. הגבלת התנועה שמותרת על ידי היקף בקרת הגישה לשירות על סמך כתובת IP פנימית

ההגדרה הנוכחית מאפשרת למשתמש שצוין להריץ שאילתות ב-BigQuery ב-project-1 מכל מקום באינטרנט, אם ניתנה לו הרשאת IAM לשליחת שאילתות על הנתונים, וכל עוד הוא משתמש בחשבון שלו. מבחינת אבטחה, המשמעות היא שאם החשבון ייפרץ, כל מי שיקבל גישה לחשבון יוכל לגשת לנתוני BigQuery ללא הגבלות נוספות.

אפשר להטמיע הגבלות נוספות באמצעות רמת גישה בכללי כניסה ויציאה כדי לציין את הקשר של המשתמש. לדוגמה, אתם יכולים לאפשר גישה על סמך כתובת ה-IP של המקור בשילוב עם כלל תעבורת נתונים נכנסת (ingress) שהוגדר בעבר ומאשר גישה על סמך זהות המתקשר. אפשר לגשת באמצעות כתובת IP של המקור גם לטווחי CIDR של כתובות IP ציבוריות, בתנאי שללקוח המשתמש מוקצית כתובת IP ציבורית, או באמצעות כתובת IP פנימית אם לקוח המשתמש פועל מפרויקט בענן של Google.

יצירת רמת גישה עם תנאי גישה של כתובת IP פנימית

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

1. בדף Access Context Manager, לוחצים על CREATE ACCESS LEVEL (יצירת רמת גישה).
2. בחלונית 'רמת גישה חדשה':
   1. מזינים שם: אפשר להשתמש ב-codelab-al.
   2. בקטע 'תנאים', לוחצים על רשתות משנה של כתובות IP.
   3. לוחצים על הכרטיסייה Private IP (כתובת IP פרטית) ואז על SELECT VPC NETWORKS (בחירת רשתות VPC).
   4. בחלונית Add VPC Networks (הוספת רשתות VPC), אפשר לעיין ברשימה ולמצוא את הרשת default או להזין ידנית את שם הרשת המלא בפורמט //compute.googleapis.com/projects/project-2/global/networks/default.
   5. לוחצים על הוספת רשת VPC.
   6. לוחצים על בחירת רשתות משנה של כתובות IP.
   7. בוחרים את האזור שבו ממוקם מופע מכונת ה-VM. ב-Codelab הזה, הערך הוא us-central1.
   8. לוחצים על שמירה.

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

הוספת רמת גישה לכלל הכניסה

כדי לאכוף שהמשתמש שאושר על ידי כלל הכניסה מאומת גם מול רמת הגישה, צריך להגדיר את רמת הגישה בכלל הכניסה. כלל הכניסה שמאשר גישה לנתוני שאילתות נמצא ב-perimeter-1. משנים את כלל ה-Ingress כדי להגדיר את המקור כרמת הגישה codelab-al.

בדיקת הגדרות חדשות

אחרי שמוסיפים את רמת הגישה לכלל תעבורת הנתונים הנכנסת, אותה שאילתת BigQuery תיכשל אלא אם היא תופעל מהלקוח ברשת ה-VPC‏ default עבור הפרויקט project-2. כדי לוודא את ההתנהגות הזו, מריצים את השאילתה ממסוף Google Cloud בזמן שמכשיר נקודת הקצה מחובר לאינטרנט. השאילתה תסתיים ללא הצלחה, ותוצג אינדיקציה להפרת כללי הכניסה.

כברירת מחדל:

• היקף הגישה של מכונת Compute Engine מוגדר כברירת מחדל לגישה שמוגדרת כברירת מחדל, שלא מאפשרת גישה ל-BigQuery API.
• למכונה של Compute Engine יהיה מצורף חשבון השירות של Compute Engine שמוגדר כברירת מחדל. בינתיים, כל הפקודות שמופעלות מהמכונה הווירטואלית יפעלו כחשבון השירות הזה, שצריך להיות בפורמט [e-mail].
  אפשר לשנות את היקף הגישה ואת חשבון השירות שמחובר למכונה וירטואלית.

אפשר להריץ את אותה שאילתה מרשת ה-VPC default, שנמצאת ב-project-2. באופן דומה, גם ביצוע אותה שאילתת BigQuery ממכונת Compute Engine שנמצאת ב-project-2 באמצעות רשת VPC default ייכשל. הסיבה לכך היא שכלל תעבורת הנתונים הנכנסת (ingress) עדיין מוגדר כך שהוא מאפשר גישה רק לחשבון המשתמש [e-mail]. עם זאת, המכונה הווירטואלית משתמשת בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine.

כדי להריץ את אותה פקודה ממכונת Compute Engine ב-project-2,צריך לוודא ש:

• למכונה הווירטואלית יש היקף גישה לשימוש ב-BigQuery API. אפשר לעשות זאת על ידי בחירה באפשרות Allow full access to all Cloud APIs כהיקף הגישה למכונה הווירטואלית.
• לחשבון השירות שמצורף למכונה הווירטואלית צריכות להיות הרשאות IAM ל:
  • יצירת משימות BigQuery ב-project-2
  • שליפת נתוני BigQuery מהטבלה ב-BigQuery שנמצאת ב-project-1
• צריך לאפשר את חשבון השירות של Compute Engine שמוגדר כברירת מחדל באמצעות כלל הכניסה והיציאה.

עכשיו צריך להוסיף את חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine לכללי תעבורת הנתונים הנכנסת (כדי לאפשר קבלת נתונים מטבלת BigQuery) ולכלל תעבורת הנתונים היוצאת (כדי לאפשר יצירת משימות BigQuery).

מריצים את הפקודה bq query הבאה מתוך מכונת Compute Engine ב-project-2 ברשת ה-VPC‏ default:

bq query --nouse_legacy_sql \
'SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;'

בהגדרה הנוכחית, הפקודה של BigQuery תצליח רק אם:

• פועל במכונה וירטואלית באמצעות רשת ה-VPC שמוגדרת כברירת מחדל ב-project-2, ו
• נמצאים באזור us-central1 שצוין (רשת משנה של כתובות IP), ו
• להפעיל באמצעות חשבון השירות שמוגדר כברירת מחדל של Compute Engine, שהוגדר בגבולות גזרה לשירות.

השאילתה של פקודת BigQuery תיכשל אם היא תופעל מכל מקום אחר, כולל:

• אם מריצים אותה ב-VM באמצעות רשת ה-VPC שמוגדרת כברירת מחדל ב-project-2, אבל המכונה ממוקמת באזור אחר מרשת המשנה שנוספה ברמת הגישה, או
• אם המשתמש מפעיל את [e-mail] באמצעות לקוח משתמש באינטרנט.

בתרשים הזה מוצגת גישה שיוזמת אותה ישות מורשית, [e-mail], משני מיקומים שונים: האינטרנט ומכונה של Compute Engine. הגישה ל-BigQuery ישירות מהאינטרנט (הקווים המקווקווים הכחולים) נחסמת על ידי VPC Service Controls, אבל הגישה ממכונה וירטואלית (הקווים הירוקים הרציפים) – תוך התחזות לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine – מותרת. הגישה מותרת כי גבולות גזרה לשירות מוגדרים כך שיאפשרו גישה למשאבים מוגנים מכתובת IP פנימית.

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

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

• כדי למחוק את המכונה הווירטואלית, מבצעים את השלבים הבאים:
  • נכנסים לדף VM instances במסוף Google Cloud.
  • מסמנים את התיבה שמימין לשם של מכונת ה-VM, לוחצים על מחיקה ואז שוב על מחיקה כדי לאשר.
• כדי למחוק את גבולות גזרה לשירות, פועלים לפי השלבים הבאים:
  • במסוף Google Cloud, בוחרים באפשרות Security ואז ב-VPC Service Controls ברמה שבה מוגדרת מדיניות הגישה, במקרה הזה ברמת התיקייה.
  • בדף VPC Service Controls, בשורת הטבלה שמתאימה לגבולות הגזרה שרוצים למחוק, לוחצים על Delete (מחיקה).
• כדי למחוק את רמת הגישה, מבצעים את השלבים הבאים:
  • במסוף Google Cloud, פותחים את הדף Access Context Manager בהיקף התיקייה.
  • בטבלה, מאתרים את השורה של רמת הגישה שרוצים למחוק, לוחצים על סמל האפשרויות הנוספות ואז על מחיקה.
• כדי להשבית את הפרויקטים, מבצעים את השלבים הבאים:
  • במסוף Google Cloud, עוברים לדף IAM & Admin Settings של הפרויקט שרוצים למחוק.
  • בדף ההגדרות של IAM ואדמין, בוחרים באפשרות כיבוי.
  • מזינים את מזהה הפרויקט ובוחרים באפשרות Shutdown anyway (הפעלה בכל מקרה).

9. מעולה!

ב-Codelab הזה יצרתם היקף אבטחה של VPC Service Controls, אכפתם אותו ופתרתם בו בעיות.

מידע נוסף

אפשר גם לבדוק את התרחישים הבאים:

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

רישיון

העבודה הזו בשימוש במסגרת רישיון Creative Commons שמותנה בייחוס כללי מגרסה 2.0.