מאמת VPN שאבד: החלפה בלי לכבות את ה-MFA

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

שלב 1: קראו את הגורמים הרשומים מרשומה, לא מהזיכרון

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

Get-MgUserAuthenticationMethod -UserId [email protected]

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

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

שלב 2: אמתו את המבקש מחוץ למסלול הכושל

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

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

שלב 3: רשמו את המחליף, ואז פרשו את הגורם הישן

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

Revoke-MgUserSignInSession -UserId [email protected]

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

שלב 4: הוכיחו שהחשבון עובד בשני הכיוונים

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

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

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

שלב 5: הסירו את התנאי שהפך את זה לכואב

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

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