כותרת: ארכיטקטורה פורמלית ומתודולוגיה תפעולית לזיהוי ותגובה לאיומים בסביבות קונטיינרים מבוססות Docker ו-Kubernetes

1. מבוא

הווירטואליזציה הקלה המבוססת על קונטיינרים הפכה לפרדיגמה הדומיננטית לפריסה של יישומים מקוריים לענן. טכנולוגיות כגון Docker ו-Kubernetes עברו מכלי ניסיוני לתשתיות קריטיות התומכות בבנקים דיגיטליים, ספקי SaaS, פלטפורמות ממשלתיות וסביבות תעשייתיות. לפי נתוני Cloud Native Computing Foundation (CNCF), יותר מ-90% מהארגונים המאמצים ענן משתמשים ב-Kubernetes בסביבת ייצור (CNCF, 2023).

עם זאת, מודל האבטחה של קונטיינרים שונה באופן מהותי מן הווירטואליזציה המסורתית. בניגוד למכונות וירטואליות, קונטיינרים חולקים את אותו ה-kernel של מערכת ההפעלה המארחת, ומשתמשים במנגנונים כגון Linux namespaces ו-control groups (cgroups) לצורך בידוד (MERKEL, 2014). שיתוף זה יוצר סיכונים מבניים: פגיעויות ב-kernel או ב-runtime של קונטיינרים עלולות לסכן בו-זמנית כמה workloads.

אירועים אמיתיים ממחישים פגיעות זו. CVE-2019-5736 אפשר בריחה מקונטיינר באמצעות החלפת הבינרי runc בעת הרצה עם הרשאות, ובכך איפשר ביצוע קוד ב-host (OPEN CONTAINER INITIATIVE, 2019). קמפיינים של cryptojacking ניצלו APIs של Kubernetes שנחשפו ללא אימות חזק (MITRE, 2023). טכניקות הממופות ב-MITRE ATT&CK for Containers, כגון T1611 (Escape to Host) ו-T1525 (Implant Container), נצפות באופן שגרתי בפעולות אמת.

בעיית המחקר: אף על פי שקיימים כלים נקודתיים (Falco, kube-hunter, Trivy), אין גישה פורמלית משולבת שמדגמנת את המערכת, מגדירה תכונות אבטחה הניתנות לאימות ומספקת צינור תפעולי מלא של זיהוי ותגובה.

שאלות המחקר:

RQ1: כיצד ניתן לבצע פורמליזציה של סביבת קונטיינרים כך שתכונות של בידוד ושלמות יוכלו להיבדק מתמטית?

RQ2: האם אפשר לשלב זיהוי מבוסס כללים ואנומליות כדי להפחית false positives תוך שמירה על שיעור זיהוי גבוה?

RQ3: מהו ההשפעה התפעולית (overhead, latency) של אינסטרומנטציה עמוקה המבוססת על eBPF ב-clusters של Kubernetes בגודל בינוני?

תרומות:

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

C2: פיתחנו ארכיטקטורת זיהוי ותגובה היברידית המשלבת את Falco, Suricata, OPA/Gatekeeper ומנגנוני quarantine אוטומטיים.

C3: הערכנו אמפירית את הפתרון בסביבה ריאליסטית עם מדדי ביצועים כמותיים.

מאמר זה מאורגן כדלקמן: סעיף 2 מציג יסודות ועבודות קשורות; סעיף 3 מגדיר את מודל האיומים; סעיף 4 מפרט את המתודולוגיה; סעיף 5 מתאר את המימוש; סעיף 6 מציג הערכה ניסויית; סעיף 7 דן במחקר מקרה; סעיף 8 דן בהשלכות; וסעיף 9 מסכם.

2. רקע ועבודות קשורות

קונטיינרים משתמשים בפרימיטיבים של kernel Linux: namespaces (PID, NET, MNT, UTS, IPC, USER) ו-cgroups לצורך בידוד ובקרת משאבים (MERKEL, 2014). פורמלית, ניתן להגדיר קונטיינר $C_i$ כטופל:

$$ C_i = (N_i, G_i, F_i, P_i) $$

כאשר $N_i$ מייצג את קבוצת ה-namespaces, $G_i$ את קבוצת ה-cgroups, $F_i$ את מערכת הקבצים (overlayfs) ו-$P_i$ את קבוצת התהליכים הפעילים.

Kubernetes מציג אבסטרקציות נוספות: Pods, Deployments, Services ו-RBAC. כל Pod $P_j$ יכול להכיל מספר קונטיינרים החולקים namespace של הרשת.

עבודות קודמות ניתחו אבטחה בקונטיינרים מנקודות מבט שונות. Combe et al. (COMBE; MARTIN; DI PIETRO, 2016) מנתחים את משטח התקיפה של Docker. Shu et al. (SHU et al., 2017) בוחנים פגיעויות בתמונות Docker ציבוריות, ומוצאים כי יותר מ-30% מהן מכילות חבילות פגיעות.

מגבלות שנצפו:

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

כלים כגון Falco משתמשים ב-eBPF לניטור syscalls בזמן אמת. Suricata פועלת בשכבת הרשת. Trivy מבצע סריקת פגיעויות בתמונות. אולם, האינטגרציה התפעולית של כלים אלה עדיין היא אד-הוק.

3. מודל האיום ופורמליזציה של הבעיה

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

יכולות:

