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

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

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

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

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

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

Размещение осуществляет: Заказчик ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ "САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ ПЕДИАТРИЧЕСКИЙ МЕДИЦИНСКИЙ УНИВЕРСИТЕТ" МИНИСТЕРСТВА ЗДРАВООХРАНЕНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

Наименование объекта закупки: Оказание услуг по передаче программного обеспечения и сертификатов на техническую поддержку в 2026 году

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

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

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

Размещение осуществляет: Заказчик

Организация, осуществляющая размещение: ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ "САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ ПЕДИАТРИЧЕСКИЙ МЕДИЦИНСКИЙ УНИВЕРСИТЕТ" МИНИСТЕРСТВА ЗДРАВООХРАНЕНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

Почтовый адрес: Российская Федерация, 194100, Санкт-Петербург, Литовская ул, Д.2

Место нахождения: Российская Федерация, 194100, Санкт-Петербург, Литовская ул, Д.2

Ответственное должностное лицо: Аксенов И. Г.

Адрес электронной почты: kontrakt@gpmu.org

Номер контактного телефона: 7-812-2952848

Дополнительная информация: Информация отсутствует

Регион: Санкт-Петербург

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

Дата и время начала срока подачи заявок: 03.07.2026 14:38 (МСК)

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

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

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

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

Начальная (максимальная) цена контракта: 1 786 875,00

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

Размер аванса, %: 1,00

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

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

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

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

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

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

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

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

