Номер извещения: 0139200000126002646

Общая информация о закупке

Внимание! За нарушение требований антимонопольного законодательства Российской Федерации о запрете участия в ограничивающих конкуренцию соглашениях, осуществления ограничивающих конкуренцию согласованных действий предусмотрена ответственность в соответствии со ст. 14.32 КоАП РФ и ст. 178 УК РФ

Способ определения поставщика (подрядчика, исполнителя): Электронный аукцион

Наименование электронной площадки в информационно-телекоммуникационной сети «Интернет»: АО «Сбербанк-АСТ»

Адрес электронной площадки в информационно-телекоммуникационной сети «Интернет»: http://www.sberbank-ast.ru

Размещение осуществляет: Уполномоченный орган ДЕПАРТАМЕНТ КОНТРАКТНОЙ СИСТЕМЫ КУЗБАССА

Наименование объекта закупки: Оказание услуг по предоставлению простых неисключительных лицензии на право использования программных продуктов Государственным бюджетным учреждением здравоохранения «Кузбасский клинический кардиологический диспансер имени академика Л.С. Барбараша»

Этап закупки: Подача заявок

Сведения о связи с позицией плана-графика: 202603393002652001000229

Контактная информация

Размещение осуществляет: Уполномоченный орган

Организация, осуществляющая размещение: ДЕПАРТАМЕНТ КОНТРАКТНОЙ СИСТЕМЫ КУЗБАССА

Почтовый адрес: 650000, г. Кемерово, пр. Советский, д. 63

Место нахождения: 650000, КЕМЕРОВСКАЯ ОБЛАСТЬ - КУЗБАСС, г.о. КЕМЕРОВСКИЙ, Г КЕМЕРОВО, ПР-КТ СОВЕТСКИЙ, Д. 63

Ответственное должностное лицо: Конради М. Р.

Адрес электронной почты: ugz@ugzko.ako.ru

Номер контактного телефона: 7-3842-585985

Факс: 7-3842-585985

Дополнительная информация: Сведения о заказчике: ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ ЗДРАВООХРАНЕНИЯ "КУЗБАССКИЙ КЛИНИЧЕСКИЙ КАРДИОЛОГИЧЕСКИЙ ДИСПАНСЕР ИМЕНИ АКАДЕМИКА Л.С. БАРБАРАША"; ИНН 4208001748; Российская Федерация, 650002, Кемеровская область - Кузбасс обл, Кемерово г, имени академика Л.С. Барбараша б-р, СТР. 6; dravun@kemcardio.ru; 7-3842-779714;

Регион: Кемеровская область - Кузбасс обл

Информация о процедуре закупки

Дата и время начала срока подачи заявок: 13.03.2026 13:27 (МСК+4)

Дата и время окончания срока подачи заявок: 25.03.2026 07:00 (МСК+4)

Дата проведения процедуры подачи предложений о цене контракта либо о сумме цен единиц товара, работы, услуги: 25.03.2026

Дата подведения итогов определения поставщика (подрядчика, исполнителя): 27.03.2026

Начальная (максимальная) цена контракта

Начальная (максимальная) цена контракта: 3 490 865,00

Валюта: РОССИЙСКИЙ РУБЛЬ

Идентификационный код закупки (ИКЗ): 263420800174842050100102020015829244

Информация об объекте закупки

Код позиции - Наименование товара, работы, услуги - Ед. измерения - Количество (объем работы, услуги) - Цена за ед., ? - Стоимость, ?

- 58.29.50.000 - Лицензия на Программный комплекс "ALD Pro" на 1 контроллер домена, (включает 8 управляемых устройств и операционную систему специального назначения «Astra Linux Special Edition» для 8 серверов) 1. Общие требования к продукту 1.1 Продукт должен быть включен в Единый реестр российских программ для электронных вычислительных машин и баз данных. 1.2 Продукт и встроенные в него программные модули должны реализовывать все описываемые функции без дополнительной разработки, закупки и установки ПО 2. Требования к серверной части o Настройка правил служб набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов для пользователей и компьютеров 2.4.3 Управление правилами SUDO, командами и группами команд SUDO: o Создание команды SUDO o Удаление команды SUDO o Создание группы команд SUDO o Удаление группы команд SUDO o Настройка правил SUDO для пользователей и компьютеров 2.5 Управление Kerberos 2.5.1 Управление службами Kerberos, в том числе создание и удаление 2.5.2 Управление политиками билетов Kerberos: o настройка срока действия билетов Kerberos o настройка максимального срока для обновления билетов Kerberos 2.6 Управление параметрами пользователей и групп 2.6.1 Управление параметрами пользователей и групп с использованием графического интерфейса Продукта 2.6.2 Управление параметрами новых пользователей и групп по умолчанию: o Настройка параметров по умолчанию для новых пользователей o Настройка параметров по умолчанию для групп 2.6.3 Расширение списка атрибутов пользователя, в том числе создание атрибута карточки пользователя: o Создание нового атрибута для карточки пользователя 2.6.4 В продукте должен быть реализован интерфейс управления учетными записями правами доступа и полномочиями, соответствующий спецификации LDAP 3. ... - Штука - 1,00 - 99 869,00 - 99 869,00

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ ЗДРАВООХРАНЕНИЯ "КУЗБАССКИЙ КЛИНИЧЕСКИЙ КАРДИОЛОГИЧЕСКИЙ ДИСПАНСЕР ИМЕНИ АКАДЕМИКА Л.С. БАРБАРАША" - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке 1. Общие требования к продукту 1.1 Продукт должен быть включен в Единый реестр российских программ для электронных вычислительных машин и баз данных. 1.2 Продукт и встроенные в него программные модули должны реализовывать все описываемые функции без дополнительной разработки, закупки и установки ПО Значение характеристики не может изменяться участником закупки 2. Требования к серверной части o Настройка правил служб набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов для пользователей и компьютеров 2.4.3 Управление правилами SUDO, командами и группами команд SUDO: o Создание команды SUDO o Удаление команды SUDO o Создание группы команд SUDO o Удаление группы команд SUDO o Настройка правил SUDO для пользователей и компьютеров 2.5 Управление Kerberos 2.5.1 Управление службами Kerberos, в том числе создание и удаление 2.5.2 Управление политиками билетов Kerberos: o настройка срока действия билетов Kerberos o настройка максимального срока для обновления билетов Kerberos 2.6 Управление параметрами пользователей и групп 2.6.1 Управление параметрами пользователей и групп с использованием графического интерфейса Продукта 2.6.2 Управление параметрами новых пользователей и групп по умолчанию: o Настройка параметров по умолчанию для новых пользователей o Настройка параметров по умолчанию для групп 2.6.3 Расширение списка атрибутов пользователя, в том числе создание атрибута карточки пользователя: o Создание нового атрибута для карточки пользователя 2.6.4 В продукте должен быть реализован интерфейс управления учетными записями правами доступа и полномочиями, соответствующий спецификации LDAP 3. Значение характеристики не может изменяться участником закупки 2.3 Управление конфигурацией домена 2.3.1 Создание, редактирование и удаление сайтов, управление параметром location идентификации сайта 2.3.2 В Продукте должна быть возможность просмотреть все сайты домена, а также карточку сайта с возможностью внесения изменений 2.3.3 Возможность изменить location параметр из карточки сайта 2.3.4 Ведение реестра серверов и ролей, привязка серверов домена к сайтам 2.3.5 Привязка домена к сайтам должна осуществляться из карточки необходимого сервера 2.3.6 Отображение связанного графа топологии домена и состояния готовности домена 2.3.7 Управление репликацией между контроллерами доменами путём добавления нового контроллера домена и создания соответствующих соглашений о репликации между конкретными контроллерами домена 2.4 Управление параметрами групповых политик 2.4.1 Управление иерархией и составом параметров групповых политик. Совместимость параметров групповых политик с версиями ОС 2.4.2 Управление правилами набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов, службами и группами служб набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов: o Создание службы набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов o Удаление службы набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов o Создание группы служб набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов o Удаление группы служб набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов 2.1.14 Продукт должен поддерживать работу в сетях IPv4 2.1.15 Продукт должен полноценно работать при отключенном NTLM версий 1 и 2 для подсистемы Управление конфигурацией домена 2.1.16 Продукт должен предусматривать механизмы отказоустойчивости на уровне приложения 2.1.17 Продукт должен обеспечивать горизонтальную масштабируемость без изменения архитектуры решения для подсистемы Управление конфигурацией домена 2.1.18 Продукт должен поддерживать георезервирование с установкой независимых компонентов в различные ЦОД для подсистемы Управление конфигурацией домена 2.1.19 Продукт должен обеспечивать восстановление своих функций после восстановления условий работоспособности при возникновении сбоев в системе электроснабжения аппаратной части; при ошибках в работе аппаратных средств; при ошибках, связанных с программным обеспечением (ОС и драйверы устройств) 2.2 Аутентификация пользователей по протоколам LDAP(S) и Kerberos 2.2.1 Поддержка возможности использования единого идентификатора для доступа ко всем разрешенным ресурсам и системам для решения задач строгой и сквозной аутентификации пользователей 2.2.2 Возможность пользователям домена авторизоваться в Продукте с использованием браузера при условии наличия соответствующих прав доступа 2.1 Общие требования к продукту 2.1.1 Продукт должен функционировать без ограничений в контуре периметра без необходимости использования внешних сервисов 2.1.2 Взаимодействие пользователей с Продуктом должно осуществляться посредством графического интерфейса (WebUI и /или GUI) 2.1.3 Графический интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать доступ ко всем функциям и операциям в рамках имеющихся у пользователя ролей и привилегий. Должен поддерживать светлую и темную тему интерфейса 2.1.4 Графический интерфейс должен быть рассчитан на использование манипулятора типа «мышь», то есть управление должно осуществляться с помощью набора экранных меню, кнопок, значков и элементов с минимизацией количества операций, выполняемых системным администратором 2.1.5 Продукт должен обеспечивать обработку аварийных ситуаций, вызванных неверными действиями системных администраторов, неверным форматом или недопустимыми значениями входных данных 2.1.6 Экранные формы должны отражать всю информацию и элементы оформления при разрешении экрана не менее 1024х768 с использованием стандартного шрифта 2.1.7 Элементы управления Продукта должны адаптироваться под контекст операции. Элементы выполнения групповых операций должны отображаться только при выборе нескольких элементов из списка 2.1.8 Все поясняющие надписи в экранных формах, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть выполнены на русском языке 2.1.9 Справочная информация по Продукту должна находиться в Продукте и позволять обратиться к ней из разделов 2.1.10 Продукт должен полноценно функционировать в контуре без необходимости использования внешних сервисов 2.1.11 Продукт должен работать на архитектуре x86 2.1.12 Архитектура Продукта должна обеспечивать централизованное управление всеми компонентами 2.1.13 Продукт должен обеспечивать развертывание всех серверных компонентов под управлением ОС Astra Linux* 2.26 Аудит событий 2.26.1 Продукт должен регистрировать события аудита информационной безопасности 2.26.2 Продукт должен регистрировать события аутентификации/авторизации (успешные, неуспешные) 2.26.3 Продукт должен регистрировать события предоставление, добавление, удаление, изменение данных каталога 2.26.3 Продукт должен регистрировать события изменение критичных параметров конфигурации 2.26.4 Продукт должен регистрировать события, связанные с выполнением технологических процессов внутри системы 2.26.5 Продукт должен поддерживать отправку событий аудита информационной безопасности по протоколу syslog 2.26.6 Продукт должен поддерживать отправку событий аудита информационной безопасности по протоколу syslog по TCP, UDP 2.26.7 Продукт должен поддерживать отправку событий аудита информационной безопасности по протоколу syslog в одном из форматов Text-based 2.26.8 Продукт должен поддерживать отправку событий аудита информационной безопасности одновременно нескольким адресатам. 2.26.9 При регистрации событий, связанных с аутентификацией, авторизацией должна регистрироваться уникальность события 2.26.10 При регистрации событий, связанных с аутентификацией, авторизацией должен регистрироваться результат операции. 2.27 Управление доверительными отношениями: односторонними (исходящими) и двусторонними, - с доменами Продукта и Microsoft Active Directory (MS AD) 2.27.1 Управление доверительными отношениями с доменами Продукта и MS AD с использованием графического интерфейса Продукта 2.27.2 Создание доверительных отношений: односторонних (исходящих) и двусторонних, - c доменами Продукта и MS AD 2.27.3 Возможность авторизации в доверенном домене Продукта и MS AD (исходящие доверительные отношения) 2.27.4 Возможность авторизации на клиентах домена Продукта и MS AD (двусторонние доверительные отношения) 2.27.5 Возможность аутентификации и авторизации под учетными записями пользователей Microsoft Active Directory в доменах под управлением Продукта 2.27.6 Миграция объектов (Учетных записей) из Microsoft Active Directory с сохранением структуры вложенности объектов. Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет; *Указание на товарный знак обусловлено необходимостью обеспечения совместимости приобретаемого программного обеспечения с существующей инфраструктурой Заказчика, в которой используются лицензии операционных систем Astra Linux. Документально подтвержденной средой функционирования, приобретаемого продукта «ALD Pro», является операционная система Astra Linux, развернутая в инфраструктуре Заказчика. В соответствии п. 1 ч. 1 ст. 33 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» поставка эквивалента не допускается. **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов. 2.24.7 При использовании механизмов репликации подсистемы Управление конфигурацией домена должна быть обеспечена поддержка более 3х соглашений репликации 2.24.8 Механизм репликации должен обеспечивать гарантированную передачу изменений из источника до получателя для подсистемы Управление конфигурацией домена 2.24.9 Механизм репликации должен обеспечивать контроль полноты и целостности передаваемых данных на всем протяжении от момента передачи до применения для подсистемы Управление конфигурацией домена 2.24.10 Работа механизмов аутентификации при использовании доверительных отношений должна продолжаться без деградации при временных прерываниях сетевого взаимодействия между доменами, участвующими в доверительных отношениях 2.24.11 Сервис Kerberos-аутентификации должен предоставляться в том числе при недоступности любой аппаратной серверной 2.24.12 Подсистема Управление конфигурацией домена должна иметь механизмы полной репликации между компонентами, реализующими подсистему хранения службы каталогов, и управления репликацией (создание/удаление правил) 2.25 Документирование в продукте Продукт должен сопровождаться подробной эксплуатационной документацией в том числе по описанию архитектуры предлагаемого решения: o Правила межсетевого экрана o Рекомендации по планированию ресурсов o Работа механизма репликации и разрешения конфликтов o Географическая балансировка нагрузки на сервисы Kerberos и LDAP o Описание работы механизма автоматического обнаружения сервисов Kerberos и LDAP o Механизм работы политик паролей и ограничения доступа к хостам - Настройка ролевой модели безопасности o Инструкция по настройке аудита o Инструкция по резервному копированию и восстановлению 2.22 Личный кабинет пользователя 2.22.1 Возможность редактирования личных данных пользователем 2.22.2 Возможность изменения собственного пароля, в том числе при истечении срока действия пароля 2.23 Парольные политики 2.23.1 Продукт должен иметь механизм контроля соответствия устанавливаемых паролей требованиям парольных политик 2.23.2 Правила парольных политик должны поддерживать ограничения на длину пароля 2.23.3 Правила парольных политик должны поддерживать требования к сложности пароля 2.23.4 Правила парольных политик должны поддерживать требования необходимости смены пароля при первом входе. 2.24 Надежность Продукта 2.24.1 Возможность предоставлять надежные и задокументированные методы для обеспечения высокой доступности 2.24.2 Возможность использовать автоматизированное развертывание своих модулей из централизованного интерфейса управления. 2.24.3 Возможность обеспечения высокой доступности (HA/DR) подсистемы Управление конфигурацией домена должно реализовывать архитектурные возможности Active-Active 2.24.4 Механизмы горизонтального масштабирования не должны иметь технических ограничений на количество узлов для подсистемы Управление конфигурацией домена 2.24.5 Продукт не должен использовать технологических решений требующих от сетевой инфраструктуры работы в растянутых (между ЦОДами) VLAN и/или через L2 Core для подсистемы Управление конфигурацией домена 2.24.6 При построении системы репликации для подсистемы Управление конфигурацией домена должны использоваться механизмы репликации средствами приложения без задействования технических средств использующих механизмы репликации ОС и/или системы хранения данных 2.17 Управление заданиями автоматизации 2.17.1 Возможность управлять заданиями автоматизации с использованием графического интерфейса Продукта 2.17.2 Настройка каталога параметров автоматизации 2.17.3 Выполнение заданий автоматизации 2.18 Мониторинг 2.18.1 Возможность осуществлять мониторинг подсистем с использованием графического интерфейса Продукта 2.18.2 Управление службой мониторинга (журнал событий, визуализация мониторинга), в том числе развёртывание серверов мониторинга, ведений журнала событий 2.18.3 Оперативный мониторинг компонент Продукта, в том числе контроль доступности и работоспособности компонентов, мониторинг ошибок репликации, постановка компонент на мониторинг 2.19 Журналирование событий 2.19.1 Возможность осуществлять журналирование событий Продукта с использованием графического интерфейса Продукта 2.19.2 Управление параметрами сбора и хранения журналов событий 2.20 Навигация и поиск объектов 2.20.1 Возможность осуществлять поиск по объектам Продукта с использованием графического интерфейса Продукта в соответствии с разделами 2.20.2 Навигация иерархического типа 2.20.3 Поиск объектов (таких, как учетные записи пользователей, учетные записи персональных компьютеров, группы безопасности и рассылки, принтеры) 2.21 Справочный центр 2.21.1 Возможность осуществлять вызов справки из любого раздела с использованием графического интерфейса Продукта 2.21.2 Наличие встроенного в Продукт справочного центра на русском языке 2.21.3 Информация в справке должна быть структурирована согласно разделам продукта 2.21.4 Возможность доступа к справочному центру из любого компонента Продукта 2.21.5 В разделе справки должны быть описаны функции подсистем Продукта в соответствии с их предназначением 2.21.6 Поиск по справке 2.21.7 Перекрестные ссылки на разделы справки в случае отсылки к другим разделам по тексту 2.21.8 Группировка по тематике и типу информации 2.13 Cлужба синхронизации времени 2.13.1 Возможность управлять службой синхронизации времени с использованием графического интерфейса Продукта 2.13.2 Управление службой синхронизации времени с использованием корневого и внешнего NTP-сервера 2.14 Служба печати 2.14.1 Возможность управлять службой печати с использованием графического интерфейса Продукта 2.14.2 Добавление принтера 2.14.3 Редактирование информации о принтере 2.14.4 Удаление принтера 2.14.5 Ведение мета-информации о принтере 2.14.6 Миграция принтеров из Microsoft Active Directory 2.15 Общий доступ к файлам 2.15.1 Создание, редактирование и удаление общих папок: o Развертывание серверов общего доступа к файлам o Создание папок общего доступа o Редактирование папок общего доступа o Удаление папок общего доступа 2.15.2 Ограничение доступа к общим папкам: Настройка схемы пользователей и групп пользователей для доступа к папке 2.16 Управление доступом 2.16.1 Возможность реализации в графическом интерфейсе Продукта 2.16.2 Делегирование роли главным администратором 2.16.3 Управление доступом путём назначения системных ролей безопасности 2.16.4 Возможность поддерживать систему прав, исключающую доступ администраторов Продукта к аутентификационной информации учетных записей, хранящихся в Продукте 2.16.5 Правила разграничения доступа должны позволять настраивать доступ для учетных записей и групп доступа 2.16.6 Правила разграничения доступа должны позволять настраивать доступ к любым объектам каталога пользователей и групп доступа 2.16.7 Правила разграничения доступа должны позволять устанавливать ограничения на определенные операции исходя из наличия привилегий учетной записи 2.16.8 Ввод в домен объектов типа «Компьютер» выполняется от имени учетной записи с полномочиями, явно указывающими на возможность выполнения такой операции, для остальных учетных записей данная функция должна быть недоступна. 2.11.4 Управление группами ПО o Создание заданий на установку и удаление ПО, в том числе на компьютеры выбранных подразделений и групп компьютеров: o Создание политик программного обеспечения o Назначение политик программного обеспечения на подразделение o Назначение политик программного обеспечения на компьютер/группу компьютеров o Принудительная установка программного обеспечения o Удаление программного обеспечения 2.11.5 Управление параметрами программного обеспечения аналогично групповым политикам с возможностью применения на компьютерах выбранных подразделений 2.11.6 Управление политиками обновления продукта 2.11.7 Взаимодействие с механизмом управления параметрами программного обеспечения должно выполняться без применения командной строки и написания скриптов 2.11.8 Возможность устанавливать ОС по сети на клиентских машинах домена с использованием графического интерфейса Продукта 2.11.9 Разворачивание сервера установки ОС по сети 2.11.10 Редактирование скриптов сценария установки ОС по сети: o preseed o postinstall o boot-меню o первого запуска 2.11.11 Импорт конфигурации сценария установки ОС по сети 2.11.12 Создание профилей компьютеров, на которые планируется осуществлять установку ОС по сети 2.11.13 Выполнение установки ОС по сети на выбранных компьютерах 2.11.14 Ввод в домен и конфигурация рабочей станции после установки ОС по сети 2.12 Служба разрешения имен 2.12.1 Возможность управлять службами разрешения имен с использованием графического интерфейса Продукта 2.12.2 Управление перенаправлением DNS запросов: Создание зон перенаправления (перенаправление запросов) 2.12.3 Возможность управлять службой динамической настройки узла с использованием графического интерфейса Продукта Управление службой DHCP: o Развертывание серверов динамической настройки узла (DHCP) o Импорт файла конфигурации DHCP o Настройка конфигурации DHCP o Настройка сетевых интерфейсов DHCP o Использование внешнего сервера DHCP 2.9 Управление групповыми политиками 2.9.1 Управление групповыми политиками с использованием графического интерфейса Продукта 2.9.2 Создание, редактирование, удаление групповых политик 2.9.3 Назначение групповых политик на подразделения 2.9.4 Обновление конфигурации и применение параметров групповых политик, ПО и правил сбора событий на клиентах при включении компьютера 2.9.5 Обновление конфигурации и применение параметров групповых политик, ПО и правил сбора событий на клиентах по таймеру каждые 30 минут с возможностью добавления произвольного отклонения от 5 до 50 минут 2.9.6 Возможность принудительного обновления конфигурации и применения параметров 2.9.7 Групповые политики, политики ПО и задания автоматизации хранятся в LDAP 2.9.8 Механизм наследования и суммирования параметров групповых политик 2.9.9 Возможность включения и отключения параметра, а также установка необходимых значений параметра групповой политики, которые будут применены на целевом компьютере и пользователе 2.9.10 Возможность установки приоритета применения групповой политики в рамках назначенного подразделения 2.10 Удаленный доступ 2.10.1 Удаленное подключение к рабочему столу пользователя с использованием графического интерфейса Продукта, с полным доступом и в режиме просмотра 2.10.2 Удаленное подключение к рабочему столу пользователя с использованием клиентского кода доступа 2.11 Установка и обновление программного обеспечения 2.11.1 Возможность устанавливать и обновлять программное обеспечения на клиентских машинах домена с использованием графического интерфейса Продукта 2.11.2 Управление репозиториями ПО 2.11.3 Возможность репликации репозиториев ПО: o Развертывание сервера репозитриев программного обеспечения o Создание репозитория программного обеспечения o Загрузка iso-образов из файла o Загрузка пакетов из файла o Редактирование репозиториев программного обеспечения o Удаление репозиториев программного обеспечения 2.7 Управление глобальным каталогом и модулем синхронизации 2.7.1 Синхронизация пользователей и групп пользователей продукта с глобальным каталогом 2.7.2 Форсированная установка нового сервера глобального каталога 2.7.3 Синхронизация паролей, подразделений, пользователей и групп пользователей: o односторонняя (MS AD ? Продукт) синхронизация подразделений, пользователей и групп пользователей o двусторонняя (MS AD ? Продукт) синхронизация паролей Обработка запрещенных символов при синхронизации пользователей, групп, подразделений. 2.8 Управление организационной структурой, пользователями и компьютерами 2.8.1 Управление организационной структурой, пользователями и компьютерами с использованием графического интерфейса Продукта 2.8.2 Возможность настройки организационной структуры подразделений в иерархическом виде. При выборе подразделения, в интерфейсе Продукта должны отображаться объекты, которые входят в данное подразделение: o Пользователи o Группы пользователей o Компьютеры o Группы компьютеров 2.8.3 Управление подразделениями: o Создание подразделения o Редактирование информации о подразделении 2.8.4 Настройка иерархии подразделений в соответствии со структурой организации o Добавление дочерних подразделений o Привязка подразделений к вышестоящим подразделениям организации 2.8.5 Управление пользователями и группами пользователей o Создание групп пользователей o Создание учетной записи пользователя o Редактирование учетной записи пользователя o Включение пользователя в группу пользователей o Привязка пользователя к подразделению o Быстрое восстановление удалённых пользователей (режим «корзины») 2.8.6 Управление компьютерами и группами компьютеров o Создание групп компьютеров o Редактирование учетной записи компьютера o Включение компьютера в группу компьютеров o Удаление учетной записи компьютера o Удаление группы компьютеров - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - 1. Общие требования к продукту - 1.1 Продукт должен быть включен в Единый реестр российских программ для электронных вычислительных машин и баз данных. 1.2 Продукт и встроенные в него программные модули должны реализовывать все описываемые функции без дополнительной разработки, закупки и установки ПО - - Значение характеристики не может изменяться участником закупки - 2. Требования к серверной части - o Настройка правил служб набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов для пользователей и компьютеров 2.4.3 Управление правилами SUDO, командами и группами команд SUDO: o Создание команды SUDO o Удаление команды SUDO o Создание группы команд SUDO o Удаление группы команд SUDO o Настройка правил SUDO для пользователей и компьютеров 2.5 Управление Kerberos 2.5.1 Управление службами Kerberos, в том числе создание и удаление 2.5.2 Управление политиками билетов Kerberos: o настройка срока действия билетов Kerberos o настройка максимального срока для обновления билетов Kerberos 2.6 Управление параметрами пользователей и групп 2.6.1 Управление параметрами пользователей и групп с использованием графического интерфейса Продукта 2.6.2 Управление параметрами новых пользователей и групп по умолчанию: o Настройка параметров по умолчанию для новых пользователей o Настройка параметров по умолчанию для групп 2.6.3 Расширение списка атрибутов пользователя, в том числе создание атрибута карточки пользователя: o Создание нового атрибута для карточки пользователя 2.6.4 В продукте должен быть реализован интерфейс управления учетными записями правами доступа и полномочиями, соответствующий спецификации LDAP 3. - - Значение характеристики не может изменяться участником закупки - 2.3 Управление конфигурацией домена 2.3.1 Создание, редактирование и удаление сайтов, управление параметром location идентификации сайта 2.3.2 В Продукте должна быть возможность просмотреть все сайты домена, а также карточку сайта с возможностью внесения изменений 2.3.3 Возможность изменить location параметр из карточки сайта 2.3.4 Ведение реестра серверов и ролей, привязка серверов домена к сайтам 2.3.5 Привязка домена к сайтам должна осуществляться из карточки необходимого сервера 2.3.6 Отображение связанного графа топологии домена и состояния готовности домена 2.3.7 Управление репликацией между контроллерами доменами путём добавления нового контроллера домена и создания соответствующих соглашений о репликации между конкретными контроллерами домена 2.4 Управление параметрами групповых политик 2.4.1 Управление иерархией и составом параметров групповых политик. Совместимость параметров групповых политик с версиями ОС 2.4.2 Управление правилами набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов, службами и группами служб набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов: o Создание службы набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов o Удаление службы набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов o Создание группы служб набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов o Удаление группы служб набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов - 2.1.14 Продукт должен поддерживать работу в сетях IPv4 2.1.15 Продукт должен полноценно работать при отключенном NTLM версий 1 и 2 для подсистемы Управление конфигурацией домена 2.1.16 Продукт должен предусматривать механизмы отказоустойчивости на уровне приложения 2.1.17 Продукт должен обеспечивать горизонтальную масштабируемость без изменения архитектуры решения для подсистемы Управление конфигурацией домена 2.1.18 Продукт должен поддерживать георезервирование с установкой независимых компонентов в различные ЦОД для подсистемы Управление конфигурацией домена 2.1.19 Продукт должен обеспечивать восстановление своих функций после восстановления условий работоспособности при возникновении сбоев в системе электроснабжения аппаратной части; при ошибках в работе аппаратных средств; при ошибках, связанных с программным обеспечением (ОС и драйверы устройств) 2.2 Аутентификация пользователей по протоколам LDAP(S) и Kerberos 2.2.1 Поддержка возможности использования единого идентификатора для доступа ко всем разрешенным ресурсам и системам для решения задач строгой и сквозной аутентификации пользователей 2.2.2 Возможность пользователям домена авторизоваться в Продукте с использованием браузера при условии наличия соответствующих прав доступа - 2.1 Общие требования к продукту 2.1.1 Продукт должен функционировать без ограничений в контуре периметра без необходимости использования внешних сервисов 2.1.2 Взаимодействие пользователей с Продуктом должно осуществляться посредством графического интерфейса (WebUI и /или GUI) 2.1.3 Графический интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать доступ ко всем функциям и операциям в рамках имеющихся у пользователя ролей и привилегий. Должен поддерживать светлую и темную тему интерфейса 2.1.4 Графический интерфейс должен быть рассчитан на использование манипулятора типа «мышь», то есть управление должно осуществляться с помощью набора экранных меню, кнопок, значков и элементов с минимизацией количества операций, выполняемых системным администратором 2.1.5 Продукт должен обеспечивать обработку аварийных ситуаций, вызванных неверными действиями системных администраторов, неверным форматом или недопустимыми значениями входных данных 2.1.6 Экранные формы должны отражать всю информацию и элементы оформления при разрешении экрана не менее 1024х768 с использованием стандартного шрифта 2.1.7 Элементы управления Продукта должны адаптироваться под контекст операции. Элементы выполнения групповых операций должны отображаться только при выборе нескольких элементов из списка 2.1.8 Все поясняющие надписи в экранных формах, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть выполнены на русском языке 2.1.9 Справочная информация по Продукту должна находиться в Продукте и позволять обратиться к ней из разделов 2.1.10 Продукт должен полноценно функционировать в контуре без необходимости использования внешних сервисов 2.1.11 Продукт должен работать на архитектуре x86 2.1.12 Архитектура Продукта должна обеспечивать централизованное управление всеми компонентами 2.1.13 Продукт должен обеспечивать развертывание всех серверных компонентов под управлением ОС Astra Linux* - 2.26 Аудит событий 2.26.1 Продукт должен регистрировать события аудита информационной безопасности 2.26.2 Продукт должен регистрировать события аутентификации/авторизации (успешные, неуспешные) 2.26.3 Продукт должен регистрировать события предоставление, добавление, удаление, изменение данных каталога 2.26.3 Продукт должен регистрировать события изменение критичных параметров конфигурации 2.26.4 Продукт должен регистрировать события, связанные с выполнением технологических процессов внутри системы 2.26.5 Продукт должен поддерживать отправку событий аудита информационной безопасности по протоколу syslog 2.26.6 Продукт должен поддерживать отправку событий аудита информационной безопасности по протоколу syslog по TCP, UDP 2.26.7 Продукт должен поддерживать отправку событий аудита информационной безопасности по протоколу syslog в одном из форматов Text-based 2.26.8 Продукт должен поддерживать отправку событий аудита информационной безопасности одновременно нескольким адресатам. 2.26.9 При регистрации событий, связанных с аутентификацией, авторизацией должна регистрироваться уникальность события 2.26.10 При регистрации событий, связанных с аутентификацией, авторизацией должен регистрироваться результат операции. 2.27 Управление доверительными отношениями: односторонними (исходящими) и двусторонними, - с доменами Продукта и Microsoft Active Directory (MS AD) 2.27.1 Управление доверительными отношениями с доменами Продукта и MS AD с использованием графического интерфейса Продукта 2.27.2 Создание доверительных отношений: односторонних (исходящих) и двусторонних, - c доменами Продукта и MS AD 2.27.3 Возможность авторизации в доверенном домене Продукта и MS AD (исходящие доверительные отношения) 2.27.4 Возможность авторизации на клиентах домена Продукта и MS AD (двусторонние доверительные отношения) 2.27.5 Возможность аутентификации и авторизации под учетными записями пользователей Microsoft Active Directory в доменах под управлением Продукта - 2.27.6 Миграция объектов (Учетных записей) из Microsoft Active Directory с сохранением структуры вложенности объектов. Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет; *Указание на товарный знак обусловлено необходимостью обеспечения совместимости приобретаемого программного обеспечения с существующей инфраструктурой Заказчика, в которой используются лицензии операционных систем Astra Linux. Документально подтвержденной средой функционирования, приобретаемого продукта «ALD Pro», является операционная система Astra Linux, развернутая в инфраструктуре Заказчика. В соответствии п. 1 ч. 1 ст. 33 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» поставка эквивалента не допускается. **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов. - 2.24.7 При использовании механизмов репликации подсистемы Управление конфигурацией домена должна быть обеспечена поддержка более 3х соглашений репликации 2.24.8 Механизм репликации должен обеспечивать гарантированную передачу изменений из источника до получателя для подсистемы Управление конфигурацией домена 2.24.9 Механизм репликации должен обеспечивать контроль полноты и целостности передаваемых данных на всем протяжении от момента передачи до применения для подсистемы Управление конфигурацией домена 2.24.10 Работа механизмов аутентификации при использовании доверительных отношений должна продолжаться без деградации при временных прерываниях сетевого взаимодействия между доменами, участвующими в доверительных отношениях 2.24.11 Сервис Kerberos-аутентификации должен предоставляться в том числе при недоступности любой аппаратной серверной 2.24.12 Подсистема Управление конфигурацией домена должна иметь механизмы полной репликации между компонентами, реализующими подсистему хранения службы каталогов, и управления репликацией (создание/удаление правил) 2.25 Документирование в продукте Продукт должен сопровождаться подробной эксплуатационной документацией в том числе по описанию архитектуры предлагаемого решения: o Правила межсетевого экрана o Рекомендации по планированию ресурсов o Работа механизма репликации и разрешения конфликтов o Географическая балансировка нагрузки на сервисы Kerberos и LDAP o Описание работы механизма автоматического обнаружения сервисов Kerberos и LDAP o Механизм работы политик паролей и ограничения доступа к хостам - Настройка ролевой модели безопасности o Инструкция по настройке аудита o Инструкция по резервному копированию и восстановлению - 2.22 Личный кабинет пользователя 2.22.1 Возможность редактирования личных данных пользователем 2.22.2 Возможность изменения собственного пароля, в том числе при истечении срока действия пароля 2.23 Парольные политики 2.23.1 Продукт должен иметь механизм контроля соответствия устанавливаемых паролей требованиям парольных политик 2.23.2 Правила парольных политик должны поддерживать ограничения на длину пароля 2.23.3 Правила парольных политик должны поддерживать требования к сложности пароля 2.23.4 Правила парольных политик должны поддерживать требования необходимости смены пароля при первом входе. 2.24 Надежность Продукта 2.24.1 Возможность предоставлять надежные и задокументированные методы для обеспечения высокой доступности 2.24.2 Возможность использовать автоматизированное развертывание своих модулей из централизованного интерфейса управления. 2.24.3 Возможность обеспечения высокой доступности (HA/DR) подсистемы Управление конфигурацией домена должно реализовывать архитектурные возможности Active-Active 2.24.4 Механизмы горизонтального масштабирования не должны иметь технических ограничений на количество узлов для подсистемы Управление конфигурацией домена 2.24.5 Продукт не должен использовать технологических решений требующих от сетевой инфраструктуры работы в растянутых (между ЦОДами) VLAN и/или через L2 Core для подсистемы Управление конфигурацией домена 2.24.6 При построении системы репликации для подсистемы Управление конфигурацией домена должны использоваться механизмы репликации средствами приложения без задействования технических средств использующих механизмы репликации ОС и/или системы хранения данных - 2.17 Управление заданиями автоматизации 2.17.1 Возможность управлять заданиями автоматизации с использованием графического интерфейса Продукта 2.17.2 Настройка каталога параметров автоматизации 2.17.3 Выполнение заданий автоматизации 2.18 Мониторинг 2.18.1 Возможность осуществлять мониторинг подсистем с использованием графического интерфейса Продукта 2.18.2 Управление службой мониторинга (журнал событий, визуализация мониторинга), в том числе развёртывание серверов мониторинга, ведений журнала событий 2.18.3 Оперативный мониторинг компонент Продукта, в том числе контроль доступности и работоспособности компонентов, мониторинг ошибок репликации, постановка компонент на мониторинг 2.19 Журналирование событий 2.19.1 Возможность осуществлять журналирование событий Продукта с использованием графического интерфейса Продукта 2.19.2 Управление параметрами сбора и хранения журналов событий 2.20 Навигация и поиск объектов 2.20.1 Возможность осуществлять поиск по объектам Продукта с использованием графического интерфейса Продукта в соответствии с разделами 2.20.2 Навигация иерархического типа 2.20.3 Поиск объектов (таких, как учетные записи пользователей, учетные записи персональных компьютеров, группы безопасности и рассылки, принтеры) 2.21 Справочный центр 2.21.1 Возможность осуществлять вызов справки из любого раздела с использованием графического интерфейса Продукта 2.21.2 Наличие встроенного в Продукт справочного центра на русском языке 2.21.3 Информация в справке должна быть структурирована согласно разделам продукта 2.21.4 Возможность доступа к справочному центру из любого компонента Продукта 2.21.5 В разделе справки должны быть описаны функции подсистем Продукта в соответствии с их предназначением 2.21.6 Поиск по справке 2.21.7 Перекрестные ссылки на разделы справки в случае отсылки к другим разделам по тексту 2.21.8 Группировка по тематике и типу информации - 2.13 Cлужба синхронизации времени 2.13.1 Возможность управлять службой синхронизации времени с использованием графического интерфейса Продукта 2.13.2 Управление службой синхронизации времени с использованием корневого и внешнего NTP-сервера 2.14 Служба печати 2.14.1 Возможность управлять службой печати с использованием графического интерфейса Продукта 2.14.2 Добавление принтера 2.14.3 Редактирование информации о принтере 2.14.4 Удаление принтера 2.14.5 Ведение мета-информации о принтере 2.14.6 Миграция принтеров из Microsoft Active Directory 2.15 Общий доступ к файлам 2.15.1 Создание, редактирование и удаление общих папок: o Развертывание серверов общего доступа к файлам o Создание папок общего доступа o Редактирование папок общего доступа o Удаление папок общего доступа 2.15.2 Ограничение доступа к общим папкам: Настройка схемы пользователей и групп пользователей для доступа к папке 2.16 Управление доступом 2.16.1 Возможность реализации в графическом интерфейсе Продукта 2.16.2 Делегирование роли главным администратором 2.16.3 Управление доступом путём назначения системных ролей безопасности 2.16.4 Возможность поддерживать систему прав, исключающую доступ администраторов Продукта к аутентификационной информации учетных записей, хранящихся в Продукте 2.16.5 Правила разграничения доступа должны позволять настраивать доступ для учетных записей и групп доступа 2.16.6 Правила разграничения доступа должны позволять настраивать доступ к любым объектам каталога пользователей и групп доступа 2.16.7 Правила разграничения доступа должны позволять устанавливать ограничения на определенные операции исходя из наличия привилегий учетной записи 2.16.8 Ввод в домен объектов типа «Компьютер» выполняется от имени учетной записи с полномочиями, явно указывающими на возможность выполнения такой операции, для остальных учетных записей данная функция должна быть недоступна. - 2.11.4 Управление группами ПО o Создание заданий на установку и удаление ПО, в том числе на компьютеры выбранных подразделений и групп компьютеров: o Создание политик программного обеспечения o Назначение политик программного обеспечения на подразделение o Назначение политик программного обеспечения на компьютер/группу компьютеров o Принудительная установка программного обеспечения o Удаление программного обеспечения 2.11.5 Управление параметрами программного обеспечения аналогично групповым политикам с возможностью применения на компьютерах выбранных подразделений 2.11.6 Управление политиками обновления продукта 2.11.7 Взаимодействие с механизмом управления параметрами программного обеспечения должно выполняться без применения командной строки и написания скриптов 2.11.8 Возможность устанавливать ОС по сети на клиентских машинах домена с использованием графического интерфейса Продукта 2.11.9 Разворачивание сервера установки ОС по сети 2.11.10 Редактирование скриптов сценария установки ОС по сети: o preseed o postinstall o boot-меню o первого запуска 2.11.11 Импорт конфигурации сценария установки ОС по сети 2.11.12 Создание профилей компьютеров, на которые планируется осуществлять установку ОС по сети 2.11.13 Выполнение установки ОС по сети на выбранных компьютерах 2.11.14 Ввод в домен и конфигурация рабочей станции после установки ОС по сети 2.12 Служба разрешения имен 2.12.1 Возможность управлять службами разрешения имен с использованием графического интерфейса Продукта 2.12.2 Управление перенаправлением DNS запросов: Создание зон перенаправления (перенаправление запросов) 2.12.3 Возможность управлять службой динамической настройки узла с использованием графического интерфейса Продукта Управление службой DHCP: o Развертывание серверов динамической настройки узла (DHCP) o Импорт файла конфигурации DHCP o Настройка конфигурации DHCP o Настройка сетевых интерфейсов DHCP o Использование внешнего сервера DHCP - 2.9 Управление групповыми политиками 2.9.1 Управление групповыми политиками с использованием графического интерфейса Продукта 2.9.2 Создание, редактирование, удаление групповых политик 2.9.3 Назначение групповых политик на подразделения 2.9.4 Обновление конфигурации и применение параметров групповых политик, ПО и правил сбора событий на клиентах при включении компьютера 2.9.5 Обновление конфигурации и применение параметров групповых политик, ПО и правил сбора событий на клиентах по таймеру каждые 30 минут с возможностью добавления произвольного отклонения от 5 до 50 минут 2.9.6 Возможность принудительного обновления конфигурации и применения параметров 2.9.7 Групповые политики, политики ПО и задания автоматизации хранятся в LDAP 2.9.8 Механизм наследования и суммирования параметров групповых политик 2.9.9 Возможность включения и отключения параметра, а также установка необходимых значений параметра групповой политики, которые будут применены на целевом компьютере и пользователе 2.9.10 Возможность установки приоритета применения групповой политики в рамках назначенного подразделения 2.10 Удаленный доступ 2.10.1 Удаленное подключение к рабочему столу пользователя с использованием графического интерфейса Продукта, с полным доступом и в режиме просмотра 2.10.2 Удаленное подключение к рабочему столу пользователя с использованием клиентского кода доступа 2.11 Установка и обновление программного обеспечения 2.11.1 Возможность устанавливать и обновлять программное обеспечения на клиентских машинах домена с использованием графического интерфейса Продукта 2.11.2 Управление репозиториями ПО 2.11.3 Возможность репликации репозиториев ПО: o Развертывание сервера репозитриев программного обеспечения o Создание репозитория программного обеспечения o Загрузка iso-образов из файла o Загрузка пакетов из файла o Редактирование репозиториев программного обеспечения o Удаление репозиториев программного обеспечения - 2.7 Управление глобальным каталогом и модулем синхронизации 2.7.1 Синхронизация пользователей и групп пользователей продукта с глобальным каталогом 2.7.2 Форсированная установка нового сервера глобального каталога 2.7.3 Синхронизация паролей, подразделений, пользователей и групп пользователей: o односторонняя (MS AD ? Продукт) синхронизация подразделений, пользователей и групп пользователей o двусторонняя (MS AD ? Продукт) синхронизация паролей Обработка запрещенных символов при синхронизации пользователей, групп, подразделений. 2.8 Управление организационной структурой, пользователями и компьютерами 2.8.1 Управление организационной структурой, пользователями и компьютерами с использованием графического интерфейса Продукта 2.8.2 Возможность настройки организационной структуры подразделений в иерархическом виде. При выборе подразделения, в интерфейсе Продукта должны отображаться объекты, которые входят в данное подразделение: o Пользователи o Группы пользователей o Компьютеры o Группы компьютеров 2.8.3 Управление подразделениями: o Создание подразделения o Редактирование информации о подразделении 2.8.4 Настройка иерархии подразделений в соответствии со структурой организации o Добавление дочерних подразделений o Привязка подразделений к вышестоящим подразделениям организации 2.8.5 Управление пользователями и группами пользователей o Создание групп пользователей o Создание учетной записи пользователя o Редактирование учетной записи пользователя o Включение пользователя в группу пользователей o Привязка пользователя к подразделению o Быстрое восстановление удалённых пользователей (режим «корзины») 2.8.6 Управление компьютерами и группами компьютеров o Создание групп компьютеров o Редактирование учетной записи компьютера o Включение компьютера в группу компьютеров o Удаление учетной записи компьютера o Удаление группы компьютеров

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

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

