במסמך הזה מתוארות שיטות מומלצות לשליטה בגישה לרשת SSH למכונות וירטואליות (VM) של Linux.
כדי להתחבר למכונה וירטואלית באמצעות SSH, למשתמש צריכה להיות גישה לרשת של המכונה הווירטואלית ופרטי כניסה תקפים ל-SSH. כברירת מחדל, ב-Compute Engine מוגדר כלל חומת אש שלא מגביל את הגישה לרשת באמצעות SSH, אבל מאפשר לכל אחד באינטרנט להתחבר ליציאה 22 של מכונות וירטואליות. האפשרות הזו נוחה למפתחים שרוצים להתחיל במהירות בלי להתחשב באמצעי הבקרה של הרשת או האבטחה, אבל היא כרוכה בסיכונים כי היא מאפשרת למשתמשים להתחבר מכל מכשיר, רשת ומיקום:
- יכול להיות שהמשתמשים יתחברו ממכשירים או מרשתות לא מהימנים.
- גורמים זדוניים עלולים לבצע תקיפות בכוח ברוטלי ולנסות לפרוץ למכונות הווירטואליות שלכם.
- גורמים זדוניים עם גישה לפרטי כניסה ל-SSH שדלפו או שלא בוטלו בזמן יכולים להשתמש בפרטי הכניסה כדי לגשת למכונה וירטואלית ולהיכנס אליה מכל רשת.
בקטעים הבאים מתואר איך אפשר לצמצם את הסיכון על ידי הגבלת הרשתות, המיקומים או המכשירים שמהם משתמשים יכולים ליצור חיבור SSH למכונות הווירטואליות:
- הפחתת החשיפה לרשת
- שימוש במכונת VM מסוג Bastion אם אתם צריכים להקליט סשנים
- שימוש במדיניות חומת אש כדי להגביל את החשיפה של SSH
- השבתת הגישה למסוף הטורי
המסמך מתמקד בשיטות שספציפיות ל- Google Cloud או רלוונטיות במיוחד לשימוש ב-SSH ב- Google Cloud. המסמך לא כולל שיטות מומלצות להטמעות ספציפיות של לקוח או שרת SSH.
הפחתת החשיפה לרשת
אם מאפשרים למשתמשים ליצור חיבורי SSH מכל מקום, המשמעות היא שאתם מסתמכים באופן מלא על מנגנוני האימות וההרשאה של SSH כדי להגן על המכונות הווירטואליות. כדי להפחית את הסיכון וליצור שכבת הגנה נוספת, אפשר לצמצם את החשיפה של מכונות וירטואליות ברשת.
יש כמה גישות לצמצום החשיפה של המכונות הווירטואליות ברשת. כדי לזהות את הגישה שהכי מתאימה לסביבה שלכם, צריך להביא בחשבון מספר גורמים, כפי שמוצג בתרשים הזרימה הבא:
גישה חיצונית: הגורם הראשון שצריך לקחת בחשבון הוא אם צריך שהמכונה הווירטואלית תהיה נגישה רק בתוך רשת ה-VPC, או שצריך שהיא תהיה נגישה גם מבחוץ.
אם גישה פנימית ל-VPC מספיקה, לא צריך להקצות כתובת IP חיצונית למכונה הווירטואלית, אבל עדיין צריך להחליט איך לנהל את הגישה.
גודל הרשת הפנימית: אם גישה פנימית ל-VPC מספיקה, הגורם השני שצריך לקחת בחשבון הוא גודל הרשת הפנימית.
ברשתות קטנות יותר, יכול להיות שמספיק להשתמש בכללי חומת אש שמאפשרים תעבורת נתונים נכנסת (ingress) ליציאה
22מכתובות פנימיות כדי להגן על המכונות הווירטואליות. ברשתות גדולות יותר, הסתמכות על כללים של חומת אש בלבד עלולה להיות מגבילה מדי. במקרים כאלה, כדאי להשתמש בהעברת TCP באמצעות שרת proxy לאימות זהויות (IAP) כדי לאכוף בקרת גישה מבוססת-הקשר למכונות וירטואליות.תכנון גבולות הגזרה של VPC Service Controls: הגורם הבא שצריך לקחת בחשבון הוא אם מופע מכונת ה-VM הוא חלק מגבולות הגזרה של VPC Service Controls.
אם המכונה הווירטואלית היא חלק מגבולות גזרה לשירות, כל גישה ל-API שמקורה במכונה הווירטואלית נחשבת כגישה שמקורה בתוך גבולות הגזרה. כשמעניקים למשתמש שנמצא מחוץ לגבולות הגישה של SSH למכונה וירטואלית בתוך הגבולות, הוא יכול להעתיק נתונים מהגבולות לתחנת העבודה המקומית שלו, או להיפך – פעולה כזו עלולה לסכן את הסודיות והשלמות של הנתונים בגבולות.
בכל פעם שצריך להעניק גישת SSH למכונה וירטואלית ששייכת לגבול גזרה של VPC Service Controls, צריך להשתמש בהעברת TCP באמצעות IAP. IAP מזהה אם תחנת העבודה של המשתמש היא חלק מאותו גבול גזרה לשירות של VPC Service Controls, וחוסם כברירת מחדל ניסיונות גישה מחוץ לגבול גזרה לשירות. כדי לאפשר גישה חיצונית, צריך להשתמש בכללי Ingress ולהגדיר אותם כך שיאפשרו בקרת גישה מבוססת-הקשר.
ניהול מכשירי לקוח: הגורם האחרון שצריך לקחת בחשבון הוא איך מנוהלים מכשירי הלקוח, כי זה קובע את הדרכים שבהן אפשר לשלוט בבקרת גישה מבוססת-הקשר.
בקרת גישה מבוססת הקשר יעילה במיוחד כשAccess Context Manager מקבל גישה למערך עשיר של אותות לגבי משתמש, המכשיר שלו והמיקום שלו, ולכן הוא פועל בשילוב עם Chrome Enterprise Premium: אם אתם משתמשים ב-Chrome Enterprise Premium כדי לנהל את המכשירים שלכם, אתם יכולים להגדיר רמות גישה ששולטות בגישה על סמך מצב האבטחה של המכשיר. לאחר מכן אפשר להחיל את רמת הגישה הזו על גישת SSH באמצעות העברת TCP ב-IAP בשילוב עם הרשאות גישה או תנאי IAM.
אם אין לכם שליטה בהגדרות של מכשיר לקוח, אתם צריכים להתייחס אליו כמכשיר לא מנוהל וייתכן שהוא לא מהימן.
כדי לאפשר גישה ממכשירים לא מנוהלים, אפשר גם להשתמש בהעברת TCP באמצעות IAP, אבל אפשר לנהל גישה רק על סמך זהות המשתמש וכתובת ה-IP של המכשיר. ל-Access Context Manager אין גישה לאותות מהמכשיר, ולכן לא תוכלו להגביל את הגישה על סמך מצב האבטחה של המכשיר.
על סמך הגורמים ובעזרת תרשים הזרימה, תוכלו לזהות את הגישה לצמצום החשיפה של הרשת שהכי מתאימה לסביבה שלכם. בקטעים הבאים מוסבר על הגישות האלה בפירוט.
גישת SSH מבוססת-IAP
הרעיון מאחורי הגישה הזו הוא לאפשר גישת SSH רק דרך העברת TCP של IAP, ולאפשר ל-IAP לשלוט בגישה על סמך זהות המשתמש.
אנחנו ממליצים על הגישה הזו למכונות וירטואליות שמתקיימים בהן התנאים הבאים:
- צריכה להיות גישה למופע ה-VM מבחוץ או מרשת פנימית גדולה.
- המכונה הווירטואלית לא נכללת בהיקף של VPC Service Controls.
כברירת מחדל, מכונה וירטואלית עם כתובת IP חיצונית מאפשרת גישה ל-SSH כי חומות האש שמוגדרות כברירת מחדל מאפשרות חיבורים מהאינטרנט הציבורי ליציאה 22, אבל לא מומלץ להשתמש בגישה הזו. הגישה הזו יכולה להגדיל באופן משמעותי את הסיכון שהמכונה הווירטואלית תהיה חשופה להתקפות כמו:
- שימוש בפרטי כניסה שלא בוטלו: עובדים לשעבר שהגישה שלהם לא בוטלה באופן מלא עשויים להמשיך לגשת למכונה הווירטואלית.
- שימוש לרעה בפרטי כניסה תקפים: גורמים זדוניים שמחזיקים בפרטי כניסה גנובים או דולפים עלולים להשתמש בהם כדי להיכנס לחשבון.
- התקפת מניעת שירות (DoS): גורמים זדוניים עלולים לנסות לנצל את המשאבים של המכונה הווירטואלית על ידי הצפתה בבקשות.
דרך מאובטחת יותר לאפשר גישת SSH חיצונית למופע של מכונה וירטואלית היא באמצעות העברת TCP ב-IAP. בדומה ליעד מבוצר (bastion host) או לשרת proxy הפוך, העברת TCP ב-IAP פועלת כמתווך בין מכשיר הלקוח לבין מכונת ה-VM.
העברת TCP ב-IAP מבצעת את ארבע הפונקציות הבאות כשמשתמש מנסה ליצור חיבור SSH:
- אימות: שרת ה-proxy לאימות זהויות (IAP) מאמת שלמשתמש יש פרטי כניסה תקפים לחשבון Google.
- הרשאה: IAP בודק את כללי המדיניות של IAM כדי לוודא שהמשתמש קיבל הרשאה להתחבר ל-VM דרך IAP.
- בקרת גישה מבוססת-הקשר: אפשר להגדיר ש-IAP יאמת שהמשתמש, המכשיר והמיקום שלו עומדים ברמות גישה מסוימות.
- ביקורת: כשיומני בקרת הרשאות הגישה לנתונים מופעלים, IAP מתעד כל ניסיון מוצלח או כושל להתחבר למכונת VM.
IAP פועל כמתווך ומבצע את הפונקציות האלה, ולכן אין צורך להקצות כתובת IP חיצונית למכונה הווירטואלית, והוא מספק שכבת אבטחה נוספת.
גישת SSH מבוססת-הקשר שמבוססת על IAP
הרעיון מאחורי הגישה הזו הוא לאפשר גישת SSH רק באמצעות העברת TCP של IAP, ולאפשר ל-IAP לשלוט בגישה על סמך הזהות של המשתמש וגורמים נוספים.
אנחנו ממליצים על הגישה הזו למכונות וירטואליות שמתקיימים בהן התנאים הבאים:
- צריכה להיות גישה למכונה הווירטואלית מחוץ ל-VPC ולרשתות שמחוברות ל-VPC.
- המכונה הווירטואלית לא נכללת בהיקף של VPC Service Controls.
- המכונה הווירטואלית צריכה להיות נגישה רק ממכשירים, מרשתות או ממיקומים מסוימים.
כשמעניקים למשתמש גישת SSH למכונה וירטואלית – באופן ישיר או דרך IAP – כברירת מחדל הוא יכול לגשת למכונה הווירטואלית מכל מכשיר, רשת ומיקום. רמת הגישה הזו נוחה למשתמשים, אבל היא מגדילה את הסיכונים כי יכול להיות שהמשתמשים מתחברים ממכשירים שנפרצו או מרשתות לא מהימנות.
כדי לצמצם את הסיכון, כדאי להגדיר העברת TCP ב-IAP כך שהמשתמשים יוכלו לגשת למופעי מכונות וירטואליות רק ממכשירים או ממיקומים מסוימים. יש שתי דרכים להגדיר בקרת גישה מבוססת-הקשר:
הקצאות גישה: אפשר ליצור רמת גישה ולהקצות אותה לקבוצה באמצעות הקצאת גישה. הקצאות גישה הן סוג של מדיניות שמבוססת על זהות, והן חלות על כל המשאבים שמשתמש מנסה לגשת אליהם – כולל IAP, אבל גם ממשקי API אחרים ו Google Cloud המסוף.
השימוש בהרשאות גישה הוא הדרך הכי טובה לוודא שבקרת גישה מבוססת הקשר נאכפת באופן אחיד בכל המשאבים.
תנאי IAM: אתם יכולים ליצור רמת גישה ולהקצות אותה לקישורים ספציפיים של תפקידי IAM באמצעות תנאי IAM.
שימוש בקשרי תפקידים ב-IAM הוא סוג של מדיניות מבוססת-משאבים, והגישה הזו מתאימה במיוחד אם רוצים להחיל מדיניות שונה על קבוצות שונות של מכונות וירטואליות.
רמות גישה בסיסיות מאפשרות להגביל את הגישה לפי רשת או מיקום גיאוגרפי. אם יש לכם מינוי ל-Chrome Enterprise Premium, אתם יכולים גם להגביל את הגישה על סמך מאפיינים אחרים, כמו חוזק האישורים, ההגדרה של הדפדפן שמשמש לאימות או מצב האבטחה של המכשיר.
גישת SSH שמבוססת על VPC Service Controls
הרעיון מאחורי הגישה הזו הוא לאפשר גישת SSH רק באמצעות העברת TCP של IAP, ולהגדיר את גבולות הגזרה לשירות כך שיאפשר תעבורת נתונים נכנסת של IAP לזהויות מסוימות במקורות שלנו.
אנחנו ממליצים על הגישה הזו למכונות וירטואליות שכלולות בגבולות גזרה של VPC Service Controls.
מתן גישת SSH חיצונית למשתמשים במכונה וירטואלית שמשויכת לגבולות גזרה לשירות עלול להיות מסוכן, כי הוא עשוי לאפשר למשתמשים לערער על גבולות הגזרה של VPC Service Controls על ידי זליגת נתונים דרך SSH.
אם מאפשרים גישת SSH רק דרך העברת TCP ב-IAP, אפשר לצמצם את הסיכון הזה ולוודא שכל גישת SSH כפופה להגדרות של גבולות הגזרה של VPC Service Controls:
- אם משתמש מנסה להתחבר מחוץ לגבולות גזרה לשירות (כפי שמודגם בדוגמה הקודמת), העברת TCP ב-IAP לא רק בודקת אם למשתמש יש גישת IAM ל-VM, אלא גם בודקת אם הבקשה עומדת באחד מכללי הכניסה של גבולות גזרה.
אם משתמש מנסה להתחבר מתוך גבולות גזרה לשירות, העברת TCP ב-IAP בודקת גם אם למשתמש יש גישת IAM למכונה הווירטואלית, אבל מתעלמת מכללי הכניסה של VPC Service Controls.
מערכת IAP מחשיבה חיבור כמקורו בתוך גבולות גזרה לשירות אם מתקיים אחד מהתנאים הבאים:
- כתובת ה-IP של המקור היא כתובת ה-IP החיצונית של מכונה וירטואלית ששייכת לגבולות גזרה לשירות.
- החיבור מתבצע דרך גישה פרטית ל-Google ממכונה וירטואלית ששייכת לגבולות גזרה לשירות.
- החיבור מתבצע דרך נקודת קצה לגישה מסוג Private Service Connect, שהיא חלק מגבולות גזרה לשירות.
גישת SSH פנימית שנשלטת על ידי חומת אש
הרעיון מאחורי הגישה הזו הוא להשבית את כל הגישה החיצונית ולאפשר רק גישת SSH פנימית ל-VPC.
אפשר להשתמש בגישה הזו למכונות וירטואליות שמתקיימים בהן התנאים הבאים:
- לא נדרשת גישה חיצונית למופע של המכונה הווירטואלית.
- המכונה הווירטואלית מחוברת לרשת פנימית קטנה עד בינונית.
- המכונה הווירטואלית לא נכללת בהיקף של VPC Service Controls.
כדי לחסום את כל הגישה החיצונית, אפשר לבצע אחת מהפעולות הבאות:
- פורסים את המכונות הווירטואליות ללא כתובת IP חיצונית.
- מגדירים כללי חומת אש כך שלא תתאפשר תעבורת נתונים נכנסת (ingress) מסוג SSH מטווחים של כתובות IP מחוץ ל-VPC.
השבתת הגישה לקונסולה סדרתית
כדי לפתור בעיות במכונות וירטואליות שלא פועלות, אפשר ב-Compute Engine להתחבר למסוף של היציאה הטורית של מכונה וירטואלית דרך שער SSH, ssh-serialport.googleapis.com. השער הזה נגיש לציבור דרך האינטרנט.
שער ה-SSH ניגש למכונה הווירטואלית דרך ההיפר-ויז'ור הבסיסי במקום דרך רשת ה-VPC. לכן, הגישה למסוף הטורי נשלטת על ידי מדיניות IAM ולא על ידי כללי חומת אש.
אם מאפשרים למשתמשים לגשת למסוף הטורי של VM, יכול להיות שה-VM תהיה חשופה מדי. כדי למנוע חשיפה מוגזמת, אפשר להשתמש בcompute.disableSerialPortAccessאילוץ של מדיניות הארגון להשבתת הגישה למסוף הטורי, ולהסיר את האילוץ באופן זמני כשצריך גישת חירום ליציאה הטורית של המכונה הווירטואלית.
שימוש במכונת VM מסוג Bastion אם נדרש תיעוד של סשנים
ה-IAP TCP-forwarding פועל כמתווך בין מכשירי לקוח ומכונות וירטואליות, ומבצע פונקציות שבדרך כלל מבוצעות על ידי מארחי באסטיון או שרתי מעבר. הפונקציות האלה כוללות:
- אכיפת מדיניות גישה באופן מרכזי
- בדיקת הרשאות גישה
בניגוד למארחי באסטיון מסוימים, העברת TCP ב-IAP לא מסיימת חיבורי SSH: כשיוצרים חיבור SSH למכונה וירטואלית באמצעות העברת TCP ב-IAP, חיבור ה-SSH מוצפן מקצה לקצה בין הלקוח לבין המכונה הווירטואלית. כתוצאה מההצפנה מקצה לקצה, אי אפשר לבדוק את התוכן של סשן ה-SSH באמצעות העברת נתונים ב-TCP של IAP, ואין אפשרות להקליט את הסשן. יומני הביקורת של IAP מכילים מטא-נתונים של חיבור, אבל לא חושפים מידע על תוכן הסשן.
אם אתם צריכים להקליט סשנים, אתם יכולים להשתמש במכונת VM מסוג Bastion:
- מגדירים את מכונת ה-bastion הווירטואלית כך שהיא תסיים חיבורי SSH ותתעד את התוכן שלהם. חשוב להגביל את השימוש בהעברת יציאות SSH, כי היא עלולה לפגוע ביעילות של הקלטת הסשן.
- מגדירים כללים של חומת האש במכונות הווירטואליות של היעד כך שחיבורי SSH יותרו רק מהמכונה הווירטואלית של ה-bastion.
- אישור גישה למכונה וירטואלית מסוג bastion רק דרך העברת TCP ב-IAP
שימוש במדיניות חומת אש להגבלת החשיפה של SSH
אחרי שתקבעו איזו דרך להגבלת החשיפה של SSH מתאימה ביותר לסביבה שלכם, תצטרכו לוודא שכל המכונות הווירטואליות והפרויקטים מוגדרים בהתאם. בפרט, צריך לוודא שבכל הפרויקטים נעשה שימוש באותה קבוצה של כללים של חומת אש, שקובעים איך אפשר להשתמש ב-SSH.
כדי להחיל קבוצה של כללי חומת אש על כמה פרויקטים, משתמשים במדיניות חומת אש היררכית ומחילים אותה על תיקיות בהיררכיית המשאבים.
לדוגמה, כדי לאכוף שכל גישת SSH תתבצע דרך העברת TCP ב-IAP, צריך להחיל מדיניות חומת אש שכוללת את שני הכללים המותאמים אישית הבאים (לפי סדר העדיפות):
- מתן הרשאה לכניסה מ-
35.235.240.0/20ליציאה 22 של מכונות וירטואליות נבחרות. 35.235.240.0/20הוא טווח כתובות ה-IP שמשמש את IAP להעברת TCP. - דחיית תעבורת כניסה מ-
0.0.0.0/0ליציאה 22 של כל המכונות הווירטואליות.