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

אבטחה בענן – מה צריך לצפות מהספק ומה צריך להשלים בכלים חיצוניים
מאת: משה פרבר, 20.7.13, 21:00
 
תהליך נכון של מעבר לענן כולל בדיקה של התחומים בהם הארגון מאבד שליטה על המידע ובדיקת מחירו של כלי "ענני" לבקרה מונעת או מפצה על השליטה שאבדה. תהליכים אלה יכולים לסייע למנהל האבטחה להפוך מגורם "מעכב"  לגורם "מאפשר".
 
עולם "מחשוב הענן" הגיע לבשלות מסוימת מבחינת אבטחת מידע. ניתן כיום להתוות מהי חלוקת האחריות בין הלקוח והספק בצורה טובה ביותר, ולאילו כלים ויכולות אפשר לצפות מספקי הענן השונים.
 
להלן יפורט עבור כל אחד ממודלי השירות (IaaS, PaaS, SaaS), מה ניתן לצפות מהספק בנושאי אבטחת מידע ומה יש להשלים בכלים חיצוניים.
 
חלוקת האחריות משתנה בין הלקוח לספק בהתאם למודל השירות. מספק IaaS יש לצפות לאחריות תשתית התקשורת, האחסון ומערכת הווירטואליזציה בלבד, והאחריות על אבטחת מערכות ההפעלה והאפליקציות תישאר בידי הלקוח עצמו. זאת, לעומת סביבות SaaS, שבהן אחריות הספק היא מרמת התשתיות ועד האפליקציה עצמה.  הטבלה הבאה מתארת את האחריות על הבקרות השונות בהתאם למודל השירות:

Figure 1: Taken from PCI DSS Cloud Guidelines
 
מה ניתן לצפות מהספק בתחומים שבאחריותו?
כאשר עוסקים בתשתית כשירות - IaaS, הלקוח נדרש להתקין טלאים, לבצע הקשחות ולנהל מערכות אנטי-וירוס כמו בסביבה הפנימית המוכרת שלו. אולם, יש מספר שינויים המאפיינים סביבות IaaS: לרוב מקבלים רשת שטוחה ללא היררכיה וללא יכולת לניהול כתובות עצמאי של כתובות IP פנימיות וחיצוניות, ולרוב אפשרויות הפיירוול הן מוגבלות, ומערכות מבוססות רשת, שרגילים אליהן כגון IPS, WAF ו-,DLP לא תהיינה קיימות (לפחות לא בתצורה המוכרת ברשת הפנימית). לעומת זאת, כן מתקבלת מרוב הספקים יכולת להפריד את השרתים ל- Security groups בהתאם לתפקידם וסיווגם, יכולות חוקי פיירוול בסיסיות (שכבה 4 בד"כ) ויכולות VPN בסיסיות (בד"כ gateway 2 gateway).
 
