דוח מודל איומים של BigQuery

תאריך העדכון האחרון: 16 באפריל 2026

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

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

האיומים הבאים זוהו בשירות הזה:

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

פרטי האיום

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

השמדת נתונים באמצעות שינוי סכימה

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

קטגוריית STRIDE	שיבוש
טקטיקה של MITRE ATT&CK	השפעה
Manifestations	עדכון זדוני של סכימה: ישות מורשית עם ההרשאה bigquery.tables.update יכולה לקרוא לשיטת tables.patch API בטבלה ב-BigQuery כדי לשנות את הסכימה שלה. שינוי סוגי הנתונים בעמודות עלול לגרום לנתונים להיות פגומים או לאובדן מידע. יכול להיות ששאילתות מאפליקציות לקוח או מכלי בינה עסקית לא יפעלו, וכתוצאה מכך יאבד האמון בדוחות שנוצרים בהמשך.
אמצעי צמצום סיכונים	הגבילו מאוד את ההרשאה bigquery.tables.update, שהיא חלק מתפקידים כמו roles/bigquery.dataOwner. צריך להעניק את ההרשאה הזו רק למספר קטן של אדמינים או לחשבונות שירות אוטומטיים של CI/CD שאחראים על העברות מנוהלות של סכימות. כדי לשחזר שינויים לא מכוונים או זדוניים בסכימה, אפשר להפעיל גיבויים של טבלאות ב-BigQuery או להשתמש בתמונות מצב של טבלאות. עוקבים אחרי קריאות ל-API של tables.patch ביומני הביקורת של Cloud ומקבלים התראה על שינויים שבוצעו מחוץ לחלון זמן מתוכנן לתחזוקה.

הסלמת הרשאות באמצעות שינוי של מדיניות הרשאה ב-IAM

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

קטגוריית STRIDE	העלאת רמת ההרשאה
טקטיקה של MITRE ATT&CK	הסלמת הרשאות
Manifestations	שינוי מדיניות של מערך נתונים: גורם ראשי עם ההרשאה bigquery.datasets.update יכול לקרוא לשיטת ה-API‏ datasets.patch במערך נתונים ב-BigQuery כדי להוסיף את הזהות שלו לתפקיד בעלים, וכך לקבל שליטה מלאה על כל המשאבים במערך הנתונים הזה. התחזות לחשבון שירות: זהות עם ההרשאה iam.serviceAccounts.actAs בחשבון שירות יכולה לצרף את חשבון השירות למשאבים אחרים, כמו מכונה של Compute Engine, כדי להריץ קוד עם הזהות של חשבון השירות המצורף. לחלופין, חשבון משתמש עם ההרשאה iam.serviceAccounts.getAccessToken יכול ליצור אסימוני גישה לחשבון השירות הזה. אם לחשבון השירות של היעד יש הרשאות מורחבות במשאבי BigQuery, התוקף יורש למעשה את ההרשאות האלה.
אמצעי צמצום סיכונים	הגבילו באופן משמעותי את ההרשאות שמאפשרות שינוי של מדיניות ההרשאות ב-IAM (לדוגמה, bigquery.datasets.update, שהיא חלק מתפקידים כמו roles/bigquery.dataOwner). הקצו את התפקידים האלה רק למספר מינימלי של אדמינים מהימנים. באופן דומה, כדאי לשלוט באופן הדוק בתפקידי ה-IAM עם הרשאה לפעול כחשבונות שירות או להתחזות להם, ולהגביל את התפקידים האלה לחשבונות ראשיים ספציפיים שזקוקים להם. כדי לזהות שינויים לא מורשים במדיניות, כדאי לעקוב אחרי קריאות ל-API של SetIamPolicy ושל datasets.patch ביומני הביקורת של Cloud.

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

תוקף עם הרשאות מוגבלות ב-BigQuery יוצר משימה או שאילתה שמפעילות שירות במורד הזרם (לדוגמה, Cloud Function, משימת Dataflow או Cloud Composer DAG), שפועל עם הרשאות גבוהות יותר. השירות במורד הזרם, שחושב שהוא מבצע פעולה לגיטימית בשם BigQuery, מרומה לבצע פעולה במשאב אחר או עם נתונים אחרים מאלה שהוגדרו על ידי מתכנני המערכת.

