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

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

למה ניהול זהויות הופך לצוואר בקבוק

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

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

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

כלים לאבטחת זהויות בענן: שכבות העבודה הנכונות

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

ספק זהויות מרכזי ואימות רב-שלבי

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

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

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

ניהול סיסמאות ארגוני

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

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

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

גישה מורשית לחשבונות רגישים

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

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

גילוי נכסים וחיבור לתפעול השוטף

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

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

איך בוחרים פתרון בלי לקנות יותר מדי

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

אחר כך בדקו את ארבע השאלות שמכריעות את הבחירה:

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

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

תהליך הטמעה שלא משתק את הארגון

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

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

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

רישוי, תמיכה מקומית ושליטה בעלויות

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

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

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

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