מבוא לאנונימיזציה של נתונים

הערה: יכול להיות שהתכונה הזו לא תהיה זמינה כשמשתמשים בהזמנות שנוצרו במהדורות מסוימות של BigQuery. מידע נוסף על התכונות שמופעלות בכל מהדורה זמין במאמר מבוא למהדורות BigQuery.

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

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

יתרונות

היתרונות של מיסוך נתונים:

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

תהליך עבודה של ביצוע אנונימיזציה של נתונים

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

הגדרת מדיניות נתונים ישירות בעמודה

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

1. יצירת מדיניות נתונים.

2. הקצאת מדיניות נתונים לעמודה.

הסתרת נתונים באמצעות תגי מדיניות

איור 1 מציג את תהליך העבודה להגדרת מיסוך נתונים:

איור 1. רכיבים של ביצוע אנונימיזציה של נתונים.

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

1. מגדירים טקסונומיה ותג מדיניות אחד או יותר.

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

   כשיוצרים מדיניות נתונים באמצעות מסוף Google Cloud , יוצרים את כלל מיסוך הנתונים ומציינים את החשבונות הראשיים בשלב אחד. כשיוצרים מדיניות גישה לנתונים באמצעות BigQuery Data Policy API, יוצרים את מדיניות הגישה לנתונים ואת כלל מיסוך הנתונים בשלב אחד, ומציינים את הגורמים הרלוונטיים למדיניות הגישה לנתונים בשלב השני.

3. מקצים את תגי המדיניות לעמודות בטבלאות BigQuery כדי להחיל את מדיניות הנתונים.

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

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

באיור 2 רואים איך בקרת גישה ברמת העמודה והסתרת נתונים פועלות יחד:

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

מידע נוסף על אינטראקציה בין תפקידים זמין במאמר איך פועלת האינטראקציה בין התפקידים Masked Reader ו-Fine-Grained Reader. מידע נוסף על ירושה של תגי מדיניות זמין במאמר תפקידים והיררכיה של תגי מדיניות.

כללים להסתרת נתונים

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

אפשר להשתמש בכללי מיסוך הנתונים הבאים:

• שגרת מיסוך בהתאמה אישית. הפונקציה מחזירה את הערך של העמודה אחרי החלת פונקציה להגדרת המשתמש (UDF) על העמודה. כדי לנהל את כלל ההסתרה, נדרשות הרשאות שגרתיות. הכלל הזה תומך בכל סוגי הנתונים של BigQuery, חוץ מסוג הנתונים STRUCT. עם זאת, התמיכה בסוגי נתונים אחרים מלבד STRING ו-BYTES מוגבלת. הפלט תלוי בפונקציה שהוגדרה.

  מידע נוסף על יצירת פונקציות UDF לשגרות מותאמות אישית של מיסוך זמין במאמר יצירת שגרות מותאמות אישית של מיסוך.

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

  סוג	מקורי	בוצעה אנונימיזציה
  DATE	2030-07-17	2030-01-01
  DATETIME	2030-07-17T01:45:06	2030-01-01T00:00:00
  TIMESTAMP	2030-07-17 01:45:06	2030-01-01 00:00:00

  הערה: החיתוך מתבצע לפי אזור הזמן UTC. כדי לשנות את זה, צריך לשנות את אזור הזמן שמוגדר כברירת מחדל באמצעות @@time_zone משתנה המערכת.

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

  בטבלה הבאה מוצג ערך המיסוך שמוגדר כברירת מחדל לכל סוג נתונים:

  סוג הנתונים	ערך ברירת מחדל לאנונימיזציה
  STRING	""
  BYTES	b''
  INTEGER	0
  FLOAT	0.0
  NUMERIC	0
  BOOLEAN	FALSE
  TIMESTAMP	‫1970-01-01 00:00:00 UTC
  DATE	1970-01-01
  TIME	00:00:00
  DATETIME	1970-01-01T00:00:00
  GEOGRAPHY	POINT(0 0)
  BIGNUMERIC	0
  ARRAY	[]
  STRUCT	NOT_APPLICABLE אי אפשר להחיל תגי מדיניות על עמודות שמשתמשות בסוג הנתונים STRUCT, אבל אפשר לשייך אותם לשדות העלים של עמודות כאלה.
  JSON	null