קטגוריית STRIDE	העלאת רמת ההרשאה
טקטיקה של MITRE ATT&CK	הסלמת הרשאות
Manifestations	הפעלה של פונקציה זדונית: שינוי ב-BigQuery מפעיל פונקציית Cloud עם הרשאות רחבות, והתוקף מבצע מניפולציה בנתוני BigQuery כדי לשלוט בפעולות של הפונקציה. ניצול צינורות Dataflow: תוצאה של שאילתת BigQuery משמשת כקלט למשימת Dataflow, והתוקף כותב את תוצאות השאילתה כדי לגרום למשימת Dataflow להטמיע נתונים מורעלים.
אמצעי צמצום סיכונים	החלת העיקרון של הרשאות מינימליות על חשבונות שירות שמשמשים שירותים במורד הזרם שמופעלים על ידי BigQuery. מוודאים שהשירותים האלה מאמתים ומסירים כל קלט או פרמטר שמתקבלים ממשימות BigQuery. שימוש ב-VPC Service Controls כדי להגביל את נתיבי הרשת ואת האינטראקציות בין השירותים. מומלץ לתכנן שירותים במורד הזרם כך שלא יסתמכו באופן מובנה על קלט מ-BigQuery בלי אימות.

זליגת נתונים באמצעות יציאה בלתי מוגבלת מהרשת

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

קטגוריית STRIDE	גילוי נאות
טקטיקה של MITRE ATT&CK	זליגת נתונים
Manifestations	גישה ל-API מרשתות לא מהימנות: תוקף משתמש בהרשאות גישה שנפרצו כדי להתחבר ל-BigQuery API הציבורי או ל-BigQuery Storage Read API ממחשב חיצוני, ועוקף את אמצעי הבקרה ברשת שהוגדרו למארחים מקומיים או למכשירי משתמשים. ייצוא לשירות חיצוני של Google Cloud: חשבון שירות שנפרץ עם הרשאות bigquery.jobs.create ו-Cloud Storage מריץ שאילתה שמייצאת תוצאות לקטגוריה ציבורית של Cloud Storage מחוץ לשליטת הארגון.
אמצעי צמצום סיכונים	הטמעה של אמצעי בקרה ליציאה מהרשת כדי לצמצם את הסיכון לזליגת מידע לשירותים חיצוניים שרירותיים. מטמיעים service perimeter של VPC Service Controls סביב הפרויקט שמכיל את משאבי BigQuery. גבולות גזרה אלה עוזרים להגביל את זליגת הנתונים לשירותי Google Cloud מחוץ לגבולות גזרה. הגדרת רמות גישה לגבולות גזרה כדי לאפשר רק בקשות API שמקורן בטווחי IP מהימנים או ברשתות VPC ספציפיות, ובכך למנוע גישה לנתונים או העברה שלהם מחוץ לגבול האבטחה המוגדר.

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

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

קטגוריית STRIDE	שיבוש
טקטיקה של MITRE ATT&CK	השפעה
Manifestations	שינוי טבלה של מאפיינים: שינוי של ערכים או מאפיינים מרכזיים בטבלה של מאפייני מוצרים. פגיעה בחיפוש: שינוי נתוני מיפוי בטבלת חיפוש.
אמצעי צמצום סיכונים	מגבילים באופן משמעותי את הרשאות הכתיבה (bigquery.tables.updateData) לטבלאות הפניה או החיפוש, כך שרק תהליכי הטמעה מהימנים של נתונים יוכלו לגשת אליהן. הטמעה של בדיקות איכות נתונים וצינורות אימות. אפשר להשתמש בתמונות מצב של טבלאות או בניהול גרסאות כדי לעקוב אחרי שינויים ולאפשר חזרה לגרסה קודמת. חשוב לעקוב אחרי יומני הביקורת כדי לראות אם יש שינויים בטבלאות הקריטיות האלה.

שיבוש נתונים באמצעות משימות טעינה זדוניות

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

