דף זה תורגם על ידי Cloud Translation API.

VPC Service Controls – הגנה על שירות העברת הנתונים ל-BigQuery

1. מבוא

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

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

איך מתקנים הפרות של תעבורת נתונים נכנסת ויוצאת באמצעות כללי תעבורת נתונים נכנסת ויוצאת, בהתאמה, בשירותים שונים, במיוחד ב-Cloud Storage, ב-BigQuery ובשירות העברת הנתונים ל-BigQuery.
להבין למה התרחשה הפרה ספציפית.

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

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

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

איך יוצרים תיקייה
איך יוצרים פרויקט בתיקייה או מעבירים פרויקט קיים לתיקייה
איך יוצרים מדיניות גישה ברמת ההיקף
איך יוצרים ומגדירים גבולות גזרה לשירות במסוף Google Cloud
איך מוצאים יומני הפרות מיומני ביקורת

הגדרה

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

תרשים של ההגדרה הראשונית ב-Codelab

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

יצירת מדיניות ברמת ההיקף וגבול שירות רגיל

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

יוצרים מדיניות גישה ברמת ההיקף ברמת התיקייה codelab-folder. בסדנת הקוד הזו, נניח שמזהה של מדיניות הגישה שנוצרה הוא 987654321.
יוצרים גבולות גזרה רגילים, אנחנו קוראים לו perimeter-2, ומוסיפים את הפרויקט project-2.

בגבול perimeter-2, מגבילים את BigQuery Data Transfer API.

הגדרות VPC SC להגנה על Data Transfer Service.

יצירת קטגוריה ב-Cloud Storage ומערך נתונים ב-BigQuery

לצורך הקודלאב הזה, כל קובץ CSV מספיק, ללא קשר לתוכן. המגבלה העיקרית קשורה לדרישה למיקום פיזי משותף, שמחייבת את הדברים הבאים:

אם מערך הנתונים ב-BigQuery נמצא במספר אזורים, הקטגוריה ב-Cloud Storage שמכילה את הנתונים שאתם מעבירים חייבת להיות באותו מספר אזורים או במיקום שנכלל במספר האזורים.
אם מערך הנתונים נמצא באזור מסוים, הקטגוריה ב-Cloud Storage חייבת להיות באותו אזור.

מעכשיו, במסגרת הקודלאב הזה, נדאג שגם הקטגוריה של Cloud Storage וגם מערך הנתונים ב-BigQuery יהיו באותו אזור או במספר אזורים.

יצירת קטגוריה חדשה של Cloud Storage בפרויקט `project-1`

כדי ליצור קטגוריה חדשה ב-Cloud Storage, פועלים לפי השלבים המפורטים במאמר יצירת קטגוריה חדשה.

בשדה 'שם הקטגוריה', מזינים שם שעומד בדרישות לשמות של קטגוריות. בסדנת הקוד הזו, נקרא לקטגוריה codelab-bqtransfer-bucket.
בשדה 'מיקום הנתונים', בוחרים Location type ו-Location שבהם יישמרו נתוני הקטגוריה באופן קבוע. ב-codelab הזה נשתמש ב-us (מספר אזורים בארצות הברית).

הגדרות היצירה של Cloud Storage.

יצירת קובץ CSV

מהמכונה המקומית או באמצעות Cloud Shell, אפשר להשתמש בפקודה echo כדי ליצור קובץ CSV לדוגמה, codelab-test-file.csv, באמצעות הפקודות הבאות:

echo "name,age" > codelab-test-file.csv; \
echo "Alice,10" >> codelab-test-file.csv; \
echo "Bob,20" >> codelab-test-file.csv; \
echo "Carol,30" >> codelab-test-file.csv; \
echo "Dan,40" >> codelab-test-file.csv; \
echo "Eve,50" >> codelab-test-file.csv; \
echo "Frank,60" >> codelab-test-file.csv; \
echo "Grace,70" >> codelab-test-file.csv; \
echo "Heidi,80" >> codelab-test-file.csv;

