תגובה לפרטי כניסה שנפרצו ב-Google Cloud

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

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

Google Cloud פרטי כניסה

בטבלה הבאה מתוארים סוגים נפוצים של Google Cloud פרטי כניסה.

פרטי כניסה תיאור
מפתחות פרטיים לחשבונות שירות (קובצי JSON ו-p12)

סוג: פרטי כניסה לחשבון שירות לטווח ארוך

מיקומים אופייניים:

  • תחנות עבודה למפתחים
  • סביבות של שרתי אפליקציות
  • מאגרי קוד מקור
  • מערכות לניהול סודות

פתרון: מפתחות וטוקנים של חשבונות שירות
אסימונים של חשבון שירות (אסימוני גישה מסוג OAuth 2.0)

סוג: פרטי כניסה לטווח קצר

מיקומים אופייניים:

  • זיכרון זמן ריצה של אפליקציה
  • עומסי עבודה בסביבת ייצור (מאוחזרים באופן דינמי משרתי מטא-נתונים של מכונות)
  • עמדות עבודה למפתחים או צינורות עיבוד נתונים של CI/CD

פתרון: מפתחות וטוקנים של חשבונות שירות
מפתחות API

סוג: פרטי כניסה לחשבון שירות לטווח ארוך

מיקומים אופייניים:

  • קוד המקור של הקצה הקדמי
  • קובצי תצורה של קצה עורפי
  • מערכות לניהול סודות או משתני סביבה

פתרון: מפתחות API
סודות של מזהי לקוחות ב-OAuth 2.0

סוג: פרטי כניסה לחשבון שירות לטווח ארוך

מיקומים אופייניים:

  • קובצי הגדרות של קצה עורפי בשרת אינטרנט
  • מערכות לניהול סודות

פתרון: סודות של מזהי לקוחות ב-OAuth 2.0
פרטי הכניסה ל-Google Cloud CLI

סוג: פרטי כניסה של משתמש עם תוקף ארוך

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

פתרון: פרטי כניסה של משתמשים ואסימוני OAuth של Google Cloud CLI
אסימוני גישה מסוג OAuth ל-Google Cloud CLI

סוג: פרטי כניסה לטווח קצר

מיקום אופייני: תחנות עבודה של מפתחים

פתרון: פרטי כניסה של משתמשים ואסימוני OAuth של ה-CLI של gcloud
Application Default Credentials

סוג: פרטי כניסה של משתמש עם תוקף ארוך

מיקום אופייני: תחנות עבודה של מפתחים

פתרון: Application Default Credentials
קובצי cookie בדפדפן

סוג: פרטי כניסה של משתמש עם תוקף ארוך

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

הפתרון: קובצי Cookie בדפדפן
אסימוני גישה מאוחדים של Security Token Service לאיחוד שירותי אימות הזהות של עומסי עבודה

סוג: פרטי כניסה לטווח קצר

מיקומים אופייניים:

  • סביבות זמן ריצה של עומסי עבודה חיצוניים
  • צינורות עיבוד נתונים לפריסה של CI/CD

תיקון: אסימוני גישה מאוחדים של שירות טוקנים לאבטחה
אסימוני גישה מאוחדים של Security Token Service לאיחוד שירותי אימות הזהות של כוח עבודה

סוג: פרטי כניסה לטווח קצר

מיקומים אופייניים:

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

תיקון: אסימוני גישה מאוחדים של שירות טוקנים לאבטחה

הגנה על Google Cloud המשאבים מפני חשיפה של פרטי הכניסה

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

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

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

מפתחות וטוקנים של חשבונות שירות

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

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