קטגוריית STRIDE	שיבוש
טקטיקה של MITRE ATT&CK	השפעה
Manifestations	החלפת טבלה: גורם ראשי עם הרשאות bigquery.jobs.create ו-bigquery.tables.updateData יוזם עבודת טעינה עם הגדרת כתיבה WRITE_TRUNCATE, מחיקת כל הנתונים הקיימים והחלפתם בנתונים זדוניים ממקור חיצוני. הוספת נתונים זדוניים: תוקף משתמש בעבודת טעינה עם WRITE_APPEND כדי להחדיר נתונים זדוניים או נתונים לא רלוונטיים לטבלה קיימת, וכך לפגוע בניתוח הנתונים בלי למחוק רשומות מקוריות.
אמצעי צמצום סיכונים	החלת העיקרון של הרשאות מינימליות. חשוב לשלוט בהרשאות כמו bigquery.jobs.create ו-bigquery.tables.updateData (שנמצאות בתפקידים כמו roles/bigquery.dataEditor). צריך להעניק את ההרשאות האלה רק לגורמים מהימנים ולהגביל אותן למערכי נתונים או לטבלאות ספציפיים. בודקים ביומני הביקורת של Cloud אם משימות הטעינה הושלמו, במיוחד משימות עם WRITE_TRUNCATE סטטוס, ויוצרים התראות למשימות שמקורן במשתמשים לא צפויים או שמטעינות נתונים ממקורות לא מהימנים.

הרשאות IAM מוגזמות שמובילות לחשיפת מידע

תפקידי IAM עם הרשאות רחבות מדי עלולים לאפשר גישה מוגזמת למידע אישי רגיש שמאוחסן בטבלאות BigQuery. תוקף שפורץ לישות מורשית עם הרשאות גישה לנתונים נרחבות יכול להעביר כמויות גדולות של נתונים, מה שיוביל לפרצה באבטחת מידע משמעותית. האיום הזה מתממש כשניתנות הרשאות כמו bigquery.tables.getData או bigquery.jobs.create בהיקף רחב (לדוגמה, ברמת הפרויקט) במקום להגביל אותן למערכי נתונים או לטבלאות ספציפיות שנדרשות לפונקציה עסקית.

קטגוריית STRIDE	גילוי נאות
טקטיקה של MITRE ATT&CK	זליגת נתונים
Manifestations	קריאת נתונים ישירה: לגורם מרכזי עם ההרשאה bigquery.tables.getData יש אפשרות לקרוא נתונים ישירות מטבלאות באמצעות שיטת ה-API‏ tabledata.list או BigQuery Storage Read API עם תפוקה גבוהה. שליפת נתונים שמבוססת על שאילתות: חשבון משתמש עם הרשאה bigquery.jobs.create יכול להריץ משימת שאילתה באמצעות jobs.insert או jobs.query כדי לקרוא נתונים מכל טבלה שיש לו גישה אליה, ואז לאחזר את התוצאות באמצעות jobs.getQueryResults. נגישות ציבורית: אפשר להגדיר מדיניות הרשאות IAM במערך נתונים או בטבלה ב-BigQuery כדי לאפשר גישה ציבורית על ידי הקצאת תפקידים לישויות מיוחדות כמו allUsers או allAuthenticatedUsers, וכך לחשוף נתונים באינטרנט.
אמצעי צמצום סיכונים	הטמעת העיקרון של הרשאות מינימליות בכל כללי מדיניות ההרשאה של IAM. מומלץ להעניק הרשאות ברמה הכי מפורטת שנדרשת (למשל, טבלאות או מערכי נתונים ספציפיים ב-BigQuery) ולא ברמת הפרויקט. כדאי להשתמש בתפקידי IAM עם הרשאות מינימליות שמכילים רק את ההרשאות הנדרשות (לדוגמה, bigquery.tables.getData, bigquery.jobs.create) למשימות ספציפיות. חשוב לבצע ביקורת באופן קבוע על מדיניות ההרשאה ב-IAM כדי לוודא שאין תפקידים עם הרשאות רחבות מדי כמו roles/bigquery.dataViewer או roles/bigquery.user שמוחלים ברמה גבוהה בהיררכיית המשאבים.

העברה של נתונים אל פרויקט בענן או חשבון בענן שנמצאים בשליטת התוקף

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

קטגוריית STRIDE	גילוי נאות
טקטיקה של MITRE ATT&CK	זליגת נתונים
Manifestations	ייצוא לקטגוריה חיצונית: שימוש בעבודת ייצוא כדי לשמור נתוני טבלה בקטגוריה של Cloud Storage בפרויקט של התוקף. יעד שאילתה בין פרויקטים: הרצת שאילתה והגדרת טבלת היעד למערך נתונים בפרויקט שנשלט על ידי תוקף.
אמצעי צמצום סיכונים	מטמיעים את VPC Service Controls כדי ליצור גבול גזרה מסביב לפרויקט, וכך למנוע זליגת נתונים לפרויקטים מחוץ לגבול הגזרה. שליטה בהרשאות כמו bigquery.tables.export ו-bigquery.jobs.create. משתמשים באילוצים של מדיניות הארגון כדי להגביל את השיתוף והיצירה של פרויקטים. כדאי לעקוב ביומני הביקורת של Cloud אחרי משימות ייצוא או שאילתות עם יעדים מחוץ לגבולות הפרויקט הצפויים.

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

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

