Обзор MFASOFT Secure Authentication Server 1.14 для многофакторной аутентификации

1. 1. Введение
2. 2. Функциональные возможности MFASOFT Secure Authentication Server 1.14
   1. 2.1. Методы аутентификации
   2. 2.2. Интеграция
   3. 2.3. Синхронизация LDAP
   4. 2.4. Аутентификация LDAP
   5. 2.5. Портал самообслуживания
   6. 2.6. Аудит, отчётность, статистика
3. 3. Архитектура MFASOFT Secure Authentication Server 1.14
4. 4. Управление Secure Authentication Server
   1. 4.1. Настройки виртуального сервера
   2. 4.2. Управление пользователями
   3. 4.3. Группы
   4. 4.4. Токены
   5. 4.5. Политики
   6. 4.6. Операторы
   7. 4.7. Настройки портала самообслуживания
   8. 4.8. Мониторинг
5. 5. Системные требования MFASOFT Secure Authentication Server 1.14
6. 6. Лицензирование MFASOFT Secure Authentication Server 1.14
7. 7. Применение MFASOFT Secure Authentication Server 1.14
8. 8. Выводы

Введение

Парольная аутентификация, несмотря на хорошо известные её ограничения, по-прежнему остаётся основным механизмом контроля доступа в большинстве информационных систем. На протяжении многих лет в списках наиболее распространённых паролей без изменений присутствуют одни и те же значения: 123456, 123456789, 12345678, admin, password. Практика их использования дополняется другой устойчивой тенденцией: четверо из пяти пользователей применяют один и тот же пароль для разных учётных записей, при том что среднее количество таких записей у одного пользователя достигает 40.

В результате пароль становится не инструментом защиты, а единым уязвимым элементом, компрометация которого автоматически расширяет поверхность атаки. Статистика подтверждает этот вывод: 81 % успешных атак были реализованы с использованием слабых или украденных паролей. Недостаточная строгость парольной политики либо её формальное соблюдение приводят сначала к компрометации отдельных компонентов информационной системы, а затем — к получению несанкционированного доступа к данным различного уровня критичности.

В этих условиях усиление механизмов аутентификации становится важнее удобства для пользователей и администраторов. Один из наиболее распространённых и практичных способов снижения рисков компрометации учётных записей — применение многофакторной аутентификации. Рекомендации по её использованию зафиксированы в методических документах и приказах Федеральной службы по техническому и экспортному контролю России (ФСТЭК России), положениях Банка России, стандарте Payment Card Industry Data Security Standard (PCI DSS).

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

Программный комплекс Secure Authentication Server (SAS) от MFASOFT (ООО «СИС разработка») предназначен для снижения вероятности несанкционированного доступа, компрометации учётных записей и последующих утечек данных. Решение ориентировано на защиту ресурсов любого типа и поддерживает различные варианты развёртывания, что позволяет использовать его в гетерогенных и масштабируемых средах.

Программный комплекс включён в реестр отечественного ПО (№ 15554 от 18.11.2022). Сертифицирован ФСТЭК России по 4 уровню доверия и техническим условиям, что позволяет применять его в ГИС (до 1 класса защищённости), ИСПДн (до 1 уровня защищённости), а также на значимых объектах КИИ (до 1 категории).

Функциональные возможности MFASOFT Secure Authentication Server 1.14

Secure Authentication Server — это ПО для многофакторной аутентификации по одноразовым паролям (OTP). Толчком к его созданию стал практический опыт работы команды MFASOFT с иностранными вендорами подобных решений. В ходе эксплуатации и внедрения таких систем стало очевидно:

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

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

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

Рассмотрим основные возможности продукта и особенности их реализации подробно.

Методы аутентификации

Поддерживается широкий набор аутентификаторов (токенов): 

• аппаратные (устройства-брелоки);
• программные (мобильные или десктопные приложения) автономные генераторы одноразовых паролей;
• механизмы отправки одноразовых паролей или пуш-уведомлений на телефон пользователя, через мессенджер или по электронной почте.

Все методы аутентификации бесконтактные, не требуют драйверов и считывателей на клиентских устройствах. Каждому отдельному токену можно присвоить индивидуальный ПИН-код, и тем самым реализовать полноценную многофакторную аутентификацию средствами только SAS, без использования доменных паролей.

Если пользователю назначено несколько токенов, то он сам может выбрать любой из них. Для этого нужно ввести или одноразовый пароль с генератора (вместе с ПИН-кодом, если он задан), или букву-селектор, указывающую на тип токена: e — для отправки кода на электронную почту, s — для отправки СМС, p — для пуш-уведомления в мобильное приложение и так далее.