• מסכת אימייל. הפונקציה מחזירה את הערך של העמודה אחרי החלפת שם המשתמש של כתובת אימייל תקינה ב-XXXXX. אם הערך בעמודה הוא לא כתובת אימייל תקינה, הפונקציה מחזירה את הערך בעמודה אחרי שהיא מופעלת באמצעות פונקציית הגיבוב (hash) SHA-256. אפשר להשתמש בכלל הזה רק עם עמודות שמשתמשות בSTRING סוג הנתונים. לדוגמה:

  מקורי	בוצעה אנונימיזציה
  [e-mail]	[e-mail]
  randomtext	jQHDyQuj7vJcveEe59ygb3Zcvj0B5FJINBzgM6Bypgw=
  test@[e-mail]	Qdje6MO+GLwI0u+KyRyAICDjHbLF1ImxRqaW08tY52k=

• ארבעת התווים הראשונים. הפונקציה מחזירה את 4 התווים הראשונים של ערך העמודה, ומחליפה את שאר המחרוזת ב-XXXXX. אם הערך בעמודה הוא באורך של 4 תווים או פחות, הפונקציה מחזירה את הערך בעמודה אחרי שהיא מופעלת באמצעות פונקציית הגיבוב SHA-256. אפשר להשתמש בכלל הזה רק עם עמודות שמשתמשות בסוג הנתונים STRING.

• גיבוב (hash)‏ (SHA-256). הפונקציה מחזירה את הערך של העמודה אחרי שהיא הופעלה באמצעות פונקציית הגיבוב (hash) SHA-256. משתמשים בזה כשרוצים שמשתמש הקצה יוכל להשתמש בעמודה הזו בפעולה JOIN בשאילתה. אפשר להשתמש בכלל הזה רק עם עמודות שמשתמשות בסוגי הנתונים STRING או BYTES.

  הפונקציה SHA-256 שמשמשת לאנונימיזציה של נתונים שומרת על סוג הנתונים, כך שערך הגיבוב (hash) שהיא מחזירה הוא מאותו סוג נתונים כמו ערך העמודה. לדוגמה, ערך הגיבוב של ערך בעמודה STRING הוא גם מסוג הנתונים STRING.

  חשוב: SHA-256 היא פונקציית גיבוב (hashing) דטרמיניסטית. ערך התחלתי תמיד יומר לאותו ערך גיבוב. עם זאת, לא נדרשים מפתחות הצפנה. כך שגורם זדוני יכול להשתמש במתקפת כוח ברוטלי כדי לקבוע את הערך המקורי. הוא יכול להריץ את כל הערכים המקוריים האפשריים באמצעות אלגוריתם SHA-256 ולראות איזה מהם יוצר גיבוב שתואם לגיבוב שמוחזר על ידי הסתרת הנתונים.

• גיבוב אקראי. הפונקציה מחזירה גיבוב של ערך העמודה באמצעות אלגוריתם גיבוב עם מלח. גיבוב אקראי מספק אבטחה חזקה יותר מאשר כלל Hash (SHA-256) הרגיל.

  • Non-deterministic: A unique random value (salt) is generated for each query. אותו ערך בעמודה מפיק תוצאות גיבוב שונות בשאילתות שונות. כך אפשר למנוע מתקפות כוח ברוטלי וניתוח של דפוסי נתונים מוסווים לאורך זמן.
  • שליטה באפשרות ההצטרפות:
    • אפשר לבצע הצטרפות בעמודות שמוסוות באמצעות RANDOM_HASH רק באותה שאילתה.
    • אי אפשר לבצע הצטרפות בין שאילתות שונות בגלל ה-salt האקראי לכל שאילתה.
    • אפשר לבצע פעולות איחוד רק אם מדיניות הנתונים שחלה על העמודות שייכת לאותו פרויקט. Google Cloud האכיפה מתבצעת על ידי הכללת מזהה הפרויקט של מדיניות הנתונים בקלט הגיבוב.
  • תרחיש לדוגמה: מתאים כשצריך את השלמות ההפניה של גיבוב (hashing) לצירופים בתוך שאילתה, אבל נדרשת רמת אבטחה חזקה יותר מפני מתקפות אופליין מאשר SHA-256 רגיל.
  • סוגי נתונים נתמכים: אפשר להשתמש בפונקציה הזו עם עמודות של סוגי נתונים STRING או BYTES.
  • מגבלות:
    • גיבוב אקראי הוא כלל מוגדר מראש להסתרת נתונים, ואי אפשר להשתמש בו בשגרות מותאמות אישית להסתרת נתונים.
    • הצפנה אקראית באמצעות hash נתמכת רק במדיניות נתונים שמוגדרת בעמודות, ולא בתגי מדיניות.

