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

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

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

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

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

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

Размещение осуществляет: Уполномоченное учреждение ГОСУДАРСТВЕННОЕ КАЗЕННОЕ УЧРЕЖДЕНИЕ НОВОСИБИРСКОЙ ОБЛАСТИ "УПРАВЛЕНИЕ КОНТРАКТНОЙ СИСТЕМЫ"

Наименование объекта закупки: Оказание услуг по предоставлению (передаче) неисключительных (пользовательских) прав на использование сервера аутентификации, его установке, настройке и адаптации

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

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

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

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

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

Почтовый адрес: 630005, Новосибирская область , Г НОВОСИБИРСК, УЛ ФРУНЗЕ, ЗД. 88, ОФИС 401

Место нахождения: 630005, Новосибирская область , Г НОВОСИБИРСК, УЛ ФРУНЗЕ, ЗД. 88, ОФИС 401

Ответственное должностное лицо: Михалев Д. И.

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

Номер контактного телефона: 8-383-2387272-6077

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ТЕРРИТОРИАЛЬНЫЙ ФОНД ОБЯЗАТЕЛЬНОГО МЕДИЦИНСКОГО СТРАХОВАНИЯ НОВОСИБИРСКОЙ ОБЛАСТИ - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Вид лицензии Простая (неисключительная) Класс программ для электронных вычислительных машин и баз данных (03.01) Средства защиты от несанкционированного доступа к информации Способ предоставления Копия электронного экземпляра Лицензия должна включать пакет ? 200 пользователей Функционал Функциональные требования. ЕСА для интеграции с ЕСИА должна поддерживать подключение к одному из следующих типовых решений: SDK ИС Клиента, TrustGate или VipNet EDI SOAP Gateway. ЕСА должна позволять создавать на основе полученных из ЕСИА сведений: учетную запись пользователя в каталоге со значениями атрибутов, соответствующих данных физического лица в ЕСИА; учетную запись группы пользователей в каталоге со значениями атрибутов, соответствующих данных организации в ЕСИА; сведения о правах доступа пользователя в организации на основе членства пользователя в группах доступа в ЕСИА. ЕСА должна предоставлять администратору возможность настроить дизайн страницы входа индивидуально для каждого приложения, в которое пользователь осуществляет вход через ЕСА. ЕСА должна поддерживать несколько языков интерфейса пользователя (дополнительно к русскому языку должна быть возможность добавить дополнительные языки в случае предоставления Заказчиком файлов с переводами). ЕСА должна отслеживать пользовательские устройства доступа. Пользователи должны иметь возможность посмотреть, какие устройства использовались для доступа в их аккаунт. Функциональные требования. ЕСА должна предоставлять пользователям веб-приложение для самостоятельного восстановления пароля. При восстановлении пароля пользователь должен подтвердить владение адресом электронной почты и/или номером мобильного телефона, знание значений выбранных атрибутов из своего аккаунта. ЕСА должна поддерживать запоминание несколько учетных записей пользователей, использующих для входа одни и те же устройство и браузер. ЕСА должна обеспечивать блокирование учетных записей в случае длительной неактивности. ЕСА должна иметь шлюз безопасности, с помощью которого можно осуществлять контроль доступа при вызове приложениями защищаемых сервисов, а именно: проверяется включенный в вызов сервиса заголовок авторизации, извлекается из заголовка маркер доступа и во взаимодействии с сервисом авторизации выполняется проверка, действителен ли маркер доступа, а также достаточно ли у пользователя и приложения прав для вызова защищаемого сервиса; во взаимодействии с сервисом авторизации заменяется маркер доступа таким образом, чтобы передаваемый от шлюза безопасности к защищаемому сервису маркер безопасности содержал только тот набор сведений о пользователе и разрешений, который необходим для работы защищаемого сервиса. При этом из маркера безопасности могут быть как изъяты излишние разрешения и сведения о пользователе, так и наоборот, добавлены в маркер доступа дополнительные разрешения и сведения, если такое установлено политикой безопасности; протоколируется в журнале событий безопасности события успешной и неуспешной проверки прав доступа. ЕСА должна предоставлять пользователю возможность самостоятельно управлять своей учетной записью, в том числе: просмотр и редактирование атрибутов учетной записи (в части, разрешенной администратором); изменение пароля от учетной записи; настройка для своей учетной записи методов двухфакторной аутентификации; просматривать события безопасности со своей учетной записью и список использованных устройств доступа. Требования по надежности и производительности ЕСА и используемые ей компоненты платформы должны поддерживать возможность развертывания в режиме кластера, позволяющего исключить наличие в системе единой точки отказа. ЕСА должна обеспечивать производительность не менее 100 запросов в секунду при медианном времени отклика не более 200 миллисекунд при осуществлении доступа из локальной сети Заказчика при работе по одному узлу кластера СУБД и приложений. ЕСА должна предоставлять метрики функционирования в формате Prometheus. Требования к предоставлению консультационных услуг по установке и настройке ПО ЕСА. Исполнитель должен предоставить Заказчику инструкцию по установке ПО ЕСА и выделить консультанта на время проведения установки. Консультант должен провести установку ЕСА самостоятельно (при предоставлении Заказчиком удаленного доступа) или консультировать инженера Заказчика при самостоятельной установке по предоставленным Исполнителем инструкциям. В процессе установки ПО удаленные консультации осуществляются в режиме видеоконференций и в режиме электронной переписки. В процессе установки ЕСА должны быть оказаны Исполнителем следующие консультации: ? рекомендованы требования к серверам для развертывания ЕСА; предоставлены инструкции по установке и настройке необходимых пакетов ОС и компонент платформы, необходимых для развертывания ЕСА; предоставлены инструкции по установке приложений ЕСА в кластерном режиме, настройке их запуска; предоставлены инструкции по настройке ЕСА для подключения к хранилищам учетных записей, настройке методов аутентификации, настройке приложений самообслуживания пользователей (ведение настроек учетной записи, восстановления пароля), подключения SMS-шлюза и сервера электронной почты; инструкции по настройке внешнего вида интерфейса пользовательских приложений. Требования к предоставлению технической поддержки. Исполнитель должен предоставить Заказчику техническую поддержку на ПО ЕСА в течение 12 месяцев с момента поставки. Техническая поддержка в последующие периоды должна оказываться в рамках отдельно заключаемого Договора технической поддержки. Техническая поддержка ПО ЕСА должна включать: исправление ошибок и дефектов ПО ЕСА, обнаруженных в процессе эксплуатации; консультирование по настройке и использованию ПО ЕСА; предоставление доступа к новым версиям ПО ЕСА и консультирование по установке обновлений. За технической поддержкой к Исполнителю должны обращаться инженеры Заказчика, отвечающие за обеспечение его эксплуатации (специалисты 2 линии технической поддержки). Техническая поддержка оказывается дистанционно в режиме видеоконференций или в режиме электронной переписки по рабочим дням и в рабочее время (с 09:00 до 18:00 по московскому времени). В рамках технической поддержки Исполнитель должен оказать консультационные услуги по настройке ПО ЕСА при подключении к ЕСА информационных систем и приложений Заказчика. Срок оказания консультационных услуг по подключению к ЕСА информационных систем и приложений Заказчика – в течение 12 месяцев с момента поставки. Требования к документации. Исполнитель должен предоставить Заказчику следующую документацию на ПО ЕСА на русском языке в виде электронных файлов: руководство администратора; руководство по интеграции; руководство пользователя; технические условия. Исполнитель должен предоставить Заказчику документацию на ПО ЕСА на русском языке в виде печатных документов: формуляр; заверенная производителем ПО ЕСА копия сертификата соответствия программного обеспечения требованиям безопасности информации. Общесистемные требования. Лицензируемое ПО должно позволять построить ЕСА со следующими характеристиками (метриками): ограничение на количество пользователей – до 1200; ограничение на количество подключенных приложений – 1000; ограничения по сроку действия лицензии – бессрочная; возможность развертывания в кластере на не менее чем 2 серверах. Веб-приложения ЕСА для конечных пользователей должны быть совместимы со следующими браузерами и ОС: браузеры актуальных версий на момент поставки: Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Яндекс.Браузер; ОС: Windows 10, 11; Astra Linux; macOS 12 и новее; iOS 15 и новее; Android 10 и новее. Веб-приложения ЕСА для администраторов должны быть совместимы со следующими браузерами и ОС: браузеры: Mozilla Firefox, Google Chrome; ОС: Windows 10, 11; Astra Linux. ПО ЕСА должно быть развернуто на серверах и ОС, предоставляемых Заказчиком. Серверное ПО ЕСА должно быть совместимо с ОС Astra Linux и СУБД PostgreSQL. Пользовательский интерфейс ЕСА должен быть на русском языке. Документация на ПО ЕСА должна быть на русском языке. ПО ЕСА должно быть включено в Единый реестр российских программ для ЭВМ. Лицензируемое ПО ЕСА должно быть зарегистрировано в установленном порядке в государственном органе по интеллектуальной собственности. Лицензируемое ПО ЕСА должно быть сертифицировано в системе сертификации ФСТЭК России. Функциональные требования. Должна быть доступна возможность настройки и использования следующих способов идентификации и аутентификации пользователей: вход по логину и паролю, причем в качестве логина должна быть возможность использовать разные сущности, например: ­ адрес электронной почты; ­ номер мобильного телефона; ­ имя пользователя (логин). идентификация и аутентификация при помощи доменной учетной записи (Kerberos); вход с помощью одноразового кода подтверждения, отправленного на телефон следующими возможными способами: в SMS-сообщении, с помощью телефонного звонка, в push-сообщении; вход с помощью одноразового кода подтверждения, отправленного на email; вход с помощью Единой системы идентификации и аутентификации (ЕСИА) в следующих возможных режимах: ­ вход в качестве физического лица; ­вход в качестве представителя организации с возможность выбора организации при входе и возможностью получения групп доступа пользователя из ЕСИА. вход через системы банков (Сбер ID, T-ID, ВТБ ID, Альфа ID) ; вход с помощью аккаунтов соцсетей и операторов связи (VK ID, Яндекс, Одноклассники, Mail ID, МТС ID); вход через внешний поставщик идентификации с поддержкой OIDC; вход через внешний поставщик идентификации с поддержкой SAML; вход по электронной подписи: USB-токены, смарт-карты; вход по ключам безопасности Passkey/FIDO2; вход с помощью чтения QR-кода и подтверждения входа на мобильном телефоне. Функциональные требования. Должна быть доступна возможность настройки и использования следующих способов подтверждения входа: подтверждение с использованием одноразового кода подтверждения, генерируемого специальным мобильным приложением (Яндекс.Ключ и аналоги); подтверждение с использованием аппаратных брелоков (HOTP/TOTP); подтверждение с использованием ключей безопасности Passkey/FIDO2/U2F; подтверждение с помощью одноразового кода подтверждения, отправленного на телефон следующими возможными способами: в SMS-сообщении, с помощью телефонного звонка, в push-сообщении; подтверждение с помощью одноразового кода подтверждения, отправленного на email; подтверждение с помощью мобильного приложения для ОС Android. Функциональные требования. ЕСА при входе по логину и паролю должна проверять соответствие пароля действующим парольным политикам и предлагать смену пароля при несоответствии пароля действующей парольной политике. Должны проверяться: сложность пароля (минимальная длина и требования к используемому алфавиту); срок действия; запрет словарных паролей; запрет повтора паролей. ЕСА должна противодействовать подбору пароля: временно блокировать вход по паролю при превышении установленного количества неправильных попыток входа по паролю; предусматривать возможность запросить проверку теста CAPTCHA (SmartCaptcha или иная, предоставленная Заказчиком); замедление входа пользователя Proof of Work (задержка входа, решение браузером вычислительно сложной задачи). Функциональные требования. ЕСА должна проверять при доступе пользователя в приложение достаточность у пользователя полномочий и надежность использованных методов аутентификации. ЕСА должна позволять администраторам ЕСА настраивать правила контроля доступа в отношении различных подключенных к ЕСА приложений. ЕСА должна протоколировать события безопасности, такие как: аутентификация пользователя, вход в приложения, привязка средств аутентификации, изменение данных пользователя. ЕСА должна предоставлять пользователям и администраторам возможность просмотра зарегистрированных событий безопасности: пользователям – в отношении своего аккаунта, администраторам – в отношении всех аккаунтов. ЕСА должна позволять в момент входа пользователя в приложения запросить у пользователя выполнить следующие действия и настройки: задать номер телефона или email, подтвердить актуальность заданных; выпустить ключ безопасности (Passkey); настроить приложение для выработки одноразовых кодов подтверждения (TOTP); показать объявление, запросить согласие пользователя. ЕСА должна предоставлять администратору ЕСА веб-консоль управления со следующими функциями администрирования: подключать веб-приложения для проведения идентификации и аутентификации, настраивать параметры взаимодействия (SAML, OpenID Connect, WS-Federation, RADIUS); настраивать атрибуты учетных записей и получение их из LDAP-каталога; настраивать доступные в ЕСА методы аутентификации; администрировать учетные записи пользователей (смотреть и менять атрибуты, сбрасывать пароль, изменять настройки двухфакторной аутентификации); управлять учетными записями администраторов системы (создавать, удалять, менять пароль, а также управлять их ролями); просматривать события безопасности; осуществлять настройку внешнего вида страниц входа; настраивать оповещения о событиях безопасности; настраивать доступные пользователям сервисы самообслуживания. Требования по взаимодействию ЕСА со смежными системами. ЕСА должно обеспечивать возможность подключения информационных систем и приложений Заказчика с использованием следующих стандартов и протоколов взаимодействия при идентификации пользователей: OpenID Connect 1.0 и OAuth 2.0 RFC 6749 "The OAuth 2.0 Authorization Framework", OpenID Connect Core 1.0 Передача атрибутов пользователя в составе id_token/access_token в JSON Web Token (JWT) Конфигурируемый REST-сервис UserInfo, настройка возвращаемых атрибутов в зависимости от scope RFC 7636 "Proof Key for Code Exchange by OAuth Public Clients" RFC 7662 "OAuth 2.0 Token Introspection" RFC 7591 "OAuth 2.0 Dynamic Client Registration Protocol" RFC 7592 "OAuth 2.0 Dynamic Client Registration Management Protocol" RFC 8252 "OAuth 2.0 for Native Apps" RFC 8414 "OAuth 2.0 Authorization Server Metadata" OpenID Connect RP-Initiated Logout 1.0 OpenID Connect Front-Channel Logout 1.0 OpenID Connect Back-Channel Logout 1.0 SAML 2.0 Web Browser SSO Profile; WS-Federation; RADIUS. Требования по взаимодействию ЕСА со смежными системами. При использовании SAML 2.0 ЕСА должна предоставлять возможность настройки администратором требуемых для подключаемой системы SAML утверждений, связи их с атрибутами учетной записи. Должна предусматриваться возможность задать идентификатор EntityID подключенной системы и загрузить/скорректировать соответствующие ей метаданные поставщика услуг. При использовании OpenID Connect 1.0 и OAuth 2 ЕСА должна предоставлять возможность в соответствии со спецификацией запросить получение кода авторизации, маркеров безопасности (маркер обновления, маркер доступа, маркер идентификации), данных пользователя (в виде JSON). ЕСА должна предоставлять возможность настройки администратором ЕСА разрешений (OAuth scope) и разрешенных в соответствии с ними атрибутов учетной записи. ЕСА должно предоставлять возможность подключения в качестве хранилища учетных записей каталоги учетных записей, поддерживающие использование протокола LDAPS. Настройки подключения ЕСА к хранилищам учетных записей должны выполняться администратором ЕСА с использованием приложения администрирования ЕСА и не должны требовать наличия у администратора ЕСА навыков программирования. Настройка должна предусматривать: указание параметров подключения ЕСА к хранилищу; указание набора атрибутов пользователя, получаемых из хранилища. Требования по взаимодействию ЕСА со смежными системами. ЕСА должна позволять администратору ЕСА настроить подключение к SMS шлюзу для отправки SMS. Для интеграции с SMS-шлюзом Заказчика должен использоваться протокол HTTPS или SMTP. ЕСА должна позволять администратору ЕСА настроить подключение к серверу электронной почты для отправки email. Для интеграции с сервером электронной почты должен использоваться протокол SMPP. ЕСА должна предоставлять REST API для следующих операций: изменение пароля; редактирование атрибутов; возможность редактирования телефона с подтверждением через код по SMS, возможность редактирования адреса электронной почты с подтверждением через код по email; настройка двухфакторной аутентификации; просмотр и редактирование запомненных устройств (ОС и браузеров), привязанных учетных записей (ЕСИА); просмотр событий безопасности с учетной записью. ЕСА должна предоставлять возможность передачи информации о событиях безопасности во внешние системы информационной безопасности. Должна быть предусмотрена возможность гибкой настройки типов передаваемых событий безопасности. - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Вид лицензии - Простая (неисключительная) - - Класс программ для электронных вычислительных машин и баз данных - (03.01) Средства защиты от несанкционированного доступа к информации - - Способ предоставления - Копия электронного экземпляра - - Лицензия должна включать пакет - ? 200 пользователей - - Функционал - Функциональные требования. ЕСА для интеграции с ЕСИА должна поддерживать подключение к одному из следующих типовых решений: SDK ИС Клиента, TrustGate или VipNet EDI SOAP Gateway. ЕСА должна позволять создавать на основе полученных из ЕСИА сведений: учетную запись пользователя в каталоге со значениями атрибутов, соответствующих данных физического лица в ЕСИА; учетную запись группы пользователей в каталоге со значениями атрибутов, соответствующих данных организации в ЕСИА; сведения о правах доступа пользователя в организации на основе членства пользователя в группах доступа в ЕСИА. ЕСА должна предоставлять администратору возможность настроить дизайн страницы входа индивидуально для каждого приложения, в которое пользователь осуществляет вход через ЕСА. ЕСА должна поддерживать несколько языков интерфейса пользователя (дополнительно к русскому языку должна быть возможность добавить дополнительные языки в случае предоставления Заказчиком файлов с переводами). ЕСА должна отслеживать пользовательские устройства доступа. Пользователи должны иметь возможность посмотреть, какие устройства использовались для доступа в их аккаунт. - - Функциональные требования. ЕСА должна предоставлять пользователям веб-приложение для самостоятельного восстановления пароля. При восстановлении пароля пользователь должен подтвердить владение адресом электронной почты и/или номером мобильного телефона, знание значений выбранных атрибутов из своего аккаунта. ЕСА должна поддерживать запоминание несколько учетных записей пользователей, использующих для входа одни и те же устройство и браузер. ЕСА должна обеспечивать блокирование учетных записей в случае длительной неактивности. ЕСА должна иметь шлюз безопасности, с помощью которого можно осуществлять контроль доступа при вызове приложениями защищаемых сервисов, а именно: проверяется включенный в вызов сервиса заголовок авторизации, извлекается из заголовка маркер доступа и во взаимодействии с сервисом авторизации выполняется проверка, действителен ли маркер доступа, а также достаточно ли у пользователя и приложения прав для вызова защищаемого сервиса; во взаимодействии с сервисом авторизации заменяется маркер доступа таким образом, чтобы передаваемый от шлюза безопасности к защищаемому сервису маркер безопасности содержал только тот набор сведений о пользователе и разрешений, который необходим для работы защищаемого сервиса. При этом из маркера безопасности могут быть как изъяты излишние разрешения и сведения о пользователе, так и наоборот, добавлены в маркер доступа дополнительные разрешения и сведения, если такое установлено политикой безопасности; протоколируется в журнале событий безопасности события успешной и неуспешной проверки прав доступа. ЕСА должна предоставлять пользователю возможность самостоятельно управлять своей учетной записью, в том числе: просмотр и редактирование атрибутов учетной записи (в части, разрешенной администратором); изменение пароля от учетной записи; настройка для своей учетной записи методов двухфакторной аутентификации; просматривать события безопасности со своей учетной записью и список использованных устройств доступа. - Требования по надежности и производительности ЕСА и используемые ей компоненты платформы должны поддерживать возможность развертывания в режиме кластера, позволяющего исключить наличие в системе единой точки отказа. ЕСА должна обеспечивать производительность не менее 100 запросов в секунду при медианном времени отклика не более 200 миллисекунд при осуществлении доступа из локальной сети Заказчика при работе по одному узлу кластера СУБД и приложений. ЕСА должна предоставлять метрики функционирования в формате Prometheus. - Требования к предоставлению консультационных услуг по установке и настройке ПО ЕСА. Исполнитель должен предоставить Заказчику инструкцию по установке ПО ЕСА и выделить консультанта на время проведения установки. Консультант должен провести установку ЕСА самостоятельно (при предоставлении Заказчиком удаленного доступа) или консультировать инженера Заказчика при самостоятельной установке по предоставленным Исполнителем инструкциям. В процессе установки ПО удаленные консультации осуществляются в режиме видеоконференций и в режиме электронной переписки. В процессе установки ЕСА должны быть оказаны Исполнителем следующие консультации: ? рекомендованы требования к серверам для развертывания ЕСА; предоставлены инструкции по установке и настройке необходимых пакетов ОС и компонент платформы, необходимых для развертывания ЕСА; предоставлены инструкции по установке приложений ЕСА в кластерном режиме, настройке их запуска; предоставлены инструкции по настройке ЕСА для подключения к хранилищам учетных записей, настройке методов аутентификации, настройке приложений самообслуживания пользователей (ведение настроек учетной записи, восстановления пароля), подключения SMS-шлюза и сервера электронной почты; инструкции по настройке внешнего вида интерфейса пользовательских приложений. - Требования к предоставлению технической поддержки. Исполнитель должен предоставить Заказчику техническую поддержку на ПО ЕСА в течение 12 месяцев с момента поставки. Техническая поддержка в последующие периоды должна оказываться в рамках отдельно заключаемого Договора технической поддержки. Техническая поддержка ПО ЕСА должна включать: исправление ошибок и дефектов ПО ЕСА, обнаруженных в процессе эксплуатации; консультирование по настройке и использованию ПО ЕСА; предоставление доступа к новым версиям ПО ЕСА и консультирование по установке обновлений. За технической поддержкой к Исполнителю должны обращаться инженеры Заказчика, отвечающие за обеспечение его эксплуатации (специалисты 2 линии технической поддержки). Техническая поддержка оказывается дистанционно в режиме видеоконференций или в режиме электронной переписки по рабочим дням и в рабочее время (с 09:00 до 18:00 по московскому времени). В рамках технической поддержки Исполнитель должен оказать консультационные услуги по настройке ПО ЕСА при подключении к ЕСА информационных систем и приложений Заказчика. Срок оказания консультационных услуг по подключению к ЕСА информационных систем и приложений Заказчика – в течение 12 месяцев с момента поставки. - Требования к документации. Исполнитель должен предоставить Заказчику следующую документацию на ПО ЕСА на русском языке в виде электронных файлов: руководство администратора; руководство по интеграции; руководство пользователя; технические условия. Исполнитель должен предоставить Заказчику документацию на ПО ЕСА на русском языке в виде печатных документов: формуляр; заверенная производителем ПО ЕСА копия сертификата соответствия программного обеспечения требованиям безопасности информации. - Общесистемные требования. Лицензируемое ПО должно позволять построить ЕСА со следующими характеристиками (метриками): ограничение на количество пользователей – до 1200; ограничение на количество подключенных приложений – 1000; ограничения по сроку действия лицензии – бессрочная; возможность развертывания в кластере на не менее чем 2 серверах. Веб-приложения ЕСА для конечных пользователей должны быть совместимы со следующими браузерами и ОС: браузеры актуальных версий на момент поставки: Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Яндекс.Браузер; ОС: Windows 10, 11; Astra Linux; macOS 12 и новее; iOS 15 и новее; Android 10 и новее. Веб-приложения ЕСА для администраторов должны быть совместимы со следующими браузерами и ОС: браузеры: Mozilla Firefox, Google Chrome; ОС: Windows 10, 11; Astra Linux. ПО ЕСА должно быть развернуто на серверах и ОС, предоставляемых Заказчиком. Серверное ПО ЕСА должно быть совместимо с ОС Astra Linux и СУБД PostgreSQL. Пользовательский интерфейс ЕСА должен быть на русском языке. Документация на ПО ЕСА должна быть на русском языке. ПО ЕСА должно быть включено в Единый реестр российских программ для ЭВМ. Лицензируемое ПО ЕСА должно быть зарегистрировано в установленном порядке в государственном органе по интеллектуальной собственности. Лицензируемое ПО ЕСА должно быть сертифицировано в системе сертификации ФСТЭК России. - Функциональные требования. Должна быть доступна возможность настройки и использования следующих способов идентификации и аутентификации пользователей: вход по логину и паролю, причем в качестве логина должна быть возможность использовать разные сущности, например: ­ адрес электронной почты; ­ номер мобильного телефона; ­ имя пользователя (логин). идентификация и аутентификация при помощи доменной учетной записи (Kerberos); вход с помощью одноразового кода подтверждения, отправленного на телефон следующими возможными способами: в SMS-сообщении, с помощью телефонного звонка, в push-сообщении; вход с помощью одноразового кода подтверждения, отправленного на email; вход с помощью Единой системы идентификации и аутентификации (ЕСИА) в следующих возможных режимах: ­ вход в качестве физического лица; ­вход в качестве представителя организации с возможность выбора организации при входе и возможностью получения групп доступа пользователя из ЕСИА. вход через системы банков (Сбер ID, T-ID, ВТБ ID, Альфа ID) ; вход с помощью аккаунтов соцсетей и операторов связи (VK ID, Яндекс, Одноклассники, Mail ID, МТС ID); вход через внешний поставщик идентификации с поддержкой OIDC; вход через внешний поставщик идентификации с поддержкой SAML; вход по электронной подписи: USB-токены, смарт-карты; вход по ключам безопасности Passkey/FIDO2; вход с помощью чтения QR-кода и подтверждения входа на мобильном телефоне. - Функциональные требования. Должна быть доступна возможность настройки и использования следующих способов подтверждения входа: подтверждение с использованием одноразового кода подтверждения, генерируемого специальным мобильным приложением (Яндекс.Ключ и аналоги); подтверждение с использованием аппаратных брелоков (HOTP/TOTP); подтверждение с использованием ключей безопасности Passkey/FIDO2/U2F; подтверждение с помощью одноразового кода подтверждения, отправленного на телефон следующими возможными способами: в SMS-сообщении, с помощью телефонного звонка, в push-сообщении; подтверждение с помощью одноразового кода подтверждения, отправленного на email; подтверждение с помощью мобильного приложения для ОС Android. - Функциональные требования. ЕСА при входе по логину и паролю должна проверять соответствие пароля действующим парольным политикам и предлагать смену пароля при несоответствии пароля действующей парольной политике. Должны проверяться: сложность пароля (минимальная длина и требования к используемому алфавиту); срок действия; запрет словарных паролей; запрет повтора паролей. ЕСА должна противодействовать подбору пароля: временно блокировать вход по паролю при превышении установленного количества неправильных попыток входа по паролю; предусматривать возможность запросить проверку теста CAPTCHA (SmartCaptcha или иная, предоставленная Заказчиком); замедление входа пользователя Proof of Work (задержка входа, решение браузером вычислительно сложной задачи). - Функциональные требования. ЕСА должна проверять при доступе пользователя в приложение достаточность у пользователя полномочий и надежность использованных методов аутентификации. ЕСА должна позволять администраторам ЕСА настраивать правила контроля доступа в отношении различных подключенных к ЕСА приложений. ЕСА должна протоколировать события безопасности, такие как: аутентификация пользователя, вход в приложения, привязка средств аутентификации, изменение данных пользователя. ЕСА должна предоставлять пользователям и администраторам возможность просмотра зарегистрированных событий безопасности: пользователям – в отношении своего аккаунта, администраторам – в отношении всех аккаунтов. ЕСА должна позволять в момент входа пользователя в приложения запросить у пользователя выполнить следующие действия и настройки: задать номер телефона или email, подтвердить актуальность заданных; выпустить ключ безопасности (Passkey); настроить приложение для выработки одноразовых кодов подтверждения (TOTP); показать объявление, запросить согласие пользователя. ЕСА должна предоставлять администратору ЕСА веб-консоль управления со следующими функциями администрирования: подключать веб-приложения для проведения идентификации и аутентификации, настраивать параметры взаимодействия (SAML, OpenID Connect, WS-Federation, RADIUS); настраивать атрибуты учетных записей и получение их из LDAP-каталога; настраивать доступные в ЕСА методы аутентификации; администрировать учетные записи пользователей (смотреть и менять атрибуты, сбрасывать пароль, изменять настройки двухфакторной аутентификации); управлять учетными записями администраторов системы (создавать, удалять, менять пароль, а также управлять их ролями); просматривать события безопасности; осуществлять настройку внешнего вида страниц входа; настраивать оповещения о событиях безопасности; настраивать доступные пользователям сервисы самообслуживания. - Требования по взаимодействию ЕСА со смежными системами. ЕСА должно обеспечивать возможность подключения информационных систем и приложений Заказчика с использованием следующих стандартов и протоколов взаимодействия при идентификации пользователей: OpenID Connect 1.0 и OAuth 2.0 RFC 6749 "The OAuth 2.0 Authorization Framework", OpenID Connect Core 1.0 Передача атрибутов пользователя в составе id_token/access_token в JSON Web Token (JWT) Конфигурируемый REST-сервис UserInfo, настройка возвращаемых атрибутов в зависимости от scope RFC 7636 "Proof Key for Code Exchange by OAuth Public Clients" RFC 7662 "OAuth 2.0 Token Introspection" RFC 7591 "OAuth 2.0 Dynamic Client Registration Protocol" RFC 7592 "OAuth 2.0 Dynamic Client Registration Management Protocol" RFC 8252 "OAuth 2.0 for Native Apps" RFC 8414 "OAuth 2.0 Authorization Server Metadata" OpenID Connect RP-Initiated Logout 1.0 OpenID Connect Front-Channel Logout 1.0 OpenID Connect Back-Channel Logout 1.0 SAML 2.0 Web Browser SSO Profile; WS-Federation; RADIUS. - Требования по взаимодействию ЕСА со смежными системами. При использовании SAML 2.0 ЕСА должна предоставлять возможность настройки администратором требуемых для подключаемой системы SAML утверждений, связи их с атрибутами учетной записи. Должна предусматриваться возможность задать идентификатор EntityID подключенной системы и загрузить/скорректировать соответствующие ей метаданные поставщика услуг. При использовании OpenID Connect 1.0 и OAuth 2 ЕСА должна предоставлять возможность в соответствии со спецификацией запросить получение кода авторизации, маркеров безопасности (маркер обновления, маркер доступа, маркер идентификации), данных пользователя (в виде JSON). ЕСА должна предоставлять возможность настройки администратором ЕСА разрешений (OAuth scope) и разрешенных в соответствии с ними атрибутов учетной записи. ЕСА должно предоставлять возможность подключения в качестве хранилища учетных записей каталоги учетных записей, поддерживающие использование протокола LDAPS. Настройки подключения ЕСА к хранилищам учетных записей должны выполняться администратором ЕСА с использованием приложения администрирования ЕСА и не должны требовать наличия у администратора ЕСА навыков программирования. Настройка должна предусматривать: указание параметров подключения ЕСА к хранилищу; указание набора атрибутов пользователя, получаемых из хранилища. - Требования по взаимодействию ЕСА со смежными системами. ЕСА должна позволять администратору ЕСА настроить подключение к SMS шлюзу для отправки SMS. Для интеграции с SMS-шлюзом Заказчика должен использоваться протокол HTTPS или SMTP. ЕСА должна позволять администратору ЕСА настроить подключение к серверу электронной почты для отправки email. Для интеграции с сервером электронной почты должен использоваться протокол SMPP. ЕСА должна предоставлять REST API для следующих операций: изменение пароля; редактирование атрибутов; возможность редактирования телефона с подтверждением через код по SMS, возможность редактирования адреса электронной почты с подтверждением через код по email; настройка двухфакторной аутентификации; просмотр и редактирование запомненных устройств (ОС и браузеров), привязанных учетных записей (ЕСИА); просмотр событий безопасности с учетной записью. ЕСА должна предоставлять возможность передачи информации о событиях безопасности во внешние системы информационной безопасности. Должна быть предусмотрена возможность гибкой настройки типов передаваемых событий безопасности.

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