Продукт поддерживает SafeNet eToken PASS, SafeNet eToken 3400, Рутокен OTP в режимах выдачи одноразового пароля по событию (HMAC-based One-Time Password, HOTP) и по времени (Time-based One-Time Password, TOTP). Аппаратные токены также можно использовать (выбрав в качестве селектора букву h) в режиме «запрос-ответ», если такой режим включён в консоли администрирования.

Рисунок 1. Поддерживаемые SAS аппаратные аутентификаторы

Из программных токенов решение поддерживает описанные ниже.

Мобильное приложение MFASOFT предназначено для использования на платформах Android, iOS и HarmonyOS.

Рисунок 2. Мобильное приложение MFASOFT

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

• выдачу одноразовых паролей по времени (ТОТР) и по событию / нажатию (НОТР);
• отдельные токены для разных учётных записей пользователя;
• добавление токенов вручную (вводом / выбором настроек) или сканированием QR-кода;
• активацию с защитой от клонирования (мобильное приложение сигнализирует серверу аутентификации, что токен активирован, и повторная активация этого же токена на другом устройстве становится невозможной);
• индикацию скорой смены одноразового пароля для токена;
• защиту доступа к токенам индивидуальными ПИН-кодами или биометрией (Touch ID, Face ID);
• централизованные политики токенов;
• приём пуш-уведомлений независимо от состояния телефона (заблокирован / разблокирован) и приложения (не запущено / свёрнуто / на переднем плане).

Google-совместимые мобильные приложения для платформ Android и iOS с синхронизацией по событию и по времени: Google Authenticator, Яндекс ID, Bitrix24 OTP.

Рисунок 3. Google-совместимые мобильные приложения

Расширение «Аутентификатор» для веб-браузера Google Chrome для платформ Windows и Linux с синхронизацией по событию и по времени.

Рисунок 4. Расширение «Аутентификатор» для веб-браузера Google Chrome

Токены типа «запрос-ответ» обеспечивают доставку одноразового пароля пользователю по различным каналам связи. Поддерживается отправка через SMS, сторонние мессенджеры и телефонные звонки с использованием API внешних сервисов. Также возможна доставка по электронной почте и в мессенджер Telegram с помощью специального бота.

Если у пользователя установлено приложение Telegram (мобильное или десктопное), то токен может работать и в режиме пуш. В приложение приходит уведомление о попытке аутентификации. Если запрос легитимен, то пользователь подтверждает вход. Если же попытка входа несанкционирована, то пользователь отклоняет запрос.

Чтобы использовать токен, его необходимо выдать пользователю, после чего пользователь должен его активировать (за исключением токенов «запрос–ответ»).

Интеграция

Чтобы защитить доступ к определённому ресурсу (устройству, приложению) одноразовыми паролями или пуш-уведомлениями, необходимо связать этот ресурс и SAS. Поддерживаются разные способы (протоколы) интеграции, выбор которых зависит от типа целевого ресурса и возможностей конкретных версий ПО, моделей устройств. Такой подход обеспечивает универсальность и гибкость решения, позволяя интегрировать его с различными системами и протоколами без изменения существующей инфраструктуры.

Рисунок 5. Интеграция целевых ресурсов с SAS

Агент для FreeRADIUS (FRA). Для интеграции целевых ресурсов с сервером аутентификации SAS по протоколу RADIUS используется агент (дополнительный модуль) для ПО FreeRADIUS. Этот агент вместе с сервером FreeRADIUS выполняет функцию шлюза, через который запросы от целевых ресурсов попадают к модулю аутентификации, а ответы от этого модуля — к целевым ресурсам. Поддерживаются как одноэтапный (для токенов-генераторов TOTP и HOTP), так и двухэтапный («запрос-ответ») режимы.

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

Агент LDAP-прокси (LPA). Для интеграции с SAS целевых ресурсов (приложений и устройств), использующих LDAP-аутентификацию, применяется агент, выполняющий функции посредника (прокси). Он принимает от целевого ресурса запросы на привязку по протоколу LDAP (или LDAPS) и транслирует их на LDAP-сервер.

Если привязка прошла успешно (то есть пароль был верным), агент отправляет (через Web API интеграции) на сервер SAS одноразовый пароль или запрашивает отправку пуш-уведомления. Если одноразовый пароль верен (или пользователь подтвердит вход в пуш-уведомлении), то LDAP-прокси отправляет на целевой ресурс подтверждение успешной привязки. Если же LDAP-пароль или одноразовый пароль неверны, или пользователь отклонит вход по пуш-уведомлению, то целевой ресурс получит сообщение, что учётные данные пользователя неверны.

Так как целевые ресурсы, использующие LDAP-аутентификацию, предлагают пользователю только одно поле для ввода пароля, при интеграции через LDAP приходится:

• или включать автоматическую отправку пуш-уведомлений заранее выбранного типа (режим «автопуш»);
• или передавать одноразовый пароль (или запрос на пуш-уведомление) вместе с паролем LDAP в одном поле.

