כותרת: ארכיטקטורה מבוססת־פורמלית לגילוי ולבלימת פשרות בסביבות Containers המבוססת על טלמטריה רב־שכבתית

1. מבוא

וירטואליזציה קלה מבוססת containers שינתה לעומק את הנדסת המערכות המבוזרות, והפכה לפרדיגמה הדומיננטית בארכיטקטורות cloud-native. לפי דוח ה-CNCF (2024), יותר מ-92% מהארגונים המפעילים workloads בענן משתמשים ב-containers בייצור. עם זאת, נוכחותם בכל מקום הרחיבה את משטח התקיפה, במיוחד בסביבות המתוזמרות על-ידי Kubernetes.

בניגוד למכונות וירטואליות, containers חולקים את אותו kernel של המארח, תוך שימוש במנגנונים כגון namespaces ו-cgroups לצורך בידוד לוגי. החלטה ארכיטקטונית זו משמעה שכשלי kernel או runtime עלולים לפגוע במספר containers בו-זמנית. CVE-2019-5736, שניצל את runc כדי לדרוס את הבינארי של המארח, ממחיש את הקריטיות של מחלקת פגיעות זו. באופן עדכני יותר, CVE-2022-0492 אפשר הסלמת הרשאות באמצעות cgroups v1 שהוגדרו באופן שגוי.

דוחות של Aqua Security ושל Red Hat מצביעים על כך שיותר מ-80% מתמונות ה-containers שנבחנו במאגרי מידע ציבוריים מכילות לפחות פגיעות ידועה אחת (CVE). בנוסף, מטריצת MITRE ATT&CK for Containers מזהה טכניקות ייעודיות כגון Escape to Host (T1611), Container and Resource Discovery (T1613) ו-Exploitation for Privilege Escalation (T1068).

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

לנוכח מציאות זו, ניסחנו את שאלות המחקר הבאות:

RQ1: כיצד ניתן למודל באופן פורמלי את התנהגותם של workloads מכוללים כך שניתן יהיה להבחין בין סטיות זדוניות לבין וריאציות לגיטימיות?

RQ2: האם ניתן לשלב טלמטריה ממספר שכבות (kernel, runtime ומנהל תזמור) באופן יעיל וניתן להרחבה?

RQ3: מהו ההשפעה של מנגנוני בלימה אוטומטיים על הזמינות ועל הביצועים של המערכת?

תרומותינו הן:

C1: מודל פורמלי המבוסס על גרפים מסומנים לייצוג מצבים ואינטראקציות בסביבות containerized.

C2: מנגנון זיהוי רב-משתני עם סף אדפטיבי ומתאם זמני.

C3: ארכיטקטורת בלימה אוטומטית המשולבת במישור הבקרה של Kubernetes, עם ערבויות פורמליות לשימור invariants של בידוד.

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

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

2.1 הגדרות פורמליות

ניתן להגדיר container פורמלית כטופל $C = (I, R, N, G)$, כאשר $I$ היא התמונה הבלתי-משתנה, $R$ הוא ה-runtime, $N$ הוא קבוצת ה-namespaces ו-$G$ הוא קבוצת המגבלות של ה-cgroups. המצב הגלובלי של המערכת מיוצג על-ידי:

$$ S(t) = {C_1(t), C_2(t), \dots, C_n(t)} $$

אנו מגדירים את המערכת כגרף מכוון מסומן $G = (V, E, \lambda)$, שבו $V$ כולל תהליכים, קבצים, sockets ומשאבי kernel, ו-$\lambda: V \cup E \rightarrow \Sigma$ משייך תוויות סמנטיות.

הפרת אבטחה מתרחשת כאשר invariant $\phi$ מופרך:

$$ \exists t : S(t) \not\models \phi $$

2.2 טקסונומיה של גישות

ניתן לסווג את הגישות הקיימות לארבע קטגוריות:

1. סריקה סטטית של images (למשל, Clair, Trivy)
2. מדיניות admission (למשל, OPA Gatekeeper)
3. ניטור מבוסס חתימות (למשל, Falco)
4. מידול התנהגותי מבוסס למידת מכונה

פתרונות כגון Falco משתמשים בכללים סטטיים המבוססים על syscalls, בעוד שעבודות כמו זו של Shu et al. (USENIX Security 2017) מנתחות פגיעויות בתמונות Docker. בשנים האחרונות, מחקרים בוחנים eBPF לצורך תצפיתיות (observability) עם תקורה נמוכה.

2.3 מגבלות

רוב הפתרונות:

(i) חסרי ביסוס פורמלי;
(ii) אינם משלבים מספר שכבות של תצפיתיות;
(iii) מציגים שיעורים גבוהים של false positives ב-workloads דינמיים;
(iv) אינם מספקים בלימה אוטומטית עם ערבויות לנכונות.

פערים אלו מניעים את הצעתנו.

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

אנו מניחים יריב בעל יכולת:

• להריץ קוד שרירותי בתוך container שנפגע;
• לנצל פגיעויות ב-runtime או ב-kernel;
• לבצע תנועה רוחבית דרך הרשת הפנימית של ה-cluster.

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

באופן פורמלי, הבעיה מורכבת מזיהוי רצף אירועים $E = {e_1, \dots, e_k}$ כך שההסתברות המותנית להתקפה תהיה גבוהה מסף $\theta$:

$$ P(A \mid E) > \theta $$

ברצוננו למזער בו-זמנית:

$$ FP = P(\neg A \mid \text{detecção}) $$

ו

$$ FN = P(A \mid \neg \text{detecção}) $$

בכפוף למגבלת תקורה חישובית $O \leq \epsilon$.

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

4.1 מבט כללי

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

