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

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

כדי לראות את העמודות שמכילות את TYPE_SSN, צריך להיות בgroup:high-access.

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

תהליך העבודה של בקרת גישה ברמת העמודה

תהליך עבודה

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

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

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

זיהוי הפריטים שצריך לתייג

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

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

תרחיש שימוש לדוגמה

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

תגי מדיניות

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

האחראי על ניהול הנתונים יוצר טקסונומיה בשם 'חשיבות עסקית'. הטקסונומיה כוללת את הצמתים, או תגי המדיניות High ו-Medium.
האחראי על הנתונים מחליט שמדיניות הגישה לצומת High כוללת גישה לקבוצה בשם high-tier-access.
האחראי על הנתונים יוצר עוד רמות של צמתים בטקסונומיה, מתחת לגבוה ולבינוני. הצומת ברמה הנמוכה ביותר הוא צומת עלה, כמו צומת העלה employee_ssn. האחראי על הנתונים יכול ליצור או לא ליצור מדיניות גישה שונה לצומת העלה employee_ssn.
האחראי על הנתונים מקצה תג מדיניות לעמודות ספציפיות בטבלה. בדוגמה הזו, האחראי על הנתונים מקצה את מדיניות הגישה High לעמודה employee_ssn בטבלה.
בדף Current schema במסוף, מנהל הנתונים יכול לראות את תג המדיניות שחל על עמודה מסוימת. בדוגמה הזו, העמודה employee_ssn נמצאת תחת תג המדיניות High, ולכן כשמציגים את הסכימה של employee_ssn, במסוף מוצגים שם הטקסונומיה ותג המדיניות בשדה Policy tags: Business criticality:High.

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

אפשרות אחרת היא להגדיר את תג המדיניות באמצעות הפקודה bq update. השדה names של policyTags כולל את המזהה של תג המדיניות High (גבוה), projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id:
```
[
 ...
 {
   "name": "ssn",
   "type": "STRING",
   "mode": "REQUIRED",
   "policyTags": {
     "names": ["projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id"]
   }
 },
 ...
]
```
פרטים על שימוש בפקודה bq update להגדרת תג מדיניות מופיעים במאמר הגדרת תג מדיניות בעמודה.

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

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

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

תפקידים שמשמשים לבקרת גישה ברמת העמודה

התפקידים הבאים משמשים לבקרת גישה ברמת העמודה ב-BigQuery.

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

תפקיד/מזהה הרשאות תיאור

תפקיד/מזהה	הרשאות	תיאור
אדמין של תגי מדיניות ב-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 בתגי מדיניות.

אדמין של תגי מדיניות ב-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 Data Policy Admin (אדמין של מדיניות נתונים ב-BigQuery), את התפקיד BigQuery Admin (אדמין של BigQuery) או את התפקיד BigQuery Data Owner (הבעלים של נתוני BigQuery). כשמשתמשים במסוףGoogle Cloud כדי לאכוף בטקסונומיה בקרת גישה, השירות יוצר בשבילכם מדיניות נתונים באופן שקוף.

תפקיד/מזהה הרשאות תיאור

תפקיד/מזהה	הרשאות	תיאור
אדמין של מדיניות נתונים ב-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 במדיניות בנושא נתונים.

