Потерянный аутентификатор VPN: замена без отключения MFA

Кто-то теряет телефон, и тикет приходит как «VPN сломан». Такая формулировка неверна дважды: учётная запись всё ещё существует, а шлюз по-прежнему доверяет поставщику удостоверений, поэтому единственная сломанная часть — один фактор, которого у человека больше нет. Относитесь к этому как к восстановлению, а не как к сбою: проверьте заявителя, зарегистрируйте замену, отзовите потерянный метод и затем докажите, что учётная запись работает. Всё это предполагает, что план был написан до потери, потому что придумывать его во время звонка — это путь, которым MFA в итоге отключают всем.

Шаг 1: читайте зарегистрированные факторы из записи, а не из памяти

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

Get-MgUserAuthenticationMethod -UserId [email protected]

Затем запишите журнал восстановления, пока учётная запись ещё работает: идентификатор записи, зарегистрированные факторы, где хранятся коды восстановления, кто может независимо проверить заявителя и до каких систем доходит запись. Храните его в защищённом инвентаре, который команда уже использует, никогда в заметке, где также находятся действующие коды. Эти пять полей превращают панический звонок в контрольный список, а руководство NIST по жизненному циклу аутентификатора рассматривает восстановление как часть учётных данных, а не исключение из них.

Записывайте канал проверки отдельным полем, потому что именно эту часть люди пропускают. Номер телефона, привязанный к записи, не является независимым каналом, когда просящий сам контролирует телефон.

Шаг 2: проверьте заявителя в обход отказавшего пути

Проводите проверку личности через канал, который не зависит от VPN, почтового ящика или потерянного устройства. Обратный звонок на номер из кадровой записи или личная проверка у руководителя, который уже есть в каталоге, работают оба; сообщение в чате, отправленное из восстанавливаемой записи, не работает. Проверка касается человека, а не его способности отвечать на вопросы об учётной записи, потому что детали записи утекают. Записывайте, кто и когда проверил запрос, поскольку следующему проверяющему понадобится и то, и другое.

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

Шаг 3: зарегистрируйте замену, затем отзовите старый фактор

Регистрируйте новый аутентификатор через обычный поток регистрации, никогда через административный обход. Затем явно удалите потерянный метод, потому что регистрация замены оставляет предыдущий аутентификатор авторизованным, пока кто-то его не отзовёт. Если старое устройство может быть в чужих руках, считайте удаление срочным и следуйте процессу инцидента, а не восстановления. Отзовите существующие сеансы в том же проходе, поскольку сеанс, созданный до изменения, может его пережить:

Revoke-MgUserSignInSession -UserId [email protected]

Удаление фактора у всех остальных или ослабление проверок сертификатов шлюза меняет восстановление одного человека на сбой, затрагивающий всё развёртывание. Держите изменение в рамках одной записи и эскалируйте, если доказательства указывают на более широкую компрометацию. Отметьте в тикете, какой фактор отозван и какой его заменил.

Шаг 4: докажите, что учётная запись работает в обе стороны

Войдите один раз с новым фактором через поддерживаемый клиент, затем подтвердите, что запись по-прежнему достигает ресурсов, которых достигала до потери. Проверьте один ресурс, которому нужен туннель, и один, которому не нужен, чтобы сбой указывал на правильный уровень. Попробуйте вход с отозванным фактором и ожидайте отказа, а не запроса, что доказывает, что удаление сработало. Вызов, который не проходит с существующего зарегистрированного устройства — это проблема запроса, а не повод регистрировать всё заново.

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

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

Шаг 5: устраните условие, которое сделало это болезненным

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

Затем перечитайте запись из первого шага против реальности. Перечисляет ли она факторы, которые действительно существуют, и доходит ли канал проверки до человека? Инструкция, которую никто не обновляет, превращается в документ, который люди игнорируют во время звонка, для которого она была написана.