שיטות מומלצות להגנה על פרטי הכניסה של מפתחים

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

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

הסיכון שפרטי הכניסה ייחשפו

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

סקירה כללית על פרטי הכניסה של מפתחים

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

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

טוקנים של OAuth ב-CLI של gcloud

ה-CLI של gcloud משתמש באסימוני גישה מסוג OAuth 2.0 כדי לאמת בקשות ל-Google Cloud APIs. תהליך OAuth משתנה בהתאם לסוגי פרטי הכניסה שבהם נעשה שימוש, אבל בדרך כלל אסימון הגישה ופרטי כניסה אחרים נגישים באופן מקומי. בכל מקרה, אסימון הגישה פג אחרי 60 דקות כברירת מחדל, אבל יכול להיות תקף עד 12 שעות בהתאם למגבלות של משך חיים מורחב. עם זאת, יכול להיות שסוגים אחרים של פרטי כניסה יהיו קבועים.

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

כשמאשרים את ה-CLI של gcloud באמצעות חשבון שירות, ה-CLI של gcloud מתחיל תהליך OAuth דו-רגלי כדי לגשת לממשקי API שלGoogle Cloud בתור הזהות של חשבון השירות. אחרי שמפעילים חשבון שירות מקובץ מפתח פרטי, ה-CLI של gcloud משתמש במפתח הזה כדי לבקש אסימון גישה באופן תקופתי. המפתח הפרטי לטווח ארוך מאוחסן בהגדרות של ה-CLI של gcloud, והוא תקף עד שמשביתים או מוחקים את המפתח של חשבון השירות.

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

Application Default Credentials

אפליקציות משתמשות ב-Application Default Credentials כדי לעבור אימות מולGoogle Cloud ממשקי API. מפתחים יכולים ליצור Application Default Credentials באמצעות הפקודה gcloud auth application-default login. הפקודה הזו כותבת קובץ JSON בטקסט פשוט ($HOME/.config/gcloud/application_default_credentials.json או %APPDATA%\gcloud\application_default_credentials.json), שמכיל אסימון רענון של OAuth 2.0 ופרטי כניסה של לקוח לספריות לקוח.

כל ספריית לקוח או סקריפט בהתאמה אישית יכולים להשתמש בפרטי הכניסה האלה כדי לקרוא ל-Google Cloud APIs.

מאחר שהאישורים שמוגדרים כברירת מחדל לאפליקציה נשמרים כטקסט פשוט, כל תהליך או סקריפט לא מהימנים שפועלים בהקשר של המשתמש יכולים לגשת לקובץ ישירות או להשתמש בפקודות כמו gcloud auth application-default print-access-token כדי לאחזר טוקנים פעילים של גישה.

תוכנות זדוניות בדרך כלל מכוונות לתיקייה ~/.config/gcloud/ כדי לאסוף application_default_credentials.json.

מידע נוסף זמין במאמר בנושא Application Default Credentials.

מפתחות של חשבונות שירות

מפתחות של חשבונות שירות הם קובצי מפתח פרטיים בפורמט JSON שמורידים מGoogle Cloud מסוף Google. האפליקציות משתמשות במפתחות האלה כדי לבצע אימות מולGoogle Cloud ממשקי API. אפשר לאחסן מפתחות של חשבונות שירות במיקומים הבאים:

  • ספריית ההגדרות האישיות של ה-CLI של gcloud אחרי הרצת הפקודה gcloud auth activate-service-account
  • מערכת הקבצים המקומית
  • מאגר המקורות של הקוד פנימי

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

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

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

מפתחות SSH

מפתחות SSH משמשים לאימות במכונות של Compute Engine. מפתחים יכולים ליצור מפתחות SSH באמצעות gcloud compute ssh. הפקודה הזו יוצרת מפתחות פרטיים מקומיים ב-~/.ssh/google_compute_engine. מפתחות SSH הם לטווח ארוך.

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

במקום להשתמש במפתחות SSH, כדאי לשקול שימוש בOS Login עם אימות דו-שלבי. מידע נוסף זמין במאמר אכיפת אימות דו-שלבי לגישה לשרת מרוחק.

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

קובצי Cookie בדפדפן מאמתים בקשות HTTP באינטרנט אל Google Cloud המסוף ואל Cloud Shell. קובצי Cookie בדפדפן נוצרים באופן אוטומטי כשמשתמש נכנס ל Google Cloud מסוף.

קובצי ה-Cookie מאוחסנים בספריית הפרופילים של הדפדפן בתחנת העבודה המקומית. לדוגמה, קובצי Cookie מאוחסנים ב-Google Chrome בנתיב ~/.config/google-chrome/ ב-Linux או בנתיב %LOCALAPPDATA%\Google\Chrome\User Data ב-Windows.

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

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

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

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

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