- 58.29.11.000 58.29.11.000-00000003 - Программное обеспечение Вид лицензии Простая (неисключительная) Класс программ для электронных вычислительных машин и баз данных (02.09) Операционные системы общего назначения Способ предоставления Экземпляр на материальном носителе - Штука - 1,00 - 98 125,00 - 98 125,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Вид лицензии Простая (неисключительная) Значение характеристики не может изменяться участником закупки Класс программ для электронных вычислительных машин и баз данных (02.09) Операционные системы общего назначения Значение характеристики не может изменяться участником закупки Способ предоставления Экземпляр на материальном носителе Значение характеристики не может изменяться участником закупки Общие требования Программное обеспечение должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных Минкомсвязи РФ по классам «Операционные системы общего назначения», «Средства виртуализации», «Серверное и связующее программное обеспечение», «Средства управления базами данных», «Системы контейнеризации и контейнеры», «Средства защиты от несанкционированного доступа к информации»; Операционная система должна соответствовать требованиям документов: «Требования безопасности информации к операционным системам» (ФСТЭК России, 2016) и «Профиль защиты операционных систем типа «А» четвертого класса защиты ИТ.ОС.А4.ПЗ» (ФСТЭК России, 2017) ; «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» не ниже четвертого уровня доверия (приказ ФСТЭК России № 76 от 2 июня 2020 г.); «Требования по безопасности информации к средствам контейнеризации» (приказ ФСТЭК России № 118, 2022,) не ниже 4 класса защиты; «Требования по безопасности информации к средствам виртуализации» (приказ ФСТЭК России, № 187, 2022 г.) не ниже 4 класса защиты; «Требования по безопасности информации к системам управления базами данных» (приказ ФСТЭК России № 64, 2023 г.) не ниже 4 класса защиты; В Формуляре ОС должны быть указаны интерпретаторы, веб сервера и сервера приложений, проверенные согласно документу: «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении», утверждена ФСТЭК России 25.12.2020 г.; Разработчик должен иметь собственную инфраструктуру разработки полного цикла, зарегистрированную и находящуюся на территории РФ, в исключительной юрисдикции РФ; Наличие в России локализованной сервисной и/или технической поддержки Значение характеристики не может изменяться участником закупки Функциональные требования (ч.1) Операционная система должна устанавливаться и функционировать на компьютерах с архитектурами x86_64 (64-разрядный процессор Intel или AMD), aarch64 («Байкал», Rockchip 3588) и «Эльбрус» (процессоры 8С, 1С+, 8СВ, 2С3, 12С, 16С) должны быть отдельные образы в сертифицированном исполнении для каждой архитектуры. Требования перечисленные в данном документе относятся к архитектуре x86_64 и могут отличатся от требований к другим архитектурам. Операционная система должна поддерживать режимы установки и загрузки Legacy/CSM, UEFI (с включенным механизмом SecureBoot), а также средствами BMC/IPMI (если поддерживается оборудованием). Операционная система должна иметь в составе ядро не ниже 6.12 (LTS) для обеспечения корректного функционирования современных средств вычислительной техники. Система должна пре доставлять графические утилиты для установки, удаления и обновления ядра, включая модули, а также для выбора ядра по умолчанию. Операционная система должна обеспечивать поддержку нескольких видеокарт (работа на нескольких мониторах). Операционная система должна обладать русифицированным интерфейсом, а также предоставлять русскоязычную документацию. Операционная система должна иметь возможность установки с DVD-диска и USB-накопителя. Операционная система должна предоставлять варианты сетевой установки: PXE/TFTP (для режима Legacy/CSM-загрузки), HTTPClient (для спецификации UEFI 2.5 и выше), iPXE Операционная система должна предоставлять возможность организации сервера сетевой загрузки. Операционная система должна предоставлять возможность установки на оборудование без графической подсистемы с локального накопителя, а также установки с использованием сервера сетевой установки по протоколу VNC Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 2) Носитель с дистрибутивом ОС должен предусматривать вариант загрузки для проведения работ по восстановлению системы, включая проверку сохранности содержимого файловой системы и проверку контрольных сумм неизменяемых файлов установленных пакетов, диагностику конфигурации аппаратного обеспечения, изменение таблицы и размеров разделов, изменение параметров файловых систем, восстановление удаленных разделов и файлов, проведение резервного копирования, очистку остаточной информации на разделах и дисках; Операционная система должна иметь возможность установки на программный RAID-массив, размещения разделов в томах LVM и использования маскирования (кодирования) разделов с парольным доступом; Операционная система должна обеспечивать возможность создания точек восстановления (снапшотов) для последующего возвращения системы к исходному состоянию в случае сбоя; Инсталлятор дистрибутива должен предусматривать возможность предварительной (OEM) установки, позволяющей при первом запуске пользователем после установки выбрать язык, принять лицензионное соглашение, настроить дату/время, настроить сеть, задать пароль root, создать системного пользователя; Операционная система должна предоставлять независимый выбор основных и дополнительных приложений в момент установки: серверные приложения (dhcp, dns,ftp, http, почтовый сервер, сервер резервного копирования, сервер печати, сервер сетевой установки), сканер обнаружения уязвимостей, сервер сертифицированной СУБД, сервер управления конфигурациями, сервер виртуальных рабочих столов, средства управления контейнеризацией, средства управления виртуализацией Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 3) Операционная система после установки должна предоставлять пользователю рабочую среду, включающую системное ПО, сетевые службы и сервисы, драйвера устройств, утилиты администрирования, базовый набор приложений; Если установлена графическая среда, операционная система должна предоставлять графическое средство настройки многопользовательского режима, позволяющего обеспечить одновременную работу нескольких пользователей на одном компьютере при наличии отдельной видеокарты, клавиатуры и мыши для каждого пользователя; Операционная система должна предоставлять инструмент для поиска уязвимостей в файлах конфигурации, файловых системах, используемых пакетах ОС (включая программные зависимости), образах контейнеров и git-репозиториях. Анализ уязвимостей должен осуществляться как по вендорской базе уязвимостей (CVE), собранной из разных источников, так и по базе уязвимостей (BDU) ФСТЭК России; Операционная система должна предоставлять возможность установки пароля на загрузчик для ограничения доступа к опциям загрузки; Операционная система должна предоставлять возможность блокировки виртуальных текстовых консолей. Комплекс средств защиты ОС должен обеспечивать выполнение программ в защищенной среде. В состав ОС должны быть включены программные интерпретаторы (php, perl, lua, python, nodejs) и веб-сервер (nginx), прошедшие испытания по выявлению уязвимостей и недекларированных возможностей в полном объеме в соответствии с Методикой выявления уязвимостей и недекларированных возможностей в программном обеспечении, утвержденной ФСТЭК России 25.12.2020 г.; Операционная система должна включать приложение для мониторинга ресурсов. Должно быть обеспечено централизованное управление конфигурациями прав доступа к утилите мониторинга температуры жесткого диска Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 4) Операционная система должна предоставлять единый графический модульный интерфейс для администрирования и настроек, а также предоставлять возможность удаленного администрирования по защищенным протоколам с помощью графических утилит (включая конфигурирование установленной системы через веб). Администратор должен иметь возможность назначить права доступа для пользователей к определенным модулям. В состав базовых сервисов должны входить: • настройка даты и времени; • управление системными службами; • просмотр системных журналов; • конфигурирование сетевых подключений и межсетевого экрана; • установка обновлений, в том числе для компьютеров без доступа в интернет; • управление выключением удаленного компьютера; • управление пользователями; • настройка пользовательских квот на использование ресурсов памяти, диска и внешних носителей. Операционная система должна реализовывать возможность хранения аутентификационной информации пользователей, полученной с использованием хеш-функций по ГОСТ Р 34.11-2012. Реализация функционала должна быть обеспечена как консольными, так и графическими утилитами; Операционная система должна обеспечивать возможность создания ssh-туннелей, использующих контроль целостности заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015; Операционная система должна предоставлять возможность авторизации по смарт-картам в консольном режиме; Операционная система должна предоставлять протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе; Операционная система должна предоставлять возможность разграничения доступа к подключаемым устройствам Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 5) Операционная система должна иметь возможность организации домена Samba-DC или интеграции с доменом Active Directory с поддержкой следующего функционала: • действовать в качестве первичного или вторичного контроллера домена; • аутентификация рабочих станций; • авторизация и предоставление ресурсов без дополнительного ввода пароля (Single Sign-On); • поддержка ролей и привилегий (назначение ролей группам); • групповые политики (GPO); Операционная система должна предоставлять возможность организации трастовых доменов Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 6) При работе в гетерогенной среде домена Active Directory (нативного или создаваемого с помощью проекта Samba) должны быть доступны, при использовании инструмента RSAT в среде Windows или с помощью собственного приложения, следующие политики для управления компьютерами и доменными пользователями, работающими на них: • Настройка установки программного обеспечения из репозитория. • Исполнение любых скриптов при включении/выключении компьютера или входе/выходе пользователя в систему. • Разрешение/Запрет на подключение класса съемных накопителей для компьютера или отдельных пользователей. • Управление ярлыками для компьютера или пользователей. • Централизованное управление конфигурациями сервисов systemd, включая интерфейс-терминала смарт-карт (openct), диспетчер авторизации (polkit), службы аудита безопасности (auditd). • Централизованное управление конфигурациями системных сервисов (CUPS, SSHD, NTP Chrony, Postfix MTA и postqueue, DNS, OpenLDAP, Rpcbind, SSSD, очередь заданий) и утилит определения прав доступа к модификации учетных записей, паролей, пользователей (включая создание индивидуальных временных каталогов) и групп, а также к утилитам su/sudo. • Централизованное управление конфигурациями прав доступа монтирования съемных накопителей, пользовательских файловых систем, подключения сетевых ресурсов по nfs. • Управление файлами и папками (создание, удаление, перемещение, копирование, предоставление общего доступа или скрытие). • Управление настройками приложений через ini-файлы. • Управление интервалом времени применения групповой политики. • Управление всеми политиками веб-браузеров Mozilla Firefox и Chromium. • Возможность принудительного выполнения политики на клиенте Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 7) Операционная система должна предоставлять возможность организации и настройки базовых сетевых сервисов и служб: • sshd; • DNS; • DHCP; • протокол аутентификации LDAP; • OpenVPN; • SMTP, POP3/IMAP (postfix, dovecot или эквивалент); • межсетевой экран; • проксирование HTTP- и FTP-запросов (squid или эквивалент); • резервное копирование (bacula или эквивалент); • сервер сетевой установки с веб-интерфейсом; • сервер обновлений с возможностью зеркалирования репозитория вендора ОС и создания служебных репозиториев используемого Заказчиком ПО; • защищенный сервер баз данных (PostgreSQL или эквивалент) с возможностью организации кластера из нескольких серверов, со встроенной реализацией функций round, trunc, date совместимой с Oracle DB; • веб-сервер; • FTP-сервер; • сервер мониторинга сетевых ресурсов с графическим интерфейсом (Zabbix, icinga2 или эквивалент); • сервер печати; • сервер групповой работы с веб-интерфейсом (SOGo или эквивалент); • сервер файлового обмена Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 8) Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - программное обеспечение (ПО) должно создавать и управлять резервными копиями виртуальных машин (ВМ), контейнеров и физических узлов, содержащие архивы файлов и образов; - ПО должно предоставлять интегрированный клиент для QEMU и LXC в виртуальной среде Proxmox; - ПО должно поддерживать резервное копирование на магнитную ленту и управление ленточными библиотеками; - ПО должно поддерживать дедупликацию, сжатие и аутентифицированое шифрование данных; - ПО должно использовать следующие алгоритмы сжатия данных lzo, gzip и zstd.; - ПО должно содержать в себе веб-интерфейс (RESTful API) управления со встроенной в него консолью, доступ должен осуществляться через системную аутентификацию Linux PAM. - ПО должно хранить данные резервных копий и предоставлять RESTful API для создания хранилищ данных и управления ими и другими ресурсами на стороне сервера; - ПО должно позволять с помощью API, предоставленного серверной частью, позволять клиенту резервного копирования получать доступ к сохранённым данным для создания и восстановления резервных копий файлов, а также для управления дисками и другими ресурсами на стороне сервера; - ПО должно использовать протокол TLS для обеспечения безопасности обмена данными между клиентской и серверной частями; - ПО должно использовать алгоритм AES-256 GCM при шифровании содержимого резервной копии на стороне клиента; - ПО должно позволять создавать хранилища данных с файловой системой форматов ext4, xfs.; - ПО должно содержать в себе набор инструментов, используемых для мониторинга и управления системой S.M.A.R.T. для локальных жёстких дисков, с возможностью отображения атрибутов S.M.A.R.T. из веб-интерфейса или при помощи командной строки; Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 9) Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - ПО должно идентифицировать каждое хранилище данных именем и указанием на каталог в файловой системе и связывать с каждым хранилищем параметры хранения, определяющие количество снимков резервных копий для каждого интервала времени: час, день, неделя, месяц, год; - ПО должно позволять создавать хранилища данных с возможностью выбора и настройки следующих параметров: название; путь к каталогу; количество резервных копий для хранения в этом хранилище; расписания периодического запуска удаления резервных копий и сборки мусора (удаления неиспользуемых блоков данных); - ПО должно позволять ограничить входящий (например, резервное копирование) и исходящий (например, восстановление) сетевой трафик из набора сетей, с возможностью настроить определенные периоды, в которые будут применяться ограничения; - ПО должно позволять создавать пользователей и управлять ими как из встроенного веб-интерфейса, так и с помощью командной строки, с возможностью создания/удаления/отключения учетных записей, просмотра списка пользователей с возможностью изменения любых свойств; - ПО должно позволять любому аутентифицированному пользователю генерировать API-токены и использовать их для настройки клиентов резервного копирования вместо прямого указания имени пользователя и пароля. API-токен должен отзываться в случае компрометации клиента и ограничивать разрешения для каждого клиента/токена в рамках разрешения пользователей. ПО должно создавать для токенов собственные записи ACL, где токены не могут делать больше, чем создавший их пользователь; Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 10) Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - ПО должно использовать систему управления разрешениями на основе ролей и путей, где роль содержит набор разрешенных действий, а путь представляет цель этих действий. По умолчанию разрешения созданным пользователям и API-токенам не должны предоставляться; - ПО должно предопределять следующий ряд ролей: нет привилегий (используется для запрета доступа); все привилегии; доступ только для чтения; все привилегии для хранилищ данных; просмотр настроек хранилищ и их содержимых, без возможности чтения фактических данных; просмотр содержимого хранилища, восстановление данных; создание и восстановление собственных резервных копий; создание, восстановление и удаление собственных резервных копий; все привилегии для удалённых серверов; просмотр настроек удалённых серверов; чтение данных с удалённых серверов; - ПО должно создавать, хранить и предоставлять следующую информацию о правах доступа: идентификатор ACL; включено или отключено; объект, на который установлено разрешение; пользователи/токены, для которых установлено разрешение; устанавливаемая роль. - ПО должно реализовывать возможность использования двухфакторной аутентификации с помощью веб-интерфейса тремя методами: TOTP (одноразовый пароль на основе времени) — для создания этого кода должен использоваться алгоритм одноразового пароля с учетом времени входа в систему (код меняется каждые 30 секунд); WebAuthn (веб-аутентификация) — реализуется с помощью различных устройств безопасности, таких как аппаратные ключи или доверенные платформенные модули (TPM). Для работы веб-аутентификации необходим сертификат HTTPS; Recovery Keys (одноразовые ключи восстановления) — список ключей, каждый из которых можно использовать только один раз. В каждый момент времени у пользователя может быть только один набор одноразовых ключей Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 11) Операционная система должна предоставлять возможность установления безопасных сетевых соединений по технологии VPN; Операционная система должна обеспечивать возможность создания VPN-туннелей, использующих контроль заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015; Операционная система должна реализовывать базовый функционал межсетевого экрана; Операционная система должна предоставлять возможность установки многоплатформенного брокера подключений для создания и управления виртуальными рабочими местами и приложениями (OpenUDS или аналог); Операционная система должна включать графическое приложение для мониторинга ресурсов и просмотра системных журналов; Операционная система должна предоставлять возможность одновременной работы пользователей в изолированных сеансах. Должны быть предусмотрены: • отдельное изолированное хранение данных аутентификации каждого пользователя системы таким образом, чтобы процессы аутентификации локального или сетевого пользователя не могли получить доступа к данным аутентификации и авторизации других пользователей системы; • поддержка изоляции временных пользовательских файлов Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 12) Операционная система должна включать автоматизированные средства изоляции приложений, чувствительных к сетевым атакам; Операционная система должна предоставлять упреждающие меры защиты и быть сконфигурирована с безопасными настройками по умолчанию; Операционная система должна предоставлять механизм управления фиксированными состояниями ключевых объектов безопасности системы, сохраняющий установленные права доступа к объектам файловой системы при обновлении пакетов; Операционная система должна обеспечивать поддержку шифрования по ГОСТ Р 34.11-2012 в OpenSSL, включая генерацию ключей и создание сертификатов; Операционная система должна предоставлять инструмент проверки контрольных сумм неизменяемых файлов установленных пакетов как при начальной установке, так и после получения обновлений. Вендор должен обеспечивать доступ к обновлениям и контрольным суммам неизменяемых файлов пакетов в них; Подсистема контроля целостности операционной системы должна поддерживать технологии IMA и EVM; Операционная система должна предоставлять возможность запрета запуска выбранных интерпретаторов в интерактивном режиме, отключения возможности удаления открытых файлов, а также установки запрета бита исполнения (SUID), распространяемого на дочерние процессы Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 13) Операционная система должна поддерживать файловые системы ext2, ext3, ext4, btrfs для чтения/записи и установки, iso9660, xfs, fat16, fat32, ntfs.; Операционная система должна поддерживать сетевые протоколы SMB, NFS, FTP, NTP, HTTP(S); Операционная система должна предоставлять возможность доустановки необходимого программного обеспечения с диска или из репозитория, а также установки обновлений. Система должна обеспечить автоматическую проверку зависимостей (apt или эквивалент), а также возможность комплексного обновления системы с отдельным процессом установки ядра ядра с помощью графических утилит; Исходные коды, обновления, инструменты для сборки серверной ОС должны находиться в том же репозитории (хранилище), где хранятся исходные коды, обновления и инструменты для ОС рабочих станций; Операционная система должна предоставлять единую систему для установки прикладного программного обеспечения в системе (eepm или аналог). Также должна быть обеспечена возможность установки сторонних приложений в форматах deb, tgz, tbz, tbz2, pkg.gz.; Операционная система должна поддерживать корневые сертификаты Минцифры России. В составе дистрибутива должен присутствовать пакет с отечественными корневыми сертификатами шифрования; Операционная система должна поддерживать корневые сертификаты Российского центра сертификации ТЦИ, предоставляемые соответствующим пакетом из состава ОС Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 1) В средстве виртуализации должны быть реализованы следующие функции безопасности: • идентификация и аутентификация субъектов доступа и объектов доступа, в том числе администраторов управления средствами виртуализации; • управление доступом субъектов доступа к объектам, в том числе внутри виртуальных машин; • регистрация событий безопасности; • управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуальной инфраструктуры, а также по ее периметру; • управление перемещением виртуальных машин (контейнеров) и обрабатываемых на них данных; • контроль целостности виртуальной инфраструктуры и ее конфигураций; • резервное копирование данных, резервирование технических средств, программного обеспечения, а также внутренних каналов связи внутри виртуальной инфраструктуры; • сегментирование виртуальной инфраструктуры для обработки информации отдельным пользователем и (или) группой пользователей; В состав дистрибутива операционной системы должен входить следующий комплекс программных компонент для построения виртуальной инфраструктуры: • гипервизор KVM (или эквивалент); • эмулятор аппаратного обеспечения различных платформ QEMU (или эквивалент); • набор инструментов, предоставляющий единый API для технологий виртуализации (libvirt или эквивалент); • гиперконвергентная система управления средой виртуализации с централизованным управлением физическими и виртуальными ресурсами; • система резервного копирования, интегрированная в систему управления средой виртуализации Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 2) В состав дистрибутива операционной системы для обеспечения корректного функционирования современных средств виртуализации должны входить следующие компоненты: • ядро LTS не ниже 6.1.114; • systemd версии не ниже 249.17; • qemu версии не ниже 8.2; • libvirt версии не ниже 9.7; • corosync версии не ниже 3.1.8; • pacemaker версии не ниже 2.1.7; • keepalived версии не ниже 2.2.8; • Ceph версии не ниже 17.2; • Gluster версии не ниже 9.3. • Требование к версионности компонентов аргументируется наличием необходимого функционала и закрытыми уязвимостями в данных версиях; Система управления средой виртуализации должна обладать возможностью высокого масштабирования и поддерживать создание и управление виртуальной инфраструктурой со следующими параметрами лимитных значений: • максимальное количество физических серверов (узлов), поддерживаемых в составе кластера высокой доступности — не менее 128; • максимальное количество логических процессоров на хост-сервер — не менее 8192; • максимальный объем ОЗУ памяти на хост-сервер — не менее 32 ТБ; • поддержка в ВМ не менее 240 vCPU; • поддержка в ВМ ОЗУ не менее 4 TБ оперативной памяти; • поддержка объема виртуального диска для одной виртуальной машины не менее 64 TБ; • поддержка в ВМ виртуальных сетевых интерфейсов NICs для одной виртуальной машины не менее 10; • поддержка в ВМ виртуальных адаптеров SATA для одной виртуальной машины не менее 6 Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 3) Система управления средой виртуализации должна предоставлять возможность управления через интерфейс CLI, графический веб-интерфейс, а также интеграцию со сторонним программным обеспечением с помощью REST API; Система управления средой виртуализации должна поддерживать технологию Wake-on-LAN; Система управления средой виртуализации должна поддерживать режим вложенной виртуализации; Система управления средой виртуализации должна обеспечивать создание виртуальных машин (ВМ), их образов и шаблонов для гостевых операционных систем аппаратных архитектур AArch64 (ARMv8) и x86-64; В составе системы управления средой виртуализации должны быть реализованы штатные графические средства мониторинга. Штатная система мониторинга, встроенная в систему управления виртуализации, должна предоставлять обзор в графическом интерфейсе для следующих ресурсов: • отображать объем всех ресурсов в соотношении к доступным (CPU, RAM, сеть, хранилище); • отображать количество всех виртуальных машин и контейнеров, а также количество запущенных и выключенных экземпляров; • отображать реквизиты объектов виртуальной инфраструктуры: IP-адрес, имя владельца и/или группы, имя хоста, ID (UID); • иметь цветовую дифференциацию объектов в зависимости их статусов и объёмов нагрузки; • обеспечивать возможность подключения дополнительных модулей мониторинга Zabbix, Grafana, Prometheus для получения детализированный информации по развёрнутой виртуальной инфраструктуре, включая низкоуровневые интерфейсы; В графическом интерфейсе системы управления средой виртуализации должны быть представлены графические инструменты подключения серверов статистики InfluxDB и Graphite Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 4) Система управления средой виртуализации должна включать в себя набор инструментов, с отображением их в веб-интерфейсе и в командной строке, для мониторинга и управления S.M.A.R.T. системой для локальных жестких дисков. Набор инструментов для мониторинга и управления S.M.A.R.T. системой должен быть активен и включён по умолчанию и должен выполнять следующие функции: • сканирование дисков каждые 30 минут на наличие ошибок и предупреждений; • отправка сообщений электронной почты пользователю root при обнаружении проблем. • При повторе ошибок узел должен отсылать электронное сообщение каждые 24 часа; Система управления средой виртуализации иметь штатные инструменты регистрации событий и обеспечивать возможность просмотра истории событий и системных журналов каждого отдельного узла кластера и каждой ВМ в веб-интерфейсе самой системы управления средой виртуализации, включая в себя выполнение заданий резервного копирования или восстановления. Журнал событий должен быть оснащен инструментами фильтрации по дате и времени события, по типу и ID ресурса, инициатору события, типу события, статусу события; Система управления средой виртуализации должна поддерживать следующие технологии оптимизации памяти: • Thin Provisioning; • KSM; • Memory balooning; • NUMA. Система управления средой виртуализации должна предоставлять возможность создания общего хранилища со следующими функциональными возможностями: • миграция ВМ в реальном масштабе времени; • плавное расширение пространства хранения с множеством узлов; • централизованное резервное копирование; • многоуровневое кэширование данных; • централизованное управление хранением Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 5) Система управления средой виртуализации должна поддерживать следующие методы организации хранения данных: • ZFS (локальный/over iSCSI); • Каталог; • BTRFS; • NFS; • CIFS; • GlusterFS; • Ceph версий 15 Octopus и 16 Pacific; • OCFS2; • LVM; • LVM-thin; • iSCSI; • Ceph/RBD. В системе управления средой виртуализацией должна быть реализована возможность хранить образы ВМ на нескольких локальных хранилищах или в общем хранилище; Для хранения всех файлов конфигурации, связанных с системой управления виртуализацией, в системе управления виртуализацией должна быть реализована кластерная файловая система, управляемая базой данных, для хранения файлов конфигурации, реплицируемых в реальном времени на все узлы кластера с помощью corosync. Такая система хранения должна позволять реализовать: • бесшовную репликацию всей конфигурации на все узлы в реальном времени; • строгие проверки согласованности, чтобы избежать дублирования идентификаторов виртуальных машин; • режим «только для чтения», когда узел теряет кворум; • автоматическое обновление конфигурации кластера corosync для всех узлов; • механизм распределенной блокировки. В системе управления виртуализацией должна быть обеспечена поддержка подключения к СХД по протоколам FC/iSCSI (поддержка блочного доступа к данным по сети SAN) Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 6) Хранилище в системе управления виртуализацией должно поддерживать несколько типов содержимого: образы виртуальных дисков, ISO-образы компакт-дисков, шаблоны ВМ и контейнеров, корневые каталоги контейнеров. Настройка должна быть доступна с помощью графического интерфейса; В системе управления виртуализацией должна быть предусмотрена возможность выбора назначения создаваемого хранилища по типу файловой системы и контенту. Настройка должна быть доступна с помощью графического интерфейса; В системе управления средой виртуализации должна быть предусмотрена возможность управления ограничением дисковой пропускной способностью. Настройка должна быть доступна с помощью графического интерфейс; В системе управления средой виртуализацией должны быть реализованы штатные инструменты выбора версии, развертывания, управления и мониторинга Ceph и его отдельных компонент: сервер метаданных (MDS), OSD, клиентов Ceph, пулов Ceph; Система управления средой виртуализации должна обеспечивать возможность добавления дополнительных узлов в кластер после его создания. При добавлении узлов в кластер в системе управления виртуализацией должна автоматически обновляться и добавляться информация об узлах в файле настройки кластера; Система управления средой виртуализации должна позволять централизованное управление с любого узла дата-центра всеми ресурсами внутри ее контура: • дата-центр; • кластеры; • узлы; • сети; • хранилища; • пулы ресурсов: виртуальные машины, контейнеры, шаблоны; • резервные копии; • пользователи и разрешения Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 7) Для обеспечения высокой надежности и отказоустойчивости система управления средой виртуализации не должна требовать отдельной установки менеджера управления на отдельную физическую или виртуальную машину; Для обеспечения согласованного состояния всех узлов кластера система управления средой виртуализации должна поддерживать режим работы «кворум»; В графическом интерфейсе системы управления средой виртуализации должно отражаться состояние кворума, а также проверка последнего временного штампа жизнеспособности (heartbeat timestamp); Система управления средой виртуализации должна поддерживать режим работы Qdevice и гарантировать кворум с четным числом узлов; В системе управления средой виртуализации для всех узлов кластера должен использоваться диспетчер отказоустойчивости — служба, управляющая политиками отказоустойчивости и высокой доступности среды виртуализации, которые описывают сценарий действий для физических и виртуальных ресурсов дата-центра; Для обеспечения корректной работы в режиме отказоустойчивости и диспетчера отказоустойчивости в системе управления средой виртуализации должен быть реализован планировщик ресурсов с функцией автоматического анализа утилизации ресурсов и распределения ресурсов согласно заданным политикам Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 8) Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать и применять следующие политики выключения для узлов: • Conditional — режим автоматически определяет, требуется ли выключение или перезагрузка, и соответствующим образом меняет поведение вычислительного узла. • Failover — режим гарантирует, что все службы будут остановлены, но они также будут восстановлены, если текущий узел не будет подключен к сети в ближайшее время. • Freeze — режим гарантирует, что все службы будут остановлены и заморожены и не будут восстановлены до тех пор, пока текущий узел снова не будет подключен к сети. • Migrate — режим инициирует миграцию всех служб, находящихся в данный момент на том узле, на котором запланировано выключение. • Настройка режимов должна быть доступна с помощью графического интерфейса Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 9) Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать объединение узлов в группы отказоустойчивости для возможности восстановления виртуальных сервисов только на определенных узлах. Настройки таких групп должны обеспечивать указание приоритизации для восстановления виртуальных ресурсов (ВМ или контейнер). Настройки должны быть доступны с помощью графического интерфейса; Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать индивидуальные политики отказоустойчивости и применять их к выделенным виртуальным ресурсам (ВМ или контейнер): • ID ресурса — номер ВМ или контейнера; • состояние ресурса при восстановлении — запущен, восстановлен, не требует восстановления, отключен; • количество попыток восстановления; • количество попыток перемещения; • группы отказоустойчивости. • Настройки должны быть доступны с помощью графического интерфейса. В системе управления средой виртуализации должен быть реализован «режим обслуживания» с функцией автоматической миграции виртуальных машин; Система управления средой виртуализации должна позволять создавать отказоустойчивую мультикластерную инфраструктуру; Система управления средой виртуализации должна позволять создавать отказоустойчивую геораспределенную инфраструктуру; Система управления средой виртуализации должна позволять настройку сетевых соединений как децентрализованно на уровне узла, так и централизованно на уровне дата-центра Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 10) В системе управления виртуализацией должны быть реализованы штатные графические инструменты создания и управления сетью со следующими функциями: • создание Linux/OVS Bridge соединений; • создание Linux/OVS Bond соединений; • создание Linux/OVS VLAN соединений; • поддержка алиаса для сетевых соединений; • создание виртуальных разделённых сетевых зон и управление ими; • создание виртуальных сетевых мостов и управление подсетями; • поддержка протоколов IPv4/IPv6; • поддержка виртуальных коммутаторов с технологией VXLAN (Virtual Extensible LAN); • поддержка трансляции сетевых адресов; • поддержка Jumbo frames до 9000; • поддержка маркировки QoS: 802.1p, DSCP; • поддержка проброса PCI устройств (SR-IOV); • поддержка протокола LLDP (Link Layer Discovery Protocol); • поддержка сетевых адаптеров не менее 10/40/100 Гб/сек. Система управления средой виртуализации должна позволять использование ВМ и контейнерами как одного моста, так и позволять создание нескольких мостов для разделения сетевых доменов (до 4094 мостов); Система управления средой виртуализации должна поддерживать объединение сетевых адаптеров/агрегацию каналов (bonding): циклическая передача (balance-rr), активное резервное копирование (active-backup), XOR (balance-xor), броадкаст (broadcast), IEEE 802.3ad (802.3ad) (LACP), режим адаптивной балансировки нагрузки при передаче (balance-tlb), режим адаптивной балансировки нагрузки (balance-alb); Сетевые настройки системы управления виртуализации должны позволять использование тегирования для VLAN. Настройка должна быть доступна с помощью графического интерфейса Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 11) Система управления средой виртуализации должна быть оснащена штатным фаерволом. Штатный фаервол должен группировать сеть на логические зоны по параметрам: • трафик от/к узлу кластера; • трафик от/к конкретной ВМ. Сетевые настройки (в том числе и в графическом интерфейсе системы) должны поддерживать возможность назначения правил фаервола для входящего и/или исходящего трафика: • для всего дата-центра; • для конкретного узла в кластере; • для конкретной ВМ. Настройки фаервола системы управления средой виртуализации должны позволять создавать секретные группы или группы безопасности. Настройки должны быть доступны с помощью графического интерфейса; Система управления средой виртуализации должна быть оснащена штатным сервером аутентификации; Система управления средой виртуализации должна поддерживать возможность интеграции внешних серверов аутентификации (Active Directory, LDAP, Linux PAM, OpenID) и обеспечивать синхронизацию с ними. Настройка должна быть доступна и в графическом интерфейсе; Система управления средой виртуализации должна поддерживать двухфакторную аутентификацию с использованием следующих методов: • TOTP; • Yubikey OTP; • WebAuthn; • одноразовые ключи восстановления. • Настройка должна быть доступна с помощью графического интерфейса. Система управления средой виртуализации должна определять многоуровневый доступ, используя основанное на ролях управление пользователями и разрешениями для всех объектов (ВМ, хранилищ, узлов и т. д.). Настройки должны быть доступны с помощью графического интерфейса Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 12) Система управления средой виртуализации должна иметь по умолчанию не менее 12 предопределенных ролей: • Administrator?—?имеет все привилегии; • NoAccess?—?нет привилегий (используется для запрета доступа); • Admin?—?все привилегии, кроме прав на изменение настроек системы; • Auditor?—?доступ только для чтения; • DatastoreAdmin?—?создание и выделение места для резервного копирования и шаблонов; • DatastoreUser?—?выделение места для резервной копии и просмотр хранилища; • PoolAdmin?—?выделение пулов; • SysAdmin?—?ACL пользователя, аудит, системная консоль и системные журналы; • TemplateUser?—?просмотр и клонирование шаблонов; • UserAdmin?—?администрирование пользователей; • VMAdmin?—?управление ВМ; • VMUser?—?просмотр, резервное копирование, настройка CDROM, консоль ВМ, управление питанием ВМ. Система управления средой виртуализации должна быть оснащена штатным конструктором ролей и обеспечивать возможность создание новых ролей. Настройка должна быть доступна с помощью графического интерфейса; Для оптимизации контроля доступа система управления средой виртуализации должна поддерживать группировку ресурсов (ВМ и хранилищ) в отдельные пулы с возможностью наделения индивидуальными разрешениями. Настройка должна быть доступна с помощью графического интерфейса Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 13) Система управления средой виртуализации должна поддерживать возможность создавать виртуальную машину как из шаблона, так и без него. Настройка должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать возможность создавать виртуальную машину с несколькими дисками. Настройка должна быть доступна с помощью графического интерфейса; Для обеспечения высокой производительности система управления средой виртуализации должна поддерживать возможность задавать настройки многопоточности и ограничения пропускной способности при создании виртуальной машины. Настройка должна быть доступна с помощью графического интерфейса; Для обеспечения высокой производительности система управления средой виртуализации должна поддерживать горячее добавление ресурсов vCPU, vRAM, vDisk, USB, vNIC без остановки или перезагрузки ВМ. Настройка должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать как оффлайн-миграцию ВМ, так и живую миграцию Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 14) Система управления средой виртуализации должна поддерживать следующие действия над ВМ и режимы работы ВМ, в том числе и в графическом интерфейсе: • запуск; • останов; • пауза; • гибернация; • перезагрузка; • сброс. Система управления средой виртуализации должна поддерживать доступ к консоли ВМ и манипуляции в ВМ как в отдельном сеансе, так и в веб-интерфейсе самой системы управления средой виртуализации; Система управления средой виртуализации должна поддерживать различные варианты копирования ВМ: • полный клон; • связанный клон; • моментальный снимок. Система управления средой виртуализации должна поддерживать следующие протоколы для доступа к консоли ВМ: VNC, SPICE, RDP; Система управления средой виртуализации должна поддерживать массовые операции над ВМ: миграция, старт, выключение. Опция должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать миграцию и импорт из других платформ и гипервизоров: P2V, V2V (Vmware, Hyper-V, KVM, oVirt) с использованием штатных инструментов самой системы управления средой виртуализации Значение характеристики не может изменяться участником закупки Требования к контейнеризации (ч.1) Операционная система в соответствии с документом «Требования по безопасности информации к средствам контейнеризации» (ФСТЭК России, 2022, приказ № 118) по 4-му классу защиты должна реализовывать следующие функции безопасности: • изоляция контейнеров; • выявление уязвимостей в образах контейнеров; • проверка корректности конфигурации контейнеров; • контроль целостности контейнеров и их образов; • регистрация событий безопасности; • управление доступом; • идентификация и аутентификация пользователей; • централизованное управление образами контейнеров и контейнерами в средстве контейнеризации. Операционная система должна предоставлять сертифицированные средства контейнеризации (kubernetes или эквивалент, podman или эквивалент) имеющие возможность запуска от непривилегированного пользователя без необходимости запуска какого-либо демона/службы; Все инструменты, в том числе контейнеры, должны входить в состав дистрибутива операционной системы и устанавливаться без обращения по сети к внешним источникам. Набор контейнеров должен включать базовые контейнеры, в том числе и distroless-образ и набор контейнеров для разворачивания кластера kubernetes Значение характеристики не может изменяться участником закупки Требования к контейнеризации (ч.2) Средства управления образами контейнеров и контейнерами (оркестратор или аналог) должны обеспечивать следующие функции: • создание, модификацию, хранение, получение и удаление образов контейнеров в информационной (автоматизированной) системе; • обновление средства контейнеризации и образов контейнеров из реестра вендора; • чтение, удаление записей о событиях безопасности, формирование отчетов с учетом заданных критериев отбора, выгрузку (экспорт) данных из журнала событий безопасности средства контейнеризации; • анализ возникающих событий безопасности в целях выявления инцидентов безопасности. Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции изоляции контейнеров: • изоляция пространств идентификаторов процессов; • изоляция пространств имен для межпроцессного взаимодействия; • изоляция пространств имен для пользователей и групп; • изоляция пространств имен хостов и доменов; • изоляция сетевых пространств имен; • изоляция пространств имен для иерархии каталогов. В дистрибутиве операционной системы должна быть реализована ролевая модель управления доступом: разработчик образов контейнеров, администратор безопасности средств контейнеризации, администратор информационной (автоматизированной) системы Значение характеристики не может изменяться участником закупки Требования к контейнеризации (ч.3) Дистрибутив операционной системы должен реализовывать следующие требования к функциям идентификации и аутентификации пользователей: • аутентификация пользователей по паролю; • пароль пользователя должен устанавливаться администратором безопасности средства контейнеризации; • средство контейнеризации должно обеспечивать возможность смены установленного администратором безопасности средства контейнеризации пароля пользователя после его первичной аутентификации; • при попытке ввода неправильного значения пароля пользователя должно выводиться соответствующее сообщение с приглашением ввести правильный пароль еще раз; • при исчерпании установленного максимального количества неуспешных попыток ввода неправильного пароля учетная запись пользователя средства контейнеризации должна быть заблокирована; • разблокировка учетной записи пользователя средства контейнеризации должна осуществляться администратором безопасности средства контейнеризации; • защита пароля пользователя должна обеспечиваться при его вводе за счет отображения вводимых символов условными знаками; • средство контейнеризации должно обеспечивать хранение аутентификационной информации пользователя средства контейнеризации в защищенном формате или в защищенном хранилище; • средство контейнеризации не должно запускать процессы в хостовой операционной системе, обладающие привилегиями администратора информационной (автоматизированной) системы и администратора безопасности информационной (автоматизированной) системы; • пароль пользователя средства контейнеризации должен содержать не менее 8 символов при алфавите пароля не менее 70 символов. Максимальное количество неуспешных попыток аутентификации (ввода неправильного пароля) до блокировки — 4. • указанные условия должны быть преднастроены в дистрибутиве операционной системы в рамках парольной политики по умолчанию Значение характеристики не может изменяться участником закупки Требования к контейнеризации (ч.4) Дистрибутив операционной системы должен реализовывать специальный механизм по выявлению уязвимостей в образах контейнеров с учетом следующих требований: • выявление известных уязвимостей при создании, первичном запуске и хранении образов контейнеров, самостоятельно или во взаимодействии с сертифицированным средством контроля и анализа защищенности на основе сведений, содержащихся в банке данных угроз безопасности информации БДУ ФСТЭК России (https://bdu.fstec.ru/), а также в иных источниках, содержащих сведения об известных уязвимостях; • оповещение о выявленных уязвимостях в образах контейнеров разработчика образов контейнеров и администратора информационной (автоматизированной) системы; • средство контейнеризации должно обеспечивать запрет создания образов контейнеров, содержащих известные уязвимости критического и высокого уровня опасности (уровень опасности определяется по значению (V) CVSS в CVE). Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции управления конфигурацией: • возможность ограничения прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование периферийных устройств, устройств хранения данных и съемных машинных носителей информации (блочных устройств), входящих в состав информационной (автоматизированной) системы; • возможность ограничения прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование вычислительных ресурсов (оперативной памяти, операций ввода-вывода за период времени) хостовой операционной системы; • запрет возможности монтирования средством контейнеризации корневой файловой системы хостовой операционной системы (за исключением режима «только для чтения») Значение характеристики не может изменяться участником закупки Требования к контейнеризации (ч.5) Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции контроля целостности контейнеров и их образов: • контролировать самостоятельно или с применением средств контроля целостности хостовой операционной системы и иных сертифицированных средств защиты информации целостность образов контейнеров и исполняемых файлов контейнеров; • информировать администратора безопасности информационной (автоматизированной) системы и администратора безопасности средства контейнеризации о нарушении целостности объектов контроля; • контролировать целостность параметров настройки средства контейнеризации; • контролировать целостность сведений о событиях безопасности и обеспечивать формирование отчетов самостоятельно или во взаимодействии с хостовой операционной системой; • контролировать целостность образов контейнеров и параметров настройки средства контейнеризации при первичном запуске и далее периодически за счет применения электронной подписи самостоятельно или во взаимодействии с хостовой операционной системой; • блокировать запуск образа контейнера при нарушении его целостности. Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции регистрации событий безопасности: • обеспечивать регистрацию событий, относящихся к инцидентам безопасности средства контейнеризации, связанных с попытками осуществления несанкционированного доступа к средству контейнеризации; • оповещать администратора безопасности средства контейнеризации и администратора безопасности информационной (автоматизированной) системы об инцидентах безопасности; • выполнять действия, являющиеся реакцией на инциденты безопасности; • осуществлять сбор и хранение записей в журнале событий безопасности Значение характеристики не может изменяться участником закупки Требования к контейнеризации (ч.6) Средства контейнеризации дистрибутива операционной системы должны соответствовать следующим требованиям к регистрации событий безопасности: • для регистрируемых событий безопасности в каждой записи журнала событий безопасности должны регистрироваться номер (уникальный идентификатор) события, дата, время, тип события безопасности; • записи журнала событий безопасности должны представляться в структурированном виде и содержать время события безопасности, взятое из хостовой операционной системы; • должна быть обеспечена запись событий безопасности контейнеров в журнал событий безопасности информационной (автоматизированной) системы с указанием идентификатора контейнера; • журнал событий безопасности средства контейнеризации должен быть доступен только для чтения. При исчерпании области памяти, отведенной под журнал событий безопасности средства контейнеризации, должно осуществляться его архивирование с последующей очисткой; • регистрации подлежат следующие события безопасности: a. неуспешные попытки аутентификации пользователей средства контейнеризации; b. создание, модификация и удаление образов контейнеров; c. получение доступа к образам контейнеров; d. запуск и остановка контейнеров с указанием причины остановки; e. изменение ролевой модели; f. модификация запускаемых контейнеров; g. выявление известных уязвимостей в образах контейнеров и некорректности конфигурации; h. факты нарушения целостности объектов контроля. • должна обеспечиваться запись событий безопасности контейнеров в журнал событий безопасности с указанием идентификатора пользователя хостовой операционной системы, от имени которого был запущен контейнер Значение характеристики не может изменяться участником закупки Нефункциональные требования Разработчик обязан оказывать гарантийную вендорскую поддержку продукта (оперативный выпуск обновлений по безопасности); Разработчик обязан оказывать техническую поддержку пользователям на условиях SLA в течение первого года использования. Для критических инцидентов должно быть обеспечено время реакции не более 8 часов в период с 9:00 до 19:00 в рабочие дни; Система должна быть основана на программном обеспечении с открытым исходным кодом Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки - Класс программ для электронных вычислительных машин и баз данных - (02.09) Операционные системы общего назначения - - Значение характеристики не может изменяться участником закупки - Способ предоставления - Экземпляр на материальном носителе - - Значение характеристики не может изменяться участником закупки - Общие требования - Программное обеспечение должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных Минкомсвязи РФ по классам «Операционные системы общего назначения», «Средства виртуализации», «Серверное и связующее программное обеспечение», «Средства управления базами данных», «Системы контейнеризации и контейнеры», «Средства защиты от несанкционированного доступа к информации»; Операционная система должна соответствовать требованиям документов: «Требования безопасности информации к операционным системам» (ФСТЭК России, 2016) и «Профиль защиты операционных систем типа «А» четвертого класса защиты ИТ.ОС.А4.ПЗ» (ФСТЭК России, 2017) ; «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» не ниже четвертого уровня доверия (приказ ФСТЭК России № 76 от 2 июня 2020 г.); «Требования по безопасности информации к средствам контейнеризации» (приказ ФСТЭК России № 118, 2022,) не ниже 4 класса защиты; «Требования по безопасности информации к средствам виртуализации» (приказ ФСТЭК России, № 187, 2022 г.) не ниже 4 класса защиты; «Требования по безопасности информации к системам управления базами данных» (приказ ФСТЭК России № 64, 2023 г.) не ниже 4 класса защиты; В Формуляре ОС должны быть указаны интерпретаторы, веб сервера и сервера приложений, проверенные согласно документу: «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении», утверждена ФСТЭК России 25.12.2020 г.; Разработчик должен иметь собственную инфраструктуру разработки полного цикла, зарегистрированную и находящуюся на территории РФ, в исключительной юрисдикции РФ; Наличие в России локализованной сервисной и/или технической поддержки - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч.1) - Операционная система должна устанавливаться и функционировать на компьютерах с архитектурами x86_64 (64-разрядный процессор Intel или AMD), aarch64 («Байкал», Rockchip 3588) и «Эльбрус» (процессоры 8С, 1С+, 8СВ, 2С3, 12С, 16С) должны быть отдельные образы в сертифицированном исполнении для каждой архитектуры. Требования перечисленные в данном документе относятся к архитектуре x86_64 и могут отличатся от требований к другим архитектурам. Операционная система должна поддерживать режимы установки и загрузки Legacy/CSM, UEFI (с включенным механизмом SecureBoot), а также средствами BMC/IPMI (если поддерживается оборудованием). Операционная система должна иметь в составе ядро не ниже 6.12 (LTS) для обеспечения корректного функционирования современных средств вычислительной техники. Система должна пре доставлять графические утилиты для установки, удаления и обновления ядра, включая модули, а также для выбора ядра по умолчанию. Операционная система должна обеспечивать поддержку нескольких видеокарт (работа на нескольких мониторах). Операционная система должна обладать русифицированным интерфейсом, а также предоставлять русскоязычную документацию. Операционная система должна иметь возможность установки с DVD-диска и USB-накопителя. Операционная система должна предоставлять варианты сетевой установки: PXE/TFTP (для режима Legacy/CSM-загрузки), HTTPClient (для спецификации UEFI 2.5 и выше), iPXE Операционная система должна предоставлять возможность организации сервера сетевой загрузки. Операционная система должна предоставлять возможность установки на оборудование без графической подсистемы с локального накопителя, а также установки с использованием сервера сетевой установки по протоколу VNC - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 2) - Носитель с дистрибутивом ОС должен предусматривать вариант загрузки для проведения работ по восстановлению системы, включая проверку сохранности содержимого файловой системы и проверку контрольных сумм неизменяемых файлов установленных пакетов, диагностику конфигурации аппаратного обеспечения, изменение таблицы и размеров разделов, изменение параметров файловых систем, восстановление удаленных разделов и файлов, проведение резервного копирования, очистку остаточной информации на разделах и дисках; Операционная система должна иметь возможность установки на программный RAID-массив, размещения разделов в томах LVM и использования маскирования (кодирования) разделов с парольным доступом; Операционная система должна обеспечивать возможность создания точек восстановления (снапшотов) для последующего возвращения системы к исходному состоянию в случае сбоя; Инсталлятор дистрибутива должен предусматривать возможность предварительной (OEM) установки, позволяющей при первом запуске пользователем после установки выбрать язык, принять лицензионное соглашение, настроить дату/время, настроить сеть, задать пароль root, создать системного пользователя; Операционная система должна предоставлять независимый выбор основных и дополнительных приложений в момент установки: серверные приложения (dhcp, dns,ftp, http, почтовый сервер, сервер резервного копирования, сервер печати, сервер сетевой установки), сканер обнаружения уязвимостей, сервер сертифицированной СУБД, сервер управления конфигурациями, сервер виртуальных рабочих столов, средства управления контейнеризацией, средства управления виртуализацией - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 3) - Операционная система после установки должна предоставлять пользователю рабочую среду, включающую системное ПО, сетевые службы и сервисы, драйвера устройств, утилиты администрирования, базовый набор приложений; Если установлена графическая среда, операционная система должна предоставлять графическое средство настройки многопользовательского режима, позволяющего обеспечить одновременную работу нескольких пользователей на одном компьютере при наличии отдельной видеокарты, клавиатуры и мыши для каждого пользователя; Операционная система должна предоставлять инструмент для поиска уязвимостей в файлах конфигурации, файловых системах, используемых пакетах ОС (включая программные зависимости), образах контейнеров и git-репозиториях. Анализ уязвимостей должен осуществляться как по вендорской базе уязвимостей (CVE), собранной из разных источников, так и по базе уязвимостей (BDU) ФСТЭК России; Операционная система должна предоставлять возможность установки пароля на загрузчик для ограничения доступа к опциям загрузки; Операционная система должна предоставлять возможность блокировки виртуальных текстовых консолей. Комплекс средств защиты ОС должен обеспечивать выполнение программ в защищенной среде. В состав ОС должны быть включены программные интерпретаторы (php, perl, lua, python, nodejs) и веб-сервер (nginx), прошедшие испытания по выявлению уязвимостей и недекларированных возможностей в полном объеме в соответствии с Методикой выявления уязвимостей и недекларированных возможностей в программном обеспечении, утвержденной ФСТЭК России 25.12.2020 г.; Операционная система должна включать приложение для мониторинга ресурсов. Должно быть обеспечено централизованное управление конфигурациями прав доступа к утилите мониторинга температуры жесткого диска - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 4) - Операционная система должна предоставлять единый графический модульный интерфейс для администрирования и настроек, а также предоставлять возможность удаленного администрирования по защищенным протоколам с помощью графических утилит (включая конфигурирование установленной системы через веб). Администратор должен иметь возможность назначить права доступа для пользователей к определенным модулям. В состав базовых сервисов должны входить: • настройка даты и времени; • управление системными службами; • просмотр системных журналов; • конфигурирование сетевых подключений и межсетевого экрана; • установка обновлений, в том числе для компьютеров без доступа в интернет; • управление выключением удаленного компьютера; • управление пользователями; • настройка пользовательских квот на использование ресурсов памяти, диска и внешних носителей. Операционная система должна реализовывать возможность хранения аутентификационной информации пользователей, полученной с использованием хеш-функций по ГОСТ Р 34.11-2012. Реализация функционала должна быть обеспечена как консольными, так и графическими утилитами; Операционная система должна обеспечивать возможность создания ssh-туннелей, использующих контроль целостности заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015; Операционная система должна предоставлять возможность авторизации по смарт-картам в консольном режиме; Операционная система должна предоставлять протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе; Операционная система должна предоставлять возможность разграничения доступа к подключаемым устройствам - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 5) - Операционная система должна иметь возможность организации домена Samba-DC или интеграции с доменом Active Directory с поддержкой следующего функционала: • действовать в качестве первичного или вторичного контроллера домена; • аутентификация рабочих станций; • авторизация и предоставление ресурсов без дополнительного ввода пароля (Single Sign-On); • поддержка ролей и привилегий (назначение ролей группам); • групповые политики (GPO); Операционная система должна предоставлять возможность организации трастовых доменов - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 6) - При работе в гетерогенной среде домена Active Directory (нативного или создаваемого с помощью проекта Samba) должны быть доступны, при использовании инструмента RSAT в среде Windows или с помощью собственного приложения, следующие политики для управления компьютерами и доменными пользователями, работающими на них: • Настройка установки программного обеспечения из репозитория. • Исполнение любых скриптов при включении/выключении компьютера или входе/выходе пользователя в систему. • Разрешение/Запрет на подключение класса съемных накопителей для компьютера или отдельных пользователей. • Управление ярлыками для компьютера или пользователей. • Централизованное управление конфигурациями сервисов systemd, включая интерфейс-терминала смарт-карт (openct), диспетчер авторизации (polkit), службы аудита безопасности (auditd). • Централизованное управление конфигурациями системных сервисов (CUPS, SSHD, NTP Chrony, Postfix MTA и postqueue, DNS, OpenLDAP, Rpcbind, SSSD, очередь заданий) и утилит определения прав доступа к модификации учетных записей, паролей, пользователей (включая создание индивидуальных временных каталогов) и групп, а также к утилитам su/sudo. • Централизованное управление конфигурациями прав доступа монтирования съемных накопителей, пользовательских файловых систем, подключения сетевых ресурсов по nfs. • Управление файлами и папками (создание, удаление, перемещение, копирование, предоставление общего доступа или скрытие). • Управление настройками приложений через ini-файлы. • Управление интервалом времени применения групповой политики. • Управление всеми политиками веб-браузеров Mozilla Firefox и Chromium. • Возможность принудительного выполнения политики на клиенте - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 7) - Операционная система должна предоставлять возможность организации и настройки базовых сетевых сервисов и служб: • sshd; • DNS; • DHCP; • протокол аутентификации LDAP; • OpenVPN; • SMTP, POP3/IMAP (postfix, dovecot или эквивалент); • межсетевой экран; • проксирование HTTP- и FTP-запросов (squid или эквивалент); • резервное копирование (bacula или эквивалент); • сервер сетевой установки с веб-интерфейсом; • сервер обновлений с возможностью зеркалирования репозитория вендора ОС и создания служебных репозиториев используемого Заказчиком ПО; • защищенный сервер баз данных (PostgreSQL или эквивалент) с возможностью организации кластера из нескольких серверов, со встроенной реализацией функций round, trunc, date совместимой с Oracle DB; • веб-сервер; • FTP-сервер; • сервер мониторинга сетевых ресурсов с графическим интерфейсом (Zabbix, icinga2 или эквивалент); • сервер печати; • сервер групповой работы с веб-интерфейсом (SOGo или эквивалент); • сервер файлового обмена - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 8) - Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - программное обеспечение (ПО) должно создавать и управлять резервными копиями виртуальных машин (ВМ), контейнеров и физических узлов, содержащие архивы файлов и образов; - ПО должно предоставлять интегрированный клиент для QEMU и LXC в виртуальной среде Proxmox; - ПО должно поддерживать резервное копирование на магнитную ленту и управление ленточными библиотеками; - ПО должно поддерживать дедупликацию, сжатие и аутентифицированое шифрование данных; - ПО должно использовать следующие алгоритмы сжатия данных lzo, gzip и zstd.; - ПО должно содержать в себе веб-интерфейс (RESTful API) управления со встроенной в него консолью, доступ должен осуществляться через системную аутентификацию Linux PAM. - ПО должно хранить данные резервных копий и предоставлять RESTful API для создания хранилищ данных и управления ими и другими ресурсами на стороне сервера; - ПО должно позволять с помощью API, предоставленного серверной частью, позволять клиенту резервного копирования получать доступ к сохранённым данным для создания и восстановления резервных копий файлов, а также для управления дисками и другими ресурсами на стороне сервера; - ПО должно использовать протокол TLS для обеспечения безопасности обмена данными между клиентской и серверной частями; - ПО должно использовать алгоритм AES-256 GCM при шифровании содержимого резервной копии на стороне клиента; - ПО должно позволять создавать хранилища данных с файловой системой форматов ext4, xfs.; - ПО должно содержать в себе набор инструментов, используемых для мониторинга и управления системой S.M.A.R.T. для локальных жёстких дисков, с возможностью отображения атрибутов S.M.A.R.T. из веб-интерфейса или при помощи командной строки; - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 9) - Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - ПО должно идентифицировать каждое хранилище данных именем и указанием на каталог в файловой системе и связывать с каждым хранилищем параметры хранения, определяющие количество снимков резервных копий для каждого интервала времени: час, день, неделя, месяц, год; - ПО должно позволять создавать хранилища данных с возможностью выбора и настройки следующих параметров: название; путь к каталогу; количество резервных копий для хранения в этом хранилище; расписания периодического запуска удаления резервных копий и сборки мусора (удаления неиспользуемых блоков данных); - ПО должно позволять ограничить входящий (например, резервное копирование) и исходящий (например, восстановление) сетевой трафик из набора сетей, с возможностью настроить определенные периоды, в которые будут применяться ограничения; - ПО должно позволять создавать пользователей и управлять ими как из встроенного веб-интерфейса, так и с помощью командной строки, с возможностью создания/удаления/отключения учетных записей, просмотра списка пользователей с возможностью изменения любых свойств; - ПО должно позволять любому аутентифицированному пользователю генерировать API-токены и использовать их для настройки клиентов резервного копирования вместо прямого указания имени пользователя и пароля. API-токен должен отзываться в случае компрометации клиента и ограничивать разрешения для каждого клиента/токена в рамках разрешения пользователей. ПО должно создавать для токенов собственные записи ACL, где токены не могут делать больше, чем создавший их пользователь; - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 10) - Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - ПО должно использовать систему управления разрешениями на основе ролей и путей, где роль содержит набор разрешенных действий, а путь представляет цель этих действий. По умолчанию разрешения созданным пользователям и API-токенам не должны предоставляться; - ПО должно предопределять следующий ряд ролей: нет привилегий (используется для запрета доступа); все привилегии; доступ только для чтения; все привилегии для хранилищ данных; просмотр настроек хранилищ и их содержимых, без возможности чтения фактических данных; просмотр содержимого хранилища, восстановление данных; создание и восстановление собственных резервных копий; создание, восстановление и удаление собственных резервных копий; все привилегии для удалённых серверов; просмотр настроек удалённых серверов; чтение данных с удалённых серверов; - ПО должно создавать, хранить и предоставлять следующую информацию о правах доступа: идентификатор ACL; включено или отключено; объект, на который установлено разрешение; пользователи/токены, для которых установлено разрешение; устанавливаемая роль. - ПО должно реализовывать возможность использования двухфакторной аутентификации с помощью веб-интерфейса тремя методами: TOTP (одноразовый пароль на основе времени) — для создания этого кода должен использоваться алгоритм одноразового пароля с учетом времени входа в систему (код меняется каждые 30 секунд); WebAuthn (веб-аутентификация) — реализуется с помощью различных устройств безопасности, таких как аппаратные ключи или доверенные платформенные модули (TPM). Для работы веб-аутентификации необходим сертификат HTTPS; Recovery Keys (одноразовые ключи восстановления) — список ключей, каждый из которых можно использовать только один раз. В каждый момент времени у пользователя может быть только один набор одноразовых ключей - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 11) - Операционная система должна предоставлять возможность установления безопасных сетевых соединений по технологии VPN; Операционная система должна обеспечивать возможность создания VPN-туннелей, использующих контроль заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015; Операционная система должна реализовывать базовый функционал межсетевого экрана; Операционная система должна предоставлять возможность установки многоплатформенного брокера подключений для создания и управления виртуальными рабочими местами и приложениями (OpenUDS или аналог); Операционная система должна включать графическое приложение для мониторинга ресурсов и просмотра системных журналов; Операционная система должна предоставлять возможность одновременной работы пользователей в изолированных сеансах. Должны быть предусмотрены: • отдельное изолированное хранение данных аутентификации каждого пользователя системы таким образом, чтобы процессы аутентификации локального или сетевого пользователя не могли получить доступа к данным аутентификации и авторизации других пользователей системы; • поддержка изоляции временных пользовательских файлов - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 12) - Операционная система должна включать автоматизированные средства изоляции приложений, чувствительных к сетевым атакам; Операционная система должна предоставлять упреждающие меры защиты и быть сконфигурирована с безопасными настройками по умолчанию; Операционная система должна предоставлять механизм управления фиксированными состояниями ключевых объектов безопасности системы, сохраняющий установленные права доступа к объектам файловой системы при обновлении пакетов; Операционная система должна обеспечивать поддержку шифрования по ГОСТ Р 34.11-2012 в OpenSSL, включая генерацию ключей и создание сертификатов; Операционная система должна предоставлять инструмент проверки контрольных сумм неизменяемых файлов установленных пакетов как при начальной установке, так и после получения обновлений. Вендор должен обеспечивать доступ к обновлениям и контрольным суммам неизменяемых файлов пакетов в них; Подсистема контроля целостности операционной системы должна поддерживать технологии IMA и EVM; Операционная система должна предоставлять возможность запрета запуска выбранных интерпретаторов в интерактивном режиме, отключения возможности удаления открытых файлов, а также установки запрета бита исполнения (SUID), распространяемого на дочерние процессы - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 13) - Операционная система должна поддерживать файловые системы ext2, ext3, ext4, btrfs для чтения/записи и установки, iso9660, xfs, fat16, fat32, ntfs.; Операционная система должна поддерживать сетевые протоколы SMB, NFS, FTP, NTP, HTTP(S); Операционная система должна предоставлять возможность доустановки необходимого программного обеспечения с диска или из репозитория, а также установки обновлений. Система должна обеспечить автоматическую проверку зависимостей (apt или эквивалент), а также возможность комплексного обновления системы с отдельным процессом установки ядра ядра с помощью графических утилит; Исходные коды, обновления, инструменты для сборки серверной ОС должны находиться в том же репозитории (хранилище), где хранятся исходные коды, обновления и инструменты для ОС рабочих станций; Операционная система должна предоставлять единую систему для установки прикладного программного обеспечения в системе (eepm или аналог). Также должна быть обеспечена возможность установки сторонних приложений в форматах deb, tgz, tbz, tbz2, pkg.gz.; Операционная система должна поддерживать корневые сертификаты Минцифры России. В составе дистрибутива должен присутствовать пакет с отечественными корневыми сертификатами шифрования; Операционная система должна поддерживать корневые сертификаты Российского центра сертификации ТЦИ, предоставляемые соответствующим пакетом из состава ОС - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 1) - В средстве виртуализации должны быть реализованы следующие функции безопасности: • идентификация и аутентификация субъектов доступа и объектов доступа, в том числе администраторов управления средствами виртуализации; • управление доступом субъектов доступа к объектам, в том числе внутри виртуальных машин; • регистрация событий безопасности; • управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуальной инфраструктуры, а также по ее периметру; • управление перемещением виртуальных машин (контейнеров) и обрабатываемых на них данных; • контроль целостности виртуальной инфраструктуры и ее конфигураций; • резервное копирование данных, резервирование технических средств, программного обеспечения, а также внутренних каналов связи внутри виртуальной инфраструктуры; • сегментирование виртуальной инфраструктуры для обработки информации отдельным пользователем и (или) группой пользователей; В состав дистрибутива операционной системы должен входить следующий комплекс программных компонент для построения виртуальной инфраструктуры: • гипервизор KVM (или эквивалент); • эмулятор аппаратного обеспечения различных платформ QEMU (или эквивалент); • набор инструментов, предоставляющий единый API для технологий виртуализации (libvirt или эквивалент); • гиперконвергентная система управления средой виртуализации с централизованным управлением физическими и виртуальными ресурсами; • система резервного копирования, интегрированная в систему управления средой виртуализации - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 2) - В состав дистрибутива операционной системы для обеспечения корректного функционирования современных средств виртуализации должны входить следующие компоненты: • ядро LTS не ниже 6.1.114; • systemd версии не ниже 249.17; • qemu версии не ниже 8.2; • libvirt версии не ниже 9.7; • corosync версии не ниже 3.1.8; • pacemaker версии не ниже 2.1.7; • keepalived версии не ниже 2.2.8; • Ceph версии не ниже 17.2; • Gluster версии не ниже 9.3. • Требование к версионности компонентов аргументируется наличием необходимого функционала и закрытыми уязвимостями в данных версиях; Система управления средой виртуализации должна обладать возможностью высокого масштабирования и поддерживать создание и управление виртуальной инфраструктурой со следующими параметрами лимитных значений: • максимальное количество физических серверов (узлов), поддерживаемых в составе кластера высокой доступности — не менее 128; • максимальное количество логических процессоров на хост-сервер — не менее 8192; • максимальный объем ОЗУ памяти на хост-сервер — не менее 32 ТБ; • поддержка в ВМ не менее 240 vCPU; • поддержка в ВМ ОЗУ не менее 4 TБ оперативной памяти; • поддержка объема виртуального диска для одной виртуальной машины не менее 64 TБ; • поддержка в ВМ виртуальных сетевых интерфейсов NICs для одной виртуальной машины не менее 10; • поддержка в ВМ виртуальных адаптеров SATA для одной виртуальной машины не менее 6 - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 3) - Система управления средой виртуализации должна предоставлять возможность управления через интерфейс CLI, графический веб-интерфейс, а также интеграцию со сторонним программным обеспечением с помощью REST API; Система управления средой виртуализации должна поддерживать технологию Wake-on-LAN; Система управления средой виртуализации должна поддерживать режим вложенной виртуализации; Система управления средой виртуализации должна обеспечивать создание виртуальных машин (ВМ), их образов и шаблонов для гостевых операционных систем аппаратных архитектур AArch64 (ARMv8) и x86-64; В составе системы управления средой виртуализации должны быть реализованы штатные графические средства мониторинга. Штатная система мониторинга, встроенная в систему управления виртуализации, должна предоставлять обзор в графическом интерфейсе для следующих ресурсов: • отображать объем всех ресурсов в соотношении к доступным (CPU, RAM, сеть, хранилище); • отображать количество всех виртуальных машин и контейнеров, а также количество запущенных и выключенных экземпляров; • отображать реквизиты объектов виртуальной инфраструктуры: IP-адрес, имя владельца и/или группы, имя хоста, ID (UID); • иметь цветовую дифференциацию объектов в зависимости их статусов и объёмов нагрузки; • обеспечивать возможность подключения дополнительных модулей мониторинга Zabbix, Grafana, Prometheus для получения детализированный информации по развёрнутой виртуальной инфраструктуре, включая низкоуровневые интерфейсы; В графическом интерфейсе системы управления средой виртуализации должны быть представлены графические инструменты подключения серверов статистики InfluxDB и Graphite - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 4) - Система управления средой виртуализации должна включать в себя набор инструментов, с отображением их в веб-интерфейсе и в командной строке, для мониторинга и управления S.M.A.R.T. системой для локальных жестких дисков. Набор инструментов для мониторинга и управления S.M.A.R.T. системой должен быть активен и включён по умолчанию и должен выполнять следующие функции: • сканирование дисков каждые 30 минут на наличие ошибок и предупреждений; • отправка сообщений электронной почты пользователю root при обнаружении проблем. • При повторе ошибок узел должен отсылать электронное сообщение каждые 24 часа; Система управления средой виртуализации иметь штатные инструменты регистрации событий и обеспечивать возможность просмотра истории событий и системных журналов каждого отдельного узла кластера и каждой ВМ в веб-интерфейсе самой системы управления средой виртуализации, включая в себя выполнение заданий резервного копирования или восстановления. Журнал событий должен быть оснащен инструментами фильтрации по дате и времени события, по типу и ID ресурса, инициатору события, типу события, статусу события; Система управления средой виртуализации должна поддерживать следующие технологии оптимизации памяти: • Thin Provisioning; • KSM; • Memory balooning; • NUMA. Система управления средой виртуализации должна предоставлять возможность создания общего хранилища со следующими функциональными возможностями: • миграция ВМ в реальном масштабе времени; • плавное расширение пространства хранения с множеством узлов; • централизованное резервное копирование; • многоуровневое кэширование данных; • централизованное управление хранением - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 5) - Система управления средой виртуализации должна поддерживать следующие методы организации хранения данных: • ZFS (локальный/over iSCSI); • Каталог; • BTRFS; • NFS; • CIFS; • GlusterFS; • Ceph версий 15 Octopus и 16 Pacific; • OCFS2; • LVM; • LVM-thin; • iSCSI; • Ceph/RBD. В системе управления средой виртуализацией должна быть реализована возможность хранить образы ВМ на нескольких локальных хранилищах или в общем хранилище; Для хранения всех файлов конфигурации, связанных с системой управления виртуализацией, в системе управления виртуализацией должна быть реализована кластерная файловая система, управляемая базой данных, для хранения файлов конфигурации, реплицируемых в реальном времени на все узлы кластера с помощью corosync. Такая система хранения должна позволять реализовать: • бесшовную репликацию всей конфигурации на все узлы в реальном времени; • строгие проверки согласованности, чтобы избежать дублирования идентификаторов виртуальных машин; • режим «только для чтения», когда узел теряет кворум; • автоматическое обновление конфигурации кластера corosync для всех узлов; • механизм распределенной блокировки. В системе управления виртуализацией должна быть обеспечена поддержка подключения к СХД по протоколам FC/iSCSI (поддержка блочного доступа к данным по сети SAN) - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 6) - Хранилище в системе управления виртуализацией должно поддерживать несколько типов содержимого: образы виртуальных дисков, ISO-образы компакт-дисков, шаблоны ВМ и контейнеров, корневые каталоги контейнеров. Настройка должна быть доступна с помощью графического интерфейса; В системе управления виртуализацией должна быть предусмотрена возможность выбора назначения создаваемого хранилища по типу файловой системы и контенту. Настройка должна быть доступна с помощью графического интерфейса; В системе управления средой виртуализации должна быть предусмотрена возможность управления ограничением дисковой пропускной способностью. Настройка должна быть доступна с помощью графического интерфейс; В системе управления средой виртуализацией должны быть реализованы штатные инструменты выбора версии, развертывания, управления и мониторинга Ceph и его отдельных компонент: сервер метаданных (MDS), OSD, клиентов Ceph, пулов Ceph; Система управления средой виртуализации должна обеспечивать возможность добавления дополнительных узлов в кластер после его создания. При добавлении узлов в кластер в системе управления виртуализацией должна автоматически обновляться и добавляться информация об узлах в файле настройки кластера; Система управления средой виртуализации должна позволять централизованное управление с любого узла дата-центра всеми ресурсами внутри ее контура: • дата-центр; • кластеры; • узлы; • сети; • хранилища; • пулы ресурсов: виртуальные машины, контейнеры, шаблоны; • резервные копии; • пользователи и разрешения - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 7) - Для обеспечения высокой надежности и отказоустойчивости система управления средой виртуализации не должна требовать отдельной установки менеджера управления на отдельную физическую или виртуальную машину; Для обеспечения согласованного состояния всех узлов кластера система управления средой виртуализации должна поддерживать режим работы «кворум»; В графическом интерфейсе системы управления средой виртуализации должно отражаться состояние кворума, а также проверка последнего временного штампа жизнеспособности (heartbeat timestamp); Система управления средой виртуализации должна поддерживать режим работы Qdevice и гарантировать кворум с четным числом узлов; В системе управления средой виртуализации для всех узлов кластера должен использоваться диспетчер отказоустойчивости — служба, управляющая политиками отказоустойчивости и высокой доступности среды виртуализации, которые описывают сценарий действий для физических и виртуальных ресурсов дата-центра; Для обеспечения корректной работы в режиме отказоустойчивости и диспетчера отказоустойчивости в системе управления средой виртуализации должен быть реализован планировщик ресурсов с функцией автоматического анализа утилизации ресурсов и распределения ресурсов согласно заданным политикам - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 8) - Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать и применять следующие политики выключения для узлов: • Conditional — режим автоматически определяет, требуется ли выключение или перезагрузка, и соответствующим образом меняет поведение вычислительного узла. • Failover — режим гарантирует, что все службы будут остановлены, но они также будут восстановлены, если текущий узел не будет подключен к сети в ближайшее время. • Freeze — режим гарантирует, что все службы будут остановлены и заморожены и не будут восстановлены до тех пор, пока текущий узел снова не будет подключен к сети. • Migrate — режим инициирует миграцию всех служб, находящихся в данный момент на том узле, на котором запланировано выключение. • Настройка режимов должна быть доступна с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 9) - Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать объединение узлов в группы отказоустойчивости для возможности восстановления виртуальных сервисов только на определенных узлах. Настройки таких групп должны обеспечивать указание приоритизации для восстановления виртуальных ресурсов (ВМ или контейнер). Настройки должны быть доступны с помощью графического интерфейса; Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать индивидуальные политики отказоустойчивости и применять их к выделенным виртуальным ресурсам (ВМ или контейнер): • ID ресурса — номер ВМ или контейнера; • состояние ресурса при восстановлении — запущен, восстановлен, не требует восстановления, отключен; • количество попыток восстановления; • количество попыток перемещения; • группы отказоустойчивости. • Настройки должны быть доступны с помощью графического интерфейса. В системе управления средой виртуализации должен быть реализован «режим обслуживания» с функцией автоматической миграции виртуальных машин; Система управления средой виртуализации должна позволять создавать отказоустойчивую мультикластерную инфраструктуру; Система управления средой виртуализации должна позволять создавать отказоустойчивую геораспределенную инфраструктуру; Система управления средой виртуализации должна позволять настройку сетевых соединений как децентрализованно на уровне узла, так и централизованно на уровне дата-центра - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 10) - В системе управления виртуализацией должны быть реализованы штатные графические инструменты создания и управления сетью со следующими функциями: • создание Linux/OVS Bridge соединений; • создание Linux/OVS Bond соединений; • создание Linux/OVS VLAN соединений; • поддержка алиаса для сетевых соединений; • создание виртуальных разделённых сетевых зон и управление ими; • создание виртуальных сетевых мостов и управление подсетями; • поддержка протоколов IPv4/IPv6; • поддержка виртуальных коммутаторов с технологией VXLAN (Virtual Extensible LAN); • поддержка трансляции сетевых адресов; • поддержка Jumbo frames до 9000; • поддержка маркировки QoS: 802.1p, DSCP; • поддержка проброса PCI устройств (SR-IOV); • поддержка протокола LLDP (Link Layer Discovery Protocol); • поддержка сетевых адаптеров не менее 10/40/100 Гб/сек. Система управления средой виртуализации должна позволять использование ВМ и контейнерами как одного моста, так и позволять создание нескольких мостов для разделения сетевых доменов (до 4094 мостов); Система управления средой виртуализации должна поддерживать объединение сетевых адаптеров/агрегацию каналов (bonding): циклическая передача (balance-rr), активное резервное копирование (active-backup), XOR (balance-xor), броадкаст (broadcast), IEEE 802.3ad (802.3ad) (LACP), режим адаптивной балансировки нагрузки при передаче (balance-tlb), режим адаптивной балансировки нагрузки (balance-alb); Сетевые настройки системы управления виртуализации должны позволять использование тегирования для VLAN. Настройка должна быть доступна с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 11) - Система управления средой виртуализации должна быть оснащена штатным фаерволом. Штатный фаервол должен группировать сеть на логические зоны по параметрам: • трафик от/к узлу кластера; • трафик от/к конкретной ВМ. Сетевые настройки (в том числе и в графическом интерфейсе системы) должны поддерживать возможность назначения правил фаервола для входящего и/или исходящего трафика: • для всего дата-центра; • для конкретного узла в кластере; • для конкретной ВМ. Настройки фаервола системы управления средой виртуализации должны позволять создавать секретные группы или группы безопасности. Настройки должны быть доступны с помощью графического интерфейса; Система управления средой виртуализации должна быть оснащена штатным сервером аутентификации; Система управления средой виртуализации должна поддерживать возможность интеграции внешних серверов аутентификации (Active Directory, LDAP, Linux PAM, OpenID) и обеспечивать синхронизацию с ними. Настройка должна быть доступна и в графическом интерфейсе; Система управления средой виртуализации должна поддерживать двухфакторную аутентификацию с использованием следующих методов: • TOTP; • Yubikey OTP; • WebAuthn; • одноразовые ключи восстановления. • Настройка должна быть доступна с помощью графического интерфейса. Система управления средой виртуализации должна определять многоуровневый доступ, используя основанное на ролях управление пользователями и разрешениями для всех объектов (ВМ, хранилищ, узлов и т. д.). Настройки должны быть доступны с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 12) - Система управления средой виртуализации должна иметь по умолчанию не менее 12 предопределенных ролей: • Administrator?—?имеет все привилегии; • NoAccess?—?нет привилегий (используется для запрета доступа); • Admin?—?все привилегии, кроме прав на изменение настроек системы; • Auditor?—?доступ только для чтения; • DatastoreAdmin?—?создание и выделение места для резервного копирования и шаблонов; • DatastoreUser?—?выделение места для резервной копии и просмотр хранилища; • PoolAdmin?—?выделение пулов; • SysAdmin?—?ACL пользователя, аудит, системная консоль и системные журналы; • TemplateUser?—?просмотр и клонирование шаблонов; • UserAdmin?—?администрирование пользователей; • VMAdmin?—?управление ВМ; • VMUser?—?просмотр, резервное копирование, настройка CDROM, консоль ВМ, управление питанием ВМ. Система управления средой виртуализации должна быть оснащена штатным конструктором ролей и обеспечивать возможность создание новых ролей. Настройка должна быть доступна с помощью графического интерфейса; Для оптимизации контроля доступа система управления средой виртуализации должна поддерживать группировку ресурсов (ВМ и хранилищ) в отдельные пулы с возможностью наделения индивидуальными разрешениями. Настройка должна быть доступна с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 13) - Система управления средой виртуализации должна поддерживать возможность создавать виртуальную машину как из шаблона, так и без него. Настройка должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать возможность создавать виртуальную машину с несколькими дисками. Настройка должна быть доступна с помощью графического интерфейса; Для обеспечения высокой производительности система управления средой виртуализации должна поддерживать возможность задавать настройки многопоточности и ограничения пропускной способности при создании виртуальной машины. Настройка должна быть доступна с помощью графического интерфейса; Для обеспечения высокой производительности система управления средой виртуализации должна поддерживать горячее добавление ресурсов vCPU, vRAM, vDisk, USB, vNIC без остановки или перезагрузки ВМ. Настройка должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать как оффлайн-миграцию ВМ, так и живую миграцию - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 14) - Система управления средой виртуализации должна поддерживать следующие действия над ВМ и режимы работы ВМ, в том числе и в графическом интерфейсе: • запуск; • останов; • пауза; • гибернация; • перезагрузка; • сброс. Система управления средой виртуализации должна поддерживать доступ к консоли ВМ и манипуляции в ВМ как в отдельном сеансе, так и в веб-интерфейсе самой системы управления средой виртуализации; Система управления средой виртуализации должна поддерживать различные варианты копирования ВМ: • полный клон; • связанный клон; • моментальный снимок. Система управления средой виртуализации должна поддерживать следующие протоколы для доступа к консоли ВМ: VNC, SPICE, RDP; Система управления средой виртуализации должна поддерживать массовые операции над ВМ: миграция, старт, выключение. Опция должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать миграцию и импорт из других платформ и гипервизоров: P2V, V2V (Vmware, Hyper-V, KVM, oVirt) с использованием штатных инструментов самой системы управления средой виртуализации - - Значение характеристики не может изменяться участником закупки - Требования к контейнеризации (ч.1) - Операционная система в соответствии с документом «Требования по безопасности информации к средствам контейнеризации» (ФСТЭК России, 2022, приказ № 118) по 4-му классу защиты должна реализовывать следующие функции безопасности: • изоляция контейнеров; • выявление уязвимостей в образах контейнеров; • проверка корректности конфигурации контейнеров; • контроль целостности контейнеров и их образов; • регистрация событий безопасности; • управление доступом; • идентификация и аутентификация пользователей; • централизованное управление образами контейнеров и контейнерами в средстве контейнеризации. Операционная система должна предоставлять сертифицированные средства контейнеризации (kubernetes или эквивалент, podman или эквивалент) имеющие возможность запуска от непривилегированного пользователя без необходимости запуска какого-либо демона/службы; Все инструменты, в том числе контейнеры, должны входить в состав дистрибутива операционной системы и устанавливаться без обращения по сети к внешним источникам. Набор контейнеров должен включать базовые контейнеры, в том числе и distroless-образ и набор контейнеров для разворачивания кластера kubernetes - - Значение характеристики не может изменяться участником закупки - Требования к контейнеризации (ч.2) - Средства управления образами контейнеров и контейнерами (оркестратор или аналог) должны обеспечивать следующие функции: • создание, модификацию, хранение, получение и удаление образов контейнеров в информационной (автоматизированной) системе; • обновление средства контейнеризации и образов контейнеров из реестра вендора; • чтение, удаление записей о событиях безопасности, формирование отчетов с учетом заданных критериев отбора, выгрузку (экспорт) данных из журнала событий безопасности средства контейнеризации; • анализ возникающих событий безопасности в целях выявления инцидентов безопасности. Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции изоляции контейнеров: • изоляция пространств идентификаторов процессов; • изоляция пространств имен для межпроцессного взаимодействия; • изоляция пространств имен для пользователей и групп; • изоляция пространств имен хостов и доменов; • изоляция сетевых пространств имен; • изоляция пространств имен для иерархии каталогов. В дистрибутиве операционной системы должна быть реализована ролевая модель управления доступом: разработчик образов контейнеров, администратор безопасности средств контейнеризации, администратор информационной (автоматизированной) системы - - Значение характеристики не может изменяться участником закупки - Требования к контейнеризации (ч.3) - Дистрибутив операционной системы должен реализовывать следующие требования к функциям идентификации и аутентификации пользователей: • аутентификация пользователей по паролю; • пароль пользователя должен устанавливаться администратором безопасности средства контейнеризации; • средство контейнеризации должно обеспечивать возможность смены установленного администратором безопасности средства контейнеризации пароля пользователя после его первичной аутентификации; • при попытке ввода неправильного значения пароля пользователя должно выводиться соответствующее сообщение с приглашением ввести правильный пароль еще раз; • при исчерпании установленного максимального количества неуспешных попыток ввода неправильного пароля учетная запись пользователя средства контейнеризации должна быть заблокирована; • разблокировка учетной записи пользователя средства контейнеризации должна осуществляться администратором безопасности средства контейнеризации; • защита пароля пользователя должна обеспечиваться при его вводе за счет отображения вводимых символов условными знаками; • средство контейнеризации должно обеспечивать хранение аутентификационной информации пользователя средства контейнеризации в защищенном формате или в защищенном хранилище; • средство контейнеризации не должно запускать процессы в хостовой операционной системе, обладающие привилегиями администратора информационной (автоматизированной) системы и администратора безопасности информационной (автоматизированной) системы; • пароль пользователя средства контейнеризации должен содержать не менее 8 символов при алфавите пароля не менее 70 символов. Максимальное количество неуспешных попыток аутентификации (ввода неправильного пароля) до блокировки — 4. • указанные условия должны быть преднастроены в дистрибутиве операционной системы в рамках парольной политики по умолчанию - - Значение характеристики не может изменяться участником закупки - Требования к контейнеризации (ч.4) - Дистрибутив операционной системы должен реализовывать специальный механизм по выявлению уязвимостей в образах контейнеров с учетом следующих требований: • выявление известных уязвимостей при создании, первичном запуске и хранении образов контейнеров, самостоятельно или во взаимодействии с сертифицированным средством контроля и анализа защищенности на основе сведений, содержащихся в банке данных угроз безопасности информации БДУ ФСТЭК России (https://bdu.fstec.ru/), а также в иных источниках, содержащих сведения об известных уязвимостях; • оповещение о выявленных уязвимостях в образах контейнеров разработчика образов контейнеров и администратора информационной (автоматизированной) системы; • средство контейнеризации должно обеспечивать запрет создания образов контейнеров, содержащих известные уязвимости критического и высокого уровня опасности (уровень опасности определяется по значению (V) CVSS в CVE). Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции управления конфигурацией: • возможность ограничения прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование периферийных устройств, устройств хранения данных и съемных машинных носителей информации (блочных устройств), входящих в состав информационной (автоматизированной) системы; • возможность ограничения прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование вычислительных ресурсов (оперативной памяти, операций ввода-вывода за период времени) хостовой операционной системы; • запрет возможности монтирования средством контейнеризации корневой файловой системы хостовой операционной системы (за исключением режима «только для чтения») - - Значение характеристики не может изменяться участником закупки - Требования к контейнеризации (ч.5) - Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции контроля целостности контейнеров и их образов: • контролировать самостоятельно или с применением средств контроля целостности хостовой операционной системы и иных сертифицированных средств защиты информации целостность образов контейнеров и исполняемых файлов контейнеров; • информировать администратора безопасности информационной (автоматизированной) системы и администратора безопасности средства контейнеризации о нарушении целостности объектов контроля; • контролировать целостность параметров настройки средства контейнеризации; • контролировать целостность сведений о событиях безопасности и обеспечивать формирование отчетов самостоятельно или во взаимодействии с хостовой операционной системой; • контролировать целостность образов контейнеров и параметров настройки средства контейнеризации при первичном запуске и далее периодически за счет применения электронной подписи самостоятельно или во взаимодействии с хостовой операционной системой; • блокировать запуск образа контейнера при нарушении его целостности. Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции регистрации событий безопасности: • обеспечивать регистрацию событий, относящихся к инцидентам безопасности средства контейнеризации, связанных с попытками осуществления несанкционированного доступа к средству контейнеризации; • оповещать администратора безопасности средства контейнеризации и администратора безопасности информационной (автоматизированной) системы об инцидентах безопасности; • выполнять действия, являющиеся реакцией на инциденты безопасности; • осуществлять сбор и хранение записей в журнале событий безопасности - - Значение характеристики не может изменяться участником закупки - Требования к контейнеризации (ч.6) - Средства контейнеризации дистрибутива операционной системы должны соответствовать следующим требованиям к регистрации событий безопасности: • для регистрируемых событий безопасности в каждой записи журнала событий безопасности должны регистрироваться номер (уникальный идентификатор) события, дата, время, тип события безопасности; • записи журнала событий безопасности должны представляться в структурированном виде и содержать время события безопасности, взятое из хостовой операционной системы; • должна быть обеспечена запись событий безопасности контейнеров в журнал событий безопасности информационной (автоматизированной) системы с указанием идентификатора контейнера; • журнал событий безопасности средства контейнеризации должен быть доступен только для чтения. При исчерпании области памяти, отведенной под журнал событий безопасности средства контейнеризации, должно осуществляться его архивирование с последующей очисткой; • регистрации подлежат следующие события безопасности: a. неуспешные попытки аутентификации пользователей средства контейнеризации; b. создание, модификация и удаление образов контейнеров; c. получение доступа к образам контейнеров; d. запуск и остановка контейнеров с указанием причины остановки; e. изменение ролевой модели; f. модификация запускаемых контейнеров; g. выявление известных уязвимостей в образах контейнеров и некорректности конфигурации; h. факты нарушения целостности объектов контроля. • должна обеспечиваться запись событий безопасности контейнеров в журнал событий безопасности с указанием идентификатора пользователя хостовой операционной системы, от имени которого был запущен контейнер - - Значение характеристики не может изменяться участником закупки - Нефункциональные требования - Разработчик обязан оказывать гарантийную вендорскую поддержку продукта (оперативный выпуск обновлений по безопасности); Разработчик обязан оказывать техническую поддержку пользователям на условиях SLA в течение первого года использования. Для критических инцидентов должно быть обеспечено время реакции не более 8 часов в период с 9:00 до 19:00 в рабочие дни; Система должна быть основана на программном обеспечении с открытым исходным кодом - - Значение характеристики не может изменяться участником закупки

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

Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

Класс программ для электронных вычислительных машин и баз данных - (02.09) Операционные системы общего назначения - - Значение характеристики не может изменяться участником закупки

Способ предоставления - Экземпляр на материальном носителе - - Значение характеристики не может изменяться участником закупки

Общие требования - Программное обеспечение должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных Минкомсвязи РФ по классам «Операционные системы общего назначения», «Средства виртуализации», «Серверное и связующее программное обеспечение», «Средства управления базами данных», «Системы контейнеризации и контейнеры», «Средства защиты от несанкционированного доступа к информации»; Операционная система должна соответствовать требованиям документов: «Требования безопасности информации к операционным системам» (ФСТЭК России, 2016) и «Профиль защиты операционных систем типа «А» четвертого класса защиты ИТ.ОС.А4.ПЗ» (ФСТЭК России, 2017) ; «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» не ниже четвертого уровня доверия (приказ ФСТЭК России № 76 от 2 июня 2020 г.); «Требования по безопасности информации к средствам контейнеризации» (приказ ФСТЭК России № 118, 2022,) не ниже 4 класса защиты; «Требования по безопасности информации к средствам виртуализации» (приказ ФСТЭК России, № 187, 2022 г.) не ниже 4 класса защиты; «Требования по безопасности информации к системам управления базами данных» (приказ ФСТЭК России № 64, 2023 г.) не ниже 4 класса защиты; В Формуляре ОС должны быть указаны интерпретаторы, веб сервера и сервера приложений, проверенные согласно документу: «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении», утверждена ФСТЭК России 25.12.2020 г.; Разработчик должен иметь собственную инфраструктуру разработки полного цикла, зарегистрированную и находящуюся на территории РФ, в исключительной юрисдикции РФ; Наличие в России локализованной сервисной и/или технической поддержки - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч.1) - Операционная система должна устанавливаться и функционировать на компьютерах с архитектурами x86_64 (64-разрядный процессор Intel или AMD), aarch64 («Байкал», Rockchip 3588) и «Эльбрус» (процессоры 8С, 1С+, 8СВ, 2С3, 12С, 16С) должны быть отдельные образы в сертифицированном исполнении для каждой архитектуры. Требования перечисленные в данном документе относятся к архитектуре x86_64 и могут отличатся от требований к другим архитектурам. Операционная система должна поддерживать режимы установки и загрузки Legacy/CSM, UEFI (с включенным механизмом SecureBoot), а также средствами BMC/IPMI (если поддерживается оборудованием). Операционная система должна иметь в составе ядро не ниже 6.12 (LTS) для обеспечения корректного функционирования современных средств вычислительной техники. Система должна пре доставлять графические утилиты для установки, удаления и обновления ядра, включая модули, а также для выбора ядра по умолчанию. Операционная система должна обеспечивать поддержку нескольких видеокарт (работа на нескольких мониторах). Операционная система должна обладать русифицированным интерфейсом, а также предоставлять русскоязычную документацию. Операционная система должна иметь возможность установки с DVD-диска и USB-накопителя. Операционная система должна предоставлять варианты сетевой установки: PXE/TFTP (для режима Legacy/CSM-загрузки), HTTPClient (для спецификации UEFI 2.5 и выше), iPXE Операционная система должна предоставлять возможность организации сервера сетевой загрузки. Операционная система должна предоставлять возможность установки на оборудование без графической подсистемы с локального накопителя, а также установки с использованием сервера сетевой установки по протоколу VNC - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 2) - Носитель с дистрибутивом ОС должен предусматривать вариант загрузки для проведения работ по восстановлению системы, включая проверку сохранности содержимого файловой системы и проверку контрольных сумм неизменяемых файлов установленных пакетов, диагностику конфигурации аппаратного обеспечения, изменение таблицы и размеров разделов, изменение параметров файловых систем, восстановление удаленных разделов и файлов, проведение резервного копирования, очистку остаточной информации на разделах и дисках; Операционная система должна иметь возможность установки на программный RAID-массив, размещения разделов в томах LVM и использования маскирования (кодирования) разделов с парольным доступом; Операционная система должна обеспечивать возможность создания точек восстановления (снапшотов) для последующего возвращения системы к исходному состоянию в случае сбоя; Инсталлятор дистрибутива должен предусматривать возможность предварительной (OEM) установки, позволяющей при первом запуске пользователем после установки выбрать язык, принять лицензионное соглашение, настроить дату/время, настроить сеть, задать пароль root, создать системного пользователя; Операционная система должна предоставлять независимый выбор основных и дополнительных приложений в момент установки: серверные приложения (dhcp, dns,ftp, http, почтовый сервер, сервер резервного копирования, сервер печати, сервер сетевой установки), сканер обнаружения уязвимостей, сервер сертифицированной СУБД, сервер управления конфигурациями, сервер виртуальных рабочих столов, средства управления контейнеризацией, средства управления виртуализацией - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 3) - Операционная система после установки должна предоставлять пользователю рабочую среду, включающую системное ПО, сетевые службы и сервисы, драйвера устройств, утилиты администрирования, базовый набор приложений; Если установлена графическая среда, операционная система должна предоставлять графическое средство настройки многопользовательского режима, позволяющего обеспечить одновременную работу нескольких пользователей на одном компьютере при наличии отдельной видеокарты, клавиатуры и мыши для каждого пользователя; Операционная система должна предоставлять инструмент для поиска уязвимостей в файлах конфигурации, файловых системах, используемых пакетах ОС (включая программные зависимости), образах контейнеров и git-репозиториях. Анализ уязвимостей должен осуществляться как по вендорской базе уязвимостей (CVE), собранной из разных источников, так и по базе уязвимостей (BDU) ФСТЭК России; Операционная система должна предоставлять возможность установки пароля на загрузчик для ограничения доступа к опциям загрузки; Операционная система должна предоставлять возможность блокировки виртуальных текстовых консолей. Комплекс средств защиты ОС должен обеспечивать выполнение программ в защищенной среде. В состав ОС должны быть включены программные интерпретаторы (php, perl, lua, python, nodejs) и веб-сервер (nginx), прошедшие испытания по выявлению уязвимостей и недекларированных возможностей в полном объеме в соответствии с Методикой выявления уязвимостей и недекларированных возможностей в программном обеспечении, утвержденной ФСТЭК России 25.12.2020 г.; Операционная система должна включать приложение для мониторинга ресурсов. Должно быть обеспечено централизованное управление конфигурациями прав доступа к утилите мониторинга температуры жесткого диска - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 4) - Операционная система должна предоставлять единый графический модульный интерфейс для администрирования и настроек, а также предоставлять возможность удаленного администрирования по защищенным протоколам с помощью графических утилит (включая конфигурирование установленной системы через веб). Администратор должен иметь возможность назначить права доступа для пользователей к определенным модулям. В состав базовых сервисов должны входить: • настройка даты и времени; • управление системными службами; • просмотр системных журналов; • конфигурирование сетевых подключений и межсетевого экрана; • установка обновлений, в том числе для компьютеров без доступа в интернет; • управление выключением удаленного компьютера; • управление пользователями; • настройка пользовательских квот на использование ресурсов памяти, диска и внешних носителей. Операционная система должна реализовывать возможность хранения аутентификационной информации пользователей, полученной с использованием хеш-функций по ГОСТ Р 34.11-2012. Реализация функционала должна быть обеспечена как консольными, так и графическими утилитами; Операционная система должна обеспечивать возможность создания ssh-туннелей, использующих контроль целостности заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015; Операционная система должна предоставлять возможность авторизации по смарт-картам в консольном режиме; Операционная система должна предоставлять протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе; Операционная система должна предоставлять возможность разграничения доступа к подключаемым устройствам - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 5) - Операционная система должна иметь возможность организации домена Samba-DC или интеграции с доменом Active Directory с поддержкой следующего функционала: • действовать в качестве первичного или вторичного контроллера домена; • аутентификация рабочих станций; • авторизация и предоставление ресурсов без дополнительного ввода пароля (Single Sign-On); • поддержка ролей и привилегий (назначение ролей группам); • групповые политики (GPO); Операционная система должна предоставлять возможность организации трастовых доменов - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 6) - При работе в гетерогенной среде домена Active Directory (нативного или создаваемого с помощью проекта Samba) должны быть доступны, при использовании инструмента RSAT в среде Windows или с помощью собственного приложения, следующие политики для управления компьютерами и доменными пользователями, работающими на них: • Настройка установки программного обеспечения из репозитория. • Исполнение любых скриптов при включении/выключении компьютера или входе/выходе пользователя в систему. • Разрешение/Запрет на подключение класса съемных накопителей для компьютера или отдельных пользователей. • Управление ярлыками для компьютера или пользователей. • Централизованное управление конфигурациями сервисов systemd, включая интерфейс-терминала смарт-карт (openct), диспетчер авторизации (polkit), службы аудита безопасности (auditd). • Централизованное управление конфигурациями системных сервисов (CUPS, SSHD, NTP Chrony, Postfix MTA и postqueue, DNS, OpenLDAP, Rpcbind, SSSD, очередь заданий) и утилит определения прав доступа к модификации учетных записей, паролей, пользователей (включая создание индивидуальных временных каталогов) и групп, а также к утилитам su/sudo. • Централизованное управление конфигурациями прав доступа монтирования съемных накопителей, пользовательских файловых систем, подключения сетевых ресурсов по nfs. • Управление файлами и папками (создание, удаление, перемещение, копирование, предоставление общего доступа или скрытие). • Управление настройками приложений через ini-файлы. • Управление интервалом времени применения групповой политики. • Управление всеми политиками веб-браузеров Mozilla Firefox и Chromium. • Возможность принудительного выполнения политики на клиенте - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 7) - Операционная система должна предоставлять возможность организации и настройки базовых сетевых сервисов и служб: • sshd; • DNS; • DHCP; • протокол аутентификации LDAP; • OpenVPN; • SMTP, POP3/IMAP (postfix, dovecot или эквивалент); • межсетевой экран; • проксирование HTTP- и FTP-запросов (squid или эквивалент); • резервное копирование (bacula или эквивалент); • сервер сетевой установки с веб-интерфейсом; • сервер обновлений с возможностью зеркалирования репозитория вендора ОС и создания служебных репозиториев используемого Заказчиком ПО; • защищенный сервер баз данных (PostgreSQL или эквивалент) с возможностью организации кластера из нескольких серверов, со встроенной реализацией функций round, trunc, date совместимой с Oracle DB; • веб-сервер; • FTP-сервер; • сервер мониторинга сетевых ресурсов с графическим интерфейсом (Zabbix, icinga2 или эквивалент); • сервер печати; • сервер групповой работы с веб-интерфейсом (SOGo или эквивалент); • сервер файлового обмена - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 8) - Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - программное обеспечение (ПО) должно создавать и управлять резервными копиями виртуальных машин (ВМ), контейнеров и физических узлов, содержащие архивы файлов и образов; - ПО должно предоставлять интегрированный клиент для QEMU и LXC в виртуальной среде Proxmox; - ПО должно поддерживать резервное копирование на магнитную ленту и управление ленточными библиотеками; - ПО должно поддерживать дедупликацию, сжатие и аутентифицированое шифрование данных; - ПО должно использовать следующие алгоритмы сжатия данных lzo, gzip и zstd.; - ПО должно содержать в себе веб-интерфейс (RESTful API) управления со встроенной в него консолью, доступ должен осуществляться через системную аутентификацию Linux PAM. - ПО должно хранить данные резервных копий и предоставлять RESTful API для создания хранилищ данных и управления ими и другими ресурсами на стороне сервера; - ПО должно позволять с помощью API, предоставленного серверной частью, позволять клиенту резервного копирования получать доступ к сохранённым данным для создания и восстановления резервных копий файлов, а также для управления дисками и другими ресурсами на стороне сервера; - ПО должно использовать протокол TLS для обеспечения безопасности обмена данными между клиентской и серверной частями; - ПО должно использовать алгоритм AES-256 GCM при шифровании содержимого резервной копии на стороне клиента; - ПО должно позволять создавать хранилища данных с файловой системой форматов ext4, xfs.; - ПО должно содержать в себе набор инструментов, используемых для мониторинга и управления системой S.M.A.R.T. для локальных жёстких дисков, с возможностью отображения атрибутов S.M.A.R.T. из веб-интерфейса или при помощи командной строки; - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 9) - Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - ПО должно идентифицировать каждое хранилище данных именем и указанием на каталог в файловой системе и связывать с каждым хранилищем параметры хранения, определяющие количество снимков резервных копий для каждого интервала времени: час, день, неделя, месяц, год; - ПО должно позволять создавать хранилища данных с возможностью выбора и настройки следующих параметров: название; путь к каталогу; количество резервных копий для хранения в этом хранилище; расписания периодического запуска удаления резервных копий и сборки мусора (удаления неиспользуемых блоков данных); - ПО должно позволять ограничить входящий (например, резервное копирование) и исходящий (например, восстановление) сетевой трафик из набора сетей, с возможностью настроить определенные периоды, в которые будут применяться ограничения; - ПО должно позволять создавать пользователей и управлять ими как из встроенного веб-интерфейса, так и с помощью командной строки, с возможностью создания/удаления/отключения учетных записей, просмотра списка пользователей с возможностью изменения любых свойств; - ПО должно позволять любому аутентифицированному пользователю генерировать API-токены и использовать их для настройки клиентов резервного копирования вместо прямого указания имени пользователя и пароля. API-токен должен отзываться в случае компрометации клиента и ограничивать разрешения для каждого клиента/токена в рамках разрешения пользователей. ПО должно создавать для токенов собственные записи ACL, где токены не могут делать больше, чем создавший их пользователь; - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 10) - Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - ПО должно использовать систему управления разрешениями на основе ролей и путей, где роль содержит набор разрешенных действий, а путь представляет цель этих действий. По умолчанию разрешения созданным пользователям и API-токенам не должны предоставляться; - ПО должно предопределять следующий ряд ролей: нет привилегий (используется для запрета доступа); все привилегии; доступ только для чтения; все привилегии для хранилищ данных; просмотр настроек хранилищ и их содержимых, без возможности чтения фактических данных; просмотр содержимого хранилища, восстановление данных; создание и восстановление собственных резервных копий; создание, восстановление и удаление собственных резервных копий; все привилегии для удалённых серверов; просмотр настроек удалённых серверов; чтение данных с удалённых серверов; - ПО должно создавать, хранить и предоставлять следующую информацию о правах доступа: идентификатор ACL; включено или отключено; объект, на который установлено разрешение; пользователи/токены, для которых установлено разрешение; устанавливаемая роль. - ПО должно реализовывать возможность использования двухфакторной аутентификации с помощью веб-интерфейса тремя методами: TOTP (одноразовый пароль на основе времени) — для создания этого кода должен использоваться алгоритм одноразового пароля с учетом времени входа в систему (код меняется каждые 30 секунд); WebAuthn (веб-аутентификация) — реализуется с помощью различных устройств безопасности, таких как аппаратные ключи или доверенные платформенные модули (TPM). Для работы веб-аутентификации необходим сертификат HTTPS; Recovery Keys (одноразовые ключи восстановления) — список ключей, каждый из которых можно использовать только один раз. В каждый момент времени у пользователя может быть только один набор одноразовых ключей - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 11) - Операционная система должна предоставлять возможность установления безопасных сетевых соединений по технологии VPN; Операционная система должна обеспечивать возможность создания VPN-туннелей, использующих контроль заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015; Операционная система должна реализовывать базовый функционал межсетевого экрана; Операционная система должна предоставлять возможность установки многоплатформенного брокера подключений для создания и управления виртуальными рабочими местами и приложениями (OpenUDS или аналог); Операционная система должна включать графическое приложение для мониторинга ресурсов и просмотра системных журналов; Операционная система должна предоставлять возможность одновременной работы пользователей в изолированных сеансах. Должны быть предусмотрены: • отдельное изолированное хранение данных аутентификации каждого пользователя системы таким образом, чтобы процессы аутентификации локального или сетевого пользователя не могли получить доступа к данным аутентификации и авторизации других пользователей системы; • поддержка изоляции временных пользовательских файлов - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 12) - Операционная система должна включать автоматизированные средства изоляции приложений, чувствительных к сетевым атакам; Операционная система должна предоставлять упреждающие меры защиты и быть сконфигурирована с безопасными настройками по умолчанию; Операционная система должна предоставлять механизм управления фиксированными состояниями ключевых объектов безопасности системы, сохраняющий установленные права доступа к объектам файловой системы при обновлении пакетов; Операционная система должна обеспечивать поддержку шифрования по ГОСТ Р 34.11-2012 в OpenSSL, включая генерацию ключей и создание сертификатов; Операционная система должна предоставлять инструмент проверки контрольных сумм неизменяемых файлов установленных пакетов как при начальной установке, так и после получения обновлений. Вендор должен обеспечивать доступ к обновлениям и контрольным суммам неизменяемых файлов пакетов в них; Подсистема контроля целостности операционной системы должна поддерживать технологии IMA и EVM; Операционная система должна предоставлять возможность запрета запуска выбранных интерпретаторов в интерактивном режиме, отключения возможности удаления открытых файлов, а также установки запрета бита исполнения (SUID), распространяемого на дочерние процессы - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 13) - Операционная система должна поддерживать файловые системы ext2, ext3, ext4, btrfs для чтения/записи и установки, iso9660, xfs, fat16, fat32, ntfs.; Операционная система должна поддерживать сетевые протоколы SMB, NFS, FTP, NTP, HTTP(S); Операционная система должна предоставлять возможность доустановки необходимого программного обеспечения с диска или из репозитория, а также установки обновлений. Система должна обеспечить автоматическую проверку зависимостей (apt или эквивалент), а также возможность комплексного обновления системы с отдельным процессом установки ядра ядра с помощью графических утилит; Исходные коды, обновления, инструменты для сборки серверной ОС должны находиться в том же репозитории (хранилище), где хранятся исходные коды, обновления и инструменты для ОС рабочих станций; Операционная система должна предоставлять единую систему для установки прикладного программного обеспечения в системе (eepm или аналог). Также должна быть обеспечена возможность установки сторонних приложений в форматах deb, tgz, tbz, tbz2, pkg.gz.; Операционная система должна поддерживать корневые сертификаты Минцифры России. В составе дистрибутива должен присутствовать пакет с отечественными корневыми сертификатами шифрования; Операционная система должна поддерживать корневые сертификаты Российского центра сертификации ТЦИ, предоставляемые соответствующим пакетом из состава ОС - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 1) - В средстве виртуализации должны быть реализованы следующие функции безопасности: • идентификация и аутентификация субъектов доступа и объектов доступа, в том числе администраторов управления средствами виртуализации; • управление доступом субъектов доступа к объектам, в том числе внутри виртуальных машин; • регистрация событий безопасности; • управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуальной инфраструктуры, а также по ее периметру; • управление перемещением виртуальных машин (контейнеров) и обрабатываемых на них данных; • контроль целостности виртуальной инфраструктуры и ее конфигураций; • резервное копирование данных, резервирование технических средств, программного обеспечения, а также внутренних каналов связи внутри виртуальной инфраструктуры; • сегментирование виртуальной инфраструктуры для обработки информации отдельным пользователем и (или) группой пользователей; В состав дистрибутива операционной системы должен входить следующий комплекс программных компонент для построения виртуальной инфраструктуры: • гипервизор KVM (или эквивалент); • эмулятор аппаратного обеспечения различных платформ QEMU (или эквивалент); • набор инструментов, предоставляющий единый API для технологий виртуализации (libvirt или эквивалент); • гиперконвергентная система управления средой виртуализации с централизованным управлением физическими и виртуальными ресурсами; • система резервного копирования, интегрированная в систему управления средой виртуализации - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 2) - В состав дистрибутива операционной системы для обеспечения корректного функционирования современных средств виртуализации должны входить следующие компоненты: • ядро LTS не ниже 6.1.114; • systemd версии не ниже 249.17; • qemu версии не ниже 8.2; • libvirt версии не ниже 9.7; • corosync версии не ниже 3.1.8; • pacemaker версии не ниже 2.1.7; • keepalived версии не ниже 2.2.8; • Ceph версии не ниже 17.2; • Gluster версии не ниже 9.3. • Требование к версионности компонентов аргументируется наличием необходимого функционала и закрытыми уязвимостями в данных версиях; Система управления средой виртуализации должна обладать возможностью высокого масштабирования и поддерживать создание и управление виртуальной инфраструктурой со следующими параметрами лимитных значений: • максимальное количество физических серверов (узлов), поддерживаемых в составе кластера высокой доступности — не менее 128; • максимальное количество логических процессоров на хост-сервер — не менее 8192; • максимальный объем ОЗУ памяти на хост-сервер — не менее 32 ТБ; • поддержка в ВМ не менее 240 vCPU; • поддержка в ВМ ОЗУ не менее 4 TБ оперативной памяти; • поддержка объема виртуального диска для одной виртуальной машины не менее 64 TБ; • поддержка в ВМ виртуальных сетевых интерфейсов NICs для одной виртуальной машины не менее 10; • поддержка в ВМ виртуальных адаптеров SATA для одной виртуальной машины не менее 6 - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 3) - Система управления средой виртуализации должна предоставлять возможность управления через интерфейс CLI, графический веб-интерфейс, а также интеграцию со сторонним программным обеспечением с помощью REST API; Система управления средой виртуализации должна поддерживать технологию Wake-on-LAN; Система управления средой виртуализации должна поддерживать режим вложенной виртуализации; Система управления средой виртуализации должна обеспечивать создание виртуальных машин (ВМ), их образов и шаблонов для гостевых операционных систем аппаратных архитектур AArch64 (ARMv8) и x86-64; В составе системы управления средой виртуализации должны быть реализованы штатные графические средства мониторинга. Штатная система мониторинга, встроенная в систему управления виртуализации, должна предоставлять обзор в графическом интерфейсе для следующих ресурсов: • отображать объем всех ресурсов в соотношении к доступным (CPU, RAM, сеть, хранилище); • отображать количество всех виртуальных машин и контейнеров, а также количество запущенных и выключенных экземпляров; • отображать реквизиты объектов виртуальной инфраструктуры: IP-адрес, имя владельца и/или группы, имя хоста, ID (UID); • иметь цветовую дифференциацию объектов в зависимости их статусов и объёмов нагрузки; • обеспечивать возможность подключения дополнительных модулей мониторинга Zabbix, Grafana, Prometheus для получения детализированный информации по развёрнутой виртуальной инфраструктуре, включая низкоуровневые интерфейсы; В графическом интерфейсе системы управления средой виртуализации должны быть представлены графические инструменты подключения серверов статистики InfluxDB и Graphite - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 4) - Система управления средой виртуализации должна включать в себя набор инструментов, с отображением их в веб-интерфейсе и в командной строке, для мониторинга и управления S.M.A.R.T. системой для локальных жестких дисков. Набор инструментов для мониторинга и управления S.M.A.R.T. системой должен быть активен и включён по умолчанию и должен выполнять следующие функции: • сканирование дисков каждые 30 минут на наличие ошибок и предупреждений; • отправка сообщений электронной почты пользователю root при обнаружении проблем. • При повторе ошибок узел должен отсылать электронное сообщение каждые 24 часа; Система управления средой виртуализации иметь штатные инструменты регистрации событий и обеспечивать возможность просмотра истории событий и системных журналов каждого отдельного узла кластера и каждой ВМ в веб-интерфейсе самой системы управления средой виртуализации, включая в себя выполнение заданий резервного копирования или восстановления. Журнал событий должен быть оснащен инструментами фильтрации по дате и времени события, по типу и ID ресурса, инициатору события, типу события, статусу события; Система управления средой виртуализации должна поддерживать следующие технологии оптимизации памяти: • Thin Provisioning; • KSM; • Memory balooning; • NUMA. Система управления средой виртуализации должна предоставлять возможность создания общего хранилища со следующими функциональными возможностями: • миграция ВМ в реальном масштабе времени; • плавное расширение пространства хранения с множеством узлов; • централизованное резервное копирование; • многоуровневое кэширование данных; • централизованное управление хранением - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 5) - Система управления средой виртуализации должна поддерживать следующие методы организации хранения данных: • ZFS (локальный/over iSCSI); • Каталог; • BTRFS; • NFS; • CIFS; • GlusterFS; • Ceph версий 15 Octopus и 16 Pacific; • OCFS2; • LVM; • LVM-thin; • iSCSI; • Ceph/RBD. В системе управления средой виртуализацией должна быть реализована возможность хранить образы ВМ на нескольких локальных хранилищах или в общем хранилище; Для хранения всех файлов конфигурации, связанных с системой управления виртуализацией, в системе управления виртуализацией должна быть реализована кластерная файловая система, управляемая базой данных, для хранения файлов конфигурации, реплицируемых в реальном времени на все узлы кластера с помощью corosync. Такая система хранения должна позволять реализовать: • бесшовную репликацию всей конфигурации на все узлы в реальном времени; • строгие проверки согласованности, чтобы избежать дублирования идентификаторов виртуальных машин; • режим «только для чтения», когда узел теряет кворум; • автоматическое обновление конфигурации кластера corosync для всех узлов; • механизм распределенной блокировки. В системе управления виртуализацией должна быть обеспечена поддержка подключения к СХД по протоколам FC/iSCSI (поддержка блочного доступа к данным по сети SAN) - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 6) - Хранилище в системе управления виртуализацией должно поддерживать несколько типов содержимого: образы виртуальных дисков, ISO-образы компакт-дисков, шаблоны ВМ и контейнеров, корневые каталоги контейнеров. Настройка должна быть доступна с помощью графического интерфейса; В системе управления виртуализацией должна быть предусмотрена возможность выбора назначения создаваемого хранилища по типу файловой системы и контенту. Настройка должна быть доступна с помощью графического интерфейса; В системе управления средой виртуализации должна быть предусмотрена возможность управления ограничением дисковой пропускной способностью. Настройка должна быть доступна с помощью графического интерфейс; В системе управления средой виртуализацией должны быть реализованы штатные инструменты выбора версии, развертывания, управления и мониторинга Ceph и его отдельных компонент: сервер метаданных (MDS), OSD, клиентов Ceph, пулов Ceph; Система управления средой виртуализации должна обеспечивать возможность добавления дополнительных узлов в кластер после его создания. При добавлении узлов в кластер в системе управления виртуализацией должна автоматически обновляться и добавляться информация об узлах в файле настройки кластера; Система управления средой виртуализации должна позволять централизованное управление с любого узла дата-центра всеми ресурсами внутри ее контура: • дата-центр; • кластеры; • узлы; • сети; • хранилища; • пулы ресурсов: виртуальные машины, контейнеры, шаблоны; • резервные копии; • пользователи и разрешения - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 7) - Для обеспечения высокой надежности и отказоустойчивости система управления средой виртуализации не должна требовать отдельной установки менеджера управления на отдельную физическую или виртуальную машину; Для обеспечения согласованного состояния всех узлов кластера система управления средой виртуализации должна поддерживать режим работы «кворум»; В графическом интерфейсе системы управления средой виртуализации должно отражаться состояние кворума, а также проверка последнего временного штампа жизнеспособности (heartbeat timestamp); Система управления средой виртуализации должна поддерживать режим работы Qdevice и гарантировать кворум с четным числом узлов; В системе управления средой виртуализации для всех узлов кластера должен использоваться диспетчер отказоустойчивости — служба, управляющая политиками отказоустойчивости и высокой доступности среды виртуализации, которые описывают сценарий действий для физических и виртуальных ресурсов дата-центра; Для обеспечения корректной работы в режиме отказоустойчивости и диспетчера отказоустойчивости в системе управления средой виртуализации должен быть реализован планировщик ресурсов с функцией автоматического анализа утилизации ресурсов и распределения ресурсов согласно заданным политикам - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 8) - Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать и применять следующие политики выключения для узлов: • Conditional — режим автоматически определяет, требуется ли выключение или перезагрузка, и соответствующим образом меняет поведение вычислительного узла. • Failover — режим гарантирует, что все службы будут остановлены, но они также будут восстановлены, если текущий узел не будет подключен к сети в ближайшее время. • Freeze — режим гарантирует, что все службы будут остановлены и заморожены и не будут восстановлены до тех пор, пока текущий узел снова не будет подключен к сети. • Migrate — режим инициирует миграцию всех служб, находящихся в данный момент на том узле, на котором запланировано выключение. • Настройка режимов должна быть доступна с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 9) - Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать объединение узлов в группы отказоустойчивости для возможности восстановления виртуальных сервисов только на определенных узлах. Настройки таких групп должны обеспечивать указание приоритизации для восстановления виртуальных ресурсов (ВМ или контейнер). Настройки должны быть доступны с помощью графического интерфейса; Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать индивидуальные политики отказоустойчивости и применять их к выделенным виртуальным ресурсам (ВМ или контейнер): • ID ресурса — номер ВМ или контейнера; • состояние ресурса при восстановлении — запущен, восстановлен, не требует восстановления, отключен; • количество попыток восстановления; • количество попыток перемещения; • группы отказоустойчивости. • Настройки должны быть доступны с помощью графического интерфейса. В системе управления средой виртуализации должен быть реализован «режим обслуживания» с функцией автоматической миграции виртуальных машин; Система управления средой виртуализации должна позволять создавать отказоустойчивую мультикластерную инфраструктуру; Система управления средой виртуализации должна позволять создавать отказоустойчивую геораспределенную инфраструктуру; Система управления средой виртуализации должна позволять настройку сетевых соединений как децентрализованно на уровне узла, так и централизованно на уровне дата-центра - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 10) - В системе управления виртуализацией должны быть реализованы штатные графические инструменты создания и управления сетью со следующими функциями: • создание Linux/OVS Bridge соединений; • создание Linux/OVS Bond соединений; • создание Linux/OVS VLAN соединений; • поддержка алиаса для сетевых соединений; • создание виртуальных разделённых сетевых зон и управление ими; • создание виртуальных сетевых мостов и управление подсетями; • поддержка протоколов IPv4/IPv6; • поддержка виртуальных коммутаторов с технологией VXLAN (Virtual Extensible LAN); • поддержка трансляции сетевых адресов; • поддержка Jumbo frames до 9000; • поддержка маркировки QoS: 802.1p, DSCP; • поддержка проброса PCI устройств (SR-IOV); • поддержка протокола LLDP (Link Layer Discovery Protocol); • поддержка сетевых адаптеров не менее 10/40/100 Гб/сек. Система управления средой виртуализации должна позволять использование ВМ и контейнерами как одного моста, так и позволять создание нескольких мостов для разделения сетевых доменов (до 4094 мостов); Система управления средой виртуализации должна поддерживать объединение сетевых адаптеров/агрегацию каналов (bonding): циклическая передача (balance-rr), активное резервное копирование (active-backup), XOR (balance-xor), броадкаст (broadcast), IEEE 802.3ad (802.3ad) (LACP), режим адаптивной балансировки нагрузки при передаче (balance-tlb), режим адаптивной балансировки нагрузки (balance-alb); Сетевые настройки системы управления виртуализации должны позволять использование тегирования для VLAN. Настройка должна быть доступна с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 11) - Система управления средой виртуализации должна быть оснащена штатным фаерволом. Штатный фаервол должен группировать сеть на логические зоны по параметрам: • трафик от/к узлу кластера; • трафик от/к конкретной ВМ. Сетевые настройки (в том числе и в графическом интерфейсе системы) должны поддерживать возможность назначения правил фаервола для входящего и/или исходящего трафика: • для всего дата-центра; • для конкретного узла в кластере; • для конкретной ВМ. Настройки фаервола системы управления средой виртуализации должны позволять создавать секретные группы или группы безопасности. Настройки должны быть доступны с помощью графического интерфейса; Система управления средой виртуализации должна быть оснащена штатным сервером аутентификации; Система управления средой виртуализации должна поддерживать возможность интеграции внешних серверов аутентификации (Active Directory, LDAP, Linux PAM, OpenID) и обеспечивать синхронизацию с ними. Настройка должна быть доступна и в графическом интерфейсе; Система управления средой виртуализации должна поддерживать двухфакторную аутентификацию с использованием следующих методов: • TOTP; • Yubikey OTP; • WebAuthn; • одноразовые ключи восстановления. • Настройка должна быть доступна с помощью графического интерфейса. Система управления средой виртуализации должна определять многоуровневый доступ, используя основанное на ролях управление пользователями и разрешениями для всех объектов (ВМ, хранилищ, узлов и т. д.). Настройки должны быть доступны с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 12) - Система управления средой виртуализации должна иметь по умолчанию не менее 12 предопределенных ролей: • Administrator?—?имеет все привилегии; • NoAccess?—?нет привилегий (используется для запрета доступа); • Admin?—?все привилегии, кроме прав на изменение настроек системы; • Auditor?—?доступ только для чтения; • DatastoreAdmin?—?создание и выделение места для резервного копирования и шаблонов; • DatastoreUser?—?выделение места для резервной копии и просмотр хранилища; • PoolAdmin?—?выделение пулов; • SysAdmin?—?ACL пользователя, аудит, системная консоль и системные журналы; • TemplateUser?—?просмотр и клонирование шаблонов; • UserAdmin?—?администрирование пользователей; • VMAdmin?—?управление ВМ; • VMUser?—?просмотр, резервное копирование, настройка CDROM, консоль ВМ, управление питанием ВМ. Система управления средой виртуализации должна быть оснащена штатным конструктором ролей и обеспечивать возможность создание новых ролей. Настройка должна быть доступна с помощью графического интерфейса; Для оптимизации контроля доступа система управления средой виртуализации должна поддерживать группировку ресурсов (ВМ и хранилищ) в отдельные пулы с возможностью наделения индивидуальными разрешениями. Настройка должна быть доступна с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 13) - Система управления средой виртуализации должна поддерживать возможность создавать виртуальную машину как из шаблона, так и без него. Настройка должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать возможность создавать виртуальную машину с несколькими дисками. Настройка должна быть доступна с помощью графического интерфейса; Для обеспечения высокой производительности система управления средой виртуализации должна поддерживать возможность задавать настройки многопоточности и ограничения пропускной способности при создании виртуальной машины. Настройка должна быть доступна с помощью графического интерфейса; Для обеспечения высокой производительности система управления средой виртуализации должна поддерживать горячее добавление ресурсов vCPU, vRAM, vDisk, USB, vNIC без остановки или перезагрузки ВМ. Настройка должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать как оффлайн-миграцию ВМ, так и живую миграцию - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 14) - Система управления средой виртуализации должна поддерживать следующие действия над ВМ и режимы работы ВМ, в том числе и в графическом интерфейсе: • запуск; • останов; • пауза; • гибернация; • перезагрузка; • сброс. Система управления средой виртуализации должна поддерживать доступ к консоли ВМ и манипуляции в ВМ как в отдельном сеансе, так и в веб-интерфейсе самой системы управления средой виртуализации; Система управления средой виртуализации должна поддерживать различные варианты копирования ВМ: • полный клон; • связанный клон; • моментальный снимок. Система управления средой виртуализации должна поддерживать следующие протоколы для доступа к консоли ВМ: VNC, SPICE, RDP; Система управления средой виртуализации должна поддерживать массовые операции над ВМ: миграция, старт, выключение. Опция должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать миграцию и импорт из других платформ и гипервизоров: P2V, V2V (Vmware, Hyper-V, KVM, oVirt) с использованием штатных инструментов самой системы управления средой виртуализации - - Значение характеристики не может изменяться участником закупки