2. Требования к серверной части - o Настройка правил служб набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов для пользователей и компьютеров 2.4.3 Управление правилами SUDO, командами и группами команд SUDO: o Создание команды SUDO o Удаление команды SUDO o Создание группы команд SUDO o Удаление группы команд SUDO o Настройка правил SUDO для пользователей и компьютеров 2.5 Управление Kerberos 2.5.1 Управление службами Kerberos, в том числе создание и удаление 2.5.2 Управление политиками билетов Kerberos: o настройка срока действия билетов Kerberos o настройка максимального срока для обновления билетов Kerberos 2.6 Управление параметрами пользователей и групп 2.6.1 Управление параметрами пользователей и групп с использованием графического интерфейса Продукта 2.6.2 Управление параметрами новых пользователей и групп по умолчанию: o Настройка параметров по умолчанию для новых пользователей o Настройка параметров по умолчанию для групп 2.6.3 Расширение списка атрибутов пользователя, в том числе создание атрибута карточки пользователя: o Создание нового атрибута для карточки пользователя 2.6.4 В продукте должен быть реализован интерфейс управления учетными записями правами доступа и полномочиями, соответствующий спецификации LDAP 3. - - Значение характеристики не может изменяться участником закупки

2.3 Управление конфигурацией домена 2.3.1 Создание, редактирование и удаление сайтов, управление параметром location идентификации сайта 2.3.2 В Продукте должна быть возможность просмотреть все сайты домена, а также карточку сайта с возможностью внесения изменений 2.3.3 Возможность изменить location параметр из карточки сайта 2.3.4 Ведение реестра серверов и ролей, привязка серверов домена к сайтам 2.3.5 Привязка домена к сайтам должна осуществляться из карточки необходимого сервера 2.3.6 Отображение связанного графа топологии домена и состояния готовности домена 2.3.7 Управление репликацией между контроллерами доменами путём добавления нового контроллера домена и создания соответствующих соглашений о репликации между конкретными контроллерами домена 2.4 Управление параметрами групповых политик 2.4.1 Управление иерархией и составом параметров групповых политик. Совместимость параметров групповых политик с версиями ОС 2.4.2 Управление правилами набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов, службами и группами служб набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов: o Создание службы набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов o Удаление службы набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов o Создание группы служб набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов o Удаление группы служб набора правил для настройки доступа пользователей и групп пользователей к определенным хостам с использованием определенных сервисов

2.1.14 Продукт должен поддерживать работу в сетях IPv4 2.1.15 Продукт должен полноценно работать при отключенном NTLM версий 1 и 2 для подсистемы Управление конфигурацией домена 2.1.16 Продукт должен предусматривать механизмы отказоустойчивости на уровне приложения 2.1.17 Продукт должен обеспечивать горизонтальную масштабируемость без изменения архитектуры решения для подсистемы Управление конфигурацией домена 2.1.18 Продукт должен поддерживать георезервирование с установкой независимых компонентов в различные ЦОД для подсистемы Управление конфигурацией домена 2.1.19 Продукт должен обеспечивать восстановление своих функций после восстановления условий работоспособности при возникновении сбоев в системе электроснабжения аппаратной части; при ошибках в работе аппаратных средств; при ошибках, связанных с программным обеспечением (ОС и драйверы устройств) 2.2 Аутентификация пользователей по протоколам LDAP(S) и Kerberos 2.2.1 Поддержка возможности использования единого идентификатора для доступа ко всем разрешенным ресурсам и системам для решения задач строгой и сквозной аутентификации пользователей 2.2.2 Возможность пользователям домена авторизоваться в Продукте с использованием браузера при условии наличия соответствующих прав доступа

2.1 Общие требования к продукту 2.1.1 Продукт должен функционировать без ограничений в контуре периметра без необходимости использования внешних сервисов 2.1.2 Взаимодействие пользователей с Продуктом должно осуществляться посредством графического интерфейса (WebUI и /или GUI) 2.1.3 Графический интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать доступ ко всем функциям и операциям в рамках имеющихся у пользователя ролей и привилегий. Должен поддерживать светлую и темную тему интерфейса 2.1.4 Графический интерфейс должен быть рассчитан на использование манипулятора типа «мышь», то есть управление должно осуществляться с помощью набора экранных меню, кнопок, значков и элементов с минимизацией количества операций, выполняемых системным администратором 2.1.5 Продукт должен обеспечивать обработку аварийных ситуаций, вызванных неверными действиями системных администраторов, неверным форматом или недопустимыми значениями входных данных 2.1.6 Экранные формы должны отражать всю информацию и элементы оформления при разрешении экрана не менее 1024х768 с использованием стандартного шрифта 2.1.7 Элементы управления Продукта должны адаптироваться под контекст операции. Элементы выполнения групповых операций должны отображаться только при выборе нескольких элементов из списка 2.1.8 Все поясняющие надписи в экранных формах, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть выполнены на русском языке 2.1.9 Справочная информация по Продукту должна находиться в Продукте и позволять обратиться к ней из разделов 2.1.10 Продукт должен полноценно функционировать в контуре без необходимости использования внешних сервисов 2.1.11 Продукт должен работать на архитектуре x86 2.1.12 Архитектура Продукта должна обеспечивать централизованное управление всеми компонентами 2.1.13 Продукт должен обеспечивать развертывание всех серверных компонентов под управлением ОС Astra Linux*

2.26 Аудит событий 2.26.1 Продукт должен регистрировать события аудита информационной безопасности 2.26.2 Продукт должен регистрировать события аутентификации/авторизации (успешные, неуспешные) 2.26.3 Продукт должен регистрировать события предоставление, добавление, удаление, изменение данных каталога 2.26.3 Продукт должен регистрировать события изменение критичных параметров конфигурации 2.26.4 Продукт должен регистрировать события, связанные с выполнением технологических процессов внутри системы 2.26.5 Продукт должен поддерживать отправку событий аудита информационной безопасности по протоколу syslog 2.26.6 Продукт должен поддерживать отправку событий аудита информационной безопасности по протоколу syslog по TCP, UDP 2.26.7 Продукт должен поддерживать отправку событий аудита информационной безопасности по протоколу syslog в одном из форматов Text-based 2.26.8 Продукт должен поддерживать отправку событий аудита информационной безопасности одновременно нескольким адресатам. 2.26.9 При регистрации событий, связанных с аутентификацией, авторизацией должна регистрироваться уникальность события 2.26.10 При регистрации событий, связанных с аутентификацией, авторизацией должен регистрироваться результат операции. 2.27 Управление доверительными отношениями: односторонними (исходящими) и двусторонними, - с доменами Продукта и Microsoft Active Directory (MS AD) 2.27.1 Управление доверительными отношениями с доменами Продукта и MS AD с использованием графического интерфейса Продукта 2.27.2 Создание доверительных отношений: односторонних (исходящих) и двусторонних, - c доменами Продукта и MS AD 2.27.3 Возможность авторизации в доверенном домене Продукта и MS AD (исходящие доверительные отношения) 2.27.4 Возможность авторизации на клиентах домена Продукта и MS AD (двусторонние доверительные отношения) 2.27.5 Возможность аутентификации и авторизации под учетными записями пользователей Microsoft Active Directory в доменах под управлением Продукта

2.27.6 Миграция объектов (Учетных записей) из Microsoft Active Directory с сохранением структуры вложенности объектов. Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет; *Указание на товарный знак обусловлено необходимостью обеспечения совместимости приобретаемого программного обеспечения с существующей инфраструктурой Заказчика, в которой используются лицензии операционных систем Astra Linux. Документально подтвержденной средой функционирования, приобретаемого продукта «ALD Pro», является операционная система Astra Linux, развернутая в инфраструктуре Заказчика. В соответствии п. 1 ч. 1 ст. 33 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» поставка эквивалента не допускается. **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов.

2.24.7 При использовании механизмов репликации подсистемы Управление конфигурацией домена должна быть обеспечена поддержка более 3х соглашений репликации 2.24.8 Механизм репликации должен обеспечивать гарантированную передачу изменений из источника до получателя для подсистемы Управление конфигурацией домена 2.24.9 Механизм репликации должен обеспечивать контроль полноты и целостности передаваемых данных на всем протяжении от момента передачи до применения для подсистемы Управление конфигурацией домена 2.24.10 Работа механизмов аутентификации при использовании доверительных отношений должна продолжаться без деградации при временных прерываниях сетевого взаимодействия между доменами, участвующими в доверительных отношениях 2.24.11 Сервис Kerberos-аутентификации должен предоставляться в том числе при недоступности любой аппаратной серверной 2.24.12 Подсистема Управление конфигурацией домена должна иметь механизмы полной репликации между компонентами, реализующими подсистему хранения службы каталогов, и управления репликацией (создание/удаление правил) 2.25 Документирование в продукте Продукт должен сопровождаться подробной эксплуатационной документацией в том числе по описанию архитектуры предлагаемого решения: o Правила межсетевого экрана o Рекомендации по планированию ресурсов o Работа механизма репликации и разрешения конфликтов o Географическая балансировка нагрузки на сервисы Kerberos и LDAP o Описание работы механизма автоматического обнаружения сервисов Kerberos и LDAP o Механизм работы политик паролей и ограничения доступа к хостам - Настройка ролевой модели безопасности o Инструкция по настройке аудита o Инструкция по резервному копированию и восстановлению

2.22 Личный кабинет пользователя 2.22.1 Возможность редактирования личных данных пользователем 2.22.2 Возможность изменения собственного пароля, в том числе при истечении срока действия пароля 2.23 Парольные политики 2.23.1 Продукт должен иметь механизм контроля соответствия устанавливаемых паролей требованиям парольных политик 2.23.2 Правила парольных политик должны поддерживать ограничения на длину пароля 2.23.3 Правила парольных политик должны поддерживать требования к сложности пароля 2.23.4 Правила парольных политик должны поддерживать требования необходимости смены пароля при первом входе. 2.24 Надежность Продукта 2.24.1 Возможность предоставлять надежные и задокументированные методы для обеспечения высокой доступности 2.24.2 Возможность использовать автоматизированное развертывание своих модулей из централизованного интерфейса управления. 2.24.3 Возможность обеспечения высокой доступности (HA/DR) подсистемы Управление конфигурацией домена должно реализовывать архитектурные возможности Active-Active 2.24.4 Механизмы горизонтального масштабирования не должны иметь технических ограничений на количество узлов для подсистемы Управление конфигурацией домена 2.24.5 Продукт не должен использовать технологических решений требующих от сетевой инфраструктуры работы в растянутых (между ЦОДами) VLAN и/или через L2 Core для подсистемы Управление конфигурацией домена 2.24.6 При построении системы репликации для подсистемы Управление конфигурацией домена должны использоваться механизмы репликации средствами приложения без задействования технических средств использующих механизмы репликации ОС и/или системы хранения данных

2.17 Управление заданиями автоматизации 2.17.1 Возможность управлять заданиями автоматизации с использованием графического интерфейса Продукта 2.17.2 Настройка каталога параметров автоматизации 2.17.3 Выполнение заданий автоматизации 2.18 Мониторинг 2.18.1 Возможность осуществлять мониторинг подсистем с использованием графического интерфейса Продукта 2.18.2 Управление службой мониторинга (журнал событий, визуализация мониторинга), в том числе развёртывание серверов мониторинга, ведений журнала событий 2.18.3 Оперативный мониторинг компонент Продукта, в том числе контроль доступности и работоспособности компонентов, мониторинг ошибок репликации, постановка компонент на мониторинг 2.19 Журналирование событий 2.19.1 Возможность осуществлять журналирование событий Продукта с использованием графического интерфейса Продукта 2.19.2 Управление параметрами сбора и хранения журналов событий 2.20 Навигация и поиск объектов 2.20.1 Возможность осуществлять поиск по объектам Продукта с использованием графического интерфейса Продукта в соответствии с разделами 2.20.2 Навигация иерархического типа 2.20.3 Поиск объектов (таких, как учетные записи пользователей, учетные записи персональных компьютеров, группы безопасности и рассылки, принтеры) 2.21 Справочный центр 2.21.1 Возможность осуществлять вызов справки из любого раздела с использованием графического интерфейса Продукта 2.21.2 Наличие встроенного в Продукт справочного центра на русском языке 2.21.3 Информация в справке должна быть структурирована согласно разделам продукта 2.21.4 Возможность доступа к справочному центру из любого компонента Продукта 2.21.5 В разделе справки должны быть описаны функции подсистем Продукта в соответствии с их предназначением 2.21.6 Поиск по справке 2.21.7 Перекрестные ссылки на разделы справки в случае отсылки к другим разделам по тексту 2.21.8 Группировка по тематике и типу информации

2.13 Cлужба синхронизации времени 2.13.1 Возможность управлять службой синхронизации времени с использованием графического интерфейса Продукта 2.13.2 Управление службой синхронизации времени с использованием корневого и внешнего NTP-сервера 2.14 Служба печати 2.14.1 Возможность управлять службой печати с использованием графического интерфейса Продукта 2.14.2 Добавление принтера 2.14.3 Редактирование информации о принтере 2.14.4 Удаление принтера 2.14.5 Ведение мета-информации о принтере 2.14.6 Миграция принтеров из Microsoft Active Directory 2.15 Общий доступ к файлам 2.15.1 Создание, редактирование и удаление общих папок: o Развертывание серверов общего доступа к файлам o Создание папок общего доступа o Редактирование папок общего доступа o Удаление папок общего доступа 2.15.2 Ограничение доступа к общим папкам: Настройка схемы пользователей и групп пользователей для доступа к папке 2.16 Управление доступом 2.16.1 Возможность реализации в графическом интерфейсе Продукта 2.16.2 Делегирование роли главным администратором 2.16.3 Управление доступом путём назначения системных ролей безопасности 2.16.4 Возможность поддерживать систему прав, исключающую доступ администраторов Продукта к аутентификационной информации учетных записей, хранящихся в Продукте 2.16.5 Правила разграничения доступа должны позволять настраивать доступ для учетных записей и групп доступа 2.16.6 Правила разграничения доступа должны позволять настраивать доступ к любым объектам каталога пользователей и групп доступа 2.16.7 Правила разграничения доступа должны позволять устанавливать ограничения на определенные операции исходя из наличия привилегий учетной записи 2.16.8 Ввод в домен объектов типа «Компьютер» выполняется от имени учетной записи с полномочиями, явно указывающими на возможность выполнения такой операции, для остальных учетных записей данная функция должна быть недоступна.

2.11.4 Управление группами ПО o Создание заданий на установку и удаление ПО, в том числе на компьютеры выбранных подразделений и групп компьютеров: o Создание политик программного обеспечения o Назначение политик программного обеспечения на подразделение o Назначение политик программного обеспечения на компьютер/группу компьютеров o Принудительная установка программного обеспечения o Удаление программного обеспечения 2.11.5 Управление параметрами программного обеспечения аналогично групповым политикам с возможностью применения на компьютерах выбранных подразделений 2.11.6 Управление политиками обновления продукта 2.11.7 Взаимодействие с механизмом управления параметрами программного обеспечения должно выполняться без применения командной строки и написания скриптов 2.11.8 Возможность устанавливать ОС по сети на клиентских машинах домена с использованием графического интерфейса Продукта 2.11.9 Разворачивание сервера установки ОС по сети 2.11.10 Редактирование скриптов сценария установки ОС по сети: o preseed o postinstall o boot-меню o первого запуска 2.11.11 Импорт конфигурации сценария установки ОС по сети 2.11.12 Создание профилей компьютеров, на которые планируется осуществлять установку ОС по сети 2.11.13 Выполнение установки ОС по сети на выбранных компьютерах 2.11.14 Ввод в домен и конфигурация рабочей станции после установки ОС по сети 2.12 Служба разрешения имен 2.12.1 Возможность управлять службами разрешения имен с использованием графического интерфейса Продукта 2.12.2 Управление перенаправлением DNS запросов: Создание зон перенаправления (перенаправление запросов) 2.12.3 Возможность управлять службой динамической настройки узла с использованием графического интерфейса Продукта Управление службой DHCP: o Развертывание серверов динамической настройки узла (DHCP) o Импорт файла конфигурации DHCP o Настройка конфигурации DHCP o Настройка сетевых интерфейсов DHCP o Использование внешнего сервера DHCP

2.9 Управление групповыми политиками 2.9.1 Управление групповыми политиками с использованием графического интерфейса Продукта 2.9.2 Создание, редактирование, удаление групповых политик 2.9.3 Назначение групповых политик на подразделения 2.9.4 Обновление конфигурации и применение параметров групповых политик, ПО и правил сбора событий на клиентах при включении компьютера 2.9.5 Обновление конфигурации и применение параметров групповых политик, ПО и правил сбора событий на клиентах по таймеру каждые 30 минут с возможностью добавления произвольного отклонения от 5 до 50 минут 2.9.6 Возможность принудительного обновления конфигурации и применения параметров 2.9.7 Групповые политики, политики ПО и задания автоматизации хранятся в LDAP 2.9.8 Механизм наследования и суммирования параметров групповых политик 2.9.9 Возможность включения и отключения параметра, а также установка необходимых значений параметра групповой политики, которые будут применены на целевом компьютере и пользователе 2.9.10 Возможность установки приоритета применения групповой политики в рамках назначенного подразделения 2.10 Удаленный доступ 2.10.1 Удаленное подключение к рабочему столу пользователя с использованием графического интерфейса Продукта, с полным доступом и в режиме просмотра 2.10.2 Удаленное подключение к рабочему столу пользователя с использованием клиентского кода доступа 2.11 Установка и обновление программного обеспечения 2.11.1 Возможность устанавливать и обновлять программное обеспечения на клиентских машинах домена с использованием графического интерфейса Продукта 2.11.2 Управление репозиториями ПО 2.11.3 Возможность репликации репозиториев ПО: o Развертывание сервера репозитриев программного обеспечения o Создание репозитория программного обеспечения o Загрузка iso-образов из файла o Загрузка пакетов из файла o Редактирование репозиториев программного обеспечения o Удаление репозиториев программного обеспечения

2.7 Управление глобальным каталогом и модулем синхронизации 2.7.1 Синхронизация пользователей и групп пользователей продукта с глобальным каталогом 2.7.2 Форсированная установка нового сервера глобального каталога 2.7.3 Синхронизация паролей, подразделений, пользователей и групп пользователей: o односторонняя (MS AD ? Продукт) синхронизация подразделений, пользователей и групп пользователей o двусторонняя (MS AD ? Продукт) синхронизация паролей Обработка запрещенных символов при синхронизации пользователей, групп, подразделений. 2.8 Управление организационной структурой, пользователями и компьютерами 2.8.1 Управление организационной структурой, пользователями и компьютерами с использованием графического интерфейса Продукта 2.8.2 Возможность настройки организационной структуры подразделений в иерархическом виде. При выборе подразделения, в интерфейсе Продукта должны отображаться объекты, которые входят в данное подразделение: o Пользователи o Группы пользователей o Компьютеры o Группы компьютеров 2.8.3 Управление подразделениями: o Создание подразделения o Редактирование информации о подразделении 2.8.4 Настройка иерархии подразделений в соответствии со структурой организации o Добавление дочерних подразделений o Привязка подразделений к вышестоящим подразделениям организации 2.8.5 Управление пользователями и группами пользователей o Создание групп пользователей o Создание учетной записи пользователя o Редактирование учетной записи пользователя o Включение пользователя в группу пользователей o Привязка пользователя к подразделению o Быстрое восстановление удалённых пользователей (режим «корзины») 2.8.6 Управление компьютерами и группами компьютеров o Создание групп компьютеров o Редактирование учетной записи компьютера o Включение компьютера в группу компьютеров o Удаление учетной записи компьютера o Удаление группы компьютеров

- 58.29.50.000 - Лицензия на Программный комплекс "ALD Pro" на 1 управляемое устройство Требования к клиентской части *Указание на товарный знак обусловлено необходимостью обеспечения совместимости приобретаемого программного обеспечения с существующей инфраструктурой Заказчика, в которой используются лицензии операционных систем Astra Linux. Документально подтвержденной средой функционирования, приобретаемого продукта «ALD Pro», является операционная система Astra Linux, развернутая в инфраструктуре Заказчика. В соответствии п. 1 ч. 1 ст. 33 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» поставка эквивалента не допускается. **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов. ... - Штука - 250,00 - 1 064,00 - 266 000,00

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ ЗДРАВООХРАНЕНИЯ "КУЗБАССКИЙ КЛИНИЧЕСКИЙ КАРДИОЛОГИЧЕСКИЙ ДИСПАНСЕР ИМЕНИ АКАДЕМИКА Л.С. БАРБАРАША" - 250 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Требования к клиентской части *Указание на товарный знак обусловлено необходимостью обеспечения совместимости приобретаемого программного обеспечения с существующей инфраструктурой Заказчика, в которой используются лицензии операционных систем Astra Linux. Документально подтвержденной средой функционирования, приобретаемого продукта «ALD Pro», является операционная система Astra Linux, развернутая в инфраструктуре Заказчика. В соответствии п. 1 ч. 1 ст. 33 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» поставка эквивалента не допускается. **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов. Значение характеристики не может изменяться участником закупки Клиент должен обеспечивать следующие возможности управления ОС: • Работать в среде ОС с архитектурой x86_64 • Обеспечивать возможность аутентификации и авторизации пользователей в доменах под управлением Продукта с использованием протоколов LDAP и Kerberos • Обеспечивать возможность аутентификации и авторизации под учетными записями пользователей Microsoft Active Directory в доменах под управлением Продукта • Обеспечивать возможность регистрации узла в службе разрешения имен при вводе клиента в домен • Обеспечивать возможность настройки динамического обновления DNS клиента при изменении их IP адреса • Удаленное подключение к рабочему столу пользователя с использованием клиентского кода доступа с помощью графической утилиты • Выполнять задания автоматизации, политик на установку ПО, групповых политик • Обеспечивать возможность осуществлять журналирование событий • Обеспечивать возможность просмотра личных данных пользователем посредством web-интерфейса • Обеспечивать возможность изменения собственного пароля, в том числе при истечении срока действия пароля • Возможность Kerberos-аутентификации должна предоставляться в том числе при недоступности контроллеров домена любого сайта • Должен обеспечивать возможность ввода в домен с помощью графического интерфейса • Должен обеспечивать возможность подключения сетевых ресурсов общего доступа к управляемой ОС Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Требования к клиентской части - *Указание на товарный знак обусловлено необходимостью обеспечения совместимости приобретаемого программного обеспечения с существующей инфраструктурой Заказчика, в которой используются лицензии операционных систем Astra Linux. Документально подтвержденной средой функционирования, приобретаемого продукта «ALD Pro», является операционная система Astra Linux, развернутая в инфраструктуре Заказчика. В соответствии п. 1 ч. 1 ст. 33 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» поставка эквивалента не допускается. **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов. - - Значение характеристики не может изменяться участником закупки - Клиент должен обеспечивать следующие возможности управления ОС: • Работать в среде ОС с архитектурой x86_64 • Обеспечивать возможность аутентификации и авторизации пользователей в доменах под управлением Продукта с использованием протоколов LDAP и Kerberos • Обеспечивать возможность аутентификации и авторизации под учетными записями пользователей Microsoft Active Directory в доменах под управлением Продукта • Обеспечивать возможность регистрации узла в службе разрешения имен при вводе клиента в домен • Обеспечивать возможность настройки динамического обновления DNS клиента при изменении их IP адреса • Удаленное подключение к рабочему столу пользователя с использованием клиентского кода доступа с помощью графической утилиты • Выполнять задания автоматизации, политик на установку ПО, групповых политик • Обеспечивать возможность осуществлять журналирование событий • Обеспечивать возможность просмотра личных данных пользователем посредством web-интерфейса • Обеспечивать возможность изменения собственного пароля, в том числе при истечении срока действия пароля • Возможность Kerberos-аутентификации должна предоставляться в том числе при недоступности контроллеров домена любого сайта • Должен обеспечивать возможность ввода в домен с помощью графического интерфейса • Должен обеспечивать возможность подключения сетевых ресурсов общего доступа к управляемой ОС Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

