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

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

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

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

יתרונות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

באיור 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. לדוגמה:

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

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

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

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

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

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

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

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

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

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

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

התנגשויות בגיבוב (hash) ותקינות הצירוף

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי לצרף תגי מדיניות לעמודות, אתם צריכים את ההרשאות datacatalog.taxonomies.get ו-bigquery.tables.setCategory. ההרשאה datacatalog.taxonomies.get כלולה בתפקידים "אדמין של תגי מדיניות ב-Data Catalog" ו"צפייה בתגי מדיניות ב-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" באמצעות תג המדיניות Financial, השאילתה מחזירה נתוני עמודות ללא הסתרה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  ת"ז	עדיפות	ערך חיי המשתמש	תאריך היצירה	אימייל
  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. התוצאות הבאות מוחזרות:

  ת"ז	עדיפות	ערך חיי המשתמש	תאריך היצירה	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. מתקבלות התוצאות הבאות:

  ת"ז	עדיפות	ערך חיי המשתמש	תאריך היצירה	אימייל
  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. מתקבלות התוצאות הבאות:

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

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

שיקולי עלות

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

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

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

ניהול מדיניות הנתונים

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

תגי מדיניות

• הפרויקט שמכיל את הטקסונומיה של תגי המדיניות חייב להיות שייך לארגון.
• הטקסונומיות של תגי המדיניות מוגדרות ברמת הארגון. אם מעבירים פרויקט לארגון אחר, הפרויקט מאבד את הגישה לטקסונומיה המקורית של Data Catalog. יכול להיות שתגי מדיניות לא עדכניים עדיין יופיעו בעמודות של הטבלה בכלי לעריכת הסכימה, אבל הם יוסרו מממשק המשתמש של תגי המדיניות במסוף Google Cloud , ואי אפשר יהיה להחיל אותם על טבלאות חדשות. אם אתם מעבירים פרויקט לארגון חדש, אתם צריכים:
  • יוצרים מחדש באופן ידני את הטקסונומיות של תגי המדיניות, את תגי המדיניות ואת מדיניות הנתונים המשויכת בפרויקט בארגון היעד.
  • מקצים באופן מפורש את התפקידים BigQuery Admin‏ (roles/bigquery.admin) ו-Data Catalog Admin‏ (roles/datacatalog.admin או roles/datacatalog.categoryAdmin) ברמת התיקייה בארגון היעד.
  • מעדכנים את העמודות בטבלה בפרויקט שהועבר כדי להפנות לתגי המדיניות החדשים שנוצרו בארגון היעד.

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

  

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

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

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

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

הרצת שאילתות על עמודות מוסתרות בטבלאות מחולקות למחיצות

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

ניבים של SQL

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

שגרות מיסוך בהתאמה אישית

שגרות הסתרה בהתאמה אישית כפופות למגבלות הבאות:

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

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

BigQuery API

לא תואם לשיטה tabledata.list. כדי להפעיל את tabledata.list, אתם צריכים גישה מלאה לכל העמודות שמוחזרות על ידי השיטה הזו. התפקיד "קריאה פרטנית ב-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 על עמודות מאוחדות, אבל ההסתרה מתבצעת לפני האיחוד. סדר הפעולות הזה יכול להוביל לתוצאות לא צפויות, כי יכול להיות שההשוואה לא תשפיע על הערכים המוסתרים כמו שצריך (לדוגמה, יכול להיות שהתאמה לא תלוית-רישיות לא תפעל אחרי ההסתרה). אפשר להשתמש בפתרונות עקיפים, כמו שימוש בשגרות מותאמות אישית של הסתרת נתונים שמנרמלות את הנתונים לפני שמחילים את פונקציית ההסתרה.

העתקת משימות

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

ייצוא נתונים

תואמת. אם יש לכם את התפקיד "קריאה של נתונים מוסתרים ב-BigQuery", הנתונים המיוצאים מוסתרים. אם יש לכם את התפקיד "קורא ברמת פירוט גבוהה" ב-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 או "", לא מספיק ייחודיות כדי להיות שימושיות.

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

תמונות מצב

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

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

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

מסע בזמן

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

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

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

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

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

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

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

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