Журнал "Information Security/ Информационная безопасность" #2, 2026

l сервисные учетные записи без строгой аутентификации; l долгоживущие сессии, которые можно использовать после компрометации; l разрозненная система управления доступом. Да, организация формаль- но внедряет современную MFA, к ней вопросов нет, но при этом сохраняются аль- тернативные пути входа, кото- рые могут использовать зло- умышленники при атаке. Устойчивость к фишингу на примере MULTIFACTOR Большинство конкретных корпоративных решений MFA развиваются эволюционно: от простых одноразовых кодов к более сложным сценариям, включающим контроль кон- текста доступа и привязку факторов к устройству. Реше- ние MULTIFACTOR 1 в этом смысле пред- ставляет собой типичный и показатель- ный пример такой архитектуры. Система выстраивается как отдельный слой аутентификации, встроенный в инфраструктуру заказчика. При этом проверка логина и пароля остается на стороне целевой системы (например, 1С, VPN или корпоративного портала), а второй фактор обрабатывается через внешний сервис. Такой подход позволяет не вмешиваться в логику приложений, добавлять защиту поверх существующих механизмов, и при этом эффективно бороться с AiTM-атаками на аутентифи- кацию. Мобильное приложение MULTI- FACTOR использует подтверждение запросов входа на привязанном устрой- стве, а также механизмы ограничения повторяющихся запросов аутентифика- ции. Это позволяет снижать эффектив- ность атак, основанных на массовой отправке пуш-запросов пользователю. Ключевой элемент MULTIFACTOR – взаимодействие через API. После успеш- ной проверки учетных данных защи- щаемая система инициирует запрос ко второму фактору, используя служебные параметры (API Key и секрет). Эти дан- ные привязаны к конкретной организа- ции и не доступны извне. Соответствен- но, злоумышленник не может корректно инициировать проверку второго фактора без доступа к внутренней инфраструк- туре, даже если ему удалось воспроиз- вести интерфейс входа. Подобный под- ход существенно усложняет реализацию AiTM-атак и снижает эффективность типовых фишинговых фреймворков. С точки зрения пользователя процесс выглядит стандартно: после ввода логи- на и пароля требуется подтвердить вход. А за этой простотой скрывается разде- ление потоков аутентификации – пароль проверяется в инфраструктуре заказчи- ка, а второй фактор проходит через отдельный контур. Важная особенность реализации – поддержка различных каналов второго фактора. В зависимости от сценария это могут быть мобильное приложение, пуш-подтверждение, Telegram, eXpress, звонок или СМС. При этом более устой- чивыми к фишингу считаются методы, в которых подтверждение происходит на привязанном устройстве пользователя, а не через передаваемый код. Интегра- ция с корпоративными системами реа- лизуется через адаптеры и плагины. Например, для 1С используется отдель- ный модуль, который встраивается в процесс аутентификации и добавляет шаг подтверждения второго фактора. Аналогичным образом решение может быть подключено к RDP, VPN и другим сервисам, включая те, которые изна- чально не поддерживают MFA. С архитектурной точки зрения система построена по гибридной модели. Облач- ная часть отвечает за обработку запро- сов и управление политиками, а компо- ненты на стороне заказчика обеспечи- вают интеграцию с конкретными систе- мами. Это позволяет централизованно обновлять механизмы защиты и быстрее реагировать на новые сценарии атак. При этом важно понимать, что устой- чивость к фишингу в таких решениях достигается не одним механизмом, а их комбинацией. Помимо собственно вто- рого фактора используются дополни- тельные меры – контроль IP-адресов, белые и черные списки, ограничения по времени доступа, а также базовые анти- фрод-правила. Они не устраняют полностью сце- нарии проксирующего фишинга, но позволяют выявлять аномалии и снижать веро- ятность успешной атаки. Заключение Для специалистов по безопасности вопрос применения MFA уже постепенно выходит за рамки выбора конкретного фактора. Речь идет о более широком изменении архитектуры аутентифика- ции. Phishing-Resistant MFA фактически переводит процесс проверки пользова- теля из модели передачи секретов в модель криптографического подтвер- ждения. Пользователь больше не сообщает системе код или пароль. Его устройство подтверждает владение клю- чом, привязанным к конкретному серви- су. Такой подход значительно усложняет атаки, основанные на фишинге и про- ксировании аутентификации. Даже если пользователь взаимодействует с под- дельным интерфейсом, злоумышленник не может получить пригодный для использования фактор. Разумеется, внедрение подобной архи- тектуры требует пересмотра существую- щих процессов доступа и интеграции с корпоративной инфраструктурой. Имен- но в этом направлении, судя по всему, будет развиваться корпоративная аутен- тификация в ближайшие годы. Система MULTIFACTOR демонстрирует характерный для рынка подход: переход от простого второго шага к более слож- ной архитектуре аутентификации, где безопасность определяется не столько типом фактора, сколько контекстом его использования и способом интеграции в инфраструктуру. l • 47 ЗАЩИТА ИНФРАСТРУКТУРЫ НА БАЗЕ РОССИЙСКИХ ОС www.itsec.ru Рис. Высокоуровневая схема работы MULTIFACTOR АДРЕСА И ТЕЛЕФОНЫ МУЛЬТИФАКТОР см. стр. 78 NM Реклама 1 https://multifactor.ru/multifactor/