מבוא לאבטחה ברמת השורה ב-BigQuery

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

מהי אבטחה ברמת השורה?

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

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

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

איך פועלת אבטחה ברמת השורה

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

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

כשיוצרים מדיניות גישה ברמת השורה, מציינים את הטבלה לפי שם, ואת המשתמשים או הקבוצות (שנקראים grantee-list) שיכולים לגשת לנתוני שורות מסוימות. המדיניות כוללת גם את הנתונים שרוצים לסנן, שנקראים filter_expression. הפונקציה filter_expression פועלת כמו פסקה WHERE בשאילתה רגילה.

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

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

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

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

סינון נתוני שורות לפי אזור

נניח שהטבלה dataset1.table1 מכילה שורות ששייכות לאזורים שונים (שמסומנים בעמודה region).

כדי ליצור את טבלת הדוגמה ולאכלס אותה, אפשר להשתמש בשאילתה הבאה:

CREATE TABLE IF NOT EXISTS
  dataset1.table1 (partner STRING,
    contact STRING,
    country STRING,
    region STRING);
INSERT INTO
  dataset1.table1 (partner,
    contact,
    country,
    region)
VALUES
  ('Example Customers Corp', 'alice@examplecustomers.com', 'Japan', 'APAC'),
  ('Example Enterprise Group', 'bob@exampleenterprisegroup.com', 'Singapore', 'APAC'),
  ('Example HighTouch Co.', 'carrie@examplehightouch.com', 'USA', 'US'),
  ('Example Buyers Inc.', 'david@examplebuyersinc.com', 'USA', 'US');

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

CREATE ROW ACCESS POLICY
  apac_filter
ON
  dataset1.table1 GRANT TO ("group:sales-apac@example.com")
FILTER USING
  (region="APAC" );

התוצאה היא שמשתמשים בקבוצה sales-apac@example.com יכולים לראות רק שורות שבהן הערך של region הוא APAC.

ההצהרה הבאה מיישמת מדיניות שמגבילה את האפשרות של אנשים פרטיים וקבוצות לראות רק שותפים מאזור ארה"ב:

CREATE ROW ACCESS POLICY
  us_filter
ON
  dataset1.table1 GRANT TO ("group:sales-us@example.com",
"user:jon@example.com")
FILTER USING
  (region="US");

התוצאה היא שמשתמשים בקבוצה sales-us@example.com והמשתמש jon@example.com יכולים לראות רק שורות שבהן הערך של region הוא US.

משתמשים שלא שייכים לקבוצות APAC או US לא רואים שורות.

סינון נתוני שורות על סמך מידע אישי רגיש

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

כדי ליצור את טבלת הדוגמה ולאכלס אותה, אפשר להשתמש בשאילתה הבאה:

CREATE OR REPLACE TABLE
  dataset1.table1 (name STRING,
    department STRING,
    salary INT64,
    email STRING);
INSERT INTO
  dataset1.table1 ( name,
    department,
    salary,
    email)
VALUES
  ('Jim D', 'HR', 100000, 'jim@example.com'),
  ('Anna K', 'Finance', 100000, 'anna@example.com'),
  ('Bruce L', 'Engineering', 100000, 'bruce@example.com'),
  ('Carrie F', 'Business', 100000, 'carrie@example.com');

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

CREATE ROW ACCESS POLICY
  salary_personal
ON
  dataset1.table1 GRANT TO ("domain:example.com")
  FILTER USING
  (Email=SESSION_USER());

התמונה הבאה מראה איך מדיניות הגישה לשורות מגבילה את הטבלה שמכילה מידע על משכורות. בדוגמה הזו, שם המשתמש הוא יואב וכתובת האימייל שלו היא jim@example.com.

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

סינון נתוני שורות על סמך טבלת מיפוי

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

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

מתי כדאי להשתמש באבטחה ברמת השורה לעומת שיטות אחרות

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

השוואה עם תצוגות מורשות: נקודות חולשה

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

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

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

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

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

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

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

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

