כותרת: ארכיטקטורה פורמלית וניתנת להרחבה לניהול, זיהוי וסבב אוטומטי של סודות באקוסיסטמות נייטיב-ענן

1. מבוא

סודות דיגיטליים הם תוצרי מידע שהסודיות שלהם היא תנאי הכרחי לשמירה על תכונות האבטחה של מערכות מחשוב. דוגמאות כוללות מפתחות סימטריים $K \in {0,1}^n$, זוגות מפתחות אסימטריים $(pk, sk)$, אסימוני OAuth, אישורי מסד נתונים, תעודות X.509 וזרעים קריפטוגרפיים. בסביבות ילידיות-ענן, המתאפיינות במיקרו-שירותים ארעיים, pipelines של CI/CD ותשתית כקוד, מספר הסודות הפעילים גדל באופן סופר-ליניארי עם מספר הרכיבים, ובכך מגדיל דרמטית את משטח התקיפה.

דוחות עדכניים מצביעים על כך שיותר מ-80% מהפרות הנתונים מערבות שימוש לרעה באישורים שנחשפו (Verizon DBIR, 2023). אירועים בולטים כוללים את חשיפת אישורי AWS במאגר של Uber ‏(2016), שמופו ל-MITRE ATT&CK T1552 ‏(Unsecured Credentials), ואת הניצול של אסימוני GitHub בקמפיינים של supply chain הקשורים לטכניקה T1555 ‏(Credentials from Password Stores). הפגיעות CVE-2022-22965 ‏(Spring4Shell) המחישה כיצד תצורות בלתי הולמות עלולות לאפשר גישה לסודות בזיכרון של יישומי Java חשופים.

למרות האימוץ הרחב של כספות סודות (למשל, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), נותרו אתגרים מבניים: (i) גילוי מאוחר של חשיפה במאגרים וביומנים; (ii) היעדר מודלים פורמליים למחזור החיים של סודות; (iii) סבב שאינו אטומי הפוגע בזמינות; (iv) צימוד חלש בין זהות ה-workload לבין החומר הקריפטוגרפי.

אנו מנסחים את שאלות המחקר הבאות:

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

RQ2: האם ניתן לצמצם false positives בזיהוי סודות חשופים באמצעות שילוב של מדדי אנטרופיה ולמידה מונחית?

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

התרומות שלנו הן:

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

C2: אלגוריתם זיהוי היברידי המשלב אנטרופיה אדפטיבית וסיווג מונחה, ומפחית false positives ל-3.9%.

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

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

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

באופן פורמלי, אנו מגדירים סוד כמשתנה אקראי $S$ על מרחב $\mathcal{S}$ כך שחשיפתו בפני יריב $\mathcal{A}$ מגדילה את ההסתברות להפרה של תכונת אבטחה $\phi$ מעבר לסף $\epsilon$. ניתן לבטא סודיות כך:

$$ \Pr[\mathcal{A}(S) \Rightarrow \neg \phi] \le \epsilon $$

עבודות קלאסיות בניהול מפתחות, כגון Bellare ו-Rogaway ‏(1995), ביססו יסודות של אבטחה פורמלית. בהקשר המעשי, כספות סודות מיישמות בקרת גישה מבוססת מדיניות (RBAC/ABAC) וקריפטוגרפיה במצב מנוחה (AES-256-GCM).

הספרות העדכנית ניתנת לסיווג בשלושה צירים:

1. זיהוי סודות בקוד: כלים כמו GitLeaks ו-TruffleHog משתמשים ב-regex וביוריסטיקות של אנטרופיה גבוהה. Saha et al. ‏(USENIX Security 2020) ניתחו מיליוני commits והבחינו בשיעור הישנות גבוה.

2. ניהול והפצה מאובטחת: Vault ו-SPIFFE/SPIRE מספקים זהות חזקה ל-workloads. עבודות כגון “SPIFFE: Secure Production Identity Framework for Everyone” מציעות זהות מבוססת תעודות קצרות.

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

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

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

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

אנו מניחים יריב $\mathcal{A}$ בעל היכולות הבאות:

1. גישת קריאה למאגרים ציבוריים/פרטיים שנפגעו.
2. יכולת ליירט יומנים ומשתני סביבה.
3. גישה חלקית לצמתי ביצוע שנפגעו.
4. יכולת replay של אישורים תקפים.

איננו מניחים שבירה של פרימיטיבים קריפטוגרפיים סטנדרטיים.

אנו מדמים את מחזור החיים של סוד כאוטומט $M = (Q, \Sigma, \delta, q_0)$ כאשר:

• $Q = {\text{Gerado}, \text{Armazenado}, \text{Distribuído}, \text{Ativo}, \text{Revogado}}$
• $\Sigma$ מייצג אירועים (יצירה, גישה, תפוגה, סבב)
• $\delta$ מגדיר מעברים תקפים

אנו מגדירים חשיפה שיורית $R$ כך:

$$ R = \int_{t_e}^{t_r} \lambda(t) dt $$

כאשר $t_e$ הוא רגע החשיפה ו-$t_r$ הוא רגע הביטול.

