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

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

למה סיסמאות ממשיכות להיות נקודת כשל

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

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

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

אימות ללא סיסמה אינו אותו דבר כמו MFA

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

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

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

מתחילים ממיפוי, לא מהפצת אפליקציה

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

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

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

ארבע בקרות שאסור לדלג עליהן

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

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

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

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

מה עושים עם מערכות שלא יכולות להיפרד מסיסמה

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

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

איפה נכנס ניהול הסיסמאות הארגוני

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

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

מדדו את המעבר גם דרך FinOps

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

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

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

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