• ארבעת התווים האחרונים. הפונקציה מחזירה את 4 התווים האחרונים של ערך העמודה, ומחליפה את שאר המחרוזת ב-XXXXX. אם הערך של העמודה שווה ל-4 תווים או פחות, הפונקציה מחזירה את הערך של העמודה אחרי שהיא מופעלת באמצעות פונקציית הגיבוב SHA-256. אפשר להשתמש בכלל הזה רק עם עמודות שמשתמשות בסוג הנתונים STRING.

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

היררכיה של כללים לאנונימיזציה של נתונים

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

1. שגרת מיסוך בהתאמה אישית
2. גיבוב אקראי
3. גיבוב (hash)‏ (SHA-256)
4. אנונימיזציה של כתובת האימייל
5. ארבעת התווים האחרונים
6. ארבעת התווים הראשונים
7. אנונימיזציה של שנת התאריך
8. ערך ברירת מחדל לאנונימיזציה
9. איפוס

לדוגמה, משתמש א' הוא חבר בקבוצות 'עובדים' ו'חשבונאות'. משתמש א' מריץ שאילתה שכוללת את השדה sales_total, שמוחל עליו תג המדיניות confidential. לתג המדיניות confidential משויכות שתי מדיניות נתונים: אחת שבה התפקיד employees (עובדים) מוגדר כחשבון המשתמש, והיא מחילה את כלל מיסוך הנתונים nullify (ביטול), ואחת שבה התפקיד accounting (חשבונאות) מוגדר כחשבון המשתמש, והיא מחילה את כלל מיסוך הנתונים hash (גיבוב) ‏(SHA-256). במקרה הזה, כלל אנונימיזציית הנתונים של הגיבוב (SHA-256) מקבל עדיפות על פני כלל אנונימיזציית הנתונים של ההחלפה בערך null, ולכן כלל הגיבוב (SHA-256) מוחל על ערך השדה sales_total בשאילתה של משתמש א'.

איור 3 מציג את התרחיש הזה:

איור 3. תעדוף של כללים לאנונימיזציה של נתונים.

תפקידים והרשאות

תפקידים לניהול טקסונומיות ותגי מדיניות

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

תפקיד/מזהה	הרשאות	תיאור
אדמין של תגי מדיניות ב-Data Catalog (datacatalog.categoryAdmin)	datacatalog.categories.getIamPolicy datacatalog.categories.setIamPolicy datacatalog.taxonomies.create datacatalog.taxonomies.delete datacatalog.taxonomies.get datacatalog.taxonomies.getIamPolicy datacatalog.taxonomies.list datacatalog.taxonomies.setIamPolicy datacatalog.taxonomies.update resourcemanager.projects.get resourcemanager.projects.list	ההגדרה חלה ברמת הפרויקט. התפקיד הזה מאפשר לבצע את הפעולות הבאות: יצירה, קריאה, עדכון ומחיקה של טקסונומיות ותגי מדיניות. קבלת מדיניות IAM והגדרת מדיניות IAM בתגי מדיניות.

תפקידים ליצירה ולניהול של מדיניות בנושא נתונים

כדי ליצור ולנהל מדיניות בנושא נתונים, צריך להיות לכם אחד מהתפקידים הבאים ב-BigQuery:

