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

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

למה הרשאות עודפות הן בעיה עסקית ולא רק בעיית אבטחה

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

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

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

צמצום הרשאות משתמשים במערכות ארגוניות מתחיל במיפוי

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

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

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

לא כל הרשאה לא פעילה היא מיותרת

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

בונים מודל גישה שאפשר לתחזק

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

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

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

מפרידים בין עבודה שוטפת לניהול מועדף

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

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

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

מחברים את מחזור חיי העובד למחזור חיי ההרשאה

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

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

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

מבצעים ביקורת הרשאות מחזורית

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

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

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

משלבים רישוי בתהליך ולא מטפלים בו בדיעבד

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

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

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