מבוא לאבטחה ברמת השורה ב-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');

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

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.

התנהגות של אבטחה ברמת השורה באזור 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 וכתובת האימייל שלו היא jim@example.com.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • פעולות שמשתמשות ב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.

מגבלות אחרות

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

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

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

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

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

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

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

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

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

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

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

  • תוצאות המדיניות של שאילתות משנה ברמה העליונה מוגבלות ל-100MB. המגבלה הזו חלה על כל מדיניות גישה ברמת השורה.

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

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

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

  • אסור להשתמש בהצהרות renaming ו-dropping שמשנות את סכימת הטבלה ועלולות להשפיע על כללי מדיניות הגישה לשורות.

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

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

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

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

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

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

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