במאמר הזה אנחנו מציעים הנחיות לא רשמיות לגבי דרכים להגיב לממצאים של פעילויות חשודות במשאבי Google Kubernetes Engine. יכול להיות שהשלבים המומלצים לא יתאימו לכל הממצאים, ושהם ישפיעו על הפעולות שלכם. לפני שתבצעו פעולה כלשהי, עליכם לבדוק את הממצאים, להעריך את המידע שאספתם ולהחליט איך להגיב.
לפני שמתחילים
- בדיקת הממצא. בודקים את המשאב המושפע ב-Google Kubernetes Engine, את כתובת האימייל של הגורם המזוהה ואת כתובת ה-IP של המתקשר (אם קיימת). כדאי גם לבדוק את הממצאים כדי לזהות סימנים לפריצה (כתובת IP, דומיין, גיבוב קובץ או חתימה).
- כדי לקבל מידע נוסף על הממצא שאתם בודקים, חפשו את הממצא באינדקס של ממצאי איומים.
המלצות כלליות
- צריך לפנות לבעלים של הפרויקט שמכיל את המשאב שייתכן שנפרץ.
- בודקים אם יש סימנים אחרים לפעילות זדונית שקשורה למשאב GKE המושפע ביומני הביקורת ב-Cloud Logging.
- להפסיק או למחוק את משאב GKE שנפרץ ולהחליף אותו במשאב חדש.
- בודקים אם יש סימנים אחרים לפעילות זדונית של הגורם המרכזי ביומני הביקורת ב-Cloud Logging.
- אם הגורם המבצע הוא חשבון שירות (IAM או Kubernetes), צריך לזהות את מקור השינוי כדי לקבוע אם הוא לגיטימי.
- אם הגורם המרכזי שביצע את הפעולה הוא לא חשבון שירות, צריך לפנות לבעלים של החשבון כדי לוודא שהבעלים הלגיטימי ביצע את הפעולה.
- כדאי לעיין בהנחיות בנושא העיקרון של הרשאות מינימליות לתפקידי RBAC ולתפקידים באשכולות.
בנוסף, כדאי לעיין בהמלצות שבסעיפים הבאים.
נוסף קובץ בינארי או ספרייה
אם הקובץ הבינארי, הסקריפט או הספרייה שנוספו נועדו להיכלל בקונטיינר, צריך לבנות מחדש את קובץ האימג' של הקונטיינר עם הקובץ הבינארי, הסקריפט או הספרייה. מידע על קובצי אימג' של קונטיינרים שלא ניתן לשנות, אפשר למצוא במאמר קובצי אימג' של קונטיינרים במסמכי התיעוד של Kubernetes.
איומים שקשורים לבקשות חתימה על אישורים (CSR) ב-Kubernetes
- בודקים את יומני הביקורת ב-Cloud Logging ואת ההתראות הנוספות לגבי אירועים אחרים שקשורים ל-CSR. בודקים אם בקשת ה-CSR אושרה והונפקה, ואם נדרשות פעולות שקשורות ל-CSR מהגורם העיקרי.
- אם אישור CSR היה בלתי צפוי או נקבע כזדוני, צריך לבצע רוטציה של פרטי הכניסה באשכול כדי לבטל את האישור. כדאי לעיין בהנחיות בנושא החלפת פרטי הכניסה של האשכול.
ממצאים בנושא איומים ב-Pods
- בודקים את קובץ המניפסט של ה-Pod ואת המטרה שלו. מוודאים שה-Pod לגיטימי ונדרש.
- אם ה-Pod לא לגיטימי, צריך להסיר אותו יחד עם כל הקישורים המשויכים של RBAC וחשבונות השירות שבהם נעשה שימוש בעומס העבודה.
המאמרים הבאים
- איך עובדים עם ממצאי איומים ב-Security Command Center
- אפשר לעיין באינדקס של ממצאי איומים.
- איך בודקים ממצא דרך מסוף Google Cloud .
- מידע על השירותים שמפיקים ממצאים לגבי איומים