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