ניהול תגי מדיניות במיקומים שונים

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

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

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

שיקולים בקשר למיקום

טקסונומיות הן משאבים אזוריים, כמו מערכי נתונים וטבלאות ב-BigQuery. כשיוצרים טקסונומיה, מציינים את האזור או את המיקום של הטקסונומיה.

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

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

שימוש בטקסונומיות במיקומים שונים

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

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

אפשר לסנכרן שוב את הטקסונומיה ואת תגי המדיניות כדי לשמור על אחידות בכמה מיקומים. כדי לשכפל טקסונומיה באופן מפורש, צריך לשלוח קריאה ל-Data Catalog API. בסנכרונים עתידיים של הטקסונומיה המשוכפלת נעשה שימוש באותה פקודת API, שמחליפה את הטקסונומיה הקודמת.

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

שכפול טקסונומיה במיקום חדש

ההרשאות הנדרשות

לפרטי הכניסה של המשתמש או לחשבון השירות שמשכפלים את הטקסונומיה צריך להיות התפקיד "אדמין של תגי מדיניות ב-Data Catalog".

במאמר הגבלת הגישה באמצעות אבטחה ברמת העמודה ב-BigQuery מוסבר איך מקצים את התפקיד "אדמין של תגי מדיניות".

במאמר תפקידים והרשאות מוגדרים מראש תוכלו לקרוא מידע נוסף על תפקידים והרשאות של IAM ב-BigQuery.

כדי לשכפל טקסונומיה בין מיקומים:

API

מפעילים את ה-method‏ projects.locations.taxonomies.import של Data Catalog API, ומספקים בקשת POST ואת השם של פרויקט היעד והמיקום במחרוזת ה-HTTP.

POST https://datacatalog.googleapis.com/{parent}/taxonomies:import

הפרמטר של הנתיב parent הוא הפרויקט והמיקום שאליהם רוצים להעתיק את הטקסונומיה. לדוגמה: projects/MyProject/locations/eu

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

כדי לסנכרן טקסונומיה שכבר שוכפלה במיקומים שונים, חוזרים על הקריאה ל-Data Catalog API כפי שמתואר בקטע שכפול טקסונומיה במיקום חדש.

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

סנכרון טקסונומיה משוכפלת באמצעות Cloud Scheduler

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

חשבונות שירות

אתם יכולים לתת הרשאות לסנכרון הרפליקציה לחשבון שירות קיים, או ליצור חשבון שירות חדש.

כדי ליצור חשבון שירות חדש, קראו את המאמר יצירת חשבונות שירות.

ההרשאות הנדרשות

  1. לחשבון השירות שמסנכרן את הטקסונומיה צריך להיות התפקיד "אדמין של תגי מדיניות ב-Data Catalog". למידע נוסף, קראו על התפקיד "אדמין של תגי מדיניות ב-Data Catalog".

  2. הפעלה של Cloud Scheduler API

הגדרת סנכרון טקסונומיה באמצעות Cloud Scheduler

כדי לסנכרן טקסונומיה משוכפלת בין מיקומים באמצעות Cloud Scheduler:

המסוף

קודם כל, יוצרים את משימת הסנכרון ואת לוח הזמנים שלה.

  1. פועלים לפי ההוראות ליצירת משימה ב-Cloud Scheduler.

  2. בשביל Target, קראו את ההוראות במאמר יצירת משימה מתוזמנת עם אימות.

בשלב הבא, מוסיפים את האימות שנדרש לסנכרון המתוזמן.

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

  2. בקטע כותרת אימות, בוחרים באפשרות "הוספת אסימון OAuth".

  3. מוסיפים את הפרטים של חשבון השירות.

  4. בשדה Scope, מזינים את הערך "https://www.googleapis.com/auth/cloud-platform".

  5. לוחצים על יצירה כדי לשמור את הסנכרון המתוזמן.

    יצירת משימה מתוזמנת – חלק 2

עכשיו בודקים שהמשימה מוגדרת כמו שצריך.

  1. אחרי שיוצרים את המשימה, לוחצים על Run now כדי לבדוק שהיא מוגדרת כמו שצריך. לאחר מכן, Cloud Scheduler מפעיל את בקשת ה-HTTP לפי לוח הזמנים שציינתם.

    בדיקת משימה של מתזמן

gcloud

תחביר:

  gcloud scheduler jobs create http "JOB_ID" --schedule="FREQUENCY" --uri="URI" --oath-service-account-email="CLIENT_SERVICE_ACCOUNT_EMAIL" --time-zone="TIME_ZONE" --message-body-from-file="MESSAGE_BODY"

מחליפים את מה שכתוב בשדות הבאים:

  1. ‫${JOB_ID} הוא שם המשימה. הוא חייב להיות ייחודי בפרויקט. שימו לב שאי אפשר להשתמש שוב בשם של משימה בפרויקט, גם אם מוחקים את המשימה שמשויכת אליו.
  2. ‫${FREQUENCY} הוא לוח הזמנים, שנקרא גם מרווח זמן של משימה, שקובע באיזו תדירות המשימה תפעל. לדוגמה, "כל 3 שעות". המחרוזת שאתם מספקים כאן יכולה להיות כל מחרוזת שתואמת ל-crontab. לחלופין, מפתחים שמכירים את App Engine cron מדור קודם יכולים להשתמש בתחביר של App Engine Cron.
  3. ‫${URI} היא כתובת ה-URL המלאה של נקודת הקצה.
  4. ‫--oauth-service-account-email מגדיר את סוג הטוקן. חשוב לזכור שממשקי Google API שמתארחים ב-*.googleapis.com מצפים לטוקן OAuth.
  5. ‫${CLIENT_SERVICE_ACCOUNT_EMAIL} הוא כתובת האימייל של חשבון השירות של הלקוח.
  6. ‫${MESSAGE_BODY} הוא הנתיב לקובץ שמכיל את גוף הבקשה של POST.

יש פרמטרים נוספים של אפשרויות, שמתוארים בחומר העזר של Google Cloud CLI.

דוגמה:

  gcloud scheduler jobs create http cross_regional_copy_to_eu_scheduler --schedule="0 0 1 * *" --uri="https://datacatalog.googleapis.com/v1/projects/my-project/locations/eu/taxonomies:import" --oauth-service-account-email="policytag-manager-service-acou@my-project.iam.gserviceaccount.com" --time-zone="America/Los_Angeles" --message-body-from-file=request_body.json

המאמרים הבאים