תפקיד/מזהה	הרשאות	תיאור
אדמין של מדיניות נתונים ב-BigQuery‏ (bigquerydatapolicy.admin) אדמין של BigQuery‏ (bigquery.admin) בעלים של נתונים ב-BigQuery‏ (bigquery.dataOwner)	bigquery.dataPolicies.create bigquery.dataPolicies.delete bigquery.dataPolicies.get bigquery.dataPolicies.getIamPolicy bigquery.dataPolicies.list bigquery.dataPolicies.setIamPolicy bigquery.dataPolicies.update	ההרשאות bigquery.dataPolicies.create ו-bigquery.dataPolicies.list חלות ברמת הפרויקט. שאר ההרשאות חלות ברמת מדיניות הנתונים. התפקיד הזה מאפשר לבצע את הפעולות הבאות: יצירה, קריאה, עדכון ומחיקה של כללי מדיניות בנושא נתונים. קבלת מדיניות IAM והגדרת מדיניות IAM במדיניות בנושא נתונים.

אתם צריכים גם את ההרשאה datacatalog.taxonomies.get, שאפשר לקבל אותה מכמה תפקידים מוגדרים מראש ב-Data Catalog.

תפקידים לצירוף תגי מדיניות לעמודות

כדי לצרף תגי מדיניות לעמודות, נדרשות ההרשאות datacatalog.taxonomies.get ו-bigquery.tables.setCategory. ההרשאה datacatalog.taxonomies.get כלולה בתפקידים 'אדמין' ו'צפייה' בתגי מדיניות של Data Catalog. ‫bigquery.tables.setCategory נכלל בתפקידים BigQuery Admin ‏ (roles/bigquery.admin) ו-BigQuery Data Owner ‏ (roles/bigquery.dataOwner).

תפקידים להרצת שאילתות על נתונים מוסווים

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

תפקיד/מזהה	הרשאות	תיאור
קורא מוסתר (bigquerydatapolicy.maskedReader)	bigquery.dataPolicies.maskedGet	אפשר לתת את התפקיד הזה רק למשאבים ב-מנהל המשאבים (פרויקטים, תיקיות וארגונים). התפקיד הזה מאפשר להציג את הנתונים המוסווים של עמודה שמשויכת למדיניות גישה לנתונים. בנוסף, למשתמש צריכות להיות הרשאות מתאימות כדי להריץ שאילתות על הטבלה. מידע נוסף זמין במאמר בנושא הרשאות נדרשות.

איך תפקידי הקורא המוסווה והקורא עם ההרשאות המפורטות פועלים יחד

הסתרת נתונים מבוססת על בקרת גישה ברמת העמודה. בעמודה מסוימת, יכול להיות שלחלק מהמשתמשים יש את התפקיד 'קורא נתונים מוסווים' ב-BigQuery שמאפשר להם לקרוא נתונים מוסווים, לחלק מהמשתמשים יש את התפקיד 'קורא מדויק' ב-Data Catalog שמאפשר להם לקרוא נתונים לא מוסווים, לחלק מהמשתמשים יש את שני התפקידים, ולחלק מהמשתמשים אין אף אחד מהתפקידים. התפקידים האלה פועלים כך:

• משתמש עם התפקידים 'קריאה עם הרשאות גישה מדויקות' ו'קריאה עם הסתרת נתונים': מה שהמשתמש רואה תלוי במיקום שבו כל תפקיד מוענק בהיררכיה של תגי המדיניות. מידע נוסף זמין במאמר ירושת הרשאות בהיררכיה של תגי מדיניות.
• משתמש עם תפקיד קריאה עם הרשאות גישה מדויקות: יכול לראות נתוני עמודות לא מוסתרים (לא מוצפנים).
• משתמש עם תפקיד Masked Reader: יכול לראות נתונים בעמודות מוסתרות (מוסווים).
• משתמש ללא אף אחד מהתפקידים: ההרשאה נדחית.

אם בטבלה יש עמודות שמוגנות או שמוגנות ומוסתרות, כדי להריץ הצהרת SELECT * FROM בטבלה הזו, המשתמש צריך להיות חבר בקבוצות המתאימות, כך שיוקצו לו התפקידים 'הרשאת קריאה עם הסתרת נתונים' או 'הרשאת קריאה עם גישה מדויקת' בכל העמודות האלה.