כדי להיכנס באמצעות זהות מאוחדת, המפתחים משתמשים בקובץ הגדרות כניסה (שנוצר באמצעות הפקודה gcloud iam workforce-pools create-login-config) ונכנסים ל-CLI של gcloud. אחרי האימות בספק הזהויות החיצוני, שירות אסימון האבטחה מחליף את קוד ההרשאה באסימון גישה לטווח קצר של איחוד שירותי האימות ובאסימון רענון של OAuth.

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

תוקף שפורץ לנקודת קצה יכול לחלץ טוקנים פעילים של גישה מאוחדת או להשתמש ב-gcloud auth print-access-token כדי להתחזות למשתמשים בארגון. אם לזהות של כוח העבודה יש הרשאות התחזות, התוקף יכול גם לבקש אסימונים לגישה לחשבון השירות כדי להסלים את ההרשאות.

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

ההשפעה של פרטי כניסה שנחשפו

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

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

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

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

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

  • התחזות לחשבון המשתמש או לחשבון השירות שנפרצו. תנועת נתונים ב-API שמשתמשת בטוקנים שנפרצו מתועדת כאילו היא הגיעה מהמשתמש או מחשבון השירות שנפרצו, ולכן קשה להבחין בין פעילות רגילה לפעילות זדונית ביומנים.
  • אפשר לבקש אסימוני גישה ללא הגבלת זמן באמצעות אסימון רענון מתמשך של OAuth (מ-ה-CLI של gcloud או מ-Application Default Credentials) או מפתח פרטי שמשויך לחשבון שירות.
  • לעקוף את האימות באמצעות הסיסמה של המשתמש או האימות הדו-שלבי, כי האסימונים מוענקים אחרי תהליך הכניסה.
  • שימוש במפתחות SSH גנובים כדי לגשת למכונות של Compute Engine ולבצע שאילתות בשרת המטא-נתונים כדי לגנוב אסימונים של חשבונות שירות שמצורפים למכונות.
  • להשתמש בקובצי Cookie גנובים בדפדפן כדי לחטוף סשנים פעילים במסוף Google Cloud בלי לדרוש את הסיסמה של המשתמש או אימות דו-שלבי.
  • שימוש באסימוני גישה מאוחדים שנגנבו כדי לגשת למשאבים שניתנו למאגרי זהויות של כוח העבודה או להסלים הרשאות על ידי התחזות לחשבונות שירות.

שיטות מומלצות לצמצום הסיכונים

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

הגדרת אורך הסשן עבור שירותי Google Cloud

כדי לצמצם את משך הזמן שבו תוקף יכול לנצל אסימון שנפרץ, מגדירים את אורך הסשן של Google Cloudשירותים. ללקוחות חדשים, אורך ברירת המחדל של הסשן הוא 16 שעות והוא נאכף באופן אוטומטי. יכול להיות שלקוחות שיצרו את הארגון Google Cloud שלהם לפני 2023 הגדירו כברירת מחדל שלא תידרש אף פעם אימות מחדש. בודקים את ההגדרה הזו כדי לוודא שיש לכם מדיניות אימות מחדש עם משך ביקור של שעה עד 24 שעות. מדיניות האימות מחדש מחייבת את המשתמשים לבצע אימות מחדש ב-CLI של gcloud באופן קבוע באמצעות הסיסמה או מפתח האבטחה שלהם.

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

הגדרת VPC Service Controls

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

הגדרה של Chrome Enterprise Premium

הגדרת מדיניות של Chrome Enterprise Premium כדי לאבטח את Google Cloud המסוף ואת Google Cloud ממשקי ה-API. הגדרת רמת גישה ב-Chrome Enterprise Premium וקישור שלה כדי לאפשר באופן סלקטיבי מאפיינים שנבדקים בכל בקשת API, כולל גישה מבוססת-IP או גישה מבוססת-אישור ל-TLS דו-כיווני. בקשות שמשתמשות בפרטי הרשאה שנפרצו אבל לא עומדות בתנאים שמוגדרים במדיניות Chrome Enterprise Premium נדחות.

‫Chrome Enterprise Premium הוא אמצעי בקרה שמתמקד במשתמשים ודוחה תנועת API של משתמשים שלא עומדת בתנאים מוגדרים. VPC Service Controls הוא אמצעי בקרה שמתמקד במשאבים ומגדיר את הגבולות שבהם המשאבים יכולים לתקשר. השירות VPC Service Controls חל על כל הזהויות של המשתמשים וחשבונות השירות, אבל Chrome Enterprise Premium חל רק על הזהויות של המשתמשים בארגון. כשמשתמשים ב-Chrome Enterprise Premium וב-VPC Service Controls ביחד, הם מצמצמים את היעילות של פרטי כניסה שנפרצו במחשב שנשלט על ידי תוקף שנמצא מחוץ לסביבה שלכם.

אכיפת אימות דו-שלבי לגישה לשרת מרחוק

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

