פורסם באוגוסט 2019 ב- New Tech Magazine
ארגונים רבים מפתחים את האפליקציות החדשות שלהם בטכנולוגיית “קונטיינרים” במקביל לאפליקציות המסורתיות הממשיכות לעבוד בעולם של Virtual Machines , אך האם הם שומרים על אותה רמת אבטחה בעולם החדש ?
אין ספק שעבודה עם קונטיינרים יצרה מהפכה בעולם פיתוח התוכנה והענן, מהרגע שחברת Docker פרצה עם פרויקט קוד פתוח, המאפשר אוטומציה של התקנה והרצת יישומים בתוך מכולות תוכנה (Containers – “קונטיינרים”),
ניתן לראות ארגונים רבים שנעים לעבוד בשיטת העבודה הזו.
עבודה עםDocker וקונטיינרים חוסכת משאבים ומקום, ומייעלת את העבודה בכך שהיא יותר קלה, מהירה ודינאמית. כתוצאה מכך Docker הופך את הטכנולוגיה המסורבלת בעבודה עם Virtual Machines לפשוטה מאוד ליישום.
בסביבת Virtual Machines – כל VM כולל בתוכו :מעטפת של שכבת ה-Hypervisor, מערכת הפעלה מלאה הצורכת משאבים ( מעבד, זיכרון, דיסק ,רשת וכ’ו) ששוקלת עשרות GB, ומעליה את האפליקציה
שכוללת בתוכה: קוד, ואת הספריות – Libs. עבודה עם קונטיינרים היא שונה, בעבודה עם קונטיינרים כל קונטיינר בנוי מ- Docker image fileהכולל בתוכו מערכת הפעלה מאוד רזה הנקראת Micro Kernel שממנה קובעים מאיזו הפצת לינוקס אנו רוצים לקבל את ה-Base
Image (כאשר בפועל אנו לא משתמשים בכל ה-Base Image אלא רק בחלקו.)
באותו Base Image המפתח יארוז את קוד האפליקציה ואת הספריות הנדרשות. כך שבסוף התהליך נוצר Docker image file ,המייצג את הקונטיינר כולו, שמתנהל באופן עצמאי ללא תלות באף סביבה אחרת.
נפח קובץ של קונטיינר (Docker image file) הרבה יותר קטן ממכונת VM (VMDK)
ולכן עבודה בקונטיינרים מאפשרת לנו לעבוד בצורה:
מהירה יותר– הטכנולוגיה מאפשרת להרים אפליקציות בשניות עם אימוץ של ארכיטקטורת Micro services (מיקרו שירותים) הדוגלת בפיתוח של רכיבים קטנים (MVP- Minimum viable program ) שיודעים לדבר בניהם דרך API . ארכיטקטורה זו מקלה באופן משמעותי
על תהליך ה- Deployment ועל עדכוני הגרסאות בכך שהוא מקצר את תהלכי ה QA ומאפשר קצב מוגבר בשחרור גרסאות והוספת פיצ’רים חדשים.
גמישה וסקלבילית יותר – קונטיינרים שוקלים מעט והם עצמאים, כך שניתן להריץ ולשכפל אותם במהירות כדי לספק מענה לעומס פתאומי באחד מהרכיבים של האפליקציה ( לדוגמא UI – User Interface שסופג עומס של פניות).
קלה יותר לתפעול – עבודה עם קונטיינרים מפשטת את התהליך לגופי הפיתוח ,מפתחים כבר לא צריכים להתאים את הקוד למערכת ההפעלה אלא להתעסק בפונקציונליות של האפליקציה עצמה.
ניידות– המאפשרת לנו להריץ את הקונטיינרים בכל תשתית ובכל סביבה On-Premise, Cloud, וה- Bare Metal, וזאת לאפליקציות שנכתבו לסביבת מחשוב המסורתי או בעולם ה Mobile.
להלן טבלה המשווה את ההבדלים בין VM לקונטיינרים בהתייחס לאותו קוד אפליקטיבי ואוסף הספריות הנלווה.
| VM |
Containers |
| שוקל ביחידות מידה GB |
שוקל ביחידות מידה KB-MB |
| רמת ביצועים נמוכה יותר עקב ריבוי שכבות תוכנה |
רמת ביצועים גבוהה יותר |
| אתחול ושכפול מכונה וירטואלית ארוך יותר |
אתחול ושכפול קונטיינר מהיר יותר |
| מוגבל בהעברה מסביבה לסביבה |
ניתן לנייד לכל סביבה |
| כל VM מריץ מערכת הפעלה משלו
ולכן סכנות לחשיפה לאיומים קטנות יותר
|
כל הקונטיינרים משותפים למערכת הפעלה של השרת המארח –נדרשת גישה ל root
ולכן החשיפה לאיומים גדולה יותר
|
קונטיינרים ומיקרו־שירותים מייצרים סביבות הטמעה עם רמות חדשות של אתגרי אבטחת מידע
מאחר וקונטיינרים אינם משויכים לשרת או לכתובת IP מסוימת, כלי האבטחה המסורתיים כגון: FireWall או Anti-virus המותקן על גבי התחנה/שרת מאבדים את החשיבות.
קונטיינרים מובילים לריבוי שירותים ויישומים במופעים רבים ולפעמים על תשתיות מבוזרות כגון ה- Public Cloud , דבר זה מקשה על הניטור והמעקב לאיתור איומים במערכת.
כתוצאה מכך, נדרש לספק פתרונות אבטחה ייעודים עבור קונטיינרים במטרה לתת הגנה ” 360″ עבורם.
האתגר הראשון הוא מניעת חדירה של התקשרויות זדוניות
פתרונות האבטחה המיועדים לקונטיינרים כוללים FW אפליקטיבי ברמת האפליקציה ,ולא ברמת המכונה, שיקבע מדיוניות אבטחה “מערך שיטור” שעל פיה קונטיינרים ופונקציות יורשו או לא יורשו לרוץ, כגון: האם image צריך לרוץ כ-root או לא, האם יש packages שלא נרצה לאשר
לדוגמא: איסור גישה ב SSH \ FTP וכו’.
בצורה זו ניתן לספק “הקשחה לקונטיינר” אשר לא תאפשר פעולות שלא הגדרנו במדיניות האבטחה. בנוסף, מנגנון זה מספק הגנה מפני פרצות אבטחה, CVE’s או Exploits שקיימות בחוץ. שיטת ההגנה מתבצעת ע”י סריקה מול רשימה של פרצות מוכרות עוד לפני שלב ההרצה.
פלטפורמות מסוג זה בדרך כלל מתחברת ישירות לכלי CI/CD(Continuous Integration and Continuous Delivery) ומפקחות כבר בתהליך האריזה של ה-Image ו-Packages שמרכיבים את ה Container image -כולו. לאחר מכן הסריקה מתבצעת הן בתהליך ההרצה והן באופן קבוע
ברמה יומית על ה-Image שנמצא ב-Registry -המאגר שמכיל את ה- , Images גם אם הוא פרטי וגם אם הוא פומבי (לדוגמא MarketPlace שממנו מורידים Images שמוכנים לשימוש).
בדרך זו ניתן לבדוק באופן תמידי האם ה Image “בריא והגייני” מבחינת אבטחת מידע ובמידה ויהיה שינוי בפרופיל שהוגדר, המערכת תדע להתריע ולחסום שינוי זה. פתרון זה מבטיח שהקונטיינר יהיה מוגן בכל שלבי ה CI/CD , מצמצם את נקודות התורפה ומונע “zero
day” attacks , פרצת אבטחה שלא הייתה ידועה עד כה.
אתגר שני – תאימות לתקנים.
חברות רבות צריכות להתאים את המערכות שלהם לתקנים בינלאומיים כגון : HIPPA, NIST, PCI שבדרך כלל על מנת ליישם זאת נדרש תהליך ארוך ומורכב. כיום יש פתרונות אבטחת מידע המיועדים לקונטיינרים שיודעים בעזרת חבילת תוכנה להתאים את המערכת לתקן הרלוונטי.
הפתרונות מבוססים על תוכנה שמנטרת את הקונטיינר באופן קבוע בתהליך ההרצה ובודקת עד כמה הוא תואם לתקן שבה החברה צריכה לעמוד, במידה ומישהו משנה בקונטיינר תכונות שלא עומדות בתקן, היא יודעת לחסום ולבלום כל ניסיון שעלול להפוך את המערכת ללא תואמת.
ג’נט אבישר, מהנדסת מערכות,
בינת תקשורת מחשבים
אתגר נוסף הוא קריאות מערכת – System calls
קריאות מערכת הן האחראיות על החיבור שבין המשתמש לליבת המערכת ( הKernel-), ובכך מאבזרת את המשתמש ונותנת לו שימוש מרבי בפונקציונליות שהיא מציעה . הקריאות האלו יכולות לייצר “באגים” שיפגעו בקרנל. בקונטיינרים, מאחר והקרנל ומערכת ההפעלה משותפים
לכל הקונטיינרים, ברגע שיש באג בקונטיינר מסוים, כל הקונטיינרים האחרים שעובדים במקביל על אותה מערכת הפעלה חשופים לבאג הזה. לכן ישנם פתרונות שמוודאים שכל System Call שנשלח הוא בטוח והגיוני. במידה ולא, הם ידעו לזהות ולחסום את
אותה קריאה.
לסיכום, אבטחת מידע בקונטיינרים תופסת חשיבות ברמה גבוהה בדומה לקצב שבו “קונטיינרים משתכפלים”. ארגונים רבים סיימו מזמן את שלב הבחינה והפיתוח ועוברים לשלב הייצור – הנושא קריטי. עבודה עם קונטיינרים מצריכה חשיבה שונה בהיבט ההגנה, רצוי ואף
מומלץ לאבטח את הסביבה בשלב מוקדם של התהליך וכמובן לפני מעבר לשלבי הייצור של האפליקציה. מחלקת ההנדסה של בינת מספקת את כל הייעוץ ,הארכיטקטורה וההטמעה לפתרונות אלו.
ג'נט אבישר, מהנדסת מערכות, בינת תקשורת מחשבים