Так как аутентификация одноэтапная, то при интеграции через LDAP токены типа «запрос-ответ» не поддерживаются.

Агент для ADFS. Для интеграции с целевыми ресурсами, использующими механизм единого входа (Single Sign On, SSO) на базе Microsoft Active Directory Federation Services (ADFS), используется агент для ADFS. Он представляет собой дополнительный модуль (плагин) для сервера ADFS, который после установки и регистрации становится доступен в консоли администрирования ADFS. Это позволяет настроить как сам модуль, так и логику подключения второго фактора аутентификации.

Когда пользователь заходит на страницу входа целевого сервиса, тот перенаправляет («перебрасывает») его на страницу аутентификации сервиса ADFS. На ней пользователь вводит свои логин и доменный пароль, а если политиками требуется двухфакторная аутентификация, то сервис показывает окно для ввода второго фактора. Введённое в это окно значение отправляется на сервер аутентификации SAS. Если проверка пройдена, то пользователя перенаправляют на стартовую страницу целевого сервиса.

Агент для Keycloak. Для интеграции целевых ресурсов с сервером аутентификации SAS по протоколам SAML (Security Assertion Markup Language) и OIDC (OpenID Connect) можно использовать агент для открытого ПО Keycloak. Этот агент представляет собой дополнительный модуль (плагин) для сервера Keycloak, который после установки и настройки становится доступен в консоли администрирования Keycloak. Это позволяет настроить как сам модуль, так и логику подключения второго фактора аутентификации.

Когда пользователь заходит на страницу входа целевого сервиса, тот перенаправляет («перебрасывает») его на страницу аутентификации Keycloak. На ней пользователь вводит свои логин и доменный пароль. Если политиками требуется двухфакторная аутентификация, то сервис показывает окно для ввода второго фактора. Введённое в это окно значение отправляется на сервер аутентификации SAS. Если проверка пройдена, то пользователя перенаправляют на стартовую страницу целевого сервиса.

Web API. Базовый, встроенный в ядро Secure Authentication Server интерфейс для обработки запросов на аутентификацию, — это реализованный в продукте собственный Web API. В конечном счёте все такие запросы и ответы на них отправляются и принимаются через протокол HTTPS на веб-сервере узла, где запущен сервер аутентификации.

Через этот интерфейс можно связать (интегрировать) с сервером аутентификации целевое (защищаемое) приложение, добавив в него программный код (агент), реализующий функции клиента аутентификации. В этом случае приложение, которому требуется проверить введённый одноразовый пароль, вызывает соответствующий программный код. Этот код устанавливает с сервером аутентификации защищённое соединение и передаёт по нему введённые пользователем данные для проверки. Такой способ интеграции подходит, если доступен исходный код приложения, и его можно модифицировать.

Синхронизация LDAP

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

В продукт включён собственный агент синхронизации LDAP, поддерживающий одновременно схемы Active Directory, SAMBA и FreeIPA. Реализована непрерывная односторонняя синхронизация, которая не требует модификации схемы и доступа в каталог на запись. Поддерживается одновременная работа нескольких агентов для повышения производительности или частоты синхронизации.

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

Аутентификация LDAP

Сервер или агент аутентификации может проверять на сервере каталога введённый пользователем пароль LDAP. Такой пароль используется:

• для доступа к порталу самообслуживания;
• вместо ПИН-кода в одной строке с OTP (если это задано политикой токенов);
• в предварительной (двухэтапной) аутентификации до или после проверки одноразового пароля;
• при интеграции целевых сервисов через агент LDAP-прокси.

Рисунок 6. Адаптивная аутентификация в MFASOFT SAS 1.14

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

Например, если доступ к порталу самообслуживания извне контролируемого периметра должен быть защищён комбинацией LDAP-пароля и OTP, а изнутри сети — только LDAP-паролем, то можно создать соответствующее правило. По нему доступ к агенту «Портал самообслуживания» извне должен требовать от пользователя ввода логина, LDAP-пароля и OTP, а доступ к агенту изнутри — только логина и LDAP-пароля.

Портал самообслуживания

Портал самообслуживания — это веб-приложение, через которое пользователи могут выполнять типичные действия без обращения в хелпдеск. Войти в него можно из любого веб-браузера по действующему токену, временному коду доступа (высылается по запросу пользователя на почту, в SMS или в Telegram) или по LDAP-паролю.

Рисунок 7. Вход в портал самообслуживания

Рисунок 8. Портал самообслуживания MFASOFT Secure Authentication Server 1.14

Самостоятельная смена LDAP-пароля возможна в двух режимах: сброс (если пароль забыт) или изменение (с вводом текущего пароля). Дополнительно можно задать ограничение по IP-адресам как дополнительную меру защиты для этой ответственной операции.

