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

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

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

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

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

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

Размещение осуществляет: Заказчик РОСТОВСКАЯ-НА-ДОНУ ГОРОДСКАЯ ДУМА

Наименование объекта закупки: Передача неисключительных прав на использование компьютерного программного обеспечения

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

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

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

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

Организация, осуществляющая размещение: РОСТОВСКАЯ-НА-ДОНУ ГОРОДСКАЯ ДУМА

Почтовый адрес: Российская Федерация, 344002, Ростовская обл, Ростов-на-Дону г, Большая Садовая ул, Д.47

Место нахождения: Российская Федерация, 344002, Ростовская обл, Ростов-на-Дону г, Большая Садовая ул, Д.47

Ответственное должностное лицо: Шкандыба Н. Н.

Адрес электронной почты: sidum@mail.ru

Номер контактного телефона: 7-863-2403465

Факс: 7-863-2694398

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

Регион: Ростовская обл

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

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

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

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

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

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

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

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

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

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

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

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

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

Закупка за счет бюджетных средств: Да

Наименование бюджета: бюджет города Ростова-на-Дону

Вид бюджета: местный бюджет

Код территории муниципального образования: 60701000: Муниципальные образования Ростовской области / Городские округа Ростовской области/ / город Ростов-на-Дону

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

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

