אבטחת תשתיות ענן ב-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.
מאמרים ושירותים קשורים
FAQ
מה זה Zero Trust ולמה זה לא רק buzzword?
Zero Trust הוא ארכיטקטורה שמניחה שאין רשת פנימית בטוחה — כל בקשה מאומתת מחדש ללא קשר למיקום. המימוש האמיתי דורש workload identity (SPIFFE/SPIRE או cloud-native equivalents), Policy-as-Code (OPA, Kyverno), ו-continuous verification מתמשך. ההבדל בין vendor שצועק 'Zero Trust' לבין מימוש אמיתי הוא בנוכחות של שלושת הרכיבים האלה.
למה כולם מדברים על eBPF?
eBPF מאפשר טעינת תוכניות קטנות ישירות לתוך ה-Linux kernel ובכך מקבל visibility מלא ל-syscalls, network, file I/O בלי agent חיצוני. זה משנה את האבטחה ברמת runtime: במקום להריץ EDR כבד עם performance penalty, אפשר לקבל kernel-level visibility ב-overhead מינימלי. Falco, Tetragon, Cilium ו-Datadog Cloud Security כולם מבוססי eBPF.
מה זה SBOM ולמה אני צריך אחד?
SBOM (Software Bill of Materials) הוא רשימה מובנית של כל תלות שהמערכת שלכם משתמשת בה — open-source libraries, container base images, runtime dependencies. הפורמטים הסטנדרטיים: SPDX ו-CycloneDX. אחרי SolarWinds ו-log4j רגולציות (כמו CISA Executive Order בארה״ב) מחייבות SBOM למוכרים לממשל, וזה זולג במהירות לסקטור הפרטי. ארגונים בריאים מייצרים SBOM אוטומטית בכל build.
Container scanning ב-CI מספיק?
לא. scanning מזהה רק vulnerabilities ידועים בזמן ה-build, ולא תופס zero-day, lateral movement, או תהליך שלא expected ב-runtime. צריך גם runtime detection (Falco, Tetragon) שעובד עם eBPF ומאתר התנהגות חריגה ברמת ה-kernel. החלוקה: CI scanning הוא prevention, runtime detection הוא response.
ארגון ישראלי קטן צריך את כל זה?
תלוי בסיכון העסקי. ארגון עם נתוני לקוחות רגישים, או שמפיץ תוכנה ללקוחות אחרים, או שעובד עם חוזים ארגוניים שדורשים SOC 2 — צריך את כל הסטאק. סטארטאפ ב-pre-revenue יכול להתחיל ממינימום: SSO + MFA, workload identity דרך cloud-native, secret management בסיסי, ו-CSPM. את ה-runtime ואת supply-chain attestation מוסיפים בשלב מאוחר יותר.