האם אתם מגנים על טכנולוגיית הסרברלס שלכם?

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

טל מלמד, בשיתוף קונטרסט סקיוריטי
תוכן שיווקי
שתפו כתבה במיילשתפו כתבה במייל
shutterstock
צילום: shutterstock
טל מלמד, בשיתוף קונטרסט סקיוריטי
תוכן שיווקי

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

טל מלמד | צילום: רמי זרנגר

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

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

אובדן השליטה בהיקף המערכת (Perimeter) - טרום עולם הסרברלס, בעת פיתוח אפליקציות מסורתיות, מונוליטיות (Monolithic application) השליטה בהיקף המערכת, כגון התעבורה, הרשת וכל מה שמחבר בין צד המשתמש לבין המערכת (צד השרת), היתה בידי הארגון. בהתאם, ארגונים הטמיעו פתרונות אבטחת מידע היקפיים כגון "חומת אש" (Firewall) מפני מתקפות מבחוץ ופתרונות כגון DLP אשר מונעים ממידע רגיש לדלוף החוצה. בפיתוח סרברלס, ההגנה ההיקפית והשליטה בכל התשתית - שמחברת בין השירות לבין קוד המערכת של הארגון - הינה באחריות ספקית הענן ונוצר פער אבטחתי בין התשתית לאבטחת הקוד אותו אחראי הארגון למלא. מערך זה מייצר פרצות שעלולות להיות מנוצלות על ידי תוקפים פוטנציאליים.

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

לבצע בדיקות עוד בשלבי הפיתוח
דבר ראשון, על חברות להבין שהאחריות על האפליקציה והמידע היא שלהן ולדאוג לכך שהן מוגנות ככל שניתן לפני העברת גרסה לייצור. לארגונים שמפתחים במודל סרברלס מומלץ לאמץ את עקרון "ההרשאות המינימליות" (Least Privilege) אשר מגדיר את ההרשאות לכל רכיב במערכת אך ורק לפעולות הנדרשות על ידיו בפועל. בנוסף, המפתחים חייבים לדאוג שקוד המערכת מאובטח דיו ועובד במודל אבטחה "אפס אמון" (Zero Trust), כך שהוא יודע להגן על עצמו ואינו מתבסס על כך שהתקפות לא יגיעו ממקורות לא צפויים. כמו כן, יש לבצע בדיקות אבטחה לקוד ולמערכת עוד בשלבי הפיתוח בכדי למנוע מקוד לא מאובטח להגיע לסביבת הייצור.

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

מענה לאתגרים בעולמות הסרברלס
חברת קונטרסט סקיוריטי (Contrast Security), המספקת פתרונות לאבטחת יישומים בענן בתהליכי פיתוח, הכריזה לאחרונה על השקת פתרון, שנותן מענה בדיוק לאתגרים בעולמות הסרברלס כשהוא מאפשר לבדוק אבטחת יישומים בענן, שפועלים על גבי ארכיטקטורה זו (Serverless Application Security Testing) בצורה אוטומטית ושקופה למפתח. הפתרון, שפותח על-ידי מרכז הפיתוח של קונטרסט סקיוריטי בישראל, מבוסס על רכישת חברת הסטארט-אפ CloudEssence (קלאודאסנס) הישראלית בדצמבר 2020. פתרון הסרברלס של קונטרסט סקיוריטי הינו הפתרון היחידי לבדיקות אבטחת מידע ייעודיות לאפליקציות סרברלס, הכולל הן בדיקות סטטיות והן בדיקות דינאמיות באופן אוטונומי ובשקיפות מלאה למפתחים, המבוסס גם על קוד המקור וקוד צד ג' וגם על הבנת הקונטקסט של הסביבה. התקנת הפתרון קלה, פשוטה ומהירה מאוד ואינה דורשת התמחות ייחודית באבטחת מידע, כאשר התוצאות מתקבלות מיידית ברגע סיום ההתקנה.

הכותב הוא דירקטור בכיר למחקר בחברת קונטרסט סקיוריטי.

למידע נוסף כנסו לאתר contrastsecurity

בשיתוף קונטרסט סקיוריטי