דוח מודל האיומים של Cloud Storage

תאריך העדכון האחרון: 22 במאי 2026

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

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

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

• חשיפת מידע באמצעות הגדרת גישה לא מאובטחת
• העלאת רמת הרשאה באמצעות הגדרות שגויות של IAM
• שיבוש או השמדה של נתונים באמצעות הרשאות מוגזמות
• זליגת נתונים באמצעות משימות של Storage Transfer Service שהוגדרו בצורה שגויה
• אובדן גישה לנתונים בגלל ניהול לא תקין של תלות
• הסתרת פעילות בגלל חוסר יכולת מעקב מספקת
• הרעלת שרשרת אספקה באמצעות ארטיפקטים שנפרצו ומאוחסנים ב-Cloud Storage
• מניעת שירות מבוססת-עלות באמצעות הצפת אובייקטים ב-Cloud Storage או ניצול לרעה של תעבורת נתונים יוצאת
• שינוי תקינות הנתונים באמצעות ניצול לרעה של ניהול גרסאות של אובייקטים ב-Cloud Storage
• גניבת נתונים באמצעות צינורות עיבוד נתונים של Dataflow שהופעלו על ידי Cloud Storage
• פגיעה בשלמות באמצעות מניפולציה של מצב IaC ב-Cloud Storage
• העלאת רמת ההרשאות של סקריפטים להפעלה או לאתחול שמאוחסנים ב-Cloud Storage
• דלת אחורית בשרשרת האספקה באמצעות נתוני אימון של למידת מכונה (ML) שמתארחים ב-Cloud Storage
• התקפת מניעת שירות (DoS) באמצעות תהליכי עבודה מסוג fan-out שמופעלים על ידי יצירת אובייקט ב-Cloud Storage
• תנועת נתונים לא מורשית באמצעות צינורות גיבוי שמגובים על ידי Cloud Storage
• עקיפת מדיניות באמצעות שימוש ברשימות ACL מדור קודם של Cloud Storage בסביבות היברידיות
• השמדת נתונים באמצעות צינורות עיבוד נתונים של CI/CD שנפרצו ומכוונים ל-Cloud Storage
• מחיקה לא מורשית של מאגר באמצעות חשבונות עם הרשאות גבוהות מדי לגישה במקרה חירום
• העברת נתונים חשאית באמצעות יעד של יומן שנפרץ וכותב ל-Cloud Storage
• הפעלת תוכנות כופר באמצעות ביטול מרכזי של CMEK
• גניבת נתונים באמצעות ייצוא של תמונת מצב או גיבוי ל-Cloud Storage

פרטי האיום

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

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

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

