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

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

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

יתרונות

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

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

תהליך עבודה של מיסוך נתונים

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

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

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

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

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

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

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

איור 1. רכיבים של מיסוך נתונים.

כדי להגדיר מיסוך נתונים:

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

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

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

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

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

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

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

איור 2. רכיבים של מיסוך נתונים.

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

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

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

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

• שגרת מיסוך מותאמת אישית. הפונקציה מחזירה את הערך של העמודה אחרי החלה של פונקציה להגדרת המשתמש (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

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

  מקורי	בוצעה אנונימיזציה
  abc123@gmail.com	XXXXX@gmail.com
  randomtext	jQHDyQuj7vJcveEe59ygb3Zcvj0B5FJINBzgM6Bypgw=
  test@gmail@gmail.com	Qdje6MO+GLwI0u+KyRyAICDjHbLF1ImxRqaW08tY52k=

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

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

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

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

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

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

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

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

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

• אפשרות הצטרפות: האם אפשר להשתמש בנתונים המוסווים בפעולות SQL JOIN אפשר להשתמש בשיטות מיסוך שמפיקות פלט עקבי עבור קלט נתון (דטרמיניסטיות בהקשר של הצירוף) ושומרות על ייחודיות מספקת.
• חוזק האבטחה: מציין את רמת ההגנה מפני ביטול האנונימיזציה או הנדסה לאחור של הנתונים המקוריים. זו השוואה יחסית.

התנגשויות גיבוב ותקינות של הצטרפות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי לצרף תגי מדיניות לעמודות, נדרשות ההרשאות 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.

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

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

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

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

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

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

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

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

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

יש לכם עמודה בטבלה שמוערת בתג המדיניות Financial, ומשתמש שהוא חבר בקבוצות ftes@example.com ו-analysts@example.com. כשהמשתמש הזה מריץ שאילתה שכוללת את העמודה עם ההערה, הגישה שלו נקבעת לפי ההיררכיה שמוגדרת בטקסונומיה של תגי המדיניות. המשתמש מקבל את התפקיד Data Catalog Fine-Grained Reader (קורא עם הרשאות גישה ברמת הפרטים) דרך תג המדיניות Financial, ולכן השאילתה מחזירה נתונים לא מוסווים בעמודה.

אם משתמש אחר שהוא רק חבר בתפקיד ftes@example.com מריץ שאילתה שכוללת את העמודה עם ההערה, השאילתה מחזירה נתוני עמודה שעברו גיבוב באמצעות אלגוריתם SHA-256, כי למשתמש מוענק תפקיד הקורא המוסווה ב-BigQuery על ידי תג המדיניות Confidential, שהוא תג האב של תג המדיניות Financial.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

העובדים משויכים לקבוצות נוספות שמאפשרות גישה לעמודות מאובטחות או מוסתרות, אם זה נדרש לעבודה שלהם. כל החברים בקבוצות הנוספות האלה הם גם חברים בקבוצה data-users@example.com. באיור 7 אפשר לראות איך הקבוצות האלה משויכות לתפקידים המתאימים:

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

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

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

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

• ‫data-users@example.com: לקבוצה הזו הוענק התפקיד 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

• ‫accounting@example.com: לקבוצה הזו הוקצה התפקיד 'קריאה עם הרשאות גישה מדויקות' ב-Data Catalog בתג המדיניות 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

• ‫sales-exec@example.com: לקבוצה הזו הוקצה התפקיד 'קריאה פרטנית' ב-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

• ‫fin-dev@example.com: לקבוצה הזו הוקצה התפקיד 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 (קריאה עם הרשאות גישה מפורטות) או BigQuery Masked Reader (קריאה עם הסתרת נתונים) ב-Data Catalog. כדי לשלוח שאילתה לטבלה 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, צריך גישה מלאה לכל העמודות שמוחזרות על ידי השיטה הזו. התפקיד Fine-Grained Reader (קורא פרטני) ב-Data Catalog מעניק גישה מתאימה.

טבלאות BigLake

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

Storage Read API ב-BigQuery

תואם. מדיניות אנונימיזציה של נתונים נאכפת ב-BigQuery Storage Read API.

‫BigQuery BI Engine

תואם. מדיניות בנושא מיסוך נתונים נאכפת ב-BI Engine. שאילתות שמופעלת בהן הסתרת נתונים לא מואצות על ידי BI Engine. השימוש בשאילתות כאלה ב-Data 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, "jane.doe@example.com");

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

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

Snapshots

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

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

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

מסע בזמן

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

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

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

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

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

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

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

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