גישה לפרטי כניסה: בקשה לחתימת אישור (CSR) ב-Kubernetes שאושרה באופן ידני

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

סקירה כללית

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

המקור של הממצא הזה הוא Event Threat Detection.

איך מגיבים

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

כדי להגיב לממצא הזה:

  1. כדי לקבוע אם פעולות שקשורות ל-CSR הן פעילות צפויה של הגורם המורשה, בודקים את יומני הביקורת ב-Cloud Logging ואת ההתראות הנוספות לגבי אירועים אחרים שקשורים ל-CSR.
  2. בודקים אם יש סימנים אחרים לפעילות זדונית של הגורם המרכזי ביומני הביקורת ב-Cloud Logging. לדוגמה:
    • האם הגורם האחראי שאישר את ה-CSR שונה מהגורם שיצר אותו?
    • האם ב-CSR צוין חותם מובנה, אבל בסופו של דבר נדרש אישור ידני כי הוא לא עמד בקריטריונים של החותם?
    • האם הגורם המרכזי ניסה לבקש, ליצור, לאשר או למחוק בקשות CSR אחרות?
  3. אם לא ציפיתם לאישור של בקשת חתימה על אישור (CSR) או אם נקבע שהיא זדונית, תצטרכו לבצע רוטציה של פרטי הכניסה כדי לבטל את האישור. מומלץ לעיין בהנחיות לביצוע רוטציה של פרטי הכניסה של האשכול.

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