סביבות ענן לא הופכות לפחות מאובטחות בן־לילה – הן פשוט נסחפות לשם

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

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

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

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

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

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

 

מיתוס #1: אם סביבת הענן מאובטחת היום – היא תישאר מאובטחת גם מחר

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

הבעיה היא שסביבות ענן אינן עומדות במקום.

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

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

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

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

מיתוס #2: הזהויות החשובות ביותר הן של המשתמשים

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

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

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

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

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

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

 

מיתוס #3: מתקפות ענן מתחילות מניצול חולשות

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

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

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

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

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

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

מיתוס #4: אתם באמת מכירים את סביבת הענן שלכם

אולי האתגר הגדול ביותר בסביבות ענן בוגרות אינו קונפיגורציה שגויה.

אלא חוסר ודאות.

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

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

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

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

 

מחשבות לסיום

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

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

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

כי סביבות ענן כמעט אף פעם לא הופכות לפחות מאובטחות בן־לילה.

הן פשוט נסחפות לשם.