בניגוד לאסימוני גישה שמוענקים לזהויות משתמשים, אי אפשר לבטל אסימוני גישה שמוענקים לחשבונות שירות דרך מסוף Admin או פקודות כמו gcloud auth revoke. בנוסף, משך הסשן שאתם מציינים בGoogle Cloud בקרת סשנים חל על חשבונות משתמשים בספרייה של Cloud Identity או Google Workspace, אבל לא על חשבונות שירות. לכן, כשמגיבים לאירוע שבו חשבונות שירות נפרצו, צריך להתייחס גם לקובצי המפתחות הקבועים וגם לאסימוני הגישה לטווח קצר.

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות בשביל להגיב למפתחות ולטוקנים של חשבונות שירות שנפרצו, אתם צריכים לבקש מהאדמין לתת לכם את תפקידי ה-IAM הבאים:

  • ניהול מפתחות של חשבונות שירות: אדמין של מפתח של חשבון שירות (roles/iam.serviceAccountKeyAdmin) בפרויקט שמכיל את חשבון השירות
  • השבתה, הפעלה או מחיקה של חשבונות שירות: אדמין של חשבון שירות (roles/iam.serviceAccountAdmin) בפרויקט שמכיל את חשבון השירות
  • החלת כללי מדיניות דחייה כדי לחסום טוקנים פעילים: אדמין דחייה (roles/iam.denyAdmin) בארגון
  • ביטול תפקידי התחזות: אדמין של ניהול זהויות והרשאות גישה (IAM) בפרויקט (roles/resourcemanager.projectIamAdmin), אדמין של חשבון שירות (roles/iam.serviceAccountAdmin) בפרויקט

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

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

ההרשאות הנדרשות

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

  • ניהול מפתחות של חשבונות שירות:
    • ‫iam.serviceAccountKeys.create בפרויקט שמכיל את חשבון השירות
    • ‫iam.serviceAccountKeys.delete בפרויקט שמכיל את חשבון השירות
    • ‫iam.serviceAccountKeys.list בפרויקט שמכיל את חשבון השירות
  • השבתה, הפעלה או מחיקה של חשבונות שירות:
    • ‫iam.serviceAccounts.disable בפרויקט שמכיל את חשבון השירות
    • ‫iam.serviceAccounts.enable בפרויקט שמכיל את חשבון השירות
    • ‫iam.serviceAccounts.delete בפרויקט שמכיל את חשבון השירות
  • החלת מדיניות דחייה לחסימת טוקנים פעילים: iam.denypolicies.create בארגון
  • ביטול תפקידי התחזות:
    • resourcemanager.projects.setIamPolicy בפרויקט
    • ‫iam.serviceAccounts.setIamPolicy בפרויקט שמכיל את חשבון השירות

יכול להיות שתקבלו את ההרשאות האלה באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.

