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

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

В этой статье я расскажу, как нам пришлось внезапно переезжать с DUO Security, которое многие из вас знают, на российское решение Мультифактор. Возможно, вам будет интересен наш опыт переезда или работы с этим решением (лучше поздно, чем никогда).

С чего все началось

С начала исхода иностранных вендоров из России в феврале 2022 года мы прекрасно понимали, что рано или поздно нам придется заменять часть решений в нашей инфраструктуре. В первую очередь мы искали альтернативы тем решениям, работу которых может саботировать вендор, и DUO Security с его облаком для администрирования, обработки запросов пользователей и отправки второго фактора был один из первых кандидатов на импортозамещение. Но большинство вендоров заранее предупреждали о планах ухода из России и давали время на переход с их решения, поэтому мы в спокойном режиме рассматривали альтернативы. Когда мы получили уведомление от DUO о том, что с мая они начнут блокировать IP адреса спорных территорий, мы были уже в самом разгаре пилота Мультифактора, и большая часть его функционала нас устраивала.

Вечером 20-го мая (а это была пятница) мы как всегда ушли на выходные, ничто не предвещало беды. Но тут нам стали приходить сообщения от дежурных администраторов, что второй фактор не работает в штатном режиме. Для нашей инфраструктуры это не было большой проблемой, потому что срабатывала настройка failmode=safe, которая позволяла пройти аутентификацию при недоступности API, но требовало нашего вмешательства для выявления причин нештатного поведения системы.

Когда мы начали выяснять причины недоступности облака DUO, то поняли, что адрес нашей админки просто не резолвится. DUO поменяли IP админки на 0.0.0.0, по сути в один момент лишив нас информации для переезда на другое решение, без предупреждения. Привычка делать бэкапы всего и вся спасла нас от необходимости внедрять второй фактор с чистого листа - копии конфигов, сохраненные в админке, у нас остались.

В итоге мы остались без второго фактора, а кроме прочего, оказалось, что failmode некорректно отрабатывал на серверах Windows, и нам пришлось экстренно удалять ключ реестра, отвечающий за использование прокси в параметрах DUO. Было решено начать экстренный переезд, и переводить тестовые серверы Мультифактора в прод.

Немного об архитектуре второго фактора в энтерпрайз

Лирическое отступление для тех, кто не знаком с архитектурой решений наподобие DUO / Мультифактора. Локально в инфраструктуре устанавливаются серверы, на которых настраиваются адаптеры. Адаптеры по сути являются прокси между системой, которая запрашивает аутентификацию (конечная точка), и системой, которая эту аутентификацию осуществляет (в нашем случае - контроллер домена). Система, в которой пользователь вводит логин и пароль, отправляет эти данные на 2FA-адаптер. Адаптер запрашивает инфу у контроллера, и получает результат - success или fail. В случае успешной аутентификации на DC 2FA-адаптер отправляет запрос на управляющий сервер 2FA-решения с "просьбой" спросить у пользователя второй фактор. Пользователь прожимает пуш / вводит пароль с токена/присланный по смс код доступа, после проверки которого получает доступ в систему.

Готовь сани летом

В рамках пилота мы уже установили, сконфигурировали под нашу инфраструктуру и протестировали LDAP и RADIUS адаптеры для VPN, Windows, DB, Tacacs+, web-ресурсы, системы с LDAP-аутентификацией.

Это помогло нам достаточно оперативно вернуться в рабочее русло, и уже в течение недели с небольшим 2FA вернулся в нашу инфраструктуру.

 Что мы для этого делали:

1. Готовили все системы инфраструктуры, которые можно было переключить сразу к переезду на Мультифактор

2. Меняли конфиги, тестировали, проверяли, разливали

3. В симбиозе с отделом поддержки пользователей оповещали пользователей, готовили инструкции, распространяли информацию о том, что теперь нужно будет установить новое приложение, и нажимать новые кнопочки, чтобы подключиться «к этому вашему VPN».

4. Получали обратную связь от пользователей, переписывали инструкции, перенастраивали адаптеры.

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

Где-то нам пришлось переделывать порядок и подход к аутентификации, как в Linux, где-то достаточно было поменять адрес наших серверов DUO на серверы Мультифактора. На тот момент Мультифактор был еще очень молодым решением, и нам пришлось понаступать на грабли и плотно поработать с вендором для доработки нужного нам функционала.

Грабли, трудности, подводные камни

Yubikey

Так сложилось (и мы к этому привыкли), что для прохождения второго фактора многие пользователи использовали Yubikey. Это было особенно удобно для шареных учетных записей, так как для одной учетки обычно можно привязать только одно приложение или телефон, а вот юбиков можно добавить несколько. На стороне вендора поддержки юбиков не было, но разработчики Мультифактора вошли в наше положение, и уже буквально через пару недель мы смогли реализовать поддержку токенов через API.

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