Вид лицензии - Простая (неисключительная) -

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

Способ предоставления - Копия электронного экземпляра -

Лицензия должна включать пакет - ? 200 пользователей -

Функционал - Функциональные требования. ЕСА для интеграции с ЕСИА должна поддерживать подключение к одному из следующих типовых решений: SDK ИС Клиента, TrustGate или VipNet EDI SOAP Gateway. ЕСА должна позволять создавать на основе полученных из ЕСИА сведений: учетную запись пользователя в каталоге со значениями атрибутов, соответствующих данных физического лица в ЕСИА; учетную запись группы пользователей в каталоге со значениями атрибутов, соответствующих данных организации в ЕСИА; сведения о правах доступа пользователя в организации на основе членства пользователя в группах доступа в ЕСИА. ЕСА должна предоставлять администратору возможность настроить дизайн страницы входа индивидуально для каждого приложения, в которое пользователь осуществляет вход через ЕСА. ЕСА должна поддерживать несколько языков интерфейса пользователя (дополнительно к русскому языку должна быть возможность добавить дополнительные языки в случае предоставления Заказчиком файлов с переводами). ЕСА должна отслеживать пользовательские устройства доступа. Пользователи должны иметь возможность посмотреть, какие устройства использовались для доступа в их аккаунт. -

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