Пользователь может сбросить ПИН-код любого своего токена, если этот код забыт, скомпрометирован или истёк. Также можно синхронизировать токен, если он рассинхронизировался из-за «дрейфа» часов (для токенов с синхронизацией по времени) или многократных «холостых» нажатий (для токенов с синхронизацией по событию).

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

Рисунок 9. Возможности Портала самообслуживания

Аудит, отчётность, статистика

Продукт имеет встроенные средства для регистрации и анализа действий субъектов доступа и событий в системе. Для каждого входа регистрируются логин, время, IP-адрес, агент, результат (успешно или нет), номер токена и описание. Эти события регистрируются в базе данных, а также могут быть отправлены на сервер syslog.

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

Архитектура MFASOFT Secure Authentication Server 1.14

Решение на базе SAS включает в себя:

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

Сервер аутентификации Secure Authentication Server состоит из нескольких независимых модулей, каждый из которых выполняет определённый набор функций:

• Модуль аутентификации проверяет одноразовые пароли и ПИН-коды.
• Консоль управления позволяет настраивать и администрировать решение.
• Модуль активации используется для активации выданных пользователю токенов.
• Портал самообслуживания предназначен для самостоятельного запроса пользователями новых токенов, сброса ПИН-кодов и доменных паролей, синхронизации токенов TOTP и HOTP.
• Модуль синхронизации LDAP отвечает за приём информации от агентов LDAP и запись её в базу данных SAS.
• Модули поддержки мобильного приложения MFASOFT и токенов Telegram в режиме «пуш» предназначены для отправки пуш-уведомлений пользователям через сторонние сервисы.
• Модуль планировщика задач отвечает за запуск задач по расписанию (например, автоматическое назначение или отзыв токенов).
• Модуль синхронизации LDAP принимает изменения от агентов синхронизации.
• Модуль API администрирования поддерживает доступ сторонних инструментов управления к функциям активации токенов, самообслуживания и управления.

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

Рисунок 10. Архитектура MFASOFT SAS 1.14

Любые компоненты решения можно объединять в кластеры (фермы), обеспечивая нужный уровень доступности и производительности: для этого используются встроенные механизмы дублирования или внешние балансировщики веб-запросов.

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

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

Рисунок 11. Балансировка нагрузки и отказоустойчивость

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

SAS предоставляет возможность создавать множество автономных виртуальных серверов аутентификации на одной инсталляции. Пользователи, их токены и целевые ресурсы распределяются по аккаунтам (тенантам). Аккаунты можно создавать по разным принципам: функциональному, географическому, ролевому или организационному. При организационном разделении отдельные аккаунты могут соответствовать как подразделениям одной организации, так и различным организациям, включая партнёров, поставщиков или клиентов, использующих решение по подписной модели.

Все аккаунты объединены в многоуровневую иерархию в виде дерева. Аккаунты, использующие решение исключительно для собственных задач, относятся к категории подписчиков. Аккаунты, которые наряду с собственным использованием могут предоставлять доступ к решению другим аккаунтам, выступают в роли сервис-провайдеров. Такая модель позволяет формировать цепочки арендаторов и субарендаторов в рамках одной инсталляции продукта.

Рисунок 12. Многоуровневая мультиарендность, мультитенантность Secure Authentication Server

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

Иерархия аккаунтов и операторов предоставляет возможность реализовать централизованное, делегированное или совместное администрирование виртуальных серверов, воплощая принцип многоуровневой мультиарендности. Например, организации-арендаторы сами могут становиться провайдерами и предоставлять к нему доступ своим субарендаторам.

Рисунок 13. Реализация мультиарендности в консоли управления SAS

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

Возможность развёртывания Secure Authentication Server в мультиарендном режиме позволяет его использовать в инфраструктуре сервис-провайдера. На одной инсталляции SAS можно быстро создать необходимое число автономных серверов аутентификации для потенциальных заказчиков. Интеграция с конечными сервисами происходит через агенты, которые развёртываются на стороне заказчика и полностью им контролируются.

Рисунок 14. Использование SAS в инфраструктуре сервис-провайдеров

Управление Secure Authentication Server

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

Рисунок 15. Веб-консоль администрирования

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

Настройки виртуального сервера

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

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

Рисунок 16. Настройки выбранного виртуального сервера в MFASOFT SAS 1.14

Общие настройки определяют поведение системы при аутентификации пользователей и администраторов.

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

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

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

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

Настройки сообщений СМС / Telegram. Сообщения (одноразовые пароли, уведомления о выдаче токенов разных типов) формируются из шаблонов, которые состоят из текста и тегов (подстановочных переменных). Эти теги можно перенести в шаблон с помощью операции drag & drop.

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

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

