קונטיינרים: 4 שיקולי אבטחה מרכזיים

מאת קימברלי קרייבן, צוות מוצרי קונטיינרים, רד האט.

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

בנקודה זאת, מחקר מנהלים של פורסטר (Forrester) שהוזמן ע"י רד האט,  גילה כי 53 אחוז ממקבלי ההחלטות בתחומי תפעול IT  ופיתוח, זיהו אבטחה כדאגה הגדולה ביותר שלהם בנוגע לאימוץ קונטיינרים.

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

להשתמש במקורות אמינים

יותר מ- 30 אחוז מהתמונות המתארחות ב- Docker Hub  בענן, מכילות פרצות אבטחה בעדיפות גבוהה. זאת על פי מחקר של BanyanOps ממאי 2015. הרשאה, ע"י חתימות דיגיטליות למשל, מוסיפה רמה של אבטחה ע"י אישור של מי ייצר את הקונטיינר ולאיזו מטרה.

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

הסמכה מסייעת להבטיח כי: כל הרכיבים מגיעים ממקורות אמינים; מארחי הקונטיינר (hosts) לא זויפו והם עדכניים; תדמית הקונטיינר נקייה מפרצות מוכרות ברכיבי ובשכבות הפלטפורמה; הקונטיינרים תואמים וירוצו ברחבי סביבות hosting מאושרות.

מה יש בתוך הקונטיינר

אימות של מקור הקונטיינר הוא חלק ממאבק, אבל אימות של מה יש בתוך תמונת הקונטיינר, חשוב באותה מידה, אם לא יותר. בדומה לאופן בו בדיקת מנות עמוקה מחפשת תוכן זדוני בתוך מנות רשת, כך DCI)  Deep Container Inspection בוחנת מעבר לפורמט תמונת הקונטיינר, את התוכן שלו. יכולת התבוננות לתוך הקוד של קונטיינרים, הינה קריטית לשמירה על אבטחה במהלך פיתוח ואחריו.

בידוד

כאשר יש יישומים מבוססי-קונטיינר המורכבים מקונטיינרים מהימנים, צריך לוודא כי אינם בסיכון מתמונות קונטיינר אחרות באותו מארח (host). האמת היא שקונטיינרים לא באמת "מכילים" יישומים באותה דרך שמכוניות משוריינות מכילות כסף. יותר מדויק לומר כי קונטיינרים אורזים קוד של יישום יחד עם התלויות שלו.

אם מדמיינים קונטיינרים כבעלי קירות, יש להבין כי אלה הם קירות דקים. תוכן זדוני בקונטיינר אחד עלול לחדור  לקונטיינר אחר או למערכת ההפעלה המארחת. כל תהליך בודד שרץ בתוך קונטיינר, מדבר ישירות לקרנל (kernel) של ה- host. הקרנל משמש כנקודת כשל יחידה עבור כל הקונטיינרים ב- host זה. נקודת תורפה בתוך קרנל הלינוקס עלולה לאפשר למי שיש להם גישה לקונטיינר אחד, להשתלט על מערכת ההפעלה של ה- host וכל הקונטיינרים האחרים ב- host זה.

זו הסיבה לכך שחשוב להסתמך על מערכת הפעלת host שמתוחזקת ע"י מהנדסי kernel מהימנים ומעודכנים באופן קבוע בעדכוני האבטחה האחרונים. קונטיינרים בנויים על host חלש, יורשים את מודל האבטחה הגרוע אותו מספק host זה. ה- kernel צריך לכלול פונקציונליות המספקת רמות מתאימות של בידוד והפרדה כמו SELinux, Seccomp , Namespaces, ועוד.

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

אמון קונטיינר הנו זמני

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

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

מסקנות

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

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

תכנים – בחינת קונטיינר לעומק יכולה לתת יותר מאשר מבט על פורמט תמונת הקונטיינר, אל תוכנו, כדי לזהות ולצמצם נקודות תורפה.

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

אמון לאורך זמן – יש לבחון את תוכן הקונטיינר באופן קבוע, כדי לאמת צמצום סיכוני אבטחה. יש להשתמש בכלי זמן ריצה כמו אלה ב- Red Hat Enterprise OpenShift , לאיתור ותיקון של נקודות תורפה.