אדמין של מדיניות נתונים ב-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.categoryFineGrainedReader`	`datacatalog.categories.fineGrainedGet`	ההגדרה חלה ברמת תג המדיניות. התפקיד הזה מעניק גישה לתוכן של עמודות שמוגבלות על ידי תג מדיניות.

הרשאת קריאה פרטנית/datacatalog.categoryFineGrainedReader

datacatalog.categories.fineGrainedGet

ההגדרה חלה ברמת תג המדיניות.

התפקיד הזה מעניק גישה לתוכן של עמודות שמוגבלות על ידי תג מדיניות.

למידע נוסף על התפקידים ב-Data Catalog, אפשר לעיין במאמר ניהול זהויות והרשאות גישה (IAM) ב-Data Catalog. מידע נוסף על תפקידים ב-BigQuery זמין במאמר בקרת גישה באמצעות IAM.

ההשפעה של פעולות כתיבה

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

ההגדרה הזו חלה על:

טבלאות, כולל טבלאות עם תווים כלליים לחיפוש
תצוגות
העתקת טבלאות

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

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

אם משתמש מריץ INSERT SELECT statement, הוא צריך לקבל את תפקיד הקורא עם ההרשאות המפורטות בטבלה שנשלחה אליה שאילתה.

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

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

מידע נוסף על ההשפעה על פעולות כתיבה עם בקרת גישה ברמת העמודה

שאילתות על טבלאות

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

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

משנים את השאילתה כדי להחריג את העמודות שהמשתמש לא יכול לגשת אליהן. לדוגמה, אם למשתמש אין גישה לעמודה ssn, אבל יש לו גישה לשאר העמודות, הוא יכול להריץ את השאילתה הבאה:
```
SELECT * EXCEPT (ssn) FROM ...
```
בדוגמה שלמעלה, התנאי EXCEPT מחריג את העמודה ssn.
צריך לבקש מאדמין של Data Catalog להוסיף את המשתמש כקורא עם הרשאות גישה ברמת גרנולריות גבוהה (fine-grained) לנתונים בסיווג הרלוונטי. בהודעת השגיאה מופיע השם המלא של תג המדיניות שהמשתמש צריך לקבל גישה אליו.

תצוגות של שאילתות

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

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

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

מידע נוסף מופיע במאמרים בנושא תצוגות מורשות ומערכי נתונים מורשים.

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

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

אם התצוגה היא תצוגה מורשית:

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

בתרשים הבא מוצג תהליך הערכת הגישה לתצוגה.

גישה לתצוגות

ההשפעה של מסע בזמן ותצוגות חומריות עם max_staleness

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

ב-SQL מדור קודם, מריצים שאילתות על נתונים היסטוריים באמצעות קישוטי זמן בשם הטבלה. ב-GoogleSQL, כדי להריץ שאילתות על נתונים היסטוריים, משתמשים בסעיף FOR SYSTEM_TIME AS OF בטבלה.

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

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

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

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

תגי מדיניות

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

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

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

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

ארגונים

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

מגבלות

יכול להיות שהתכונה הזו לא תהיה זמינה כשמשתמשים בהזמנות שנוצרו במהדורות מסוימות של BigQuery. מידע נוסף על התכונות שמופעלות בכל מהדורה זמין במאמר מבוא למהדורות BigQuery.
ב-BigQuery אפשר להגדיר בקרת גישה ברמת העמודה רק עבור טבלאות BigLake, טבלאות BigQuery וטבלאות BigQuery Omni.
אם אתם מחליפים את התוכן של טבלת יעד, כל תגי המדיניות הקיימים מוסרים מהטבלה, אלא אם אתם משתמשים בדגל --destination_schema כדי לציין סכימה עם תגי מדיניות. בדוגמה הבאה אפשר לראות איך משתמשים ב---destination_schema.
```
bq query --destination_table mydataset.mytable2 \
  --use_legacy_sql=false --destination_schema=schema.json \
  'SELECT * FROM mydataset.mytable1'
```
שינויים בסכימה מתרחשים בפעולה נפרדת מהרצת השאילתה. אם כותבים תוצאות של שאילתה לטבלה באמצעות ציון הדגל --destination_table, והשאילתה מעלה חריג, יכול להיות ששינויים בסכימה יידלגו. אם זה קורה, צריך לבדוק את הסכימה של טבלת היעד ולעדכן אותה באופן ידני אם צריך.
לכל עמודה אפשר להוסיף רק תג מדיניות אחד.
בטבלה יכולים להיות לכל היותר 1,000 תגי מדיניות ייחודיים.
אי אפשר להשתמש ב-SQL מדור קודם אם הפעלתם בקרת גישה ברמת העמודה. אם יש תגי מדיניות בטבלאות היעד, כל שאילתות SQL מדור קודם נדחות.
היררכיית תגי מדיניות יכולה לכלול עד חמש רמות, מהצומת הבסיסי ועד לתג המשנה ברמה הנמוכה ביותר, כמו שמוצג בצילום המסך הבא:
שמות הטקסונומיה חייבים להיות ייחודיים בין כל הפרויקטים בארגון.
אי אפשר להעתיק טבלה בין אזורים אם הפעלתם בטבלה בקרת גישה ברמת העמודה או ברמת השורה. כל העותקים של טבלאות באזורים שונים נדחים אם יש תגי מדיניות בטבלאות המקור.

תמחור

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

רישום ביומן ביקורת

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

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

מידע נוסף על רישום ביומן ב-BigQuery זמין במאמר מבוא לניטור ב-BigQuery.

מידע נוסף על רישום ביומנים של Google Cloudזמין במאמר בנושא Cloud Logging.

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

לפרטים על שימוש בבקרת גישה ברמת העמודה, אפשר לעיין במאמר הגבלת הגישה באמצעות בקרת גישה ברמת העמודה.
מידע על שיטות מומלצות לשימוש בתגי מדיניות זמין במאמר BigQuery best practices: Using policy tags.