Требования к клиентской части - *Указание на товарный знак обусловлено необходимостью обеспечения совместимости приобретаемого программного обеспечения с существующей инфраструктурой Заказчика, в которой используются лицензии операционных систем Astra Linux. Документально подтвержденной средой функционирования, приобретаемого продукта «ALD Pro», является операционная система Astra Linux, развернутая в инфраструктуре Заказчика. В соответствии п. 1 ч. 1 ст. 33 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» поставка эквивалента не допускается. **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов. - - Значение характеристики не может изменяться участником закупки

Клиент должен обеспечивать следующие возможности управления ОС: • Работать в среде ОС с архитектурой x86_64 • Обеспечивать возможность аутентификации и авторизации пользователей в доменах под управлением Продукта с использованием протоколов LDAP и Kerberos • Обеспечивать возможность аутентификации и авторизации под учетными записями пользователей Microsoft Active Directory в доменах под управлением Продукта • Обеспечивать возможность регистрации узла в службе разрешения имен при вводе клиента в домен • Обеспечивать возможность настройки динамического обновления DNS клиента при изменении их IP адреса • Удаленное подключение к рабочему столу пользователя с использованием клиентского кода доступа с помощью графической утилиты • Выполнять задания автоматизации, политик на установку ПО, групповых политик • Обеспечивать возможность осуществлять журналирование событий • Обеспечивать возможность просмотра личных данных пользователем посредством web-интерфейса • Обеспечивать возможность изменения собственного пароля, в том числе при истечении срока действия пароля • Возможность Kerberos-аутентификации должна предоставляться в том числе при недоступности контроллеров домена любого сайта • Должен обеспечивать возможность ввода в домен с помощью графического интерфейса • Должен обеспечивать возможность подключения сетевых ресурсов общего доступа к управляемой ОС Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет

- 58.29.50.000 - Лицензия на диспетчера подключений виртуальных рабочих мест «Термидеcк», вариант лицензирования "Termidesk Terminal", на 1 конкурентное соединение 1. Общее описание решения Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет; **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов. ... - Штука - 300,00 - 2 170,00 - 651 000,00

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ ЗДРАВООХРАНЕНИЯ "КУЗБАССКИЙ КЛИНИЧЕСКИЙ КАРДИОЛОГИЧЕСКИЙ ДИСПАНСЕР ИМЕНИ АКАДЕМИКА Л.С. БАРБАРАША" - 300 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке 1. Общее описание решения Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет; **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов. Значение характеристики не может изменяться участником закупки 1.5 Продукт должен поддерживать горизонтальное масштабирование «Универсальных диспетчеров» и «Шлюзов», а также обеспечивать высокую доступность (отказоустойчивость) «Универсальных диспетчеров». 1.6 В продукте должен быть реализован API проверки работоспособности компонентов (healthcheck), обеспечивающего функционирование программного комплекса для использования во внешних системах мониторинга. 1.7 В продукте должен быть реализован API получения метрик, характеризующих состояние узла и запущенных на нём компонентов продукта, доступный для использования во внешних системах мониторинга. 1.8 В продукте должен поддерживаться механизм централизованных настроек (далее - политики), применяемых без переконфигурации объектов. Политики должны применяться иерархически, глобально и на уровне фонда. 1.9 В продукте должна поддерживаться доставка рабочих столов и приложений в режиме удаленного доступа по протоколам RDP и собственной разработки. 2. Требования к решению 2.1 Наличие режима «Техническое обслуживание» для фондов и терминальных серверов. 2.2 Возможность работы с терминальными сессиями Microsoft Remote Desktop Services по протоколу RDP. 2.3 Возможность работы с удаленным доступом к приложениям, расположенным на сервере Microsoft Remote Desktop Services по протоколу RDP. 2.4 Возможность работы с терминальными Linux-сессиями по протоколу RDP. 2.5 Возможность работы с удаленным доступом к Linux-приложениям по протоколу RDP. 2.6 Возможность балансировки пользовательских сессий между терминальными серверами. 2.7 Получение сведений о пользователях и группах из следующих серверов каталогов: • ALD; • ALD Pro; • FreeIPA; • Microsoft Active Directory. 2.8 Аутентификация пользователей в следующих серверах каталогов: • ALD; • ALD Pro; • FreeIPA; • Microsoft Active Directory. 9. Требования к компоненту «Termidesk Live» 9.1 Загрузка c подготовленного USB-носителя. 9.2 Загрузка по сети с использованием технологии PXE-загрузки. 9.3 Наличие предустановленного компонента «Клиент». 9.4 Обеспечение работы компонента «Клиент». 9.5 Возможность добавления администратором приложений, отсутствующих в поставляемом образе компонента. 10. Дополнительные требования к Продукту 10.1 ПО должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и БД. 10.2 Наличие собственного центра разработки в России. 10.3 Наличие центра технической поддержки в России с возможностью приема заявок 24x7. 10.4 Наличие дорожной карты развития Продукта. 10.5 Наличие обучающих курсов на русском языке, доступных в учебных центрах на территории России. 10.6 Наличие документации по установке и эксплуатации Продукта на русском языке. 10.7 Наличие графического интерфейса Продукта на русском языке. 10.8 Наличие срочного и бессрочного лицензирования Продукта. 10.9 Наличие лицензирования по количеству конкурентных соединений (количество одновременных подключений пользователей к терминальным серверам) и по пользователям (именные лицензии, привязанные к пользователю). 10.10 Наличие двустороннего сертификата совместимости с ПО VMmanager (или эквивалент), подтверждающего корректность совместной работы. 7.8 Предоставление возможности указания размера экрана сессии. 7.9 Поддержка ограничения сессии пользователя по времени. 7.10 Поддержка установки таймера неактивности пользователя. 7.11 Поддержка настройки уровней безопасности протокола RDP. 7.12 Поддержка изолированных друг от друга сессий пользователей. 7.13 Поддержка собственного оконного менеджера для публикуемых приложений. 7.14 Возможность выбора ранее запущенной сессии для переподключения к ней. 8. Требования к компоненту «Виртуальный модуль Termidesk» 8.1 Поставка компонента в форматах: для гипервизоров QEMU/KVM и для платформы виртуализации VMware. 8.2 Наличие в компоненте соответствующих наборов инструментов гостевой ОС в зависимости от формата поставки. 8.3 Выполнение одной или нескольких функций решения каждым экземпляром компонента: • «Универсальный диспетчер»; • «Шлюз»; • «База данных». 8.4 Поддержка базового и усиленного режима защищенности ОС Astra Linux Special Edition не ниже 1.7. 8.5 Поддержка установки как в распределенном варианте, так и в режиме комплексной установки. 8.6 Предоставление псевдографического интерфейса администрирования. 8.7 Псевдографический интерфейс должен предоставлять следующие возможности по управлению компонентом: • изменение настроек сети; • диагностика сетевых подключений; • изменение имени узла; • смена пароля учетной записи администратора; • экспорт и импорт настроек продукта. 8.8 Компонент должен предоставлять графический веб-интерфейс администратора. 8.9 Графический веб-интерфейс администратора должен предоставлять следующие возможности по управлению компонентом: • управление состоянием служб ОС компонента; • настройка режима высокой доступности продукта; • формирование и выгрузка системных журналов компонента; • просмотр и замена используемого сертификата; • управление датой и временем ОС компонента. 6. Требования к компоненту «Агент» 6.1 Возможность установки в среде ОС терминального сервера, работающей под управлением ОС Microsoft Windows Server не ниже 2016, Astra Linux Special Edition не ниже 1.7 и прочих GNU/Linux. 6.2 Установка в ОС терминального сервера для обеспечения взаимодействия с компонентом «Универсальный диспетчер», конфигурации терминального сервера, фиксации действий пользователя и реализации управляющих сообщений. 6.3 Установка на терминальный сервер для предоставления возможностей публикации терминалов и удаленных приложений. 6.4 Установка на терминальный сервер для предоставления возможности множественного доступа пользователей к удалённым рабочим столам и приложениям. 6.5 Установка в ОС терминального сервера для перенаправления смарт-карт с пользовательской рабочей станции в режиме совместного использования. 6.6 Установка в ОС терминального сервера для перенаправления видеокамеры с пользовательской рабочей станции в оптимизированном режиме. 6.7 Взаимодействие с «Универсальным диспетчером» по протоколу HTTPS. 6.8 Поддержка автозапуска при старте ОС терминального сервера. 6.9 Поддержка интеграции с системным журналом ОС терминального сервера. 7. Требования к компоненту «Сервер терминалов Astra Linux» (STAL) 7.1 Возможность установки в среде ОС, работающей под управлением ОС Astra Linux Special Edition не ниже 1.7. 7.2 Предоставление доступа пользователям к терминальной сессии по протоколу RDP. 7.3 Предоставление доступа пользователям к экрану одного приложения. 7.4 Использование одного TCP порта для подключения пользователей. 7.5 Использование режима проверки пользовательского запроса NTLM. 7.6 Предоставление списка установленных и размещенных в графическом меню приложений для режима удаленного доступа к приложениям. 7.7 Предоставление возможности указания произвольного установленного приложения для режима удаленного доступа к приложениям. 5.12 Поддержка возможности перенаправления (захвата) клавиатуры и указателя мыши из ОС пользовательской рабочей станции в терминальную сессию. 5.13 Обеспечение выбора протоколов доставки терминальных сессий. 5.14 Отключаемая возможность сохранения имени пользователя и пароля для повторного использования. 5.15 Возможность автоматического подключения к серверу решения, указанному посредством TXT-записи на сервере DNS. 5.16 Предоставление пользователю возможности управлять перенаправлением локальных ресурсов в соответствии с назначенными политиками. 5.17 Возможность перенаправления принтеров в режиме совместного использования в пользовательской рабочей станции и терминальной сессии. 5.18 Возможность выбора драйвера для перенаправляемого принтера. 5.19 Возможность перенаправления каталогов из файловой системы пользовательской рабочей станции в терминальную сессию. 5.20 Возможность перенаправления USB-токенов и смарт-карт в режиме совместного использования в пользовательской рабочей станции и терминальной сессии (оптимизация перенаправления). 5.21 Возможность аутентификации пользователей по смарт-картам и токенам Рутокен в домене Microsoft Active Directory. 5.22 Возможность работы с несколькими мониторами. 5.23 Возможность сопоставления виртуальных мониторов физическим. 5.24 Возможность управления отображением панели инструментов в полноэкранном режиме. 5.25 Возможность выгрузки отладочной информации для службы технической поддержки из графического интерфейса приложения. 5.26 Возможность настраиваемого автоматического переподключения к ранее запущенным сеансам. 5.27 Возможность управления активными сеансами из единого центра подключений. 4. Требования к компоненту «Шлюз» 4.1 Возможность установки совместно с «Универсальным диспетчером». 4.2 Возможность установки отдельно от «Универсального диспетчера». 4.3 Туннелирование протоколов доставки посредством протокола Websocket. 4.4 Проксирование подключений пользователей к терминальным серверам. 4.5 Использование одного внешнего IP-адреса и TCP-порта для подключений к публикуемым ресурсам. 4.6 Возможность использования безопасного транспорта SSL/TLS при доставке терминальных сессий. 4.7 Валидация пользовательских подключений. 4.8 Предоставление статистики подключений в формате JSON. 4.9 Предоставление API проверки работоспособности компонента (healthcheck). 4.10 Предоставление API сбора метрик узла. 5. Требования к компоненту «Клиент» 5.1 Возможность установки и использования в средах ОС Microsoft Windows не ниже 10, Astra Linux Special Edition не ниже 1.7 и других ОС на базе ядра GNU/Linux. 5.2 Обеспечение консольного и графического режима запуска. 5.3 Прием параметров из командной строки для настройки подключения к «Универсальному диспетчеру». 5.4 Отключаемая возможность запуска во множественном экземпляре. 5.5 Подключение к нескольким инсталляциям Termidesk. 5.6 Визуализация списка доступных рабочих столов и приложений в графическом виде. 5.7 Возможность формирования пользовательской группы (избранное) для последующего быстрого доступа к выбранным рабочим столам и приложениям. 5.8 Обеспечение настраиваемой сортировки объектов. 5.9 Возможность выбора языка: предустановленного или используемого в ОС. 5.10 Возможность использования светлой и темной тем оформления. 5.11 Поддержка централизованной конфигурации используемых функций, назначаемых через интерфейс управления. 3.2.13 Перенаправление событий на несколько внешних серверов по протоколу SYSLOG. 3.2.14 Возможность подключения к внешнему серверу SYSLOG по протоколам TCP, UDP и TLS. 3.2.15 Выгрузка журнала и событий аудита в формате CSV. 3.2.16 Построение и выгрузка отчетов для следующих действий пользователей: • вход в систему; • сеанс; • подключение. 3.2.17 Оповещение администраторов о нештатных ситуациях по электронной почте. 3.2.18 Возможность указания ограничения длительности сессии пользователя. 3.2.19 Принудительная блокировка пользователя из графического веб-интерфейса. 3.2.20 Блокировка на заданный промежуток времени доступа пользователя к «Универсальному диспетчеру» при превышении заданного количества попыток входа. 3.2.21 Указание максимального количества неудачных попыток входа пользователя. 3.2.22 Разблокировка заблокированного пользователя из графического веб-интерфейса. 3.2.23 Возможность настройки произвольного текста, выводимого в графический веб-интерфейс пользователя при ошибке входа. 3.2.24 Возможность установки приоритета использования протокола доставки рабочих столов и приложений. 3.2.25 Возможность указания URL-адреса ресурса, на котором осуществляется поддержка пользователей. 3.2.26 Возможность загрузки и размещения картинки для визуализации назначения фонда. 3.2.27 Возможность предоставления доступа к фонду конкретному пользователю и группе пользователей. 3.2.28 Возможность выгрузки файла для запроса лицензии. 3.3 Возможности для пользователя 3.3.1 Доступ к графическому интерфейсу из веб-обозревателя по протоколу HTTPS. 3.3.2 Доступ посредством компонента «Клиент». 3.3.3 Возможность выбора домена аутентификации. 3.3.4 Предоставление списка доступных пользователю ресурсов. 3.3.5 Возможность группировки ресурсов. 3.3.6 Возможность выбора протокола подключения. 3.3.7 Возможность вызова установленного в системе «Клиента» при запуске ресурса из веб-обозревателя. 3.2.5 Графический веб-интерфейс с функцией мастеров, упрощающих процесс публикации рабочих столов и приложений. 3.2.6 Наличие CLI-интерфейса, позволяющего выполнять следующие функции: • вывод версии «Универсального диспетчера»; • управление системными настройками (просмотр и изменение); • управление способами аутентификации; • управление протоколами доставки. 3.2.7 Наличие REST API-интерфейса, минимально предоставляющего следующие возможности: • доступ по токену безопасности; • документирование доступных функций; • автоматическое обнаружение функций и версии API; • управление системными настройками (просмотр и изменение); • управление способами аутентификации; • управление протоколами доставки; • управление объектами инфраструктуры; • управление листами доступа (ACL) и ролями; • управление политиками; • управление фондами терминальных серверов; • управление сессиями пользователей. 3.2.8 Ограничение доступа к графическому веб-интерфейсу по следующим критериям: • количеству попыток входа; • заблокированным администраторам. 3.2.9 Возможность указания ограничения длительности сессии администратора. 3.2.10 Визуализация событий аудита в графическом веб-интерфейсе со следующими возможностями: • вывод всех событий аудита; • вывод событий в соответствии с заданным фильтром; • поиск событий в заданный временной интервал. 3.2.11 Возможность сбора и хранения статистики, мониторинг состояния терминальных серверов с функцией визуализации системных событий, источников их возникновения, уровня важности. 3.2.12 Возможность отслеживания всех событий, ассоциированных с сеансом пользователя, при помощи глобального уникального сессионного идентификатора. 3. Требования к компоненту «Универсальный диспетчер» 3.1 Общие возможности 3.1.1 Наличие установщика, работающего в диалоговом режиме с возможностью настройки протокола подключения к базе данных (БД) и брокеру сообщений. 3.1.2 Выполнение установки в соответствии с заданной ролью узла (портал администратора, портал пользователя) 3.1.3 Возможность совмещения нескольких ролей на одном узле. 3.1.4 Настройка параметров доступа к системе, позволяющая: • управлять полномочиями пользователей из графического веб-интерфейса; • назначать полномочия отдельным пользователям и группам; • отображать графический веб-интерфейс администратора в соответствии с его полномочиями; • назначать полномочия пользователям для делегирования функций администратора; • назначать полномочия просмотра, создания, удаления и редактирования для функций управления «Универсальным диспетчером». 3.1.5 Наличие аудита действий администратора с возможностью ведения журнала в файле, внутренней БД и отправки на внешние серверы по протоколу SYSLOG. 3.1.6 Настраиваемая ротация журнала аудита событий. 3.1.7 Поддержка хранения паролей во внешних хранилищах секретов. 3.2 Возможности для администратора 3.2.1 Доступ к графическому интерфейсу управления из веб-обозревателя по протоколу HTTPS. 3.2.2 Наглядный графический веб-интерфейс, визуализирующий основные параметры, такие как: • количество пользователей и конкурентных соединений; • количество и состояние поставщиков ресурсов и фондов терминальных серверов; • количество и состояние компонентов («Универсальных диспетчеров», «Порталов», «Шлюзов»). 3.2.3 Возможность поиска в графическом веб-интерфейсе объектов и записей, в том числе по нескольким критериям одновременно. 3.2.4 Настраиваемое автоматическое обновление данных в графическом веб-интерфейсе без перезагрузки страницы целиком. 2.9 Поиск пользователя в Microsoft Active Directory: • во вложенных группах сервера каталогов; • в распределенной архитектуре сервера каталогов Microsoft Active Directory («лесу»). 2.10 Авторизация пользователя на основе принадлежности к группе пользователей. 2.11 Аутентификация пользователей по протоколу SAML. 2.12 Аутентификация пользователей по протоколу OpenID Connect. 2.13 Аутентификация пользователей по смарт-картам и токенам Рутокен в домене Microsoft Active Directory. 2.14 Идентификация пользователей по IP-адресу с возможностью указания диапазона адресов. 2.15 Поддержка двухфакторной аутентификации на основе реестра кодов (TOTP) со следующими возможностями: • совместимость с TOTP приложениями, такими как: FreeOTP, Google Authenticator, Яндекс.Ключ; • валидация токена «Универсальным диспетчером»; • предоставление одноразовых кодов «Универсальным диспетчером»; • валидация кода сервером каталогов FreeIPA. 2.16 Поддержка режимов прямого соединения и соединения через «Шлюз» для протокола RDP. 2.17 Возможность настраиваемого перенаправления аппаратных устройств (принтеров, токенов, USB-носителей) и буфера обмена устройства доступа в терминальные сессии. 2.18 Возможность ограничения перенаправления USB-устройств по их Product ID и Vendor ID. 2.19 Возможность принудительной активации использования буфера обмена между узлом пользователя и терминальным сервером. 2.20 Возможность ограничения типа и объёма информации, передаваемой через буфер обмена. 2.21 Возможность принудительного указания направления работы буфера обмена между узлом пользователя и терминальным сервером. 1.1 Решение, реализующее инфраструктуру терминальных серверов, должно включать в себя следующие отдельные программные компоненты (далее – Продукт): • «Универсальный диспетчер» — компонент, отвечающий за идентификацию пользователей, предоставление терминального доступа, а также предоставляющий графическую систему управления терминальным сервером («Портал администратора», «Портал пользователя», «Портал универсальный»); • «Шлюз» – компонент, обеспечивающий контролируемое и безопасное туннелирование доставки терминальных сессий по каналам связи через один внешний IP-адрес и порт; • «Клиент» – компонент, устанавливаемый на рабочее место пользователя и предоставляющий возможности доставки терминальных сессий авторизованным пользователям; • «Агент» – компонент, устанавливаемый на узел виртуализации или сервер терминалов, для передачи информационных сообщений и получения управляющих команд от «Универсального диспетчера», а также операций с ОС терминального сервера (ОС), гипервизором или терминальным сервером; • «Сервер терминалов Astra Linux» (STAL) компонент, обеспечивающий множественный пользовательский доступ к удаленному экземпляру рабочего стола или приложения; • «Виртуальный модуль Termidesk» — компонент, представляющий собой образ виртуальной машины (ВМ) (или диска ВМ) с предварительно установленной и настроенной ОС и набором программного обеспечения (ПО), необходимого для эксплуатации решения; • «Termidesk Live» – компонент, представляющий собой загрузочный образ ОС с предустановленным компонентом «Клиент». 1.2 Продукт должен функционировать в среде ОС специального назначения Astra Linux Special Edition не ниже 1.7. 1.3 Продукт должен поддерживать следующие встроенные механизмы безопасности сертифицированной ОС специального назначения Astra Linux Special Edition не ниже 1.7: замкнутая программная среда и мандатный контроль целостности. 1.4 Продукт предназначен для управления терминальными серверами и доступом пользователей к ним. - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - 1. Общее описание решения - Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет; **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов. - - Значение характеристики не может изменяться участником закупки - 1.5 Продукт должен поддерживать горизонтальное масштабирование «Универсальных диспетчеров» и «Шлюзов», а также обеспечивать высокую доступность (отказоустойчивость) «Универсальных диспетчеров». 1.6 В продукте должен быть реализован API проверки работоспособности компонентов (healthcheck), обеспечивающего функционирование программного комплекса для использования во внешних системах мониторинга. 1.7 В продукте должен быть реализован API получения метрик, характеризующих состояние узла и запущенных на нём компонентов продукта, доступный для использования во внешних системах мониторинга. 1.8 В продукте должен поддерживаться механизм централизованных настроек (далее - политики), применяемых без переконфигурации объектов. Политики должны применяться иерархически, глобально и на уровне фонда. 1.9 В продукте должна поддерживаться доставка рабочих столов и приложений в режиме удаленного доступа по протоколам RDP и собственной разработки. 2. Требования к решению 2.1 Наличие режима «Техническое обслуживание» для фондов и терминальных серверов. 2.2 Возможность работы с терминальными сессиями Microsoft Remote Desktop Services по протоколу RDP. 2.3 Возможность работы с удаленным доступом к приложениям, расположенным на сервере Microsoft Remote Desktop Services по протоколу RDP. 2.4 Возможность работы с терминальными Linux-сессиями по протоколу RDP. 2.5 Возможность работы с удаленным доступом к Linux-приложениям по протоколу RDP. 2.6 Возможность балансировки пользовательских сессий между терминальными серверами. 2.7 Получение сведений о пользователях и группах из следующих серверов каталогов: • ALD; • ALD Pro; • FreeIPA; • Microsoft Active Directory. 2.8 Аутентификация пользователей в следующих серверах каталогов: • ALD; • ALD Pro; • FreeIPA; • Microsoft Active Directory. - 9. Требования к компоненту «Termidesk Live» 9.1 Загрузка c подготовленного USB-носителя. 9.2 Загрузка по сети с использованием технологии PXE-загрузки. 9.3 Наличие предустановленного компонента «Клиент». 9.4 Обеспечение работы компонента «Клиент». 9.5 Возможность добавления администратором приложений, отсутствующих в поставляемом образе компонента. 10. Дополнительные требования к Продукту 10.1 ПО должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и БД. 10.2 Наличие собственного центра разработки в России. 10.3 Наличие центра технической поддержки в России с возможностью приема заявок 24x7. 10.4 Наличие дорожной карты развития Продукта. 10.5 Наличие обучающих курсов на русском языке, доступных в учебных центрах на территории России. 10.6 Наличие документации по установке и эксплуатации Продукта на русском языке. 10.7 Наличие графического интерфейса Продукта на русском языке. 10.8 Наличие срочного и бессрочного лицензирования Продукта. 10.9 Наличие лицензирования по количеству конкурентных соединений (количество одновременных подключений пользователей к терминальным серверам) и по пользователям (именные лицензии, привязанные к пользователю). 10.10 Наличие двустороннего сертификата совместимости с ПО VMmanager (или эквивалент), подтверждающего корректность совместной работы. - 7.8 Предоставление возможности указания размера экрана сессии. 7.9 Поддержка ограничения сессии пользователя по времени. 7.10 Поддержка установки таймера неактивности пользователя. 7.11 Поддержка настройки уровней безопасности протокола RDP. 7.12 Поддержка изолированных друг от друга сессий пользователей. 7.13 Поддержка собственного оконного менеджера для публикуемых приложений. 7.14 Возможность выбора ранее запущенной сессии для переподключения к ней. 8. Требования к компоненту «Виртуальный модуль Termidesk» 8.1 Поставка компонента в форматах: для гипервизоров QEMU/KVM и для платформы виртуализации VMware. 8.2 Наличие в компоненте соответствующих наборов инструментов гостевой ОС в зависимости от формата поставки. 8.3 Выполнение одной или нескольких функций решения каждым экземпляром компонента: • «Универсальный диспетчер»; • «Шлюз»; • «База данных». 8.4 Поддержка базового и усиленного режима защищенности ОС Astra Linux Special Edition не ниже 1.7. 8.5 Поддержка установки как в распределенном варианте, так и в режиме комплексной установки. 8.6 Предоставление псевдографического интерфейса администрирования. 8.7 Псевдографический интерфейс должен предоставлять следующие возможности по управлению компонентом: • изменение настроек сети; • диагностика сетевых подключений; • изменение имени узла; • смена пароля учетной записи администратора; • экспорт и импорт настроек продукта. 8.8 Компонент должен предоставлять графический веб-интерфейс администратора. 8.9 Графический веб-интерфейс администратора должен предоставлять следующие возможности по управлению компонентом: • управление состоянием служб ОС компонента; • настройка режима высокой доступности продукта; • формирование и выгрузка системных журналов компонента; • просмотр и замена используемого сертификата; • управление датой и временем ОС компонента. - 6. Требования к компоненту «Агент» 6.1 Возможность установки в среде ОС терминального сервера, работающей под управлением ОС Microsoft Windows Server не ниже 2016, Astra Linux Special Edition не ниже 1.7 и прочих GNU/Linux. 6.2 Установка в ОС терминального сервера для обеспечения взаимодействия с компонентом «Универсальный диспетчер», конфигурации терминального сервера, фиксации действий пользователя и реализации управляющих сообщений. 6.3 Установка на терминальный сервер для предоставления возможностей публикации терминалов и удаленных приложений. 6.4 Установка на терминальный сервер для предоставления возможности множественного доступа пользователей к удалённым рабочим столам и приложениям. 6.5 Установка в ОС терминального сервера для перенаправления смарт-карт с пользовательской рабочей станции в режиме совместного использования. 6.6 Установка в ОС терминального сервера для перенаправления видеокамеры с пользовательской рабочей станции в оптимизированном режиме. 6.7 Взаимодействие с «Универсальным диспетчером» по протоколу HTTPS. 6.8 Поддержка автозапуска при старте ОС терминального сервера. 6.9 Поддержка интеграции с системным журналом ОС терминального сервера. 7. Требования к компоненту «Сервер терминалов Astra Linux» (STAL) 7.1 Возможность установки в среде ОС, работающей под управлением ОС Astra Linux Special Edition не ниже 1.7. 7.2 Предоставление доступа пользователям к терминальной сессии по протоколу RDP. 7.3 Предоставление доступа пользователям к экрану одного приложения. 7.4 Использование одного TCP порта для подключения пользователей. 7.5 Использование режима проверки пользовательского запроса NTLM. 7.6 Предоставление списка установленных и размещенных в графическом меню приложений для режима удаленного доступа к приложениям. 7.7 Предоставление возможности указания произвольного установленного приложения для режима удаленного доступа к приложениям. - 5.12 Поддержка возможности перенаправления (захвата) клавиатуры и указателя мыши из ОС пользовательской рабочей станции в терминальную сессию. 5.13 Обеспечение выбора протоколов доставки терминальных сессий. 5.14 Отключаемая возможность сохранения имени пользователя и пароля для повторного использования. 5.15 Возможность автоматического подключения к серверу решения, указанному посредством TXT-записи на сервере DNS. 5.16 Предоставление пользователю возможности управлять перенаправлением локальных ресурсов в соответствии с назначенными политиками. 5.17 Возможность перенаправления принтеров в режиме совместного использования в пользовательской рабочей станции и терминальной сессии. 5.18 Возможность выбора драйвера для перенаправляемого принтера. 5.19 Возможность перенаправления каталогов из файловой системы пользовательской рабочей станции в терминальную сессию. 5.20 Возможность перенаправления USB-токенов и смарт-карт в режиме совместного использования в пользовательской рабочей станции и терминальной сессии (оптимизация перенаправления). 5.21 Возможность аутентификации пользователей по смарт-картам и токенам Рутокен в домене Microsoft Active Directory. 5.22 Возможность работы с несколькими мониторами. 5.23 Возможность сопоставления виртуальных мониторов физическим. 5.24 Возможность управления отображением панели инструментов в полноэкранном режиме. 5.25 Возможность выгрузки отладочной информации для службы технической поддержки из графического интерфейса приложения. 5.26 Возможность настраиваемого автоматического переподключения к ранее запущенным сеансам. 5.27 Возможность управления активными сеансами из единого центра подключений. - 4. Требования к компоненту «Шлюз» 4.1 Возможность установки совместно с «Универсальным диспетчером». 4.2 Возможность установки отдельно от «Универсального диспетчера». 4.3 Туннелирование протоколов доставки посредством протокола Websocket. 4.4 Проксирование подключений пользователей к терминальным серверам. 4.5 Использование одного внешнего IP-адреса и TCP-порта для подключений к публикуемым ресурсам. 4.6 Возможность использования безопасного транспорта SSL/TLS при доставке терминальных сессий. 4.7 Валидация пользовательских подключений. 4.8 Предоставление статистики подключений в формате JSON. 4.9 Предоставление API проверки работоспособности компонента (healthcheck). 4.10 Предоставление API сбора метрик узла. 5. Требования к компоненту «Клиент» 5.1 Возможность установки и использования в средах ОС Microsoft Windows не ниже 10, Astra Linux Special Edition не ниже 1.7 и других ОС на базе ядра GNU/Linux. 5.2 Обеспечение консольного и графического режима запуска. 5.3 Прием параметров из командной строки для настройки подключения к «Универсальному диспетчеру». 5.4 Отключаемая возможность запуска во множественном экземпляре. 5.5 Подключение к нескольким инсталляциям Termidesk. 5.6 Визуализация списка доступных рабочих столов и приложений в графическом виде. 5.7 Возможность формирования пользовательской группы (избранное) для последующего быстрого доступа к выбранным рабочим столам и приложениям. 5.8 Обеспечение настраиваемой сортировки объектов. 5.9 Возможность выбора языка: предустановленного или используемого в ОС. 5.10 Возможность использования светлой и темной тем оформления. 5.11 Поддержка централизованной конфигурации используемых функций, назначаемых через интерфейс управления. - 3.2.13 Перенаправление событий на несколько внешних серверов по протоколу SYSLOG. 3.2.14 Возможность подключения к внешнему серверу SYSLOG по протоколам TCP, UDP и TLS. 3.2.15 Выгрузка журнала и событий аудита в формате CSV. 3.2.16 Построение и выгрузка отчетов для следующих действий пользователей: • вход в систему; • сеанс; • подключение. 3.2.17 Оповещение администраторов о нештатных ситуациях по электронной почте. 3.2.18 Возможность указания ограничения длительности сессии пользователя. 3.2.19 Принудительная блокировка пользователя из графического веб-интерфейса. 3.2.20 Блокировка на заданный промежуток времени доступа пользователя к «Универсальному диспетчеру» при превышении заданного количества попыток входа. 3.2.21 Указание максимального количества неудачных попыток входа пользователя. 3.2.22 Разблокировка заблокированного пользователя из графического веб-интерфейса. 3.2.23 Возможность настройки произвольного текста, выводимого в графический веб-интерфейс пользователя при ошибке входа. 3.2.24 Возможность установки приоритета использования протокола доставки рабочих столов и приложений. 3.2.25 Возможность указания URL-адреса ресурса, на котором осуществляется поддержка пользователей. 3.2.26 Возможность загрузки и размещения картинки для визуализации назначения фонда. 3.2.27 Возможность предоставления доступа к фонду конкретному пользователю и группе пользователей. 3.2.28 Возможность выгрузки файла для запроса лицензии. 3.3 Возможности для пользователя 3.3.1 Доступ к графическому интерфейсу из веб-обозревателя по протоколу HTTPS. 3.3.2 Доступ посредством компонента «Клиент». 3.3.3 Возможность выбора домена аутентификации. 3.3.4 Предоставление списка доступных пользователю ресурсов. 3.3.5 Возможность группировки ресурсов. 3.3.6 Возможность выбора протокола подключения. 3.3.7 Возможность вызова установленного в системе «Клиента» при запуске ресурса из веб-обозревателя. - 3.2.5 Графический веб-интерфейс с функцией мастеров, упрощающих процесс публикации рабочих столов и приложений. 3.2.6 Наличие CLI-интерфейса, позволяющего выполнять следующие функции: • вывод версии «Универсального диспетчера»; • управление системными настройками (просмотр и изменение); • управление способами аутентификации; • управление протоколами доставки. 3.2.7 Наличие REST API-интерфейса, минимально предоставляющего следующие возможности: • доступ по токену безопасности; • документирование доступных функций; • автоматическое обнаружение функций и версии API; • управление системными настройками (просмотр и изменение); • управление способами аутентификации; • управление протоколами доставки; • управление объектами инфраструктуры; • управление листами доступа (ACL) и ролями; • управление политиками; • управление фондами терминальных серверов; • управление сессиями пользователей. 3.2.8 Ограничение доступа к графическому веб-интерфейсу по следующим критериям: • количеству попыток входа; • заблокированным администраторам. 3.2.9 Возможность указания ограничения длительности сессии администратора. 3.2.10 Визуализация событий аудита в графическом веб-интерфейсе со следующими возможностями: • вывод всех событий аудита; • вывод событий в соответствии с заданным фильтром; • поиск событий в заданный временной интервал. 3.2.11 Возможность сбора и хранения статистики, мониторинг состояния терминальных серверов с функцией визуализации системных событий, источников их возникновения, уровня важности. 3.2.12 Возможность отслеживания всех событий, ассоциированных с сеансом пользователя, при помощи глобального уникального сессионного идентификатора. - 3. Требования к компоненту «Универсальный диспетчер» 3.1 Общие возможности 3.1.1 Наличие установщика, работающего в диалоговом режиме с возможностью настройки протокола подключения к базе данных (БД) и брокеру сообщений. 3.1.2 Выполнение установки в соответствии с заданной ролью узла (портал администратора, портал пользователя) 3.1.3 Возможность совмещения нескольких ролей на одном узле. 3.1.4 Настройка параметров доступа к системе, позволяющая: • управлять полномочиями пользователей из графического веб-интерфейса; • назначать полномочия отдельным пользователям и группам; • отображать графический веб-интерфейс администратора в соответствии с его полномочиями; • назначать полномочия пользователям для делегирования функций администратора; • назначать полномочия просмотра, создания, удаления и редактирования для функций управления «Универсальным диспетчером». 3.1.5 Наличие аудита действий администратора с возможностью ведения журнала в файле, внутренней БД и отправки на внешние серверы по протоколу SYSLOG. 3.1.6 Настраиваемая ротация журнала аудита событий. 3.1.7 Поддержка хранения паролей во внешних хранилищах секретов. 3.2 Возможности для администратора 3.2.1 Доступ к графическому интерфейсу управления из веб-обозревателя по протоколу HTTPS. 3.2.2 Наглядный графический веб-интерфейс, визуализирующий основные параметры, такие как: • количество пользователей и конкурентных соединений; • количество и состояние поставщиков ресурсов и фондов терминальных серверов; • количество и состояние компонентов («Универсальных диспетчеров», «Порталов», «Шлюзов»). 3.2.3 Возможность поиска в графическом веб-интерфейсе объектов и записей, в том числе по нескольким критериям одновременно. 3.2.4 Настраиваемое автоматическое обновление данных в графическом веб-интерфейсе без перезагрузки страницы целиком. - 2.9 Поиск пользователя в Microsoft Active Directory: • во вложенных группах сервера каталогов; • в распределенной архитектуре сервера каталогов Microsoft Active Directory («лесу»). 2.10 Авторизация пользователя на основе принадлежности к группе пользователей. 2.11 Аутентификация пользователей по протоколу SAML. 2.12 Аутентификация пользователей по протоколу OpenID Connect. 2.13 Аутентификация пользователей по смарт-картам и токенам Рутокен в домене Microsoft Active Directory. 2.14 Идентификация пользователей по IP-адресу с возможностью указания диапазона адресов. 2.15 Поддержка двухфакторной аутентификации на основе реестра кодов (TOTP) со следующими возможностями: • совместимость с TOTP приложениями, такими как: FreeOTP, Google Authenticator, Яндекс.Ключ; • валидация токена «Универсальным диспетчером»; • предоставление одноразовых кодов «Универсальным диспетчером»; • валидация кода сервером каталогов FreeIPA. 2.16 Поддержка режимов прямого соединения и соединения через «Шлюз» для протокола RDP. 2.17 Возможность настраиваемого перенаправления аппаратных устройств (принтеров, токенов, USB-носителей) и буфера обмена устройства доступа в терминальные сессии. 2.18 Возможность ограничения перенаправления USB-устройств по их Product ID и Vendor ID. 2.19 Возможность принудительной активации использования буфера обмена между узлом пользователя и терминальным сервером. 2.20 Возможность ограничения типа и объёма информации, передаваемой через буфер обмена. 2.21 Возможность принудительного указания направления работы буфера обмена между узлом пользователя и терминальным сервером. - 1.1 Решение, реализующее инфраструктуру терминальных серверов, должно включать в себя следующие отдельные программные компоненты (далее – Продукт): • «Универсальный диспетчер» — компонент, отвечающий за идентификацию пользователей, предоставление терминального доступа, а также предоставляющий графическую систему управления терминальным сервером («Портал администратора», «Портал пользователя», «Портал универсальный»); • «Шлюз» – компонент, обеспечивающий контролируемое и безопасное туннелирование доставки терминальных сессий по каналам связи через один внешний IP-адрес и порт; • «Клиент» – компонент, устанавливаемый на рабочее место пользователя и предоставляющий возможности доставки терминальных сессий авторизованным пользователям; • «Агент» – компонент, устанавливаемый на узел виртуализации или сервер терминалов, для передачи информационных сообщений и получения управляющих команд от «Универсального диспетчера», а также операций с ОС терминального сервера (ОС), гипервизором или терминальным сервером; • «Сервер терминалов Astra Linux» (STAL) компонент, обеспечивающий множественный пользовательский доступ к удаленному экземпляру рабочего стола или приложения; • «Виртуальный модуль Termidesk» — компонент, представляющий собой образ виртуальной машины (ВМ) (или диска ВМ) с предварительно установленной и настроенной ОС и набором программного обеспечения (ПО), необходимого для эксплуатации решения; • «Termidesk Live» – компонент, представляющий собой загрузочный образ ОС с предустановленным компонентом «Клиент». 1.2 Продукт должен функционировать в среде ОС специального назначения Astra Linux Special Edition не ниже 1.7. 1.3 Продукт должен поддерживать следующие встроенные механизмы безопасности сертифицированной ОС специального назначения Astra Linux Special Edition не ниже 1.7: замкнутая программная среда и мандатный контроль целостности. 1.4 Продукт предназначен для управления терминальными серверами и доступом пользователей к ним.

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