Настройки Keycloak. ПО Keycloak предназначено для реализации единого входа в веб-приложения. На одном экземпляре Keycloak можно определить отдельные области аутентификации (так называемые «реалмы»). Если в Keycloak определён единственный реалм, то достаточно добавить его как узел аутентификации в виртуальный сервер SAS, и никаких дополнительных настроек не требуется.

Однако бывают ситуации, когда нужно сопоставить разные реалмы с разными виртуальными серверами. Но так как все запросы от Keycloak идут с одного IP-адреса, необходимо для каждого реалма сгенерировать уникальный GUID, который будет однозначно сопоставлять его с нужным виртуальным сервером.

Настройки синхронизации LDAP. Secure Authentication Server поддерживает автоматическую синхронизацию пользователей и групп из каталогов LDAP. В консоли можно настроить параметры подключения агентов LDAP к модулю синхронизации LDAP.

Для пользователей и групп, синхронизируемых через LDAP, реализована возможность установить отложенное удаление, чтобы после удаления из LDAP-источника они удалялись из базы SAS не сразу, а через 24 часа. Если пользователи и группы были удалены по ошибке, то достаточно вернуть их в LDAP-источник. После повторной синхронизации пометка на удаление в базе SAS будет снята.

Настройки LDAP-аутентификации. Можно использовать внешний сервер LDAP для аутентификации локальных и синхронизированных пользователей системы SAS. Параметры подключения к серверу LDAP передаются в процессе синхронизации пользователей с использованием агента синхронизации. После сохранения изменений параметров можно выполнить тестовую аутентификацию на первом и втором сервере LDAP, нажав кнопку «Тест» для первого и второго узлов LDAP соответственно.

Настройки агента syslog. SAS позволяет отправлять записи аудита, а также сообщения о доступности внешних сервисов (SMTP, СМС, Telegram) на сервер syslog. Для интеграции с сервером syslog используется специальный агент, который получает сообщения по HTTPS и отправляет их по протоколу syslog на сервер syslog.

Настройки пуш-прокси. Панель отображает (только чтение) параметры подключения к пуш-прокси, определённые в файле конфигурации. Дополнительно панель позволяет выполнить проверку подключения к серверам пуш-прокси.

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

Техническая поддержка.

Управление пользователями

Для каждого пользователя решения создаётся учётная запись (УЗ), одна или несколько. Все УЗ сгруппированы по виртуальным серверам, поэтому все действия с пользовательскими УЗ проводятся для каждого виртуального сервера в отдельности. Это означает, что сначала нужно переключиться в консоли на нужный виртуальный сервер.

К любому пользователю можно применить ограничения на вход по дате (не раньше и/или не позже выбранной) и/или по дням недели. Если же пользователю назначена роль администратора, то к этой роли можно применить свои, независимые от пользовательских, ограничения. То есть возможна ситуация, когда пользователь сможет войти в целевой сервис, но не сможет управлять виртуальным сервером в качестве его оператора.

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

Рисунок 17. Управление пользователями в MFASOFT SAS 1.14

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

Прежде чем использовать аппаратный или программный токен, его нужно активировать.

Задачи активации. Активация токена происходит в два этапа. Пользователю выдаётся токен, который необходимо активировать, перейдя по ссылке, отправленной по электронной почте, в SMS или в Telegram, или доступной на портале самообслуживания.

Программные аутентификаторы поддерживают два механизма активации: ручную и автоматическую. При ручной активации пользователь должен перейти на страницу активации, отсканировать QR-код или ввести строку инициализации, где содержатся параметры токена. После этого он должен ввести значение одноразового пароля из приложения и подтвердить активацию, нажав кнопку на странице активации. Автоматическая активация (поддерживается только мобильным приложением MFASOFT) предоставляет QR-код, который достаточно отсканировать.

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

Рисунок 18. Пример сообщения активации токена

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

Задачи запросов токенов. Если на портале самообслуживания активирован раздел «Запрос токена», то пользователь может самостоятельно запросить себе аутентификатор. Если политикой требуется одобрение выдачи аутентификатора, то запрос токена будет отображаться в панели «Задачи» запросов токенов. Оператор может одобрить запрос на выдачу токена или отклонить его, написав в отдельном окне причину отклонения.

Группы

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

Группы могут создаваться вручную или синхронизацией из LDAP-источника.

Рисунок 19. Вкладка «Группы» в MFASOFT Secure Authentication Server 1.14

Токены

Отличительная черта продукта — централизованное управление жизненным циклом токенов: импорт, выдача, активация, приостановка, отзыв.

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

Найти и получить сведения о токене возможно во вкладке «Управление токенами».

Рисунок 20. Вкладка «Управление токенами»

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

