עובדת מחלקת הכספים עברה לפני שנתיים לתפקיד חדש ב-IT. את ההרשאות החדשות היא קיבלה ביום הראשון, אבל את ההרשאות הישנות למערכת הכספים אף אחד לא טרח לבטל. במשך שנתיים זה לא הפריע לאיש, עד שהחשבון שלה נפרץ, והתוקף גילה שיש לו גישה גם ל-ERP הפיננסי של הארגון.
לפי נתונים שפורסמו ב-Security Magazine, רק 34% מהארגונים מבטלים גישה למערכות ביום העזיבה של עובד, ובכמחצית מהארגונים התהליך נמשך ימים. הפער הזה, בין ההרשאות שמשתמש באמת צריך לבין מה שיש לו בפועל, הוא הבעיה שניהול מחזור חיים של זהויות נועד לפתור.
מה זה Identity Lifecycle Management?
ניהול מחזור החיים של זהויות (Identity Lifecycle Management) הוא תהליך אוטומטי ומבוסס מדיניות לניהול זהויות דיגיטליות והרשאות הגישה שלהן, מהרגע שבו משתמש, עובד או מערכת מצטרפים לארגון ועד לרגע שבו אין בהם עוד צורך.
בתעשייה נהוג לתאר את התהליך גם במונח JML: מצטרף (Joiner), עובר תפקיד (Mover) ועוזב (Leaver). אלו שלוש נקודות הזמן שבהן הרשאות צריכות להשתנות, ובניסיון שלי אלו גם הנקודות שבהן רוב הארגונים מפספסים.
המטרה היא לוודא שלכל זהות, אנושית או דיגיטלית, יהיו בדיוק ההרשאות שהיא זקוקה להן, ורק כל עוד היא זקוקה להן. זה נשמע מובן מאליו, אבל ברוב הארגונים שאני פוגש המציאות רחוקה מזה.
למה זה חשוב?
הרשאות גישה אינן נשארות קבועות. עובדים מחליפים תפקידים, ספקים מקבלים גישה זמנית, אפליקציות מתקשרות באמצעות מפתחות API וחשבונות שירות. כשכל זה מנוהל ידנית, בטבלת אקסל או בזיכרון של מנהל המערכת, נוצרים פערים. הסיכונים המרכזיים:
הצטברות הרשאות (Privilege Creep): עובדים ממשיכים להחזיק בהרשאות מתפקידים ומפרויקטים קודמים, וההרשאות רק מצטברות עם השנים.
חשבונות יתומים: חשבונות שנשארו פתוחים בלי בעלים ובלי צורך עסקי. אף אחד לא משתמש בהם, אבל גם אף אחד לא מנטר אותם, ולכן הם יעד נוח לתוקפים.
איומים פנימיים: עובדים או עובדים לשעבר שמנצלים הרשאות שמעולם לא היו צריכות להישאר בידיהם.
פערי תאימות ורגולציה: בביקורת, הארגון מתקשה להוכיח מי קיבל גישה, מי אישר אותה, מתי נבדקה ומתי בוטלה.
ניהול נכון של מחזור החיים מאפשר ליישם את עקרון ההרשאות המינימליות (Least Privilege) ולצמצם משמעותית את משטח התקיפה של הארגון.
ארבעת השלבים במחזור החיים של זהות
שלב 1: יצירת הזהות והקצאת הרשאות (Provisioning)
התהליך מתחיל כשעובד, משתמש או מערכת מצטרפים לארגון. נוצרים חשבונות ומוקצות הרשאות בהתאם לתפקיד, למחלקה ולתחומי האחריות.
אותו עיקרון חל על זהויות שאינן אנושיות: חשבונות שירות, אפליקציות ומפתחות API. לכל זהות כזו צריך להיות בעלים מוגדר, צורך עסקי ברור והרשאות מינימליות המתאימות למטרתה. בפועל, זהויות מכונה נוצרות פעמים רבות עם הרשאות רחבות מהנדרש, וכמעט אף פעם לא חוזרים אליהן.
שלב 2: התאמת הרשאות לאורך הדרך (Access Management)
הצרכים משתנים. עובדים עוברים בין מחלקות, מקבלים קידום, מצטרפים לפרויקטים. מערכת ILM טובה לא רק מוסיפה את ההרשאות החדשות, אלא גם מסירה את אלה שכבר אינן רלוונטיות. בתהליך ידני, ההוספה מתבצעת כמעט תמיד וההסרה נשכחת כמעט תמיד, וכך נוצרת הצטברות ההרשאות שתיארנו קודם.
שלב 3: ניטור ובקרה (Monitoring)
ניהול הזהות לא מסתיים ברגע שההרשאה ניתנה. הארגון צריך לדעת אילו זהויות פעילות, למי הן שייכות, לאילו מערכות הן ניגשות וכיצד נעשה שימוש בהרשאות בפועל.
ניטור נכון מזהה חשבונות לא פעילים, זהויות בעלות הרשאות גבוהות שאינן מנוהלות, דפוסי גישה חריגים ופעילות שאינה תואמת את תפקיד המשתמש. יומני ביקורת (Audit Logs) מספקים את התיעוד הדרוש לחקירת אירועים, לביקורות הרשאות ולהוכחת עמידה בדרישות רגולטוריות.
שלב 4: ביטול הרשאות וסגירת החשבון (Deprovisioning)
עובד עוזב, חוזה של ספק מסתיים, אפליקציה יוצאת משימוש. בשלב הזה צריך לבטל את הגישה באופן מלא ומהיר: השבתת חשבונות, ביטול פרטי גישה ו-Tokens, הסרה מקבוצות, ביטול מפתחות ו-Certificates.
התהליך חל גם על זהויות מכונה. אינטגרציה שיצאה משימוש לפני שנה, שמפתח ה-API שלה עדיין תקף, היא סיכון אמיתי שקל מאוד לפספס.
ארבעה עקרונות ליישום נכון
אוטומציה של Provisioning ו-Deprovisioning. חיבור תהליכי ניהול הזהויות למערכת משאבי האנוש מאפשר ליצור חשבון עם קליטת העובד, לעדכן הרשאות עם שינוי תפקיד ולבטל את כולן ביום העזיבה עצמו, ולא כעבור שבוע.
ניהול הרשאות מבוסס תפקידים (RBAC). במקום להגדיר הרשאות לכל משתמש בנפרד, מגדירים פרופילי הרשאות לפי תפקידים: מנהלי מערכת, מפתחים, אנשי תמיכה, משתמשים עסקיים. כך מצמצמים טעויות ושומרים על מדיניות עקבית.
עיקרון ההרשאות המינימליות. מעניקים רק את הנדרש לביצוע המשימה. בגישה למערכות רגישות מומלץ להפריד בין חשבונות רגילים לחשבונות פריבילגיים, ולהעדיף גישה זמנית בשיטת Just-in-Time על פני הרשאות קבועות.
סקירות גישה תקופתיות וניטור שימוש. לא מספיק לדעת למי יש הרשאה. צריך לבדוק באופן שוטף האם היא עדיין נדרשת, ולהבין כיצד נעשה בה שימוש בפועל, במיוחד כשמדובר במנהלי מערכת, ספקים, קבלנים וחשבונות משותפים.
ILM, IAM ו-IGA: סדר במושגים
ניהול זהויות וגישה (IAM) הוא התחום הרחב: ניהול זהויות, Authentication, Authorization ומדיניות גישה למערכות הארגוניות.
ILM הוא חלק מעולם ה-IAM, והוא מתמקד במחזור החיים המלא של הזהות: יצירה, שינוי, ניטור וביטול.
כשמיישמים ILM ברמה ארגונית מלאה, כולל תהליכי אישורים, סקירות גישה וקישור למערכות HR, נכנס לתמונה גם תחום ה-IGA (ממשל זהויות), שמספק את שכבת המדיניות והבקרה מעל תהליכי ה-ILM.
איפה Syteca נכנסת לתמונה?
יישום ILM מלא בארגון דורש שילוב של כמה מערכות, ובראשן פלטפורמת IGA המקושרת למערכות משאבי האנוש. Syteca לא באה להחליף אותן. היא מתמקדת בחלק אחד של מחזור החיים, שהוא גם המסוכן ביותר: הזהויות הפריבילגיות. מנהלי מערכת, ספקים חיצוניים, חשבונות שירות וחשבונות משותפים. פריצה לחשבון אחד כזה מסוכנת לארגון הרבה יותר מפריצה לחשבון של משתמש רגיל.
את הזהויות האלה Syteca מלווה לאורך כל שלבי מחזור החיים:
בשלב הגילוי וה-Provisioning: איתור חשבונות בעלי הרשאות גבוהות שאינם מנוהלים, שמירה מאובטחת של פרטי גישה וניהול גישה מבוסס תפקידים ל-Secrets.
בשלב הניהול השוטף: החלפה אוטומטית של סיסמאות ופרטי גישה, וגישה זמנית מבוקרת למערכות רגישות.
בשלב הניטור: מעקב אחר פעילות משתמשים פריבילגיים בזמן אמת, הקלטת Sessions לצורכי בקרה ותחקור, והתראות על פעילות חריגה.
בשלב הביקורת וה-Deprovisioning: יומני ביקורת הניתנים לחיפוש ולניתוח, שמתעדים לא רק למי הייתה גישה אלא גם מה נעשה בה בפועל.
שאלות נפוצות
מה ההבדל בין ILM ל-IAM?
IAM הוא התחום הרחב של ניהול זהויות וגישה. ILM הוא תת-תחום שמתמקד במחזור החיים של הזהות, מהיצירה ועד הביטול.
מה זה מודל JML?
ראשי תיבות של Joiner, Mover, Leaver: הצטרפות לארגון, מעבר תפקיד ועזיבה. אלו שלוש נקודות הזמן שבהן הרשאות של משתמש חייבות להשתנות.
האם ILM רלוונטי גם לזהויות שאינן אנושיות?
כן, ולעיתים אף יותר מאשר לזהויות אנושיות. חשבונות שירות, מפתחות API ואינטגרציות נוצרים לרוב עם הרשאות רחבות מהנדרש וכמעט אף פעם לא מבוטלים. הם דורשים בעלים מוגדר, ניטור וביטול מסודר בדיוק כמו משתמש אנושי.
באיזו תדירות צריך לבצע סקירת הרשאות?
המלצת התעשייה היא סקירה רבעונית להרשאות פריבילגיות וסקירה חצי-שנתית לכלל ההרשאות. בסביבות רגולטוריות ייתכנו דרישות מחמירות יותר.
רוצים לראות איך נראית שליטה מלאה בזהויות הפריבילגיות בארגון שלכם?
צוות קונסיסט, הנציגה הבלעדית של Syteca בישראל, ישמח להראות לכם בדמו חי. צרו קשר לתיאום.