אבטחת תשתיות ענן ב-2026: מ-Zero Trust ועד eBPF
22/05/2026

אבטחת תשתיות ענן ב-2026 נראית אחרת לגמרי מ-2020. אז דיברנו על "Cloud Security" כעל firewalls וירטואליים, על Cloud Security Posture Management (CSPM) ועל שמירה על תצורות נכונות. היום הדיון עבר לתשתית עמוקה יותר: workload identity, runtime security ב-eBPF, supply-chain attestation, ו-Zero Trust שעבר מ-buzzword לארכיטקטורה. במאמר הזה נסכם איפה הסטנדרט המקצועי עומד היום, ואיפה רוב הצוותים עדיין מפגרים.
Zero Trust — מ-buzzword לתשתית
Zero Trust הפך למילה שכל vendor שיווק מנופף בה, ובאופן פרדוקסלי איבד משמעות. בפועל, מימוש אמיתי דורש שלושה מרכיבים:
1. Identity-centric access — כל בקשה (אדם → שירות, שירות → שירות, שירות → DB) חייבת לשאת זהות מאומתת. לא IP, לא subnet, לא VPN. בענן זה אומר SPIFFE/SPIRE עבור workload identity, או שילוב של cloud-native: AWS IAM Roles for Service Accounts (IRSA), GCP Workload Identity, Azure AD Pod Identity.
2. Least privilege ברמת ה-call — כל זהות מקבלת הרשאה לפעולה ספציפית על משאב ספציפי, ולא role רחב. כלי standar: Open Policy Agent (OPA), Kyverno, AWS Cedar.
3. Continuous verification — שינוי תצורה (קונטיינר אחר, version אחר) מתחיל מחדש את הבחינה. לא "התחברת פעם אחת, הכל בסדר". כאן eBPF נכנס לתמונה — בקבלה רציפה של signals מהמערכת.
הצוותים שכבר עברו את הקפיצה הזו ב-2026 ראו ירידה של 70%+ בהיקף ה-lateral movement בתרחישי תקיפה (ירידה שנמדדה בעיקר ב-red-team exercises של חברות ביטחוניות וקיבר).
ארבע שכבות הגנה שכל מערכת ענן צריכה
לא קוד מתחת, לא מעל. סדר השכבות הוא קריטי:
- Identity & access — IAM, SSO, MFA, workload identity. אם זה לא חזק, הכל מעליו דליף.
- Network segmentation — לא VPC isolation לבד. micro-segmentation עם service mesh (Istio, Linkerd) או cilium-based policies.
- Secrets management — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault. בתוך הקוד צריך להיעלם כל secret hardcoded. ב-2026 זה כבר standard, אבל באודיטים שאנחנו עושים — עדיין מוצאים secrets ב-environment variables ב-CI/CD pipelines.
- Runtime security — Falco, Tetragon, Datadog Cloud Security, Wiz. eBPF הוא הטכנולוגיה שמאפשרת observation בלי agent — kernel-level visibility למה רץ, מתי, ועם איזה syscalls.
Container & Kubernetes: השינוי הגדול — eBPF
ב-2024–2025 הקהילה התכנסה סביב eBPF (extended Berkeley Packet Filter) כ-foundation לאבטחת runtime ב-Linux. במקום להריץ agent כבד שצורך מעבד ויוצר טביעת רגל גדולה, eBPF טוען תכניות קטנות ישירות לתוך ה-kernel ומקבל visibility מלא ל-syscalls, network packets, file I/O, ו-process tree — ב-overhead מינימלי.
הסטאק הסטנדרטי לאבטחת Kubernetes ב-2026:
- Pod Security Standards (PSS) — מחליף את Pod Security Policies. Restricted profile כברירת מחדל.
- OPA / Kyverno — Policy-as-Code: שכבת policies שמונעת deployments שלא עומדים בסטנדרט הארגוני.
- Falco או Tetragon — runtime detection ב-eBPF. "תהליך docker-runc יצא תהליך שהוא לא expected — alert".
- Cilium — networking-as-policy. Network policies שלא נשענות על iptables אלא על eBPF.
- Sigstore + Cosign — image signing ו-verification בתוך admission controller. רק images חתומים מורשים לרוץ.
הטעות הנפוצה: לחשוב ש-image scanning ב-CI מספיק. הוא לא — vulnerability יכול להיכנס בין scan ל-deploy, ו-zero-day לא מזוהה ב-scan כי הוא לא ידוע. צריך גם runtime.
Supply Chain Security — הסכנה הגדולה החדשה
אחרי SolarWinds, log4j ו-XZ Utils, supply-chain אבטחה הפכה מ-"good to have" ל-mandatory בפרויקטים ארגוניים. הסטנדרטים החדשים:
- SLSA (Supply-chain Levels for Software Artifacts) — framework של Google שמדרג רמות אבטחה של build pipeline. SLSA Level 3 הוא היעד הסביר ל-2026.
- SBOM (Software Bill of Materials) — רשימה מובנית של כל תלות שהמערכת משתמשת בה. SPDX או CycloneDX הם הפורמטים. CISA Executive Order מחייב SBOMs בכל מערכת שמכרים לממשל אמריקאי, וזה זולג לסקטור הפרטי.
- Sigstore — תשתית open-source לחתימת artifacts ולאימות. cosign, fulcio, rekor.
- Dependency monitoring — Snyk, GitHub Dependabot, Renovate. אבל לא רק לאתר vulnerabilities — גם לזהות packages חשודים (typosquatting, malicious updates).
iGates עובדת עם לקוחות תעשייתיים שדורשים SBOM כחלק מהמסירה. הקפיצה ה-DevOps שצריכה לקרות זה לעבור מ-"build artifacts" ל-"signed, verifiable, traceable artifacts".
Multi-cloud — אתגרים שלא מדברים עליהם
עוד lock-in רוב הארגונים כבר חיים בו: workload-ים ב-AWS, identity ב-Azure AD, monitoring ב-Datadog, secrets ב-Vault שרץ on-prem. multi-cloud הוא לא הצהרה — הוא ה-default. הבעיות:
- Inconsistent policies — מה שהוגדר ב-AWS IAM לא רלוונטי ל-GCP. כל cloud עם DSL משלו.
- Cross-cloud workload identity — שירות ב-AWS שצריך לקרוא ל-resource ב-GCP. הפתרון הפרקטי: workload federation או SPIFFE, אבל מימוש מורכב.
- Visibility מאוחדת — Cloud Security Posture Management (CSPM) tools (Wiz, Orca, Prisma Cloud) עוזרים, אבל היקרים ולא תמיד מסונכרנים עם cloud-native.
- Compliance multi-jurisdictional — GDPR ב-EU, חוק הגנת הפרטיות החדש בישראל, CCPA בקליפורניה, SOC 2 לכולם. data residency הופך לבעיה ארכיטקטונית, לא רק משפטית.
הקשר הישראלי
תעשיית הסייבר הישראלית היא מהמובילות בעולם — חברות כמו Wiz, Orca, Aqua, Snyk (mostly Israeli founding teams) הגדירו את הסטנדרטים שכל הקהילה מאמצת. בפועל, רמת ה-baseline בארגונים ישראליים גבוהה יחסית: רוב הצוותים שאנחנו רואים כבר משתמשים ב-CSPM, רובם עם MFA על כל user, וחלק נכבד עם Vault או secrets manager.
הפער ב-2026 הוא לא בידע — הוא ב-mature implementation. הרבה ארגונים מכירים את הכלים אבל לא הגיעו לשלב שבו policies הם as-code, ש-runtime monitoring רץ ב-production, וש-supply-chain attestation הוא תנאי מקדים ל-deploy. הקפיצה הזו היא מה שמבדיל בין מערכת מאובטחת ל-mature, לבין מערכת שעוברת ביקורת בזכות checkbox.
סיכום
אבטחת ענן ב-2026 היא תהליך הנדסי רציף, לא יוזמה חד-פעמית. הצוותים שמצליחים בונים את ארבע השכבות (identity, network, secrets, runtime), עוברים ל-eBPF-based monitoring ב-Kubernetes, ומכניסים supply-chain attestation לתוך ה-CI/CD pipeline. ב-iGates אנחנו עוזרים ללקוחות לעבור מ-baseline ל-mature implementation — מערכת שיכולה לעמוד ב-audit אמיתי, לא רק ב-checkbox.