מחיקה מרומזת של מדיניות גישה ברמת השורה

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

העיקרון הכללי למחיקה אוטומטית של מדיניות גישה לשורות הוא:

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

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

• החלפת טבלה: כשמחליפים טבלה באמצעות הצהרת DDL‏ CREATE OR REPLACE TABLE, כל כללי מדיניות הגישה הקיימים בשורות בטבלה המקורית נמחקים. זה קורה גם אם שאילתת ההחלפה מבוססת על הנתונים של הטבלה המקורית.

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

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

• פעולות של העתקת טבלה: כשמעתיקים טבלה ללא מדיניות גישה לשורות לטבלת יעד שיש לה מדיניות גישה לשורות, המדיניות בטבלת היעד מוסרת, אלא אם משתמשים בדגל --append_table או ב-"writeDisposition": "WRITE_APPEND". מידע נוסף על עבודות להעתקת טבלאות זמין במאמר שימוש באבטחה ברמת השורה עם תכונות אחרות של BigQuery.

שימוש בפקודת DML‏ TRUNCATE TABLE, שמסירה את כל השורות מטבלה תוך שמירה על הסכימה שלה, לא מסיר את מדיניות הגישה לשורות.

מכסות

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

תמחור

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

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

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

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

מידע נוסף על התמחור של שאילתות ב-BigQuery זמין במאמר תמחור ב-BigQuery.

מגבלות

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

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

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

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

• יכול להיות שתחוו ירידה קלה בביצועים כשאתם שולחים שאילתות לטבלאות עם אבטחה ברמת השורה.

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

מגבלות אחרות

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

• מדיניות גישה ברמת השורה לא תואמת ל-SQL מדור קודם. שאילתות של טבלאות עם מדיניות גישה ברמת השורה חייבות להשתמש ב-GoogleSQL. שאילתות SQL מדור קודם נדחות עם שגיאה.

• אי אפשר להחיל מדיניות של גישה ברמת השורה על עמודות JSON.

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

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

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

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

  • מדיניות גישה לשורות שמשלבת שאילתות משנה לא תואמת ל-BigQuery Storage Read API. ‫BigQuery Storage Read API תומך רק בפרדיקטים פשוטים של מסננים.

• פעולות שאינן שאילתות, כולל משימות של חשבון שירות, שדורשות גישה מלאה לנתוני הטבלה, יכולות להשתמש באבטחה ברמת השורה עם המסנן TRUE. לדוגמה: העתקת טבלאות, תהליכי עבודה של Managed Service for Apache Spark ועוד. מידע נוסף מופיע במאמר בנושא שימוש באבטחה ברמת השורה.

• אפשר ליצור, להחליף או למחוק מדיניות גישה ברמת השורה באמצעות הצהרות DDL או ממשקי API של מדיניות גישה ברמת השורה. אפשר גם לבצע את כל הפעולות שזמינות בממשקי ה-API של מדיניות הגישה לשורות באמצעות כלי שורת הפקודה של BigQuery‏ (bq). אפשר לראות את רשימת מדיניות הגישה ברמת השורה במסוףCloud de Confiance .

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

• דגימת טבלה לא תואמת לאבטחה ברמת השורה.

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

• INשאילתות משנה ברמה העליונה שבהן הסוג של search_value הוא FLOAT, ‏ STRUCT, ‏ ARRAY, ‏ JSON או GEOGRAPHY לא זמינות במדיניות גישה ברמת השורה.

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

• מדיניות גישה ברמת השורה בשאילתות משנה תומכת רק בטבלאות BigQuery, בטבלאות חיצוניות של BigLake ובטבלאות מנוהלות של BigLake.

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

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

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

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

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

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

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

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

• מידע על ניהול אבטחה ברמת השורה זמין במאמר שימוש באבטחה ברמת השורה.

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

• מידע על שיטות מומלצות לאבטחה ברמת השורה זמין במאמר שיטות מומלצות לאבטחה ברמת השורה ב-BigQuery.