תקיפות ענן - Cloud Attacks מוסבר

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

למה תקיפת ענן שונה מתקיפת רשת מסורתית

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

שירותי אחסון פתוחים מדי

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

הרשאות IAM ותקיפת הסלמה

בדיוק כמו הרשאות ACL בעולם ה-Active Directory, גם בענן ניהול ההרשאות (IAM - Identity and Access Management) הוא הלב האמיתי של האבטחה. משתמש או שירות עם הרשאה שנראית מוגבלת - למשל היכולת ליצור תפקיד (role) חדש, או לצרף מדיניות הרשאה לחשבון קיים - יכול לפעמים לנצל את זה כדי להעניק לעצמו הרשאות הרבה יותר רחבות ממה שהתכוונו לתת לו במקור. בדיוק כמו ב-Active Directory, שרשראות הרשאה כאלה קשה למפות ידנית, ולכן קיימים כלים ייעודיים שסורקים את מבנה ה-IAM של סביבת ענן ומאתרים נתיבי הסלמה אפשריים.

ניצול שירות המטא-דאטה

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

תקיפת שירותים ללא שרת ותצורות מיוחדות

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

איך בודקים תקיפות ענן בפועל

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

איך מתגוננים

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

איך לומדים את זה נכון

תקיפת ענן הפכה לתחום הכרחי בכל בדיקת חדירות מודרנית, לצד רשתות ו-Active Directory. מי שרוצה להתמקצע במסלול הזה יכול להתחיל מקורס בדיקות החדירות שלנו.

לסיכום

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

יש לכם שאלות על אבטחת ענן ומודלי הרשאות? בואו לקהילה שלנו.

הצטרפו לקהילה בדיסקורד