- 58.29.11.000 58.29.11.000-00000003 - Программное обеспечение Вид лицензии Простая (неисключительная) Класс программ для электронных вычислительных машин и баз данных (02.07) Средства управления базами данных Способ предоставления Экземпляр на материальном носителе - Штука - 4,00 - 238 781,00 - 955 124,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Вид лицензии Простая (неисключительная) Значение характеристики не может изменяться участником закупки Класс программ для электронных вычислительных машин и баз данных (02.07) Средства управления базами данных Значение характеристики не может изменяться участником закупки Способ предоставления Экземпляр на материальном носителе Значение характеристики не может изменяться участником закупки Общие требования к СУБД Программное обеспечение (ПО) системы управления базами данных (СУБД) должно предоставляться в виде неисключительного права на ПО СУБД. СУБД должна быть включена в Единый реестр российских программ для электронных вычислительных машин и баз данных (reestr.minsvyaz.ru/reestr). Вариант исполнения СУБД, сертифицированный ФСТЭК, должен соответствовать 4-му уровню доверия согласно Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденным приказом ФСТЭК России от 2 июня 2020 г. № 76. Вариант исполнения СУБД, сертифицированный ФСТЭК, должен соответствовать 4-му классу защиты согласно Требованиям по безопасности информации к системам управления базами данных, утвержденным приказом ФСТЭК России от 14 апреля 2023 № 64. СУБД должна быть официально совместима с приложениями (1С, Галактика, Парус и др.). СУБД должны быть официальна совместима с российскими системами резервного копирования (Кибер Бэкап - Реестровая запись №4160 от 11.12.2017 - https://reestr.digital.gov.ru/reestr/305510/?sphrase_id=14279641, RuBackup - Реестровая запись №6808 от 16.07.2020 - https://reestr.digital.gov.ru/reestr/308158/?sphrase_id=14279721 и др.) Значение характеристики не может изменяться участником закупки Базовые требования к СУБД: 1. Поддерживать современные стандарты реляционных баз данных (БД) по требованиям ACID, а именно: - Атомарность (Atomicity) - Согласованность (Consistency) - Изолированность (Isolation) - Устойчивость (Durability) 2. Обеспечивать уровни изоляции транзакций SERIALIZABLE, REPEATABLE READ, READ COMMITTED. 3. Поддерживать управление доступом с помощью многоверсионности (MVCC - MultiVersion Concurrency Control), которая используется для поддержания согласованности данных в конкурентных условиях. 4. Обеспечивать поддержку блокировок на уровне записей. 5. Обеспечивать журнал упреждающей записи (Write-Ahead Logging - WAL), механизм протоколирования транзакций, что позволяет восстановить систему после возможных сбоев. . 6. Обеспечивать ссылочную целостность. 7. Обеспечить возможность добавления новых типов данных, функций, операторов, методов доступа, языков программирования без перекомпилирования ядра СУБД и остановки экземпляра БД. 8. Обеспечить возможность доступа к сторонним данным для работы с СУБД Microsoft SQL Server, MySQL, Oracle и PostgreSQL. Ограничения СУБД: - отсутствие ограничения на размер БД - отсутствие ограничения на максимальное количество записей (строк) - отсутствие ограничения на количество индексов - поддержку таблиц размером не менее 32 ТБ - поддержку не менее 1600 полей (столбцов) в одной таблице - поддержку полей (столбцов) размером не менее 1 ГБ Значение характеристики не может изменяться участником закупки Требования к операционным системам (ОС) и аппаратным платформам: – Операционная система, в среде которой функционирует система управления базами данных, должна быть сертифицирована на соответствие Требованиям в области технического регулирования к продукции, используемой в целях защиты сведений, составляющих государственную тайну или относимых к охраняемой в соответствии с законодательством Российской Федерации иной информации ограниченного доступа (требованиям безопасности информации к операционным системам), утвержденным приказом ФСТЭК России от 19 августа 2016 г. N 119, и Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденным приказом ФСТЭК России от 2 июня 2020 г. N 76. – Система управления базами данных должна функционировать в среде сертифицированной операционной системы, имеющей класс защиты не ниже класса защиты системы управления базами данных. – Система управления базами данных должна функционировать в среде поддерживаемого дистрибутива ОС. СУБД должна предъявлять следующие минимальные требования к аппаратному обеспечению: - процессор - 2 ГГц и более - оперативная память - 2 Гбайт и более - жесткий диск (свободное пространство) - 40 Гбайт и более. Версия ПО: серверная Значение характеристики не может изменяться участником закупки Требования к стандартизации и унификации СУБД должна поддерживать следующие стандартные, унифицированные типы данных: - числовые типы (целочисленные типы: INT, SMALLINT, BIGINT; числа с произвольной точностью; типы с плавающей точкой: REAL, DOUBLE PRESISION, FLOAT; последовательные типы) - денежные типы - символьные типы данных: VARCHAR(n), CHAR(n), TEXT - двоичные типы данных - типы даты и времени: DATE, TIME, TIMESTAMP, TIMESTAMP WITH TIMEZONE, INTERVAL - логический тип BOOLEAN - типы перечислений - геометрические типы - типы, описывающие сетевые адреса - битовые строки - типы данных, предназначенные для текстового поиска - UUID - XML - JSON/JSONB - SQL/JSON - массивы - составные типы - диапазонные типы - типы доменов - идентификаторы объектов - тип pg_lsn - псевдотипы Значение характеристики не может изменяться участником закупки Требования к функциям (задачам), выполняемым системой СУБД должна обладать следующими функциональными характеристиками: - соответствие стандарту SQL (SQL:2016, SQL:2011, SQL:2008, SQL:2006, SQL:2003, SQL:1999 и SQL-92) - поддержка представлений - поддержка внешних ключей - поддержка транзакций - поддержка оконных функций - поддержка наследований - поддержка функций и операторов - поддержка хранимых процедур - поддержка различных типов индексов: B-tree, hash, GiST, SP-GiST, GIN, RUM, BRIN - наличие встроенной системы полнотекстового поиска, средств ускорения полнотекстового поиска и словарей для полнотекстового поиска - поддержка табличных пространств - поддержка табличных триггеров БД и триггеров событий - поддержка процедурных языков, в т.ч. PL/pgSQL, PL/Perl, PL/Python, PL/Tcl - поддержка кодировки UTF8 - поддержка NoSQL - наличие программных интерфейсов для работы с C/C++, Java/JDBC, .NET, ODBC, Perl, Python, Ruby, Tcl - наличие встроенных средств аутентификации пользователей, поддерживающих GSSAPI, SSPI, LDAP, RADIUS, PAM, BSD - поддержка SSL - возможность разграничения доступа к объектам БД - возможность разграничения доступа к таблицам на уровне строк - возможность разграничения доступа на уровне отдельных строк таблицы - возможность безопасного хранения паролей - возможность интеграции с подсистемой SE-Linux Значение характеристики не может изменяться участником закупки Требования к высокой доступности СУБД должна обладать следующими функциональными возможностями по обеспечению сохранности информации при авариях: - наличие встроенных средств репликации данных: синхронная, асинхронная, каскадная - возможность использования различных видов репликации данных: потоковая, логическая - возможность построения отказоустойчивого кластера (ведущий-ведомый) с произвольным количеством реплик (ведомых серверов) в разных конфигурациях (теплый резерв, горячий резерв) - встроенная отказоустойчивость, которая достигается за счёт развёртывания кластера: • с физической репликацией, которая может быть как синхронной, так и асинхронной; • со встроенным механизмом аварийного переключения узлов; • с автоматическим обнаружением сбоя узлов, реагированием и последующим изменением конфигурации кластера; • не требующего дополнительного внешнего кластерного ПО - наличие встроенных средств ‘горячего’ резервного копирования и восстановления данных - возможность полного и инкрементального (на уровне страниц) резервного копирования данных с сохранением журналов транзакций и сжатием, что позволяет экономить место на диске и создавать копии быстрее, чем при полном копировании - возможность полного и инкрементального (на уровне страниц) восстановления данных быстрее, чем воспроизведение файлов WAL - ускорение восстановления из копии благодаря повторному использованию неизменённых страниц, имеющихся в PGDATA - возможность контроля целостности данных и проверки резервных копий без восстановления данных - возможность управление архивами WAL и резервными копиями в соответствии с установленными правилами их хранения Значение характеристики не может изменяться участником закупки Требования к надежности - возможность выполнение операций резервного копирования и восстановления в несколько параллельных потоков - возможность хранения копируемых данных в сжатом состоянии для экономии дискового пространства - возможность получения списка резервных копий и соответствующей метаинформации в виде простого текста или JSON - возможность получения списка всех линий времени в WAL и соответствующей метаинформации в виде простого текста или JSON - возможность восстановления избранной базы данных / объекта базы данных - возможность восстановления на заданный момент в прошлом (point-in-time recovery - PITR) - возможность резервного копирование файлов и каталогов, расположенных вне каталога данных PGDATA, например скриптов, файлов конфигурации, журналов или SQL-дампов - возможность резервного копирования экземпляра СУБД, находящегося в удалённой системе, и его удалённого восстановления - наличие API для облегчения интеграции и создания собственных приложений резервного копирования и восстановления данных Значение характеристики не может изменяться участником закупки Требования к производительности СУБД должна обладать следующими возможностями, обеспечивающими производительность и масштабируемость: - улучшенный механизм проверки блокировок, не оказывающий отрицательного влияния на производительность - увеличенная скорость и эффективность планирования для различных типов запросов - уменьшенное потребление памяти при обработке сложных запросов со множеством таблиц - наличие стоимостного оптимизатора, учитывающего дисковые операции и процессорное время - возможность добавлять поддержку указаний для планировщика, позволяющих отключать или подключать определённые индексы при выполнении запроса (управление планами запросов) - возможность обучения оптимизатора на ошибках и уточнение оценок планирования - возможность проверки целостности таблиц и индексов, в том числе – индекса-B-дерева с ограничением уникальности - возможность применения оптимизации "skip scan" в многостолбцовых индексах, благодаря которой индекс может использоваться не только для проверки первого проиндексированного столбца и полной связки столбцов, но и для обработки по отдельности остальных проиндексированных столбцов - возможность асинхронного подтверждения транзакций - возможность применения асинхронного ввода-вывода для операций чтения, которая позволяет повысить производительность последовательного сканирования, сканирования кучи по битовой карте, процесса очистки и других операций - возможность параллельного выполнения запросов - возможность параллельного создания индексов и параллельного доступа к индексам - возможность сканирования только индекса (покрывающие индексы) - возможность параллельной выгрузки и загрузки данных - поддержка виртуальных генерируемых столбцов, значения которых вычисляются во время операций чтения - возможность сохранения статистики планировщика запросов после обновления между мажорными релизами - поддержка секционирования для больших таблиц - возможность использования большого количества секций (10К+) на таблицу без деградации производительности Значение характеристики не может изменяться участником закупки Требования к масштабируемости - возможность параллельного секционирования таблиц - возможность динамического создания секций для секционированных таблиц - возможность разделения одной секции на несколько или объединения нескольких секций в одну по диапазону значений ключа или по списку значений ключа одной командой Значение характеристики не может изменяться участником закупки Требования к администрированию - наличие собственной графической консоли мониторинга и управления, обеспечивающей интерфейс к основным задачам администрирования, мониторинга и диагностики - наличие центра оперативного контроля, который обеспечивает удобное визуальное представление обо всех контролируемых экземплярах СУБД, а также позволяет просматривать исторические данные по основным метрикам экземпляров в формате графиков. - возможность управления отказоустойчивыми кластерами - их создание, назначение ролей отдельным узлам, установка режимов переключения ролей - возможность группового управления экземплярами СУБД, например, создание и применение пресетов конфигураций - возможность учёта потребляемых ресурсов - маркировка экземпляров, работающих в продуктивной среде и лицензируемых по подписке, подсчет количества ядер сервера, где запущен экземпляр, подготовка отчетов - возможность вызова консольной утилиты PSQL из web-браузера, без непосредственного доступа по ssh - наличие собственного универсального агента мониторинга, поддерживающего протокол Open Telemetry - визуальное представление планов запросов в различных режимах - возможность полноценного управления задачами резервного копирования и восстановления из графической консоли, включая настройки хранения резервных копий и различные режимы восстановления (PITR, отдельные БД, валидация) - возможность реорганизации таблиц с ликвидацией пустот в таблицах и индексах и дополнительным восстановлением физического порядка кластеризованных индексов без исключительных блокировок в ходе обработки таблиц- расширенные возможности загрузки данных (замена нулевого байта заданным ASCII-символом при загрузке данных) - возможность изменения структуры таблицы без блокировки - возможность перестроения индексов без блокировки таблицы - наличие утилиты для автоматической настройки параметров конфигурации СУБД на основе параметров оборудования и типа нагрузки - возможность узнавать текущее состояние выполнения запросов в работающем обслуживающем процессе Значение характеристики не может изменяться участником закупки Требования к администрированию и мониторингу - возможность использования функций для работы с переменными различных типов в рамках текущей сессии - поддержка платформонезависимой сортировки (использование ICU на всех платформах) - наличие унифицированной структуры пакетов Linux, упрощающую миграцию между ними и позволяющая устанавливать несколько различных продуктов на базе PostgreSQL совместно без каких-либо конфликтов - расширенные возможности расширения auto_explain (добавление времени планирования) - наличие выделенного соединения для администратора - возможность для сбора статистики планирования и выполнения всех обрабатываемых сервером SQL-операторов - возможность немедленно обновлять статистику после операций INSERT, UPDATE, DELETE или SELECT INTO в целевых таблицах - возможность периодического сбора статистики по событиям ожидания для понимания характера активности сервера, в т.ч. просмотра текущих событий ожидания во всех обычных и фоновых рабочих процессах - возможность экспортировать статистику таблиц при выгрузке и восстанавливать её вместо того, чтобы выполнять VACUUM ANALYZE после восстановления базы или обновления сервера - наличие встроенного агента мониторинга состояния БД - возможность получать подробные диагностические отчёты по нагрузке за определенный период времени по различным категориям с включением планов запросов для выявления и анализа: • наиболее ресурсоёмких операций в базе данных; • таблиц с наибольшим количеством операций, например, генерирующих большой объём WAL вследствие операций очистки; • расширенной статистики по сессиям, например, чем сессии занимались между основными снимками; • связей между основными ожиданиями в БД и топовыми запросами Значение характеристики не может изменяться участником закупки Требования к мониторингу • распределения нагрузки между несколькими активными БД в одном экземпляре; • агрегированной статистики событий аннулирования по каждой базе данных - возможность трассировки (логирования) сессий пользователей, подпадающих под гибкий набор условий, например: долго выполняющихся, содержащих много дисковых операций, исходящих из определенного бэкенда - возможность узнавать текущее состояние выполнения запросов в работающем обслуживающем процессе - возможность получения плана и прогресса выполнения активных запросов - возможность получения истории и профиля ожиданий сессии - возможность логического декодирования, позволяющая преобразовать изменения базы данных из журнала предзаписи (WAL) в формат JSON Значение характеристики не может изменяться участником закупки Общие требования безопасности информации, предъявляемые к СУБД СУБД должна применяться для защищенной обработки информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну. В СУБД должны использоваться средства защиты информации, соответствующие требованиям по безопасности информации, установленным в документе «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (утв. приказом ФСТЭК России от 02.06.2020 N 76) – не ниже 4 уровня доверия. В СУБД должны использоваться средства защиты информации, соответствующие требованиям по безопасности информации, установленным в документе «Требования по безопасности информации к системам управления базами данных» (утв. приказом ФСТЭК России от 14.04.2023 N 64) – не ниже 4 класса защиты. В сертифицированный дистрибутив СУБД должны входить минимум три мажорные версии Значение характеристики не может изменяться участником закупки СУБД должна обеспечивать защиту информации, содержащейся в базах данных, находящихся под их управлением, путем реализации следующих процессов - ролевой метод управления доступом для следующих ролей пользователей СУБД: администратор СУБД, администратор базы данных (администратор информационной системы), пользователь базы данных (пользователь информационной системы); - управление параметрами ролей через профили, которые задают парольные политики (длину, сложность, срок жизни, число неудачных попыток входа до блокировки), а также - блокирование и разблокирование ролей; - идентификация и аутентификация субъектов доступа, предоставление доступа к базе данных в случае успешной аутентификации пользователя, блокирование доступа к базе данных в случае неуспешной аутентификации пользователя; - поддержка механизма аутентификации и авторизации OAuth 2.0, который позволяет сторонним приложениям получать ограниченный доступ к защищённым ресурсам; - поддержка синхронизации ролей и привилегий СУБД с группами LDAP - возможность временного использования одновременно старого и нового пароля для его бесшовной смены у технологических учётных записей; - наличие утилиты для поиска чувствительной информации в СУБД с использованием мета-словаря, содержащего маски для проверки имен и содержимого полей по набору регулярных выражений и константным значениям - управление доступом субъектов доступа к объектам доступа, предоставление пользователям запрашиваемых типов доступа к объектам СУБД в соответствии с реализуемым методом управления доступом Значение характеристики не может изменяться участником закупки Требования к защите информации от несанкционированного доступа - регистрация событий безопасности, связанных с функционированием СУБД и действиями пользователей СУБД, с указанием важности и записью как в централизованное средство журналирования операционной системы (syslog), так и в файлы Common Event Format (при интеграции с SIEM-системой) или в CSV-формат; - обеспечение целостности исполняемых файлов СУБД, библиотек и других неизменяемых файлов, а также – файлов конфигурации БД; блокировка работы (запуска) экземпляра БД в случае обнаружения фактов нарушения целостности; - встроенные механизмы защиты данных, которые позволяют стерилизовать объекты, перед удалением заполняя их нулями. Обнуление объектов может производиться перед удалением файлов на диске и перед удалением устаревших версий строк (очисткой страниц), освобождением ОЗУ и удалением или перезаписью файлов WAL; - обеспечение доступности информации: резервное копирование и восстановление информации, содержащейся в базе данных Значение характеристики не может изменяться участником закупки Требования к гарантийной поддержке, документации и разработке СУБД Требования к гарантийной поддержке СУБД: - Предоставление базовой услуги Техподдержки СУБД в режиме 24х7 на территории РФ с целевым временем обработки заявок высшего приоритета (не хуже): • Время реакции – 15 мин. в режиме 24х7 • Время предоставления решения – 4 ч. в режиме 24х7 • Время исправления ошибки в коде – 24 ч. в режиме 24х7 - Наличие телефонной ‘горячей линии’ Техподдержки 24х7 - Наличие портала Техподдержки с доступом: • к информации о составе купленных Заказчиком лицензий и сроках их действия; • к бинарным репозиториям для установки и обновления ПО вендора; • к интерфейсу самообслуживания Заказчика для создания новых заявок на поддержку и работе с ними; • к архиву закрытых заявок и заявок других сотрудников Заказчика; • к Базе знаний отдела Техподдержки вендора; - Экстренный выпуск патчей / исправлений ошибок в коде СУБД - Получение технических консультаций Требования к документации СУБД: - Наличие русскоязычной документации в электронном виде на сайте Производителя СУБД с описанием реализации всех функций СУБД - Наличие документации по всем поддерживаемым версиям СУБД Требования к разработке СУБД: - Доступность по крайней мере трёх последних поддерживаемых мажорных версий СУБД с актуальными обновлениями - Периодичность выпуска новых версий СУБД с обновлениями не реже одного раза в квартал - Выпуск внеочередных версий СУБД с исправлениями (в т.ч. исправлениями безопасности) - Наличие опубликованного плана доработок СУБД (roadmap) - Наличие доработок / патчей специалистами Производителя СУБД в основную ветку базовой версии СУБД (PostgreSQL или др.) - Наличие у Производителя СУБД специалистов со статусом Contributor / Major Contributor (PostgreSQL или др.) - Наличие у Производителя СУБД сертификата разработчика безопасного программного обеспечения Значение характеристики не может изменяться участником закупки Условия передачи неисключительного права При передаче неисключительных прав (прав использования) на ПО необходимо не разглашать и не использовать во вред Заказчику полученные в рамках передачи неисключительного права (права использования) на передаваемое ПО сведения о Заказчике, о степени защищенности объектов информатизации, мероприятиях, применяемых для их защиты, персональные данные и информацию, прямо названную Заказчиком конфиденциальной. Передача указанной информации другим лицам может быть осуществлена только с письменного согласия Заказчика. За разглашение сведений, составляющих служебную, коммерческую и иную тайну, а также представляющих собой персональные данные, и нанесенный в результате этого ущерб Поставщик несет ответственность в соответствии с действующим законодательством Российской Федерации Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки - Класс программ для электронных вычислительных машин и баз данных - (02.07) Средства управления базами данных - - Значение характеристики не может изменяться участником закупки - Способ предоставления - Экземпляр на материальном носителе - - Значение характеристики не может изменяться участником закупки - Общие требования к СУБД - Программное обеспечение (ПО) системы управления базами данных (СУБД) должно предоставляться в виде неисключительного права на ПО СУБД. СУБД должна быть включена в Единый реестр российских программ для электронных вычислительных машин и баз данных (reestr.minsvyaz.ru/reestr). Вариант исполнения СУБД, сертифицированный ФСТЭК, должен соответствовать 4-му уровню доверия согласно Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденным приказом ФСТЭК России от 2 июня 2020 г. № 76. Вариант исполнения СУБД, сертифицированный ФСТЭК, должен соответствовать 4-му классу защиты согласно Требованиям по безопасности информации к системам управления базами данных, утвержденным приказом ФСТЭК России от 14 апреля 2023 № 64. СУБД должна быть официально совместима с приложениями (1С, Галактика, Парус и др.). СУБД должны быть официальна совместима с российскими системами резервного копирования (Кибер Бэкап - Реестровая запись №4160 от 11.12.2017 - https://reestr.digital.gov.ru/reestr/305510/?sphrase_id=14279641, RuBackup - Реестровая запись №6808 от 16.07.2020 - https://reestr.digital.gov.ru/reestr/308158/?sphrase_id=14279721 и др.) - - Значение характеристики не может изменяться участником закупки - Базовые требования к СУБД: - 1. Поддерживать современные стандарты реляционных баз данных (БД) по требованиям ACID, а именно: - Атомарность (Atomicity) - Согласованность (Consistency) - Изолированность (Isolation) - Устойчивость (Durability) 2. Обеспечивать уровни изоляции транзакций SERIALIZABLE, REPEATABLE READ, READ COMMITTED. 3. Поддерживать управление доступом с помощью многоверсионности (MVCC - MultiVersion Concurrency Control), которая используется для поддержания согласованности данных в конкурентных условиях. 4. Обеспечивать поддержку блокировок на уровне записей. 5. Обеспечивать журнал упреждающей записи (Write-Ahead Logging - WAL), механизм протоколирования транзакций, что позволяет восстановить систему после возможных сбоев. . 6. Обеспечивать ссылочную целостность. 7. Обеспечить возможность добавления новых типов данных, функций, операторов, методов доступа, языков программирования без перекомпилирования ядра СУБД и остановки экземпляра БД. 8. Обеспечить возможность доступа к сторонним данным для работы с СУБД Microsoft SQL Server, MySQL, Oracle и PostgreSQL. Ограничения СУБД: - отсутствие ограничения на размер БД - отсутствие ограничения на максимальное количество записей (строк) - отсутствие ограничения на количество индексов - поддержку таблиц размером не менее 32 ТБ - поддержку не менее 1600 полей (столбцов) в одной таблице - поддержку полей (столбцов) размером не менее 1 ГБ - - Значение характеристики не может изменяться участником закупки - Требования к операционным системам (ОС) и аппаратным платформам: - – Операционная система, в среде которой функционирует система управления базами данных, должна быть сертифицирована на соответствие Требованиям в области технического регулирования к продукции, используемой в целях защиты сведений, составляющих государственную тайну или относимых к охраняемой в соответствии с законодательством Российской Федерации иной информации ограниченного доступа (требованиям безопасности информации к операционным системам), утвержденным приказом ФСТЭК России от 19 августа 2016 г. N 119, и Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденным приказом ФСТЭК России от 2 июня 2020 г. N 76. – Система управления базами данных должна функционировать в среде сертифицированной операционной системы, имеющей класс защиты не ниже класса защиты системы управления базами данных. – Система управления базами данных должна функционировать в среде поддерживаемого дистрибутива ОС. СУБД должна предъявлять следующие минимальные требования к аппаратному обеспечению: - процессор - 2 ГГц и более - оперативная память - 2 Гбайт и более - жесткий диск (свободное пространство) - 40 Гбайт и более. Версия ПО: серверная - - Значение характеристики не может изменяться участником закупки - Требования к стандартизации и унификации - СУБД должна поддерживать следующие стандартные, унифицированные типы данных: - числовые типы (целочисленные типы: INT, SMALLINT, BIGINT; числа с произвольной точностью; типы с плавающей точкой: REAL, DOUBLE PRESISION, FLOAT; последовательные типы) - денежные типы - символьные типы данных: VARCHAR(n), CHAR(n), TEXT - двоичные типы данных - типы даты и времени: DATE, TIME, TIMESTAMP, TIMESTAMP WITH TIMEZONE, INTERVAL - логический тип BOOLEAN - типы перечислений - геометрические типы - типы, описывающие сетевые адреса - битовые строки - типы данных, предназначенные для текстового поиска - UUID - XML - JSON/JSONB - SQL/JSON - массивы - составные типы - диапазонные типы - типы доменов - идентификаторы объектов - тип pg_lsn - псевдотипы - - Значение характеристики не может изменяться участником закупки - Требования к функциям (задачам), выполняемым системой - СУБД должна обладать следующими функциональными характеристиками: - соответствие стандарту SQL (SQL:2016, SQL:2011, SQL:2008, SQL:2006, SQL:2003, SQL:1999 и SQL-92) - поддержка представлений - поддержка внешних ключей - поддержка транзакций - поддержка оконных функций - поддержка наследований - поддержка функций и операторов - поддержка хранимых процедур - поддержка различных типов индексов: B-tree, hash, GiST, SP-GiST, GIN, RUM, BRIN - наличие встроенной системы полнотекстового поиска, средств ускорения полнотекстового поиска и словарей для полнотекстового поиска - поддержка табличных пространств - поддержка табличных триггеров БД и триггеров событий - поддержка процедурных языков, в т.ч. PL/pgSQL, PL/Perl, PL/Python, PL/Tcl - поддержка кодировки UTF8 - поддержка NoSQL - наличие программных интерфейсов для работы с C/C++, Java/JDBC, .NET, ODBC, Perl, Python, Ruby, Tcl - наличие встроенных средств аутентификации пользователей, поддерживающих GSSAPI, SSPI, LDAP, RADIUS, PAM, BSD - поддержка SSL - возможность разграничения доступа к объектам БД - возможность разграничения доступа к таблицам на уровне строк - возможность разграничения доступа на уровне отдельных строк таблицы - возможность безопасного хранения паролей - возможность интеграции с подсистемой SE-Linux - - Значение характеристики не может изменяться участником закупки - Требования к высокой доступности - СУБД должна обладать следующими функциональными возможностями по обеспечению сохранности информации при авариях: - наличие встроенных средств репликации данных: синхронная, асинхронная, каскадная - возможность использования различных видов репликации данных: потоковая, логическая - возможность построения отказоустойчивого кластера (ведущий-ведомый) с произвольным количеством реплик (ведомых серверов) в разных конфигурациях (теплый резерв, горячий резерв) - встроенная отказоустойчивость, которая достигается за счёт развёртывания кластера: • с физической репликацией, которая может быть как синхронной, так и асинхронной; • со встроенным механизмом аварийного переключения узлов; • с автоматическим обнаружением сбоя узлов, реагированием и последующим изменением конфигурации кластера; • не требующего дополнительного внешнего кластерного ПО - наличие встроенных средств ‘горячего’ резервного копирования и восстановления данных - возможность полного и инкрементального (на уровне страниц) резервного копирования данных с сохранением журналов транзакций и сжатием, что позволяет экономить место на диске и создавать копии быстрее, чем при полном копировании - возможность полного и инкрементального (на уровне страниц) восстановления данных быстрее, чем воспроизведение файлов WAL - ускорение восстановления из копии благодаря повторному использованию неизменённых страниц, имеющихся в PGDATA - возможность контроля целостности данных и проверки резервных копий без восстановления данных - возможность управление архивами WAL и резервными копиями в соответствии с установленными правилами их хранения - - Значение характеристики не может изменяться участником закупки - Требования к надежности - - возможность выполнение операций резервного копирования и восстановления в несколько параллельных потоков - возможность хранения копируемых данных в сжатом состоянии для экономии дискового пространства - возможность получения списка резервных копий и соответствующей метаинформации в виде простого текста или JSON - возможность получения списка всех линий времени в WAL и соответствующей метаинформации в виде простого текста или JSON - возможность восстановления избранной базы данных / объекта базы данных - возможность восстановления на заданный момент в прошлом (point-in-time recovery - PITR) - возможность резервного копирование файлов и каталогов, расположенных вне каталога данных PGDATA, например скриптов, файлов конфигурации, журналов или SQL-дампов - возможность резервного копирования экземпляра СУБД, находящегося в удалённой системе, и его удалённого восстановления - наличие API для облегчения интеграции и создания собственных приложений резервного копирования и восстановления данных - - Значение характеристики не может изменяться участником закупки - Требования к производительности - СУБД должна обладать следующими возможностями, обеспечивающими производительность и масштабируемость: - улучшенный механизм проверки блокировок, не оказывающий отрицательного влияния на производительность - увеличенная скорость и эффективность планирования для различных типов запросов - уменьшенное потребление памяти при обработке сложных запросов со множеством таблиц - наличие стоимостного оптимизатора, учитывающего дисковые операции и процессорное время - возможность добавлять поддержку указаний для планировщика, позволяющих отключать или подключать определённые индексы при выполнении запроса (управление планами запросов) - возможность обучения оптимизатора на ошибках и уточнение оценок планирования - возможность проверки целостности таблиц и индексов, в том числе – индекса-B-дерева с ограничением уникальности - возможность применения оптимизации "skip scan" в многостолбцовых индексах, благодаря которой индекс может использоваться не только для проверки первого проиндексированного столбца и полной связки столбцов, но и для обработки по отдельности остальных проиндексированных столбцов - возможность асинхронного подтверждения транзакций - возможность применения асинхронного ввода-вывода для операций чтения, которая позволяет повысить производительность последовательного сканирования, сканирования кучи по битовой карте, процесса очистки и других операций - возможность параллельного выполнения запросов - возможность параллельного создания индексов и параллельного доступа к индексам - возможность сканирования только индекса (покрывающие индексы) - возможность параллельной выгрузки и загрузки данных - поддержка виртуальных генерируемых столбцов, значения которых вычисляются во время операций чтения - возможность сохранения статистики планировщика запросов после обновления между мажорными релизами - поддержка секционирования для больших таблиц - возможность использования большого количества секций (10К+) на таблицу без деградации производительности - - Значение характеристики не может изменяться участником закупки - Требования к масштабируемости - - возможность параллельного секционирования таблиц - возможность динамического создания секций для секционированных таблиц - возможность разделения одной секции на несколько или объединения нескольких секций в одну по диапазону значений ключа или по списку значений ключа одной командой - - Значение характеристики не может изменяться участником закупки - Требования к администрированию - - наличие собственной графической консоли мониторинга и управления, обеспечивающей интерфейс к основным задачам администрирования, мониторинга и диагностики - наличие центра оперативного контроля, который обеспечивает удобное визуальное представление обо всех контролируемых экземплярах СУБД, а также позволяет просматривать исторические данные по основным метрикам экземпляров в формате графиков. - возможность управления отказоустойчивыми кластерами - их создание, назначение ролей отдельным узлам, установка режимов переключения ролей - возможность группового управления экземплярами СУБД, например, создание и применение пресетов конфигураций - возможность учёта потребляемых ресурсов - маркировка экземпляров, работающих в продуктивной среде и лицензируемых по подписке, подсчет количества ядер сервера, где запущен экземпляр, подготовка отчетов - возможность вызова консольной утилиты PSQL из web-браузера, без непосредственного доступа по ssh - наличие собственного универсального агента мониторинга, поддерживающего протокол Open Telemetry - визуальное представление планов запросов в различных режимах - возможность полноценного управления задачами резервного копирования и восстановления из графической консоли, включая настройки хранения резервных копий и различные режимы восстановления (PITR, отдельные БД, валидация) - возможность реорганизации таблиц с ликвидацией пустот в таблицах и индексах и дополнительным восстановлением физического порядка кластеризованных индексов без исключительных блокировок в ходе обработки таблиц- расширенные возможности загрузки данных (замена нулевого байта заданным ASCII-символом при загрузке данных) - возможность изменения структуры таблицы без блокировки - возможность перестроения индексов без блокировки таблицы - наличие утилиты для автоматической настройки параметров конфигурации СУБД на основе параметров оборудования и типа нагрузки - возможность узнавать текущее состояние выполнения запросов в работающем обслуживающем процессе - - Значение характеристики не может изменяться участником закупки - Требования к администрированию и мониторингу - - возможность использования функций для работы с переменными различных типов в рамках текущей сессии - поддержка платформонезависимой сортировки (использование ICU на всех платформах) - наличие унифицированной структуры пакетов Linux, упрощающую миграцию между ними и позволяющая устанавливать несколько различных продуктов на базе PostgreSQL совместно без каких-либо конфликтов - расширенные возможности расширения auto_explain (добавление времени планирования) - наличие выделенного соединения для администратора - возможность для сбора статистики планирования и выполнения всех обрабатываемых сервером SQL-операторов - возможность немедленно обновлять статистику после операций INSERT, UPDATE, DELETE или SELECT INTO в целевых таблицах - возможность периодического сбора статистики по событиям ожидания для понимания характера активности сервера, в т.ч. просмотра текущих событий ожидания во всех обычных и фоновых рабочих процессах - возможность экспортировать статистику таблиц при выгрузке и восстанавливать её вместо того, чтобы выполнять VACUUM ANALYZE после восстановления базы или обновления сервера - наличие встроенного агента мониторинга состояния БД - возможность получать подробные диагностические отчёты по нагрузке за определенный период времени по различным категориям с включением планов запросов для выявления и анализа: • наиболее ресурсоёмких операций в базе данных; • таблиц с наибольшим количеством операций, например, генерирующих большой объём WAL вследствие операций очистки; • расширенной статистики по сессиям, например, чем сессии занимались между основными снимками; • связей между основными ожиданиями в БД и топовыми запросами - - Значение характеристики не может изменяться участником закупки - Требования к мониторингу - • распределения нагрузки между несколькими активными БД в одном экземпляре; • агрегированной статистики событий аннулирования по каждой базе данных - возможность трассировки (логирования) сессий пользователей, подпадающих под гибкий набор условий, например: долго выполняющихся, содержащих много дисковых операций, исходящих из определенного бэкенда - возможность узнавать текущее состояние выполнения запросов в работающем обслуживающем процессе - возможность получения плана и прогресса выполнения активных запросов - возможность получения истории и профиля ожиданий сессии - возможность логического декодирования, позволяющая преобразовать изменения базы данных из журнала предзаписи (WAL) в формат JSON - - Значение характеристики не может изменяться участником закупки - Общие требования безопасности информации, предъявляемые к СУБД - СУБД должна применяться для защищенной обработки информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну. В СУБД должны использоваться средства защиты информации, соответствующие требованиям по безопасности информации, установленным в документе «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (утв. приказом ФСТЭК России от 02.06.2020 N 76) – не ниже 4 уровня доверия. В СУБД должны использоваться средства защиты информации, соответствующие требованиям по безопасности информации, установленным в документе «Требования по безопасности информации к системам управления базами данных» (утв. приказом ФСТЭК России от 14.04.2023 N 64) – не ниже 4 класса защиты. В сертифицированный дистрибутив СУБД должны входить минимум три мажорные версии - - Значение характеристики не может изменяться участником закупки - СУБД должна обеспечивать защиту информации, содержащейся в базах данных, находящихся под их управлением, путем реализации следующих процессов - - ролевой метод управления доступом для следующих ролей пользователей СУБД: администратор СУБД, администратор базы данных (администратор информационной системы), пользователь базы данных (пользователь информационной системы); - управление параметрами ролей через профили, которые задают парольные политики (длину, сложность, срок жизни, число неудачных попыток входа до блокировки), а также - блокирование и разблокирование ролей; - идентификация и аутентификация субъектов доступа, предоставление доступа к базе данных в случае успешной аутентификации пользователя, блокирование доступа к базе данных в случае неуспешной аутентификации пользователя; - поддержка механизма аутентификации и авторизации OAuth 2.0, который позволяет сторонним приложениям получать ограниченный доступ к защищённым ресурсам; - поддержка синхронизации ролей и привилегий СУБД с группами LDAP - возможность временного использования одновременно старого и нового пароля для его бесшовной смены у технологических учётных записей; - наличие утилиты для поиска чувствительной информации в СУБД с использованием мета-словаря, содержащего маски для проверки имен и содержимого полей по набору регулярных выражений и константным значениям - управление доступом субъектов доступа к объектам доступа, предоставление пользователям запрашиваемых типов доступа к объектам СУБД в соответствии с реализуемым методом управления доступом - - Значение характеристики не может изменяться участником закупки - Требования к защите информации от несанкционированного доступа - - регистрация событий безопасности, связанных с функционированием СУБД и действиями пользователей СУБД, с указанием важности и записью как в централизованное средство журналирования операционной системы (syslog), так и в файлы Common Event Format (при интеграции с SIEM-системой) или в CSV-формат; - обеспечение целостности исполняемых файлов СУБД, библиотек и других неизменяемых файлов, а также – файлов конфигурации БД; блокировка работы (запуска) экземпляра БД в случае обнаружения фактов нарушения целостности; - встроенные механизмы защиты данных, которые позволяют стерилизовать объекты, перед удалением заполняя их нулями. Обнуление объектов может производиться перед удалением файлов на диске и перед удалением устаревших версий строк (очисткой страниц), освобождением ОЗУ и удалением или перезаписью файлов WAL; - обеспечение доступности информации: резервное копирование и восстановление информации, содержащейся в базе данных - - Значение характеристики не может изменяться участником закупки - Требования к гарантийной поддержке, документации и разработке СУБД - Требования к гарантийной поддержке СУБД: - Предоставление базовой услуги Техподдержки СУБД в режиме 24х7 на территории РФ с целевым временем обработки заявок высшего приоритета (не хуже): • Время реакции – 15 мин. в режиме 24х7 • Время предоставления решения – 4 ч. в режиме 24х7 • Время исправления ошибки в коде – 24 ч. в режиме 24х7 - Наличие телефонной ‘горячей линии’ Техподдержки 24х7 - Наличие портала Техподдержки с доступом: • к информации о составе купленных Заказчиком лицензий и сроках их действия; • к бинарным репозиториям для установки и обновления ПО вендора; • к интерфейсу самообслуживания Заказчика для создания новых заявок на поддержку и работе с ними; • к архиву закрытых заявок и заявок других сотрудников Заказчика; • к Базе знаний отдела Техподдержки вендора; - Экстренный выпуск патчей / исправлений ошибок в коде СУБД - Получение технических консультаций Требования к документации СУБД: - Наличие русскоязычной документации в электронном виде на сайте Производителя СУБД с описанием реализации всех функций СУБД - Наличие документации по всем поддерживаемым версиям СУБД Требования к разработке СУБД: - Доступность по крайней мере трёх последних поддерживаемых мажорных версий СУБД с актуальными обновлениями - Периодичность выпуска новых версий СУБД с обновлениями не реже одного раза в квартал - Выпуск внеочередных версий СУБД с исправлениями (в т.ч. исправлениями безопасности) - Наличие опубликованного плана доработок СУБД (roadmap) - Наличие доработок / патчей специалистами Производителя СУБД в основную ветку базовой версии СУБД (PostgreSQL или др.) - Наличие у Производителя СУБД специалистов со статусом Contributor / Major Contributor (PostgreSQL или др.) - Наличие у Производителя СУБД сертификата разработчика безопасного программного обеспечения - - Значение характеристики не может изменяться участником закупки - Условия передачи неисключительного права - При передаче неисключительных прав (прав использования) на ПО необходимо не разглашать и не использовать во вред Заказчику полученные в рамках передачи неисключительного права (права использования) на передаваемое ПО сведения о Заказчике, о степени защищенности объектов информатизации, мероприятиях, применяемых для их защиты, персональные данные и информацию, прямо названную Заказчиком конфиденциальной. Передача указанной информации другим лицам может быть осуществлена только с письменного согласия Заказчика. За разглашение сведений, составляющих служебную, коммерческую и иную тайну, а также представляющих собой персональные данные, и нанесенный в результате этого ущерб Поставщик несет ответственность в соответствии с действующим законодательством Российской Федерации - - Значение характеристики не может изменяться участником закупки

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

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

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

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

Общие требования к СУБД - Программное обеспечение (ПО) системы управления базами данных (СУБД) должно предоставляться в виде неисключительного права на ПО СУБД. СУБД должна быть включена в Единый реестр российских программ для электронных вычислительных машин и баз данных (reestr.minsvyaz.ru/reestr). Вариант исполнения СУБД, сертифицированный ФСТЭК, должен соответствовать 4-му уровню доверия согласно Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденным приказом ФСТЭК России от 2 июня 2020 г. № 76. Вариант исполнения СУБД, сертифицированный ФСТЭК, должен соответствовать 4-му классу защиты согласно Требованиям по безопасности информации к системам управления базами данных, утвержденным приказом ФСТЭК России от 14 апреля 2023 № 64. СУБД должна быть официально совместима с приложениями (1С, Галактика, Парус и др.). СУБД должны быть официальна совместима с российскими системами резервного копирования (Кибер Бэкап - Реестровая запись №4160 от 11.12.2017 - https://reestr.digital.gov.ru/reestr/305510/?sphrase_id=14279641, RuBackup - Реестровая запись №6808 от 16.07.2020 - https://reestr.digital.gov.ru/reestr/308158/?sphrase_id=14279721 и др.) - - Значение характеристики не может изменяться участником закупки

Базовые требования к СУБД: - 1. Поддерживать современные стандарты реляционных баз данных (БД) по требованиям ACID, а именно: - Атомарность (Atomicity) - Согласованность (Consistency) - Изолированность (Isolation) - Устойчивость (Durability) 2. Обеспечивать уровни изоляции транзакций SERIALIZABLE, REPEATABLE READ, READ COMMITTED. 3. Поддерживать управление доступом с помощью многоверсионности (MVCC - MultiVersion Concurrency Control), которая используется для поддержания согласованности данных в конкурентных условиях. 4. Обеспечивать поддержку блокировок на уровне записей. 5. Обеспечивать журнал упреждающей записи (Write-Ahead Logging - WAL), механизм протоколирования транзакций, что позволяет восстановить систему после возможных сбоев. . 6. Обеспечивать ссылочную целостность. 7. Обеспечить возможность добавления новых типов данных, функций, операторов, методов доступа, языков программирования без перекомпилирования ядра СУБД и остановки экземпляра БД. 8. Обеспечить возможность доступа к сторонним данным для работы с СУБД Microsoft SQL Server, MySQL, Oracle и PostgreSQL. Ограничения СУБД: - отсутствие ограничения на размер БД - отсутствие ограничения на максимальное количество записей (строк) - отсутствие ограничения на количество индексов - поддержку таблиц размером не менее 32 ТБ - поддержку не менее 1600 полей (столбцов) в одной таблице - поддержку полей (столбцов) размером не менее 1 ГБ - - Значение характеристики не может изменяться участником закупки

Требования к операционным системам (ОС) и аппаратным платформам: - – Операционная система, в среде которой функционирует система управления базами данных, должна быть сертифицирована на соответствие Требованиям в области технического регулирования к продукции, используемой в целях защиты сведений, составляющих государственную тайну или относимых к охраняемой в соответствии с законодательством Российской Федерации иной информации ограниченного доступа (требованиям безопасности информации к операционным системам), утвержденным приказом ФСТЭК России от 19 августа 2016 г. N 119, и Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденным приказом ФСТЭК России от 2 июня 2020 г. N 76. – Система управления базами данных должна функционировать в среде сертифицированной операционной системы, имеющей класс защиты не ниже класса защиты системы управления базами данных. – Система управления базами данных должна функционировать в среде поддерживаемого дистрибутива ОС. СУБД должна предъявлять следующие минимальные требования к аппаратному обеспечению: - процессор - 2 ГГц и более - оперативная память - 2 Гбайт и более - жесткий диск (свободное пространство) - 40 Гбайт и более. Версия ПО: серверная - - Значение характеристики не может изменяться участником закупки

Требования к стандартизации и унификации - СУБД должна поддерживать следующие стандартные, унифицированные типы данных: - числовые типы (целочисленные типы: INT, SMALLINT, BIGINT; числа с произвольной точностью; типы с плавающей точкой: REAL, DOUBLE PRESISION, FLOAT; последовательные типы) - денежные типы - символьные типы данных: VARCHAR(n), CHAR(n), TEXT - двоичные типы данных - типы даты и времени: DATE, TIME, TIMESTAMP, TIMESTAMP WITH TIMEZONE, INTERVAL - логический тип BOOLEAN - типы перечислений - геометрические типы - типы, описывающие сетевые адреса - битовые строки - типы данных, предназначенные для текстового поиска - UUID - XML - JSON/JSONB - SQL/JSON - массивы - составные типы - диапазонные типы - типы доменов - идентификаторы объектов - тип pg_lsn - псевдотипы - - Значение характеристики не может изменяться участником закупки

Требования к функциям (задачам), выполняемым системой - СУБД должна обладать следующими функциональными характеристиками: - соответствие стандарту SQL (SQL:2016, SQL:2011, SQL:2008, SQL:2006, SQL:2003, SQL:1999 и SQL-92) - поддержка представлений - поддержка внешних ключей - поддержка транзакций - поддержка оконных функций - поддержка наследований - поддержка функций и операторов - поддержка хранимых процедур - поддержка различных типов индексов: B-tree, hash, GiST, SP-GiST, GIN, RUM, BRIN - наличие встроенной системы полнотекстового поиска, средств ускорения полнотекстового поиска и словарей для полнотекстового поиска - поддержка табличных пространств - поддержка табличных триггеров БД и триггеров событий - поддержка процедурных языков, в т.ч. PL/pgSQL, PL/Perl, PL/Python, PL/Tcl - поддержка кодировки UTF8 - поддержка NoSQL - наличие программных интерфейсов для работы с C/C++, Java/JDBC, .NET, ODBC, Perl, Python, Ruby, Tcl - наличие встроенных средств аутентификации пользователей, поддерживающих GSSAPI, SSPI, LDAP, RADIUS, PAM, BSD - поддержка SSL - возможность разграничения доступа к объектам БД - возможность разграничения доступа к таблицам на уровне строк - возможность разграничения доступа на уровне отдельных строк таблицы - возможность безопасного хранения паролей - возможность интеграции с подсистемой SE-Linux - - Значение характеристики не может изменяться участником закупки

Требования к высокой доступности - СУБД должна обладать следующими функциональными возможностями по обеспечению сохранности информации при авариях: - наличие встроенных средств репликации данных: синхронная, асинхронная, каскадная - возможность использования различных видов репликации данных: потоковая, логическая - возможность построения отказоустойчивого кластера (ведущий-ведомый) с произвольным количеством реплик (ведомых серверов) в разных конфигурациях (теплый резерв, горячий резерв) - встроенная отказоустойчивость, которая достигается за счёт развёртывания кластера: • с физической репликацией, которая может быть как синхронной, так и асинхронной; • со встроенным механизмом аварийного переключения узлов; • с автоматическим обнаружением сбоя узлов, реагированием и последующим изменением конфигурации кластера; • не требующего дополнительного внешнего кластерного ПО - наличие встроенных средств ‘горячего’ резервного копирования и восстановления данных - возможность полного и инкрементального (на уровне страниц) резервного копирования данных с сохранением журналов транзакций и сжатием, что позволяет экономить место на диске и создавать копии быстрее, чем при полном копировании - возможность полного и инкрементального (на уровне страниц) восстановления данных быстрее, чем воспроизведение файлов WAL - ускорение восстановления из копии благодаря повторному использованию неизменённых страниц, имеющихся в PGDATA - возможность контроля целостности данных и проверки резервных копий без восстановления данных - возможность управление архивами WAL и резервными копиями в соответствии с установленными правилами их хранения - - Значение характеристики не может изменяться участником закупки

Требования к надежности - - возможность выполнение операций резервного копирования и восстановления в несколько параллельных потоков - возможность хранения копируемых данных в сжатом состоянии для экономии дискового пространства - возможность получения списка резервных копий и соответствующей метаинформации в виде простого текста или JSON - возможность получения списка всех линий времени в WAL и соответствующей метаинформации в виде простого текста или JSON - возможность восстановления избранной базы данных / объекта базы данных - возможность восстановления на заданный момент в прошлом (point-in-time recovery - PITR) - возможность резервного копирование файлов и каталогов, расположенных вне каталога данных PGDATA, например скриптов, файлов конфигурации, журналов или SQL-дампов - возможность резервного копирования экземпляра СУБД, находящегося в удалённой системе, и его удалённого восстановления - наличие API для облегчения интеграции и создания собственных приложений резервного копирования и восстановления данных - - Значение характеристики не может изменяться участником закупки

Требования к производительности - СУБД должна обладать следующими возможностями, обеспечивающими производительность и масштабируемость: - улучшенный механизм проверки блокировок, не оказывающий отрицательного влияния на производительность - увеличенная скорость и эффективность планирования для различных типов запросов - уменьшенное потребление памяти при обработке сложных запросов со множеством таблиц - наличие стоимостного оптимизатора, учитывающего дисковые операции и процессорное время - возможность добавлять поддержку указаний для планировщика, позволяющих отключать или подключать определённые индексы при выполнении запроса (управление планами запросов) - возможность обучения оптимизатора на ошибках и уточнение оценок планирования - возможность проверки целостности таблиц и индексов, в том числе – индекса-B-дерева с ограничением уникальности - возможность применения оптимизации "skip scan" в многостолбцовых индексах, благодаря которой индекс может использоваться не только для проверки первого проиндексированного столбца и полной связки столбцов, но и для обработки по отдельности остальных проиндексированных столбцов - возможность асинхронного подтверждения транзакций - возможность применения асинхронного ввода-вывода для операций чтения, которая позволяет повысить производительность последовательного сканирования, сканирования кучи по битовой карте, процесса очистки и других операций - возможность параллельного выполнения запросов - возможность параллельного создания индексов и параллельного доступа к индексам - возможность сканирования только индекса (покрывающие индексы) - возможность параллельной выгрузки и загрузки данных - поддержка виртуальных генерируемых столбцов, значения которых вычисляются во время операций чтения - возможность сохранения статистики планировщика запросов после обновления между мажорными релизами - поддержка секционирования для больших таблиц - возможность использования большого количества секций (10К+) на таблицу без деградации производительности - - Значение характеристики не может изменяться участником закупки

Требования к масштабируемости - - возможность параллельного секционирования таблиц - возможность динамического создания секций для секционированных таблиц - возможность разделения одной секции на несколько или объединения нескольких секций в одну по диапазону значений ключа или по списку значений ключа одной командой - - Значение характеристики не может изменяться участником закупки

Требования к администрированию - - наличие собственной графической консоли мониторинга и управления, обеспечивающей интерфейс к основным задачам администрирования, мониторинга и диагностики - наличие центра оперативного контроля, который обеспечивает удобное визуальное представление обо всех контролируемых экземплярах СУБД, а также позволяет просматривать исторические данные по основным метрикам экземпляров в формате графиков. - возможность управления отказоустойчивыми кластерами - их создание, назначение ролей отдельным узлам, установка режимов переключения ролей - возможность группового управления экземплярами СУБД, например, создание и применение пресетов конфигураций - возможность учёта потребляемых ресурсов - маркировка экземпляров, работающих в продуктивной среде и лицензируемых по подписке, подсчет количества ядер сервера, где запущен экземпляр, подготовка отчетов - возможность вызова консольной утилиты PSQL из web-браузера, без непосредственного доступа по ssh - наличие собственного универсального агента мониторинга, поддерживающего протокол Open Telemetry - визуальное представление планов запросов в различных режимах - возможность полноценного управления задачами резервного копирования и восстановления из графической консоли, включая настройки хранения резервных копий и различные режимы восстановления (PITR, отдельные БД, валидация) - возможность реорганизации таблиц с ликвидацией пустот в таблицах и индексах и дополнительным восстановлением физического порядка кластеризованных индексов без исключительных блокировок в ходе обработки таблиц- расширенные возможности загрузки данных (замена нулевого байта заданным ASCII-символом при загрузке данных) - возможность изменения структуры таблицы без блокировки - возможность перестроения индексов без блокировки таблицы - наличие утилиты для автоматической настройки параметров конфигурации СУБД на основе параметров оборудования и типа нагрузки - возможность узнавать текущее состояние выполнения запросов в работающем обслуживающем процессе - - Значение характеристики не может изменяться участником закупки

Требования к администрированию и мониторингу - - возможность использования функций для работы с переменными различных типов в рамках текущей сессии - поддержка платформонезависимой сортировки (использование ICU на всех платформах) - наличие унифицированной структуры пакетов Linux, упрощающую миграцию между ними и позволяющая устанавливать несколько различных продуктов на базе PostgreSQL совместно без каких-либо конфликтов - расширенные возможности расширения auto_explain (добавление времени планирования) - наличие выделенного соединения для администратора - возможность для сбора статистики планирования и выполнения всех обрабатываемых сервером SQL-операторов - возможность немедленно обновлять статистику после операций INSERT, UPDATE, DELETE или SELECT INTO в целевых таблицах - возможность периодического сбора статистики по событиям ожидания для понимания характера активности сервера, в т.ч. просмотра текущих событий ожидания во всех обычных и фоновых рабочих процессах - возможность экспортировать статистику таблиц при выгрузке и восстанавливать её вместо того, чтобы выполнять VACUUM ANALYZE после восстановления базы или обновления сервера - наличие встроенного агента мониторинга состояния БД - возможность получать подробные диагностические отчёты по нагрузке за определенный период времени по различным категориям с включением планов запросов для выявления и анализа: • наиболее ресурсоёмких операций в базе данных; • таблиц с наибольшим количеством операций, например, генерирующих большой объём WAL вследствие операций очистки; • расширенной статистики по сессиям, например, чем сессии занимались между основными снимками; • связей между основными ожиданиями в БД и топовыми запросами - - Значение характеристики не может изменяться участником закупки

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

Общие требования безопасности информации, предъявляемые к СУБД - СУБД должна применяться для защищенной обработки информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну. В СУБД должны использоваться средства защиты информации, соответствующие требованиям по безопасности информации, установленным в документе «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (утв. приказом ФСТЭК России от 02.06.2020 N 76) – не ниже 4 уровня доверия. В СУБД должны использоваться средства защиты информации, соответствующие требованиям по безопасности информации, установленным в документе «Требования по безопасности информации к системам управления базами данных» (утв. приказом ФСТЭК России от 14.04.2023 N 64) – не ниже 4 класса защиты. В сертифицированный дистрибутив СУБД должны входить минимум три мажорные версии - - Значение характеристики не может изменяться участником закупки

СУБД должна обеспечивать защиту информации, содержащейся в базах данных, находящихся под их управлением, путем реализации следующих процессов - - ролевой метод управления доступом для следующих ролей пользователей СУБД: администратор СУБД, администратор базы данных (администратор информационной системы), пользователь базы данных (пользователь информационной системы); - управление параметрами ролей через профили, которые задают парольные политики (длину, сложность, срок жизни, число неудачных попыток входа до блокировки), а также - блокирование и разблокирование ролей; - идентификация и аутентификация субъектов доступа, предоставление доступа к базе данных в случае успешной аутентификации пользователя, блокирование доступа к базе данных в случае неуспешной аутентификации пользователя; - поддержка механизма аутентификации и авторизации OAuth 2.0, который позволяет сторонним приложениям получать ограниченный доступ к защищённым ресурсам; - поддержка синхронизации ролей и привилегий СУБД с группами LDAP - возможность временного использования одновременно старого и нового пароля для его бесшовной смены у технологических учётных записей; - наличие утилиты для поиска чувствительной информации в СУБД с использованием мета-словаря, содержащего маски для проверки имен и содержимого полей по набору регулярных выражений и константным значениям - управление доступом субъектов доступа к объектам доступа, предоставление пользователям запрашиваемых типов доступа к объектам СУБД в соответствии с реализуемым методом управления доступом - - Значение характеристики не может изменяться участником закупки

Требования к защите информации от несанкционированного доступа - - регистрация событий безопасности, связанных с функционированием СУБД и действиями пользователей СУБД, с указанием важности и записью как в централизованное средство журналирования операционной системы (syslog), так и в файлы Common Event Format (при интеграции с SIEM-системой) или в CSV-формат; - обеспечение целостности исполняемых файлов СУБД, библиотек и других неизменяемых файлов, а также – файлов конфигурации БД; блокировка работы (запуска) экземпляра БД в случае обнаружения фактов нарушения целостности; - встроенные механизмы защиты данных, которые позволяют стерилизовать объекты, перед удалением заполняя их нулями. Обнуление объектов может производиться перед удалением файлов на диске и перед удалением устаревших версий строк (очисткой страниц), освобождением ОЗУ и удалением или перезаписью файлов WAL; - обеспечение доступности информации: резервное копирование и восстановление информации, содержащейся в базе данных - - Значение характеристики не может изменяться участником закупки

Требования к гарантийной поддержке, документации и разработке СУБД - Требования к гарантийной поддержке СУБД: - Предоставление базовой услуги Техподдержки СУБД в режиме 24х7 на территории РФ с целевым временем обработки заявок высшего приоритета (не хуже): • Время реакции – 15 мин. в режиме 24х7 • Время предоставления решения – 4 ч. в режиме 24х7 • Время исправления ошибки в коде – 24 ч. в режиме 24х7 - Наличие телефонной ‘горячей линии’ Техподдержки 24х7 - Наличие портала Техподдержки с доступом: • к информации о составе купленных Заказчиком лицензий и сроках их действия; • к бинарным репозиториям для установки и обновления ПО вендора; • к интерфейсу самообслуживания Заказчика для создания новых заявок на поддержку и работе с ними; • к архиву закрытых заявок и заявок других сотрудников Заказчика; • к Базе знаний отдела Техподдержки вендора; - Экстренный выпуск патчей / исправлений ошибок в коде СУБД - Получение технических консультаций Требования к документации СУБД: - Наличие русскоязычной документации в электронном виде на сайте Производителя СУБД с описанием реализации всех функций СУБД - Наличие документации по всем поддерживаемым версиям СУБД Требования к разработке СУБД: - Доступность по крайней мере трёх последних поддерживаемых мажорных версий СУБД с актуальными обновлениями - Периодичность выпуска новых версий СУБД с обновлениями не реже одного раза в квартал - Выпуск внеочередных версий СУБД с исправлениями (в т.ч. исправлениями безопасности) - Наличие опубликованного плана доработок СУБД (roadmap) - Наличие доработок / патчей специалистами Производителя СУБД в основную ветку базовой версии СУБД (PostgreSQL или др.) - Наличие у Производителя СУБД специалистов со статусом Contributor / Major Contributor (PostgreSQL или др.) - Наличие у Производителя СУБД сертификата разработчика безопасного программного обеспечения - - Значение характеристики не может изменяться участником закупки

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

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Дополнительные характеристики установлены Заказчиком в связи с недостаточностью характеристик, приведенных в КТРУ для закупки программного обеспечения, требуемого Заказчику. Применение параметров, касающихся технических, функциональных (потребительских свойств) и качественных характеристик программного обеспечения, не учтенных КТРУ, обусловлено необходимостью поставки программного обеспечения надлежащего качества, с параметрами, в наибольшей степени удовлетворяющими потребности Заказчика для перехода на новую систему электронного документооборота.

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

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Вид лицензии Простая (неисключительная) Значение характеристики не может изменяться участником закупки Класс программ для электронных вычислительных машин и баз данных (02.09) Операционные системы общего назначения Значение характеристики не может изменяться участником закупки Способ предоставления Экземпляр на материальном носителе Значение характеристики не может изменяться участником закупки Общие требования 1. Программное обеспечение должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных Минкомсвязи РФ по классам «Операционные системы общего назначения», «Средства виртуализации», «Серверное и связующее программное обеспечение», «Средства управления базами данных», «Системы контейнеризации и контейнеры», «Средства защиты от несанкционированного доступа к информации». 2. Операционная система должна соответствовать требованиям документов: a. «Требования безопасности информации к операционным системам» (утвержденным приказом ФСТЭК России от 19 августа 2016 года N 119) и «Профиль защиты операционных систем типа «А» четвертого класса защиты ИТ.ОС.А4.ПЗ» (утв. ФСТЭК России 08.02.2017). b. «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» не ниже четвертого уровня доверия (приказ ФСТЭК России № 76 от 2 июня 2020 г.). c. «Требования по безопасности информации к средствам контейнеризации» (утв. приказом ФСТЭК России от 04.07.2022 N 118) не ниже 4 класса защиты. d. «Требования по безопасности информации к средствам виртуализации» (утв. приказом ФСТЭК России от 27.10.2022 N 187) не ниже 4 класса защиты. e. «Требования по безопасности информации к системам управления базами данных» (утв. приказом ФСТЭК России от 14.04.2023 N 64) не ниже 4 класса защиты. 3. В Формуляре ОС должны быть указаны интерпретаторы, веб сервера и сервера приложений, проверенные согласно документу: «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении», утверждена ФСТЭК России 25.12.2020 г. 4. Разработчик должен иметь собственную инфраструктуру разработки полного цикла, зарегистрированную и находящуюся на территории РФ, в исключительной юрисдикции РФ. 5. Наличие локализованной сервисной и/или технической поддержки Значение характеристики не может изменяться участником закупки Функциональные требования (1-5) 1. Операционная система должна устанавливаться и функционировать на компьютерах с архитектурами x86_64 (64-разрядный процессор Intel или AMD), aarch64 («Байкал», Rockchip 3588) и «Эльбрус» (процессоры 8С, 1С+, 8СВ, 2С3, 12С, 16С) должны быть отдельные образы в сертифицированном исполнении для каждой архитектуры. Требования, перечисленные в данном документе, относятся к архитектуре x86_64 и могут отличаться от требований к другим архитектурам. 2. Операционная система должна поддерживать режимы установки и загрузки Legacy/CSM, UEFI (с включенным механизмом SecureBoot), а также средствами BMC/IPMI (если поддерживается оборудованием). 3. Операционная система должна иметь в составе ядро не ниже 6.12 (LTS) для обеспечения корректного функционирования современных средств вычислительной техники. Система должна предоставлять графические утилиты для установки, удаления и обновления ядра, включая модули, а также для выбора ядра по умолчанию. 4. Операционная система должна обеспечивать поддержку нескольких видеокарт (работа на нескольких мониторах). 5. Операционная система должна обладать русифицированным интерфейсом, а также предоставлять русскоязычную документацию Значение характеристики не может изменяться участником закупки Функциональные требования (6-10) 6. Операционная система должна иметь возможность установки с DVD-диска и USB-накопителя. Операционная система должна предоставлять варианты сетевой установки: PXE/TFTP (для режима Legacy/CSM-загрузки), HTTPClient (для спецификации UEFI 2.5 и выше), iPXE. 7. Операционная система должна предоставлять возможность организации сервера сетевой загрузки. 8. Операционная система должна предоставлять возможность установки на оборудование без графической подсистемы с локального накопителя, а также установки с использованием сервера сетевой установки по протоколу VNC. 9. Носитель с дистрибутивом ОС должен предусматривать вариант загрузки для проведения работ по восстановлению системы, включая проверку сохранности содержимого файловой системы и проверку контрольных сумм неизменяемых файлов установленных пакетов, диагностику конфигурации аппаратного обеспечения, изменение таблицы и размеров разделов, изменение параметров файловых систем, восстановление удаленных разделов и файлов, проведение резервного копирования, очистку остаточной информации на разделах и дисках. 10. Операционная система должна иметь возможность установки на программный RAID-массив, размещения разделов в томах LVM и использования маскирования (кодирования) разделов с парольным доступом Значение характеристики не может изменяться участником закупки Функциональные требования (11-15) 11. Операционная система должна обеспечивать возможность создания точек восстановления (снапшотов) для последующего возвращения системы к исходному состоянию в случае сбоя. 12. Инсталлятор дистрибутива должен предусматривать возможность предварительной (OEM) установки, позволяющей при первом запуске пользователем после установки выбрать язык, принять лицензионное соглашение, настроить дату/время, настроить сеть, задать пароль root, создать системного пользователя. 13. Операционная система должна предоставлять независимый выбор основных и дополнительных приложений в момент установки: серверные приложения (dhcp, dns,ftp, http, почтовый сервер, сервер резервного копирования, сервер печати, сервер сетевой установки), сканер обнаружения уязвимостей, сервер сертифицированной СУБД, сервер управления конфигурациями, сервер виртуальных рабочих столов, средства управления контейнеризацией, средства управления виртуализацией. 14. Операционная система после установки должна предоставлять пользователю рабочую среду, включающую системное ПО, сетевые службы и сервисы, драйвера устройств, утилиты администрирования, базовый набор приложений. 15. Если установлена графическая среда, операционная система должна предоставлять графическое средство настройки многопользовательского режима, позволяющего обеспечить одновременную работу нескольких пользователей на одном компьютере при наличии отдельной видеокарты, клавиатуры и мыши для каждого пользователя Значение характеристики не может изменяться участником закупки Функциональные требования (16-20) 16. Операционная система должна предоставлять инструмент для поиска уязвимостей в файлах конфигурации, файловых системах, используемых пакетах ОС (включая программные зависимости), образах контейнеров и git-репозиториях. Анализ уязвимостей должен осуществляться как по вендорской базе уязвимостей (CVE), собранной из разных источников, так и по базе уязвимостей (BDU) ФСТЭК России. 17. Операционная система должна предоставлять возможность установки пароля на загрузчик для ограничения доступа к опциям загрузки. 18. Операционная система должна предоставлять возможность блокировки виртуальных текстовых консолей. 19. Комплекс средств защиты ОС должен обеспечивать выполнение программ в защищенной среде. В состав ОС должны быть включены программные интерпретаторы (php, perl, lua, python, nodejs) и веб-сервер (nginx), прошедшие испытания по выявлению уязвимостей и недекларированных возможностей в полном объеме в соответствии с Методикой выявления уязвимостей и недекларированных возможностей в программном обеспечении, утвержденной ФСТЭК России 25.12.2020 г. 20. Операционная система должна включать приложение для мониторинга ресурсов. Должно быть обеспечено централизованное управление конфигурациями прав доступа к утилите мониторинга температуры жесткого диска Значение характеристики не может изменяться участником закупки Функциональные требования (21-25) 21. Операционная система должна предоставлять единый графический модульный интерфейс для администрирования и настроек, а также предоставлять возможность удаленного администрирования по защищенным протоколам с помощью графических утилит (включая конфигурирование установленной системы через веб). Администратор должен иметь возможность назначить права доступа для пользователей к определенным модулям. В состав базовых сервисов должны входить: • настройка даты и времени; • управление системными службами; • просмотр системных журналов; • конфигурирование сетевых подключений и межсетевого экрана; • установка обновлений, в том числе для компьютеров без доступа в интернет; • управление выключением удаленного компьютера; • управление пользователями; • настройка пользовательских квот на использование ресурсов памяти, диска и внешних носителей. 22. Операционная система должна реализовывать возможность хранения аутентификационной информации пользователей, полученной с использованием хеш-функций по ГОСТ Р 34.11-2012. Реализация функционала должна быть обеспечена как консольными, так и графическими утилитами. 23. Операционная система должна обеспечивать возможность создания ssh-туннелей, использующих контроль целостности заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015. 24. Операционная система должна предоставлять возможность авторизации по смарт-картам в консольном режиме. 25. Операционная система должна предоставлять протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе Значение характеристики не может изменяться участником закупки Функциональные требования (26-28) 26. Операционная система должна предоставлять возможность разграничения доступа к подключаемым устройствам. 27. Операционная система должна иметь возможность организации домена Samba-DC или интеграции с доменом Active Directory с поддержкой следующего функционала: • действовать в качестве первичного или вторичного контроллера домена; • аутентификация рабочих станций; • авторизация и предоставление ресурсов без дополнительного ввода пароля (Single Sign-On); • поддержка ролей и привилегий (назначение ролей группам); • групповые политики (GPO). 28. Операционная система должна предоставлять возможность организации трастовых доменов Значение характеристики не может изменяться участником закупки Функциональные требования (29) 29. При работе в гетерогенной среде домена 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. • Возможность принудительного выполнения политики на клиенте Значение характеристики не может изменяться участником закупки Функциональные требования (30) 30. Операционная система должна предоставлять возможность организации и настройки базовых сетевых сервисов и служб: • sshd; • DNS; • DHCP; • протокол аутентификации LDAP; • OpenVPN; • SMTP, POP3/IMAP (postfix, dovecot или эквивалент); • межсетевой экран; • проксирование HTTP- и FTP-запросов (squid или эквивалент); • резервное копирование (bacula или эквивалент); • сервер сетевой установки с веб-интерфейсом; • сервер обновлений с возможностью зеркалирования репозитория вендора ОС и создания служебных репозиториев используемого Заказчиком ПО; • защищенный сервер баз данных (PostgreSQL или эквивалент) с возможностью организации кластера из нескольких серверов, со встроенной реализацией функций round, trunc, date совместимой с Oracle DB; • веб-сервер; • FTP-сервер; • сервер мониторинга сетевых ресурсов с графическим интерфейсом (Zabbix, icinga2 или эквивалент); • сервер печати; • сервер групповой работы с веб-интерфейсом (SOGo или эквивалент); • сервер файлового обмена Значение характеристики не может изменяться участником закупки Функциональные требования (31.a-h) 31. Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: a. Программное обеспечение (ПО) должно создавать и управлять резервными копиями виртуальных машин (ВМ), контейнеров и физических узлов, содержащие архивы файлов и образов. b. ПО должно предоставлять интегрированный клиент для QEMU и LXC в виртуальной среде Proxmox. c. ПО должно поддерживать резервное копирование на магнитную ленту и управление ленточными библиотеками. d. ПО должно поддерживать дедупликацию, сжатие и аутентифицированое шифрование данных. e. ПО должно использовать следующие алгоритмы сжатия данных lzo, gzip и zstd. f. ПО должно содержать в себе веб-интерфейс (RESTful API) управления со встроенной в него консолью, доступ должен осуществляться через системную аутентификацию Linux PAM. g. ПО должно хранить данные резервных копий и предоставлять RESTful API для создания хранилищ данных и управления ими и другими ресурсами на стороне сервера. h. ПО должно позволять с помощью API, предоставленного серверной частью, позволять клиенту резервного копирования получать доступ к сохранённым данным для создания и восстановления резервных копий файлов, а также для управления дисками и другими ресурсами на стороне сервера Значение характеристики не может изменяться участником закупки Функциональные требования (31.i-o) i. ПО должно использовать протокол TLS для обеспечения безопасности обмена данными между клиентской и серверной частями. j. ПО должно использовать алгоритм AES-256 GCM при шифровании содержимого резервной копии на стороне клиента. k. ПО должно позволять создавать хранилища данных с файловой системой форматов ext4, xfs. l. ПО должно содержать в себе набор инструментов, используемых для мониторинга и управления системой S.M.A.R.T. для локальных жёстких дисков, с возможностью отображения атрибутов S.M.A.R.T. из веб-интерфейса или при помощи командной строки. m. ПО должно идентифицировать каждое хранилище данных именем и указанием на каталог в файловой системе и связывать с каждым хранилищем параметры хранения, определяющие количество снимков резервных копий для каждого интервала времени: час, день, неделя, месяц, год. n. ПО должно позволять создавать хранилища данных с возможностью выбора и настройки следующих параметров: название; путь к каталогу; количество резервных копий для хранения в этом хранилище; расписания периодического запуска удаления резервных копий и сборки мусора (удаления неиспользуемых блоков данных). o. ПО должно позволять ограничить входящий (например, резервное копирование) и исходящий (например, восстановление) сетевой трафик из набора сетей, с возможностью настроить определенные периоды, в которые будут применяться ограничения Значение характеристики не может изменяться участником закупки Функциональные требования (31.p-t) p. ПО должно позволять создавать пользователей и управлять ими как из встроенного веб-интерфейса, так и с помощью командной строки, с возможностью создания/удаления/отключения учетных записей, просмотра списка пользователей с возможностью изменения любых свойств. q. ПО должно позволять любому аутентифицированному пользователю генерировать API-токены и использовать их для настройки клиентов резервного копирования вместо прямого указания имени пользователя и пароля. API-токен должен отзываться в случае компрометации клиента и ограничивать разрешения для каждого клиента/токена в рамках разрешения пользователей. ПО должно создавать для токенов собственные записи ACL, где токены не могут делать больше, чем создавший их пользователь. r. ПО должно использовать систему управления разрешениями на основе ролей и путей, где роль содержит набор разрешенных действий, а путь представляет цель этих действий. По умолчанию разрешения созданным пользователям и API-токенам не должны предоставляться. s. ПО должно предопределять следующий ряд ролей: нет привилегий (используется для запрета доступа); все привилегии; доступ только для чтения; все привилегии для хранилищ данных; просмотр настроек хранилищ и их содержимых, без возможности чтения фактических данных; просмотр содержимого хранилища, восстановление данных; создание и восстановление собственных резервных копий; создание, восстановление и удаление собственных резервных копий; все привилегии для удалённых серверов; просмотр настроек удалённых серверов; чтение данных с удалённых серверов. t. ПО должно создавать, хранить и предоставлять следующую информацию о правах доступа: идентификатор ACL; включено или отключено; объект, на который установлено разрешение; пользователи/токены, для которых установлено разрешение; устанавливаемая роль Значение характеристики не может изменяться участником закупки Функциональные требования (31.u-36) u. ПО должно реализовывать возможность использования двухфакторной аутентификации с помощью веб-интерфейса тремя методами: TOTP (одноразовый пароль на основе времени) — для создания этого кода должен использоваться алгоритм одноразового пароля с учетом времени входа в систему (код меняется каждые 30 секунд); WebAuthn (веб-аутентификация) — реализуется с помощью различных устройств безопасности, таких как аппаратные ключи или доверенные платформенные модули (TPM). Для работы веб-аутентификации необходим сертификат HTTPS; Recovery Keys (одноразовые ключи восстановления) — список ключей, каждый из которых можно использовать только один раз. В каждый момент времени у пользователя может быть только один набор одноразовых ключей. 32. Операционная система должна предоставлять возможность установления безопасных сетевых соединений по технологии VPN. 33. Операционная система должна обеспечивать возможность создания VPN-туннелей, использующих контроль заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015. 34. Операционная система должна реализовывать базовый функционал межсетевого экрана. 35. Операционная система должна предоставлять возможность установки многоплатформенного брокера подключений для создания и управления виртуальными рабочими местами и приложениями (OpenUDS или аналог). 36. Операционная система должна включать графическое приложение для мониторинга ресурсов и просмотра системных журналов Значение характеристики не может изменяться участником закупки Функциональные требования (37-43) 37. Операционная система должна предоставлять возможность одновременной работы пользователей в изолированных сеансах. Должны быть предусмотрены: • отдельное изолированное хранение данных аутентификации каждого пользователя системы таким образом, чтобы процессы аутентификации локального или сетевого пользователя не могли получить доступа к данным аутентификации и авторизации других пользователей системы; • поддержка изоляции временных пользовательских файлов. 38. Операционная система должна включать автоматизированные средства изоляции приложений, чувствительных к сетевым атакам. 39. Операционная система должна предоставлять упреждающие меры защиты и быть сконфигурирована с безопасными настройками по умолчанию. 40. Операционная система должна предоставлять механизм управления фиксированными состояниями ключевых объектов безопасности системы, сохраняющий установленные права доступа к объектам файловой системы при обновлении пакетов. 41. Операционная система должна обеспечивать поддержку шифрования по ГОСТ Р 34.11-2012 в OpenSSL, включая генерацию ключей и создание сертификатов. 42. Операционная система должна предоставлять инструмент проверки контрольных сумм неизменяемых файлов установленных пакетов как при начальной установке, так и после получения обновлений. Вендор должен обеспечивать доступ к обновлениям и контрольным суммам неизменяемых файлов пакетов в них. 43. Подсистема контроля целостности операционной системы должна поддерживать технологии IMA и EVM Значение характеристики не может изменяться участником закупки Функциональные требования (44-52) 44. Операционная система должна предоставлять возможность запрета запуска выбранных интерпретаторов в интерактивном режиме, отключения возможности удаления открытых файлов, а также установки запрета бита исполнения (SUID), распространяемого на дочерние процессы. 45. Операционная система должна поддерживать файловые системы ext2, ext3, ext4, btrfs для чтения/записи и установки, iso9660, xfs, fat16, fat32, ntfs. 46. Операционная система должна поддерживать сетевые протоколы SMB, NFS, FTP, NTP, HTTP(S). 47. Операционная система должна предоставлять возможность доустановки необходимого программного обеспечения с диска или из репозитория, а также установки обновлений. Система должна обеспечить автоматическую проверку зависимостей (apt или эквивалент), а также возможность комплексного обновления системы с отдельным процессом установки ядра ядра с помощью графических утилит. 48. Исходные коды, обновления, инструменты для сборки серверной ОС должны находиться в том же репозитории (хранилище), где хранятся исходные коды, обновления и инструменты для ОС рабочих станций. 49. Операционная система должна предоставлять единую систему для установки прикладного программного обеспечения в системе (eepm или аналог). Также должна быть обеспечена возможность установки сторонних приложений в форматах deb, tgz, tbz, tbz2, pkg.gz. 50. Операционная система должна поддерживать корневые сертификаты Минцифры России. В составе дистрибутива должен присутствовать пакет с отечественными корневыми сертификатами шифрования. 51. Операционная система должна поддерживать корневые сертификаты Российского центра сертификации ТЦИ, предоставляемые соответствующим пакетом из состава ОС. 52. Совместимость со сторонним программным обеспечением. Подсистема настольных приложений должна быть совместима с СЭД на базе программного обеспечения «ДЕЛО» (Правообладатель ООО «Электронные офисные системы», Свидетельство о гос.регистрации программы для ЭВМ № 2006614189 от 06.12.2006 г.) Значение характеристики не может изменяться участником закупки Нефункциональные требования 1. Разработчик обязан оказывать гарантийную вендорскую поддержку продукта (оперативный выпуск обновлений по безопасности). 2. Разработчик обязан оказывать техническую поддержку пользователям на условиях SLA в течение первого года использования. Для критических инцидентов должно быть обеспечено время реакции не более 8 часов в период с 9:00 до 19:00 в рабочие дни. 3. Система должна быть основана на программном обеспечении с открытым исходным кодом Значение характеристики не может изменяться участником закупки Условия передачи неисключительного права При передаче неисключительных прав (прав использования) на ПО необходимо не разглашать и не использовать во вред Заказчику полученные в рамках передачи неисключительного права (права использования) на передаваемое ПО сведения о Заказчике, о степени защищенности объектов информатизации, мероприятиях, применяемых для их защиты, персональные данные и информацию, прямо названную Заказчиком конфиденциальной. Передача указанной информации другим лицам может быть осуществлена только с письменного согласия Заказчика. За разглашение сведений, составляющих служебную, коммерческую и иную тайну, а также представляющих собой персональные данные, и нанесенный в результате этого ущерб Поставщик несет ответственность в соответствии с действующим законодательством Российской Федерации Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки - Класс программ для электронных вычислительных машин и баз данных - (02.09) Операционные системы общего назначения - - Значение характеристики не может изменяться участником закупки - Способ предоставления - Экземпляр на материальном носителе - - Значение характеристики не может изменяться участником закупки - Общие требования - 1. Программное обеспечение должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных Минкомсвязи РФ по классам «Операционные системы общего назначения», «Средства виртуализации», «Серверное и связующее программное обеспечение», «Средства управления базами данных», «Системы контейнеризации и контейнеры», «Средства защиты от несанкционированного доступа к информации». 2. Операционная система должна соответствовать требованиям документов: a. «Требования безопасности информации к операционным системам» (утвержденным приказом ФСТЭК России от 19 августа 2016 года N 119) и «Профиль защиты операционных систем типа «А» четвертого класса защиты ИТ.ОС.А4.ПЗ» (утв. ФСТЭК России 08.02.2017). b. «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» не ниже четвертого уровня доверия (приказ ФСТЭК России № 76 от 2 июня 2020 г.). c. «Требования по безопасности информации к средствам контейнеризации» (утв. приказом ФСТЭК России от 04.07.2022 N 118) не ниже 4 класса защиты. d. «Требования по безопасности информации к средствам виртуализации» (утв. приказом ФСТЭК России от 27.10.2022 N 187) не ниже 4 класса защиты. e. «Требования по безопасности информации к системам управления базами данных» (утв. приказом ФСТЭК России от 14.04.2023 N 64) не ниже 4 класса защиты. 3. В Формуляре ОС должны быть указаны интерпретаторы, веб сервера и сервера приложений, проверенные согласно документу: «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении», утверждена ФСТЭК России 25.12.2020 г. 4. Разработчик должен иметь собственную инфраструктуру разработки полного цикла, зарегистрированную и находящуюся на территории РФ, в исключительной юрисдикции РФ. 5. Наличие локализованной сервисной и/или технической поддержки - - Значение характеристики не может изменяться участником закупки - Функциональные требования (1-5) - 1. Операционная система должна устанавливаться и функционировать на компьютерах с архитектурами x86_64 (64-разрядный процессор Intel или AMD), aarch64 («Байкал», Rockchip 3588) и «Эльбрус» (процессоры 8С, 1С+, 8СВ, 2С3, 12С, 16С) должны быть отдельные образы в сертифицированном исполнении для каждой архитектуры. Требования, перечисленные в данном документе, относятся к архитектуре x86_64 и могут отличаться от требований к другим архитектурам. 2. Операционная система должна поддерживать режимы установки и загрузки Legacy/CSM, UEFI (с включенным механизмом SecureBoot), а также средствами BMC/IPMI (если поддерживается оборудованием). 3. Операционная система должна иметь в составе ядро не ниже 6.12 (LTS) для обеспечения корректного функционирования современных средств вычислительной техники. Система должна предоставлять графические утилиты для установки, удаления и обновления ядра, включая модули, а также для выбора ядра по умолчанию. 4. Операционная система должна обеспечивать поддержку нескольких видеокарт (работа на нескольких мониторах). 5. Операционная система должна обладать русифицированным интерфейсом, а также предоставлять русскоязычную документацию - - Значение характеристики не может изменяться участником закупки - Функциональные требования (6-10) - 6. Операционная система должна иметь возможность установки с DVD-диска и USB-накопителя. Операционная система должна предоставлять варианты сетевой установки: PXE/TFTP (для режима Legacy/CSM-загрузки), HTTPClient (для спецификации UEFI 2.5 и выше), iPXE. 7. Операционная система должна предоставлять возможность организации сервера сетевой загрузки. 8. Операционная система должна предоставлять возможность установки на оборудование без графической подсистемы с локального накопителя, а также установки с использованием сервера сетевой установки по протоколу VNC. 9. Носитель с дистрибутивом ОС должен предусматривать вариант загрузки для проведения работ по восстановлению системы, включая проверку сохранности содержимого файловой системы и проверку контрольных сумм неизменяемых файлов установленных пакетов, диагностику конфигурации аппаратного обеспечения, изменение таблицы и размеров разделов, изменение параметров файловых систем, восстановление удаленных разделов и файлов, проведение резервного копирования, очистку остаточной информации на разделах и дисках. 10. Операционная система должна иметь возможность установки на программный RAID-массив, размещения разделов в томах LVM и использования маскирования (кодирования) разделов с парольным доступом - - Значение характеристики не может изменяться участником закупки - Функциональные требования (11-15) - 11. Операционная система должна обеспечивать возможность создания точек восстановления (снапшотов) для последующего возвращения системы к исходному состоянию в случае сбоя. 12. Инсталлятор дистрибутива должен предусматривать возможность предварительной (OEM) установки, позволяющей при первом запуске пользователем после установки выбрать язык, принять лицензионное соглашение, настроить дату/время, настроить сеть, задать пароль root, создать системного пользователя. 13. Операционная система должна предоставлять независимый выбор основных и дополнительных приложений в момент установки: серверные приложения (dhcp, dns,ftp, http, почтовый сервер, сервер резервного копирования, сервер печати, сервер сетевой установки), сканер обнаружения уязвимостей, сервер сертифицированной СУБД, сервер управления конфигурациями, сервер виртуальных рабочих столов, средства управления контейнеризацией, средства управления виртуализацией. 14. Операционная система после установки должна предоставлять пользователю рабочую среду, включающую системное ПО, сетевые службы и сервисы, драйвера устройств, утилиты администрирования, базовый набор приложений. 15. Если установлена графическая среда, операционная система должна предоставлять графическое средство настройки многопользовательского режима, позволяющего обеспечить одновременную работу нескольких пользователей на одном компьютере при наличии отдельной видеокарты, клавиатуры и мыши для каждого пользователя - - Значение характеристики не может изменяться участником закупки - Функциональные требования (16-20) - 16. Операционная система должна предоставлять инструмент для поиска уязвимостей в файлах конфигурации, файловых системах, используемых пакетах ОС (включая программные зависимости), образах контейнеров и git-репозиториях. Анализ уязвимостей должен осуществляться как по вендорской базе уязвимостей (CVE), собранной из разных источников, так и по базе уязвимостей (BDU) ФСТЭК России. 17. Операционная система должна предоставлять возможность установки пароля на загрузчик для ограничения доступа к опциям загрузки. 18. Операционная система должна предоставлять возможность блокировки виртуальных текстовых консолей. 19. Комплекс средств защиты ОС должен обеспечивать выполнение программ в защищенной среде. В состав ОС должны быть включены программные интерпретаторы (php, perl, lua, python, nodejs) и веб-сервер (nginx), прошедшие испытания по выявлению уязвимостей и недекларированных возможностей в полном объеме в соответствии с Методикой выявления уязвимостей и недекларированных возможностей в программном обеспечении, утвержденной ФСТЭК России 25.12.2020 г. 20. Операционная система должна включать приложение для мониторинга ресурсов. Должно быть обеспечено централизованное управление конфигурациями прав доступа к утилите мониторинга температуры жесткого диска - - Значение характеристики не может изменяться участником закупки - Функциональные требования (21-25) - 21. Операционная система должна предоставлять единый графический модульный интерфейс для администрирования и настроек, а также предоставлять возможность удаленного администрирования по защищенным протоколам с помощью графических утилит (включая конфигурирование установленной системы через веб). Администратор должен иметь возможность назначить права доступа для пользователей к определенным модулям. В состав базовых сервисов должны входить: • настройка даты и времени; • управление системными службами; • просмотр системных журналов; • конфигурирование сетевых подключений и межсетевого экрана; • установка обновлений, в том числе для компьютеров без доступа в интернет; • управление выключением удаленного компьютера; • управление пользователями; • настройка пользовательских квот на использование ресурсов памяти, диска и внешних носителей. 22. Операционная система должна реализовывать возможность хранения аутентификационной информации пользователей, полученной с использованием хеш-функций по ГОСТ Р 34.11-2012. Реализация функционала должна быть обеспечена как консольными, так и графическими утилитами. 23. Операционная система должна обеспечивать возможность создания ssh-туннелей, использующих контроль целостности заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015. 24. Операционная система должна предоставлять возможность авторизации по смарт-картам в консольном режиме. 25. Операционная система должна предоставлять протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе - - Значение характеристики не может изменяться участником закупки - Функциональные требования (26-28) - 26. Операционная система должна предоставлять возможность разграничения доступа к подключаемым устройствам. 27. Операционная система должна иметь возможность организации домена Samba-DC или интеграции с доменом Active Directory с поддержкой следующего функционала: • действовать в качестве первичного или вторичного контроллера домена; • аутентификация рабочих станций; • авторизация и предоставление ресурсов без дополнительного ввода пароля (Single Sign-On); • поддержка ролей и привилегий (назначение ролей группам); • групповые политики (GPO). 28. Операционная система должна предоставлять возможность организации трастовых доменов - - Значение характеристики не может изменяться участником закупки - Функциональные требования (29) - 29. При работе в гетерогенной среде домена 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. • Возможность принудительного выполнения политики на клиенте - - Значение характеристики не может изменяться участником закупки - Функциональные требования (30) - 30. Операционная система должна предоставлять возможность организации и настройки базовых сетевых сервисов и служб: • sshd; • DNS; • DHCP; • протокол аутентификации LDAP; • OpenVPN; • SMTP, POP3/IMAP (postfix, dovecot или эквивалент); • межсетевой экран; • проксирование HTTP- и FTP-запросов (squid или эквивалент); • резервное копирование (bacula или эквивалент); • сервер сетевой установки с веб-интерфейсом; • сервер обновлений с возможностью зеркалирования репозитория вендора ОС и создания служебных репозиториев используемого Заказчиком ПО; • защищенный сервер баз данных (PostgreSQL или эквивалент) с возможностью организации кластера из нескольких серверов, со встроенной реализацией функций round, trunc, date совместимой с Oracle DB; • веб-сервер; • FTP-сервер; • сервер мониторинга сетевых ресурсов с графическим интерфейсом (Zabbix, icinga2 или эквивалент); • сервер печати; • сервер групповой работы с веб-интерфейсом (SOGo или эквивалент); • сервер файлового обмена - - Значение характеристики не может изменяться участником закупки - Функциональные требования (31.a-h) - 31. Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: a. Программное обеспечение (ПО) должно создавать и управлять резервными копиями виртуальных машин (ВМ), контейнеров и физических узлов, содержащие архивы файлов и образов. b. ПО должно предоставлять интегрированный клиент для QEMU и LXC в виртуальной среде Proxmox. c. ПО должно поддерживать резервное копирование на магнитную ленту и управление ленточными библиотеками. d. ПО должно поддерживать дедупликацию, сжатие и аутентифицированое шифрование данных. e. ПО должно использовать следующие алгоритмы сжатия данных lzo, gzip и zstd. f. ПО должно содержать в себе веб-интерфейс (RESTful API) управления со встроенной в него консолью, доступ должен осуществляться через системную аутентификацию Linux PAM. g. ПО должно хранить данные резервных копий и предоставлять RESTful API для создания хранилищ данных и управления ими и другими ресурсами на стороне сервера. h. ПО должно позволять с помощью API, предоставленного серверной частью, позволять клиенту резервного копирования получать доступ к сохранённым данным для создания и восстановления резервных копий файлов, а также для управления дисками и другими ресурсами на стороне сервера - - Значение характеристики не может изменяться участником закупки - Функциональные требования (31.i-o) - i. ПО должно использовать протокол TLS для обеспечения безопасности обмена данными между клиентской и серверной частями. j. ПО должно использовать алгоритм AES-256 GCM при шифровании содержимого резервной копии на стороне клиента. k. ПО должно позволять создавать хранилища данных с файловой системой форматов ext4, xfs. l. ПО должно содержать в себе набор инструментов, используемых для мониторинга и управления системой S.M.A.R.T. для локальных жёстких дисков, с возможностью отображения атрибутов S.M.A.R.T. из веб-интерфейса или при помощи командной строки. m. ПО должно идентифицировать каждое хранилище данных именем и указанием на каталог в файловой системе и связывать с каждым хранилищем параметры хранения, определяющие количество снимков резервных копий для каждого интервала времени: час, день, неделя, месяц, год. n. ПО должно позволять создавать хранилища данных с возможностью выбора и настройки следующих параметров: название; путь к каталогу; количество резервных копий для хранения в этом хранилище; расписания периодического запуска удаления резервных копий и сборки мусора (удаления неиспользуемых блоков данных). o. ПО должно позволять ограничить входящий (например, резервное копирование) и исходящий (например, восстановление) сетевой трафик из набора сетей, с возможностью настроить определенные периоды, в которые будут применяться ограничения - - Значение характеристики не может изменяться участником закупки - Функциональные требования (31.p-t) - p. ПО должно позволять создавать пользователей и управлять ими как из встроенного веб-интерфейса, так и с помощью командной строки, с возможностью создания/удаления/отключения учетных записей, просмотра списка пользователей с возможностью изменения любых свойств. q. ПО должно позволять любому аутентифицированному пользователю генерировать API-токены и использовать их для настройки клиентов резервного копирования вместо прямого указания имени пользователя и пароля. API-токен должен отзываться в случае компрометации клиента и ограничивать разрешения для каждого клиента/токена в рамках разрешения пользователей. ПО должно создавать для токенов собственные записи ACL, где токены не могут делать больше, чем создавший их пользователь. r. ПО должно использовать систему управления разрешениями на основе ролей и путей, где роль содержит набор разрешенных действий, а путь представляет цель этих действий. По умолчанию разрешения созданным пользователям и API-токенам не должны предоставляться. s. ПО должно предопределять следующий ряд ролей: нет привилегий (используется для запрета доступа); все привилегии; доступ только для чтения; все привилегии для хранилищ данных; просмотр настроек хранилищ и их содержимых, без возможности чтения фактических данных; просмотр содержимого хранилища, восстановление данных; создание и восстановление собственных резервных копий; создание, восстановление и удаление собственных резервных копий; все привилегии для удалённых серверов; просмотр настроек удалённых серверов; чтение данных с удалённых серверов. t. ПО должно создавать, хранить и предоставлять следующую информацию о правах доступа: идентификатор ACL; включено или отключено; объект, на который установлено разрешение; пользователи/токены, для которых установлено разрешение; устанавливаемая роль - - Значение характеристики не может изменяться участником закупки - Функциональные требования (31.u-36) - u. ПО должно реализовывать возможность использования двухфакторной аутентификации с помощью веб-интерфейса тремя методами: TOTP (одноразовый пароль на основе времени) — для создания этого кода должен использоваться алгоритм одноразового пароля с учетом времени входа в систему (код меняется каждые 30 секунд); WebAuthn (веб-аутентификация) — реализуется с помощью различных устройств безопасности, таких как аппаратные ключи или доверенные платформенные модули (TPM). Для работы веб-аутентификации необходим сертификат HTTPS; Recovery Keys (одноразовые ключи восстановления) — список ключей, каждый из которых можно использовать только один раз. В каждый момент времени у пользователя может быть только один набор одноразовых ключей. 32. Операционная система должна предоставлять возможность установления безопасных сетевых соединений по технологии VPN. 33. Операционная система должна обеспечивать возможность создания VPN-туннелей, использующих контроль заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015. 34. Операционная система должна реализовывать базовый функционал межсетевого экрана. 35. Операционная система должна предоставлять возможность установки многоплатформенного брокера подключений для создания и управления виртуальными рабочими местами и приложениями (OpenUDS или аналог). 36. Операционная система должна включать графическое приложение для мониторинга ресурсов и просмотра системных журналов - - Значение характеристики не может изменяться участником закупки - Функциональные требования (37-43) - 37. Операционная система должна предоставлять возможность одновременной работы пользователей в изолированных сеансах. Должны быть предусмотрены: • отдельное изолированное хранение данных аутентификации каждого пользователя системы таким образом, чтобы процессы аутентификации локального или сетевого пользователя не могли получить доступа к данным аутентификации и авторизации других пользователей системы; • поддержка изоляции временных пользовательских файлов. 38. Операционная система должна включать автоматизированные средства изоляции приложений, чувствительных к сетевым атакам. 39. Операционная система должна предоставлять упреждающие меры защиты и быть сконфигурирована с безопасными настройками по умолчанию. 40. Операционная система должна предоставлять механизм управления фиксированными состояниями ключевых объектов безопасности системы, сохраняющий установленные права доступа к объектам файловой системы при обновлении пакетов. 41. Операционная система должна обеспечивать поддержку шифрования по ГОСТ Р 34.11-2012 в OpenSSL, включая генерацию ключей и создание сертификатов. 42. Операционная система должна предоставлять инструмент проверки контрольных сумм неизменяемых файлов установленных пакетов как при начальной установке, так и после получения обновлений. Вендор должен обеспечивать доступ к обновлениям и контрольным суммам неизменяемых файлов пакетов в них. 43. Подсистема контроля целостности операционной системы должна поддерживать технологии IMA и EVM - - Значение характеристики не может изменяться участником закупки - Функциональные требования (44-52) - 44. Операционная система должна предоставлять возможность запрета запуска выбранных интерпретаторов в интерактивном режиме, отключения возможности удаления открытых файлов, а также установки запрета бита исполнения (SUID), распространяемого на дочерние процессы. 45. Операционная система должна поддерживать файловые системы ext2, ext3, ext4, btrfs для чтения/записи и установки, iso9660, xfs, fat16, fat32, ntfs. 46. Операционная система должна поддерживать сетевые протоколы SMB, NFS, FTP, NTP, HTTP(S). 47. Операционная система должна предоставлять возможность доустановки необходимого программного обеспечения с диска или из репозитория, а также установки обновлений. Система должна обеспечить автоматическую проверку зависимостей (apt или эквивалент), а также возможность комплексного обновления системы с отдельным процессом установки ядра ядра с помощью графических утилит. 48. Исходные коды, обновления, инструменты для сборки серверной ОС должны находиться в том же репозитории (хранилище), где хранятся исходные коды, обновления и инструменты для ОС рабочих станций. 49. Операционная система должна предоставлять единую систему для установки прикладного программного обеспечения в системе (eepm или аналог). Также должна быть обеспечена возможность установки сторонних приложений в форматах deb, tgz, tbz, tbz2, pkg.gz. 50. Операционная система должна поддерживать корневые сертификаты Минцифры России. В составе дистрибутива должен присутствовать пакет с отечественными корневыми сертификатами шифрования. 51. Операционная система должна поддерживать корневые сертификаты Российского центра сертификации ТЦИ, предоставляемые соответствующим пакетом из состава ОС. 52. Совместимость со сторонним программным обеспечением. Подсистема настольных приложений должна быть совместима с СЭД на базе программного обеспечения «ДЕЛО» (Правообладатель ООО «Электронные офисные системы», Свидетельство о гос.регистрации программы для ЭВМ № 2006614189 от 06.12.2006 г.) - - Значение характеристики не может изменяться участником закупки - Нефункциональные требования - 1. Разработчик обязан оказывать гарантийную вендорскую поддержку продукта (оперативный выпуск обновлений по безопасности). 2. Разработчик обязан оказывать техническую поддержку пользователям на условиях SLA в течение первого года использования. Для критических инцидентов должно быть обеспечено время реакции не более 8 часов в период с 9:00 до 19:00 в рабочие дни. 3. Система должна быть основана на программном обеспечении с открытым исходным кодом - - Значение характеристики не может изменяться участником закупки - Условия передачи неисключительного права - При передаче неисключительных прав (прав использования) на ПО необходимо не разглашать и не использовать во вред Заказчику полученные в рамках передачи неисключительного права (права использования) на передаваемое ПО сведения о Заказчике, о степени защищенности объектов информатизации, мероприятиях, применяемых для их защиты, персональные данные и информацию, прямо названную Заказчиком конфиденциальной. Передача указанной информации другим лицам может быть осуществлена только с письменного согласия Заказчика. За разглашение сведений, составляющих служебную, коммерческую и иную тайну, а также представляющих собой персональные данные, и нанесенный в результате этого ущерб Поставщик несет ответственность в соответствии с действующим законодательством Российской Федерации - - Значение характеристики не может изменяться участником закупки

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

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

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

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

Общие требования - 1. Программное обеспечение должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных Минкомсвязи РФ по классам «Операционные системы общего назначения», «Средства виртуализации», «Серверное и связующее программное обеспечение», «Средства управления базами данных», «Системы контейнеризации и контейнеры», «Средства защиты от несанкционированного доступа к информации». 2. Операционная система должна соответствовать требованиям документов: a. «Требования безопасности информации к операционным системам» (утвержденным приказом ФСТЭК России от 19 августа 2016 года N 119) и «Профиль защиты операционных систем типа «А» четвертого класса защиты ИТ.ОС.А4.ПЗ» (утв. ФСТЭК России 08.02.2017). b. «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» не ниже четвертого уровня доверия (приказ ФСТЭК России № 76 от 2 июня 2020 г.). c. «Требования по безопасности информации к средствам контейнеризации» (утв. приказом ФСТЭК России от 04.07.2022 N 118) не ниже 4 класса защиты. d. «Требования по безопасности информации к средствам виртуализации» (утв. приказом ФСТЭК России от 27.10.2022 N 187) не ниже 4 класса защиты. e. «Требования по безопасности информации к системам управления базами данных» (утв. приказом ФСТЭК России от 14.04.2023 N 64) не ниже 4 класса защиты. 3. В Формуляре ОС должны быть указаны интерпретаторы, веб сервера и сервера приложений, проверенные согласно документу: «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении», утверждена ФСТЭК России 25.12.2020 г. 4. Разработчик должен иметь собственную инфраструктуру разработки полного цикла, зарегистрированную и находящуюся на территории РФ, в исключительной юрисдикции РФ. 5. Наличие локализованной сервисной и/или технической поддержки - - Значение характеристики не может изменяться участником закупки

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

Функциональные требования (6-10) - 6. Операционная система должна иметь возможность установки с DVD-диска и USB-накопителя. Операционная система должна предоставлять варианты сетевой установки: PXE/TFTP (для режима Legacy/CSM-загрузки), HTTPClient (для спецификации UEFI 2.5 и выше), iPXE. 7. Операционная система должна предоставлять возможность организации сервера сетевой загрузки. 8. Операционная система должна предоставлять возможность установки на оборудование без графической подсистемы с локального накопителя, а также установки с использованием сервера сетевой установки по протоколу VNC. 9. Носитель с дистрибутивом ОС должен предусматривать вариант загрузки для проведения работ по восстановлению системы, включая проверку сохранности содержимого файловой системы и проверку контрольных сумм неизменяемых файлов установленных пакетов, диагностику конфигурации аппаратного обеспечения, изменение таблицы и размеров разделов, изменение параметров файловых систем, восстановление удаленных разделов и файлов, проведение резервного копирования, очистку остаточной информации на разделах и дисках. 10. Операционная система должна иметь возможность установки на программный RAID-массив, размещения разделов в томах LVM и использования маскирования (кодирования) разделов с парольным доступом - - Значение характеристики не может изменяться участником закупки

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

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

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

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

Функциональные требования (29) - 29. При работе в гетерогенной среде домена 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. • Возможность принудительного выполнения политики на клиенте - - Значение характеристики не может изменяться участником закупки

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

Функциональные требования (31.a-h) - 31. Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: a. Программное обеспечение (ПО) должно создавать и управлять резервными копиями виртуальных машин (ВМ), контейнеров и физических узлов, содержащие архивы файлов и образов. b. ПО должно предоставлять интегрированный клиент для QEMU и LXC в виртуальной среде Proxmox. c. ПО должно поддерживать резервное копирование на магнитную ленту и управление ленточными библиотеками. d. ПО должно поддерживать дедупликацию, сжатие и аутентифицированое шифрование данных. e. ПО должно использовать следующие алгоритмы сжатия данных lzo, gzip и zstd. f. ПО должно содержать в себе веб-интерфейс (RESTful API) управления со встроенной в него консолью, доступ должен осуществляться через системную аутентификацию Linux PAM. g. ПО должно хранить данные резервных копий и предоставлять RESTful API для создания хранилищ данных и управления ими и другими ресурсами на стороне сервера. h. ПО должно позволять с помощью API, предоставленного серверной частью, позволять клиенту резервного копирования получать доступ к сохранённым данным для создания и восстановления резервных копий файлов, а также для управления дисками и другими ресурсами на стороне сервера - - Значение характеристики не может изменяться участником закупки

Функциональные требования (31.i-o) - i. ПО должно использовать протокол TLS для обеспечения безопасности обмена данными между клиентской и серверной частями. j. ПО должно использовать алгоритм AES-256 GCM при шифровании содержимого резервной копии на стороне клиента. k. ПО должно позволять создавать хранилища данных с файловой системой форматов ext4, xfs. l. ПО должно содержать в себе набор инструментов, используемых для мониторинга и управления системой S.M.A.R.T. для локальных жёстких дисков, с возможностью отображения атрибутов S.M.A.R.T. из веб-интерфейса или при помощи командной строки. m. ПО должно идентифицировать каждое хранилище данных именем и указанием на каталог в файловой системе и связывать с каждым хранилищем параметры хранения, определяющие количество снимков резервных копий для каждого интервала времени: час, день, неделя, месяц, год. n. ПО должно позволять создавать хранилища данных с возможностью выбора и настройки следующих параметров: название; путь к каталогу; количество резервных копий для хранения в этом хранилище; расписания периодического запуска удаления резервных копий и сборки мусора (удаления неиспользуемых блоков данных). o. ПО должно позволять ограничить входящий (например, резервное копирование) и исходящий (например, восстановление) сетевой трафик из набора сетей, с возможностью настроить определенные периоды, в которые будут применяться ограничения - - Значение характеристики не может изменяться участником закупки

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

Функциональные требования (31.u-36) - u. ПО должно реализовывать возможность использования двухфакторной аутентификации с помощью веб-интерфейса тремя методами: TOTP (одноразовый пароль на основе времени) — для создания этого кода должен использоваться алгоритм одноразового пароля с учетом времени входа в систему (код меняется каждые 30 секунд); WebAuthn (веб-аутентификация) — реализуется с помощью различных устройств безопасности, таких как аппаратные ключи или доверенные платформенные модули (TPM). Для работы веб-аутентификации необходим сертификат HTTPS; Recovery Keys (одноразовые ключи восстановления) — список ключей, каждый из которых можно использовать только один раз. В каждый момент времени у пользователя может быть только один набор одноразовых ключей. 32. Операционная система должна предоставлять возможность установления безопасных сетевых соединений по технологии VPN. 33. Операционная система должна обеспечивать возможность создания VPN-туннелей, использующих контроль заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015. 34. Операционная система должна реализовывать базовый функционал межсетевого экрана. 35. Операционная система должна предоставлять возможность установки многоплатформенного брокера подключений для создания и управления виртуальными рабочими местами и приложениями (OpenUDS или аналог). 36. Операционная система должна включать графическое приложение для мониторинга ресурсов и просмотра системных журналов - - Значение характеристики не может изменяться участником закупки

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

Функциональные требования (44-52) - 44. Операционная система должна предоставлять возможность запрета запуска выбранных интерпретаторов в интерактивном режиме, отключения возможности удаления открытых файлов, а также установки запрета бита исполнения (SUID), распространяемого на дочерние процессы. 45. Операционная система должна поддерживать файловые системы ext2, ext3, ext4, btrfs для чтения/записи и установки, iso9660, xfs, fat16, fat32, ntfs. 46. Операционная система должна поддерживать сетевые протоколы SMB, NFS, FTP, NTP, HTTP(S). 47. Операционная система должна предоставлять возможность доустановки необходимого программного обеспечения с диска или из репозитория, а также установки обновлений. Система должна обеспечить автоматическую проверку зависимостей (apt или эквивалент), а также возможность комплексного обновления системы с отдельным процессом установки ядра ядра с помощью графических утилит. 48. Исходные коды, обновления, инструменты для сборки серверной ОС должны находиться в том же репозитории (хранилище), где хранятся исходные коды, обновления и инструменты для ОС рабочих станций. 49. Операционная система должна предоставлять единую систему для установки прикладного программного обеспечения в системе (eepm или аналог). Также должна быть обеспечена возможность установки сторонних приложений в форматах deb, tgz, tbz, tbz2, pkg.gz. 50. Операционная система должна поддерживать корневые сертификаты Минцифры России. В составе дистрибутива должен присутствовать пакет с отечественными корневыми сертификатами шифрования. 51. Операционная система должна поддерживать корневые сертификаты Российского центра сертификации ТЦИ, предоставляемые соответствующим пакетом из состава ОС. 52. Совместимость со сторонним программным обеспечением. Подсистема настольных приложений должна быть совместима с СЭД на базе программного обеспечения «ДЕЛО» (Правообладатель ООО «Электронные офисные системы», Свидетельство о гос.регистрации программы для ЭВМ № 2006614189 от 06.12.2006 г.) - - Значение характеристики не может изменяться участником закупки

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

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

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Дополнительные характеристики установлены Заказчиком в связи с недостаточностью характеристик, приведенных в КТРУ для закупки программного обеспечения, требуемого Заказчику. Применение параметров, касающихся технических, функциональных (потребительских свойств) и качественных характеристик программного обеспечения, не учтенных КТРУ, обусловлено необходимостью поставки программного обеспечения надлежащего качества, с параметрами, в наибольшей степени удовлетворяющими потребности Заказчика для перехода на новую систему электронного документооборота.

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

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Вид лицензии Простая (неисключительная) Значение характеристики не может изменяться участником закупки Класс программ для электронных вычислительных машин и баз данных (02.09) Операционные системы общего назначения Значение характеристики не может изменяться участником закупки Способ предоставления Копия электронного экземпляра Значение характеристики не может изменяться участником закупки Общие требования 1. Программное обеспечение должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных Минкомсвязи РФ по классам «Операционные системы общего назначения», «Средства виртуализации», «Серверное и связующее программное обеспечение», «Средства управления базами данных», «Системы контейнеризации и контейнеры», «Средства защиты от несанкционированного доступа к информации». 2. Операционная система должна соответствовать требованиям документов: a. «Требования безопасности информации к операционным системам» (приказом ФСТЭК России от 19 августа 2016 года N 119) и «Профиль защиты операционных систем типа «А» четвертого класса защиты ИТ.ОС.А4.ПЗ» (утв. ФСТЭК России 08.02.2017). b. «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» не ниже четвертого уровня доверия (приказ ФСТЭК России № 76 от 2 июня 2020 г.). c. «Требования по безопасности информации к средствам контейнеризации» (утв. приказом ФСТЭК России от 04.07.2022 N 118) не ниже 4 класса защиты. d. «Требования по безопасности информации к средствам виртуализации» (утв. приказом ФСТЭК России от 27.10.2022 N 187) не ниже 4 класса защиты. e. «Требования по безопасности информации к системам управления базами данных» (утв. приказом ФСТЭК России от 14.04.2023 N 64) не ниже 4 класса защиты. 3. В Формуляре ОС должны быть указаны интерпретаторы, веб сервера и сервера приложений, проверенные согласно документу: «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении», утверждена ФСТЭК России 25.12.2020 г. 4. Разработчик должен иметь собственную инфраструктуру разработки полного цикла, зарегистрированную и находящуюся на территории РФ, в исключительной юрисдикции РФ. 5. Наличие локализованной сервисной и/или технической поддержки Значение характеристики не может изменяться участником закупки Функциональные требования (1-5) 1. Операционная система должна устанавливаться и функционировать на компьютерах с архитектурами x86_64 (64-разрядный процессор Intel или AMD), aarch64 («Байкал», Rockchip 3588) и «Эльбрус» (процессоры 8С, 1С+, 8СВ, 2С3, 12С, 16С) должны быть отдельные образы в сертифицированном исполнении для каждой архитектуры. Требования, перечисленные в данном документе, относятся к архитектуре x86_64 и могут отличаться от требований к другим архитектурам. 2. Операционная система должна поддерживать режимы установки и загрузки Legacy/CSM, UEFI (с включенным механизмом SecureBoot), а также средствами BMC/IPMI (если поддерживается оборудованием). 3. Операционная система должна иметь в составе ядро не ниже 6.12 (LTS) для обеспечения корректного функционирования современных средств вычислительной техники. Система должна предоставлять графические утилиты для установки, удаления и обновления ядра, включая модули, а также для выбора ядра по умолчанию. 4. Операционная система должна обеспечивать поддержку нескольких видеокарт (работа на нескольких мониторах). 5. Операционная система должна обладать русифицированным интерфейсом, а также предоставлять русскоязычную документацию Значение характеристики не может изменяться участником закупки Функциональные требования (6-10) 6. Операционная система должна иметь возможность установки с DVD-диска и USB-накопителя. Операционная система должна предоставлять варианты сетевой установки: PXE/TFTP (для режима Legacy/CSM-загрузки), HTTPClient (для спецификации UEFI 2.5 и выше), iPXE. 7. Операционная система должна предоставлять возможность организации сервера сетевой загрузки. 8. Операционная система должна предоставлять возможность установки на оборудование без графической подсистемы с локального накопителя, а также установки с использованием сервера сетевой установки по протоколу VNC. 9. Носитель с дистрибутивом ОС должен предусматривать вариант загрузки для проведения работ по восстановлению системы, включая проверку сохранности содержимого файловой системы и проверку контрольных сумм неизменяемых файлов установленных пакетов, диагностику конфигурации аппаратного обеспечения, изменение таблицы и размеров разделов, изменение параметров файловых систем, восстановление удаленных разделов и файлов, проведение резервного копирования, очистку остаточной информации на разделах и дисках. 10. Операционная система должна иметь возможность установки на программный RAID-массив, размещения разделов в томах LVM и использования маскирования (кодирования) разделов с парольным доступом Значение характеристики не может изменяться участником закупки Функциональные требования (11-15) 11. Операционная система должна обеспечивать возможность создания точек восстановления (снапшотов) для последующего возвращения системы к исходному состоянию в случае сбоя. 12. Инсталлятор дистрибутива должен предусматривать возможность предварительной (OEM) установки, позволяющей при первом запуске пользователем после установки выбрать язык, принять лицензионное соглашение, настроить дату/время, настроить сеть, задать пароль root, создать системного пользователя. 13. Операционная система должна предоставлять независимый выбор основных и дополнительных приложений в момент установки: серверные приложения (dhcp, dns,ftp, http, почтовый сервер, сервер резервного копирования, сервер печати, сервер сетевой установки), сканер обнаружения уязвимостей, сервер сертифицированной СУБД, сервер управления конфигурациями, сервер виртуальных рабочих столов, средства управления контейнеризацией, средства управления виртуализацией. 14. Операционная система после установки должна предоставлять пользователю рабочую среду, включающую системное ПО, сетевые службы и сервисы, драйвера устройств, утилиты администрирования, базовый набор приложений. 15. Если установлена графическая среда, операционная система должна предоставлять графическое средство настройки многопользовательского режима, позволяющего обеспечить одновременную работу нескольких пользователей на одном компьютере при наличии отдельной видеокарты, клавиатуры и мыши для каждого пользователя Значение характеристики не может изменяться участником закупки Функциональные требования (16-20) 16. Операционная система должна предоставлять инструмент для поиска уязвимостей в файлах конфигурации, файловых системах, используемых пакетах ОС (включая программные зависимости), образах контейнеров и git-репозиториях. Анализ уязвимостей должен осуществляться как по вендорской базе уязвимостей (CVE), собранной из разных источников, так и по базе уязвимостей (BDU) ФСТЭК России. 17. Операционная система должна предоставлять возможность установки пароля на загрузчик для ограничения доступа к опциям загрузки. 18. Операционная система должна предоставлять возможность блокировки виртуальных текстовых консолей. 19. Комплекс средств защиты ОС должен обеспечивать выполнение программ в защищенной среде. В состав ОС должны быть включены программные интерпретаторы (php, perl, lua, python, nodejs) и веб-сервер (nginx), прошедшие испытания по выявлению уязвимостей и недекларированных возможностей в полном объеме в соответствии с Методикой выявления уязвимостей и недекларированных возможностей в программном обеспечении, утвержденной ФСТЭК России 25.12.2020 г. 20. Операционная система должна включать приложение для мониторинга ресурсов. Должно быть обеспечено централизованное управление конфигурациями прав доступа к утилите мониторинга температуры жесткого диска Значение характеристики не может изменяться участником закупки Функциональные требования (21-25) 21. Операционная система должна предоставлять единый графический модульный интерфейс для администрирования и настроек, а также предоставлять возможность удаленного администрирования по защищенным протоколам с помощью графических утилит (включая конфигурирование установленной системы через веб). Администратор должен иметь возможность назначить права доступа для пользователей к определенным модулям. В состав базовых сервисов должны входить: • настройка даты и времени; • управление системными службами; • просмотр системных журналов; • конфигурирование сетевых подключений и межсетевого экрана; • установка обновлений, в том числе для компьютеров без доступа в интернет; • управление выключением удаленного компьютера; • управление пользователями; • настройка пользовательских квот на использование ресурсов памяти, диска и внешних носителей. 22. Операционная система должна реализовывать возможность хранения аутентификационной информации пользователей, полученной с использованием хеш-функций по ГОСТ Р 34.11-2012. Реализация функционала должна быть обеспечена как консольными, так и графическими утилитами. 23. Операционная система должна обеспечивать возможность создания ssh-туннелей, использующих контроль целостности заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015. 24. Операционная система должна предоставлять возможность авторизации по смарт-картам в консольном режиме. 25. Операционная система должна предоставлять протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе Значение характеристики не может изменяться участником закупки Функциональные требования (26-28) 26. Операционная система должна предоставлять возможность разграничения доступа к подключаемым устройствам. 27. Операционная система должна иметь возможность организации домена Samba-DC или интеграции с доменом Active Directory с поддержкой следующего функционала: • действовать в качестве первичного или вторичного контроллера домена; • аутентификация рабочих станций; • авторизация и предоставление ресурсов без дополнительного ввода пароля (Single Sign-On); • поддержка ролей и привилегий (назначение ролей группам); • групповые политики (GPO). 28. Операционная система должна предоставлять возможность организации трастовых доменов Значение характеристики не может изменяться участником закупки Функциональные требования (29) 29. При работе в гетерогенной среде домена 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. • Возможность принудительного выполнения политики на клиенте Значение характеристики не может изменяться участником закупки Функциональные требования (30) 30. Операционная система должна предоставлять возможность организации и настройки базовых сетевых сервисов и служб: • sshd; • DNS; • DHCP; • протокол аутентификации LDAP; • OpenVPN; • SMTP, POP3/IMAP (postfix, dovecot или эквивалент); • межсетевой экран; • проксирование HTTP- и FTP-запросов (squid или эквивалент); • резервное копирование (bacula или эквивалент); • сервер сетевой установки с веб-интерфейсом; • сервер обновлений с возможностью зеркалирования репозитория вендора ОС и создания служебных репозиториев используемого Заказчиком ПО; • защищенный сервер баз данных (PostgreSQL или эквивалент) с возможностью организации кластера из нескольких серверов, со встроенной реализацией функций round, trunc, date совместимой с Oracle DB; • веб-сервер; • FTP-сервер; • сервер мониторинга сетевых ресурсов с графическим интерфейсом (Zabbix, icinga2 или эквивалент); • сервер печати; • сервер групповой работы с веб-интерфейсом (SOGo или эквивалент); • сервер файлового обмена Значение характеристики не может изменяться участником закупки Функциональные требования (31.a-h) 31. Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: a. Программное обеспечение (ПО) должно создавать и управлять резервными копиями виртуальных машин (ВМ), контейнеров и физических узлов, содержащие архивы файлов и образов. b. ПО должно предоставлять интегрированный клиент для QEMU и LXC в виртуальной среде Proxmox. c. ПО должно поддерживать резервное копирование на магнитную ленту и управление ленточными библиотеками. d. ПО должно поддерживать дедупликацию, сжатие и аутентифицированое шифрование данных. e. ПО должно использовать следующие алгоритмы сжатия данных lzo, gzip и zstd. f. ПО должно содержать в себе веб-интерфейс (RESTful API) управления со встроенной в него консолью, доступ должен осуществляться через системную аутентификацию Linux PAM. g. ПО должно хранить данные резервных копий и предоставлять RESTful API для создания хранилищ данных и управления ими и другими ресурсами на стороне сервера. h. ПО должно позволять с помощью API, предоставленного серверной частью, позволять клиенту резервного копирования получать доступ к сохранённым данным для создания и восстановления резервных копий файлов, а также для управления дисками и другими ресурсами на стороне сервера Значение характеристики не может изменяться участником закупки Функциональные требования (31.i-o) i. ПО должно использовать протокол TLS для обеспечения безопасности обмена данными между клиентской и серверной частями. j. ПО должно использовать алгоритм AES-256 GCM при шифровании содержимого резервной копии на стороне клиента. k. ПО должно позволять создавать хранилища данных с файловой системой форматов ext4, xfs. l. ПО должно содержать в себе набор инструментов, используемых для мониторинга и управления системой S.M.A.R.T. для локальных жёстких дисков, с возможностью отображения атрибутов S.M.A.R.T. из веб-интерфейса или при помощи командной строки. m. ПО должно идентифицировать каждое хранилище данных именем и указанием на каталог в файловой системе и связывать с каждым хранилищем параметры хранения, определяющие количество снимков резервных копий для каждого интервала времени: час, день, неделя, месяц, год. n. ПО должно позволять создавать хранилища данных с возможностью выбора и настройки следующих параметров: название; путь к каталогу; количество резервных копий для хранения в этом хранилище; расписания периодического запуска удаления резервных копий и сборки мусора (удаления неиспользуемых блоков данных). o. ПО должно позволять ограничить входящий (например, резервное копирование) и исходящий (например, восстановление) сетевой трафик из набора сетей, с возможностью настроить определенные периоды, в которые будут применяться ограничения Значение характеристики не может изменяться участником закупки Функциональные требования (31.p-t) p. ПО должно позволять создавать пользователей и управлять ими как из встроенного веб-интерфейса, так и с помощью командной строки, с возможностью создания/удаления/отключения учетных записей, просмотра списка пользователей с возможностью изменения любых свойств. q. ПО должно позволять любому аутентифицированному пользователю генерировать API-токены и использовать их для настройки клиентов резервного копирования вместо прямого указания имени пользователя и пароля. API-токен должен отзываться в случае компрометации клиента и ограничивать разрешения для каждого клиента/токена в рамках разрешения пользователей. ПО должно создавать для токенов собственные записи ACL, где токены не могут делать больше, чем создавший их пользователь. r. ПО должно использовать систему управления разрешениями на основе ролей и путей, где роль содержит набор разрешенных действий, а путь представляет цель этих действий. По умолчанию разрешения созданным пользователям и API-токенам не должны предоставляться. s. ПО должно предопределять следующий ряд ролей: нет привилегий (используется для запрета доступа); все привилегии; доступ только для чтения; все привилегии для хранилищ данных; просмотр настроек хранилищ и их содержимых, без возможности чтения фактических данных; просмотр содержимого хранилища, восстановление данных; создание и восстановление собственных резервных копий; создание, восстановление и удаление собственных резервных копий; все привилегии для удалённых серверов; просмотр настроек удалённых серверов; чтение данных с удалённых серверов. t. ПО должно создавать, хранить и предоставлять следующую информацию о правах доступа: идентификатор ACL; включено или отключено; объект, на который установлено разрешение; пользователи/токены, для которых установлено разрешение; устанавливаемая роль Значение характеристики не может изменяться участником закупки Функциональные требования (31.u-36) u. ПО должно реализовывать возможность использования двухфакторной аутентификации с помощью веб-интерфейса тремя методами: TOTP (одноразовый пароль на основе времени) — для создания этого кода должен использоваться алгоритм одноразового пароля с учетом времени входа в систему (код меняется каждые 30 секунд); WebAuthn (веб-аутентификация) — реализуется с помощью различных устройств безопасности, таких как аппаратные ключи или доверенные платформенные модули (TPM). Для работы веб-аутентификации необходим сертификат HTTPS; Recovery Keys (одноразовые ключи восстановления) — список ключей, каждый из которых можно использовать только один раз. В каждый момент времени у пользователя может быть только один набор одноразовых ключей. 32. Операционная система должна предоставлять возможность установления безопасных сетевых соединений по технологии VPN. 33. Операционная система должна обеспечивать возможность создания VPN-туннелей, использующих контроль заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015. 34. Операционная система должна реализовывать базовый функционал межсетевого экрана. 35. Операционная система должна предоставлять возможность установки многоплатформенного брокера подключений для создания и управления виртуальными рабочими местами и приложениями (OpenUDS или аналог). 36. Операционная система должна включать графическое приложение для мониторинга ресурсов и просмотра системных журналов Значение характеристики не может изменяться участником закупки Функциональные требования (37-43) 37. Операционная система должна предоставлять возможность одновременной работы пользователей в изолированных сеансах. Должны быть предусмотрены: • отдельное изолированное хранение данных аутентификации каждого пользователя системы таким образом, чтобы процессы аутентификации локального или сетевого пользователя не могли получить доступа к данным аутентификации и авторизации других пользователей системы; • поддержка изоляции временных пользовательских файлов. 38. Операционная система должна включать автоматизированные средства изоляции приложений, чувствительных к сетевым атакам. 39. Операционная система должна предоставлять упреждающие меры защиты и быть сконфигурирована с безопасными настройками по умолчанию. 40. Операционная система должна предоставлять механизм управления фиксированными состояниями ключевых объектов безопасности системы, сохраняющий установленные права доступа к объектам файловой системы при обновлении пакетов. 41. Операционная система должна обеспечивать поддержку шифрования по ГОСТ Р 34.11-2012 в OpenSSL, включая генерацию ключей и создание сертификатов. 42. Операционная система должна предоставлять инструмент проверки контрольных сумм неизменяемых файлов установленных пакетов как при начальной установке, так и после получения обновлений. Вендор должен обеспечивать доступ к обновлениям и контрольным суммам неизменяемых файлов пакетов в них. 43. Подсистема контроля целостности операционной системы должна поддерживать технологии IMA и EVM Значение характеристики не может изменяться участником закупки Функциональные требования (44-52) 44. Операционная система должна предоставлять возможность запрета запуска выбранных интерпретаторов в интерактивном режиме, отключения возможности удаления открытых файлов, а также установки запрета бита исполнения (SUID), распространяемого на дочерние процессы. 45. Операционная система должна поддерживать файловые системы ext2, ext3, ext4, btrfs для чтения/записи и установки, iso9660, xfs, fat16, fat32, ntfs. 46. Операционная система должна поддерживать сетевые протоколы SMB, NFS, FTP, NTP, HTTP(S). 47. Операционная система должна предоставлять возможность доустановки необходимого программного обеспечения с диска или из репозитория, а также установки обновлений. Система должна обеспечить автоматическую проверку зависимостей (apt или эквивалент), а также возможность комплексного обновления системы с отдельным процессом установки ядра с помощью графических утилит. 48. Исходные коды, обновления, инструменты для сборки серверной ОС должны находиться в том же репозитории (хранилище), где хранятся исходные коды, обновления и инструменты для ОС рабочих станций. 49. Операционная система должна предоставлять единую систему для установки прикладного программного обеспечения в системе (eepm или аналог). Также должна быть обеспечена возможность установки сторонних приложений в форматах deb, tgz, tbz, tbz2, pkg.gz. 50. Операционная система должна поддерживать корневые сертификаты Минцифры России. В составе дистрибутива должен присутствовать пакет с отечественными корневыми сертификатами шифрования. 51. Операционная система должна поддерживать корневые сертификаты Российского центра сертификации ТЦИ, предоставляемые соответствующим пакетом из состава ОС. 52. Совместимость со сторонним программным обеспечением. Подсистема настольных приложений должна быть совместима с СЭД на базе программного обеспечения «ДЕЛО» (Правообладатель ООО "Электронные офисные системы", Свидетельство о гос.регистрации программы для ЭВМ № 2006614189 от 06.12.2006 г.) Значение характеристики не может изменяться участником закупки Нефункциональные требования 1. Разработчик обязан оказывать гарантийную вендорскую поддержку продукта (оперативный выпуск обновлений по безопасности). 2. Разработчик обязан оказывать техническую поддержку пользователям на условиях SLA в течение первого года использования. Для критических инцидентов должно быть обеспечено время реакции не более 8 часов в период с 9:00 до 19:00 в рабочие дни. 3. Система должна быть основана на программном обеспечении с открытым исходным кодом Значение характеристики не может изменяться участником закупки Условия передачи неисключительного права При передаче неисключительных прав (прав использования) на ПО необходимо не разглашать и не использовать во вред Заказчику полученные в рамках передачи неисключительного права (права использования) на передаваемое ПО сведения о Заказчике, о степени защищенности объектов информатизации, мероприятиях, применяемых для их защиты, персональные данные и информацию, прямо названную Заказчиком конфиденциальной. Передача указанной информации другим лицам может быть осуществлена только с письменного согласия Заказчика. За разглашение сведений, составляющих служебную, коммерческую и иную тайну, а также представляющих собой персональные данные, и нанесенный в результате этого ущерб Поставщик несет ответственность в соответствии с действующим законодательством Российской Федерации Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки - Класс программ для электронных вычислительных машин и баз данных - (02.09) Операционные системы общего назначения - - Значение характеристики не может изменяться участником закупки - Способ предоставления - Копия электронного экземпляра - - Значение характеристики не может изменяться участником закупки - Общие требования - 1. Программное обеспечение должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных Минкомсвязи РФ по классам «Операционные системы общего назначения», «Средства виртуализации», «Серверное и связующее программное обеспечение», «Средства управления базами данных», «Системы контейнеризации и контейнеры», «Средства защиты от несанкционированного доступа к информации». 2. Операционная система должна соответствовать требованиям документов: a. «Требования безопасности информации к операционным системам» (приказом ФСТЭК России от 19 августа 2016 года N 119) и «Профиль защиты операционных систем типа «А» четвертого класса защиты ИТ.ОС.А4.ПЗ» (утв. ФСТЭК России 08.02.2017). b. «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» не ниже четвертого уровня доверия (приказ ФСТЭК России № 76 от 2 июня 2020 г.). c. «Требования по безопасности информации к средствам контейнеризации» (утв. приказом ФСТЭК России от 04.07.2022 N 118) не ниже 4 класса защиты. d. «Требования по безопасности информации к средствам виртуализации» (утв. приказом ФСТЭК России от 27.10.2022 N 187) не ниже 4 класса защиты. e. «Требования по безопасности информации к системам управления базами данных» (утв. приказом ФСТЭК России от 14.04.2023 N 64) не ниже 4 класса защиты. 3. В Формуляре ОС должны быть указаны интерпретаторы, веб сервера и сервера приложений, проверенные согласно документу: «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении», утверждена ФСТЭК России 25.12.2020 г. 4. Разработчик должен иметь собственную инфраструктуру разработки полного цикла, зарегистрированную и находящуюся на территории РФ, в исключительной юрисдикции РФ. 5. Наличие локализованной сервисной и/или технической поддержки - - Значение характеристики не может изменяться участником закупки - Функциональные требования (1-5) - 1. Операционная система должна устанавливаться и функционировать на компьютерах с архитектурами x86_64 (64-разрядный процессор Intel или AMD), aarch64 («Байкал», Rockchip 3588) и «Эльбрус» (процессоры 8С, 1С+, 8СВ, 2С3, 12С, 16С) должны быть отдельные образы в сертифицированном исполнении для каждой архитектуры. Требования, перечисленные в данном документе, относятся к архитектуре x86_64 и могут отличаться от требований к другим архитектурам. 2. Операционная система должна поддерживать режимы установки и загрузки Legacy/CSM, UEFI (с включенным механизмом SecureBoot), а также средствами BMC/IPMI (если поддерживается оборудованием). 3. Операционная система должна иметь в составе ядро не ниже 6.12 (LTS) для обеспечения корректного функционирования современных средств вычислительной техники. Система должна предоставлять графические утилиты для установки, удаления и обновления ядра, включая модули, а также для выбора ядра по умолчанию. 4. Операционная система должна обеспечивать поддержку нескольких видеокарт (работа на нескольких мониторах). 5. Операционная система должна обладать русифицированным интерфейсом, а также предоставлять русскоязычную документацию - - Значение характеристики не может изменяться участником закупки - Функциональные требования (6-10) - 6. Операционная система должна иметь возможность установки с DVD-диска и USB-накопителя. Операционная система должна предоставлять варианты сетевой установки: PXE/TFTP (для режима Legacy/CSM-загрузки), HTTPClient (для спецификации UEFI 2.5 и выше), iPXE. 7. Операционная система должна предоставлять возможность организации сервера сетевой загрузки. 8. Операционная система должна предоставлять возможность установки на оборудование без графической подсистемы с локального накопителя, а также установки с использованием сервера сетевой установки по протоколу VNC. 9. Носитель с дистрибутивом ОС должен предусматривать вариант загрузки для проведения работ по восстановлению системы, включая проверку сохранности содержимого файловой системы и проверку контрольных сумм неизменяемых файлов установленных пакетов, диагностику конфигурации аппаратного обеспечения, изменение таблицы и размеров разделов, изменение параметров файловых систем, восстановление удаленных разделов и файлов, проведение резервного копирования, очистку остаточной информации на разделах и дисках. 10. Операционная система должна иметь возможность установки на программный RAID-массив, размещения разделов в томах LVM и использования маскирования (кодирования) разделов с парольным доступом - - Значение характеристики не может изменяться участником закупки - Функциональные требования (11-15) - 11. Операционная система должна обеспечивать возможность создания точек восстановления (снапшотов) для последующего возвращения системы к исходному состоянию в случае сбоя. 12. Инсталлятор дистрибутива должен предусматривать возможность предварительной (OEM) установки, позволяющей при первом запуске пользователем после установки выбрать язык, принять лицензионное соглашение, настроить дату/время, настроить сеть, задать пароль root, создать системного пользователя. 13. Операционная система должна предоставлять независимый выбор основных и дополнительных приложений в момент установки: серверные приложения (dhcp, dns,ftp, http, почтовый сервер, сервер резервного копирования, сервер печати, сервер сетевой установки), сканер обнаружения уязвимостей, сервер сертифицированной СУБД, сервер управления конфигурациями, сервер виртуальных рабочих столов, средства управления контейнеризацией, средства управления виртуализацией. 14. Операционная система после установки должна предоставлять пользователю рабочую среду, включающую системное ПО, сетевые службы и сервисы, драйвера устройств, утилиты администрирования, базовый набор приложений. 15. Если установлена графическая среда, операционная система должна предоставлять графическое средство настройки многопользовательского режима, позволяющего обеспечить одновременную работу нескольких пользователей на одном компьютере при наличии отдельной видеокарты, клавиатуры и мыши для каждого пользователя - - Значение характеристики не может изменяться участником закупки - Функциональные требования (16-20) - 16. Операционная система должна предоставлять инструмент для поиска уязвимостей в файлах конфигурации, файловых системах, используемых пакетах ОС (включая программные зависимости), образах контейнеров и git-репозиториях. Анализ уязвимостей должен осуществляться как по вендорской базе уязвимостей (CVE), собранной из разных источников, так и по базе уязвимостей (BDU) ФСТЭК России. 17. Операционная система должна предоставлять возможность установки пароля на загрузчик для ограничения доступа к опциям загрузки. 18. Операционная система должна предоставлять возможность блокировки виртуальных текстовых консолей. 19. Комплекс средств защиты ОС должен обеспечивать выполнение программ в защищенной среде. В состав ОС должны быть включены программные интерпретаторы (php, perl, lua, python, nodejs) и веб-сервер (nginx), прошедшие испытания по выявлению уязвимостей и недекларированных возможностей в полном объеме в соответствии с Методикой выявления уязвимостей и недекларированных возможностей в программном обеспечении, утвержденной ФСТЭК России 25.12.2020 г. 20. Операционная система должна включать приложение для мониторинга ресурсов. Должно быть обеспечено централизованное управление конфигурациями прав доступа к утилите мониторинга температуры жесткого диска - - Значение характеристики не может изменяться участником закупки - Функциональные требования (21-25) - 21. Операционная система должна предоставлять единый графический модульный интерфейс для администрирования и настроек, а также предоставлять возможность удаленного администрирования по защищенным протоколам с помощью графических утилит (включая конфигурирование установленной системы через веб). Администратор должен иметь возможность назначить права доступа для пользователей к определенным модулям. В состав базовых сервисов должны входить: • настройка даты и времени; • управление системными службами; • просмотр системных журналов; • конфигурирование сетевых подключений и межсетевого экрана; • установка обновлений, в том числе для компьютеров без доступа в интернет; • управление выключением удаленного компьютера; • управление пользователями; • настройка пользовательских квот на использование ресурсов памяти, диска и внешних носителей. 22. Операционная система должна реализовывать возможность хранения аутентификационной информации пользователей, полученной с использованием хеш-функций по ГОСТ Р 34.11-2012. Реализация функционала должна быть обеспечена как консольными, так и графическими утилитами. 23. Операционная система должна обеспечивать возможность создания ssh-туннелей, использующих контроль целостности заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015. 24. Операционная система должна предоставлять возможность авторизации по смарт-картам в консольном режиме. 25. Операционная система должна предоставлять протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе - - Значение характеристики не может изменяться участником закупки - Функциональные требования (26-28) - 26. Операционная система должна предоставлять возможность разграничения доступа к подключаемым устройствам. 27. Операционная система должна иметь возможность организации домена Samba-DC или интеграции с доменом Active Directory с поддержкой следующего функционала: • действовать в качестве первичного или вторичного контроллера домена; • аутентификация рабочих станций; • авторизация и предоставление ресурсов без дополнительного ввода пароля (Single Sign-On); • поддержка ролей и привилегий (назначение ролей группам); • групповые политики (GPO). 28. Операционная система должна предоставлять возможность организации трастовых доменов - - Значение характеристики не может изменяться участником закупки - Функциональные требования (29) - 29. При работе в гетерогенной среде домена 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. • Возможность принудительного выполнения политики на клиенте - - Значение характеристики не может изменяться участником закупки - Функциональные требования (30) - 30. Операционная система должна предоставлять возможность организации и настройки базовых сетевых сервисов и служб: • sshd; • DNS; • DHCP; • протокол аутентификации LDAP; • OpenVPN; • SMTP, POP3/IMAP (postfix, dovecot или эквивалент); • межсетевой экран; • проксирование HTTP- и FTP-запросов (squid или эквивалент); • резервное копирование (bacula или эквивалент); • сервер сетевой установки с веб-интерфейсом; • сервер обновлений с возможностью зеркалирования репозитория вендора ОС и создания служебных репозиториев используемого Заказчиком ПО; • защищенный сервер баз данных (PostgreSQL или эквивалент) с возможностью организации кластера из нескольких серверов, со встроенной реализацией функций round, trunc, date совместимой с Oracle DB; • веб-сервер; • FTP-сервер; • сервер мониторинга сетевых ресурсов с графическим интерфейсом (Zabbix, icinga2 или эквивалент); • сервер печати; • сервер групповой работы с веб-интерфейсом (SOGo или эквивалент); • сервер файлового обмена - - Значение характеристики не может изменяться участником закупки - Функциональные требования (31.a-h) - 31. Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: a. Программное обеспечение (ПО) должно создавать и управлять резервными копиями виртуальных машин (ВМ), контейнеров и физических узлов, содержащие архивы файлов и образов. b. ПО должно предоставлять интегрированный клиент для QEMU и LXC в виртуальной среде Proxmox. c. ПО должно поддерживать резервное копирование на магнитную ленту и управление ленточными библиотеками. d. ПО должно поддерживать дедупликацию, сжатие и аутентифицированое шифрование данных. e. ПО должно использовать следующие алгоритмы сжатия данных lzo, gzip и zstd. f. ПО должно содержать в себе веб-интерфейс (RESTful API) управления со встроенной в него консолью, доступ должен осуществляться через системную аутентификацию Linux PAM. g. ПО должно хранить данные резервных копий и предоставлять RESTful API для создания хранилищ данных и управления ими и другими ресурсами на стороне сервера. h. ПО должно позволять с помощью API, предоставленного серверной частью, позволять клиенту резервного копирования получать доступ к сохранённым данным для создания и восстановления резервных копий файлов, а также для управления дисками и другими ресурсами на стороне сервера - - Значение характеристики не может изменяться участником закупки - Функциональные требования (31.i-o) - i. ПО должно использовать протокол TLS для обеспечения безопасности обмена данными между клиентской и серверной частями. j. ПО должно использовать алгоритм AES-256 GCM при шифровании содержимого резервной копии на стороне клиента. k. ПО должно позволять создавать хранилища данных с файловой системой форматов ext4, xfs. l. ПО должно содержать в себе набор инструментов, используемых для мониторинга и управления системой S.M.A.R.T. для локальных жёстких дисков, с возможностью отображения атрибутов S.M.A.R.T. из веб-интерфейса или при помощи командной строки. m. ПО должно идентифицировать каждое хранилище данных именем и указанием на каталог в файловой системе и связывать с каждым хранилищем параметры хранения, определяющие количество снимков резервных копий для каждого интервала времени: час, день, неделя, месяц, год. n. ПО должно позволять создавать хранилища данных с возможностью выбора и настройки следующих параметров: название; путь к каталогу; количество резервных копий для хранения в этом хранилище; расписания периодического запуска удаления резервных копий и сборки мусора (удаления неиспользуемых блоков данных). o. ПО должно позволять ограничить входящий (например, резервное копирование) и исходящий (например, восстановление) сетевой трафик из набора сетей, с возможностью настроить определенные периоды, в которые будут применяться ограничения - - Значение характеристики не может изменяться участником закупки - Функциональные требования (31.p-t) - p. ПО должно позволять создавать пользователей и управлять ими как из встроенного веб-интерфейса, так и с помощью командной строки, с возможностью создания/удаления/отключения учетных записей, просмотра списка пользователей с возможностью изменения любых свойств. q. ПО должно позволять любому аутентифицированному пользователю генерировать API-токены и использовать их для настройки клиентов резервного копирования вместо прямого указания имени пользователя и пароля. API-токен должен отзываться в случае компрометации клиента и ограничивать разрешения для каждого клиента/токена в рамках разрешения пользователей. ПО должно создавать для токенов собственные записи ACL, где токены не могут делать больше, чем создавший их пользователь. r. ПО должно использовать систему управления разрешениями на основе ролей и путей, где роль содержит набор разрешенных действий, а путь представляет цель этих действий. По умолчанию разрешения созданным пользователям и API-токенам не должны предоставляться. s. ПО должно предопределять следующий ряд ролей: нет привилегий (используется для запрета доступа); все привилегии; доступ только для чтения; все привилегии для хранилищ данных; просмотр настроек хранилищ и их содержимых, без возможности чтения фактических данных; просмотр содержимого хранилища, восстановление данных; создание и восстановление собственных резервных копий; создание, восстановление и удаление собственных резервных копий; все привилегии для удалённых серверов; просмотр настроек удалённых серверов; чтение данных с удалённых серверов. t. ПО должно создавать, хранить и предоставлять следующую информацию о правах доступа: идентификатор ACL; включено или отключено; объект, на который установлено разрешение; пользователи/токены, для которых установлено разрешение; устанавливаемая роль - - Значение характеристики не может изменяться участником закупки - Функциональные требования (31.u-36) - u. ПО должно реализовывать возможность использования двухфакторной аутентификации с помощью веб-интерфейса тремя методами: TOTP (одноразовый пароль на основе времени) — для создания этого кода должен использоваться алгоритм одноразового пароля с учетом времени входа в систему (код меняется каждые 30 секунд); WebAuthn (веб-аутентификация) — реализуется с помощью различных устройств безопасности, таких как аппаратные ключи или доверенные платформенные модули (TPM). Для работы веб-аутентификации необходим сертификат HTTPS; Recovery Keys (одноразовые ключи восстановления) — список ключей, каждый из которых можно использовать только один раз. В каждый момент времени у пользователя может быть только один набор одноразовых ключей. 32. Операционная система должна предоставлять возможность установления безопасных сетевых соединений по технологии VPN. 33. Операционная система должна обеспечивать возможность создания VPN-туннелей, использующих контроль заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015. 34. Операционная система должна реализовывать базовый функционал межсетевого экрана. 35. Операционная система должна предоставлять возможность установки многоплатформенного брокера подключений для создания и управления виртуальными рабочими местами и приложениями (OpenUDS или аналог). 36. Операционная система должна включать графическое приложение для мониторинга ресурсов и просмотра системных журналов - - Значение характеристики не может изменяться участником закупки - Функциональные требования (37-43) - 37. Операционная система должна предоставлять возможность одновременной работы пользователей в изолированных сеансах. Должны быть предусмотрены: • отдельное изолированное хранение данных аутентификации каждого пользователя системы таким образом, чтобы процессы аутентификации локального или сетевого пользователя не могли получить доступа к данным аутентификации и авторизации других пользователей системы; • поддержка изоляции временных пользовательских файлов. 38. Операционная система должна включать автоматизированные средства изоляции приложений, чувствительных к сетевым атакам. 39. Операционная система должна предоставлять упреждающие меры защиты и быть сконфигурирована с безопасными настройками по умолчанию. 40. Операционная система должна предоставлять механизм управления фиксированными состояниями ключевых объектов безопасности системы, сохраняющий установленные права доступа к объектам файловой системы при обновлении пакетов. 41. Операционная система должна обеспечивать поддержку шифрования по ГОСТ Р 34.11-2012 в OpenSSL, включая генерацию ключей и создание сертификатов. 42. Операционная система должна предоставлять инструмент проверки контрольных сумм неизменяемых файлов установленных пакетов как при начальной установке, так и после получения обновлений. Вендор должен обеспечивать доступ к обновлениям и контрольным суммам неизменяемых файлов пакетов в них. 43. Подсистема контроля целостности операционной системы должна поддерживать технологии IMA и EVM - - Значение характеристики не может изменяться участником закупки - Функциональные требования (44-52) - 44. Операционная система должна предоставлять возможность запрета запуска выбранных интерпретаторов в интерактивном режиме, отключения возможности удаления открытых файлов, а также установки запрета бита исполнения (SUID), распространяемого на дочерние процессы. 45. Операционная система должна поддерживать файловые системы ext2, ext3, ext4, btrfs для чтения/записи и установки, iso9660, xfs, fat16, fat32, ntfs. 46. Операционная система должна поддерживать сетевые протоколы SMB, NFS, FTP, NTP, HTTP(S). 47. Операционная система должна предоставлять возможность доустановки необходимого программного обеспечения с диска или из репозитория, а также установки обновлений. Система должна обеспечить автоматическую проверку зависимостей (apt или эквивалент), а также возможность комплексного обновления системы с отдельным процессом установки ядра с помощью графических утилит. 48. Исходные коды, обновления, инструменты для сборки серверной ОС должны находиться в том же репозитории (хранилище), где хранятся исходные коды, обновления и инструменты для ОС рабочих станций. 49. Операционная система должна предоставлять единую систему для установки прикладного программного обеспечения в системе (eepm или аналог). Также должна быть обеспечена возможность установки сторонних приложений в форматах deb, tgz, tbz, tbz2, pkg.gz. 50. Операционная система должна поддерживать корневые сертификаты Минцифры России. В составе дистрибутива должен присутствовать пакет с отечественными корневыми сертификатами шифрования. 51. Операционная система должна поддерживать корневые сертификаты Российского центра сертификации ТЦИ, предоставляемые соответствующим пакетом из состава ОС. 52. Совместимость со сторонним программным обеспечением. Подсистема настольных приложений должна быть совместима с СЭД на базе программного обеспечения «ДЕЛО» (Правообладатель ООО "Электронные офисные системы", Свидетельство о гос.регистрации программы для ЭВМ № 2006614189 от 06.12.2006 г.) - - Значение характеристики не может изменяться участником закупки - Нефункциональные требования - 1. Разработчик обязан оказывать гарантийную вендорскую поддержку продукта (оперативный выпуск обновлений по безопасности). 2. Разработчик обязан оказывать техническую поддержку пользователям на условиях SLA в течение первого года использования. Для критических инцидентов должно быть обеспечено время реакции не более 8 часов в период с 9:00 до 19:00 в рабочие дни. 3. Система должна быть основана на программном обеспечении с открытым исходным кодом - - Значение характеристики не может изменяться участником закупки - Условия передачи неисключительного права - При передаче неисключительных прав (прав использования) на ПО необходимо не разглашать и не использовать во вред Заказчику полученные в рамках передачи неисключительного права (права использования) на передаваемое ПО сведения о Заказчике, о степени защищенности объектов информатизации, мероприятиях, применяемых для их защиты, персональные данные и информацию, прямо названную Заказчиком конфиденциальной. Передача указанной информации другим лицам может быть осуществлена только с письменного согласия Заказчика. За разглашение сведений, составляющих служебную, коммерческую и иную тайну, а также представляющих собой персональные данные, и нанесенный в результате этого ущерб Поставщик несет ответственность в соответствии с действующим законодательством Российской Федерации - - Значение характеристики не может изменяться участником закупки

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

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

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

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

Общие требования - 1. Программное обеспечение должно быть включено в Единый реестр российских программ для электронных вычислительных машин и баз данных Минкомсвязи РФ по классам «Операционные системы общего назначения», «Средства виртуализации», «Серверное и связующее программное обеспечение», «Средства управления базами данных», «Системы контейнеризации и контейнеры», «Средства защиты от несанкционированного доступа к информации». 2. Операционная система должна соответствовать требованиям документов: a. «Требования безопасности информации к операционным системам» (приказом ФСТЭК России от 19 августа 2016 года N 119) и «Профиль защиты операционных систем типа «А» четвертого класса защиты ИТ.ОС.А4.ПЗ» (утв. ФСТЭК России 08.02.2017). b. «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» не ниже четвертого уровня доверия (приказ ФСТЭК России № 76 от 2 июня 2020 г.). c. «Требования по безопасности информации к средствам контейнеризации» (утв. приказом ФСТЭК России от 04.07.2022 N 118) не ниже 4 класса защиты. d. «Требования по безопасности информации к средствам виртуализации» (утв. приказом ФСТЭК России от 27.10.2022 N 187) не ниже 4 класса защиты. e. «Требования по безопасности информации к системам управления базами данных» (утв. приказом ФСТЭК России от 14.04.2023 N 64) не ниже 4 класса защиты. 3. В Формуляре ОС должны быть указаны интерпретаторы, веб сервера и сервера приложений, проверенные согласно документу: «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении», утверждена ФСТЭК России 25.12.2020 г. 4. Разработчик должен иметь собственную инфраструктуру разработки полного цикла, зарегистрированную и находящуюся на территории РФ, в исключительной юрисдикции РФ. 5. Наличие локализованной сервисной и/или технической поддержки - - Значение характеристики не может изменяться участником закупки

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

Функциональные требования (6-10) - 6. Операционная система должна иметь возможность установки с DVD-диска и USB-накопителя. Операционная система должна предоставлять варианты сетевой установки: PXE/TFTP (для режима Legacy/CSM-загрузки), HTTPClient (для спецификации UEFI 2.5 и выше), iPXE. 7. Операционная система должна предоставлять возможность организации сервера сетевой загрузки. 8. Операционная система должна предоставлять возможность установки на оборудование без графической подсистемы с локального накопителя, а также установки с использованием сервера сетевой установки по протоколу VNC. 9. Носитель с дистрибутивом ОС должен предусматривать вариант загрузки для проведения работ по восстановлению системы, включая проверку сохранности содержимого файловой системы и проверку контрольных сумм неизменяемых файлов установленных пакетов, диагностику конфигурации аппаратного обеспечения, изменение таблицы и размеров разделов, изменение параметров файловых систем, восстановление удаленных разделов и файлов, проведение резервного копирования, очистку остаточной информации на разделах и дисках. 10. Операционная система должна иметь возможность установки на программный RAID-массив, размещения разделов в томах LVM и использования маскирования (кодирования) разделов с парольным доступом - - Значение характеристики не может изменяться участником закупки

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

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

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

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

Функциональные требования (29) - 29. При работе в гетерогенной среде домена 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. • Возможность принудительного выполнения политики на клиенте - - Значение характеристики не может изменяться участником закупки

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

Функциональные требования (31.a-h) - 31. Операционная система должна предоставлять клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и данных с физических узлов, обладающее следующими свойствами: a. Программное обеспечение (ПО) должно создавать и управлять резервными копиями виртуальных машин (ВМ), контейнеров и физических узлов, содержащие архивы файлов и образов. b. ПО должно предоставлять интегрированный клиент для QEMU и LXC в виртуальной среде Proxmox. c. ПО должно поддерживать резервное копирование на магнитную ленту и управление ленточными библиотеками. d. ПО должно поддерживать дедупликацию, сжатие и аутентифицированое шифрование данных. e. ПО должно использовать следующие алгоритмы сжатия данных lzo, gzip и zstd. f. ПО должно содержать в себе веб-интерфейс (RESTful API) управления со встроенной в него консолью, доступ должен осуществляться через системную аутентификацию Linux PAM. g. ПО должно хранить данные резервных копий и предоставлять RESTful API для создания хранилищ данных и управления ими и другими ресурсами на стороне сервера. h. ПО должно позволять с помощью API, предоставленного серверной частью, позволять клиенту резервного копирования получать доступ к сохранённым данным для создания и восстановления резервных копий файлов, а также для управления дисками и другими ресурсами на стороне сервера - - Значение характеристики не может изменяться участником закупки

Функциональные требования (31.i-o) - i. ПО должно использовать протокол TLS для обеспечения безопасности обмена данными между клиентской и серверной частями. j. ПО должно использовать алгоритм AES-256 GCM при шифровании содержимого резервной копии на стороне клиента. k. ПО должно позволять создавать хранилища данных с файловой системой форматов ext4, xfs. l. ПО должно содержать в себе набор инструментов, используемых для мониторинга и управления системой S.M.A.R.T. для локальных жёстких дисков, с возможностью отображения атрибутов S.M.A.R.T. из веб-интерфейса или при помощи командной строки. m. ПО должно идентифицировать каждое хранилище данных именем и указанием на каталог в файловой системе и связывать с каждым хранилищем параметры хранения, определяющие количество снимков резервных копий для каждого интервала времени: час, день, неделя, месяц, год. n. ПО должно позволять создавать хранилища данных с возможностью выбора и настройки следующих параметров: название; путь к каталогу; количество резервных копий для хранения в этом хранилище; расписания периодического запуска удаления резервных копий и сборки мусора (удаления неиспользуемых блоков данных). o. ПО должно позволять ограничить входящий (например, резервное копирование) и исходящий (например, восстановление) сетевой трафик из набора сетей, с возможностью настроить определенные периоды, в которые будут применяться ограничения - - Значение характеристики не может изменяться участником закупки

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

Функциональные требования (31.u-36) - u. ПО должно реализовывать возможность использования двухфакторной аутентификации с помощью веб-интерфейса тремя методами: TOTP (одноразовый пароль на основе времени) — для создания этого кода должен использоваться алгоритм одноразового пароля с учетом времени входа в систему (код меняется каждые 30 секунд); WebAuthn (веб-аутентификация) — реализуется с помощью различных устройств безопасности, таких как аппаратные ключи или доверенные платформенные модули (TPM). Для работы веб-аутентификации необходим сертификат HTTPS; Recovery Keys (одноразовые ключи восстановления) — список ключей, каждый из которых можно использовать только один раз. В каждый момент времени у пользователя может быть только один набор одноразовых ключей. 32. Операционная система должна предоставлять возможность установления безопасных сетевых соединений по технологии VPN. 33. Операционная система должна обеспечивать возможность создания VPN-туннелей, использующих контроль заголовков IP-пакетов в соответствии с ГОСТ Р 34.12-2015. 34. Операционная система должна реализовывать базовый функционал межсетевого экрана. 35. Операционная система должна предоставлять возможность установки многоплатформенного брокера подключений для создания и управления виртуальными рабочими местами и приложениями (OpenUDS или аналог). 36. Операционная система должна включать графическое приложение для мониторинга ресурсов и просмотра системных журналов - - Значение характеристики не может изменяться участником закупки

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

Функциональные требования (44-52) - 44. Операционная система должна предоставлять возможность запрета запуска выбранных интерпретаторов в интерактивном режиме, отключения возможности удаления открытых файлов, а также установки запрета бита исполнения (SUID), распространяемого на дочерние процессы. 45. Операционная система должна поддерживать файловые системы ext2, ext3, ext4, btrfs для чтения/записи и установки, iso9660, xfs, fat16, fat32, ntfs. 46. Операционная система должна поддерживать сетевые протоколы SMB, NFS, FTP, NTP, HTTP(S). 47. Операционная система должна предоставлять возможность доустановки необходимого программного обеспечения с диска или из репозитория, а также установки обновлений. Система должна обеспечить автоматическую проверку зависимостей (apt или эквивалент), а также возможность комплексного обновления системы с отдельным процессом установки ядра с помощью графических утилит. 48. Исходные коды, обновления, инструменты для сборки серверной ОС должны находиться в том же репозитории (хранилище), где хранятся исходные коды, обновления и инструменты для ОС рабочих станций. 49. Операционная система должна предоставлять единую систему для установки прикладного программного обеспечения в системе (eepm или аналог). Также должна быть обеспечена возможность установки сторонних приложений в форматах deb, tgz, tbz, tbz2, pkg.gz. 50. Операционная система должна поддерживать корневые сертификаты Минцифры России. В составе дистрибутива должен присутствовать пакет с отечественными корневыми сертификатами шифрования. 51. Операционная система должна поддерживать корневые сертификаты Российского центра сертификации ТЦИ, предоставляемые соответствующим пакетом из состава ОС. 52. Совместимость со сторонним программным обеспечением. Подсистема настольных приложений должна быть совместима с СЭД на базе программного обеспечения «ДЕЛО» (Правообладатель ООО "Электронные офисные системы", Свидетельство о гос.регистрации программы для ЭВМ № 2006614189 от 06.12.2006 г.) - - Значение характеристики не может изменяться участником закупки

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

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

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Дополнительные характеристики установлены Заказчиком в связи с недостаточностью характеристик, приведенных в КТРУ для закупки программного обеспечения, требуемого Заказчику. Применение параметров, касающихся технических, функциональных (потребительских свойств) и качественных характеристик программного обеспечения, не учтенных КТРУ, обусловлено необходимостью поставки программного обеспечения надлежащего качества, с параметрами, в наибольшей степени удовлетворяющими потребности Заказчика для перехода на новую систему электронного документооборота.

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

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

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

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

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

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

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

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

Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке, а также условия гарантии: Порядок внесения денежных средств в качестве обеспечения заявки в соответствии со статьей 44 Закона № 44-ФЗ. Обеспечение заявки на участие в закупке может предоставляться участником закупки в виде денежных средств или независимой гарантии, предусмотренной статьей 45 Закона № 44-ФЗ и требованиям, установленным постановления Правительства Российской Федерации от 08.11.2013 № 1005 «О независимых гарантиях, используемых для целей Федерального закона "О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд" (далее ПП № 1005). Выбор способа обеспечения заявки на участие в аукционе осуществляется участником закупки самостоятельно. Срок действия независимой гарантии доложен составлять не менее месяца с даты окончания срока подачи заявок. Споры, возникающие в связи с исполнением обязательств по независимой гарантии, подлежат рассмотрению в Арбитражном суде Ростовской области.

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03232643607010005800, л/c 05901153320, БИК 016015102, ОКЦ № 9 ЮГУ Банка России//УФК по Ростовской области, г Ростов-на-Дону, к/c 40102810845370000050

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

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, обл Ростовская, г.о. город Ростов-на-Дону, г Ростов-на-Дону, ул Большая Садовая, зд. 47, каб. 220

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

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

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

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

Порядок предоставления обеспечения исполнения контракта, требования к обеспечению: Исполнение контракта может обеспечиваться предоставлением независимой гарантии соответствующей требованиям ст.45 Закона № 44-ФЗ и ПП № 1005 или внесением денежных средств на указанный Заказчиком счет, на котором в соответствии с законодательством Российской Федерации учитываются операции со средствами, поступающими Заказчику. Выбор способа обеспечения осуществляется участником закупки самостоятельно. Срок действия независимой гарантии должен превышать предусмотренный контрактом срок исполнения обязательств, которые должны быть обеспечены такой независимой гарантией, не менее чем на один месяц, в том числе в случае его изменения в соответствии со ст. 95 Закона № 44-ФЗ. Споры, возникающие в связи с исполнением обязательств по независимой гарантии, подлежат рассмотрению в Арбитражном суде Ростовской области. Если участником закупки, с которым заключается контракт, предложена цена контракта, которая на двадцать пять и более процентов ниже начальной (максимальной) цены контракта, контракт заключается только после предоставления таким участником обеспечения исполнения контракта в соответствии со ст. 37 Закона № 44-ФЗ. Участник закупки освобождается от предоставления обеспечения исполнения контракта, в том числе с учетом ст. 37 Закона № 44-ФЗ в случае предоставления таким участником закупки информации согласно ч. 8.1 ст. 96 Закона № 44-ФЗ.

Платежные реквизиты для обеспечения исполнения контракта: p/c 03232643607010005800, л/c 05901153320, БИК 016015102, ОКЦ № 9 ЮГУ Банка России//УФК по Ростовской области, г Ростов-на-Дону, к/c 40102810845370000050

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

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

Срок, на который предоставляется гарантия и (или) требования к объему предоставления гарантий качества товара, работы, услуги: Предоставляемые неисключительные права на использование программного обеспечения (позиции №№ 1, 2, 3) предусматривают бессрочное использование программного обеспечения Заказчиком в соответствии с его функциональным назначением.

Информация о требованиях к гарантийному обслуживанию товара:

Требования к гарантии производителя товара:

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

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

Документы

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

Документы

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