גישה ל-Remote Desktop Protocol ‏ (RDP) למופעי Windows ב-Compute Engine לא תומכת בשירות OS Login, ולכן אי אפשר לאכוף אימות דו-שלבי בצורה מפורטת עבור סשנים של RDP. כשמשתמשים ב-Identity-Aware Proxy (IAP) Desktop או בתוספים של RDP שמבוססים על Google Chrome, צריך לבצע את הפעולות הבאות:

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

  • משביתים את ההגדרה משתמשים יכולים לתת אמון במכשירים בקטע 'אימות דו-שלבי'.

הגבלת השימוש במפתחות של חשבונות שירות

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

כדי לצמצם או לבטל את תרחישי השימוש שלכם שתלויים במפתח של חשבון שירות, כדאי לעיין בחלופות מאובטחות יותר לאימות. בנוסף, אוכפים את האילוצים של מדיניות הארגון constraints/iam.disableServiceAccountKeyCreation ו-constraints/iam.disableServiceAccountKeyUpload כדי להשבית את היצירה של מפתחות לחשבון שירות.

החלת העיקרון של הרשאות מינימליות

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

הגנה על נקודות הקצה

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

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

  • איך מוגנת האבטחה הפיזית של תחנות עבודה של מפתחים?
  • איך מזהים פריצות לרשת ומגיבים להן?
  • איך משתמשים מקבלים גישה מרחוק לסשנים של SSH או RDP?
  • איך יכול להיות שפרטי כניסה קבועים כמו מפתחות SSH או מפתחות של חשבונות שירות ייפגעו?
  • האם יש תהליכי עבודה שמשתמשים בפרטי כניסה קבועים שאפשר להחליף בפרטי כניסה לטווח קצר?
  • האם יש מכשירים משותפים שבהם מישהו יכול לקרוא את פרטי הכניסה של משתמש אחר ל-CLI של gcloud שנשמרו במטמון?
  • האם משתמש יכול לבצע אימות באמצעות ה-CLI של gcloud ממכשיר לא מהימן?
  • איך תעבורת נתונים מאושרת מתחברת למשאבים בתוך גבולות הגזרה של VPC Service Controls?

חשוב לוודא שפעולות האבטחה שלכם נותנות מענה לכל אחת מהשאלות האלה.

התאמה בין צוותי התגובה

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

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

מעקב לזיהוי חשיפה של פרטי כניסה

כדי להיות עם יד על הדופק ולזהות חשיפות פוטנציאליות, כדאי:

  • לסרוק סודות במאגרי הקודים באמצעות כלים כמו זיהוי אנומליות או סריקת סודות.

  • ב-Cloud Audit Logs, מגדירים התראות לגבי הפעולות הבאות:

    • שיטות iamcredentials.googleapis.com (כמו GenerateAccessToken,‏ GenerateIdToken, ‏ SignJwt) לביקורת על יצירת אסימונים בחשבון שירות

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

    • protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail כדי לבצע ביקורת על התחזויות של משתמשים וחשבונות שירות

    • sts.googleapis.com בקשות להחלפה של הצהרות חריגות לגבי זהות

  • ב-Security Command Center, מנטרים את ממצאי האיומים הבאים מ-Event Threat Detection:

    • התמדה: מיקום גיאוגרפי חדש
    • התמדה: סוכן משתמש חדש
    • התמדה: שיטת API חדשה
    • התחמקות: גישה משרת proxy לאנונימיזציה
    • העלאת רמת ההרשאה: התחזות חריגה לחשבון שירות לצורך פעילות אדמין
    • העלאת הרשאות: התחזות חריגה לחשבון שירות לצורך פעילות אדמין
    • גישה ראשונית: נעשה שימוש במפתח של חשבון שירות שדלף
    • התמדה: נוצר מפתח לחשבון השירות
    • גישה ראשונית: נחסמה התחברות חשודה
    • גישה ראשונית: החשבון הושבת כי הוא נפרץ

    לכל איום, מוצגים שלבים מומלצים לחקירה שיעזרו לכם להגיב.

  • לעקוב אחרי התחברות של משתמשים ב-Google Workspace וב-Cloud Identity. כדאי לייצא את היומנים ל-Cloud Logging כדי שיהיה מעקב טוב יותר אחרי בעיות.

  • מעקב אחרי יומנים מ-Chrome Enterprise Premium ומ-VPC Service Controls כדי לזהות ניסיונות גישה מחוץ לאזור עם טוקנים גנובים.

  • לעקוב אחרי חריגות בשימוש במפתחות של חשבונות שירות באמצעות Cloud Monitoring.

חשוב לוודא שאתם מקבלים התראות מיידיות במרכז האבטחה (SOC) שלכם, ושב-SOC יש את הפלייבוקים, הרשאות הגישה והכלים הנדרשים כדי להגיב במהירות לכל חשד לחשיפה של פרטי הכניסה. אפשר גם לשלב את Security Command Center עם הכלי הקיים לניהול אירועים ואבטחת מידע (SIEM) או לייבא יומנים ל-Google Security Operations להמשך ניתוח.

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