תגובה למפתחות ולטוקנים של חשבונות שירות שנפרצו

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

    • השבתת חשבון השירות שקשור לפרטי הכניסה.

    • מחילים מדיניות IAM deny על הסוכן (principal) של חשבון השירות (principal://iam.googleapis.com/projects/-/serviceAccounts/SA_EMAIL_ADDRESS) בפרויקטים או בתיקיות. מדיניות הדחייה של IAM דוחה גישה לממשקי API רגישים ולהרשאות של אסימונים ועומסי עבודה פעילים, כדי שתוכלו לחקור את האירוע בלי להרוס את חשבון השירות.

    • מחיקת חשבון השירות.

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

  2. כדי להחליף מפתח של חשבון שירות שנפרץ, פועלים לפי השלבים הבאים:

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

      כניסה לדף Service accounts

    2. מוצאים את חשבון השירות שהושפע מהחשיפה.

    3. במקרה הצורך, יוצרים מפתח חדש לחשבון השירות ומפיצים אותו לכל המקומות שבהם המפתח הקודם היה בשימוש.

    4. משביתים את המפתח הישן כדי לוודא שהמפתח החדש פועל כמו שצריך.

    5. מוחקים את המפתח הישן.

    מידע נוסף מופיע במאמר יצירה ומחיקה של מפתחות של חשבונות שירות.

  3. אם יש חשבונות משתמשים לא מורשים שיש להם הרשאה ליצור אסימונים, צריך לבטל את התפקיד 'יצירת אסימונים בחשבון שירות' (roles/iam.serviceAccountTokenCreator). הוראות מפורטות זמינות במאמר ניהול הגישה לפרויקטים, לתיקיות ולארגונים.

  4. אחרי שהתקרית נפתרה, צריך להמתין לפחות 60 דקות אחרי השבתת חשבון השירות כדי שהאסימון שנפרץ יפוג. אם הגדרתם מדיניות עם משך חיים ממושך יותר באמצעות constraints/iam.allowServiceAccountCredentialLifetimeExtension, תצטרכו לחכות את הזמן שצוין באילוץ לפני שתפעילו מחדש את חשבון השירות.

  5. אחרי שחלף זמן ההמתנה הנדרש, מפעילים מחדש את חשבון השירות ומאפסים את מדיניות הדחייה.

פרטי כניסה של משתמשים ואסימוני OAuth של ה-CLI של gcloud

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

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות לביטול הגישה של משתמשים ולביטול תוקף של טוקני OAuth של gcloud CLI במסוף Google Workspace Admin, צריך לבקש מהאדמין להקצות לכם את תפקידי האדמין הבאים ב-Google Workspace:

  • ניהול אפליקציות מקושרות של צד שלישי ואמצעי בקרה על סשנים: Security Admin או סופר-אדמין
  • ניהול פרטי הכניסה של המשתמשים וסשנים של כניסה: אדמין לניהול משתמשים או סופר-אדמין
  • מריצים את סקריפט הביטול של SDK לאדמינים directory: אדמין על או תפקיד אדמין בהתאמה אישית עם הרשאות Admin API לניהול משתמשים (https://www.googleapis.com/auth/admin.directory.user.security)

מידע נוסף על הקצאת תפקידי אדמין ב-Google Workspace זמין במאמר בנושא הקצאת תפקידי אדמין במסוף Google Admin.

ביטול תוקף של אסימונים ב-CLI של gcloud לחשבונות משתמש ספציפיים

כדי להסיר את הגישה של משתמש ל-CLI של gcloud ולבטל את התוקף של טוקנים שנפרצו:

  1. כדי לבטל את הגישה של משתמש ל-Google Cloud CLI, מבצעים אחת מהפעולות הבאות:

    כשהמשתמש ינסה להשתמש שוב ב-Google Cloud CLI, הוא יתבקש לאשר מחדש את האפליקציה.

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

    curl -d "token=TOKEN_STRING" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -X POST "https://oauth2.googleapis.com/revoke"

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

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

ביטול תוקף של טוקנים של ה-CLI של gcloud עבור הרבה חשבונות משתמשים

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

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

קוד הדוגמה הבא משתמש ב-Google Workspace Admin SDK כדי לזהות את כל זהויות המשתמשים בחשבון Google Workspace או בחשבון Cloud Identity שיש להם גישה ל-gcloud CLI. אם משתמש אישר את ה-CLI של gcloud, הסקריפט מבטל את אסימון הרענון ואת אסימון הגישה, ומחייב את המשתמש לבצע אימות מחדש באמצעות הסיסמה או מפתח האבטחה שלו. הוראות להפעלת Admin SDK API ולהרצת הקוד הזה מופיעות במדריך למתחילים בנושא Google Apps Script.

/**
 * Remove access to the Google Cloud CLI for all users in an organization
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/tokens
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/users
 * @see https://developers.google.com/apps-script/guides/services/advanced#enabling_advanced_services
 */

function listUsersAndInvalidate() {
  const users = AdminDirectory.Users.list({
    customer: 'my_customer' // alias to represent your account's customerId
    }).users;
  if (!users || users.length === 0) {
    Logger.log('No users found.');
    return;
  }
  for (const user of users){
    let tokens = AdminDirectory.Tokens.list(user.primaryEmail).items
    if (!tokens || tokens.length === 0) {
      continue;
    }
    for (const token of tokens) {
      if (token.clientId === "32555940559.apps.googleusercontent.com") {
        AdminDirectory.Tokens.remove(user.primaryEmail, token.clientId)
        Logger.log('Invalidated the tokens granted to gcloud for user %s', user.primaryEmail)
      }
    }
  }
}

Application Default Credentials

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

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות להסרת הגישה של אפליקציות מקושרות במסוף Google Workspace Admin, צריך לבקש מהאדמין לתת לכם את התפקיד Security Admin או Super Admin.

פקודות מקומיות שמופעלות בתחנות עבודה של מפתחים לא דורשות תפקידי אדמין. מידע נוסף על הקצאת תפקידי אדמין ב-Google Workspace זמין במאמר בנושא הקצאת תפקידי אדמין במסוף Google Admin.

ביטול Application Default Credentials

מבצעים אחת מהפעולות הבאות:

  • כאדמינים ב-Google Workspace, אתם יכולים להסיר את הגישה ל-Google Auth Library מרשימת האפליקציות המקושרות של משתמש. למידע נוסף, ראו הצגה והסרה של גישה לאפליקציות צד שלישי.

  • צריך להנחות את הבעלים של פרטי הכניסה שנחשפו לבצע את הפעולות הבאות:

    1. מתקינים ומפעילים את ה-CLI של gcloud, אם עוד לא עשיתם זאת.

    2. מבטלים את פרטי הכניסה:

      gcloud auth application-default revoke

    3. אם אתם לא מצליחים להריץ את ה-CLI של gcloud, צריך לבצע את הפעולות הבאות:

      1. מבטלים את הגישה ל-Google Auth Library באמצעות myaccount.google.com/permissions או נקודת הביטול של OAuth 2.0.

      2. מוחקים ידנית את הקובץ application_default_credentials.json:

        • ב-Linux ו-macOS:‏ $HOME/.config/gcloud/application_default_credentials.json‎
        • ב-Windows:‏ %APPDATA%\gcloud\application_default_credentials.json‎

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

      gcloud auth application-default login

מפתחות API

כדי ליצור מחדש מפתח API שנפרץ:

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות לניהול מפתחות API, צריך לבקש מהאדמין להקצות לכם ב-IAM את התפקיד אדמין של מפתחות API (roles/serviceusage.apiKeysAdmin) בפרויקט. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

ההרשאות הנדרשות

כדי לנהל מפתחות API, נדרשות ההרשאות הבאות:

  • apikeys.keys.create
  • apikeys.keys.delete
  • apikeys.keys.update
  • apikeys.keys.getKeyString
  • apikeys.keys.list
  • apikeys.keys.get

יכול להיות שתקבלו את ההרשאות האלה באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.

יצירה מחדש של מפתח API

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

    כניסה לדף Credentials

  2. לוחצים על השם של מפתח ה-API שרוצים להחליף.

  3. לוחצים על Rotate key (ביצוע רוטציה למפתח).

  4. מזינים שם ומאשרים את ההגבלות.

  5. לוחצים על יצירה.

  6. מעדכנים את האפליקציות כך שישתמשו במפתח ה-API החדש.

  7. בקטע Previous key (מפתח קודם), לוחצים על Delete the previous key (מחיקת המפתח הקודם).

מידע נוסף מופיע במאמר סיבוב מפתח API.

סודות של מזהי לקוחות ב-OAuth 2.0

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

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות לאיפוס הסודות של מזהה הלקוח ב-OAuth 2.0, צריך לבקש מהאדמין להקצות לכם ב-IAM את התפקיד עורך הגדרות OAuth (roles/oauthconfig.editor) בפרויקט. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

ההרשאות הנדרשות

כדי לאפס סודות של מזהי לקוחות ב-OAuth 2.0, נדרשות ההרשאות הבאות:

  • clientauthconfig.clients.createSecret
  • clientauthconfig.clients.getWithSecret
  • clientauthconfig.clients.update
  • clientauthconfig.clients.get

יכול להיות שתקבלו את ההרשאות האלה באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.

איפוס הסוד של מזהה הלקוח ב-OAuth 2.0

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

    כניסה לדף Credentials

  2. בוחרים את מזהה הלקוח שנחשף ב-OAuth 2.0 ועורכים אותו.

  3. לוחצים על Reset Secret.

  4. פורסים את הסוד החדש באפליקציה.

למידע נוסף, תוכלו לקרוא את המאמר הגדרת OAuth 2.0 ושימוש ב-OAuth 2.0 לגישה ל-Google APIs.

אסימוני גישה מאוחדים של Security Token Service

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

התפקידים הנדרשים

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

  • ניהול מאגרים וספקים של זהויות של עומסי עבודה: Workload Identity Pool Admin (roles/iam.workloadIdentityPoolAdmin) בפרויקט שמכיל את מאגר הזהויות של עומסי עבודה
  • ניהול ספקים ומאגרים של זהויות של כוח העבודה: אדמין של מאגר זהויות של כוח העבודה (roles/iam.workforcePoolAdmin) בארגון שמכיל את מאגר הזהויות של כוח העבודה
  • החלת כללי מדיניות דחייה כדי לחסום טוקנים פעילים: אדמין דחייה (roles/iam.denyAdmin) בארגון
  • ניהול התחזות לחשבון שירות: אדמין של חשבון שירות (roles/iam.serviceAccountAdmin) בפרויקט שמכיל את חשבון השירות

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

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

ההרשאות הנדרשות

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

  • ניהול ספקים ומאגרים של זהויות של עומסי עבודה:
    • ‫iam.workloadIdentityPools.update בפרויקט שמכיל את מאגר הזהויות של עומסי העבודה
    • ‫iam.workloadIdentityPoolProviders.update בפרויקט שמכיל את מאגר הזהויות של עומסי העבודה
  • ניהול ספקים ומאגרים של זהויות של כוח העבודה:
    • ‫iam.workforcePools.update בארגון שמכיל את מאגר הזהויות של כוח העבודה
    • ‫iam.workforcePoolProviders.update בארגון שמכיל את מאגר הזהויות של כוח העבודה
  • החלת מדיניות דחייה כדי לחסום טוקנים פעילים:
    • iam.denypolicies.create בארגון
    • iam.denypolicies.update בפרויקט, בתיקייה או בארגון
  • ניהול התחזות לחשבון שירות: iam.serviceAccounts.setIamPolicy בפרויקט שמכיל את חשבון השירות

יכול להיות שתקבלו את ההרשאות האלה באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.

חסימת טוקנים של גישה מאוחדת

  1. מבצעים אחת מהפעולות הבאות:

  2. כדי לחסום גישה מיידית לאסימוני bearer פעילים (שתקפים למשך שעה לכל היותר), מבצעים אחת מהפעולות הבאות:

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

קובצי cookie בדפדפן

כדי לבטל את התוקף של קובצי Cookie בדפדפן עבור משתמש, צריך לבצע את השלבים הבאים.

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות כדי להוציא משתמש מהחשבון ולכפות שינוי סיסמה במסוף Admin ב-Google Workspace, צריך לבקש מהאדמין להקצות לכם את התפקיד אדמין לניהול משתמשים או סופר-אדמין.

מידע נוסף על הקצאת תפקידי אדמין ב-Google Workspace זמין במאמר הפיכת משתמש לאדמין.

ביטול התוקף של קובצי Cookie בדפדפן

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

הפעולות האלו מבטלות את התוקף של כל קובצי ה-cookie הקיימים, והמשתמשים יצטרכו להתחבר מחדש.

חקירת גישה לא מורשית למשאבים ושימוש בהם אחרי ביטול אישורים

אחרי שמבטלים את פרטי הכניסה שנחשפו ומשחזרים את הגישה לשירות, כדאי לבדוק את כל הגישה למשאבים Google Cloud . אפשר להשתמש ב-Cloud Logging או ב-Security Command Center.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות בשביל לחקור גישה לא מורשית למשאבים, אתם צריכים לבקש מהאדמין לתת לכם את תפקידי ה-IAM הבאים:

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

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

ההרשאות הנדרשות

כדי לחקור גישה לא מורשית למשאבים ושימוש בהם, נדרשות ההרשאות הבאות:

  • צפייה ביומני ביקורת ב-Logging:
    • logging.logEntries.list בפרויקט, בתיקייה או בארגון
    • logging.views.access בפרויקט, בתיקייה או בארגון
  • צפייה ביומני ביקורת של גישה לנתונים ב-Logging: logging.privateLogEntries.list בפרויקט, בתיקייה או בארגון
  • צפייה בממצאים ב-Security Command Center:
    • securitycenter.findings.list בפרויקט או בארגון
    • securitycenter.findings.get בפרויקט או בארגון

יכול להיות שתקבלו את ההרשאות האלה באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.

בדיקת גישה לא מורשית למשאבים ושימוש בהם

ב-Logging, מבצעים את הפעולות הבאות:

  1. בודקים את יומני הביקורת במסוףGoogle Cloud .

    כניסה לדף Logs Explorer

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

    לדוגמה, מבצעים את הפעולות הבאות:

    • מחפשים את כל קריאות ה-API שהופעלו על ידי הזהות שנפרצה במהלך חלון האירוע.
    • אם לזהות היו הרשאות התחזות, מחפשים פעולות שבהן protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail תואם לחשבון המשתמש שנפרץ.
    • בודקים אם נוצרו מפתחות חדשים לחשבונות שירות, חשבונות משתמשים חדשים או מפתחות SSH ברמת הפרויקט במהלך האירוע.

ב-Security Command Center, מבצעים את הפעולות הבאות:

  1. במסוף Google Cloud , עוברים לדף Findings של Security Command Center.

    כניסה לדף Findings

  2. אם צריך, בוחרים את Google Cloud הפרויקט או הארגון.

  3. בקטע Quick filters (מסננים מהירים), לוחצים על המסנן המתאים כדי להציג את הממצא שרוצים בטבלה Findings query results (תוצאות של שאילתת ממצאים). לדוגמה, אם בוחרים באפשרות Event Threat Detection או Container Threat Detection בקטע המשנה שם התצוגה של המקור, בתוצאות יופיעו רק ממצאים מהשירות שנבחר.

    הטבלה תאוכלס בממצאים לגבי המקור שבחרתם.

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

  5. כדי להציג את כל הממצאים שנוצרו כתוצאה מהפעולות של אותו משתמש:

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

    3. בעורך השאילתות, מזינים את השאילתה הבאה:

      access.principal_email="USER_EMAIL"

      מחליפים את USER_EMAIL בכתובת האימייל שהעתקתם קודם.

      ב-Security Command Center מוצגים כל הממצאים שמשויכים לפעולות שבוצעו על ידי המשתמש שציינתם.

מחיקת כל המשאבים הלא מורשים

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

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

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

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

יצירת קשר עם שירות הלקוחות

אם אתם לא מוצאים את היומנים והכלים Google Cloud של Google Cloud שאתם צריכים לפעולות החקירה והטיפול, וזקוקים לעזרה, תוכלו לפנות אל שירות הלקוחות של Cloud ולשלוח בקשת תמיכה.

טיפול במקרים של אובדן גישה לחשבון

אם אין לכם גישה לחשבון, אתם יכולים לנסות את האפשרויות הבאות:

  • אפשר להשתמש בטופס לשחזור חשבון Google Workspace, שזמין בארגז הכלים של Google Admin. מידע נוסף מופיע במאמר בנושא איך משחזרים גישה של אדמין לחשבון.

  • אם תוקף יוצר משאבים שמקורם בתרמית בזמן שאתם נעולים לחלוטין מחוץ לחשבון ויש לכם זכאות לתמיכה, עליכם לבצע את הפעולות הבאות:

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

    2. בוחרים באפשרות כן ולוחצים על שליחת כרטיס.

    3. ממלאים את הטופס ושולחים אותו עם הפרטים שלכם.

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

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

    2. עונים על השאלות באופן הבא:

      שאלה בפותר הבעיות בחירה נדרשת
      יש לך זכאות לתמיכה? לא
      האם אתם נמצאים כרגע בתקופת הניסיון בחינם? לא
      האם יש לך הרשאת אדמין לחיוב בחשבון לחיוב ב-GCP ‏ (Google Cloud)? לא
      האם נתקלת באחת מהסיטואציות האלה? אין לי יותר גישה לפרויקט ב-GCP או לחשבון לחיוב, ואני צריך לקבל שוב גישה.

    3. לוחצים על שליחת כרטיס לצוות לשחזור גישה.

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

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

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