Учёт и управление жизненным циклом аппаратных и программных средств аутентификации и электронной подписи, включая распространённые токены и смарт-карты различных поставщиков, "облачные" токены, хранящиеся на них объекты, считыватели смарт-карт, а также аппаратные и программные OTP-/U2F-аутентификаторы.
В состав системы входит производительный сервер усиленной аутентификации (2ФА) JaCarta Authentication Server (JAS) для предоставления второго фактора аутентификации компаниям, по той или иной причине не готовым к развёртыванию PKI-инфраструктуры или желающим обеспечить усиленную аутентификацию с использованием одноразовых паролей какой-то части своих сотрудников.
Автоматизация учёта токенов JaCarta, Рутокен и ESMART, в том числе сертифицированных ФСБ России как СКЗИ или обладающих несколькими функциями. Учитываются владелец, номер, модель, а также объекты на токене и рабочие станции, использующие токены. Аналогичным образом учитываются "облачные токены" (КриптоПро DSS) и сертификаты, выпускаемые для личных хранилищ пользователей и рабочих станций. Также учитываются ридеры смарт-карт производства компании "Аладдин Р.Д."
Наряду с PKI-токенами JMS ведёт и учёт аппаратных OTP-\U2F- токенов, Messaging (SMS) аутентификаторов, а также программных OTP\PUSH аутентификаторов, реализованных с использованием разработанного "Аладдин Р.Д." мобильного приложения для двухфакторной аутентификации Aladdin 2FA или сторонних приложений Google Authenticator, Яндекс.Ключ и им подобных.
Для оформления бумажных документов, таких как отчёты и заявки на выдачу токена, реализована встроенная подсистема печати.
Управлять токенами и программными средствами аутентификации на всех этапах их жизненного цикла, включая выдачу, перевыпуск и отзыв токенов и всех связанных с ними объектов (сертификатов, ключей, меток АПМДЗ и т.д.). Автоматическая синхронизация токенов и поддержка популярных удостоверяющих центров позволяют мгновенно приводить текущий парк токенов в актуальное состояние.
JMS поддерживает работу с популярными и распространёнными удостоверяющими центрами – Microsoft CA, КриптоПро 1.5 и 2.0, ViPNet 4.6 и Notary-Pro. В составе системы есть Офлайн-коннектор, позволяющий организовать работу с аттестованными удостоверяющими центрами, расположенными в изолированных контурах, не нарушая требований к информационной безопасности, предъявляемых к ним.
JMS также интегрируется с ресурсными системами (источниками информации о пользователях и рабочих станциях), в качестве которых может выступать не только Microsoft AD и Крипто Про, но и собственная служба каталогов JMS – JaCarta Directory Service (JDS).
Поддерживаются все токены и смарт карты линейки JaCarta, распространённые модели токенов и смарт-карт сторонних компаний-изготовителей (Рутокен, ESMART), а также аппаратные и программные OTP-, U2F-аутентификаторы, включая "облачные" токены (КриптоПро DSS).
С помощью реализованного в JMS механизма профилей платформа связывает между собой такие сущности, как "пользователь", "токен", "программный или аппаратный OTP-/U2F-аутентификатор" или "объект на токене". Профиль представляет собой набор правил (политик), применяемых к перечисленным сущностям. Профиль может быть применён к контейнеру (OU) ресурсной системы, группе или отдельному пользователю. В профиле, например, можно указать параметры сертификатов, выпускаемых на токены пользователей из конкретной OU. Далее при соответствующей настройке включение нового пользователя в указанный OU вызовет автоматический выпуск для него указанного сертификата и запись его на токен в процессе синхронизации (применения политик). Исключение пользователя из OU вызовет автоматический отзыв его сертификата и удаление последнего с токена пользователя.
Реализован гибкий механизм фильтрации применения политик в том числе с использованием групп безопасности Microsoft Active Directory.
Благодаря реализованным в JMS классическому “толстому” клиенту и веб-порталу самообслуживания пользователи JMS в соответствии с установленными администраторами политиками имеют возможность выполнять все необходимые разрешённые операции жизненного цикла как аппаратных токенов/смарт-карт, так и объектов, хранящихся на них. Возможности самообслуживания в равной степени относятся к аппаратным OTP-\U2F- и программным PUSH\OTP\SMS аутентификаторам. Платформа позволяет реализовать внутренний (внутри периметра организации) и внешний порталы самообслуживания с отличающимися наборами разрешённых функций.
Система JMS спроектирована с учётом высоких требований к производительности и поддерживает как вертикальную (за счёт более производительного аппаратного обеспечения), так и горизонтальную (кластеризация) масштабируемость. Более того, реализованные технологии исключают практическую возможность отказа в обслуживании клиентского запроса.
Поддерживаются кластерные технологии (NLB) и распространённые аппаратные балансировщики нагрузки. Возможность резервного копирования настроек, базы данных системы, закрытых ключей и сертификатов.
На существующих внедрениях JMS обслуживает десятки тысяч пользователей (до 100 тысяч) без внесения каких-либо ощутимых задержек в работу администраторов и пользователей.
Начиная с версии 3.5, JMS проходит нагрузочные тестирования и оптимизацию по результатам тестирования на специально разработанном в облаке стенде, позволяющем имитировать практически любую нагрузку в самых разнообразных сценариях работы платформы.
В состав JMS входит мощная система журналирования, позволяющая фиксировать все события, связанные с управлением администраторами и эксплуатацией пользователями как токенов и объектов на них, так и программных и аппаратных OTP-/U2F-аутентификаторов.
Начиная с версии 3.7 в журнале событий также регистрируются события аутентификации. Система ведёт собственный служебный журнал с удобными возможностями фильтрации событий и настройки отчётов, что облегчает проведение отчётности, диагностику неисправностей и разбор конфликтных ситуаций.
Существует возможность выгрузки информации о событиях на сервер Syslog для интеграции с SIEM-системами.
Система JMS создана в России, является полностью отечественной разработкой и включена в Единый реестр отечественного ПО (№ 311). Ориентация на российского потребителя позволяет в полной мере удовлетворить потребности заказчиков, например, такие как учёт СКЗИ в соответствии с требованиями ФСБ России.
JMS сертифицирована ФСТЭК России на соответствие 4 уровню доверия и техническим условиям (сертификат соответствия № 4411 от 20 мая 2021 года).
Для клиентов, использующих системы иностранного происхождения, например, SafeNet Authentication Manager (SAM) или Token Management System (TMS), доступна простая миграция на JMS с сохранением всех настроек и данных.
Системные требования |
» Сервер JMS
» СУБД
» АРМ пользователей (Клиент JMS, Консоль управления JMS)
|
||||||
Модели поддерживаемых электронных ключей и ридеров смарт-карт |
JaCarta
ESMART
eToken
Рутокен
|
||||||
Поддерживаемые УЦ |
|
||||||
Ресурсные системы |
|
||||||
Масштабируемость и отказоустойчивость |
|
||||||
Территориальные ограничения использования продукта | Нет (ограничения есть только при использовании сертифицированных СКЗИ) | ||||||
Необходимость наличия лицензий на распространение JMS | Нет (лицензия ФСБ России на распространение СКЗИ требуется при продаже электронных ключей с поддержкой российской криптографии, например, JaCarta ГОСТ, eToken ГОСТ, Рутокен ЭЦП) | ||||||
Локализация (поддерживаемые языки) |
|
||||||
Поддерживаемые СКЗИ (функция "Учёт СКЗИ") | В JMS реализована поддержка ключевых носителей, являющихся сертифицированными СКЗИ, таких, как JaCarta, Рутокен, ESMART, а также сертифицированных программных СКЗИ, например, КриптоПро и ViPNet CSP. Благодаря встроенным возможностям определения новых типов СКЗИ JMS позволяет вести учёт любых аппаратных и программных СКЗИ в соответствии с нормативными правилами регулятора (ФСБ России). | ||||||
Возможность добавления других моделей электронных ключей | Есть (по запросу) | ||||||
Сертификация |
ФСТЭК России Сертификат ФСТЭК России № 4411 от 20.05.2021 на соответствие ТУ и 4 уровню доверия позволяет использовать JMS для защиты информации в ИСПДн до 1 уровня включительно и при создании автоматизированных ИС до класса защищённости 1Г включительно. |
||||||
Единый реестр отечественного ПО | JMS — первая корпоративная система управления жизненным циклом средств аутентификации, включенная в Единый реестр отечественного ПО (№ 311) и рекомендуемая к закупкам государственными и муниципальными органами власти (при наличии отечественного решения государственные структуры не могут приобретать аналогичное по функциям импортное ПО) | ||||||
Масштабирование | От 100 до 1 000 000 токенов (использование JMS для работы менее чем со 100 токенами нецелесообразно) | ||||||
Дополнительные возможности | В состав платформы JMS входит (опционально) производительный сервер усиленной аутентификации (2FA) JaCarta Authentication Service (JAS) |
Сервер JMS — ядро JMS, осуществляющее централизованное управление учётными записями пользователей, токенами, политиками и т.д. Может быть установлен как единичный сервер или развёрнут как кластер. Поддерживается виртуализация и резервное копирование закрытых ключей, баз данных и настроек системы.
База данных JMS обеспечивает централизованное хранение информации об учётных записях пользователей JMS, токенах, объектах, выпущенных на токенах, политиках, настройках JMS и т.д. Значимая информация хранится в криптохранилище.
Криптохранилище — виртуальный объект (область базы данных), где хранятся критически важные данные (закрытые ключи, PIN-коды и т.д.). Криптохранилище создаётся в процессе первоначальной настройки конфигурации JMS.
Консоль управления JMS — консоль администратора, позволяющая регистрировать пользователей, выполнять операции с токенами пользователей, настраивать профили выпуска, создавать и редактировать глобальные группы JMS, выполнять планы обслуживания. Доступ к объектам и операциям в консоли управления определяется полномочиями конкретного администратора в соответствии с назначенной ему ролью.
Клиент JMS — клиентский агент JMS на стороне пользователя, который выполняет функцию синхронизации содержимого токена с данными на сервере, а также позволяет пользователю выполнять ряд операций с токеном в рамках сервиса самообслуживания (выпуск, разблокировка, отзыв).
JMS Server API — открытый API для разработки коннекторов к УЦ и ресурсным системам, собственного клиентского ПО, а также для интеграции с другими ИТ- и ИБ-системами предприятия.
JMS предоставляет открытый серверный API, обеспечивающий дополнительные возможности по расширению функциональности системы с помощью добавления новых модулей, разработки коннекторов к УЦ и ресурсным системам, создания собственного клиентского программного обеспечения, а также интеграции JMS в существующие корпоративные системы.
Схема точек расширения продукта с помощью SDK
Для интеграции JMS с внешней системой в сценариях, когда JMS является ведущей системой, необходимо применять коннектор. Коннектор к внешней системе позволяет в автоматическом режиме управлять данными, которые внешней системе требуется разместить на ключевом носителе (КН).
Для реализации прикладной логики чтения/записи данных на КН предоставляется возможность разработки собственного набора клиентских команд, которые будут выполняться в клиентском агенте и консоли управления при синхронизации КН.
Для интеграции JMS с новым типом Удостоверяющего Центра (УЦ) необходимо разработать адаптер к УЦ.
Адаптер к УЦ является расширением для встроенного в JMS коннектора – коннектора к УЦ. Коннектор к УЦ реализует общую логику работы с УЦ, а взаимодействия с конкретным типом УЦ коннектор осуществляет через адаптеры.
Для интеграции JMS с внешней системой, которая будет являться источником учетных записей пользователей и рабочих станций для JMS, необходимо разработать адаптер к ресурсной системе.
В стандартный комплект SDK описание клиентского API не входит. По запросу может быть предоставлен пример, выполняющий необходимые сценарии для встраивания в корпоративное ПО.
В числе ключевых возможностей и преимуществ, ставших доступными в версии 3.7:
По сравнению с версией 2.5 в JMS 3.0 были реализованы следующие функции:
Таблица 1 – Требования к аппаратному обеспечению JMS
Прогнозируемая нагрузка (число пользователей) |
300* - 3000** |
Требования к серверу |
Процессор: 4 ядра, Частота ≥ 2.5 ГГц ОЗУ: Min – 4 ГБ, Рекомендуется – 8 ГБ Жесткий диск: Min – 100 ГБ, Интерфейс—SATA/SAS Скорость канала до СУБД: 100 Мб/c (фактическая скорость) |
Требования к серверу БД |
Процессор: 4 ядра, Частота ≥ 2.5 ГГц ОЗУ: Min – 4 ГБ, Рекомендуется – 8 ГБ Дисковая память: RAID 1, 5 или 50, Min (суммарная емкость) – 200 ГБ, Интерфейс — SATA/SAS Примечания: Postgres - max_connections = 500 |
Требования приведены с учетом обработки сервером самых сложных и ресурсоемких сценариев со следующим набором операций:
* Сервер обработает тяжелые сценарии 1000 пользователей за 1 минуту.
** Сервер обработает тяжелые сценарии 10000 пользователей за 10 минут.
Подавляющее большинство операций в процессе выпуска сертификатов выполняются в фоновом режиме без участия пользователя. Поэтому время 10-15 минут выглядит (подтверждено практикой) вполне адекватным.
Дальнейшее увеличение характеристик сервера не дает значительного прироста производительности (итераций в секунду), упирается в предел транспортного модуля (WCF), поэтому дальнейшее увеличение производительности возможно только за счет горизонтального масштабирования.
Таблица 2 – Требования к аппаратному обеспечению кластера JMS
Прогнозируемая нагрузка (число пользователей) |
3000 - 10000 |
10000 - 20000 |
20000 - 35000 |
Число узлов в кластере |
2 |
3 |
4 |
Требования к серверу* – узлу кластера |
Процессор: 4 ядра, Частота ≥ 2.5 ГГц ОЗУ: Min – 4 ГБ, Рекомендуется – 8 ГБ Жесткий диск: Min – 100 ГБ, Интерфейс—SATA/SAS Скорость канала до СУБД: 100 Мб/c (фактическая скорость) |
Процессор: 4 ядра, Частота ≥ 2.5 ГГц ОЗУ: Min – 4 ГБ, Рекомендуется – 8 ГБ Жесткий диск: Min – 100 ГБ, Интерфейс—SATA/SAS Скорость канала до СУБД: 1 Гб/c (фактическая скорость) |
Процессор: 4 ядра, Частота ≥ 2.5 ГГц ОЗУ: Min – 4 ГБ, Рекомендуется – 8 ГБ Жесткий диск: Min – 100 ГБ, Интерфейс—SATA/SAS Скорость канала до СУБД: 1 Гб/c (фактическая скорость) |
Требования к серверу БД |
Процессор: 4 ядра, Частота ≥ 2.5 ГГц ОЗУ: Min – 4 ГБ, Рекомендуется – 6 ГБ Дисковая память: RAID 1, 5 или 50, Min (суммарная емкость) – 200 ГБ, Интерфейс — SATA/SAS |
Процессор: 8 ядер, Частота ≥ 2.5 ГГц ОЗУ: Min – 6 ГБ, Рекомендуется – 8 ГБ Дисковая память: RAID 1, 5 или 50, Min (суммарная емкость) – 200 ГБ, Интерфейс — SAS |
Процессор: 10-12 ядер, Частота ≥ 2.5 ГГц ОЗУ: Min – 8 ГБ, Рекомендуется – 10 ГБ Дисковая память: RAID 1, 5 или 50, Min (суммарная емкость) – 200 ГБ, Интерфейс — SAS |
Если в качестве сервера используется виртуальная машина, то её характеристики задаются так, чтобы производительность была равной или большей, чем указанная в таблице.