בקשת MFA ל-VPN נדחתה: מה הלקוח צריך לעשות

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

בדקו איזו בקשה נכשלה

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

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

נסו שוב פעם אחת, בכוונה, עם אתגר חדש

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

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

מה הלקוח אסור לו לעשות

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

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

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

מה לתעד עבור התמיכה

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

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

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

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