מאפיינים אלה גורמים לכך, שבמערכות תשתית כשירות, מקובל יותר להטמיע מערכות אבטחת מידע ברמת השרת (Host) ולא ברמת הרשת, ובהתאם, גדל ההיצע למערכות אבטחה חדשות, שיודעות לבצע ברמת השרת משימות, שבד"כ בוצעו כשירות רשתי. למערכות אלו צריכות להיות תכונות חשובות לענן, כגון יכולת ניהול לרוחב של כמה ספקים שונים ויכולת לשנות את המדיניות בהתאם למיקומו של השרת.
 
 
דברים נוספים, שאפשר לצפות מספק הענן, כוללים מפתחות הצפנה לצורך תקשורת מאובטחת עם השרתים, Access keys עבור ה-API השונים (בד"כ Rest API), וגישה לממשק ניהול עם הרשאות גישה שונות בהתאם לתפקידים. אוסף המפתחות וה-Credentials השונים מחייבים התייחסות מיוחדת מצד מנהל אבטחת המידע. עם העלייה בכמות המשתמשים, יהיו יותר ויותר מפתחות הצפנה שונים לנהל עבור השרתים, וידרשו כלים ומתודולוגיות לניהול נכון של אוסף נתוני הגישה.
 

  Figure 2: Taken from CSA guidelines
 
בעולם ה- Platform as a Service הדברים פשוטים יותר, אך מחייבים תשומת לב ודגש על פרטים מסוימים. כאשר מפתחים אפליקציה על גבי PaaS, יש לזכור, כי כל נושאי אבטחת הרשת, תחזוקת מערכות ההפעלה ושכבת הפיתוח הם לא באחריות הלקוח, ועל כן, עליו להרחיב בבקרות ברמת האפליקציה המפותחת. נושאים כגון ביצוע logging, הצפנות, ניהול זהויות וזיהוי מאובטח יש לשלב בתהליך הפיתוח, או ליישם באמצעות כלים חיצוניים.
כמו כן יש לזכור, כי בדיקות האבטחה כגון Dynamic analysis ו-Penetration tests צריכות להתבצע לרוב לאחר תיאום עם הספק ותחת ההגבלות שהוא מאפשר. מדד לבחינת בשלות של ספק PaaS הוא קיומו של תהליך מסודר לביצוע בדיקות אלה.
 
בעולם ה-Software as a Service רוב האחריות נמצאת אצל ספק השירות. הארגון לרוב נדרש לבצע בקרות משלימות ומומלץ לעדכן בקרות אלו, עוד בשלב חתימת החוזה עם הספק. לרוב, הלקוח יכול לצפות לשליטה ברמה כזו או אחרת בתחומים מסוימים: שליטה מסוימת על Application logic, יכולת לבצע מבחני פגיעות ומבדקי פריצה (בתיאום מראש) ויכולות של ניהול משתמשים. בנושא זה של Identity Management יש שיפור רב בשוק, וכיום יש מספר הולך וגובר של ספקים התומכים בסטנדרטים מתקדמים כגון SCIM, שמאפשר Provisioning ו-SAML, OAUTH ו-OpenID, שמאפשרים SSO, Authorization ו-Federation בין הסביבה הפנימית לחיצונית או בין ספקי שירות וספקי זהויות (תחום חם לאחרונה).
 
כפי שתואר לעיל, בהתאם למודל השירות, קטנה היכולת של מנהל אבטחת המידע לשלוט על מגוון הרכיבים. אך במקביל יש התקדמות יפה בכלי אבטחת מידע המותאמים לסביבות ענן. כלי הצפנה עם יכולות להצפין מידע בסביבות שאינן בשליטת הלקוח, מאפשרים לו להוציא מידע חסוי לסביבות ענן, ללא חשיפת מפתח ההצפנה לספק. חברות חדשות מציעות שירותי VPN, DLP ו-WAF כשירות מותאם לענן ומאפשרות להתגבר על מגבלות הרשת השטוחה. כלים נוספים מאפשרים ללקוח לקבל בענן הציבורי יכולות שליטה ואבטחה, הדומות לרשת הפנימית המסורתית.
 
לסיום:
מנהלי אבטחת מידע רבים נתקלים במצב בו הארגון דורש לעבור לסביבות ענן, על מנת לחסוך בעלויות. על מנהל אבטחת המידע לא להתנגד למגמה זו, אלא להתייחס למעבר לענן כהזדמנות. תהליך נכון של מעבר לענן יכלול בתוכו בדיקה של התחומים בהם הארגון מאבד שליטה על המידע ובדיקה של מחירו של כלי "ענני", לבקרה מונעת או מפצה על השליטה שאבדה. בצורה זו ניתן לשקלל בצורה טובה יותר את המעבר לענן ולהתייחס לעליה או לירידה בסיכון. תהליכים אלה יכולים לסייע למנהל האבטחה להפוך מגורם "מעכב"  לגורם "מאפשר", וזוהי דרישה של ממש בעולם ה-IT כיום.
 
מאת: משה פרבר,  יולי 2013,
מרצה בתחום אבטחת מידע, משקיע ושותף בחברות ההזנק FortyCloud ו – Clarisite, ומדריך מוסמך של  ה – Cloud Security Alliance. מידע נוסף – כאן.