משתמש שלא קיבל את התפקידים האלה צריך לציין בהצהרת SELECT רק עמודות שיש לו גישה אליהן, או להשתמש ב-SELECT * EXCEPT (restricted_columns) FROM כדי להחריג את העמודות המאובטחות או המוסתרות.

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

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

לדוגמה, נניח שיש לכם תג מדיניות והגדרת מדיניות נתונים כמו שמוצג באיור 4:

איור 4. הגדרת תג מדיניות ומדיניות נתונים.

יש לכם עמודה בטבלה שמוערת בתג המדיניות Financial, ומשתמש שהוא חבר בקבוצות [e-mail] ו[e-mail]. כשהמשתמש הזה מריץ שאילתה שכוללת את העמודה עם ההערה, הגישה שלו נקבעת לפי ההיררכיה שמוגדרת בטקסונומיה של תגי המדיניות. השאילתה מחזירה נתונים לא מוסווים בעמודה, כי תג המדיניות Financial מעניק למשתמש את התפקיד Data Catalog Fine-Grained Reader.

אם משתמש אחר שהוא רק חבר בתפקיד [e-mail] מריץ שאילתה שכוללת את העמודה עם ההערה, השאילתה מחזירה נתוני עמודה שעברו גיבוב באמצעות אלגוריתם SHA-256, כי למשתמש מוענק התפקיד Masked Reader (קורא עם מיסוך) ב-BigQuery באמצעות תג המדיניות Confidential, שהוא תג האב של תג המדיניות Financial.

משתמש שלא משויך לאף אחת מההרשאות האלה יקבל שגיאה על דחיית גישה אם הוא ינסה להריץ שאילתה על העמודה עם ההערות.

לעומת זאת, נניח שיש לנו את תג המדיניות ואת הגדרת מדיניות הנתונים שמוצגים באיור 5:

איור 5. הגדרת תג מדיניות ומדיניות נתונים.

המצב זהה לזה שמוצג באיור 4, אבל למשתמש מוקצית הרשאת Fine-Grained Reader ברמה גבוהה יותר בהיררכיית תגי המדיניות, והרשאת Masked Reader ברמה נמוכה יותר בהיררכיית תגי המדיניות. לכן, השאילתה מחזירה נתונים מוסווים בעמודה לגבי המשתמש הזה. זה קורה למרות שהמשתמש קיבל את התפקיד Fine-Grained Reader (קריאה עם הרשאות גישה מפורטות) ברמה גבוהה יותר בהיררכיית התגים, כי השירות משתמש בתפקיד הראשון שמוקצה לו שהוא נתקל בו כשהוא עולה בהיררכיית תגי המדיניות כדי לבדוק את גישת המשתמש.

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

• תג מדיניות 1
  • תג מדיניות 1a
    • תג מדיניות 1ai
  • תג מדיניות 1b
    • תג מדיניות 1bi
    • תג מדיניות 1bii

אם רוצים שמדיניות נתונים תחול על כל תגי המדיניות האלה, מגדירים את מדיניות הנתונים בתג מדיניות 1. אם רוצים שמדיניות נתונים תחול על תג מדיניות 1b ועל תגי המדיניות המשניים שלו, צריך להגדיר את מדיניות הנתונים בתג מדיניות 1b.

הסתרת נתונים באמצעות תכונות לא תואמות

כשמשתמשים בתכונות של BigQuery שלא תואמות להסתרת נתונים, השירות מתייחס לעמודה המוסתרת כעמודה מאובטחת, ומעניק גישה רק למשתמשים שיש להם את התפקיד Data Catalog Fine-Grained Reader.

לדוגמה, ניקח את תג המדיניות ואת הגדרת מדיניות הנתונים שמוצגים באיור 6:

איור 6. הגדרת תג מדיניות ומדיניות נתונים.

