אבטחת קונטיינרים: מדריך מעמיק להגנה מהאימג' ועד ה-runtime

מאת צוות מדיה דיל · 07.08.2026 · DevOps · 7 דק'

מדריך ארכיטקטוני לאבטחת קונטיינרים לכל אורך מחזור החיים: hardening של base images, הרשאות runtime, בידוד kernel, שרשרת אספקה ו-monitoring בזמן אמת.

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

מודל האיום הייחודי לקונטיינרים

ה-kernel המשותף הוא נקודת המוצא להבנת אבטחת קונטיינרים: בעוד VM מקבל hypervisor שמפריד אותו ברמת החומרה מכל VM אחר על אותו מארח, קונטיינרים משתמשים באותו kernel דרך namespaces ו-cgroups - מנגנוני בידוד ברמת התוכנה, לא ברמת החומרה. המשמעות: חולשה ב-kernel עצמו, או קונפיגורציה לא נכונה שמאפשרת לקונטיינר לגשת ליכולות (capabilities) שהוא לא צריך, יכולה לאפשר container escape - יציאה מהקונטיינר לגישה ישירה למארח, וממנו לכל קונטיינר אחר שרץ עליו. זה שונה מהותית מהאיום המוכר של פריצה ל-VM בודד, ודורש חשיבה אחרת לגמרי על שכבות הגנה.

Hardening של Base Images: הבסיס לכל השאר

כל חולשה שקיימת ב-base image עוברת אוטומטית לכל אימג' שנבנה עליו. הבחירה בין אימג' מלא (כמו ubuntu:latest) לאימג' מינימלי (alpine, distroless) היא החלטת אבטחה משמעותית, לא רק החלטת ביצועים: אימג' מלא מכיל package manager, shell מלא, וכלי מערכת רבים שלא נדרשים לרוב האפליקציות - וכל אחד מהם הוא משטח תקיפה פוטנציאלי נוסף אם התוקף כבר בפנים. אימג'י distroless (מבית Google) הולכים צעד נוסף ומסירים אפילו shell בסיסי - אם אין shell, תוקף שהצליח להריץ קוד בקונטיינר לא יכול בקלות להריץ פקודות נוספות או לחקור את הסביבה.

נעילת גרסת base image לתגית מדויקת (לא latest) עם עדכון סדיר מתוכנן - לא רק בתגובה לחולשה שהתגלתה - מונעת מצב שבו אימג' ישן שאף אחד לא נגע בו כבר חצי שנה צובר חולשות בלי שאף אחד שם לב.

הרשאות Runtime: העיקרון של להריץ עם הכי פחות כוח אפשרי

קונטיינר שרץ עם דגל --privileged מקבל גישה כמעט מלאה למארח - זה הרוב המכריע של הזמן שגיאה, לא צורך אמיתי. גם בלי privileged מלא, כל Linux capability שמוענקת (כמו NET_ADMIN או SYS_ADMIN) מרחיבה את מה שקוד זדוני בתוך הקונטיינר יכול לעשות אם הוא משתלט על התהליך. הגישה הנכונה: להתחיל מ-drop all capabilities ולהוסיף בחזרה רק את המינימום ההכרחי שהאפליקציה בפועל דורשת - תהליך שדורש פרופיל (profiling) של האפליקציה כדי לדעת בדיוק מה היא צריכה, אבל משתלם עשרות מונים בהפחתת סיכון.

הרצה כ-non-root user (UID לא מיוחס) היא כלל בסיסי נוסף: גם אם קוד זדוני מצליח לרוץ בתוך הקונטיינר, בלי הרשאות root הוא לא יכול לשנות קבצי מערכת קריטיים בתוך הקונטיינר עצמו, וברוב תרחישי container escape, הרשאות root בתוך הקונטיינר הן תנאי הכרחי להצלחת הבריחה.

Seccomp, AppArmor ו-SELinux: מגבילים מה מותר לקרוא ל-kernel

מעבר להרשאות ברמת capabilities, פרופילי seccomp (secure computing mode) מגבילים אילו syscalls (קריאות מערכת ל-kernel) קונטיינר מורשה לבצע כלל. הפרופיל הדיפולטיבי של Docker כבר חוסם מאות syscalls מסוכנים, אבל פרופיל מותאם אישית לאפליקציה ספציפית יכול לצמצם עוד יותר - אם האפליקציה שלכם לעולם לא צריכה ליצור namespace חדש או לשנות הרשאות קבצים ברמת kernel, אין סיבה שהיכולת הזו תהיה זמינה לה בכלל, גם אם היא לעולם לא מתכוונת להשתמש בה בזדון.