Требования по надежности и производительности ЕСА и используемые ей компоненты платформы должны поддерживать возможность развертывания в режиме кластера, позволяющего исключить наличие в системе единой точки отказа. ЕСА должна обеспечивать производительность не менее 100 запросов в секунду при медианном времени отклика не более 200 миллисекунд при осуществлении доступа из локальной сети Заказчика при работе по одному узлу кластера СУБД и приложений. ЕСА должна предоставлять метрики функционирования в формате Prometheus.

Требования к предоставлению консультационных услуг по установке и настройке ПО ЕСА. Исполнитель должен предоставить Заказчику инструкцию по установке ПО ЕСА и выделить консультанта на время проведения установки. Консультант должен провести установку ЕСА самостоятельно (при предоставлении Заказчиком удаленного доступа) или консультировать инженера Заказчика при самостоятельной установке по предоставленным Исполнителем инструкциям. В процессе установки ПО удаленные консультации осуществляются в режиме видеоконференций и в режиме электронной переписки. В процессе установки ЕСА должны быть оказаны Исполнителем следующие консультации: ? рекомендованы требования к серверам для развертывания ЕСА; предоставлены инструкции по установке и настройке необходимых пакетов ОС и компонент платформы, необходимых для развертывания ЕСА; предоставлены инструкции по установке приложений ЕСА в кластерном режиме, настройке их запуска; предоставлены инструкции по настройке ЕСА для подключения к хранилищам учетных записей, настройке методов аутентификации, настройке приложений самообслуживания пользователей (ведение настроек учетной записи, восстановления пароля), подключения SMS-шлюза и сервера электронной почты; инструкции по настройке внешнего вида интерфейса пользовательских приложений.

