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

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

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

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

יתרונות

אנונימיזציה של נתונים מספקת את היתרונות הבאים:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ארבעת התווים האחרונים. הפונקציה מחזירה את 4 התווים האחרונים של ערך העמודה, ומחליפה את שאר המחרוזת ב-XXXXX. אם הערך בעמודה שווה לאורך של 4 תווים או קצר ממנו, הפונקציה מחזירה את הערך בעמודה אחרי שהיא מופעלת באמצעות פונקציית הגיבוב (hash) 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 משויכות שתי מדיניות נתונים: אחת שבה התפקיד employees (עובדים) מוגדר כחשבון המשתמש, והיא מחילה את כלל אנונימיזציית הנתונים nullify (ביטול), ואחת שבה התפקיד accounting (חשבונאות) מוגדר כחשבון המשתמש, והיא מחילה את כלל אנונימיזציית הנתונים hash (גיבוב) ‏(SHA-256). במקרה הזה, כלל אנונימיזציית הנתונים של הגיבוב (SHA-256) מקבל עדיפות על פני כלל אנונימיזציית הנתונים של ההחלפה בערך null, ולכן כלל הגיבוב (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, שמאפשר להם לקרוא נתונים לא מוסווים, חלק מהמשתמשים יקבלו את שני התפקידים וחלק מהמשתמשים לא יקבלו אף אחד מהם. התפקידים האלה פועלים כך:

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

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

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

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

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

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

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

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

אם משתמש אחר שהוא רק חבר בתפקיד ftes@example.com מריץ שאילתה שכוללת את העמודה עם ההערה, השאילתה מחזירה נתוני עמודה שעברו גיבוב באמצעות אלגוריתם SHA-256, כי למשתמש מוענק תפקיד הקורא עם המסכה ב-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, ויש משתמש שהוא חבר בקבוצה analysts@example.com. כשמשתמש מנסה לגשת לעמוד עם ההערות באמצעות אחת מהתכונות הלא תואמות, הוא מקבל שגיאת דחיית גישה. הסיבה לכך היא שהם מקבלים את תפקיד הקורא המוסווה ב-BigQuery באמצעות תג המדיניות Financial, אבל במקרה הזה הם צריכים לקבל את תפקיד הקורא הפרטני ב-Data Catalog. מכיוון שהשירות כבר קבע תפקיד רלוונטי למשתמש, הוא לא ממשיך לבדוק את ההיררכיה של תגי המדיניות כדי למצוא הרשאות נוספות.

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

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

בדומיין example.com, גישה בסיסית ניתנת דרך הקבוצה data-users@example.com ‎. כל העובדים שצריכים גישה קבועה לנתונים ב-BigQuery הם חברים בקבוצה הזו, שמוקצות לה כל ההרשאות הנדרשות לקריאה מטבלאות, וגם התפקיד BigQuery Masked Reader (קריאה מוסתרת ב-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. התוצאות הבאות מוחזרות:

  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

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

העתקת משימות

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

ייצוא נתונים

תואם. אם יש לכם את התפקיד 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");

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

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

תמונות מצב

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

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

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

מסע בזמן

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

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

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

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

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

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

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

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