קטגוריית STRIDE	גילוי נאות
טקטיקה של MITRE ATT&CK	אוסף
Manifestations	לוגיקת תצוגה פגומה: השאילתה של תצוגה מורשית משמיטה סעיפי WHERE נדרשים שקיימים במדיניות אבטחה ברמת השורה בטבלת הבסיס. עקיפת אבטחה ברמת השורה: מדיניות אבטחה מורכבת ברמת השורה מכילה שגיאה לוגית שמאפשרת גישה רחבה יותר מהמתוכנן.
אמצעי צמצום סיכונים	מטמיעים תהליך קפדני של סקר קוד ללוגיקת ה-SQL שמשמשת בתצוגות מורשות ובכללי מדיניות אבטחה ברמת השורה. חשוב לבדוק את לוגיקת האבטחה באופן יסודי. הגבלת הרשאות (כמו bigquery.tables.create,‏ bigquery.tables.update או bigquery.rowAccessPolicies.create) ליצירה או לעדכון של תצוגות ומדיניות אבטחה ברמת השורה. חשוב לבדוק באופן קבוע את התצוגות הקיימות ואת הגדרות האבטחה ברמת השורה. חשוב לפעול לפי השיטות המומלצות בנוגע לאבטחה ברמת השורה.

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

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

קטגוריית STRIDE	גילוי נאות
טקטיקה של MITRE ATT&CK	זליגת נתונים
Manifestations	מערך נתונים ציבורי: מדיניות הרשאות IAM במערך נתונים מעניקה הרשאות צפייה ל-allUsers. שיתוף יתר בין פרויקטים: מערך נתונים משותף עם ארגון חיצוני או עם חשבון שירות בפרויקט לא מהימן.
אמצעי צמצום סיכונים	הטמעת העיקרון של הרשאות מינימליות במדיניות ההרשאות של IAM של מערכי נתונים. אפשר להשתמש במדיניות הארגון, כמו constraints/iam.allowedPolicyMemberDomains, כדי להגביל את השיתוף לדומיינים ספציפיים. כדאי לבצע ביקורת על מדיניות ההרשאות של IAM במערכי נתונים באופן קבוע באמצעות Security Command Center, כדי לזהות הרשאות ציבוריות או רחבות מדי. אפשר להשתמש ב-VPC Service Controls כדי ליצור גבולות גזרה מסביב לפרויקטים שמכילים מידע אישי רגיש, וכך למנוע יציאה לא מורשית של נתונים.

שימוש לרעה על ידי משתמשים פנימיים בגישה מורשית ל-BigQuery (שאילתות לגיטימיות שמשמשות לאיסוף זדוני)

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

קטגוריית STRIDE	גילוי נאות
טקטיקה של MITRE ATT&CK	אוסף
Manifestations	אגירת נתונים: שליחת שאילתות והורדה של נתוני לקוחות באופן קבוע מעבר לדרישות התפקיד. ניתוח רגיש: ביצוע ניתוחים כדי לחלץ סודות מסחריים או פרטים אישיים מזהים (PII) לצורך העברה לא מורשית.
אמצעי צמצום סיכונים	כדי לעקוב אחרי דפוסי גישה לנתונים, מומלץ להפעיל את יומני הביקורת Data Access ולעקוב אחריהם. כדאי להשתמש בכלים כמו Sensitive Data Protection כדי לסרוק את תוצאות השאילתות ולחפש מידע רגיש. הטמעה של ניתוח התנהגות משתמשים (UBA) כדי לזהות דפוסי שאילתות חריגים או נפחי גישה לנתונים. אכיפה של כללי מדיניות ברורים לטיפול בנתונים ומתן הדרכה להעלאת המודעות לאבטחה. כדי להגביל את החשיפה של הנתונים גם למשתמשים מורשים, אפשר להשתמש באבטחה ברמת השורה ובאבטחה ברמת העמודה.

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

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