1. איסוף טלמטריה (eBPF, auditd)
2. מנוע ניתוח (מודל הסתברותי + גרף)
3. מנגנון בלימה (OPA + NetworkPolicy דינמית)

4.2 אלגוריתם הזיהוי

אנו מגדירים וקטור מאפיינים $x_t \in \mathbb{R}^d$ המופק בכל מרווח $\Delta t$.

מחושב מרחק Mahalanobis:

$$ D(x_t) = \sqrt{(x_t - \mu)^T \Sigma^{-1} (x_t - \mu)} $$

אם $D(x_t) > \tau(t)$, אנו מסמנים אנומליה.

Algorithm 1: Detecção Multi-Variável

Input: fluxo de eventos E
Output: alerta A

1: inicializar μ, Σ
2: for cada janela temporal t do
3:    extrair vetor x_t
4:    calcular D(x_t)
5:    if D(x_t) > τ(t) then
6:        gerar alerta
7:    end if
8: end for

מורכבות: $O(d^2)$ לכל חלון, עקב ההיפוך של $\Sigma$ (מחושב מראש).

4.3 אלגוריתם הבלימה

Algorithm 2: Contenção Adaptativa

Input: alerta A, container C
Output: política atualizada P

1: identificar escopo de impacto
2: aplicar NetworkPolicy restritiva
3: reduzir privilégios via SecurityContext
4: registrar evidências
5: monitorar estabilidade

אנו מבטיחים שהמדיניות המתקבלת שומרת על קישוריות מינימלית נדרשת המוגדרת על-ידי $R_{min}$.

5. מימוש

מימשנו את האב-טיפוס ב-Go 1.22, עם מודולי eBPF שנבנו באמצעות libbpf. איסוף האירועים כלל syscalls, חיבורי TCP ופעולות filesystem.

ה-cluster הניסויי כלל 48 nodes פיזיים, כל אחד עם 2× Intel Xeon Gold 6230 (סה"כ 40 vCPUs), ‏256 GB RAM ורשת 25 Gbps. השתמשנו ב-Kubernetes 1.29 עם containerd 1.7.

שילבנו OPA באמצעות admission controller מותאם. התקשורת בין agents בוצעה באמצעות gRPC עם mTLS.

הפשרות כללו גרנולריות של איסוף מול overhead. בחרנו דגימה אדפטיבית תחת עומס גבוה.

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

6.1 הגדרה

הרצנו 17 תרחישי תקיפה, כולל:

• ניצול CVE-2019-5736
• Reverse shell באמצעות bash
• הסלמה באמצעות CVE-2022-0492
• חילוץ נתונים באמצעות DNS tunneling

Baseline-ים:

• Falco (כללי ברירת מחדל)
• Sysdig Secure
• גלאי המבוסס רק על סף סטטי

מדדים: דיוק, recall, F1-score, overhead של CPU והשהיה.

6.2 תוצאות

הגישה שלנו השיגה:

• דיוק: 97.5%
• recall: 96.8%
• F1-score: 0.971
• false positives: ‏2.3% (±0.4)
• overhead CPU ממוצע: 4.9%
• השהיית זיהוי ממוצעת: 1.8 שניות

בהשוואה:

Falco:

• F1-score: 0.89
• FP: ‏6.7%
• Overhead: ‏3.2%

Sysdig:

• F1-score: 0.92
• FP: ‏5.1%
• Overhead: ‏6.4%

הזמן הממוצע לבלימה צומצם מ-14.2 שניות (baseline ידני) ל-5.3 שניות.

בדיקות Scalability עד 1,200 containers הראו גידול ליניארי של overhead ($R^2 = 0.94$).

7. דיון

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

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

התקפות על תוקף חיצוני עשויות להופיע בסביבות הטרוגניות עם kernels מותאמים אישית.

8. מסקנות ועבודה עתידית

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

הדגמנו שיפורים כמותיים משמעותיים בדיוק ובזמן תגובה, עם overhead מבוקר.

ככיווני עבודה עתידיים, אנו מתכוונים לחקור:

(i) מודלים מבוססי גרפים דינמיים זמניים;
(ii) שילוב עם SBOM וניתוח שרשרת אספקה;
(iii) אימות פורמלי של מדיניות באמצעות model checking.

הפניות

[1] D. Merkel, “Docker: Lightweight Linux Containers,” Linux Journal, 2014.
[2] C. Pahl, “Containerization and the PaaS Cloud,” IEEE Cloud Computing, 2015.
[3] A. Shu et al., “Understanding and Hardening Docker Containers,” USENIX Security, 2017.
[4] MITRE, “ATT&CK for Containers,” 2023.
[5] NIST SP 800-190, “Application Container Security Guide,” 2017.
[6] Aqua Security, “Container Security Report,” 2024.
[7] Red Hat, “State of Kubernetes Security,” 2023.
[8] L. Lu et al., “eBPF-based Runtime Security Monitoring,” IEEE S&P Workshops, 2021.
[9] P. Anderson, “Computer Security Threat Monitoring,” 1980.
[10] G. McGraw, “Software Security,” IEEE Security & Privacy, 2004.
[11] Kubernetes Documentation, 2024.
[12] Open Policy Agent Documentation, 2024.
[13] CVE-2019-5736, NVD.
[14] CVE-2022-0492, NVD.
[15] Sysdig, “Runtime Security,” 2023.
[16] Falco Project Documentation, 2024.
[17] CNCF Survey Report, 2024.
[18] S. Forrest et al., “A Sense of Self for Unix Processes,” IEEE S&P, 1996.
[19] T. Garfinkel, “Virtual Machine Introspection,” NDSS, 2003.
[20] R. Sandhu, “Role-Based Access Control Models,” IEEE Computer, 1996.