В зависимости от определённой на виртуальном сервере политики, токенам можно назначать индивидуальные ПИН-коды. Таким образом можно внедрить двухфакторную беспарольную (т. е. не привязанную к паролям корпоративных УЗ) аутентификацию. Общее количество и тип токенов ограничиваются условиями приобретённой и активированной лицензии. Созданные администратором токены (аппаратные и программные) распределяются между аккаунтами и затем выдаются их пользователям.

Любой выданный пользователю токен можно приостановить, возобновить, сбросить его ПИН-код, отозвать и синхронизировать.

Доступна инвентаризация токенов: сбор информации по токенам, заведённым в системе.

Рисунок 21. Состояние токенов

Политики

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

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

Рисунок 22. Настройки блокировки пользователей

Разграничение доступа. Управление доступом на основе ролей (Role-Based Access Control, RBAC) позволяет ограничивать доступ администраторов к отдельным панелям консоли. Решение поддерживает как встроенные, так и настраиваемые роли, что обеспечивает точное соответствие прав пользователей требованиям безопасности и организационной структуры.

Рисунок 23. Пример разграничения доступа к отдельным панелям консоли

Автоназначение. Функция позволяет освободить администраторов решений на базе SAS от рутинных операций, минимизировать человеческий фактор и ускорить подключения новых пользователей к системе. При включении пользователя в группу или исключении из неё автоматически срабатывает одно или несколько правил, по которым токены выдаются или отзываются. Для каждого виртуального сервера формируется собственный набор таких правил.

Рисунок 24. Автоназначение в MFASOFT Secure Authentication Server 1.14

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

Рисунок 25. Автоназначение администраторов

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

Политика предварительной аутентификации. Она задаёт условия, при соблюдении которых будет разрешена аутентификация по одноразовым паролям или пуш-уведомлениям. Политика состоит из правил, каждое из которых включает одно или несколько условий.

Рисунок 26. Политика предварительной аутентификации

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

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

Рисунок 27. Политика ограничения токенов

Политики аппаратных и программных токенов. На уровне виртуального сервера можно настроить параметры работы токенов.

Рисунок 28. Политики токенов в MFASOFT SAS 1.14

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

Рисунок 29. Политика временного пароля

Политика токена в режиме «запрос-ответ». Доступна настройка параметров работы SMS / Telegram / почтового токена.

Рисунок 30. Политика токена в режиме «запрос-ответ»

Политика ПИН-кода. Если для виртуального сервера используются ПИН-коды, то можно настроить их политики.

Рисунок 31. Политики ПИН-кода в MFASOFT Secure Authentication Server 1.14

Новые политики распространяются только на вновь выдаваемые токены. Для ранее выданных токенов продолжают действовать политики, с которыми те были выданы.

Операторы

Управление операторами доступно в одноимённой вкладке.

Рисунок 32. Управление операторами

Настройки портала самообслуживания

Система позволяет включать или отключать портал, а также изменять его веб-адрес.

Настройка политики временного кода определяет условия использования временного кода для входа на портал вместо OTP. Политика запросов токенов задаёт, какие типы токенов пользователи могут запрашивать через портал самообслуживания, и определяет список лиц, которые будут одобрять эти запросы.

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

Рисунок 33. Настройки портала самообслуживания

Дополнительно доступны настройки для сброса и изменения пароля LDAP.

Мониторинг

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

Статистика. Для быстрой проверки и анализа основных показателей работы виртуального сервера служит вкладка статистики. Она позволяет узнать:

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

Рисунок 34. Статистика

Статистика в виде дашбордов представлена в неизменном виде: нельзя добавлять, удалять или менять порядок элементов. Но возможно скачать представленные данные в виде html-файла.

Рисунок 35. Скачанные данные в виде html-файла

Аудит. Для каждого виртуального сервера система ведёт отдельный журнал событий аутентификации (входа), который хранится в базе данных и отображается в консоли.

Рисунок 36. Журнал пользователей в MFASOFT SAS 1.14

Журнал аудита экспортируется в формате csv.

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

Рисунок 37. Вкладка «Отчёты»

Реализована возможность создания шаблона отчёта на основе встроенного.

Рисунок 38. Создание собственного шаблона отчёта на основе встроенного

Интеграция с сервером (серверами) syslog. Решение может быть интегрировано с ним (ними) для централизованного хранения записей аудита, настройки триггеров на события и дальнейшей корреляции событий безопасности во внешних системах.

Системные требования MFASOFT Secure Authentication Server 1.14

Серверы аутентификации SAS вместе с базой данных можно развернуть локально в своей корпоративной сети, на хостинге в коммерческом ЦОДе или подключиться к публичному облаку одного из сервис-провайдеров MFASOFT (при этом используется один и тот же установочный файл (дистрибутив)). Агенты для интеграции SAS с защищаемыми ресурсами, для синхронизации с корпоративным каталогом LDAP и для отправки сообщений на сервер syslog всегда размещаются в корпоративной сети.

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