יש לכם עמודה בטבלה עם ההערה של תג המדיניות Financial, ומשתמש שהוא חבר בקבוצה [e-mail]. כשמשתמש מנסה לגשת לעמוד עם ההערות באמצעות אחת מהתכונות הלא תואמות, הוא מקבל שגיאת דחיית גישה. הסיבה לכך היא שהם מקבלים את תפקיד BigQuery Masked Reader (קורא עם מיסוך) באמצעות תג מדיניות Financial, אבל במקרה הזה הם צריכים לקבל את התפקיד Data Catalog Fine-Grained Reader (קורא פרטני ב-Data Catalog). מכיוון שהשירות כבר קבע תפקיד רלוונטי למשתמש, הוא לא ממשיך לבדוק את היררכיית תגי המדיניות כדי למצוא הרשאות נוספות.

דוגמה לביצוע אנונימיזציה של נתונים עם פלט

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

בדומיין example.com, גישה בסיסית ניתנת דרך הקבוצה [e-mail]. כל העובדים שצריכים גישה קבועה לנתוני BigQuery הם חברים בקבוצה הזו, שמוקצות לה כל ההרשאות הנדרשות לקריאה מטבלאות, וגם התפקיד BigQuery Masked Reader.

העובדים משויכים לקבוצות נוספות שמעניקות גישה לעמודות מאובטחות או מוסתרות, אם זה נדרש לעבודה שלהם. כל החברים בקבוצות הנוספות האלה הם גם חברים בקבוצה [e-mail]. באיור 7 אפשר לראות איך הקבוצות האלה משויכות לתפקידים המתאימים:

איור 7. תגי מדיניות ומדיניות נתונים עבור example.com.

תגי המדיניות משויכים לעמודות בטבלה, כמו שמוצג באיור 8:

איור 8. תגי מדיניות של example.com שמשויכים לעמודות בטבלה.

בהינתן התגים שמשויכים לעמודות, הפעלת SELECT * FROM Accounts; מובילה לתוצאות הבאות עבור הקבוצות השונות:

• ‫[e-mail]: לקבוצה הזו הוענק התפקיד BigQuery Masked Reader (משתמש עם הרשאת קריאה מוסתרת ב-BigQuery) בתגי המדיניות PII ו-Confidential. התוצאות הבאות מוחזרות:

  SSN	עדיפות	ערך חיי המשתמש	תאריך היצירה	אימייל
  NULL	""	0	‫8 במרץ 1983	NULL
  NULL	""	0	‫29 בדצמבר 2009	NULL
  NULL	""	0	‫14 ביולי 2021	NULL
  NULL	""	0	‫5 במאי 1997	NULL

• ‫[e-mail]: לקבוצה הזו הוקצה התפקיד Data Catalog Fine-Grained Reader בתג המדיניות SSN. התוצאות הבאות מוחזרות:

  SSN	עדיפות	ערך חיי המשתמש	תאריך היצירה	NULL
  123-45-6789	""	0	‫8 במרץ 1983	NULL
  234-56-7891	""	0	‫29 בדצמבר 2009	NULL
  345-67-8912	""	0	‫14 ביולי 2021	NULL
  456-78-9123	""	0	‫5 במאי 1997	NULL

• ‫[e-mail]: לקבוצה הזו הוקצה התפקיד 'קריאה פרטנית' ב-Data Catalog בתג המדיניות Confidential. התוצאות הבאות מוחזרות:

  SSN	עדיפות	ערך חיי המשתמש	תאריך היצירה	אימייל
  NULL	גבוהה	90,000	‫8 במרץ 1983	NULL
  NULL	גבוהה	84,875	‫29 בדצמבר 2009	NULL
  NULL	בינוני	38,000	‫14 ביולי 2021	NULL
  NULL	נמוכה	245	‫5 במאי 1997	NULL

• ‫[e-mail]: לקבוצה הזו הוקצה התפקיד BigQuery Masked Reader (קריאה מוסתרת ב-BigQuery) בתג המדיניות Financial. התוצאות הבאות מוחזרות:

  SSN	עדיפות	ערך חיי המשתמש	תאריך היצירה	אימייל
  NULL	""	Zmy9vydG5q=	‫8 במרץ 1983	NULL
  NULL	""	GhwTwq6Ynm=	‫29 בדצמבר 2009	NULL
  NULL	""	B6y7dsgaT9=	‫14 ביולי 2021	NULL
  NULL	""	Uh02hnR1sg=	‫5 במאי 1997	NULL

