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

בארגון בינוני או אנטרפרייז, משתמש אחד יכול להחזיק זהות ב-Active Directory או Entra ID, חשבון דוא"ל, גישה ל-VPN, מערכות ERP ו-CRM, כלי פיתוח, אחסון ענן, מערכות תמיכה מרחוק וכלי אבטחה. בלי מדיניות אחידה, כל מערכת הופכת למאגר הרשאות נפרד. התוצאה מוכרת: עובדים עם יותר הרשאות ממה שהם צריכים, חשבונות כפולים, רישיונות שלא בשימוש, ותחקיר אירוע אבטחה שמתחיל בשאלה בסיסית מדי - מי בכלל היה אמור לקבל גישה?

מהו ניהול זהויות ארגוני ולמה הוא משפיע גם על עלויות

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

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

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

שלב ראשון: למפות זהויות, מערכות והרשאות בפועל

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

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

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

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

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

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

שלב שני: לבנות מחזור חיים מסודר לזהות

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

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

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

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

שלב שלישי: SSO ו-MFA לפי רמת הסיכון

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

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

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

הרשאות מינימליות וחשבונות אדמין נפרדים

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

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

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

בקרה, תאימות ורישוי: להפוך נתונים להחלטות

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

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

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

מדדים שכדאי להציג להנהלה

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

איך מתחילים בלי להפוך את הפרויקט למבצע אינסופי

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

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

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