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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מידע נוסף על מתן התפקיד Policy Tag Admin זמין במאמר הגבלת הגישה באמצעות אבטחה ברמת העמודה ב-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 במסוף Cloud de Confiance או באמצעות Google Cloud CLI.

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

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

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

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

במאמר יצירת חשבונות שירות מוסבר איך יוצרים חשבון שירות חדש.

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

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

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

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

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

המסוף

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

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

  2. במאמר יצירת משימה לתזמון עם אימות מוסבר איך להגדיר Target.

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

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

  2. בקטע Auth header, בוחרים באפשרות 'Add OAuth token' (הוספת טוקן OAuth).

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

  4. בשדה Scope (היקף), מזינים https://www.googleapis.com/auth/cloud-platform.

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

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

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

  1. אחרי שיוצרים את העבודה, לוחצים על הפעלה עכשיו כדי לבדוק שהעבודה מוגדרת בצורה נכונה. לאחר מכן, 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. לחלופין, מפתחים שמכירים את cron מדור קודם של App Engine יכולים להשתמש בתחביר של 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.s3ns.iam.gserviceaccount.com" --time-zone="America/Los_Angeles" --message-body-from-file=request_body.json

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