קטגוריית STRIDE	גילוי נאות
טקטיקה של MITRE ATT&CK	אוסף
Manifestations	חשיפה של קטגוריה ציבורית: קטגוריה ב-Cloud Storage הופכת לציבורית כשמעניקים תפקידים כמו Storage Object Viewer לחשבונות allUsers או allAuthenticatedUsers במדיניות ההרשאות שלה ב-IAM. אם מניעת הגישה הציבורית לנתונים לא נאכפת, התפקידים האלה חושפים את כל האובייקטים באינטרנט. דליפה של כתובת URL חתומה: כתובת URL חתומה, שמשמשת כאסימון זמני, דולפת בטעות דרך קוד בצד הלקוח, יומנים או שידור לא מאובטח. כל משתמש או אפליקציה חיצוניים שמקבלים את כתובת ה-URL יכולים לגשת לאובייקט שצוין ב-Cloud Storage עם ההרשאות (לדוגמה, קריאה או כתיבה) עד שתוקף החתימה של כתובת ה-URL יפוג. הרשאות IAM רחבות מדי: זהויות, כמו חשבון משתמש או חשבון שירות, מקבלות הרשאות רחבות (לדוגמה, storage.objects.get או storage.objects.list) בהרבה דליים, כשהזהויות צריכות גישה רק לקבוצת משנה קטנה של נתונים. פרטי כניסה של זהות שנפרצה: תוקף משיג את פרטי הכניסה של חשבון משתמש או מפתח של חשבון שירות, מה שמאפשר לו לבצע אימות ל-API בפורמט JSON של Cloud Storage ולגשת לכל הנתונים שהזהות שנפרצה מורשית לראות. הגדרה שגויה של מאזן עומסים: יכול להיות שמופע של Cloud Load Balancing שהוגדר עם קטגוריית Cloud Storage כקצה עורפי, יוגדר בצורה שגויה ויחשוף אובייקטים לציבור, גם אם הקטגוריה עצמה לא ציבורית. הגדרת שגיאה כזו יוצרת נתיב גישה חלופי לנתונים, שיכול להיות פחות מאובטח, ועוקף את אמצעי הבקרה הישירים של IAM ב-Cloud Storage. שמירת נתונים במטמון של CDN בצורה לא תקינה: כשמשתמשים בקטגוריה של Cloud Storage כקצה עורפי של Cloud Load Balancing ו-Cloud CDN, הגדרה שגויה עלולה לגרום לשמירת מידע אישי רגיש במטמון במיקומי קצה ציבוריים של Google. אם שירות הבק-אנד לא שולח את הכותרות הנכונות של Cache-Control (לדוגמה, private או no-store), יכול להיות שרשת ה-CDN תציג את התוכן שנשמר במטמון למשתמשים לא מורשים, ותעקוף את בדיקות ה-IAM של קטגוריית ה-bucket.
אמצעי צמצום סיכונים	אפשר לאכוף את מניעת הגישה הציבורית לנתונים בקטגוריות אחסון ספציפיות או ברמת הפרויקט, התיקייה או הארגון באמצעות האילוץ storage.publicAccessPrevention של מדיניות הארגון. כדי לפשט את ההרשאות ולהימנע מרשימות ACL מדור קודם, מומלץ להשתמש בגישה אחידה ברמת הקטגוריה. הגדרת מפתחות הצפנה בניהול הלקוח (CMEK) כדי להגן על נתונים באמצעות הצפנה במנוחה. חשוב להגדיר את תוקף כתובות ה-URL החתומות לזמן הקצר ביותר האפשרי. חשוב לבדוק באופן קבוע את המפתחות של חשבונות השירות ולהסיר מפתחות שנפרצו או שלא נמצאים בשימוש. כדאי להטמיע VPC Service Controls כדי ליצור גבולות גזרה לשירות ולמנוע זליגת נתונים גם אם פרטי הכניסה נגנבים. כדי להגביל את הגישה, מוודאים שמדיניות Cloud Armor חלה על מאזני עומסים שמציגים תוכן של Cloud Storage.

העלאת רמת הרשאה באמצעות הגדרות שגויות של IAM

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

קטגוריית STRIDE	העלאת רמת ההרשאה
טקטיקה של MITRE ATT&CK	הסלמת הרשאות
Manifestations	שינוי ישיר של מדיניות: זהות, כמו משתמש או חשבון שירות, שקיבלה את ההרשאה storage.buckets.setIamPolicy בקטגוריה של Cloud Storage יכולה לשנות ישירות את מדיניות ההרשאות שלה. ההגדרה הזו מאפשרת לתוקף להעניק לעצמו תפקידים עם הרשאות גבוהות, כמו Storage Admin, וכך להשיג שליטה מלאה בהגדרות ובנתונים של ה-bucket. התחזות לחשבון שירות: זהות עם תפקיד כמו roles/iam.serviceAccountUser שמכיל את ההרשאה iam.serviceAccounts.actAs בחשבון שירות יכולה לצרף את חשבון השירות למשאבים אחרים, כמו מכונה של Compute Engine, כדי להריץ קוד עם הזהות של חשבון השירות המצורף. לחלופין, זהות עם תפקיד כמו roles/iam.serviceAccountTokenCreator שיש לו הרשאות כולל iam.serviceAccounts.getAccessToken יכולה ליצור אסימוני גישה לחשבון השירות הזה. אם לחשבון השירות של היעד יש הרשאות מורחבות למשאבי Cloud Storage, התוקף יורש למעשה את ההרשאות האלה. יצירת כתובות URL חתומות: זהות עם ההרשאה iam.serviceAccounts.signBlob בחשבון שירות יכולה ליצור כתובות URL חתומות בגרסה 4. כתובות ה-URL האלה מאפשרות לתוקף ליצור גישה זמנית באמצעות אסימון bearer לאובייקטים שחשבון השירות יכול לקרוא או לכתוב, ובכך לעקוף אמצעי בקרה מגבילים יותר ברשת או את העובדה שלתוקף אין הרשאות ישירות ל-Cloud Storage.
אמצעי צמצום סיכונים	פועלים לפי העיקרון של הרשאות מינימליות. מומלץ להימנע מהוספת הרשאות כמו storage.buckets.setIamPolicy, iam.serviceAccounts.actAs או iam.serviceAccounts.signBlob לתפקידים, אלא אם זה הכרחי. משתמשים בתנאים של IAM כדי להגביל את ההרשאות למשאבים ספציפיים או לפרקי זמן מסוימים. כדאי לבדוק באופן קבוע את מדיניות ההרשאות באמצעות כלים כמו מאגר משאבי הענן, כדי לזהות הרשאות מוגזמות ולהסיר אותן. חשוב לוודא שאפליקציות שמטפלות בכתובות URL חתומות לא מתעדות אותן ולא חושפות אותן באופן שמאפשר לצדדים שלישיים לגרד אותן. לדוגמה, אם משתמשים ב-Cloud CDN כדי לשמור במטמון כתובות URL חתומות, צריך להגדיר כותרות מתאימות של Cache-Control כדי למנוע שמירה במטמון באופן ציבורי של אובייקטים רגישים שצריכים להיות פרטיים ומאומתים באמצעות כתובת URL חתומה.

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

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

