מדי פעם יוצא לי לשוחח עם אנשים שאחראים על סביבות שמצריכות סיווג בטחוני גבוה, ואותם אנשים מחפשים תמיד את השלב הבא בהגנה על התשתית של החברה שלהם. אחד הדברים שהם הכי חוששים מהם זה "פריצה פנימית": איך ניתן למישהו שמנהל תשתיות וירטואליזציה לנהל את כל המערכת, אך לא לאפשר לו "להציץ" דרך כלים שונים – בתוך אותן מכונות VM שרצות, גם כאשר לאותו איש תשתיות יש root למכונה הפיזית (שימו לב: אני לא מדבר על ביצוע ssh לתוך מכונת VM, אלא להריץ סקריפט/כלי ברמת ה-Hypervisor כדי "לחקור" מכונת VM).
הבעיה אמיתית יותר בסביבות חיצוניות: נניח ויש לנו VM שאנחנו רוצים להריץ אותו בענן ציבורי או אצל כל ספק מקומי על תשתית ה-Hypervisor שלו. גם אם נאבטח וננעל את ה-VM עצמו מבפנים, תמיד יהיה חשש שמישהו בעל הרשאות root יוכל להריץ כלים כדי לאבחן את ה-VM מבחינת דברים שהוא מריץ (סריקת זכרון וכו'). ניתן כמובן, לשכור שרת פיזי ולהריץ את ה-VM עליו, אך זה סיפור יותר יקר וגם שם יש בעיות אבטחה אחרות.
אינטל בזמנו פיתחה את ה-SGX, מערכת שמאפשרת לנו ליצור אזור מאובטח שעליו ירוץ קוד בצורה מוצפנת, כך שגם מנהל Hypervisor עם תוכנות זדוניות לא יוכל לסרוק את אותו הזיכרון ולמצוא מה רץ. ה-SGX עצמו כבר נפרץ (אינטל הוציאה תיקון), אבל בכל מקרה הפתרון עצמו היה בעייתי עוד מלכתחילה: האפליקציה המוצפנת הייתה צריכה להיות מאוד קטנה (עד 64 מגהבייט זיכרון), והביצועים (במיוחד ה-Floating Point) היו, איך נאמר בעדינות - לא משהו להתגאות בו. ב-VMWare, לא רצו לגעת בזה, גם עם מקל ארוך.
ואז הגיעה חברת AMD, ובשנת 2017 היא פרסמה על תוספות חדשות שיהיו זמינים במעבדים שלה לשרתים (EPYC) ובמעבדים לצרכים מקצועיים (Ryzen Pro): התוספות הן SEV ו-SME (והתוספת החדשה: SEV-ES – להצפין גם רג'יסטרים במעבד שמשומשים ע"י אותו VM מוצפן). ה-SEV אפשר להצפין את מכונת ה-VM עם מפתח ייחודי שמגיע מתוך מעבד ARM שנמצא במעבד EPYC (כן, מעבד בתוך מעבד) ו-SME שמצפין את הזיכרון של ה-VM.
• אין צורך לעשות שינויים מהותיים ב-VM (רק להחליף Kernel לאחד שתומך ב-SME/SEV)
• ההצפנה היא ברמת חומרה, כך שה"קנס" ברמת ביצועים הוא מאוד מינימלי
• המפתחות הם ייחודיים ולכל VM יש מפתח משלו שמונפק ע"י המעבד. ניתן להנפיק עד 105 מפתחות (כל VM מקבל מפתח אחד, כך שאפשר להריץ עד 105 מכונות VM מוצפנות בשרת עם מעבד EPYC יחיד או 210 בשרת עם שני מעבדי EPYC).
• אי אפשר להצפין מכונות Windows, לפחות עד שמיקרוסופט לא תוסיף את תמיכת ההצפנה ל-OS עצמו.
• VMware בשלב זה אינה תומכת בפונקציות אלו מ-AMD או אינטל (הרחבה בהמשך) – זה יתווסף בגרסה 6.8 או 7.0 ולכן אם אתם צריכים זאת עכשיו, תצטרכו לעבור ל-KVM או על אחת הפלטפורמות שמבוססות על KVM (בכל מקרה יש צורך לבצע את החלפת ה-Kernel).
באינטל ראו את הפתרון של AMD, והחליטו שגם הם יוציאו משהו דומה: תכירו את TME (Total Memory Encryption) ואת MKTME (Multi Key Total Memory Encryption). אפשר לקרוא על הפתרון הזה בקצרה כאן, אך אני אומר מראש: אל תבנו על הפתרון הזה: הוא לא זמין באף מעבד נוכחי.
מכיוון שגם אינטל וגם AMD הולכות באותו כיוון (רק של-AMD יש פתרון שאפשר להשתמש בו כיום), אפשר להניח על הפתרון את הדברים הבאים:
• כן, הפתרון רץ. אך על מנת להשתמש בו, יש צורך בידע טוב בלינוקס. אם צריכים את הפתרון ל"מחר בבוקר" – תצטרכו לבצע שינויים הן ברמת ה-HyperVisor, והן ברמת ה-VM
• הפתרון אינו מבטיח הגנות נגד דברים אחרים כמו Side Memory Attack, DDoS
• הפתרון הוא יחסית צעיר (ב-AMD פיתחו אותו בכלל עבור הגנת הקונסולות של סוני ומיקרוסופט ואז החליטו שזה רעיון מעולה להעביר אותו למעבדים לשרתים), ולפיכך מתגלים בו באגים (ו-AMD משחררת קושחות לתיקון)
• כיום, הפתרון של AMD נמצא בשימוש בשרתים החדשים (דור 10) של HPE שמבוססים על מעבדי EPYC (כלומר DL325 ו-DL385), בשילוב ה-Root of Trust של HPE והחברה (HPE) טוענת שזה הפתרון הכי מאובטח שיש להם להציע לשוק
• זה לא לפרודקשן אם ה-VM שלכם צריך לרוץ בחוץ או ה-Hypervisor שלכם מחובר לאינטרנט (יש לא מעט כאלו)
עוד השוואות בין הפתרונות ניתן לראות במצגת הבאה ובמצגת הזו (החור שמוזכר שם, אגב, בשלבי תיקון).
השיטה ש-AMD מציגה על מנת להגן על מכונות VM נגד האזנה למכונות VM היא שיטה טובה מאוד (ובגלל זה אינטל גם מעתיקים אותה), אך זהו פתרון חדש, וככזה הוא יכול להתאים למאמצים מוקדמים (Early Adopters) עם ידע בלינוקס. אני מאמין שבעוד שנה, הפתרון יתבגר יותר ובמקביל נראה הצעות מספקי ענן ציבורי לשכור Instances שיתמכו ב-SEV/SME, כך שה-Instances שלכם יהיו מוצפנים מספיק טוב בכדי לא לאפשר (באופן עקרוני) לגורמים זרים שיש להם גישה לברזל – לחטט בזיכרון של ה-VM שלכם.
מדי פעם יוצא לי לשוחח עם אנשים שאחראים על סביבות שמצריכות סיווג בטחוני גבוה, ואותם אנשים מחפשים תמיד את השלב הבא בהגנה על התשתית של החברה שלהם. אחד הדברים שהם הכי חוששים מהם זה "פריצה פנימית": איך ניתן למישהו שמנהל תשתיות וירטואליזציה לנהל את כל המערכת, אך לא לאפשר לו "להציץ" דרך כלים שונים – בתוך אותן מכונות VM שרצות, גם כאשר לאותו איש תשתיות יש root למכונה הפיזית (שימו לב: אני לא מדבר על ביצוע ssh לתוך מכונת VM, אלא להריץ סקריפט/כלי ברמת ה-Hypervisor כדי "לחקור" מכונת VM).
הבעיה אמיתית יותר בסביבות חיצוניות: נניח ויש לנו VM שאנחנו רוצים להריץ אותו בענן ציבורי או אצל כל ספק מקומי על תשתית ה-Hypervisor שלו. גם אם נאבטח וננעל את ה-VM עצמו מבפנים, תמיד יהיה חשש שמישהו בעל הרשאות root יוכל להריץ כלים כדי לאבחן את ה-VM מבחינת דברים שהוא מריץ (סריקת זכרון וכו'). ניתן כמובן, לשכור שרת פיזי ולהריץ את ה-VM עליו, אך זה סיפור יותר יקר וגם שם יש בעיות אבטחה אחרות.
אינטל בזמנו פיתחה את ה-SGX, מערכת שמאפשרת לנו ליצור אזור מאובטח שעליו ירוץ קוד בצורה מוצפנת, כך שגם מנהל Hypervisor עם תוכנות זדוניות לא יוכל לסרוק את אותו הזיכרון ולמצוא מה רץ. ה-SGX עצמו כבר נפרץ (אינטל הוציאה תיקון), אבל בכל מקרה הפתרון עצמו היה בעייתי עוד מלכתחילה: האפליקציה המוצפנת הייתה צריכה להיות מאוד קטנה (עד 64 מגהבייט זיכרון), והביצועים (במיוחד ה-Floating Point) היו, איך נאמר בעדינות - לא משהו להתגאות בו. ב-VMWare, לא רצו לגעת בזה, גם עם מקל ארוך.
ואז הגיעה חברת AMD, ובשנת 2017 היא פרסמה על תוספות חדשות שיהיו זמינים במעבדים שלה לשרתים (EPYC) ובמעבדים לצרכים מקצועיים (Ryzen Pro): התוספות הן SEV ו-SME (והתוספת החדשה: SEV-ES – להצפין גם רג'יסטרים במעבד שמשומשים ע"י אותו VM מוצפן). ה-SEV אפשר להצפין את מכונת ה-VM עם מפתח ייחודי שמגיע מתוך מעבד ARM שנמצא במעבד EPYC (כן, מעבד בתוך מעבד) ו-SME שמצפין את הזיכרון של ה-VM.
• אין צורך לעשות שינויים מהותיים ב-VM (רק להחליף Kernel לאחד שתומך ב-SME/SEV)
• ההצפנה היא ברמת חומרה, כך שה"קנס" ברמת ביצועים הוא מאוד מינימלי
• המפתחות הם ייחודיים ולכל VM יש מפתח משלו שמונפק ע"י המעבד. ניתן להנפיק עד 105 מפתחות (כל VM מקבל מפתח אחד, כך שאפשר להריץ עד 105 מכונות VM מוצפנות בשרת עם מעבד EPYC יחיד או 210 בשרת עם שני מעבדי EPYC).
• אי אפשר להצפין מכונות Windows, לפחות עד שמיקרוסופט לא תוסיף את תמיכת ההצפנה ל-OS עצמו.
• VMware בשלב זה אינה תומכת בפונקציות אלו מ-AMD או אינטל (הרחבה בהמשך) – זה יתווסף בגרסה 6.8 או 7.0 ולכן אם אתם צריכים זאת עכשיו, תצטרכו לעבור ל-KVM או על אחת הפלטפורמות שמבוססות על KVM (בכל מקרה יש צורך לבצע את החלפת ה-Kernel).
באינטל ראו את הפתרון של AMD, והחליטו שגם הם יוציאו משהו דומה: תכירו את TME (Total Memory Encryption) ואת MKTME (Multi Key Total Memory Encryption). אפשר לקרוא על הפתרון הזה בקצרה כאן, אך אני אומר מראש: אל תבנו על הפתרון הזה: הוא לא זמין באף מעבד נוכחי.
מכיוון שגם אינטל וגם AMD הולכות באותו כיוון (רק של-AMD יש פתרון שאפשר להשתמש בו כיום), אפשר להניח על הפתרון את הדברים הבאים:
• כן, הפתרון רץ. אך על מנת להשתמש בו, יש צורך בידע טוב בלינוקס. אם צריכים את הפתרון ל"מחר בבוקר" – תצטרכו לבצע שינויים הן ברמת ה-HyperVisor, והן ברמת ה-VM
• הפתרון אינו מבטיח הגנות נגד דברים אחרים כמו Side Memory Attack, DDoS
• הפתרון הוא יחסית צעיר (ב-AMD פיתחו אותו בכלל עבור הגנת הקונסולות של סוני ומיקרוסופט ואז החליטו שזה רעיון מעולה להעביר אותו למעבדים לשרתים), ולפיכך מתגלים בו באגים (ו-AMD משחררת קושחות לתיקון)
• כיום, הפתרון של AMD נמצא בשימוש בשרתים החדשים (דור 10) של HPE שמבוססים על מעבדי EPYC (כלומר DL325 ו-DL385), בשילוב ה-Root of Trust של HPE והחברה (HPE) טוענת שזה הפתרון הכי מאובטח שיש להם להציע לשוק
• זה לא לפרודקשן אם ה-VM שלכם צריך לרוץ בחוץ או ה-Hypervisor שלכם מחובר לאינטרנט (יש לא מעט כאלו)
עוד השוואות בין הפתרונות ניתן לראות במצגת הבאה ובמצגת הזו (החור שמוזכר שם, אגב, בשלבי תיקון).
השיטה ש-AMD מציגה על מנת להגן על מכונות VM נגד האזנה למכונות VM היא שיטה טובה מאוד (ובגלל זה אינטל גם מעתיקים אותה), אך זהו פתרון חדש, וככזה הוא יכול להתאים למאמצים מוקדמים (Early Adopters) עם ידע בלינוקס. אני מאמין שבעוד שנה, הפתרון יתבגר יותר ובמקביל נראה הצעות מספקי ענן ציבורי לשכור Instances שיתמכו ב-SEV/SME, כך שה-Instances שלכם יהיו מוצפנים מספיק טוב בכדי לא לאפשר (באופן עקרוני) לגורמים זרים שיש להם גישה לברזל – לחטט בזיכרון של ה-VM שלכם.
הודעתך לא התקבלה - נסה שוב מאוחר יותר
Oops! Something went wrong while submitting the form