Требования к предоставлению технической поддержки. Исполнитель должен предоставить Заказчику техническую поддержку на ПО ЕСА в течение 12 месяцев с момента поставки. Техническая поддержка в последующие периоды должна оказываться в рамках отдельно заключаемого Договора технической поддержки. Техническая поддержка ПО ЕСА должна включать: исправление ошибок и дефектов ПО ЕСА, обнаруженных в процессе эксплуатации; консультирование по настройке и использованию ПО ЕСА; предоставление доступа к новым версиям ПО ЕСА и консультирование по установке обновлений. За технической поддержкой к Исполнителю должны обращаться инженеры Заказчика, отвечающие за обеспечение его эксплуатации (специалисты 2 линии технической поддержки). Техническая поддержка оказывается дистанционно в режиме видеоконференций или в режиме электронной переписки по рабочим дням и в рабочее время (с 09:00 до 18:00 по московскому времени). В рамках технической поддержки Исполнитель должен оказать консультационные услуги по настройке ПО ЕСА при подключении к ЕСА информационных систем и приложений Заказчика. Срок оказания консультационных услуг по подключению к ЕСА информационных систем и приложений Заказчика – в течение 12 месяцев с момента поставки.

Требования к документации. Исполнитель должен предоставить Заказчику следующую документацию на ПО ЕСА на русском языке в виде электронных файлов: руководство администратора; руководство по интеграции; руководство пользователя; технические условия. Исполнитель должен предоставить Заказчику документацию на ПО ЕСА на русском языке в виде печатных документов: формуляр; заверенная производителем ПО ЕСА копия сертификата соответствия программного обеспечения требованиям безопасности информации.

Общесистемные требования. Лицензируемое ПО должно позволять построить ЕСА со следующими характеристиками (метриками): ограничение на количество пользователей – до 1200; ограничение на количество подключенных приложений – 1000; ограничения по сроку действия лицензии – бессрочная; возможность развертывания в кластере на не менее чем 2 серверах. Веб-приложения ЕСА для конечных пользователей должны быть совместимы со следующими браузерами и ОС: браузеры актуальных версий на момент поставки: Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Яндекс.Браузер; ОС: Windows 10, 11; Astra Linux; macOS 12 и новее; iOS 15 и новее; Android 10 и новее. Веб-приложения ЕСА для администраторов должны быть совместимы со следующими браузерами и ОС: браузеры: Mozilla Firefox, Google Chrome; ОС: Windows 10, 11; Astra Linux. ПО ЕСА должно быть развернуто на серверах и ОС, предоставляемых Заказчиком. Серверное ПО ЕСА должно быть совместимо с ОС Astra Linux и СУБД PostgreSQL. Пользовательский интерфейс ЕСА должен быть на русском языке. Документация на ПО ЕСА должна быть на русском языке. ПО ЕСА должно быть включено в Единый реестр российских программ для ЭВМ. Лицензируемое ПО ЕСА должно быть зарегистрировано в установленном порядке в государственном органе по интеллектуальной собственности. Лицензируемое ПО ЕСА должно быть сертифицировано в системе сертификации ФСТЭК России.

Функциональные требования. Должна быть доступна возможность настройки и использования следующих способов идентификации и аутентификации пользователей: вход по логину и паролю, причем в качестве логина должна быть возможность использовать разные сущности, например: ­ адрес электронной почты; ­ номер мобильного телефона; ­ имя пользователя (логин). идентификация и аутентификация при помощи доменной учетной записи (Kerberos); вход с помощью одноразового кода подтверждения, отправленного на телефон следующими возможными способами: в SMS-сообщении, с помощью телефонного звонка, в push-сообщении; вход с помощью одноразового кода подтверждения, отправленного на email; вход с помощью Единой системы идентификации и аутентификации (ЕСИА) в следующих возможных режимах: ­ вход в качестве физического лица; ­вход в качестве представителя организации с возможность выбора организации при входе и возможностью получения групп доступа пользователя из ЕСИА. вход через системы банков (Сбер ID, T-ID, ВТБ ID, Альфа ID) ; вход с помощью аккаунтов соцсетей и операторов связи (VK ID, Яндекс, Одноклассники, Mail ID, МТС ID); вход через внешний поставщик идентификации с поддержкой OIDC; вход через внешний поставщик идентификации с поддержкой SAML; вход по электронной подписи: USB-токены, смарт-карты; вход по ключам безопасности Passkey/FIDO2; вход с помощью чтения QR-кода и подтверждения входа на мобильном телефоне.

Функциональные требования. Должна быть доступна возможность настройки и использования следующих способов подтверждения входа: подтверждение с использованием одноразового кода подтверждения, генерируемого специальным мобильным приложением (Яндекс.Ключ и аналоги); подтверждение с использованием аппаратных брелоков (HOTP/TOTP); подтверждение с использованием ключей безопасности Passkey/FIDO2/U2F; подтверждение с помощью одноразового кода подтверждения, отправленного на телефон следующими возможными способами: в SMS-сообщении, с помощью телефонного звонка, в push-сообщении; подтверждение с помощью одноразового кода подтверждения, отправленного на email; подтверждение с помощью мобильного приложения для ОС Android.

Функциональные требования. ЕСА при входе по логину и паролю должна проверять соответствие пароля действующим парольным политикам и предлагать смену пароля при несоответствии пароля действующей парольной политике. Должны проверяться: сложность пароля (минимальная длина и требования к используемому алфавиту); срок действия; запрет словарных паролей; запрет повтора паролей. ЕСА должна противодействовать подбору пароля: временно блокировать вход по паролю при превышении установленного количества неправильных попыток входа по паролю; предусматривать возможность запросить проверку теста CAPTCHA (SmartCaptcha или иная, предоставленная Заказчиком); замедление входа пользователя Proof of Work (задержка входа, решение браузером вычислительно сложной задачи).

Функциональные требования. ЕСА должна проверять при доступе пользователя в приложение достаточность у пользователя полномочий и надежность использованных методов аутентификации. ЕСА должна позволять администраторам ЕСА настраивать правила контроля доступа в отношении различных подключенных к ЕСА приложений. ЕСА должна протоколировать события безопасности, такие как: аутентификация пользователя, вход в приложения, привязка средств аутентификации, изменение данных пользователя. ЕСА должна предоставлять пользователям и администраторам возможность просмотра зарегистрированных событий безопасности: пользователям – в отношении своего аккаунта, администраторам – в отношении всех аккаунтов. ЕСА должна позволять в момент входа пользователя в приложения запросить у пользователя выполнить следующие действия и настройки: задать номер телефона или email, подтвердить актуальность заданных; выпустить ключ безопасности (Passkey); настроить приложение для выработки одноразовых кодов подтверждения (TOTP); показать объявление, запросить согласие пользователя. ЕСА должна предоставлять администратору ЕСА веб-консоль управления со следующими функциями администрирования: подключать веб-приложения для проведения идентификации и аутентификации, настраивать параметры взаимодействия (SAML, OpenID Connect, WS-Federation, RADIUS); настраивать атрибуты учетных записей и получение их из LDAP-каталога; настраивать доступные в ЕСА методы аутентификации; администрировать учетные записи пользователей (смотреть и менять атрибуты, сбрасывать пароль, изменять настройки двухфакторной аутентификации); управлять учетными записями администраторов системы (создавать, удалять, менять пароль, а также управлять их ролями); просматривать события безопасности; осуществлять настройку внешнего вида страниц входа; настраивать оповещения о событиях безопасности; настраивать доступные пользователям сервисы самообслуживания.

Требования по взаимодействию ЕСА со смежными системами. ЕСА должно обеспечивать возможность подключения информационных систем и приложений Заказчика с использованием следующих стандартов и протоколов взаимодействия при идентификации пользователей: OpenID Connect 1.0 и OAuth 2.0 RFC 6749 "The OAuth 2.0 Authorization Framework", OpenID Connect Core 1.0 Передача атрибутов пользователя в составе id_token/access_token в JSON Web Token (JWT) Конфигурируемый REST-сервис UserInfo, настройка возвращаемых атрибутов в зависимости от scope RFC 7636 "Proof Key for Code Exchange by OAuth Public Clients" RFC 7662 "OAuth 2.0 Token Introspection" RFC 7591 "OAuth 2.0 Dynamic Client Registration Protocol" RFC 7592 "OAuth 2.0 Dynamic Client Registration Management Protocol" RFC 8252 "OAuth 2.0 for Native Apps" RFC 8414 "OAuth 2.0 Authorization Server Metadata" OpenID Connect RP-Initiated Logout 1.0 OpenID Connect Front-Channel Logout 1.0 OpenID Connect Back-Channel Logout 1.0 SAML 2.0 Web Browser SSO Profile; WS-Federation; RADIUS.

Требования по взаимодействию ЕСА со смежными системами. При использовании SAML 2.0 ЕСА должна предоставлять возможность настройки администратором требуемых для подключаемой системы SAML утверждений, связи их с атрибутами учетной записи. Должна предусматриваться возможность задать идентификатор EntityID подключенной системы и загрузить/скорректировать соответствующие ей метаданные поставщика услуг. При использовании OpenID Connect 1.0 и OAuth 2 ЕСА должна предоставлять возможность в соответствии со спецификацией запросить получение кода авторизации, маркеров безопасности (маркер обновления, маркер доступа, маркер идентификации), данных пользователя (в виде JSON). ЕСА должна предоставлять возможность настройки администратором ЕСА разрешений (OAuth scope) и разрешенных в соответствии с ними атрибутов учетной записи. ЕСА должно предоставлять возможность подключения в качестве хранилища учетных записей каталоги учетных записей, поддерживающие использование протокола LDAPS. Настройки подключения ЕСА к хранилищам учетных записей должны выполняться администратором ЕСА с использованием приложения администрирования ЕСА и не должны требовать наличия у администратора ЕСА навыков программирования. Настройка должна предусматривать: указание параметров подключения ЕСА к хранилищу; указание набора атрибутов пользователя, получаемых из хранилища.

Требования по взаимодействию ЕСА со смежными системами. ЕСА должна позволять администратору ЕСА настроить подключение к SMS шлюзу для отправки SMS. Для интеграции с SMS-шлюзом Заказчика должен использоваться протокол HTTPS или SMTP. ЕСА должна позволять администратору ЕСА настроить подключение к серверу электронной почты для отправки email. Для интеграции с сервером электронной почты должен использоваться протокол SMPP. ЕСА должна предоставлять REST API для следующих операций: изменение пароля; редактирование атрибутов; возможность редактирования телефона с подтверждением через код по SMS, возможность редактирования адреса электронной почты с подтверждением через код по email; настройка двухфакторной аутентификации; просмотр и редактирование запомненных устройств (ОС и браузеров), привязанных учетных записей (ЕСИА); просмотр событий безопасности с учетной записью. ЕСА должна предоставлять возможность передачи информации о событиях безопасности во внешние системы информационной безопасности. Должна быть предусмотрена возможность гибкой настройки типов передаваемых событий безопасности.

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

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

