SSO לאפליקציית ווב: היכן הכניסה וההרשאות נשברות
כניסה אחודה (SSO) מפסיקה להיות "סתם כפתור כניסה" כשבארגון יש כמה מערכות: ספר עובדים, פורטל פנימי, CRM, מחסן, הנהלת חשבונות. כל אחת חיה עם מסד חשבונות משלה, ומספיק שאדם יעזוב או יחליף תפקיד — וההרשאות נשארות תלויות בשלושה-ארבעה מקומות. האימות עובד פורמלית, אבל כניסה למערכת אחת כבר פותחת יותר מדי באחרת.
הכשל הטיפוסי הראשון — אי-סנכרון חשבונות. העובד נוצר בספר אך לא נוצר באפליקציה, או להפך: מפוטר ממשיך להיכנס באמצעות טוקן ישן, כי ההפעלה חיה יותר מהרשומה במדריך.
השני — איפוסי סיסמה ידניים: התמיכה מבזבזת שעות על "לא מכניס לאזור האישי", אף שהבעיה בתעודה שפגה תוקפה או בשעה שגויה בשרת.
הכשל השלישי — כפילות כניסות. המשתמש פותח חשבון שני תחת דואר אחר, ובדוחות מופיעים שני "אותם" ישויות עם הרשאות שונות. הרביעי — גידול בעומס על התמיכה: ככל שיש יותר מערכות, כך יש יותר פניות, וכל אינטגרציה חדשה מוסיפה נקודת כשל משלה.
מפרקים כיצד זה נסגר: נקודת אימות אחודה, סנכרון המדריך וכללי שלילת גישה.
מה נותן כניסה אחודה: האפקט במספרים
כניסה אחודה נמדדת לא לפי נוחות "באופן כללי", אלא לפי שלושה מדדים: זמן הגישה לאפליקציה, שיעור הפניות לתמיכה הקשורות לגישה, ומספר האירועים עם סיסמאות. לפני ההטמעה עובד מבלה על כניסה לכל מערכת בין 20 ל-40 שניות — הזנת שם משתמש, המתנה לאימות, חזרה על הפעולה במקרה של שגיאה. עם עשרה שירותי עבודה מדובר בעשרות דקות בשבוע לאדם, וההפסדים גדלים באופן ליניארי עם מספר האפליקציות.
האפקט העיקרי — היעלמות סוג השגיאות הקשורות לאיפוס סיסמה. לפי הניסיון שלנו, איפוס ושחזור גישה מהווים בין 20 ל-40 אחוזים מכלל הפניות לתמיכה. לאחר המעבר לכניסה אחודה המשתמש עובר אימות פעם אחת דרך חשבון המשתמש הארגוני, והאפליקציה מקבלת סשן מאומת. הפניות בנושא סיסמאות יורדות פי כמה — התמיכה עוברת למשימות שבאמת דורשות אדם.
זמן הכניסה מתקצר לאימות אחד בתחילת יום העבודה: לאחר מכן המעברים בין השירותים מתרחשים ללא אימות חוזר. לתרחישים עם דרישות אבטחה מוגברות אנו מגדירים אישור חוזר רק לפעולות קריטיות, ולא לכל מעבר — ההגנה נשמרת, החיכוך נעלם. בנפרד נסגרת הסוגיה של פיטורים והחלפת תפקידים: הגישה נשללת בנקודה אחת, ולא בעשרה ממשקי ניהול.
אנו עובדים עם פרוטוקולים מוכחים של אימות פדרטיבי ומדריכים ארגוניים סטנדרטיים — Keycloak כאחת האפשרויות של broker, אם נדרש שליטה מלאה על התשתית. זה נותן אינטגרציה צפויה עם מדריך המשתמשים הקיים ללא כתיבה מחדש של האפליקציות.
את האפקט אנו מתעדים לפני ואחרי: מודדים את זמן הכניסה, מחשבים את שיעור הפניות בנושאי גישות, ועוקבים אחרי מספר האירועים עם סיסמאות.
דרכים למימוש SSO: השוואת גישות
כניסה אחודה נדיר שבונים מאפס — לעתים קרובות בוחרים בין פרוטוקול מוכן, חיבור לספרייה ארגונית או שער proxy לפני האפליקציה. הבחירה נקבעת לא על ידי אופנה, אלא על ידי הנוף: אילו מערכות כבר קיימות, היכן מאוחסנים חשבונות המשתמשים וכמה עמוק האפליקציה צריכה לדעת על המשתמש.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| OpenID Connect מעל OAuth 2.0 | אפליקציות ווב חדשות, משתמשים חיצוניים, לקוחות ניידים | דורשת ספק זהות ועבודה מדויקת עם טוקנים לרענון |
| SAML 2.0 | מתחם ארגוני, קיימת כבר ספרייה ופדרציה עם שותפים | חילופי נתונים מילוליים, ניפוי שגיאות מורכב יותר, תמיכה חלשה יותר בתרחישים ניידים |
| חיבור ל-LDAP או Active Directory | מערכות פנימיות ברשת אחת, נדרש מדריך עובדים אחוד | עובר בקושי דרך גבולות חיצוניים, דורש ערוץ מאובטח |
| שער proxy לפני האפליקציה | מערכות legacy שלא ניתן לשכתב | גמישות מוגבלת, תלות בשער כנקודת כשל יחידה |
למה להסתכל בבחירה
השאלה המרכזית היא היכן חי הסשן וכיצד האפליקציה לומדת על יציאת המשתמש. בפרוטוקולים פדרטיביים נדרשת יציאה אחודה: בלעדיה סגירת סשן במערכת אחת משאירה את האחרות פתוחות. עבור המתחם הפנימי זה נפתר בקישור לספרייה, ועבור החיצוני — בזמן חיים קצר של הטוקן וברענון לפי דרישה.
בנפרד בודקים את התאמת התפקידים והקבוצות: מאפיינים מהספרייה צריכים להתפרס להרשאות האפליקציה ללא סנכרון ידני. אם התפקידים מנוהלים בשני מקומות, במוקדם או במאוחר הם יתפצלו, והגישה תינתן למי שלא נועדה לו.
מה לקחת בחשבון לגבי מגבלות
שער proxy חוסך זמן בהתחלה, אך מוסיף נקודת כשל ומסבך את ניפוי השגיאות: האפליקציה מפסיקה לראות את ההקשר האמיתי של המשתמש. SAML אמין בסביבה ארגונית, אולם כל אפליקציה חדשה דורשת הגדרה נפרדת של מטא-נתונים. OpenID Connect גמיש יותר, אך מעביר חלק מהאחריות לאבטחת טוקנים לצוות הפיתוח.
אנחנו מנתחים את נוף המערכות שלכם ומציעים גישה שלא תצטרכו לשנות עם גידול מספר האפליקציות. תארו את המשימה — נחזור עם הערכה ותוכנית.
שלבי הטמעת כניסה אחודה למוצר
הטמעת SSO אינה "לחבר ספרייה", אלא להחליף את אופן אימות הזהות בכל נקודות הכניסה, מבלי לאבד אף משתמש ומבלי לפתוח פרצה בהרשאות.
לכן מתחילים לא מהקוד, אלא ממלאי מלאי: אילו אפליקציות ושירותים כבר משתמשים באימות, היכן מאוחסנים חשבונות המשתמש, אילו פרוטוקולים תומך כל רכיב ומי הבעלים של כל הרשאה. ללא מפה זו, כל הגדרה הופכת להגרלה.
כיצד בנוי התהליך
- ביקורת האימות הנוכחי. אוספים מרשם של אפליקציות, שירותים חיצוניים ואינטגרציות, מתעדים היכן הכניסה מקומית, היכן דרך ספק צד שלישי, והיכן ההרשאות ניתנו ידנית. בנפרד מסמנים שירותים שאינם תומכים בפרוטוקול כניסה אחודה — עבורם מתכננים מראש נתיב עוקף.
- בחירת תרחיש וספק. קובעים מי משמש כמקור האמת לחשבונות המשתמש: ספריית ארגון, ספק חיצוני או בסיס נתונים עצמאי. מכך נגזרת סכימת התאמת המשתמשים והכללים שלפיהם ההרשאות מהספרייה עוברות לאפליקציות.
- הגדרת הספק והאפליקציות. רושמים כל אפליקציה אצל הספק, מגדירים כתובות חזרה מהימנות, משכי חיים של הפעלות וטוקנים, והתאמת מאפיינים. כאן גם מניחים יציאה מכל המערכות בפעולה אחת — אחרת הכניסה האחודה נשארת חלקית.
- בדיקה בסביבת ניסוי. מריצים תרחישים: כניסה ראשונה של משתמש חדש, כניסה חוזרת, שינוי תפקיד בספרייה, שלילת הרשאה, פקיעת הפעלה, אי-זמינות הספק. כל תרחיש נבדק על כל סוגי חשבונות המשתמש, כולל חשבונות שירות.
- העברת משתמשים. מעבירים חשבונות משתמש וקשרים עם תפקידים, ובתקופת מעבר משאירים את שתי דרכי הכניסה, כדי שאיש לא יאבד גישה. סיסמאות מקומיות מנטרלים רק לאחר שווידאנו שכולם נכנסו דרך הכניסה האחודה.
- מסירה לתפעול. מתעדים תקנון: כיצד מוסיפים אפליקציה חדשה, כיצד שוללים הרשאה בעת סיום העסקה, מי אחראי על הספק. מגדירים תיעוד כניסות והתראות על אנומליות.
- תמיכה וליווי. מעיינים מעת לעת ברשימת השירותים המחוברים ובכללי ההתאמה — הרכב המערכות משתנה מהר מכפי שנדמה.
תארו את סכימת הכניסות הנוכחית שלכם — נחזור עם הערכה ותוכנית עבודה.
מה נשאר אצל הלקוח לאחר ההטמעה
הטמעת SSO היא לא "התקנו ושכחנו": האינטגרציה חיה ומשתנה יחד עם סביבת האפליקציות שלכם. לכן את כל הארטיפקטים אנו מעבירים לתשתית ולמאגרים שלכם, ולא שומרים אצלנו. להלן מה בדיוק נשאר בידיכם וכיצד להשתמש בזה בלעדינו.
- קונפיגורציות של שירות הזיהוי — פרמטרי חיבור של אפליקציות, הגדרות סשנים וטוקנים, כללי הנפקה ורענון של פרטי זיהוי. הכול במערכת בקרת גרסאות, עם היסטוריית שינויים ויכולת שחזור.
- תרשימי זרימות אימות — כיצד המשתמש עובר כניסה, היכן מתבצעת בדיקת הרשאות, כיצד האפליקציה מקבלת אישור זהות. התרשימים מתארים גם את התרחיש השגרתי וגם את ההתנהגות בעת אי-זמינות של הספק.
- מדיניות גישה — שיוך תפקידים וקבוצות לאפליקציות, כללי ירושת הרשאות, סדר הענקה ושלילה של גישה בעת קליטה, העברה וסיום העסקה של עובד.
- נהלי תפעול — כיצד להוסיף אפליקציה חדשה, כיצד לחבר קבלן חיצוני, מה לעשות בעת כשל בכניסה ולאן להסתכל קודם כל. שלב אחר שלב, עם אחראים ונקודות בקרה.
- תיעוד — תיאור הארכיטקטורה, רשימת המערכות המחוברות, מדריך הגדרות, יומן שינויים. מיועד למהנדס שיפתח אותו בעוד חצי שנה בלעדינו.
- הנחיות לשירות התמיכה — פניות אופייניות בנושא כניסה ושחזור גישה, תשובות מוכנות והגבול שמעבר לו מתחברת הצוות הטכני.
- גישות והרשאות של מנהלים — הפרדה בין תפקידים לניהול משתמשים לבין שינוי קונפיגורציה, כך שפעולות יומיומיות לא ידרשו הרשאות מלאות.
מערך כזה מסיר את הסיכון העיקרי: כאשר SSO מתחיל לחיות חיים משל עצמו, יש לכם גם מפת שטח וגם מנופי שליטה. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית, כולל הרכב הארטיפקטים המועברים.
מקרה בוחן: כיצד הסרנו את חוסר הסנכרון בין חשבונות המשתמש
הלקוח — חברת שירותים עם צוות מבוזר — הגיע עם כאב קלאסי: מספר מערכות פנימיות, שלכל אחת מהן מסד נתונים משלו של משתמשים. העובד נרשם בעת הקבלה לארבעה מקומות באופן ידני, ובעת סיום העסקתו החשבון שלו לא הושבת בכל המקומות.
במהלך הרבעון הצטברו כ-40 רשומות פעילות "מתות", ומחלקת התמיכה בילתה עד שליש מזמן העבודה על איפוס סיסמאות וטיפול בהרשאות גישה.
מה היה לפני ההטמעה
חשבונות המשתמש התקיימו במערכות שונות באופן בלתי תלוי: מקור אמת יחיד לא היה קיים, וההרשאות הוקצו "לפי העין". חוסר הסנכרון התבטא בשני תרחישים — עובד שסיים את העסקתו שמר על גישה לחלק מהמערכות, ועובד שהועבר למחלקה אחרת המשיך לראות נתונים של היחידה הקודמת. כל מקרה כזה טופל באופן ידני, תוך שחזור מהלוגים היכן ומתי נפרדו הרשומות.
מה שינינו
בנינו כניסה אחודה על בסיס Keycloak כספק זיהוי וחיברנו אליו את כל המערכות הפנימיות בפרוטוקול תקני. קטלוג העובדים הפך למקור האמת היחיד: חשבון המשתמש נוצר פעם אחת, והתפקידים וההרשאות מוקצים דרך קבוצות.
השבתת עובד כעת סוגרת את הגישה בכל המערכות בו-זמנית — זהו חלק מהתהליך, ולא משימה נפרדת של מנהל המערכת.
מה נהיה לאחר מכן
מספר הפעולות הידניות ליצירה ולמחיקה של חשבונות הצטמצם בכ-90%, ורשומות פעילות "מתות" לא נותרו כלל. פניות לתמיכה בנושא סיסמאות ירדו כמעט פי שלושה — העובדים נכנסים עם סט נתונים אחד.
הזמן לחיבור אדם חדש למערכות העבודה הצטמצם משעות ספורות לדקות, ובדיקת הגישה (audit) כעת אורכת שאילתה אחת במקום מעבר ידני בין המערכות.
במה שונה SSO מפדרציית זהויות?
SSO פותר את משימת הכניסה בתוך היקף אחד: המשתמש מאמת את עצמו פעם אחת בשירות מרכזי ומקבל גישה ליישומים שנותנים בו אמון. האמון כאן נבנה על חשבון משותף ומאגר משותף — ספרייה שבה נמצאים שמות משתמש, קבוצות ותפקידים.
כל היישומים נמצאים תחת שליטה ניהולית אחת, ולכן תיאום מדיניויות סיסמאות, משכי חיי הפעלה ודרישות לאימות רב-גורמי מתרחש בתוך צוות אחד.
פדרציית זהויות פועלת בין דומיינים שונים ובעלים שונים. המשתמש נשאר בארגון שלו, והשירות השותף אינו פותח אצלו חשבון — הוא נותן אמון בהצהרה על זהות החתומה על ידי ספק הזהויות.
ההבדל המרכזי: ב-SSO אנו מנהלים את כל החשבונות בעצמנו, בעוד שבפדרציה — רק מאשרים את עובדת האימות, בלי לקבל גישה לסיסמה ולפרופיל של המשתמש.
מכאן נובעות דרישות שונות למימוש. עבור SSO די בספרייה אחודה ובפרוטוקול להעברת הפעלה בין יישומים באותו דומיין. עבור פדרציה נדרשים מטא-נתונים של שני הצדדים, החלפת מפתחות חתימה, מאפיינים שהוסכמו מראש — איזה מידע בדיוק על המשתמש מועבר ובאיזו צורה. טעות בהתאמת מאפיינים מביאה לכך שהאדם נכנס, אך אינו מקבל את ההרשאות הנדרשות.
בפועל לעתים קרובות משלבים בין המודלים הללו. בתוך החברה פורסים SSO, ועבור שותפים חיצוניים וקבלנים מגדירים פדרציה, כדי לא להנפיק להם חשבונות בספרייה שלהם. הגבול בין הגישות עובר בשאלה: מי owns את החשבון ומי אחראי למחזור החיים שלו — יצירה, חסימה ומחיקה בעת פיטורים או סיום חוזה.
ספקות טכניים בעת הטמעת SSO
שאלות בשלב בחירת הפרוטוקול ותכנית האינטגרציה עולות תמיד — וזה נורמלי: מהתשובות תלוי כיצד SSO ישתלב בנוף האפליקציות הנוכחי והאם לא ישבור את הכניסה למשתמשים קיימים. להלן מה שלרוב דנים בו עם צוותים טכניים לפני תחילת העבודה.
האם SSO תואם לאפליקציות הנוכחיות שלנו, אם חלקן כתובות בעצמנו?
כן, אם האפליקציה יודעת לעבוד עם ספק זהות חיצוני. עבור מסגרות מודרניות אלו ספריות סטנדרטיות, ועבור מערכות שנכתבו בעצמנו — אינטגרציה דרך פרוטוקולים סטנדרטיים (OIDC או SAML). אם האפליקציה אינה תומכת באף אחד מהם, מתאימים אותה: מוסיפים מודול לבדיקת טוקן והעברת נתוני המשתמש לסשן. המורכבות תלויה בשאלה האם המערכת שומרת מסד סיסמאות ותפקידים משלה — זאת מנתחים בשלב הסקר.
מה עם האבטחה: האם נקודת כניסה אחודה לא תהפוך לחוליה חלשה?
להיפך — SSO מסיר את הפגיעות העיקרית, כאשר משתמשים מחזיקים סיסמאות שונות או עושים שימוש חוזר באחת. האימות מתרכז במקום אחד, שבו ניתן להפעיל בדיקה רב-שלבית, הגבלה לפי IP ותיעוד כניסות.
העיקר — להגדיר נכון את תוקף הטוקנים וביטולם בעת יציאה, כדי שהסשן לא יישאר פעיל בכל האפליקציות לאחר התנתקות.
כיצד תתבצע ההגירה — האם נצטרך לחייב את כולם להחליף סיסמאות?
לא בהכרח. חשבונות המשתמשים מועברים, וניתן לסנכרן סיסמאות דרך פדרציה עם מאגר הנתונים הנוכחי או להשאיר כניסה לפי הסיסמה הישנה לתקופת מעבר. בדרך כלל מפעילים את SSO במקביל לכניסה הקודמת, מעבירים אפליקציה אחת בכל פעם ומכבים את התכנית הישנה כאשר משתכנעים שכל תרחישי הכניסה עובדים. חזרה אחורה בכל שלב — החזרה לתצורה הקודמת ללא אובדן חשבונות משתמשים.
מי יקבל גישה לנתוני המשתמשים וכיצד זה מוסדר?
ספק הזהות שומר רק מאפיינים הנדרשים לכניסה ולתפקידים — שאר הנתונים נשארים באפליקציות. ההרשאות מחולקות לפי קבוצות, ולא באופן ידני, ולכן בעת פיטורים או שינוי תפקיד הגישה נסגרת במקום אחד ומיד בכל המערכות.
נדון במשימה שלך בנושא כניסה מאוחדת
לפני שנציע פתרון, עלינו להבין את התמונה הנוכחית שלך: אילו אפליקציות ושירותים כבר בשימוש, היכן מאוחסנים חשבונות המשתמש, וכיצד בנויים התפקידים והרשאות הגישה. מכך תלוי אם הכניסה המאוחדת תהיה תוספת מעל ספריית המשתמשים הקיימת או שתדרוש בנייה מחדש של מודל הגישה.
לכן הצעד הראשון הוא ניתוח קצר של המשימה יחד עם הצוות שלך: אילו מערכות צריכות להשתתף ב-SSO, מי וכיצד מנהל את המשתמשים כיום, ואילו תרחישי כניסה הם קריטיים.
בעקבות הניתוח נחזור עם הערכה ותוכנית יישום — עם שלבים, לוחות זמנים ותחומי אחריות. אין צורך להכין אפיון טכני מפורט: די לתאר את המשימה ואת המצב הקיים, ואת השאר נארגן בעצמנו.
מה תקבל בתחילת העבודה:
- ניתוח של סכימת האימות הנוכחית והנקודות שבהן היא נכשלת.
- רשימת האפליקציות והשירותים שייכללו בכניסה המאוחדת, עם עדיפות החיבור.
- מודל תפקידים והרשאות: מי מקבל גישה למה וכיצד זה משתנה בעת פיטורים או העברה.
- אפשרויות יישום SSO עבור המצב הקיים שלך — עם היתרונות והמגבלות של כל אחת.
- תוכנית הגירת משתמשים ללא השבתה ועם אפשרות לחזרה לאחור.
- רשימת סיכונים: מערכות שאינן תואמות, אפליקציות מיושנות, קבלנים חיצוניים.
- הערכת לוחות זמנים והרכב העבודות לפי שלבים.
תאר את המשימה — אילו אפליקציות יש לאחד, כמה משתמשים, האם יש שותפים חיצוניים ודרישות אבטחה. נחזור עם הערכה ותוכנית יישום, שלפיה ניתן לקבל החלטה.
