הדור הבא של Shift left

לפני זמן מה נתקלנו בכתבה מעניינת, שקובעת ש-״יותר מ- 30% מאריזות פריסה הרשמיות ב-Docker Hub מכילות פגיעויות אבטחה ברמה גבוהה״. האחוז נשמע כל כך גבוה, כך שהתגובה הראשונה היא הלם. אך אם להקדיש לכך מחשבה, זה לא באמת מפתיע. עובדה זו כנראה נכונה לכל סוג של תוכנה, רק שבפועל הרבה יותר קשה לכמת פגיעויות באבטחה של כל תוכנה מאשר את אלה שבקונטיינרים.

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

בהגדרה, לקונטיינרים יש גבולות אחריות ברורים ומוגדרים היטב, כי כל אחד מיישם שירות אפליקטיבי מסוים. זו הסיבה שקונטיינרים הם דרך טובה למדוד סיכונים. בנוסף, האופי המסוים של ארכיטקטורת הקונטיינרים הופך את הפרדת האחריות (Separation of concerns) למובנת יותר.

הסיכונים והתאמת אבטחת הייצור

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

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

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

סיכון COPO – הוא כרוך בביצוע פעולות מתקנות ומונעות בייצור (Corrective and preventive operations). מכאן הקיצור COPO. סיכון זה הוא זניח במקרה של תשתית שהיא בהחלט בלתי ניתנת לשינוי (Immutable infrastructure), אך סיכון הפריסה גובר במקרים אלה. הסיבה לכך היא שבתשתית בלתי ניתנת לשינוי האפשרות לתיקון זריז לא קיימת וכל תיקון, אפילו הקטן ביותר, מחייב פריסה מחדש.

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

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