תגובה לממצאי איומים ב-Google Kubernetes Engine

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

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

לפני שמתחילים

  1. בדיקת הממצא. בודקים את המשאב המושפע ב-Google Kubernetes Engine, את כתובת האימייל של הגורם המזוהה ואת כתובת ה-IP של המתקשר (אם יש). כדאי גם לבדוק את הממצאים כדי לזהות סימנים לפריצה (כתובת IP, דומיין, גיבוב קובץ או חתימה).
  2. כדי לקבל מידע נוסף על הממצא שאתם בודקים, חפשו את הממצא באינדקס של ממצאי איומים.

המלצות כלליות

  • צריך לפנות לבעלים של הפרויקט שמכיל את המשאב שאולי נפרץ.
  • בודקים אם יש ביומני הביקורת ב-Cloud Logging סימנים נוספים לפעילות זדונית שקשורה למשאב GKE שהושפע.
  • מפסיקים או מוחקים את משאב GKE שנפרץ ומחליפים אותו במשאב חדש.
  • בודקים אם יש סימנים אחרים לפעילות זדונית של הגורם המרכזי ביומני הביקורת ב-Cloud Logging.
  • אם הגורם המבצע הוא חשבון שירות (IAM או Kubernetes), צריך לזהות את מקור השינוי כדי לקבוע אם הוא לגיטימי.
  • אם הגורם המרכזי שביצע את הפעולה הוא לא חשבון שירות, צריך ליצור קשר עם הבעלים של החשבון כדי לוודא שהבעלים הלגיטימי ביצע את הפעולה.
  • כדאי לעיין בהנחיות בנושא העיקרון של הרשאות מינימליות לגבי תפקידי RBAC ותפקידים באשכולות.

בנוסף, כדאי לעיין בהמלצות שבסעיפים הבאים.

נוסף קובץ בינארי או ספרייה

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

איומים שקשורים לבקשות חתימה על אישורים (CSR) ב-Kubernetes

  • בודקים את יומני הביקורת ב-Cloud Logging ואת ההתראות הנוספות לגבי אירועים אחרים שקשורים ל-CSR. בודקים אם בקשת ה-CSR אושרה והונפקה, ואם נדרשות פעולות שקשורות ל-CSR מהגורם המנהל.
  • אם אישור CSR היה בלתי צפוי או נקבע כזדוני, צריך לבצע רוטציה של האישורים באשכול כדי לבטל את האישור. כדאי לעיין בהנחיות בנושא החלפת פרטי הכניסה של האשכול.

ממצאים בנושא איומים ב-Pods

  • בודקים את קובץ המניפסט של ה-Pod ואת המטרה שלו. מוודאים שה-Pod לגיטימי ונדרש.
  • אם ה-Pod לא לגיטימי, צריך להסיר אותו יחד עם כל הקישורים המשויכים של RBAC וחשבונות השירות שבהם נעשה שימוש בעומס העבודה.

המאמרים הבאים