קטגוריית STRIDE	העלאת רמת ההרשאה
טקטיקה של MITRE ATT&CK	התמדה
Manifestations	הרשאות IAM לערכת נתונים מוסתרת: הענקת הרשאות צפייה בחשבון אישי בערכת נתונים ספציפית שפחות מנוטרת. דלת אחורית לתצוגה מורשית: יצירת תצוגה עם הרשאה לגשת לטבלה מוגבלת, והענקת גישה לתצוגה. שאילתה מתוזמנת זדונית: הגדרת שאילתה מתוזמנת להעתקת נתונים למיקום חיצוני מעת לעת.
אמצעי צמצום סיכונים	חשוב לבדוק באופן קבוע את כל כללי מדיניות ההרשאה ב-IAM, כולל הרשאות ברמת מערך הנתונים, באמצעות כלים כמו Security Command Center. שליטה בהרשאות ליצירה או לעדכון של מערכי נתונים (bigquery.datasets.update), שגרות (bigquery.routines.create/update) והעברות נתונים (bigquery.transfers.update).

זיוף באמצעות פרטי כניסה לחשבון שירות שנפרץ או אסימון OAuth שמשמש לגישה ל-BigQuery

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

קטגוריית STRIDE	זיוף
טקטיקה של MITRE ATT&CK	Initial Access
Manifestations	מפתח של חשבון שירות הודלף: קובץ מפתח JSON נחשף במאגרי קוד, באחסון ציבורי או במטא-נתונים של מופע. אפליקציה שנפרצה: אפליקציה שמשתמשת בחשבון שירות נפרצת, והתוקף יכול לחלץ את פרטי הכניסה שלה ולהשתמש בהם. טוקן OAuth שנגנב: תוקף מיירט או מדליף טוקן OAuth מאפליקציית לקוח או מהפעלה של דפדפן. טוקן עם היקף הרשאות רחב מדי: אפליקציה מבקשת ומאחסנת טוקנים עם היקפי הרשאות רחבים מדי (לדוגמה, גישה מלאה ל-BigQuery כשנדרשת רק גישת קריאה).
אמצעי צמצום סיכונים	מומלץ להימנע מייצוא של מפתחות לחשבונות שירות. במקום זאת, מומלץ להשתמש בחשבונות שירות מצורפים או באיחוד שירותי אימות הזהות של עומסי עבודה, אם אפשר. אם יש צורך במפתחות, מבצעים רוטציה של המפתחות באופן קבוע ומעניקים לחשבון השירות רק את ההרשאות המינימליות הנדרשות. עוקבים אחרי יומני הביקורת של Cloud ו-Security Command Center כדי לזהות פעילות חריגה בחשבון שירות או חשיפה של מפתח. משתמשים באילוץ constraints/iam.disableServiceAccountKeyCreation של מדיניות הארגון כדי להשבית את היצירה של מפתחות לחשבונות שירות. אחסון ושליחה של טוקנים של OAuth באופן מאובטח. כדאי לפעול לפי השיטות המומלצות של OAuth 2.0. בקשו רק את היקפי ההרשאות הנדרשים. חשוב להשתמש בטוקנים לטווח קצר ובטוקנים לרענון בצורה מאובטחת. הטמעה של מנגנונים לזיהוי ולביטול של טוקנים שנפרצו. מעקב אחרי דפוסי שימוש חריגים בטוקנים. מבצעים אמצעי הגנה סטנדרטיים על מפתחות של חשבונות שירות. הגדרת אורך הסשן בשירותי Google Cloud כדי לאכוף אסימונים לטווח קצר ולצמצם את הסיכון לאסימון שדלף.

מניעת שירות מבוססת-עלות באמצעות שאילתות יקרות

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

קטגוריית STRIDE	התקפת מניעת שירות
טקטיקה של MITRE ATT&CK	השפעה
Manifestations	שאילתות לא אופטימליות: הרצת שאילתות עם הצלבות בטבלאות גדולות ללא מסננים. ביצוע חוזר: הפעלת סקריפטים לביצוע תכוף של שאילתות יקרות.
אמצעי צמצום סיכונים	אפשר להשתמש במכסות מותאמות אישית של BigQuery כדי להגדיר מגבלות על השימוש בשאילתות ברמת המשתמש וברמת הפרויקט (לדוגמה, בייטים שנסרקו ביום). משתמשים בפרמטר maximumBytesBilled במשרות של שאילתות. משתמשים בהזמנות ב-BigQuery כדי לבודד עומסי עבודה ולהבטיח קיבולת. כדי לזהות חריגות ולהגיב להן, אפשר להגדיר התראות חיוב בחיוב ב-Cloud ולעקוב אחרי ניצול המשבצות ב-Cloud Monitoring.