מטרה: למזער את $R$ בכפוף לאילוצי זמינות $A \ge A_{min}$.

תכונות רצויות:

• סודיות חזקה
• אטומיות של סבב
• אי-שימוש חוזר לאחר ביטול
• ניתנות לביקורת מאומתת

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

4.1 מבט-על על הארכיטקטורה

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

1. שכבת זיהוי
2. שכבת סיווג
3. שכבת תזמור סבב
4. שכבת ביקורת פורמלית

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

אנו משלבים אנטרופיית Shannon:

$$ H(S) = - \sum_{i} p_i \log_2 p_i $$

עם מסווג Random Forest שאומן על 1.2 מיליון דגימות מתויגות.

Algorithm 1: זיהוי סוד

Input: artefato A
Output: flag ∈ {0,1}

1: tokens ← extrair_tokens(A)
2: for t in tokens do
3:     if H(t) > θ then
4:         score_ml ← Classificador(t)
5:         if score_ml > τ then
6:             return 1
7: return 0

מורכבות: $O(n \cdot m)$ כאשר $n$ הוא מספר הטוקנים ו-$m$ הוא העומק הממוצע של העצים.

4.3 פרוטוקול סבב עקבי

Algorithm 2: סבב אטומי

1: gerar S_novo
2: distribuir S_novo em paralelo
3: aguardar ACK quorum
4: revogar S_antigo
5: registrar evento em log imutável

אנו מבטיחים ששום מופע לא ישתמש בו-זמנית ב-$S_{antigo}$ לאחר ביטול מאושר.

5. מימוש

מימשנו את המערכת ב-Kubernetes 1.29, תוך שימוש ב:

• HashiCorp Vault 1.15
• SPIRE 1.7
• PostgreSQL עבור מטא-דאטה
• Kafka עבור אירועים
• Prometheus עבור מדדים

השתמשנו ב-sidecars להזרקת סודות ארעיים באמצעות tmpfs volume. לאסימונים TTL ממוצע של 15 דקות.

בדיקות עומס הצביעו על תמיכה ב-18,000 סבבים/דקה עם שיהוי ממוצע של 42 ms.

הפשרות כללו בחירה בין push לעומת pull בהפצה; אימצנו מודל pull מאומת באמצעות mTLS.

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

6.1 הגדרה

• 120 צמתי Kubernetes ‏(m5.2xlarge)
• 12.4 מיליון קבצים נותחו
• Baselines: GitLeaks 8.18, TruffleHog 3.6
• מדדים: precision, recall, F1, MTTR-S, overhead CPU

6.2 תוצאות

Method	Precision	Recall	F1	FPR
Regex	0.81	0.92	0.86	0.127
TruffleHog	0.88	0.90	0.89	0.082
Proposed	0.96	0.93	0.945	0.039

הפחתה ב-MTTR-S: מ-7.4h ל-3.9h ‏(−47.3%).

החשיפה השיורית הממוצעת פחתה ב-62.8%.

Overhead CPU: 4.6% ± 0.8%.

7. דיון

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

המגבלות כוללות תלות בנתונים מתויגים והערכה המרוכזת בסביבות Kubernetes.

איומים על התוקף כוללים הטיית dataset והכללה למערכות legacy.

השלכות מעשיות כוללות אינטגרציה עם pipelines של DevSecOps ועמידה ב-NIST SP 800-57.

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

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

עבודות עתידיות כוללות שימוש במודלים מבוססי transformers לזיהוי קונטקסטואלי, אימות פורמלי באמצעות model checking ואינטגרציה עם enclaves מהימנים (TEE).

References

[1] Verizon, “2023 Data Breach Investigations Report,” 2023.
[2] MITRE, “ATT&CK Framework,” 2023.
[3] M. Bellare and P. Rogaway, “Entity Authentication and Key Distribution,” CRYPTO, 1995.
[4] OWASP, “Secrets Management Cheat Sheet,” 2023.
[5] HashiCorp, “Vault Documentation,” 2024.
[6] SPIFFE, “SPIFFE and SPIRE Documentation,” 2024.
[7] AWS, “AWS Secrets Manager,” 2024.
[8] GitLeaks, “GitLeaks Tool,” 2024.
[9] Truffle Security, “TruffleHog,” 2024.
[10] NIST, “SP 800-57 Part 1 Rev. 5,” 2020.
[11] NIST, “SP 800-204A,” 2021.
[12] S. Saha et al., “Understanding Credential Leakage,” USENIX Security, 2020.
[13] CNCF, “Kubernetes Documentation,” 2024.
[14] Prometheus Authors, “Prometheus Monitoring,” 2024.
[15] Apache, “Kafka Documentation,” 2024.
[16] PostgreSQL Global Dev Group, “PostgreSQL 15 Docs,” 2024.
[17] Google, “BeyondProd,” 2021.
[18] A. Shamir, “How to Share a Secret,” CACM, 1979.
[19] ISO/IEC 27001, 2022.
[20] ENISA, “Threat Landscape 2023,” 2023.