Требования к контейнеризации (ч.1) - Операционная система в соответствии с документом «Требования по безопасности информации к средствам контейнеризации» (ФСТЭК России, 2022, приказ № 118) по 4-му классу защиты должна реализовывать следующие функции безопасности: • изоляция контейнеров; • выявление уязвимостей в образах контейнеров; • проверка корректности конфигурации контейнеров; • контроль целостности контейнеров и их образов; • регистрация событий безопасности; • управление доступом; • идентификация и аутентификация пользователей; • централизованное управление образами контейнеров и контейнерами в средстве контейнеризации. Операционная система должна предоставлять сертифицированные средства контейнеризации (kubernetes или эквивалент, podman или эквивалент) имеющие возможность запуска от непривилегированного пользователя без необходимости запуска какого-либо демона/службы; Все инструменты, в том числе контейнеры, должны входить в состав дистрибутива операционной системы и устанавливаться без обращения по сети к внешним источникам. Набор контейнеров должен включать базовые контейнеры, в том числе и distroless-образ и набор контейнеров для разворачивания кластера kubernetes - - Значение характеристики не может изменяться участником закупки

Требования к контейнеризации (ч.2) - Средства управления образами контейнеров и контейнерами (оркестратор или аналог) должны обеспечивать следующие функции: • создание, модификацию, хранение, получение и удаление образов контейнеров в информационной (автоматизированной) системе; • обновление средства контейнеризации и образов контейнеров из реестра вендора; • чтение, удаление записей о событиях безопасности, формирование отчетов с учетом заданных критериев отбора, выгрузку (экспорт) данных из журнала событий безопасности средства контейнеризации; • анализ возникающих событий безопасности в целях выявления инцидентов безопасности. Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции изоляции контейнеров: • изоляция пространств идентификаторов процессов; • изоляция пространств имен для межпроцессного взаимодействия; • изоляция пространств имен для пользователей и групп; • изоляция пространств имен хостов и доменов; • изоляция сетевых пространств имен; • изоляция пространств имен для иерархии каталогов. В дистрибутиве операционной системы должна быть реализована ролевая модель управления доступом: разработчик образов контейнеров, администратор безопасности средств контейнеризации, администратор информационной (автоматизированной) системы - - Значение характеристики не может изменяться участником закупки

