שיטות מומלצות לאבטחה ברמת השורה ב-BigQuery
במסמך הזה מוסברות שיטות מומלצות לשימוש באבטחה ברמת השורה.
לפני שקוראים את המאמר הזה, מומלץ לקרוא את המאמרים מבוא לאבטחה ברמת השורה ב-BigQuery ועבודה עם אבטחה ברמת השורה כדי להכיר את הנושא.
הגבלת הרשאות משתמשים כדי לצמצם את הסיכון למתקפות בערוץ צדדי
מתקפה בערוץ צדדי היא מתקפת אבטחה שמבוססת על מידע שמתקבל מהמערכת עצמה. אם לתוקף יש הרשאות רחבות יותר מהנדרש, הוא יכול לבצע התקפות בערוץ צדדי וללמוד מידע אישי רגיש על ידי צפייה או חיפוש בחיוב, ברישום ביומן או בהודעות מערכת.
כדי לצמצם את הסיכויים לניצול חולשות כאלה, BigQuery מסתיר נתונים סטטיסטיים רגישים בכל השאילתות שמופעלות על טבלאות עם אבטחה ברמת השורה. הנתונים הסטטיסטיים הרגישים האלה כוללים את מספר הבייטים והמחיצות שעברו עיבוד, את מספר הבייטים שחויבו ואת השלבים בתוכנית השאילתה.
מומלץ שאדמינים יימנעו מהענקת ההרשאות הבאות למשתמשים שצריכים לראות רק נתונים מסוננים, כדי למנוע גישה לנתונים רגישים.
| הרשאות | מידע אישי רגיש |
|---|---|
| בעלי הפרויקט | בעלי פרויקטים יכולים לראות את הנתונים שקשורים לבייטים שעברו עיבוד רק ביומני הביקורת. אי אפשר לראות את מטא-נתוני החיוב מפרטי המשרה. אין הרשאה או תפקיד ספציפיים שאפשר להעניק כדי לתת גישת צפייה למטא-נתונים של החיוב. |
| תפקידים של עריכה, בעלות או צפייה בנתונים ב-BigQuery | הצגת הודעות שגיאה בשאילתות. |
| הרשאות צפייה בחיוב ב-Cloud | הצגת החיוב ב-BigQuery. |
דוגמאות
- באמצעות תצפית חוזרת על משך השאילתה כשמריצים שאילתות על טבלאות עם מדיניות גישה ברמת השורה, משתמש יכול להסיק את הערכים של שורות שאחרת עשויות להיות מוגנות על ידי מדיניות גישה ברמת השורה. סוג כזה של מתקפה דורש ניסיונות חוזרים רבים על פני טווח של ערכי מפתח בעמודות של חלוקה למחיצות או של אשכולות. למרות שיש רעשי רקע מובנים כשצופים במשך הזמן של שאילתה או מודדים אותו, אם התוקף ינסה שוב ושוב הוא יוכל לקבל הערכה מהימנה. אם רמת ההגנה הזו חשובה לכם, מומלץ להשתמש בטבלאות נפרדות כדי לבודד שורות עם דרישות שונות של בקרת גישה.
- תוקף יכול לחפש את הבייטים שעובדו על ידי שאילתה באמצעות מעקב אחרי השגיאות שמתרחשות כשחורגים מהמגבלות של עבודת השאילתה (למשל, מספר הבייטים המקסימלי לחיוב או אמצעי בקרה מותאמים אישית על העלויות). עם זאת, כדי לבצע את המתקפה הזו נדרש נפח גבוה של שאילתות.
- באמצעות שאילתות חוזרות והתבוננות בסכום החיוב ב-BigQuery בחיוב ב-Cloud, משתמש יכול להסיק את הערכים של שורות שאחרת עשויות להיות מוגנות על ידי מדיניות גישה ברמת השורה. סוג כזה של מתקפה דורש ניסיונות חוזרים רבים על טווח של ערכי מפתח בעמודות של חלוקה למחיצות או של אשכולות. אם רמת ההגנה הזו חשובה לכם, מומלץ להגביל את הגישה לנתוני החיוב בשאילתות.
מומלץ גם לאדמינים לעקוב אחרי Cloud Audit Logs(/bigquery/docs/reference/auditlogs) כדי לזהות פעילות חשודה בטבלאות עם אבטחה ברמת השורה, כמו הוספות, שינויים ומחיקות לא צפויים של מדיניות גישה ברמת השורה.
הגבלת הרשאות משתמשים כדי למנוע שינוי נתונים
משתמשים עם הרשאות כתיבה לטבלה יכולים להוסיף נתונים לטבלה באמצעות הפקודה bq load או באמצעות BigQuery Storage Write API. כך משתמשים עם הרשאות כתיבה יכולים לשנות את תוצאות השאילתה של משתמשים אחרים.
מומלץ שאדמינים ייצרו קבוצות נפרדות ב-Google לגישת כתיבה לטבלה ולמדיניות גישה ברמת השורה. משתמשים שצריכים לראות רק תוצאות של טבלה מסוננת לא צריכים לקבל הרשאת כתיבה בטבלה המסוננת.
איך להימנע מגישה לא מכוונת כשיוצרים מחדש מדיניות גישה ברמת השורה
כשמוסיפים מדיניות גישה לשורות בטבלה בפעם הראשונה, מתחילים מיד לסנן את הנתונים בתוצאות השאילתה. כשמסירים את מדיניות הגישה האחרונה ברמת השורה בטבלה, גם אם אתם מתכוונים רק ליצור מחדש את מדיניות הגישה ברמת השורה, יכול להיות שתעניקו בטעות גישה לא מסוננת לקהל רחב יותר ממה שהתכוונתם.
מומלץ שאדמינים יקפידו במיוחד על ההנחיות הבאות כשהם יוצרים מחדש מדיניות אחרונה של גישה ברמת השורה בטבלה:
- קודם צריך להסיר את כל הגישה לטבלה באמצעות אמצעי הבקרה לגישה לטבלה.
- מסירים את כל מדיניות הגישה ברמת השורה.
- יוצרים מחדש את מדיניות הגישה ברמת השורה.
- מפעילים מחדש את הגישה לטבלה.
לחלופין, אפשר קודם ליצור מדיניות חדשה של גישה ברמת השורה בטבלה, ואז למחוק את המדיניות הקודמת של גישה ברמת השורה שכבר לא נחוצה.
אפשר להשתמש באבטחה ברמת השורה רק בתוך ארגונים, ולא בין ארגונים
כדי למנוע דליפת נתונים באמצעות מתקפות בערוץ צדדי, וכדי לשמור על שליטה טובה יותר בגישה למידע אישי רגיש, לא מומלץ להשתמש בתכונת האבטחה ברמת השורה בארגונים.
למדיניות גישה ברמת השורה של שאילתות משנה, יוצרים טבלאות ומחפשים אותן בארגונים או בפרויקטים. כך האבטחה משתפרת והגדרת ACL הופכת לפשוטה יותר, כי למקבלים צריכה להיות ההרשאה bigquery.tables.getData בטבלאות היעד וההפניה במדיניות, וגם הרשאות רלוונטיות של אבטחה ברמת העמודה.
מומלץ להשתמש בתכונת האבטחה ברמת השורה רק למגבלות אבטחה בתוך הארגון (למשל, לשיתוף נתונים בתוך ארגון, חברה או עסק), ולא לאבטחה בין ארגונים או לאבטחה ציבורית.
דוגמה
מחוץ לארגון, יש לכם פחות שליטה על מי שיש לו גישה לנתונים. בארגון שלכם, אתם יכולים לקבוע למי תהיה גישה לפרטי החיוב של שאילתות שמופעלות על טבלאות עם מדיניות גישה ברמת השורה. פרטי החיוב הם וקטור להתקפות ערוץ צדדי.
ניהול התפקיד Filtered Data Viewer באמצעות מדיניות גישה ברמת השורה
כשיוצרים מדיניות גישה ברמת השורה, חשבונות המשתמשים במדיניות מקבלים אוטומטית את התפקיד bigquery.filteredDataViewer. אפשר להוסיף או להסיר חשבונות משתמש ממדיניות הגישה באמצעות הצהרת DDL בלבד.
אסור להעניק את התפקיד bigquery.filteredDataViewer באמצעות IAM למשאב ברמה גבוהה יותר, כמו טבלה, מערך נתונים או פרויקט. הענקת התפקיד בדרך הזו מאפשרת למשתמשים לצפות בשורות שמוגדרות על ידי כל מדיניות הגישה ברמת השורה במסגרת ההיקף הזה, ללא קשר להגבלות המיועדות. יכול להיות שאיחוד המסננים של מדיניות הגישה ברמת השורה לא יכלול את כל הטבלה, אבל השיטה הזו יוצרת סיכון אבטחה משמעותי ומבטלת את המטרה של אבטחה ברמת השורה.
מומלץ לנהל את התפקיד bigquery.filteredDataViewer באופן בלעדי באמצעות מדיניות גישה ברמת השורה. השיטה הזו מבטיחה שהתפקיד bigquery.filteredDataViewer יינתן לחשבונות הראשיים באופן מרומז ונכון, בהתאם לתנאי המסנן שהוגדרו לכל מדיניות.
השפעת הסינון על ביצועים בעמודות עם חלוקה למחיצות
מסננים של מדיניות גישה ברמת השורה לא משתתפים בגיזום של שאילתות בטבלאות עם חלוקה למחיצות ובטבלאות מקובצות.
אם מדיניות הגישה ברמת השורה מציינת עמודה עם חלוקה למחיצות, השאילתה לא מקבלת את היתרונות של ביצועים משופרים כתוצאה מגיזום השאילתה.