ТЕРРИТОРИАЛЬНЫЙ ФОНД ОБЯЗАТЕЛЬНОГО МЕДИЦИНСКОГО СТРАХОВАНИЯ НОВОСИБИРСКОЙ ОБЛАСТИ - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Вид лицензии Простая (неисключительная) Класс программ для электронных вычислительных машин и баз данных (03.01) Средства защиты от несанкционированного доступа к информации Способ предоставления Копия электронного экземпляра Лицензия должна включать пакет ? 1000 клиентов Функционал Требования по взаимодействию ЕСА со смежными системами. ЕСА должна позволять администратору ЕСА настроить подключение к SMS шлюзу для отправки SMS. Для интеграции с SMS-шлюзом Заказчика должен использоваться протокол HTTPS или SMTP. ЕСА должна позволять администратору ЕСА настроить подключение к серверу электронной почты для отправки email. Для интеграции с сервером электронной почты должен использоваться протокол SMPP. ЕСА должна предоставлять REST API для следующих операций: изменение пароля; редактирование атрибутов; возможность редактирования телефона с подтверждением через код по SMS, возможность редактирования адреса электронной почты с подтверждением через код по email; настройка двухфакторной аутентификации; просмотр и редактирование запомненных устройств (ОС и браузеров), привязанных учетных записей (ЕСИА); просмотр событий безопасности с учетной записью. ЕСА должна предоставлять возможность передачи информации о событиях безопасности во внешние системы информационной безопасности. Должна быть предусмотрена возможность гибкой настройки типов передаваемых событий безопасности. Функциональные требования. ЕСА должна предоставлять пользователям веб-приложение для самостоятельного восстановления пароля. При восстановлении пароля пользователь должен подтвердить владение адресом электронной почты и/или номером мобильного телефона, знание значений выбранных атрибутов из своего аккаунта. ЕСА должна поддерживать запоминание несколько учетных записей пользователей, использующих для входа одни и те же устройство и браузер. ЕСА должна обеспечивать блокирование учетных записей в случае длительной неактивности. ЕСА должна иметь шлюз безопасности, с помощью которого можно осуществлять контроль доступа при вызове приложениями защищаемых сервисов, а именно: проверяется включенный в вызов сервиса заголовок авторизации, извлекается из заголовка маркер доступа и во взаимодействии с сервисом авторизации выполняется проверка, действителен ли маркер доступа, а также достаточно ли у пользователя и приложения прав для вызова защищаемого сервиса; во взаимодействии с сервисом авторизации заменяется маркер доступа таким образом, чтобы передаваемый от шлюза безопасности к защищаемому сервису маркер безопасности содержал только тот набор сведений о пользователе и разрешений, который необходим для работы защищаемого сервиса. При этом из маркера безопасности могут быть как изъяты излишние разрешения и сведения о пользователе, так и наоборот, добавлены в маркер доступа дополнительные разрешения и сведения, если такое установлено политикой безопасности; протоколируется в журнале событий безопасности события успешной и неуспешной проверки прав доступа. ЕСА должна предоставлять пользователю возможность самостоятельно управлять своей учетной записью, в том числе: просмотр и редактирование атрибутов учетной записи (в части, разрешенной администратором); изменение пароля от учетной записи; настройка для своей учетной записи методов двухфакторной аутентификации; просматривать события безопасности со своей учетной записью и список использованных устройств доступа. Требования к предоставлению консультационных услуг по установке и настройке ПО ЕСА. Исполнитель должен предоставить Заказчику инструкцию по установке ПО ЕСА и выделить консультанта на время проведения установки. Консультант должен провести установку ЕСА самостоятельно (при предоставлении Заказчиком удаленного доступа) или консультировать инженера Заказчика при самостоятельной установке по предоставленным Исполнителем инструкциям. В процессе установки ПО удаленные консультации осуществляются в режиме видеоконференций и в режиме электронной переписки. В процессе установки ЕСА должны быть оказаны Исполнителем следующие консультации: рекомендованы требования к серверам для развертывания ЕСА; предоставлены инструкции по установке и настройке необходимых пакетов ОС и компонент платформы, необходимых для развертывания ЕСА; предоставлены инструкции по установке приложений ЕСА в кластерном режиме, настройке их запуска; предоставлены инструкции по настройке ЕСА для подключения к хранилищам учетных записей, настройке методов аутентификации, настройке приложений самообслуживания пользователей (ведение настроек учетной записи, восстановления пароля), подключения SMS-шлюза и сервера электронной почты; инструкции по настройке внешнего вида интерфейса пользовательских приложений. Общесистемные требования. Лицензируемое ПО должно позволять построить ЕСА со следующими характеристиками (метриками): ограничение на количество пользователей – до 1200; ограничение на количество подключенных приложений – 1000; ограничения по сроку действия лицензии – бессрочная; возможность развертывания в кластере на не менее чем 2 серверах. Веб-приложения ЕСА для конечных пользователей должны быть совместимы со следующими браузерами и ОС: браузеры актуальных версий на момент поставки: Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Яндекс.Браузер; ОС: Windows 10, 11; Astra Linux; macOS 12 и новее; iOS 15 и новее; Android 10 и новее. Веб-приложения ЕСА для администраторов должны быть совместимы со следующими браузерами и ОС: браузеры: Mozilla Firefox, Google Chrome; ОС: Windows 10, 11; Astra Linux. ПО ЕСА должно быть развернуто на серверах и ОС, предоставляемых Заказчиком. Серверное ПО ЕСА должно быть совместимо с ОС Astra Linux и СУБД PostgreSQL. Пользовательский интерфейс ЕСА должен быть на русском языке. Документация на ПО ЕСА должна быть на русском языке. ПО ЕСА должно быть включено в Единый реестр российских программ для ЭВМ. Лицензируемое ПО ЕСА должно быть зарегистрировано в установленном порядке в государственном органе по интеллектуальной собственности. Лицензируемое ПО ЕСА должно быть сертифицировано в системе сертификации ФСТЭК России. Функциональные требования. Должна быть доступна возможность настройки и использования следующих способов идентификации и аутентификации пользователей: вход по логину и паролю, причем в качестве логина должна быть возможность использовать разные сущности, например: ­ адрес электронной почты; ­ номер мобильного телефона; ­ имя пользователя (логин). идентификация и аутентификация при помощи доменной учетной записи (Kerberos); вход с помощью одноразового кода подтверждения, отправленного на телефон следующими возможными способами: в SMS-сообщении, с помощью телефонного звонка, в push-сообщении; вход с помощью одноразового кода подтверждения, отправленного на email; вход с помощью Единой системы идентификации и аутентификации (ЕСИА) в следующих возможных режимах: ­ вход в качестве физического лица; ­ вход в качестве представителя организации с возможность выбора организации при входе и возможностью получения групп доступа пользователя из ЕСИА. вход через системы банков (Сбер ID, T-ID, ВТБ ID, Альфа ID) ; вход с помощью аккаунтов соцсетей и операторов связи (VK ID, Яндекс, Одноклассники, Mail ID, МТС ID); вход через внешний поставщик идентификации с поддержкой OIDC; вход через внешний поставщик идентификации с поддержкой SAML; вход по электронной подписи: USB-токены, смарт-карты; вход по ключам безопасности Passkey/FIDO2; вход с помощью чтения QR-кода и подтверждения входа на мобильном телефоне. Функциональные требования. Должна быть доступна возможность настройки и использования следующих способов подтверждения входа: подтверждение с использованием одноразового кода подтверждения, генерируемого специальным мобильным приложением (Яндекс.Ключ и аналоги); подтверждение с использованием аппаратных брелоков (HOTP/TOTP); подтверждение с использованием ключей безопасности Passkey/FIDO2/U2F; подтверждение с помощью одноразового кода подтверждения, отправленного на телефон следующими возможными способами: в SMS-сообщении, с помощью телефонного звонка, в push-сообщении; подтверждение с помощью одноразового кода подтверждения, отправленного на email; подтверждение с помощью мобильного приложения для ОС Android. Функциональные требования. ЕСА при входе по логину и паролю должна проверять соответствие пароля действующим парольным политикам и предлагать смену пароля при несоответствии пароля действующей парольной политике. Должны проверяться: сложность пароля (минимальная длина и требования к используемому алфавиту); срок действия; запрет словарных паролей; запрет повтора паролей. ЕСА должна противодействовать подбору пароля: временно блокировать вход по паролю при превышении установленного количества неправильных попыток входа по паролю; предусматривать возможность запросить проверку теста CAPTCHA (SmartCaptcha или иная, предоставленная Заказчиком); замедление входа пользователя Proof of Work (задержка входа, решение браузером вычислительно сложной задачи). Функциональные требования. ЕСА для интеграции с ЕСИА должна поддерживать подключение к одному из следующих типовых решений: SDK ИС Клиента, TrustGate или VipNet EDI SOAP Gateway. ЕСА должна позволять создавать на основе полученных из ЕСИА сведений: учетную запись пользователя в каталоге со значениями атрибутов, соответствующих данных физического лица в ЕСИА; учетную запись группы пользователей в каталоге со значениями атрибутов, соответствующих данных организации в ЕСИА; сведения о правах доступа пользователя в организации на основе членства пользователя в группах доступа в ЕСИА. ЕСА должна предоставлять администратору возможность настроить дизайн страницы входа индивидуально для каждого приложения, в которое пользователь осуществляет вход через ЕСА. ЕСА должна поддерживать несколько языков интерфейса пользователя (дополнительно к русскому языку должна быть возможность добавить дополнительные языки в случае предоставления Заказчиком файлов с переводами). ЕСА должна отслеживать пользовательские устройства доступа. Пользователи должны иметь возможность посмотреть, какие устройства использовались для доступа в их аккаунт. Функциональные требования. ЕСА должна проверять при доступе пользователя в приложение достаточность у пользователя полномочий и надежность использованных методов аутентификации. ЕСА должна позволять администраторам ЕСА настраивать правила контроля доступа в отношении различных подключенных к ЕСА приложений. ЕСА должна протоколировать события безопасности, такие как: аутентификация пользователя, вход в приложения, привязка средств аутентификации, изменение данных пользователя. ЕСА должна предоставлять пользователям и администраторам возможность просмотра зарегистрированных событий безопасности: пользователям – в отношении своего аккаунта, администраторам – в отношении всех аккаунтов. ЕСА должна позволять в момент входа пользователя в приложения запросить у пользователя выполнить следующие действия и настройки: задать номер телефона или email, подтвердить актуальность заданных; выпустить ключ безопасности (Passkey); настроить приложение для выработки одноразовых кодов подтверждения (TOTP); показать объявление, запросить согласие пользователя. ЕСА должна предоставлять администратору ЕСА веб-консоль управления со следующими функциями администрирования: подключать веб-приложения для проведения идентификации и аутентификации, настраивать параметры взаимодействия (SAML, OpenID Connect, WS-Federation, RADIUS); настраивать атрибуты учетных записей и получение их из LDAP-каталога; настраивать доступные в ЕСА методы аутентификации; администрировать учетные записи пользователей (смотреть и менять атрибуты, сбрасывать пароль, изменять настройки двухфакторной аутентификации); управлять учетными записями администраторов системы (создавать, удалять, менять пароль, а также управлять их ролями); просматривать события безопасности; осуществлять настройку внешнего вида страниц входа; настраивать оповещения о событиях безопасности; настраивать доступные пользователям сервисы самообслуживания. Требования по взаимодействию ЕСА со смежными системами. ЕСА должно обеспечивать возможность подключения информационных систем и приложений Заказчика с использованием следующих стандартов и протоколов взаимодействия при идентификации пользователей: OpenID Connect 1.0 и OAuth 2.0 RFC 6749 "The OAuth 2.0 Authorization Framework", OpenID Connect Core 1.0 Передача атрибутов пользователя в составе id_token/access_token в JSON Web Token (JWT) Конфигурируемый REST-сервис UserInfo, настройка возвращаемых атрибутов в зависимости от scope RFC 7636 "Proof Key for Code Exchange by OAuth Public Clients" RFC 7662 "OAuth 2.0 Token Introspection" RFC 7591 "OAuth 2.0 Dynamic Client Registration Protocol" RFC 7592 "OAuth 2.0 Dynamic Client Registration Management Protocol" RFC 8252 "OAuth 2.0 for Native Apps" RFC 8414 "OAuth 2.0 Authorization Server Metadata" OpenID Connect RP-Initiated Logout 1.0 OpenID Connect Front-Channel Logout 1.0 OpenID Connect Back-Channel Logout 1.0 SAML 2.0 Web Browser SSO Profile; WS-Federation; RADIUS. Требования по взаимодействию ЕСА со смежными системами. При использовании SAML 2.0 ЕСА должна предоставлять возможность настройки администратором требуемых для подключаемой системы SAML утверждений, связи их с атрибутами учетной записи. Должна предусматриваться возможность задать идентификатор EntityID подключенной системы и загрузить/скорректировать соответствующие ей метаданные поставщика услуг. При использовании OpenID Connect 1.0 и OAuth 2 ЕСА должна предоставлять возможность в соответствии со спецификацией запросить получение кода авторизации, маркеров безопасности (маркер обновления, маркер доступа, маркер идентификации), данных пользователя (в виде JSON). ЕСА должна предоставлять возможность настройки администратором ЕСА разрешений (OAuth scope) и разрешенных в соответствии с ними атрибутов учетной записи. ЕСА должно предоставлять возможность подключения в качестве хранилища учетных записей каталоги учетных записей, поддерживающие использование протокола LDAPS. Настройки подключения ЕСА к хранилищам учетных записей должны выполняться администратором ЕСА с использованием приложения администрирования ЕСА и не должны требовать наличия у администратора ЕСА навыков программирования. Настройка должна предусматривать: указание параметров подключения ЕСА к хранилищу; указание набора атрибутов пользователя, получаемых из хранилища. Требования по надежности и производительности. ЕСА и используемые ей компоненты платформы должны поддерживать возможность развертывания в режиме кластера, позволяющего исключить наличие в системе единой точки отказа. ЕСА должна обеспечивать производительность не менее 100 запросов в секунду при медианном времени отклика не более 200 миллисекунд при осуществлении доступа из локальной сети Заказчика при работе по одному узлу кластера СУБД и приложений. ЕСА должна предоставлять метрики функционирования в формате Prometheus. Требования к предоставлению технической поддержки. Исполнитель должен предоставить Заказчику техническую поддержку на ПО ЕСА в течение 12 месяцев с момента поставки. Техническая поддержка в последующие периоды должна оказываться в рамках отдельно заключаемого Договора технической поддержки. Техническая поддержка ПО ЕСА должна включать: исправление ошибок и дефектов ПО ЕСА, обнаруженных в процессе эксплуатации; консультирование по настройке и использованию ПО ЕСА; предоставление доступа к новым версиям ПО ЕСА и консультирование по установке обновлений. За технической поддержкой к Исполнителю должны обращаться инженеры Заказчика, отвечающие за обеспечение его эксплуатации (специалисты 2 линии технической поддержки). Техническая поддержка оказывается дистанционно в режиме видеоконференций или в режиме электронной переписки по рабочим дням и в рабочее время (с 09:00 до 18:00 по московскому времени). В рамках технической поддержки Исполнитель должен оказать консультационные услуги по настройке ПО ЕСА при подключении к ЕСА информационных систем и приложений Заказчика. Срок оказания консультационных услуг по подключению к ЕСА информационных систем и приложений Заказчика – в течение 12 месяцев с момента поставки. Требования к документации. Исполнитель должен предоставить Заказчику следующую документацию на ПО ЕСА на русском языке в виде электронных файлов: руководство администратора; руководство по интеграции; руководство пользователя; технические условия. Исполнитель должен предоставить Заказчику документацию на ПО ЕСА на русском языке в виде печатных документов: формуляр; заверенная производителем ПО ЕСА копия сертификата соответствия программного обеспечения требованиям безопасности информации. - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Вид лицензии - Простая (неисключительная) - - Класс программ для электронных вычислительных машин и баз данных - (03.01) Средства защиты от несанкционированного доступа к информации - - Способ предоставления - Копия электронного экземпляра - - Лицензия должна включать пакет - ? 1000 клиентов - - Функционал - Требования по взаимодействию ЕСА со смежными системами. ЕСА должна позволять администратору ЕСА настроить подключение к SMS шлюзу для отправки SMS. Для интеграции с SMS-шлюзом Заказчика должен использоваться протокол HTTPS или SMTP. ЕСА должна позволять администратору ЕСА настроить подключение к серверу электронной почты для отправки email. Для интеграции с сервером электронной почты должен использоваться протокол SMPP. ЕСА должна предоставлять REST API для следующих операций: изменение пароля; редактирование атрибутов; возможность редактирования телефона с подтверждением через код по SMS, возможность редактирования адреса электронной почты с подтверждением через код по email; настройка двухфакторной аутентификации; просмотр и редактирование запомненных устройств (ОС и браузеров), привязанных учетных записей (ЕСИА); просмотр событий безопасности с учетной записью. ЕСА должна предоставлять возможность передачи информации о событиях безопасности во внешние системы информационной безопасности. Должна быть предусмотрена возможность гибкой настройки типов передаваемых событий безопасности. - - Функциональные требования. ЕСА должна предоставлять пользователям веб-приложение для самостоятельного восстановления пароля. При восстановлении пароля пользователь должен подтвердить владение адресом электронной почты и/или номером мобильного телефона, знание значений выбранных атрибутов из своего аккаунта. ЕСА должна поддерживать запоминание несколько учетных записей пользователей, использующих для входа одни и те же устройство и браузер. ЕСА должна обеспечивать блокирование учетных записей в случае длительной неактивности. ЕСА должна иметь шлюз безопасности, с помощью которого можно осуществлять контроль доступа при вызове приложениями защищаемых сервисов, а именно: проверяется включенный в вызов сервиса заголовок авторизации, извлекается из заголовка маркер доступа и во взаимодействии с сервисом авторизации выполняется проверка, действителен ли маркер доступа, а также достаточно ли у пользователя и приложения прав для вызова защищаемого сервиса; во взаимодействии с сервисом авторизации заменяется маркер доступа таким образом, чтобы передаваемый от шлюза безопасности к защищаемому сервису маркер безопасности содержал только тот набор сведений о пользователе и разрешений, который необходим для работы защищаемого сервиса. При этом из маркера безопасности могут быть как изъяты излишние разрешения и сведения о пользователе, так и наоборот, добавлены в маркер доступа дополнительные разрешения и сведения, если такое установлено политикой безопасности; протоколируется в журнале событий безопасности события успешной и неуспешной проверки прав доступа. ЕСА должна предоставлять пользователю возможность самостоятельно управлять своей учетной записью, в том числе: просмотр и редактирование атрибутов учетной записи (в части, разрешенной администратором); изменение пароля от учетной записи; настройка для своей учетной записи методов двухфакторной аутентификации; просматривать события безопасности со своей учетной записью и список использованных устройств доступа. - Требования к предоставлению консультационных услуг по установке и настройке ПО ЕСА. Исполнитель должен предоставить Заказчику инструкцию по установке ПО ЕСА и выделить консультанта на время проведения установки. Консультант должен провести установку ЕСА самостоятельно (при предоставлении Заказчиком удаленного доступа) или консультировать инженера Заказчика при самостоятельной установке по предоставленным Исполнителем инструкциям. В процессе установки ПО удаленные консультации осуществляются в режиме видеоконференций и в режиме электронной переписки. В процессе установки ЕСА должны быть оказаны Исполнителем следующие консультации: рекомендованы требования к серверам для развертывания ЕСА; предоставлены инструкции по установке и настройке необходимых пакетов ОС и компонент платформы, необходимых для развертывания ЕСА; предоставлены инструкции по установке приложений ЕСА в кластерном режиме, настройке их запуска; предоставлены инструкции по настройке ЕСА для подключения к хранилищам учетных записей, настройке методов аутентификации, настройке приложений самообслуживания пользователей (ведение настроек учетной записи, восстановления пароля), подключения SMS-шлюза и сервера электронной почты; инструкции по настройке внешнего вида интерфейса пользовательских приложений. - Общесистемные требования. Лицензируемое ПО должно позволять построить ЕСА со следующими характеристиками (метриками): ограничение на количество пользователей – до 1200; ограничение на количество подключенных приложений – 1000; ограничения по сроку действия лицензии – бессрочная; возможность развертывания в кластере на не менее чем 2 серверах. Веб-приложения ЕСА для конечных пользователей должны быть совместимы со следующими браузерами и ОС: браузеры актуальных версий на момент поставки: Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Яндекс.Браузер; ОС: Windows 10, 11; Astra Linux; macOS 12 и новее; iOS 15 и новее; Android 10 и новее. Веб-приложения ЕСА для администраторов должны быть совместимы со следующими браузерами и ОС: браузеры: Mozilla Firefox, Google Chrome; ОС: Windows 10, 11; Astra Linux. ПО ЕСА должно быть развернуто на серверах и ОС, предоставляемых Заказчиком. Серверное ПО ЕСА должно быть совместимо с ОС Astra Linux и СУБД PostgreSQL. Пользовательский интерфейс ЕСА должен быть на русском языке. Документация на ПО ЕСА должна быть на русском языке. ПО ЕСА должно быть включено в Единый реестр российских программ для ЭВМ. Лицензируемое ПО ЕСА должно быть зарегистрировано в установленном порядке в государственном органе по интеллектуальной собственности. Лицензируемое ПО ЕСА должно быть сертифицировано в системе сертификации ФСТЭК России. - Функциональные требования. Должна быть доступна возможность настройки и использования следующих способов идентификации и аутентификации пользователей: вход по логину и паролю, причем в качестве логина должна быть возможность использовать разные сущности, например: ­ адрес электронной почты; ­ номер мобильного телефона; ­ имя пользователя (логин). идентификация и аутентификация при помощи доменной учетной записи (Kerberos); вход с помощью одноразового кода подтверждения, отправленного на телефон следующими возможными способами: в SMS-сообщении, с помощью телефонного звонка, в push-сообщении; вход с помощью одноразового кода подтверждения, отправленного на email; вход с помощью Единой системы идентификации и аутентификации (ЕСИА) в следующих возможных режимах: ­ вход в качестве физического лица; ­ вход в качестве представителя организации с возможность выбора организации при входе и возможностью получения групп доступа пользователя из ЕСИА. вход через системы банков (Сбер ID, T-ID, ВТБ ID, Альфа ID) ; вход с помощью аккаунтов соцсетей и операторов связи (VK ID, Яндекс, Одноклассники, Mail ID, МТС ID); вход через внешний поставщик идентификации с поддержкой OIDC; вход через внешний поставщик идентификации с поддержкой SAML; вход по электронной подписи: USB-токены, смарт-карты; вход по ключам безопасности Passkey/FIDO2; вход с помощью чтения QR-кода и подтверждения входа на мобильном телефоне. - Функциональные требования. Должна быть доступна возможность настройки и использования следующих способов подтверждения входа: подтверждение с использованием одноразового кода подтверждения, генерируемого специальным мобильным приложением (Яндекс.Ключ и аналоги); подтверждение с использованием аппаратных брелоков (HOTP/TOTP); подтверждение с использованием ключей безопасности Passkey/FIDO2/U2F; подтверждение с помощью одноразового кода подтверждения, отправленного на телефон следующими возможными способами: в SMS-сообщении, с помощью телефонного звонка, в push-сообщении; подтверждение с помощью одноразового кода подтверждения, отправленного на email; подтверждение с помощью мобильного приложения для ОС Android. - Функциональные требования. ЕСА при входе по логину и паролю должна проверять соответствие пароля действующим парольным политикам и предлагать смену пароля при несоответствии пароля действующей парольной политике. Должны проверяться: сложность пароля (минимальная длина и требования к используемому алфавиту); срок действия; запрет словарных паролей; запрет повтора паролей. ЕСА должна противодействовать подбору пароля: временно блокировать вход по паролю при превышении установленного количества неправильных попыток входа по паролю; предусматривать возможность запросить проверку теста CAPTCHA (SmartCaptcha или иная, предоставленная Заказчиком); замедление входа пользователя Proof of Work (задержка входа, решение браузером вычислительно сложной задачи). - Функциональные требования. ЕСА для интеграции с ЕСИА должна поддерживать подключение к одному из следующих типовых решений: SDK ИС Клиента, TrustGate или VipNet EDI SOAP Gateway. ЕСА должна позволять создавать на основе полученных из ЕСИА сведений: учетную запись пользователя в каталоге со значениями атрибутов, соответствующих данных физического лица в ЕСИА; учетную запись группы пользователей в каталоге со значениями атрибутов, соответствующих данных организации в ЕСИА; сведения о правах доступа пользователя в организации на основе членства пользователя в группах доступа в ЕСИА. ЕСА должна предоставлять администратору возможность настроить дизайн страницы входа индивидуально для каждого приложения, в которое пользователь осуществляет вход через ЕСА. ЕСА должна поддерживать несколько языков интерфейса пользователя (дополнительно к русскому языку должна быть возможность добавить дополнительные языки в случае предоставления Заказчиком файлов с переводами). ЕСА должна отслеживать пользовательские устройства доступа. Пользователи должны иметь возможность посмотреть, какие устройства использовались для доступа в их аккаунт. - Функциональные требования. ЕСА должна проверять при доступе пользователя в приложение достаточность у пользователя полномочий и надежность использованных методов аутентификации. ЕСА должна позволять администраторам ЕСА настраивать правила контроля доступа в отношении различных подключенных к ЕСА приложений. ЕСА должна протоколировать события безопасности, такие как: аутентификация пользователя, вход в приложения, привязка средств аутентификации, изменение данных пользователя. ЕСА должна предоставлять пользователям и администраторам возможность просмотра зарегистрированных событий безопасности: пользователям – в отношении своего аккаунта, администраторам – в отношении всех аккаунтов. ЕСА должна позволять в момент входа пользователя в приложения запросить у пользователя выполнить следующие действия и настройки: задать номер телефона или email, подтвердить актуальность заданных; выпустить ключ безопасности (Passkey); настроить приложение для выработки одноразовых кодов подтверждения (TOTP); показать объявление, запросить согласие пользователя. ЕСА должна предоставлять администратору ЕСА веб-консоль управления со следующими функциями администрирования: подключать веб-приложения для проведения идентификации и аутентификации, настраивать параметры взаимодействия (SAML, OpenID Connect, WS-Federation, RADIUS); настраивать атрибуты учетных записей и получение их из LDAP-каталога; настраивать доступные в ЕСА методы аутентификации; администрировать учетные записи пользователей (смотреть и менять атрибуты, сбрасывать пароль, изменять настройки двухфакторной аутентификации); управлять учетными записями администраторов системы (создавать, удалять, менять пароль, а также управлять их ролями); просматривать события безопасности; осуществлять настройку внешнего вида страниц входа; настраивать оповещения о событиях безопасности; настраивать доступные пользователям сервисы самообслуживания. - Требования по взаимодействию ЕСА со смежными системами. ЕСА должно обеспечивать возможность подключения информационных систем и приложений Заказчика с использованием следующих стандартов и протоколов взаимодействия при идентификации пользователей: OpenID Connect 1.0 и OAuth 2.0 RFC 6749 "The OAuth 2.0 Authorization Framework", OpenID Connect Core 1.0 Передача атрибутов пользователя в составе id_token/access_token в JSON Web Token (JWT) Конфигурируемый REST-сервис UserInfo, настройка возвращаемых атрибутов в зависимости от scope RFC 7636 "Proof Key for Code Exchange by OAuth Public Clients" RFC 7662 "OAuth 2.0 Token Introspection" RFC 7591 "OAuth 2.0 Dynamic Client Registration Protocol" RFC 7592 "OAuth 2.0 Dynamic Client Registration Management Protocol" RFC 8252 "OAuth 2.0 for Native Apps" RFC 8414 "OAuth 2.0 Authorization Server Metadata" OpenID Connect RP-Initiated Logout 1.0 OpenID Connect Front-Channel Logout 1.0 OpenID Connect Back-Channel Logout 1.0 SAML 2.0 Web Browser SSO Profile; WS-Federation; RADIUS. - Требования по взаимодействию ЕСА со смежными системами. При использовании SAML 2.0 ЕСА должна предоставлять возможность настройки администратором требуемых для подключаемой системы SAML утверждений, связи их с атрибутами учетной записи. Должна предусматриваться возможность задать идентификатор EntityID подключенной системы и загрузить/скорректировать соответствующие ей метаданные поставщика услуг. При использовании OpenID Connect 1.0 и OAuth 2 ЕСА должна предоставлять возможность в соответствии со спецификацией запросить получение кода авторизации, маркеров безопасности (маркер обновления, маркер доступа, маркер идентификации), данных пользователя (в виде JSON). ЕСА должна предоставлять возможность настройки администратором ЕСА разрешений (OAuth scope) и разрешенных в соответствии с ними атрибутов учетной записи. ЕСА должно предоставлять возможность подключения в качестве хранилища учетных записей каталоги учетных записей, поддерживающие использование протокола LDAPS. Настройки подключения ЕСА к хранилищам учетных записей должны выполняться администратором ЕСА с использованием приложения администрирования ЕСА и не должны требовать наличия у администратора ЕСА навыков программирования. Настройка должна предусматривать: указание параметров подключения ЕСА к хранилищу; указание набора атрибутов пользователя, получаемых из хранилища. - Требования по надежности и производительности. ЕСА и используемые ей компоненты платформы должны поддерживать возможность развертывания в режиме кластера, позволяющего исключить наличие в системе единой точки отказа. ЕСА должна обеспечивать производительность не менее 100 запросов в секунду при медианном времени отклика не более 200 миллисекунд при осуществлении доступа из локальной сети Заказчика при работе по одному узлу кластера СУБД и приложений. ЕСА должна предоставлять метрики функционирования в формате Prometheus. - Требования к предоставлению технической поддержки. Исполнитель должен предоставить Заказчику техническую поддержку на ПО ЕСА в течение 12 месяцев с момента поставки. Техническая поддержка в последующие периоды должна оказываться в рамках отдельно заключаемого Договора технической поддержки. Техническая поддержка ПО ЕСА должна включать: исправление ошибок и дефектов ПО ЕСА, обнаруженных в процессе эксплуатации; консультирование по настройке и использованию ПО ЕСА; предоставление доступа к новым версиям ПО ЕСА и консультирование по установке обновлений. За технической поддержкой к Исполнителю должны обращаться инженеры Заказчика, отвечающие за обеспечение его эксплуатации (специалисты 2 линии технической поддержки). Техническая поддержка оказывается дистанционно в режиме видеоконференций или в режиме электронной переписки по рабочим дням и в рабочее время (с 09:00 до 18:00 по московскому времени). В рамках технической поддержки Исполнитель должен оказать консультационные услуги по настройке ПО ЕСА при подключении к ЕСА информационных систем и приложений Заказчика. Срок оказания консультационных услуг по подключению к ЕСА информационных систем и приложений Заказчика – в течение 12 месяцев с момента поставки. - Требования к документации. Исполнитель должен предоставить Заказчику следующую документацию на ПО ЕСА на русском языке в виде электронных файлов: руководство администратора; руководство по интеграции; руководство пользователя; технические условия. Исполнитель должен предоставить Заказчику документацию на ПО ЕСА на русском языке в виде печатных документов: формуляр; заверенная производителем ПО ЕСА копия сертификата соответствия программного обеспечения требованиям безопасности информации.

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

