בעולם הענן, ארגונים כמעט אף פעם לא עובדים לבד. כלי ניטור, פלטפורמות נתונים, שירותי גיבוי ומוצרי אבטחה צריכים גישה לחשבון הענן של הלקוח כדי לעשות את העבודה שלהם. הדרך המקובלת לתת להם את הגישה הזאת ב-AWS נקראת Cross-Account Role, תפקיד חוצה חשבונות: הלקוח מגדיר בחשבון שלו תפקיד עם הרשאות מסוימות, וקובע ש"חשבון ה-AWS של הספק רשאי להשתמש בתפקיד הזה".
היתרון ברור: הלקוח לא צריך למסור לספק סיסמאות או מפתחות קבועים, והוא יכול לבטל את הגישה בכל רגע. זו דרך בטוחה יותר מהחלופות, וספקיות הענן ממליצות עליה. אבל יש לה נקודת תורפה מובנית: הביטחון של הלקוח תלוי בביטחון של הספק. מי שמשיג גישה לחשבון של הספק, יכול לנצל את כל התפקידים שכל הלקוחות הגדירו עבורו, בבת אחת.
זה בדיוק מה שקרה במתקפה דרך Qubole, שנחשפה השבוע על ידי Wiz ו-Sentra: תוקף השתמש בפרטי גישה של חשבון שקשור לספק, ונכנס לחשבונות של לקוחות רבים. ויש בעיה נוספת: תפקידים כאלה נשארים בחשבון גם אחרי שהארגון הפסיק לעבוד עם הספק, אלא אם מישהו זכר למחוק אותם. בארגונים גדולים יש לפעמים עשרות תפקידים כאלה, של ספקים שאף אחד כבר לא זוכר.
איך מצמצמים את הסיכון? ראשית, מלאי: לדעת אילו תפקידים קיימים, לאיזה ספק כל אחד שייך, ומתי השתמשו בו לאחרונה. ספקיות הענן מציגות את המידע הזה, וכלי אבטחת ענן עושים את זה אוטומטית. שנית, הרשאות מינימליות: ספק שצריך לקרוא נתונים מתיקייה אחת לא צריך גישה לכל האחסון. שלישית, צמצום האמון: במקום לתת אמון לחשבון של הספק כולו, לתת אמון רק לזהות הספציפית שהוא משתמש בה, ולהוסיף מזהה ייחודי (External ID) כשהספק תומך בזה.
והכלל החשוב מכולם: ניהול גישה של ספקים הוא תהליך, לא הגדרה חד-פעמית. כמו שמשביתים כרטיס כניסה של עובד שעוזב, כך צריך למחוק את הגישה של ספק שהחוזה איתו הסתיים. במתקפות של השבוע, השכחה הזאת הייתה הפרצה.
