Решение на базе SAS включает в себя один или несколько серверов аутентификации, а также программные агенты, с помощью которых обеспечивается связь (интеграция) с целевыми (защищаемыми) информационными ресурсами, внешними каталогами учетных записей и системами регистрации событий. Поддерживаются разные способы (протоколы) интеграции с целевыми ресурсами (собственный Web API MFASOFT, RADIUS, SAML, OpenID Connect, WS-Fed) – выбор зависит как от типа целевого ресурса, так и от возможностей конкретных версий ПО и моделей устройств.
Сервер аутентификации можно развернуть локально в своей корпоративной сети, на хостинге в коммерческом ЦОДе или подключиться к публичному облаку одного из сервиспровайдеров MFASOFT. При этом в корпоративной сети размещаются только агенты, а на устройства пользователей (кроме тех, вход в которые нужно защитить) ничего устанавливать не нужно. Это обеспечивает удобство и гибкость: пользователи могут работать с любых устройств и использовать те же самые способы входа.
Сервер аутентификации SAS состоит из нескольких независимых модулей, каждый из которых выполняет определенный набор функций.
• модуль (ядро) аутентификации;
• модуль (консоль) администрирования через веб-интерфейс;
• модуль активации аутентификаторов;
• модуль портала самообслуживания;
• модули для работы аутентификаторов с пуш-уведомлениями;
• модуль синхронизации LDAP;
• модуль API администрирования.
Отвечает за получение от узла аутентификации одноразового пароля (в том числе в сочетании с ПИН-кодом, если он задан), их проверку и отправку на узел результата этой проверки.
Параметры из строки запроса передаются процессу сервера аутентификации, который в свою очередь обращается к базе данных. Поэтому нужно настроить подключение этого модуля к базе данных (т.е. создать учетную запись пользователя этой базы).
Проверка запроса на аутентификацию выполняется только на основании данных, которые хранятся в базе данных. Модуль аутентификации не кэширует никаких результатов вычислений и не хранит никаких предвычисленных значений. С одной стороны, это обеспечивает целостность данных, исключает необходимость синхронизации с другими экземплярами модулей аутентификации. С другой стороны, доступность и производительность аутентификации будет зависеть от работы базы данных. Поэтому модули аутентификации следует размещать во внутреннем периметре корпоративной сети так, чтобы, с одной стороны, обеспечивать связность и приемлемое время задержки от узлов аутентификации, с другой стороны, гарантировать требуемую пропускную способность и время задержки до всех серверов баз данных.
Принимает запросы от мобильного аутентификатора, разработанного компанией MFASOFT для мобильных платформ Android и iOS, по протоколу HTTPS. Кроме того, модуль взаимодействует с сервером Redis (система управления базами данных класса NoSQL для работы со структурами «ключ-значение»), который хранит ответы пользователей на запросы аутентификации (утвердить или отклонить).
Модуль размещается в так называемой «демилитаризованной зоне» (DMZ) для того, чтобы мобильные аутентификаторы могли отправлять запросы из-за периметра корпоративной сети.
Принимает запросы от аутентификаторов 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 и запись ее в базу данных SAS. Модуль синхронизации может принимать информацию сразу для нескольких виртуальных серверов, в том числе и от нескольких агентов сразу (при условии, что все агенты имеют одинаковые настройки для одних и тех же виртуальных серверов). Передача данных от агентов зашифрована с помощью SSL. Кроме того, для верификации агентов используется идентификатор и ключ (подпись): с их помощью модуль аутентификации может удостовериться, что поток данных идет от легитимных агентов.
Объекты, созданные посредством синхронизации, могут быть изменены только модулем синхронизации LDAP – в консоли администрирования они доступны только на чтение, и ни одно из синхронизированных свойств изменить нельзя.
Для извлечения информации из каталога LDAP используется агент синхронизации LDAP (LDAP Synchronization Agent, LSA). Этот агент периодически подключается к каталогу, скачивает из него нужные свойства выбранных для синхронизации объектов и сравнивает их со своей локальной базой данных (так называемым «срезом»), в которой хранится текущая информация о синхронизированных объектах в базе SAS. Если с этими объектами произошли любые изменения (создание, удаление, модификация), то локальная база агента обновляется, и затем изменения в ней асинхронно отправляются в базу данных сервера аутентификации через модуль синхронизации LDAP. Такие события, как подключение к серверам каталога, ошибки при доступе к объектам LDAP и при записи их в базу данных SAS, регистрируются в локальном журнале LSA. Для подключения к каталогу агент может использовать как базовый протокол LDAP, так и LDAP через SSL (LDAPS). По соображениям безопасности агент рекомендуется размещать в пределах общего с сервером каталогов корпоративного сетевого периметра.
Для отправки событий на сервер syslog служит агент syslog (SysLog Agent, SLA). Он принимает сообщения от сервера аутентификации по протоколу HTTPS и отправляет их на сервер регистрации событий по протоколу syslog.
Хранит все данные и настройки продукта в таблицах реляционной базы данных, выполняет запросы на чтение и запись этих данных от любого из модулей решения. Хотя сама СУБД не входит в состав продукта Secure Authentication Server, от производительности и доступности сервера баз данных во многом зависят характеристики решения в целом.
Программные модули (агенты), через которые целевые ресурсы подключаются к модулю аутентификации. Такой агент может быть встроен или в сам целевой ресурс, или в сервис централизованной аутентификации, от которых этот агент получает имя пользователя и введенный им одноразовый пароль. Узлами аутентификации могут быть агенты для FreeRADIUS, серверов ADFS и Keycloack, а также приложения со встроенным в них агентом аутентификации (программным кодом).
Узел аутентификации отправляет по Web API введенные пользователем учетные данные на модуль аутентификации методом POST по протоколу HTTPS. Можно «привязать» разные узлы аутентификации к разным виртуальным серверам решения, указав IP-адреса, запросы от которых будут обрабатываться для пользователей из этого виртуального сервера.
Вернуться к Оглавлению.