Требования к контейнеризации (ч.3) - Дистрибутив операционной системы должен реализовывать следующие требования к функциям идентификации и аутентификации пользователей: • аутентификация пользователей по паролю; • пароль пользователя должен устанавливаться администратором безопасности средства контейнеризации; • средство контейнеризации должно обеспечивать возможность смены установленного администратором безопасности средства контейнеризации пароля пользователя после его первичной аутентификации; • при попытке ввода неправильного значения пароля пользователя должно выводиться соответствующее сообщение с приглашением ввести правильный пароль еще раз; • при исчерпании установленного максимального количества неуспешных попыток ввода неправильного пароля учетная запись пользователя средства контейнеризации должна быть заблокирована; • разблокировка учетной записи пользователя средства контейнеризации должна осуществляться администратором безопасности средства контейнеризации; • защита пароля пользователя должна обеспечиваться при его вводе за счет отображения вводимых символов условными знаками; • средство контейнеризации должно обеспечивать хранение аутентификационной информации пользователя средства контейнеризации в защищенном формате или в защищенном хранилище; • средство контейнеризации не должно запускать процессы в хостовой операционной системе, обладающие привилегиями администратора информационной (автоматизированной) системы и администратора безопасности информационной (автоматизированной) системы; • пароль пользователя средства контейнеризации должен содержать не менее 8 символов при алфавите пароля не менее 70 символов. Максимальное количество неуспешных попыток аутентификации (ввода неправильного пароля) до блокировки — 4. • указанные условия должны быть преднастроены в дистрибутиве операционной системы в рамках парольной политики по умолчанию - - Значение характеристики не может изменяться участником закупки

