מפו מי מנהל את המנוע ומה כל שירות צריך
רשמו מארח, גרסת מנוע, שירותים, בעלים ותפקידים. בדקו מי יכול לשלוט ב-Docker ובאילו ערוצים, לא רק מי נכנס לתוך קונטיינר. תיעוד Docker מציג את משטח המנוע ואת תצורת הקונטיינר כשכבות אבטחה נפרדות. גישה למנוע אינה הרשאת צפייה רגילה בתוכן האתר.
חשיפה של ממשק ניהול או חיבור socket לכלי אחר צריכה צורך מפורש והגנות מתאימות. אין לפתוח גישה למנוע כדי לפתור בקלות תהליך פריסה בלי להבין מה היא מאפשרת. גם כלי ניטור או אוטומציה מקבל רק את היכולת שנדרשת ושניתן לתחזק.
בחנו משתמש, יכולות ותיקיות מחוברות
זהות הריצה והיכולות שניתנו לקונטיינר משפיעות על ההיקף שלו. בדקו צורך ב-privileged, במכשירים, בקבצי מארח ובכתיבה לתיקיות. Rootless הוא מנגנון ש-Docker מציע להפעלת מנוע וקונטיינרים ללא root, בכפוף לתנאים ולהתאמה; הוא אינו תיקון אוטומטי לכל חולשה ביישום.
הטבלה היא מסגרת סקירה מקורית. לא משנים משתמש, בעלות או mount בשרת חי בלי לבדוק מה היישום צריך כדי לעבוד. הצמצום צריך להיות אפקטיבי ולא רק ערך יפה בקובץ תצורה.
| תחום | שאלת בדיקה | ראיית סיום |
|---|---|---|
| זהות ריצה | האם נחוצות ההרשאות שניתנו | תפקיד מצומצם ותפקוד יישום |
| יכולות ו-privileged | מהו הצורך בחריגה | נימוק או הסרה עם בדיקה |
| תיקיית מארח | איזה נתיב מחובר ולקריאה או כתיבה | גישה רק למידע הנחוץ |
| מנוע או socket | מי יכול להפעיל ניהול | היקף והגנה שנבדקו |
| נתונים מתמידים | היכן נשמר מצב עסקי | יכולת גיבוי ושחזור נפרדת |
פרסום פורט צריך להיבדק מנתיב הגישה המתוכנן
Docker מתעד שפרסום פורט נעשה לכל ממשקי המארח כברירת מחדל, כאשר לא נבחרת כתובת מתאימה. שירות שנועד רק לרכיב פנימי עלול לקבל חשיפה לא מתוכננת. בדקו גם גרסה, כללי ספק, חומת אש ונתיבי IPv4/IPv6 לפי הסביבה, ולא רק אם השירות נגיש מהשרת עצמו.
התיעוד מתאר גם אינטראקציה עם מנגנוני חומת אש. כלל מקומי שנראה מחמיר אינו הוכחה שכל תעבורת הקונטיינר עוברת במסלול שהנחתם. לא מבטלים כללי Docker באופן גורף; מתכננים בקרה מתאימה ומאמתים גישה מותרת וחסימה צפויה.
תמונה, סוד ותהליך עדכון הם חלק מההגנה
רשמו מאין מתקבל image, איזו גרסה או זהות תמונה נפרסה ומי אחראי לבנייה ולעדכון. הנחיות Docker מדגישות מקור מתאים ובנייה חוזרת לצורך קבלת עדכונים. קונטיינר שכבר פועל אינו מקבל בהכרח תיקוני image רק משום שקיימת גרסה חדשה במאגר.
סודות אינם חומר להטמעה בתמונה ציבורית או בלוג. בוחרים מנגנון מתאים לסביבה, מגבילים גישה ומתכננים החלפה. גם גיבוי קובץ תצורה יכול לכלול ערכים רגישים, ולכן הוא נכלל במפת ההרשאות. בדיקת תמונה אינה מחליפה בדיקת רשת והרשאות ריצה.
דוגמה: מסד פנימי פורסם בלי צורך עסקי
התרחיש להמחשה בלבד. יישום צריך לפנות למסד בתוך סביבת הפריסה, אך הפורט פורסם גם במארח. הצוות ממפה את מסלול היישום ואת צרכי הניהול, ומגדיר צמצום מתאים. הבדיקה אינה מסתיימת בפתיחת האתר; היא בוחנת גם שחיבור מורשה עובד ושמסלול לא נדרש אינו זמין לפי המדיניות.
לא סורקים מערכות של אחרים כדי להמחיש את הבעיה ולא מנסים גישה לא מאושרת. משתמשים בסביבת ניסיון או בבדיקה מצומצמת שסוכמה עם הבעלים. אם קיימים סימנים לניצול, פותחים מסלול אירוע בנפרד משינוי הפרסום.
מסרו גבולות שניתן לבדוק שוב
התוצר כולל שירותים, זהויות, images, mounts, פורטים וסודות בהיקף סקירה, ללא הערכים הסודיים עצמם. רשמו שינויים וחריגות עם בעלים, תפקוד שנבדק ודרך חזרה. אחרי הוספת כלי או image בוחנים את השורות הרלוונטיות, ולא מניחים שהסקירה הישנה מכסה אוטומטית תצורה חדשה.
ב-CyberFixCrew אפשר להגדיר בדיקת פריסה וחיבורים לשירותי Docker/Linux הקיימים. המדריך אינו טענה שבוצעה בדיקת חדירה או שכל חולשה נשללה. גיבוי והתאוששות נשארים בדיקה נפרדת, גם כשהרשאות הריצה נראות מצומצמות.