קטגוריית STRIDE	שיבוש
טקטיקה של MITRE ATT&CK	השפעה
Manifestations	מניפולציה ישירה של אובייקטים: זהות עם הרשאות storage.objects.create או storage.objects.delete יכולה לדרוס או להרוס אובייקטים ספציפיים ב-Cloud Storage. הפיכת מדיניות מחזור החיים לכלי נשק: תוקף עם הרשאה storage.buckets.update יכול לשנות את ההגדרה של ניהול מחזור החיים של האובייקטים בקטגוריה כדי ליצור כלל שמוחק את כל האובייקטים באופן מיידי או אחרי תקופה קצרה, וכך לגרום להרס המוני של נתונים. מחיקת קטגוריה: תוקף עם הרשאות גבוהות מאוד והרשאה storage.buckets.delete יכול למחוק קטגוריה שלמה ב-Cloud Storage, ובכך להרוס באופן מיידי את כל האובייקטים, ההגדרות והמדיניות שמשויכים אליה. חטיפת התראות: תוקף עם הרשאה storage.buckets.update יכול לשנות או למחוק באופן זדוני הגדרות של התראות Pub/Sub. המתקפה הזו יכולה להשבית מערכות במורד הזרם שמסתמכות על האירועים האלה, או להפנות התראות לנושא שנשלט על ידי התוקף.
אמצעי צמצום סיכונים	אם אתם צריכים אחסון שלא ניתן לשינוי או תקופת שמירה מינימלית, אתם יכולים להגדיר נעילת קטגוריה לקטגוריה כולה או נעילת אובייקט לאובייקטים בודדים. כדי לתכנן שחזור נתונים במקרה של שכתוב בטעות או בזדון בקטגוריות שמכילות נתונים קריטיים, כדאי להגדיר ניהול גרסאות של אובייקטים ומדיניות של מחיקה רכה. כדאי להגדיר תקופה מוגדרת למחיקה רכה, שתיתן לכם מספיק זמן לזהות את האובייקטים ולשחזר אותם לפני שהם יימחקו באופן סופי. כדי לעקוב אחרי דפוסי גישה לא סדירים, מומלץ להפעיל יומני ביקורת של גישה לנתונים בדליים שמכילים נתונים קריטיים.

זליגת נתונים באמצעות משימות של Storage Transfer Service שהוגדרו בצורה לא נכונה

תוקף עם הרשאות storagetransfer.transferjobs.create או storagetransfer.transferjobs.update יכול ליצור או לשנות משימה של Storage Transfer Service כדי להעתיק נתונים מקטגוריה רגישה של Cloud Storage לקטגוריה בשליטת התוקף בפרויקט אחר. אפשר להשתמש בווקטור התקפה הזה כדי לחלץ נפחים גדולים של נתונים באופן שקט ורציף, תוך עקיפת מעקב טיפוסי אחר גישה לנתונים, שמתמקד בדרך כלל בקריאות ישירות ל-API כמו storage.objects.get.

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

אובדן גישה לנתונים בגלל ניהול לא תקין של תלות

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