Затем мы вошли во вкус и нам понадобился функционал клонирования Yubikey пользователя к сервисным учетным записям, чтобы подключать второй фактор и им. Более детально это выглядит как возможность использования юбика сотрудника для входа под сервисной учеткой, зная доменный пароль от этой самой сервисной УЗ, все же это гораздо безопаснее, чем 1FA. На этом история с Yubikey подошла к финалу - мы наконец смогли использовать юбики как раньше.

Логины

Во многих организациях шаблон именования пользователей в LDAP выглядит примерно как n.surname. При этом некоторые системы, такие как Oracle, не допускают точку в логине. Исторически сложилось, что мы в таком случае заменяли точку нижним подчеркиванием - N_SURNAME. В DUO, который был написан на питоне, мы в исходниках добавили replace и не забыли о проблеме - дальше все работало, как задумано:

request.username = request.username.replace("SPARK_", "").replace("",".", 1).replace("", "-")

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

Linux и PAM

Для внедрения 2FA на сервера Linux нам был необходим PAM-модуль, написанный именно под нас, так как у нас имелись свои требования на этот счет. Как мы решали данную проблему с DUO, вы можете прочесть в этой статье.

Желаемая логика конфигурации 2fa для SSH в Linux:

Типы разрешенных auth (AuthenticationMethods в sshd_config):

• publickey — использование ssh pub key не должно требовать 2FA

• kerberos — использование kerberos должно требовать 2FA

• password — должно требовать 2FA.

Разделение на локальных и доменных пользователей:

• Логин под локальными пользователями (перечисленными в /etc/passwd) не должен требовать 2FA

• Логин под доменными пользователями должен требовать 2FA.

Данную конфигурацию частично получается настроить с помощью перечисления стадий auth в AuthenticationMethods, например:

AuthenticationMethods publickey gssapi-with-mic,keyboard-interactive password,keyboard-interactive

Но возникают проблемы, когда мы начинаем смешивать методы auth, обрабатываемые через pam (password), и непосредственно в sshd (gssapi,publickey)— и первая, и вторая стадии auth будут обрабатываться одним стеком PAM.

Если вкратце:

• нужен pam-модуль

• pam-модуль должен уметь понимать, на каком этапе он вызван (password или keyboard-interactive), и в зависимости от этого менять поведение.

• pam-модуль должен должен уметь понимать, какой программой он вызван (sshd, login), и в зависимости от этого менять поведение.

В конце сентября 2022 мы получили готовый модуль, который после тестов внедрили в контур. При работе с некоторыми базами данных возникает проблема — софт инициирует не один запрос, а вплоть до шести и более. Когда мы работали с DUO, то починили это, добавив cache_key и проблемы с нескончаемыми пушами были решены. А вот момент внедрения Мультифактора в контур таких решений на стороне вендора ещё не было. Запрошенную доработку нам сделали в разумные сроки. Многие пользователи облегчённо выдохнули и порадовались такому неожиданному подарку под Новый год :)

Мультифактор VS DUO Mobile

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

Плюсы Мультифактора

• Это российский вендор, нет геополитических рисков (вашу админку не удалят без предупреждения)

• Возможность использовать свои шлюзы СМС и Телефонии

• Общение с поддержкой онлайн 24/7. До DUO было сложнее достучаться, работали они медленнее, а ответов вида «У меня всё такое же, но работает» было достаточно.

• Возможность запроса доработок. Очень полезная опция.

• Работает быстрее, чем DUO, сказывается как удаленность сервисов, так и язык, на котором написаны адаптеры (Python vs C#)

• Из важного — Мультифактор поддерживает собственные шлюзы для телефонии. Благодаря этому мы смогли полноценно использовать свои шлюзы для прохождения второго фактора — теперь SMS (или звонок) пользователям поступает именно от QIWI, чисто психологически это повышает уровень доверия. Да и красиво :) У других вендоров я поддержки своих шлюзов не нашел.

Минусы

• Нет возможности доступа в API с ограниченным доступом к ресурсам/пользователям/отчетам.

• Некоторые недоработки в GUI облака. Например, внутри облака у нас пара сотен конфигов, и по ним нет возможности нормального поиска — есть только скролл. Причем на первый скролл выводится лишь 50 конфигов, потом надо кликать, чтобы подгрузить ещё 50. Возможно, ребята просто не предполагали, что у компаний типа нашей может быть такое количество конфигов.

А если вы тоже переходили с какого-то привычного 2FA/MFA-решения на менее привычное, расскажите, пожалуйста, в комментариях — что на что сменили и как впечатления.