מדריך

תכנון אסטרטגיית אבטחה הוליסטית של ענן נייטיב.

→יישם בקרות אבטחה על פני ארבעת ה-C-ים: Cloud (יסוד), Cluster, Container ו-Code.

למה: פגיעה בשכבה חיצונית (לדוגמה, Cloud) מערערת את האבטחה של כל השכבות הפנימיות. האבטחה חזקה כחולייתה החלשה ביותר.

מקור↗

הגנה מפני כשלים ביטחוניים בנקודה בודדת.

→יישם בקרות אבטחה מרובות וחופפות בשכבות שונות (לדוגמה, NetworkPolicies, RBAC, Security Contexts).

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

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

→יישם מודל "לעולם אל תאמין, תמיד ודא". אימות ואישור כל בקשה, לרוב באמצעות service mesh עבור mTLS.

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

הגבלת רדיוס הפיצוץ של זהות או רכיב שנפרצו.

→הענק לכל הנבדקים (משתמשים, service accounts, nodes) רק את ההרשאות המינימליות הנדרשות לביצוע תפקידם.

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

הפחתת העלות וההשפעה של חולשות אבטחה.

→שלב סריקות אבטחה אוטומטיות (SAST, SCA, image scanning) ובדיקות מדיניות בשלבים המוקדמים של pipeline ה-CI/CD.

למה: מוצא ומתקן חולשות מוקדם יותר במחזור חיי הפיתוח, כאשר הן הכי זולות לתיקון.

הגנה על נתוני קלאסטר רגישים (במיוחד Secrets) אם אחסון ה-etcd נפרץ.

→ב-kube-apiserver, השתמש ב-`--encryption-provider-config` כדי לאפשר הצפנה במנוחה (at rest) עבור משאבים לפני שהם נשמרים ב-etcd.

למה: כברירת מחדל, Kubernetes Secrets מקודדים ב-base64 בלבד ב-etcd. זה מספק הצפנה אמיתית על הדיסק.

מקור↗

מניעת גישה בלתי מורשית וציתות לתקשורת etcd.

→הגדר את etcd עם mTLS עבור תקשורת לקוח (`--client-cert-auth`) וגם עמית (`--peer-client-cert-auth`).

למה: מבטיח שרק רכיבים מאומתים (apiserver, חברי etcd אחרים) יכולים לתקשר עם etcd ושהתעבורה מוצפנת.

מניעת גישה לא מאומתת לשרת ה-API של Kubernetes.

→הגדר את הדגל `--anonymous-auth=false`. השתמש בשיטות אימות חזקות כמו OIDC או תעודות x509.

למה: משבית את המשתמש `system:anonymous`, ואוכף שכל הבקשות יאומתו ויתועדו כנגד זהות ספציפית.

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

→אפשר רישום ביקורת (audit logging) של שרת ה-API עם `--audit-policy-file` ושלח את היומנים למערכת רישום חיצונית ובלתי ניתנת לשינוי.

למה: מספק עקבות חיוניות ועמידות בפני שינויים לחקירת אירועים, ציד איומים וביקורות תאימות.

מקור↗

הפחתת שטח התקיפה של צומתי עבודה (worker nodes).

→הגדר את דגלי kubelet: `--anonymous-auth=false`, `--authorization-mode=Webhook`, ו-`--read-only-port=0`.

למה: זה אוכף שכל הבקשות ל-API של kubelet מאומתות ומורשות על ידי ה-API server ומשבית את יציאת הקריאה בלבד הלא מאובטחת והלא מאומתת.

מניעת דליפת מידע מרכיבי control plane.

→הגדר את הדגל `--profiling=false` ב-kube-apiserver, kube-controller-manager, ו-kube-scheduler בסביבת ייצור.

למה: נקודות קצה של פרופילים (Profiling endpoints) יכולות לחשוף נתוני ביצועים פנימיים ופרטי מערכת שיכולים לסייע לתוקף בביצוע סיור.

הגנה על רכיבי control plane מפני גישת רשת בלתי מורשית.

→השתמש בחוקי חומת אש (קבוצות אבטחה בענן, iptables) כדי להגביל גישה לשרת ה-API (פורט 6443) ול-etcd (פורט 2379) למקורות מהימנים בלבד.

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

הענקת הרשאות למשתמשים או יישומים.

→השתמש ב-`Roles` עם namespace על פני `ClusterRoles`. הענק פעלים ספציפיים (`get`, `list`) במקום תווים כלליים (`*`).

למה: עוקב אחר עקרון ההרשאה המינימלית (least privilege), ומגביל את היקף ההרשאות רק למה שנדרש בתוך namespace ספציפי.

מקור↗

ל-pod אין צורך לתקשר עם ה-API של Kubernetes.

→הגדר `automountServiceAccountToken: false` במפרט ה-pod או ב-ServiceAccount עצמו.