Сервер аутентификации и большинство агентов (кроме агентов для ADFS и Keycloak, которые выполнены в виде плагинов для уже развёрнутых в корпоративной инфраструктуре сервисов) поставляются в виде образов контейнеров Docker. Благодаря этому компоненты продукта можно запустить везде, где есть поддержка Docker — а это не только любые дистрибутивы Linux, но и Windows, macOS.

Все данные решения (информация о пользователях, токенах, группах, настройках и политиках, записи аудита) хранятся в базе данных. Настройки для запуска серверов аутентификации (в том числе параметры подключения к БД) и агентов — в конфигурационных файлах. Эти файлы удобно хранить не в контейнере, а на хосте (или вообще на сетевом диске).

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

Для запуска компонентов решения машина (физическая или виртуальная) должна соответствовать минимальным требованиям, обеспечивающим работу компонентов под минимальной нагрузкой. Если СУБД и модули SAS работают на одной машине, то нужно взять наибольшее (из двух) значение.

Таблица 1. Системные требования для MFASOFT SAS 1.14

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

В минимальной конфигурации можно разместить все компоненты решения, включая базу данных, на одной машине. Однако такая конфигурация с учётом плановых простоев обеспечивает уровень доступности «две девятки». Она подойдёт только для ознакомления с SAS, тестирования его отдельных функций. Для обеспечения уровня доступности «три девятки» для большей части сценариев следует задублировать все компоненты решения, разместив их как минимум на двух машинах. Серверы баз данных будут объединены в кластер «активный-активный».

При использовании внешней СУБД или недостаточной производительности машин необходимо серверы баз данных разместить в отдельном кластере. Если в организации используется межсетевой экран, который блокирует весь исходящий трафик из публичной сети (WAN) или демилитаризованной зоны (DMZ) во внутренний сегмент (LAN), пользователи решения не смогут получать пуш-уведомления. Они не смогут входить на портал самообслуживания и активировать аутентификаторы из-за периметра корпоративной сети. Администраторы при этом не смогут использовать консоль администрирования без подключения к VPN.

Чтобы обеспечить работу перечисленных функций, необходимо выполнить следующие действия:

• Сконфигурировать отдельную DMZ, исходящий трафик из которой в LAN будет заблокирован, а входящий из LAN — разрешён.
• Разместить в этой отдельной DMZ серверы аутентификации SAS и базу данных.
• Разместить агенты аутентификации и синхронизации LDAP в LAN.
• Опубликовать («пробросить») с помощью обратного прокси-сервера порт HTTPS серверов аутентификации SAS в общую DMZ.
• Добавить в межсетевой экран правила-исключения, разрешающие трафик от обратного веб-прокси к серверам SAS.

Рисунок 39. Размещение компонентов MFASOFT SAS 1.14 в корпоративной сети

Лицензирование MFASOFT Secure Authentication Server 1.14

Комплекс лицензируется по максимальному количеству пользователей, которым можно назначить аутентификатор. Одна лицензия включает: 1 аппаратный токен, 3 программных токена, 1 SMS-токен, 1 почтовый токен, 1 токен Telegram. Продукт поддерживает три схемы лицензирования:

• Срочная (term limited). Лицензия, включая техническую поддержку вендора, действует 1, 2 или 3 года.
• Бессрочная (perpetual). Ограничений по времени нет. В первый год включена техническая поддержка (продление можно приобрести отдельно).
• Оплата по фактическому использованию (usage based). Лицензия требует отправки ежемесячных биллинговых отчётов о фактическом использовании продукта (количестве назначенных пользователям лицензий) и оплаты счетов, выставляемых на основании этого отчёта.

Редакция Demo предназначена для ознакомления с продуктом и допускает его использование с ограничением по времени и числу пользователей. Редакция Enterprise позволяет использовать продукт в течение срока для указанного в счёте количества пользователей.

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

Техническая поддержка работает восемь часов пять дней в неделю. Включает в себя консультирование по возможностям продукта, сайзинг, помощь в установке, настройке и эксплуатации решения. В неё входит доступ к обновлениям дистрибутивов и документации, заявкам на совершенствование продукта.

Применение MFASOFT Secure Authentication Server 1.14

Основная область применения SAS — централизованные решения для защиты доступа к корпоративным информационным ресурсам, включая пользовательские устройства и прикладные системы. Рассмотрим возможные сценарии его применения, в рамках которых могут использоваться разные аутентификаторы: аппаратные, программные (как собственные, так и сторонние Google Authenticator, Яндекс Ключ), пуш в Telegram и мобильный пуш, отправка OTP по внешним каналам (SMS, почта, мессенджеры, звонок).