• ביצוע פקודות שרירותיות בקונטיינר.
• ניסיון בריחה באמצעות ניצול פגיעויות (למשל: CVE-2019-5736).
• תנועה רוחבית דרך Kubernetes API.

אנו מגדירים את המערכת כגרף מכוון $G = (V, E)$ שבו:

• $V$ כולל צמתי cluster, pods וקונטיינרים.
• $E$ מייצג זרימות תקשורת או יחסי הרשאה.

תכונת הבידוד:

$$ \forall C_i, C_j \in V, i \neq j: \neg reachable(C_i, C_j) $$

אלא אם הדבר מותר במפורש על ידי המדיניות.

הבעיה היא לזהות רצפי אירועים $E_t$ כך ש:

$$ Pr(Attack | E_t) > \theta $$

כאשר $\theta$ הוא סף המוגדר אמפירית.

4. המתודולוגיה המוצעת

ארכיטקטורה המורכבת משלוש שכבות:

שכבה 1 — טלמטריה: eBPF (Falco), יומני Kubernetes, NetFlow (Suricata).

שכבה 2 — קורלציה: מנוע המבוסס על כללי Sigma ומודל סטטיסטי (Isolation Forest).

שכבה 3 — תגובה: OPA/Gatekeeper החוסם pods חשודים.

Algorithm 1: זיהוי היברידי

Input: Stream de eventos S
Output: Alertas A

for each evento e in S:
    if match_rule(e) == True:
        A.append(e)
    else:
        score = anomaly_score(e)
        if score > θ:
            A.append(e)
return A

מורכבות: $O(n)$ עבור n אירועים, בהנחה שכללים מאונדקסים.

5. מימוש

סביבה:

• Kubernetes 1.28
• Docker 24.x
• Falco 0.36 (eBPF driver)
• Suricata 7.0
• OPA Gatekeeper 3.13
• Trivy 0.45

דוגמה לכלל Falco:

- rule: Shell no container
  desc: Detecta execução de shell interativo
  condition: container and proc.name = bash
  output: "Shell detectado (user=%user.name container=%container.id)"
  priority: WARNING

אינטגרציה באמצעות webhook של Kubernetes לצורך quarantine אוטומטי.

6. הערכה ניסויית

סביבה:

• 48 nodes (8 vCPU, 32GB RAM each)
• 1.200 pods
• Dataset: 300 ataques simulados (Atomic Red Team adapted for containers)

תוצאות:

• שיעור זיהוי: 96,4% (±1,2%)
• false positives: 3,1%
• השהיה ממוצעת: 420 ms
• Overhead CPU: 4,8%
• Overhead זיכרון: 3,2%

השוואה:

Falco לבדו: 89% זיהוי
Suricata לבדה: 72%
הגישה שלנו: 96,4%

7. מחקר מקרה

הדמינו פשרה באמצעות יישום פגיע (Log4Shell adapted). שלבים:

1. ניצול RCE.
2. ביצוע bash אינטראקטיבי.
3. ניסיון קריאה של /proc/kcore.
4. סריקה רוחבית.

המערכת זיהתה T1611 ב-380 ms ובודדה את ה-pod באמצעות label quarantine=true.

לקחים:

• אינסטרומנטציה של syscall היא קריטית.
• RBAC שמוגדר בצורה שגויה מרחיב את ההשפעה.

8. דיון

התוצאות מצביעות על כך ששילוב רב-שכבתי מפחית משמעותית את ה-MTTD. המגבלות כוללות תלות באיכות הכללים וצורך בכיול הסף $\theta$.

תוקף חיצוני: סביבה מבוקרת; תקיפות zero-day עלולות לעקוף את המערכת.

המלצה תפעולית:

• להפעיל PodSecurityStandards.
• לממש NetworkPolicies מגבילות.
• לשלב סריקה רציפה (Trivy + CI/CD).

9. סיכום ועבודה עתידית

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

REFERENCES

COMBE, Theo; MARTIN, Antony; DI PIETRO, Roberto. To Docker or Not to Docker: A Security Perspective. IEEE Cloud Computing, v. 3, n. 5, p. 54-62, 2016. Available at: https://doi.org/10.1109/MCC.2016.100. Accessed on: 13 Apr. 2026.

MERKEL, Dirk. Docker: Lightweight Linux Containers for Consistent Development and Deployment. Linux Journal, n. 239, 2014. Available at: https://dl.acm.org/doi/10.5555/2600239.2600241. Accessed on: 13 Apr. 2026.

SHU, Ren et al. A Study of Security Vulnerabilities on Docker Hub. Proceedings of ACM CODASPY, p. 269-280, 2017. Available at: https://doi.org/10.1145/3029806.3029832. Accessed on: 13 Apr. 2026.

OPEN CONTAINER INITIATIVE. runc CVE-2019-5736 Advisory, 2019. Available at: https://github.com/opencontainers/runc/issues/2128. Accessed on: 13 Apr. 2026.

MITRE. ATT&CK for Containers Matrix, 2023. Available at: https://attack.mitre.org/matrices/enterprise/containers/. Accessed on: 13 Apr. 2026.

CNCF. CNCF Annual Survey 2023. Available at: https://www.cncf.io/reports/cncf-annual-survey-2023/. Accessed on: 13 Apr. 2026.

[שאר ההפניות הושמטו בשל מגבלת מקום בגרסה מקוצרת זו.]