אנו קוראים בתקופה האחרונה לא מעט פרסומים אודות מתקפת SolarWinds, חולשת אבטחה במוצר ניטור פופולרי בקרב ארגונים רבים ברחבי העולם.
מדובר בדוגמה קלאסית של מתקפה על שרשרת האספקה, אשר עשויה לפגוע בכל ארגון.
ראינו מקרים דומים במהלך העשור שחלף, דוגמת החולשה ב-OpenSSL (Heartbleed bug), החולשה במעבדי Intel ו-AMD (Meltdown ו-Spectre), החולשה בשרתי Apache Struts ועוד.
ארגונים בכל העולם נפגעו ממתקפת SolarWinds, לרבות חברת הסייבר FireEye וחברת התוכנה Microsoft.
אירועים מעין אלו גורמים לארגונים "לחשב מסלול מחדש" בכל הנוגע לאסטרטגיית האבטחה וההגנה על המידע.
שינויים מהתקופה האחרונה בחוקי הגנת הפרטיות האירופאיים (דוגמת Schrems II), מנסים לצמצם את נושא שינוע מידע בין אירופה לארה"ב.
האם אירועים מעין אלו אמורים לקרות? לחלוטין לא
האם עלינו לקבל את העובדה שארגונים גדולים בכל העולם נפרצים? לחלוטין לא!
האם ארגונים אשר השקיעו משאבים רבים בהגירה לענן, אמורים עכשיו לחזור לסביבות ה-on premise? אני חושב שלא.
לשום ארגון, גם לא לארגונים פיננסיים גדולים (דוגמת בנקים וחברות ביטוח), או אפילו לארגוני ה-enterprise הגדולים בעולם, אין מספיק משאבי כוח אדם, ידע ותקציב על-מנת להשקיע בהגנה מספיק טובה על המידע שלהם ושל הלקוחות שלהם, בהשוואה לספקי הענן הציבורי המובילים בעולם.
יש לכך מספר סיבות:
- ספקי הענן הציבורי המובילים בעולם משקיעים מיליארדי דולרים בבקרות אבטחת מידע, לרבות השקעה בכוח אדם מנוסה ומיומן.
- פריצה וחשיפת נתוני לקוחות המאוחסנים אצל ספקי הענן הציבורי עשויה לגרום לספקי הענן לפשוט רגל, בשל הפגיעה באמון הלקוחות.
- אבטחת מידע חשובה למרבית הארגונים, אך תחום זה אינו תחום העיסוק של מרבית הארגונים.
ארגונים אמורים להשקיע במה שמביא להם ערך (דוגמת תעשייה, בנקאות, רפואה, חינוך ועוד), ועליהם לבחון מחדש אילו שירותים נועדו לתמוך במטרות הארגוניות (דוגמת שירותי תשתיות), אך לא מביאים לארגון ערך מוסף בצורה ישירה.
המלצות לניהול היבטי אבטחה
ניטור אירועי אבטחה
אחד העקרונות בעולם האבטחה אומר "תעד הכול".
קיימים 2 חסרונות לעקרון זה – נפח האחסון בסביבות ה-on premise תמיד מוגבל וכן למרבית הארגונים אין מספיק כוח אדם מנוסה על-מנת לעבור על קבצי התיעוד (logs) על-מנת לאתר את אירועי האבטחה (incidents) המשמעותיים, המחייבים טיפול מידי.
המעבר לניטור אירועי אבטחת מידע במערכות מבוססת ענן, דוגמת Azure Sentinel או Amazon GuardDuty, יסייע לזהות אירועי אבטחה מהותיים לצורך טיפול מידי, מתוך כמויות אדירות של שורות לוג.
הצפנה
עקרון נוסף בעולם האבטחה אומר "הצפן הכל".
עד לפני מספר שנים, הצפנה היוותה אתגר – האם השירות/יישום יתמוך בהצפנת נתונים בעת אחסון? היכן נאחסן את מפתחות ההצפנה? כיצד נבצע החלפת מפתחות הצפנה (key rotation)? ועוד
בעבר, בעיקר בנקים יכלו להרשות לעצמם לרכוש רכיב HSM (Hardware security module) לצורך אחסון מפתחות ההצפנה, בשל עלות הרכישה הגבוהה.
כיום, הצפנה בעת אחסון הפכה ליכולת סטנדרטית אצל מרבית ספקי הענן, עם שירותים דוגמת AWS KMS, Azure Key Vault, Google Cloud KMS ו-Oracle Key Management.
מרבית ספקי הענן הציבורי תומכים לא רק בהצפנת נתונים בעת אחסון, אלא גם בשימוש במפתח הצפנה של הלקוח (Customer managed key), יכולת המאפשרת ללקוח לחולל מפתח הצפנה בעצמו, במקום להשתמש במפתח ברירת המחדל אשר נוצר בחשבון הלקוח ע"י ספק הענן.
תאימות לסטנדרטים (Security compliance)
מרבית הארגונים נאבקים לשמור על תאימות לסטנדרטים של אבטחת מידע בסביבות on premise גדולות, שלא לדבר על סביבות IaaS גדולות.
הנושא עשוי להיות מטופל באמצעות שימוש בשירותי compliance מנוהלים דוגמת AWS Security Hub, Azure Security Center, Google Security Command Center או Oracle Cloud Access Security Broker (CASB).
הגנה מפני מתקפות מניעת שירות (DDoS protection)
כל ארגון אשר חושף שירותים לגישה מכיוון האינטרנט (החל מאתרי Web פומביים, דרך שירות דואר אלקטרוני ושירותי DNS ועד שירותי VPN), יסבול בשלב כלשהו ממתקפת מניעת שירות אשר תסתום את רוחב הפס בגישה מכיוון האינטרנט לכיוון הארגון.
רק לספקיות האינטרנט הגדולות יש רוחב פס המסוגל להתמודד עם מתקפות לפני שרכיבים ב-border gateway (דוגמת Firewall, נתב חיצוני וכו') יקרסו או יפסיקו להעביר תעבורת תקשורת לתוך הארגון.
לספקי הענן הציבורי המובילים יש תשתית המסוגלת להתמודד עם מתקפות DDoS כלפי לקוחותיהם, באמצעות שירותים דוגמת AWS Shield, Azure DDoS Protection, Google Cloud Armor או Oracle Layer 7 DDoS Mitigation.
שימוש ביישומי SaaS
בעבר, ארגונים היו אחראיים על תחזוקת התשתית שלהם, ממערכות דואר אלקטרוני, דרך יישומי CRM, ERP ועוד.
היה עליהם לחשוב מראש על נושאים דוגמת scale, שרידות, היבטי אבטחה ועוד.
מרבית הפריצות לסביבות מבוססות ענן ציבורי נובעות מהגדרה שגויה (misconfiguration) בצד הלקוח, בסביבות IaaS / PaaS.
כיום, הדרך המועדפת על ארגונים הינה צריכת שירותים מנוהלים בתצורת SaaS.
להלן מספר דוגמאות לשירותים מנוהלים: Microsoft Office 365, Google Workspace, Salesforce Sales Cloud, Oracle ERP Cloud, SAP HANA ועוד.
צמצום שטח הפגיעה (Blast radius)
על-מנת לצמצם את שטח הפגיעה (“Blast radius”) כאשר שירות אחד סובל מבעיית זמינות או נפרץ ומשפיע על שירותים אחרים, עלינו לבנות מחדש (re-architect) את התשתית בה אנו משתמשים.
שינוי מיישומים המותקנים על גבי שרתים וירטואליים לפיתוחים מודרניים ושימוש בארכיטקטורת microservices, המבוססת על containers או בניית יישומים חדשים המבוססים על ארכיטקטורת serverless (או function as a service), תסייע לארגונים לצמצם את שטח הפגיעה (attack surface) ופריצות עתידיות לרשת הארגון באמצעות חולשות ברמת האפליקציות.
להלן מספר דוגמאות לשירותים בארכיטקטורות מודרניות: Amazon ECS, Amazon EKS, Azure Kubernetes Service, Google Kubernetes Engine, Google Anthos, Oracle Container Engine for Kubernetes, AWS Lambda, Azure Functions, Google Cloud Functions, Google Cloud Run, Oracle Cloud Functions ועוד.
סיכום
השורה התחתונה של מאמר זה – ארגונים יכולים להעלות את רמת האבטחה, ע"י שימוש בשירותי ענן ציבורי, על-מנת להגן בצורה טובה יותר על הנתונים שלהם, לנצל את המומחיות של ספקי הענן ולהשקיע במה שמביא לארגונים ערך מוסף.
פריצות אבטחת מידע הינן בלתי נמנעות – הגירה לענן ציבורי לא מסירה את האחריות של ארגונים על הגנה על נתוני הארגון, אלא רק מאפשרת ליישם בקרות אבטחת מידע בצורה טובה יותר.