Запрос MFA к VPN отклонён: что должен сделать клиент

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

Проверьте, какой запрос завершился неудачей

Начните с определения того, какой запрос завершился неудачей. Push-уведомление, код TOTP, утверждение FIDO и поток SAML отказывают каждый по-своему, и клиент обычно знает, что именно запрашивал. Отказ, истёкший вызов и сбой доставки, так и не дошедший до устройства, заканчиваются одной и той же общей ошибкой, поэтому разница часто сохраняется только в состоянии самого клиента.

Это состояние стоит записывать точно. Зафиксируйте идентификатор вызова или ссылку на транзакцию, тип фактора, отметку времени и результат, но никогда — код или утверждение. Идентификатор вызова позволяет администратору найти событие на стороне поставщика удостоверений; без него разговор с поддержкой начинается со слов «где-то за последний час» и обычно там же заканчивается. Относитесь к нему как к диагностическим метаданным, а не как к секрету.

Повторите один раз, осознанно, с новым вызовом

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

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

Чего клиент не должен делать

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

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

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

Что записать для поддержки

Для поддержки полезная запись невелика. Приблизительное время с часовым поясом, учётная запись, клиент и версия, тип фактора и несекретный статус каждой попытки: запрошено, отклонено, истекло, одобрено, но отклонено политикой.

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

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

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