Вид лицензии - Простая (неисключительная) -

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

Способ предоставления - Копия электронного экземпляра -

Лицензия должна включать пакет - ? 1000 клиентов -

Функционал - Требования по взаимодействию ЕСА со смежными системами. ЕСА должна позволять администратору ЕСА настроить подключение к SMS шлюзу для отправки SMS. Для интеграции с SMS-шлюзом Заказчика должен использоваться протокол HTTPS или SMTP. ЕСА должна позволять администратору ЕСА настроить подключение к серверу электронной почты для отправки email. Для интеграции с сервером электронной почты должен использоваться протокол SMPP. ЕСА должна предоставлять REST API для следующих операций: изменение пароля; редактирование атрибутов; возможность редактирования телефона с подтверждением через код по SMS, возможность редактирования адреса электронной почты с подтверждением через код по email; настройка двухфакторной аутентификации; просмотр и редактирование запомненных устройств (ОС и браузеров), привязанных учетных записей (ЕСИА); просмотр событий безопасности с учетной записью. ЕСА должна предоставлять возможность передачи информации о событиях безопасности во внешние системы информационной безопасности. Должна быть предусмотрена возможность гибкой настройки типов передаваемых событий безопасности. -

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

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

Общесистемные требования. Лицензируемое ПО должно позволять построить ЕСА со следующими характеристиками (метриками): ограничение на количество пользователей – до 1200; ограничение на количество подключенных приложений – 1000; ограничения по сроку действия лицензии – бессрочная; возможность развертывания в кластере на не менее чем 2 серверах. Веб-приложения ЕСА для конечных пользователей должны быть совместимы со следующими браузерами и ОС: браузеры актуальных версий на момент поставки: Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Яндекс.Браузер; ОС: Windows 10, 11; Astra Linux; macOS 12 и новее; iOS 15 и новее; Android 10 и новее. Веб-приложения ЕСА для администраторов должны быть совместимы со следующими браузерами и ОС: браузеры: Mozilla Firefox, Google Chrome; ОС: Windows 10, 11; Astra Linux. ПО ЕСА должно быть развернуто на серверах и ОС, предоставляемых Заказчиком. Серверное ПО ЕСА должно быть совместимо с ОС Astra Linux и СУБД PostgreSQL. Пользовательский интерфейс ЕСА должен быть на русском языке. Документация на ПО ЕСА должна быть на русском языке. ПО ЕСА должно быть включено в Единый реестр российских программ для ЭВМ. Лицензируемое ПО ЕСА должно быть зарегистрировано в установленном порядке в государственном органе по интеллектуальной собственности. Лицензируемое ПО ЕСА должно быть сертифицировано в системе сертификации ФСТЭК России.