AppArmor ו-SELinux מוסיפים שכבת mandatory access control נוספת ברמת קבצים ותהליכים - הגדרה מפורשת של אילו קבצים קונטיינר יכול לקרוא או לכתוב, ואילו תהליכים הוא יכול להריץ. שילוב שלוש השכבות (capabilities, seccomp, MAC) יוצר defense in depth אמיתי - גם אם תוקף עוקף שכבה אחת, שתי האחרות עדיין עומדות בדרכו.

שרשרת אספקה: מהקוד ועד ל-registry

אבטחת קונטיינרים מתחילה הרבה לפני שהאימג' רץ - היא מתחילה בכל תלות שנכנסת אליו. סריקת תלויות (dependency scanning) עם כלים כמו Snyk או Trivy צריכה לרוץ בכל build, לא רק פעם בחודש. חתימה דיגיטלית על אימג'ים (Cosign, Notary) מאפשרת לוודא ברגע ה-deploy שהאימג' שרץ הוא בדיוק זה שנבנה ונבדק, ולא גרסה שהוחלפה בדרך (supply chain attack). יצירת SBOM (Software Bill of Materials) לכל build מספקת נראות מלאה לכל רכיב שנמצא באימג' - חיוני כשמתגלה חולשה חדשה בספריה נפוצה, כדי לדעת מיד אילו שירותים מושפעים בלי צורך בסריקה חוזרת של הכל.

Runtime Detection: לתפוס תקיפה שכבר בפנים

גם עם כל שכבות המניעה, חייבים הנחת עבודה שמישהו יצליח לחדור בסופו של דבר. כלים כמו Falco עוקבים אחרי syscalls בזמן אמת ומזהים דפוסי התנהגות חריגים - קונטיינר שפתאום פותח shell אינטראקטיבי, מנסה לקרוא קבצי הרשאות רגישים כמו /etc/shadow, או יוצר חיבור רשת יוצא לכתובת לא צפויה. ההבדל בין ארגון שמזהה תקיפה תוך דקות לבין ארגון שמגלה אותה שבועות אחר כך, אחרי שהנזק כבר נעשה, הוא בדיוק השכבה הזו של runtime detection.

ניהול Secrets בתוך קונטיינרים

Secrets (מפתחות API, סיסמאות מסד נתונים) שמוטמעים ישירות באימג' - ב-Dockerfile או ב-environment variables קבועים - הם טעות אבטחה נפוצה וחמורה, כי כל מי שיש לו גישה לאימג' (כולל דרך registry שנפרץ) מקבל אותם בחינם. הפתרון הנכון הוא הזרקה (injection) של secrets בזמן ריצה בלבד, דרך מנגנון ייעודי (Vault, AWS Secrets Manager, Kubernetes Secrets עם הצפנה במנוחה), ולא כחלק מהאימג' עצמו. גם ההיסטוריה של git repository שבו נבנה ה-Dockerfile חייבת להיבדק - secret שהוכנס בטעות ונמחק בקומיט מאוחר יותר עדיין קיים בהיסטוריה, ותוקף עם גישה ל-repo יכול לחלץ אותו.

ניטור וביקורת מתמשכת

אבטחת קונטיינרים היא לא נקודת זמן אלא תהליך מתמשך. סביבת קונטיינרים משתנה כל הזמן - אימג'ים חדשים נבנים, תלויות מתעדכנות, קונפיגורציות משתנות. סריקה חד-פעמית לפני deploy לא תופסת חולשה חדשה שמתגלה בספריה קיימת שבועיים אחרי שהאימג' כבר רץ בפרודקשן. סריקה מתמשכת (continuous scanning) של אימג'ים שכבר בשימוש, לצד ניטור runtime שוטף, היא מה שמאפשר לזהות ולתקן חולשות לפני שהן מנוצלות בפועל, לא רק בזמן ה-build המקורי.

בידוד רשת ברמת קונטיינר בודד

מעבר לבידוד ברמת ה-kernel, גם רשת היא וקטור תקיפה מרכזי. קונטיינר שרץ עם גישה חופשית לכל רשת פנימית - כולל מסדי נתונים, שירותים פנימיים ותשתית ניהול - מרחיב משמעותית את הנזק הפוטנציאלי אם הוא נפרץ. הגבלת תעבורה יוצאת (egress) לרשימת יעדים ידועה מראש, במקום לאפשר גישה חופשית לאינטרנט, מונעת מקונטיינר שנפרץ ליצור חיבור יוצא לשרת פיקוד ושליטה (command and control) של תוקף, או לגנוב נתונים החוצה. גם ברמת קונטיינר בודד (לא רק ב-orchestrator), כלים כמו iptables או eBPF-based tools יכולים לאכוף מדיניות רשת מוגבלת שמצמצמת את מרחב הפעולה של קוד זדוני.