העלאת קובץ CSV לקטגוריה של Cloud Storage

אחרי שיוצרים את קובץ ה-CSV, מריצים את הפקודה הבאה כדי להעלות את אובייקט הקובץ לקטגוריה שנוצרה:

gcloud storage cp codelab-test-file.csv gs://codelab-bqtransfer-bucket

מריצים את הפקודה cp כדי להעלות קובץ CSV ל-Cloud Storage.

כדי לוודא שהקובץ הועלה לקטגוריה שנוצרה, אפשר לציין את האובייקטים בקטגוריה או להריץ את הפקודה הבאה:

gcloud storage ls --recursive gs://codelab-bqtransfer-bucket/**

יצירת טבלה ומערך נתונים ב-BigQuery ב-`project-2`

יוצרים מערך נתונים ב-BigQuery, בפרויקט project-2, לפי השלבים האלה.
1. בשדה Dataset ID, מזינים שם ייחודי למערך הנתונים. ב-Codelab הזה אנחנו משתמשים ב-codelab_bqtransfer_dataset.
2. בשדה Location type, בוחרים מיקום גיאוגרפי למערך הנתונים. בסדנת הקוד הזו, אנחנו משתמשים באותו מיקום כמו הקטגוריה ב-Cloud Storage: ארה"ב (מספר אזורים בארצות הברית).
יוצרים טבלה ב-BigQuery במסגרת מערך הנתונים codelab_bqtransfer_dataset שנוצר, לפי השלבים האלה.
1. בקטע Source, בוחרים באפשרות Empty table ברשימה Create table from.
2. בשדה Table מזינים את שם הטבלה שרוצים ליצור. ב-Codelab הזה נשתמש בשם: codelab-bqtransfer-table.
3. מוודאים שהשדה Table type מוגדר כ-Native table
4. בקטע Schema, מזינים את ההגדרה של הסכימה. כדי להזין את פרטי הסכימה, לוחצים על Edit as text (עריכה כטקסט) ומזינים את הסכימה הבאה, שתואמת לפורמט של קובץ ה-CSV שנוצר.
```
[{
"name": "name",
"type": "STRING",
"mode": "NULLABLE",
"description": "The name"
},
{
"name": "age",
"type": "INTEGER",
"mode": "NULLABLE",
"description": "The age"
}]
```

עלות

כדי להשתמש במשאבים או בממשקי ה-API של Cloud, צריך להפעיל את החיוב בפרויקטים project-2 ו-project-1. מומלץ להשבית את המשאבים שבהם השתמשתם כדי להימנע מחיוב מעבר לקודלאב הזה.

המשאבים שגורמים לעלויות הם BigQuery ו-Cloud Storage. אפשר למצוא עלות משוערת במחשבון התמחור של BigQuery ובמחשבון של Cloud Storage.

3. הגדרת העברת נתונים מאובייקט ב-Cloud Storage לטבלה ב-BigQuery

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

הגדרת העברת נתונים מ-Cloud Storage

כדי ליצור העברת נתונים:

עוברים אל הדף של BigQuery במסוף Google Cloud של project-2.
לוחצים על העברות נתונים.

הפרת VPC SC בדף של Data Transfer Service.

בדיקת ההפרה בזמן הגישה לדף 'העברות נתונים'

במסוף Google Cloud אפשר לראות את המזהה הייחודי של VPC Service Controls. משתמשים באותו מזהה כדי לסנן יומנים ולזהות את פרטי ההפרה (מחליפים את OBSERVED_VPCSC_DENIAL_UNIQUE_ID במזהה הדחייה שנצפה):

protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="OBSERVED_VPCSC_DENIAL_UNIQUE_ID"

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

ingressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
targetResource: "projects/[PROJECT2_NUMBER]"
}]
violationReason: "NO_MATCHING_ACCESS_LEVEL"
callerIp: "USER_PUBLIC_IP_ADDRESS"
resource: {
labels: {
method: "google.cloud.bigquery.datatransfer.v1.DataTransferService.ListTransferConfigs"
project_id: "project-2"
service: "bigquerydatatransfer.googleapis.com"
}
type: "audited_resource"
}

