קונטיינרים: ארבעה שיקולי אבטחה מרכזיים
כתבה: קימברלי קרייבן, צוות מוצרי קונטיינרים, רד-האט
קונטיינרים – מכולות (Containers), המאפשרים לנצל משאבים קטנים במיוחד בזכות החיסכון במערכות הפעלה ומתאימים במיוחד לסביבות ענן, מבטיחים לסייע לארגוני פיתוח תוכנה לחסוך זמן וכסף על ידי אספקת מנגנון לניוד יישומים ברחבי סביבות פיתוח, בדיקות, והטמעה.
התפוצה הרחבה של קונטיינרים גם מציבה אתגרים באימוץ על ידי ארגוני אנטרפרייז, כולל אתגרים סביב אבטחת הקונטיינר.
מחקר מנהלים של פורסטר (Forrester) שהוזמן על ידי רד-האט, גילה כי 53% ממקבלי ההחלטות בתחומי תפעול IT ופיתוח, זיהו אבטחה כדאגה הגדולה ביותר שלהם בנוגע לאימוץ קונטיינרים.
חברות המעוניינות לאמץ קונטיינרים, צריכות לבדוק היטב איך הן מתכננות לאבטח אותם, עם דגש על מקור, תוכן קונטיינר, בידוד, ואמון.
להשתמש במקורות אמינים
יותר מ-30% אחוז מהתמונות המתארחות ב-Docker Hub בענן, מכילות פרצות אבטחה בעדיפות גבוהה. זאת על פי מחקר של BanyanOps ממאי 2015. הרשאה, על ידי חתימות דיגיטליות למשל, מוסיפה רמה של אבטחה על ידי אישור של מי ייצר את הקונטיינר ולאיזו מטרה.
הכנסת תכני קונטיינר לא מהימנים לתוך דטה סנטר, עלולה לגרום הרבה יותר נזק מאשר לתלות יצירת אמנות מזויפת במשרד. זו הסיבה לכך שרד-האט ומובילי תעשייה אחרים פועלים ליצירת סטנדרטים ושיטות עבודה סביב הסמכת קונטיינרים.
מה יש בתוך הקונטיינר
אימות של מקור הקונטיינר הוא חלק ממאבק, אבל אימות של מה יש בתוך תמונת הקונטיינר, חשוב באותה מידה, אם לא יותר. בדומה לאופן בו בדיקת מנות עמוקה מחפשת תוכן זדוני בתוך מנות רשת, כך DCI (ר"ת Deep Container Inspection) בוחנת מעבר לפורמט תמונת הקונטיינר, את התוכן שלו. יכולת התבוננות לתוך הקוד של קונטיינרים, הינה קריטית לשמירה על אבטחה במהלך פיתוח ואחריו.
בידוד
כאשר יש יישומים מבוססי-קונטיינר המורכבים מקונטיינרים מהימנים, צריך לוודא כי אינם בסיכון מתמונות קונטיינר אחרות באותו מארח (host). האמת היא שקונטיינרים לא באמת "מכילים" יישומים באותה דרך שמכוניות משוריינות מכילות כסף. יותר מדויק לומר כי קונטיינרים אורזים קוד של יישום יחד עם התלויות שלו.
אם מדמיינים קונטיינרים כבעלי קירות, יש להבין כי אלה הם קירות דקים. תוכן זדוני בקונטיינר אחד עלול לחדור לקונטיינר אחר או למערכת ההפעלה המארחת. כל תהליך בודד שרץ בתוך קונטיינר, מדבר ישירות לקרנל (Kernel) של ה-Host.
הקרנל משמש כנקודת כשל יחידה עבור כל הקונטיינרים ב-Host זה. נקודת תורפה בתוך קרנל ה-Linux עלולה לאפשר למי שיש להם גישה לקונטיינר אחד, להשתלט על מערכת ההפעלה של ה-Host וכל הקונטיינרים האחרים ב-Host זה.
זו הסיבה לכך שחשוב להסתמך על מערכת הפעלת Host שמתוחזקת על ידי מהנדסי Kernel מהימנים ומעודכנים באופן קבוע בעדכוני האבטחה האחרונים.
קונטיינרים בנויים על Host חלש, יורשים את מודל האבטחה הגרוע אותו מספק Host זה.
חשוב להבין כי יישומים מוכלים בקונטיינרים, דורשים אותם אמצעי אבטחה כמו יישומים מסורתיים.
אמון קונטיינר הנו זמני
בעוד אולי ניתן לסמוך על תמונת קונטיינר כשזו נוצרת לראשונה, אותו קונטיינר ותכניו עלולים להזדהם לאורך זמן. אם ביום הראשון יישום מבוסס קונטיינר הוטמע לתוך ייצור (פרודקשן), מה קורה ביום שאחריו? ואחרי יומיים?
נקודות תורפה חדשות מזוהות על בסיס יומיומי, ותמונת קונטיינר היא מאובטחת כמו הקוד והתלויות שהיא מכילה. לדוגמה, רד-האט זיהתה ותיקנה 66 נקודות תורפה קריטיות, חשובות ומשפיעות, בסביבת זמן הריצה של Java לאורך תקופה של 315 יום. נדרשת רק נקודת תורפה אחת כדי לפגוע בקונטיינר, ובאופן פוטנציאלי, במערך תשתית שלם.
