הדברים המסוכנים בבחירת פתרונות VDI מסוימים

Print Friendly, PDF & Email

תחום ה-VDI נדחף חזק מאוד ע"י חברות רבות מאוד, החל מיצרני שרתים, יצרני GPU, חברות כמו מיקרוסופט, VMWare, Red Hat, Citrix וחברות רבות נוספות. הסיבה לכך היא שמדובר בסכומים מאוד רציניים שחברות ישלמו פר העברת מחשבי משתמשים ל-VDI, ולכן חברות רבות שמחות להציע את מרוכלתן בתחום ה-VDI, והאמת היא שחלק מהפתרונות מסוכנים מבחינת אבטחת מידע.

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

2 הצעות VDI הן מסוכנות חלקית להטמעה: של מיקרוסופט ושל Citrix. ב-2 המקרים ישנה אפשרות שלא מעט מעדיפים – שכל משתמש יקבל בעצם סשן דסקטופ "טבעי" ולא VM. היתרון הגדול בכך שניתן לחסוך במשאבי מחשוב, צריך פחות שרתים, אך מכיוון ש-2 ההצעות מבוססות על ה-Windows עצמו – הסיכון העצום הוא בנתינת סשן שהוא מעין "דסקטופ" מלא – כלומר המשתמש מקבל סשן עם הכל – דפדפן, אופיס, אאוטלוק, ואפליקציות נוספות, רק שזה לא רץ במכונה וירטואלית נפרדת.

מה הסיכון? הסיכון כרוך בבעיה מושרשת שקיימת ב-RDS ובפתרון הדומה שיש ל-Citrix וב-RDSH של VMware: ל-Windows יש יכולת גרועה לנטר ולהגביל תהליכים (Process). אם Process כלשהו יפעיל את עצמו 100 פעם, למכונת ה-Windows לא תהיה שום בעיה עם זה. אם ה-Process בולע זכרון כאילו אין מחר – גם עם זה ל-Windows אין בעיה. תוסיפו לזה את העובדה שמעתה יש עשרות סשנים כאלו פתוחים ע"י משתמשים שלא ממש מבינים במחשבים, ומספיק שאחד מהם הוריד משהו מסוכן שמתחיל לעשות Spawn ל-Process שהוא מקים ו"לשתות" זכרון, ותוך כמה דקות כולם סובלים. אם לעומת זאת הסשן דסקטופ היה מגיע ממכונה וירטואלית מיועדת, אז רק אותו משתמש היה סובל (טוב, למעט אם מדובר בנוזקה שיודעת להשתמש ברשת וחולשות אבטחה של Windows שלא עודכנו באותה חברה). זה די עצוב שבשנת 2018 לפתרונות שמבוססים על סשנים ולא על VM אין מספיק מגבלות על הדברים הללו. אפילו קונטיינרים מכילים את ההגנות הנ"ל.

סשנים כמו RDS ופתרונות דומים של אחרים הם מעולים לדבר אחד: Published Application, כלומר כשהמשתמש לוחץ על אייקון מסויים, נפתח לו סשן שמראה רק את האפליקציה, בלי Start ובלי שום דבר אחר. זהו פתרון שגם נוח מאוד למשתמשים שלא רואים דברים מיותרים ורגילים כבר לאותה אפליקציה.

לכן, ההמלצה שלי כשמקימים VDI, ולא משנה על איזו טכנולוגיה היא עובדת, היא VM פר משתמש, כלומר אם יש לנו 50 משתמשים, יהיה לנו Pool של מינימום 50 מכונות וירטואליות שינוהלו ע"י אותו פתרון שנבחר, עם Portal וכו' פר משתמש ואם צריך – גם Published App/Xen App או ThinApp וכו' של אפליקציות שמוצגות עצמאית.

פוסטים קודמים שכתבתי בנושא:

2 תגובות בנושא “הדברים המסוכנים בבחירת פתרונות VDI מסוימים”

  1. אתה בטוח שאין פתרון המגביל צריכת cpu/ram פר סשן בחלונות?

    גיגול קצר מרמז ש Windows System Resource Manager מאפשר זאת.

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

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

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