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 הזה, אנחנו נניח שאתם כבר יודעים:

הגדרה

ההגדרה הראשונית שלנו בנויה כך:

תכנון ראשוני עם גבולות גזרה לשירות שלא מגנים על ממשק API.

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

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

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

ב-Codelab הזה נשתמש במכונה אחת של Compute Engine ב-project-2, שנמצאת ב-us-central1, ומשתמשים ברשת 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). (יש לעיין בצילום המסך למטה). שמירת התוצאות ב-BigQuery.
  2. בוחרים את project-1 כפרויקט היעד.
  3. נותנים למערך הנתונים את השם codelab_dataset. (בוחרים CREATE DATASET, אלא אם משתמשים במערך נתונים קיים). בחירת פרויקט היעד ושמירת התוצאות ב-BigQuery.
  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 מתאימות.

הגדרת Codelab ללא גבולות גזרה לשירות של VPC Service Controls. בתרשים הזה ממחיש את התהליך שבו חשבון משתמש שולח שאילתה למערך נתונים של 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

הפרה של תעבורת נתונים יוצאת (egress) ל-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

תנועת תעבורת נתונים יוצאת (egress) נכשלה ביצירת משימות ב-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) על ידי חשבון המשתמש שהריץ את השאילתה (user@example.com) בשירות BigQuery וה-method או ההרשאה bigquery.jobs.create.

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

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

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

הפרה של תעבורת נתונים נכנסת (ingress VPC Service Controls)

ההפרה החדשה היא הפרה של תעבורת נתונים נכנסת (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.

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

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

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

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

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

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

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

  • FROM | זהויות: רק הזהות שצוינה user@example.com יכולה לחצות את גבולות ההיקף.
  • אל | פרויקטים: הזהות שצוינה יכולה לחצות גבולות היקפיים רק אם היעד הוא הפרויקט שצוין project-1.
  • אל | שירותים: הזהות שצוינה יכולה ליזום תנועה בתוך גבולות הגזרה רק אם הקריאה ל-API היא ל-BigQuery API ולשיטה bigquery.tables.getData שצוינה.

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

הגבלנו בהצלחה את BigQuery API ב-project-1 כך שהוא יהיה בשימוש רק על ידי user@example.com ולא על ידי user2@example.com.

גבולות גזרה של VPC Service Controls להגנה על BigQuery API בתרשים הזה ממחיש איך שני חשבונות משתמשים שונים מנסים לשלוח שאילתה על אותו מערך נתונים. הגישה של user2@example.com (קווים כחולים מקווקוות) נדחתה על ידי VPC Service Controls, כי אין להן הרשאה להריץ פעולות BigQuery מההגדרה project-1 של גבולות הגזרה או אליה. הגישה של user@example.com (קו ירוק רציף) בוצעה בהצלחה, כי ההגדרות של 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).

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

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

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

רמת גישה עם רשת VPC

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

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

אפשר להריץ את אותה שאילתה מרשת ה-VPC default, שממוקמת ב-project-2. באופן דומה, הפעלת אותה שאילתת BigQuery ממכונה של Compute Engine שנמצאת ב-project-2 באמצעות רשת ה-VPC default תיכשל. הסיבה לכך היא שכלל תעבורת הנתונים הנכנסת (ingress) עדיין מוגדר לאפשר רק את חשבון המשתמש user@example.com. עם זאת, המכונה הווירטואלית משתמשת בחשבון השירות שמשמש כברירת המחדל של 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).

הגדרת גבולות גזרה לשירות VPC Service Controls עם רמות גישה

במכונה של 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 אבל היא נמצאת באזור שונה מזה של רשת המשנה שנוספה ברמת הגישה, או
  • אם הוא מופעל על ידי המשתמש user@example.com עם לקוח משתמש באינטרנט.

גבולות גזרה לשירות מאפשרים גישה לחשבון השירות שמשמש כברירת מחדל ל-GCE. בתרשים הזה מוצגת גישה שיזמה אותו חשבון משתמש, user@example.com, משני מיקומים שונים: האינטרנט ומכונה של 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 כדי לאשר. מחיקת מכונה של Compute Engine.
  • כדי למחוק את גבולות הגזרה לשירות:
    • במסוף 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 גנרי.