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

במסמך הזה מוסברות שיטות מומלצות לשימוש באבטחה ברמת השורה.

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

שיקולים בתכנון מדיניות גישה לשורות

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

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

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

בדיקת חשבונות שירות באמצעות מדיניות גישה ברמת השורה

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

1. יוצרים חשבון שירות.
2. מעדכנים את מדיניות הגישה לשורות כדי להעניק גישה לחשבון השירות. אפשרות אחרת היא להוסיף את חשבון השירות לקבוצת Google שקיבלה גישה באמצעות מדיניות הגישה לשורות.
3. משתמשים בהתחזות לחשבון שירות כדי לוודא שמדיניות הגישה לשורות פועלת כמצופה.

הגבלת הרשאות משתמש כדי לצמצם את הסיכון למתקפות בערוץ צדדי

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

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

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

דוגמאות

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

מומלץ גם שאדמינים יעקבו אחרי יומני הביקורת של Cloud(/bigquery/docs/reference/auditlogs) כדי לזהות פעילות חשודה בטבלאות עם אבטחה ברמת השורה, כמו הוספות, שינויים ומחיקות לא צפויים של מדיניות גישה ברמת השורה.

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

משתמשים עם הרשאות כתיבה לטבלה יכולים להוסיף נתונים לטבלה באמצעות הפקודה bq load או באמצעות BigQuery Storage Write API. כך המשתמש עם הרשאות כתיבה יכול לשנות את תוצאות השאילתה של משתמשים אחרים.

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

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

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

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

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

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

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

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

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

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

דוגמה

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

ניהול התפקיד Filtered Data Viewer באמצעות מדיניות גישה ברמת השורה

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

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

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

ההשפעה של מסננים על עמודות עם חלוקה למחיצות על הביצועים

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

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