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, אפשר לעיין בשיעור 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, נכנסים אל project-2 ו-project-1 ועוברים אל הדף BigQuery Studio. אפשר לעשות זאת כי גם אם 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_PERIMETERVPC 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. אחרי שהגדרתם את גבולות הגזרה, אי אפשר ליזום בקשות 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 עם הקשר ששונה מההקשרים שמותרים לפי המדיניות שכבר הוגדרה תגרום להפרה שונה.

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

• ‫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. לוחצים על ADD VPC Network (הוספת רשת VPC).
   6. לוחצים על בחירת רשתות משנה של כתובות IP.
   7. בוחרים את האזור שבו ממוקם מופע מכונת ה-VM. ב-Codelab הזה, הערך הוא us-central1.
   8. לוחצים על שמירה.

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

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

כדי לוודא שהמשתמש שאושר על ידי כלל הכניסה מאומת גם מול רמת הגישה, צריך להגדיר את רמת הגישה בכלל הכניסה. כלל הכניסה שמאשר גישה לנתוני שאילתות נמצא ב-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).

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

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

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