Функциональные требования. Должна быть доступна возможность настройки и использования следующих способов идентификации и аутентификации пользователей: вход по логину и паролю, причем в качестве логина должна быть возможность использовать разные сущности, например: ­ адрес электронной почты; ­ номер мобильного телефона; ­ имя пользователя (логин). идентификация и аутентификация при помощи доменной учетной записи (Kerberos); вход с помощью одноразового кода подтверждения, отправленного на телефон следующими возможными способами: в SMS-сообщении, с помощью телефонного звонка, в push-сообщении; вход с помощью одноразового кода подтверждения, отправленного на email; вход с помощью Единой системы идентификации и аутентификации (ЕСИА) в следующих возможных режимах: ­ вход в качестве физического лица; ­ вход в качестве представителя организации с возможность выбора организации при входе и возможностью получения групп доступа пользователя из ЕСИА. вход через системы банков (Сбер ID, T-ID, ВТБ ID, Альфа ID) ; вход с помощью аккаунтов соцсетей и операторов связи (VK ID, Яндекс, Одноклассники, Mail ID, МТС ID); вход через внешний поставщик идентификации с поддержкой OIDC; вход через внешний поставщик идентификации с поддержкой SAML; вход по электронной подписи: USB-токены, смарт-карты; вход по ключам безопасности Passkey/FIDO2; вход с помощью чтения QR-кода и подтверждения входа на мобильном телефоне.