1. Общее описание решения - Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет; **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов. - - Значение характеристики не может изменяться участником закупки

1.5 Продукт должен поддерживать горизонтальное масштабирование «Универсальных диспетчеров» и «Шлюзов», а также обеспечивать высокую доступность (отказоустойчивость) «Универсальных диспетчеров». 1.6 В продукте должен быть реализован API проверки работоспособности компонентов (healthcheck), обеспечивающего функционирование программного комплекса для использования во внешних системах мониторинга. 1.7 В продукте должен быть реализован API получения метрик, характеризующих состояние узла и запущенных на нём компонентов продукта, доступный для использования во внешних системах мониторинга. 1.8 В продукте должен поддерживаться механизм централизованных настроек (далее - политики), применяемых без переконфигурации объектов. Политики должны применяться иерархически, глобально и на уровне фонда. 1.9 В продукте должна поддерживаться доставка рабочих столов и приложений в режиме удаленного доступа по протоколам RDP и собственной разработки. 2. Требования к решению 2.1 Наличие режима «Техническое обслуживание» для фондов и терминальных серверов. 2.2 Возможность работы с терминальными сессиями Microsoft Remote Desktop Services по протоколу RDP. 2.3 Возможность работы с удаленным доступом к приложениям, расположенным на сервере Microsoft Remote Desktop Services по протоколу RDP. 2.4 Возможность работы с терминальными Linux-сессиями по протоколу RDP. 2.5 Возможность работы с удаленным доступом к Linux-приложениям по протоколу RDP. 2.6 Возможность балансировки пользовательских сессий между терминальными серверами. 2.7 Получение сведений о пользователях и группах из следующих серверов каталогов: • ALD; • ALD Pro; • FreeIPA; • Microsoft Active Directory. 2.8 Аутентификация пользователей в следующих серверах каталогов: • ALD; • ALD Pro; • FreeIPA; • Microsoft Active Directory.

9. Требования к компоненту «Termidesk Live» 9.1 Загрузка c подготовленного USB-носителя. 9.2 Загрузка по сети с использованием технологии PXE-загрузки. 9.3 Наличие предустановленного компонента «Клиент». 9.4 Обеспечение работы компонента «Клиент». 9.5 Возможность добавления администратором приложений, отсутствующих в поставляемом образе компонента. 10. Дополнительные требования к Продукту 10.1 ПО должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и БД. 10.2 Наличие собственного центра разработки в России. 10.3 Наличие центра технической поддержки в России с возможностью приема заявок 24x7. 10.4 Наличие дорожной карты развития Продукта. 10.5 Наличие обучающих курсов на русском языке, доступных в учебных центрах на территории России. 10.6 Наличие документации по установке и эксплуатации Продукта на русском языке. 10.7 Наличие графического интерфейса Продукта на русском языке. 10.8 Наличие срочного и бессрочного лицензирования Продукта. 10.9 Наличие лицензирования по количеству конкурентных соединений (количество одновременных подключений пользователей к терминальным серверам) и по пользователям (именные лицензии, привязанные к пользователю). 10.10 Наличие двустороннего сертификата совместимости с ПО VMmanager (или эквивалент), подтверждающего корректность совместной работы.

7.8 Предоставление возможности указания размера экрана сессии. 7.9 Поддержка ограничения сессии пользователя по времени. 7.10 Поддержка установки таймера неактивности пользователя. 7.11 Поддержка настройки уровней безопасности протокола RDP. 7.12 Поддержка изолированных друг от друга сессий пользователей. 7.13 Поддержка собственного оконного менеджера для публикуемых приложений. 7.14 Возможность выбора ранее запущенной сессии для переподключения к ней. 8. Требования к компоненту «Виртуальный модуль Termidesk» 8.1 Поставка компонента в форматах: для гипервизоров QEMU/KVM и для платформы виртуализации VMware. 8.2 Наличие в компоненте соответствующих наборов инструментов гостевой ОС в зависимости от формата поставки. 8.3 Выполнение одной или нескольких функций решения каждым экземпляром компонента: • «Универсальный диспетчер»; • «Шлюз»; • «База данных». 8.4 Поддержка базового и усиленного режима защищенности ОС Astra Linux Special Edition не ниже 1.7. 8.5 Поддержка установки как в распределенном варианте, так и в режиме комплексной установки. 8.6 Предоставление псевдографического интерфейса администрирования. 8.7 Псевдографический интерфейс должен предоставлять следующие возможности по управлению компонентом: • изменение настроек сети; • диагностика сетевых подключений; • изменение имени узла; • смена пароля учетной записи администратора; • экспорт и импорт настроек продукта. 8.8 Компонент должен предоставлять графический веб-интерфейс администратора. 8.9 Графический веб-интерфейс администратора должен предоставлять следующие возможности по управлению компонентом: • управление состоянием служб ОС компонента; • настройка режима высокой доступности продукта; • формирование и выгрузка системных журналов компонента; • просмотр и замена используемого сертификата; • управление датой и временем ОС компонента.

6. Требования к компоненту «Агент» 6.1 Возможность установки в среде ОС терминального сервера, работающей под управлением ОС Microsoft Windows Server не ниже 2016, Astra Linux Special Edition не ниже 1.7 и прочих GNU/Linux. 6.2 Установка в ОС терминального сервера для обеспечения взаимодействия с компонентом «Универсальный диспетчер», конфигурации терминального сервера, фиксации действий пользователя и реализации управляющих сообщений. 6.3 Установка на терминальный сервер для предоставления возможностей публикации терминалов и удаленных приложений. 6.4 Установка на терминальный сервер для предоставления возможности множественного доступа пользователей к удалённым рабочим столам и приложениям. 6.5 Установка в ОС терминального сервера для перенаправления смарт-карт с пользовательской рабочей станции в режиме совместного использования. 6.6 Установка в ОС терминального сервера для перенаправления видеокамеры с пользовательской рабочей станции в оптимизированном режиме. 6.7 Взаимодействие с «Универсальным диспетчером» по протоколу HTTPS. 6.8 Поддержка автозапуска при старте ОС терминального сервера. 6.9 Поддержка интеграции с системным журналом ОС терминального сервера. 7. Требования к компоненту «Сервер терминалов Astra Linux» (STAL) 7.1 Возможность установки в среде ОС, работающей под управлением ОС Astra Linux Special Edition не ниже 1.7. 7.2 Предоставление доступа пользователям к терминальной сессии по протоколу RDP. 7.3 Предоставление доступа пользователям к экрану одного приложения. 7.4 Использование одного TCP порта для подключения пользователей. 7.5 Использование режима проверки пользовательского запроса NTLM. 7.6 Предоставление списка установленных и размещенных в графическом меню приложений для режима удаленного доступа к приложениям. 7.7 Предоставление возможности указания произвольного установленного приложения для режима удаленного доступа к приложениям.

5.12 Поддержка возможности перенаправления (захвата) клавиатуры и указателя мыши из ОС пользовательской рабочей станции в терминальную сессию. 5.13 Обеспечение выбора протоколов доставки терминальных сессий. 5.14 Отключаемая возможность сохранения имени пользователя и пароля для повторного использования. 5.15 Возможность автоматического подключения к серверу решения, указанному посредством TXT-записи на сервере DNS. 5.16 Предоставление пользователю возможности управлять перенаправлением локальных ресурсов в соответствии с назначенными политиками. 5.17 Возможность перенаправления принтеров в режиме совместного использования в пользовательской рабочей станции и терминальной сессии. 5.18 Возможность выбора драйвера для перенаправляемого принтера. 5.19 Возможность перенаправления каталогов из файловой системы пользовательской рабочей станции в терминальную сессию. 5.20 Возможность перенаправления USB-токенов и смарт-карт в режиме совместного использования в пользовательской рабочей станции и терминальной сессии (оптимизация перенаправления). 5.21 Возможность аутентификации пользователей по смарт-картам и токенам Рутокен в домене Microsoft Active Directory. 5.22 Возможность работы с несколькими мониторами. 5.23 Возможность сопоставления виртуальных мониторов физическим. 5.24 Возможность управления отображением панели инструментов в полноэкранном режиме. 5.25 Возможность выгрузки отладочной информации для службы технической поддержки из графического интерфейса приложения. 5.26 Возможность настраиваемого автоматического переподключения к ранее запущенным сеансам. 5.27 Возможность управления активными сеансами из единого центра подключений.

4. Требования к компоненту «Шлюз» 4.1 Возможность установки совместно с «Универсальным диспетчером». 4.2 Возможность установки отдельно от «Универсального диспетчера». 4.3 Туннелирование протоколов доставки посредством протокола Websocket. 4.4 Проксирование подключений пользователей к терминальным серверам. 4.5 Использование одного внешнего IP-адреса и TCP-порта для подключений к публикуемым ресурсам. 4.6 Возможность использования безопасного транспорта SSL/TLS при доставке терминальных сессий. 4.7 Валидация пользовательских подключений. 4.8 Предоставление статистики подключений в формате JSON. 4.9 Предоставление API проверки работоспособности компонента (healthcheck). 4.10 Предоставление API сбора метрик узла. 5. Требования к компоненту «Клиент» 5.1 Возможность установки и использования в средах ОС Microsoft Windows не ниже 10, Astra Linux Special Edition не ниже 1.7 и других ОС на базе ядра GNU/Linux. 5.2 Обеспечение консольного и графического режима запуска. 5.3 Прием параметров из командной строки для настройки подключения к «Универсальному диспетчеру». 5.4 Отключаемая возможность запуска во множественном экземпляре. 5.5 Подключение к нескольким инсталляциям Termidesk. 5.6 Визуализация списка доступных рабочих столов и приложений в графическом виде. 5.7 Возможность формирования пользовательской группы (избранное) для последующего быстрого доступа к выбранным рабочим столам и приложениям. 5.8 Обеспечение настраиваемой сортировки объектов. 5.9 Возможность выбора языка: предустановленного или используемого в ОС. 5.10 Возможность использования светлой и темной тем оформления. 5.11 Поддержка централизованной конфигурации используемых функций, назначаемых через интерфейс управления.

3.2.13 Перенаправление событий на несколько внешних серверов по протоколу SYSLOG. 3.2.14 Возможность подключения к внешнему серверу SYSLOG по протоколам TCP, UDP и TLS. 3.2.15 Выгрузка журнала и событий аудита в формате CSV. 3.2.16 Построение и выгрузка отчетов для следующих действий пользователей: • вход в систему; • сеанс; • подключение. 3.2.17 Оповещение администраторов о нештатных ситуациях по электронной почте. 3.2.18 Возможность указания ограничения длительности сессии пользователя. 3.2.19 Принудительная блокировка пользователя из графического веб-интерфейса. 3.2.20 Блокировка на заданный промежуток времени доступа пользователя к «Универсальному диспетчеру» при превышении заданного количества попыток входа. 3.2.21 Указание максимального количества неудачных попыток входа пользователя. 3.2.22 Разблокировка заблокированного пользователя из графического веб-интерфейса. 3.2.23 Возможность настройки произвольного текста, выводимого в графический веб-интерфейс пользователя при ошибке входа. 3.2.24 Возможность установки приоритета использования протокола доставки рабочих столов и приложений. 3.2.25 Возможность указания URL-адреса ресурса, на котором осуществляется поддержка пользователей. 3.2.26 Возможность загрузки и размещения картинки для визуализации назначения фонда. 3.2.27 Возможность предоставления доступа к фонду конкретному пользователю и группе пользователей. 3.2.28 Возможность выгрузки файла для запроса лицензии. 3.3 Возможности для пользователя 3.3.1 Доступ к графическому интерфейсу из веб-обозревателя по протоколу HTTPS. 3.3.2 Доступ посредством компонента «Клиент». 3.3.3 Возможность выбора домена аутентификации. 3.3.4 Предоставление списка доступных пользователю ресурсов. 3.3.5 Возможность группировки ресурсов. 3.3.6 Возможность выбора протокола подключения. 3.3.7 Возможность вызова установленного в системе «Клиента» при запуске ресурса из веб-обозревателя.

3.2.5 Графический веб-интерфейс с функцией мастеров, упрощающих процесс публикации рабочих столов и приложений. 3.2.6 Наличие CLI-интерфейса, позволяющего выполнять следующие функции: • вывод версии «Универсального диспетчера»; • управление системными настройками (просмотр и изменение); • управление способами аутентификации; • управление протоколами доставки. 3.2.7 Наличие REST API-интерфейса, минимально предоставляющего следующие возможности: • доступ по токену безопасности; • документирование доступных функций; • автоматическое обнаружение функций и версии API; • управление системными настройками (просмотр и изменение); • управление способами аутентификации; • управление протоколами доставки; • управление объектами инфраструктуры; • управление листами доступа (ACL) и ролями; • управление политиками; • управление фондами терминальных серверов; • управление сессиями пользователей. 3.2.8 Ограничение доступа к графическому веб-интерфейсу по следующим критериям: • количеству попыток входа; • заблокированным администраторам. 3.2.9 Возможность указания ограничения длительности сессии администратора. 3.2.10 Визуализация событий аудита в графическом веб-интерфейсе со следующими возможностями: • вывод всех событий аудита; • вывод событий в соответствии с заданным фильтром; • поиск событий в заданный временной интервал. 3.2.11 Возможность сбора и хранения статистики, мониторинг состояния терминальных серверов с функцией визуализации системных событий, источников их возникновения, уровня важности. 3.2.12 Возможность отслеживания всех событий, ассоциированных с сеансом пользователя, при помощи глобального уникального сессионного идентификатора.

3. Требования к компоненту «Универсальный диспетчер» 3.1 Общие возможности 3.1.1 Наличие установщика, работающего в диалоговом режиме с возможностью настройки протокола подключения к базе данных (БД) и брокеру сообщений. 3.1.2 Выполнение установки в соответствии с заданной ролью узла (портал администратора, портал пользователя) 3.1.3 Возможность совмещения нескольких ролей на одном узле. 3.1.4 Настройка параметров доступа к системе, позволяющая: • управлять полномочиями пользователей из графического веб-интерфейса; • назначать полномочия отдельным пользователям и группам; • отображать графический веб-интерфейс администратора в соответствии с его полномочиями; • назначать полномочия пользователям для делегирования функций администратора; • назначать полномочия просмотра, создания, удаления и редактирования для функций управления «Универсальным диспетчером». 3.1.5 Наличие аудита действий администратора с возможностью ведения журнала в файле, внутренней БД и отправки на внешние серверы по протоколу SYSLOG. 3.1.6 Настраиваемая ротация журнала аудита событий. 3.1.7 Поддержка хранения паролей во внешних хранилищах секретов. 3.2 Возможности для администратора 3.2.1 Доступ к графическому интерфейсу управления из веб-обозревателя по протоколу HTTPS. 3.2.2 Наглядный графический веб-интерфейс, визуализирующий основные параметры, такие как: • количество пользователей и конкурентных соединений; • количество и состояние поставщиков ресурсов и фондов терминальных серверов; • количество и состояние компонентов («Универсальных диспетчеров», «Порталов», «Шлюзов»). 3.2.3 Возможность поиска в графическом веб-интерфейсе объектов и записей, в том числе по нескольким критериям одновременно. 3.2.4 Настраиваемое автоматическое обновление данных в графическом веб-интерфейсе без перезагрузки страницы целиком.

2.9 Поиск пользователя в Microsoft Active Directory: • во вложенных группах сервера каталогов; • в распределенной архитектуре сервера каталогов Microsoft Active Directory («лесу»). 2.10 Авторизация пользователя на основе принадлежности к группе пользователей. 2.11 Аутентификация пользователей по протоколу SAML. 2.12 Аутентификация пользователей по протоколу OpenID Connect. 2.13 Аутентификация пользователей по смарт-картам и токенам Рутокен в домене Microsoft Active Directory. 2.14 Идентификация пользователей по IP-адресу с возможностью указания диапазона адресов. 2.15 Поддержка двухфакторной аутентификации на основе реестра кодов (TOTP) со следующими возможностями: • совместимость с TOTP приложениями, такими как: FreeOTP, Google Authenticator, Яндекс.Ключ; • валидация токена «Универсальным диспетчером»; • предоставление одноразовых кодов «Универсальным диспетчером»; • валидация кода сервером каталогов FreeIPA. 2.16 Поддержка режимов прямого соединения и соединения через «Шлюз» для протокола RDP. 2.17 Возможность настраиваемого перенаправления аппаратных устройств (принтеров, токенов, USB-носителей) и буфера обмена устройства доступа в терминальные сессии. 2.18 Возможность ограничения перенаправления USB-устройств по их Product ID и Vendor ID. 2.19 Возможность принудительной активации использования буфера обмена между узлом пользователя и терминальным сервером. 2.20 Возможность ограничения типа и объёма информации, передаваемой через буфер обмена. 2.21 Возможность принудительного указания направления работы буфера обмена между узлом пользователя и терминальным сервером.

1.1 Решение, реализующее инфраструктуру терминальных серверов, должно включать в себя следующие отдельные программные компоненты (далее – Продукт): • «Универсальный диспетчер» — компонент, отвечающий за идентификацию пользователей, предоставление терминального доступа, а также предоставляющий графическую систему управления терминальным сервером («Портал администратора», «Портал пользователя», «Портал универсальный»); • «Шлюз» – компонент, обеспечивающий контролируемое и безопасное туннелирование доставки терминальных сессий по каналам связи через один внешний IP-адрес и порт; • «Клиент» – компонент, устанавливаемый на рабочее место пользователя и предоставляющий возможности доставки терминальных сессий авторизованным пользователям; • «Агент» – компонент, устанавливаемый на узел виртуализации или сервер терминалов, для передачи информационных сообщений и получения управляющих команд от «Универсального диспетчера», а также операций с ОС терминального сервера (ОС), гипервизором или терминальным сервером; • «Сервер терминалов Astra Linux» (STAL) компонент, обеспечивающий множественный пользовательский доступ к удаленному экземпляру рабочего стола или приложения; • «Виртуальный модуль Termidesk» — компонент, представляющий собой образ виртуальной машины (ВМ) (или диска ВМ) с предварительно установленной и настроенной ОС и набором программного обеспечения (ПО), необходимого для эксплуатации решения; • «Termidesk Live» – компонент, представляющий собой загрузочный образ ОС с предустановленным компонентом «Клиент». 1.2 Продукт должен функционировать в среде ОС специального назначения Astra Linux Special Edition не ниже 1.7. 1.3 Продукт должен поддерживать следующие встроенные механизмы безопасности сертифицированной ОС специального назначения Astra Linux Special Edition не ниже 1.7: замкнутая программная среда и мандатный контроль целостности. 1.4 Продукт предназначен для управления терминальными серверами и доступом пользователей к ним.

