מי שמתחבר ל-LMS שלכם פעם בשנה לריענון ציות לעולם לא יזכור את הסיסמה שלו. אז הוא לוחץ על ‘שכחתי סיסמה’, מחכה לאימייל, ממציא סיסמה חדשה שיישכח שוב, או מוותר ופותח פנייה. התחברות ללא סיסמה מסירה את הסיסמה לגמרי. המדריך הזה מסביר איך זה עובד, איפה באמת נמצאות פשרות האבטחה, ומתי כדאי להוסיף מעל זה כניסה יחידה ב-SAML.
למה סיסמאות מכשילות לומדים מזדמנים
סיסמאות עובדות הכי טוב במערכות שאנשים משתמשים בהן כל יום. פלטפורמת הדרכה היא לרוב ההפך: אנשים מתחברים כשהם נרשמים, כשמגיעה תזכורת, או כשתעודה עומדת לפוג.
זה יוצר סדרת בעיות צפויה:
- סיסמאות שנשכחו. כשעוברים חודשים בין התחברות להתחברות, לומדים רבים מתחילים באיפוס, לעיתים קרובות ביום שבו ההדרכה אמורה להסתיים.
- שימוש חוזר. אנשים שלא יכולים לזכור עוד סיסמה משתמשים בסיסמה מאתר אחר. אם האתר האחר נפרץ, אפשר לנסות את אותו אימייל ואותה סיסמה מול ה-LMS שלכם.
- עקיפות. כללי סיסמה מחמירים מובילים לסיסמאות על פתקים דביקים, או לווריאציות צפויות כמו הוספת מספר בכל פעם.
- עומס על התמיכה. כל נעילה וכל איפוס הם פנייה לשירות התמיכה שלכם או לצוות ה-L&D.
יש גם נקודה שקטה יותר. רוב מערכות הסיסמאות מאפשרות לאנשים לאפס את הסיסמה באימייל, וזה אומר שתיבת הדואר כבר שולטת בחשבון. הסיסמה היא החלק שאנשים שוכחים, לא החלק שמגן עליהם. התחברות ללא סיסמה פשוט הופכת את זה למפורש.
איך התחברות ללא סיסמה עובדת
קודים חד-פעמיים באימייל
- הלומד מזין את כתובת האימייל שלו.
- ה-LMS מייצר קוד אקראי קצר ושולח אותו אליו באימייל.
- הלומד מקליד את הקוד, וה-LMS בודק אותו.
קוד מתוכנן היטב עובד פעם אחת, פג תוך דקות, ומפסיק לעבוד אחרי כמה ניסיונות שגויים. אין מה לזכור, אין שימוש חוזר בסיסמה מאתר אחר, ואין סיסמה שיכולה לדלוף.
מערכות מסוימות שולחות באימייל קישור התחברות במקום קוד. קודים נוחים כשמישהו קורא אימייל בטלפון אבל מתחבר במחשב עבודה, כי אפשר פשוט להקליד את הקוד.
חשבונות Google, Microsoft או LinkedIn
עם כפתורי ‘התחברות באמצעות’, ה-LMS מעביר את ההתחברות לספק באמצעות פרוטוקולים סטנדרטיים כמו OAuth 2.0 ו-OpenID Connect. הספק בודק מי האדם, כולל כל אימות דו-שלבי בחשבון שלו, ומודיע ל-LMS מי הוא ומהי כתובת האימייל המאומתת שלו. ה-LMS אף פעם לא רואה את הסיסמה שלו.
זה מתאים לעובדים שכבר מתחברים ל-Microsoft 365 או ל-Google Workspace כל יום: לחיצה אחת והם בפנים.
פשרות האבטחה, בכנות
התחברות ללא סיסמה אינה קסם. היא מעבירה את האמון למקום אחר, וכדאי שתדעו לאן.
| שיטה | מה מגן על החשבון | על מה לשים לב |
|---|---|---|
| סיסמה | משהו שהלומד זוכר | שימוש חוזר, בחירות חלשות, ואיפוסים באימייל בכל מקרה |
| קוד באימייל | גישה לתיבת הדואר של הלומד | תיבת דואר שנפרצה פירושה חשבון LMS שנפרץ |
| Google, Microsoft או LinkedIn | חשבון הספק והאימות הדו-שלבי שלו | חשבונות אישיים נמצאים מחוץ לשליטה שלכם |
| כניסה יחידה ב-SAML | ספק הזהויות שלכם והמדיניות שלו | מאמץ הגדרה, ותלות בזמינות הספק |
כמה פרטים כדאי להבין:
- חשבון האימייל הוא החשוב ביותר. כל מי שיכול לקרוא את האימייל של לומד יכול להתחבר בתור אותו לומד. אימות רב-שלבי בתיבות דואר של העבודה תורם לאבטחת ה-LMS יותר מכל כלל סיסמה.
- פקיעה וניסיונות מוגבלים עוצרים ניחושים. לקוד בן שש ספרות יש בערך מיליון ערכים אפשריים, כך שלשלושה ניסיונות יש למנחש סיכוי של כמה במיליון, וכל קוד חי דקות ספורות. הגבלות על תדירות בקשת הקודים מאטות את התהליך עוד יותר.
- אפשר עדיין לעשות פישינג לקודים. דף התחברות מזויף יכול לבקש קוד ולהשתמש בו מיד. למדו אנשים להזין קודים רק בכתובת האמיתית של ה-LMS שלכם, ושאף אחד, כולל התמיכה, לעולם לא יבקש מהם קוד.
- תיבות דואר משותפות מחלישות את הרשומות שלכם. אם כמה אנשים יכולים לקרוא תיבה אחת, כל אחד מהם יכול להתחבר בתור הבעלים שלה. כל לומד צריך כתובת משלו כדי שלרשומות ההדרכה תהיה משמעות.
- צריך להסיר את מי שעוזבים מכל מקום. חשבון Google או LinkedIn אישי לא נעלם כשמישהו עוזב. השהו או העבירו לארכיון את החשבון ב-LMS כחלק מתהליך העזיבה, ולא רק בספריית המשתמשים שלכם.
- מסירת האימייל היא חלק מהמערכת. קודים שנוחתים בספאם או מגיעים באיחור גורמים להתחברויות שנכשלות. בקשו מ-IT לאפשר את האימיילים של ה-LMS במסנני הדואר שלכם.
תכננו שחזור לפני שתצטרכו אותו
עם התחברות ללא סיסמה, פניות ‘שכחתי סיסמה’ נעלמות ברובן. שאלת התמיכה הרגילה הופכת ל’לא קיבלתי את הקוד שלי’, והתשובה כמעט תמיד היא לבדוק בתיקיית הספאם, לאשר את הכתובת ולבקש קוד חדש.
מנהלים דורשים מחשבה נוספת. אם אתם נשענים על כניסה יחידה ולספק הזהויות שלכם יש תקלה, או שהגדרה שונתה בטעות, אתם צריכים דרך להיכנס שלא תלויה במה שנשבר. נוהג טוב:
- שמרו לפחות שני מנהלים, כך שאדם אחד שמאבד גישה לא יינעל מחוץ לארגון.
- ודאו שלמנהלים יש מסלול שחזור שאינו תלוי בספק הזהויות שלכם.
- נסו את מסלול השחזור הזה פעם אחת, ברוגע, לפני שתצטרכו אותו ביום רע.
- אם אתם מגבילים מנהלים לטווחי IP של המשרד, בדקו איך מנהלים מרחוק ייכנסו.
מתי להוסיף כניסה יחידה ב-SAML
קודים באימייל והתחברות חברתית מתאימים לרוב הלומדים. כדאי להוסיף כניסה יחידה ב-SAML כאשר:
- העובדים שלכם כבר מנוהלים ב-Microsoft Entra ID, ב-Okta או ב-Google Workspace.
- אתם רוצים שמדיניות האימות הרב-שלבי והגישה של ספק הזהויות שלכם תחול גם על ההדרכה.
- אתם רוצים שאנשים יאבדו גישה ברגע שהם מושבתים בספריית המשתמשים שלכם.
- סקירות אבטחה או שאלוני לקוחות מבקשים כניסה יחידה.
זו לא התשובה המלאה אם לומדים רבים נמצאים מחוץ לספרייה שלכם, כמו קבלנים, מתנדבים, לקוחות או עובדים של ארגונים אחרים. במקרה כזה, השתמשו ב-SSO לעובדים שלכם ושמרו קודים באימייל לכל השאר. אנחנו מכסים את ההגדרה ביתר פירוט בכניסה יחידה ל-LMS שלכם.
איך Acadenix עושה את זה
ב-Acadenix אין סיסמאות בכלל. אנשים מתחברים באחת מהדרכים האלה:
- קודים באימייל. אנשים מזינים את האימייל שלהם ומקבלים קוד בן שש ספרות. הוא עובד פעם אחת, למשך חמש דקות, ומפסיק לעבוד אחרי שלושה ניסיונות שגויים. מי שמבקש קודים לעיתים קרובות מדי מתבקש להמתין.
- Google, Microsoft ו-LinkedIn. כל שיטה מופעלת או מכובה במסך Settings → Authentication (הגדרות ← אימות), ואפשר להגביל אותה לדומייני אימייל מאומתים מסוימים. לפני שמירת שינוי רואים כמה אנשים והפעלות הוא משפיע עליהם.
- אפליקציות ההתחברות שלכם. ארגונים יכולים להשתמש באפליקציית Google, Microsoft או LinkedIn משלהם. עם אפליקציית Microsoft משלכם, רק חשבונות ב-tenant שלכם יכולים להשתמש בה.
- כניסה יחידה ב-SAML ב-Gold. חברו Microsoft Entra ID, Okta או Google Workspace. אפשר ליצור חשבונות לומדים בהתחברות הראשונה, אבל רק לכתובות שנמצאות בדומייני האימייל של הארגון שלכם. בפעם הראשונה שמישהו מתחבר דרך SAML נשלח אליו באימייל קוד לאישור הקישור, פעם אחת לכל אדם. שיטות אחרות שהפעלתם נשארות כגיבוי. ראו מסלולים ומחירים.
למנהלים יש אמצעי הגנה נוספים. אפשר להגביל מנהלים לטווחי ה-IP שלכם בלי להשפיע על לומדים, והפעלות לא פעילות מתנתקות. אם שיטת ההתחברות הרגילה שלכם מפסיקה לעבוד, מנהל עדיין יכול להיכנס עם קוד שחזור שנשלח לאימייל שלו, ואי אפשר לכבות את המסלול הזה. השהיית חשבון של מישהו עוצרת אותו מלהתחבר מיד, והמסך Email History (היסטוריית אימיילים) מראה אילו אימיילים נשלחו או נכשלו ב-30 הימים האחרונים, בלי לשמור את תוכן ההודעות או את הקודים. יש פירוט נוסף בדף האבטחה שלנו.
עיקרי הדברים
- ללומדים מזדמנים, סיסמאות יוצרות איפוסים, שימוש חוזר ופניות בלי להוסיף הרבה הגנה.
- קודים באימייל והתחברות עם חשבון עבודה מסירים את הסיסמה; תיבת הדואר או חשבון הספק הופכים למפתח, ולכן הגנו עליהם באימות רב-שלבי.
- קודים חד-פעמיים שפגים במהירות ומאפשרים מעט ניסיונות הופכים ניחוש לבלתי מעשי, אבל אנשים עדיין צריכים לדעת לא לשתף קוד לעולם.
- תכננו שחזור למנהלים ותהליך עזיבה לפני שאתם מפעילים שיטות התחברות.
- הוסיפו כניסה יחידה ב-SAML כשהעובדים שלכם מנוהלים בספק זהויות מרכזי, ושמרו קודים באימייל לכל השאר.
אם סיסמאות הן המקור הגדול ביותר לפניות התמיכה בהדרכה שלכם, ראו איך התחברות ללא סיסמה עובדת עם האנשים שלכם. בקשו גרסת הערכה והגדירו את שיטות ההתחברות שמתאימות לארגון שלכם.