קטגוריית STRIDE	שיבוש
טקטיקה של MITRE ATT&CK	השפעה
Manifestations	אי-זמינות של CMEK: אם קטגוריית Cloud Storage מוגדרת לשימוש ב-CMEK, השבתה או מחיקה של מפתח ה-Cloud KMS שמשמש כגיבוי גורמת לכך שאי אפשר לגשת באופן קריפטוגרפי לכל האובייקטים שמוצפנים באמצעות המפתח הזה. סוכן השירות של Cloud Storage לא יכול לבצע פענוח, ולכן הגישה לנתונים האלה נחסמת לחלוטין. נעילת קטגוריה זדונית: תוקף עם הרשאות storage.buckets.update יכול להחיל נעילת קטגוריה עם תקופת שמירה ארוכה מדי. הנעילה הזו מונעת מחיקה לגיטימית של נתונים, מה שעלול להוביל להצטברות של עלויות משמעותיות ומיותרות, שהן סוג של מניעת שירות פיננסית.
אמצעי צמצום סיכונים	הטמעה של מדיניות הרשאות קפדנית ב-IAM והפרדת תפקידים לניהול Cloud KMS. מוודאים שלזהויות עם הרשאה לניהול קטגוריות של Cloud Storage אין גם הרשאה לניהול המפתחות של Cloud KMS שבהם נעשה שימוש בקטגוריות. שימוש במנגנונים למניעת מחיקה של מפתחות Cloud KMS. במקרה של נעילת מאגר, חשוב לשלוט בהרשאה storage.buckets.update ולעקוב אחרי שינויים לא צפויים בהגדרות כדי לקבל התראות.

הסתרת פעילות בגלל חוסר יכולת מעקב מספקת

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

קטגוריית STRIDE	התכחשות
טקטיקה של MITRE ATT&CK	Defense Evasion
Manifestations	יומני גישה לנתונים מושבתים: יומני פעילות האדמין תמיד מופעלים, אבל יומני הגישה לנתונים, שמתעדים קריאה וכתיבה של אובייקטים, מושבתים כברירת מחדל. אם לא מפעילים את ההגדרה הזו באופן מפורש, תוקף יכול להעביר נתונים מחוץ למאגר או לשנות את כל הנתונים במאגר, בלי שיווצרו יומני ביקורת של Cloud לפעולות האלה. כך קשה לזהות את הפרצה או לחקור אותה. שינוי של אובייקט מסוג sink ביומן: תוקף שמקבל הרשאות מספיקות יכול להשבית או להגדיר מחדש את האובייקטים מסוג sink ביומן שמנתבים את יומני הביקורת של Cloud, ובכך לעצור את זרימת הנתונים שרלוונטיים לאבטחה למערכות הניטור. הזנחת מעקב אחרי מדדים: תוקף מבצע פעילויות איטיות ומתונות, כמו העברה הדרגתית של כמויות קטנות של נתונים לאורך תקופה ארוכה. יכול להיות שהפעולות האלה לא יפעילו התראות ברמת חומרה גבוהה ביומני הביקורת של Cloud, אבל הן ייצרו דפוסים חריגים במדדים של Cloud Monitoring (לדוגמה, תעבורת נתונים יוצאת מתמשכת). אם לא עוקבים אחרי המדדים האלה, התוקף יכול להישאר לא מזוהה.
אמצעי צמצום סיכונים	מפעילים את יומני הביקורת Data Access לכל הדליים שמכילים נתונים רגישים או קריטיים. מוודאים שהיומנים מנותבים לפרויקט רישום מרכזי ומאובטח, עם הרשאות מבוקרות בקפידה כדי למנוע שינוי של יומני השימוש. כדי לזהות באופן פעיל פעילויות חשודות, כמו דפוסי גישה חריגים או שינויים במדיניות ההרשאות ב-IAM, אפשר להגדיר התראות שמבוססות על יומנים ב-Cloud Monitoring או במערכת SIEM. כדי לזהות חריגות מההתנהגות הבסיסית, אפשר ליצור התראות שמבוססות על מדדים מרכזיים של Cloud Monitoring. להשתמש בלוחות בקרה מובנים של Storage Intelligence ובנתוני תובנות מ-Data Security Posture Management כדי לספק מעקב רציף אחר חשיפת הסיכון ברמת האובייקט והערכות של מצב האבטחה.

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