- 58.29.50.000 - Лицензия на систему резервного копирования "RuBackup", включает 1ТБ хранимых резервных копий, «back-end» Описание Программное обеспечение (далее - СРК) должно соответствовать требованиям Постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». СРК должно отвечать следующим требованиям: • Управление СРК должно осуществляться с помощью: o WEB-интерфейса; o графического интерфейса; o утилиты командной строки; o программного интерфейса REST API. • Обеспечивать возможность централизованного управления и планирования работы с помощью централизованного расписания резервного копирования. Должна быть обеспечена возможность делегирования управления локальным расписанием резервного копирования клиенту системы резервного копирования. • Обеспечивать ролевую модель доступа к административным функциям системы резервного копирования. Должна быть обеспечена возможность разграничения доступа для нескольких администраторов единой системы резервного копирования. • Обеспечивать возможность аутентификации пользователей с помощью Microsoft Active Directory. • Обеспечивать возможность аутентификации пользователей с помощью ALD Pro. • Обеспечивать приоритизацию заданий резервного копирования. • Обеспечивать возможность разрешения, запрета централизованного восстановления, а также возможность запрета восстановления, инициации резервного копирования со стороны клиента. • Обеспечивать возможность выполнения групповых операций для нескольких клиентов одновременно. • Предоставлять автономный режим работы клиента с возможностью резервирования данных на локальное устройство хранения. • Обеспечивать возможность установки минимального обязательного периода хранения любых резервных копий, без возможности их удаления из системы резервного копирования. ... - Штука - 1,00 - 22 036,00 - 22 036,00

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ ЗДРАВООХРАНЕНИЯ "КУЗБАССКИЙ КЛИНИЧЕСКИЙ КАРДИОЛОГИЧЕСКИЙ ДИСПАНСЕР ИМЕНИ АКАДЕМИКА Л.С. БАРБАРАША" - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Описание Программное обеспечение (далее - СРК) должно соответствовать требованиям Постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». СРК должно отвечать следующим требованиям: • Управление СРК должно осуществляться с помощью: o WEB-интерфейса; o графического интерфейса; o утилиты командной строки; o программного интерфейса REST API. • Обеспечивать возможность централизованного управления и планирования работы с помощью централизованного расписания резервного копирования. Должна быть обеспечена возможность делегирования управления локальным расписанием резервного копирования клиенту системы резервного копирования. • Обеспечивать ролевую модель доступа к административным функциям системы резервного копирования. Должна быть обеспечена возможность разграничения доступа для нескольких администраторов единой системы резервного копирования. • Обеспечивать возможность аутентификации пользователей с помощью Microsoft Active Directory. • Обеспечивать возможность аутентификации пользователей с помощью ALD Pro. • Обеспечивать приоритизацию заданий резервного копирования. • Обеспечивать возможность разрешения, запрета централизованного восстановления, а также возможность запрета восстановления, инициации резервного копирования со стороны клиента. • Обеспечивать возможность выполнения групповых операций для нескольких клиентов одновременно. • Предоставлять автономный режим работы клиента с возможностью резервирования данных на локальное устройство хранения. • Обеспечивать возможность установки минимального обязательного периода хранения любых резервных копий, без возможности их удаления из системы резервного копирования. Значение характеристики не может изменяться участником закупки • Обеспечивать возможность архивации и архивного хранения файлов с возможностью использования того же клиентского ПО, что и для резервного копирования, и передача их на долговременное хранение. • Обеспечивать возможность временной приостановки и продолжения работы задач резервного копирования. • Предоставлять журнал аутентификации пользователей. • Предоставлять защиту от случайного удаления резервных копий из хранилища, в том числе суперпользователем (root) без предварительного изменения атрибутов копии суперпользователем. • Предоставлять защиту от случайного ручного и автоматического удаления последней резервной копии источника данных в средствах управления СРК. • Предоставлять возможность использования предварительно настроенного аварийного локального хранилища резервных копий в случае отсутствия места в основном хранилище. • Обеспечивать возможность экспорта и импорта резервных копий между независимыми инсталляциями СРК. • Обеспечивать возможность выполнения pre- и post- скриптов в процессе создания резервной копии и в процессе восстановления резервной копии. • Обеспечивать возможность создания плана регламентного обслуживания для клиентов и групп клиентов СРК, с выбором определённых источников данных. • Обеспечивать возможность частичного восстановления данных из резервных копий (отдельные файлы). СРК должно иметь клиент-серверную архитектуру, включающую следующие компоненты: • Основной сервер СРК, включающий СУБД для хранения метаданных резервных копий и конфигурационных параметров СРК; • Медиасервер (сервера на которых подключены устройства хранения резервных копий); • Агент СРК. СРК должна поддерживать одновременную установку всех компонентов на один физический или виртуальный сервер при выполнении консолидированных аппаратных требований, предъявляемых компонентами к серверу, на который производится установка. Основной сервер СРК должен отвечать следующим требованиям: • Имеет возможность установки на следующие операционные системы (ОС) архитектуры x64: o ALT Linux версии 10; o Astra Linux версий 1.6, 1.7, 1.8; o RedOS версий 7.3, 8; o Rosa Cobalt версий 7.3, 7.9; o Rosa Chrome версии 12; o Debian версий 10, 12; o Ubuntu версий 18.04, 20.04, 22.04; o CentOS версий 7, 8; o RHEL версии 9. • Поддерживать PostgreSQL из репозиториев поддерживаемых ОС в качестве СУБД. • Иметь возможность подключения компонентов СРК к СУБД и администратора с использованием защищённого соединения SSL. • Поддерживать работу в режиме высокой доступности: o Поддерживать конфигурации СУБД с использованием решения Patroni, развернутом на отдельно стоящих серверах; o Основной сервер СРК должен иметь возможность использования дополнительного Резервного сервера. В таком режиме Резервный сервер, в случае отказа основного сервера, должен обеспечить функционал основного сервера СРК, а Агенты СРК должны переключиться на резервный сервер. После восстановления функционирования основного сервера, Агенты СРК должны подключаться к основному серверу. o Создание резервного сервера управления механизмов и переключения функционала должны обеспечиваться средствами СРК без использования стороннего ПО. Медиасервер СРК должен отвечать следующим требованиям: • Поддерживать хранение резервных копий в: o блочных устройствах; o файловых системах; o ленточных библиотеках, включая устройства VTL (виртуальные ленточные библиотеки); o устройствах TATLIN.BACKUP; o облаках и устройствах S3, включая MinIO, VK Сloud Storage, TATLIN.OBJECT. • Поддерживать резервное копирование на ленточные библиотеки с использованием LTFS. • Обеспечивать возможность добавления в серверную группировку СРК неограниченного количества дополнительных медиа-серверов для последующего масштабирования и возможности распределения потоков данных. • Обеспечивать возможность автоматического удаления устаревших резервных копий, возможность автоматического перемещения резервных копий на другие устройства хранения в зависимости от срока хранения, возможность автоматической репликации резервных копий при их создании. • Обеспечивать возможность автоматической проверки резервных копий для контроля их целостности. • Дедупликация резервных копий должна осуществляться как на блочные устройства, так и на файловые системы. • Обеспечивать возможность непрерывной удаленной репликации для файловых систем и систем виртуализации ПК СВ «Брест». • Обеспечивать автоматическую балансировку задач резервного копирования между пулами и медиа-серверами резервного копирования по заданным параметрам. Агент СРК должен отвечать следующим требованиям: • Обеспечивать резервное копирование операционной системы Astra Linux Special Edition версий 1.6, 1.7, 1.7.5, 1.8, в том числе обеспечивать резервное копирование без нарушения мандатных атрибутов. • Обеспечивать возможность резервного копирования следующих ОС: o CentOS версий 7, 8 o AltLinux версии 10 o RedOS версии 7.3, o РОСА "Кобальт" версий 7.3, 7.9, o РОСА "Хром" версии 12; o Red Hat Enterprise Linux (RHEL) версий 7, 8, 9; o Ubuntu версий 22.04, 20.04; o Windows Server версий 2012-2022 файловой системы с поддержкой VSS. • Обеспечивать возможность электронной подписи создаваемой резервной копии для последующего подтверждения её подлинности. • Обеспечить возможность защитного преобразования резервных копий с использованием алгоритма ГОСТ Р 34.12-2015 «Кузнечик». • Обеспечивать резервное копирование СУБД PostgreSQL версий 11-17: o Поддержка непрерывного резервного копирования с периодическим резервным копированием архивных WAL файлов. o Поддержка выполнения резервного копирования PostgreSQL в кластерной среде (Patroni), с возможностью создания резервной копии как с мастера, синхронной реплики, асинхронной реплики, а также иметь возможность автоопределения мастера и реплик кластера с автоматическим переключением между ними. o Поддержка выполнения потабличного резервного копирования и восстановления СУБД, как в обычном режиме, так и в кластерной конфигурации с использованием Patroni. o Поддержка режима PTRACK, PAGE и DELTA, а также интеграции с pg_probackup. o Поддержка создания резервных копий баз данных с применением механизма моментальных снимков LVM. o Поддержка создания резервных копий баз данных с применением механизма моментальных снимков dattobd (Datto Block Driver). o Поддержка создания резервных копий баз данных с применением механизма аппаратных моментальных снимков СХД TATLIN.UNIFIED. o Поддержка интеграции с утилитой pg_probackup для резервного копирования и восстановления баз данных в S3-хранилище без передачи данных через сервера СРК. o Поддержка резервного копирования баз данных с включенной логической репликацией, параметр wal_level = logical. • Обеспечивать резервное копирование СУБД Oracle версий 10g, 11g, 12c, 18c, 19c: o Поддержка полного и инкрементального резервного копирования. o Поддержка полного восстановления баз данных на момент выполнения резервного копирования. o Поддержка восстановления на заданный момент времени (point-in-time recovery). • Обеспечивать резервное копирование СУБД Yandex Database. • Обеспечивать резервное копирование СУБД Microsoft SQL Server версий 2014, 2016, 2017, 2019. 2022: o Поддержка резервного копирования в режиме Open Database Connectivity (ODBC) o Поддержка резервного копирования в режиме Volume Shadow Copy (VSS) o Поддержка полного, инкрементального и дифференциального резервного копирования в режиме ODBC o Поддержка полного и дифференциального резервного копирования в режиме VSS. • Обеспечивать резервное копирование СУБД SAP HANA: o Поддержка полного, инкрементального и дифференциального резервного копирования. o Поддержка полного восстановления баз данных на момент выполнения резервного копирования. o Поддержка восстановление на заданный момент времени (point-in-time recovery). • Обеспечивать поддержку выполнения резервного копирования почтовых систем: o CommunigatePro 6.3 с возможностью гранулярного восстановления вплоть до письма. o VK WorkMail с возможностью гранулярного восстановления вплоть до письма. o RuPost с возможностью инкрементального резервного копирования. • Обеспечивать поддержку выполнения резервного копирования FreeIPA версий 4.7; 4.8, 4.9; • Полное, инкрементальное и дифференциальное резервное копирование файловых систем: o ext2, ext3, ext4; o Xfs; o lvm2; o NTFS; o ZFS; o Btrfs. • Обеспечивать резервное копирование томов LVM. • Иметь возможность создания консистентных резервных копий файловых систем с использованием моментальных снимков LVM и dattobd (Datto Block Driver). СРК должно поддерживать безагентное резервное копирование сред виртуализации: • Microsoft Hyper-V. • Proxmox VE. • RUSTACK, а также поддерживать типы хранилищ РУСТЭК: OCFS2, NFS, NetApp-ISCSI. • oVirt/zVirt/REDVirt. • ROSA Virtualization версий 2.1, 3.0. • VMmanager 6 c возможностью резервного копирования и восстановления виртуальных машин. Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. • OpenStack: Zed, Yoga, Xena, Antelope. Включая возможность выполнения пользовательских сценариев во время задачи резервного копирования модулем OpenStack через SSH (без использования QEMU-agent). • ПК СВ «Брест» версий 3.3, 3.2, 3.1, 2.12. Должна быть реализована возможность выполнения полных, инкрементальных и дифференциальных резервных копий для виртуальных машин и возможность выполнения полных резервных копий для шаблонов виртуальных машин. При выполнении резервного копирования функционирующих виртуальных машин должна быть возможность исполнить в них скрипт перед созданием моментального снимка виртуальной машины и сразу после создания снимка виртуальной машины для того, чтобы можно было привести данные функционирующих в виртуальной машине приложений в консистентное состояние. Должны поддерживаться типы хранилищ ПК СВ «Брест» и методы передачи данных: Ceph (ceph), Filesystem (qcow2, shared), LVM (lvm_lvm), OCFS2. • VMware vSphere 6.7, 7, 8, обеспечить возможность резервного копирования виртуальных машин с использованием методов NBD/NBDSSL, HOTADD. • BASIS.Dynamix Enterprise версий 3.8.8, 4.0, 4.1, Tionix. • АЭРОДИСК VAIR версий 3.7, 3.8, 4.0. Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет. **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов. - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Описание - Программное обеспечение (далее - СРК) должно соответствовать требованиям Постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». СРК должно отвечать следующим требованиям: • Управление СРК должно осуществляться с помощью: o WEB-интерфейса; o графического интерфейса; o утилиты командной строки; o программного интерфейса REST API. • Обеспечивать возможность централизованного управления и планирования работы с помощью централизованного расписания резервного копирования. Должна быть обеспечена возможность делегирования управления локальным расписанием резервного копирования клиенту системы резервного копирования. • Обеспечивать ролевую модель доступа к административным функциям системы резервного копирования. Должна быть обеспечена возможность разграничения доступа для нескольких администраторов единой системы резервного копирования. • Обеспечивать возможность аутентификации пользователей с помощью Microsoft Active Directory. • Обеспечивать возможность аутентификации пользователей с помощью ALD Pro. • Обеспечивать приоритизацию заданий резервного копирования. • Обеспечивать возможность разрешения, запрета централизованного восстановления, а также возможность запрета восстановления, инициации резервного копирования со стороны клиента. • Обеспечивать возможность выполнения групповых операций для нескольких клиентов одновременно. • Предоставлять автономный режим работы клиента с возможностью резервирования данных на локальное устройство хранения. • Обеспечивать возможность установки минимального обязательного периода хранения любых резервных копий, без возможности их удаления из системы резервного копирования. - - Значение характеристики не может изменяться участником закупки - • Обеспечивать возможность архивации и архивного хранения файлов с возможностью использования того же клиентского ПО, что и для резервного копирования, и передача их на долговременное хранение. • Обеспечивать возможность временной приостановки и продолжения работы задач резервного копирования. • Предоставлять журнал аутентификации пользователей. • Предоставлять защиту от случайного удаления резервных копий из хранилища, в том числе суперпользователем (root) без предварительного изменения атрибутов копии суперпользователем. • Предоставлять защиту от случайного ручного и автоматического удаления последней резервной копии источника данных в средствах управления СРК. • Предоставлять возможность использования предварительно настроенного аварийного локального хранилища резервных копий в случае отсутствия места в основном хранилище. • Обеспечивать возможность экспорта и импорта резервных копий между независимыми инсталляциями СРК. • Обеспечивать возможность выполнения pre- и post- скриптов в процессе создания резервной копии и в процессе восстановления резервной копии. • Обеспечивать возможность создания плана регламентного обслуживания для клиентов и групп клиентов СРК, с выбором определённых источников данных. • Обеспечивать возможность частичного восстановления данных из резервных копий (отдельные файлы). СРК должно иметь клиент-серверную архитектуру, включающую следующие компоненты: • Основной сервер СРК, включающий СУБД для хранения метаданных резервных копий и конфигурационных параметров СРК; • Медиасервер (сервера на которых подключены устройства хранения резервных копий); • Агент СРК. СРК должна поддерживать одновременную установку всех компонентов на один физический или виртуальный сервер при выполнении консолидированных аппаратных требований, предъявляемых компонентами к серверу, на который производится установка. - Основной сервер СРК должен отвечать следующим требованиям: • Имеет возможность установки на следующие операционные системы (ОС) архитектуры x64: o ALT Linux версии 10; o Astra Linux версий 1.6, 1.7, 1.8; o RedOS версий 7.3, 8; o Rosa Cobalt версий 7.3, 7.9; o Rosa Chrome версии 12; o Debian версий 10, 12; o Ubuntu версий 18.04, 20.04, 22.04; o CentOS версий 7, 8; o RHEL версии 9. • Поддерживать PostgreSQL из репозиториев поддерживаемых ОС в качестве СУБД. • Иметь возможность подключения компонентов СРК к СУБД и администратора с использованием защищённого соединения SSL. • Поддерживать работу в режиме высокой доступности: o Поддерживать конфигурации СУБД с использованием решения Patroni, развернутом на отдельно стоящих серверах; o Основной сервер СРК должен иметь возможность использования дополнительного Резервного сервера. В таком режиме Резервный сервер, в случае отказа основного сервера, должен обеспечить функционал основного сервера СРК, а Агенты СРК должны переключиться на резервный сервер. После восстановления функционирования основного сервера, Агенты СРК должны подключаться к основному серверу. o Создание резервного сервера управления механизмов и переключения функционала должны обеспечиваться средствами СРК без использования стороннего ПО. Медиасервер СРК должен отвечать следующим требованиям: • Поддерживать хранение резервных копий в: o блочных устройствах; o файловых системах; o ленточных библиотеках, включая устройства VTL (виртуальные ленточные библиотеки); o устройствах TATLIN.BACKUP; o облаках и устройствах S3, включая MinIO, VK Сloud Storage, TATLIN.OBJECT. • Поддерживать резервное копирование на ленточные библиотеки с использованием LTFS. • Обеспечивать возможность добавления в серверную группировку СРК неограниченного количества дополнительных медиа-серверов для последующего масштабирования и возможности распределения потоков данных. - • Обеспечивать возможность автоматического удаления устаревших резервных копий, возможность автоматического перемещения резервных копий на другие устройства хранения в зависимости от срока хранения, возможность автоматической репликации резервных копий при их создании. • Обеспечивать возможность автоматической проверки резервных копий для контроля их целостности. • Дедупликация резервных копий должна осуществляться как на блочные устройства, так и на файловые системы. • Обеспечивать возможность непрерывной удаленной репликации для файловых систем и систем виртуализации ПК СВ «Брест». • Обеспечивать автоматическую балансировку задач резервного копирования между пулами и медиа-серверами резервного копирования по заданным параметрам. Агент СРК должен отвечать следующим требованиям: • Обеспечивать резервное копирование операционной системы Astra Linux Special Edition версий 1.6, 1.7, 1.7.5, 1.8, в том числе обеспечивать резервное копирование без нарушения мандатных атрибутов. • Обеспечивать возможность резервного копирования следующих ОС: o CentOS версий 7, 8 o AltLinux версии 10 o RedOS версии 7.3, o РОСА "Кобальт" версий 7.3, 7.9, o РОСА "Хром" версии 12; o Red Hat Enterprise Linux (RHEL) версий 7, 8, 9; o Ubuntu версий 22.04, 20.04; o Windows Server версий 2012-2022 файловой системы с поддержкой VSS. • Обеспечивать возможность электронной подписи создаваемой резервной копии для последующего подтверждения её подлинности. • Обеспечить возможность защитного преобразования резервных копий с использованием алгоритма ГОСТ Р 34.12-2015 «Кузнечик». • Обеспечивать резервное копирование СУБД PostgreSQL версий 11-17: o Поддержка непрерывного резервного копирования с периодическим резервным копированием архивных WAL файлов. - o Поддержка выполнения резервного копирования PostgreSQL в кластерной среде (Patroni), с возможностью создания резервной копии как с мастера, синхронной реплики, асинхронной реплики, а также иметь возможность автоопределения мастера и реплик кластера с автоматическим переключением между ними. o Поддержка выполнения потабличного резервного копирования и восстановления СУБД, как в обычном режиме, так и в кластерной конфигурации с использованием Patroni. o Поддержка режима PTRACK, PAGE и DELTA, а также интеграции с pg_probackup. o Поддержка создания резервных копий баз данных с применением механизма моментальных снимков LVM. o Поддержка создания резервных копий баз данных с применением механизма моментальных снимков dattobd (Datto Block Driver). o Поддержка создания резервных копий баз данных с применением механизма аппаратных моментальных снимков СХД TATLIN.UNIFIED. o Поддержка интеграции с утилитой pg_probackup для резервного копирования и восстановления баз данных в S3-хранилище без передачи данных через сервера СРК. o Поддержка резервного копирования баз данных с включенной логической репликацией, параметр wal_level = logical. • Обеспечивать резервное копирование СУБД Oracle версий 10g, 11g, 12c, 18c, 19c: o Поддержка полного и инкрементального резервного копирования. o Поддержка полного восстановления баз данных на момент выполнения резервного копирования. o Поддержка восстановления на заданный момент времени (point-in-time recovery). • Обеспечивать резервное копирование СУБД Yandex Database. • Обеспечивать резервное копирование СУБД Microsoft SQL Server версий 2014, 2016, 2017, 2019. 2022: o Поддержка резервного копирования в режиме Open Database Connectivity (ODBC) o Поддержка резервного копирования в режиме Volume Shadow Copy (VSS) o Поддержка полного, инкрементального и дифференциального резервного копирования в режиме ODBC - o Поддержка полного и дифференциального резервного копирования в режиме VSS. • Обеспечивать резервное копирование СУБД SAP HANA: o Поддержка полного, инкрементального и дифференциального резервного копирования. o Поддержка полного восстановления баз данных на момент выполнения резервного копирования. o Поддержка восстановление на заданный момент времени (point-in-time recovery). • Обеспечивать поддержку выполнения резервного копирования почтовых систем: o CommunigatePro 6.3 с возможностью гранулярного восстановления вплоть до письма. o VK WorkMail с возможностью гранулярного восстановления вплоть до письма. o RuPost с возможностью инкрементального резервного копирования. • Обеспечивать поддержку выполнения резервного копирования FreeIPA версий 4.7; 4.8, 4.9; • Полное, инкрементальное и дифференциальное резервное копирование файловых систем: o ext2, ext3, ext4; o Xfs; o lvm2; o NTFS; o ZFS; o Btrfs. • Обеспечивать резервное копирование томов LVM. • Иметь возможность создания консистентных резервных копий файловых систем с использованием моментальных снимков LVM и dattobd (Datto Block Driver). СРК должно поддерживать безагентное резервное копирование сред виртуализации: • Microsoft Hyper-V. • Proxmox VE. • RUSTACK, а также поддерживать типы хранилищ РУСТЭК: OCFS2, NFS, NetApp-ISCSI. • oVirt/zVirt/REDVirt. • ROSA Virtualization версий 2.1, 3.0. • VMmanager 6 c возможностью резервного копирования и восстановления виртуальных машин. Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. • OpenStack: Zed, Yoga, Xena, Antelope. Включая возможность выполнения пользовательских сценариев во время задачи резервного копирования модулем OpenStack через SSH (без использования QEMU-agent). - • ПК СВ «Брест» версий 3.3, 3.2, 3.1, 2.12. Должна быть реализована возможность выполнения полных, инкрементальных и дифференциальных резервных копий для виртуальных машин и возможность выполнения полных резервных копий для шаблонов виртуальных машин. При выполнении резервного копирования функционирующих виртуальных машин должна быть возможность исполнить в них скрипт перед созданием моментального снимка виртуальной машины и сразу после создания снимка виртуальной машины для того, чтобы можно было привести данные функционирующих в виртуальной машине приложений в консистентное состояние. Должны поддерживаться типы хранилищ ПК СВ «Брест» и методы передачи данных: Ceph (ceph), Filesystem (qcow2, shared), LVM (lvm_lvm), OCFS2. • VMware vSphere 6.7, 7, 8, обеспечить возможность резервного копирования виртуальных машин с использованием методов NBD/NBDSSL, HOTADD. • BASIS.Dynamix Enterprise версий 3.8.8, 4.0, 4.1, Tionix. • АЭРОДИСК VAIR версий 3.7, 3.8, 4.0. Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет. **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов.

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

Описание - Программное обеспечение (далее - СРК) должно соответствовать требованиям Постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». СРК должно отвечать следующим требованиям: • Управление СРК должно осуществляться с помощью: o WEB-интерфейса; o графического интерфейса; o утилиты командной строки; o программного интерфейса REST API. • Обеспечивать возможность централизованного управления и планирования работы с помощью централизованного расписания резервного копирования. Должна быть обеспечена возможность делегирования управления локальным расписанием резервного копирования клиенту системы резервного копирования. • Обеспечивать ролевую модель доступа к административным функциям системы резервного копирования. Должна быть обеспечена возможность разграничения доступа для нескольких администраторов единой системы резервного копирования. • Обеспечивать возможность аутентификации пользователей с помощью Microsoft Active Directory. • Обеспечивать возможность аутентификации пользователей с помощью ALD Pro. • Обеспечивать приоритизацию заданий резервного копирования. • Обеспечивать возможность разрешения, запрета централизованного восстановления, а также возможность запрета восстановления, инициации резервного копирования со стороны клиента. • Обеспечивать возможность выполнения групповых операций для нескольких клиентов одновременно. • Предоставлять автономный режим работы клиента с возможностью резервирования данных на локальное устройство хранения. • Обеспечивать возможность установки минимального обязательного периода хранения любых резервных копий, без возможности их удаления из системы резервного копирования. - - Значение характеристики не может изменяться участником закупки

• Обеспечивать возможность архивации и архивного хранения файлов с возможностью использования того же клиентского ПО, что и для резервного копирования, и передача их на долговременное хранение. • Обеспечивать возможность временной приостановки и продолжения работы задач резервного копирования. • Предоставлять журнал аутентификации пользователей. • Предоставлять защиту от случайного удаления резервных копий из хранилища, в том числе суперпользователем (root) без предварительного изменения атрибутов копии суперпользователем. • Предоставлять защиту от случайного ручного и автоматического удаления последней резервной копии источника данных в средствах управления СРК. • Предоставлять возможность использования предварительно настроенного аварийного локального хранилища резервных копий в случае отсутствия места в основном хранилище. • Обеспечивать возможность экспорта и импорта резервных копий между независимыми инсталляциями СРК. • Обеспечивать возможность выполнения pre- и post- скриптов в процессе создания резервной копии и в процессе восстановления резервной копии. • Обеспечивать возможность создания плана регламентного обслуживания для клиентов и групп клиентов СРК, с выбором определённых источников данных. • Обеспечивать возможность частичного восстановления данных из резервных копий (отдельные файлы). СРК должно иметь клиент-серверную архитектуру, включающую следующие компоненты: • Основной сервер СРК, включающий СУБД для хранения метаданных резервных копий и конфигурационных параметров СРК; • Медиасервер (сервера на которых подключены устройства хранения резервных копий); • Агент СРК. СРК должна поддерживать одновременную установку всех компонентов на один физический или виртуальный сервер при выполнении консолидированных аппаратных требований, предъявляемых компонентами к серверу, на который производится установка.

Основной сервер СРК должен отвечать следующим требованиям: • Имеет возможность установки на следующие операционные системы (ОС) архитектуры x64: o ALT Linux версии 10; o Astra Linux версий 1.6, 1.7, 1.8; o RedOS версий 7.3, 8; o Rosa Cobalt версий 7.3, 7.9; o Rosa Chrome версии 12; o Debian версий 10, 12; o Ubuntu версий 18.04, 20.04, 22.04; o CentOS версий 7, 8; o RHEL версии 9. • Поддерживать PostgreSQL из репозиториев поддерживаемых ОС в качестве СУБД. • Иметь возможность подключения компонентов СРК к СУБД и администратора с использованием защищённого соединения SSL. • Поддерживать работу в режиме высокой доступности: o Поддерживать конфигурации СУБД с использованием решения Patroni, развернутом на отдельно стоящих серверах; o Основной сервер СРК должен иметь возможность использования дополнительного Резервного сервера. В таком режиме Резервный сервер, в случае отказа основного сервера, должен обеспечить функционал основного сервера СРК, а Агенты СРК должны переключиться на резервный сервер. После восстановления функционирования основного сервера, Агенты СРК должны подключаться к основному серверу. o Создание резервного сервера управления механизмов и переключения функционала должны обеспечиваться средствами СРК без использования стороннего ПО. Медиасервер СРК должен отвечать следующим требованиям: • Поддерживать хранение резервных копий в: o блочных устройствах; o файловых системах; o ленточных библиотеках, включая устройства VTL (виртуальные ленточные библиотеки); o устройствах TATLIN.BACKUP; o облаках и устройствах S3, включая MinIO, VK Сloud Storage, TATLIN.OBJECT. • Поддерживать резервное копирование на ленточные библиотеки с использованием LTFS. • Обеспечивать возможность добавления в серверную группировку СРК неограниченного количества дополнительных медиа-серверов для последующего масштабирования и возможности распределения потоков данных.

• Обеспечивать возможность автоматического удаления устаревших резервных копий, возможность автоматического перемещения резервных копий на другие устройства хранения в зависимости от срока хранения, возможность автоматической репликации резервных копий при их создании. • Обеспечивать возможность автоматической проверки резервных копий для контроля их целостности. • Дедупликация резервных копий должна осуществляться как на блочные устройства, так и на файловые системы. • Обеспечивать возможность непрерывной удаленной репликации для файловых систем и систем виртуализации ПК СВ «Брест». • Обеспечивать автоматическую балансировку задач резервного копирования между пулами и медиа-серверами резервного копирования по заданным параметрам. Агент СРК должен отвечать следующим требованиям: • Обеспечивать резервное копирование операционной системы Astra Linux Special Edition версий 1.6, 1.7, 1.7.5, 1.8, в том числе обеспечивать резервное копирование без нарушения мандатных атрибутов. • Обеспечивать возможность резервного копирования следующих ОС: o CentOS версий 7, 8 o AltLinux версии 10 o RedOS версии 7.3, o РОСА "Кобальт" версий 7.3, 7.9, o РОСА "Хром" версии 12; o Red Hat Enterprise Linux (RHEL) версий 7, 8, 9; o Ubuntu версий 22.04, 20.04; o Windows Server версий 2012-2022 файловой системы с поддержкой VSS. • Обеспечивать возможность электронной подписи создаваемой резервной копии для последующего подтверждения её подлинности. • Обеспечить возможность защитного преобразования резервных копий с использованием алгоритма ГОСТ Р 34.12-2015 «Кузнечик». • Обеспечивать резервное копирование СУБД PostgreSQL версий 11-17: o Поддержка непрерывного резервного копирования с периодическим резервным копированием архивных WAL файлов.

o Поддержка выполнения резервного копирования PostgreSQL в кластерной среде (Patroni), с возможностью создания резервной копии как с мастера, синхронной реплики, асинхронной реплики, а также иметь возможность автоопределения мастера и реплик кластера с автоматическим переключением между ними. o Поддержка выполнения потабличного резервного копирования и восстановления СУБД, как в обычном режиме, так и в кластерной конфигурации с использованием Patroni. o Поддержка режима PTRACK, PAGE и DELTA, а также интеграции с pg_probackup. o Поддержка создания резервных копий баз данных с применением механизма моментальных снимков LVM. o Поддержка создания резервных копий баз данных с применением механизма моментальных снимков dattobd (Datto Block Driver). o Поддержка создания резервных копий баз данных с применением механизма аппаратных моментальных снимков СХД TATLIN.UNIFIED. o Поддержка интеграции с утилитой pg_probackup для резервного копирования и восстановления баз данных в S3-хранилище без передачи данных через сервера СРК. o Поддержка резервного копирования баз данных с включенной логической репликацией, параметр wal_level = logical. • Обеспечивать резервное копирование СУБД Oracle версий 10g, 11g, 12c, 18c, 19c: o Поддержка полного и инкрементального резервного копирования. o Поддержка полного восстановления баз данных на момент выполнения резервного копирования. o Поддержка восстановления на заданный момент времени (point-in-time recovery). • Обеспечивать резервное копирование СУБД Yandex Database. • Обеспечивать резервное копирование СУБД Microsoft SQL Server версий 2014, 2016, 2017, 2019. 2022: o Поддержка резервного копирования в режиме Open Database Connectivity (ODBC) o Поддержка резервного копирования в режиме Volume Shadow Copy (VSS) o Поддержка полного, инкрементального и дифференциального резервного копирования в режиме ODBC

o Поддержка полного и дифференциального резервного копирования в режиме VSS. • Обеспечивать резервное копирование СУБД SAP HANA: o Поддержка полного, инкрементального и дифференциального резервного копирования. o Поддержка полного восстановления баз данных на момент выполнения резервного копирования. o Поддержка восстановление на заданный момент времени (point-in-time recovery). • Обеспечивать поддержку выполнения резервного копирования почтовых систем: o CommunigatePro 6.3 с возможностью гранулярного восстановления вплоть до письма. o VK WorkMail с возможностью гранулярного восстановления вплоть до письма. o RuPost с возможностью инкрементального резервного копирования. • Обеспечивать поддержку выполнения резервного копирования FreeIPA версий 4.7; 4.8, 4.9; • Полное, инкрементальное и дифференциальное резервное копирование файловых систем: o ext2, ext3, ext4; o Xfs; o lvm2; o NTFS; o ZFS; o Btrfs. • Обеспечивать резервное копирование томов LVM. • Иметь возможность создания консистентных резервных копий файловых систем с использованием моментальных снимков LVM и dattobd (Datto Block Driver). СРК должно поддерживать безагентное резервное копирование сред виртуализации: • Microsoft Hyper-V. • Proxmox VE. • RUSTACK, а также поддерживать типы хранилищ РУСТЭК: OCFS2, NFS, NetApp-ISCSI. • oVirt/zVirt/REDVirt. • ROSA Virtualization версий 2.1, 3.0. • VMmanager 6 c возможностью резервного копирования и восстановления виртуальных машин. Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. • OpenStack: Zed, Yoga, Xena, Antelope. Включая возможность выполнения пользовательских сценариев во время задачи резервного копирования модулем OpenStack через SSH (без использования QEMU-agent).

• ПК СВ «Брест» версий 3.3, 3.2, 3.1, 2.12. Должна быть реализована возможность выполнения полных, инкрементальных и дифференциальных резервных копий для виртуальных машин и возможность выполнения полных резервных копий для шаблонов виртуальных машин. При выполнении резервного копирования функционирующих виртуальных машин должна быть возможность исполнить в них скрипт перед созданием моментального снимка виртуальной машины и сразу после создания снимка виртуальной машины для того, чтобы можно было привести данные функционирующих в виртуальной машине приложений в консистентное состояние. Должны поддерживаться типы хранилищ ПК СВ «Брест» и методы передачи данных: Ceph (ceph), Filesystem (qcow2, shared), LVM (lvm_lvm), OCFS2. • VMware vSphere 6.7, 7, 8, обеспечить возможность резервного копирования виртуальных машин с использованием методов NBD/NBDSSL, HOTADD. • BASIS.Dynamix Enterprise версий 3.8.8, 4.0, 4.1, Tionix. • АЭРОДИСК VAIR версий 3.7, 3.8, 4.0. Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет. **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов.

