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

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

VPN נותן נתיב לרשת, Splashtop נותן שליטה על עמדה

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

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

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

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

אבטחה: השאלה היא כמה גישה באמת צריך לתת

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

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

כדי להפעיל גישה מרחוק בצורה אחראית, כדאי להגדיר MFA לכל משתמש בעל הרשאות גישה, לעבוד עם קבוצות ולא עם הרשאות ידניות למשתמשים בודדים, ולבחון אפשרויות SSO בהתאם לרישוי ולארכיטקטורה הקיימים. חשוב גם להפריד בין גישת משתמש לעמדתו האישית לבין גישת אנשי IT לעמדות רבות. אלו שני תרחישים שונים, ולכן לא נכון לנהל אותם תחת אותה קבוצת הרשאות.

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

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

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

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

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

מתי VPN עדיין הוא הבחירה הנכונה

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

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

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

מתי Splashtop מפחית מורכבות ועלות תפעולית

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

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

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

Splashtop מול VPN לגישה ארגונית: מסגרת החלטה מעשית

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

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

הטמעה נכונה מתחילה בפיילוט קטן

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

בשלב הזה כדאי לערב יחד את ה-IT, אבטחת המידע והרכש. IT בודק תפעול, אבטחה בודקת חשיפה ותאימות, ורכש מוודא שמודל הרישוי ניתן לניהול לאורך זמן. ShalevSoft יכולה לסייע בהתאמת רישוי Splashtop לתרחישי השימוש בפועל ובתמיכה טכנית בעברית, כדי שהפיילוט לא יישאר עוד כלי מבודד בארגון.

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