• כל שאר המשתמשים: כל משתמש שלא שייך לאחת מהקבוצות שמופיעות ברשימה מקבל שגיאת דחיית גישה, כי לא הוקצו לו התפקידים Fine-Grained Reader (קריאה עם הרשאות גישה מפורטות) או Masked Reader (קריאה עם הרשאות גישה מוסתרות) של Data Catalog או BigQuery. כדי לשלוח שאילתה לטבלה Accounts, הם צריכים לציין רק עמודות שיש להם גישה אליהן ב-SELECT * EXCEPT (restricted_columns) FROM Accounts, כדי להחריג את העמודות המאובטחות או המוסתרות.

שיקולי עלות

הסתרת נתונים עשויה להשפיע באופן עקיף על מספר הבייטים שעברו עיבוד, ולכן על העלות של השאילתה. אם משתמש שולח שאילתה לעמודה שמוסתרת ממנו באמצעות הכללים Nullify או Default Masking Value, העמודה הזו לא נסרקת בכלל, וכתוצאה מכך מעובדים פחות בייטים.

הגבלות ומגבלות

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

ניהול מדיניות בנושא נתונים

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

תגי מדיניות

• הפרויקט שמכיל את הטקסונומיה של תגי המדיניות צריך להיות שייך לארגון.

• היררכיית תגי מדיניות יכולה לכלול עד חמש רמות, מהצומת הבסיסי ועד לתג המשנה ברמה הנמוכה ביותר, כמו שמוצג בצילום המסך הבא:

  

הגדרת בקרת גישה

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

תצוגות מהותיות ושאילתות חוזרות להסתרת רשומות

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

שאילתות על עמודות עם מיסוך בטבלאות מחולקות למחיצות

אין תמיכה בשאילתות שכוללות מיסוך נתונים בעמודות עם חלוקה למחיצות או עם אשכולות.

ניבים של SQL

אין תמיכה ב-SQL מדור קודם.

תרחישי מיסוך מותאמים אישית

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

• הסתרת נתונים בהתאמה אישית תומכת בכל סוגי הנתונים ב-BigQuery, למעט STRUCT, כי אפשר להחיל הסתרת נתונים רק על שדות עלים מסוג הנתונים STRUCT.
• מחיקה של שגרת מיסוך מותאמת אישית לא מוחקת את כל כללי המדיניות בנושא נתונים שמשתמשים בה. עם זאת, מדיניות הנתונים שמשתמשת בשגרת המיסוך שנמחקה נשארת עם כלל מיסוך ריק. משתמשים עם תפקיד Masked Reader במדיניות אחרת של נתונים עם אותו תג יכולים לראות נתונים מוסווים. אחרים רואים את ההודעה Permission denied. הפניות תלויות לכללי מיסוך ריקים עשויות להימחק על ידי תהליכים אוטומטיים אחרי שבעה ימים.

תאימות לתכונות אחרות של BigQuery

BigQuery API

לא תואם לשיטה tabledata.list. כדי להפעיל את tabledata.list, צריך גישה מלאה לכל העמודות שמוחזרות על ידי השיטה הזו. התפקיד Data Catalog Fine-Grained Reader (קורא פרטני ב-Data Catalog) מעניק גישה מתאימה.

טבלאות BigLake

תואמת. מדיניות אנונימיזציה של נתונים נאכפת בטבלאות BigLake.

Storage Read API ב-BigQuery

תואמת. מדיניות מיסוך הנתונים נאכפת ב-BigQuery Storage Read API.

‫BigQuery BI Engine

תואמת. מדיניות בנושא מיסוך נתונים נאכפת ב-BI Engine. שאילתות שמופעל בהן מיסוך נתונים לא מואצות על ידי BI Engine. השימוש בשאילתות כאלה ב-Looker Studio עלול להאט את הפעולה של דוחות או לוחות בקרה קשורים, ולהגדיל את העלויות.

BigQuery Omni

תואמת. כללי המדיניות למסכות נתונים נאכפים בטבלאות BigQuery Omni.

אוסף כללים (collation)

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

העתקת משימות

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

ייצוא נתונים

