העברה לא מורשית: העברה לא מורשית של Cloud SQL שהופעלה על ידי Agent Engine

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

סקירה כללית

הדלפת נתונים מ-Cloud SQL שמתבצעת על ידי סוכן שפריסתו בוצעה ב-Vertex AI Agent Engine מזוהה על ידי בדיקת יומני ביקורת בשני תרחישים:

  • נתונים של מופע פעיל שמיוצאים לקטגוריה של Cloud Storage מחוץ לארגון.
  • נתונים של מופע פעיל שמיוצאים לקטגוריה של Cloud Storage שבבעלות הארגון ונגישה באופן ציבורי.

יש תמיכה בכל סוגי המופעים של Cloud SQL.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

איך מגיבים

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

שלב 1: בדיקת פרטי הממצא

  1. פותחים ממצא של Exfiltration: Agent Engine Initiated Cloud SQL Exfiltration, כמו שמוסבר במאמר בדיקת ממצאים. חלונית הפרטים של הממצא תיפתח בכרטיסייה סיכום.

  2. בכרטיסייה סיכום, בודקים את המידע בקטעים הבאים:

    • מה זוהה, במיוחד השדות הבאים:
      • כתובת האימייל העיקרית : החשבון ששימש להעברת הנתונים.
      • מקורות של אקספילטרציה: פרטים על מכונת Cloud SQL שהנתונים שלה עברו אקספילטרציה.
      • יעדי אקספילטרציה: פרטים על הקטגוריה של Cloud Storage שאליה יוצאו הנתונים.
    • מקור המידע שהושפע, במיוחד השדות הבאים:
      • השם המלא של המשאב: שם המשאב של Cloud SQL שהנתונים שלו נגנבו.
      • השם המלא של הפרויקט: Google Cloud הפרויקט שמכיל את נתוני המקור של Cloud SQL.
    • קישורים רלוונטיים, כולל:
      • ‫Cloud Logging URI: קישור לרשומות ב-Logging.
      • שיטת MITRE ATT&CK: קישור למסמך של MITRE ATT&CK.
      • ממצאים קשורים: קישורים לממצאים קשורים.

  3. לוחצים על הכרטיסייה JSON.

  4. בשדה ה-JSON של הממצא, שימו לב לשדות הבאים:

    • sourceProperties:
      • evidence:
      • sourceLogId:
        • ‫projectId: הפרויקט Google Cloud שמכיל את מופע Cloud SQL של המקור.
      • properties
      • ‫bucketAccess: האם יש גישה ציבורית לקטגוריה של Cloud Storage או שהיא חיצונית לארגון
      • ‫exportScope: כמה נתונים יוצאו, למשל, המופע כולו, מסד נתונים אחד או יותר, טבלה אחת או יותר או קבוצת משנה שצוינה על ידי שאילתה)

שלב 2: בדיקת ההרשאות וההגדרות

  1. נכנסים לדף IAM במסוף Google Cloud .

    כניסה לדף IAM

  2. אם צריך, בוחרים את הפרויקט של המופע שמופיע בשדה projectId ב-JSON של הממצא (משלב 1).

  3. בדף שמופיע, בתיבה Filter, מזינים את כתובת האימייל שמופיעה בשורה Principal email בכרטיסייה Summary של פרטי הממצא (משלב 1). בודקים אילו הרשאות הוקצו לחשבון.

שלב 3: בדיקת היומנים

  1. במסוף Google Cloud , לוחצים על הקישור ב-Cloud Logging URI (משלב 1) כדי לעבור אל Logs Explorer. הדף Logs Explorer כולל את כל היומנים שקשורים למופע הרלוונטי של Cloud SQL.

שלב 4: מחקר על שיטות תקיפה ותגובה

  1. כדאי לעיין בערך של מסגרת MITRE ATT&CK לגבי סוג הממצא הזה: Exfiltration to Cloud Storage (העברה לא מורשית אל Cloud Storage).
  2. כדי לעיין בממצאים קשורים, לוחצים על הקישור בשורה ממצאים קשורים שמתוארת בשלב 1. לממצאים קשורים יש את אותו סוג ממצא באותה מכונת Cloud SQL.
  3. כדי לפתח תוכנית תגובה, משלבים את תוצאות החקירה עם מחקר של MITRE.

שלב 5: הטמעת התגובה

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

  • צריך לפנות לבעלים של הפרויקט עם הנתונים שחולצו.
  • מומלץ לבטל את ההרשאות של access.principalEmail עד לסיום החקירה.
  • כדי למנוע העברה נוספת של נתונים, מוסיפים מדיניות IAM מגבילה למופעי Cloud SQL שהושפעו.
  • כדי להגביל את הגישה ל-Cloud SQL Admin API ואת האפשרות לייצא ממנו, השתמשו ב-VPC Service Controls.
  • כדי לזהות ולתקן תפקידים עם יותר מדי הרשאות, אפשר להשתמש בשירות המלצות IAM.

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