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

הבעיה אינה פתיחת משתמשים, אלא מחזור החיים שלהם

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

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

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

מה אוטומציית הקצאת הרשאות עובדים חייבת לעשות

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

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

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

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

כך בונים תהליך שלא נשבר אחרי חודש

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

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

מומלץ ליישם את האוטומציה בשלבים:

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

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

קבוצות הן מנגנון בקרה, לא רק כלי נוחות

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

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

החיבור ל-FinOps: לא כל רישיון צריך להישאר פעיל

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

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

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

מדדי הצלחה שלא מסתמכים על תחושת בטן

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

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

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

איפה ארגונים נתקעים

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

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

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