- 58.29.50.000 - Лицензия клиентская на программное обеспечение RuPost Standard CAL на 1 пользователя 1.Технические требования 2.2.9. Продукт должен поддерживать разделение хранения почты на несколько хранилищ, связанных правилами репликации для создания как «горячих» копий (одной или нескольких) с возможностью переключения основного хранилища на горячую копию, так и «холодной» копии для работы с системами резервного копирования (СРК). 2.2.10. Продукт должен предоставлять возможность разделения почтовых ящиков на группы. Каждая группа или совокупность групп должны иметь возможность привязки к определенному набору хранилищ (основное хранилище, горячая и холодная реплика). 2.2.11. Продукт должен иметь возможность как ручного, так и автоматического перемещения почтового ящика со всем содержимым между группами. 2.2.12. Продукт должен иметь возможность перемещения группы почтовых ящиков между наборами хранилищ. 2.2.13. Продукт должен предоставлять возможность устанавливать для групп почтовых ящиков ограничения по: • максимальному размеру входящего письма; • максимальному размеру почтового ящика. 2.2.14. Продукт должен предоставлять возможность для групп почтовых ящиков устанавливать политики архивирования писем по заданному сроку. 2.2.15. Продукт должен обладать возможностью настройки резервного хранилища почтовых очередей с функциональностью автоматического переключения на него в случае сбоя или недоступности основного хранилища. 2.2.16. Продукт должен предоставлять возможность отправки писем с доверенных узлов без аутентификации. 2.3. Функции мониторинга и диагностики 2.3.1. Продукт должен вести журнал успешно применённых конфигураций, с возможностью просмотра информации по дате и времени применения, администратора, который осуществлял изменения и полную информацию о конфигурации. ... - Штука - 400,00 - 1 582,00 - 632 800,00

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ ЗДРАВООХРАНЕНИЯ "КУЗБАССКИЙ КЛИНИЧЕСКИЙ КАРДИОЛОГИЧЕСКИЙ ДИСПАНСЕР ИМЕНИ АКАДЕМИКА Л.С. БАРБАРАША" - 400 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке 1.Технические требования 2.2.9. Продукт должен поддерживать разделение хранения почты на несколько хранилищ, связанных правилами репликации для создания как «горячих» копий (одной или нескольких) с возможностью переключения основного хранилища на горячую копию, так и «холодной» копии для работы с системами резервного копирования (СРК). 2.2.10. Продукт должен предоставлять возможность разделения почтовых ящиков на группы. Каждая группа или совокупность групп должны иметь возможность привязки к определенному набору хранилищ (основное хранилище, горячая и холодная реплика). 2.2.11. Продукт должен иметь возможность как ручного, так и автоматического перемещения почтового ящика со всем содержимым между группами. 2.2.12. Продукт должен иметь возможность перемещения группы почтовых ящиков между наборами хранилищ. 2.2.13. Продукт должен предоставлять возможность устанавливать для групп почтовых ящиков ограничения по: • максимальному размеру входящего письма; • максимальному размеру почтового ящика. 2.2.14. Продукт должен предоставлять возможность для групп почтовых ящиков устанавливать политики архивирования писем по заданному сроку. 2.2.15. Продукт должен обладать возможностью настройки резервного хранилища почтовых очередей с функциональностью автоматического переключения на него в случае сбоя или недоступности основного хранилища. 2.2.16. Продукт должен предоставлять возможность отправки писем с доверенных узлов без аутентификации. 2.3. Функции мониторинга и диагностики 2.3.1. Продукт должен вести журнал успешно применённых конфигураций, с возможностью просмотра информации по дате и времени применения, администратора, который осуществлял изменения и полную информацию о конфигурации. Значение характеристики не может изменяться участником закупки 1.1. Продукт должен обеспечивать возможность работы без применения эмуляции ОС на следующих операционных системах: • ОС Astra Linux Special Edition версий 1.7.X (начиная с 1.7.4) и 1.8.X c соответствующими оперативными обновлениями. 1.2. Продукт должен иметь возможность работы с СУБД на базе PostgreSQL. Продукт должен поддерживать взаимодействие с кластером БД PostgreSQL, построенным на базе технологии Patroni. 1.3. Продукт должен обеспечивать возможность бесшовной интеграции (без применения промежуточных адаптеров), обмена данными и синхронизации с адресными книгами, организованными в LDAP - совместимых службах каталогов. 1.4. В связи с необходимостью обеспечения совместимости с программным обеспечением Заказчика продукты, имеющие иные технические требования или использующие другие программные компоненты, не применимы. 2. Функциональные требования 2.1. Пользовательские функции 2.1.1. Продукт должен предоставлять пользователям услуги приема, отправки, хранения и управления сообщениями электронной почты. 2.1.2. Продукт должен предоставлять пользователям услуги управления событиями календаря, а также приема, отправки и хранения событий. 2.1.3. Продукт должен обеспечивать возможность доступа к почтовому ящику посредством Web-интерфейса. 2.1.4. Продукт должен поддерживать функциональность делегирования прав доступа на почтовый ящик сотрудника. 2.1.5. Продукт должен поддерживать функциональность делегирования прав доступа на календарь сотрудника. 2.1.6. Продукт должен обеспечивать доступ и хранение общей адресной книги пользователей. 2.1.7. Продукт должен обеспечивать работу с ресурсами организации, таких как переговорные комнаты, предметы и рабочие группы, с возможностью автоматических ответов на приглашение и настройкой принципов бронирования таких ресурсов. 4.5. Продукт должен обеспечивать возможность изменения/дополнения функционала для каждого пользователя в пределах ограничений, наложенных приобретенными лицензиями на использование, без остановки сервиса эксплуатируемого продукта и без переустановки (деинсталляция/инсталляция) продукта. 2.1.8. Продукт должен иметь возможность оповещения пользователей о различных уровнях использовании квоты на место в почтовом ящике. 2.1.9. Продукт должен иметь возможность отзыва пользователем писем, отправленных по ошибке с возможностью удаления писем из ящиков получателей вне зависимости от статуса прочтения (прочитано / нет). 2.1.10. Продукт должен предоставлять функционал общих почтовых ящиков. Выдача прав на общие ящики пользователям, включая права от имени общего ящика, должна быть основана на принадлежности пользователя к определенной группе LDAP или иному признаку в совместимом LDAP каталоге пользователей. 2.2. Функции администрирования 2.2.1. Продукт должен обладать единым Web-интерфейсом Администратора для администрирования сервера, управления услугами и мониторинга. 2.2.2. Продукт должен иметь CLI/API интерфейс для автоматизации задач по администрированию, управлению услугами и мониторингу. CLI интерфейс должен обладать функциональностью автоматического дополнения вводимой команды с возможностью вывода всех возможных команд. 2.2.3. Продукт должен иметь возможность заведения администраторов системы из совместимых LDAP каталогов, с отключением локального администратора. 2.2.4. Продукт должен обеспечивать возможность разграничения разрешений администраторами с гибкой настройкой их полномочий. 2.2.5. Продукт должен обладать библиотекой шаблонов конфигурации с возможностью пополнения пользовательскими шаблонами, описанными на языке YAML. 2.2.6. Продукт должен поддерживать механизм применения шаблонов конфигураций для оперативной развертки или перенастройки системы. 2.2.7. Продукт должен обладать механизмом оперативной настройки и ввода в эксплуатацию сервера электронной почты с помощью графического интерфейса Администратора. 2.2.8. Продукт должен иметь возможность работы с наборами хранилищ почтовых ящиков, разделенных по логическому или территориальному признаку. • Финализация – выполнение полного цикла - миграция/домиграция с автоматическим переключением почтового ящика с Microsoft Exchange на целевой сервер. 2.9.4. Продукт должен иметь возможность сосуществования с Microsoft Exchange, а также обеспечивать возможность вывода Microsoft Exchange из промышленной эксплуатации. 3. Дополнительные требования 3.1. Продукт должен быть российского производства и иметь подтверждение копией выписки из Единого реестра российских программ для ЭВМ Минцифры России. 3.2. Все необходимые Руководства, техническая документация по продукту должны быть предоставлены производителем на русском языке. 3.3. Документация, поставляемая с ПО, должна детально описывать процесс установки, настройки и эксплуатации соответствующего ПО. 3.4. Техническая поддержка производителя должна осуществляться на русском языке и по двум каналам взаимодействия: телефон и/или портал и/или эл.почта. 3.5. Должна быть обеспечена корректная работа с ПО «ALD Pro» без дополнительных работ по адаптации и необходимости расширения схемы LDAP. При этом должна быть обеспечена возможность управления сервисными учётными записями Почтовой системы при помощи встроенных инструментов ПО «ALD Pro». 3.6. Должна быть обеспечена корректная работа с ПО «RuBackup» (или эквивалент). 4. Особенности лицензирования 4.1. Продукт должен передаваться в виде пакета клиентских лицензий, соответствующих количеству почтовых ящиков пользователей. 4.2. Работа служебных ящиков электронной почты (рассылки, ресурсы календаря) не должны требовать пользовательскую лицензию. 4.3. Работа в кластерной конфигурации не должна требовать отдельного лицензирования. 4.4. Продукт должен обеспечивать возможность расширения или ограничения до необходимого количества пользователей без остановки сервиса эксплуатируемого продукта и без переустановки (деинсталляция/инсталляция) продукта. 2.8.6. Почтовый клиент должен обеспечивать одновременную работу как с собственными почтовыми ящиками, так и ящиками на Microsoft Exchange без установки дополнительных компонент сторонней разработки. 2.8.7. Продукт должен поддерживать возможность отправки Push-уведомлений. 2.8.8. Продукт должен поддерживать для ПО Microsoft Outlook для ОС Windows (с версии как минимум 2013 и выше), автоматическую настройку подключения к календарям и адресным книгам с помощью специального плагина, без ввода учетных записей и настройки путей подключения, в том числе к календарям и адресным книгам, к которым предоставлен общий доступ другими пользователями. 2.8.9. Специальный плагин для настольных клиентов Microsoft Outlook должен иметь возможность установки через групповые политики. 2.8.10. Продукт должен обеспечивать возможность работы Microsoft Outlook с синхронизацией почты, календарей и контактов. 2.8.11. Продукт должен поддерживать автоконфигурирование почтовых клиентов. 2.9. Функции совместимости с почтовыми системами 2.9.1. Продукт должен обладать автоматизированным инструментом миграции с почтовых систем Microsoft Exchange 2010 SP3 и выше с возможностью мониторинга и управления процессом миграции через визуальную панель управления. 2.9.2. Инструмент миграции должен обеспечивать перенос следующих элементов: • структуры папок почтового ящика и прав доступа к почтовым папкам; • сообщений; • адресных книг и прав доступа к адресным книгам; • контактов; • календарей и прав доступа к календарям; • задач; • календарных событий; • подписок на общие календари и адресные книги; • псевдонимов; • серверных архивов Exchange; • обеспечивать гибкий выбор переносимых данных из списка переносимых элементов. 2.9.3. Инструмент миграции должен обеспечивать следующие режимы миграции: • Обычный – первичный перенос данных почтовых ящиков. • Дельта – возобновление миграции с шага, на котором она остановилась ранее. 2.6.11. Правила ограничения приема и отправки писем наружу, должны иметь возможность комбинирования. 2.7. Функции предотвращения потери информации 2.7.1. Продукт должен обеспечивать SSL/TLS - безопасный обмен данными для SMTP, IMAP, HTTP, LDAP и сессий Администрирования. 2.7.2. Продукт должен иметь возможность интеграции, с промышленными системами, входящими в Реестр отечественного ПО Минцифры, обеспечивающими высокопроизводительную фильтрацию электронной почты от вирусов, спама и других нежелательных сообщений. 2.7.3. Продукт должен поддерживать 2FA (двухфакторную аутентификацию) для доступа к почтовым ящикам через Web-интерфейс, через приложение-аутентификатор. 2.7.4. Продукт должен поддерживать Milter протокол для интеграции с решениями, обеспечивающими функциональность по защите ИБ. 2.7.5. Продукт не должен содержать в своем составе встроенных компонент по ИБ, построенных на основе открытого ПО. 2.7.6. Продукт должен предоставлять возможность работы с системами резервного копирования, при этом конечное восстановление объектов должно происходить с участием оператора/администратора почтовой системы. 2.8. Функции совместимости с почтовыми клиентами 2.8.1. Продукт должен обеспечивать поддержку протоколов для работы с почтой – IMAP, SMTP, POP3. 2.8.2. Продукт должен обеспечивать работу с календарями по протоколу CalDAV и обеспечивать работу с адресными книгами по протоколу CardDAV. 2.8.3. В состав продукта должен входить кросс-платформенный почтовый клиент (установочный пакет) для OC Astra Linux, ОС RedOS, OC AltLinux и ОС Windows. 2.8.4. Почтовый клиент в составе продукта должен поддерживать работу с протоколами IMAP, SMTP, POP3, CalDAV, CardDAV, Exchange ActiveSync (EAS). 2.8.5. Почтовый клиент должен обеспечивать прием, отправку почтовых сообщений, работу с папками, календарями и списком контактов и предусматривать возможность автоопределения настроек подключения. • письма с не установленным флагом IMAP "Flagged"; • письма, для которых не установлен флаг передаваемого ключевого слова IMAP; • письма с не установленным флагом IMAP "Seen". 2.6. Функции управления рассылками и обработки почты 2.6.1. Продукт должен иметь возможность организации статических списков рассылки с помощью перечней адресов получателей. В перечень адресов получателей должна предоставляться возможность добавления внешних относительно почтовой системы адресатов. 2.6.2. Продукт должен иметь возможность организовывать динамические списки рассылки почтовых сообщений на основании LDAP фильтров с использованием Web-интерфейса и интерфейса командой строки. 2.6.3. Настройки списков рассылок должны предоставлять возможность указания как отдельных адресатов на право отправки на группу рассылок, так и указания всех внутренних пользователей единой настройкой. 2.6.4. Продукт должен обеспечивать возможность отключаемой возможности получения входящей почты извне на списки рассылок. Возможность включения, отключения должна быть реализована для каждого отдельно взятого списка рассылки. 2.6.5. Продукт должен иметь возможность создания серверных правил обработки входящей корреспонденции, как общих для всей организации, так и индивидуальных. 2.6.6. Продукт должен иметь возможность осуществлять фильтрацию входящей почты на основании «черных» и «белых» адресов отправителя. 2.6.7. Продукт должен иметь возможность осуществлять фильтрацию исходящей почты на основании «черного» списка адресов получателя. 2.6.8. Продукт должен обеспечивать возможность ограничения ряду пользователей отправлять корреспонденцию за пределы организации. 2.6.9. Продукт должен обеспечивать возможность ограничения ряду пользователей получать корреспонденцию извне организации. 2.6.10. Продукт должен обеспечивать возможность ограничения ряду пользователей отправлять корреспонденцию за пределы почтовой организации. • все письма; • письма с установленным флагом IMAP "Answered"; • письма, которые содержат указанную строку в поле BCC структуры IMAP письма; • письма с внутренней датой до указанной даты; • письма, которые содержат указанную строку в теле письма; • письма, которые содержат указанную строку в поле CC структуры IMAP письма; • письма с установленным флагом IMAP "Deleted"; • письма с установленным флагом IMAP "Draft"; • письма с установленным флагом IMAP "Flagged"; • письма, которые содержат указанную строку в поле FROM структуры IMAP письма; • письма, которые имеют или содержат указанную строку в поле заголовка • письма с установленным флагом для переданного ключевого слова IMAP • письма, которые больше указанного размера; • письма в почтовом ящике с указанным именем; • письма, с установленным флагом IMAP "Recent", но с неустановленным флагом IMAP "Seen"; • письма, где поиск не соответствует указанному ключу поиска или его значению; • письма, у которых не установлен флаг IMAP "Recent"; • письма, внутренняя дата которых соответствует указанной дате; • письма с установленным флагом IMAP "Recent"; • письма, которые были сохранены до указанной даты; • письма, дата сохранения которых соответствует указанной дате; • письма, которые были сохранены после указанной даты; • письма с установленным флагом IMAP "Seen"; • письма с заголовком Date до указанной даты; • письма с заголовком Date соответствующим указанной дате; • письма с заголовком Date после указанной даты; • письма, внутренняя дата которых находится в пределах или после указанной даты; • письма, которые меньше указанного размера; • письма, которые содержат указанную строку в поле SUBJECT структуры IMAP письма; • письма, которые содержат указанную строку в заголовках или теле письма; • письма, которые содержат указанную строку в поле TO структуры IMAP письма; • письма с не установленным флагом IMAP "Answered"; • письма с не установленным флагом IMAP "Deleted"; • письма с не установленным флагом IMAP "Draft"; 2.4.3. Система журналирования должна предоставлять возможность вывода журналов по всем или отдельно взятым компонентам системы, с возможность указания даты или диапазона времени. 2.4.4. Продукт должен обеспечивать журналирование событий, связанных с администрированием системы, и предоставлять аудит действий различных администраторов системы. 2.4.5. Продукт должен обеспечивать просмотр журналов событий почтовых компонентов с помощью графического интерфейса Администратора с возможностью выбора узлов и компонентов системы и средством поиска информации в журналах. 2.4.6. Продукт должен предоставлять возможность трассировки писем. 2.5. Функции управления почтовыми ящиками 2.5.1. Продукт должен иметь возможность поддержки работы с разнородными службами каталогов. 2.5.2. Продукт должен иметь возможность работы с почтовыми доменами, не привязанными к службе каталогов. 2.5.3. Продукт должен иметь возможность множественного добавления почтовых ящиков на основании критериев поиска пользователей в домене LDAP. 2.5.4. Продукт должен поддерживать возможность заведения нескольких псевдонимов для почтового адреса пользователя в разных почтовых доменах. Псевдонимы должны обеспечивать как получение почты с их использованием, так и отправку. 2.5.5. Продукт должен поддерживать политики хранения и удаления почтовых ящиков. 2.5.6. Продукт должен поддерживать работу с архивными почтовыми папками, в том числе их автоподключение пользователям. 2.5.7. Продукт должен обеспечивать автоматический перенос в архив писем, с возможностью указания различных периодов архивации. 2.5.8. Продукт должен поддерживать функциональность папки удержания писем для хранения всех почтовых отправлений, удаленных из корзин пользователей. 2.5.9. Продукт должен обеспечивать возможность поиска писем при помощи графической панели Администратора в соответствии с заданными параметрами и последующего выбора и удаления писем в любых почтовых ящиках. Критерии поиска должны включать в себя: 2.3.2. Продукт должен поддерживать выбор развернутой конфигурации из истории с возможностью ее оперативного применения. 2.3.3. Продукт должен осуществлять контроль не регламентированного изменения конфигурационных файлов почтовых компонентов с возможностью уведомления администратора, журналированием событий и обладать возможностью автоматического восстановления конфигурации либо остановки узла, на котором обнаружены не регламентированные изменения конфигурации. 2.3.4. Продукт должен обладать системой мониторинга с возможностью отображения информации в графической панели управления, в том числе нагрузочных параметров на узле системы (CPU, RAM, дисковая подсистема), информации о почтовых очередях, параметров доступности инфраструктурных объектов, критичных для функционирования почтовой системы. 2.3.5. Продукт должен обладать системой мониторинга с возможностью отображения информации в графической панели управления, в том числе информации, связанной с пользовательскими данными – список самых больших ящиков пользователей системы, список пользователей, квота на ящик которых приближается к максимальным значениям, размер общих данных, занимаемых на системах хранения почтовых данных. 2.3.6. Продукт должен обеспечивать возможность отслеживания действий пользователя в своем почтовом ящике. 2.3.7. Продукт должен обеспечивать автоматический перезапуск экземпляра почтового сервера при обнаружении сбоя компонентов сервера. 2.4. Функции журналирования 2.4.1. Продукт должен обеспечивать журналирование событий системы, связанные с ее работоспособностью, функционированием компонент системы, а также действий по включению, выключению и действий по изменению параметров системы 2.4.2. Продукт должен обеспечивать журналирование событий почтового трафика и клиентский подключений, для отслеживания движения писем внутри системы. - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - 1.Технические требования - 2.2.9. Продукт должен поддерживать разделение хранения почты на несколько хранилищ, связанных правилами репликации для создания как «горячих» копий (одной или нескольких) с возможностью переключения основного хранилища на горячую копию, так и «холодной» копии для работы с системами резервного копирования (СРК). 2.2.10. Продукт должен предоставлять возможность разделения почтовых ящиков на группы. Каждая группа или совокупность групп должны иметь возможность привязки к определенному набору хранилищ (основное хранилище, горячая и холодная реплика). 2.2.11. Продукт должен иметь возможность как ручного, так и автоматического перемещения почтового ящика со всем содержимым между группами. 2.2.12. Продукт должен иметь возможность перемещения группы почтовых ящиков между наборами хранилищ. 2.2.13. Продукт должен предоставлять возможность устанавливать для групп почтовых ящиков ограничения по: • максимальному размеру входящего письма; • максимальному размеру почтового ящика. 2.2.14. Продукт должен предоставлять возможность для групп почтовых ящиков устанавливать политики архивирования писем по заданному сроку. 2.2.15. Продукт должен обладать возможностью настройки резервного хранилища почтовых очередей с функциональностью автоматического переключения на него в случае сбоя или недоступности основного хранилища. 2.2.16. Продукт должен предоставлять возможность отправки писем с доверенных узлов без аутентификации. 2.3. Функции мониторинга и диагностики 2.3.1. Продукт должен вести журнал успешно применённых конфигураций, с возможностью просмотра информации по дате и времени применения, администратора, который осуществлял изменения и полную информацию о конфигурации. - - Значение характеристики не может изменяться участником закупки - 1.1. Продукт должен обеспечивать возможность работы без применения эмуляции ОС на следующих операционных системах: • ОС Astra Linux Special Edition версий 1.7.X (начиная с 1.7.4) и 1.8.X c соответствующими оперативными обновлениями. 1.2. Продукт должен иметь возможность работы с СУБД на базе PostgreSQL. Продукт должен поддерживать взаимодействие с кластером БД PostgreSQL, построенным на базе технологии Patroni. 1.3. Продукт должен обеспечивать возможность бесшовной интеграции (без применения промежуточных адаптеров), обмена данными и синхронизации с адресными книгами, организованными в LDAP - совместимых службах каталогов. 1.4. В связи с необходимостью обеспечения совместимости с программным обеспечением Заказчика продукты, имеющие иные технические требования или использующие другие программные компоненты, не применимы. 2. Функциональные требования 2.1. Пользовательские функции 2.1.1. Продукт должен предоставлять пользователям услуги приема, отправки, хранения и управления сообщениями электронной почты. 2.1.2. Продукт должен предоставлять пользователям услуги управления событиями календаря, а также приема, отправки и хранения событий. 2.1.3. Продукт должен обеспечивать возможность доступа к почтовому ящику посредством Web-интерфейса. 2.1.4. Продукт должен поддерживать функциональность делегирования прав доступа на почтовый ящик сотрудника. 2.1.5. Продукт должен поддерживать функциональность делегирования прав доступа на календарь сотрудника. 2.1.6. Продукт должен обеспечивать доступ и хранение общей адресной книги пользователей. 2.1.7. Продукт должен обеспечивать работу с ресурсами организации, таких как переговорные комнаты, предметы и рабочие группы, с возможностью автоматических ответов на приглашение и настройкой принципов бронирования таких ресурсов. - 4.5. Продукт должен обеспечивать возможность изменения/дополнения функционала для каждого пользователя в пределах ограничений, наложенных приобретенными лицензиями на использование, без остановки сервиса эксплуатируемого продукта и без переустановки (деинсталляция/инсталляция) продукта. - 2.1.8. Продукт должен иметь возможность оповещения пользователей о различных уровнях использовании квоты на место в почтовом ящике. 2.1.9. Продукт должен иметь возможность отзыва пользователем писем, отправленных по ошибке с возможностью удаления писем из ящиков получателей вне зависимости от статуса прочтения (прочитано / нет). 2.1.10. Продукт должен предоставлять функционал общих почтовых ящиков. Выдача прав на общие ящики пользователям, включая права от имени общего ящика, должна быть основана на принадлежности пользователя к определенной группе LDAP или иному признаку в совместимом LDAP каталоге пользователей. 2.2. Функции администрирования 2.2.1. Продукт должен обладать единым Web-интерфейсом Администратора для администрирования сервера, управления услугами и мониторинга. 2.2.2. Продукт должен иметь CLI/API интерфейс для автоматизации задач по администрированию, управлению услугами и мониторингу. CLI интерфейс должен обладать функциональностью автоматического дополнения вводимой команды с возможностью вывода всех возможных команд. 2.2.3. Продукт должен иметь возможность заведения администраторов системы из совместимых LDAP каталогов, с отключением локального администратора. 2.2.4. Продукт должен обеспечивать возможность разграничения разрешений администраторами с гибкой настройкой их полномочий. 2.2.5. Продукт должен обладать библиотекой шаблонов конфигурации с возможностью пополнения пользовательскими шаблонами, описанными на языке YAML. 2.2.6. Продукт должен поддерживать механизм применения шаблонов конфигураций для оперативной развертки или перенастройки системы. 2.2.7. Продукт должен обладать механизмом оперативной настройки и ввода в эксплуатацию сервера электронной почты с помощью графического интерфейса Администратора. 2.2.8. Продукт должен иметь возможность работы с наборами хранилищ почтовых ящиков, разделенных по логическому или территориальному признаку. - • Финализация – выполнение полного цикла - миграция/домиграция с автоматическим переключением почтового ящика с Microsoft Exchange на целевой сервер. 2.9.4. Продукт должен иметь возможность сосуществования с Microsoft Exchange, а также обеспечивать возможность вывода Microsoft Exchange из промышленной эксплуатации. 3. Дополнительные требования 3.1. Продукт должен быть российского производства и иметь подтверждение копией выписки из Единого реестра российских программ для ЭВМ Минцифры России. 3.2. Все необходимые Руководства, техническая документация по продукту должны быть предоставлены производителем на русском языке. 3.3. Документация, поставляемая с ПО, должна детально описывать процесс установки, настройки и эксплуатации соответствующего ПО. 3.4. Техническая поддержка производителя должна осуществляться на русском языке и по двум каналам взаимодействия: телефон и/или портал и/или эл.почта. 3.5. Должна быть обеспечена корректная работа с ПО «ALD Pro» без дополнительных работ по адаптации и необходимости расширения схемы LDAP. При этом должна быть обеспечена возможность управления сервисными учётными записями Почтовой системы при помощи встроенных инструментов ПО «ALD Pro». 3.6. Должна быть обеспечена корректная работа с ПО «RuBackup» (или эквивалент). 4. Особенности лицензирования 4.1. Продукт должен передаваться в виде пакета клиентских лицензий, соответствующих количеству почтовых ящиков пользователей. 4.2. Работа служебных ящиков электронной почты (рассылки, ресурсы календаря) не должны требовать пользовательскую лицензию. 4.3. Работа в кластерной конфигурации не должна требовать отдельного лицензирования. 4.4. Продукт должен обеспечивать возможность расширения или ограничения до необходимого количества пользователей без остановки сервиса эксплуатируемого продукта и без переустановки (деинсталляция/инсталляция) продукта. - 2.8.6. Почтовый клиент должен обеспечивать одновременную работу как с собственными почтовыми ящиками, так и ящиками на Microsoft Exchange без установки дополнительных компонент сторонней разработки. 2.8.7. Продукт должен поддерживать возможность отправки Push-уведомлений. 2.8.8. Продукт должен поддерживать для ПО Microsoft Outlook для ОС Windows (с версии как минимум 2013 и выше), автоматическую настройку подключения к календарям и адресным книгам с помощью специального плагина, без ввода учетных записей и настройки путей подключения, в том числе к календарям и адресным книгам, к которым предоставлен общий доступ другими пользователями. 2.8.9. Специальный плагин для настольных клиентов Microsoft Outlook должен иметь возможность установки через групповые политики. 2.8.10. Продукт должен обеспечивать возможность работы Microsoft Outlook с синхронизацией почты, календарей и контактов. 2.8.11. Продукт должен поддерживать автоконфигурирование почтовых клиентов. 2.9. Функции совместимости с почтовыми системами 2.9.1. Продукт должен обладать автоматизированным инструментом миграции с почтовых систем Microsoft Exchange 2010 SP3 и выше с возможностью мониторинга и управления процессом миграции через визуальную панель управления. 2.9.2. Инструмент миграции должен обеспечивать перенос следующих элементов: • структуры папок почтового ящика и прав доступа к почтовым папкам; • сообщений; • адресных книг и прав доступа к адресным книгам; • контактов; • календарей и прав доступа к календарям; • задач; • календарных событий; • подписок на общие календари и адресные книги; • псевдонимов; • серверных архивов Exchange; • обеспечивать гибкий выбор переносимых данных из списка переносимых элементов. 2.9.3. Инструмент миграции должен обеспечивать следующие режимы миграции: • Обычный – первичный перенос данных почтовых ящиков. • Дельта – возобновление миграции с шага, на котором она остановилась ранее. - 2.6.11. Правила ограничения приема и отправки писем наружу, должны иметь возможность комбинирования. 2.7. Функции предотвращения потери информации 2.7.1. Продукт должен обеспечивать SSL/TLS - безопасный обмен данными для SMTP, IMAP, HTTP, LDAP и сессий Администрирования. 2.7.2. Продукт должен иметь возможность интеграции, с промышленными системами, входящими в Реестр отечественного ПО Минцифры, обеспечивающими высокопроизводительную фильтрацию электронной почты от вирусов, спама и других нежелательных сообщений. 2.7.3. Продукт должен поддерживать 2FA (двухфакторную аутентификацию) для доступа к почтовым ящикам через Web-интерфейс, через приложение-аутентификатор. 2.7.4. Продукт должен поддерживать Milter протокол для интеграции с решениями, обеспечивающими функциональность по защите ИБ. 2.7.5. Продукт не должен содержать в своем составе встроенных компонент по ИБ, построенных на основе открытого ПО. 2.7.6. Продукт должен предоставлять возможность работы с системами резервного копирования, при этом конечное восстановление объектов должно происходить с участием оператора/администратора почтовой системы. 2.8. Функции совместимости с почтовыми клиентами 2.8.1. Продукт должен обеспечивать поддержку протоколов для работы с почтой – IMAP, SMTP, POP3. 2.8.2. Продукт должен обеспечивать работу с календарями по протоколу CalDAV и обеспечивать работу с адресными книгами по протоколу CardDAV. 2.8.3. В состав продукта должен входить кросс-платформенный почтовый клиент (установочный пакет) для OC Astra Linux, ОС RedOS, OC AltLinux и ОС Windows. 2.8.4. Почтовый клиент в составе продукта должен поддерживать работу с протоколами IMAP, SMTP, POP3, CalDAV, CardDAV, Exchange ActiveSync (EAS). 2.8.5. Почтовый клиент должен обеспечивать прием, отправку почтовых сообщений, работу с папками, календарями и списком контактов и предусматривать возможность автоопределения настроек подключения. - • письма с не установленным флагом IMAP "Flagged"; • письма, для которых не установлен флаг передаваемого ключевого слова IMAP; • письма с не установленным флагом IMAP "Seen". 2.6. Функции управления рассылками и обработки почты 2.6.1. Продукт должен иметь возможность организации статических списков рассылки с помощью перечней адресов получателей. В перечень адресов получателей должна предоставляться возможность добавления внешних относительно почтовой системы адресатов. 2.6.2. Продукт должен иметь возможность организовывать динамические списки рассылки почтовых сообщений на основании LDAP фильтров с использованием Web-интерфейса и интерфейса командой строки. 2.6.3. Настройки списков рассылок должны предоставлять возможность указания как отдельных адресатов на право отправки на группу рассылок, так и указания всех внутренних пользователей единой настройкой. 2.6.4. Продукт должен обеспечивать возможность отключаемой возможности получения входящей почты извне на списки рассылок. Возможность включения, отключения должна быть реализована для каждого отдельно взятого списка рассылки. 2.6.5. Продукт должен иметь возможность создания серверных правил обработки входящей корреспонденции, как общих для всей организации, так и индивидуальных. 2.6.6. Продукт должен иметь возможность осуществлять фильтрацию входящей почты на основании «черных» и «белых» адресов отправителя. 2.6.7. Продукт должен иметь возможность осуществлять фильтрацию исходящей почты на основании «черного» списка адресов получателя. 2.6.8. Продукт должен обеспечивать возможность ограничения ряду пользователей отправлять корреспонденцию за пределы организации. 2.6.9. Продукт должен обеспечивать возможность ограничения ряду пользователей получать корреспонденцию извне организации. 2.6.10. Продукт должен обеспечивать возможность ограничения ряду пользователей отправлять корреспонденцию за пределы почтовой организации. - • все письма; • письма с установленным флагом IMAP "Answered"; • письма, которые содержат указанную строку в поле BCC структуры IMAP письма; • письма с внутренней датой до указанной даты; • письма, которые содержат указанную строку в теле письма; • письма, которые содержат указанную строку в поле CC структуры IMAP письма; • письма с установленным флагом IMAP "Deleted"; • письма с установленным флагом IMAP "Draft"; • письма с установленным флагом IMAP "Flagged"; • письма, которые содержат указанную строку в поле FROM структуры IMAP письма; • письма, которые имеют или содержат указанную строку в поле заголовка • письма с установленным флагом для переданного ключевого слова IMAP • письма, которые больше указанного размера; • письма в почтовом ящике с указанным именем; • письма, с установленным флагом IMAP "Recent", но с неустановленным флагом IMAP "Seen"; • письма, где поиск не соответствует указанному ключу поиска или его значению; • письма, у которых не установлен флаг IMAP "Recent"; • письма, внутренняя дата которых соответствует указанной дате; • письма с установленным флагом IMAP "Recent"; • письма, которые были сохранены до указанной даты; • письма, дата сохранения которых соответствует указанной дате; • письма, которые были сохранены после указанной даты; • письма с установленным флагом IMAP "Seen"; • письма с заголовком Date до указанной даты; • письма с заголовком Date соответствующим указанной дате; • письма с заголовком Date после указанной даты; • письма, внутренняя дата которых находится в пределах или после указанной даты; • письма, которые меньше указанного размера; • письма, которые содержат указанную строку в поле SUBJECT структуры IMAP письма; • письма, которые содержат указанную строку в заголовках или теле письма; • письма, которые содержат указанную строку в поле TO структуры IMAP письма; • письма с не установленным флагом IMAP "Answered"; • письма с не установленным флагом IMAP "Deleted"; • письма с не установленным флагом IMAP "Draft"; - 2.4.3. Система журналирования должна предоставлять возможность вывода журналов по всем или отдельно взятым компонентам системы, с возможность указания даты или диапазона времени. 2.4.4. Продукт должен обеспечивать журналирование событий, связанных с администрированием системы, и предоставлять аудит действий различных администраторов системы. 2.4.5. Продукт должен обеспечивать просмотр журналов событий почтовых компонентов с помощью графического интерфейса Администратора с возможностью выбора узлов и компонентов системы и средством поиска информации в журналах. 2.4.6. Продукт должен предоставлять возможность трассировки писем. 2.5. Функции управления почтовыми ящиками 2.5.1. Продукт должен иметь возможность поддержки работы с разнородными службами каталогов. 2.5.2. Продукт должен иметь возможность работы с почтовыми доменами, не привязанными к службе каталогов. 2.5.3. Продукт должен иметь возможность множественного добавления почтовых ящиков на основании критериев поиска пользователей в домене LDAP. 2.5.4. Продукт должен поддерживать возможность заведения нескольких псевдонимов для почтового адреса пользователя в разных почтовых доменах. Псевдонимы должны обеспечивать как получение почты с их использованием, так и отправку. 2.5.5. Продукт должен поддерживать политики хранения и удаления почтовых ящиков. 2.5.6. Продукт должен поддерживать работу с архивными почтовыми папками, в том числе их автоподключение пользователям. 2.5.7. Продукт должен обеспечивать автоматический перенос в архив писем, с возможностью указания различных периодов архивации. 2.5.8. Продукт должен поддерживать функциональность папки удержания писем для хранения всех почтовых отправлений, удаленных из корзин пользователей. 2.5.9. Продукт должен обеспечивать возможность поиска писем при помощи графической панели Администратора в соответствии с заданными параметрами и последующего выбора и удаления писем в любых почтовых ящиках. Критерии поиска должны включать в себя: - 2.3.2. Продукт должен поддерживать выбор развернутой конфигурации из истории с возможностью ее оперативного применения. 2.3.3. Продукт должен осуществлять контроль не регламентированного изменения конфигурационных файлов почтовых компонентов с возможностью уведомления администратора, журналированием событий и обладать возможностью автоматического восстановления конфигурации либо остановки узла, на котором обнаружены не регламентированные изменения конфигурации. 2.3.4. Продукт должен обладать системой мониторинга с возможностью отображения информации в графической панели управления, в том числе нагрузочных параметров на узле системы (CPU, RAM, дисковая подсистема), информации о почтовых очередях, параметров доступности инфраструктурных объектов, критичных для функционирования почтовой системы. 2.3.5. Продукт должен обладать системой мониторинга с возможностью отображения информации в графической панели управления, в том числе информации, связанной с пользовательскими данными – список самых больших ящиков пользователей системы, список пользователей, квота на ящик которых приближается к максимальным значениям, размер общих данных, занимаемых на системах хранения почтовых данных. 2.3.6. Продукт должен обеспечивать возможность отслеживания действий пользователя в своем почтовом ящике. 2.3.7. Продукт должен обеспечивать автоматический перезапуск экземпляра почтового сервера при обнаружении сбоя компонентов сервера. 2.4. Функции журналирования 2.4.1. Продукт должен обеспечивать журналирование событий системы, связанные с ее работоспособностью, функционированием компонент системы, а также действий по включению, выключению и действий по изменению параметров системы 2.4.2. Продукт должен обеспечивать журналирование событий почтового трафика и клиентский подключений, для отслеживания движения писем внутри системы.

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

1.Технические требования - 2.2.9. Продукт должен поддерживать разделение хранения почты на несколько хранилищ, связанных правилами репликации для создания как «горячих» копий (одной или нескольких) с возможностью переключения основного хранилища на горячую копию, так и «холодной» копии для работы с системами резервного копирования (СРК). 2.2.10. Продукт должен предоставлять возможность разделения почтовых ящиков на группы. Каждая группа или совокупность групп должны иметь возможность привязки к определенному набору хранилищ (основное хранилище, горячая и холодная реплика). 2.2.11. Продукт должен иметь возможность как ручного, так и автоматического перемещения почтового ящика со всем содержимым между группами. 2.2.12. Продукт должен иметь возможность перемещения группы почтовых ящиков между наборами хранилищ. 2.2.13. Продукт должен предоставлять возможность устанавливать для групп почтовых ящиков ограничения по: • максимальному размеру входящего письма; • максимальному размеру почтового ящика. 2.2.14. Продукт должен предоставлять возможность для групп почтовых ящиков устанавливать политики архивирования писем по заданному сроку. 2.2.15. Продукт должен обладать возможностью настройки резервного хранилища почтовых очередей с функциональностью автоматического переключения на него в случае сбоя или недоступности основного хранилища. 2.2.16. Продукт должен предоставлять возможность отправки писем с доверенных узлов без аутентификации. 2.3. Функции мониторинга и диагностики 2.3.1. Продукт должен вести журнал успешно применённых конфигураций, с возможностью просмотра информации по дате и времени применения, администратора, который осуществлял изменения и полную информацию о конфигурации. - - Значение характеристики не может изменяться участником закупки

1.1. Продукт должен обеспечивать возможность работы без применения эмуляции ОС на следующих операционных системах: • ОС Astra Linux Special Edition версий 1.7.X (начиная с 1.7.4) и 1.8.X c соответствующими оперативными обновлениями. 1.2. Продукт должен иметь возможность работы с СУБД на базе PostgreSQL. Продукт должен поддерживать взаимодействие с кластером БД PostgreSQL, построенным на базе технологии Patroni. 1.3. Продукт должен обеспечивать возможность бесшовной интеграции (без применения промежуточных адаптеров), обмена данными и синхронизации с адресными книгами, организованными в LDAP - совместимых службах каталогов. 1.4. В связи с необходимостью обеспечения совместимости с программным обеспечением Заказчика продукты, имеющие иные технические требования или использующие другие программные компоненты, не применимы. 2. Функциональные требования 2.1. Пользовательские функции 2.1.1. Продукт должен предоставлять пользователям услуги приема, отправки, хранения и управления сообщениями электронной почты. 2.1.2. Продукт должен предоставлять пользователям услуги управления событиями календаря, а также приема, отправки и хранения событий. 2.1.3. Продукт должен обеспечивать возможность доступа к почтовому ящику посредством Web-интерфейса. 2.1.4. Продукт должен поддерживать функциональность делегирования прав доступа на почтовый ящик сотрудника. 2.1.5. Продукт должен поддерживать функциональность делегирования прав доступа на календарь сотрудника. 2.1.6. Продукт должен обеспечивать доступ и хранение общей адресной книги пользователей. 2.1.7. Продукт должен обеспечивать работу с ресурсами организации, таких как переговорные комнаты, предметы и рабочие группы, с возможностью автоматических ответов на приглашение и настройкой принципов бронирования таких ресурсов.

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

2.1.8. Продукт должен иметь возможность оповещения пользователей о различных уровнях использовании квоты на место в почтовом ящике. 2.1.9. Продукт должен иметь возможность отзыва пользователем писем, отправленных по ошибке с возможностью удаления писем из ящиков получателей вне зависимости от статуса прочтения (прочитано / нет). 2.1.10. Продукт должен предоставлять функционал общих почтовых ящиков. Выдача прав на общие ящики пользователям, включая права от имени общего ящика, должна быть основана на принадлежности пользователя к определенной группе LDAP или иному признаку в совместимом LDAP каталоге пользователей. 2.2. Функции администрирования 2.2.1. Продукт должен обладать единым Web-интерфейсом Администратора для администрирования сервера, управления услугами и мониторинга. 2.2.2. Продукт должен иметь CLI/API интерфейс для автоматизации задач по администрированию, управлению услугами и мониторингу. CLI интерфейс должен обладать функциональностью автоматического дополнения вводимой команды с возможностью вывода всех возможных команд. 2.2.3. Продукт должен иметь возможность заведения администраторов системы из совместимых LDAP каталогов, с отключением локального администратора. 2.2.4. Продукт должен обеспечивать возможность разграничения разрешений администраторами с гибкой настройкой их полномочий. 2.2.5. Продукт должен обладать библиотекой шаблонов конфигурации с возможностью пополнения пользовательскими шаблонами, описанными на языке YAML. 2.2.6. Продукт должен поддерживать механизм применения шаблонов конфигураций для оперативной развертки или перенастройки системы. 2.2.7. Продукт должен обладать механизмом оперативной настройки и ввода в эксплуатацию сервера электронной почты с помощью графического интерфейса Администратора. 2.2.8. Продукт должен иметь возможность работы с наборами хранилищ почтовых ящиков, разделенных по логическому или территориальному признаку.