הגישה לדף Data transfers (העברות נתונים) מנסה לרשום העברות נתונים מוגדרות, ולכן מתרחשת ההפרה של השיטה ListTransferConfigs.

תיקון ההפרה בשירות `bigquerydatatransfer.googleapis.com`

אפשר להשתמש ברמת גישה או בכלל תעבורת נתונים נכנסת (ingress) כדי לתקן הפרה של תעבורת נתונים נכנסת. בקודלאב הזה נשתמש בכלל תעבורת נתונים נכנסת (ingress) שמוגדר עם זהות המשתמש שנדחתה, ומאפשר גישה לשירות bigquerydatatransfer.googleapis.com ולכל השיטות.

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

אחרי שתגדירו את כלל ה-ingress, הגישה לדף Data transfers אמורה לפעול ללא בעיות.

המשך ההגדרה של העברת נתונים מ-Cloud Storage

מהשלבים הקודמים, בדף 'העברות נתונים' (אחרי שלוחצים על 'העברות נתונים'), ממשיכים בשלבים הבאים:

לוחצים על ‎+ Create transfer.
בקטע Source type, בוחרים באפשרות Google Cloud Storage בשדה Source.
בקטע Transfer config name, בשדה Display name, מזינים שם להעברה, למשל Codelab Transfer.
בקטע אפשרויות תזמון:
1. בוחרים תדירות חזרה, למשל 15 דקות.
2. חשוב לבחור באפשרות Start now (אני רוצה להתחיל). אחרת, העברת הנתונים תתחיל רק אחרי תדירות החזרה שהוגדרה.
בקטע Destination settings, בקטע Destination dataset, בוחרים את מערך הנתונים שיצרתם לאחסון הנתונים: codelab_bqtransfer_dataset
בקטע פרטי מקור הנתונים
1. בשדה Destination table, מזינים את שם טבלת היעד. טבלת היעד חייבת לעמוד בכללים למתן שמות לטבלאות. בקודלאב הזה נשתמש בטבלה שיצרנו מקודם: codelab-bqtransfer-table
2. בשדה Cloud Storage URI, מזינים את Cloud Storage URI. ב-codelab הזה נשתמש בקטגוריה ובקובץ שנוצרו: codelab-bqtransfer-bucket/codelab-test-file.csv
3. בשדה Write preference, משאירים את הערך APPEND (או בוחרים באפשרות MIRROR).
4. אל תבחרו למחוק את הקבצים אחרי ההעברה (כי אנחנו נשתמש שוב ושוב באותו קובץ). עם זאת, אפשר להשתמש בכמה קבצים ולמחוק את קובצי המקור אחרי ההעברה).
5. בקטע פורמט הקובץ, בוחרים באפשרות CSV.
6. בקטע Transfer Options (אפשרויות העברה), בקטע CSV (CSV), מזינים פסיק (",") בתור Field delimiter (מפריד שדות).
בתפריט Service Account, בוחרים חשבון שירות מתוך חשבונות השירות שמשויכים לפרויקט ב-Google Cloud
1. לחשבון השירות שנבחר צריכות להיות ההרשאות הנדרשות גם ל-Cloud Storage בפרויקט שמארח את קטגוריית האחסון, project-1 בקודלאב הזה.
2. בסדנת הקוד הזו נשתמש בחשבון שירות שנוצר ב-project-2 בתור codelab-sa@project-2.iam.gserviceaccount.com.
לוחצים על שמירה.

מכיוון שבחרנו באפשרות Start Now (התחלה מיידית) לתזמון, ההעברה הראשונה תתחיל ברגע שבוחרים באפשרות Save (שמירה).

אימות הסטטוס של שירות העברת הנתונים

