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

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

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

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

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

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

הזהות לפני הרשת

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

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

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

הרשאות מינימליות וזמניות

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

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

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

אל תחשפו שירותי ניהול לאינטרנט

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

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

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

שליטה בסשן, בקבצים ובנתונים

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

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

ניטור שמאפשר תגובה, לא רק סימון וי

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

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

רישוי נכון הוא חלק ממודל האבטחה

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

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

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

בדיקה תקופתית היא חלק מההגדרה

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

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

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