כמעט כל ארגון יודע שמשתמשים לא אמורים להיות אדמינים מקומיים על התחנה. משתמש עם הרשאות אדמין יכול להתקין כל תוכנה, לכבות הגנות ולהריץ קוד זדוני עם הרשאות מלאות. תוקף שמשתלט על החשבון שלו מקבל את אותן הרשאות.
ובכל זאת, הרבה ארגונים משאירים את ההרשאות האלה. הסיבה היא לרוב לא חוסר מודעות, אלא חשש מהפתרון: ניהול הרשאות אדמין, או EPM (Endpoint Privilege Management), נחשב לפרויקט מסובך, יקר לתחזוקה, מעצבן למשתמשים ולא מתאים למפתחים.
ארבעת החששות האלה היו נכונים לגבי חלק מהפתרונות. הם כבר לא חייבים להיות נכונים.
מיתוס 1: היישום מורכב וארוך
החשש מוכר: פרויקט של חודשים, שרתים ייעודיים, מסדי נתונים, ויועצים שבונים מדיניות לכל אפליקציה בארגון לפני שאפשר להתחיל.
בפתרון מבוסס ענן התמונה אחרת. אין שרתים להקים ואין תשתית לתחזק. מתקינים סוכן קטן על התחנות, דרך Intune או כל כלי הפצה אחר, ומנהלים הכל מפורטל בענן.
גם את המדיניות לא צריך לבנות מראש. אפשר להתחיל במצב תיעוד בלבד, כשלמשתמשים עדיין יש הרשאות אדמין, וכל פעולה שדורשת הרשאות נרשמת. אחרי כמה שבועות רואים בדיוק אילו תוכנות המשתמשים באמת צריכים, ובונים את המדיניות לפי נתונים אמיתיים ולא לפי ניחושים. לפי Admin By Request, היישום אצלם קצר בכ-70% מיישום של מערכות אחרות.
מיתוס 2: התחזוקה דורשת חצי משרה ויותר
בחלק מהפתרונות הוותיקים, ניהול המערכת הוא עבודה במשרה חלקית ואפילו מלאה: עדכון כללים לכל גרסה חדשה של תוכנה, טיפול בבקשות ותחזוקת שרתים.
המפתח לתחזוקה נמוכה הוא אוטומציה של ההחלטות השגרתיות:
- אישור מראש לתוכנות מוכרות. תוכנות שהארגון סומך עליהן, לפי יצרן או תעודה דיגיטלית, רצות בלי בקשה. אין צורך לעדכן כלל בכל גרסה חדשה.
- אישור אוטומטי מבוסס AI. Admin By Request מדרג יצרנים ואפליקציות ויכול לאשר אוטומטית בקשות לתוכנות מוכרות ומהימנות.
- אישור מהנייד. בקשה שכן צריכה אישור מגיעה לאפליקציה בטלפון, ומאשרים אותה בלחיצה.
- אין תשתית לתחזק. הפורטל בענן והסוכן מתעדכן אוטומטית.
בפועל, אחרי תקופת ההתאמה הראשונה, רוב הבקשות מטופלות אוטומטית, וצוות ה-IT מטפל רק בחריגים.
מיתוס 3: המשתמשים לא יוכלו לעבוד
זה החשש הגדול ביותר, ובצדק. אם כל התקנה של מדפסת או עדכון של תוכנה דורשים פנייה למחלקת IT והמתנה של שעות, המשתמשים יתלוננו וההנהלה תבקש להחזיר את ההרשאות.
אבל פתרון EPM טוב משפר את חוויית המשתמש לעומת המצב הקיים. בלי EPM, משתמש בלי הרשאות אדמין צריך לפתוח קריאה ולחכות שטכנאי יתחבר מרחוק. עם EPM, תוכנה מאושרת רצה בלי להמתין לאישור, ובקשה לתוכנה אחרת נשלחת מהתחנה עצמה ומאושרת בדקות, לעיתים אוטומטית.
המשתמש לא צריך לדעת סיסמה של אדמין, לא צריך לחכות לטכנאי, ובדרך כלל גם לא מרגיש שמשהו השתנה.
מיתוס 4: אי אפשר להסיר הרשאות אדמין למפתחים
מפתחים הם הקבוצה שהכי קשה לשכנע, ולכן הרבה ארגונים מוותרים עליה מראש ומשאירים להם הרשאות אדמין קבועות. הטיעון מוכר: מפתחים מתקינים כלים כל הזמן, עובדים עם Docker, WSL, npm ו-PowerShell, ומשנים הגדרות מערכת. כל בקשת אישור תעצור אותם.
אבל דווקא בגלל זה המפתחים הם הקבוצה שהכי חשוב להגן עליה. יש להם גישה לקוד, לסביבות הפיתוח, למפתחות ולשרתים. תוקף שמשתלט על תחנה של מפתח עם הרשאות אדמין מקבל הרבה יותר מתחנה רגילה.
הפתרון הוא לא לוותר על הקבוצה, אלא לבנות לה מדיניות נפרדת:
- מדיניות ייעודית לקבוצת המפתחים. אותה ברירת מחדל גלובלית, עם שכבת חריגים שמתאימה לעבודת פיתוח.
- אישור מראש לכלי הפיתוח לפי יצרן. Visual Studio, JetBrains, Docker, Git וכלים דומים רצים עם הרשאות בלי בקשה, גם אחרי עדכון גרסה.
- Admin Session למשימות מורכבות. כשמפתח צריך כמה פעולות ברצף, למשל התקנה של סביבה חדשה, הוא מקבל הרשאות אדמין זמניות ומתועדות במקום הרשאות קבועות.
- סריקה של כל קובץ. גם כשמפתח מקבל יותר חופש, כל קובץ שרץ עם הרשאות נסרק בעשרות מנועים.
זה עובד בפועל: כל לקוחות Admin By Request EPM שלנו בישראל הסירו הרשאות אדמין מהמשתמשים בתחנות הקצה. וזה בדיוק המדד שבו נבחנת איכות של פתרון EPM: לא כמה תחנות הסוכן מותקן עליהן, אלא אצל כמה משתמשים ההרשאות באמת הוסרו.
הגישה של Admin By Request
Admin By Request נבנה מההתחלה סביב הבעיות האלה: יישום מהיר, תחזוקה מינימלית וחוויית משתמש שלא נפגעת. לפי החברה, יותר ממחצית הלקוחות שלה עברו אליה מפתרונות EPM אחרים.
הארכיטקטורה פשוטה:
- סוכן קטן במיוחד. קובץ ההתקנה קטן מ-3MB, והסוכן צורך בממוצע פחות מ-1% מהמעבד. ההפצה מהירה גם ברשתות איטיות.
- פורטל ניהול בענן. אין שרתים, אין מסדי נתונים ואין תשתית מקומית.
- תמיכה ב-Windows, ב-macOS וב-Linux מאותו פורטל.
- בלי סיסמאות. המערכת לא שומרת ולא מנהלת סיסמאות של משתמשים, כך שאין כספת סיסמאות שאפשר לפרוץ אליה.
שני מצבי הרשאה
| Run As Admin | Admin Session | |
|---|---|---|
| מה הוא נותן | הרשאות אדמין לתוכנה אחת בלבד | הרשאות אדמין זמניות על כל התחנה |
| דוגמאות | התקנת תוכנה, הרצת תוכנה שדורשת הרשאות, כלי מערכת הפעלה | פתרון תקלה שדורש כמה פעולות ברצף |
| למי מתאים | כל המשתמשים | בעיקר אנשי תמיכה ו-IT |
| טווח הסיכון | מצומצם: רק התוכנה שהורצה | רחב יותר, ולכן מוגבל בזמן ומתועד |
Run As Admin הוא המצב שרוב המשתמשים צריכים. ההרשאות ניתנות רק לתוכנה שהמשתמש ביקש להריץ, ולא לשום דבר אחר בתחנה.
Admin Session נותן למשתמש הרשאות אדמין מלאות על התחנה לזמן מוגבל, עם טיימר שמסתיים אוטומטית. בדרך כלל לא נותנים את המצב הזה למשתמשים רגילים, אלא רק לאנשי תמיכה. כל פעולה בזמן הסשן מתועדת.
אבטחה ותאימות מובנות
- סריקה בעשרות מנועים, בלי עלות נוספת. כל קובץ שמשתמש מבקש להריץ עם הרשאות אדמין נסרק עם OPSWAT MetaDefender בעשרות מנועי אנטי-וירוס. קובץ זדוני לא ירוץ, גם אם המשתמש ביקש אישור. הסריקה כלולה בפתרון.
- אינטגרציה עם Intune. אפשר לקשר את ההרשאות למצב התאימות של התחנה ב-Intune.
- MFA לפני הרשאות. אפשר לדרוש אימות עם Entra ID לפני שמשתמש מקבל הרשאות אדמין.
- תמיכה בכל תצורות Windows. המערכת עובדת בתחנות ב-Workgroup, בדומיין מקומי, בתחנות היברידיות (Hybrid Joined) ובתחנות שמחוברות ל-Entra ID בלבד. זה חשוב במיוחד לארגונים באמצע מעבר לענן.
לסיכום
ארבעת המיתוסים על EPM נולדו מפתרונות כבדים שדרשו תשתית, צוות ייעודי והרבה סבלנות מהמשתמשים. עם סוכן קטן, פורטל בענן ואוטומציה של ההחלטות השגרתיות, אפשר להסיר הרשאות אדמין מקומיות בלי פרויקט ארוך, בלי משרה נוספת ובלי לפגוע בעבודה.
ב-OnCloud אנחנו מטמיעים את Admin By Request מקצה לקצה: הפצת הסוכן, תקופת התיעוד, בניית המדיניות והסרת ההרשאות. רוצים לבדוק את זה בארגון שלכם?
תיאום פגישה לדמו טכני