Практики внедрения MFA: как не сделать хуже

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

Ниже — практики, которые отделяют работающий механизм от галочки в отчёте.

1. Начинайте с администраторов, но не останавливайтесь на них

Учётные записи с расширенными правами защищают в первую очередь — это очевидно.

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

Поэтому MFA для избранных отделов оставляет открытым тот самый путь, ради закрытия которого всё затевалось. Администраторы — первый этап, а не единственный.

2. Выбирайте методы, устойчивые к фишингу

Разные способы подтверждения защищают по-разному, и разница принципиальна.

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

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

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

3. Откажитесь от SMS там, где это возможно

Коды по SMS лучше, чем отсутствие второго фактора, но это самый слабый вариант: перевыпуск SIM-карты и перехват сообщений — известные и работающие приёмы.

Для массовых пользователей SMS приемлем как переходная мера. Для административного доступа — нет.

4. Учитывайте контекст

Требовать подтверждение при каждом действии — верный способ приучить людей подтверждать всё автоматически, не глядя. Именно на этом строятся атаки с изматыванием запросами.

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

5. Продумайте восстановление до внедрения

Самая недооценённая часть. Если сброс второго фактора выполняется по ответу на пару простых вопросов, вся схема обесценивается: злоумышленник пойдёт именно этим путём.

Что нужно предусмотреть заранее:

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

Потерянный телефон — рутинная ситуация, а не исключительная. Она случится в первую же неделю.

6. Сочетайте с единым входом

Второй фактор, запрашиваемый в каждом приложении отдельно, воспринимается как помеха и порождает поиск обходных путей.

Связка «единый вход + MFA» решает это: пользователь подтверждает личность один раз в начале сессии, а дальше работает без повторных запросов. Проверка происходит там, где она действительно нужна, и не мешает в остальное время.

7. Наблюдайте за происходящим

Внедрение — не конец, а начало эксплуатации. Смотреть стоит на:

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

8. Объясните пользователям смысл

Техническая часть внедрения обычно проще организационной.

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

Без этого объяснения атака изматыванием срабатывает: человек подтверждает десятый подряд запрос просто чтобы тот перестал приходить.

Как это устроено в Keydee

• TOTP и passkeys доступны как факторы; passkeys предпочтительны из-за устойчивости к фишингу.
• Требование MFA включается политикой компании и действует во всех её приложениях сразу.
• Фактор привязан к сессии: подтвердив личность, пользователь не проходит проверку повторно в рамках сессии.
• Завершение сессии возвращает требование подтверждения при следующем входе.
• Резервные коды выдаются при подключении фактора.
• Администратор может отозвать фактор сотрудника — например, при утере устройства.
• События фиксируются в журнале с реальным IP-адресом.

Короткий чек-лист

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