הסרת הרשאות אדמין מקומיות היא אחד הצעדים האפקטיביים ביותר להקשחת תחנות קצה. המפתח להצלחה הוא לא הטכנולוגיה, אלא הסדר: קודם לומדים מה המשתמשים צריכים, ורק אחר כך מסירים הרשאות.
במדריך הזה נעבור על התהליך שאנחנו מיישמים ב-OnCloud עם Admin By Request:
- פיילוט על עד 25 תחנות, עם התוכנית החינמית.
- פריסה מלאה במצב למידה ובניית אישורים מראש.
- הסרת הרשאות מדורגת וטיפול בתקלות הנפוצות.
- העברת מוקד התמיכה לעבודה בלי הרשאות אדמין קבועות.
שלב 1: פיילוט
לפני שמתחייבים, כדאי לבדוק את הפתרון על קבוצה קטנה. ל-Admin By Request יש תוכנית חינמית (Free Plan) שמוגבלת ל-25 תחנות, אבל כוללת את כל היכולות של המערכת ולא מוגבלת בזמן. זו הדרך הנוחה לעשות פיילוט אמיתי, על הטננט של הארגון ובתנאי עבודה אמיתיים.
חיבור למערכת הזהויות. הצעד הראשון בטננט החדש הוא לחבר אותו לספק הזהויות של הארגון, בדרך כלל Entra ID או Okta. החיבור מאפשר אימות דו-שלבי לכניסה לפורטל, ובניית מדיניות לפי קבוצות משתמשים. אנחנו ממליצים לבנות את המדיניות לפי קבוצות משתמשים.
הפעלה במצב למידה. מתקינים את הסוכן על תחנות הפיילוט, אבל לא מסירים עדיין את הרשאות האדמין. המערכת מתעדת כל פעולה שהמשתמשים מריצים עם הרשאות אדמין. התיעוד הזה הוא הבסיס לאישורים מראש: התוכנות, כלי מערכת ההפעלה והפעולות שהמשתמשים צריכים, כך שלא יצטרכו להגיש בקשה בשבילם.
ערוץ האישורים. בשלב הזה גם מגדירים איך בקשות יגיעו לאישור: הודעה ב-Slack או ב-Teams, אפליקציית המובייל של Admin By Request, או חיבור למערכת ניהול הקריאות של הארגון.
מה לבדוק בפיילוט. כדאי להתמקד באפליקציות הייחודיות של הארגון, כמו תוכנות ייעודיות לתחום הפעילות או מערכות ישנות. אפליקציות נפוצות, כמו דפדפנים או תוכנות אופיס, כמעט אף פעם לא דורשות בדיקה.
שלב 2: פריסה מלאה ואישורים מראש
אחרי שהפיילוט הסתיים והרישיונות נרכשו, פורסים את הסוכן על כל התחנות בארגון, שוב במצב למידה. נותנים למערכת לאסוף נתונים במשך שבוע עד שבועיים, ובונים את האישורים מראש לפני שמסירים הרשאות למישהו.
זה השלב החשוב ביותר בפרויקט. ככל שהאישורים מראש מדויקים יותר, כך פחות משתמשים ירגישו בשינוי. אלה הדרכים לאשר אפליקציה מראש:
| שיטה | מה היא מאשרת | מתי להשתמש |
|---|---|---|
| תעודה דיגיטלית | כל האפליקציות של אותו יצרן | יצרן שהארגון סומך עליו לגמרי |
| תעודה דיגיטלית ושם אפליקציה | אפליקציה ספציפית של יצרן | רוב המקרים: מדויק, ולא נשבר בעדכון גרסה |
| Checksum | קובץ מסוים בגרסה מסוימת | תוכנה בלי חתימה דיגיטלית |
| מיקום | קובץ בתיקייה מסוימת, בשרת קבצים או על המחשב | כלים פנימיים של הארגון |
בנוסף, אפשר להגדיר שאפליקציות מסוימות ירוצו תמיד עם הרשאות אדמין, בלי שהמשתמש יצטרך לבקש.
Tray Tools ב-Windows. כלים של מערכת ההפעלה, כמו הוספת מדפסת, Control Panel או הגדרות כרטיס רשת, ממקמים ב-Tray Tools. משם המשתמש מריץ אותם עם הרשאות אדמין, בלי בקשה ובלי לפנות לתמיכה.
שלב 3: הסרת הרשאות מדורגת
את ההרשאות מסירים בהדרגה, קבוצה אחרי קבוצה, ולא בכל הארגון בבת אחת. המערכת תומכת בזה, ואם קבוצה מסוימת נתקלת בבעיה, אפשר להחזיר לה את ההרשאות בקלות.
שתי תקלות שנתקלים בהן כמעט בכל פריסה:
- אפליקציה שלא מבקשת הרשאות אדמין כמו שצריך. יש אפליקציות שלא עובדות בצורה נקייה עם ה-UAC של Windows, ולכן לא מבקשות הרשאות כשהן צריכות אותן. הפתרון פשוט: לחיצה ימנית ו-Run as administrator. צריך רק להדריך את המשתמשים, או להגדיר את האפליקציה כך שתרוץ תמיד עם הרשאות אדמין.
- כלי מערכת הפעלה שמקפיץ מסך UAC. משתמש שמנסה לפתוח כלי של Windows ונתקל במסך UAC שמבקש סיסמת אדמין, מחפש את הכלי במקום הלא נכון. המקום הנכון להריץ ממנו כלים כאלה הוא Tray Tools, שמריץ אותם עם הרשאות אדמין.
שלב 4: מוקד התמיכה בלי הרשאות קבועות
אחרי שהסרנו את הרשאות האדמין מכל המשתמשים, נשאר עוד פער אחד: אנשי התמיכה. ברוב הארגונים לחשבונות שלהם יש הרשאות אדמין קבועות על כל התחנות. חשבון כזה הוא יעד מועדף לתוקפים.
הפיצ'ר Support Assist פותר את זה. אנשי התמיכה כבר לא צריכים הרשאות אדמין קבועות. כשאיש תמיכה מתחבר לתחנה, הוא נכנס למצב תמיכה, והתחנה עוברת זמנית מהמדיניות של המשתמש למדיניות של התומך, שמאפשרת לו להריץ כל מה שהוא צריך. כשהוא מסיים, התחנה חוזרת למדיניות הרגילה.
אגב, בגלל זה הרבה ארגונים פורסים את המערכת גם בתחנות שבהן למשתמשים כבר אין הרשאות אדמין: כדי לייעל את העבודה של התמיכה, וכדי לאפשר למשתמשים להריץ מדי פעם דברים שהם צריכים בלי לפתוח קריאת שירות.
הגדרות אבטחה למערכת עצמה
מערכת שמחליטה מי מקבל הרשאות אדמין צריכה להיות מוגנת בעצמה. אלה ההגדרות שאנחנו ממליצים עליהן:
- חיבור למערכת ניטור האבטחה (SIEM) של הארגון. כל בקשה, אישור וסשן של הרשאות אדמין נשלחים למערכת הניטור, וצוות האבטחה רואה אותם לצד שאר האירועים בארגון.
- הפרדת הרשאות בפורטל. מגדירים שני סוגי משתמשי ניהול: מנהלי מערכת עם הרשאות מלאות להגדרות ולמדיניות, ואנשי מוקד תמיכה שיכולים רק לאשר בקשות.
- גישת חירום (Break Glass). אנשי התמיכה יכולים לייצר חשבון אדמין מקומי זמני לתחנה, למקרה שהיא לא מחוברת לרשת ולא יכולה לתקשר עם הפורטל.
לסיכום
פריסה מוצלחת של EPM נשענת על סדר נכון: פיילוט על האפליקציות הייחודיות, תקופת למידה, אישורים מראש מדויקים, הסרת הרשאות בהדרגה, ולבסוף העברת מוקד התמיכה לעבודה בלי הרשאות קבועות. כשעובדים ככה, רוב המשתמשים בכלל לא מרגישים שמשהו השתנה.
ב-OnCloud אנחנו מלווים את כל השלבים, מהפיילוט ועד העברת מוקד התמיכה. רוצים להתחיל בפיילוט?
תיאום פגישה לדמו טכני