אי שם בעבר, הגנת המידע הייתה פשוטה בהרבה. כיום, כשפיסות קוד משותפות משמשות גורמים רבים, כשהארכיטקטורה הארגונית מבוססת בצורה משמעותית על פלטפורמות ומערכות SaaS וכשמחיר החזרה לשולחן השרטוטים בשלב מאוחר הוא כבד - סוגיית אבטחת המידע דורשת ידע ותפיסה חדשה. במסגרת פרדיגמת ה-Shift left, המשקל עובר מהגנה על מה שכבר אופיין ופותח, לשילוב אבטחת המידע של המוצרים והמערכות כבר בשלבי התכנון המוקדמים - Security by design. קל וחומר כשמדובר בטכנולוגיות ענן.
"הגבולות בין הדיסציפלינות השונות - אבטחת המידע, פיתוח ותשתיות - מיטשטשים בענן", אומר אלכס שרמן, מוביל צוות הענן במרכז הסייבר של Deloitte. "בענן פיתוח הקוד משולב בהרבה מקרים עם הגדרות התשתית שעליה רצים השירותים, והתשתית עצמה מוקמת כקוד תוכנה (Infrastructure As Code)". טשטוש הגבולות משפיע על כלל היבטי העבודה, ולמעשה כיום נדרשים אנשי המקצוע להיכרות מעמיקה עם כל אחד מהתחומים המשיקים כדי לדבר את אותה השפה. "לא מספיק להיות מומחה בתחום צר אחד", מסביר שרמן. "נכון, אי אפשר להיות מומחה עומק בתחומים רבים היות ולכל אחד יש התמחות עיקרית משלו, אבל כולם חייבים הבנה בסיסית על מנת שיוכלו לתקשר זה עם זה בצורה יעילה ומובנת".
איך מתחלקת האחריות בין הארגון לענן?
ישנה הנחה שגויה שהמעבר לענן מבטיח הגנה אוטומטית. "ארגון לא בטוח באופן מלא מעצם המעבר לענן", מדגיש מיכאל שטרית, מנג'ר במרכז הסייבר של Deloitte. "נכון שכלי האבטחה בענן נגישים להטמעה ולשימוש מיידי בלחיצת כפתור, ונכון גם שזה לב העשייה של ספקיות הענן הגדולות (אמזון, גוגל ומייקרוסופט) – והן משקיעות בזה יותר מכל ארגון ממוצע, אבל הצרכנים חייבים להכיר היטב את הכלים והבקרות וממש כמו בסביבות מקומיות, להפעיל אותם באופן יזום ולבצע הגדרות על פי דרישות הארגון וצרכיו".
שטרית מזכיר את מודל האחריות המשותפת - Shared Responsibility Model - המוסכם בין ספקיות הענן לבין החברות והארגונים המגדיר מי אחראי על מה. "הספקיות אחראיות על התשתיות הפיזיות והלוגיות, על ה-Physical security, ובשירות מנוהל גם על הפלטפורמות. אבל גם במודל Software/Infrastructure/Platform as-a-Service (SaaS, IaaS, PaaS), האחריות על הגישה למערכות, על אבטחת המידע של הארגון וניהול הזהויות - למי מותר לגשת לאן ומה מותר לו לעשות - מוטלת על החברה. הצפנת המידע היא בוודאי באחריותה ולפי שיקול דעתה - האם להשתמש במַפתח שמגיע עם הכלי, במפתח שלה שהיא מנהלת בענן, או - וזו הפרקטיקה המומלצת לתפיסתי - במפתח שמנוהל מהסביבה המקומית שלה? כל אפשרות כזאת פירושה רמה אחרת של אבטחה".
הנה כמה טעויות נפוצות:
1. הגדרות שגויות (Misconfiguration) - למשל, כשמאחסנים מידע בבאקטים (Buckets) בשירותי הענן, סימון לא נכון במסכי ההגדרה עלול להפוך את המידע כולו לחשוף. כך למשל ב-2017 נחשף מידע מסווג של משרד ההגנה האמריקאי (אירוע Booz Allen Hamilton). ב-2022 נחשפו באירוע אחר למעלה מ-3 טרהבייט של מידע (כ-1.5 מיליון קבצים) שהכילו מדע פרטי ומידע רגיש נוסף משדות תעופה בפרו וקולומביה רק מעצם הגדרה לא נכונה של הגישה למידע המאוחסן בענן. כדי למנוע מצב כזה רצוי לבצע בתדירות גבוהה מעבר על הגדרות אבטחת המידע ובדיקת הבקרות, לבצע בדיקת חדירות - Penetration testing - ולסרוק בעקביות את העננים והרשת. כמו כן יש לוודא שלא מסתמכים רק על הגדרות ברירת המחדל, אלא מבצעים הגדרות מותאמות למדיניות אבטחת המידע הארגונית.
2. היעדר בקרות פיננסיות - נושא זה נוגע בעיקר לפן הניהולי והפיננסי, כלומר ל-FinOps, אבל יש גם השלכות ישירות לנושא אבטחת הענן. חשוב לזכור כי מרבית השירותים בענן עולים כסף, וכמעט כל משתמש עם הרשאות בארגון או בתמיכת ה-IT יכול להפעיל כל שירות בכמה קליקים, כך שהפעלת שירות ללא בקרות מתאימות יכולה להסתיים בעלויות משמעותיות לארגון תוך זמן קצר מאוד. למשל, הקמה של שרת "לבדיקה בלבד" והשארתו פעיל בסיום הבדיקה, יכולה להסתיים בהוצאה של מאות עד אלפי דולרים ליום תלוי בגודל השרת, וזו רק דוגמה קטנה.
3. ספריות קוד פתוח - ספריות קוד מצריכות רמת ניהול גבוהה וקפדנית, מודעוּת ובדיקה מוקדמת מצד המפתחים. רבות מהן כוללות חולשות מובנות העוברות בירושה, כמו באירוע Log4j. באחת האפליקציות שבדק מרכז הסייבר התגלו 120 ספריות ומספר גדול בהרבה של ממצאים. זה לא כי המפתחים לא יודעים לעבוד – מדובר באנשי מקצוע מהשורה הראשונה - אבל הם ערכו שימוש בספריות לא מאובטחות או בעלות חולשות אבטחה, כאשר חלק מהחולשות הגיעו מספריות צד שלישי לאורך שרשרת האספקה. דבר זה נובע בעיקר בגלל חוסר מודעות וחוסר הדרכה מספקת של אנשי הפיתוח בנושאי אבטחת מידע ופיתוח מאובטח. לעיתים התיקון הוא שימוש בגרסה עדכנית יותר, לעיתים ניתן להפעיל בקרות מפצות, ויש מקרים שבהם ההמלצה תהיה להימנע מספריה עקב חולשה קריטית שטרם נמצא לה תיקון.
צוות אדום, Assume Breach, ענן מאובטח ומה שביניהם
אז איך ארגון נערך ל"יום פקודה" שבו התשתיות הטכנולוגיות שלו יותקפו בלוחמת סייבר? מספר טיפים בסיסיים וקריטיים שמונים שטרית ושרמן:
מיפוי החוזקות והחולשות באמצעות סימולציה - אחד השרותים של מרכז הסייבר של Deloitte כולל [HM1] "צוותים אדומים" שלומדים את הלקוח ואת משטחי התקיפה, מדמים חשיבה של גורם זדוני ומנסים להגיע בכל דרך לנכסי המידע. זה כולל מניפולציות, פישינג ממוקד, Social engineering (למשל: להתקשר לתמיכה או ל-HR ולבקש לאפס סיסמה ש"נשכחה") ואמצעים נוספים.
Assume Breach - כדאי גם לדמות תרחישים שבהם הארגון מתנהל בהנחה שהוא נמצא באופן קבוע תחת תקיפה של גורם זדוני. בתהליך כזה בוחנים את הטכנולוגיות והתהליכים האירגוניים כדי להבין מה יכול למנוע מתוקף להעלות את רמת ההרשאות שלו ולהשיג עוד ועוד הרשאות חזקות יותר או לגשת באופן רוחבי למערכות אחרות בארגון, לאסוף מידע או לגרום להן נזק.
סריקת ענן – בפרקי זמן מוגדרים מראש, חשוב לסרוק את חשבון הענן של הלקוח מקצה לקצה בשילוב כלים אוטומטיים וידניים. עם סיום הסריקה, נכתב דו"ח מפורט עם כלל הכשלים והממצאים שזוהו, כולל היבטים רגולטוריים.
שרמן מסכם: "הענן לא מצמצם את הצורך באבטחת מידע אלא מגביר אותו, וזו לא חובתו ואחריותו של צוות אבטחת המידע בלבד - כל מי שנוגע במערכת חייב להיות מודע לדגשים וההשלכות של אבטחת המידע ולנהוג בהתאם". שטרית: "פעם היית כותב אפליקציה, מתקין אותה על שרת או מספר שרתים ויודע היטב מה הם עושים, איך הם נראים ומי מטפל בהם. היום הגבולות מטושטשים, עם אוסף של שירותים וקטעי קוד שרצים להם אי שם. יכול להיות שההזדהות והאימות יושבים כ-SaaS ב-Azure של מיקרוסופט כשהאימות עצמו מגיע מספק שירותים של גוגל, כשהאפליקציה יושבת בכלל ב-AWS, מותקנת על גבי קונטיינרים עם microservices וקוד שרצים בצורה מבוזרת כלשהי, חלקם כשירות מנוהל וחלקם מנוהלים בארגון, וכל זה מחובר בסדרה של ממשקי APIs. הסיכונים נמצאים בכל מרכיב ומרכיב, והאתגר רק מתעצם".
'מעוניינים לשמוע עוד מהמומחים שלנו? לחצו כאן