כדי לבדוק את הסטטוס של העברת הנתונים שהוגדרה:

נכנסים לדף BigQuery במסוף Google Cloud.
לוחצים על העברות נתונים.
מוצגת רשימת ההעברות שהוגדרו

משימות של שירות העברת הנתונים.

לוחצים על Codelab Transfer (מתחת לשם המוצג) ותופיע רשימה של כל ההפעלות שבוצעו עד כה.

פרטים על הפעלות של Data Transfer Service.

העברת הנתונים אמורה להימשך בהצלחה, ללא הפרה של VPC Service Controls גם בהעברת נתונים שהופעלה באופן ידני וגם בהעברת נתונים מתוזמנת. הערה: רק העברה שמופעל באופן ידני זקוקה לכלל תעבורת נתונים נכנסת (ingress) כדי לאפשר גישה לחשבון המשתמש שמפעיל את ההעברה באופן ידני.

4. הגבלות על כתובות IP להעברות נתונים שמופעלות באופן ידני

כללי הכניסה הנוכחיים מאפשרים לזהות שהוגדרה להפעיל העברת נתונים באופן ידני מכל כתובת IP.

בעזרת רמת הגישה, VPC Service Controls מאפשר להגביל את הגישה המותרת לפי מאפיינים ספציפיים של בקשות API, במיוחד:

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

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

גישה שמוגנת על ידי VPC SC לפי כתובת ה-IP של המשתמש בתרשים הזה מוצגת גישה שהתרחשה ביוזמת שני חשבונות המשתמשים (user@example.com ו-user2@example.com) בשלושה תרחישים, שממחישים איך VPC Service Controls מעריך מקורות (רמת גישה לתעבורת נתונים נכנסת) ומאפייני זהות כתנאי AND שבו שני הגורמים חייבים להתאים.

למשתמש user@example.com מותר לגשת כשמנסים לגשת מכתובת IP שמוגדרת כרשות ברמת הגישה, כי כתובת ה-IP וחשבון המשתמש שלו תואמים להגדרות של כלל הקלט.
הגישה של המשתמש user@example.com חסומה כשכתובת ה-IP שלו לא תואמת לכתובת ה-IP המותרת, למרות שזה החשבון שהוגדר בכלל ה-ingress.
הגישה של המשתמש user2@example.com חסומה למרות ניסיון הגישה מכתובת IP מורשית, כי החשבון שלו לא מורשה לפי כלל ה-ingress.

יצירה של רמת גישה

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

פותחים את הדף Access Context Manager במסוף Google Cloud.
- אם מוצגת בקשה לעשות זאת, בוחרים את התיקייה codelab-folder.
בחלק העליון של הדף Access Context Manager, לוחצים על CREATE ACCESS LEVEL.
בחלונית New Access Level, נותנים שם לרמת הגישה החדשה. ב-codelab הזה, נקרא לו project_2_al.
בקטע Conditions, לוחצים על + לפני IP subnetworks.
בתיבה IP Subnetworks בוחרים באפשרות Public IP
- לחלופין, אפשר לבחור להשתמש ב-IP פרטי כדי להשתמש בכתובת IP פנימית ברמות הגישה. עם זאת, בקוד ה-lab הזה אנחנו משתמשים בכתובת IP ציבורית.
- מזינים טווח IPv4 או IPv6 אחד או יותר בפורמט של בלוקים של CIDR.

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

בכלל תעבורת הנתונים נכנסת, רמת הגישה מופיעה בשדה sources. זהו שדה חובה כפי שמתואר במאמר הפנייה לכלל תעבורת נתונים נכנסת. כדי לאפשר תעבורת נתונים נכנסת (ingress) למשאבים, מערכת VPC Service Controls מעריכה את המאפיינים sources ו-identityType כתנאי AND. כלל ה-ingress משתמש בזהות של חשבון המשתמש שמפעיל את העברת הנתונים באופן ידני, ולא בחשבון השירות שצוין בהגדרת העברת הנתונים.

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

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

