Единая MFA для корпоративных систем: как внедрить один раз, а не настраивать каждую отдельно
Многофакторная аутентификация (MFA) используется во многих организациях как дополнительный способ защиты учётных записей. В современных информационных системах (ИС) поддержка второго фактора часто предусмотрена разработчиком, однако администратору всё равно приходится разбираться с настройками каждой системы. При большом количестве ИС такая работа занимает значительное время, особенно если в организации установлены единые требования к аутентификации.
Проблема заключается не только в отсутствии MFA в старых приложениях. Одни системы позволяют подключить сторонний TOTP-сервис, другие рассчитаны на собственный механизм подтверждения, а для некоторых требуется отдельный шлюз. В результате приходится сопровождать несколько вариантов одной и той же процедуры аутентификации.
Для объединения этих механизмов можно использовать централизованный сервис аутентификации (IdP), например Keycloak, Authelia или «Цифровой КУПОЛ». В зависимости от возможностей решения в одном месте настраиваются политики MFA и подключение к сервисам подтверждения через push, SMPP или SMTP. Далее рассмотрим, как организовать такую схему для ИС с разными протоколами аутентификации.
Почему MFA неудобно настраивать отдельно в каждой ИС
При раздельном внедрении MFA часть работы повторяется для каждого приложения. Администратору необходимо настроить подключение к сервису подтверждения, определить требования к пользователям и обеспечить сопровождение выбранного способа аутентификации.
Политики MFA в разных ИС могут отличаться. Например, в одной системе второй фактор обязателен для всех сотрудников, а в другой включается пользователем самостоятельно. Поддерживать единые требования при такой схеме сложнее.
Пользователю также приходится регистрировать дополнительные факторы в нескольких приложениях. Это особенно заметно при использовании TOTP: для разных ИС создаются отдельные записи, хотя сотрудник использует одно и то же устройство.
При замене телефона или увольнении сотрудника администратору необходимо проверить привязки факторов в каждой ИС. Централизация позволяет выполнять основную часть этих действий через один сервис.
Журналы подтверждения входа при раздельной настройке остаются в разных системах. При использовании центрального сервиса события MFA можно собирать в одном месте и передавать в SIEM.
Для старых ИС, в которых нет собственной поддержки MFA, можно использовать промежуточные компоненты, если это допускает способ аутентификации приложения.
Чем больше систем использует отдельные механизмы MFA, тем больше времени требуется на их настройку и сопровождение. Именно эту задачу решает централизованный подход.
Как работает централизованная MFA
При централизованной MFA проверка дополнительного фактора выполняется на стороне IdP или связанного с ним MFA-сервера. Информационная система получает результат аутентификации через поддерживаемый протокол. Регистрация факторов и правила их применения при этом сосредоточены в центральном решении, а не повторяются в каждом приложении.
В такой схеме каталог пользователей — Active Directory, FreeIPA или OpenLDAP — хранит учётные записи, группы и необходимые атрибуты. IdP и MFA-сервер участвуют в проверке учётных данных, запросе второго фактора и применении настроенных политик.
Для подключения ИС используются OIDC, SAML, RADIUS, LDAP-прокси или обратный прокси — в зависимости от возможностей системы.
Способ подключения выбирается исходя из того, как конкретная ИС проверяет учётные данные. Во многих случаях можно обойтись без изменения кода приложения: достаточно настроить поддерживаемый протокол или установить промежуточный компонент.
Какие способы подключения можно использовать
Наиболее удобный вариант — интеграция по OIDC или SAML. Для систем, в которых эти протоколы отсутствуют, можно использовать RADIUS, LDAP-прокси или обратный прокси. При этом необходимо учитывать, какие действия выполняет само приложение, а какие передаются центральному сервису.
Пример подключения корпоративных ИС
Предположим, что в организации уже развёрнут IdP по адресу idp.company.com. Помимо приложений с OIDC, требуется подключить к MFA следующие системы:
- VPN-шлюз, в котором предусмотрена аутентификация по RADIUS;
- систему заявок, использующую LDAP bind для проверки пароля;
- внутреннее веб-приложение, не поддерживающее SSO.
Подключение по OIDC и SAML
Для приложений с поддержкой OIDC или SAML дополнительная проверка включается в процесс аутентификации на стороне IdP. Например, пользователь открывает GitLab, перенаправляется на страницу входа IdP, вводит учётные данные и подтверждает вход вторым фактором. После этого GitLab получает токен или утверждение об успешной аутентификации. Если приложению необходимо знать, каким способом пользователь подтвердил вход, в OIDC могут использоваться claims amr и acr. Для запроса определённого уровня аутентификации предусмотрен параметр acr_values, если такой сценарий поддерживают IdP и приложение.
При подключении необходимо проверить, доступен ли в ИС локальный вход помимо IdP. Если он остаётся включённым, требования MFA могут не распространяться на этот способ аутентификации. Для аварийных учётных записей порядок доступа определяется отдельно.
Подключение по RADIUS
Для VPN-шлюзов и сетевого оборудования с поддержкой RADIUS можно использовать MFA-сервер с соответствующим интерфейсом или отдельный RADIUS-адаптер. После проверки пароля сервер запрашивает подтверждение входа и возвращает оборудованию результат аутентификации.
Вариант подтверждения зависит от возможностей RADIUS-клиента. При использовании push пользователь получает уведомление в приложении и подтверждает вход, пока клиент ожидает ответ. Если оборудование поддерживает Access-Challenge, оно может запросить одноразовый код отдельным сообщением.
В отдельных сценариях, когда клиент не поддерживает дополнительный запрос, пароль и код вводятся в одно поле. Совместимость такого формата необходимо проверить при настройке.
Аналогичная схема может использоваться для RDP-доступа через RD Gateway при наличии поддерживаемой интеграции с RADIUS.
Подключение через LDAP-прокси
Если приложение умеет проверять пароль только через LDAP bind, между ним и каталогом можно разместить LDAP-прокси. Он принимает запрос приложения, выполняет предусмотренную проверку учётных данных и при поддержке такого сценария обращается к MFA-серверу. Например, после проверки пароля пользователю направляется push-запрос, а приложение получает успешный ответ только после подтверждения.
Для такой интеграции важно правильно настроить время ожидания LDAP-ответа и отдельно определить порядок обработки сервисных учётных записей, которые приложение использует для чтения каталога.
Подключение через обратный прокси
Если веб-приложение не поддерживает SSO, перед ним можно установить обратный прокси с OIDC-аутентификацией. Для этого применяются, например, oauth2-proxy, Pomerium, Authelia или соответствующие механизмы Nginx и Traefik. Прокси направляет пользователя на IdP и после успешной проверки передаёт запрос приложению.
При такой схеме прямой доступ к приложению должен быть закрыт: иначе пользователь сможет обратиться к нему, минуя прокси. Заголовки с данными аутентификации приложение должно принимать только от доверенного компонента.
Сопоставление вариантов интеграции
Для систем с поддержкой OIDC или SAML — например, GitLab, Grafana, 1С (тонкого и веб-клиента) и собственных приложений — отдельный адаптер к IdP не нужен. Доработка самой системы также не требуется.
VPN-шлюзы, межсетевые экраны, сетевое оборудование и RD Gateway с поддержкой RADIUS подключаются через RADIUS-сервер MFA. В настройках системы указываются его адрес и время ожидания ответа.
Для старых ИС, которые проверяют пароль только через LDAP bind, используется LDAP-прокси. В настройках приложения необходимо указать адрес этого прокси.
Внутренние веб-панели и старые порталы без поддержки перечисленных способов подключения можно подключить через обратный прокси с OIDC. При этом необходимо ограничить прямой доступ к приложению.
Выбор факторов MFA
Централизованный сервис позволяет настроить перечень доступных факторов сразу для подключённых ИС. При выборе нужно учитывать не только удобство пользователя, но и то, какие способы подтверждения поддерживаются конкретным протоколом. Возможности зависят от выбранного MFA-решения.
SMS-коды и коды по электронной почте могут использоваться как резервный фактор, а TOTP-коды из приложения-аутентификатора — как базовый фактор для всех пользователей. Эти способы обладают низкой стойкостью к фишингу и применимы в сценариях с RADIUS и LDAP.
Для сотрудников подходит и push-подтверждение с вводом числа (number matching). Его стойкость к фишингу оценивается как средняя; такой способ также может использоваться в сценариях с RADIUS и LDAP.
FIDO2/WebAuthn — аппаратный ключ или passkey — отличается высокой стойкостью к фишингу и подходит для критичных ИС. Обычно этот вариант используется для веб-аутентификации; для ИС с RADIUS или LDAP потребуется иная архитектура подключения.
Смарт-карта или токен с сертификатом (PKI) также обладает высокой стойкостью к фишингу и подходит для доменного входа. Применимость в сценариях с RADIUS и LDAP ограничена.
Политики MFA могут различаться в зависимости от типа ИС и категории пользователя. Для административного доступа может требоваться более строгий фактор, а для обычного корпоративного портала — подтверждение при начале сессии. Администраторам и другим пользователям с расширенными правами можно назначить отдельные требования к MFA.
При необходимости политика может учитывать устройство пользователя и условия подключения, например вход из корпоративной сети или извне. Для отдельных операций приложение может запросить повторное подтверждение, если IdP поддерживает такой сценарий.
Как организовать внедрение
Основные этапы
Внедрение лучше начинать с определения способов аутентификации в существующих ИС. Это позволит заранее понять, какие системы подключаются непосредственно к IdP, а для каких потребуется адаптер или прокси. Для этого составляется перечень ИС с указанием используемого протокола, способа входа и категорий пользователей.
Затем определяется очерёдность подключения: в первую очередь можно выбрать VPN и системы административного доступа, а после них — остальные корпоративные приложения. До подключения развёртываются необходимые компоненты IdP и MFA, настраиваются резервирование и передача событий аутентификации.
Пользователи регистрируют выбранные факторы. Порядок регистрации зависит от используемого решения и требований организации. На небольшой группе сотрудников проверяются вход в подключённые ИС, подтверждение вторым фактором и восстановление доступа.
По результатам проверки остальные ИС подключаются к централизованной MFA. Для каждой системы достаточно выполнить настройки выбранного способа интеграции. Отдельно проверяются оставшиеся локальные способы входа, чтобы они не позволяли обходить установленные требования MFA.
Настройка центрального сервиса
Для доступности MFA-сервиса предусматривается резервирование основных компонентов. При подключении по RADIUS и LDAP необходимо согласовать время ожидания ответа с длительностью подтверждения входа.
При использовании push можно настроить подтверждение с вводом числа и ограничить частоту повторных запросов. Для сервисных учётных записей при необходимости задаются отдельные правила аутентификации.
Регистрация, замена и восстановление факторов выполняются централизованно, поэтому обращаться к настройкам отдельных ИС приходится реже.
Итоги
Единая MFA позволяет перенести управление дополнительными факторами из отдельных ИС в централизованный сервис. Администратору больше не требуется настраивать собственный механизм подтверждения в каждом приложении, если система поддерживает интеграцию с IdP или соответствующим адаптером. Это особенно полезно в инфраструктуре, где одновременно используются современные веб-приложения, VPN и унаследованные ИС.
При таком подходе организация получает единые настройки политик MFA для подключённых систем, централизованную регистрацию и восстановление факторов, а также возможность управлять доступом пользователя через центральный сервис. События MFA поступают из общего источника для мониторинга и передачи в SIEM.
Автор: Аверин Андрей Александрович, руководитель группы Центра информационной безопасности, компания Digital Design.
