dedoc/tz_dataset huggingface dataset:
взаимодействия).
4.2.1.2.3 Требования к разработке системы динамического
изменения настроек СМЭВ без остановки работы СМЭВ
Для минимизации количества случаев, требующих перезагрузки
системы, необходимо обеспечить динамическое изменение ключевых
настроек СМЭВ без необходимости перезапуска системы в целом.
Время применения новых значений настроек может варьироваться от
одного часа до 24 часов – в зависимости от типа измененных параметров.
Список основных параметров приведен в Приложении №1 и может быть
изменен в ходе разработки технического проекта.
4.2.1.2.4 Разработка функционала полного асинхронного режима
обработки запросов
Для увеличения производительности и вертикальной масштабируемости
системы необходимо обеспечить функцию переключения работы системы в
режим полной асинхронной проверки входящих запросов (полный
асинхронный режим).
При полном асинхронном режиме входящие запросы должны сразу
помещаться в асинхронную очередь СМЭВ3.х. Асинхронная очередь – это
организованная очередь запросов СМЭВ3.x, ожидающих прохождения
процедур асинхронных проверок. В случае полного асинхронного режима все
обязательные проверочные процедуры запросов СМЭВ3.x выполняются в
асинхронном режиме.
Система может работать в двух режимах:
- Полный асинхронный режим.
- Синхронный с переводом обработки запросов в асинхронный режим
по событию.
Режим определяется параметрами Системы.
Список событий переключения должен быть определен в ходе
разработки технического проекта.
4.2.1.2.5 Разработка функционала push-уведомлений о наличии
сообщений во входящей очереди сообщений
Для снижения нагрузки на каналы СМЭВ3.х и упорядочивания
взаимодействия информационных систем участников взаимодействия с
СМЭВ3.х необходимо разработать функционал push-уведомлений о наличии
сообщений во входящих очередях сообщений.
Для приема push-уведомлений на стороне информационных систем
организуется сервис заданной конфигурации. Адрес сервиса регистрируется в
СМЭВ3.х при регистрации информационной системы участника. При наличии
сообщений во входящей очереди ИС участника СМЭВ3.х направляет в адрес
сервиса ИС участника push-уведомление о наличии сообщений в очереди. При
получении push-уведомления участник взаимодействия может осуществить
чтение входящей очереди.
4.2.1.3 Требования к доработке подсистемы администрирования
4.2.1.3.1 Требование к доработке журнала СМЭВ
Для улучшения мониторинга системы и минимизации сроков
расследований инцидентов необходимо доработать Журнал СМЭВ
необходимо реализовать следующие требования:
1) Интеграция логов всех компонент СМЭВ3.x в пределах одного
геораспределенного узла в единой точке доступности. Данное
требование может быть реализовано путем создания единой БД
хранения логов компонент, либо другой централизованной
а) Конкретное решение должно быть проработано на этапе разработки
технического проекта.
2) Доработанная подсистема администрирования СМЭВ должна
предоставлять администраторам СМЭВ доработанный веб-интерфейс
Журнала СМЭВ на основе единой точки доступности логов СМЭВ.
3) Отдельно должны агрегироваться логи действий
администраторов по созданию/редактированию/удалению бизнес-
сущностей системы и по разграничению прав пользователей
(заведение пользователя, присвоение роли пользователю, заведение
ВС и ИС, и т.д.). СМЭВ в административной панели должны быть
выделы в отдельную панель Журнала СМЭВ.
Так же необходимо доработать механизм передачи данных о
функционировании СМЭВ в Ситуационный центр ИЭП для учета в СЦ новых
данных логирования.
В веб-интерфейсе Журнала СМЭВ должны выводиться основные
показатели СМЭВ, необходимые для мониторинга работы СМЭВ и
проведения расследований бизнес-процессов, включая:
1) сообщения об ошибках в работе компонентов СМЭВ;
2) агрегированные данные о транзакциях СМЭВ;
3) административные действия администраторов СМЭВ.
Детальный список отслеживаемых показателей должен быть определен
Доработанный Журнал СМЭВ должен позволять осуществлять
фильтрацию и поиск по своему содержимому, в том числе в разрезе
компонент СМЭВ.
4.2.1.3.2 Требование к переносу регистрационных данных между
средами СМЭВ
В целях минимизации ошибок при переносе регистрационных данных
между средами системы необходимо в рамках одного геораспределенного
узла реализовать функционал автоматизированной выгрузки/загрузки в файл
регистрационных данных по информационным системам и видам сведений,
что позволит осуществлять файловый перенос регистрационных данных
между средами СМЭВ.
При этом должна быть реализована защита от ошибок при загрузке
данных.
4.2.1.3.3 Требование к вводу параметров динамической настройки
работы СМЭВ
Для обеспечения функционала динамического изменения настроек
СМЭВ3.x в рамках одного геораспределенного узла необходимо доработать
панель ввода основных параметров настройки работы СМЭВ, а так же панель
настройки информационных систем, дополнив их формами ввода параметров
динамической настройки работы СМЭВ, реализованных в ходе доработки
транспортной подсистемы.
уточнен в ходе разработки технического проекта.
Для предотвращения ошибочного изменения настроек необходимо
реализовать расширенную систему предупреждений и восстановления
примененных настроек.
4.2.1.3.1 Требования к мониторингу работы узлов и компонент
СМЭВ3.х
Для улучшения мониторинга работоспособности компонентов системы в
рамках одного геораспределенного узла необходимо реализовать отдельную
панель мониторинга работоспособности компонент и узлов СМЭВ, и их
производительности.
4.2.1.4 Разработка единой системы генерации кодов транзакций в
рамках оказания государственных услуг и осуществления
государственных функций
Необходимо разработать единую систему генерации кодов транзакций в
рамках оказания ведомствами государственных услуг и исполнения
государственных функций.
Разрабатываемая система позволит получать в Ситуационном центре
расширенную аналитическую отчетность по предоставляемым ведомствами
услугам и выполняемым функциям – в разрезе количества и характеристик
запросов на каждую услугу или функцию.
Система позволит информационным системам, участвующим в оказании
государственных услуг и функций, получать уникальные коды транзакций
для дальнейшего включения полученных кодов в состав сообщений
(запрос/ответ) СМЭВ.
Использование системы предполагает обязательность включения кодов
транзакций во все сообщения СМЭВ.
Система должна представлять собой отдельное программное
обеспечение, на вход которого из информационных систем, участвующих в
оказании государственных услуг и выполнении государственных функций,
поступает либо код услуги ФРГУ (в случае оказания услуги), либо условный
запрос на предоставление уникального кода функции. В состав запроса может
опционально входить дополнительная информация, связанная с услугой или
функцией, в рамках которой производится запрос. Система, получив запрос, в
ответ возвращает уникальный код либо транзакции соответствующей услуги
или функции. Коды транзакций должны быть уникальны в рамках всего
объема кодов системы. При этом, под «транзакцией» понимается
совокупность всех сообщений СМЭВ в рамках предоставления одной
государственной услуги или осуществления одной государственной функции.
Выданные коды транзакций должны включаться в состав сообщений
(запрос/ответ) СМЭВ в рамках оказания соответствующей государственной
услуги или функции.
Данные о выданных кодах должны выгружаться в Ситуационный центр
вместе с соответствующей им дополнительной информацией.
4.3 Требования к видам обеспечения
4.3.1 Требования к математическому обеспечению системы
Дополнительные требования к математическому обеспечению системы
не предъявляются.
4.3.2 Требования к информационному обеспечению системы
Дополнительные требования по информационному обеспечению
4.3.3 Требования к лингвистическому обеспечению системы
Доработка существующих подсистем СМЭВ должна проводиться на
языке программирования, с помощью которого была разработана текущая
версия подсистемы.
При разработке новых подсистем предпочтение должно отдаваться
технологиям и языкам, уже использованным при реализации текущей версии
СМЭВ. Могут быть использованы технологии и языки, не применявшиеся
ранее при разработке СМЭВ, при условии обоснования преимуществ их
применения.
4.3.4 Требования к программному обеспечению системы
Дополнительные требования к программному обеспечению не
4.3.5 Требования к техническому обеспечению системы
Дополнительные требования к техническому обеспечению СМЭВ не
4.3.6 Требования к метрологическому обеспечению
Дополнительные требования к метрологическому обеспечению не
4.3.7 Требования к организационному обеспечению
4.3.7.1 Требования к структуре и функциям подразделений
Дополнительные требования к структуре и функциям подразделений не
4.3.7.2 Требования к организации функционирования системы
Дополнительные требования к организации функционирования системы
4.3.7.3 Требования к защите от ошибочных действий
В панели администрирования СМЭВ необходимо реализовать функции
защиты от случайных действий администратора, включая ввод настроек
СМЭВ, путем создания расширенной системы логического контроля,
предупреждений, подтверждений и отмены произведенных действий.
4.3.7.4 Требования к методическому обеспечению
По результатам работ должны быть подготовлены:
- проекты изменений в нормативно-правовые акты,
- методические рекомендации, регламентирующие межведомственное
взаимодействие через СМЭВ.
Список НПА подлежащих изменению должен быть определён во время
технического проектирования.
4.3.7.5 Требования к разработке комплекта документов для
аттестации (переаттестации) системы
На Этапе 4 работ должен быть сформирован пакет документов для
проведения аттестационных мероприятий СМЭВ, включающих подготовку
документации для получения аттестатов информационной безопасности на
СМЭВ. Перечень необходимых для аттестации документов будет уточнён на
этапе разработки ЧТЗ.
ВЗАИМОДЕЙСТВИЯ В ЧАСТИ МОДЕРНИЗАЦИИ СЕТИ СКЗИ
5.1 Полное наименование системы и её условное обозначение
Полное наименование системы: Модернизация системы
криптографической защиты информации инфраструктуры электронного
правительства.
Краткое наименование системы: СКЗИ, Система.
6 ТРЕБОВАНИЯ К СИСТЕМЕ
6.1 Требования к системе в целом
6.1.1 Требования к структуре и функционированию системы
6.1.1.1 Перечень подсистем, их назначение и основные
В рамках данного технического задания рассматривается подсистема
криптографической защиты информации для организации подключения к
системе «Электронное правительство», построенная на решениях следующих
поставщиков:
Кластеры в ФЦОД:
1. Решение поставщика «Код безопасности».
2. Решение поставщика «С-Терра СиЭсПи».
Кластеры в КЦОД:
Состав и комплектация оборудования, используемого в проведении
работ, определяется Исполнителем на основании требований к
производительности, отказоустойчивости и масштабируемости системы,
полученных от Заказчика.
6.1.1.2 Требования по номенклатуре используемых решений в
Организации при подключении абонентов ИЭП.
В Таблице 4 представлены рекомендации по выбору типа АПКШ
Континент в зависимости от количества используемых в подключаемой
организации сетевых узлов (АРМ, серверов, терминалов), обрабатывающих
подлежащую защите информацию:
Таблица 4 - Рекомендуемое оборудование в зависимости от
количества АРМ
В Таблице 5 представлены рекомендации по выбору типа CSP VPN Gate в
зависимости от количества используемых в подключаемой организации
сетевых узлов (АРМ, серверов, терминалов), обрабатывающих подлежащую
защите информацию:
Таблица 5 - Рекомендуемое оборудование в зависимости от
необходимую пропускную способность каналов связи.
В Таблице 6 представлены рекомендации по выбору типа АПКШ
Континент в зависимости от необходимой пропускной способности при
подключении Организации к ЗСПД:
Таблица 6 - Рекомендации по пропускной способности каналов связи
В Таблице 7 представлены рекомендации по выбору типа CSP VPN Gate в
зависимости от необходимой пропускной способности при подключении