VPC Service Controls – BigQuery Protection Codelab I

1. מבוא

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

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

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

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

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

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

• הסבר על הרצת שאילתות ב-BigQuery: אפשר לעיין בסדנת התכנות הזו כדי ללמוד איך להריץ שאילתות במערך הנתונים של ויקיפדיה ב-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 הזה.

יצירה של service perimeter רגיל

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

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

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

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

במעבדת התכנות הזו נשתמש במכונת 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 Console (או בכלי שורת הפקודה bq) כדי לנהל נתונים ב-BigQuery, המערכת יוצרת משימות שמשמשות להשלמת הפעולות הרצויות. בינתיים, האירוע הראשון הוא יצירת משימה ב-BigQuery.

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

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

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

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

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

• FROM | Identities: רק לזהות שצוינה [e-mail] צריכה להיות הרשאה לחצות את גבול ההיקף.
• ‫TO | projects: הזהות שצוינה יכולה לחצות את גבולות גזרת השירות רק אם היעד הוא הפרויקט שצוין 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 עם הקשר שונה מההקשרים שמותרים על ידי המדיניות שכבר הוגדרה תגרום להפרה שונה.

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

• ‫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 שאליהם יש לו גישה.

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

• מקור (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 Cloud.

יצירת רמת גישה עם תנאי גישה של כתובת 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. משנים את כלל הכניסה כדי להגדיר את המקור כרמת הגישה 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 כהיקף הגישה של מכונת ה-VM.
• לחשבון השירות שמצורף למכונה הווירטואלית צריכות להיות הרשאות 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 תיכשל אם היא תופעל מכל מקום אחר, כולל:

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

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

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

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

• כדי למחוק את המכונה הווירטואלית, מבצעים את השלבים הבאים:
  • נכנסים לדף VM instances במסוף Google Cloud.
  • מסמנים את התיבה שמימין לשם של מכונת ה-VM, לוחצים על מחיקה ואז שוב על מחיקה כדי לאשר.
• כדי למחוק את service perimeter, פועלים לפי השלבים הבאים:
  • במסוף 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 המותנה בייחוס.