Network Security Policies: מדוע התעבורה בין שירותים פתוחה
כברירת מחדל, הרשת בתוך האשכול שטוחה: פודים רואים זה את זה ישירות, והמסלול בין הצמתים אינו דורש אישור. כל עוד Network Security Policies לא הוגדרו, כל שירות יכול לפנות למסד נתונים, broker תורים או API פנימי — לא מפני שכך תוכנן, אלא מפני ששום דבר לא אוסר זאת.
המחיר של תמונה כזו ניכר כבר בתקלה הראשונה: שגיאת קונפיגורציה או פגיעות בשירות אחד פותחת גישה לשירותים שכנים, ודרך אותה תעבורה פתוחה בין שירותים — למערכות חיצוניות ולמאגרי נתונים. נסביר כיצד סוגרים זאת.
סגמנטציה של עומסים נשענת על שלוש שאלות: מי יוזם את החיבור, לאן ובאיזה פורט. את הכלל מתארים באמצעות סלקטורים של תוויות פודים ומרחבי שמות, ולכן בידוד תעבורה באשכול אינו תלוי בכתובות ואינו נשבר כאשר פודים נוצרים מחדש.
מצב «הכול אסור למעט מה שהותר» מפעילים ראשון, ואת החריגים מוסיפים באופן ממוקד — לפי קשרים בפועל, לא לפי הנחות.
סדר העבודה הפוך מהרגיל: תחילה מפיקים מפת זרימות לפי לוגים ומדדי רשת, מסמנים קשרים מחייבים ומסלולי דיבוג שנותרו לאחר ההפעלה. לאחר מכן מתארים מדיניות אבטחת רשת ב-Calico או Cilium, כולל כללים לתעבורה יוצאת והרשאת שמות, ובודקים אותם בסביבת בדיקה. בתוצאה — סט כללים במאגר לצד המניפסטים: שינוי עובר בדיקה ופריסה כמו קוד, ולא ידנית בפאנל.
בידוד תעבורה בין סביבות: סוגי כשלים וזמן תגובה
סגמנטציה מתחילה במצב חסימה כברירת מחדל (default-deny): בכל מרחב שמות התעבורה הנכנסת והיוצאת סגורה, ולאחר מכן נפתחים רק זוגות «שירות — שירות» והפורטים הנדרשים. הכללים מתארים לא «למי מותר», אלא «למי אסור אחרת» — הקשרים נראים מהמניפסטים, ולא משוחזרים מהלוגים. את הגישה תומכות תוספי רשת נפוצים, כולל Calico, והיא מועברת ביניהם כמעט ללא שכתוב כללים.
אילו סוגי כשלים מפסיקים להתפשט: דליפת פרטי התחברות במרחב שמות בדיקה אינה נותנת יותר גישה למסד הייצור, ופוד נגוע אינו סורק את שכניו — תנועה לרוחב נעצרת בחסימה הראשונה. שגיאת קונפיגורציה שבגללה שירות פונה למאגר של אחר נתפסת על ידי הרשת, ולא מתגלה מנתונים פגומים.
זמן ניתוח התקרית יורד, מפני שהמדיניות היא תרשים קשרים לביצוע. התורן רואה את הזרימות המותרות ופוסל מיד מחצית מההשערות, והחסימה שהופעלה נרשמת כאירוע נפרד — אין צורך לאסוף את השרשרת «מי פנה למי» טיפין טיפין.
ההשבתה נעשית צפויה: רדיוס הנזק מוגבל לסגמנט אחד, והחזרה לאחור היא החזרת גרסת כללים קודמת, ולא שחזור של כל הרשת. כללים חדשים מיושמים תחילה במצב תצפית ורק אחר כך חוסמים תעבורה.
Network Security Policies: מצבי בקרה ומגבלות
כברירת מחדל, הקשרים בתוך האשכול פתוחים: כל עומס עבודה יכול לפנות לכל עומס אחר. מדיניות רשת הופכות זאת למודל «מותר רק מה שמופיע ברשימה» — הכללים מתארים לאילו שירותים ולאילו פורטים מותר לפנות, ונשענים על תוויות, לא על כתובות.
אותם מבצע רכיב הרשת של האשכול: אם המימוש הנבחר אינו תומך בקבוצת השדות הנדרשת, המדיניות נשארת תיאור בלי השלכות, ותחושת ביטחון מדומה יקרה מהיעדר כללים.
ארבע רמות בידוד
שכבות הבקרה פותרות משימות שונות ובפועל משתלבות — הבחירה תלויה במה שצריך לסגור.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| כללי ברירת מחדל של האשכול | אשכול אחיד, קשרים בין שירותים צפויים | אינם מנהלים תעבורה אל מחוץ לאשכול; בתוך קבוצה מורשית אינם מבדילים מי בדיוק פנה |
| כללים ברמת הצומת | צריך לסגור קשרים בין צמתים ויציאה החוצה, חלק מהעומס חי מחוץ לאשכול | מוגדרים בנפרד מתיאור השירותים ומתנתקים בסנכרון בעת העברות; דיבוג יקר יותר |
| בידוד בהיקף חיצוני | האשכול כולו בסגמנט סגור, כמה סביבות תחת בקרה משותפת | בתוך הסגמנט הקשרים נשארים פתוחים; אין בקרה לפי שירותים בודדים |
| אימות הדדי | חשוב לא רק «מותר», אלא גם «מי בדיוק» פונה | נדרשים הנפקה ורוטציה של אישורים; דרישות תחזוקה גבוהות יותר |
סדר היישום בדרך כלל כזה: מפעילים כללי ברירת מחדל במצב תצפית, אוספים מהלוגים קשרים בפועל, מעבירים מתצפית לחסימה, ורק לאחר מכן מוסיפים כללים ברמת הצומת ואימות הדדי במקומות שבהם נדרשת הגנה מפני תנועה לרוחב.
סדר היישום: מאינוונטר תעבורה ועד מסירה
את סדר העבודה בונים כך שאף שירות ייצור לא יאבד קישוריות. תחילה מפיקים מפת זרימות בפועל, לאחר מכן מתארים קשרים מורשים, ורק אחר כך מפעילים חסימה — בסביבת בדיקה, ואז בגלים לפי מרחבי שמות, עם תוכנית חזרה לאחור בכל שלב.
- אינוונטר תעבורה. אוספים לוגים של זרימות רשת, בקשות DNS ומדדי service mesh לתקופה שמכסה גם משימות שגרה וגם תהליכי לילה. בתוצאה — מטריצת «שירות → שירות → פורט».
- תרשים קשרים מורשים. משאירים קשרים מאומתים, ומקרים שנויים במחלוקת מתאמים עם בעלי השירותים. קו הבסיס — איסור של כל מה שלא תואר במפורש.
- הגדרה בסביבת בדיקה. מעבירים את המדיניות לאשכול העתקה ומפעילים במצב לוגים: הכללים מחושבים, התעבורה אינה נחסמת. כך צוברים הפעלות על פרופיל עומס אמיתי בלי סיכון.
- בדיקת מדיניות. מריצים שרשראות לגיטימיות ומסלולים מקצה לקצה של ניטור, אוספי לוגים ורישום אימג'ים: המותר עובר, והעודף נרשם בדוח.
- הפעלה מדורגת של כללים. מעבירים מרחבי שמות למצב חסימה אחד אחד, החל מסביבות לא קריטיות. לפני כל שלב — בקרת מדדי זמינות.
- ניתוח חסימות. לפי הלוגים מבדילים תעבורה מזיקה מקשר לא מתועד אך נחוץ: או חריגה מדויקת, או תיקון השירות עצמו.
- מסירה לצוות. מוסרים את המדיניות במערכת בקרת גרסאות, נוהל שינויים, תרשים קשרים והוראות לתורן. חזרה לאחור — מעבר לסט הכללים הקודם.
מניפסטים, תרשימי זרימה ונוהל שינויים
מדיניות בלי תיעוד מחזיקה בדיוק עד החלפת האחראי הראשונה: מהנדס חדש רואה סט כללים ולא מבין אילו קשרים באמת נדרשים ואילו נותרו מהארכיטקטורה הקודמת. לכן יחד עם סביבה עובדת מוסרים ערכה שלפיה אפשר לבצע שינוי במודע, בלי לפתוח יותר מדי.
- מרשם זרימות מורשות — מי מתקשר עם מי, באיזה פורט ואיזה שירות אחראי לקשר. אליו מפנים בניתוח תקלה ובהפסקת שירות.
- קונפיגורציות מדיניות מוכנות — מניפסטים עם שמות מובנים, מחולקים לפי מרחבי שמות, עם סימון אילו כללים מחייבים ואילו זמניים. נפרסים כפי שהם.
- תרשים אמון — מפת סגמנטים וכיווני תעבורה: מה נחשב להיקף חיצוני, מה לאזור פנימי, והיכן מותר מעבר בין סביבות וסביבות פיתוח.
- נוהל שינויים — סדר התיקון: בקשה עם נימוק, בדיקה בסביבת בדיקה, חלון פריסה, אחראי לאישור. בלעדיו הכללים הופכים במהרה לערמת חריגים.
- לוג חסימות ונוהל ניתוח — לאן להסתכל בעת כשל שירות, כיצד להבדיל בין הפעלה שגויה לניסיון קשר אמיתי, ובתוך כמה זמן הכלל מוסר.
- הוראות חזרה לאחור — כיצד להחזיר את סט הכללים הקודם בפעולה אחת, אם לאחר השינוי התפוררו תלויות.
- תרחישי קבלה — רשימת קשרים שנבדקים לאחר כל תיקון, כדי לתפוס רגרסיה לפני סביבת העבודה.
את הערכה מנהלים במאגר יחד עם המניפסטים, ולכן התיעוד אינו מתרחק מהמצב בפועל של האשכול: שינוי המדיניות ושינוי התיאור שלה נעשים בפעולה אחת מתואמת.
מקרה בוחן: סגמנטציה של אשכול בלי השבתת שירותים
לפני: רשת שטוחה
האשכול שירת את סביבת הייצור, סביבת הטרום-ייצור וסביבת הבדיקה באותה רשת — כל פוד יכול היה לפנות לכל שירות בכל פורט. כמעט כל הקשרים היו מורשים: הסביבה עצמה לא הגבילה דבר, וניתוח תקלה התחיל במעבר ידני על לוגים בכל הצמתים ונמשך לפחות ארבע שעות. סביבת הבדיקה, בהתאם, ראתה את מסדי הייצור.
מה שינו
תחילה אספו תעבורה על פני כמה מחזורי שחרור ובנו גרף תלויות «שירות → שירות → פורט» — הוא הפך למקור הכללים. את המדיניות תיארו ב-Calico: תחילה במצב לוגים, שבו קשרים רק נרשמים אך אינם נחסמים, ואחר כך הפעילו חסימה כברירת מחדל והרשאות ממוקדות. לכל סביבה ניתנה קבוצת כללים משלה, ולכן סביבת הטרום-ייצור וסביבת הבדיקה הפסיקו לנתב אל סביבת הייצור.
תוצאה
שיעור הקשרים המורשים ירד מ-100% ל-11% — השאר סגור באיסורים מפורשים. ניתוח התקלה הואץ פי כמה: במקום מעבר על צמתים די להסתכל בלוג החיבורים הנדחים, 30–40 דקות במקום חצי יום עבודה.
הכללים הופעלו בלי לעצור את העומס: התורן עקב אחר זרימת הכשלים, החזרה לפרופיל הקודם ארכה דקות, ולא נדרש חלון השבתה.
במה מדיניות רשת שונות מתפקידי גישה?
תפקידי גישה ומדיניות רשת סוגרים שאלות שונות, וערבוב ביניהם משאיר חורים בהגנה. תפקידים מחלקים הרשאות: איזו חשבון יכול לקרוא, ליצור ולשנות אובייקטים במערכת הניהול. מדיניות ברמת הרשת עונה על שאלה אחרת — אילו חיבורים בין עומסים בכלל אפשריים.
מודל הגישה בנוי סביב סובייקט ופעולה: הרשאה ניתנת לפעולה על אובייקט. הרשת מתוארת אחרת — כזרימה: מקור, יעד, פורט. לכן תפקיד לא יעצור פוד שכבר רץ ופונה למסד נתונים של אחר.
ההבדל ניכר בדוגמה. לחשבון של שירות מותר לקרוא סודות במרחב השמות שלו — התפקיד מאפשר זאת, וזה תקין. אבל זה לא אומר שאותו שירות צריך לפנות למסד החיוב: המדיניות אוסרת את החיבור, ובמקרה של פגיעות בפוד התוקף לא ייכנס לסביבה זרה.
כברירת מחדל, באשכול בלי מדיניות התעבורה בין מרחבי שמות פתוחה. לכן את היישום מתחילים בחסימה כברירת מחדל ובהרשאות מפורשות לפי סלקטורי פודים: רק הזוגות הנדרשים «שירות → שירות» וגישה יוצאת ל-DNS. Calico ו-Cilium מיישמים כללים כאלה ברמת הרשת ומשליכים את החיבור לפני שהוא מגיע לאפליקציה.
השוואת המנגנונים מצטמצמת לתחום האחריות: תפקידים אחראים לניהול האשכול והאובייקטים שלו, מדיניות — לקשרים בין עומסים. גם הביקורת שונה: שינויי הרשאות נראים בלוג מערכת הניהול, חיבורים נדחים — במוני הצומת. מודל הגישה עובד רק כששני השכבות מוגדרות.
ספקות טכניים: תאימות, חזרה לאחור, תמיכה
מדיניות אבטחת רשת משנות את האופן שבו נעה התעבורה בתוך האשכול, ולכן הספקות אצל צוותים כמעט תמיד זהים. אנו עונים על אלה שנשאלות לרוב לפני ההתחלה.
איך להבין שהמדיניות לא תחמוס את התעבורה העובדת?
מפיקים תמונה של הזרימות הנוכחיות: אילו שירותים ומרחבי שמות מתקשרים, באילו פורטים, מי יוצא החוצה. את המדיניות מפעילים במצב תצפית — הן רק רושמות מה היה נזרק. לאחר ניתוח הפערים מוסיפים הרשאות, ורק אז מעבירים את הכללים למצב אכיפה.
מה יקרה לכללים שכבר קיימים באשכול?
עורכים אינוונטר של כל מה שמתואר במניפסטים ומאחדים לסט אחד עם בדיקת עדיפויות: במקרה של חפיפה, סדר היישום מכריע את התוצאה. בקרים מחשבים את הסדר הזה באופן שונה, ולכן אין לערבב שניים באשכול אחד — נשאר אחד.
כיצד לחזור אחורה משינויים אם הגישה אבדה?
כללים חיים באופן הצהרתי במאגר, ולכן חזרה לאחור היא החזרת גרסה קודמת והחלתה, בלי תיקונים ידניים. מחזיקים בעקרון: «לאסור הכול» אינו מיושם כצעד ראשון — הרשאות לתעבורת שירות נשארות במקומן עד למעבר.
מי מתחזק את המדיניות לאחר המסירה?
מוסרים מאגר עם כללים, תרשים זרימות בין שירותים והוראות אבחון: לפי אילו לוגים רואים מה בדיוק נזרק. בזמן הראשון נשארים בקשר ומתקנים כללים יחד עם הצוות שלכם, עד שהוא עובר למצב עצמאי.
תחילת העבודה: מה נדרש מצדכם ולוחות זמנים
סדר ההתחלה זהה לאשכול אחד ולמשק של עשרות: תחילה נתוני קלט, אחר כך הערכת עבודה, ולאחר מכן תוכנית יישום מתואמת עם לוחות זמנים.
בלי תרשים סביבות ורשימת שירותים ההערכה הופכת לטווח, ואת Network Security Policies צריך לתכנן מחדש תוך כדי — לכן איסוף הנתונים מוציאים לשלב הראשון ומקבעים את התוצאה בכתב.
- תרשים סביבות: אשכולות ייצור, טרום-ייצור ופיתוח, הקשרים ביניהם ועם רשתות חיצוניות.
- רשימת שירותים: מי מתקשר עם מי, אילו כתובות ופורטים חיצוניים נדרשים, והיכן התעבורה דו-כיוונית.
- נקודות כניסה: מאזני עומסים, שערים, פרסום שירותים, גישות ל-DNS ולרישום אימג'ים.
- פרטי התחברות: תפקיד נפרד עם הרשאה לקרוא מדיניות ומצב ביקורת פעיל בסביבת הבדיקה.
- דרישות יעד: מה בדיוק מגבילים — קשרים בין מרחבי שמות, יציאה לאינטרנט, גישה למסדי נתונים.
- מגבלות: חלונות שבהם מותרים שינויים בייצור, ושירותים שאסור לעצור.
- אחראי מצדכם: מהנדס שמאשר קשרים ומקבל את התוצאה.
לאחר מכן חוזרים עם הערכה לפי שלבים ותוכנית: פיילוט בסביבת בדיקה במצב ביקורת, שבו המדיניות רק רושמת תעבורה ואינה חוסמת דבר, השוואת הלוג עם קשרים בפועל, מעבר למצב חסימה לפי מרחב שמות אחד, ואז ייצור.
מדיון במשימה ועד פיילוט עוברים ימים, עד מעבר מלא — שבועות; המועד המדויק תלוי במספר השירותים והקשרים ביניהם.