כדי להעריך את היעילות של ההגדרות שהוחלו, מפעילים את ההעברה שוב לפי התרחישים הבאים:

באמצעות כתובת ה-IP בטווח המותר ברמת הגישה שצוינה בכלל הקלט.
שימוש בכתובת IP שלא מותרת בהגדרות

הגישה מכתובות IP מורשות אמורה להצליח, בעוד שהגישה מכתובות IP לא מורשות אמורה להיכשל ולהוביל להפרה של VPC Service Controls.

אחת מהדרכים הפשוטות לבדוק באמצעות כתובת IP אחרת היא לאפשר כתובת IP שהוקצה בזמן השימוש במסוף Google Cloud, ואז לבדוק באמצעות Cloud Shell.

ב-Cloud Shell, מריצים את הפקודה הבאה כדי להפעיל העברה באופן ידני, ומחליפים את RUN_TIME ואת RESOURCE_NAME:

bq mk \
  --transfer_run \
  --run_time='RUN_TIME' \
  RESOURCE_NAME

לדוגמה, הפקודה לדוגמה הבאה פועלת באופן מיידי להגדרת העברה 12345678-90ab-cdef-ghij-klmnopqrstuv בפרויקט 1234567890.

NOW=$(TZ=GMT date +"%Y-%m-%dT%H:%M:%SZ");
bq mk \
  --transfer_run \
  --run_time=$NOW \
  projects/1234567890/locations/us/transferConfigs/12345678-90ab-cdef-ghij-klmnopqrstuv

הפלט שנצפה מראה הפרה של VPC Service Controls, כצפוי, כי כתובת ה-IP אסורה.

הפרת VPC SC מכתובת IP לא מורשית.

ההפרה זוהתה בשיטה DataTransferService.StartManualTransferRuns.

ingressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
targetResource: "projects/[PROJECT2_NUMBER]"
targetResourcePermissions: [0: "vpcsc.permissions.unavailable"]
}]
violationReason: "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
resource: {
labels: {
method: "google.cloud.bigquery.datatransfer.v1.DataTransferService.StartManualTransferRuns"
project_id: "project-2"
service: "bigquerydatatransfer.googleapis.com"
}
type: "audited_resource"
}
severity: "ERROR"

5. התחלת העברת נתונים תוך הגנה על שירות Cloud Storage

מכיוון שאנחנו מבצעים העברה מ-Cloud Storage ל-BigQuery, נוסיף את Cloud Storage לשירותים שמוגנים על ידי VPC Service Controls ונבדוק אם ההעברה תמשיך לפעול.

בתצורה של perimeter-2, מוסיפים את Cloud Storage API כאחד מהשירותים המוגבלים, יחד עם BigQuery Data Transfer API.

הגדרות VPC SC להגנה על Cloud Storage.

אחרי שמאבטחים את Cloud Storage API, צריך להמתין להעברת הנתונים המתוזמנת הבאה או להפעיל העברה באופן ידני לפי השלבים הבאים:

נכנסים לדף BigQuery במסוף Google Cloud.
לוחצים על העברות נתונים.
בוחרים את ההעברה מהרשימה: בקודלאב הזה אנחנו משתמשים בהעברה של Codelab Transfer
לוחצים על הפעלת ההעברה.
לוחצים על אישור.

תתבצע העברה נוספת. יכול להיות שתצטרכו לרענן את הדף כדי לראות את האפשרות הזו. הפעם ההעברה תיכשל עם הפרה של VPC Service Controls.

הפרה של VPC SC בגלל העתקה של מערך נתונים ב-BigQuery.

חקירה של הפרה של VPC Service Controls ב-Cloud Storage

מסננים את יומני הביקורת באמצעות vpcServiceControlsUniqueIdentifier כפי שמופיע בסיכום של ההעברה.

ההפרה שזוהתה היא הפרת תעבורת נתונים יוצאת (egress) מסוג RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER עם הפרטים הבאים:

