Проводите аудит всего пути аутентификации, а не одного экрана входа
Надежный на вид экран входа не описывает весь механизм аутентификации. Доступ к учетной записи также зависит от того, как регистрируется фактор, как сервис проверяет обычный вход, когда он запрашивает повторное подтверждение перед внесением конфиденциальных изменений, как долго длятся сессии, как работает восстановление и как заменяется утерянный фактор. Постройте карту пути аутентификации с семью столбцами: регистрация, обычный вход, дополнительная проверка, повторная проверка конфиденциального действия, управление сессиями, восстановление, а также вывод из эксплуатации или замена. Для каждого столбца зафиксируйте аутентификатор, проверяющую сторону, канал передачи запроса, отображение для пользователя, существующий резервный вариант (fallback) и наблюдаемый результат, подтверждающий завершение. Это позволяет отделить аутентификацию учетной записи от локальной разблокировки телефона и выявляет случаи, когда удобный метод незаметно откатывается к менее безопасному пути.
Укажите каждую роль, фактор и точку входа
Начните с идентификатора учетной записи, службы учетных данных или провайдера удостоверений, верификатора, приложения-компаньона, зарегистрированных аутентификаторов, контактов для восстановления, доверенных устройств и активных сессий. Модель цифровой идентификации NIST рассматривает подтверждение личности, аутентификаторы, верификаторы, федерацию и сессии как связанные, но различные функции. Пароль — это знание; зарегистрированное устройство или криптографический ключ — владение; отпечаток пальца может активировать аутентификатор на устройстве, сам по себе не становясь удаленными учетными данными учетной записи. Зафиксируйте то, что текущий продукт действительно предлагает, вместо того чтобы присваивать метку безопасности на основе его значка. Включите вход через веб-интерфейс, мобильное приложение, вход через сторонние сервисы, сброс пароля, одобрение устройства и восстановление с помощью службы поддержки. Неизвестные пути остаются неизвестными до тех пор, пока на них не ответит актуальная официальная документация или контролируемый тест.
Сравните обычный вход с проверками конфиденциальных действий
Перечислите действия, изменяющие контроль над учетной записью: добавление или удаление аутентификатора, изменение адреса электронной почты для восстановления, экспорт данных, отключение дополнительной проверки, привязка внешней учетной записи, просмотр кодов восстановления, удаление учетной записи или завершение всех сессий. Проверьте, запрашивает ли приложение повторную аутентификацию перед каждым поддерживаемым действием и какой фактор оно принимает. Руководство OWASP по аутентификации рассматривает повторную аутентификацию для конфиденциальных изменений, восстановление и обработку сессий как отдельные механизмы контроля. Телефон, разблокированный пять минут назад, не является доказательством того, что изменение контроля над учетной записью было проверено заново. Используйте безопасные настройки и собственную учетную запись; не провоцируйте многократно восстановление или блокировку. Зафиксируйте точный запрос, назначение, использованный фактор, поведение при отмене и то, произошли ли какие-либо видимые изменения в других сессиях.
Изучите свойства аутентификаторов, не сводя их к рейтингу
Для каждого предлагаемого метода отметьте предварительные условия регистрации, привязку к устройству, синхронизацию, резервное копирование, устойчивость к фишингу, верификацию пользователя, замену и отзыв. NIST поясняет, что пароли не устойчивы к фишингу, а вводимые вручную одноразовые коды не считаются устойчивыми к фишингу, поскольку поддельный верификатор может их ретранслировать. Некоторые криптографические аутентификаторы привязывают результат к имени верификатора или защищенному каналу. Это не делает один метод универсальным решением: доступность, поддерживаемые устройства, восстановление и границы использования общих устройств по-прежнему имеют значение. CISA рекомендует использовать MFA везде, где это возможно, но два запроса полезны только тогда, когда они действительно независимы, а резервный сценарий не представляет собой необъяснимый обход защиты. Зафиксируйте задокументированное свойство метода, а не маркетинговые эпитеты, такие как «продвинутый» или «безопасный».
Отслеживайте сессии и восстановление как отдельные конечные автоматы
После успешной аутентификации сессия может оставаться действительной до истечения срока действия, выхода из системы, события риска или отзыва на стороне сервера. Восстановление может включать настройку нового аутентификатора, сброс пароля, восстановление федеративного входа или обращение в службу поддержки. Опишите обе последовательности шаг за шагом. Проверьте, влияет ли выход на одном устройстве на другое, закрывает ли смена фактора старые сессии и различает ли список сессий профили браузера и физические устройства. Затем проверьте предварительные условия восстановления и уведомления, не выполняя ненужных сбросов. Почтовый ящик для восстановления, доступ к которому утрачен, телефонный номер, который вскоре будет аннулирован, или резервный код, сохраненный в обычных заметках, могут свести на нет в остальном надежный путь входа. Никогда не вносите в отчет аудита учетные данные, временные коды, ссылки для восстановления или точные ответы на секретные вопросы.
Проведите три теста с ограниченными переходами
Во-первых, выполните обычный вход на контролируемом вами устройстве и зафиксируйте фактор, источник запроса, полученную сессию и видимый идентификатор учетной записи. Во-вторых, откройте безопасную конфиденциальную настройку, отмените действие в окне повторной проверки и убедитесь, что настройка и сессии остались без изменений. В-третьих, добавьте или замените второстепенный аутентификатор, только если сервис документирует обратимый процесс; проверьте его один раз, затем удалите тестовый фактор и убедитесь, что он больше не работает. Если замена не является безопасно обратимой, ограничьтесь анализом вместо выполнения. Зафиксируйте версию приложения, устройство, временную метку, ожидаемое состояние, наблюдаемое состояние и нерешенные вопросы. Успешно пройденный тест распространяется только на этот путь и версию; он не гарантирует скрытое поведение сервера.
Принимайте решения на основе самого слабого перехода, а не самого привлекательного скриншота
Охарактеризуйте каждый путь как запланированный, наблюдаемый, недоступный или неизвестный. Безупречно выглядящий запрос ключа доступа (passkey) не компенсирует процедуру восстановления, которая принимает старый почтовый ящик без повторной проверки. Наличие MFA при обычном входе не дает ответа на вопрос, требует ли удаление фактора повторной проверки. Полный чек-лист должен содержать как минимум один поддерживаемый маршрут восстановления, способ просмотра или закрытия сессий, четкие уведомления об изменениях контроля учетной записи и задокументированный метод вывода из эксплуатации утерянных аутентификаторов. Если критический путь неизвестен, избегайте размещения особо конфиденциальных данных в учетной записи, пока не обратитесь за актуальной официальной поддержкой. Возвращайтесь к карте после смены основного устройства, контакта для восстановления, провайдера удостоверений, типа аутентификатора или версии приложения, а не по графику, который лишь создает видимость активности без новых данных.
Частые вопросы
Является ли блокировка приложения тем же самым, что и аутентификация учетной записи?
Нет. Локальная блокировка может ограничивать доступ к одному устройству, в то время как удаленные сессии учетной записи и восстановление подчиняются отдельным механизмам контроля.
Делает ли MFA любое изменение учетной записи автоматически более безопасным?
Не автоматически. Проверьте, какие факторы защищают обычный вход, восстановление, удаление факторов и внесение конфиденциальных изменений.
Следует ли многократно тестировать восстановление учетной записи?
Нет. Изучите предварительные условия и выполняйте только ограниченное, задокументированное тестирование, если сервис предоставляет безопасный обратимый маршрут.