• Финализация – выполнение полного цикла - миграция/домиграция с автоматическим переключением почтового ящика с Microsoft Exchange на целевой сервер. 2.9.4. Продукт должен иметь возможность сосуществования с Microsoft Exchange, а также обеспечивать возможность вывода Microsoft Exchange из промышленной эксплуатации. 3. Дополнительные требования 3.1. Продукт должен быть российского производства и иметь подтверждение копией выписки из Единого реестра российских программ для ЭВМ Минцифры России. 3.2. Все необходимые Руководства, техническая документация по продукту должны быть предоставлены производителем на русском языке. 3.3. Документация, поставляемая с ПО, должна детально описывать процесс установки, настройки и эксплуатации соответствующего ПО. 3.4. Техническая поддержка производителя должна осуществляться на русском языке и по двум каналам взаимодействия: телефон и/или портал и/или эл.почта. 3.5. Должна быть обеспечена корректная работа с ПО «ALD Pro» без дополнительных работ по адаптации и необходимости расширения схемы LDAP. При этом должна быть обеспечена возможность управления сервисными учётными записями Почтовой системы при помощи встроенных инструментов ПО «ALD Pro». 3.6. Должна быть обеспечена корректная работа с ПО «RuBackup» (или эквивалент). 4. Особенности лицензирования 4.1. Продукт должен передаваться в виде пакета клиентских лицензий, соответствующих количеству почтовых ящиков пользователей. 4.2. Работа служебных ящиков электронной почты (рассылки, ресурсы календаря) не должны требовать пользовательскую лицензию. 4.3. Работа в кластерной конфигурации не должна требовать отдельного лицензирования. 4.4. Продукт должен обеспечивать возможность расширения или ограничения до необходимого количества пользователей без остановки сервиса эксплуатируемого продукта и без переустановки (деинсталляция/инсталляция) продукта.

2.8.6. Почтовый клиент должен обеспечивать одновременную работу как с собственными почтовыми ящиками, так и ящиками на Microsoft Exchange без установки дополнительных компонент сторонней разработки. 2.8.7. Продукт должен поддерживать возможность отправки Push-уведомлений. 2.8.8. Продукт должен поддерживать для ПО Microsoft Outlook для ОС Windows (с версии как минимум 2013 и выше), автоматическую настройку подключения к календарям и адресным книгам с помощью специального плагина, без ввода учетных записей и настройки путей подключения, в том числе к календарям и адресным книгам, к которым предоставлен общий доступ другими пользователями. 2.8.9. Специальный плагин для настольных клиентов Microsoft Outlook должен иметь возможность установки через групповые политики. 2.8.10. Продукт должен обеспечивать возможность работы Microsoft Outlook с синхронизацией почты, календарей и контактов. 2.8.11. Продукт должен поддерживать автоконфигурирование почтовых клиентов. 2.9. Функции совместимости с почтовыми системами 2.9.1. Продукт должен обладать автоматизированным инструментом миграции с почтовых систем Microsoft Exchange 2010 SP3 и выше с возможностью мониторинга и управления процессом миграции через визуальную панель управления. 2.9.2. Инструмент миграции должен обеспечивать перенос следующих элементов: • структуры папок почтового ящика и прав доступа к почтовым папкам; • сообщений; • адресных книг и прав доступа к адресным книгам; • контактов; • календарей и прав доступа к календарям; • задач; • календарных событий; • подписок на общие календари и адресные книги; • псевдонимов; • серверных архивов Exchange; • обеспечивать гибкий выбор переносимых данных из списка переносимых элементов. 2.9.3. Инструмент миграции должен обеспечивать следующие режимы миграции: • Обычный – первичный перенос данных почтовых ящиков. • Дельта – возобновление миграции с шага, на котором она остановилась ранее.

2.6.11. Правила ограничения приема и отправки писем наружу, должны иметь возможность комбинирования. 2.7. Функции предотвращения потери информации 2.7.1. Продукт должен обеспечивать SSL/TLS - безопасный обмен данными для SMTP, IMAP, HTTP, LDAP и сессий Администрирования. 2.7.2. Продукт должен иметь возможность интеграции, с промышленными системами, входящими в Реестр отечественного ПО Минцифры, обеспечивающими высокопроизводительную фильтрацию электронной почты от вирусов, спама и других нежелательных сообщений. 2.7.3. Продукт должен поддерживать 2FA (двухфакторную аутентификацию) для доступа к почтовым ящикам через Web-интерфейс, через приложение-аутентификатор. 2.7.4. Продукт должен поддерживать Milter протокол для интеграции с решениями, обеспечивающими функциональность по защите ИБ. 2.7.5. Продукт не должен содержать в своем составе встроенных компонент по ИБ, построенных на основе открытого ПО. 2.7.6. Продукт должен предоставлять возможность работы с системами резервного копирования, при этом конечное восстановление объектов должно происходить с участием оператора/администратора почтовой системы. 2.8. Функции совместимости с почтовыми клиентами 2.8.1. Продукт должен обеспечивать поддержку протоколов для работы с почтой – IMAP, SMTP, POP3. 2.8.2. Продукт должен обеспечивать работу с календарями по протоколу CalDAV и обеспечивать работу с адресными книгами по протоколу CardDAV. 2.8.3. В состав продукта должен входить кросс-платформенный почтовый клиент (установочный пакет) для OC Astra Linux, ОС RedOS, OC AltLinux и ОС Windows. 2.8.4. Почтовый клиент в составе продукта должен поддерживать работу с протоколами IMAP, SMTP, POP3, CalDAV, CardDAV, Exchange ActiveSync (EAS). 2.8.5. Почтовый клиент должен обеспечивать прием, отправку почтовых сообщений, работу с папками, календарями и списком контактов и предусматривать возможность автоопределения настроек подключения.

• письма с не установленным флагом IMAP "Flagged"; • письма, для которых не установлен флаг передаваемого ключевого слова IMAP; • письма с не установленным флагом IMAP "Seen". 2.6. Функции управления рассылками и обработки почты 2.6.1. Продукт должен иметь возможность организации статических списков рассылки с помощью перечней адресов получателей. В перечень адресов получателей должна предоставляться возможность добавления внешних относительно почтовой системы адресатов. 2.6.2. Продукт должен иметь возможность организовывать динамические списки рассылки почтовых сообщений на основании LDAP фильтров с использованием Web-интерфейса и интерфейса командой строки. 2.6.3. Настройки списков рассылок должны предоставлять возможность указания как отдельных адресатов на право отправки на группу рассылок, так и указания всех внутренних пользователей единой настройкой. 2.6.4. Продукт должен обеспечивать возможность отключаемой возможности получения входящей почты извне на списки рассылок. Возможность включения, отключения должна быть реализована для каждого отдельно взятого списка рассылки. 2.6.5. Продукт должен иметь возможность создания серверных правил обработки входящей корреспонденции, как общих для всей организации, так и индивидуальных. 2.6.6. Продукт должен иметь возможность осуществлять фильтрацию входящей почты на основании «черных» и «белых» адресов отправителя. 2.6.7. Продукт должен иметь возможность осуществлять фильтрацию исходящей почты на основании «черного» списка адресов получателя. 2.6.8. Продукт должен обеспечивать возможность ограничения ряду пользователей отправлять корреспонденцию за пределы организации. 2.6.9. Продукт должен обеспечивать возможность ограничения ряду пользователей получать корреспонденцию извне организации. 2.6.10. Продукт должен обеспечивать возможность ограничения ряду пользователей отправлять корреспонденцию за пределы почтовой организации.

• все письма; • письма с установленным флагом IMAP "Answered"; • письма, которые содержат указанную строку в поле BCC структуры IMAP письма; • письма с внутренней датой до указанной даты; • письма, которые содержат указанную строку в теле письма; • письма, которые содержат указанную строку в поле CC структуры IMAP письма; • письма с установленным флагом IMAP "Deleted"; • письма с установленным флагом IMAP "Draft"; • письма с установленным флагом IMAP "Flagged"; • письма, которые содержат указанную строку в поле FROM структуры IMAP письма; • письма, которые имеют или содержат указанную строку в поле заголовка • письма с установленным флагом для переданного ключевого слова IMAP • письма, которые больше указанного размера; • письма в почтовом ящике с указанным именем; • письма, с установленным флагом IMAP "Recent", но с неустановленным флагом IMAP "Seen"; • письма, где поиск не соответствует указанному ключу поиска или его значению; • письма, у которых не установлен флаг IMAP "Recent"; • письма, внутренняя дата которых соответствует указанной дате; • письма с установленным флагом IMAP "Recent"; • письма, которые были сохранены до указанной даты; • письма, дата сохранения которых соответствует указанной дате; • письма, которые были сохранены после указанной даты; • письма с установленным флагом IMAP "Seen"; • письма с заголовком Date до указанной даты; • письма с заголовком Date соответствующим указанной дате; • письма с заголовком Date после указанной даты; • письма, внутренняя дата которых находится в пределах или после указанной даты; • письма, которые меньше указанного размера; • письма, которые содержат указанную строку в поле SUBJECT структуры IMAP письма; • письма, которые содержат указанную строку в заголовках или теле письма; • письма, которые содержат указанную строку в поле TO структуры IMAP письма; • письма с не установленным флагом IMAP "Answered"; • письма с не установленным флагом IMAP "Deleted"; • письма с не установленным флагом IMAP "Draft";

2.4.3. Система журналирования должна предоставлять возможность вывода журналов по всем или отдельно взятым компонентам системы, с возможность указания даты или диапазона времени. 2.4.4. Продукт должен обеспечивать журналирование событий, связанных с администрированием системы, и предоставлять аудит действий различных администраторов системы. 2.4.5. Продукт должен обеспечивать просмотр журналов событий почтовых компонентов с помощью графического интерфейса Администратора с возможностью выбора узлов и компонентов системы и средством поиска информации в журналах. 2.4.6. Продукт должен предоставлять возможность трассировки писем. 2.5. Функции управления почтовыми ящиками 2.5.1. Продукт должен иметь возможность поддержки работы с разнородными службами каталогов. 2.5.2. Продукт должен иметь возможность работы с почтовыми доменами, не привязанными к службе каталогов. 2.5.3. Продукт должен иметь возможность множественного добавления почтовых ящиков на основании критериев поиска пользователей в домене LDAP. 2.5.4. Продукт должен поддерживать возможность заведения нескольких псевдонимов для почтового адреса пользователя в разных почтовых доменах. Псевдонимы должны обеспечивать как получение почты с их использованием, так и отправку. 2.5.5. Продукт должен поддерживать политики хранения и удаления почтовых ящиков. 2.5.6. Продукт должен поддерживать работу с архивными почтовыми папками, в том числе их автоподключение пользователям. 2.5.7. Продукт должен обеспечивать автоматический перенос в архив писем, с возможностью указания различных периодов архивации. 2.5.8. Продукт должен поддерживать функциональность папки удержания писем для хранения всех почтовых отправлений, удаленных из корзин пользователей. 2.5.9. Продукт должен обеспечивать возможность поиска писем при помощи графической панели Администратора в соответствии с заданными параметрами и последующего выбора и удаления писем в любых почтовых ящиках. Критерии поиска должны включать в себя:

2.3.2. Продукт должен поддерживать выбор развернутой конфигурации из истории с возможностью ее оперативного применения. 2.3.3. Продукт должен осуществлять контроль не регламентированного изменения конфигурационных файлов почтовых компонентов с возможностью уведомления администратора, журналированием событий и обладать возможностью автоматического восстановления конфигурации либо остановки узла, на котором обнаружены не регламентированные изменения конфигурации. 2.3.4. Продукт должен обладать системой мониторинга с возможностью отображения информации в графической панели управления, в том числе нагрузочных параметров на узле системы (CPU, RAM, дисковая подсистема), информации о почтовых очередях, параметров доступности инфраструктурных объектов, критичных для функционирования почтовой системы. 2.3.5. Продукт должен обладать системой мониторинга с возможностью отображения информации в графической панели управления, в том числе информации, связанной с пользовательскими данными – список самых больших ящиков пользователей системы, список пользователей, квота на ящик которых приближается к максимальным значениям, размер общих данных, занимаемых на системах хранения почтовых данных. 2.3.6. Продукт должен обеспечивать возможность отслеживания действий пользователя в своем почтовом ящике. 2.3.7. Продукт должен обеспечивать автоматический перезапуск экземпляра почтового сервера при обнаружении сбоя компонентов сервера. 2.4. Функции журналирования 2.4.1. Продукт должен обеспечивать журналирование событий системы, связанные с ее работоспособностью, функционированием компонент системы, а также действий по включению, выключению и действий по изменению параметров системы 2.4.2. Продукт должен обеспечивать журналирование событий почтового трафика и клиентский подключений, для отслеживания движения писем внутри системы.

- 58.29.50.000 - Лицензия на программное обеспечение VMmanager 6 редакции Infrastructure на 1 физический сервер не более 2 CPU описание 1. Программное обеспечение (ПО), должно выполнять следующие функции управления серверной виртуализации: управление серверами и кластерами виртуализации; управление виртуальными машинами; управление контейнерами; управление виртуальными дисками; управление виртуальными коммутаторами; управление сетями и пулами; управление доступом пользователей и групп к объектам инфраструктуры. 2. ПО должно поддерживать установку хостов виртуализации на ОС, соответствующую программному классу «Операционные системы общего назначения» из Единого реестра российских программ для электронных вычислительных машин и баз данных. 3. ПО должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных. 4. Документация предоставляемая на ПО должна быть доступна на русском и английском языках. 5. ПО должно обеспечивать виртуализацию аппаратных ресурсов в виде обособленных виртуальных машин, работающих на физическом сервере х86 архитектуры. 6. ПО должно поддерживать возможность работы собственной системы управления в следующих конфигурациях: • на выделенном физическом сервере; • на виртуальной машине размещенной на на отдельно стоящем сервере; • на виртуальной машине размещенной непосредственно на узле управляемого кластера (без необходимости дополнительного сервера). 7. ПО должно поддерживать работу в закрытом сетевом контуре без доступа в сеть Интернет. 8. ПО должно иметь поддержку отображения графического интерфейса администратора на русском языке. 9. ПО должно обеспечивать единый веб-интерфейс и интерфейс командной строки администратора службы. 10. ПО должно обеспечивать вызов основных функций через API, в частности, обладать встроенным в ПО компонентом отладки API запросов Swagger. ... - Штука - 1,00 - 227 395,00 - 227 395,00

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ ЗДРАВООХРАНЕНИЯ "КУЗБАССКИЙ КЛИНИЧЕСКИЙ КАРДИОЛОГИЧЕСКИЙ ДИСПАНСЕР ИМЕНИ АКАДЕМИКА Л.С. БАРБАРАША" - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке описание 1. Программное обеспечение (ПО), должно выполнять следующие функции управления серверной виртуализации: управление серверами и кластерами виртуализации; управление виртуальными машинами; управление контейнерами; управление виртуальными дисками; управление виртуальными коммутаторами; управление сетями и пулами; управление доступом пользователей и групп к объектам инфраструктуры. 2. ПО должно поддерживать установку хостов виртуализации на ОС, соответствующую программному классу «Операционные системы общего назначения» из Единого реестра российских программ для электронных вычислительных машин и баз данных. 3. ПО должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных. 4. Документация предоставляемая на ПО должна быть доступна на русском и английском языках. 5. ПО должно обеспечивать виртуализацию аппаратных ресурсов в виде обособленных виртуальных машин, работающих на физическом сервере х86 архитектуры. 6. ПО должно поддерживать возможность работы собственной системы управления в следующих конфигурациях: • на выделенном физическом сервере; • на виртуальной машине размещенной на на отдельно стоящем сервере; • на виртуальной машине размещенной непосредственно на узле управляемого кластера (без необходимости дополнительного сервера). 7. ПО должно поддерживать работу в закрытом сетевом контуре без доступа в сеть Интернет. 8. ПО должно иметь поддержку отображения графического интерфейса администратора на русском языке. 9. ПО должно обеспечивать единый веб-интерфейс и интерфейс командной строки администратора службы. 10. ПО должно обеспечивать вызов основных функций через API, в частности, обладать встроенным в ПО компонентом отладки API запросов Swagger. Значение характеристики не может изменяться участником закупки 11. ПО должно содержать инструменты для разработчиков, позволяющие управлять функциями API. 12. ПО должно иметь административный и пользовательский веб-портал. 13. ПО должно обеспечивать работу виртуальных машин и остальных серверных компонентов инфраструктуры. 14. ПО должно обеспечивать возможность создания шаблонов виртуальных машин и быстрого развертывания виртуальных машин из этих шаблонов. 15. ПО должно поддерживать возможность подключения библиотеки с образами виртуальных машин. При этом: • у производителя должна быть доступна и поддерживаться онлайн-библиотека с популярными образами; • система должна позволять подключить локальную библиотеку образов; • должна быть возможность использования нескольких библиотек образов в одной системе. 16. ПО должно обеспечивать возможность администратору системы получать доступ к гостевой операционной системе через сервер виртуализации даже в случае отсутствия у виртуальной машины сетевого адаптера или подключения к сети. 17. ПО должно обеспечивать доступ к консоли ВМ по протоколам SPICE, VNC. (без необходимости использовать дополнительное ПО) 18. ПО должно поддерживать систему расширенного удаленного доступа с пробросом буфера обмена, папок и файлов, звука и видео на базе протокола SPICE 19. В ПО должна быть возможность создавать пользовательские шаблоны конфигурации, в которых задаются характеристики виртуальной машины (процессор, память, настройки SPICE, настройки дисков), при этом шаблон не содержит копии виртуального диска с ОС и используется для быстрой конфигурации мастера создания новых ВМ 20. ПО должно обеспечивать разграничение доступа к виртуальной среде, построенное на основе классической ролевой политики безопасности и имеющее возможность ее интеграции со службой каталога. 21. ПО должно обеспечивать возможность перемещения виртуальных машин между серверами без выключения ОС виртуальной машины. 22. ПО должно обеспечивать возможность перемещения файлов виртуальных машин между системами хранения без выключения ОС виртуальной машины. 23. ПО должно обеспечивать функционал управляемого аварийного восстановления ВМ, с использованием разделяемого хранилища, в случае аварийного выхода из строя узла кластера, администратор платформы из графического интерфейса может выполнить операцию восстановления ВМ на резервном узле. 24. ПО должно поддерживать конфигурацию высокой-доступности ВМ, при котором в случае аварийного сбоя узла кластера обеспечивается автоматический перезапуск виртуальных машин на доступных серверах кластера. Функционал должен поддерживать защиту на уровне кластера с общим хранилищем, поддерживать индивидуальную настройку защищаемых ВМ. 25. ПО должно обеспечивать функцию клонирования виртуальных машин. 26. ПО должно обеспечивать возможность изменения конфигурации ВМ без необходимости остановки или перезапуска (изменение характеристик включенной виртуальной машины vCPU, RAM, Virtual Hard Drives и др.). 27. ПО должно обеспечивать возможность выделять пространство на файловом хранилище для дисков виртуальных машин по требованию, позволяющее более эффективно его использовать. 28. ПО должно обеспечивать возможность создания мгновенного снимка состояния виртуальной машины с возможностью возврата к нему, при этом должна быть доступна опция сохранения оперативной памяти ВМ. 29. ПО должно обеспечивать единое окно отслеживания состояния системы в реальном времени (Dashboard). 30. ПО должно обеспечивать размещение файлов виртуальных машин на следующих типах систем хранения: • на локальном диске гипервизора; • на СХД с блочным доступом по протоколам Fibre Channel и iSCSI, FC-NVMe; • на кластере SDS на базе Ceph. 31. ПО должно обеспечивать возможность динамической балансировки нагрузок между серверами кластера, путем автоматической миграции виртуальных машин, без необходимости выключения или перезагрузки. При этом администратор платформы должен иметь возможность, из графического интерфейса задать параметры балансировки, такие как уровни нагрузки центрального процессора и оперативной памяти, для тонкой настройки активации и деактивации автоматики балансировки. 32. ПО должно поддерживать интеграцию с системой мониторинга Zabbix, а также поддерживать размещение шаблонов агентов мониторинга в официальных репозиториях Zabbix 33. ПО должно иметь встроенный в свой состав контейнер с системой визуализации Grafana для передачи параметров состояния физических и виртуальных машин. 34. ПО должно иметь возможность интеграции с ПО Termidesk (или эквивалент). Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. 35. ПО должно обеспечивать возможность управления локальными пользователями посредством веб-интерфейса. 36. ПО должно обеспечивать возможность импорта ВМ из платформы виртуализации VMware vSphere. 37. ПО должно иметь возможность “растягивания” виртуальных сетей VxLAN между географически распределенными локациями поверх сети Интернет. 38. ПО должно поддерживать протоколы iBGP/eBGP, настройка которых должна быть доступна из web-интерфейса платформы. 39. ПО должно обеспечивать возможность централизованной настройки сетевых компонентов виртуальной коммутации на хостах виртуализации через графический интерфейс системы. 40. ПО должно обеспечивать поддержку миграции виртуальных машин между кластерами без прерывания работы сервисов в гостевых ОС. 41. ПО должно обеспечивать поддержку миграции дисков виртуальных машин между хранилищами без прерывания работы гостевых ОС. 42. ПО должно обеспечивать масштабирование не менее чем до 64 кластеров, 250 хостов виртуализации в рамках одного кластера без функции отказоустойчивости, и не менее 24 хостов виртуализации в рамках одного отказоустойчивого кластера. Общее число хостов виртуализации в одной платформе до 700 43. ПО должно обладать встроенной системой класса IPAM управления IP-адресами. 44. ПО должно обладать совместимостью с системой резервного копирования RuBackup без необходимости использования дополнительных инструментов. Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. 45. ПО должно содержать встроенные инструменты мониторинга и оповещений как с использованием почты, так и с интеграцией с Telegram. 46. Для ПО должны быть разработаны готовые интеграции с биллинговыми системами для учета выделенных и потраченных ресурсов. 47. ПО должно обладать готовой интеграцией с Terraform для реализации подхода IaC в управлении инфраструктурой. 48. ПО должно обладать возможностью ведения библиотеки скриптов Shell, PowerShell, Ansible, Python. Возможностью запуска для настройки виртуальных машин, узлов кластера из графического интерфейса системы. 49. ПО должно обладать возможностью использования преднастроенных, динамических, статических, локальных и глобальных переменных для скриптов с разным уровнем доступа для пользователя и администратора. 50. ПО должно обладать возможностью использования параметров для передачи в скрипт при выполнении на конкретном объекте виртуальной инфраструктуры. Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет. **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов. - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - описание - 1. Программное обеспечение (ПО), должно выполнять следующие функции управления серверной виртуализации: управление серверами и кластерами виртуализации; управление виртуальными машинами; управление контейнерами; управление виртуальными дисками; управление виртуальными коммутаторами; управление сетями и пулами; управление доступом пользователей и групп к объектам инфраструктуры. 2. ПО должно поддерживать установку хостов виртуализации на ОС, соответствующую программному классу «Операционные системы общего назначения» из Единого реестра российских программ для электронных вычислительных машин и баз данных. 3. ПО должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных. 4. Документация предоставляемая на ПО должна быть доступна на русском и английском языках. 5. ПО должно обеспечивать виртуализацию аппаратных ресурсов в виде обособленных виртуальных машин, работающих на физическом сервере х86 архитектуры. 6. ПО должно поддерживать возможность работы собственной системы управления в следующих конфигурациях: • на выделенном физическом сервере; • на виртуальной машине размещенной на на отдельно стоящем сервере; • на виртуальной машине размещенной непосредственно на узле управляемого кластера (без необходимости дополнительного сервера). 7. ПО должно поддерживать работу в закрытом сетевом контуре без доступа в сеть Интернет. 8. ПО должно иметь поддержку отображения графического интерфейса администратора на русском языке. 9. ПО должно обеспечивать единый веб-интерфейс и интерфейс командной строки администратора службы. 10. ПО должно обеспечивать вызов основных функций через API, в частности, обладать встроенным в ПО компонентом отладки API запросов Swagger. - - Значение характеристики не может изменяться участником закупки - 11. ПО должно содержать инструменты для разработчиков, позволяющие управлять функциями API. 12. ПО должно иметь административный и пользовательский веб-портал. 13. ПО должно обеспечивать работу виртуальных машин и остальных серверных компонентов инфраструктуры. 14. ПО должно обеспечивать возможность создания шаблонов виртуальных машин и быстрого развертывания виртуальных машин из этих шаблонов. 15. ПО должно поддерживать возможность подключения библиотеки с образами виртуальных машин. При этом: • у производителя должна быть доступна и поддерживаться онлайн-библиотека с популярными образами; • система должна позволять подключить локальную библиотеку образов; • должна быть возможность использования нескольких библиотек образов в одной системе. 16. ПО должно обеспечивать возможность администратору системы получать доступ к гостевой операционной системе через сервер виртуализации даже в случае отсутствия у виртуальной машины сетевого адаптера или подключения к сети. 17. ПО должно обеспечивать доступ к консоли ВМ по протоколам SPICE, VNC. (без необходимости использовать дополнительное ПО) 18. ПО должно поддерживать систему расширенного удаленного доступа с пробросом буфера обмена, папок и файлов, звука и видео на базе протокола SPICE 19. В ПО должна быть возможность создавать пользовательские шаблоны конфигурации, в которых задаются характеристики виртуальной машины (процессор, память, настройки SPICE, настройки дисков), при этом шаблон не содержит копии виртуального диска с ОС и используется для быстрой конфигурации мастера создания новых ВМ 20. ПО должно обеспечивать разграничение доступа к виртуальной среде, построенное на основе классической ролевой политики безопасности и имеющее возможность ее интеграции со службой каталога. 21. ПО должно обеспечивать возможность перемещения виртуальных машин между серверами без выключения ОС виртуальной машины. - 22. ПО должно обеспечивать возможность перемещения файлов виртуальных машин между системами хранения без выключения ОС виртуальной машины. 23. ПО должно обеспечивать функционал управляемого аварийного восстановления ВМ, с использованием разделяемого хранилища, в случае аварийного выхода из строя узла кластера, администратор платформы из графического интерфейса может выполнить операцию восстановления ВМ на резервном узле. 24. ПО должно поддерживать конфигурацию высокой-доступности ВМ, при котором в случае аварийного сбоя узла кластера обеспечивается автоматический перезапуск виртуальных машин на доступных серверах кластера. Функционал должен поддерживать защиту на уровне кластера с общим хранилищем, поддерживать индивидуальную настройку защищаемых ВМ. 25. ПО должно обеспечивать функцию клонирования виртуальных машин. 26. ПО должно обеспечивать возможность изменения конфигурации ВМ без необходимости остановки или перезапуска (изменение характеристик включенной виртуальной машины vCPU, RAM, Virtual Hard Drives и др.). 27. ПО должно обеспечивать возможность выделять пространство на файловом хранилище для дисков виртуальных машин по требованию, позволяющее более эффективно его использовать. 28. ПО должно обеспечивать возможность создания мгновенного снимка состояния виртуальной машины с возможностью возврата к нему, при этом должна быть доступна опция сохранения оперативной памяти ВМ. 29. ПО должно обеспечивать единое окно отслеживания состояния системы в реальном времени (Dashboard). 30. ПО должно обеспечивать размещение файлов виртуальных машин на следующих типах систем хранения: • на локальном диске гипервизора; • на СХД с блочным доступом по протоколам Fibre Channel и iSCSI, FC-NVMe; • на кластере SDS на базе Ceph. - 31. ПО должно обеспечивать возможность динамической балансировки нагрузок между серверами кластера, путем автоматической миграции виртуальных машин, без необходимости выключения или перезагрузки. При этом администратор платформы должен иметь возможность, из графического интерфейса задать параметры балансировки, такие как уровни нагрузки центрального процессора и оперативной памяти, для тонкой настройки активации и деактивации автоматики балансировки. 32. ПО должно поддерживать интеграцию с системой мониторинга Zabbix, а также поддерживать размещение шаблонов агентов мониторинга в официальных репозиториях Zabbix 33. ПО должно иметь встроенный в свой состав контейнер с системой визуализации Grafana для передачи параметров состояния физических и виртуальных машин. 34. ПО должно иметь возможность интеграции с ПО Termidesk (или эквивалент). Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. 35. ПО должно обеспечивать возможность управления локальными пользователями посредством веб-интерфейса. 36. ПО должно обеспечивать возможность импорта ВМ из платформы виртуализации VMware vSphere. 37. ПО должно иметь возможность “растягивания” виртуальных сетей VxLAN между географически распределенными локациями поверх сети Интернет. 38. ПО должно поддерживать протоколы iBGP/eBGP, настройка которых должна быть доступна из web-интерфейса платформы. 39. ПО должно обеспечивать возможность централизованной настройки сетевых компонентов виртуальной коммутации на хостах виртуализации через графический интерфейс системы. 40. ПО должно обеспечивать поддержку миграции виртуальных машин между кластерами без прерывания работы сервисов в гостевых ОС. 41. ПО должно обеспечивать поддержку миграции дисков виртуальных машин между хранилищами без прерывания работы гостевых ОС. - 42. ПО должно обеспечивать масштабирование не менее чем до 64 кластеров, 250 хостов виртуализации в рамках одного кластера без функции отказоустойчивости, и не менее 24 хостов виртуализации в рамках одного отказоустойчивого кластера. Общее число хостов виртуализации в одной платформе до 700 43. ПО должно обладать встроенной системой класса IPAM управления IP-адресами. 44. ПО должно обладать совместимостью с системой резервного копирования RuBackup без необходимости использования дополнительных инструментов. Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. 45. ПО должно содержать встроенные инструменты мониторинга и оповещений как с использованием почты, так и с интеграцией с Telegram. 46. Для ПО должны быть разработаны готовые интеграции с биллинговыми системами для учета выделенных и потраченных ресурсов. 47. ПО должно обладать готовой интеграцией с Terraform для реализации подхода IaC в управлении инфраструктурой. 48. ПО должно обладать возможностью ведения библиотеки скриптов Shell, PowerShell, Ansible, Python. Возможностью запуска для настройки виртуальных машин, узлов кластера из графического интерфейса системы. 49. ПО должно обладать возможностью использования преднастроенных, динамических, статических, локальных и глобальных переменных для скриптов с разным уровнем доступа для пользователя и администратора. 50. ПО должно обладать возможностью использования параметров для передачи в скрипт при выполнении на конкретном объекте виртуальной инфраструктуры. Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет. - **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов.

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

описание - 1. Программное обеспечение (ПО), должно выполнять следующие функции управления серверной виртуализации: управление серверами и кластерами виртуализации; управление виртуальными машинами; управление контейнерами; управление виртуальными дисками; управление виртуальными коммутаторами; управление сетями и пулами; управление доступом пользователей и групп к объектам инфраструктуры. 2. ПО должно поддерживать установку хостов виртуализации на ОС, соответствующую программному классу «Операционные системы общего назначения» из Единого реестра российских программ для электронных вычислительных машин и баз данных. 3. ПО должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных. 4. Документация предоставляемая на ПО должна быть доступна на русском и английском языках. 5. ПО должно обеспечивать виртуализацию аппаратных ресурсов в виде обособленных виртуальных машин, работающих на физическом сервере х86 архитектуры. 6. ПО должно поддерживать возможность работы собственной системы управления в следующих конфигурациях: • на выделенном физическом сервере; • на виртуальной машине размещенной на на отдельно стоящем сервере; • на виртуальной машине размещенной непосредственно на узле управляемого кластера (без необходимости дополнительного сервера). 7. ПО должно поддерживать работу в закрытом сетевом контуре без доступа в сеть Интернет. 8. ПО должно иметь поддержку отображения графического интерфейса администратора на русском языке. 9. ПО должно обеспечивать единый веб-интерфейс и интерфейс командной строки администратора службы. 10. ПО должно обеспечивать вызов основных функций через API, в частности, обладать встроенным в ПО компонентом отладки API запросов Swagger. - - Значение характеристики не может изменяться участником закупки

11. ПО должно содержать инструменты для разработчиков, позволяющие управлять функциями API. 12. ПО должно иметь административный и пользовательский веб-портал. 13. ПО должно обеспечивать работу виртуальных машин и остальных серверных компонентов инфраструктуры. 14. ПО должно обеспечивать возможность создания шаблонов виртуальных машин и быстрого развертывания виртуальных машин из этих шаблонов. 15. ПО должно поддерживать возможность подключения библиотеки с образами виртуальных машин. При этом: • у производителя должна быть доступна и поддерживаться онлайн-библиотека с популярными образами; • система должна позволять подключить локальную библиотеку образов; • должна быть возможность использования нескольких библиотек образов в одной системе. 16. ПО должно обеспечивать возможность администратору системы получать доступ к гостевой операционной системе через сервер виртуализации даже в случае отсутствия у виртуальной машины сетевого адаптера или подключения к сети. 17. ПО должно обеспечивать доступ к консоли ВМ по протоколам SPICE, VNC. (без необходимости использовать дополнительное ПО) 18. ПО должно поддерживать систему расширенного удаленного доступа с пробросом буфера обмена, папок и файлов, звука и видео на базе протокола SPICE 19. В ПО должна быть возможность создавать пользовательские шаблоны конфигурации, в которых задаются характеристики виртуальной машины (процессор, память, настройки SPICE, настройки дисков), при этом шаблон не содержит копии виртуального диска с ОС и используется для быстрой конфигурации мастера создания новых ВМ 20. ПО должно обеспечивать разграничение доступа к виртуальной среде, построенное на основе классической ролевой политики безопасности и имеющее возможность ее интеграции со службой каталога. 21. ПО должно обеспечивать возможность перемещения виртуальных машин между серверами без выключения ОС виртуальной машины.