חשבון המשתמש הוא חשבון השירות שהוגדר בשירות העברת הנתונים (בין שההפעלה היא ידנית ובין שהיא של העברת הנתונים המתוזמנת, חשבון המשתמש שנדחה יהיה זהה).
השירות המושפע הוא Cloud Storage
המקור של הבקשה הוא הפרויקט שבו הוגדר השירות להעברת נתונים: project-2
פרויקט היעד הוא הפרויקט שבו נמצא האובייקט ב-Cloud Storage: project-1

principalEmail: "codelab-sa@project-2.iam.gserviceaccount.com"
egressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
source: "projects/[PROJECT2_NUMBER]"
sourceType: "Resource"
targetResource: "projects/[PROJECT1_NUMBER]"
targetResourcePermissions: [0: "storage.objects.get"]
}]
labels: {
method: "google.storage.objects.get"
project_id: "project-2"
service: "storage.googleapis.com"
}

תיקון הפרת תעבורת הנתונים היוצאת (egress) ב-Cloud Storage

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

כלל תעבורת נתונים יוצאת (egress) שמאפשר לחשבון השירות של codelab.

אחרי שינוי היקף השירות perimeter-2, צריך לחזור על התהליך כדי להפעיל שוב את ההעברה. לא תופיע שגיאה בהעברה.

פרטי ההפעלות של העברת הנתונים לאחר הגדרת כלל תעבורת הנתונים היוצאת.

6. העתקת מערך נתונים ב-BigQuery מ-project-2 אל project-1

אחרי שמוודאים שאפשר להעביר נתונים מקטגוריה של Cloud Storage ב-project-1 למערך נתונים ב-BigQuery ב-project-2, מעתיקים את מערך הנתונים ב-BigQuery מ-project-2 אל project-1, בזמן שממשק ה-API של BigQuery מוגן על ידי VPC Service Controls.

כדי ליצור ולהעתיק את מערך הנתונים, נשתמש בפקודה bq mk, שמשתמשת בכלי bq.

יצירת מערך נתונים יעד ב-`project-1`

לפני שמעתיקים את מערך הנתונים, צריך ליצור קודם את מערך הנתונים של היעד. כדי ליצור את מערך הנתונים של היעד, אפשר להריץ את הפקודה הבאה, שיוצרת מערך נתונים בשם copied_dataset בפרויקט project-1 עם us כמיקום.

bq mk \
  --dataset \
  --location=us \
  project-1:copied_dataset

הגנה על שירות BigQuery ב-`project-2` באמצעות VPC Service Controls

משנים את ההגדרה של ההיקף perimeter-2 ומוסיפים את BigQuery API כשירות המוגן, יחד עם השירותים BigQuery Data Transfer ו-Cloud Storage.

VPC SC מוגדר להגנה על Cloud Storage API.

הפעלת העתקה של מערך נתונים

כדי להעתיק את מערך הנתונים, מריצים את הפקודה bq mk הבאה. הפקודה מעתיקה את מערך הנתונים codelab_bqtransfer_dataset מהפרויקט project-2 למערך הנתונים copied_dataset ב-project-1, ומחליפת את תוכן מערך הנתונים, אם יש כזה.

bq mk \
  --transfer_config \
  --project_id=project-1 \
  --target_dataset=copied_dataset \
  --data_source=cross_region_copy \
  --display_name='Dataset from project-2 to project-1' \
  --params='{
     "source_dataset_id":"codelab_bqtransfer_dataset",
     "source_project_id":"project-2",
     "overwrite_destination_table":"true"
     }'

הפקודה תפעל בהצלחה, ובמקביל תצורת ההעברה תיוצר כדי להתחיל את הפעולה להעתקת מערך הנתונים. העתקת מערך הנתונים עצמו תיכשל, עם הפרה של VPC Service Controls.