Требования к контейнеризации (ч.4) - Дистрибутив операционной системы должен реализовывать специальный механизм по выявлению уязвимостей в образах контейнеров с учетом следующих требований: • выявление известных уязвимостей при создании, первичном запуске и хранении образов контейнеров, самостоятельно или во взаимодействии с сертифицированным средством контроля и анализа защищенности на основе сведений, содержащихся в банке данных угроз безопасности информации БДУ ФСТЭК России (https://bdu.fstec.ru/), а также в иных источниках, содержащих сведения об известных уязвимостях; • оповещение о выявленных уязвимостях в образах контейнеров разработчика образов контейнеров и администратора информационной (автоматизированной) системы; • средство контейнеризации должно обеспечивать запрет создания образов контейнеров, содержащих известные уязвимости критического и высокого уровня опасности (уровень опасности определяется по значению (V) CVSS в CVE). Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции управления конфигурацией: • возможность ограничения прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование периферийных устройств, устройств хранения данных и съемных машинных носителей информации (блочных устройств), входящих в состав информационной (автоматизированной) системы; • возможность ограничения прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование вычислительных ресурсов (оперативной памяти, операций ввода-вывода за период времени) хостовой операционной системы; • запрет возможности монтирования средством контейнеризации корневой файловой системы хостовой операционной системы (за исключением режима «только для чтения») - - Значение характеристики не может изменяться участником закупки

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

Требования к контейнеризации (ч.6) - Средства контейнеризации дистрибутива операционной системы должны соответствовать следующим требованиям к регистрации событий безопасности: • для регистрируемых событий безопасности в каждой записи журнала событий безопасности должны регистрироваться номер (уникальный идентификатор) события, дата, время, тип события безопасности; • записи журнала событий безопасности должны представляться в структурированном виде и содержать время события безопасности, взятое из хостовой операционной системы; • должна быть обеспечена запись событий безопасности контейнеров в журнал событий безопасности информационной (автоматизированной) системы с указанием идентификатора контейнера; • журнал событий безопасности средства контейнеризации должен быть доступен только для чтения. При исчерпании области памяти, отведенной под журнал событий безопасности средства контейнеризации, должно осуществляться его архивирование с последующей очисткой; • регистрации подлежат следующие события безопасности: a. неуспешные попытки аутентификации пользователей средства контейнеризации; b. создание, модификация и удаление образов контейнеров; c. получение доступа к образам контейнеров; d. запуск и остановка контейнеров с указанием причины остановки; e. изменение ролевой модели; f. модификация запускаемых контейнеров; g. выявление известных уязвимостей в образах контейнеров и некорректности конфигурации; h. факты нарушения целостности объектов контроля. • должна обеспечиваться запись событий безопасности контейнеров в журнал событий безопасности с указанием идентификатора пользователя хостовой операционной системы, от имени которого был запущен контейнер - - Значение характеристики не может изменяться участником закупки

Нефункциональные требования - Разработчик обязан оказывать гарантийную вендорскую поддержку продукта (оперативный выпуск обновлений по безопасности); Разработчик обязан оказывать техническую поддержку пользователям на условиях SLA в течение первого года использования. Для критических инцидентов должно быть обеспечено время реакции не более 8 часов в период с 9:00 до 19:00 в рабочие дни; Система должна быть основана на программном обеспечении с открытым исходным кодом - - Значение характеристики не может изменяться участником закупки

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Для наиболее полного описания потребности Заказчика

- 58.29.11.000 58.29.11.000-00000003 - Программное обеспечение Вид лицензии Простая (неисключительная) Класс программ для электронных вычислительных машин и баз данных (02.09) Операционные системы общего назначения Способ предоставления Копия электронного экземпляра - Штука - 3,00 - 96 250,00 - 288 750,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Вид лицензии Простая (неисключительная) Значение характеристики не может изменяться участником закупки Класс программ для электронных вычислительных машин и баз данных (02.09) Операционные системы общего назначения Значение характеристики не может изменяться участником закупки Способ предоставления Копия электронного экземпляра Значение характеристики не может изменяться участником закупки Общие требования Программное обеспечение должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных Минкомсвязи РФ по классам «Операционные системы общего назначения», «Средства виртуализации», «Серверное и связующее программное обеспечение», «Средства управления базами данных», «Системы контейнеризации и контейнеры», «Средства защиты от несанкционированного доступа к информации»; Операционная система должна соответствовать требованиям документов: «Требования безопасности информации к операционным системам» (ФСТЭК России, 2016) и «Профиль защиты операционных систем типа «А» четвертого класса защиты ИТ.ОС.А4.ПЗ» (ФСТЭК России, 2017) ; «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» не ниже четвертого уровня доверия (приказ ФСТЭК России № 76 от 2 июня 2020 г.); «Требования по безопасности информации к средствам контейнеризации» (приказ ФСТЭК России № 118, 2022,) не ниже 4 класса защиты; «Требования по безопасности информации к средствам виртуализации» (приказ ФСТЭК России, № 187, 2022 г.) не ниже 4 класса защиты; «Требования по безопасности информации к системам управления базами данных» (приказ ФСТЭК России № 64, 2023 г.) не ниже 4 класса защиты; В Формуляре ОС должны быть указаны интерпретаторы, веб сервера и сервера приложений, проверенные согласно документу: «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении», утверждена ФСТЭК России 25.12.2020 г.; Разработчик должен иметь собственную инфраструктуру разработки полного цикла, зарегистрированную и находящуюся на территории РФ, в исключительной юрисдикции РФ; Наличие в России локализованной сервисной и/или технической поддержки Значение характеристики не может изменяться участником закупки Функциональные требования (ч.1) Операционная система должна устанавливаться и функционировать на компьютерах с архитектурами x86_64 (64-разрядный процессор Intel или AMD), aarch64 («Байкал», Rockchip 3588) и «Эльбрус» (процессоры 8С, 1С+, 8СВ, 2С3, 12С, 16С) должны быть отдельные образы в сертифицированном исполнении для каждой архитектуры. Требования перечисленные в данном документе относятся к архитектуре x86_64 и могут отличатся от требований к другим архитектурам. Операционная система должна поддерживать режимы установки и загрузки Legacy/CSM, UEFI (с включенным механизмом SecureBoot), а также средствами BMC/IPMI (если поддерживается оборудованием). Операционная система должна иметь в составе ядро не ниже 6.12 (LTS) для обеспечения корректного функционирования современных средств вычислительной техники. Система должна пре доставлять графические утилиты для установки, удаления и обновления ядра, включая модули, а также для выбора ядра по умолчанию. Операционная система должна обеспечивать поддержку нескольких видеокарт (работа на нескольких мониторах). Операционная система должна обладать русифицированным интерфейсом, а также предоставлять русскоязычную документацию. Операционная система должна иметь возможность установки с DVD-диска и USB-накопителя. Операционная система должна предоставлять варианты сетевой установки: PXE/TFTP (для режима Legacy/CSM-загрузки), HTTPClient (для спецификации UEFI 2.5 и выше), iPXE Операционная система должна предоставлять возможность организации сервера сетевой загрузки. Операционная система должна предоставлять возможность установки на оборудование без графической подсистемы с локального накопителя, а также установки с использованием сервера сетевой установки по протоколу VNC Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 2) Носитель с дистрибутивом ОС должен предусматривать вариант загрузки для проведения работ по восстановлению системы, включая проверку сохранности содержимого файловой системы и проверку контрольных сумм неизменяемых файлов установленных пакетов, диагностику конфигурации аппаратного обеспечения, изменение таблицы и размеров разделов, изменение параметров файловых систем, восстановление удаленных разделов и файлов, проведение резервного копирования, очистку остаточной информации на разделах и дисках; Операционная система должна иметь возможность установки на программный RAID-массив, размещения разделов в томах LVM и использования маскирования (кодирования) разделов с парольным доступом; Операционная система должна обеспечивать возможность создания точек восстановления (снапшотов) для последующего возвращения системы к исходному состоянию в случае сбоя; Инсталлятор дистрибутива должен предусматривать возможность предварительной (OEM) установки, позволяющей при первом запуске пользователем после установки выбрать язык, принять лицензионное соглашение, настроить дату/время, настроить сеть, задать пароль root, создать системного пользователя; Операционная система должна предоставлять независимый выбор основных и дополнительных приложений в момент установки: серверные приложения (dhcp, dns,ftp, http, почтовый сервер, сервер резервного копирования, сервер печати, сервер сетевой установки), сканер обнаружения уязвимостей, сервер сертифицированной СУБД, сервер управления конфигурациями, сервер виртуальных рабочих столов, средства управления контейнеризацией, средства управления виртуализацией Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 3) Операционная система после установки должна предоставлять пользователю рабочую среду, включающую системное ПО, сетевые службы и сервисы, драйвера устройств, утилиты администрирования, базовый набор приложений; Если установлена графическая среда, операционная система должна предоставлять графическое средство настройки многопользовательского режима, позволяющего обеспечить одновременную работу нескольких пользователей на одном компьютере при наличии отдельной видеокарты, клавиатуры и мыши для каждого пользователя; Операционная система должна предоставлять инструмент для поиска уязвимостей в файлах конфигурации, файловых системах, используемых пакетах ОС (включая программные зависимости), образах контейнеров и git-репозиториях. Анализ уязвимостей должен осуществляться как по вендорской базе уязвимостей (CVE), собранной из разных источников, так и по базе уязвимостей (BDU) ФСТЭК России; Операционная система должна предоставлять возможность установки пароля на загрузчик для ограничения доступа к опциям загрузки; Операционная система должна предоставлять возможность блокировки виртуальных текстовых консолей. Комплекс средств защиты ОС должен обеспечивать выполнение программ в защищенной среде. В состав ОС должны быть включены программные интерпретаторы (php, perl, lua, python, nodejs) и веб-сервер (nginx), прошедшие испытания по выявлению уязвимостей и недекларированных возможностей в полном объеме в соответствии с Методикой выявления уязвимостей и недекларированных возможностей в программном обеспечении, утвержденной ФСТЭК России 25.12.2020 г.; Операционная система должна включать приложение для мониторинга ресурсов. Должно быть обеспечено централизованное управление конфигурациями прав доступа к утилите мониторинга температуры жесткого диска Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 4) Операционная система должна предоставлять единый графический модульный интерфейс для администрирования и настроек, а также предоставлять возможность удаленного администрирования по защищенным протоколам с помощью графических утилит (включая конфигурирование установленной системы через веб). Администратор должен иметь возможность назначить права доступа для пользователей к определенным модулям. В состав базовых сервисов должны входить: • настройка даты и времени; • управление системными службами; • просмотр системных журналов; • конфигурирование сетевых подключений и межсетевого экрана; • установка обновлений, в том числе для компьютеров без доступа в интернет; • управление выключением удаленного компьютера; • управление пользователями; • настройка пользовательских квот на использование ресурсов памяти, диска и внешних носителей. Операционная система должна реализовывать возможность хранения аутентификационной информации пользователей, полученной с использованием хеш-функций по ГОСТ Р 34.11-2012. Реализация функционала должна быть обеспечена как консольными, так и графическими утилитами; Операционная система должна обеспечивать возможность создания ssh-туннелей, использующих контроль целостности заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015; Операционная система должна предоставлять возможность авторизации по смарт-картам в консольном режиме; Операционная система должна предоставлять протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе; Операционная система должна предоставлять возможность разграничения доступа к подключаемым устройствам Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 5) Операционная система должна иметь возможность организации домена Samba-DC или интеграции с доменом Active Directory с поддержкой следующего функционала: • действовать в качестве первичного или вторичного контроллера домена; • аутентификация рабочих станций; • авторизация и предоставление ресурсов без дополнительного ввода пароля (Single Sign-On); • поддержка ролей и привилегий (назначение ролей группам); • групповые политики (GPO); Операционная система должна предоставлять возможность организации трастовых доменов Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 6) При работе в гетерогенной среде домена Active Directory (нативного или создаваемого с помощью проекта Samba) должны быть доступны, при использовании инструмента RSAT в среде Windows или с помощью собственного приложения, следующие политики для управления компьютерами и доменными пользователями, работающими на них: • Настройка установки программного обеспечения из репозитория. • Исполнение любых скриптов при включении/выключении компьютера или входе/выходе пользователя в систему. • Разрешение/Запрет на подключение класса съемных накопителей для компьютера или отдельных пользователей. • Управление ярлыками для компьютера или пользователей. • Централизованное управление конфигурациями сервисов systemd, включая интерфейс-терминала смарт-карт (openct), диспетчер авторизации (polkit), службы аудита безопасности (auditd). • Централизованное управление конфигурациями системных сервисов (CUPS, SSHD, NTP Chrony, Postfix MTA и postqueue, DNS, OpenLDAP, Rpcbind, SSSD, очередь заданий) и утилит определения прав доступа к модификации учетных записей, паролей, пользователей (включая создание индивидуальных временных каталогов) и групп, а также к утилитам su/sudo. • Централизованное управление конфигурациями прав доступа монтирования съемных накопителей, пользовательских файловых систем, подключения сетевых ресурсов по nfs. • Управление файлами и папками (создание, удаление, перемещение, копирование, предоставление общего доступа или скрытие). • Управление настройками приложений через ini-файлы. • Управление интервалом времени применения групповой политики. • Управление всеми политиками веб-браузеров Mozilla Firefox и Chromium. • Возможность принудительного выполнения политики на клиенте Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 7) Операционная система должна предоставлять возможность организации и настройки базовых сетевых сервисов и служб: • sshd; • DNS; • DHCP; • протокол аутентификации LDAP; • OpenVPN; • SMTP, POP3/IMAP (postfix, dovecot или эквивалент); • межсетевой экран; • проксирование HTTP- и FTP-запросов (squid или эквивалент); • резервное копирование (bacula или эквивалент); • сервер сетевой установки с веб-интерфейсом; • сервер обновлений с возможностью зеркалирования репозитория вендора ОС и создания служебных репозиториев используемого Заказчиком ПО; • защищенный сервер баз данных (PostgreSQL или эквивалент) с возможностью организации кластера из нескольких серверов, со встроенной реализацией функций round, trunc, date совместимой с Oracle DB; • веб-сервер; • FTP-сервер; • сервер мониторинга сетевых ресурсов с графическим интерфейсом (Zabbix, icinga2 или эквивалент); • сервер печати; • сервер групповой работы с веб-интерфейсом (SOGo или эквивалент); • сервер файлового обмена Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 8) Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - программное обеспечение (ПО) должно создавать и управлять резервными копиями виртуальных машин (ВМ), контейнеров и физических узлов, содержащие архивы файлов и образов; - ПО должно предоставлять интегрированный клиент для QEMU и LXC в виртуальной среде Proxmox; - ПО должно поддерживать резервное копирование на магнитную ленту и управление ленточными библиотеками; - ПО должно поддерживать дедупликацию, сжатие и аутентифицированое шифрование данных; - ПО должно использовать следующие алгоритмы сжатия данных lzo, gzip и zstd.; - ПО должно содержать в себе веб-интерфейс (RESTful API) управления со встроенной в него консолью, доступ должен осуществляться через системную аутентификацию Linux PAM. - ПО должно хранить данные резервных копий и предоставлять RESTful API для создания хранилищ данных и управления ими и другими ресурсами на стороне сервера; - ПО должно позволять с помощью API, предоставленного серверной частью, позволять клиенту резервного копирования получать доступ к сохранённым данным для создания и восстановления резервных копий файлов, а также для управления дисками и другими ресурсами на стороне сервера; - ПО должно использовать протокол TLS для обеспечения безопасности обмена данными между клиентской и серверной частями; - ПО должно использовать алгоритм AES-256 GCM при шифровании содержимого резервной копии на стороне клиента; - ПО должно позволять создавать хранилища данных с файловой системой форматов ext4, xfs.; - ПО должно содержать в себе набор инструментов, используемых для мониторинга и управления системой S.M.A.R.T. для локальных жёстких дисков, с возможностью отображения атрибутов S.M.A.R.T. из веб-интерфейса или при помощи командной строки; Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 9) Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - ПО должно идентифицировать каждое хранилище данных именем и указанием на каталог в файловой системе и связывать с каждым хранилищем параметры хранения, определяющие количество снимков резервных копий для каждого интервала времени: час, день, неделя, месяц, год; - ПО должно позволять создавать хранилища данных с возможностью выбора и настройки следующих параметров: название; путь к каталогу; количество резервных копий для хранения в этом хранилище; расписания периодического запуска удаления резервных копий и сборки мусора (удаления неиспользуемых блоков данных); - ПО должно позволять ограничить входящий (например, резервное копирование) и исходящий (например, восстановление) сетевой трафик из набора сетей, с возможностью настроить определенные периоды, в которые будут применяться ограничения; - ПО должно позволять создавать пользователей и управлять ими как из встроенного веб-интерфейса, так и с помощью командной строки, с возможностью создания/удаления/отключения учетных записей, просмотра списка пользователей с возможностью изменения любых свойств; - ПО должно позволять любому аутентифицированному пользователю генерировать API-токены и использовать их для настройки клиентов резервного копирования вместо прямого указания имени пользователя и пароля. API-токен должен отзываться в случае компрометации клиента и ограничивать разрешения для каждого клиента/токена в рамках разрешения пользователей. ПО должно создавать для токенов собственные записи ACL, где токены не могут делать больше, чем создавший их пользователь; Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 10) Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - ПО должно использовать систему управления разрешениями на основе ролей и путей, где роль содержит набор разрешенных действий, а путь представляет цель этих действий. По умолчанию разрешения созданным пользователям и API-токенам не должны предоставляться; - ПО должно предопределять следующий ряд ролей: нет привилегий (используется для запрета доступа); все привилегии; доступ только для чтения; все привилегии для хранилищ данных; просмотр настроек хранилищ и их содержимых, без возможности чтения фактических данных; просмотр содержимого хранилища, восстановление данных; создание и восстановление собственных резервных копий; создание, восстановление и удаление собственных резервных копий; все привилегии для удалённых серверов; просмотр настроек удалённых серверов; чтение данных с удалённых серверов; - ПО должно создавать, хранить и предоставлять следующую информацию о правах доступа: идентификатор ACL; включено или отключено; объект, на который установлено разрешение; пользователи/токены, для которых установлено разрешение; устанавливаемая роль. - ПО должно реализовывать возможность использования двухфакторной аутентификации с помощью веб-интерфейса тремя методами: TOTP (одноразовый пароль на основе времени) — для создания этого кода должен использоваться алгоритм одноразового пароля с учетом времени входа в систему (код меняется каждые 30 секунд); WebAuthn (веб-аутентификация) — реализуется с помощью различных устройств безопасности, таких как аппаратные ключи или доверенные платформенные модули (TPM). Для работы веб-аутентификации необходим сертификат HTTPS; Recovery Keys (одноразовые ключи восстановления) — список ключей, каждый из которых можно использовать только один раз. В каждый момент времени у пользователя может быть только один набор одноразовых ключей Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 11) Операционная система должна предоставлять возможность установления безопасных сетевых соединений по технологии VPN; Операционная система должна обеспечивать возможность создания VPN-туннелей, использующих контроль заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015; Операционная система должна реализовывать базовый функционал межсетевого экрана; Операционная система должна предоставлять возможность установки многоплатформенного брокера подключений для создания и управления виртуальными рабочими местами и приложениями (OpenUDS или аналог); Операционная система должна включать графическое приложение для мониторинга ресурсов и просмотра системных журналов; Операционная система должна предоставлять возможность одновременной работы пользователей в изолированных сеансах. Должны быть предусмотрены: • отдельное изолированное хранение данных аутентификации каждого пользователя системы таким образом, чтобы процессы аутентификации локального или сетевого пользователя не могли получить доступа к данным аутентификации и авторизации других пользователей системы; • поддержка изоляции временных пользовательских файлов Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 12) Операционная система должна включать автоматизированные средства изоляции приложений, чувствительных к сетевым атакам; Операционная система должна предоставлять упреждающие меры защиты и быть сконфигурирована с безопасными настройками по умолчанию; Операционная система должна предоставлять механизм управления фиксированными состояниями ключевых объектов безопасности системы, сохраняющий установленные права доступа к объектам файловой системы при обновлении пакетов; Операционная система должна обеспечивать поддержку шифрования по ГОСТ Р 34.11-2012 в OpenSSL, включая генерацию ключей и создание сертификатов; Операционная система должна предоставлять инструмент проверки контрольных сумм неизменяемых файлов установленных пакетов как при начальной установке, так и после получения обновлений. Вендор должен обеспечивать доступ к обновлениям и контрольным суммам неизменяемых файлов пакетов в них; Подсистема контроля целостности операционной системы должна поддерживать технологии IMA и EVM; Операционная система должна предоставлять возможность запрета запуска выбранных интерпретаторов в интерактивном режиме, отключения возможности удаления открытых файлов, а также установки запрета бита исполнения (SUID), распространяемого на дочерние процессы Значение характеристики не может изменяться участником закупки Функциональные требования (ч. 13) Операционная система должна поддерживать файловые системы ext2, ext3, ext4, btrfs для чтения/записи и установки, iso9660, xfs, fat16, fat32, ntfs.; Операционная система должна поддерживать сетевые протоколы SMB, NFS, FTP, NTP, HTTP(S); Операционная система должна предоставлять возможность доустановки необходимого программного обеспечения с диска или из репозитория, а также установки обновлений. Система должна обеспечить автоматическую проверку зависимостей (apt или эквивалент), а также возможность комплексного обновления системы с отдельным процессом установки ядра ядра с помощью графических утилит; Исходные коды, обновления, инструменты для сборки серверной ОС должны находиться в том же репозитории (хранилище), где хранятся исходные коды, обновления и инструменты для ОС рабочих станций; Операционная система должна предоставлять единую систему для установки прикладного программного обеспечения в системе (eepm или аналог). Также должна быть обеспечена возможность установки сторонних приложений в форматах deb, tgz, tbz, tbz2, pkg.gz.; Операционная система должна поддерживать корневые сертификаты Минцифры России. В составе дистрибутива должен присутствовать пакет с отечественными корневыми сертификатами шифрования; Операционная система должна поддерживать корневые сертификаты Российского центра сертификации ТЦИ, предоставляемые соответствующим пакетом из состава ОС Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 1) В средстве виртуализации должны быть реализованы следующие функции безопасности: • идентификация и аутентификация субъектов доступа и объектов доступа, в том числе администраторов управления средствами виртуализации; • управление доступом субъектов доступа к объектам, в том числе внутри виртуальных машин; • регистрация событий безопасности; • управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуальной инфраструктуры, а также по ее периметру; • управление перемещением виртуальных машин (контейнеров) и обрабатываемых на них данных; • контроль целостности виртуальной инфраструктуры и ее конфигураций; • резервное копирование данных, резервирование технических средств, программного обеспечения, а также внутренних каналов связи внутри виртуальной инфраструктуры; • сегментирование виртуальной инфраструктуры для обработки информации отдельным пользователем и (или) группой пользователей; В состав дистрибутива операционной системы должен входить следующий комплекс программных компонент для построения виртуальной инфраструктуры: • гипервизор KVM (или эквивалент); • эмулятор аппаратного обеспечения различных платформ QEMU (или эквивалент); • набор инструментов, предоставляющий единый API для технологий виртуализации (libvirt или эквивалент); • гиперконвергентная система управления средой виртуализации с централизованным управлением физическими и виртуальными ресурсами; • система резервного копирования, интегрированная в систему управления средой виртуализации Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 2) В состав дистрибутива операционной системы для обеспечения корректного функционирования современных средств виртуализации должны входить следующие компоненты: • ядро LTS не ниже 6.1.114; • systemd версии не ниже 249.17; • qemu версии не ниже 8.2; • libvirt версии не ниже 9.7; • corosync версии не ниже 3.1.8; • pacemaker версии не ниже 2.1.7; • keepalived версии не ниже 2.2.8; • Ceph версии не ниже 17.2; • Gluster версии не ниже 9.3. • Требование к версионности компонентов аргументируется наличием необходимого функционала и закрытыми уязвимостями в данных версиях; Система управления средой виртуализации должна обладать возможностью высокого масштабирования и поддерживать создание и управление виртуальной инфраструктурой со следующими параметрами лимитных значений: • максимальное количество физических серверов (узлов), поддерживаемых в составе кластера высокой доступности — не менее 128; • максимальное количество логических процессоров на хост-сервер — не менее 8192; • максимальный объем ОЗУ памяти на хост-сервер — не менее 32 ТБ; • поддержка в ВМ не менее 240 vCPU; • поддержка в ВМ ОЗУ не менее 4 TБ оперативной памяти; • поддержка объема виртуального диска для одной виртуальной машины не менее 64 TБ; • поддержка в ВМ виртуальных сетевых интерфейсов NICs для одной виртуальной машины не менее 10; • поддержка в ВМ виртуальных адаптеров SATA для одной виртуальной машины не менее 6 Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 3) Система управления средой виртуализации должна предоставлять возможность управления через интерфейс CLI, графический веб-интерфейс, а также интеграцию со сторонним программным обеспечением с помощью REST API; Система управления средой виртуализации должна поддерживать технологию Wake-on-LAN; Система управления средой виртуализации должна поддерживать режим вложенной виртуализации; Система управления средой виртуализации должна обеспечивать создание виртуальных машин (ВМ), их образов и шаблонов для гостевых операционных систем аппаратных архитектур AArch64 (ARMv8) и x86-64; В составе системы управления средой виртуализации должны быть реализованы штатные графические средства мониторинга. Штатная система мониторинга, встроенная в систему управления виртуализации, должна предоставлять обзор в графическом интерфейсе для следующих ресурсов: • отображать объем всех ресурсов в соотношении к доступным (CPU, RAM, сеть, хранилище); • отображать количество всех виртуальных машин и контейнеров, а также количество запущенных и выключенных экземпляров; • отображать реквизиты объектов виртуальной инфраструктуры: IP-адрес, имя владельца и/или группы, имя хоста, ID (UID); • иметь цветовую дифференциацию объектов в зависимости их статусов и объёмов нагрузки; • обеспечивать возможность подключения дополнительных модулей мониторинга Zabbix, Grafana, Prometheus для получения детализированный информации по развёрнутой виртуальной инфраструктуре, включая низкоуровневые интерфейсы; В графическом интерфейсе системы управления средой виртуализации должны быть представлены графические инструменты подключения серверов статистики InfluxDB и Graphite Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 4) Система управления средой виртуализации должна включать в себя набор инструментов, с отображением их в веб-интерфейсе и в командной строке, для мониторинга и управления S.M.A.R.T. системой для локальных жестких дисков. Набор инструментов для мониторинга и управления S.M.A.R.T. системой должен быть активен и включён по умолчанию и должен выполнять следующие функции: • сканирование дисков каждые 30 минут на наличие ошибок и предупреждений; • отправка сообщений электронной почты пользователю root при обнаружении проблем. • При повторе ошибок узел должен отсылать электронное сообщение каждые 24 часа; Система управления средой виртуализации иметь штатные инструменты регистрации событий и обеспечивать возможность просмотра истории событий и системных журналов каждого отдельного узла кластера и каждой ВМ в веб-интерфейсе самой системы управления средой виртуализации, включая в себя выполнение заданий резервного копирования или восстановления. Журнал событий должен быть оснащен инструментами фильтрации по дате и времени события, по типу и ID ресурса, инициатору события, типу события, статусу события; Система управления средой виртуализации должна поддерживать следующие технологии оптимизации памяти: • Thin Provisioning; • KSM; • Memory balooning; • NUMA. Система управления средой виртуализации должна предоставлять возможность создания общего хранилища со следующими функциональными возможностями: • миграция ВМ в реальном масштабе времени; • плавное расширение пространства хранения с множеством узлов; • централизованное резервное копирование; • многоуровневое кэширование данных; • централизованное управление хранением Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 5) Система управления средой виртуализации должна поддерживать следующие методы организации хранения данных: • ZFS (локальный/over iSCSI); • Каталог; • BTRFS; • NFS; • CIFS; • GlusterFS; • Ceph версий 15 Octopus и 16 Pacific; • OCFS2; • LVM; • LVM-thin; • iSCSI; • Ceph/RBD. В системе управления средой виртуализацией должна быть реализована возможность хранить образы ВМ на нескольких локальных хранилищах или в общем хранилище; Для хранения всех файлов конфигурации, связанных с системой управления виртуализацией, в системе управления виртуализацией должна быть реализована кластерная файловая система, управляемая базой данных, для хранения файлов конфигурации, реплицируемых в реальном времени на все узлы кластера с помощью corosync. Такая система хранения должна позволять реализовать: • бесшовную репликацию всей конфигурации на все узлы в реальном времени; • строгие проверки согласованности, чтобы избежать дублирования идентификаторов виртуальных машин; • режим «только для чтения», когда узел теряет кворум; • автоматическое обновление конфигурации кластера corosync для всех узлов; • механизм распределенной блокировки. В системе управления виртуализацией должна быть обеспечена поддержка подключения к СХД по протоколам FC/iSCSI (поддержка блочного доступа к данным по сети SAN) Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 6) Хранилище в системе управления виртуализацией должно поддерживать несколько типов содержимого: образы виртуальных дисков, ISO-образы компакт-дисков, шаблоны ВМ и контейнеров, корневые каталоги контейнеров. Настройка должна быть доступна с помощью графического интерфейса; В системе управления виртуализацией должна быть предусмотрена возможность выбора назначения создаваемого хранилища по типу файловой системы и контенту. Настройка должна быть доступна с помощью графического интерфейса; В системе управления средой виртуализации должна быть предусмотрена возможность управления ограничением дисковой пропускной способностью. Настройка должна быть доступна с помощью графического интерфейс; В системе управления средой виртуализацией должны быть реализованы штатные инструменты выбора версии, развертывания, управления и мониторинга Ceph и его отдельных компонент: сервер метаданных (MDS), OSD, клиентов Ceph, пулов Ceph; Система управления средой виртуализации должна обеспечивать возможность добавления дополнительных узлов в кластер после его создания. При добавлении узлов в кластер в системе управления виртуализацией должна автоматически обновляться и добавляться информация об узлах в файле настройки кластера; Система управления средой виртуализации должна позволять централизованное управление с любого узла дата-центра всеми ресурсами внутри ее контура: • дата-центр; • кластеры; • узлы; • сети; • хранилища; • пулы ресурсов: виртуальные машины, контейнеры, шаблоны; • резервные копии; • пользователи и разрешения Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 7) Для обеспечения высокой надежности и отказоустойчивости система управления средой виртуализации не должна требовать отдельной установки менеджера управления на отдельную физическую или виртуальную машину; Для обеспечения согласованного состояния всех узлов кластера система управления средой виртуализации должна поддерживать режим работы «кворум»; В графическом интерфейсе системы управления средой виртуализации должно отражаться состояние кворума, а также проверка последнего временного штампа жизнеспособности (heartbeat timestamp); Система управления средой виртуализации должна поддерживать режим работы Qdevice и гарантировать кворум с четным числом узлов; В системе управления средой виртуализации для всех узлов кластера должен использоваться диспетчер отказоустойчивости — служба, управляющая политиками отказоустойчивости и высокой доступности среды виртуализации, которые описывают сценарий действий для физических и виртуальных ресурсов дата-центра; Для обеспечения корректной работы в режиме отказоустойчивости и диспетчера отказоустойчивости в системе управления средой виртуализации должен быть реализован планировщик ресурсов с функцией автоматического анализа утилизации ресурсов и распределения ресурсов согласно заданным политикам Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 8) Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать и применять следующие политики выключения для узлов: • Conditional — режим автоматически определяет, требуется ли выключение или перезагрузка, и соответствующим образом меняет поведение вычислительного узла. • Failover — режим гарантирует, что все службы будут остановлены, но они также будут восстановлены, если текущий узел не будет подключен к сети в ближайшее время. • Freeze — режим гарантирует, что все службы будут остановлены и заморожены и не будут восстановлены до тех пор, пока текущий узел снова не будет подключен к сети. • Migrate — режим инициирует миграцию всех служб, находящихся в данный момент на том узле, на котором запланировано выключение. • Настройка режимов должна быть доступна с помощью графического интерфейса Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 9) Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать объединение узлов в группы отказоустойчивости для возможности восстановления виртуальных сервисов только на определенных узлах. Настройки таких групп должны обеспечивать указание приоритизации для восстановления виртуальных ресурсов (ВМ или контейнер). Настройки должны быть доступны с помощью графического интерфейса; Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать индивидуальные политики отказоустойчивости и применять их к выделенным виртуальным ресурсам (ВМ или контейнер): • ID ресурса — номер ВМ или контейнера; • состояние ресурса при восстановлении — запущен, восстановлен, не требует восстановления, отключен; • количество попыток восстановления; • количество попыток перемещения; • группы отказоустойчивости. • Настройки должны быть доступны с помощью графического интерфейса. В системе управления средой виртуализации должен быть реализован «режим обслуживания» с функцией автоматической миграции виртуальных машин; Система управления средой виртуализации должна позволять создавать отказоустойчивую мультикластерную инфраструктуру; Система управления средой виртуализации должна позволять создавать отказоустойчивую геораспределенную инфраструктуру; Система управления средой виртуализации должна позволять настройку сетевых соединений как децентрализованно на уровне узла, так и централизованно на уровне дата-центра Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 10) В системе управления виртуализацией должны быть реализованы штатные графические инструменты создания и управления сетью со следующими функциями: • создание Linux/OVS Bridge соединений; • создание Linux/OVS Bond соединений; • создание Linux/OVS VLAN соединений; • поддержка алиаса для сетевых соединений; • создание виртуальных разделённых сетевых зон и управление ими; • создание виртуальных сетевых мостов и управление подсетями; • поддержка протоколов IPv4/IPv6; • поддержка виртуальных коммутаторов с технологией VXLAN (Virtual Extensible LAN); • поддержка трансляции сетевых адресов; • поддержка Jumbo frames до 9000; • поддержка маркировки QoS: 802.1p, DSCP; • поддержка проброса PCI устройств (SR-IOV); • поддержка протокола LLDP (Link Layer Discovery Protocol); • поддержка сетевых адаптеров не менее 10/40/100 Гб/сек. Система управления средой виртуализации должна позволять использование ВМ и контейнерами как одного моста, так и позволять создание нескольких мостов для разделения сетевых доменов (до 4094 мостов); Система управления средой виртуализации должна поддерживать объединение сетевых адаптеров/агрегацию каналов (bonding): циклическая передача (balance-rr), активное резервное копирование (active-backup), XOR (balance-xor), броадкаст (broadcast), IEEE 802.3ad (802.3ad) (LACP), режим адаптивной балансировки нагрузки при передаче (balance-tlb), режим адаптивной балансировки нагрузки (balance-alb); Сетевые настройки системы управления виртуализации должны позволять использование тегирования для VLAN. Настройка должна быть доступна с помощью графического интерфейса Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 11) Система управления средой виртуализации должна быть оснащена штатным фаерволом. Штатный фаервол должен группировать сеть на логические зоны по параметрам: • трафик от/к узлу кластера; • трафик от/к конкретной ВМ. Сетевые настройки (в том числе и в графическом интерфейсе системы) должны поддерживать возможность назначения правил фаервола для входящего и/или исходящего трафика: • для всего дата-центра; • для конкретного узла в кластере; • для конкретной ВМ. Настройки фаервола системы управления средой виртуализации должны позволять создавать секретные группы или группы безопасности. Настройки должны быть доступны с помощью графического интерфейса; Система управления средой виртуализации должна быть оснащена штатным сервером аутентификации; Система управления средой виртуализации должна поддерживать возможность интеграции внешних серверов аутентификации (Active Directory, LDAP, Linux PAM, OpenID) и обеспечивать синхронизацию с ними. Настройка должна быть доступна и в графическом интерфейсе; Система управления средой виртуализации должна поддерживать двухфакторную аутентификацию с использованием следующих методов: • TOTP; • Yubikey OTP; • WebAuthn; • одноразовые ключи восстановления. • Настройка должна быть доступна с помощью графического интерфейса. Система управления средой виртуализации должна определять многоуровневый доступ, используя основанное на ролях управление пользователями и разрешениями для всех объектов (ВМ, хранилищ, узлов и т. д.). Настройки должны быть доступны с помощью графического интерфейса Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 12) Система управления средой виртуализации должна иметь по умолчанию не менее 12 предопределенных ролей: • Administrator?—?имеет все привилегии; • NoAccess?—?нет привилегий (используется для запрета доступа); • Admin?—?все привилегии, кроме прав на изменение настроек системы; • Auditor?—?доступ только для чтения; • DatastoreAdmin?—?создание и выделение места для резервного копирования и шаблонов; • DatastoreUser?—?выделение места для резервной копии и просмотр хранилища; • PoolAdmin?—?выделение пулов; • SysAdmin?—?ACL пользователя, аудит, системная консоль и системные журналы; • TemplateUser?—?просмотр и клонирование шаблонов; • UserAdmin?—?администрирование пользователей; • VMAdmin?—?управление ВМ; • VMUser?—?просмотр, резервное копирование, настройка CDROM, консоль ВМ, управление питанием ВМ. Система управления средой виртуализации должна быть оснащена штатным конструктором ролей и обеспечивать возможность создание новых ролей. Настройка должна быть доступна с помощью графического интерфейса; Для оптимизации контроля доступа система управления средой виртуализации должна поддерживать группировку ресурсов (ВМ и хранилищ) в отдельные пулы с возможностью наделения индивидуальными разрешениями. Настройка должна быть доступна с помощью графического интерфейса Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 13) Система управления средой виртуализации должна поддерживать возможность создавать виртуальную машину как из шаблона, так и без него. Настройка должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать возможность создавать виртуальную машину с несколькими дисками. Настройка должна быть доступна с помощью графического интерфейса; Для обеспечения высокой производительности система управления средой виртуализации должна поддерживать возможность задавать настройки многопоточности и ограничения пропускной способности при создании виртуальной машины. Настройка должна быть доступна с помощью графического интерфейса; Для обеспечения высокой производительности система управления средой виртуализации должна поддерживать горячее добавление ресурсов vCPU, vRAM, vDisk, USB, vNIC без остановки или перезагрузки ВМ. Настройка должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать как оффлайн-миграцию ВМ, так и живую миграцию Значение характеристики не может изменяться участником закупки Требования к виртуализации (ч. 14) Система управления средой виртуализации должна поддерживать следующие действия над ВМ и режимы работы ВМ, в том числе и в графическом интерфейсе: • запуск; • останов; • пауза; • гибернация; • перезагрузка; • сброс. Система управления средой виртуализации должна поддерживать доступ к консоли ВМ и манипуляции в ВМ как в отдельном сеансе, так и в веб-интерфейсе самой системы управления средой виртуализации; Система управления средой виртуализации должна поддерживать различные варианты копирования ВМ: • полный клон; • связанный клон; • моментальный снимок. Система управления средой виртуализации должна поддерживать следующие протоколы для доступа к консоли ВМ: VNC, SPICE, RDP; Система управления средой виртуализации должна поддерживать массовые операции над ВМ: миграция, старт, выключение. Опция должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать миграцию и импорт из других платформ и гипервизоров: P2V, V2V (Vmware, Hyper-V, KVM, oVirt) с использованием штатных инструментов самой системы управления средой виртуализации Значение характеристики не может изменяться участником закупки Требования к контейнеризации (ч.1) Операционная система в соответствии с документом «Требования по безопасности информации к средствам контейнеризации» (ФСТЭК России, 2022, приказ № 118) по 4-му классу защиты должна реализовывать следующие функции безопасности: • изоляция контейнеров; • выявление уязвимостей в образах контейнеров; • проверка корректности конфигурации контейнеров; • контроль целостности контейнеров и их образов; • регистрация событий безопасности; • управление доступом; • идентификация и аутентификация пользователей; • централизованное управление образами контейнеров и контейнерами в средстве контейнеризации. Операционная система должна предоставлять сертифицированные средства контейнеризации (kubernetes или эквивалент, podman или эквивалент) имеющие возможность запуска от непривилегированного пользователя без необходимости запуска какого-либо демона/службы; Все инструменты, в том числе контейнеры, должны входить в состав дистрибутива операционной системы и устанавливаться без обращения по сети к внешним источникам. Набор контейнеров должен включать базовые контейнеры, в том числе и distroless-образ и набор контейнеров для разворачивания кластера kubernetes Значение характеристики не может изменяться участником закупки Требования к контейнеризации (ч.2) Средства управления образами контейнеров и контейнерами (оркестратор или аналог) должны обеспечивать следующие функции: • создание, модификацию, хранение, получение и удаление образов контейнеров в информационной (автоматизированной) системе; • обновление средства контейнеризации и образов контейнеров из реестра вендора; • чтение, удаление записей о событиях безопасности, формирование отчетов с учетом заданных критериев отбора, выгрузку (экспорт) данных из журнала событий безопасности средства контейнеризации; • анализ возникающих событий безопасности в целях выявления инцидентов безопасности. Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции изоляции контейнеров: • изоляция пространств идентификаторов процессов; • изоляция пространств имен для межпроцессного взаимодействия; • изоляция пространств имен для пользователей и групп; • изоляция пространств имен хостов и доменов; • изоляция сетевых пространств имен; • изоляция пространств имен для иерархии каталогов. В дистрибутиве операционной системы должна быть реализована ролевая модель управления доступом: разработчик образов контейнеров, администратор безопасности средств контейнеризации, администратор информационной (автоматизированной) системы Значение характеристики не может изменяться участником закупки Требования к контейнеризации (ч.3) Дистрибутив операционной системы должен реализовывать следующие требования к функциям идентификации и аутентификации пользователей: • аутентификация пользователей по паролю; • пароль пользователя должен устанавливаться администратором безопасности средства контейнеризации; • средство контейнеризации должно обеспечивать возможность смены установленного администратором безопасности средства контейнеризации пароля пользователя после его первичной аутентификации; • при попытке ввода неправильного значения пароля пользователя должно выводиться соответствующее сообщение с приглашением ввести правильный пароль еще раз; • при исчерпании установленного максимального количества неуспешных попыток ввода неправильного пароля учетная запись пользователя средства контейнеризации должна быть заблокирована; • разблокировка учетной записи пользователя средства контейнеризации должна осуществляться администратором безопасности средства контейнеризации; • защита пароля пользователя должна обеспечиваться при его вводе за счет отображения вводимых символов условными знаками; • средство контейнеризации должно обеспечивать хранение аутентификационной информации пользователя средства контейнеризации в защищенном формате или в защищенном хранилище; • средство контейнеризации не должно запускать процессы в хостовой операционной системе, обладающие привилегиями администратора информационной (автоматизированной) системы и администратора безопасности информационной (автоматизированной) системы; • пароль пользователя средства контейнеризации должен содержать не менее 8 символов при алфавите пароля не менее 70 символов. Максимальное количество неуспешных попыток аутентификации (ввода неправильного пароля) до блокировки — 4. • указанные условия должны быть преднастроены в дистрибутиве операционной системы в рамках парольной политики по умолчанию Значение характеристики не может изменяться участником закупки Требования к контейнеризации (ч.4) Дистрибутив операционной системы должен реализовывать специальный механизм по выявлению уязвимостей в образах контейнеров с учетом следующих требований: • выявление известных уязвимостей при создании, первичном запуске и хранении образов контейнеров, самостоятельно или во взаимодействии с сертифицированным средством контроля и анализа защищенности на основе сведений, содержащихся в банке данных угроз безопасности информации БДУ ФСТЭК России (https://bdu.fstec.ru/), а также в иных источниках, содержащих сведения об известных уязвимостях; • оповещение о выявленных уязвимостях в образах контейнеров разработчика образов контейнеров и администратора информационной (автоматизированной) системы; • средство контейнеризации должно обеспечивать запрет создания образов контейнеров, содержащих известные уязвимости критического и высокого уровня опасности (уровень опасности определяется по значению (V) CVSS в CVE). Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции управления конфигурацией: • возможность ограничения прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование периферийных устройств, устройств хранения данных и съемных машинных носителей информации (блочных устройств), входящих в состав информационной (автоматизированной) системы; • возможность ограничения прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование вычислительных ресурсов (оперативной памяти, операций ввода-вывода за период времени) хостовой операционной системы; • запрет возможности монтирования средством контейнеризации корневой файловой системы хостовой операционной системы (за исключением режима «только для чтения») Значение характеристики не может изменяться участником закупки Требования к контейнеризации (ч.5) Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции контроля целостности контейнеров и их образов: • контролировать самостоятельно или с применением средств контроля целостности хостовой операционной системы и иных сертифицированных средств защиты информации целостность образов контейнеров и исполняемых файлов контейнеров; • информировать администратора безопасности информационной (автоматизированной) системы и администратора безопасности средства контейнеризации о нарушении целостности объектов контроля; • контролировать целостность параметров настройки средства контейнеризации; • контролировать целостность сведений о событиях безопасности и обеспечивать формирование отчетов самостоятельно или во взаимодействии с хостовой операционной системой; • контролировать целостность образов контейнеров и параметров настройки средства контейнеризации при первичном запуске и далее периодически за счет применения электронной подписи самостоятельно или во взаимодействии с хостовой операционной системой; • блокировать запуск образа контейнера при нарушении его целостности. Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции регистрации событий безопасности: • обеспечивать регистрацию событий, относящихся к инцидентам безопасности средства контейнеризации, связанных с попытками осуществления несанкционированного доступа к средству контейнеризации; • оповещать администратора безопасности средства контейнеризации и администратора безопасности информационной (автоматизированной) системы об инцидентах безопасности; • выполнять действия, являющиеся реакцией на инциденты безопасности; • осуществлять сбор и хранение записей в журнале событий безопасности Значение характеристики не может изменяться участником закупки Требования к контейнеризации (ч.6) Средства контейнеризации дистрибутива операционной системы должны соответствовать следующим требованиям к регистрации событий безопасности: • для регистрируемых событий безопасности в каждой записи журнала событий безопасности должны регистрироваться номер (уникальный идентификатор) события, дата, время, тип события безопасности; • записи журнала событий безопасности должны представляться в структурированном виде и содержать время события безопасности, взятое из хостовой операционной системы; • должна быть обеспечена запись событий безопасности контейнеров в журнал событий безопасности информационной (автоматизированной) системы с указанием идентификатора контейнера; • журнал событий безопасности средства контейнеризации должен быть доступен только для чтения. При исчерпании области памяти, отведенной под журнал событий безопасности средства контейнеризации, должно осуществляться его архивирование с последующей очисткой; • регистрации подлежат следующие события безопасности: a. неуспешные попытки аутентификации пользователей средства контейнеризации; b. создание, модификация и удаление образов контейнеров; c. получение доступа к образам контейнеров; d. запуск и остановка контейнеров с указанием причины остановки; e. изменение ролевой модели; f. модификация запускаемых контейнеров; g. выявление известных уязвимостей в образах контейнеров и некорректности конфигурации; h. факты нарушения целостности объектов контроля. • должна обеспечиваться запись событий безопасности контейнеров в журнал событий безопасности с указанием идентификатора пользователя хостовой операционной системы, от имени которого был запущен контейнер Значение характеристики не может изменяться участником закупки Нефункциональные требования Разработчик обязан оказывать гарантийную вендорскую поддержку продукта (оперативный выпуск обновлений по безопасности); Разработчик обязан оказывать техническую поддержку пользователям на условиях SLA в течение первого года использования. Для критических инцидентов должно быть обеспечено время реакции не более 8 часов в период с 9:00 до 19:00 в рабочие дни; Система должна быть основана на программном обеспечении с открытым исходным кодом Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки - Класс программ для электронных вычислительных машин и баз данных - (02.09) Операционные системы общего назначения - - Значение характеристики не может изменяться участником закупки - Способ предоставления - Копия электронного экземпляра - - Значение характеристики не может изменяться участником закупки - Общие требования - Программное обеспечение должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных Минкомсвязи РФ по классам «Операционные системы общего назначения», «Средства виртуализации», «Серверное и связующее программное обеспечение», «Средства управления базами данных», «Системы контейнеризации и контейнеры», «Средства защиты от несанкционированного доступа к информации»; Операционная система должна соответствовать требованиям документов: «Требования безопасности информации к операционным системам» (ФСТЭК России, 2016) и «Профиль защиты операционных систем типа «А» четвертого класса защиты ИТ.ОС.А4.ПЗ» (ФСТЭК России, 2017) ; «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» не ниже четвертого уровня доверия (приказ ФСТЭК России № 76 от 2 июня 2020 г.); «Требования по безопасности информации к средствам контейнеризации» (приказ ФСТЭК России № 118, 2022,) не ниже 4 класса защиты; «Требования по безопасности информации к средствам виртуализации» (приказ ФСТЭК России, № 187, 2022 г.) не ниже 4 класса защиты; «Требования по безопасности информации к системам управления базами данных» (приказ ФСТЭК России № 64, 2023 г.) не ниже 4 класса защиты; В Формуляре ОС должны быть указаны интерпретаторы, веб сервера и сервера приложений, проверенные согласно документу: «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении», утверждена ФСТЭК России 25.12.2020 г.; Разработчик должен иметь собственную инфраструктуру разработки полного цикла, зарегистрированную и находящуюся на территории РФ, в исключительной юрисдикции РФ; Наличие в России локализованной сервисной и/или технической поддержки - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч.1) - Операционная система должна устанавливаться и функционировать на компьютерах с архитектурами x86_64 (64-разрядный процессор Intel или AMD), aarch64 («Байкал», Rockchip 3588) и «Эльбрус» (процессоры 8С, 1С+, 8СВ, 2С3, 12С, 16С) должны быть отдельные образы в сертифицированном исполнении для каждой архитектуры. Требования перечисленные в данном документе относятся к архитектуре x86_64 и могут отличатся от требований к другим архитектурам. Операционная система должна поддерживать режимы установки и загрузки Legacy/CSM, UEFI (с включенным механизмом SecureBoot), а также средствами BMC/IPMI (если поддерживается оборудованием). Операционная система должна иметь в составе ядро не ниже 6.12 (LTS) для обеспечения корректного функционирования современных средств вычислительной техники. Система должна пре доставлять графические утилиты для установки, удаления и обновления ядра, включая модули, а также для выбора ядра по умолчанию. Операционная система должна обеспечивать поддержку нескольких видеокарт (работа на нескольких мониторах). Операционная система должна обладать русифицированным интерфейсом, а также предоставлять русскоязычную документацию. Операционная система должна иметь возможность установки с DVD-диска и USB-накопителя. Операционная система должна предоставлять варианты сетевой установки: PXE/TFTP (для режима Legacy/CSM-загрузки), HTTPClient (для спецификации UEFI 2.5 и выше), iPXE Операционная система должна предоставлять возможность организации сервера сетевой загрузки. Операционная система должна предоставлять возможность установки на оборудование без графической подсистемы с локального накопителя, а также установки с использованием сервера сетевой установки по протоколу VNC - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 2) - Носитель с дистрибутивом ОС должен предусматривать вариант загрузки для проведения работ по восстановлению системы, включая проверку сохранности содержимого файловой системы и проверку контрольных сумм неизменяемых файлов установленных пакетов, диагностику конфигурации аппаратного обеспечения, изменение таблицы и размеров разделов, изменение параметров файловых систем, восстановление удаленных разделов и файлов, проведение резервного копирования, очистку остаточной информации на разделах и дисках; Операционная система должна иметь возможность установки на программный RAID-массив, размещения разделов в томах LVM и использования маскирования (кодирования) разделов с парольным доступом; Операционная система должна обеспечивать возможность создания точек восстановления (снапшотов) для последующего возвращения системы к исходному состоянию в случае сбоя; Инсталлятор дистрибутива должен предусматривать возможность предварительной (OEM) установки, позволяющей при первом запуске пользователем после установки выбрать язык, принять лицензионное соглашение, настроить дату/время, настроить сеть, задать пароль root, создать системного пользователя; Операционная система должна предоставлять независимый выбор основных и дополнительных приложений в момент установки: серверные приложения (dhcp, dns,ftp, http, почтовый сервер, сервер резервного копирования, сервер печати, сервер сетевой установки), сканер обнаружения уязвимостей, сервер сертифицированной СУБД, сервер управления конфигурациями, сервер виртуальных рабочих столов, средства управления контейнеризацией, средства управления виртуализацией - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 3) - Операционная система после установки должна предоставлять пользователю рабочую среду, включающую системное ПО, сетевые службы и сервисы, драйвера устройств, утилиты администрирования, базовый набор приложений; Если установлена графическая среда, операционная система должна предоставлять графическое средство настройки многопользовательского режима, позволяющего обеспечить одновременную работу нескольких пользователей на одном компьютере при наличии отдельной видеокарты, клавиатуры и мыши для каждого пользователя; Операционная система должна предоставлять инструмент для поиска уязвимостей в файлах конфигурации, файловых системах, используемых пакетах ОС (включая программные зависимости), образах контейнеров и git-репозиториях. Анализ уязвимостей должен осуществляться как по вендорской базе уязвимостей (CVE), собранной из разных источников, так и по базе уязвимостей (BDU) ФСТЭК России; Операционная система должна предоставлять возможность установки пароля на загрузчик для ограничения доступа к опциям загрузки; Операционная система должна предоставлять возможность блокировки виртуальных текстовых консолей. Комплекс средств защиты ОС должен обеспечивать выполнение программ в защищенной среде. В состав ОС должны быть включены программные интерпретаторы (php, perl, lua, python, nodejs) и веб-сервер (nginx), прошедшие испытания по выявлению уязвимостей и недекларированных возможностей в полном объеме в соответствии с Методикой выявления уязвимостей и недекларированных возможностей в программном обеспечении, утвержденной ФСТЭК России 25.12.2020 г.; Операционная система должна включать приложение для мониторинга ресурсов. Должно быть обеспечено централизованное управление конфигурациями прав доступа к утилите мониторинга температуры жесткого диска - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 4) - Операционная система должна предоставлять единый графический модульный интерфейс для администрирования и настроек, а также предоставлять возможность удаленного администрирования по защищенным протоколам с помощью графических утилит (включая конфигурирование установленной системы через веб). Администратор должен иметь возможность назначить права доступа для пользователей к определенным модулям. В состав базовых сервисов должны входить: • настройка даты и времени; • управление системными службами; • просмотр системных журналов; • конфигурирование сетевых подключений и межсетевого экрана; • установка обновлений, в том числе для компьютеров без доступа в интернет; • управление выключением удаленного компьютера; • управление пользователями; • настройка пользовательских квот на использование ресурсов памяти, диска и внешних носителей. Операционная система должна реализовывать возможность хранения аутентификационной информации пользователей, полученной с использованием хеш-функций по ГОСТ Р 34.11-2012. Реализация функционала должна быть обеспечена как консольными, так и графическими утилитами; Операционная система должна обеспечивать возможность создания ssh-туннелей, использующих контроль целостности заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015; Операционная система должна предоставлять возможность авторизации по смарт-картам в консольном режиме; Операционная система должна предоставлять протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе; Операционная система должна предоставлять возможность разграничения доступа к подключаемым устройствам - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 5) - Операционная система должна иметь возможность организации домена Samba-DC или интеграции с доменом Active Directory с поддержкой следующего функционала: • действовать в качестве первичного или вторичного контроллера домена; • аутентификация рабочих станций; • авторизация и предоставление ресурсов без дополнительного ввода пароля (Single Sign-On); • поддержка ролей и привилегий (назначение ролей группам); • групповые политики (GPO); Операционная система должна предоставлять возможность организации трастовых доменов - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 6) - При работе в гетерогенной среде домена Active Directory (нативного или создаваемого с помощью проекта Samba) должны быть доступны, при использовании инструмента RSAT в среде Windows или с помощью собственного приложения, следующие политики для управления компьютерами и доменными пользователями, работающими на них: • Настройка установки программного обеспечения из репозитория. • Исполнение любых скриптов при включении/выключении компьютера или входе/выходе пользователя в систему. • Разрешение/Запрет на подключение класса съемных накопителей для компьютера или отдельных пользователей. • Управление ярлыками для компьютера или пользователей. • Централизованное управление конфигурациями сервисов systemd, включая интерфейс-терминала смарт-карт (openct), диспетчер авторизации (polkit), службы аудита безопасности (auditd). • Централизованное управление конфигурациями системных сервисов (CUPS, SSHD, NTP Chrony, Postfix MTA и postqueue, DNS, OpenLDAP, Rpcbind, SSSD, очередь заданий) и утилит определения прав доступа к модификации учетных записей, паролей, пользователей (включая создание индивидуальных временных каталогов) и групп, а также к утилитам su/sudo. • Централизованное управление конфигурациями прав доступа монтирования съемных накопителей, пользовательских файловых систем, подключения сетевых ресурсов по nfs. • Управление файлами и папками (создание, удаление, перемещение, копирование, предоставление общего доступа или скрытие). • Управление настройками приложений через ini-файлы. • Управление интервалом времени применения групповой политики. • Управление всеми политиками веб-браузеров Mozilla Firefox и Chromium. • Возможность принудительного выполнения политики на клиенте - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 7) - Операционная система должна предоставлять возможность организации и настройки базовых сетевых сервисов и служб: • sshd; • DNS; • DHCP; • протокол аутентификации LDAP; • OpenVPN; • SMTP, POP3/IMAP (postfix, dovecot или эквивалент); • межсетевой экран; • проксирование HTTP- и FTP-запросов (squid или эквивалент); • резервное копирование (bacula или эквивалент); • сервер сетевой установки с веб-интерфейсом; • сервер обновлений с возможностью зеркалирования репозитория вендора ОС и создания служебных репозиториев используемого Заказчиком ПО; • защищенный сервер баз данных (PostgreSQL или эквивалент) с возможностью организации кластера из нескольких серверов, со встроенной реализацией функций round, trunc, date совместимой с Oracle DB; • веб-сервер; • FTP-сервер; • сервер мониторинга сетевых ресурсов с графическим интерфейсом (Zabbix, icinga2 или эквивалент); • сервер печати; • сервер групповой работы с веб-интерфейсом (SOGo или эквивалент); • сервер файлового обмена - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 8) - Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - программное обеспечение (ПО) должно создавать и управлять резервными копиями виртуальных машин (ВМ), контейнеров и физических узлов, содержащие архивы файлов и образов; - ПО должно предоставлять интегрированный клиент для QEMU и LXC в виртуальной среде Proxmox; - ПО должно поддерживать резервное копирование на магнитную ленту и управление ленточными библиотеками; - ПО должно поддерживать дедупликацию, сжатие и аутентифицированое шифрование данных; - ПО должно использовать следующие алгоритмы сжатия данных lzo, gzip и zstd.; - ПО должно содержать в себе веб-интерфейс (RESTful API) управления со встроенной в него консолью, доступ должен осуществляться через системную аутентификацию Linux PAM. - ПО должно хранить данные резервных копий и предоставлять RESTful API для создания хранилищ данных и управления ими и другими ресурсами на стороне сервера; - ПО должно позволять с помощью API, предоставленного серверной частью, позволять клиенту резервного копирования получать доступ к сохранённым данным для создания и восстановления резервных копий файлов, а также для управления дисками и другими ресурсами на стороне сервера; - ПО должно использовать протокол TLS для обеспечения безопасности обмена данными между клиентской и серверной частями; - ПО должно использовать алгоритм AES-256 GCM при шифровании содержимого резервной копии на стороне клиента; - ПО должно позволять создавать хранилища данных с файловой системой форматов ext4, xfs.; - ПО должно содержать в себе набор инструментов, используемых для мониторинга и управления системой S.M.A.R.T. для локальных жёстких дисков, с возможностью отображения атрибутов S.M.A.R.T. из веб-интерфейса или при помощи командной строки; - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 9) - Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - ПО должно идентифицировать каждое хранилище данных именем и указанием на каталог в файловой системе и связывать с каждым хранилищем параметры хранения, определяющие количество снимков резервных копий для каждого интервала времени: час, день, неделя, месяц, год; - ПО должно позволять создавать хранилища данных с возможностью выбора и настройки следующих параметров: название; путь к каталогу; количество резервных копий для хранения в этом хранилище; расписания периодического запуска удаления резервных копий и сборки мусора (удаления неиспользуемых блоков данных); - ПО должно позволять ограничить входящий (например, резервное копирование) и исходящий (например, восстановление) сетевой трафик из набора сетей, с возможностью настроить определенные периоды, в которые будут применяться ограничения; - ПО должно позволять создавать пользователей и управлять ими как из встроенного веб-интерфейса, так и с помощью командной строки, с возможностью создания/удаления/отключения учетных записей, просмотра списка пользователей с возможностью изменения любых свойств; - ПО должно позволять любому аутентифицированному пользователю генерировать API-токены и использовать их для настройки клиентов резервного копирования вместо прямого указания имени пользователя и пароля. API-токен должен отзываться в случае компрометации клиента и ограничивать разрешения для каждого клиента/токена в рамках разрешения пользователей. ПО должно создавать для токенов собственные записи ACL, где токены не могут делать больше, чем создавший их пользователь; - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 10) - Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - ПО должно использовать систему управления разрешениями на основе ролей и путей, где роль содержит набор разрешенных действий, а путь представляет цель этих действий. По умолчанию разрешения созданным пользователям и API-токенам не должны предоставляться; - ПО должно предопределять следующий ряд ролей: нет привилегий (используется для запрета доступа); все привилегии; доступ только для чтения; все привилегии для хранилищ данных; просмотр настроек хранилищ и их содержимых, без возможности чтения фактических данных; просмотр содержимого хранилища, восстановление данных; создание и восстановление собственных резервных копий; создание, восстановление и удаление собственных резервных копий; все привилегии для удалённых серверов; просмотр настроек удалённых серверов; чтение данных с удалённых серверов; - ПО должно создавать, хранить и предоставлять следующую информацию о правах доступа: идентификатор ACL; включено или отключено; объект, на который установлено разрешение; пользователи/токены, для которых установлено разрешение; устанавливаемая роль. - ПО должно реализовывать возможность использования двухфакторной аутентификации с помощью веб-интерфейса тремя методами: TOTP (одноразовый пароль на основе времени) — для создания этого кода должен использоваться алгоритм одноразового пароля с учетом времени входа в систему (код меняется каждые 30 секунд); WebAuthn (веб-аутентификация) — реализуется с помощью различных устройств безопасности, таких как аппаратные ключи или доверенные платформенные модули (TPM). Для работы веб-аутентификации необходим сертификат HTTPS; Recovery Keys (одноразовые ключи восстановления) — список ключей, каждый из которых можно использовать только один раз. В каждый момент времени у пользователя может быть только один набор одноразовых ключей - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 11) - Операционная система должна предоставлять возможность установления безопасных сетевых соединений по технологии VPN; Операционная система должна обеспечивать возможность создания VPN-туннелей, использующих контроль заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015; Операционная система должна реализовывать базовый функционал межсетевого экрана; Операционная система должна предоставлять возможность установки многоплатформенного брокера подключений для создания и управления виртуальными рабочими местами и приложениями (OpenUDS или аналог); Операционная система должна включать графическое приложение для мониторинга ресурсов и просмотра системных журналов; Операционная система должна предоставлять возможность одновременной работы пользователей в изолированных сеансах. Должны быть предусмотрены: • отдельное изолированное хранение данных аутентификации каждого пользователя системы таким образом, чтобы процессы аутентификации локального или сетевого пользователя не могли получить доступа к данным аутентификации и авторизации других пользователей системы; • поддержка изоляции временных пользовательских файлов - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 12) - Операционная система должна включать автоматизированные средства изоляции приложений, чувствительных к сетевым атакам; Операционная система должна предоставлять упреждающие меры защиты и быть сконфигурирована с безопасными настройками по умолчанию; Операционная система должна предоставлять механизм управления фиксированными состояниями ключевых объектов безопасности системы, сохраняющий установленные права доступа к объектам файловой системы при обновлении пакетов; Операционная система должна обеспечивать поддержку шифрования по ГОСТ Р 34.11-2012 в OpenSSL, включая генерацию ключей и создание сертификатов; Операционная система должна предоставлять инструмент проверки контрольных сумм неизменяемых файлов установленных пакетов как при начальной установке, так и после получения обновлений. Вендор должен обеспечивать доступ к обновлениям и контрольным суммам неизменяемых файлов пакетов в них; Подсистема контроля целостности операционной системы должна поддерживать технологии IMA и EVM; Операционная система должна предоставлять возможность запрета запуска выбранных интерпретаторов в интерактивном режиме, отключения возможности удаления открытых файлов, а также установки запрета бита исполнения (SUID), распространяемого на дочерние процессы - - Значение характеристики не может изменяться участником закупки - Функциональные требования (ч. 13) - Операционная система должна поддерживать файловые системы ext2, ext3, ext4, btrfs для чтения/записи и установки, iso9660, xfs, fat16, fat32, ntfs.; Операционная система должна поддерживать сетевые протоколы SMB, NFS, FTP, NTP, HTTP(S); Операционная система должна предоставлять возможность доустановки необходимого программного обеспечения с диска или из репозитория, а также установки обновлений. Система должна обеспечить автоматическую проверку зависимостей (apt или эквивалент), а также возможность комплексного обновления системы с отдельным процессом установки ядра ядра с помощью графических утилит; Исходные коды, обновления, инструменты для сборки серверной ОС должны находиться в том же репозитории (хранилище), где хранятся исходные коды, обновления и инструменты для ОС рабочих станций; Операционная система должна предоставлять единую систему для установки прикладного программного обеспечения в системе (eepm или аналог). Также должна быть обеспечена возможность установки сторонних приложений в форматах deb, tgz, tbz, tbz2, pkg.gz.; Операционная система должна поддерживать корневые сертификаты Минцифры России. В составе дистрибутива должен присутствовать пакет с отечественными корневыми сертификатами шифрования; Операционная система должна поддерживать корневые сертификаты Российского центра сертификации ТЦИ, предоставляемые соответствующим пакетом из состава ОС - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 1) - В средстве виртуализации должны быть реализованы следующие функции безопасности: • идентификация и аутентификация субъектов доступа и объектов доступа, в том числе администраторов управления средствами виртуализации; • управление доступом субъектов доступа к объектам, в том числе внутри виртуальных машин; • регистрация событий безопасности; • управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуальной инфраструктуры, а также по ее периметру; • управление перемещением виртуальных машин (контейнеров) и обрабатываемых на них данных; • контроль целостности виртуальной инфраструктуры и ее конфигураций; • резервное копирование данных, резервирование технических средств, программного обеспечения, а также внутренних каналов связи внутри виртуальной инфраструктуры; • сегментирование виртуальной инфраструктуры для обработки информации отдельным пользователем и (или) группой пользователей; В состав дистрибутива операционной системы должен входить следующий комплекс программных компонент для построения виртуальной инфраструктуры: • гипервизор KVM (или эквивалент); • эмулятор аппаратного обеспечения различных платформ QEMU (или эквивалент); • набор инструментов, предоставляющий единый API для технологий виртуализации (libvirt или эквивалент); • гиперконвергентная система управления средой виртуализации с централизованным управлением физическими и виртуальными ресурсами; • система резервного копирования, интегрированная в систему управления средой виртуализации - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 2) - В состав дистрибутива операционной системы для обеспечения корректного функционирования современных средств виртуализации должны входить следующие компоненты: • ядро LTS не ниже 6.1.114; • systemd версии не ниже 249.17; • qemu версии не ниже 8.2; • libvirt версии не ниже 9.7; • corosync версии не ниже 3.1.8; • pacemaker версии не ниже 2.1.7; • keepalived версии не ниже 2.2.8; • Ceph версии не ниже 17.2; • Gluster версии не ниже 9.3. • Требование к версионности компонентов аргументируется наличием необходимого функционала и закрытыми уязвимостями в данных версиях; Система управления средой виртуализации должна обладать возможностью высокого масштабирования и поддерживать создание и управление виртуальной инфраструктурой со следующими параметрами лимитных значений: • максимальное количество физических серверов (узлов), поддерживаемых в составе кластера высокой доступности — не менее 128; • максимальное количество логических процессоров на хост-сервер — не менее 8192; • максимальный объем ОЗУ памяти на хост-сервер — не менее 32 ТБ; • поддержка в ВМ не менее 240 vCPU; • поддержка в ВМ ОЗУ не менее 4 TБ оперативной памяти; • поддержка объема виртуального диска для одной виртуальной машины не менее 64 TБ; • поддержка в ВМ виртуальных сетевых интерфейсов NICs для одной виртуальной машины не менее 10; • поддержка в ВМ виртуальных адаптеров SATA для одной виртуальной машины не менее 6 - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 3) - Система управления средой виртуализации должна предоставлять возможность управления через интерфейс CLI, графический веб-интерфейс, а также интеграцию со сторонним программным обеспечением с помощью REST API; Система управления средой виртуализации должна поддерживать технологию Wake-on-LAN; Система управления средой виртуализации должна поддерживать режим вложенной виртуализации; Система управления средой виртуализации должна обеспечивать создание виртуальных машин (ВМ), их образов и шаблонов для гостевых операционных систем аппаратных архитектур AArch64 (ARMv8) и x86-64; В составе системы управления средой виртуализации должны быть реализованы штатные графические средства мониторинга. Штатная система мониторинга, встроенная в систему управления виртуализации, должна предоставлять обзор в графическом интерфейсе для следующих ресурсов: • отображать объем всех ресурсов в соотношении к доступным (CPU, RAM, сеть, хранилище); • отображать количество всех виртуальных машин и контейнеров, а также количество запущенных и выключенных экземпляров; • отображать реквизиты объектов виртуальной инфраструктуры: IP-адрес, имя владельца и/или группы, имя хоста, ID (UID); • иметь цветовую дифференциацию объектов в зависимости их статусов и объёмов нагрузки; • обеспечивать возможность подключения дополнительных модулей мониторинга Zabbix, Grafana, Prometheus для получения детализированный информации по развёрнутой виртуальной инфраструктуре, включая низкоуровневые интерфейсы; В графическом интерфейсе системы управления средой виртуализации должны быть представлены графические инструменты подключения серверов статистики InfluxDB и Graphite - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 4) - Система управления средой виртуализации должна включать в себя набор инструментов, с отображением их в веб-интерфейсе и в командной строке, для мониторинга и управления S.M.A.R.T. системой для локальных жестких дисков. Набор инструментов для мониторинга и управления S.M.A.R.T. системой должен быть активен и включён по умолчанию и должен выполнять следующие функции: • сканирование дисков каждые 30 минут на наличие ошибок и предупреждений; • отправка сообщений электронной почты пользователю root при обнаружении проблем. • При повторе ошибок узел должен отсылать электронное сообщение каждые 24 часа; Система управления средой виртуализации иметь штатные инструменты регистрации событий и обеспечивать возможность просмотра истории событий и системных журналов каждого отдельного узла кластера и каждой ВМ в веб-интерфейсе самой системы управления средой виртуализации, включая в себя выполнение заданий резервного копирования или восстановления. Журнал событий должен быть оснащен инструментами фильтрации по дате и времени события, по типу и ID ресурса, инициатору события, типу события, статусу события; Система управления средой виртуализации должна поддерживать следующие технологии оптимизации памяти: • Thin Provisioning; • KSM; • Memory balooning; • NUMA. Система управления средой виртуализации должна предоставлять возможность создания общего хранилища со следующими функциональными возможностями: • миграция ВМ в реальном масштабе времени; • плавное расширение пространства хранения с множеством узлов; • централизованное резервное копирование; • многоуровневое кэширование данных; • централизованное управление хранением - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 5) - Система управления средой виртуализации должна поддерживать следующие методы организации хранения данных: • ZFS (локальный/over iSCSI); • Каталог; • BTRFS; • NFS; • CIFS; • GlusterFS; • Ceph версий 15 Octopus и 16 Pacific; • OCFS2; • LVM; • LVM-thin; • iSCSI; • Ceph/RBD. В системе управления средой виртуализацией должна быть реализована возможность хранить образы ВМ на нескольких локальных хранилищах или в общем хранилище; Для хранения всех файлов конфигурации, связанных с системой управления виртуализацией, в системе управления виртуализацией должна быть реализована кластерная файловая система, управляемая базой данных, для хранения файлов конфигурации, реплицируемых в реальном времени на все узлы кластера с помощью corosync. Такая система хранения должна позволять реализовать: • бесшовную репликацию всей конфигурации на все узлы в реальном времени; • строгие проверки согласованности, чтобы избежать дублирования идентификаторов виртуальных машин; • режим «только для чтения», когда узел теряет кворум; • автоматическое обновление конфигурации кластера corosync для всех узлов; • механизм распределенной блокировки. В системе управления виртуализацией должна быть обеспечена поддержка подключения к СХД по протоколам FC/iSCSI (поддержка блочного доступа к данным по сети SAN) - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 6) - Хранилище в системе управления виртуализацией должно поддерживать несколько типов содержимого: образы виртуальных дисков, ISO-образы компакт-дисков, шаблоны ВМ и контейнеров, корневые каталоги контейнеров. Настройка должна быть доступна с помощью графического интерфейса; В системе управления виртуализацией должна быть предусмотрена возможность выбора назначения создаваемого хранилища по типу файловой системы и контенту. Настройка должна быть доступна с помощью графического интерфейса; В системе управления средой виртуализации должна быть предусмотрена возможность управления ограничением дисковой пропускной способностью. Настройка должна быть доступна с помощью графического интерфейс; В системе управления средой виртуализацией должны быть реализованы штатные инструменты выбора версии, развертывания, управления и мониторинга Ceph и его отдельных компонент: сервер метаданных (MDS), OSD, клиентов Ceph, пулов Ceph; Система управления средой виртуализации должна обеспечивать возможность добавления дополнительных узлов в кластер после его создания. При добавлении узлов в кластер в системе управления виртуализацией должна автоматически обновляться и добавляться информация об узлах в файле настройки кластера; Система управления средой виртуализации должна позволять централизованное управление с любого узла дата-центра всеми ресурсами внутри ее контура: • дата-центр; • кластеры; • узлы; • сети; • хранилища; • пулы ресурсов: виртуальные машины, контейнеры, шаблоны; • резервные копии; • пользователи и разрешения - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 7) - Для обеспечения высокой надежности и отказоустойчивости система управления средой виртуализации не должна требовать отдельной установки менеджера управления на отдельную физическую или виртуальную машину; Для обеспечения согласованного состояния всех узлов кластера система управления средой виртуализации должна поддерживать режим работы «кворум»; В графическом интерфейсе системы управления средой виртуализации должно отражаться состояние кворума, а также проверка последнего временного штампа жизнеспособности (heartbeat timestamp); Система управления средой виртуализации должна поддерживать режим работы Qdevice и гарантировать кворум с четным числом узлов; В системе управления средой виртуализации для всех узлов кластера должен использоваться диспетчер отказоустойчивости — служба, управляющая политиками отказоустойчивости и высокой доступности среды виртуализации, которые описывают сценарий действий для физических и виртуальных ресурсов дата-центра; Для обеспечения корректной работы в режиме отказоустойчивости и диспетчера отказоустойчивости в системе управления средой виртуализации должен быть реализован планировщик ресурсов с функцией автоматического анализа утилизации ресурсов и распределения ресурсов согласно заданным политикам - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 8) - Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать и применять следующие политики выключения для узлов: • Conditional — режим автоматически определяет, требуется ли выключение или перезагрузка, и соответствующим образом меняет поведение вычислительного узла. • Failover — режим гарантирует, что все службы будут остановлены, но они также будут восстановлены, если текущий узел не будет подключен к сети в ближайшее время. • Freeze — режим гарантирует, что все службы будут остановлены и заморожены и не будут восстановлены до тех пор, пока текущий узел снова не будет подключен к сети. • Migrate — режим инициирует миграцию всех служб, находящихся в данный момент на том узле, на котором запланировано выключение. • Настройка режимов должна быть доступна с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 9) - Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать объединение узлов в группы отказоустойчивости для возможности восстановления виртуальных сервисов только на определенных узлах. Настройки таких групп должны обеспечивать указание приоритизации для восстановления виртуальных ресурсов (ВМ или контейнер). Настройки должны быть доступны с помощью графического интерфейса; Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать индивидуальные политики отказоустойчивости и применять их к выделенным виртуальным ресурсам (ВМ или контейнер): • ID ресурса — номер ВМ или контейнера; • состояние ресурса при восстановлении — запущен, восстановлен, не требует восстановления, отключен; • количество попыток восстановления; • количество попыток перемещения; • группы отказоустойчивости. • Настройки должны быть доступны с помощью графического интерфейса. В системе управления средой виртуализации должен быть реализован «режим обслуживания» с функцией автоматической миграции виртуальных машин; Система управления средой виртуализации должна позволять создавать отказоустойчивую мультикластерную инфраструктуру; Система управления средой виртуализации должна позволять создавать отказоустойчивую геораспределенную инфраструктуру; Система управления средой виртуализации должна позволять настройку сетевых соединений как децентрализованно на уровне узла, так и централизованно на уровне дата-центра - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 10) - В системе управления виртуализацией должны быть реализованы штатные графические инструменты создания и управления сетью со следующими функциями: • создание Linux/OVS Bridge соединений; • создание Linux/OVS Bond соединений; • создание Linux/OVS VLAN соединений; • поддержка алиаса для сетевых соединений; • создание виртуальных разделённых сетевых зон и управление ими; • создание виртуальных сетевых мостов и управление подсетями; • поддержка протоколов IPv4/IPv6; • поддержка виртуальных коммутаторов с технологией VXLAN (Virtual Extensible LAN); • поддержка трансляции сетевых адресов; • поддержка Jumbo frames до 9000; • поддержка маркировки QoS: 802.1p, DSCP; • поддержка проброса PCI устройств (SR-IOV); • поддержка протокола LLDP (Link Layer Discovery Protocol); • поддержка сетевых адаптеров не менее 10/40/100 Гб/сек. Система управления средой виртуализации должна позволять использование ВМ и контейнерами как одного моста, так и позволять создание нескольких мостов для разделения сетевых доменов (до 4094 мостов); Система управления средой виртуализации должна поддерживать объединение сетевых адаптеров/агрегацию каналов (bonding): циклическая передача (balance-rr), активное резервное копирование (active-backup), XOR (balance-xor), броадкаст (broadcast), IEEE 802.3ad (802.3ad) (LACP), режим адаптивной балансировки нагрузки при передаче (balance-tlb), режим адаптивной балансировки нагрузки (balance-alb); Сетевые настройки системы управления виртуализации должны позволять использование тегирования для VLAN. Настройка должна быть доступна с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 11) - Система управления средой виртуализации должна быть оснащена штатным фаерволом. Штатный фаервол должен группировать сеть на логические зоны по параметрам: • трафик от/к узлу кластера; • трафик от/к конкретной ВМ. Сетевые настройки (в том числе и в графическом интерфейсе системы) должны поддерживать возможность назначения правил фаервола для входящего и/или исходящего трафика: • для всего дата-центра; • для конкретного узла в кластере; • для конкретной ВМ. Настройки фаервола системы управления средой виртуализации должны позволять создавать секретные группы или группы безопасности. Настройки должны быть доступны с помощью графического интерфейса; Система управления средой виртуализации должна быть оснащена штатным сервером аутентификации; Система управления средой виртуализации должна поддерживать возможность интеграции внешних серверов аутентификации (Active Directory, LDAP, Linux PAM, OpenID) и обеспечивать синхронизацию с ними. Настройка должна быть доступна и в графическом интерфейсе; Система управления средой виртуализации должна поддерживать двухфакторную аутентификацию с использованием следующих методов: • TOTP; • Yubikey OTP; • WebAuthn; • одноразовые ключи восстановления. • Настройка должна быть доступна с помощью графического интерфейса. Система управления средой виртуализации должна определять многоуровневый доступ, используя основанное на ролях управление пользователями и разрешениями для всех объектов (ВМ, хранилищ, узлов и т. д.). Настройки должны быть доступны с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 12) - Система управления средой виртуализации должна иметь по умолчанию не менее 12 предопределенных ролей: • Administrator?—?имеет все привилегии; • NoAccess?—?нет привилегий (используется для запрета доступа); • Admin?—?все привилегии, кроме прав на изменение настроек системы; • Auditor?—?доступ только для чтения; • DatastoreAdmin?—?создание и выделение места для резервного копирования и шаблонов; • DatastoreUser?—?выделение места для резервной копии и просмотр хранилища; • PoolAdmin?—?выделение пулов; • SysAdmin?—?ACL пользователя, аудит, системная консоль и системные журналы; • TemplateUser?—?просмотр и клонирование шаблонов; • UserAdmin?—?администрирование пользователей; • VMAdmin?—?управление ВМ; • VMUser?—?просмотр, резервное копирование, настройка CDROM, консоль ВМ, управление питанием ВМ. Система управления средой виртуализации должна быть оснащена штатным конструктором ролей и обеспечивать возможность создание новых ролей. Настройка должна быть доступна с помощью графического интерфейса; Для оптимизации контроля доступа система управления средой виртуализации должна поддерживать группировку ресурсов (ВМ и хранилищ) в отдельные пулы с возможностью наделения индивидуальными разрешениями. Настройка должна быть доступна с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 13) - Система управления средой виртуализации должна поддерживать возможность создавать виртуальную машину как из шаблона, так и без него. Настройка должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать возможность создавать виртуальную машину с несколькими дисками. Настройка должна быть доступна с помощью графического интерфейса; Для обеспечения высокой производительности система управления средой виртуализации должна поддерживать возможность задавать настройки многопоточности и ограничения пропускной способности при создании виртуальной машины. Настройка должна быть доступна с помощью графического интерфейса; Для обеспечения высокой производительности система управления средой виртуализации должна поддерживать горячее добавление ресурсов vCPU, vRAM, vDisk, USB, vNIC без остановки или перезагрузки ВМ. Настройка должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать как оффлайн-миграцию ВМ, так и живую миграцию - - Значение характеристики не может изменяться участником закупки - Требования к виртуализации (ч. 14) - Система управления средой виртуализации должна поддерживать следующие действия над ВМ и режимы работы ВМ, в том числе и в графическом интерфейсе: • запуск; • останов; • пауза; • гибернация; • перезагрузка; • сброс. Система управления средой виртуализации должна поддерживать доступ к консоли ВМ и манипуляции в ВМ как в отдельном сеансе, так и в веб-интерфейсе самой системы управления средой виртуализации; Система управления средой виртуализации должна поддерживать различные варианты копирования ВМ: • полный клон; • связанный клон; • моментальный снимок. Система управления средой виртуализации должна поддерживать следующие протоколы для доступа к консоли ВМ: VNC, SPICE, RDP; Система управления средой виртуализации должна поддерживать массовые операции над ВМ: миграция, старт, выключение. Опция должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать миграцию и импорт из других платформ и гипервизоров: P2V, V2V (Vmware, Hyper-V, KVM, oVirt) с использованием штатных инструментов самой системы управления средой виртуализации - - Значение характеристики не может изменяться участником закупки - Требования к контейнеризации (ч.1) - Операционная система в соответствии с документом «Требования по безопасности информации к средствам контейнеризации» (ФСТЭК России, 2022, приказ № 118) по 4-му классу защиты должна реализовывать следующие функции безопасности: • изоляция контейнеров; • выявление уязвимостей в образах контейнеров; • проверка корректности конфигурации контейнеров; • контроль целостности контейнеров и их образов; • регистрация событий безопасности; • управление доступом; • идентификация и аутентификация пользователей; • централизованное управление образами контейнеров и контейнерами в средстве контейнеризации. Операционная система должна предоставлять сертифицированные средства контейнеризации (kubernetes или эквивалент, podman или эквивалент) имеющие возможность запуска от непривилегированного пользователя без необходимости запуска какого-либо демона/службы; Все инструменты, в том числе контейнеры, должны входить в состав дистрибутива операционной системы и устанавливаться без обращения по сети к внешним источникам. Набор контейнеров должен включать базовые контейнеры, в том числе и distroless-образ и набор контейнеров для разворачивания кластера kubernetes - - Значение характеристики не может изменяться участником закупки - Требования к контейнеризации (ч.2) - Средства управления образами контейнеров и контейнерами (оркестратор или аналог) должны обеспечивать следующие функции: • создание, модификацию, хранение, получение и удаление образов контейнеров в информационной (автоматизированной) системе; • обновление средства контейнеризации и образов контейнеров из реестра вендора; • чтение, удаление записей о событиях безопасности, формирование отчетов с учетом заданных критериев отбора, выгрузку (экспорт) данных из журнала событий безопасности средства контейнеризации; • анализ возникающих событий безопасности в целях выявления инцидентов безопасности. Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции изоляции контейнеров: • изоляция пространств идентификаторов процессов; • изоляция пространств имен для межпроцессного взаимодействия; • изоляция пространств имен для пользователей и групп; • изоляция пространств имен хостов и доменов; • изоляция сетевых пространств имен; • изоляция пространств имен для иерархии каталогов. В дистрибутиве операционной системы должна быть реализована ролевая модель управления доступом: разработчик образов контейнеров, администратор безопасности средств контейнеризации, администратор информационной (автоматизированной) системы - - Значение характеристики не может изменяться участником закупки - Требования к контейнеризации (ч.3) - Дистрибутив операционной системы должен реализовывать следующие требования к функциям идентификации и аутентификации пользователей: • аутентификация пользователей по паролю; • пароль пользователя должен устанавливаться администратором безопасности средства контейнеризации; • средство контейнеризации должно обеспечивать возможность смены установленного администратором безопасности средства контейнеризации пароля пользователя после его первичной аутентификации; • при попытке ввода неправильного значения пароля пользователя должно выводиться соответствующее сообщение с приглашением ввести правильный пароль еще раз; • при исчерпании установленного максимального количества неуспешных попыток ввода неправильного пароля учетная запись пользователя средства контейнеризации должна быть заблокирована; • разблокировка учетной записи пользователя средства контейнеризации должна осуществляться администратором безопасности средства контейнеризации; • защита пароля пользователя должна обеспечиваться при его вводе за счет отображения вводимых символов условными знаками; • средство контейнеризации должно обеспечивать хранение аутентификационной информации пользователя средства контейнеризации в защищенном формате или в защищенном хранилище; • средство контейнеризации не должно запускать процессы в хостовой операционной системе, обладающие привилегиями администратора информационной (автоматизированной) системы и администратора безопасности информационной (автоматизированной) системы; • пароль пользователя средства контейнеризации должен содержать не менее 8 символов при алфавите пароля не менее 70 символов. Максимальное количество неуспешных попыток аутентификации (ввода неправильного пароля) до блокировки — 4. • указанные условия должны быть преднастроены в дистрибутиве операционной системы в рамках парольной политики по умолчанию - - Значение характеристики не может изменяться участником закупки - Требования к контейнеризации (ч.4) - Дистрибутив операционной системы должен реализовывать специальный механизм по выявлению уязвимостей в образах контейнеров с учетом следующих требований: • выявление известных уязвимостей при создании, первичном запуске и хранении образов контейнеров, самостоятельно или во взаимодействии с сертифицированным средством контроля и анализа защищенности на основе сведений, содержащихся в банке данных угроз безопасности информации БДУ ФСТЭК России (https://bdu.fstec.ru/), а также в иных источниках, содержащих сведения об известных уязвимостях; • оповещение о выявленных уязвимостях в образах контейнеров разработчика образов контейнеров и администратора информационной (автоматизированной) системы; • средство контейнеризации должно обеспечивать запрет создания образов контейнеров, содержащих известные уязвимости критического и высокого уровня опасности (уровень опасности определяется по значению (V) CVSS в CVE). Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции управления конфигурацией: • возможность ограничения прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование периферийных устройств, устройств хранения данных и съемных машинных носителей информации (блочных устройств), входящих в состав информационной (автоматизированной) системы; • возможность ограничения прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование вычислительных ресурсов (оперативной памяти, операций ввода-вывода за период времени) хостовой операционной системы; • запрет возможности монтирования средством контейнеризации корневой файловой системы хостовой операционной системы (за исключением режима «только для чтения») - - Значение характеристики не может изменяться участником закупки - Требования к контейнеризации (ч.5) - Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции контроля целостности контейнеров и их образов: • контролировать самостоятельно или с применением средств контроля целостности хостовой операционной системы и иных сертифицированных средств защиты информации целостность образов контейнеров и исполняемых файлов контейнеров; • информировать администратора безопасности информационной (автоматизированной) системы и администратора безопасности средства контейнеризации о нарушении целостности объектов контроля; • контролировать целостность параметров настройки средства контейнеризации; • контролировать целостность сведений о событиях безопасности и обеспечивать формирование отчетов самостоятельно или во взаимодействии с хостовой операционной системой; • контролировать целостность образов контейнеров и параметров настройки средства контейнеризации при первичном запуске и далее периодически за счет применения электронной подписи самостоятельно или во взаимодействии с хостовой операционной системой; • блокировать запуск образа контейнера при нарушении его целостности. Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции регистрации событий безопасности: • обеспечивать регистрацию событий, относящихся к инцидентам безопасности средства контейнеризации, связанных с попытками осуществления несанкционированного доступа к средству контейнеризации; • оповещать администратора безопасности средства контейнеризации и администратора безопасности информационной (автоматизированной) системы об инцидентах безопасности; • выполнять действия, являющиеся реакцией на инциденты безопасности; • осуществлять сбор и хранение записей в журнале событий безопасности - - Значение характеристики не может изменяться участником закупки - Требования к контейнеризации (ч.6) - Средства контейнеризации дистрибутива операционной системы должны соответствовать следующим требованиям к регистрации событий безопасности: • для регистрируемых событий безопасности в каждой записи журнала событий безопасности должны регистрироваться номер (уникальный идентификатор) события, дата, время, тип события безопасности; • записи журнала событий безопасности должны представляться в структурированном виде и содержать время события безопасности, взятое из хостовой операционной системы; • должна быть обеспечена запись событий безопасности контейнеров в журнал событий безопасности информационной (автоматизированной) системы с указанием идентификатора контейнера; • журнал событий безопасности средства контейнеризации должен быть доступен только для чтения. При исчерпании области памяти, отведенной под журнал событий безопасности средства контейнеризации, должно осуществляться его архивирование с последующей очисткой; • регистрации подлежат следующие события безопасности: a. неуспешные попытки аутентификации пользователей средства контейнеризации; b. создание, модификация и удаление образов контейнеров; c. получение доступа к образам контейнеров; d. запуск и остановка контейнеров с указанием причины остановки; e. изменение ролевой модели; f. модификация запускаемых контейнеров; g. выявление известных уязвимостей в образах контейнеров и некорректности конфигурации; h. факты нарушения целостности объектов контроля. • должна обеспечиваться запись событий безопасности контейнеров в журнал событий безопасности с указанием идентификатора пользователя хостовой операционной системы, от имени которого был запущен контейнер - - Значение характеристики не может изменяться участником закупки - Нефункциональные требования - Разработчик обязан оказывать гарантийную вендорскую поддержку продукта (оперативный выпуск обновлений по безопасности); Разработчик обязан оказывать техническую поддержку пользователям на условиях SLA в течение первого года использования. Для критических инцидентов должно быть обеспечено время реакции не более 8 часов в период с 9:00 до 19:00 в рабочие дни; Система должна быть основана на программном обеспечении с открытым исходным кодом - - Значение характеристики не может изменяться участником закупки

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

Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

Класс программ для электронных вычислительных машин и баз данных - (02.09) Операционные системы общего назначения - - Значение характеристики не может изменяться участником закупки

Способ предоставления - Копия электронного экземпляра - - Значение характеристики не может изменяться участником закупки

Общие требования - Программное обеспечение должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных Минкомсвязи РФ по классам «Операционные системы общего назначения», «Средства виртуализации», «Серверное и связующее программное обеспечение», «Средства управления базами данных», «Системы контейнеризации и контейнеры», «Средства защиты от несанкционированного доступа к информации»; Операционная система должна соответствовать требованиям документов: «Требования безопасности информации к операционным системам» (ФСТЭК России, 2016) и «Профиль защиты операционных систем типа «А» четвертого класса защиты ИТ.ОС.А4.ПЗ» (ФСТЭК России, 2017) ; «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» не ниже четвертого уровня доверия (приказ ФСТЭК России № 76 от 2 июня 2020 г.); «Требования по безопасности информации к средствам контейнеризации» (приказ ФСТЭК России № 118, 2022,) не ниже 4 класса защиты; «Требования по безопасности информации к средствам виртуализации» (приказ ФСТЭК России, № 187, 2022 г.) не ниже 4 класса защиты; «Требования по безопасности информации к системам управления базами данных» (приказ ФСТЭК России № 64, 2023 г.) не ниже 4 класса защиты; В Формуляре ОС должны быть указаны интерпретаторы, веб сервера и сервера приложений, проверенные согласно документу: «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении», утверждена ФСТЭК России 25.12.2020 г.; Разработчик должен иметь собственную инфраструктуру разработки полного цикла, зарегистрированную и находящуюся на территории РФ, в исключительной юрисдикции РФ; Наличие в России локализованной сервисной и/или технической поддержки - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч.1) - Операционная система должна устанавливаться и функционировать на компьютерах с архитектурами x86_64 (64-разрядный процессор Intel или AMD), aarch64 («Байкал», Rockchip 3588) и «Эльбрус» (процессоры 8С, 1С+, 8СВ, 2С3, 12С, 16С) должны быть отдельные образы в сертифицированном исполнении для каждой архитектуры. Требования перечисленные в данном документе относятся к архитектуре x86_64 и могут отличатся от требований к другим архитектурам. Операционная система должна поддерживать режимы установки и загрузки Legacy/CSM, UEFI (с включенным механизмом SecureBoot), а также средствами BMC/IPMI (если поддерживается оборудованием). Операционная система должна иметь в составе ядро не ниже 6.12 (LTS) для обеспечения корректного функционирования современных средств вычислительной техники. Система должна пре доставлять графические утилиты для установки, удаления и обновления ядра, включая модули, а также для выбора ядра по умолчанию. Операционная система должна обеспечивать поддержку нескольких видеокарт (работа на нескольких мониторах). Операционная система должна обладать русифицированным интерфейсом, а также предоставлять русскоязычную документацию. Операционная система должна иметь возможность установки с DVD-диска и USB-накопителя. Операционная система должна предоставлять варианты сетевой установки: PXE/TFTP (для режима Legacy/CSM-загрузки), HTTPClient (для спецификации UEFI 2.5 и выше), iPXE Операционная система должна предоставлять возможность организации сервера сетевой загрузки. Операционная система должна предоставлять возможность установки на оборудование без графической подсистемы с локального накопителя, а также установки с использованием сервера сетевой установки по протоколу VNC - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 2) - Носитель с дистрибутивом ОС должен предусматривать вариант загрузки для проведения работ по восстановлению системы, включая проверку сохранности содержимого файловой системы и проверку контрольных сумм неизменяемых файлов установленных пакетов, диагностику конфигурации аппаратного обеспечения, изменение таблицы и размеров разделов, изменение параметров файловых систем, восстановление удаленных разделов и файлов, проведение резервного копирования, очистку остаточной информации на разделах и дисках; Операционная система должна иметь возможность установки на программный RAID-массив, размещения разделов в томах LVM и использования маскирования (кодирования) разделов с парольным доступом; Операционная система должна обеспечивать возможность создания точек восстановления (снапшотов) для последующего возвращения системы к исходному состоянию в случае сбоя; Инсталлятор дистрибутива должен предусматривать возможность предварительной (OEM) установки, позволяющей при первом запуске пользователем после установки выбрать язык, принять лицензионное соглашение, настроить дату/время, настроить сеть, задать пароль root, создать системного пользователя; Операционная система должна предоставлять независимый выбор основных и дополнительных приложений в момент установки: серверные приложения (dhcp, dns,ftp, http, почтовый сервер, сервер резервного копирования, сервер печати, сервер сетевой установки), сканер обнаружения уязвимостей, сервер сертифицированной СУБД, сервер управления конфигурациями, сервер виртуальных рабочих столов, средства управления контейнеризацией, средства управления виртуализацией - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 3) - Операционная система после установки должна предоставлять пользователю рабочую среду, включающую системное ПО, сетевые службы и сервисы, драйвера устройств, утилиты администрирования, базовый набор приложений; Если установлена графическая среда, операционная система должна предоставлять графическое средство настройки многопользовательского режима, позволяющего обеспечить одновременную работу нескольких пользователей на одном компьютере при наличии отдельной видеокарты, клавиатуры и мыши для каждого пользователя; Операционная система должна предоставлять инструмент для поиска уязвимостей в файлах конфигурации, файловых системах, используемых пакетах ОС (включая программные зависимости), образах контейнеров и git-репозиториях. Анализ уязвимостей должен осуществляться как по вендорской базе уязвимостей (CVE), собранной из разных источников, так и по базе уязвимостей (BDU) ФСТЭК России; Операционная система должна предоставлять возможность установки пароля на загрузчик для ограничения доступа к опциям загрузки; Операционная система должна предоставлять возможность блокировки виртуальных текстовых консолей. Комплекс средств защиты ОС должен обеспечивать выполнение программ в защищенной среде. В состав ОС должны быть включены программные интерпретаторы (php, perl, lua, python, nodejs) и веб-сервер (nginx), прошедшие испытания по выявлению уязвимостей и недекларированных возможностей в полном объеме в соответствии с Методикой выявления уязвимостей и недекларированных возможностей в программном обеспечении, утвержденной ФСТЭК России 25.12.2020 г.; Операционная система должна включать приложение для мониторинга ресурсов. Должно быть обеспечено централизованное управление конфигурациями прав доступа к утилите мониторинга температуры жесткого диска - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 4) - Операционная система должна предоставлять единый графический модульный интерфейс для администрирования и настроек, а также предоставлять возможность удаленного администрирования по защищенным протоколам с помощью графических утилит (включая конфигурирование установленной системы через веб). Администратор должен иметь возможность назначить права доступа для пользователей к определенным модулям. В состав базовых сервисов должны входить: • настройка даты и времени; • управление системными службами; • просмотр системных журналов; • конфигурирование сетевых подключений и межсетевого экрана; • установка обновлений, в том числе для компьютеров без доступа в интернет; • управление выключением удаленного компьютера; • управление пользователями; • настройка пользовательских квот на использование ресурсов памяти, диска и внешних носителей. Операционная система должна реализовывать возможность хранения аутентификационной информации пользователей, полученной с использованием хеш-функций по ГОСТ Р 34.11-2012. Реализация функционала должна быть обеспечена как консольными, так и графическими утилитами; Операционная система должна обеспечивать возможность создания ssh-туннелей, использующих контроль целостности заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015; Операционная система должна предоставлять возможность авторизации по смарт-картам в консольном режиме; Операционная система должна предоставлять протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе; Операционная система должна предоставлять возможность разграничения доступа к подключаемым устройствам - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 5) - Операционная система должна иметь возможность организации домена Samba-DC или интеграции с доменом Active Directory с поддержкой следующего функционала: • действовать в качестве первичного или вторичного контроллера домена; • аутентификация рабочих станций; • авторизация и предоставление ресурсов без дополнительного ввода пароля (Single Sign-On); • поддержка ролей и привилегий (назначение ролей группам); • групповые политики (GPO); Операционная система должна предоставлять возможность организации трастовых доменов - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 6) - При работе в гетерогенной среде домена Active Directory (нативного или создаваемого с помощью проекта Samba) должны быть доступны, при использовании инструмента RSAT в среде Windows или с помощью собственного приложения, следующие политики для управления компьютерами и доменными пользователями, работающими на них: • Настройка установки программного обеспечения из репозитория. • Исполнение любых скриптов при включении/выключении компьютера или входе/выходе пользователя в систему. • Разрешение/Запрет на подключение класса съемных накопителей для компьютера или отдельных пользователей. • Управление ярлыками для компьютера или пользователей. • Централизованное управление конфигурациями сервисов systemd, включая интерфейс-терминала смарт-карт (openct), диспетчер авторизации (polkit), службы аудита безопасности (auditd). • Централизованное управление конфигурациями системных сервисов (CUPS, SSHD, NTP Chrony, Postfix MTA и postqueue, DNS, OpenLDAP, Rpcbind, SSSD, очередь заданий) и утилит определения прав доступа к модификации учетных записей, паролей, пользователей (включая создание индивидуальных временных каталогов) и групп, а также к утилитам su/sudo. • Централизованное управление конфигурациями прав доступа монтирования съемных накопителей, пользовательских файловых систем, подключения сетевых ресурсов по nfs. • Управление файлами и папками (создание, удаление, перемещение, копирование, предоставление общего доступа или скрытие). • Управление настройками приложений через ini-файлы. • Управление интервалом времени применения групповой политики. • Управление всеми политиками веб-браузеров Mozilla Firefox и Chromium. • Возможность принудительного выполнения политики на клиенте - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 7) - Операционная система должна предоставлять возможность организации и настройки базовых сетевых сервисов и служб: • sshd; • DNS; • DHCP; • протокол аутентификации LDAP; • OpenVPN; • SMTP, POP3/IMAP (postfix, dovecot или эквивалент); • межсетевой экран; • проксирование HTTP- и FTP-запросов (squid или эквивалент); • резервное копирование (bacula или эквивалент); • сервер сетевой установки с веб-интерфейсом; • сервер обновлений с возможностью зеркалирования репозитория вендора ОС и создания служебных репозиториев используемого Заказчиком ПО; • защищенный сервер баз данных (PostgreSQL или эквивалент) с возможностью организации кластера из нескольких серверов, со встроенной реализацией функций round, trunc, date совместимой с Oracle DB; • веб-сервер; • FTP-сервер; • сервер мониторинга сетевых ресурсов с графическим интерфейсом (Zabbix, icinga2 или эквивалент); • сервер печати; • сервер групповой работы с веб-интерфейсом (SOGo или эквивалент); • сервер файлового обмена - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 8) - Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - программное обеспечение (ПО) должно создавать и управлять резервными копиями виртуальных машин (ВМ), контейнеров и физических узлов, содержащие архивы файлов и образов; - ПО должно предоставлять интегрированный клиент для QEMU и LXC в виртуальной среде Proxmox; - ПО должно поддерживать резервное копирование на магнитную ленту и управление ленточными библиотеками; - ПО должно поддерживать дедупликацию, сжатие и аутентифицированое шифрование данных; - ПО должно использовать следующие алгоритмы сжатия данных lzo, gzip и zstd.; - ПО должно содержать в себе веб-интерфейс (RESTful API) управления со встроенной в него консолью, доступ должен осуществляться через системную аутентификацию Linux PAM. - ПО должно хранить данные резервных копий и предоставлять RESTful API для создания хранилищ данных и управления ими и другими ресурсами на стороне сервера; - ПО должно позволять с помощью API, предоставленного серверной частью, позволять клиенту резервного копирования получать доступ к сохранённым данным для создания и восстановления резервных копий файлов, а также для управления дисками и другими ресурсами на стороне сервера; - ПО должно использовать протокол TLS для обеспечения безопасности обмена данными между клиентской и серверной частями; - ПО должно использовать алгоритм AES-256 GCM при шифровании содержимого резервной копии на стороне клиента; - ПО должно позволять создавать хранилища данных с файловой системой форматов ext4, xfs.; - ПО должно содержать в себе набор инструментов, используемых для мониторинга и управления системой S.M.A.R.T. для локальных жёстких дисков, с возможностью отображения атрибутов S.M.A.R.T. из веб-интерфейса или при помощи командной строки; - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 9) - Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - ПО должно идентифицировать каждое хранилище данных именем и указанием на каталог в файловой системе и связывать с каждым хранилищем параметры хранения, определяющие количество снимков резервных копий для каждого интервала времени: час, день, неделя, месяц, год; - ПО должно позволять создавать хранилища данных с возможностью выбора и настройки следующих параметров: название; путь к каталогу; количество резервных копий для хранения в этом хранилище; расписания периодического запуска удаления резервных копий и сборки мусора (удаления неиспользуемых блоков данных); - ПО должно позволять ограничить входящий (например, резервное копирование) и исходящий (например, восстановление) сетевой трафик из набора сетей, с возможностью настроить определенные периоды, в которые будут применяться ограничения; - ПО должно позволять создавать пользователей и управлять ими как из встроенного веб-интерфейса, так и с помощью командной строки, с возможностью создания/удаления/отключения учетных записей, просмотра списка пользователей с возможностью изменения любых свойств; - ПО должно позволять любому аутентифицированному пользователю генерировать API-токены и использовать их для настройки клиентов резервного копирования вместо прямого указания имени пользователя и пароля. API-токен должен отзываться в случае компрометации клиента и ограничивать разрешения для каждого клиента/токена в рамках разрешения пользователей. ПО должно создавать для токенов собственные записи ACL, где токены не могут делать больше, чем создавший их пользователь; - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 10) - Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: - ПО должно использовать систему управления разрешениями на основе ролей и путей, где роль содержит набор разрешенных действий, а путь представляет цель этих действий. По умолчанию разрешения созданным пользователям и API-токенам не должны предоставляться; - ПО должно предопределять следующий ряд ролей: нет привилегий (используется для запрета доступа); все привилегии; доступ только для чтения; все привилегии для хранилищ данных; просмотр настроек хранилищ и их содержимых, без возможности чтения фактических данных; просмотр содержимого хранилища, восстановление данных; создание и восстановление собственных резервных копий; создание, восстановление и удаление собственных резервных копий; все привилегии для удалённых серверов; просмотр настроек удалённых серверов; чтение данных с удалённых серверов; - ПО должно создавать, хранить и предоставлять следующую информацию о правах доступа: идентификатор ACL; включено или отключено; объект, на который установлено разрешение; пользователи/токены, для которых установлено разрешение; устанавливаемая роль. - ПО должно реализовывать возможность использования двухфакторной аутентификации с помощью веб-интерфейса тремя методами: TOTP (одноразовый пароль на основе времени) — для создания этого кода должен использоваться алгоритм одноразового пароля с учетом времени входа в систему (код меняется каждые 30 секунд); WebAuthn (веб-аутентификация) — реализуется с помощью различных устройств безопасности, таких как аппаратные ключи или доверенные платформенные модули (TPM). Для работы веб-аутентификации необходим сертификат HTTPS; Recovery Keys (одноразовые ключи восстановления) — список ключей, каждый из которых можно использовать только один раз. В каждый момент времени у пользователя может быть только один набор одноразовых ключей - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 11) - Операционная система должна предоставлять возможность установления безопасных сетевых соединений по технологии VPN; Операционная система должна обеспечивать возможность создания VPN-туннелей, использующих контроль заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015; Операционная система должна реализовывать базовый функционал межсетевого экрана; Операционная система должна предоставлять возможность установки многоплатформенного брокера подключений для создания и управления виртуальными рабочими местами и приложениями (OpenUDS или аналог); Операционная система должна включать графическое приложение для мониторинга ресурсов и просмотра системных журналов; Операционная система должна предоставлять возможность одновременной работы пользователей в изолированных сеансах. Должны быть предусмотрены: • отдельное изолированное хранение данных аутентификации каждого пользователя системы таким образом, чтобы процессы аутентификации локального или сетевого пользователя не могли получить доступа к данным аутентификации и авторизации других пользователей системы; • поддержка изоляции временных пользовательских файлов - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 12) - Операционная система должна включать автоматизированные средства изоляции приложений, чувствительных к сетевым атакам; Операционная система должна предоставлять упреждающие меры защиты и быть сконфигурирована с безопасными настройками по умолчанию; Операционная система должна предоставлять механизм управления фиксированными состояниями ключевых объектов безопасности системы, сохраняющий установленные права доступа к объектам файловой системы при обновлении пакетов; Операционная система должна обеспечивать поддержку шифрования по ГОСТ Р 34.11-2012 в OpenSSL, включая генерацию ключей и создание сертификатов; Операционная система должна предоставлять инструмент проверки контрольных сумм неизменяемых файлов установленных пакетов как при начальной установке, так и после получения обновлений. Вендор должен обеспечивать доступ к обновлениям и контрольным суммам неизменяемых файлов пакетов в них; Подсистема контроля целостности операционной системы должна поддерживать технологии IMA и EVM; Операционная система должна предоставлять возможность запрета запуска выбранных интерпретаторов в интерактивном режиме, отключения возможности удаления открытых файлов, а также установки запрета бита исполнения (SUID), распространяемого на дочерние процессы - - Значение характеристики не может изменяться участником закупки

