על 3 טעויות סייבר נפוצות בזמן שימוש בענן

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

אזהרת אקסיומה שגויה: "המעבר לענן מבטיח לארגון הגנה אוטומטית". לא נכון. הענן מנגיש כלי אבטחה שזמינים בלחיצת כפתור, אבל הלקוחות חייבים ללמוד על בוריים את הכלים והבקרות שהעננים השונים מספקים ולהתאים אותם לצרכים הארגוניים. רגע, אתם שואלים? על מי האחריות נופלת במעבר לענן – על הארגון או על ספקית הענן? התשובה, כמו תמיד, נמצאת באמצע: Shared Responsibility Model (או 'מודל האחריות המשותפת'), שמגדיר במסגרת ההתקשרות בין הארגון לבין ספקית הענן את גבולות האחריות, או 'מי אחראי על מה?'. אבל גם במודל הזה, האחריות על אבטחת המידע של הארגון על שלל היבטיה – מוטלת על החברה. 

בואו נדבר על מספר מושגי סייבר שכיחים שחברות עושות במעבר לענן:

1. מיס-קונפיגורציה – ובלשון העם – "הגדרות שגויות". לדוגמא: כשמאחסנים מידע ב'באקטים' (Buckets) בשירותי הענן, סימון שגוי במסכי ההגדרה עלול לחשוף בטעות את כל המידע הארגוני. ולא חסרות דוגמאות למקרים כאלו – חשיפת מידע מסווג של משרד ההגנה האמריקני (2017), אירוע דומה של חשיפת מידע רגיל מנמלי תעופה בפרו וקולומביה (2022), והרשימה נמשכת. מה עושים בכדי למנוע מצב כזה? סקירה ומעקב של מערכות האבטחה בתדירות גבוהה, הכוללת בדיקת חדירות - Penetration testing, ולהזהר מלהסתמך רק על הגדרות ברירת המחדל. 

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

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

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

מיפוי החוזקות והחולשות באמצעות סימולציה – ממפים את הארגון ואת משטחי התקיפה הפוטנציאליים,  מדמים חשיבה של גורם זדוני ומביימים תקיפה. מה תקיפה כזו עשויה לכלול? מניפולציות, דיוג ("פישינג") Social engineering (למשל: להתקשר לתמיכה או ל-HR ולבקש לאפס סיסמה ש"נשכחה") ואמצעים נוספים. כדאי גם לסמלץ תרחישים שבהם הארגון מתנהל בהנחה שהוא נמצא באופן קבוע תחת תקיפה של גורם זדוני. 

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

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