כדי למצוא את פרטי ההפרה התואמים של VPC Service Controls, בודקים את היומנים ב-project-2 (פרויקט מערך הנתונים המקור) באמצעות שאילתה הבא של היומן. שאילתת היומן מסננת יומנים לפי שם המשאב והשירות של BigQuery של מערך הנתונים שמעתיקים (codelab_bqtransfer_dataset).

resource.labels.service="bigquery.googleapis.com"
protoPayload.metadata.resourceNames:"datasets/codelab_bqtransfer_dataset"

ההפרה של VPC Service Controls היא הפרת תעבורת נתונים יוצאת (egress) מ-project-2 אל project-1.

egressViolations: [
  0: {
   servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
   source: "projects/[PROJECT-2-NUMBER]"
   sourceType: "Resource"
   targetResource: "projects/[PROJECT-1-NUMBER]"
   targetResourcePermissions: [
     0: "bigquery.transfers.update"
     1: "bigquery.transfers.get"
     2: "bigquery.jobs.create"
     ]
   }
]
method: "bigquery.tables.getData"
service: "bigquery.googleapis.com"

מתקנים את כל ההפרות ב-BigQuery ומתחילים שוב להעתיק את מערך הנתונים

כדי לתקן את ההפרה של תעבורת הנתונים היוצאת, צריך ליצור כלל תעבורת נתונים יוצאת שמאפשר לחשבון המשתמש שנדחה. חשבון המשתמש שנדחה הוא זה שמריץ את הפקודה mk.

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

אחרי שמגדירים את כלל תעבורת הנתונים היוצאת, מריצים את אותה הפקודה כדי להעתיק את מערך הנתונים ב-perimeter-2. הפעם, המערכת אמורה להעתיק את מערך הנתונים בהצלחה ללא הפרה של VPC Service Controls.

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

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

כדי למחוק את הקטגוריה של Cloud Storage, מבצעים את השלבים הבאים:
- נכנסים לדף Cloud Storage Buckets במסוף Google Cloud.
- מסמנים את התיבה של הקטגוריה שרוצים למחוק ולוחצים על מחיקה.
- בחלון שכבת-העל שמופיע, מאשרים שרוצים למחוק את הקטגוריה ואת התוכן שלה.
כדי למחוק את מערך הנתונים ב-BigQuery, מבצעים את השלבים הבאים:
- נכנסים לדף BigQuery במסוף Google Cloud.
- בחלונית Explorer מרחיבים את הפרויקט ובוחרים מערך נתונים.
- מרחיבים את תפריט שלוש הנקודות ולוחצים על מחיקה.
- בתיבת הדו-שיח Delete dataset, מקלידים delete בשדה ולוחצים על Delete.
כדי למחוק את service perimeter, מבצעים את השלבים הבאים:
- במסוף Google Cloud, בוחרים באפשרות Security ואז ב-VPC Service Controls ברמה שבה היקף מדיניות הגישה מוגדר, במקרה הזה ברמת התיקייה.
- בדף VPC Service Controls, בשורה בטבלה שתואם לגבול הגזרה שרוצים למחוק, בוחרים באפשרות Delete Icon.
כדי למחוק את רמת הגישה, מבצעים את השלבים הבאים:
- במסוף Google Cloud, פותחים את הדף Access Context Manager ברמת התיקייה.
- בתצוגת הרשת, מאתרים את השורה של רמת הגישה שרוצים למחוק, לוחצים על תפריט שלוש הנקודות ואז על מחיקה.
כדי להשבית את הפרויקטים, מבצעים את השלבים הבאים:
- נכנסים לדף IAM & Admin Settings (הגדרות IAM ואדמין) של הפרויקט שרוצים למחוק במסוף Google Cloud.
- בדף IAM & Admin Settings (הגדרות IAM ואדמין), בוחרים באפשרות Shutdown (השבתה).
- מזינים את מזהה הפרויקט ובוחרים באפשרות Shutdown anyway.

8. מעולה!

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

מידע נוסף

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

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

רישיון

העבודה הזו בשימוש במסגרת רישיון Creative Commons Attribution 2.0 Generic.