Функциональные требования (ч. 13) - Операционная система должна поддерживать файловые системы ext2, ext3, ext4, btrfs для чтения/записи и установки, iso9660, xfs, fat16, fat32, ntfs.; Операционная система должна поддерживать сетевые протоколы SMB, NFS, FTP, NTP, HTTP(S); Операционная система должна предоставлять возможность доустановки необходимого программного обеспечения с диска или из репозитория, а также установки обновлений. Система должна обеспечить автоматическую проверку зависимостей (apt или эквивалент), а также возможность комплексного обновления системы с отдельным процессом установки ядра ядра с помощью графических утилит; Исходные коды, обновления, инструменты для сборки серверной ОС должны находиться в том же репозитории (хранилище), где хранятся исходные коды, обновления и инструменты для ОС рабочих станций; Операционная система должна предоставлять единую систему для установки прикладного программного обеспечения в системе (eepm или аналог). Также должна быть обеспечена возможность установки сторонних приложений в форматах deb, tgz, tbz, tbz2, pkg.gz.; Операционная система должна поддерживать корневые сертификаты Минцифры России. В составе дистрибутива должен присутствовать пакет с отечественными корневыми сертификатами шифрования; Операционная система должна поддерживать корневые сертификаты Российского центра сертификации ТЦИ, предоставляемые соответствующим пакетом из состава ОС - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 1) - В средстве виртуализации должны быть реализованы следующие функции безопасности: • идентификация и аутентификация субъектов доступа и объектов доступа, в том числе администраторов управления средствами виртуализации; • управление доступом субъектов доступа к объектам, в том числе внутри виртуальных машин; • регистрация событий безопасности; • управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуальной инфраструктуры, а также по ее периметру; • управление перемещением виртуальных машин (контейнеров) и обрабатываемых на них данных; • контроль целостности виртуальной инфраструктуры и ее конфигураций; • резервное копирование данных, резервирование технических средств, программного обеспечения, а также внутренних каналов связи внутри виртуальной инфраструктуры; • сегментирование виртуальной инфраструктуры для обработки информации отдельным пользователем и (или) группой пользователей; В состав дистрибутива операционной системы должен входить следующий комплекс программных компонент для построения виртуальной инфраструктуры: • гипервизор KVM (или эквивалент); • эмулятор аппаратного обеспечения различных платформ QEMU (или эквивалент); • набор инструментов, предоставляющий единый API для технологий виртуализации (libvirt или эквивалент); • гиперконвергентная система управления средой виртуализации с централизованным управлением физическими и виртуальными ресурсами; • система резервного копирования, интегрированная в систему управления средой виртуализации - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 2) - В состав дистрибутива операционной системы для обеспечения корректного функционирования современных средств виртуализации должны входить следующие компоненты: • ядро LTS не ниже 6.1.114; • systemd версии не ниже 249.17; • qemu версии не ниже 8.2; • libvirt версии не ниже 9.7; • corosync версии не ниже 3.1.8; • pacemaker версии не ниже 2.1.7; • keepalived версии не ниже 2.2.8; • Ceph версии не ниже 17.2; • Gluster версии не ниже 9.3. • Требование к версионности компонентов аргументируется наличием необходимого функционала и закрытыми уязвимостями в данных версиях; Система управления средой виртуализации должна обладать возможностью высокого масштабирования и поддерживать создание и управление виртуальной инфраструктурой со следующими параметрами лимитных значений: • максимальное количество физических серверов (узлов), поддерживаемых в составе кластера высокой доступности — не менее 128; • максимальное количество логических процессоров на хост-сервер — не менее 8192; • максимальный объем ОЗУ памяти на хост-сервер — не менее 32 ТБ; • поддержка в ВМ не менее 240 vCPU; • поддержка в ВМ ОЗУ не менее 4 TБ оперативной памяти; • поддержка объема виртуального диска для одной виртуальной машины не менее 64 TБ; • поддержка в ВМ виртуальных сетевых интерфейсов NICs для одной виртуальной машины не менее 10; • поддержка в ВМ виртуальных адаптеров SATA для одной виртуальной машины не менее 6 - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 3) - Система управления средой виртуализации должна предоставлять возможность управления через интерфейс CLI, графический веб-интерфейс, а также интеграцию со сторонним программным обеспечением с помощью REST API; Система управления средой виртуализации должна поддерживать технологию Wake-on-LAN; Система управления средой виртуализации должна поддерживать режим вложенной виртуализации; Система управления средой виртуализации должна обеспечивать создание виртуальных машин (ВМ), их образов и шаблонов для гостевых операционных систем аппаратных архитектур AArch64 (ARMv8) и x86-64; В составе системы управления средой виртуализации должны быть реализованы штатные графические средства мониторинга. Штатная система мониторинга, встроенная в систему управления виртуализации, должна предоставлять обзор в графическом интерфейсе для следующих ресурсов: • отображать объем всех ресурсов в соотношении к доступным (CPU, RAM, сеть, хранилище); • отображать количество всех виртуальных машин и контейнеров, а также количество запущенных и выключенных экземпляров; • отображать реквизиты объектов виртуальной инфраструктуры: IP-адрес, имя владельца и/или группы, имя хоста, ID (UID); • иметь цветовую дифференциацию объектов в зависимости их статусов и объёмов нагрузки; • обеспечивать возможность подключения дополнительных модулей мониторинга Zabbix, Grafana, Prometheus для получения детализированный информации по развёрнутой виртуальной инфраструктуре, включая низкоуровневые интерфейсы; В графическом интерфейсе системы управления средой виртуализации должны быть представлены графические инструменты подключения серверов статистики InfluxDB и Graphite - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 4) - Система управления средой виртуализации должна включать в себя набор инструментов, с отображением их в веб-интерфейсе и в командной строке, для мониторинга и управления S.M.A.R.T. системой для локальных жестких дисков. Набор инструментов для мониторинга и управления S.M.A.R.T. системой должен быть активен и включён по умолчанию и должен выполнять следующие функции: • сканирование дисков каждые 30 минут на наличие ошибок и предупреждений; • отправка сообщений электронной почты пользователю root при обнаружении проблем. • При повторе ошибок узел должен отсылать электронное сообщение каждые 24 часа; Система управления средой виртуализации иметь штатные инструменты регистрации событий и обеспечивать возможность просмотра истории событий и системных журналов каждого отдельного узла кластера и каждой ВМ в веб-интерфейсе самой системы управления средой виртуализации, включая в себя выполнение заданий резервного копирования или восстановления. Журнал событий должен быть оснащен инструментами фильтрации по дате и времени события, по типу и ID ресурса, инициатору события, типу события, статусу события; Система управления средой виртуализации должна поддерживать следующие технологии оптимизации памяти: • Thin Provisioning; • KSM; • Memory balooning; • NUMA. Система управления средой виртуализации должна предоставлять возможность создания общего хранилища со следующими функциональными возможностями: • миграция ВМ в реальном масштабе времени; • плавное расширение пространства хранения с множеством узлов; • централизованное резервное копирование; • многоуровневое кэширование данных; • централизованное управление хранением - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 5) - Система управления средой виртуализации должна поддерживать следующие методы организации хранения данных: • ZFS (локальный/over iSCSI); • Каталог; • BTRFS; • NFS; • CIFS; • GlusterFS; • Ceph версий 15 Octopus и 16 Pacific; • OCFS2; • LVM; • LVM-thin; • iSCSI; • Ceph/RBD. В системе управления средой виртуализацией должна быть реализована возможность хранить образы ВМ на нескольких локальных хранилищах или в общем хранилище; Для хранения всех файлов конфигурации, связанных с системой управления виртуализацией, в системе управления виртуализацией должна быть реализована кластерная файловая система, управляемая базой данных, для хранения файлов конфигурации, реплицируемых в реальном времени на все узлы кластера с помощью corosync. Такая система хранения должна позволять реализовать: • бесшовную репликацию всей конфигурации на все узлы в реальном времени; • строгие проверки согласованности, чтобы избежать дублирования идентификаторов виртуальных машин; • режим «только для чтения», когда узел теряет кворум; • автоматическое обновление конфигурации кластера corosync для всех узлов; • механизм распределенной блокировки. В системе управления виртуализацией должна быть обеспечена поддержка подключения к СХД по протоколам FC/iSCSI (поддержка блочного доступа к данным по сети SAN) - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 6) - Хранилище в системе управления виртуализацией должно поддерживать несколько типов содержимого: образы виртуальных дисков, ISO-образы компакт-дисков, шаблоны ВМ и контейнеров, корневые каталоги контейнеров. Настройка должна быть доступна с помощью графического интерфейса; В системе управления виртуализацией должна быть предусмотрена возможность выбора назначения создаваемого хранилища по типу файловой системы и контенту. Настройка должна быть доступна с помощью графического интерфейса; В системе управления средой виртуализации должна быть предусмотрена возможность управления ограничением дисковой пропускной способностью. Настройка должна быть доступна с помощью графического интерфейс; В системе управления средой виртуализацией должны быть реализованы штатные инструменты выбора версии, развертывания, управления и мониторинга Ceph и его отдельных компонент: сервер метаданных (MDS), OSD, клиентов Ceph, пулов Ceph; Система управления средой виртуализации должна обеспечивать возможность добавления дополнительных узлов в кластер после его создания. При добавлении узлов в кластер в системе управления виртуализацией должна автоматически обновляться и добавляться информация об узлах в файле настройки кластера; Система управления средой виртуализации должна позволять централизованное управление с любого узла дата-центра всеми ресурсами внутри ее контура: • дата-центр; • кластеры; • узлы; • сети; • хранилища; • пулы ресурсов: виртуальные машины, контейнеры, шаблоны; • резервные копии; • пользователи и разрешения - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 7) - Для обеспечения высокой надежности и отказоустойчивости система управления средой виртуализации не должна требовать отдельной установки менеджера управления на отдельную физическую или виртуальную машину; Для обеспечения согласованного состояния всех узлов кластера система управления средой виртуализации должна поддерживать режим работы «кворум»; В графическом интерфейсе системы управления средой виртуализации должно отражаться состояние кворума, а также проверка последнего временного штампа жизнеспособности (heartbeat timestamp); Система управления средой виртуализации должна поддерживать режим работы Qdevice и гарантировать кворум с четным числом узлов; В системе управления средой виртуализации для всех узлов кластера должен использоваться диспетчер отказоустойчивости — служба, управляющая политиками отказоустойчивости и высокой доступности среды виртуализации, которые описывают сценарий действий для физических и виртуальных ресурсов дата-центра; Для обеспечения корректной работы в режиме отказоустойчивости и диспетчера отказоустойчивости в системе управления средой виртуализации должен быть реализован планировщик ресурсов с функцией автоматического анализа утилизации ресурсов и распределения ресурсов согласно заданным политикам - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 8) - Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать и применять следующие политики выключения для узлов: • Conditional — режим автоматически определяет, требуется ли выключение или перезагрузка, и соответствующим образом меняет поведение вычислительного узла. • Failover — режим гарантирует, что все службы будут остановлены, но они также будут восстановлены, если текущий узел не будет подключен к сети в ближайшее время. • Freeze — режим гарантирует, что все службы будут остановлены и заморожены и не будут восстановлены до тех пор, пока текущий узел снова не будет подключен к сети. • Migrate — режим инициирует миграцию всех служб, находящихся в данный момент на том узле, на котором запланировано выключение. • Настройка режимов должна быть доступна с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 9) - Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать объединение узлов в группы отказоустойчивости для возможности восстановления виртуальных сервисов только на определенных узлах. Настройки таких групп должны обеспечивать указание приоритизации для восстановления виртуальных ресурсов (ВМ или контейнер). Настройки должны быть доступны с помощью графического интерфейса; Диспетчер отказоустойчивости в системе управления средой виртуализации должен поддерживать индивидуальные политики отказоустойчивости и применять их к выделенным виртуальным ресурсам (ВМ или контейнер): • ID ресурса — номер ВМ или контейнера; • состояние ресурса при восстановлении — запущен, восстановлен, не требует восстановления, отключен; • количество попыток восстановления; • количество попыток перемещения; • группы отказоустойчивости. • Настройки должны быть доступны с помощью графического интерфейса. В системе управления средой виртуализации должен быть реализован «режим обслуживания» с функцией автоматической миграции виртуальных машин; Система управления средой виртуализации должна позволять создавать отказоустойчивую мультикластерную инфраструктуру; Система управления средой виртуализации должна позволять создавать отказоустойчивую геораспределенную инфраструктуру; Система управления средой виртуализации должна позволять настройку сетевых соединений как децентрализованно на уровне узла, так и централизованно на уровне дата-центра - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 10) - В системе управления виртуализацией должны быть реализованы штатные графические инструменты создания и управления сетью со следующими функциями: • создание Linux/OVS Bridge соединений; • создание Linux/OVS Bond соединений; • создание Linux/OVS VLAN соединений; • поддержка алиаса для сетевых соединений; • создание виртуальных разделённых сетевых зон и управление ими; • создание виртуальных сетевых мостов и управление подсетями; • поддержка протоколов IPv4/IPv6; • поддержка виртуальных коммутаторов с технологией VXLAN (Virtual Extensible LAN); • поддержка трансляции сетевых адресов; • поддержка Jumbo frames до 9000; • поддержка маркировки QoS: 802.1p, DSCP; • поддержка проброса PCI устройств (SR-IOV); • поддержка протокола LLDP (Link Layer Discovery Protocol); • поддержка сетевых адаптеров не менее 10/40/100 Гб/сек. Система управления средой виртуализации должна позволять использование ВМ и контейнерами как одного моста, так и позволять создание нескольких мостов для разделения сетевых доменов (до 4094 мостов); Система управления средой виртуализации должна поддерживать объединение сетевых адаптеров/агрегацию каналов (bonding): циклическая передача (balance-rr), активное резервное копирование (active-backup), XOR (balance-xor), броадкаст (broadcast), IEEE 802.3ad (802.3ad) (LACP), режим адаптивной балансировки нагрузки при передаче (balance-tlb), режим адаптивной балансировки нагрузки (balance-alb); Сетевые настройки системы управления виртуализации должны позволять использование тегирования для VLAN. Настройка должна быть доступна с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 11) - Система управления средой виртуализации должна быть оснащена штатным фаерволом. Штатный фаервол должен группировать сеть на логические зоны по параметрам: • трафик от/к узлу кластера; • трафик от/к конкретной ВМ. Сетевые настройки (в том числе и в графическом интерфейсе системы) должны поддерживать возможность назначения правил фаервола для входящего и/или исходящего трафика: • для всего дата-центра; • для конкретного узла в кластере; • для конкретной ВМ. Настройки фаервола системы управления средой виртуализации должны позволять создавать секретные группы или группы безопасности. Настройки должны быть доступны с помощью графического интерфейса; Система управления средой виртуализации должна быть оснащена штатным сервером аутентификации; Система управления средой виртуализации должна поддерживать возможность интеграции внешних серверов аутентификации (Active Directory, LDAP, Linux PAM, OpenID) и обеспечивать синхронизацию с ними. Настройка должна быть доступна и в графическом интерфейсе; Система управления средой виртуализации должна поддерживать двухфакторную аутентификацию с использованием следующих методов: • TOTP; • Yubikey OTP; • WebAuthn; • одноразовые ключи восстановления. • Настройка должна быть доступна с помощью графического интерфейса. Система управления средой виртуализации должна определять многоуровневый доступ, используя основанное на ролях управление пользователями и разрешениями для всех объектов (ВМ, хранилищ, узлов и т. д.). Настройки должны быть доступны с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 12) - Система управления средой виртуализации должна иметь по умолчанию не менее 12 предопределенных ролей: • Administrator?—?имеет все привилегии; • NoAccess?—?нет привилегий (используется для запрета доступа); • Admin?—?все привилегии, кроме прав на изменение настроек системы; • Auditor?—?доступ только для чтения; • DatastoreAdmin?—?создание и выделение места для резервного копирования и шаблонов; • DatastoreUser?—?выделение места для резервной копии и просмотр хранилища; • PoolAdmin?—?выделение пулов; • SysAdmin?—?ACL пользователя, аудит, системная консоль и системные журналы; • TemplateUser?—?просмотр и клонирование шаблонов; • UserAdmin?—?администрирование пользователей; • VMAdmin?—?управление ВМ; • VMUser?—?просмотр, резервное копирование, настройка CDROM, консоль ВМ, управление питанием ВМ. Система управления средой виртуализации должна быть оснащена штатным конструктором ролей и обеспечивать возможность создание новых ролей. Настройка должна быть доступна с помощью графического интерфейса; Для оптимизации контроля доступа система управления средой виртуализации должна поддерживать группировку ресурсов (ВМ и хранилищ) в отдельные пулы с возможностью наделения индивидуальными разрешениями. Настройка должна быть доступна с помощью графического интерфейса - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 13) - Система управления средой виртуализации должна поддерживать возможность создавать виртуальную машину как из шаблона, так и без него. Настройка должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать возможность создавать виртуальную машину с несколькими дисками. Настройка должна быть доступна с помощью графического интерфейса; Для обеспечения высокой производительности система управления средой виртуализации должна поддерживать возможность задавать настройки многопоточности и ограничения пропускной способности при создании виртуальной машины. Настройка должна быть доступна с помощью графического интерфейса; Для обеспечения высокой производительности система управления средой виртуализации должна поддерживать горячее добавление ресурсов vCPU, vRAM, vDisk, USB, vNIC без остановки или перезагрузки ВМ. Настройка должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать как оффлайн-миграцию ВМ, так и живую миграцию - - Значение характеристики не может изменяться участником закупки