22. ПО должно обеспечивать возможность перемещения файлов виртуальных машин между системами хранения без выключения ОС виртуальной машины. 23. ПО должно обеспечивать функционал управляемого аварийного восстановления ВМ, с использованием разделяемого хранилища, в случае аварийного выхода из строя узла кластера, администратор платформы из графического интерфейса может выполнить операцию восстановления ВМ на резервном узле. 24. ПО должно поддерживать конфигурацию высокой-доступности ВМ, при котором в случае аварийного сбоя узла кластера обеспечивается автоматический перезапуск виртуальных машин на доступных серверах кластера. Функционал должен поддерживать защиту на уровне кластера с общим хранилищем, поддерживать индивидуальную настройку защищаемых ВМ. 25. ПО должно обеспечивать функцию клонирования виртуальных машин. 26. ПО должно обеспечивать возможность изменения конфигурации ВМ без необходимости остановки или перезапуска (изменение характеристик включенной виртуальной машины vCPU, RAM, Virtual Hard Drives и др.). 27. ПО должно обеспечивать возможность выделять пространство на файловом хранилище для дисков виртуальных машин по требованию, позволяющее более эффективно его использовать. 28. ПО должно обеспечивать возможность создания мгновенного снимка состояния виртуальной машины с возможностью возврата к нему, при этом должна быть доступна опция сохранения оперативной памяти ВМ. 29. ПО должно обеспечивать единое окно отслеживания состояния системы в реальном времени (Dashboard). 30. ПО должно обеспечивать размещение файлов виртуальных машин на следующих типах систем хранения: • на локальном диске гипервизора; • на СХД с блочным доступом по протоколам Fibre Channel и iSCSI, FC-NVMe; • на кластере SDS на базе Ceph.

31. ПО должно обеспечивать возможность динамической балансировки нагрузок между серверами кластера, путем автоматической миграции виртуальных машин, без необходимости выключения или перезагрузки. При этом администратор платформы должен иметь возможность, из графического интерфейса задать параметры балансировки, такие как уровни нагрузки центрального процессора и оперативной памяти, для тонкой настройки активации и деактивации автоматики балансировки. 32. ПО должно поддерживать интеграцию с системой мониторинга Zabbix, а также поддерживать размещение шаблонов агентов мониторинга в официальных репозиториях Zabbix 33. ПО должно иметь встроенный в свой состав контейнер с системой визуализации Grafana для передачи параметров состояния физических и виртуальных машин. 34. ПО должно иметь возможность интеграции с ПО Termidesk (или эквивалент). Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. 35. ПО должно обеспечивать возможность управления локальными пользователями посредством веб-интерфейса. 36. ПО должно обеспечивать возможность импорта ВМ из платформы виртуализации VMware vSphere. 37. ПО должно иметь возможность “растягивания” виртуальных сетей VxLAN между географически распределенными локациями поверх сети Интернет. 38. ПО должно поддерживать протоколы iBGP/eBGP, настройка которых должна быть доступна из web-интерфейса платформы. 39. ПО должно обеспечивать возможность централизованной настройки сетевых компонентов виртуальной коммутации на хостах виртуализации через графический интерфейс системы. 40. ПО должно обеспечивать поддержку миграции виртуальных машин между кластерами без прерывания работы сервисов в гостевых ОС. 41. ПО должно обеспечивать поддержку миграции дисков виртуальных машин между хранилищами без прерывания работы гостевых ОС.

42. ПО должно обеспечивать масштабирование не менее чем до 64 кластеров, 250 хостов виртуализации в рамках одного кластера без функции отказоустойчивости, и не менее 24 хостов виртуализации в рамках одного отказоустойчивого кластера. Общее число хостов виртуализации в одной платформе до 700 43. ПО должно обладать встроенной системой класса IPAM управления IP-адресами. 44. ПО должно обладать совместимостью с системой резервного копирования RuBackup без необходимости использования дополнительных инструментов. Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. 45. ПО должно содержать встроенные инструменты мониторинга и оповещений как с использованием почты, так и с интеграцией с Telegram. 46. Для ПО должны быть разработаны готовые интеграции с биллинговыми системами для учета выделенных и потраченных ресурсов. 47. ПО должно обладать готовой интеграцией с Terraform для реализации подхода IaC в управлении инфраструктурой. 48. ПО должно обладать возможностью ведения библиотеки скриптов Shell, PowerShell, Ansible, Python. Возможностью запуска для настройки виртуальных машин, узлов кластера из графического интерфейса системы. 49. ПО должно обладать возможностью использования преднастроенных, динамических, статических, локальных и глобальных переменных для скриптов с разным уровнем доступа для пользователя и администратора. 50. ПО должно обладать возможностью использования параметров для передачи в скрипт при выполнении на конкретном объекте виртуальной инфраструктуры. Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет.

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

- 58.29.50.000 - Расширение лицензии на программное обеспечение VMmanager 6 редакции Infrastructure на 1 физический сервер (не более 2 CPU или дополнительно 2 CPU) описание 1. Программное обеспечение (ПО), должно выполнять следующие функции управления серверной виртуализации: управление серверами и кластерами виртуализации; управление виртуальными машинами; управление контейнерами; управление виртуальными дисками; управление виртуальными коммутаторами; управление сетями и пулами; управление доступом пользователей и групп к объектам инфраструктуры. 2. ПО должно поддерживать установку хостов виртуализации на ОС, соответствующую программному классу «Операционные системы общего назначения» из Единого реестра российских программ для электронных вычислительных машин и баз данных. 3. ПО должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных. 4. Документация предоставляемая на ПО должна быть доступна на русском и английском языках. 5. ПО должно обеспечивать виртуализацию аппаратных ресурсов в виде обособленных виртуальных машин, работающих на физическом сервере х86 архитектуры. 6. ПО должно поддерживать возможность работы собственной системы управления в следующих конфигурациях: • на выделенном физическом сервере; • на виртуальной машине размещенной на на отдельно стоящем сервере; • на виртуальной машине размещенной непосредственно на узле управляемого кластера (без необходимости дополнительного сервера). 7. ПО должно поддерживать работу в закрытом сетевом контуре без доступа в сеть Интернет. 8. ПО должно иметь поддержку отображения графического интерфейса администратора на русском языке. 9. ПО должно обеспечивать единый веб-интерфейс и интерфейс командной строки администратора службы. 10. ПО должно обеспечивать вызов основных функций через API, в частности, обладать встроенным в ПО компонентом отладки API запросов Swagger. ... - Штука - 7,00 - 227 395,00 - 1 591 765,00

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ ЗДРАВООХРАНЕНИЯ "КУЗБАССКИЙ КЛИНИЧЕСКИЙ КАРДИОЛОГИЧЕСКИЙ ДИСПАНСЕР ИМЕНИ АКАДЕМИКА Л.С. БАРБАРАША" - 7 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке описание 1. Программное обеспечение (ПО), должно выполнять следующие функции управления серверной виртуализации: управление серверами и кластерами виртуализации; управление виртуальными машинами; управление контейнерами; управление виртуальными дисками; управление виртуальными коммутаторами; управление сетями и пулами; управление доступом пользователей и групп к объектам инфраструктуры. 2. ПО должно поддерживать установку хостов виртуализации на ОС, соответствующую программному классу «Операционные системы общего назначения» из Единого реестра российских программ для электронных вычислительных машин и баз данных. 3. ПО должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных. 4. Документация предоставляемая на ПО должна быть доступна на русском и английском языках. 5. ПО должно обеспечивать виртуализацию аппаратных ресурсов в виде обособленных виртуальных машин, работающих на физическом сервере х86 архитектуры. 6. ПО должно поддерживать возможность работы собственной системы управления в следующих конфигурациях: • на выделенном физическом сервере; • на виртуальной машине размещенной на на отдельно стоящем сервере; • на виртуальной машине размещенной непосредственно на узле управляемого кластера (без необходимости дополнительного сервера). 7. ПО должно поддерживать работу в закрытом сетевом контуре без доступа в сеть Интернет. 8. ПО должно иметь поддержку отображения графического интерфейса администратора на русском языке. 9. ПО должно обеспечивать единый веб-интерфейс и интерфейс командной строки администратора службы. 10. ПО должно обеспечивать вызов основных функций через API, в частности, обладать встроенным в ПО компонентом отладки API запросов Swagger. Значение характеристики не может изменяться участником закупки 11. ПО должно содержать инструменты для разработчиков, позволяющие управлять функциями API. 12. ПО должно иметь административный и пользовательский веб-портал. 13. ПО должно обеспечивать работу виртуальных машин и остальных серверных компонентов инфраструктуры. 14. ПО должно обеспечивать возможность создания шаблонов виртуальных машин и быстрого развертывания виртуальных машин из этих шаблонов. 15. ПО должно поддерживать возможность подключения библиотеки с образами виртуальных машин. При этом: • у производителя должна быть доступна и поддерживаться онлайн-библиотека с популярными образами; • система должна позволять подключить локальную библиотеку образов; • должна быть возможность использования нескольких библиотек образов в одной системе. 16. ПО должно обеспечивать возможность администратору системы получать доступ к гостевой операционной системе через сервер виртуализации даже в случае отсутствия у виртуальной машины сетевого адаптера или подключения к сети. 17. ПО должно обеспечивать доступ к консоли ВМ по протоколам SPICE, VNC. (без необходимости использовать дополнительное ПО) 18. ПО должно поддерживать систему расширенного удаленного доступа с пробросом буфера обмена, папок и файлов, звука и видео на базе протокола SPICE 19. В ПО должна быть возможность создавать пользовательские шаблоны конфигурации, в которых задаются характеристики виртуальной машины (процессор, память, настройки SPICE, настройки дисков), при этом шаблон не содержит копии виртуального диска с ОС и используется для быстрой конфигурации мастера создания новых ВМ 20. ПО должно обеспечивать разграничение доступа к виртуальной среде, построенное на основе классической ролевой политики безопасности и имеющее возможность ее интеграции со службой каталога. 21. ПО должно обеспечивать возможность перемещения виртуальных машин между серверами без выключения ОС виртуальной машины. 22. ПО должно обеспечивать возможность перемещения файлов виртуальных машин между системами хранения без выключения ОС виртуальной машины. 23. ПО должно обеспечивать функционал управляемого аварийного восстановления ВМ, с использованием разделяемого хранилища, в случае аварийного выхода из строя узла кластера, администратор платформы из графического интерфейса может выполнить операцию восстановления ВМ на резервном узле. 24. ПО должно поддерживать конфигурацию высокой-доступности ВМ, при котором в случае аварийного сбоя узла кластера обеспечивается автоматический перезапуск виртуальных машин на доступных серверах кластера. Функционал должен поддерживать защиту на уровне кластера с общим хранилищем, поддерживать индивидуальную настройку защищаемых ВМ. 25. ПО должно обеспечивать функцию клонирования виртуальных машин. 26. ПО должно обеспечивать возможность изменения конфигурации ВМ без необходимости остановки или перезапуска (изменение характеристик включенной виртуальной машины vCPU, RAM, Virtual Hard Drives и др.). 27. ПО должно обеспечивать возможность выделять пространство на файловом хранилище для дисков виртуальных машин по требованию, позволяющее более эффективно его использовать. 28. ПО должно обеспечивать возможность создания мгновенного снимка состояния виртуальной машины с возможностью возврата к нему, при этом должна быть доступна опция сохранения оперативной памяти ВМ. 29. ПО должно обеспечивать единое окно отслеживания состояния системы в реальном времени (Dashboard). 30. ПО должно обеспечивать размещение файлов виртуальных машин на следующих типах систем хранения: • на локальном диске гипервизора; • на СХД с блочным доступом по протоколам Fibre Channel и iSCSI, FC-NVMe; • на кластере SDS на базе Ceph. 31. ПО должно обеспечивать возможность динамической балансировки нагрузок между серверами кластера, путем автоматической миграции виртуальных машин, без необходимости выключения или перезагрузки. При этом администратор платформы должен иметь возможность, из графического интерфейса задать параметры балансировки, такие как уровни нагрузки центрального процессора и оперативной памяти, для тонкой настройки активации и деактивации автоматики балансировки. 32. ПО должно поддерживать интеграцию с системой мониторинга Zabbix, а также поддерживать размещение шаблонов агентов мониторинга в официальных репозиториях Zabbix 33. ПО должно иметь встроенный в свой состав контейнер с системой визуализации Grafana для передачи параметров состояния физических и виртуальных машин. 34. ПО должно иметь возможность интеграции с ПО Termidesk (или эквивалент). Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. 35. ПО должно обеспечивать возможность управления локальными пользователями посредством веб-интерфейса. 36. ПО должно обеспечивать возможность импорта ВМ из платформы виртуализации VMware vSphere. 37. ПО должно иметь возможность “растягивания” виртуальных сетей VxLAN между географически распределенными локациями поверх сети Интернет. 38. ПО должно поддерживать протоколы iBGP/eBGP, настройка которых должна быть доступна из web-интерфейса платформы. 39. ПО должно обеспечивать возможность централизованной настройки сетевых компонентов виртуальной коммутации на хостах виртуализации через графический интерфейс системы. 40. ПО должно обеспечивать поддержку миграции виртуальных машин между кластерами без прерывания работы сервисов в гостевых ОС. 41. ПО должно обеспечивать поддержку миграции дисков виртуальных машин между хранилищами без прерывания работы гостевых ОС. 42. ПО должно обеспечивать масштабирование не менее чем до 64 кластеров, 250 хостов виртуализации в рамках одного кластера без функции отказоустойчивости, и не менее 24 хостов виртуализации в рамках одного отказоустойчивого кластера. Общее число хостов виртуализации в одной платформе до 700 43. ПО должно обладать встроенной системой класса IPAM управления IP-адресами. 44. ПО должно обладать совместимостью с системой резервного копирования RuBackup без необходимости использования дополнительных инструментов. Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. 45. ПО должно содержать встроенные инструменты мониторинга и оповещений как с использованием почты, так и с интеграцией с Telegram. 46. Для ПО должны быть разработаны готовые интеграции с биллинговыми системами для учета выделенных и потраченных ресурсов. 47. ПО должно обладать готовой интеграцией с Terraform для реализации подхода IaC в управлении инфраструктурой. 48. ПО должно обладать возможностью ведения библиотеки скриптов Shell, PowerShell, Ansible, Python. Возможностью запуска для настройки виртуальных машин, узлов кластера из графического интерфейса системы. 49. ПО должно обладать возможностью использования преднастроенных, динамических, статических, локальных и глобальных переменных для скриптов с разным уровнем доступа для пользователя и администратора. 50. ПО должно обладать возможностью использования параметров для передачи в скрипт при выполнении на конкретном объекте виртуальной инфраструктуры. Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет. **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов. - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - описание - 1. Программное обеспечение (ПО), должно выполнять следующие функции управления серверной виртуализации: управление серверами и кластерами виртуализации; управление виртуальными машинами; управление контейнерами; управление виртуальными дисками; управление виртуальными коммутаторами; управление сетями и пулами; управление доступом пользователей и групп к объектам инфраструктуры. 2. ПО должно поддерживать установку хостов виртуализации на ОС, соответствующую программному классу «Операционные системы общего назначения» из Единого реестра российских программ для электронных вычислительных машин и баз данных. 3. ПО должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных. 4. Документация предоставляемая на ПО должна быть доступна на русском и английском языках. 5. ПО должно обеспечивать виртуализацию аппаратных ресурсов в виде обособленных виртуальных машин, работающих на физическом сервере х86 архитектуры. 6. ПО должно поддерживать возможность работы собственной системы управления в следующих конфигурациях: • на выделенном физическом сервере; • на виртуальной машине размещенной на на отдельно стоящем сервере; • на виртуальной машине размещенной непосредственно на узле управляемого кластера (без необходимости дополнительного сервера). 7. ПО должно поддерживать работу в закрытом сетевом контуре без доступа в сеть Интернет. 8. ПО должно иметь поддержку отображения графического интерфейса администратора на русском языке. 9. ПО должно обеспечивать единый веб-интерфейс и интерфейс командной строки администратора службы. 10. ПО должно обеспечивать вызов основных функций через API, в частности, обладать встроенным в ПО компонентом отладки API запросов Swagger. - - Значение характеристики не может изменяться участником закупки - 11. ПО должно содержать инструменты для разработчиков, позволяющие управлять функциями API. 12. ПО должно иметь административный и пользовательский веб-портал. 13. ПО должно обеспечивать работу виртуальных машин и остальных серверных компонентов инфраструктуры. 14. ПО должно обеспечивать возможность создания шаблонов виртуальных машин и быстрого развертывания виртуальных машин из этих шаблонов. 15. ПО должно поддерживать возможность подключения библиотеки с образами виртуальных машин. При этом: • у производителя должна быть доступна и поддерживаться онлайн-библиотека с популярными образами; • система должна позволять подключить локальную библиотеку образов; • должна быть возможность использования нескольких библиотек образов в одной системе. 16. ПО должно обеспечивать возможность администратору системы получать доступ к гостевой операционной системе через сервер виртуализации даже в случае отсутствия у виртуальной машины сетевого адаптера или подключения к сети. 17. ПО должно обеспечивать доступ к консоли ВМ по протоколам SPICE, VNC. (без необходимости использовать дополнительное ПО) 18. ПО должно поддерживать систему расширенного удаленного доступа с пробросом буфера обмена, папок и файлов, звука и видео на базе протокола SPICE 19. В ПО должна быть возможность создавать пользовательские шаблоны конфигурации, в которых задаются характеристики виртуальной машины (процессор, память, настройки SPICE, настройки дисков), при этом шаблон не содержит копии виртуального диска с ОС и используется для быстрой конфигурации мастера создания новых ВМ 20. ПО должно обеспечивать разграничение доступа к виртуальной среде, построенное на основе классической ролевой политики безопасности и имеющее возможность ее интеграции со службой каталога. 21. ПО должно обеспечивать возможность перемещения виртуальных машин между серверами без выключения ОС виртуальной машины. - 22. ПО должно обеспечивать возможность перемещения файлов виртуальных машин между системами хранения без выключения ОС виртуальной машины. 23. ПО должно обеспечивать функционал управляемого аварийного восстановления ВМ, с использованием разделяемого хранилища, в случае аварийного выхода из строя узла кластера, администратор платформы из графического интерфейса может выполнить операцию восстановления ВМ на резервном узле. 24. ПО должно поддерживать конфигурацию высокой-доступности ВМ, при котором в случае аварийного сбоя узла кластера обеспечивается автоматический перезапуск виртуальных машин на доступных серверах кластера. Функционал должен поддерживать защиту на уровне кластера с общим хранилищем, поддерживать индивидуальную настройку защищаемых ВМ. 25. ПО должно обеспечивать функцию клонирования виртуальных машин. 26. ПО должно обеспечивать возможность изменения конфигурации ВМ без необходимости остановки или перезапуска (изменение характеристик включенной виртуальной машины vCPU, RAM, Virtual Hard Drives и др.). 27. ПО должно обеспечивать возможность выделять пространство на файловом хранилище для дисков виртуальных машин по требованию, позволяющее более эффективно его использовать. 28. ПО должно обеспечивать возможность создания мгновенного снимка состояния виртуальной машины с возможностью возврата к нему, при этом должна быть доступна опция сохранения оперативной памяти ВМ. 29. ПО должно обеспечивать единое окно отслеживания состояния системы в реальном времени (Dashboard). 30. ПО должно обеспечивать размещение файлов виртуальных машин на следующих типах систем хранения: • на локальном диске гипервизора; • на СХД с блочным доступом по протоколам Fibre Channel и iSCSI, FC-NVMe; • на кластере SDS на базе Ceph. - 31. ПО должно обеспечивать возможность динамической балансировки нагрузок между серверами кластера, путем автоматической миграции виртуальных машин, без необходимости выключения или перезагрузки. При этом администратор платформы должен иметь возможность, из графического интерфейса задать параметры балансировки, такие как уровни нагрузки центрального процессора и оперативной памяти, для тонкой настройки активации и деактивации автоматики балансировки. 32. ПО должно поддерживать интеграцию с системой мониторинга Zabbix, а также поддерживать размещение шаблонов агентов мониторинга в официальных репозиториях Zabbix 33. ПО должно иметь встроенный в свой состав контейнер с системой визуализации Grafana для передачи параметров состояния физических и виртуальных машин. 34. ПО должно иметь возможность интеграции с ПО Termidesk (или эквивалент). Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. 35. ПО должно обеспечивать возможность управления локальными пользователями посредством веб-интерфейса. 36. ПО должно обеспечивать возможность импорта ВМ из платформы виртуализации VMware vSphere. 37. ПО должно иметь возможность “растягивания” виртуальных сетей VxLAN между географически распределенными локациями поверх сети Интернет. 38. ПО должно поддерживать протоколы iBGP/eBGP, настройка которых должна быть доступна из web-интерфейса платформы. 39. ПО должно обеспечивать возможность централизованной настройки сетевых компонентов виртуальной коммутации на хостах виртуализации через графический интерфейс системы. 40. ПО должно обеспечивать поддержку миграции виртуальных машин между кластерами без прерывания работы сервисов в гостевых ОС. 41. ПО должно обеспечивать поддержку миграции дисков виртуальных машин между хранилищами без прерывания работы гостевых ОС. - 42. ПО должно обеспечивать масштабирование не менее чем до 64 кластеров, 250 хостов виртуализации в рамках одного кластера без функции отказоустойчивости, и не менее 24 хостов виртуализации в рамках одного отказоустойчивого кластера. Общее число хостов виртуализации в одной платформе до 700 43. ПО должно обладать встроенной системой класса IPAM управления IP-адресами. 44. ПО должно обладать совместимостью с системой резервного копирования RuBackup без необходимости использования дополнительных инструментов. Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. 45. ПО должно содержать встроенные инструменты мониторинга и оповещений как с использованием почты, так и с интеграцией с Telegram. 46. Для ПО должны быть разработаны готовые интеграции с биллинговыми системами для учета выделенных и потраченных ресурсов. 47. ПО должно обладать готовой интеграцией с Terraform для реализации подхода IaC в управлении инфраструктурой. 48. ПО должно обладать возможностью ведения библиотеки скриптов Shell, PowerShell, Ansible, Python. Возможностью запуска для настройки виртуальных машин, узлов кластера из графического интерфейса системы. 49. ПО должно обладать возможностью использования преднастроенных, динамических, статических, локальных и глобальных переменных для скриптов с разным уровнем доступа для пользователя и администратора. 50. ПО должно обладать возможностью использования параметров для передачи в скрипт при выполнении на конкретном объекте виртуальной инфраструктуры. Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет. - **Программное обеспечение должно быть совместимо и корректно функционировать между собой для обеспечения единой информационной экосистемы с целью упрощенного внедрения комплексных решений без необходимости адаптации и интеграции стороннего ПО, а также предоставлять единый личный кабинет для обеспечения единообразной технической поддержки и услуг по обновлению программных продуктов.

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

описание - 1. Программное обеспечение (ПО), должно выполнять следующие функции управления серверной виртуализации: управление серверами и кластерами виртуализации; управление виртуальными машинами; управление контейнерами; управление виртуальными дисками; управление виртуальными коммутаторами; управление сетями и пулами; управление доступом пользователей и групп к объектам инфраструктуры. 2. ПО должно поддерживать установку хостов виртуализации на ОС, соответствующую программному классу «Операционные системы общего назначения» из Единого реестра российских программ для электронных вычислительных машин и баз данных. 3. ПО должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных. 4. Документация предоставляемая на ПО должна быть доступна на русском и английском языках. 5. ПО должно обеспечивать виртуализацию аппаратных ресурсов в виде обособленных виртуальных машин, работающих на физическом сервере х86 архитектуры. 6. ПО должно поддерживать возможность работы собственной системы управления в следующих конфигурациях: • на выделенном физическом сервере; • на виртуальной машине размещенной на на отдельно стоящем сервере; • на виртуальной машине размещенной непосредственно на узле управляемого кластера (без необходимости дополнительного сервера). 7. ПО должно поддерживать работу в закрытом сетевом контуре без доступа в сеть Интернет. 8. ПО должно иметь поддержку отображения графического интерфейса администратора на русском языке. 9. ПО должно обеспечивать единый веб-интерфейс и интерфейс командной строки администратора службы. 10. ПО должно обеспечивать вызов основных функций через API, в частности, обладать встроенным в ПО компонентом отладки API запросов Swagger. - - Значение характеристики не может изменяться участником закупки

11. ПО должно содержать инструменты для разработчиков, позволяющие управлять функциями API. 12. ПО должно иметь административный и пользовательский веб-портал. 13. ПО должно обеспечивать работу виртуальных машин и остальных серверных компонентов инфраструктуры. 14. ПО должно обеспечивать возможность создания шаблонов виртуальных машин и быстрого развертывания виртуальных машин из этих шаблонов. 15. ПО должно поддерживать возможность подключения библиотеки с образами виртуальных машин. При этом: • у производителя должна быть доступна и поддерживаться онлайн-библиотека с популярными образами; • система должна позволять подключить локальную библиотеку образов; • должна быть возможность использования нескольких библиотек образов в одной системе. 16. ПО должно обеспечивать возможность администратору системы получать доступ к гостевой операционной системе через сервер виртуализации даже в случае отсутствия у виртуальной машины сетевого адаптера или подключения к сети. 17. ПО должно обеспечивать доступ к консоли ВМ по протоколам SPICE, VNC. (без необходимости использовать дополнительное ПО) 18. ПО должно поддерживать систему расширенного удаленного доступа с пробросом буфера обмена, папок и файлов, звука и видео на базе протокола SPICE 19. В ПО должна быть возможность создавать пользовательские шаблоны конфигурации, в которых задаются характеристики виртуальной машины (процессор, память, настройки SPICE, настройки дисков), при этом шаблон не содержит копии виртуального диска с ОС и используется для быстрой конфигурации мастера создания новых ВМ 20. ПО должно обеспечивать разграничение доступа к виртуальной среде, построенное на основе классической ролевой политики безопасности и имеющее возможность ее интеграции со службой каталога. 21. ПО должно обеспечивать возможность перемещения виртуальных машин между серверами без выключения ОС виртуальной машины.

22. ПО должно обеспечивать возможность перемещения файлов виртуальных машин между системами хранения без выключения ОС виртуальной машины. 23. ПО должно обеспечивать функционал управляемого аварийного восстановления ВМ, с использованием разделяемого хранилища, в случае аварийного выхода из строя узла кластера, администратор платформы из графического интерфейса может выполнить операцию восстановления ВМ на резервном узле. 24. ПО должно поддерживать конфигурацию высокой-доступности ВМ, при котором в случае аварийного сбоя узла кластера обеспечивается автоматический перезапуск виртуальных машин на доступных серверах кластера. Функционал должен поддерживать защиту на уровне кластера с общим хранилищем, поддерживать индивидуальную настройку защищаемых ВМ. 25. ПО должно обеспечивать функцию клонирования виртуальных машин. 26. ПО должно обеспечивать возможность изменения конфигурации ВМ без необходимости остановки или перезапуска (изменение характеристик включенной виртуальной машины vCPU, RAM, Virtual Hard Drives и др.). 27. ПО должно обеспечивать возможность выделять пространство на файловом хранилище для дисков виртуальных машин по требованию, позволяющее более эффективно его использовать. 28. ПО должно обеспечивать возможность создания мгновенного снимка состояния виртуальной машины с возможностью возврата к нему, при этом должна быть доступна опция сохранения оперативной памяти ВМ. 29. ПО должно обеспечивать единое окно отслеживания состояния системы в реальном времени (Dashboard). 30. ПО должно обеспечивать размещение файлов виртуальных машин на следующих типах систем хранения: • на локальном диске гипервизора; • на СХД с блочным доступом по протоколам Fibre Channel и iSCSI, FC-NVMe; • на кластере SDS на базе Ceph.

31. ПО должно обеспечивать возможность динамической балансировки нагрузок между серверами кластера, путем автоматической миграции виртуальных машин, без необходимости выключения или перезагрузки. При этом администратор платформы должен иметь возможность, из графического интерфейса задать параметры балансировки, такие как уровни нагрузки центрального процессора и оперативной памяти, для тонкой настройки активации и деактивации автоматики балансировки. 32. ПО должно поддерживать интеграцию с системой мониторинга Zabbix, а также поддерживать размещение шаблонов агентов мониторинга в официальных репозиториях Zabbix 33. ПО должно иметь встроенный в свой состав контейнер с системой визуализации Grafana для передачи параметров состояния физических и виртуальных машин. 34. ПО должно иметь возможность интеграции с ПО Termidesk (или эквивалент). Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. 35. ПО должно обеспечивать возможность управления локальными пользователями посредством веб-интерфейса. 36. ПО должно обеспечивать возможность импорта ВМ из платформы виртуализации VMware vSphere. 37. ПО должно иметь возможность “растягивания” виртуальных сетей VxLAN между географически распределенными локациями поверх сети Интернет. 38. ПО должно поддерживать протоколы iBGP/eBGP, настройка которых должна быть доступна из web-интерфейса платформы. 39. ПО должно обеспечивать возможность централизованной настройки сетевых компонентов виртуальной коммутации на хостах виртуализации через графический интерфейс системы. 40. ПО должно обеспечивать поддержку миграции виртуальных машин между кластерами без прерывания работы сервисов в гостевых ОС. 41. ПО должно обеспечивать поддержку миграции дисков виртуальных машин между хранилищами без прерывания работы гостевых ОС.

42. ПО должно обеспечивать масштабирование не менее чем до 64 кластеров, 250 хостов виртуализации в рамках одного кластера без функции отказоустойчивости, и не менее 24 хостов виртуализации в рамках одного отказоустойчивого кластера. Общее число хостов виртуализации в одной платформе до 700 43. ПО должно обладать встроенной системой класса IPAM управления IP-адресами. 44. ПО должно обладать совместимостью с системой резервного копирования RuBackup без необходимости использования дополнительных инструментов. Совместимость и корректность работы должны быть документально подтверждены двусторонним сертификатом. 45. ПО должно содержать встроенные инструменты мониторинга и оповещений как с использованием почты, так и с интеграцией с Telegram. 46. Для ПО должны быть разработаны готовые интеграции с биллинговыми системами для учета выделенных и потраченных ресурсов. 47. ПО должно обладать готовой интеграцией с Terraform для реализации подхода IaC в управлении инфраструктурой. 48. ПО должно обладать возможностью ведения библиотеки скриптов Shell, PowerShell, Ansible, Python. Возможностью запуска для настройки виртуальных машин, узлов кластера из графического интерфейса системы. 49. ПО должно обладать возможностью использования преднастроенных, динамических, статических, локальных и глобальных переменных для скриптов с разным уровнем доступа для пользователя и администратора. 50. ПО должно обладать возможностью использования параметров для передачи в скрипт при выполнении на конкретном объекте виртуальной инфраструктуры. Способ передачи лицензий: электронный; Техническая поддержка: 12 месяцев; Срок действия лицензий: 12 месяцев с возможностью полной передачи лицензии по результату продления в течении 3х лет.

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

Преимущества, требования к участникам

Преимущества: Не установлены

Требования к участникам: 1. Требования к участникам закупок в соответствии с ч. 1.1 ст. 31 Закона № 44-ФЗ 2. Единые требования к участникам закупок в соответствии с ч. 1 ст. 31 Закона № 44-ФЗ

Применение национального режима по ст. 14 Закона № 44-ФЗ

Применение национального режима по ст. 14 Закона № 44-ФЗ: Основанием для установки указания запретов, ограничений закупок товаров, происходящих из иностранных государств, выполняемых работ, оказываемых услуг иностранными лицами, а так же преимуществ в отношении товаров российского происхождения, а также товаров происходящих из стран ЕАЭС, выполняемых работ, оказываемых услуг российскими лицами, а также лицами, зарегистрированными в странах ЕАЭС, является Постановление Правительства Российской Федерации о мерах по предоставлению национального режима от 23.12.2024 № 1875.

Сведения о связи с позицией плана-графика

Сведения о связи с позицией плана-графика: 202603393002652001000229

Начальная (максимальная) цена контракта: 3 490 865,00

Валюта: РОССИЙСКИЙ РУБЛЬ

Идентификационный код закупки (ИКЗ): 263420800174842050100102020015829244

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

Дата начала исполнения контракта: с даты заключения контракта

Срок исполнения контракта: 26.05.2027

Закупка за счет собственных средств организации: Да

Требуется обеспечение заявки: Да

Размер обеспечения заявки: 34 908,65 РОССИЙСКИЙ РУБЛЬ

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

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03224643320000005100, л/c 802Ю1178000/ОБ, БИК 015004950, ОКЦ № 1 СибГУ Банка России//УФК по Новосибирской области, г Новосибирск, к/c 40102810445370000043

Реквизиты счета для перечисления денежных средств в случае, предусмотренном ч.13 ст. 44 Закона № 44-ФЗ (в соответствующий бюджет бюджетной системы Российской Федерации): Получатель Номер единого казначейского счета Номер казначейского счета БИК ТОФК УПРАВЛЕНИЕ ФЕДЕРАЛЬНОГО КАЗНАЧЕЙСТВА ПО КЕМЕРОВСКОЙ ОБЛАСТИ - КУЗБАССУ (МИНЗДРАВ КУЗБАССА) ИНН: 4207022150 КПП: 420501001 КБК: 00511610056020000140 ОКТМО: 32701000001 40102810745370000032 03100643000000013900 013207212

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, обл Кемеровская область - Кузбасс, г. Новокузнецк: ул. Димитрова 31, ул. Димитрова 31/6, ул. Димитрова 35, ул. Кузнецова 35

Предусмотрена возможность одностороннего отказа от исполнения контракта в соответствии со ст. 95 Закона № 44-ФЗ: Да

Требуется обеспечение исполнения контракта: Да

Размер обеспечения исполнения контракта: 174 543,25 ? (5 %)

Порядок предоставления обеспечения исполнения контракта, требования к обеспечению: Указан в соответствующем разделе прикрепленного проекта контракта

Платежные реквизиты для обеспечения исполнения контракта: p/c 03224643320000005100, л/c 802Ю1178000/ОБ, БИК 015004950, ОКЦ № 1 СибГУ Банка России//УФК по Новосибирской области, г Новосибирск, к/c 40102810445370000043

Банковское или казначейское сопровождение контракта не требуется

Информация о сроках исполнения контракта и источниках финансирования

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

Дата начала исполнения контракта: с даты заключения контракта

Срок исполнения контракта: 26.05.2027

Закупка за счет собственных средств организации: Да

Документы

Общая информация

Документы

Журнал событий