Втрачений автентифікатор VPN: заміна без вимкнення MFA

Хтось губить телефон, і тікет приходить як «VPN зламано». Таке формулювання хибне двічі: обліковий запис ще існує, а шлюз досі довіряє постачальнику ідентичності, тому єдина зламана частина — це один фактор, якого людина більше не має. Ставтеся до цього як до відновлення, а не як до збою: перевірте заявника, зареєструйте заміну, відкличте втрачений метод і потім доведіть, що запис працює. Усе це припускає, що план було написано до втрати, бо вигадувати його під час дзвінка — це шлях, яким MFA зрештою вимикають усім.

Крок 1: читайте зареєстровані фактори із запису, а не з пам'яті

Перше питання — не який пристрій втрачено, а що ще може використовувати обліковий запис. У записі може бути пароль із push, код на основі часу, апаратний ключ і роздруковані коди відновлення, і втрата одного з них — зовсім інша подія, ніж втрата єдиного. Читайте список методів із системи ідентичності, а не просіть користувача пам'ятати його, і в клієнті Microsoft Entra запит — один рядок:

Get-MgUserAuthenticationMethod -UserId [email protected]

Потім запишіть журнал відновлення, поки обліковий запис ще працює: ідентифікатор запису, зареєстровані фактори, де зберігаються коди відновлення, хто може незалежно перевірити заявника і до яких систем доходить запис. Тримайте його в захищеному інвентарі, який команда вже використовує, ніколи в нотатці, де також є дійсні коди. Ці п'ять полів перетворюють панічний дзвінок на контрольний список, а настанова NIST щодо життєвого циклу автентифікатора розглядає відновлення як частину облікових даних, а не виняток із них.

Записуйте канал перевірки окремим полем, бо саме цю частину люди пропускають. Номер телефону, прив'язаний до запису, не є незалежним каналом, коли прохач сам контролює телефон.

Крок 2: перевірте заявника поза шляхом, що відмовив

Проводьте перевірку особи через канал, який не залежить від VPN, поштової скриньки або втраченого пристрою. Зворотний дзвінок на номер із кадрового запису або особиста перевірка в керівника, який уже є в каталозі, працюють обидва; повідомлення в чаті, надіслане з відновлюваного запису, не працює. Перевірка стосується людини, а не її здатності відповідати на питання про запис, бо деталі запису витікають. Записуйте, хто і коли перевірив запит, оскільки наступному рецензенту знадобиться і те, і інше.

Коли запит приходить із терміновістю й тиском пропустити перевірку, саме тоді й треба сповільнитися. Шахрайство з відновленням виглядає точно як поспішний колега, що допомагає.

Крок 3: зареєструйте заміну, потім відкличте старий фактор

Реєструйте новий автентифікатор через звичайний потік реєстрації, ніколи через адміністративний обхід. Потім явно видаліть втрачений метод, бо реєстрація заміни залишає попередній автентифікатор авторизованим, доки хтось його не відкличе. Якщо старий пристрій може бути в чужих руках, вважайте видалення терміновим і дотримуйтеся процесу інциденту, а не відновлення. Відкличте наявні сеанси в тому самому проході, оскільки сеанс, створений до зміни, може її пережити:

Revoke-MgUserSignInSession -UserId [email protected]

Видалення фактора для всіх інших або послаблення перевірок сертифікатів шлюзу обмінює відновлення однієї людини на збій, що зачіпає все розгортання. Тримайте зміну в межах одного запису й ескалюйте, якщо докази вказують на ширшу компрометацію. Позначте в тікеті, який фактор відкликано і який його замінив.

Крок 4: доведіть, що запис працює в обидва боки

Увійдіть один раз із новим фактором через підтримуваний клієнт, потім підтвердіть, що запис досі досягає ресурсів, яких досягав до втрати. Перевірте один ресурс, якому потрібен тунель, і один, якому не потрібен, щоб збій указував на правильний шар. Спробуйте вхід з відкликаним фактором і очікуйте відмову, а не запит, що доводить, що видалення спрацювало. Виклик, який не проходить із наявного зареєстрованого пристрою — це проблема запиту, а не привід реєструвати все заново.

Потім попросіть користувача виконати той самий вхід без підказок. Ваш успішний тест доводить конфігурацію; його спроба доводить передачу.

Закрийте тікет із позначкою часу успішного входу та іменем фактора, який зараз використовується. Оновіть журнал відновлення в тому самому проході, щоб наступна втрата починалася з точного інвентаря, а не застарілого.

Крок 5: усуньте умову, яка зробила це болісним

Кожен дзвінок про відновлення — доказ про проєктування реєстрації. Якщо в записі був рівно один фактор, вимагайте другий для всіх у цій групі. Якщо коди відновлення лежали на загубленому ноутбуці, змініть, де вони зберігаються. Якщо перевірка потребувала керівника у відпустці, призначте заступника. Кожне виправлення займає пів дня і прибирає найгіршу годину наступного інциденту.

Потім перечитайте запис із першого кроку проти реальності. Чи перелічує він фактори, які справді існують, і чи канал перевірки досі доходить до людини? Інструкція, яку ніхто не оновлює, перетворюється на документ, який люди ігнорують під час дзвінка, для якого його написано.