Требования к виртуализации (ч. 14) - Система управления средой виртуализации должна поддерживать следующие действия над ВМ и режимы работы ВМ, в том числе и в графическом интерфейсе: • запуск; • останов; • пауза; • гибернация; • перезагрузка; • сброс. Система управления средой виртуализации должна поддерживать доступ к консоли ВМ и манипуляции в ВМ как в отдельном сеансе, так и в веб-интерфейсе самой системы управления средой виртуализации; Система управления средой виртуализации должна поддерживать различные варианты копирования ВМ: • полный клон; • связанный клон; • моментальный снимок. Система управления средой виртуализации должна поддерживать следующие протоколы для доступа к консоли ВМ: VNC, SPICE, RDP; Система управления средой виртуализации должна поддерживать массовые операции над ВМ: миграция, старт, выключение. Опция должна быть доступна с помощью графического интерфейса; Система управления средой виртуализации должна поддерживать миграцию и импорт из других платформ и гипервизоров: P2V, V2V (Vmware, Hyper-V, KVM, oVirt) с использованием штатных инструментов самой системы управления средой виртуализации - - Значение характеристики не может изменяться участником закупки

Требования к контейнеризации (ч.1) - Операционная система в соответствии с документом «Требования по безопасности информации к средствам контейнеризации» (ФСТЭК России, 2022, приказ № 118) по 4-му классу защиты должна реализовывать следующие функции безопасности: • изоляция контейнеров; • выявление уязвимостей в образах контейнеров; • проверка корректности конфигурации контейнеров; • контроль целостности контейнеров и их образов; • регистрация событий безопасности; • управление доступом; • идентификация и аутентификация пользователей; • централизованное управление образами контейнеров и контейнерами в средстве контейнеризации. Операционная система должна предоставлять сертифицированные средства контейнеризации (kubernetes или эквивалент, podman или эквивалент) имеющие возможность запуска от непривилегированного пользователя без необходимости запуска какого-либо демона/службы; Все инструменты, в том числе контейнеры, должны входить в состав дистрибутива операционной системы и устанавливаться без обращения по сети к внешним источникам. Набор контейнеров должен включать базовые контейнеры, в том числе и distroless-образ и набор контейнеров для разворачивания кластера kubernetes - - Значение характеристики не может изменяться участником закупки

