שיטות מומלצות לצמצום פריצת אסימוני OAuth עבור Google Cloud CLI

Last reviewed 2025-03-10 UTC

במאמר הזה מוסבר איך לצמצם את ההשפעה של תוקף שפרץ לאסימוני OAuth מסוג bearer שמשמשים את ה-CLI של gcloud.

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

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

סקירה כללית

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

סוגים של פרטי כניסה שמאוחסנים ב-CLI של gcloud

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

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

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

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

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

איך תוקף יכול להשתמש בטוקנים של OAuth שנפרצו

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

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

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

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

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

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

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

כדי לסייע בצמצום הסיכון לאיומים על טוקנים של ה-CLI של gcloud, מומלץ להטמיע את אמצעי הבקרה שמתוארים בקטעים הבאים. אם אתם פועלים לפי השיטות המומלצות לאבטחה שמתוארות בתוכנית הבסיסית לארגונים או בעיצוב אזור הנחיתה ב- 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 בו-זמני (mTLS). בקשות שמשתמשות בפרטי הרשאה שנפרצו אבל לא עומדות בתנאים שמוגדרים במדיניות 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. כשמשתמשים ב-IAP Desktop או בפלאגינים של RDP שמבוססים על Google Chrome, צריך להגדיר אמצעי בקרה גסים כמו משך הסשן בשירותי Google ואימות דו-שלבי לסשנים של המשתמשים באינטרנט, ולהשבית את ההגדרה המשתמש יכול להוסיף את המכשיר לרשימת המכשירים המהימנים בקטע 'אימות דו-שלבי'.

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

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

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

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

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

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

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

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

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

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

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

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

כדי להסיר גישה מחשבון משתמש שנפרץ, צוות התגובה לאירועים צריך תפקיד במסוף Admin, כמו אדמין לניהול משתמשים. כדי להעריך אם התרחשה פעילות חשודה במשאבים שלכם, יכול להיות שהצוות יזדקק גם לתפקידי IAM, כמו Security Reviewer בכל הפרויקטים או Logs Viewer ב-sink ביומן מרכזי. Google Cloudהתפקידים הנדרשים לצוות האבטחה משתנים בהתאם לעיצוב ולתפעול של הסביבה.

שיטות מומלצות לתיקון אחרי אירוע אבטחה

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

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

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

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

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

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

משתמשים יכולים גם להסיר את פרטי הכניסה של ה-CLI של gcloud מהחשבון האישי שלהם.

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

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

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

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

בדוגמת הקוד הבאה נעשה שימוש ב-Workspace Admin SDK כדי לזהות את כל זהויות המשתמשים בחשבון Google Workspace או Cloud Identity שיש להם גישה אל ה-CLI של gcloud. אם משתמש אישר את ה-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)
      }
    }
  }
}

ביטול תוקף והחלפה של פרטי כניסה לחשבונות שירות

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

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

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

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