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

במסמך הזה מפורטות שיטות מומלצות להגנה על פרטי הכניסה ל-SSH.

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

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

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

התייחסות למפתחות פרטיים של SSH באופן דומה למפתחות של חשבונות שירות

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

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

שימוש במפתחות SSH זמניים למשתמשי מכונה

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

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

  1. לבצע אימות כחשבון שירות בלי להשתמש במפתח או בסוד, למשל באמצעות חשבון שירות מצורף או איחוד שירותי אימות הזהות של עומסי עבודה.
  2. יוצרים זוג מפתחות SSH זמני באמצעות כלי כמו ssh-keygen.

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

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

  4. משתמשים במפתח הפרטי כדי ליצור חיבורי SSH למכונות וירטואליות.

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

לדוגמה:

# Generate RSA key pair without passphrase
ssh-keygen -t rsa -f ephemeral_key -q -N "" -V 30m

# Publish key to the service account's OS Login profile, with 30 min expiry
gcloud compute os-login ssh-keys add --key-file ephemeral_key.pub --ttl 30m

# Look up the service account's UNIX username
USERNAME=$(gcloud compute os-login describe-profile --format "value(posixAccounts[0].username)")

# Authenticate using the service account's UNIX user and public key
ssh $USERNAME@VM whoami

# Remove key
gcloud compute os-login ssh-keys remove --key-file ephemeral_key.pub

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

שימוש ב-IAP בנוסף לאימות באמצעות מפתח ציבורי SSH

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

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

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

‫IAP פועל כשרת proxy הפוך ומאפשר למשתמשים ליצור חיבורי SSH למכונות וירטואליות רק אם הם עברו אימות באמצעות פרטי הכניסה שלהם ב-Google. בנוסף, IAP מאפשרת לכם להגביל את המכונות הווירטואליות שהמשתמשים יכולים להתחבר אליהן ולאכוף בקרת גישה מבוססת-הקשר.

שימוש באימות רב-שלבי

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

כדי לצמצם את ההשפעה האפשרית של מתקפות כאלה של גניבת פרטי כניסה, אפשר להגדיר ב-Cloud Identity או ב-Google Workspace שיידרש אימות רב-שלבי (MFA).

אם Cloud Identity או Google Workspace הם ספק הזהויות הראשי שלכם, אתם יכולים לאכוף אימות דו-שלבי באופן הבא:

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

אם אתם משתמשים בכניסה יחידה (SSO) עם ספק זהויות חיצוני, בצעו את הפעולות הבאות במקום זאת:

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

כדי לוודא ש-MFA חל גם על גישת SSH, צריך לבצע לפחות אחת מהפעולות הבאות:

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

משתמשים עם התפקיד אדמין מכונות של Compute או תפקיד שווה ערך במכונה וירטואלית או בפרויקט יכולים להשבית את האימות הדו-שלבי ב-OS Login על ידי שינוי המטא-נתונים של המכונה. לכן, היעילות של 2FA ב-OS Login מוגבלת אם לא אוכפים גם MFA ב-Cloud Identity או בספק הזהויות החיצוני (IdP).

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

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

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

  • שימוש במפתח שמגובה בחומרה: בגרסאות מודרניות של OpenSSH אפשר להשתמש במפתחות אבטחה מסוג FIDO2 לאימות, ואפשר להגדיר את OS Login כך שהוא יאפשר רק מפתחות אבטחה שרשומים ב-Cloud Identity או ב-Google Workspace. שימוש במפתחות שמגובים בחומרה עוזר לכם להימנע מאחסון של חומר מפתח פרטי במערכת הקבצים של המחשב.
  • שימוש במתקני אחסון מפתחות של מערכת ההפעלה: לדוגמה, IAP Desktop לא משתמש במפתחות מבוססי-קובץ, אלא ב-Windows CNG כדי להגן על מפתחות ה-SSH.

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

שימוש במפתחות מארח לאימות המארח

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

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

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

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

אל תשאירו פרטי כניסה אישיים במכונות וירטואליות

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

יכול להיות שמשתמשים אחרים לא יוכלו לגשת למחשב המקומי שלכם, אבל במופע של VM, משתמשים אחרים עם הרשאות sudo יכולים לגשת גם לספריית הבית שלכם ב-VM.

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

כשמתחברים למכונה וירטואלית באמצעות SSH, מומלץ להימנע ממתן הרשאה ל-CLI של gcloud או ל-Application Default Credentials (ADC) באמצעות פרטי הכניסה האישיים, ולאפשר ל-CLI של gcloud להשתמש בחשבון השירות שמצורף למכונה הווירטואלית. באופן דומה, כדאי להימנע מהפעלת כלים אחרים שעשויים לאחסן פרטי כניסה אישיים בספריית הבית.

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

לא לשלוח מפתחות פרטיים של SSH למאגרים של קוד מקור

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

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

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

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

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