תואמת. אם יש לכם את התפקיד BigQuery Masked Reader, הנתונים המיוצאים מוסווים. אם יש לכם את התפקיד Fine-Grained Reader (קורא עם הרשאות גישה מפורטות) ב-Data Catalog, הנתונים המיוצאים לא מוסווים.

אבטחה ברמת השורה

התכונה הזו תואמת רק לשאילתות שכוללות מדיניות גישה לשורות שלא מבוססת על שאילתת משנה. הסתרת נתונים מוחלת בנוסף לאבטחה ברמת השורה. לדוגמה, אם יש מדיניות גישה לשורות שחלה על location = "US" ו-location מוסתר, המשתמשים יכולים לראות שורות שבהן location = "US" אבל שדה המיקום מוסתר בתוצאות.

שאילתות שכוללות מדיניות גישה לשורות של שאילתת משנה דורשות גישת קריאה פרטנית לעמודות שמדיניות הגישה לשורות מפנה אליהן.

חיפוש ב-BigQuery

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

כשמפעילים את הפונקציה SEARCH על עמודות שמוחל עליהן מיסוך נתונים, צריך להשתמש בקריטריוני חיפוש שתואמים לרמת הגישה שלכם. לדוגמה, אם יש לכם גישה ל-Masked Reader עם כלל לאנונימיזציה של נתונים מסוג גיבוב (SHA-256), תשתמשו בערך הגיבוב בסעיף SEARCH, באופן דומה לדוגמה הבאה:

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "sg172y34shw94fujaweu");

אם יש לכם גישת קריאה עם הרשאות גרנולריות, תשתמשו בערך העמודה בפועל בסעיף SEARCH, באופן דומה לדוגמה הבאה:

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "[e-mail]");

החיפוש יהיה פחות שימושי אם יש לכם גישה ל-Masked Reader לעמודה שבה כלל מיסוך הנתונים שבו נעשה שימוש הוא Nullify או Default Masking Value. הסיבה לכך היא שהתוצאות המוסוות שבהן תשתמשו כקריטריוני חיפוש, כמו NULL או "", לא ייחודיות מספיק כדי להיות שימושיות.

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

Snapshots

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

שינוי שם הטבלה

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

מסע בזמן

התכונה הזו תואמת גם לתגי עיצוב של זמן וגם לאפשרות FOR SYSTEM_TIME AS OF בהצהרות SELECT. תגי המדיניות של סכימת מערך הנתונים הנוכחי מוחלים על הנתונים שאוחזרו.

שמירת שאילתות במטמון

תואם באופן חלקי. ב-BigQuery, תוצאות של שאילתות נשמרות במטמון למשך כ-24 שעות, אבל המטמון מתבטל אם מתבצעים שינויים בנתוני הטבלה או בסכימה לפני כן. בנסיבות הבאות, יכול להיות שמשתמש שלא קיבל את התפקיד Data Catalog Fine-Grained Reader בעמודה מסוימת עדיין יוכל לראות את נתוני העמודה כשהוא מריץ שאילתה:

1. למשתמש ניתנה ההרשאה Data Catalog Fine-Grained Reader (קריאה מפורטת של קטלוג הנתונים) בעמודה.
2. המשתמש מריץ שאילתה שכוללת את העמודה המוגבלת והנתונים נשמרים במטמון.
3. תוך 24 שעות משלב 2, למשתמש מוקצה התפקיד 'קורא נתונים מוסווים' ב-BigQuery, וההרשאה שלו לתפקיד 'קורא עם הרשאות גישה מפורטות' ב-Data Catalog מבוטלת.
4. במהלך 24 שעות אחרי שלב 2, המשתמש מריץ את אותה שאילתה, והנתונים שנשמרו במטמון מוחזרים.

שאילתות של טבלאות עם תווים כלליים לחיפוש

לא תואם. צריכה להיות לכם גישה מלאה לכל העמודות שמופיעות בהפניה בכל הטבלאות שתואמות לשאילתת התו הכללי. התפקיד Fine-Grained Reader (קורא פרטני) ב-Data Catalog מעניק גישה מתאימה.

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

• הוראות מפורטות להפעלת מיסוך נתונים