Архитектура решения Secure Authentication Server
Решение на базе SAS состоит из следующих частей (компонентов):
- сервера (-ов) аутентификации;
- сервера (-ов) баз данных;
- узлов (агентов) аутентификации;
- агента (-ов) LDAP;
- агента (-ов) syslog.
Модуль аутентификации
Отвечает за получение от узла аутентификации одноразового пароля (в том числе в сочетании с ПИН-кодом, если он задан), их проверку и отправку на узел результата этой проверки.
Параметры из строки запроса передаются процессу сервера аутентификации, который в свою очередь обращается к базе данных. Поэтому нужно настроить подключение этого модуля к базе данных (т.е. создать учетную запись пользователя этой базы).
Проверка запроса на аутентификацию выполняется только на основании данных, которые хранятся в базе данных. Модуль аутентификации не кэширует никаких результатов вычислений и не хранит никаких предвычисленных значений. С одной стороны, это обеспечивает целостность данных, исключает необходимость синхронизации с другими экземплярами модулей аутентификации. С другой стороны, доступность и производительность аутентификации будет зависеть от работы базы данных. Поэтому модули аутентификации следует размещать во внутреннем периметре корпоративной сети так, чтобы, с одной стороны, обеспечивать связность и приемлемое время задержки от узлов аутентификации, с другой стороны, гарантировать требуемую пропускную способность и время задержки до всех серверов баз данных.
Модуль для работы мобильного приложения MFASOFT в режиме пуш
Принимает запросы от мобильного аутентификатора, разработанного компанией MFASOFT для мобильных платформ Android и iOS, по протоколу HTTPS. Кроме того, модуль взаимодействует с сервером Redis (система управления базами данных класса NoSQL для работы со структурами «ключ-значение»), который хранит ответы пользователей на запросы аутентификации (утвердить или отклонить).
Модуль размещается в так называемой «демилитаризованной зоне» (DMZ) для того, чтобы мобильные аутентификаторы могли отправлять запросы из-за периметра корпоративной сети.
Модуль для работы токенов Telegram в режиме пуш
Принимает запросы от аутентификаторов Telegram по протоколу HTTPS. Кроме того, модуль взаимодействует с сервером Redis (система управления базами данных класса NoSQL для работы со структурами «ключ-значение»), который хранит ответы пользователей на запросы аутентификации (утвердить или отклонить).
Модуль размещается в так называемой «демилитаризованной зоне» (DMZ) для того, чтобы токены Telegram могли отправлять запросы из-за периметра корпоративной сети.
Модуль (консоль) администрирования
Представляет собой веб-приложение для настройки и администрирования продукта. Консоль поддерживает последние версии всех современных веб-браузеров (Chrome, Edge, Firefox, Safari) для всех распространенных операционных систем (Windows, Linux, macOS, Android, iOS). Запросы от браузера обрабатываются модулем администрирования.
Доступ к консоли происходит по протоколу HTTPS. Перед началом сеанса работы с консолью нужно аутентифицироваться в веб-форме входа. Данные из этой формы (логин и код доступа) отправляются в модуль аутентификации SAS. Данные сеанса хранятся в cookie.
Размещать модуль администрирования нужно так, чтобы обеспечить доступ веб-браузера администратора и комфортное время отклика, а также связь с модулем аутентификации и базой данных.
Модуль активации аутентификаторов
Нужен для того, чтобы пользователи могли активировать назначенные им аутентификаторы. Запрос на активацию приходит пользователю в виде одноразовой ссылки в сообщении электронной почты, и эта ссылка ведет на страницу активации. SAS поддерживает два типа активации токенов: ручную и автоматическую. Для аппаратных токенов и программных аутентификаторов сторонних разработчиков применяется ручная активация, при которой пользователю на странице активации нужно ввести серийный номер ключа (для аппаратных аутентификаторов) или отсканировать QR-код, в котором закодирован вектор инициализации (для программных аутентификаторов), после чего ввести одноразовый код с этого аутентификатора и установить его ПИН-код. Для программных аутентификаторов, разработанных компанией MFASOFT для платформ Android и iOS, поддерживается автоматическая активация.
Если модуль активации расположен внутри периметра корпоративной сети, доступ к которой извне защищен с помощью этого же решения, то получается, что до активации своего первого аутентификатора пользователь за пределами периметра корпоративной сети не сможет пройти по ссылке на модуль активации. Поэтому нужно или размещать модуль активации в DMZ, либо пользователю придется активировать свой первый аутентификатор, находясь внутри периметра.
Модуль (портал) самообслуживания
Обеспечивает выполнение пользователями типовых операций с аутентификаторами: сброса забытых ПИН-кодов, синхронизации счетчиков между токеном и сервером (если они рассинхронизируются из-за многократных «холостых» нажатий или дрейфа внутренних часов). Работа с порталом ведется через веб-браузер. В процессе работы модуль обменивается данными с сервером баз данных.
Войти на портал активации можно с любым из действующих токенов или по временному 10-минутному коду, который высылается по запросу пользователя на адрес электронной почты, указанный в его учетной записи. Один и тот же экземпляр модуля поддерживает индивидуальные порталы для разных виртуальных серверов.
Модуль планировщика задач
Для автоматического выполнения некоторых периодических задач служит планировщик. Время их запуска можно установить так, чтобы спланировать ресурсоемкие операции на периоды наименьшей загрузки решения. Планировщик запускает автоматическое назначение и отзыв аутентификаторов, рассылку уведомлений пользователям (например, о том, что нужно сменить ПИН-код аутентификатора), выполнение запланированных действий на сервере аутентификации (например, очистку старых событий аудита).
Модуль отчетности
Система позволяет не только регистрировать события аутентификации пользователей и администраторов, но и формировать отчеты о количестве, распределении и статусе пользователей, токенов и лицензий, о действиях операторов, о создании задач и узлов активации и так далее. Модуль отчетности позволяет мгновенно или по расписанию создавать отчеты по настроенным шаблонам, сохранять отчеты на сервере или отправлять их на электронную почту.
Модуль синхронизации LDAP
Учетные записи пользователей можно добавлять как вручную из консоли управления или импортом из текстового файла, так и синхронизацией по LDAP. Модуль синхронизации LDAP отвечает за прием информации от агентов LDAP и запись ее в базу данных SAS. Модуль синхронизации может принимать информацию сразу для нескольких виртуальных серверов, в том числе и от нескольких агентов сразу (при условии, что все агенты имеют одинаковые настройки для одних и тех же виртуальных серверов). Передача данных от агентов зашифрована с помощью SSL. Кроме того, для верификации агентов используется идентификатор и ключ (подпись): с их помощью модуль аутентификации может удостовериться, что поток данных идет от легитимных агентов.
Объекты, созданные посредством синхронизации, могут быть изменены только модулем синхронизации LDAP – в консоли администрирования они доступны только на чтение, и ни одно из синхронизированных свойств изменить нельзя.
Агент LDAP (LSA)
Для извлечения информации из каталога LDAP используется агент синхронизации LDAP (LDAP Synchronization Agent, LSA). Этот агент периодически подключается к каталогу, скачивает из него нужные свойства выбранных для синхронизации объектов и сравнивает их со своей локальной базой данных (так называемым «срезом»), в которой хранится текущая информация о синхронизированных объектах в базе SAS. Если с этими объектами произошли любые изменения (создание, удаление, модификация), то локальная база агента обновляется, и затем изменения в ней асинхронно отправляются в базу данных сервера аутентификации через модуль синхронизации LDAP. В качестве LDAP-источников поддерживаются Microsoft Active Directory и FreeIPA. Можно скорректировать типовую схему сопоставления полей LDAP объекта с полями пользователя в Secure Authentication Server. Такие события, как подключение к серверам каталога, ошибки при доступе к объектам LDAP и при записи их в базу данных SAS, регистрируются в локальном журнале LSA. Для подключения к каталогу агент может использовать как базовый протокол LDAP, так и LDAP через SSL (LDAPS).
Агенты синхронизации с LDAP можно объединять в кластеры из двух и более узлов. Это обеспечивает отказоустойчивость, а также ускоряет синхронизацию, когда объектов в каталоге много. Помимо функции синхронизации пользователей агент LDAP также участвует в процессе автоматического назначения и отзыва аутентификаторов, а также в процессе автоматического назначения и отзыва ролей операторов. Если при синхронизации срабатывает правило автоматического назначения (например, пользователь принадлежит определенной группе и у него нет токена), то система автоматически сама назначает ему аутентификатор. Если в правиле указан автоматический отзыв токена (или роли оператора), то, когда пользователь перестает соответствовать этому правилу, система автоматически отзывает аутентификатор или роль.
Сервер базы данных
Хранит все данные и настройки продукта в таблицах реляционной базы данных, выполняет запросы на чтение и запись этих данных от любого из модулей решения. Хотя сама СУБД не входит в состав продукта Secure Authentication Server, от производительности и доступности сервера баз данных во многом зависят характеристики решения в целом.
Шлюз RADIUS (FRA)
Для интеграции целевых ресурсов с сервером аутентификации SAS по протоколу RADIUS используется агент (дополнительный модуль) для ПО FreeRADIUS. Этот агент вместе с сервером FreeRADIUS выполняет функцию шлюза, через который запросы от целевых ресурсов попадают к модулю аутентификации, а ответы от этого модуля – к целевым ресурсам.
При интеграции целевых ресурсов по протоколу RADIUS решение может после успешной аутентификации пользователя возвращать так называемые атрибуты RADIUS. Они нужны для поддержки расширенных возможностей аутентификации и авторизации, например, динамических групп, членство в которых определяется значением возвращаемого атрибута.
Чтобы обеспечить миграцию со стороннего решения для аутентификации по одноразовым паролям на Secure Authentication Server с продолжительным периодом сосуществования, шлюз RADIUS поддерживает режим миграции. В режиме миграции, если сервер аутентификации SAS доступен и в его базе есть учетная запись пользователя, но у нее нет токенов, то при входе под такой учетной записью шлюз вместо того, чтобы сразу сообщить о неуспешной аутентификации, отправляет по протоколу RADIUS повторный запрос на аутентификацию к стороннему решению.
Агент Web API
Целевой ресурс можно связать с SAS напрямую, добавив в программный код этого ресурса агент для работы с SAS. В этом случае приложение, которому нужно проверить введенный в него одноразовый пароль, будет вызывать агент, а тот – устанавливать с сервером аутентификации защищенное соединение и передавать по нему введенные пользователем данные для проверки. Такой способ интеграции подходит, если доступен исходный код приложения.
Агент ADFS
Для интеграции целевых ресурсов с сервером аутентификации SAS по протоколу Microsoft ADFS используется агент ADFS. Этот агент интегрируется в сервис Microsoft Active Directory Federation Services как модуль расширения для двухфакторной аутентификации. В сочетании с функциональностью сервиса ADFS агент позволяет реализовывать механизм адаптивной аутентификации (определять условия, которых требуется двухфакторная аутентификация).
Агент Keycloak
Веб-приложения, использующие протоколы интеграции SAML (Security Assertion Markup Language) или OIDC (OpenID Connect), можно подключить к серверу аутентификации SAS через приложение Keycloack. Для этого на сервере KeyCloak нужно установить и настроить в качестве модуля двухфакторной аутентификации агент для SAS. После регистрации модуля он становится доступен в консоли администрирования KeyCloak, что позволяет настроить как сам модуль, так и критерии применения второго фактора.
Вернуться к Оглавлению.