ניהול מחזור חיים: מתי אימג' צריך למות

אימג'ים ישנים שממשיכים לרוץ בפרודקשן הם סיכון מצטבר - כל יום נוסף שהם רצים בלי עדכון, ההסתברות שנחשפה בהם חולשה חדשה עולה. מדיניות מחזור חיים ברורה (image lifecycle policy) שמגדירה תדירות עדכון מינימלית (למשל rebuild ופריסה מחדש כל שבועיים גם בלי שינוי קוד, רק כדי לרענן את שכבת ה-base image והתלויות) מבטיחה שהמערכת לא צוברת חוב אבטחה שקט. ארגונים רבים בונים pipeline שמריץ rebuild אוטומטי מתוזמן, לא רק בתגובה לשינוי קוד - הרגל שמונע מצב שבו אימג' 'יציב' ריצה חצי שנה בלי עדכון, ובינתיים נחשפו בו עשרות חולשות.

עוד היבט מעשי שכדאי לשלב בתהליך: הרצת בדיקות חדירה (penetration testing) ממוקדות דווקא בהנחת יסוד שקוד זדוני כבר רץ בתוך קונטיינר - לא רק בדיקה של 'איך תוקף חיצוני נכנס', אלא 'מה קורה אחרי שהוא כבר בפנים'. תרגיל כזה, המכונה לעיתים breakout testing, בודק במפורש האם ניתן לצאת מהקונטיינר לנוד המארח, האם ניתן לגשת לקונטיינרים אחרים, והאם ניתן לחלץ secrets מהסביבה. ארגונים שמריצים תרגיל כזה באופן סדיר מגלים כמעט תמיד פערים שסריקה אוטומטית לבדה לא הייתה תופסת, כי היא בודקת חולשות ידועות ולא שרשראות ניצול מורכבות שמשלבות כמה חולשות קטנות יחד. ההשקעה הזו משתלמת בעיקר בארגונים עם דרישות ציות רגולטוריות (כמו PCI-DSS או SOC 2), שבהם תיעוד תהליך אבטחה מתמשך הוא לא רק המלצה טובה אלא דרישה מפורשת של המבקרים. גם ללא דרישה רגולטורית מפורשת, תיעוד כזה מספק תמונת מצב ברורה להנהלה על רמת הסיכון בפועל, במקום תחושת ביטחון מבוססת הנחות שאף אחד לא בדק אותן.

מ-Container Security ל-Kubernetes Security: הקשר בין השכבות

כל העקרונות שתוארו כאן ברמת הקונטיינר הבודד ממשיכים להיות רלוונטיים כשהקונטיינרים רצים בתוך orchestrator כמו Kubernetes (למאמר מורחב ראו אבטחת Kubernetes) - אבל שם הם מתווספים לשכבות נוספות כמו RBAC, Network Policies ו-admission controllers שאוכפים חלק מהכללים האלה אוטומטית ברמת ה-cluster. ההבנה החשובה: אבטחת runtime ברמת הקונטיינר הבודד היא תנאי הכרחי אבל לא מספיק - היא הבסיס שעליו נבנות כל שכבות ההגנה הנוספות ב-orchestration.

סיכום: אבטחה כתהליך, לא כתכונה

אבטחת קונטיינרים אפקטיבית דורשת התייחסות לכל שלב במחזור החיים - מבחירת base image, דרך הרשאות runtime, ועד ניטור מתמיד אחרי ה-deploy. הטעות הכי נפוצה שאנחנו רואים במדיה דיל היא התייחסות לאבטחה כפרויקט חד-פעמי שנעשה לפני ההשקה, במקום תהליך מתמשך שמלווה את המערכת לאורך כל חייה. ארגון שמטמיע סריקה אוטומטית, הרשאות מינימליות וניטור runtime כחלק אינטגרלי מה-pipeline - לא כשלב נפרד שאפשר לדלג עליו בלחץ זמן - הוא זה שבאמת מוגן, לא רק זה שעבר ביקורת אבטחה פעם אחת בהצלחה.

תגיות: Container Security · Docker Security · Seccomp · AppArmor · Image Scanning · SBOM · Falco · Supply Chain Security

← חזרה לבלוג · צור קשר