1. Zen IT Technologies
  2. ניהול זהויות והרשאות

מקור אמת אחד לשאלה מי יכול לגשת למה.

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

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

בואו נדבר

הבעיה

רוב מערכי הזהויות מעולם לא תוכננו. הם הצטברו.

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

הסימפטומים מוכרים:

  • חשבונות ששורדים את העובד.

    משתמשים שעזבו ועדיין יש להם גישה פעילה למערכות SaaS שאף אחד לא מיפה.

  • הקצאה ידנית בהיקף גדול.

    עובדים חדשים שממתינים יום לגישה, וצוות IT שיוצר חשבונות ידנית בתריסר מערכות.

  • הרשאות שניתנו ולא בוטלו.

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

  • יותר ממקור סמכות אחד.

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

  • שאלות ביקורת שאין לכם תשובה עליהן.

    מבקר SOC 2 או ISO שואל למי הייתה גישה למה ומתי, ואין מערכת שיודעת לענות.

מה אנחנו עושים
  1. משתמש
  2. IdP
  3. SaaS
  4. מכשיר

הקצאת משתמשים (SCIM) וניהול מחזור חיים

  • מעבר בין פלטפורמות זהויות

    מעברים מלאים בין מערכות זהויות: מ-JumpCloud ל-Okta, מ-Google או מספרייה מקומית ל-Entra ID, ואיחוד ספריות מקבילות למקור אמת אחד. מתוכנן כמעבר מדורג עם אפשרות חזרה לאחור בכל שלב, לא כהימור של סוף שבוע.

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

  • בחירת הפלטפורמה: SSO או IdP

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

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

    כאשר מערכת הזהויות עצמה צריכה להיות מקור האמת, מדובר בפתרון IdP, וזו כבר ארכיטקטורה אחרת: מחזור חיים שמתחיל במערכת משאבי האנוש, הרשאות הנגזרות מתפקיד, אינטגרציות SCIM מלאות מול מערכות שמיישמות את התקן באופן חלקי, גישה מותנית לפי מכשיר והקשר, Authorization Servers ייעודיים ל-API שלכם והאצלת סמכויות ניהול שעומדת בביקורת. כאן נמצא ההבדל בין Okta לפלטפורמות קלות יותר: לא בהתחברות עצמה, אלא בכל מה שבא אחריה.

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

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

  • SSO ופדרציה

    חיבורי SAML ו-OIDC על פני כל מערך ה-SaaS, כולל המקרים המורכבים: authorization servers ייעודיים, תכנון scopes ל-API, מערכות עם תמיכה חלקית בתקנים, ופלטפורמות שדורשות מיפוי claims מותאם.

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

  • הקצאת משתמשים (SCIM) וניהול מחזור חיים

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

    כולל אינטגרציה ל-HRIS, תכנון מודל קבוצות, אוטומציה של הקצאת רישיונות, והדיווח שמוכיח שהתהליך אכן רץ.

  • תהליכי IT ואוטומציה

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

  • סקירת הרשאות וניהול גישה בהרשאות גבוהות

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

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

  • סקירת ספקים וניהול ספקים

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

מסמכים טכניים באנגלית

SSO הוא החלק הקל

האימות הוא רק צד אחד של העניין. השאלה אילו חשבונות בכלל צריכים להתקיים היא החלק המורכב.

עוד בנושא

איך זה עובד

  1. מיפוי.

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

  2. תכנון.

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

  3. מעבר.

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

  4. ניהול שוטף.

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

זמין כפרויקט ←

דוגמאות מהשטח

  • ניהול הזהויות וניהול המכשירים הופרדו בלי מעבר טראומטי.

    חברת סייבר

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

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

    חברת פינטק

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

  • מערכת ללא תמיכה בזהות ארגונית חוברה לאימות מרכזי.

    חברת טכנולוגיה

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

  • מודל הרשאות מפוצל הוחלף בגישה מבוססת מחזור חיים.

    חברת טכנולוגיה

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

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

למי זה מתאים

בדרך כלל זה השלב שבו כדאי לפעול:

מספר העובדים ומערכות ה-SaaS גדלים מהר יותר ממודל הזהויות שמאחוריהם.

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

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

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

שאלות נפוצות

  • אנחנו צריכים IdP, או ש-SSO מספיק?

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

  • זו בעיה להפעיל יותר מפלטפורמת זהויות אחת?

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

  • כמה זמן לוקח מעבר בין פלטפורמות?

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

  • אפשר להפעיל את שתי הפלטפורמות במקביל בזמן המעבר?

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

  • מה זה SCIM והאם אנחנו באמת צריכים את זה?

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

  • עם אילו פלטפורמות אתם עובדים?

    מערכות ופלטפורמות ארגוניות שאנחנו עובדים איתן כוללות Microsoft 365, Google Workspace, Okta, JumpCloud, Atlassian, Mimecast, Jamf, Salesforce ופלטפורמות דומות. הפלטפורמה עצמה היא רק חלק מהתמונה. מה שחשוב הוא מי מנהל את הזהויות, איך ניתנות ונשללות הרשאות, ואיך המערכות מתחברות זו לזו.

בואו נגלה מה באמת יש במערך הזהויות שלכם.

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

בואו נדבר