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

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

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

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

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

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

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

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

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

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

4. ניהול הגישה לתגי המדיניות. כדי להגביל את הגישה לכל תג מדיניות, משתמשים במדיניות של ניהול זהויות והרשאות גישה (IAM). המדיניות חלה על כל עמודה ששייכת לתג המדיניות.

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

הערה: בקרת הגישה ברמת העמודה נאכפת בנוסף לרשימות בקרת הגישה (ACL) של מערכי הנתונים. משתמש צריך הרשאה לערכת הנתונים והרשאה לתג המדיניות כדי לגשת לנתונים שמוגנים על ידי בקרת גישה ברמת העמודה.

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

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

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

פרופילים של נתוני עמודות ב-Sensitive Data Protection

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

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

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

1. האחראי על הנתונים יוצר טקסונומיה בשם 'חשיבות עסקית'. הטקסונומיה כוללת את הצמתים, או תגי המדיניות High ו-Medium.

2. האחראי על הנתונים מחליט שמדיניות הגישה לצומת High כוללת גישה לקבוצה בשם high-tier-access.

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

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

5. בדף 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 להגדרת תג מדיניות מופיעים במאמר הגדרת תג מדיניות בעמודה.

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

6. האדמין מבצע שלבים דומים לתג המדיניות 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 בתגי מדיניות.

כדי ליצור ולנהל מדיניות נתונים, צריך את התפקיד 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 במדיניות נתונים.

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

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

תפקיד/מזהה	הרשאות	תיאור
Fine-Grained Reader/datacatalog.categoryFineGrainedReader	datacatalog.categories.fineGrainedGet	ההגדרה חלה ברמת תג המדיניות. התפקיד הזה מעניק גישה לתוכן של עמודות שמוגבלות על ידי תג מדיניות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• משנים את השאילתה כדי להחריג את העמודות שהמשתמש לא יכול לגשת אליהן. לדוגמה, אם למשתמש אין גישה לעמודה ssn, אבל יש לו גישה לשאר העמודות, הוא יכול להריץ את השאילתה הבאה:

  SELECT * EXCEPT (ssn) FROM ...

  בדוגמה שלמעלה, התנאי EXCEPT מחריג את העמודה ssn.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• אם הסכימה בזמן t שונה מהסכימה הנוכחית של העמודות בשאילתה, השאילתה תיכשל.

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

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

תגי מדיניות

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

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

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

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

ארגונים

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

מגבלות

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

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

• תמחור ב-BigQuery
• תמחור של Data Catalog

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

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

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

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

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

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

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

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