למה: מונע חשיפה של אישורי גישה מיותרים בתוך ה-pod, ומפחית את שטח התקיפה אם ה-pod נפרץ.

אכיפת תצורת אבטחה בסיסית (baseline) לכל ה-pods ב-namespace.

→השתמש בבקר הקבלה (admission controller) המובנה `PodSecurity` על ידי יישום תוויות namespace כמו `pod-security.kubernetes.io/enforce: baseline`.

למה: מספק דרך סטנדרטית ומובנית למנוע תצורות pod מסוכנות (כמו קונטיינרים בעלי הרשאות גבוהות) ללא כלים מצד שלישי.

מקור↗

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

→במפרט ה-pod, הגדר שדות `securityContext`: `runAsNonRoot: true`, `allowPrivilegeEscalation: false`, `readOnlyRootFilesystem: true`.

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

יישום מודל רשת של אפס אמון (zero-trust) בתוך הקלאסטר.

→החל NetworkPolicy של "מניעה כברירת מחדל" (default-deny) לכל namespace הבוחר את כל ה-pods (`podSelector: {}`) ויש לו רשימת כללי ingress/egress ריקה.

למה: התקשורת ברשת Kubernetes היא "אישור כברירת מחדל". מדיניות זו הופכת את המודל ל"מניעה כברירת מחדל", ומכריחה מפתחים לאפשר במפורש תעבורה נדרשת.

מתן אפשרות לתעבורה רק בין שכבות יישומים ספציפיות (לדוגמה, web-to-api).

→צור NetworkPolicies המשתמשות ב-`podSelector` וב-`namespaceSelector` כדי להגדיר כללי ingress ו-egress מדויקים המבוססים על תוויות.

למה: מונע תנועה רוחבית (lateral movement) על ידי תוקפים בכך שמבטיח ש-pod שנפרץ יכול לתקשר רק עם עמיתים המורשים במפורש.

משתמש זקוק להרשאה ל-`kubectl exec` לתוך קונטיינרים לצורך איתור באגים.

→הענק את הפועל `create` על ה-subresource `pods/exec` ב-Role או ClusterRole הרלוונטי.

למה: פעולת `exec` נשלטת באופן לא אינטואיטיבי על ידי הפועל `create` מכיוון שהיא יוצרת סשן exec חדש. זוהי נקודת בלבול נפוצה.

תוקף משיג גישה לקונטיינר ומנסה לפרוץ את צומת המארח.

→אסור קונטיינרים בעלי הרשאות גבוהות (`securityContext.privileged: false`), host namespaces (`hostNetwork`, `hostPID`), וטעינת ה-Docker socket.

למה: תצורות אלו שוברות למעשה את בידוד הקונטיינר, ומעניקות לקונטיינר שנפרץ גישת root-level למארח.

מניעת פריסת תמונות קונטיינר עם חולשות ידועות או קוד זדוני.

→יישם סריקת תמונות (לדוגמה, Trivy) ואימות חתימת תמונה (לדוגמה, Cosign) ב-pipeline ה-CI/CD ובאמצעות admission control.

למה: מספק גישה של הגנה לעומק: סריקה תופסת חולשות ידועות, בעוד חתימה מאמתת את שלמות התמונה ומקוריותה.

תוקף פרץ ל-pod אחד ומנסה לגשת ל-pods אחרים בקלאסטר.

→יישם NetworkPolicies של "מניעה כברירת מחדל" וצור כללי אישור ספציפיים רק לתקשורת pod-to-pod הנדרשת.

למה: מגביל את "קו הראייה" של התוקף מ-pod שנפרץ, ומכיל את הפרצה ומונע את התפשטותה.

מניעת גניבת אישורי IAM של ענן משירות ה-metadata של המופע על ידי pod שנפרץ.

→החל NetworkPolicy של egress "מניעה כברירת מחדל" החוסם במפורש תעבורה ל-IP של ה-metadata (לדוגמה, `169.254.169.254/32`).

למה: זהו נתיב תקיפה נפוץ בסביבות ענן. חסימת נתיב egress זה מפחיתה את הסיכון לגניבת אישורי IAM מ-pods.

הגנה מפני התקפות מניעת שירות (denial-of-service) או cryptojacking המכלות את משאבי הצומת.

→החל אובייקטים של `ResourceQuota` ל-namespaces כדי להגביל את השימוש הכולל במשאבים, ואובייקטים של `LimitRange` כדי לאכוף מגבלות על pods בודדים.

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

תוקף מנסה לשמור על גישה ארוכת טווח לקלאסטר שנפרץ.

→פקח על יצירת `DaemonSets`, `CronJobs`, או pods בעלי הרשאות גבוהות בלתי צפויים. הגבל הרשאות ליצירת משאבים אלו.

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

הבטחת תמונות קונטיינר נקיות מחולשות ידועות לפני הפריסה.