Подключение к VPN-серверу. Например, при установке VPN-соединения через FortiGate реализуется дополнительная проверка пользователя при помощи MFASOFT SAS. Интеграция с сетевым оборудованием выполняется по протоколу RADIUS. После ввода учётных данных пользователь подтверждает доступ к VPN посредством второго фактора: через мессенджер Telegram.

Рисунок 40. Двухэтапная аутентификация в FortiGate при установлении VPN-соединения

Подключение по протоколам удалённого доступа RDP и инфраструктурам виртуальных рабочих мест (VDI). В качестве примера рассмотрим RD Gateway, входящий в состав инфраструктуры удалённых рабочих столов Microsoft Remote Desktop Services и обеспечивающий безопасный доступ к внутренним ресурсам по протоколу RDP.

Так как при подключении к RD Gateway нет поля, куда можно было бы ввести OTP, на базе SAS в этом случае можно реализовать двухэтапную аутентификацию с использованием аутентификаторов в режиме пуш: мобильного приложения MFASOFT или Telegram. На рисунке ниже показали, как используется для аутентификации мобильное приложение в режиме пуш.

Рисунок 41. Двухэтапная аутентификация через мобильное приложение MFASOFT

Подключение к системам привилегированного доступа (PAM). Для примера возьмём СКДПУ НТ («АйТи Бастион»). Интеграция может быть выполнена как по протоколу LDAP(S), так и по протоколу RADIUS (в одно- или двухэтапном режимах). На рисунке ниже приведён пример аутентификации через Telegram.

Рисунок 42. Двухфакторная аутентификация в PAM-системе с использованием Telegram

Вход в веб-приложения. Рассмотрим пример реализации двухфакторной аутентификации для веб-приложения Portainer, предназначенного для управления контейнерами. Для организации аутентификации используется протокол OIDC, подключение реализуется через агент SAS для Keycloak.

Рисунок 43. Двухфакторная аутентификация с использованием расширения для браузера

Администрирование и вход в Linux. Для интеграции с SAS используется модуль pam-radius в Linux и агент SAS для протокола RADIUS. В этом случае можно использовать следующие типы аутентификаторов: аппаратные токены, программные (как собственные, так и сторонние), отправка в виде SMS, в сторонние мессенджеры, поддержка технологии Telegram-пуш и мобильный пуш.

Рисунок 44. Двухфакторная аутентификация в Astra Linux

Двухфакторная аутентификация также применяется при администрировании Linux-систем и доступе к прикладным сервисам. В качестве примера рассмотрим Zabbix — систему мониторинга, предназначенную для контроля состояния серверов, сетевого оборудования, виртуальных машин, приложений и ИТ-сервисов в режиме реального времени. В данном сценарии аутентификация осуществляется по протоколу LDAPS с использованием агента LDAP-прокси.

Рисунок 45. Двухфакторная аутентификация в Zabbix через Telegram

Выводы

MFASOFT Secure Authentication Server 1.14 обеспечивает централизованное управление аутентификацией, снижает административную нагрузку и упрощает взаимодействие пользователей с системой. Архитектура решения не ограничивает возможности интеграции и масштабирования.

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

Преимущества:

• Поддержка широкого спектра аутентификаторов.
• Все методы аутентификации универсальные и бесконтактные, не требуют драйверов и считывателей на клиентских устройствах.
• Возможность реализовать полноценную двухфакторную аутентификацию без использования других решений благодаря индивидуальным ПИН-кодам токенов.
• Реализация адаптивной аутентификации.
• Многоуровневая мультиарендность с делегированием доступа.
• Веб-консоль с детальной системой административных ролей.
• Развитые средства автоматизации: синхронизация пользователей и групп, автовыдача / автоотзыв токенов и административных ролей.
• Портал самообслуживания с возможностями полноценного личного кабинета управления аутентификацией.
• Регистрация всех попыток входа в целевые приложения, включая действия в консоли администрирования и портале самообслуживания.
• Модульная архитектура с дублированием всех компонентов.
• Поставка компонентов в виде готовых образов контейнеров Docker, настройки для которых можно хранить отдельно, тем самым достигается удобство и скорость развёртывания.
• Интеграция с корпоративными информационными системами через стандартные протоколы (Web API MFASOFT — для случаев, если приложение не поддерживает ни один из стандартных протоколов).
• Мобильное приложения MFASOFT доступно на мобильных устройствах под управлением Android, iOS и HarmonyOS.
• Встроенные в консоль документация по продукту и контакты техподдержки.
• Включение в реестр отечественного ПО, сертификация ФСТЭК России по 4 уровню доверия.

Недостатки:

• Статистика в виде дашбордов представлена в неизменном виде: нельзя добавлять, удалять или менять порядок элементов.
• Техподдержка доступна в рабочее время.
• Поддерживается только MariaDB, отсутствие официальной поддержки отечественных СУБД.