אם תוקף מקבל הרשאת כתיבה, כמו storage.objects.create או storage.objects.delete, לקטגוריית Cloud Storage שמשמשת לאחסון ארטיפקטים של תוכנה (לדוגמה, קבצים בינאריים, קובצי אימג' של קונטיינרים או סקריפטים של בנייה), הוא יכול להחליף ארטיפקטים לגיטימיים בגרסאות זדוניות. צינורות CI/CD במורד הזרם, מפתחים או משתמשי קצה שסומכים על הארטיפקטים מהמאגר הזה יריצו בטעות את הקוד שנפרץ, מה שיוביל למתקפת שרשרת אספקה נרחבת.

קטגוריית STRIDE	שיבוש
טקטיקה של MITRE ATT&CK	Initial Access
Manifestations	החלפה בינארית: תוקף מחליף ספרייה או קובץ בינארי של גרסת הפצה בגרסה שכוללת סוס טרויאני. כשהארטיפקט הזה נטען לתוך build או נפרס, הקוד של התוקף מופעל בסביבת היעד. הרעלת קובצי אימג' של קונטיינרים: לתוקף עם גישה לקטגוריה שמשמשת כבק-אנד למאגר קונטיינרים (לדוגמה, Artifact Registry) יש פוטנציאל לשנות שכבות של קובצי אימג', להחדיר נקודות חולשה או Backdoor. שינוי סקריפט בנייה: תוקף משנה סקריפטים של בנייה (לדוגמה, cloudbuild.yaml או Makefile) שמאוחסנים ב-Cloud Storage כדי לשנות את תהליך build עצמו. יכול להיות שתוקף ישנה סקריפטים של build כדי לייצא סודות או להטמיע דלת אחורית במהלך הקומפילציה. הרעלת מודל AI: תוקף עשוי להחליף נקודת ביקורת תקינה של מודל ב-Cloud Storage בנקודת ביקורת זדונית שמריצה קוד כשהיא נטענת על ידי מערכת ייצור. או שתוקף יכול לשנות נתונים בקטגוריה של Cloud Storage שמשמשת לאימון מודלים, כדי להחדיר דלתות אחוריות או התנהגות זדונית למודל שאומן.
אמצעי צמצום סיכונים	להשתמש בשירות ייעודי לניהול ארטיפקטים, כמו Artifact Registry, שכולל סריקה לאיתור נקודות חולשה ובקרת גישה משופרת. אל תשתמשו בקטגוריות רגילות של Cloud Storage לאחסון של ארטיפקטים קריטיים של תוכנה. הטמעה של חתימה דיגיטלית לכל הארטיפקטים של הבנייה. כדאי להגדיר צינורות CI/CD כדי לאמת את החתימה של ארטיפקט לפני פריסתו, וכך לוודא את השלמות והמקוריות שלו. כדי לשמור אובייקטים שנמחקו או שנכתבו עליהם נתונים זדוניים, צריך להגדיר ניהול גרסאות של אובייקטים בקטגוריה.

מניעת שירות מבוססת-עלות באמצעות הצפת אובייקטים ב-Cloud Storage או ניצול לרעה של תעבורת נתונים יוצאת

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

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

שימוש לרעה בניהול גרסאות של אובייקטים ב-Cloud Storage כדי לשנות את תקינות הנתונים

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

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

זליגת נתונים באמצעות צינורות Dataflow שהופעלו על ידי Cloud Storage

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

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

פגיעה בשלמות הנתונים באמצעות מניפולציה של מצב IaC ב-Cloud Storage

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

קטגוריית STRIDE	שיבוש
טקטיקה של MITRE ATT&CK	השפעה
Manifestations	השבתה של אמצעי בקרה לאבטחה: תוקף משנה את קובץ המצב כדי להציג מצב לא מדויק של כלל חומת אש או של מדיניות הרשאות IAM. יכול להיות שההפעלה הבאה של Terraform לא תחיל את ההגדרה המאובטחת הרצויה בצורה נכונה.
אמצעי צמצום סיכונים	מפעילים ניהול גרסאות של אובייקטים בקטגוריה של Cloud Storage שבה מאוחסן קובץ המצב. ניהול גרסאות של אובייקטים מאפשר לשחזר את קובץ המצב במקרה של שינוי מקרי או זדוני. הטמעת אמצעי בקרה קפדניים של IAM בקטגוריית קובצי המצב. חשוב לוודא שרק לחשבון השירות של CI/CD יש הרשאת כתיבה, ולמפתחים יש הרשאת קריאה בלבד לכל היותר.

העלאת רמת ההרשאות של סקריפטים להפעלה או לאתחול שמאוחסנים ב-Cloud Storage

אם מכונה של Compute Engine או צומת GKE שולפים את הסקריפטים להפעלה או לאתחול מקטגוריה של Cloud Storage, תוקף עם גישת כתיבה לקטגוריה הזו יכול לשנות את הסקריפטים האלה. מכיוון שהסקריפטים האלה פועלים לעיתים קרובות עם הרשאות גבוהות (למשל, כמשתמש root במכונה הווירטואלית או עם חשבון השירות של הצומת), התוקף יכול להזריק פקודות כדי ליצור משתמשים עם דלת אחורית, להעביר מטא-נתונים ואסימוני גישה או להתקין תוכנה זדונית. הפעולות האלה מאפשרות לתוקף להרחיב את ההרשאות שלו מהרשאות כתיבה לאובייקט ב-Cloud Storage לשליטה מלאה במשאבי מחשוב.

קטגוריית STRIDE	העלאת רמת ההרשאה
טקטיקה של MITRE ATT&CK	הסלמת הרשאות
Manifestations	גניבת מטא-נתונים: התוקף מוסיף פקודות כמו curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/... לסקריפט לטעינה בזמן ההפעלה כדי לגנוב אסימונים של חשבונות שירות או סודות אחרים. Reverse shell: התוקף מחדיר פקודה כדי להפעיל reverse shell ממופע המחשוב לשרת שנמצא בשליטת התוקף, וכך מקבל גישה אינטראקטיבית.
אמצעי צמצום סיכונים	אחסון סקריפטים להפעלה בקטגוריה ייעודית של Cloud Storage עם בקרות הדוקות. כדאי להחיל כללי מדיניות הרשאה של IAM עם הרשאות מינימליות, כך שרק אדמינים מורשים או צינורות CI/CD יוכלו לשנות את הסקריפטים. כדאי לשקול אסטרטגיה לסיווג נתונים שבה מגדירים תגי משאבים בקטגוריות שמשמשות לסקריפטים להפעלה, ומשתמשים בגישה מותנית מבוססת-תגים של IAM כדי להגביל עוד יותר את הגישה. במקום לשלוף סקריפטים מ-Cloud Storage, אפשר לכלול אותם בתמונות מכונה מותאמות אישית. השיטה הזו יוצרת ארטיפקט שלא ניתן לשנות, ולכן הוא פחות רגיש לשינויים בזמן הריצה.

דלת אחורית בשרשרת האספקה באמצעות נתוני אימון של למידת מכונה (ML) שמתארחים ב-Cloud Storage

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

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

התקפת מניעת שירות (DoS) באמצעות תהליכי עבודה מסוג fan-out שמופעלים על ידי יצירת אובייקט ב-Cloud Storage

אם תהליך עבודה (לדוגמה, פונקציות של Cloud Run או Workflows) מוגדר להפעיל יצירת אובייקט בקטגוריה של Cloud Storage ולבצע משימה שדורשת הרבה משאבים, תוקף עם הרשאה storage.objects.create יכול ליזום התקפת מניעת שירות (DoS). התוקף יכול להעלות מספר גדול של קבצים בפרק זמן קצר (מה שנקרא טריגר fan-out), ולגרום לשירות במורד הזרם להתרחב במהירות, לצרוך משאבים מוגזמים, להגיע למגבלות של פעולות בו-זמניות או של הרחבה, ולגרום לעלויות משמעותיות. בסופו של דבר, השירות לא יהיה זמין למשתמשים לגיטימיים.

קטגוריית STRIDE	התקפת מניעת שירות
טקטיקה של MITRE ATT&CK	השפעה
Manifestations	מיצוי משאבים: תוקף מעלה 10,000 קבצים קטנים, מה שגורם להפעלות מקבילות של 10,000 פונקציות Cloud Run שממצות את מכסת המעבד (CPU), הזיכרון או מגבלות הקצב של ה-API במורד הזרם של הפרויקט. התקפת DoS שמבוססת על עלות: ה-fan-out גורם להפעלה של מספר עצום של הרצות בשירות בתשלום, מה שמוביל לחשבון גדול מאוד ולהשעיה של חשבון פוטנציאלית, ובפועל מונע את השימוש בשירות.
אמצעי צמצום סיכונים	הטמעת אמצעי בקרת גישה חזקים בקטגוריות של Cloud Storage שמפעילות תהליכי עבודה. מומלץ להשתמש בעיקרון של הרשאות מינימליות כשמעניקים גישת כתיבה לקטגוריות האלה, ולבצע ביקורת באופן קבוע באמצעות כלים כמו כלי הניתוח למדיניות. הגדרת מגבלות על מספר ההפעלות בו-זמנית בפונקציות Cloud Run מבוססות-אירועים כדי לשלוט במספר המקסימלי של ההפעלות המקבילות, וכך למנוע ניצול יתר של משאבים. מטמיעים מנגנון לביטול כפילויות, שקורא ללוגיקה הראשית של העיבוד. דוגמה למנגנון לביטול כפילויות היא הוספת משימה לתור של Cloud Tasks עם הגבלות קצב. המנגנון הזה עוזר לנהל עליות פתאומיות בנפח הבקשות על ידי פיזורן לאורך זמן. מגדירים גבולות גזרה של VPC Service Controls כדי להגביל את הגישה למשאבים רגישים, כמו כתיבה ל-bucket שמפעילה תהליך עבודה, מחוץ לגבולות הגזרה המהימנים.

תנועת נתונים לא מורשית באמצעות צינורות גיבוי שמגובים על ידי Cloud Storage

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

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

עקיפת מדיניות באמצעות שימוש ברשימות ACL מדור קודם של Cloud Storage בסביבות היברידיות

‫Cloud Storage תומך בשתי מערכות של בקרת גישה שאינן תלויות זו בזו: IAM ורשימות ACL מדור קודם. כשגישה אחידה ברמת הקטגוריה מושבתת, מתבצעת הערכה של שתי המערכות. האקר יכול לנצל את ההגדרה הזו על ידי הוספת רשימת ACL מדור קודם (לדוגמה, הענקת גישה לחשבון Google אישי או לקבוצה ציבורית) לאובייקט, גם אם מדיניות ההרשאות ברמת הקטגוריה נראית מגבילה. המתקפה הזו יוצרת נתיב גישה נסתר שלרוב לא מזוהה על ידי סורקי אבטחה שמתמקדים ב-IAM, וכך התוקף יכול לעקוף את מדיניות האבטחה המיועדת.

קטגוריית STRIDE	העלאת רמת ההרשאה
טקטיקה של MITRE ATT&CK	Defense Evasion
Manifestations	גישה ציבורית ברמת האובייקט: תוקף עם ההרשאה storage.objects.update מוסיף רשימת ACL עם הרשאת קריאה ציבורית לאובייקט רגיש, וכך מאפשר לכל אחד באינטרנט לגשת אליו, תוך עקיפת מדיניות ההרשאות המגבילה של הקטגוריה. גישה בין חשבונות: תוקף מקצה לחשבון החיצוני שלו את ההרשאה OWNER באובייקט קריטי של הגדרה באמצעות ACL, וכך מאפשר לו לשנות את האובייקט בלי שביקורות IAM יזהו את השינוי.
אמצעי צמצום סיכונים	הפעלת גישה אחידה ברמת הקטגוריה בכל הקטגוריות של Cloud Storage. הגישה האחידה ברמת הקטגוריה משביתה את כל רשימות ה-ACL ומבטיחה ש-IAM יהיה השיטה היחידה והעקבית לניהול הגישה, וכך מפשטת את הביקורות ומונעת את העקיפה הזו. משתמשים באילוץ מדיניות הארגון constraints/storage.uniformBucketLevelAccess כדי לאכוף גישה אחידה ברמת הקטגוריה בכל הקטגוריות החדשות בפרויקט, בתיקייה או בארגון.

השמדת נתונים באמצעות צינורות CI/CD שנפרצו ומכוונים ל-Cloud Storage

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

קטגוריית STRIDE	שיבוש
טקטיקה של MITRE ATT&CK	השפעה
Manifestations	שלב בנייה זדוני: תוקף מוסיף שלב לצינור CI/CD שמנקה את כל הנתונים. לדוגמה, התוקף מוסיף שלב ב-cloudbuild.yaml שמריץ פקודה כמו gcloud storage rm -r gs://critical-bucket/. העברת הרשאות: התוקף משתמש בחשבון השירות של צינור עיבוד הנתונים שנפרץ, שיש לו הרשאות רחבות, כדי להעניק לחשבון שלו גישת אדמין למאגרי Cloud Storage לשימוש מאוחר יותר.
אמצעי צמצום סיכונים	החלת העיקרון של הרשאות מינימליות על חשבונות שירות של CI/CD. לדוגמה, אל תקצו הרשאות למחיקת קטגוריות ייצור לצינורות עיבוד נתונים של בנייה. משתמשים בזהויות נפרדות לשלבים שונים של צינור עיבוד הנתונים, כמו בנייה, בדיקה או פריסה. כדי להגן על קטגוריות קריטיות ב-Cloud Storage מפני מחיקה, אפשר להפעיל נעילת קטגוריות או נעילת אובייקטים, או לוודא שלחשבון השירות של CI/CD אין את ההרשאה storage.buckets.delete.

מחיקת דלי לא מורשית באמצעות חשבונות break-glass עם הרשאות גבוהות מדי

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

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

זליגת מידע שקטה באמצעות יעד של יומן שנפרץ וכותב ל-Cloud Storage

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

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

הפעלת תוכנת כופר באמצעות ביטול מרכזי של CMEK

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

קטגוריית STRIDE	שיבוש
טקטיקה של MITRE ATT&CK	השפעה
Manifestations	השמדת מפתח: תוקף עם הרשאה cloudkms.cryptoKeyVersions.destroy יכול להשמיד גרסת מפתח באופן סופי, כך שאי אפשר יהיה לשחזר את הנתונים. השבתת מפתח: תוקף עם הרשאה cloudkms.cryptoKeyVersions.disable משבית מפתח, וכך הנתונים ב-Cloud Storage לא ניתנים לקריאה עד שהמפתח מופעל מחדש. הפעולה הזו עלולה לגרום להשבתה ממושכת.
אמצעי צמצום סיכונים	אפשר לאכוף משך זמן מינימלי למצב 'מתוזמן להשמדה' לפני שמפתחות Cloud KMS מושמדים. כברירת מחדל, התקופה הזו היא 30 יום, אבל אפשר להגדיר תקופה של יום אחד עד 120 יום בזמן שיוצרים את המפתח בפעם הראשונה. אי אפשר לשנות את התקופה הזו אחרי שמפתח נמחק. כדאי לאכוף את האילוץ constraints/cloudkms.minimumDestroyScheduledDuration של מדיניות הארגון כדי לוודא שלא ניתן ליצור מפתחות עם תקופה מתוכננת להשמדה שקטנה מהמינימום הצפוי. הגבילו באופן משמעותי את הגישה לתפקידי אדמין ב-Cloud KMS. כדי למנוע מצב שבו חשבון שנפרץ יכול גם להשתמש במפתחות וגם להרוס אותם, צריך להפריד בין התפקידים של שימוש במפתחות לבין ניהול מפתחות. החלפת מפתחות של Cloud KMS באופן תקופתי, בחירת תקופת החלפה על סמך רגישות או דרישות התאימות של עומס העבודה.

העברת נתונים לא מורשית באמצעות ייצוא של קובץ snapshot או גיבוי ל-Cloud Storage

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

קטגוריית STRIDE	גילוי נאות
טקטיקה של MITRE ATT&CK	זליגת נתונים
Manifestations	קובץ snapshot של דיסק לקטגוריה ציבורית: מפתח פנימי עם הרשאות compute.snapshots.create ו-storage.objectAdmin יוצר קובץ snapshot של דיסק של מכונה וירטואלית שמכיל סודות ומייצא אותו לקטגוריה ציבורית ב-Cloud Storage. ייצוא מסד נתונים: תוקף עם הרשאה cloudsql.instances.export מייצא מסד נתונים של ייצור לקטגוריה של Cloud Storage בפרויקט שנשלט על ידי התוקף.
אמצעי צמצום סיכונים	כדי לשמור על רמת אבטחה עקבית, חשוב לוודא שלפרויקטים שמיועדים לגיבויים ולתמונות מצב יש מדיניות IAM ו-VPC Service Controls שהיא לפחות מחמירה כמו המדיניות של פרויקטי המקור. כדאי לשקול אסטרטגיה של סיווג נתונים שבה מגדירים תגי משאבים בקטגוריות שמשמשות לגיבויים, ומוסיפים תנאי גישה מבוססי-תגים של IAM כדי להגביל עוד יותר את הגישה.