→שלב סורק תמונות כמו Trivy, Clair, או Grype ב-pipeline ה-CI/CD כדי לסרוק תמונות ולכשול את ה-build אם נמצאות חולשות קריטיות.

למה: ממכן את זיהוי החולשות מוקדם ("shift left"), ומונע מקוד פגיע להגיע לייצור.

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

→חתום על תמונות באמצעות כלי כמו Cosign ב-pipeline ה-CI. השתמש בבקר קבלה מאמת (validating admission controller) (לדוגמה, Kyverno, Gatekeeper) כדי לאמת את החתימה בזמן הפריסה.

למה: מספק הוכחה קריפטוגרפית לשלמות התמונה (שלא נעשה בה שינוי) ולמקוריותה (שהגיעה ממקור מהימן).

איתור פעילות זדונית בתוך קונטיינר פועל (לדוגמה, shell שהופעל, גישה לקובץ רגיש).

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

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

אכיפת מדיניות אבטחה מותאמת אישית, ספציפית לארגון (לדוגמה, "כל התמונות חייבות להגיע מה-registry הארגוני שלנו").

→השתמש במנוע מדיניות כמו OPA Gatekeeper או Kyverno כבקר קבלה מאמת כדי לאכוף מדיניות שנכתבה ב-Rego או YAML.

למה: מאפשר אכיפה גמישה, הצהרתית (declarative) ואוטומטית של מדיניות אבטחה החורגת מבקרות Kubernetes המובנות.

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

→יישם service mesh (לדוגמה, Istio, Linkerd) כדי לספק אוטומטית mTLS (mutual TLS) עבור כל השירותים המשולבים ברשת השירות.

למה: משיג רשת אפס אמון (zero-trust networking) על ידי הבטחה שכל התעבורה בתוך הקלאסטר מוצפנת וששירותים מאמתים הדדית את זהותם.

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

→השתמש בסביבת הרצה של קונטיינר מבודדת (sandboxed) כמו gVisor או Kata Containers, המספקות שכבת בידוד נוספת בין הקונטיינר לגרעין המארח.

למה: מפחית את שטח התקיפה של גרעין המארח, מה שהופך בריחת קונטיינר לקשה משמעותית.

שליטה עדינה על הרשאות קונטיינר ברמת ה-kernel.

→השתמש בפרופילי Seccomp כדי לסנן קריאות מערכת (syscalls) מורשות, ובפרופילי AppArmor/SELinux כדי לאכוף בקרות גישה חובה (MAC) על גישת קבצים ורשת.

למה: תכונות אבטחה מקוריות אלו של לינוקס מספקות שכבת הגנה עמוקה, המגבילה את מה שתהליך קונטיינר שנפרץ יכול לעשות באופן יסודי.

הפחתת שטח התקיפה בתוך תמונת קונטיינר.

→בנה תמונות יישומים באמצעות תמונות בסיס מינימליות או "distroless" המכילות רק את היישום ואת התלויות הישירות שלו.

למה: מסיר shells, מנהלי חבילות, ושירותים אחרים שאינם נחוצים לייצור ועלולים לשמש תוקף לאחר פריצה.

אימות שקלאסטר Kubernetes מוגדר בהתאם לשיטות העבודה המומלצות לאבטחה.

→הרץ באופן קבוע את `kube-bench`, כלי אוטומטי הבודק את הקלאסטר מול ה-CIS Kubernetes Benchmark.

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

קלאסטר חייב לעבד ולאחסן נתוני כרטיסי אשראי בהתאם ל-PCI DSS.

→השתמש ב-NetworkPolicies עבור פילוח רשת כדי לבודד את סביבת נתוני בעל הכרטיס (CDE), ואפשר הצפנה במנוחה (at rest) עבור etcd.

למה: בקרות אלו מתאימות ישירות לדרישות PCI DSS עבור פילוח רשת (דרישה 1) והגנה על נתוני בעל הכרטיס המאוחסנים (דרישה 3).

קלאסטר מטפל במידע רפואי מוגן (PHI) וחייב לעמוד ב-HIPAA.

→יישם RBAC קפדני, אפשר רישום ביקורת מקיף (comprehensive audit logging), והבטח שנתונים מוצפנים גם במנוחה וגם במעבר.

למה: בקרות אלו מטפלות בהגנות הטכניות של HIPAA עבור בקרת גישה, בקרות ביקורת, ואבטחת העברה.

הבטחת יומני ביקורת נשמרים לצורך תאימות ופורנזיות, גם אם הקלאסטר נפרץ.

→הגדר את ה-API server לשדר יומני ביקורת ל-backend רישום חיצוני, חד-פעמי/בלתי ניתן לשינוי (לדוגמה, SIEM או bucket אחסון ענן נעול).

למה: מונע מתוקף עם הרשאות cluster-admin לטשטש את עקבותיו על ידי שינוי או מחיקת יומני ביקורת מקומיים.