VPC Service Controls – BigQuery Protection Codelab I

1. מבוא

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

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

• להבין איך לתקן הפרות של תעבורת נתונים נכנסת (ingress) ויוצאת (egress) באמצעות כללים לתעבורת נתונים נכנסת (ingress) ויוצאת (egress) בהתאמה.
• הסבר על הסיבה להפרה ספציפית.
• ניתוח ההיקף של תיקון ההפרה שהוחל.
• לשנות את התיקון (כלל של תעבורת נתונים נכנסת (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 (ברמת הפרויקט) ואדמין של מנהל הרשאות גישה (ברמת הארגון). יהיו לכם את התפקידים הנדרשים להגדרת המשאבים הנדרשים לכל ה-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. לוחצים על Save Results (שמירת התוצאות) ובוחרים את BigQuery table (טבלה ב-BigQuery). (יש לעיין בצילום המסך למטה).
2. בוחרים את project-1 כפרויקט היעד.
3. נותנים למערך הנתונים את השם codelab_dataset. (בוחרים CREATE DATASET, אלא אם משתמשים במערך נתונים קיים).
4. נותנים לטבלה את השם: codelab-table.
5. לוחצים על שמירה.

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

מערך הנתונים של השאילתה נשמר ב-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.

אימות אכיפת גבולות גזרה לשירות

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

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

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

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

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

ההתנהגות הצפויה מהכלל של תעבורת הנתונים היוצאת (egress) שהוגדר:

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

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

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

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

תתרחש הפרה נוספת, הפעם הפרה של תעבורת הנתונים הנכנסת (ingress) מסוג 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"]}
 ]

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

חשוב להבין איך פועל שירות API נתון כדי לצפות הפרות צפויות.

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

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

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

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

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

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

• FROM | זהויות: רק הזהות שצוינה [e-mail] יכולה לחצות את גבולות ההיקף.
• אל | פרויקטים: הזהות שצוינה יכולה לחצות גבולות היקפיים רק אם היעד הוא הפרויקט שצוין project-1.
• אל | שירותים: הזהות שצוינה יכולה ליזום תנועה בתוך גבולות הגזרה רק אם הקריאה ל-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 של גבולות הגזרה או אליה. הגישה של [e-mail] (קו ירוק רציף) בוצעה בהצלחה, כי ההגדרות של VPC Service Controls יכולות לבצע פעולות מהנקודה project-1 ולידה.

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

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

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

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

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

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

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

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

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

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

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

כברירת מחדל:

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

אפשר להריץ את אותה שאילתה מרשת ה-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.
• לחשבון השירות המחובר ל-VM נדרשות הרשאות IAM כדי:
  • יצירת משימות ב-BigQuery ב-project-2
  • קבלת נתוני BigQuery מהטבלה ב-BigQuery שנמצאת בכתובת project-1
• חשבון השירות שמשמש כברירת המחדל של Compute Engine צריך להיות מורשה באמצעות הכלל של תעבורת נתונים נכנסת (ingress) ויוצאת (egress).

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

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

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

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

9. מעולה!

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

מידע נוסף

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

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

רישיון

היצירה הזו בשימוש ברישיון Creative Commons Attribution 2.0 גנרי.