Без названия
Актуально на 04.11.2026.
Как цитировать: Без названия. https://bukva.ai/docs/bez-nazvaniya-4365
Документ 42758
ЕДИНАЯ ЦИФРОВАЯ ПЛАТФОРМА РОССИЙСКОЙ ФЕДЕРАЦИИ «ГосТех» ДЛЯ СОЗДАНИЯ, РАЗВИТИЯ И ЭКСПЛУАТАЦИИ
ГОСУДАРСТВЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ
1. Термины и определения
В настоящих методических рекомендациях применены следующие термины и сокращения с соответствующими определениями:
2. Общие положения
Основной целью создания ЕЦП «ГосТех» является высокая удовлетворенность Конечных пользователей при взаимодействии с государственными органами в электронном виде за счет сокращения сроков создания и развития ГИС на ЕЦП «ГосТех», а также повышения их доступности и надежности.
Для достижения поставленной цели ЕЦП «ГосТех» должна функционировать исходя из ряда основополагающих принципов, среди которых: принцип открытости, обеспечивающий недискриминационный доступ поставщиков цифровых продуктов на ЕЦП «ГосТех», а также возможность их участия в обсуждении проектов методических рекомендаций по функционированию ЕЦП «ГосТех», содержащих требования к цифровым продуктам и поставщикам, и принцип переиспользования, обеспечивающий механизмы повторного использования типовых программных компонентов ГИС и цифровых продуктов ЕЦП «ГосТех».
Эти два принципа определяют, что ЕЦП «ГосТех» развивается как расширяемая платформа, которая в соответствии с потребностями Клиентов допускает наращивание своей базовой функциональности путем включения в состав ЕЦП «ГосТех» новых Сервисов, а также путем расширения функциональности Сервисов, входящих в состав ЕЦП «ГосТех».
Сервисы, расширяющие ЕЦП «ГосТех», должны соответствовать следующим основополагающим принципам ЕЦП «ГосТех»:
принцип клиентоцентричности: создание и развитие Сервисов, входящих в состав ЕЦП «ГосТех», должно быть нацелено на эффективное удовлетворение потребностей Конечных пользователей с применением современных методов проектирования;
принцип оплаты фактического объема потребления: оплата потребления цифровых продуктов ЕЦП «ГосТех» осуществляется преимущественно по факту их потребления по цене, определяемой в зависимости от используемых ресурсов в соответствии с каталогом цифровых продуктов ЕЦП «ГосТех» и едиными требованиями к качеству цифровых продуктов;
принцип масштабируемости: Сервисы, входящие в состав ЕЦП «ГосТех», должны обеспечивать требуемую отказоустойчивость и производительность при изменении количества ГИС на ЕЦП «ГосТех», пользователей, цифровых продуктов, транзакций, а также объема обрабатываемых данных в соответствии с соглашением об уровне качества обслуживания;
принцип адаптируемости: Сервисы, входящие в состав ЕЦП «ГосТех», должны обеспечивать возможность непрерывного совершенствования функциональности при изменении законодательства Российской Федерации и развитии информационных технологий;
принцип импортозамещения: Сервисы, входящие в состав ЕЦП «ГосТех», должны соответствовать требованиям действующего законодательства Российской Федерации в области импортозамещения;
принцип доверия: ЕЦП «ГосТех» обеспечивает соответствие требованиям законодательства Российской Федерации в области информационной безопасности, в том числе конфиденциальность и целостность информации, недопущение несанкционированных действий, в частности, использование, раскрытие, искажение, изменение, исследование, уничтожение информации.
3. Область применения
Настоящие методические рекомендации устанавливают требования к Сервисам, предоставляемым Поставщиками, для включения их в состав ЕЦП «ГосТех» в качестве расширения базовых сервисов платформы с целью развития ее функциональности в соответствии с потребностями Пользователей ЕЦП «ГосТех». Базовые сервисы ЕЦП «ГосТех» описаны в отдельных методических рекомендациях: «ЕЦП ГосТех. Базовые сервисы. Основные требования к составу и функциям».
Данные методические рекомендации описывают обязательные требования, предъявляемые к каждому Сервису, который планируется включить в ЕЦП «ГосТех», а также к Поставщику. В случае несоответствия Сервиса или Поставщика предъявляемым требованиям включение Сервиса в ЕЦП «ГосТех» до устранения выявленных недостатков не допускается. Настоящие методические рекомендации распространяются как на сами Сервисы, так и на все Компоненты, входящие в состав этих Сервисов и являющиеся их частью.
Список Сервисов, входящих в состав ЕЦП «ГосТех», публикуется и актуализируется на официальном сайте ЕЦП «ГосТех» [1].
Порядок включения поставщика и Сервиса в ЕЦП «ГосТех» будет утвержден Министерством цифрового развития, связи и массовых коммуникаций Российской Федерации.
В настоящих методических рекомендациях рассматриваются следующие виды Сервисов:
1. Сервисы, являющиеся частью или модулем какой-либо информационной системы, разрабатываемой в рамках государственного контракта, которые можно переиспользовать при создании новых ГИС (далее — Сервис ГК). В основном это сервисы, реализующие типовые прикладные задачи ГИС, например, интеграция с системой уведомлений Единого портала государственных услуг (ЕПГУ). Сервисы данного типа поставляются в виде исходного кода с использованием Национального фонда алгоритмов и программ [2].
2. Сервисы, разработанные Поставщиками, поставляемые в виде дистрибутивов без передачи исключительных прав. Данные сервисы размещаются у облачного провайдера «ГосТех» и предоставляются Пользователю ЕЦП «ГосТех» из каталога ЕЦП «ГосТех». Примеры таких сервисов: Postgres Pro, Tarantool, AntiDDOS и т.д. (далее — Сервисы вендоров).
3. Сервисы, которые Поставщик предоставляет Конечным пользователям в виде готовых облачных SaaS-решений через простые web-интерфейсы, при этом Поставщик обеспечивает работоспособность Сервиса. Например, «Дневник.ру», «Мой Спорт» и т.д. Такие сервисы должны быть размещены в облачной инфраструктуре ЕЦП «ГосТех». Размещение сервисов данного вида в облачной инфраструктуре сторонних облачных провайдеров должно быть одобрено межведомственной рабочей группой по архитектуре базовых информационных ресурсов и принципам обработки данных состав которой утвержден Заместителем Председателя Правительства Российской Федерации Д.Н. Чернышенко 17.11.2021 (далее — МРГ по архитектуре). Сервисы данного типа имеют дополнительные требования, описанные в разделе 9 (далее — Публикуемые SaaS).
4. Требования к поставщику
Поставщик должен соответствовать следующим требованиям:
-
наличие общей и специальной гражданской правоспособности в полном объеме для заключения и исполнения государственного контракта (договора) по использованию Сервиса;
-
наличие лицензий на осуществление отдельных видов деятельности, в случаях если деятельность по созданию Сервиса подлежит лицензированию в соответствии с требованиями законодательства Российской Федерации;
-
непроведение ликвидации юридического лица и отсутствие решения арбитражного суда о признании юридического лица несостоятельным (банкротом) и об открытии конкурсного производства;
-
неприостановление деятельности юридического лица в порядке, установленном Кодексом Российской Федерации об административных правонарушениях;
-
отсутствие у юридического лица недоимки по налогам, сборам, задолженности по иным обязательным платежам в бюджеты бюджетной системы Российской Федерации (за исключением сумм, на которые предоставлены отсрочка, рассрочка, инвестиционный налоговый кредит в соответствии с законодательством Российской Федерации о налогах и сборах, которые реструктурированы в соответствии с законодательством Российской Федерации, по которым имеется вступившее в законную силу решение суда о признании обязанности заявителя по уплате этих сумм исполненной или которые признаны безнадежными к взысканию в соответствии с законодательством Российской Федерации о налогах и сборах) за прошедший календарный год, размер которых превышает двадцать пять процентов балансовой стоимости активов юридического лица, по данным бухгалтерской отчетности за последний отчетный период. Юридическое лицо считается соответствующим установленному требованию в случае, если им в установленном порядке подано заявление об обжаловании указанных недоимки, задолженности и решение по такому заявлению на дату рассмотрения заявки на включение Сервиса в ЕЦП «ГосТех» не принято;
6) отсутствие у руководителя юридического лица, членов коллегиального исполнительного органа, лица, исполняющего функции единоличного исполнительного органа, или главного бухгалтера юридического лица судимости за преступления в сфере экономики и (или) преступления, предусмотренные статьями 289, 290, 291, 291.1 Уголовного кодекса Российской Федерации (за исключением лиц, у которых такая судимость погашена или снята), а также неприменение в отношении указанных физических лиц наказания в виде лишения права занимать определенные должности или заниматься определенной деятельностью, которые связаны с поставкой товара, выполнением работы, оказанием услуги, являющихся объектом осуществляемой закупки, и административного наказания в виде дисквалификации;
7) отсутствие привлечения юридического лица к административной ответственности за совершение административного правонарушения, предусмотренного статьей 19.28 Кодекса Российской Федерации об административных правонарушениях, в течение двух лет до момента подачи заявки на включение в ЕЦП «ГосТех»;
8) обладание Поставщиком интеллектуальными правами на результаты интеллектуальной деятельности (Сервис и его компоненты);
- юридическое лицо не является офшорной компанией, не имеет в составе участников (членов) корпоративного юридического лица или в составе учредителей унитарного юридического лица офшорной компании, а также не имеет офшорных компаний в числе лиц, владеющих напрямую или косвенно (через юридическое лицо или через несколько юридических лиц) более чем десятью процентами голосующих акций хозяйственного общества либо долей, превышающей десять процентов в уставном (складочном) капитале хозяйственного товарищества или общества;
- отсутствие информации о юридическом лице в реестрах недобросовестных поставщиков (подрядчиков, исполнителей), предусмотренных Федеральным законом от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» и Федеральным законом от 18.07.2011 № 223-ФЗ «О закупках товаров, работ, услуг отдельными видами юридических лиц».
Правительством Российской Федерации могут быть утверждены дополнительные требования к Поставщикам, в том числе к наличию:
-
на праве собственности или ином законном основании оборудования и других материальных ресурсов, лицензий на используемое инструментальное ПО и библиотеки;
-
необходимого количества специалистов и иных работников определенного уровня квалификации.
5. Требования к поставке
Поставка Сервиса должна включать:
Спецификацию ресурсных потребностей;
Сертификаты соответствия (при наличии);
Список зависимостей (при наличии).
5.1 Требования к дистрибутиву
Дистрибутив должен иметь средства, подтверждающие отсутствие несанкционированных изменений. Подтверждение отсутствия фактов внесения несанкционированных изменений в дистрибутив осуществляется посредством сравнения контрольной суммы (ГОСТ Р 34.11-2012) переданного экземпляра дистрибутива и контрольной суммы (ГОСТ Р 34.11-2012) этого дистрибутива, указанной в документации на поставку.
Требование не применимо к Сервисам типа: Публикуемые SaaS.
5.2 Требования к скриптам развертывания
Для разворачивания и конфигурирования Сервисов должна использоваться система управления конфигурациями, совместимая с системой с открытым исходным кодом — Ansible [3]. В состав поставки Сервиса должны входить параметризованные скрипты развертывания в формате Ansible playbook.
Скрипты подготовки инфраструктуры для Сервиса должны соответствовать стандарту по управлению динамической инфраструктурой ЕЦП «ГосТех» [1].
Требование не применимо к Сервисам типа: Публикуемые SaaS.
5.3 Требования к документации
Проектная и рабочая документация на Сервис должна содержать следующую информацию:
А) Назначение сервиса, перечень основных функций, выполнение которых обеспечивает сервис.
Б) Описание сервиса, в том числе:
Архитектурные схемы, описывающие состав и функционирование Сервиса;
Максимальный уровень возможной доступности и необходимые для этого условия.
В) Системные требования (требования к аппаратному и программному обеспечению среды функционирования), в том числе:
Спецификация ресурсных потребностей;
Методика расчета требуемых аппаратных ресурсов на основании целевых показателей нагрузки.
Г) Порядок установки (разворачивания) сервиса.
Д) Настройка и конфигурирование.
Е) Перечень информационных ресурсов и разрешенных операций с этими ресурсами (матрица доступа), доступ к которым должен обеспечиваться средствами управления доступом ЕЦП «ГосТех»;
Ж) Перечень бизнес-метрик мониторинга для их учета средствами мониторинга ЕЦП «ГосТех».
З) Перечень событий аудита для их учета средствами аудита ЕЦП «ГосТех».
И) Регламент по эксплуатации Сервиса, включающий инструкцию по выполнению типовых операций по обслуживанию:
Резервное копирование и восстановление из резервной копии.
К) Документ «Программа и методика приемочных испытаний» содержит следующий раздел:
Набор функциональных тестов на тестовом наборе данных и минимально необходимый комплект тестовых данных, на основании которых принимается решение о соответствии заявленной функциональности Сервиса реально имеющейся.
Л) Документы по информационной безопасности в соответствии с п. 10.
Для Сервисов типа: Публикуемые SaaS, требования к документации ограничиваются описанием сервиса (назначение, перечень основных функций, выполнение которых обеспечивает сервис) и руководством пользователя.
5.4 Требования к манифесту Сервиса
Основным назначением манифеста является предоставление основных характеристик Сервиса в структурированном машиночитаемом формате. Манифест поставляется в виде файла — manifest.yaml, оформленного с использованием открытого формата разметки: YAML [4]. Формат файла-манифеста описан в Приложении 1.
Файл-манифест используется различными информационными системами, такими как: производственный конвейер ЕЦП «ГосТех», портал самообслуживания ЕЦП «ГосТех», информационный портал «ГосТех» и другими для отображения основных характеристик Сервиса в графических интерфейсах соответствующих систем.
Манифест содержит следующую информацию о Сервисе:
5.4.1 Описание сервиса
Описание Сервиса должно предоставлять информацию, достаточную для идентификации решаемой сервисом задачи: наименование (манифест: раздел name), версию (version), краткое описание (description), категорию Сервиса (categories) и ключевые слова, описывающие Сервис (keywords).
5.4.2 Информация о лицензировании
В разделе license должны быть представлены сведения об условиях использования и распространения Сервиса в составе ЕЦП «ГосТех».
5.4.3 Спецификации ресурсных потребностей
Документация Сервиса должна включать методику расчета требуемых аппаратных ресурсов (физические или виртуальные ядра процессора, частота процессора, размер оперативной памяти, размер и скорость доступа к дисковой памяти) на основании целевых показателей нагрузки Сервиса, таких как: количество запросов в секунду, количество пользователей, количество одновременных транзакций с данными в единицу времени, количество входящих или исходящих данных в единицу времени (мегабайты в секунду) и т.п.
В манифесте необходимые Сервису ресурсы описываются в разделе: resources, при этом имеется возможность указать эти потребности для одного из двух вариантов конфигурирования сервиса: исходя из его показателей нагрузки, например, количество пользователей, количество транзакций в секунду (раздел business-metrics), либо исходя из непосредственного конфигурирования необходимых ресурсов (раздел nodes).
5.4.4 Обеспечение согласованного уровня предоставления услуги
Данный раздел включает требования к уровню предоставления услуги, с предоставлением следующей информации:
Непрерывность услуги, включая конкретные параметры метрик, таких как среднее время восстановления, среднее время между отказами и иные;
Состав участников и зоны их ответственности для обеспечения предоставления услуги;
Требования к зависимым сервисам и оборудованию по обеспечению доступности, надежности и производительности предоставления услуги;
Регламент обработки обращений, связанных со снижением или отсутствием факта предоставления услуги, в том числе с учетом взаимодействия с другими сервисами;
Схема и правила эскалации обращений;
Условия и сроки профилактических и регламентных работ;
Регламент резервного копирования и восстановления данных;
Предоставление данных для контроля факта предоставления услуги.
Раздел должен содержать информацию относительно состава участников и зон их ответственности, состава услуг и ключевых показателей технической поддержки в соответствии с Приложением 2, а также способах коммуникаций при оказании технической поддержки (блок технической поддержки в манифесте support), а также описание технологических операций, с указанием состава исполнителей, надзора, продолжительности работ и плана действий с делением на операции.
Для оказания технической поддержки в рамках ЕЦП «ГосТех» выделяются следующие линии сопровождения:
1 линия — обработка обращений от Пользователей ЕЦП «ГосТех», передача обращений техническим специалистам;
2 линия — консультация, настройка, составление технической документации;
3 линия — системное сопровождение, устранение ошибок в работе сервиса.
Для Сервисов вендора должно быть обеспечено как минимум оказание 1 и 3 линий технической поддержки со стороны Поставщика.
Для Публикуемых SaaS сервисов со стороны Поставщика должно быть обеспечено оказание всех трех линий технической поддержки.
Требования по доступности должны предоставлять информацию о максимальном времени доступности услуги и допустимом времени недоступности, а также условиях, обеспечивающих заданные уровни.
Требования по надежности должны предоставлять информацию об обеспечении предоставления согласованного уровня услуги при перечисленных условиях за указанный промежуток времени.
Требования по производительности должны предоставлять информацию о показателях производительности, обеспечивающих предоставление согласованного уровня услуги.
Для обеспечения контроля факта предоставления согласованного уровня услуги поставщик должен предоставлять следующую информацию:
Количество нерешенных обращений на начало периода;
Количество поступивших за период обращений;
Количество решенных за период обращений;
Количество обращений, перешедших в следующий период;
Процент обращений, решенных за период в соответствии с SLA;
Процент обращений, решенных за период с нарушением SLA;
Количество зарегистрированных проблем;
Перечень зарегистрированных запросов на изменение;
Перечень решенных запросов на изменение.
Сервисы ГК поставляются без предоставления технической поддержки.
Указанные варианты технической поддержки будут влиять на возможность использования Сервиса в информационных системах разного класса.
Возможность обновления Сервиса без остановки его работы и без влияния на эксплуатационные характеристики Сервиса указывается в разделе манифеста — zero_downtime_upgrade.
Возможность горизонтального масштабирования Сервиса в автоматизированном режиме указывается в разделе манифеста — autoscaling.
Использование при разработке сервиса конвейера безопасной разработки ЕЦП «ГосТех» указывается в разделе манифеста — devsecops.
5.4.5 Сертификаты соответствия (при наличии)
Наличие у Сервиса сертификатов соответствия указывается в манифесте, раздел certification. Для каждого сертификата указываются следующие параметры:
Наименование программного обеспечения/средства (cert-software-name);
Система сертификации (cert-system);
Орган по сертификации (cert-org);
Номер сертификата (cert-number);
Наименование документов, требованиям которых соответствует (cert-doc);
Производитель (cert-software-vendor);
Значение полей заполняются на основании данных в сертификате соответствия.
5.4.6 Параметры конфигурации
Сервис может определить параметры своей конфигурации в раздел манифеста config. Данные параметры будут использоваться в административном интерфейсе портала самообслуживания ЕЦП «ГосТех».
5.4.7 Список зависимостей
Полный состав сервисов и их версий, не входящих в поставку добавляемого сервиса на ЕЦП «ГосТех», но влияющих на установку, настройку или использование, должен быть указан в манифесте (раздел: dependencies).
6. Требования к Сервису
Сервис должен быть включен в Единый реестр российских программ для электронных вычислительных машин и баз данных, исключение составляют Сервисы ГК.
Сервис и все его компоненты должны быть совместимы, по крайней мере, с одной из операционных систем на базе Linux, внесенных в Единый реестр российских программ для электронных вычислительных машин и баз данных.
6.1 Требования к надежности
Должно быть предусмотрено сохранение работоспособности Сервиса при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Сервиса (отказ рабочей станции, потеря сетевого доступа и т.п.).
Сервис должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации Сервиса.
6.2 Требования к доступности
В документации Сервиса должен быть указан максимальный уровень доступности, который Сервис может обеспечить, а также необходимые для этого условия.
Доступность измеряется в процентах и рассчитывается по формуле:
- СВД — согласованное время доступности Сервиса;
- ВН — время недоступности Сервиса (на основании зарегистрированных обращений оператора информационной системы в период ее эксплуатации).
Значение доступности Сервиса должно быть не менее 97%.
Указанные параметры максимальной доступности Сервиса будут влиять на возможность его использования в информационных системах разного класса. Например, требования к доступности должны соответствовать значениям:
- для информационных систем класса К1 — не менее 99,9%;
- для информационных систем класса К2 и менее — не менее 97%.
6.3 Требования по диагностируемости
Сервис и его компоненты должны обеспечивать диагностику своей работоспособности путем передачи журналов и метрик в централизованную систему диагностики ЕЦП «ГосТех». Передаваемой информации должно быть достаточно для однозначной локализации уже произошедших ошибок или потенциальных проблем. Информация, поступающая от Сервиса в систему диагностики, должна позволять однозначно указать элемент или группу элементов согласно спецификации развертывания, в которой произошли ошибки или в ближайшее время прогнозируются ошибки при нарушении установленных диапазонов значений для метрик мониторинга.
Записи журнала должны передаваться с использованием REST или gRPC API системы диагностики ЕЦП «ГосТех» в формате плоского JSON и содержать следующий минимальный набор полей:
Уровень логирования должен конфигурироваться и поддерживать следующие значения:
DEBUG — логирование всех видов событий;
INFO — логирование ошибок, предупреждений и сообщений;
WARN — логирование ошибок и предупреждений;
ERROR — логирование всех ошибок.
Для определенных уровней логирования должна быть возможность настроить передачу исчерпывающей информации обо всех действиях потребителей Сервиса (внесение, изменение, удаление и т.п.) в отношении всех объектов данных, с которыми работает Сервис.
Для осуществления сбора, обработки и пересылки лог-сообщений рекомендуется использовать сервис fluent-bit (https://docs.fluentbit.io/manual) — кроссплатформенное решение по сбору, обработке и маршрутизации логов с открытым исходным кодом. Может использоваться в качестве агента на уровне сервера и агента на уровне pod.
Требования по передаче событий мониторинга:
Система диагностики ЕЦП «ГосТех» предоставляет для Сервиса два режима передачи событий мониторинга: режим pull и push. Сервис может использовать любой из этих режимов или сразу оба;
Для использования режима pull Сервис должен выставить специфицированное API, по которому система диагностики ЕЦП «ГосТех» будет осуществлять сбор метрик Сервиса с заданной периодичностью. Выставление метрик Сервиса (pull) должно осуществляться в формате Prometheus [5]. У Сервиса должен быть выставлен HTTP метод, который возвращает метрики, а также в случае публикации в Kubernetes в Сервисе в аннотациях должен быть указан порт и адрес для получения метрик у сервиса.
Для использования режима push Сервис должен самостоятельно вызывать REST или gRPC API системы диагностики ЕЦП «ГосТех» и передавать информацию по своим метрикам.
Обязательным набором метрик является:
Метрики использования системных ресурсов (CPU, RAM, Memory);
Время исполнения входящих запросов;
Количество успешных/неуспешных выполнений входящих запросов;
Время исполнения исходящих запросов или обращений к СПО;
Количество успешных/неуспешных выполнений исходящих запросов или обращений к СПО.
6.4 Требования по управлению пользователями
Сервис и его компоненты должны использовать один из протоколов: OpenID Connect 1.0, SAML 2.0, Kerberos, LDAP.
В Сервисе должна быть разработана ролевая модель и загружена в IAM ЕЦП «ГосТех» через интерфейс администрирования, либо при разворачивании или запуске сервиса с привилегированным доступом по одному из доступных протоколов.
Если Сервис предполагает подключение Конечных пользователей, он должен позволять осуществлять их идентификацию и аутентификацию через сервис IAM с использованием учетных записей единой системы идентификации и аутентификации (ЕСИА).
6.5 Требования к API
API Сервиса должен обеспечивать обратную совместимость, в том числе за счет поддержки механизмов версионирования. В случае необходимости внести в API изменения, нарушающие обратную совместимость, новая версия Сервиса рассматривается как новый Сервис и должна удовлетворять всем требованиям данных методических рекомендаций.
7. Требования к юридическому оформлению
7.1 Право использования Сервиса передается по лицензионному договору. Пределы прав и способы использования Сервиса, предусмотренные лицензионным договором, должны обеспечивать возможность подключения Конечных пользователей на весь период использования соответствующих ГИС на ЕЦП «ГосТех» на территории Российской Федерации без необходимости приобретения Пользователем ЕЦП «ГосТех» дополнительных пользовательских, серверных, процессных или других лицензий.
Поставщик Сервиса обязан передать права на использование охраняемых результатов интеллектуальной деятельности Пользователю ЕЦП «ГосТех» в объеме, необходимом для использования Сервиса Пользователем ЕЦП «ГосТех» в соответствии с назначением ГИС на ЕЦП «ГосТех». Ситуативно в объем передаваемых прав могут быть включены права на адаптацию и/или модификацию. Исключительные права на результаты работ, полученные при использовании Сервиса, подлежат передаче Пользователю ЕЦП «ГосТех».
При использовании в составе Сервиса программ (программных комплексов или компонентов), разработанных третьими лицами, условия, на которых передается право на использование (исполнение) этих программ, не должны накладывать ограничений, препятствующих использованию Сервиса по его прямому назначению. Программы для ЭВМ третьих лиц, как подразумевающие, так и не подразумевающие свободное использование, должны быть обеспечены гарантийным обслуживанием Поставщика.
7.2 Поставщик должен обеспечить приоритет применения программного обеспечения российского производства или свободного распространяемого ПО в соответствии с постановлением Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд» [6].
8. Дополнительные требования к Сервисам, созданным в рамках государственного контракта (Сервисы ГК)
Сервис, созданный в рамках государственного контракта, должен быть размещен в Национальном фонде алгоритмов и программ для электронных вычислительных машин (далее — НФАП).
Сервис ГК должен быть отчуждаем от ИС, в рамках которой он был изначально создан. Сервис ГК должен разворачиваться как самостоятельная единица с сохранением всей документированной функциональности.
Комплект поставки Сервиса ГК должен соответствовать требованиям для регистрации сервиса в НФАП согласно требованиям Методических указаний о порядке формирования и использования информационного ресурса национального фонда алгоритмов и программ для электронных вычислительных машин, утвержденных приказом Министерства связи и массовых коммуникаций Российской Федерации от 16.09.2013 № 248 [7].
Для Сервиса ГК Поставщиком проводится формирование комплекта документации (материалов) для последующего оформления интеллектуальных и имущественных прав на результаты работ по созданию/развитию Системы, а также объектов НФАП, предусмотренных Положением о национальном фонде алгоритмов и программ для электронных вычислительных машин, утвержденным постановлением Правительства Российской Федерации от 30.01.2013 № 62 [8] и Положением о федеральной государственной информационной системе координации информатизации, утвержденным постановлением Правительства Российской Федерации от 14.11.2015 № 1235 [9].
Для Сервиса ГК состав документации должен соответствовать требованиям по подготовке комплекта документов, необходимых для последующей регистрации Сервиса ГК в НФАП, согласно требованиям Методических указаний о порядке формирования и использования информационного ресурса национального фонда алгоритмов и программ для электронных вычислительных машин, утвержденных приказом Министерства связи и массовых коммуникаций Российской Федерации от 16.09.2013 № 248.
Сервис ГК должен быть реализован на рекомендованном технологическом стеке. Данный технологический стек определяется возможностями сборки Сервисов ГК на конвейере разработки ЕЦП «ГосТех» с автоматизированными проверками качества и безопасности кода:
C/C++ — компилируемый статически типизированный язык программирования общего назначения;
C# — объектно-ориентированный язык программирования для платформы .NET Core;
Groovy — объектно-ориентированный язык программирования, дополнение к языку Java;
Java — строго типизированный объектно-ориентированный язык программирования общего назначения;
JavaScript — мультипарадигменный встраиваемый язык программирования;
PL/pgSQL — процедурное расширение языка SQL, используемое в СУБД PostgreSQL;
Python — высокоуровневый язык программирования общего назначения с динамической строгой типизацией и автоматическим управлением памятью;
Scala — мультипарадигменный язык программирования;
Ruby — интерпретируемый высокоуровневый язык программирования с открытым исходным кодом;
Perl — высокоуровневый интерпретируемый динамический язык программирования общего назначения;
Go — мультиплатформенный компилируемый язык;
Shell — язык написания скриптов в ОС семейства Linux;
Lua — скриптовый язык программирования.
HTML — стандартизированный язык разметки для браузеров;
XML — расширяемый язык разметки.
JSON — текстовый формат обмена данными, основанный на JavaScript;
YAML — формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования;
TOML — формат конфигурационных файлов, спроектированный для обеспечения человеко-читаемости, с одной стороны и однозначного преобразования в ассоциативный массив, с другой.
HiveQL — язык запросов на основе SQL для Apache Hive;
SQL — язык структурированных запросов к реляционным данным;
SPARQL — язык структурированных запросов к графам в формате RDF;
XPATH — язык структурированных запросов данным в формате XML.
Комплект поставки Сервиса ГК должен позволять Оператору ЕЦП «ГосТех» произвести успешную сборку Сервиса ГК из исходных кодов, переданных Поставщиком, развертывание Сервиса ГК и проведение всех необходимых тестов в соответствии с «Программа и методика приемочных испытаний» п. 5.3-К.
9. Дополнительные требования к Сервисам типа: Публикуемые SaaS
В отличие от Сервисов, предназначенных для переиспользования в ГИС на ЕЦП «ГосТех», готовые облачные решения/сервисы (SaaS) предназначены для использования Конечными пользователями, а также уполномоченными лицами органов исполнительной власти. Взаимодействие пользователей с такими сервисами должно осуществляться посредством Web-интерфейса (далее — Интерфейс пользователя).
Все надписи Интерфейса пользователя, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке.
Готовые облачные сервисы должны обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях пользователю должны выдаваться соответствующие сообщения, после чего сервис должен возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.
При разработке готовых облачных сервисов рекомендуется руководствоваться Методическими рекомендациями по совершенствованию пользовательских интерфейсов, утвержденными приказом Министерства связи и массовых коммуникаций Российской Федерации от 16.10.2015 № 405 и Методическими рекомендациями по информированию граждан о преимуществах получения государственных и муниципальных услуг в электронной форме, утвержденными Протоколом заседания подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 14.10.2015 № 406пр.
Адаптация или настройка готовых облачных сервисов должна осуществляться с помощью конфигурации, доступной через Интерфейс пользователя.
Готовый облачный сервис должен предоставлять государственным органам возможность бесплатного предварительного ознакомления с функциональностью сервиса в объеме, достаточном для осуществления обоснованного выбора сервиса и его закупки.
Готовый облачный сервис должен позволять осуществлять идентификацию и аутентификацию Конечных пользователей сервиса через единую систему идентификации и аутентификации (ЕСИА).
10. Требования по защите информации
10.1 Базовые требования
Разработка Сервиса, включаемого в состав ЕЦП «ГосТех», должна проводиться с учетом общих требований к содержанию и порядку выполнения работ, связанных с созданием безопасного (защищенного) программного обеспечения, а также формированием (поддержанием) среды обеспечения оперативного устранения выявленных ошибок программного обеспечения и уязвимостей в соответствии с требованиями ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» (далее — ГОСТ Р 56939-2016).
В отношении предоставляемого Поставщиком Сервиса должен быть проведен анализ уязвимостей по требованиям к оценочному уровню доверия (далее — ОУД) в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности», утвержденного приказом Федерального агентства по техническому регулированию и метрологии от 08.11.2013 № 1340-ст.
В качестве подтверждения соответствия вышеуказанным требованиям Поставщик Сервиса может предоставить заверенную в установленном порядке копию одного из следующих документов:
- сертификат соответствия по требованиям безопасности информации ФСТЭК России;
- заключение испытательной лаборатории об оценке соответствия прикладного программного обеспечения Сервиса требованиям к оценочному уровню доверия;
- оценку соответствия реализованных Поставщиком мер по разработке безопасного программного обеспечения с приложением результатов проведенных испытаний по выявлению уязвимостей в программном обеспечении Сервиса.
В соответствии с требованиями приказов ФСТЭК России от 11.02.2013 № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», от 03.04.2018 № 55 «Об утверждении Положения о системе сертификации средств защиты информации», Сервисы, реализующие функционал средств защиты информации, должны быть сертифицированы на соответствие требованиям по безопасности информации, установленным нормативными правовыми актами ФСТЭК России, а также техническими условиями, техническим заданием, заданием по безопасности, согласованными заявителями на сертификацию с ФСТЭК России.
Все применяемые средства криптографической защиты информации должны соответствовать требованиям ФСБ России.
Вместе с этим, для усиления подсистемы защиты информации Сервисы должны соответствовать следующим основным требованиям:
- поддержка программного или аппаратного VPN с ГОСТ-шифрованием;
- возможность доступа к веб-консоли и API управления облачными ресурсами с использованием ГОСТ-TLS;
- обеспечение подлинности сетевых соединений (сеансов взаимодействия), в том числе для защиты от подмены сетевых устройств и сервисов.
10.2 Требования к поддержке безопасности программного обеспечения
Поставщик Сервиса обеспечивает реализацию:
процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения, входящего в состав ЕЦП «ГосТех»;
определение способов и сроков доведения разработчиком (производителем) программного обеспечения до оператора платформы и его пользователей информации об уязвимостях программного обеспечения, компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности;
наличие процедур информирования оператора Платформы и его пользователей об окончании поддержки программного обеспечения.
10.3 Требование к событиям аудита
Сервис и его компоненты должны осуществлять отправку событий безопасности, связанных с действиями пользователей в системе, в централизованный компонент аудита ЕЦП «ГосТех». События, которые необходимо отслеживать и передавать в аудит, прорабатываются на этапе проектирования информационной безопасности решения и проработки модели угроз.
События должны отправляться путем вызова REST или gRPC API централизованной системы аудита ЕЦП «ГосТех» с передачей следующих значений в теле запроса:
11. Уровни требований
Данные методические рекомендации определяют минимальный уровень требований к сервисам для включения их в каталог ЕЦП «ГосТех». В зависимости от выполнения дополнительных требований сервисы можно условно разделить на три уровня:
Требования к информационным системам при необходимости могут содержать минимальный уровень требований Сервисов, переиспользуемых в информационной системе.
В случае наличия идентичных сервисов, то есть сервисов, функциональность которых достаточна для решения конкретной задачи или для функционирования конкретного приложения, предпочтение оказывается базовым сервисам платформы, определенным в методических рекомендациях: «ЕЦП ГосТех. Базовые сервисы. Основные требования к составу и функциям», а при их отсутствии — сервисам, разработанным с использованием производственного конвейера ЕЦП «ГосТех».
Исключения для отдельных сервисов должны быть одобрены МРГ по архитектуре.
12. Библиография
| [1] | Официальный сайт ЕЦП «ГосТех» | Официальный сайт ЕЦП «ГосТех» https://platform.digital.gov.ru/ |
|---|---|---|
| [2] | Национального фонда алгоритмов и программ | https://portal.eskigov.ru/nfap/ |
| [3] | Ansible | https://docs.ansible.com/ansible/latest/index.html |
| [4] | YAML | https://github.com/yamlcss/yaml |
| [5] | Prometheus Text-based format | Формат метрик Prometheus, основанный на текстовом представлении данных https://github.com/prometheus/docs/blob/main/content/docs/instrumenting/exposition_formats.md |
| [6] | Постановление Правительства Российской Федерации от 16 ноября 2015 г. № 1236 | https://base.garant.ru/71252170/ |
| [7] | Приказ Министерства связи и массовых коммуникаций РФ от 16 сентября 2013 г. № 248 | Методические указания о порядке формирования и использования информационного ресурса национального фонда алгоритмов и программ для электронных вычислительных машин https://docs.cntd.ru/document/499047248?marker=6540IN |
| [8] | Постановление Правительства Российской Федерации от 30 января 2013 г. № 62 | https://base.garant.ru/70308380/ |
| [9] | Постановление Правительства Российской Федерации от 14 ноября 2015 г. № 1235 | https://base.garant.ru/71252176/ |
ФОРМАТ ФАЙЛА-МАНИФЕСТА ОПИСАНИЯ СЕРВИСА ПРИ ВКЛЮЧЕНИИ В ЕЦП «ГосТех»
id: ru.provider.service name: Service Name version: v1.0.0 homepage: https://service.provider.ru
Описание для карточки в каталоге
description: type: [string|markdown] value: [description|file path]
license: type: MIT link: url
Варианты категорий выдаются ГосТех
categories:
- «database»
- «algorithms»
- «analytics»
- «integration»
- «security»
- ...
Для поиска. Имеют более высокий приоритет, чем описание
keywords:
- some
- keywords
Документация. Включена в поставку или ссылка на сайт документации
поставщика docs: type: [markdown|link] path: [file path|url]
Спецификация ресурсных потребностей
resources: type: [business-metrics|nodes] nodes: — node: vcpu: value vcpu-freq: value ram: value disks: — speed: value # discuss: value or fixed list of values size: value network-bandwidth: value config: — name: param name display: param display name type: [string|number|list|radio|boolean] values: — list — of — values — for — array — elements business-metrics: — condition: — type: [tps|mbps-throughput|mbps-data-change|request-size-limit|etc ...] min: value max: value resources: vcpu: value vcpu-freq: value ram: value disks: — speed: value # discuss: value or fixed list of values size: value network-bandwidth: value # conditions specific config required-config: — name: param name display: param display name type: [string|number|list|radio|boolean] values: — list — of — values — for — array — elements
Параметры поддержки
support: phone: phone email: email web: url sla: med-latency: value max-response-time: value med-throughput: value description: description
Поддержка непрерывного обновления
zero_downtime_upgrade: [yes|no]
Поддержка автоматизированного горизонтального масштабирования
autoscaling: [yes|no]
Использование конвейера безопасной разработки ЕЦП «ГосТех»
devsecops: [platform]other|no]
Имеющиеся сертификаты
certification:
- cert-system: cert-org: cert-number: cert-data-from: cert-data-to: cert-doc: cert-software-vendor: cert-owner:
Общие параметры конфигурации
config:
- name: param name
display: param display name
type: [string|number|list|radio|boolean]
values:
- list
- of
- values
- for
- array
- elements
Список зависимостей
dependencies:
- id: another service id in gostech version: v1.0.0
Скрипты
prepare — скрипты подготовки необходимого для сервиса окружения
install — скрипты инсталляции сервиса
healthcheck — скрипты проверки работоспособности сервиса
backup — скрипты резервного сохранения данных сервиса
restore — скрипты восстановления данных сервиса
uninstall — скрипты удаления сервиса
cleanup — скрипты очистки данных сервиса
scripts: prepare: — engine: [docker|helm|ansible|terraform] engine-specific-params: install: — engine: [docker|helm|ansible|terraform] engine-specific-params: healthcheck: — engine: [docker|helm|ansible|terraform] engine-specific-params: backup: — engine: [docker|helm|ansible|terraform] engine-specific-params: restore: — engine: [docker|helm|ansible|terraform] engine-specific-params: uninstall: — engine: [docker|helm|ansible|terraform] engine-specific-params: cleanup: — engine: [docker|helm|ansible|terraform] engine-specific-params:
Приложение 2
Пример целевых показателей по обработке обращений, классифицированных как инциденты:
Время реакции — это время ответа, которое не является временем выполнения обращения. Не позднее указанного срока Поставщик сервиса обязан представить Оператору ГИС или Конечному пользователю сервиса информацию о ходе исполнения заявки и прогноз времени, необходимого для его выполнения. Эта информация является исходной для согласования реального приоритета и срока выполнения обращения.
Время решения обращения определяется как разность моментов окончания и начала исполнения обращения, за вычетом времени ожидания от автора обращения дополнительной информации, необходимой для исполнения обращения.
Иллюстрации
\cdot
\cdot
\cdot
\cdot
\circ
\circ
\circ
\circ
\circ
\circ
\circ
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\circ
\circ
\circ
\circ
\cdot
\cdot
\cdot
\cdot
\circ
\circ
\circ
\circ
\circ
\cdot
\circ
\circ
\circ
\circ
\circ
\circ
\circ
\circ
\circ
\circ
\circ
\circ
\circ
\cdot
\circ
\circ
\cdot
\circ
\circ
\circ
\cdot
\circ
\circ
\circ
\circ
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot
\cdot