הגדרת אבטחת זמן ריצה לקונטיינרים עם Sysdig כפתרון מלא

Runtime security של קונטיינרים: מה נשבר בפרודקשן

באשכול טיפוסי עומסי עבודה מופעלים עם עודף הרשאות: שכבת בסיס עם root כברירת מחדל, חשבון שירות ממופה לכל פוד, ומצב privileged נשאר «כדי שזה בוודאות יעבוד».

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

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

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

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

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

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

מה נותן בקרת התנהגות של עומסי עבודה

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

חקירת אירוע — דקות במקום שעות

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

הזמן הממוצע מהאות ועד הסיבה יורד משעות לדקות, והוויכוח «זו האפליקציה או הסביבה» נסגר בעובדות, לא בגרסאות.

מחלקת כשלים שלא מגיעה לסביבה

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

יכולת חיזוי בעדכונים

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

יציבות תחת עומס

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

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

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

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

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

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

שלבי הטמעת בקרת התנהגות באשכול

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

1. ביקורת הרשאות קונטיינרים ופרופילים. אוספים את היכולות בפועל, מצבי privileged וגישה ל-socket של סביבת ההרצה — ומקבלים רשימה של שירותים עם הרשאות מיותרות.

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

3. הגדרת כללי גילוי. מתארים הפעלת shell בתוך הקונטיינר, קריאה של קבצים עם פרטי זיהוי, כתיבה לתיקיות זרות, פנייה ל-socket. את הכללים מצמידים לקבוצות שירותים, לא לאשכול כולו.

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

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

6. העברה למשמרת תורנית. מנתחים התראות אמיתיות, מוסרים את תרשים הכיסוי ואת סדר ההסלמה — מכאן והלאה הכללים מנוהלים בידיים שלהם.

מה מועבר לידיים אחרי ההטמעה

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

• קונפיגורציות כללים — מניפסטים דקלרטיביים של מדיניות: הפעלת תהליכים privileged, כתיבה לתיקיות מערכת, פנייה למטא-נתונים, חיבורים ברשת. עריכה עוברת סקירה ומתבטלת בשינוי אחד.
• תרשים כיסוי צמתים — מפת אשכולות: היכן הסוכן מותקן, אילו מרחבי שמות הוחרגו ולמה, ואילו צמתים דורשים פרופיל נפרד.
• מדיניות גישה — מטריצת תפקידים: מי רואה את זרם האירועים, מי עורך כללים ומפעיל חסימות, מי עובד בקריאה בלבד; בנפרד חשבונות שירות ותחומי הנראות שלהם.
• תיעוד הטמעה — תרשים ארכיטקטורה, תלויות, נקודות אינטגרציה עם מערכת איסוף האירועים, סדר עדכון הסוכן והבדיקה שאחריו.
• נוהל תגובה — טבלה «אירוע → עדיפות → פעולת המשמרת התורנית → מועד»: מתי מספיק לתעד אירוע, ומתי נדרש בידוד של הקונטיינר.
• העברת קונפיגורציות — ייצוא כללים ופרופילים של הסוכן בתוספת סדר פריסה מאפס בסביבה חדשה: בדיקות, גיבוי או אזור אחר.
• סשן עם המשמרת התורנית — ניתוח אירועים אמיתיים על התקן שלכם, כדי שהנוהל לא יישאר מסמך שאיש לא פתח.

מקרה בוחן: הסרנו מחלקת כשלים בשלב העלייה

מצב התחלתי

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

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

מה שינו

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

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

מדדים לפני ואחרי

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

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

במה בקרת התנהגות שונה מסריקת אימג'ים?

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

בקרת התנהגות נדלקת אחרי עליית התהליך ומסתכלת על הפעולות בפועל: קריאות מערכת, פניות לקבצים, חיבורים ברשת, הפעלת תהליכי ילד, ניסיונות mount. ההבדל בין הגישות הוא ברגע ובמושא התצפית — סריקה עונה על השאלה «מה בפנים», ובקרת התנהגות — על השאלה «מה קורה עכשיו». אפשר לתאר אימג' כדרכון בכניסה, והתנהגות — כיומן פעולות אחרי שהדלת נסגרה.

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

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

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

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

מגבלות וספקות טכניים

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

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

כמה התראות שווא יהיו ומי מטפל בהן?

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

האם זה תואם לסביבה הקיימת אם חלק מהשירותים כבר פרוסים?

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

נדבר על המשימה ונחזור עם תוכנית הטמעה

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

בסיום הדיון תקבלו:

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

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