Требования к контейнеризации (ч.2) - Средства управления образами контейнеров и контейнерами (оркестратор или аналог) должны обеспечивать следующие функции: • создание, модификацию, хранение, получение и удаление образов контейнеров в информационной (автоматизированной) системе; • обновление средства контейнеризации и образов контейнеров из реестра вендора; • чтение, удаление записей о событиях безопасности, формирование отчетов с учетом заданных критериев отбора, выгрузку (экспорт) данных из журнала событий безопасности средства контейнеризации; • анализ возникающих событий безопасности в целях выявления инцидентов безопасности. Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции изоляции контейнеров: • изоляция пространств идентификаторов процессов; • изоляция пространств имен для межпроцессного взаимодействия; • изоляция пространств имен для пользователей и групп; • изоляция пространств имен хостов и доменов; • изоляция сетевых пространств имен; • изоляция пространств имен для иерархии каталогов. В дистрибутиве операционной системы должна быть реализована ролевая модель управления доступом: разработчик образов контейнеров, администратор безопасности средств контейнеризации, администратор информационной (автоматизированной) системы - - Значение характеристики не может изменяться участником закупки

Требования к контейнеризации (ч.3) - Дистрибутив операционной системы должен реализовывать следующие требования к функциям идентификации и аутентификации пользователей: • аутентификация пользователей по паролю; • пароль пользователя должен устанавливаться администратором безопасности средства контейнеризации; • средство контейнеризации должно обеспечивать возможность смены установленного администратором безопасности средства контейнеризации пароля пользователя после его первичной аутентификации; • при попытке ввода неправильного значения пароля пользователя должно выводиться соответствующее сообщение с приглашением ввести правильный пароль еще раз; • при исчерпании установленного максимального количества неуспешных попыток ввода неправильного пароля учетная запись пользователя средства контейнеризации должна быть заблокирована; • разблокировка учетной записи пользователя средства контейнеризации должна осуществляться администратором безопасности средства контейнеризации; • защита пароля пользователя должна обеспечиваться при его вводе за счет отображения вводимых символов условными знаками; • средство контейнеризации должно обеспечивать хранение аутентификационной информации пользователя средства контейнеризации в защищенном формате или в защищенном хранилище; • средство контейнеризации не должно запускать процессы в хостовой операционной системе, обладающие привилегиями администратора информационной (автоматизированной) системы и администратора безопасности информационной (автоматизированной) системы; • пароль пользователя средства контейнеризации должен содержать не менее 8 символов при алфавите пароля не менее 70 символов. Максимальное количество неуспешных попыток аутентификации (ввода неправильного пароля) до блокировки — 4. • указанные условия должны быть преднастроены в дистрибутиве операционной системы в рамках парольной политики по умолчанию - - Значение характеристики не может изменяться участником закупки

Требования к контейнеризации (ч.4) - Дистрибутив операционной системы должен реализовывать специальный механизм по выявлению уязвимостей в образах контейнеров с учетом следующих требований: • выявление известных уязвимостей при создании, первичном запуске и хранении образов контейнеров, самостоятельно или во взаимодействии с сертифицированным средством контроля и анализа защищенности на основе сведений, содержащихся в банке данных угроз безопасности информации БДУ ФСТЭК России (https://bdu.fstec.ru/), а также в иных источниках, содержащих сведения об известных уязвимостях; • оповещение о выявленных уязвимостях в образах контейнеров разработчика образов контейнеров и администратора информационной (автоматизированной) системы; • средство контейнеризации должно обеспечивать запрет создания образов контейнеров, содержащих известные уязвимости критического и высокого уровня опасности (уровень опасности определяется по значению (V) CVSS в CVE). Средства контейнеризации дистрибутива операционной системы должны реализовывать следующие требования к функции управления конфигурацией: • возможность ограничения прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование периферийных устройств, устройств хранения данных и съемных машинных носителей информации (блочных устройств), входящих в состав информационной (автоматизированной) системы; • возможность ограничения прав прикладного программного обеспечения, выполняемого внутри контейнера, на использование вычислительных ресурсов (оперативной памяти, операций ввода-вывода за период времени) хостовой операционной системы; • запрет возможности монтирования средством контейнеризации корневой файловой системы хостовой операционной системы (за исключением режима «только для чтения») - - Значение характеристики не может изменяться участником закупки

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

Требования к контейнеризации (ч.6) - Средства контейнеризации дистрибутива операционной системы должны соответствовать следующим требованиям к регистрации событий безопасности: • для регистрируемых событий безопасности в каждой записи журнала событий безопасности должны регистрироваться номер (уникальный идентификатор) события, дата, время, тип события безопасности; • записи журнала событий безопасности должны представляться в структурированном виде и содержать время события безопасности, взятое из хостовой операционной системы; • должна быть обеспечена запись событий безопасности контейнеров в журнал событий безопасности информационной (автоматизированной) системы с указанием идентификатора контейнера; • журнал событий безопасности средства контейнеризации должен быть доступен только для чтения. При исчерпании области памяти, отведенной под журнал событий безопасности средства контейнеризации, должно осуществляться его архивирование с последующей очисткой; • регистрации подлежат следующие события безопасности: a. неуспешные попытки аутентификации пользователей средства контейнеризации; b. создание, модификация и удаление образов контейнеров; c. получение доступа к образам контейнеров; d. запуск и остановка контейнеров с указанием причины остановки; e. изменение ролевой модели; f. модификация запускаемых контейнеров; g. выявление известных уязвимостей в образах контейнеров и некорректности конфигурации; h. факты нарушения целостности объектов контроля. • должна обеспечиваться запись событий безопасности контейнеров в журнал событий безопасности с указанием идентификатора пользователя хостовой операционной системы, от имени которого был запущен контейнер - - Значение характеристики не может изменяться участником закупки

Нефункциональные требования - Разработчик обязан оказывать гарантийную вендорскую поддержку продукта (оперативный выпуск обновлений по безопасности); Разработчик обязан оказывать техническую поддержку пользователям на условиях SLA в течение первого года использования. Для критических инцидентов должно быть обеспечено время реакции не более 8 часов в период с 9:00 до 19:00 в рабочие дни; Система должна быть основана на программном обеспечении с открытым исходным кодом - - Значение характеристики не может изменяться участником закупки

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Для наиболее полного описания потребности Заказчика

- 62.02.30.000 - Сертификат на техническую поддержку Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 1) Консультационные услуги по электронной почте и телефону: Исполнитель обеспечивает прием обращений от специалистов Заказчика. Исполнитель предоставляет Заказчику контактную информацию для приема обращений: инженерный ресурс; телефон горячей линии для Запросов. Время приёма запросов — 24х7. Консультирование обеспечивается Исполнителем: с 9:00-19:00 (по времени Заказчика) в рабочие дни, 24х7 – для запросов с приоритетом 1 и 2; Сопровождение работоспособности продуктов: Переход на очередной минорный релиз Продукта. Переход на очередной мажорный релиз Продукта. Предоставление актуальной документации на продукт. Доступ к информационному порталу о закрытии уязвимостей. Доступ к обновлениям Продукта (в том числе к обновлениям по безопасности). Помощь в развертывании и настройке хранилищ, в устранении ошибок. Консультации по обновлениям продукта и отдельных его компонент. Доступ к реестру контейнеров вендора и специализированным закрытым репозиториям. Прием сообщений об ошибках. Исправление уязвимостей в Продукте. Выделенный специалист службы сопровождения с 9:00 до 19:00 (МСК) Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 2) Консультирование при установке продуктов: Консультирование по выбору и типу установки защищенной виртуализации. Консультации по установке и базовой настройке хостовой ОС. Консультации по установке и настройке системы управления виртуализацией. Консультации по организации хранения данных (выбор типа хранилищ и ФС, развертывание, репликация и т.п.). Консультации по установке и настройке системы управления Kubernetes (в том числе в root-less режиме). Консультации по установке и настройке Podman и его компонент (настройка политик, создание сервиса регистратора и подписей, работа в rootless-режиме). Консультация по настройке отказоустойчивости. Анализ совместимости оборудования, при наличии технической возможности. Консультация и помощь в миграции физических и виртуальных серверов на платформу виртуализации. Консультации по проектированию инфраструктуры в части использования Продукта Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 3) Консультирование при эксплуатации продуктов: Предоставление рецептов How To по отдельным сценариям использования. Консультация по установке и настройке системы VDI (совместно с PVE). Консультации по установке дополнительного ПО из списка совместимого ПО. Помощь в развертывании, подключении к платформе управления контейнерами и настройке хранилищ, в устранении ошибок. Консультации по использованию реестра контейнеров вендора, где хранятся образы OCI-контейнеров и доступны публичные репозитории с базовыми образами, distroless-образами, а так же продуктовые образы. Консультации по установке и настройке и интеграции дополнительных инфраструктурных систем (мониторинга, управления конфигурациями, резервного копирования и т.п.). Удаленное подключение к системе Пользователя для анализа проблемы и выдача рекомендаций. Помощь по восстановлению работоспособности платформы виртуализации после сбоев. Помощь по восстановлению работоспособности платформы управления контейнерами после сбоев Анализ пользовательской конфигурации Продукта с предоставлением рекомендаций по повышению производительности, отказоустойчивости, соответствию стандартам информационной безопасности - Штука - 4,00 - 350 000,00 - 1 400 000,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 1) Консультационные услуги по электронной почте и телефону: Исполнитель обеспечивает прием обращений от специалистов Заказчика. Исполнитель предоставляет Заказчику контактную информацию для приема обращений: инженерный ресурс; телефон горячей линии для Запросов. Время приёма запросов — 24х7. Консультирование обеспечивается Исполнителем: с 9:00-19:00 (по времени Заказчика) в рабочие дни, 24х7 – для запросов с приоритетом 1 и 2; Сопровождение работоспособности продуктов: Переход на очередной минорный релиз Продукта. Переход на очередной мажорный релиз Продукта. Предоставление актуальной документации на продукт. Доступ к информационному порталу о закрытии уязвимостей. Доступ к обновлениям Продукта (в том числе к обновлениям по безопасности). Помощь в развертывании и настройке хранилищ, в устранении ошибок. Консультации по обновлениям продукта и отдельных его компонент. Доступ к реестру контейнеров вендора и специализированным закрытым репозиториям. Прием сообщений об ошибках. Исправление уязвимостей в Продукте. Выделенный специалист службы сопровождения с 9:00 до 19:00 (МСК) Значение характеристики не может изменяться участником закупки Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 2) Консультирование при установке продуктов: Консультирование по выбору и типу установки защищенной виртуализации. Консультации по установке и базовой настройке хостовой ОС. Консультации по установке и настройке системы управления виртуализацией. Консультации по организации хранения данных (выбор типа хранилищ и ФС, развертывание, репликация и т.п.). Консультации по установке и настройке системы управления Kubernetes (в том числе в root-less режиме). Консультации по установке и настройке Podman и его компонент (настройка политик, создание сервиса регистратора и подписей, работа в rootless-режиме). Консультация по настройке отказоустойчивости. Анализ совместимости оборудования, при наличии технической возможности. Консультация и помощь в миграции физических и виртуальных серверов на платформу виртуализации. Консультации по проектированию инфраструктуры в части использования Продукта Значение характеристики не может изменяться участником закупки Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 3) Консультирование при эксплуатации продуктов: Предоставление рецептов How To по отдельным сценариям использования. Консультация по установке и настройке системы VDI (совместно с PVE). Консультации по установке дополнительного ПО из списка совместимого ПО. Помощь в развертывании, подключении к платформе управления контейнерами и настройке хранилищ, в устранении ошибок. Консультации по использованию реестра контейнеров вендора, где хранятся образы OCI-контейнеров и доступны публичные репозитории с базовыми образами, distroless-образами, а так же продуктовые образы. Консультации по установке и настройке и интеграции дополнительных инфраструктурных систем (мониторинга, управления конфигурациями, резервного копирования и т.п.). Удаленное подключение к системе Пользователя для анализа проблемы и выдача рекомендаций. Помощь по восстановлению работоспособности платформы виртуализации после сбоев. Помощь по восстановлению работоспособности платформы управления контейнерами после сбоев Анализ пользовательской конфигурации Продукта с предоставлением рекомендаций по повышению производительности, отказоустойчивости, соответствию стандартам информационной безопасности Значение характеристики не может изменяться участником закупки Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 4) При наличии технической возможности исполнителя: Решение вопросов Пользователя, связанных с совместимостью оборудования. Моделирование проблемных ситуаций Пользователя на тестовом стенде. Включение пакетов ПО в репозиторий Продукта по инициативе Пользователя (по согласованию с вендором). Обновление пакетов ПО в репозиторий Продукта по инициативе Пользователя (по согласованию с вендором); Полное прекращение работы системы и невозможность нормального функционирования ключевых бизнес-процессов Пользователя - время реакции, не более 1 рабочего часа; Часть программного обеспечения продолжает работать, но его недостаточно для продолжения нормального функционирования ключевых бизнес-процессов Пользователя - время реакции, не более 2 рабочих часов; Некритичные проблемы в работе системы, частичную потерю функционала, которая несет за собой потерю производительности, но не приводит к полному прекращению работы в целом - время реакции, не более 4 рабочих часов; Проблемы, не влияющие на основной функционал, но требующие решения: незначительные ошибки при работе программного обеспечения - время реакции, не более 8 рабочих часов; Вопросы, не требующие срочного решения: ошибки в документации, общие вопросы по использованию - время реакции, не более 16 рабочих часов Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 1) - Консультационные услуги по электронной почте и телефону: Исполнитель обеспечивает прием обращений от специалистов Заказчика. Исполнитель предоставляет Заказчику контактную информацию для приема обращений: инженерный ресурс; телефон горячей линии для Запросов. Время приёма запросов — 24х7. Консультирование обеспечивается Исполнителем: с 9:00-19:00 (по времени Заказчика) в рабочие дни, 24х7 – для запросов с приоритетом 1 и 2; Сопровождение работоспособности продуктов: Переход на очередной минорный релиз Продукта. Переход на очередной мажорный релиз Продукта. Предоставление актуальной документации на продукт. Доступ к информационному порталу о закрытии уязвимостей. Доступ к обновлениям Продукта (в том числе к обновлениям по безопасности). Помощь в развертывании и настройке хранилищ, в устранении ошибок. Консультации по обновлениям продукта и отдельных его компонент. Доступ к реестру контейнеров вендора и специализированным закрытым репозиториям. Прием сообщений об ошибках. Исправление уязвимостей в Продукте. Выделенный специалист службы сопровождения с 9:00 до 19:00 (МСК) - - Значение характеристики не может изменяться участником закупки - Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 2) - Консультирование при установке продуктов: Консультирование по выбору и типу установки защищенной виртуализации. Консультации по установке и базовой настройке хостовой ОС. Консультации по установке и настройке системы управления виртуализацией. Консультации по организации хранения данных (выбор типа хранилищ и ФС, развертывание, репликация и т.п.). Консультации по установке и настройке системы управления Kubernetes (в том числе в root-less режиме). Консультации по установке и настройке Podman и его компонент (настройка политик, создание сервиса регистратора и подписей, работа в rootless-режиме). Консультация по настройке отказоустойчивости. Анализ совместимости оборудования, при наличии технической возможности. Консультация и помощь в миграции физических и виртуальных серверов на платформу виртуализации. Консультации по проектированию инфраструктуры в части использования Продукта - - Значение характеристики не может изменяться участником закупки - Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 3) - Консультирование при эксплуатации продуктов: Предоставление рецептов How To по отдельным сценариям использования. Консультация по установке и настройке системы VDI (совместно с PVE). Консультации по установке дополнительного ПО из списка совместимого ПО. Помощь в развертывании, подключении к платформе управления контейнерами и настройке хранилищ, в устранении ошибок. Консультации по использованию реестра контейнеров вендора, где хранятся образы OCI-контейнеров и доступны публичные репозитории с базовыми образами, distroless-образами, а так же продуктовые образы. Консультации по установке и настройке и интеграции дополнительных инфраструктурных систем (мониторинга, управления конфигурациями, резервного копирования и т.п.). Удаленное подключение к системе Пользователя для анализа проблемы и выдача рекомендаций. Помощь по восстановлению работоспособности платформы виртуализации после сбоев. Помощь по восстановлению работоспособности платформы управления контейнерами после сбоев Анализ пользовательской конфигурации Продукта с предоставлением рекомендаций по повышению производительности, отказоустойчивости, соответствию стандартам информационной безопасности - - Значение характеристики не может изменяться участником закупки - Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 4) - При наличии технической возможности исполнителя: Решение вопросов Пользователя, связанных с совместимостью оборудования. Моделирование проблемных ситуаций Пользователя на тестовом стенде. Включение пакетов ПО в репозиторий Продукта по инициативе Пользователя (по согласованию с вендором). Обновление пакетов ПО в репозиторий Продукта по инициативе Пользователя (по согласованию с вендором); Полное прекращение работы системы и невозможность нормального функционирования ключевых бизнес-процессов Пользователя - время реакции, не более 1 рабочего часа; Часть программного обеспечения продолжает работать, но его недостаточно для продолжения нормального функционирования ключевых бизнес-процессов Пользователя - время реакции, не более 2 рабочих часов; Некритичные проблемы в работе системы, частичную потерю функционала, которая несет за собой потерю производительности, но не приводит к полному прекращению работы в целом - время реакции, не более 4 рабочих часов; Проблемы, не влияющие на основной функционал, но требующие решения: незначительные ошибки при работе программного обеспечения - время реакции, не более 8 рабочих часов; Вопросы, не требующие срочного решения: ошибки в документации, общие вопросы по использованию - время реакции, не более 16 рабочих часов - - Значение характеристики не может изменяться участником закупки

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

Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 1) - Консультационные услуги по электронной почте и телефону: Исполнитель обеспечивает прием обращений от специалистов Заказчика. Исполнитель предоставляет Заказчику контактную информацию для приема обращений: инженерный ресурс; телефон горячей линии для Запросов. Время приёма запросов — 24х7. Консультирование обеспечивается Исполнителем: с 9:00-19:00 (по времени Заказчика) в рабочие дни, 24х7 – для запросов с приоритетом 1 и 2; Сопровождение работоспособности продуктов: Переход на очередной минорный релиз Продукта. Переход на очередной мажорный релиз Продукта. Предоставление актуальной документации на продукт. Доступ к информационному порталу о закрытии уязвимостей. Доступ к обновлениям Продукта (в том числе к обновлениям по безопасности). Помощь в развертывании и настройке хранилищ, в устранении ошибок. Консультации по обновлениям продукта и отдельных его компонент. Доступ к реестру контейнеров вендора и специализированным закрытым репозиториям. Прием сообщений об ошибках. Исправление уязвимостей в Продукте. Выделенный специалист службы сопровождения с 9:00 до 19:00 (МСК) - - Значение характеристики не может изменяться участником закупки

Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 2) - Консультирование при установке продуктов: Консультирование по выбору и типу установки защищенной виртуализации. Консультации по установке и базовой настройке хостовой ОС. Консультации по установке и настройке системы управления виртуализацией. Консультации по организации хранения данных (выбор типа хранилищ и ФС, развертывание, репликация и т.п.). Консультации по установке и настройке системы управления Kubernetes (в том числе в root-less режиме). Консультации по установке и настройке Podman и его компонент (настройка политик, создание сервиса регистратора и подписей, работа в rootless-режиме). Консультация по настройке отказоустойчивости. Анализ совместимости оборудования, при наличии технической возможности. Консультация и помощь в миграции физических и виртуальных серверов на платформу виртуализации. Консультации по проектированию инфраструктуры в части использования Продукта - - Значение характеристики не может изменяться участником закупки

Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 3) - Консультирование при эксплуатации продуктов: Предоставление рецептов How To по отдельным сценариям использования. Консультация по установке и настройке системы VDI (совместно с PVE). Консультации по установке дополнительного ПО из списка совместимого ПО. Помощь в развертывании, подключении к платформе управления контейнерами и настройке хранилищ, в устранении ошибок. Консультации по использованию реестра контейнеров вендора, где хранятся образы OCI-контейнеров и доступны публичные репозитории с базовыми образами, distroless-образами, а так же продуктовые образы. Консультации по установке и настройке и интеграции дополнительных инфраструктурных систем (мониторинга, управления конфигурациями, резервного копирования и т.п.). Удаленное подключение к системе Пользователя для анализа проблемы и выдача рекомендаций. Помощь по восстановлению работоспособности платформы виртуализации после сбоев. Помощь по восстановлению работоспособности платформы управления контейнерами после сбоев Анализ пользовательской конфигурации Продукта с предоставлением рекомендаций по повышению производительности, отказоустойчивости, соответствию стандартам информационной безопасности - - Значение характеристики не может изменяться участником закупки

Объем Сопровождения (технической поддержки) в рамках сертификата (ч. 4) - При наличии технической возможности исполнителя: Решение вопросов Пользователя, связанных с совместимостью оборудования. Моделирование проблемных ситуаций Пользователя на тестовом стенде. Включение пакетов ПО в репозиторий Продукта по инициативе Пользователя (по согласованию с вендором). Обновление пакетов ПО в репозиторий Продукта по инициативе Пользователя (по согласованию с вендором); Полное прекращение работы системы и невозможность нормального функционирования ключевых бизнес-процессов Пользователя - время реакции, не более 1 рабочего часа; Часть программного обеспечения продолжает работать, но его недостаточно для продолжения нормального функционирования ключевых бизнес-процессов Пользователя - время реакции, не более 2 рабочих часов; Некритичные проблемы в работе системы, частичную потерю функционала, которая несет за собой потерю производительности, но не приводит к полному прекращению работы в целом - время реакции, не более 4 рабочих часов; Проблемы, не влияющие на основной функционал, но требующие решения: незначительные ошибки при работе программного обеспечения - время реакции, не более 8 рабочих часов; Вопросы, не требующие срочного решения: ошибки в документации, общие вопросы по использованию - время реакции, не более 16 рабочих часов - - Значение характеристики не может изменяться участником закупки

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

Преимущества: Преимущество в соответствии с ч. 3 ст. 30 Закона № 44-ФЗ - Размер преимущества не установлен

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

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

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

Обеспечение заявки

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

Размер обеспечения заявки: 17 868,75 Российский рубль

Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке, а также условия гарантии: Обеспечение заявки на участие в закупке может предоставляться участником закупки в виде денежных средств или независимой гарантии, предусмотренной ст. 45 Федерального закона № 44-ФЗ (далее - № 44-ФЗ). Выбор способа обеспечения осуществляется участником закупки самостоятельно. Срок действия независимой гарантии должен составлять не менее месяца от даты окончания срока подачи заявок. Обеспечение заявки на участие в закупке предоставляется одним из следующих способов: а) путем блокирования денежных средств на банковском счете, открытом таким участником в банке, включенном в перечень, утвержденный Правительством РФ (далее - специальный счет), для их перевода в случаях, предусмотренных настоящей статьей, на счет, на котором в соответствии с законодательством РФ учитываются операции со средствами, поступающими заказчику, или в соответствующий бюджет бюджетной системы РФ. Требования к таким банкам, к договору специального счета, к порядку использования, имеющегося у участника закупки банковского счета в качестве специального счета устанавливаются Правительством РФ; б) путем предоставления независимой гарантии, соответствующей требованиям ст. 45 № 44-ФЗ; в) участники закупки, являющиеся юридическими лицами, зарегистрированными на территории государства - члена Евразийского экономического союза, за исключением РФ, или физическими лицами, являющимися гражданами государства - члена Евразийского экономического союза, за исключением РФ, вправе предоставить обеспечение заявок в виде денежных средств с учетом особенностей, установленных постановлением Правительства РФ от 10.04.2023 № 579 «Об особенностях порядка предоставления обеспечения заявок на участие в закупках товаров, работ, услуг для обеспечения государственных или муниципальных нужд участниками таких закупок, являющимися иностранными лицами». Информация и документы, подтверждающие предоставление обеспечения заявки, включаются в заявку в форме электронных документов или в форме электронных образов бумажных документов

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03214643000000013225, л/c 20726Х38130, БИК 012202102, ОКЦ № 1 ВВГУ Банка России//УФК по Нижегородской области, г Нижний Новгород, к/c 40102810745370000024

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

Условия контракта

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, г Санкт-Петербург, ул. Литовская, д. 2

Обеспечение исполнения контракта

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

Размер обеспечения исполнения контракта: 10 %

Порядок предоставления обеспечения исполнения контракта, требования к обеспечению: Исполнение контракта, может обеспечиваться независимой гарантии, соответствующей требованиям ст.45 Федерального закона № 44-ФЗ (далее-№ 44-ФЗ), или внесением денежных средств на указанный заказчиком счет, на котором учитываются операции со средствами, поступающими заказчику. Способ обеспечения исполнения контракта, срок действия независимой гарантии определяются в соответствии с требованиями №44-ФЗ участником закупки, с которым заключается контракт, самостоятельно. При этом срок действия независимой гарантии должен превышать предусмотренный контрактом срок исполнения обязательств, не менее чем на один месяц, в том числе в случае его изменения в соответствии со ст.95 № 44-ФЗ. Обеспечение исполнения контракта предоставляется в сроки определенные ст.51 №44-ФЗ. В случае, если цена, сумма цен единиц ТРУ снижены на 25 и более процентов по отношению к НМЦК, начальной сумме цен единиц ТРУ, обеспечение предоставляется с учетом положений ст.37 № 44-ФЗ. Если контракт заключается в соответствии с п.1 ч.1 ст.30 №44-ФЗ, размер обеспечения исполнения контракта устанавливается в соответствии с ч.6 и 6.1 ст.96 №44-ФЗ от цены контракта, по которой в соответствии с № 44-ФЗ заключается контракт. Если предусмотрена выплата аванса, размер обеспечения исполнения контракта устанавливается не менее чем в размере аванса, за исключением случая, если расчеты по контракту в части выплаты аванса подлежат казначейскому сопровождению. Если расчеты по контракту в части выплаты аванса подлежат казначейскому сопровождению, размер обеспечения исполнения контракта устанавливается заказчиком от НМЦК (от ЦК в случае, предусмотренном ч.6.2 ст.96 №44-ФЗ при заключении контракта в соответствии с п.1 ч.1 ст.30 № 44-ФЗ), уменьшенной на размер такого аванса. Если расчеты по контракту подлежат казначейскому сопровождению, размер такого обеспечения устанавливается в размере до 10 процентов от НМЦК (от ЦК в случае, предусмотренном ч.6.2 ст.96 № 44-ФЗ при заключении контракта в соответствии с п.1 ч.1 ст.30 № 44-ФЗ

Платежные реквизиты для обеспечения исполнения контракта: p/c 03214643000000013225, л/c 20726Х38130, БИК 012202102, ОКЦ № 1 ВВГУ Банка России//УФК по Нижегородской области, г Нижний Новгород, к/c 40102810745370000024

Требования к гарантии качества товара, работы, услуги

Требуется гарантия качества товара, работы, услуги: Да

Срок, на который предоставляется гарантия и (или) требования к объему предоставления гарантий качества товара, работы, услуги: Гарантийный срок не менее 12 (двенадцать) месяцев от даты подписания Заказчиком документа о приемке в электронном виде с использованием единой информационной системы.

Информация о банковском и (или) казначейском сопровождении контракта

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

Документы

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

Документы

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