שיטות מומלצות לשליטה בגישת התחברות באמצעות SSH

במסמך הזה מתוארות שיטות מומלצות לשליטה בגישת התחברות SSH למכונות וירטואליות (VM) של Linux.

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

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

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

שימוש ב-OS Login כדי להבטיח הערכה רציפה של הגישה בהתאם למדיניות IAM

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

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

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

  • הרשאת מפתחות ב-OS Login: משתמשים מעלים מפתח ציבורי אחד או יותר לפרופיל שלהם ב-OS Login, שהוא חלק מחשבון המשתמש שלהם ב-Google.

    אדמינים יכולים להחליט אם לתת למשתמש הרשאות root או הרשאות משתמש רגילות במכונה הווירטואלית. כדי לעשות את זה, הם צריכים להקצות למשתמש את תפקיד ה-IAM‏ OS Login Admin User או את תפקיד ה-IAM‏ OS Login User.

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

ההבדל העיקרי בין שני המנגנונים הוא מתי מתבצעת הערכה של הגישה בהתאם למדיניות IAM:

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

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

  • עם OS Login, הגישה מוערכת בכל פעם שמשתמש מנסה ליצור סשן SSH.

    המפתח של המשתמש קשור למחזור החיים של חשבון המשתמש שלו. אם משעים או מוחקים משתמש ב-Cloud Identity או ב-Google Workspace, אי אפשר יותר להשתמש במפתחות שלו כדי להעניק גישת SSH.

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

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

שימוש במדיניות הארגון כדי לאכוף שימוש עקבי ב-OS Login

השירות OS Login נשלט על ידי מפתח המטא-נתונים enable-oslogin: אם מגדירים את enable-oslogin לערך TRUE במטא-נתונים של הפרויקט או של המכונה, השירות OS Login מופעל. אם מגדירים אותו לערך FALSE, השירות מושבת.

כדי לשנות מטא-נתונים ברמת הפרויקט, צריך את ההרשאה compute.projects.setCommonInstanceMetadata בפרויקט. ההרשאה הזו היא חלק מהתפקידים אדמין מכונות של Compute (roles/compute.instanceAdmin.v1) ואדמין Compute (roles/compute.admin). באופן דומה, כדי לשנות מטא-נתונים ברמת המכונה הווירטואלית צריך את ההרשאה compute.instances.setMetadata במכונה הווירטואלית הרלוונטית.

מטא נתונים ברמת המופע מקבלים עדיפות גבוהה יותר ממטא נתונים ברמת הפרויקט. לכן, הגדרת enable-oslogin ל-TRUE במטא-נתונים של הפרויקט לא מספיקה כדי לאכוף את השימוש ב-OS Login בכל הפרויקט: משתמשים עם אדמין מכונות של Compute או גישה שוות ערך למכונות וירטואליות בפרויקט יכולים לעקוף את ההגדרה שלכם על ידי הוספת enable-oslogin=FALSE למטא-נתונים של המכונה הווירטואלית.

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

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

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

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

  • מעניקים למשתמשים את התפקיד Compute Viewer או תפקיד שווה ערך עם הרשאת צפייה בלבד ברמת הפרויקט. התפקיד הזה מאפשר למשתמשים לעיין במכונות וירטואליות באמצעות מסוף Google Cloud , אבל לא מאפשר להם לפרסם מפתחות SSH או לגשת למכונות הווירטואליות.
  • מעניקים למשתמשים את התפקידים OS Login,‏ אדמין מכונות של Compute או תפקידים אחרים עם הרשאות מיוחדות רק למכונות וירטואליות ספציפיות, או רק על בסיס הרשאה זמנית.

השעיית חשבונות משתמשים כשמשתמשים עוזבים את הארגון

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

אם הגדרתם את Cloud Identity או את Google Workspace לשימוש בספק IdP חיצוני לצורך כניסה יחידה (SSO), לעובדים יש חשבון משתמש גם בספק ה-IdP החיצוני וגם ב-Cloud Identity או ב-Google Workspace. השבתה או מחיקה של חשבון משתמש של עובד בספק חיצוני של IdP מבטלת את היכולת שלו ליצור סשנים חדשים בדפדפן כדי לגשת לשירותי Google, אבל אין לה השפעה מיידית על OS Login: כל עוד חשבון המשתמש של העובד ב-Cloud Identity או ב-Google Workspace נשאר פעיל, OS Login תמשיך לאפשר למשתמש לאמת את הזהות שלו וליצור חיבורי SSH.

כדי לשלול את הגישת SSH באופן מהימן כשמשתמש עוזב את הארגון, חשוב להשעות או למחוק את חשבון המשתמש שלו ב-Cloud Identity או ב-Google Workspace. אם אתם משתמשים ב-IdP חיצוני, הגדירו אותו כך שיפיץ אירועים של השעיית משתמשים כדי ש-OS Login יוכל לבטל את הגישה.

הימנעו מהענקת גישת SSH למכונות וירטואליות שמחובר אליהן חשבון שירות בעל הרשאות

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

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

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

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

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

הגבלת השימוש בהרשאות root

כשמשתמשים ב-OS Login ומעניקים למשתמש את התפקיד OS Login User (roles/compute.osLogin), מקצים למשתמש הרשאות משתמש מוגבלות במכונה הווירטואלית. לעומת זאת, כשנותנים למשתמש את התפקיד OS Login Admin User (roles/compute.osAdminLogin), משתמשים בהרשאת מפתחות שמבוססת על מטא-נתונים במקום ב-OS Login, או מאפשרים למשתמשים לשנות את המטא-נתונים של המכונה הווירטואלית, אתם נותנים למשתמש באופן מרומז הרשאות root במכונה הווירטואלית.

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

כדי לצמצם את הסיכון הזה, כדאי להגביל את השימוש בהרשאות root ולהקצות רק את התפקיד OS Login User ‏ (roles/compute.osLogin) כשאין צורך בהרשאות root.

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

כל מכונה וירטואלית של Linux מחזיקה במסד נתונים מקומי של משתמשים (/etc/passwd) וקבוצות (/etc/groups). כשמתחברים לראשונה למכונה וירטואלית של Linux באמצעות SSH, סביבת האורח יוצרת באופן אוטומטי חשבון משתמש ב-Linux ומקצה לו UID.

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

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

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

  • שם משתמש ב-Linux שהוא ייחודי לכל המשתמשים באותו חשבון Cloud Identity או Google Workspace
  • מזהה משתמש (UID) ומזהה קבוצה (GID) שייחודיים בכל Google Cloud הפרויקטים
  • נתיב של ספריית בית
  • הגדרות נוספות, כמו מעטפת כניסה

אם לחשבון Google שלכם אין פרופיל POSIX כשאתם נכנסים לראשונה, OS Login תיצור אותו בשבילכם באופן אוטומטי.

שם המשתמש ומזהי המשתמש (UID) שמוקצים על ידי OS Login הם ייחודיים בסביבת Google Cloud העבודה שלכם, אבל יכול להיות שהם יהיו זהים או לא עקביים עם שמות משתמש ומזהי משתמש שבהם אתם משתמשים מחוץ ל- Google Cloud. אם אתם צריכים ששמות המשתמשים ומזהי המשתמש (UID) של OS Login יהיו עקביים בסביבות אחרות, עדיף לא להסתמך על יצירה אוטומטית של פרופילים. במקום זאת, אפשר להשתמש ב-Directory API כדי ליצור מראש פרופילים של POSIX ל-OS Login ולהקצות שמות משתמשים, מספרי לקוחות ומספרי קבוצות בהתאמה אישית.

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