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