Функциональные требования. Должна быть доступна возможность настройки и использования следующих способов подтверждения входа: подтверждение с использованием одноразового кода подтверждения, генерируемого специальным мобильным приложением (Яндекс.Ключ и аналоги); подтверждение с использованием аппаратных брелоков (HOTP/TOTP); подтверждение с использованием ключей безопасности Passkey/FIDO2/U2F; подтверждение с помощью одноразового кода подтверждения, отправленного на телефон следующими возможными способами: в SMS-сообщении, с помощью телефонного звонка, в push-сообщении; подтверждение с помощью одноразового кода подтверждения, отправленного на email; подтверждение с помощью мобильного приложения для ОС Android.

Функциональные требования. ЕСА при входе по логину и паролю должна проверять соответствие пароля действующим парольным политикам и предлагать смену пароля при несоответствии пароля действующей парольной политике. Должны проверяться: сложность пароля (минимальная длина и требования к используемому алфавиту); срок действия; запрет словарных паролей; запрет повтора паролей. ЕСА должна противодействовать подбору пароля: временно блокировать вход по паролю при превышении установленного количества неправильных попыток входа по паролю; предусматривать возможность запросить проверку теста CAPTCHA (SmartCaptcha или иная, предоставленная Заказчиком); замедление входа пользователя Proof of Work (задержка входа, решение браузером вычислительно сложной задачи).

Функциональные требования. ЕСА для интеграции с ЕСИА должна поддерживать подключение к одному из следующих типовых решений: SDK ИС Клиента, TrustGate или VipNet EDI SOAP Gateway. ЕСА должна позволять создавать на основе полученных из ЕСИА сведений: учетную запись пользователя в каталоге со значениями атрибутов, соответствующих данных физического лица в ЕСИА; учетную запись группы пользователей в каталоге со значениями атрибутов, соответствующих данных организации в ЕСИА; сведения о правах доступа пользователя в организации на основе членства пользователя в группах доступа в ЕСИА. ЕСА должна предоставлять администратору возможность настроить дизайн страницы входа индивидуально для каждого приложения, в которое пользователь осуществляет вход через ЕСА. ЕСА должна поддерживать несколько языков интерфейса пользователя (дополнительно к русскому языку должна быть возможность добавить дополнительные языки в случае предоставления Заказчиком файлов с переводами). ЕСА должна отслеживать пользовательские устройства доступа. Пользователи должны иметь возможность посмотреть, какие устройства использовались для доступа в их аккаунт.

Функциональные требования. ЕСА должна проверять при доступе пользователя в приложение достаточность у пользователя полномочий и надежность использованных методов аутентификации. ЕСА должна позволять администраторам ЕСА настраивать правила контроля доступа в отношении различных подключенных к ЕСА приложений. ЕСА должна протоколировать события безопасности, такие как: аутентификация пользователя, вход в приложения, привязка средств аутентификации, изменение данных пользователя. ЕСА должна предоставлять пользователям и администраторам возможность просмотра зарегистрированных событий безопасности: пользователям – в отношении своего аккаунта, администраторам – в отношении всех аккаунтов. ЕСА должна позволять в момент входа пользователя в приложения запросить у пользователя выполнить следующие действия и настройки: задать номер телефона или email, подтвердить актуальность заданных; выпустить ключ безопасности (Passkey); настроить приложение для выработки одноразовых кодов подтверждения (TOTP); показать объявление, запросить согласие пользователя. ЕСА должна предоставлять администратору ЕСА веб-консоль управления со следующими функциями администрирования: подключать веб-приложения для проведения идентификации и аутентификации, настраивать параметры взаимодействия (SAML, OpenID Connect, WS-Federation, RADIUS); настраивать атрибуты учетных записей и получение их из LDAP-каталога; настраивать доступные в ЕСА методы аутентификации; администрировать учетные записи пользователей (смотреть и менять атрибуты, сбрасывать пароль, изменять настройки двухфакторной аутентификации); управлять учетными записями администраторов системы (создавать, удалять, менять пароль, а также управлять их ролями); просматривать события безопасности; осуществлять настройку внешнего вида страниц входа; настраивать оповещения о событиях безопасности; настраивать доступные пользователям сервисы самообслуживания.

Требования по взаимодействию ЕСА со смежными системами. ЕСА должно обеспечивать возможность подключения информационных систем и приложений Заказчика с использованием следующих стандартов и протоколов взаимодействия при идентификации пользователей: OpenID Connect 1.0 и OAuth 2.0 RFC 6749 "The OAuth 2.0 Authorization Framework", OpenID Connect Core 1.0 Передача атрибутов пользователя в составе id_token/access_token в JSON Web Token (JWT) Конфигурируемый REST-сервис UserInfo, настройка возвращаемых атрибутов в зависимости от scope RFC 7636 "Proof Key for Code Exchange by OAuth Public Clients" RFC 7662 "OAuth 2.0 Token Introspection" RFC 7591 "OAuth 2.0 Dynamic Client Registration Protocol" RFC 7592 "OAuth 2.0 Dynamic Client Registration Management Protocol" RFC 8252 "OAuth 2.0 for Native Apps" RFC 8414 "OAuth 2.0 Authorization Server Metadata" OpenID Connect RP-Initiated Logout 1.0 OpenID Connect Front-Channel Logout 1.0 OpenID Connect Back-Channel Logout 1.0 SAML 2.0 Web Browser SSO Profile; WS-Federation; RADIUS.

Требования по взаимодействию ЕСА со смежными системами. При использовании SAML 2.0 ЕСА должна предоставлять возможность настройки администратором требуемых для подключаемой системы SAML утверждений, связи их с атрибутами учетной записи. Должна предусматриваться возможность задать идентификатор EntityID подключенной системы и загрузить/скорректировать соответствующие ей метаданные поставщика услуг. При использовании OpenID Connect 1.0 и OAuth 2 ЕСА должна предоставлять возможность в соответствии со спецификацией запросить получение кода авторизации, маркеров безопасности (маркер обновления, маркер доступа, маркер идентификации), данных пользователя (в виде JSON). ЕСА должна предоставлять возможность настройки администратором ЕСА разрешений (OAuth scope) и разрешенных в соответствии с ними атрибутов учетной записи. ЕСА должно предоставлять возможность подключения в качестве хранилища учетных записей каталоги учетных записей, поддерживающие использование протокола LDAPS. Настройки подключения ЕСА к хранилищам учетных записей должны выполняться администратором ЕСА с использованием приложения администрирования ЕСА и не должны требовать наличия у администратора ЕСА навыков программирования. Настройка должна предусматривать: указание параметров подключения ЕСА к хранилищу; указание набора атрибутов пользователя, получаемых из хранилища.

Требования по надежности и производительности. ЕСА и используемые ей компоненты платформы должны поддерживать возможность развертывания в режиме кластера, позволяющего исключить наличие в системе единой точки отказа. ЕСА должна обеспечивать производительность не менее 100 запросов в секунду при медианном времени отклика не более 200 миллисекунд при осуществлении доступа из локальной сети Заказчика при работе по одному узлу кластера СУБД и приложений. ЕСА должна предоставлять метрики функционирования в формате Prometheus.

Требования к предоставлению технической поддержки. Исполнитель должен предоставить Заказчику техническую поддержку на ПО ЕСА в течение 12 месяцев с момента поставки. Техническая поддержка в последующие периоды должна оказываться в рамках отдельно заключаемого Договора технической поддержки. Техническая поддержка ПО ЕСА должна включать: исправление ошибок и дефектов ПО ЕСА, обнаруженных в процессе эксплуатации; консультирование по настройке и использованию ПО ЕСА; предоставление доступа к новым версиям ПО ЕСА и консультирование по установке обновлений. За технической поддержкой к Исполнителю должны обращаться инженеры Заказчика, отвечающие за обеспечение его эксплуатации (специалисты 2 линии технической поддержки). Техническая поддержка оказывается дистанционно в режиме видеоконференций или в режиме электронной переписки по рабочим дням и в рабочее время (с 09:00 до 18:00 по московскому времени). В рамках технической поддержки Исполнитель должен оказать консультационные услуги по настройке ПО ЕСА при подключении к ЕСА информационных систем и приложений Заказчика. Срок оказания консультационных услуг по подключению к ЕСА информационных систем и приложений Заказчика – в течение 12 месяцев с момента поставки.

Требования к документации. Исполнитель должен предоставить Заказчику следующую документацию на ПО ЕСА на русском языке в виде электронных файлов: руководство администратора; руководство по интеграции; руководство пользователя; технические условия. Исполнитель должен предоставить Заказчику документацию на ПО ЕСА на русском языке в виде печатных документов: формуляр; заверенная производителем ПО ЕСА копия сертификата соответствия программного обеспечения требованиям безопасности информации.

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

- 62.09.20.120 - Установка и настройка сервиса Установка и настройка сервиса указано в Описании объекта закупки - Условная единица - 1,00 - 1 162 980,00 - 1 162 980,00

ТЕРРИТОРИАЛЬНЫЙ ФОНД ОБЯЗАТЕЛЬНОГО МЕДИЦИНСКОГО СТРАХОВАНИЯ НОВОСИБИРСКОЙ ОБЛАСТИ - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Установка и настройка сервиса указано в Описании объекта закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Установка и настройка сервиса - указано в Описании объекта закупки -

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

Установка и настройка сервиса - указано в Описании объекта закупки -

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

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

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

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

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

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

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

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

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

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

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

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

Срок исполнения контракта: 56  рабочих дней

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

Наименование бюджета: бюджет Территориального фонда обязательного медицинского страхования Новосибирской области

Вид бюджета: бюджет территориального государственного внебюджетного фонда

Код территории муниципального образования: 50000009: Муниципальные образования Новосибирской области / Территориальный фонд обязательного медицинского страхования

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

Размер обеспечения заявки: 16 052,40 Российский рубль

Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке, а также условия гарантии: Обеспечение заявки предоставляется участником закупки в соответствии со ст.44 Федерального закона от 05.04.2013 №44-ФЗ. Условия независимой гарантии установлены в соответствии со ст. 45 Федерального закона от 05.04.2013 №44-ФЗ.

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03272643500000095100, л/c 05515035790, БИК 015004950, СИБИРСКОЕ ГУ БАНКА РОССИИ/УФК по Новосибирской области г. Новосибирск, к/c 40102810445370000043

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

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, обл. Новосибирская, г.о. город Новосибирск, г. Новосибирск, пр-кт Красный, зд. 42А

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

Размер обеспечения исполнения контракта: 321 048,00 Российский рубль (10 %)

Порядок предоставления обеспечения исполнения контракта, требования к обеспечению: Обеспечение исполнения контракта предоставляется участником закупки в соответствии со ст. 96 Федерального закона от 05.04.2013 №44-ФЗ.Антидемпинговые меры применяются в соответствии со ст. 37 Федерального закона о 05.04.2013 №44-ФЗ.Условия независимой гарантии установлены в соответствии со ст. 45 Федерального закона от 05.04.2013 №44-ФЗ.

Платежные реквизиты для обеспечения исполнения контракта: p/c 03272643500000095100, л/c 05515035790, БИК 015004950, СИБИРСКОЕ ГУ БАНКА РОССИИ/УФК по Новосибирской области г. Новосибирск, к/c 40102810445370000043

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

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

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

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

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

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

Срок исполнения контракта: 56  рабочих дней

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

Наименование бюджета: бюджет Территориального фонда обязательного медицинского страхования Новосибирской области

Вид бюджета: бюджет территориального государственного внебюджетного фонда

Код территории муниципального образования: 50000009: Муниципальные образования Новосибирской области / Территориальный фонд обязательного медицинского страхования

Документы

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

Документы

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