מה ממפים לפני הניסוי
רשמו שירותים, ספק זהות, סוגי מכשירים ודפדפנים, וכן חשבונות ניהול וחשבונות רגילים. בדקו בתיעוד של כל שירות אם הוא תומך בשיטת הכניסה הרצויה ובמדיניות הניהול הנדרשת. תמיכה של מערכת אחת אינה מעידה שכל החיבורים העסקיים תומכים באותו תהליך.
מפו גם כניסות חלופיות ושחזור. אם הסיסמה הישנה עדיין פעילה, הוספת Passkey אינה מסירה אוטומטית את מסלול הכניסה הזה. החלטה על צמצום חלופות נעשית רק אחרי שהחלופה המאושרת וההתאוששות נבדקו.
איפה יישמר מפתח הגישה
Passkeys יכולים להיות מסונכרנים באמצעות ספק מתאים או קשורים למכשיר מסוים, לרבות מפתח אבטחה. לפי FIDO, ההבדל משפיע על ניידות ושחזור. בשני המקרים צריך לתכנן כיצד המשתמש חוזר לחשבון אם האמצעי הרגיל אינו זמין.
לעסק חשובה גם הבעלות על חשבון הסנכרון. אין להניח שמפתח שנשמר בחשבון פרטי ניתן להעברה או לניהול ארגוני. בחרו אופן אחסון מותר ותעדו כיצד מסירים רישום מהשירות כאשר עובד עוזב או מכשיר אובד.
אילו תרחישים בודקים בקבוצת הניסיון
בדקו את מסלול העבודה ולא רק את מסך הרישום. הכינו מראש איש קשר מורשה ותוכנית חזרה, בלי להסיר את אמצעי הכניסה האחרון של משתמש אמיתי לצורך ניסוי. התרחישים הבאים הם מסגרת קבלה שתתאימו למערכות שלכם.
| תרחיש | מה מאמתים | מה מתעדים |
|---|---|---|
| כניסה רגילה | השיטה עובדת במכשירים ובדפדפנים שנבחרו | שירות, מכשיר ותוצאה |
| מכשיר אינו זמין | מסלול חלופי מורשה אכן נגיש | מי מאמת זהות ואיך חוזרים |
| מפתח לא מוכר | ניתן לזהות ולבטל רישום בשירות | הרישום שבוטל ותוצאת הבדיקה |
| עזיבת עובד | החשבון והגישה מבוטלים אצל הספק | חשבון, חיבורים ופעולות משלימות |
| כניסה ישנה | ידוע אילו מסלולים נשארו פעילים | חריגים ומועד לבחינה מחדש |
דוגמה להגדרה שצריך לבדוק ב-Workspace
ב-Google Workspace מנהל יכול לאפשר דילוג על סיסמה באמצעות Passkey, והמשתמש משלים רישום והגדרה בחשבונו. לפי Google, האפשרות אינה מוחקת את הסיסמה הקיימת ורישום Passkey אינו מפעיל אוטומטית 2SV.
זו דוגמה לכך שתמיכת מוצר, רישום מפתח ומדיניות אכיפה הם דברים שונים. בודקים את ההגדרה האפקטיבית על חשבון ניסיון ומתעדים אותה. אין להעתיק את אותם צעדי ממשק למערכת אחרת או להניח שכולם כבר עברו לכניסה ללא סיסמה.
מתי מרחיבים את ההטמעה
מרחיבים אחרי שהכניסה, השחזור והטיפול בעזיבה עברו בדיקה, ושהתמיכה יודעת מה לעשות במקרה תקלה. בנו רשימה של שירותים שאושרו ושל כאלה שנותרו בתהליך אחר. FIDO מרכזת משאבים ייעודיים לפריסה ארגונית; הבחירה בפועל תלויה בדרישות וביכולות הספק.
Passkeys נועדו לחזק אימות עמיד לפישינג, אך אינם מנקים מכשיר פגוע או מבטלים הרשאות עודפות. המשיכו לבדוק מכשירים, sessions ודרכי שחזור. תיעוד ההטמעה צריך לתאר כיסוי שנבדק, ולא הבטחה שכל אירוע השתלטות נמנע.
תרחיש פיילוט: מחשב עבודה, טלפון חלופי ועזיבת עובד
הדוגמה הבאה היא תכנון מוצע. בחרו שירות שהארגון רשאי לנהל וחשבון ניסיון שאינו הדרך היחידה לניהולו. רשמו מכשיר ראשי, מכשיר חלופי, ספק אחסון המפתחות ודרך שחזור. אמתו האם המפתח מסונכרן או קשור למכשיר לפי יכולות המוצר ולא לפי שם שיווקי בלבד.
בדקו כניסה רגילה וכניסה מסביבת העבודה הנדרשת. תרגלו אובדן מדומה בלי למחוק את אמצעי הגישה האחרון: האם איש התמיכה יודע את המסלול המורשה, האם המשתמש יכול לחזור לעבודה ואילו רישומים נדרשים. אין צורך למסור מפתח פרטי או לפתוח חשבון ענן אישי של עובד כדי לאמת את התהליך.
לאחר מכן בדקו תהליך עזיבה בחשבון הניסיון: ביטול גישה במערכת, רישומים והשלכות על חיבורים. עצם קיומו של מפתח במכשיר אינו אומר שהחשבון עוד מורשה, ומחיקת המפתח לבדה אינה בהכרח מסיימת חיבור פעיל. רשמו מה הוכח בכל שירות ומה נשאר באחריות ספק או מערכת אחרת.
