שימוש באבטחה ברמת השורה עם תכונות אחרות של BigQuery

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

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

המסנן TRUE

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

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

דוגמאות לפעולות שאינן שאילתות:

TRUE דוגמה למסנן

CREATE ROW ACCESS POLICY all_access ON project.dataset.table1
GRANT TO ("group:all-rows-access@example.com")
FILTER USING (TRUE);

תכונות שפועלות עם המסנן TRUE

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

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

העתקת משימות

כדי להעתיק טבלה עם כללי מדיניות של גישה ברמת השורה, צריך קודם לקבל הרשאת גישה למסנן TRUE בטבלת המקור. כל מדיניות הגישה ברמת השורה בטבלת המקור מועתקת גם לטבלת היעד החדשה. אם מעתיקים טבלת מקור ללא מדיניות גישה ברמת השורה לטבלת יעד שיש בה מדיניות גישה ברמת השורה, מדיניות הגישה ברמת השורה מוסרת מטבלת היעד, אלא אם משתמשים בדגל --append_table או מגדירים את "writeDisposition": "WRITE_APPEND".

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

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

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

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

הרשאה משאב
bigquery.rowAccessPolicies.list טבלת המקור.
bigquery.rowAccessPolicies.getIamPolicy טבלת המקור.
המסנן TRUE טבלת המקור.
bigquery.rowAccessPolicies.create טבלת היעד.
bigquery.rowAccessPolicies.setIamPolicy טבלת היעד.

‫Tabledata.list ב-BigQuery API

כדי להשתמש ב-method‏ tabledata.list ב-BigQuery API בטבלה עם מדיניות גישה ברמת השורה, אתם צריכים הרשאת גישה למסנן TRUE.

DML

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

באופן ספציפי, MERGE statements מתקשרים עם מדיניות גישה ברמת השורה באופן הבא:

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

תמונות מצב של טבלאות

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

טבלה ב-BigQuery עם עמודות JSON

אי אפשר להחיל מדיניות גישה ברמת השורה על עמודות JSON. מידע נוסף על המגבלות של אבטחה ברמת השורה זמין במאמר מגבלות.

גרף הרצה

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

שליפת משרות

אם בטבלה מוגדרת מדיניות גישה ברמת השורה, רק הנתונים שאתם יכולים לראות מיוצאים ל-Cloud Storage כשמריצים משימת חילוץ.

טבלאות מחולקות למחיצות ומקובצות לאשכולות

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

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

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

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

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

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

עדכונים בסטרימינג

כדי לבצע פעולות בטבלה זמנית UPDATE או DELETE באמצעות סימון נתונים שהשתנו (CDC), צריך להיות לכם מסנן גישה TRUE.

מסע בזמן

רק אדמין של טבלה יכול לגשת לנתונים היסטוריים של טבלה שיש לה מדיניות גישה ברמת השורה, או שהייתה לה מדיניות כזו בעבר. משתמשים אחרים מקבלים את השגיאה access denied אם הם משתמשים ב-decorator של מסע בזמן בטבלה שהייתה לה גישה ברמת השורה. מידע נוסף זמין במאמר בנושא גישה ברמת השורה ושימוש בתכונה 'חזרה בזמן'.

תצוגות לוגיות, מהותיות ומורשות

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

תצוגות לוגיות או מהותיות

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

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

ביצועים של תצוגות מהותיות

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

תצוגות מורשות

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

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

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

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