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

1. מבוא

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

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

  • הסבר על תיקון הפרות של תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) באמצעות כללי תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) בשירותים שונים, במיוחד Cloud Storage,‏ BigQuery ושירות העברת הנתונים ל-BigQuery.
  • הסבר על הפרה ספציפית.

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

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

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

הגדרה

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

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

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

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

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

תצורות של VPC SC שמגנות על שירות העברת נתונים.

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

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

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

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

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

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

  • בשדה של שם הקטגוריה, מזינים שם שעומד בקריטריונים לשמות של קטגוריות. ב-codelab הזה, נקרא לקטגוריית האחסון 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

  1. יוצרים מערך נתונים ב-BigQuery בפרויקט project-2 לפי השלבים האלה.
    1. בשדה Dataset ID, מזינים שם ייחודי למערך הנתונים. ב-Codelab הזה אנחנו משתמשים ב: codelab_bqtransfer_dataset.
    2. בשדה Location type, בוחרים מיקום גיאוגרפי לקבוצת הנתונים. ב-Codelab הזה, אנחנו משתמשים באותו מיקום כמו בקטגוריה של Cloud Storage: ארה"ב (מספר אזורים בארצות הברית). יצירת מערך נתונים ב-BigQuery.
  2. יוצרים טבלה ב-BigQuery, במערך הנתונים codelab_bqtransfer_dataset שנוצר, לפי השלבים האלה.
    1. בקטע מקור, בוחרים באפשרות טבלה ריקה ברשימה יצירת טבלה מ.
    2. בשדה Table (טבלה), מזינים את השם של הטבלה שרוצים ליצור. ב-Codelab הזה אנחנו משתמשים בשם: codelab-bqtransfer-table.
    3. מוודאים שהשדה Table type (סוג הטבלה) מוגדר לערך Native table (טבלה מקורית).
    4. בקטע Schema (סכימה), מזינים את הגדרת הסכימה. אפשר להזין את פרטי הסכימה על ידי לחיצה על עריכה כטקסט והזנת הסכימה הבאה, שתואמת לפורמט של קובץ ה-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. מומלץ להשבית את המשאבים שבהם השתמשתם כדי להימנע מחיובים נוספים אחרי סיום ה-codelab.

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

כדי ליצור העברת נתונים, פועלים לפי השלבים הבאים:

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

הפרה של VPC SC בדף שירות העברת נתונים.

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

במסוף 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"
}

כשניגשים לדף 'העברות נתונים', המערכת מנסה להציג רשימה של כל העברות הנתונים שהוגדרו. לכן, זו הפרה של השיטה ListTransferConfigs.

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

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

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

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

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

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

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

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

בדיקת הסטטוס של השירות להעברת נתונים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. פותחים את הדף Access Context Manager במסוף Google Cloud.
    • אם מוצגת בקשה לעשות זאת, בוחרים את התיקייה codelab-folder.
  2. בחלק העליון של הדף Access Context Manager, לוחצים על CREATE ACCESS LEVEL.
  3. בחלונית New Access Level (רמת גישה חדשה), נותנים שם לרמת הגישה החדשה. ב-Codelab הזה, נקרא לו project_2_al.
  4. בקטע תנאים, לוחצים על + לצד רשתות משנה של כתובות IP.
  5. בתיבה IP Subnetworks (רשתות משנה של כתובות IP), בוחרים באפשרות Public IP (כתובת IP גלויה לכולם)

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

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

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

הרצת ההעברה מחדש עם ההגדרות שמגבילות את הגישה לפי כתובת 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, צריך לחכות להעברת הנתונים המתוזמנת הבאה או להפעיל העברה באופן ידני באמצעות השלבים הבאים:

  1. נכנסים לדף BigQuery במסוף Google Cloud.
  2. לוחצים על העברות נתונים.
  3. בוחרים את ההעברה מהרשימה: ב-codelab הזה אנחנו משתמשים בהעברה Codelab Transfer.
  4. לוחצים על הפעלת ההעברה עכשיו.
  5. לוחצים על אישור.

תתחיל העברה נוספת. יכול להיות שתצטרכו לרענן את הדף כדי לראות את השינוי. הפעם ההעברה תיכשל בגלל הפרה של 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"
}

פתרון הפרה של יציאת נתונים מ-Cloud Storage

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

כלל יציאה כדי לאפשר לחשבון השירות של 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 היא הפרת יציאה מ-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 והתחלה מחדש של העתקת מערך הנתונים

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

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

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

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

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

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

8. מעולה!

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

מידע נוסף

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

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

רישיון

העבודה הזו בשימוש במסגרת רישיון Creative Commons שמותנה בייחוס כללי מגרסה 2.0.