=== ФАЙЛ: Приложение 1 ТЗ_СЭДО_р(002) | docs/0173100008626000034/Приложение 1 ТЗ_СЭДО_р(002).pdf
Приложение № 1 к Извещению
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на выполнение работ по развитию Системы электронного
документооборота Минэкономразвития России
Москва, 2026
 2
Содержание
1
ОБЩИЕ СВЕДЕНИЯ............................................................................................................. 4
1.1
Наименование объекта работ...................................................................................................................................4
1.2
Наименование работ................................................................................................................................................. 4
1.3
Заказчик..................................................................................................................................................................... 4
1.4
Исполнитель.............................................................................................................................................................. 4
1.5
Cроки выполнения работ..........................................................................................................................................4
1.6
Сведения об источниках и порядке финансирования работ.................................................................................5
1.7
Перечень нормативных правовых документов, стандартов и иных документов, которые должны быть
учтены при выполнении работ............................................................................................................................................5
1.8
Перечень терминов, сокращений и обозначений.................................................................................................10
1.9
Порядок оформления и предъявления результатов работ..................................................................................15
2
ЦЕЛИ И ЗАДАЧИ РАБОТ.................................................................................................. 18
2.1
2.2
Цели..........................................................................................................................................................................18
Задачи.......................................................................................................................................................................19
3
ХАРАКТЕРИСТИКА ОБЪЕКТА ВЫПОЛНЕНИЯ РАБОТ........................................21
3.1
3.2
3.3
3.4
Назначение и краткое описание Системы............................................................................................................ 21
Сведения о ранее заключенных контрактах.........................................................................................................23
Пользователи Системы...........................................................................................................................................23
Сведения о программном комплексе Системы....................................................................................................24
3.4.1
Подсистемы и компоненты..........................................................................................................................24
3.4.2
Перечень частей программного обеспечения............................................................................................26
3.5
Взаимодействие с внешними информационными системами............................................................................30
4
ТРЕБОВАНИЯ К РАБОТАМ.............................................................................................31
4.1
Требование к передаче прав и уровней доступа к Системе................................................................................31
4.2
Численность, квалификация персонала и режим его работы............................................................................. 31
4.3
Требования к характеристикам взаимосвязей Системы со смежными системами, требованиям к ее
совместимости.................................................................................................................................................................... 32
4.4
Требования к информационной безопасности.....................................................................................................32
4.5
Требования к Системе в целом..............................................................................................................................42
4.5.1
Требования к показателям назначения....................................................................................................... 42
4.5.2
Требования к надежности............................................................................................................................ 42
4.5.3
Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов........43
4.5.4
Требования к режимам функционирования............................................................................................... 44
4.5.5
Требования по сохранности информации при авариях............................................................................45
4.5.6
Требования к эргономике и технической эстетике...................................................................................46
4.5.7
Требования к информационному обмену между компонентами Системы............................................46
4.5.8
Требования к патентной чистоте.................................................................................................................47
4.5.9
Требования по стандартизации и унификации.......................................................................................... 47
4.6
Требования к видам обеспечений..........................................................................................................................47
4.6.1
Требования к организационному обеспечению.........................................................................................47
4.6.2
Требования к методическому обеспечению...............................................................................................48
4.6.3
Требования к лингвистическому обеспечению......................................................................................... 48
4.6.4
Требования к программному обеспечению................................................................................................48
4.7
Требования к функциям (задачам) по развитию Системы.................................................................................49
4.7.1
Требования к развитию (адаптации) функционала модуля МЭДО в части обмена данными с
глобальным адресным справочником (ГАС)................................................................................................................. 49
4.7.2
Требования к развитию (адаптации) функционала модуля МЭДО в части поддержки формата
обмена данными МЭДО 3.0.............................................................................................................................................50
 3
4.7.3
Требования к развитию (адаптации) функционала СЭДО в части обмена данными по событиям
цифровых поручений второй очереди............................................................................................................................ 51
4.7.4
Требования к развитию (адаптации) функционала СЭДО интеграции с сайтом Минэкономразвития
России в части передачи контактной информации структурного подразделения Министерства по запросу
юридического лица...........................................................................................................................................................52
4.7.5
Требования к развитию (адаптации) функционала СЭДО в части отправки одного исходящего
события по нескольким пунктам цифрового поручения..............................................................................................52
4.7.6
Требования к развитию (адаптации) функционала СЭДО в части автоматической простановки вида
контроля «ВК» по пунктам цифрового поручения, где Минэкономразвития России является соисполнителем. .53
4.7.7
Требования к развитию (адаптации) функционала СЭДО в части отображения подписанта
цифрового поручения в дереве резолюций РК.............................................................................................................. 53
4.7.8
Требования к развитию (адаптации) функционала СЭДО в части изменения последовательности
отображения значений в поле «Номер пункта» в резолюциях по событиям Цифровых поручений.......................54
4.7.9
Требования к развитию (адаптации) функционала СЭДО в части автоматического указания
Министра экономического развития Российской Федерации исполнителем по пунктам цифрового поручения. 54
4.7.10
Требования к развитию (адаптации) функционала СЭДО в части изменения порядка отображения
пунктов цифрового поручения........................................................................................................................................ 54
4.7.11
Требования к развитию (адаптации) функционала СЭДО в части реализации возможности вывода
информации в поле «Текст поручения» в пункте внешней резолюции РК................................................................54
4.7.12
Требования к развитию (адаптации) функционала СЭДО в части реализации возможности
направления исходящего документа по пунктам цифрового поручения, созданным вручную во внешней
резолюции 55
4.7.13
Требования к разработке Частного технического задания на развитие Системы..................................55
4.7.14
Системы
Требование к актуализации Модели угроз и Модели нарушителя информационной безопасности
56
4.7.15
Требование к актуализации Частного технического задания на модернизацию системы защиты
информации Системы...................................................................................................................................................... 57
5
6
СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ СИСТЕМЫ.........................61
ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ ВЫПОЛНЕННЫХ РАБОТ..........................67
6.1
Виды, состав, объем и методы испытаний Системы и ее составных частей....................................................67
6.1.1
Требования к проведению предварительных испытаний......................................................................... 67
6.1.2
Требования к проведению опытной эксплуатации...................................................................................68
6.1.3
Требования к проведению приемочных испытаний.................................................................................69
6.1.4
Требования к мероприятиям по подготовке и проведению аттестационных испытаний Системы.....70
7
8
ОБЪЕМ И СРОКИ ГАРАНТИЙ КАЧЕСТВА.................................................................72
ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ.................................................................73
8.1
8.2
8.3
Перечень подлежащих разработке документов................................................................................................... 73
Требования к эксплуатационной и программной документации.......................................................................73
Требования по использованию ЕСКД и ЕСПД при разработке документов....................................................73
 4
1
Общие сведения
1.1
Наименование объекта работ
Наименование
объекта
работ:
Система
электронного
документооборота
Минэкономразвития России (далее – СЭДО, Система).
Код по ОКПД2/КТРУ: 58.29.50.000/58.29.11.000-00000003; 62.01.11.000.
1.2
Наименование работ
Полное
наименование
работ:
работы
по
развитию
Системы
электронного
документооборота Минэкономразвития России (далее – выполнение работ, работы, развитие).
Сокращенное наименование работ: работы по развитию Системы.
1.3
Заказчик
Заказчиком настоящих работ является Министерство экономического развития
Российской Федерации (далее – Заказчик, Министерство).
Сведения о реквизитах Заказчика представлены в Таблице 1.
Таблица 1 – Реквизиты Заказчика
№
п/п
Наименование
Описание
1
Место нахождения и почтовый адрес
2
3
4
Телефон
Контактный адрес электронной почты
Адрес Заказчика в сети Интернет
1.4
123112, г. Москва, Пресненская наб., д. 10,
стр. 2
+7 (495) 870-29-21
mineconom@economy.gov.ru
www.economy.gov.ru
Исполнитель
Исполнитель
определяется
по
результатам
проведения
открытого
аукциона
в электронной форме соответствии с федеральным законом от 5 апреля 2013 г. № 44-ФЗ
«О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения
государственных и муниципальных нужд».
1.5
Cроки выполнения работ
Сроки выполнения работ: с даты заключения контракта по 20 декабря 2026 г.
включительно, в том числе:
- этап Работ № 1: в течение 7 календарных дней с даты заключения Контракта;
- этап Работ № 2: с даты заключения контракта по 25 ноября 2026 г. включительно;
- этап Работ № 3: с даты завершения этапа работ № 2 по 11 декабря 2026 г.
включительно;
 5
- этап Работ № 4: с даты завершения этапа работ № 3 по 20 декабря 2026г.
включительно.
1.6
Сведения об источниках и порядке финансирования работ
Источником финансирования работ является федеральный бюджет.
Порядок финансирования определяется действующими нормативными правовыми
актами, регулирующими вопросы финансирования расходов федерального бюджета,
и Контрактом, заключаемым с Исполнителем.
1.7
Перечень нормативных правовых документов, стандартов и иных
документов, которые должны быть учтены при выполнении работ
Перечень нормативных правовых документов, стандартов и иных документов, которые
должны быть учтены при выполнении работ:
 приказ Министерства цифрового развития, связи и массовых коммуникаций
Российской Федерации от 11 июля 2024 г. № 610 «Об утверждении цифровых
шаблонов
и форматов документов, используемых при работе с поручениями Правительства
Российской
Федерации
в
информационной
системе
обеспечения
внутриведомственного
и межведомственного документооборота и контроля исполнения поручений, в том
числе
с использованием облачных сервисов»;
 приказ Министерства цифрового развития, связи и массовых коммуникаций
Российской Федерации № 611, ФСО России № 96 от 12 июля 2024 г. «Об утверждении
Требований к организационно-техническому взаимодействию государственных
органов и государственных организаций»;
 Федеральный закон от 27 июля 2006 г. № 149-ФЗ «Об информации,
информационных технологиях и о защите информации»;
 Федеральный закон от 27 июля 2006 г. № 152-ФЗ «О персональных данных»;
 Федеральный закон от 6 апреля 2011 г. № 63-ФЗ «Об электронной подписи»;
 Федеральный закон от 4 мая 2011 г. № 99-ФЗ «О лицензировании отдельных
видов деятельности»;
 Указ Президента Российской Федерации от 17 марта 2008 г. № 351 «О мерах
по обеспечению информационной безопасности
Российской
Федерации при
 6
использовании
информационно-телекоммуникационных
сетей
международного
информационного обмена»;
 Указ Президента Российской Федерации от 5 декабря 2016 г. № 646 «Об
утверждении Доктрины информационной безопасности Российской Федерации»;
 Указ Президента Российской Федерации от 1 мая 2022 г. № 250 «О
дополнительных мерах по обеспечению информационной безопасности Российской
Федерации»;
 Постановление Правительства Российской Федерации от 18 мая 2009 г. № 424
«Об
особенностях
подключения
федеральных
государственных
систем
к
информационно-телекоммуникационным сетям»;
 Постановление Правительства Российской Федерации от 24 ноября 2009 г. №
953 «Об обеспечении доступа к информации о деятельности Правительства
Российской Федерации, подведомственных ему организаций и федеральных органов
исполнительной власти»;
 Постановление Правительства Российской Федерации от 8 сентября 2010 г. №
697 «О единой системе межведомственного электронного взаимодействия»;
 Постановление Правительства Российской Федерации от 3 февраля 2012 г. №
79 «О лицензировании деятельности по технической защите конфиденциальной
информации»;
 Постановление Правительства Российской Федерации от 21 марта 2012 г. №
211 «Об утверждении перечня мер, направленных на обеспечение выполнения
обязанностей, предусмотренных Федеральным законом «О персональных данных» и
принятыми в соответствии с ним нормативными правовыми актами, операторами,
являющимися государственными или муниципальными органами»;
 Постановление Правительства Российской Федерации от 16 апреля 2012 г. № 313
«Об утверждении Положения о лицензировании деятельности по разработке, производству,
распространению шифровальных (криптографических) средств, информационных систем и
телекоммуникационных
систем,
защищенных
с
использованием
шифровальных
(криптографических) средств, выполнению работ, оказанию услуг в области шифрования
информации, техническому обслуживанию шифровальных (криптографических) средств,
информационных систем и телекоммуникационных систем, защищенных с использованием
шифровальных (криптографических) средств (за исключением случая, если техническое
обслуживание шифровальных (криптографических) средств, информационных систем и
телекоммуникационных
систем,
защищенных
с
использованием
шифровальных
 7
(криптографических)
средств,
осуществляется
для
обеспечения
собственных
нужд
юридического лица или индивидуального предпринимателя)»;
 Постановление Правительства Российской Федерации от 1 ноября 2012 г. №
1119 «Об утверждении требований к защите персональных данных при их обработке
в информационных системах персональных данных»;
 Постановление Правительства Российской Федерации от 6 июля 2015 г. № 675
«О порядке осуществления контроля за соблюдением требований, предусмотренных
частью 2.1 статьи 13 и частью 6 статьи 14 Федерального закона «Об информации,
информационных технологиях и о защите информации»;
 Постановление Правительства Российской Федерации от 6 июля 2015 г. № 676
«О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и
вывода из эксплуатации государственных информационных систем и дальнейшего
хранения содержащейся в их базах данных информации»;
 Приказ ФСТЭК России от 11 апреля 2025 г. № 117 «Об утверждении
Требований
о
защите
информации,
содержащейся
в государственных
информационных системах, иных информационных системах государственных
органов, государственных унитарных предприятий, государственных учреждений»;
 Приказ ФСТЭК России от 18 февраля 2013 г. № 21 «Об утверждении Состава и
содержания организационных и технических мер по обеспечению безопасности
персональных данных при их обработке в информационных системах персональных
данных»;
 Приказ ФСТЭК России от 29 апреля 2021 г. № 77 «Об утверждении Порядка
организации и проведения работ по аттестации объектов информатизации на
соответствие
требованиям
о
защите
информации
ограниченного
доступа,
не составляющей государственную тайну»;
 Приказ ФСТЭК России от 4 июля 2022 г. № 118 «Требования по безопасности
информации к средствам контейнеризации (выписка)»;
 Приказ ФСТЭК России от 1 декабря 2023 № 240 «Об утверждении Порядка
проведения
сертификации
процессов
безопасной
разработки
программного
обеспечения средств защиты информации»;
 Приказ ФСБ России и ФСТЭК России от 31 августа 2010 г. № 416/489 «Об
утверждении Требований о защите информации, содержащейся в информационных
системах общего пользования»;
 8
 Приказ ФСБ России от 9 февраля 2005 г. № 66 «Об утверждении Положения о
разработке, производстве, реализации и эксплуатации шифровальных (криптографических)
средств защиты информации (Положение ПКЗ-2005)»;
 Приказ ФСБ России от 10 июля 2014 г. № 378 «Об утверждении Состава и
содержания организационных и технических мер по обеспечению безопасности персональных
данных при их обработке в информационных системах персональных данных с
использованием средств криптографической защиты информации, необходимых для
выполнения установленных Правительством Российской Федерации требований к защите
персональных данных для каждого из уровней защищенности»;
 Приказ ФСБ России от 24 июля 2018 г. № 367 «Об утверждении перечня
информации, представляемой в государственную систему обнаружения, предупреждения и
ликвидации последствий компьютерных атак на информационные ресурсы Российской
Федерации и порядка представления информации в государственную систему обнаружения,
предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы
Российской Федерации»;
 Приказ ФСБ России от 4 ноября 2022 г. № 547 «Об утверждении перечня сведений в
области военной, военно-технической деятельности Российской Федерации, которые при их
получении иностранными источниками могут быть использованы против безопасности
Российской Федерации»;
 Приказ ФСБ России от 13 февраля 2023 г. № 77 «Об утверждении порядка
взаимодействия операторов с государственной системой обнаружения, предупреждения и
ликвидации последствий компьютерных атак на информационные ресурсы Российской
Федерации, включая информирование ФСБ России о компьютерных инцидентах, повлекших
неправомерную передачу (предоставление, распространение, доступ) персональных данных»;
 Приказ ФАПСИ от 13 июня 2001 г. № 152 «Об утверждении Инструкции об
организации и обеспечении безопасности хранения, обработки и передачи по каналам связи с
использованием средств криптографической защиты информации с ограниченным доступом,
не содержащей сведений, составляющих государственную тайну»;
 Приказ Министерства связи и массовых коммуникаций Российской
Федерации от 25 августа 2009 г. № 104 «Об утверждении Требований по обеспечению
целостности, устойчивости функционирования и безопасности информационных
систем общего пользования»;
 Приказ Министерства связи и массовых коммуникаций Российской
Федерации от 23 июня 2015 г. № 210 «Об утверждении технических требований к
 9
взаимодействию информационных систем в единой системе межведомственного
электронного взаимодействия»;
 Приказ Министерства цифрового развития, связи и массовых коммуникаций
Российской Федерации от 18 августа 2021 г. № 857 «Об утверждении единых
требований
к
формам
доверенностей,
необходимых
для
использования
квалифицированной электронной подписи»;
 Приказ Министерства экономического развития Российской Федерации от 13
ноября 2023 г. № 785 «Об определении угроз безопасности персональных данных,
актуальных при обработке персональных данных в информационных системах
персональных
данных,
экономического
эксплуатируемых
развития
Российской
при
осуществлении
Федерации
функций,
Министерством
определенных
законодательством Российской Федерации»;
 Приказ Министерства экономического развития Российской Федерации от 24
ноября 2023 г. № 821 «Об утверждении Регламента выявления, анализа и устранения
уязвимостей в информационных системах Министерства экономического развития
Российской Федерации»;
 Методика испытаний систем защиты информации информационных систем
методами тестирования на проникновение, утв. ФСТЭК России 25 июня 2025 г.;
 Методический документ «Методика оценки показателя состояния технической
защиты информации в информационных системах и обеспечение безопасности значимых
объектов критической информационной инфраструктуры Российской Федерации», утвержден
ФСТЭК России 11 ноября 2025 г.;
 Методический документ «Методика анализа защищенности информационных
систем», утвержден ФСТЭК России 25 ноября 2025 г.;
 Методический документ «Состав и содержание мероприятий и мер по защите
информации, содержащейся в информационных системах», утвержден ФСТЭК России
12 апреля 2026 г.;
 Методический
документ
«Методика
оценки
угроз
безопасности
информации», утвержден ФСТЭК России от 5 февраля 2021 г.;
 Методический документ «Методика оценки уровня критичности уязвимостей
программных, программно-аппаратных средств», утвержден ФСТЭК России от 30 июня
2025 г.;
 Методический документ «Методика тестирования обновлений безопасности
программных, программно-аппаратных средств», утвержден ФСТЭК России от 28
октября 2022 г.;
 10
 Методический документ «Руководство по организации процесса управления
уязвимостями в органе (организации)», утвержден ФСТЭК России от 17 мая 2023 г.
 Приказ ФСБ России от 22 августа 2026 г. № 321 «Об утверждении Требований
о защите информации, содержащейся в государственных информационных системах, иных
информационных
системах
государственных
органов,
государственных
унитарных
предприятий, государственных учреждений, а также при использовании технических средств
и программ для электронных вычислительных машин и баз данных в соответствии с частью
5.1 статьи 13 Федерального закона от 27 июля 2006 г. № 149-ФЗ «Об информации,
информационных технологиях и о защите информации» с использованием шифровальных
(криптографических) средств»;
 ГОСТ Р 59792-2021. Национальный стандарт Российской Федерации.
Информационные технологии. Комплекс стандартов на автоматизированные системы.
Виды испытаний автоматизированных систем;
Требования указанных выше нормативно-правовых актов применяются только
и исключительно в той части, которая не ведет к изменению объема и стоимости работ
по Государственному контракту.
1.8
Перечень терминов, сокращений и обозначений
В Таблице 2 приведены термины, сокращения и обозначения, используемые
в настоящем ТЗ.
Таблица 2 – Термины, сокращения и определения
Термин, сокращение,
обозначение
АРМ
БД
БДУ
Вычислительные
ресурсы
Веб-браузер
Веб-клиент
ГК
ГИС «ТОР СЭД»
ГОСТ
Полная форма
Автоматизированное рабочее место
База данных
Банк данных угроз безопасности информации ФСТЭК России
Технические средства ЭВМ, в том числе процессор, объемы оперативной
и внешней памяти, время, в течение которого программа занимает эти
средства в ходе выполнения
Приложение для просмотра и взаимодействия посредством сети
Интернет-ресурсов, размещенных в удаленном доступе (документы,
файлы, сервисы)
Приложение СЭДО, выполняющее функции Тонкого клиента
Государственный контракт
Государственная информационная система «Типовое облачное решение
системы электронного документооборота»
Государственный стандарт
 11
ГОСТ РО
ГОСТ Р
ГосЭДО
ДСП
ЕИС
ЗК
ИБ
Информационнотелекоммуникационная
сеть «Интернет»
ИС
Исполнитель
КЗ
МРМР
МЭДО
Контракт
Министерство,
Минэкономразвития
России, Заказчик
МУиН
НСД
ОК
ОС
Государственный стандарт, действующий только на территории
Российской Федерации ограниченного распространения
Государственный стандарт, действующий только на территории
Российской Федерации
Государственный электронный документооборот (платформа для
юридически значимого обмена электронными документами между
бизнесом и государственными органами)
Гриф «для служебного пользования», используется для обозначения
документов, содержащих информацию, отнесенную к сведениям,
составляющим служебную тайну
Единая информационная система в сфере закупок
Закрытый контур
Информационная безопасность
Технологическая система, предназначенная для передачи по линиям связи
информации, доступ к которой осуществляется с использованием средств
вычислительной техники
Информационная система
Организация, определенная победителем по результатам проведения
открытого конкурса в электронной форме в соответствии с Федеральным
законом от 5 апреля 2013 г. № 44-ФЗ «О контрактной системе в сфере
закупок товаров, работ, услуг для обеспечения государственных и
муниципальных нужд»
Карточка задания, сформированная в СЭДО для одного исполнителя при
утверждении инициативного поручения или резолюции, при запуске
маршрута согласования или при передаче документа на рассмотрение
Мобильное рабочее место руководителя. Интегрированный с СЭДО
модуль на базе программного обеспечения «Мобильное Рабочее Место
Руководителя», предоставляющий возможность выполнения операций с
документами и поручениями СЭДО на мобильных устройствах
Система межведомственного электронного документооборота –
федеральная
информационная
система,
обеспечивающая
в
автоматизированном режиме защищенный обмен электронными
сообщениями, в том числе ДСП, между Администрацией Президента
Российской Федерации, Аппаратом Правительства Российской
Федерации и федеральными органами исполнительной власти, а также
иными федеральными органами и ведомствами государственной власти
Государственный контракт на выполнение работ по развитию Системы
электронного документооборота Минэкономразвития России
Министерство экономического развития Российской Федерации
Модель угроз безопасности информации и Модель нарушителя
безопасности информации
Несанкционированный доступ
Открытый контур
Операционная система
 12
Оператор
Оператор ОЦОД ПК
ОЦОД ПК
Патентная чистота ПО
ПДн
ПК
ПО
ПОС
Ресурс
Минэкономразвития
России для размещения
отчетной документации
РК
Сайт
СДУ
СМЭВ
ССТУ.РФ
СЗИ
Организация, которая технически подключает участников (госорганы,
организации) к системе обмена электронными документами и
обеспечивает их связь с общей инфраструктурой ГАС/МЭДО.
Организация, обслуживающая ОЦОД ПК и предоставляющая доступ к
мощностям ОЦОД ПК
Объединенный центр обработки данных Правительственного комплекса
Юридическое свойство технической реализации программного
обеспечения, означающее отсутствие нарушения на территории РФ
исключительных прав третьих лиц на объекты промышленной
собственности (охраняемые патентами в соответствии со ст. 1350–
1352 ГК РФ), а также отсутствие препятствий для использования ПО,
связанных с правами на другие объекты интеллектуальной собственности.
Персональные данные
Правительственный
комплекс,
расположенный
по
адресу
г. Москва, Пресненская наб., д.10, стр.2 (Башня 2)
Программное обеспечение
Единое цифровое окно обратной связи (Платформа обратной связи)
федеральной государственной информационной системы «Единый
портал государственных и муниципальных услуг (функций)»
Информационная система (или компонент информационной системы)
Минэкономразвития России, с функциональностью по размещению
отчётной
документации,
предусмотренной
Государственными
контрактами
Регистрационная карточка
Система экспертного сопровождения и общественного обсуждения Плана
деятельности Министерства экономического развития Российской
Федерации (официальный информационный сайт) в информационнотелекоммуникационной сети «Интернет»
Система документационного управления
Система
межведомственного
электронного
взаимодействия
–
федеральная государственная информационная система, в задачу которой
входит обеспечение исполнения государственных функций и
предоставления государственных услуг в электронной форме, а также
обеспечение информационного взаимодействия при предоставлении этих
услуг и исполнении этих функций
Портал коммутационной платформы сетевого справочного телефонного
узла – сетевой информационный ресурс, на котором публикуются данные
об органах местного самоуправления, государственных учреждениях и
органах, а также соответствующих лицах, уполномоченных на решение
государственных и территориальных вопросов. На ресурсе также
публикуются результаты рассмотрения обращений граждан в
вышеуказанные органы и к соответствующим лицам
Система защиты информации
 13
СПО
СрЗИ
ОПО
Система, СЭДО
СКЗИ
СУБД
ТЗ
ТС
ТУ
ТК, Транспортный
контейнер
Тонкий клиент
ТУ ИС ФОИВ ОЦОД
ПК
Фаззинг-тестирование
ФОИВ
ФСБ России
ФСТЭК России
ФТ
Хеш-сумма
Специальное
программное
обеспечение,
часть
программного
обеспечения,
представляющая
собой
совокупность
программ,
разработанных при создании/развитии данной Системы (ГОСТ Р 598532021. Национальный стандарт Российской Федерации. Информационные
технологии. Комплекс стандартов на автоматизированные системы.
Автоматизированные системы. Термины и определения)
Средства защиты информации
Общее программное обеспечение, часть программного обеспечения,
представляющая
собой
совокупность
программных
средств,
разработанных вне связи с созданием/развитием данной Системы.
Обычно ОПО представляет собой совокупность программ общего
назначения, предназначенных для организации вычислительного
процесса и решения часто встречающихся задач обработки информации
(ГОСТ Р 59853-2021. Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Автоматизированные системы. Термины и
определения)
Система электронного документооборота Минэкономразвития России
Средства криптографической защиты информации
Система управления базами данных
Техническое задание
Технические средства
Технические условия
Основная единица передачи данных по МЭДО, представляющая собой
ZIP-архив, содержащий данные в соответствии с утверждёнными
форматами взаимодействия
Приложение, выполняющее задачи по обработке данных, у которого
ресурсы для выполнения задач и данные для их выполнения находятся на
сервере баз данных, а на устройстве, на котором оно установлено,
находится только интерфейс, выполняющий соответствующие запросы к
серверу. В рамках настоящего документа термин аналогичен термину
«Веб-клиент»
Технические условия по размещению информационных систем
федеральных органов исполнительной власти в объединённом центре
обработки
данных
правительственного
комплекса,
редакция
АГРВ.466459.301-01ТУ
Техника тестирования программного обеспечения, часто автоматическая
или полуавтоматическая, заключающаяся в передаче приложению на вход
неправильных, неожиданных или случайных данных
Федеральный орган исполнительной власти
Федеральная служба безопасности Российской Федерации
Федеральная служба по техническому и экспортному контролю
Российской Федерации
Функциональные требования
Результат обработки данных математическим алгоритмом (хешфункцией), который отображает данные произвольного размера в
битовый массив фиксированного размера
 14
ЦОД
ЦП
ЧТЗ
ЧТЗ на СЗИ
ЭВМ
ЭП
AppArmor
API
BPMN
CAPTCHA
CSS
CVE
DDMWeb Service
DocsVision
ERD
HTML (HyperText
Markup Language)
HTTP (HyperText
Transfer Protocol)
Специализированный объект, представляющий собой связанную
систему
ИТ-инфраструктуры
и
инженерной
инфраструктуры,
оборудование и части которых размещены в здании или помещении,
подключенном к внешним сетям, как инженерным, так и
телекоммуникационным
Цифровое поручение
Частное техническое задание
Частное техническое задание на модернизацию системы защиты
информации
Электронная вычислительная машина
Электронная подпись
Реализация безопасности линукс по управлению доступом на основе имен
(англ. Application Programming Interface, интерфейс прикладного
программирования) — набор готовых классов, процедур, функций,
структур и констант, предоставляемых приложением (библиотекой,
сервисом) или операционной системой для использования во внешних
программных продуктах
Business Process Model and Notation (нотация и модель бизнес-процессов)
– система условных обозначений (нотация) и их описания в XML для
моделирования бизнес-процессов
(англ. Completely Automated Public Turing test to tell Computers and Humans
Apart, полностью автоматизированный публичный тест Тьюринга для
различения компьютеров и людей) — компьютерный тест, используемый
для того, чтобы определить, кем является пользователь системы:
человеком или компьютером
(англ. Cascading Style Sheets) формальный язык декорирования и описания
внешнего вида документа (веб-страницы), написанного с использованием
языка разметки
(англ. Common Vulnerabilities and Exposures) база данных общеизвестных
уязвимостей информационной безопасности
Cервис для сканирования и печати документов на принтере в Веб-клиенте
Комплексная
программная
платформа,
предназначенная
для
автоматизации процессов управления, документооборота и для создания
интегрированных приложений. Платформа DocsVision представляет
собой трехуровневое приложение, центральным элементом которого
является карточка – совокупность описания структуры, соответствующих
ей данных и одного или нескольких элементов управления ActiveX,
реализующих пользовательский интерфейс. Платформа включает в себя
основную часть серверных компонентов СЭДО
(англ. Entity Relationship Diagram) визуальное представление структуры
данных и связей между ними в системе
Стандартизированный язык гипертекстовой разметки документов для
просмотра веб-страниц в браузере
Сетевой протокол прикладного уровня, который изначально
предназначался для получения с серверов гипертекстовых документов в
формате HTML.
 15
HTTPS (HyperText
Transfer Protocol
Secure)
IP, IP-адрес
IEDMS
JavaScript
ООМ
ReCAPTCHA
REST
RSA
SELinux
SBOM
SCA
SPDX
SSL
SWID
TCP/IP
Unicode Bidi (Unicode
Bidirectional Algorithm)
URL
XSS уязвимость
Расширение протокола HTTP для поддержки шифрования в целях
повышения безопасности
(англ. Internet Protocol, межсетевой протокол) — маршрутизируемый
протокол сетевого уровня стека TCP/IP
(Англ. Integrated Electronic Document Management System) –
интегрированная электронная система управления документами
(англ. JS) — мультипарадигменный язык программирования
(англ. out-of-memory) механизм ядра ОС Linux, который в случае
исчерпания оперативной памяти (RAM) освобождает ее путем
завершения существующих процессов
Система, разработанная в университете Карнеги — Меллона для защиты
веб-сайтов от интернет-ботов и одновременной помощи в оцифровке
текстов книг. Является продолжением проекта CAPTCHA
(Англ. Representational State Transfer) – способ организации программного
взаимодействия с помощью протокола HTTP
(Аббревиатура от фамилий Rivest, Shamir и Adleman) –
криптографический алгоритм с открытым ключом, используемый и для
шифрования, и для цифровой подписи
(англ. Security-Enhanced Linux) реализация системы принудительного
контроля доступа, которая может работать параллельно с классической
избирательной системой контроля доступа
(англ. Software Bill of Materials) — спецификация программного
обеспечения
(англ. Software Composition Analysis) анализ состава программного
обеспечения.
(англ. Software Package Data Exchange) международный открытый
стандарт (ISO/IEC 5962:2021) для представления спецификации
программного обеспечения
(англ. Secure Sockets Layer, уровень защищённых сокетов) —
криптографический протокол, который использует асимметричную
криптографию для аутентификации ключей обмена, симметричное
шифрование для сохранения конфиденциальности, коды аутентификации
сообщений для целостности сообщений
(англ. Software Identification Tag) формат маркировки программного
обеспечения, регламентированный международным стандартом ISO/IEC
19770-2:2015 и его адаптированными версиями
Набор сетевых протоколов передачи данных, используемых в сетях,
включая сеть Интернет. Протоколы работают друг с другом в стеке (англ.
stack, стопка) – это означает, что протокол, располагающийся на уровне
выше, работает «поверх» нижнего, используя механизмы инкапсуляции.
Например, протокол TCP работает поверх протокола IP
(англ. unicode bidirectional algorithm) алгоритм двунаправленного
юникода
(англ. Uniform Resource Locator) адрес ресурса в сети Интернет
(англ. Cross-Site Scripting) подтип атаки на веб-системы, заключающийся
во внедрении в выдаваемую веб-системой страницу вредоносного кода и
взаимодействии этого кода с веб-сервером злоумышленника
 16
1.9
Порядок оформления и предъявления результатов работ
Результаты работ оформляются и передаются в соответствии с разделом 5 настоящего
ТЗ Заказчику в порядке, установленном Контрактом и настоящим ТЗ.
Результатами выполнения Исполнителем работ, требования к которым определены
в
настоящем
ТЗ,
является
функционирование
адаптированных
функций
Системы
в соответствии с требованиями, приведенными в пункте 4.7.
В ходе и по завершении выполнения работ по отчетному периоду Исполнитель
размещает отчетную документацию, определенную требованиями Контракта как результат
выполнения работ по отчетному периоду, на Ресурсе Минэкономразвития России для
размещения отчетной документации.
По факту размещения материалов Исполнителем на Ресурсе Минэкономразвития
России для размещения отчетной документации и уведомления Заказчика об этом Заказчик
проводит экспертизу (в порядке, определенном Контрактом) представленной отчетной
документации на предмет полноты и качества выполненных работ, в том числе на предмет
их соответствия требованиям Контракта.
В случае выявления замечаний по результатам экспертизы к представленной отчетной
документации Заказчик направляет перечень замечаний Исполнителю, а Исполнитель
обязуется устранить указанные замечания до предоставления Заказчику итоговых отчетных
материалов, определенных требованиями Контракта как результат выполненных работ
за отчетный период.
Заказчик вправе запросить внеочередное предоставление отчетных материалов
по выполнению работ за отчетный период (не чаще 1 раза в квартал, не более 2 раз в ходе
выполнения работ за отчетный период). В случае такого запроса от Заказчика Исполнителем
должны быть представлены отчетные документы официальным письмом, в которых
содержатся сведения о работах, фактически выполненных на момент поступления данного
запроса. Срок внеочередного предоставления отчетных материалов – 3 (три) рабочих дня
с даты запроса.
В установленный Контрактом срок Исполнитель формирует итоговые отчетные
документы и материалы по выполнению работ за отчетный период и предоставляет
с использованием Единой информационной системе в сфере закупок (далее – ЕИС),
подписывает усиленной квалифицированной электронной подписью лица, имеющего право
действовать от имени Исполнителя, и размещает в ЕИС документ о приемке в соответствии
с требованиями ч.13 ст. 94 Федерального закона от 5 апреля 2013 г. № 44-ФЗ «О контрактной
системе в сфере закупок товаров, работ, услуг для обеспечения государственных
 17
и муниципальных нужд».
Документация в виде электронных документов и (или) электронных образов
документов должна быть подписана усиленной квалифицированной электронной подписью
юридического лица с указанием фамилии, имени, отчества, имеющего право действовать без
доверенности от имени Исполнителя, либо представителем на основании доверенности
(личной усиленной квалифицированной электронной подписью физического лица), либо
усиленной квалифицированной электронной подписью физического лица, исполняющего
соответствующие должностные обязанности Исполнителя.
Контроль и приемка выполненных работ за отчетный период осуществляется
в соответствии с условиями Контракта, пунктом 6 настоящего ТЗ и оформляется Актами
приемки выполненных работ за отчетный период. Условия оплаты выполненных работ
определяются Контрактом.
В случае, если при проверке представленных отчетных документов в ходе контроля и
приемки выполненных работ за отчетный период будет установлена неактуальность,
противоречивость либо неполнота сведений, Заказчик в порядке, определенном Контрактом,
возвращает Исполнителю документы на доработку с указанием причин отказа в приемке
результатов выполненных работ.
Требования к оформлению отчетной документации по результату выполненных работ
обозначены в пункте 8 настоящего ТЗ.
 18
2
Цели и задачи работ
2.1
Цели
Целями выполнения работ являются:
−
Оптимизация процессов электронного документооборота за счет обмена
данными с глобальным адресным справочником (ГАС);
−
Реализация взаимодействия с внешними ИС по формату обмена данными МЭДО
3.0 за счет развития модуля МЭДО;
−
Соответствие нормативным требованиям в части обработки цифровых
поручений по событиям «Принятие информации об исполнении», «Изменение
срока поручения», «Представление промежуточного доклада» и «Запрос
изменения срока поручения»;
−
Автоматизация процесса передачи информации об департаменте, ответственном
за обработку обращения юридического лица;
−
Расширение функциональных возможностей в части подготовки одного
закрывающего документа по нескольким пунктам цифрового поручения;
−
Автоматизация процесса указания вида контроля для соисполнителей по
пунктам цифрового поручения во внешней резолюции;
−
Повышение эргономичности интерфейса СЭДО за счет отображения внешнего
контрагента в дереве резолюций;
−
Повышение
эргономичности
интерфейса
СЭДО
за
счет
изменения
последовательности отображения значений в поле «Номер пункта» во внешней
резолюции цифрового поручения;
−
Автоматизация процесса заполнения поля «Исполнитель» во внешней
резолюции цифрового поручения;
−
Повышение
эргономичности
интерфейса
СЭДО
за
счет
развития
функциональности изменения последовательности пунктов внешней резолюции
цифрового поручения;
−
Расширение функциональных возможностей СЭДО в части вывода информации
в поле «Текст поручения» в пункте внешней резолюции цифрового поручения;
−
Оптимизация возможности отчитаться по пунктам цифрового поручения,
созданных вручную во внешней резолюции;
−
Обеспечение защиты информации ограниченного доступа (персональных
данных, иной информации конфиденциального характера), обрабатываемой в
Системе, от несанкционированного или случайного доступа, уничтожения,
 19
изменения, блокирования, копирования, предоставления, распространения, а
также
от
иных
неправомерных
действий
в
отношении
информации
ограниченного доступа; поддержание требуемого уровня защищенности
информации в Системе.
2.2
Задачи
Задачи, которые необходимо решить для достижения поставленных целей:
–
–
Развитие (адаптация) функционала модуля МЭДО в части обмена данными с
глобальным адресным справочником (ГАС);
Развитие (адаптация) функционала модуля МЭДО в части поддержки формата
обмена данными МЭДО 3.0;
–
Развитие (адаптация) функционала СЭДО в части обмена данными по событиям
цифровых поручений второй очереди;
–
Развитие (адаптация) функционала СЭДО в части интеграции с сайтом
Минэкономразвития
России
для
передачи
контактной
информации
структурного подразделения Министерства по запросу юридического лица;
–
Развитие (адаптация) функционала СЭДО в части отправки одного исходящего
события по нескольким пунктам цифрового поручения;
–
Развитие (адаптация) функционала СЭДО в части автоматической простановки
вида контроля «ВК» по пунктам цифрового поручения, где Минэкономразвития
России является соисполнителем;
–
Развитие (адаптация) функционала СЭДО в части отображения подписанта
внешнего контрагента в дереве резолюций;
–
Развитие (адаптация) функционала СЭДО в части изменения формата
отображения номера пункта цифрового поручения;
–
Развитие (адаптация) функционала СЭДО в части автоматического указания
руководителя Минэкономразвития России исполнителем по пунктам внешней
резолюции цифрового поручения;
–
Развитие (адаптация) функционала СЭДО в части изменения порядка
отображения пунктов цифрового поручения во внешней резолюции и дереве
резолюции;
–
Развитие (адаптация) функционала СЭДО в части реализации возможности
вывода информации в поле «Текст поручения» в пункте внешней резолюции
цифрового поручения;
 20
–
Развитие (адаптация) функционала СЭДО в части реализации возможности
направления исходящего документа по пунктам цифрового поручения,
созданным вручную во внешней резолюции;
–
Актуализация действующей Модели угроз и нарушителя безопасности
информации Системы (МУиН);
–
Проверка Системы на наличие уязвимостей программного обеспечения и
устранение выявленных уязвимостей;
–
Осуществление
комплекса
аттестационным
испытаниям
мероприятий
на
по
соответствие
подготовке
требованиям
Системы
о
защите
информации»;
–
к
Разработка частного технического задания на развитие Системы и/или СЗИ.
 21
3
Характеристика объекта выполнения работ
3.1
Назначение и краткое описание Системы
СЭДО предназначена для комплексной автоматизации документооборота, а именно для
автоматизации следующих видов деятельности:
– регистрация входящих документов (в том числе обращений граждан);
– подготовка, согласование и регистрация внутренних и исходящих документов (в
том числе ответов на обращения граждан);
– подготовка резолюций и инициативных поручений;
– исполнение заданий по резолюциям;
– контроль исполнительской дисциплины;
– формирование отчетности;
– поиск регистрационных карточек и карточек заданий;
– ведение оперативного архива.
Система
оснащена
сертифицированными
средствами
защиты
информации
и эксплуатируется в соответствии с требованиями по информационной безопасности,
Аттестатом соответствия системы требованиям о защите информации, внутренними
стандартами, требованиями по безопасности информации, требованиями к эксплуатации,
техническому обслуживанию, ремонту и хранению компонентов Системы, определяемыми
производителями средств защиты информации, внутренними регламентами Заказчика и ТУ
ИС ФОИВ ОЦОД ПК в инфраструктуре объединенного центра обработки данных
Правительственного комплекса (далее – ОЦОД ПК).
ОЦОД ПК имеет Аттестат соответствия требованиям о защите информации от 23 марта
2023 г. № Л024-00107-00/00582586.00547.2023
и соответствует требованиям о защите
информации в части реализации мер защиты предъявляемым к государственным
информационным
системам
первого
класса
защищенности
(К1)
в
соответствии
с «Требованиями о защите информации, не составляющей государственную тайну,
содержащейся в государственных информационных системах», утвержденными приказом
ФСТЭК России от 11 февраля 2013 г. № 17 «Об утверждении Требований о защите
информации, не составляющей государственную тайну, содержащейся в государственных
информационных системах», и к информационным системам персональных данных, для
которых
установлена
необходимость
обеспечения
первого
уровня
защищённости
персональных данных (У3-1) в соответствии с постановлением Правительства Российской
Федерации от 1 ноября 2012 г. № 1119 «Об утверждении требований к защите персональных
данных при их обработке в информационных системах персональных данных».
 22
В
в
соответствии
государственных
с
«Требованиями
информационных
о
защите
системах,
иных
информации,
содержащейся
информационных
системах
государственных органов, государственных унитарных предприятий, государственных
учреждений», утвержденных приказом ФСТЭК России от 11 апреля 2025 г. № 117
предполагаемый класс защищенности ОЦОД ПК – К1 (высокий уровень значимости, масштаб
– федеральный).
от
Система
имеет
14.03.2025.
№
Аттестат
соответствия
требованиям
Л024-00107-0000580416.232.2023
и
о
защите
информации
соответствует
требованиям,
предъявляемым к государственным информационным системам 1 класса защищенности (К1) в
соответствии с «Требованиями о защите информации, не составляющей государственную
тайну, содержащейся в государственных информационных системах», утвержденными
приказом ФСТЭК России от 11 февраля 2013 г. № 17 «Об утверждении Требований о защите
информации, не составляющей государственную тайну, содержащейся в государственных
информационных системах», и к информационным системам персональных данных, для
которых
установлена
персональных
необходимость
данных
(У3-3)
в
обеспечения
соответствии
третьего
с
уровня
защищённости
постановлением
Правительства
Российской Федерации от 1 ноября 2012 г. № 1119 «Об утверждении требований к защите
персональных данных при их обработке в информационных системах персональных данных».
В соответствии с «Требованиями о защите информации, содержащейся в
государственных
информационных
системах,
иных
информационных
системах
государственных органов, государственных унитарных предприятий, государственных
учреждений», утвержденных приказом ФСТЭК России от 11 апреля 2025 г. № 117
предполагаемый класс защищенности Системы – К1 (высокий уровень значимости, масштаб –
федеральный, масштаб – федеральный).
Система введена в эксплуатацию приказом Минэкономразвития России от 25 января
2007 г. № 19 «Об организации промышленной эксплуатации Системы электронного
документооборота Минэкономразвития России».
Система не является объектом критической информационной инфраструктуры
Российской
Федерации,
не
субъектом
является
в
связи
критической
с
тем,
что
информационной
Минэкономразвития
инфраструктуры
России
Российской
Федерации, так как сфера деятельности не попадает под определение части 8 статьи 2
Федерального закона от 26 июля 2017 г. № 187-ФЗ «О безопасности критической
информационной инфраструктуры Российской Федерации».
В качестве основы функционирования СЭДО и прикладного программного
обеспечения используется система документационного управления «Приоритет» (далее –
 23
СДУ «Приоритет») на базе платформы DocsVision 5 и включает в себя серверные и клиентские
компоненты.
Обеспечение взаимодействия с Национальным координационным центром по
компьютерным инцидентам (НКЦКИ) в рамках Государственной системы обнаружения,
предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы
Российской Федерации (ГосСОПКА) осуществляется силами Корпоративного центра
ГосСОПКА «Ростелеком-Солар» при оказании услуг информационной безопасности и
технической
защите
информационно-телекоммуникационной
инфраструктуры
правительственного комплекса по отдельному государственному контракту.
Обеспечение взаимодействия в автоматизированном режиме с Национальной системой
противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи
общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите Системы от атак,
направленных на отказ в обслуживании, осуществляется владельцем ОЦОД ПК при оказании
услуг
информационной
безопасности
и
технической
защите
информационно-
телекоммуникационной инфраструктуры правительственного комплекса по отдельному
государственному контракту.
3.2
Сведения о ранее заключенных контрактах
Развитие и сопровождение Системы осуществлялось на основании следующих
контрактов:

от 10 ноября 2020 г. № 0173100008620000045;

от 29 октября 2021 г. № 0173100008621000054;

от 17 октября 2022 г. № 0173100008622000030;

от 25 ноября 2024 г. № 0173100008624000031.
3.3
Пользователи Системы
Пользователями СЭДО являются сотрудники Минэкономразвития России,
исполнение должностных обязанностей которых связано с документооборотом.
 24
3.4
Сведения о программном комплексе Системы
Система размещена на вычислительных ресурсах облачной инфраструктуры ОЦОД
ПК.
Система построена на основе программных компонентов и модулей, обеспечивающих
как внутреннее взаимодействие подсистем, так и взаимодействие с внешними ИС в закрытом
сегменте ОЦОД ПК.
3.4.1
Подсистемы и компоненты
Система включает следующие подсистемы (Таблица 3):
Таблица 3 – Перечень подсистем
№ п/п
Наименование
модуля / подсистемы
1.
Платформа DocsVision 5
2.
Делопроизводство/TakeOffice
3.
Расширенные отчеты/Reporting
4.
Служебные карточки/BackOffice
5.
Системные карточки/.NET
6.
Административное делопроизводство/DDM
Описание и предназначение
Обеспечивает
базовые
функции
автоматизации
документооборота
и
процессов
управления,
содержит
параметрические механизмы настройки
функциональности без программирования
Обеспечивает
расширение
набора
атрибутов РК для организации типового
документооборота Организации, а также
предоставляет справочники для ведения
справочной информации, используемой для
заполнения атрибутов РК
Реализует функциональность построения
отчетов высокой сложности. Отчеты такого
типа
могут
использоваться
при
необходимости
отображения
данных,
требующих
формирования
сложных
запросов, а также, если внешний вид отчета
не может быть реализован стандартным
механизмом представлений или требует
выгрузки в специальный формат
Реализует
функциональность
разграничения
прав
доступа
к
определенным элементам системы
Реализует функциональность управления
настройками СЭДО и ее составляющих
модулей
Предоставляет интерфейс для создания и
обработки регистрационных карточек
входящих и исходящих документов,
просмотра уведомлений МЭДО, работу со
«Справочником
сопоставления»
и
«Справочником наложения штампов»,
позволяет выполнять анализ состояний
входящих/исходящих
карточек
в
виртуальных поисковых папках
 25
№ п/п
Наименование
модуля / подсистемы
Описание и предназначение
7.
АРМ контролера/Card Control
8.
Веб-клиент/DDMWeb
9.
АРМ Руководителя/Executive Workspace
10.
Модуль
интеграционного
интерфейса/Integration Service
11.
Модуль интеграции с ПОС/FeedbackService
12.
Модуль интеграции с МЭДО/IEDMS
13.
Модуль интеграции с ССТУ.РФ/ SSTU
Integration Service
14.
Сервис
/Synchronizationservice
15.
Сервис конвертации/ Conversion-service
16.
Мастер наложения штампов/Stamp Wizard
17.
Модуль архивного делопроизводства/Archive
18.
Модуль интеграции с Российским офисным
синхронизации
Модуль предназначен для контроля
исполнения поручений, поставленных на
внешний контроль, контроль на уровне
организации или контроль на уровне
подразделения
Предназначен
для
выполнения
пользовательских задач по работе с
модулем
Административное
делопроизводство
системы
документооборота с использованием веббраузера
Предоставляет возможность выполнения
операций с документами и поручениями
СЭДО на мобильных устройствах как в
онлайн, так и в оффлайн режиме, после
предварительной
синхронизации
с
сервером
Предоставляет программный интерфейс
для интеграции СЭДО с внешними ИС
Предназначен для получения из ПОС
данных по обращениям граждан через
СМЭВ, обработки адаптером СМЭВ и
отправки через адаптер в СМЭВ, а затем в
ПОС ответов на обращения граждан и
статусов их рассмотрения
Позволяет
организовывать
обмен
документами
электронного
документооборота между различными
федеральными органами исполнительной
власти, а также отслеживать процесс
обработки
документа
на
стороне
получателя через получение уведомлений о
ключевых этапах обработки документа
Предназначен для отправки данных о
результатах
рассмотрения
обращений
граждан на портал ССТУ.РФ
Обеспечивает обмен данными между СЭДО
и АРМ Руководителя, в том числе
преобразование данных в нужный формат и
изменение объектов СЭДО на основании
данных, полученных из МРМР
Обеспечивает
конвертацию
файлов
вложений
документов
СЭДО
для
обеспечения функций клиента
Предназначен для наложения штампов на
утвержденные
и
подписанные
ЭП
документы
Позволяет вести систематизированный
перечень дел с указанием необходимых
атрибутов и параметров
Обеспечивает возможность интеграции с
 26
Наименование
модуля / подсистемы
ПО/R7Office
Транспортные
TransportExtensions
№ п/п
Описание и предназначение
Российским офисным ПО (с Р7-Офис)
расширения/ Предназначен для формирования записей в
блоке «Журнал обмена»
Предназначен для рассылки пользователям
системы
почтовых
сообщений
об
Сервис
отправки
почтовых
операциях, выполняемых с карточками
уведомлений/Notification Service
системы, и сообщений о необходимости
выполнения определенных заданий
Предназначен
для
автоматизации
выполнения
периодических
или
отложенных операций над объектами
Сервис периодических задач/Scheduled Job Системами. Особенности выполняемых
Launcher
операций определяется устанавливаемыми
плагинами
(расширениями).
Сервис
обеспечивает запуск плагинов с указанной
при настройке периодичностью
Модуль
Искусственного
интеллекта
Системы электронного документооборота
Министерства экономического развития
Модуль ИИ авторосписи документов
Российской Федерации, использующего
искусственный интеллект в задачах
документооборота
19.
20.
21.
22.
3.4.2
Перечень частей программного обеспечения
Программное обеспечение Системы включает:
–
общее программное обеспечение (далее – ОПО);
–
специальное программное обеспечение (далее – СПО);
–
ПО автоматизированных рабочих мест пользователей.
ОПО Системы обеспечивает:
–
штатное функционирование комплекса технических средств Системы;
–
функционирование СПО;
–
взаимодействие с периферийными устройствами;
–
сетевое взаимодействие;
–
другие необходимые общесистемные функции.
Перечень ОПО Системы представлен в Таблице 4.
Таблица 4 – Перечень ОПО и СПО Системы
Сервер
Продуктивная зона
Программное обеспечение
 27
Сервер
Программное обеспечение
Сегмент закрытого контура
Сервер СУБД
Сервер кворум etcd
Сервер бэкапов
Сервер приложений –
платформа Docsvison 5 Core
ECM и модули СДУ
«Приоритет»
Сервер веб-приложений –
Тонкий клиент
Сервер сервисов
Сервер предпросмотра
Сервер конвертации
Сервер интеллектуального
поиска
Сервер координатор
интеллектуального поиска
Сервер синхронизации АРМ
Astra Linux 1.7
Docker 24.0.2
PostgreSQL 12.16
Astra Linux 1.7
Docker 24.0.2
Astra Linux 1.7
Docker 24.0.2
PostgreSQL 12.16
Astra Linux 1.7
Docker 24.0.2
Sdu astra 90 (Вся функциональность сервера приложений СДУ с
серверными расширениями, установочными скриптами БД и
настроенным КриптоПро CSP)
Reportingsite-astra 5.0.2026.19 (Сайт для расширенных отчетов)
Reportingservice-astra 5.0.2026.19 (Сервис для расширенных отчетов)
Astra Linux 1.7
Docker 24.0.2
Ddmweb-ui-astra 5.20.20.0 (Клиентская часть Тонкого клиента)
Ddmweb-api-astra 5.20.20.0 (REST API сервис Тонкого клиента)
Ddmwebadmin-ui-astra 5.20.20.0 (Административная часть Тонкого
клиента)
Entityextractor-astra 1.0.16.1
Astra Linux 1.7
Docker 24.0.2
Scheduledjoblauncher-astra 5.0.2028.26 (Сервис периодических задач)
Notificationsender-astra 2.0.30.5 (Сервис отправки уведомлений)
Astra Linux 1.7
Docker 24.0.2
R7Office 7.4.0.112
Astra Linux 1.7
Docker 24.0.2
Conversion-service-astra 5.5.0.65 (Сервис конвертации в PDF)
R7Office 7.4.0.112
Astra Linux 1.7
Docker 24.0.2
Elasticsearch 7.15 (утилита для поиска и анализа данных в БД)
elasticsearch-analysis-morphology 7.15
ingest-attachment 7.15
Java (open jdk) 1.8
Cerebro 0.9.2 (инструмент администрирования Elasticsearch)
Astra Linux 1.7
Docker 24.0.2
Elasticsearch 7.15 (утилита для поиска и анализа данных в БД)
elasticsearch-analysis-morphology 7.15
ingest-attachment 7.15
Java (open jdk) 1.8
Cerebro 0.9.2 (инструмент администрирования Elasticsearch)
Astra Linux 1.7
Docker 24.0.2
Cryptopro-proxy (Проксирующий сервер для SSL с шифрованием по
ГОСТ алгоритмам)
 28
Сервер
Балансировщик серверных
узлов
Сервер распределенного
кэша
Сервер файлового
хранилища
Сервер управления
Сервер интеграций
Программное обеспечение
Synchronizationservice-astra 5.27.0.180 (Сервис синхронизации)
Rsa-proxy-astra 19 (Проксирующий сервер для SSL RSA)
Astra Linux 1.7
Docker 24.0.2
Haproxy 2.4.24
KeepAlived 2.0.19
Astra Linux 1.7
Docker 24.0.2
Redis 6.2.6
Astra Linux 1.7
NFS v4
Astra Linux 1.7
Docker 24.0.2
Astra Linux 1.7
Docker 24.0.2
Сегмент открытого контура
Сервер push-уведомлений
Балансировщик серверных
узлов
Сервер управления
Astra Linux 1.7
Docker 24.0.2
Proxyservice 5.26.0.154 (Прокси-сервис сервиса синхронизации)
Astra Linux 1.7
Docker 24.0.2
Haproxy 2.4.24
KeepAlived 2.0.19
Astra Linux 1.7
Docker 24.0.2
Предпродуктивная зона
Сегмент закрытого контура
Сервер СУБД
Astra Linux 1.7
Docker 24.0.2
PostgreSQL 12.16
Сервер приложений –
платформа Docsvison 5 Core
ECM и модули СДУ
«Приоритет»
Astra Linux 1.7
Docker 24.0.2
Sdu astra 90 (Вся функциональность сервера приложений СДУ с
серверными расширениями, установочными скриптами БД и
настроенным КриптоПро CSP)
Reportingsite-astra 5.0.2026.19 (Сайт для расширенных отчетов)
Reportingservice-astra 5.0.2026.19 (Сервис для расширенных отчетов)
Сервер веб-приложений –
Тонкий клиент
Astra Linux 1.7
Docker 24.0.2
Docker 24.0.2
Ddmweb-ui-astra 5.20.20.0 (Клиентская часть Тонкого клиента)
Ddmweb-api-astra 5.20.20.0 (REST API сервис Тонкого клиента)
Ddmwebadmin-ui-astra 5.20.20.0 (Административная часть Тонкого
клиента)
Entityextractor-astra 1.0.16.1
Сервер сервисов
Astra Linux 1.7
Docker 24.0.2
Scheduledjoblauncher-astra 5.0.2028.26 (Сервис периодических задач)
Notificationsender-astra 2.0.30.5 (Сервис отправки уведомлений)
 29
Сервер
Программное обеспечение
Сервер предпросмотра
Astra Linux 1.7
Docker 24.0.2
R7Office 7.4.0.112
Сервер конвертации
Astra Linux 1.7
Docker 24.0.2
Conversion-service-astra 5.5.0.65 (Сервис конвертации в PDF)
R7Office 7.4.0.112
Балансировщик серверных
узлов
Astra Linux 1.7
Docker 24.0.2
Haproxy 2.4.24
KeepAlived 2.4.24
Сервер распределенного кэша Astra Linux 1.7
Docker 24.0.2
Redis 6.2.6
Сервер интеллектуального
поиска
Astra Linux 1.7
Docker 24.0.2
Elasticsearch 7.15
elasticsearch-analysis-morphology 7.15
ingest-attachment 7.15
Java (open jdk) 1.8
Cerebro 0.9.2
Сервер управления
Astra Linux 1.7
Docker 24.0.2
Ansible 2.13
Сервер интеграций
Astra Linux 1.7
Docker 24.0.2
Сервер синхронизации АРМ
Astra Linux 1.7
Docker 24.0.2
Cryptopro-proxy (Проксирующий сервер для SSL с шифрованием по
ГОСТ алгоритмам)
Synchronizationservice-astra 5.27.0.180 (Сервис синхронизации)
Rsa-proxy-astra 19 (Проксирующий сервер для SSL RSA)
Сервер машинного обучения
Astra Linux 1.7
Docker 24.0.2
Сегмент открытого контура
Балансировщик
узлов
серверных Astra Linux 1.7
Docker 24.0.2
Haproxy 2.4.24
KeepAlived 2.4.24
Сервер push-уведомлений
Astra Linux 1.7
Docker 24.0.2
Cryptopro-proxy (Проксирующий сервер для SSL с шифрованием по
ГОСТ алгоритмам)
Сервер управления
Astra Linux 1.7
Docker 24.0.2
Ansible 2.13
 30
Сервер
Программное обеспечение
Сервер мониторинга
Alpine Linux 3.16.1
Zabbix-alpine 6.0.7
Клиентские рабочие места для Астра Линукс 1.7 и выше/ Windows 10 или выше;
работы с веб-клиентом
Р7-Офис / Microsoft Office 2016 или выше;
КриптоПро CSP 4.0 R4 для Windows / КриптоПро CSP 5.0;
Веб-браузер: Яндекс браузер версии 24.x и выше
СПО Системы устанавливается на сервер приложений и взаимодействует со всеми
компонентами Системы.
СПО предназначено для решения поставленных задач Пользователя, реализации
функций разрабатываемых подсистем и разработано с учетом характеристик ОПО объекта
автоматизации и особенностей автоматизируемых процессов.
СПО отвечает следующим требованиям:
–
высокая степень готовности для решения поставленных задач;
–
совместимость программных продуктов в части используемых технических
средств, общего программного обеспечения и общесистемной инфраструктуры в
пределах требований к техническому обеспечению, а также их информационная
совместимость в пределах требований к информационному обмену;
–
3.5
наличие эксплуатационной документации на русском языке.
Взаимодействие с внешними информационными системами
Система
осуществляет
информационное
взаимодействие
со
следующими
информационными системами:
1. Система
межведомственного
электронного
документооборота
(МЭДО):
двусторонний обмен данными в части получения и отправки электронных
документов, а также уведомлений о ключевых этапах их обработки;
2. Единое цифровое окно обратной связи (Платформа обратной связи) федеральной
государственной информационной системы «Единый портал государственных и
муниципальных услуг (функций)» (ПОС): двусторонний обмен в части получения
данных по обращениям граждан, отправки ответов на них и статусов их
рассмотрения. Обмен данными с ПОС осуществляется посредством системы
межведомственного электронного взаимодействия (СМЭВ);
3. Коммутационная платформа сетевого справочного телефонного узла (ССТУ.РФ):
отправка данных о результатах рассмотрения обращений граждан;
 31
4. Интеграция с Официальным сайтом Минэкономразвития Российской Федерации:
односторонний обмен в части передачи информации по статусам обработки
обращений граждан.
 32
4
Требования к работам
Проектные
решения
Системы
должны
отвечать
требованиям
действующего
законодательства Российской Федерации по патентной чистоте.
В целях обеспечения модульности Системы и снижения затрат на её интеграцию и
эксплуатацию
взаимодействие
подсистем
Системы
должно
строиться
на
основе
общепринятых открытых технологических стандартов.
Все доработки, произведенные в результате развития Системы, должны быть
размещены в ОЦОД ПК и не противоречить требованиям положений ТУ ИС ФОИВ ОЦОД
ПК.
4.1
Требование к передаче прав и уровней доступа к Системе
В течение 5 (пяти) рабочих дней с начала выполнения работ за 1 отчетный период
Исполнитель обязан получить на территории Заказчика необходимые атрибуты доступа
(логин и пароль) к ОЦОД ПК и необходимые атрибуты доступа к действующей версии
Системы: параметры подключения к серверам, параметры доступа к экземпляру Системы,
находящейся в эксплуатации.
После получения атрибутов и параметров доступа Исполнитель в течение 1 (одного)
рабочего дня обязан произвести изменение атрибутов доступа.
В течение 5 (пяти) рабочих дней с начала выполнения работ за 1 отчетный период
Исполнитель обязан определить ответственных лиц, для которых предполагается удаленный
доступ к инфраструктуре Заказчика, направить перечень ответственных лиц Заказчику.
Исполнитель не должен разглашать и использовать в своих целях информацию (без
разрешения Заказчика), которая может стать ему известной в ходе выполнения работ, а также
не должен передавать информацию третьим лицам без письменного разрешения Заказчика.
Исполнитель обязан использовать доступ к информационным ресурсам Заказчика
только в целях выполнения работ и не распространять в любой форме любые материалы,
содержащиеся на серверах и прочих средствах хранения информации Заказчика. Исполнитель
несет ответственность за соблюдение данных требований в соответствии с законодательством
Российской Федерации.
4.2
Численность, квалификация персонала и режим его работы
Численность персонала и необходимый уровень квалификации определяется
Исполнителем таким образом, чтобы обеспечить выполнение требований к выполнению
работ, указанных в настоящем ТЗ.
 33
Исполнитель в течение 5 (пяти) рабочих дней с начала выполнения работ направляет
Заказчику информацию о представителе (представителях) Исполнителя, ответственном за
организацию информационной безопасности, разработку программного обеспечения,
администрирование, тестирование Системы, предоставление аналитики и иных штатных и
(или) привлекаемых специалистах, задействованных в реализации соответствующих
процессов, предусмотренных ГОСТ Р 56939-2024 «Защита информации. Разработка
безопасного программного обеспечения. Общие требования».
Режим работы персонала должен соответствовать действующему законодательству
Российской Федерации и обеспечить выполнение работ Исполнителем в соответствии с
требованиями к качеству, режиму и периодичности выполнения работ, определенными
настоящим ТЗ.
Заказчик вправе запросить заверенные копии документов, подтверждающих
квалификацию персонала, в том числе дипломов, протоколов подготовки специалистов, и
провести проверку соответствия заявленных в них сведений фактическим в отношении всех
или отдельных работников Исполнителя.
4.3
Требования к характеристикам взаимосвязей Системы со смежными
системами, требованиям к ее совместимости
Взаимодействие с внешними системами должно осуществляться с помощью
интеграционных модулей или веб-сервисов путем обмена структурированными файлами в
специализированных форматах.
Информационное
взаимодействие
СЭДО
с
внешними
системами
должно
осуществляться только при наличии технических возможностей по взаимодействию с
интегрируемыми системами.
Перечень внешних информационных систем, с которыми интегрирована СЭДО,
приведен в п.3.5.
4.4
Требования к информационной безопасности
Каждое средство защиты информации, поставляемое в составе общесистемного
и специального программного обеспечения (ОПО и СПО) в рамках работ по развитию
Системы, а также СЗИ, уже присутствующее в текущей версии Системы (независимо от того,
изменяется ли соответствующий компонент Системы (подсистема, модуль, функция) в рамках
Контракта), должно иметь действующий сертификат соответствия ФСТЭК России и/или ФСБ
России на встроенные функции защиты информации на момент поставки и в течение всего
гарантийного срока по Контракту. Исполнитель или фирма-производитель ПО обязаны
 34
обеспечивать официальную техническую поддержку СЗИ до окончания гарантийного срока,
включая выпуск обновлений для устранения уязвимостей, критических обновлений
безопасности и бюллетеней по безопасности. Прекращение поддержки или истечение срока
сертификата ранее указанных сроков не допускается, за исключением замены СЗИ на
равноценное с действующим сертификатом. В случае выявления в ходе выполнения работ по
развитию Системы СЗИ, не имеющего действующего сертификата (в том числе в компонентах
Системы, не затрагиваемых развитием), Исполнитель обязан предоставить Заказчику план
приведения таких СЗИ в соответствие требованиям ФСТЭК России и/или ФСБ России (замена,
модернизация, изоляция с компенсирующими мерами).
В
случае
выявления
Исполнителем
необходимости
при
развитии
Системы
использовать средства защиты информации сторонних фирм-производителей, то все
используемое ОПО и СПО должно иметь совместимость с данными средствами защиты
информации сторонних фирм-производителей.
В
случае
использовать
выявления
шифровальные
Исполнителем
необходимости
(криптографические)
при
средств
развитии
защиты
Системы
информации
(далее – СКЗИ), Исполнитель должен обеспечить неукоснительное соблюдение требований
формуляров на СКЗИ, в частности, на требование, касающееся проведения оценки влияния
среды функционирования СКЗИ на выполнение предъявленных к СКЗИ требований.
Проведение работ по оценке влияния среды функционирования СКЗИ на выполнение
предъявленных к СКЗИ требований является обязательным условием действия сертификата на
СКЗИ, в соответствии с которым СКЗИ обеспечивает заданный уровень информационной
безопасности при выполнении требований эксплуатационной документации согласно
формуляру на СКЗИ.
В соответствии с Положением о разработке, производстве, реализации и эксплуатации
шифровальных (криптографических) средств защиты информации, утвержденным приказом
ФСБ России от 9 февраля 2005 г. № 66 (далее – Положение ПКЗ-2005), оценка влияния
аппаратных,
программно-аппаратных
и
программных
средств
сети
(системы)
конфиденциальной связи, совместно с которыми предполагается штатное функционирование
СКЗИ, на выполнение предъявленных к ним требований осуществляется Исполнителем
совместно со специализированной организацией. Результаты исследований оценки влияния
аппаратных,
программно-аппаратных
и
программных
средств
сети
(системы)
конфиденциальной связи, совместно с которыми предполагается штатное функционирование
СКЗИ, на выполнение предъявленных к ним требований, а также опытные образцы СКЗИ
и аппаратные, программно-аппаратные и программные средства, необходимые для штатного
 35
функционирования СКЗИ, передаются в ФСБ России для проведения экспертизы, по итогам
которой утверждается заключение ФСБ России по результатам оценки влияния.
В случае применения Исполнителем при развитии Системы СКЗИ, не имеющего
положительного заключения ФСБ России по результатам оценки влияния аппаратных,
программно-аппаратных и программных средств, если такое требование установлено
в формуляре на это СКЗИ, приводит к нарушению п. 46 Положения ПКЗ-2005 и влечет за
собой
административную
ответственность
операторов
персональных
данных,
предусмотренную ч. 6 ст. 13.12. Кодекса Российской Федерации об административных
правонарушениях.
Применяемые меры обеспечения информационной безопасности должны быть
достаточными для предотвращения
рисков, связанных с
возможным нарушением
конфиденциальности, целостности и доступности информации, содержащейся в Системе.
Развитие Системы должно осуществляться на базе программного обеспечения,
соответствующего требованиям законодательства Российской Федерации, приведенного в ТЗ,
в том числе на предмет обеспечения соответствующего уровня защиты в отношении
персональных данных по согласованию с Заказчиком.
Исполнитель в рамках выполнения работ должен провести проверку развернутой
версии Системы на наличие уязвимостей программного обеспечения с использованием
программного обеспечения представленного на официальном сайте ФСТЭК России по адресу
в
сети
Интернет:
https://bdu.fstec.ru/scanoval
и/или
https://bdu.fstec.ru/scanovalforlinux,
а в случае невозможности применения иного программного обеспечения, указанного
в Государственном реестре сертифицированных средств защиты и направляет результаты
проверки Заказчику с приложением плана по устранению выявленных уязвимостей (далее –
проверка на наличие уязвимостей программного обеспечения). В случае невозможности
проведения проверки на наличие уязвимостей программного обеспечения Системы
указанным выше программным обеспечением, при наличии действующей лицензии ФСТЭК
России на деятельность по технической защите конфиденциальной информации Исполнитель
в соответствии с подпунктом «б» пункта 4 Положения о лицензировании деятельности по
технической защите конфиденциальной информации, утвержденного постановлением
Правительства Российской Федерации от 3 февраля 2012 г. № 79 направляет соответствующее
заключение
от своего имени, либо от субподрядной организации, имеющей указанную лицензию.
Порядок оценки уровня критичности уязвимостей программных, программноаппаратных средств и принятие мер защиты информации, направленных на устранение
уязвимостей, определяется в соответствии с Методикой оценки уровня критичности
 36
уязвимостей программных, программно-аппаратных средств (утв. Федеральной службой по
техническому и экспортному контролю 30 июня 2025 г.).
Результаты проверки на наличие уязвимостей программного обеспечения должны быть
представлены в виде Отчета о проведении проверки на наличие уязвимостей программного
обеспечения, включающего в себя отчет, полученный в результате работы программного
обеспечения для автоматизированных проверок на наличие уязвимостей, либо заключение в
соответствии с подпунктом «б» пункта 4 Положения о лицензировании деятельности по
технической защите конфиденциальной информации, утвержденного постановлением
Правительства Российской Федерации от 3 февраля 2012 г. № 79.
После выполнения проверок на наличие уязвимостей программного обеспечения
Системы Исполнитель должен определить перечень уязвимостей, для устранения которых
требуется доработка СПО Системы. Соответствующие требования к доработке СПО Системы,
необходимые для устранения уязвимостей, должны быть включены в ЧТЗ на развитие
Системы и (при необходимости) в ЧТЗ на СЗИ.
Все
выполняемые
работы
в
части
информационной
безопасности
должны
осуществляться с учетом положений Федерального закона от 4 мая 2011 г. № 99-ФЗ
«О лицензировании отдельных видов деятельности», приказа ФСТЭК России от 11 апреля
2025 г. № 117 «Об утверждении требований о защите информации, содержащейся
в
государственных
информационных
системах,
иных
информационных
системах
государственных органов, государственных унитарных предприятий, государственных
учреждений», Приказа ФСБ России от 22 августа 2026 г. № 321 «Об утверждении Требований
о защите информации, содержащейся в государственных информационных системах, иных
информационных
системах
государственных
органов,
государственных
унитарных
предприятий, государственных учреждений, а также при использовании технических средств
и программ для электронных вычислительных машин и баз данных в соответствии с частью
5.1 статьи 13 Федерального закона от 27 июля 2006 г. N 149-ФЗ «Об информации,
информационных технологиях и о защите информации" с использованием шифровальных
(криптографических) средств», постановления Правительства Российской Федерации
от 1 ноября 2012 г. № 1119 «Об утверждении требований к защите персональных данных
при их обработке в информационных системах персональных данных» и приказа ФСТЭК
России от 18 февраля 2013 г. № 21 «Об утверждении Состава и содержания организационных
и технических мер по обеспечению безопасности персональных данных при их обработке
в информационных системах персональных данных», Методики испытаний систем защиты
информации
информационных
систем
методами
тестирования
на
проникновение,
утв. ФСТЭК России 25 июня 2025 г., Методики анализа защищенности информационных
 37
систем, утвержден ФСТЭК России 25 ноября 2025 г., и иных указаний ФСТЭК России
и(или) ФСБ России о мерах по повышению защищенности информационной инфраструктуры
Российской Федерации. В случае, если указанные документы утратят силу в период
исполнения Контракта, необходимо руководствоваться действующими документами,
принятыми взамен утративших силу.
В течение 15 (пятнадцати) календарных дней (включительно) с начала выполнения
работ за 1 отчетный период Исполнитель обязан:
– определить ответственных лиц, ответственных за обеспечение информационной
безопасности,
имеющее
квалификацию,
позволяющую
реализовывать
требования
безопасности информации.
– определить ответственных лиц, для которых предполагается удаленный доступ к
информационной инфраструктуре, согласовать с Заказчиком состав ответственных лиц и
количество учетных записей, с которых предполагается удаленный доступ к информационной
инфраструктуре;
– организовать для ответственных лиц выделение автоматизированных рабочих мест:

не имеющих сторонних подключений;

не использующихся в личных целях;

к которым применяются корпоративные меры по информационной
безопасности Исполнителя;

с установленными на них сертифицированными средствами защиты
информации, реализующими аутентификацию и идентификацию
Пользователей, а также антивирусную защиту.
– согласовать с Заказчиком перечень IP-адресов, с которых может осуществляться
подключение работников Исполнителя и отразить информацию в перечне ответственных лиц,
в т. ч. лиц, для которых предполагается удаленный доступ к инфраструктуре, и информация об
их рабочих местах;
– предоставить Заказчику актуальный документ «Перечень ответственных лиц, в том
числе лиц, для которых предполагается удаленный доступ к инфраструктуре и информация об
их рабочих местах»;
– предоставить Заказчику политику информационной безопасности Исполнителя,
результаты внутренних (внешних) аудитов информационной безопасности, результаты
тестирования на проникновение инфраструктуры Исполнителя, план реагирования на
компьютерные инциденты, а также регламент действий работников Исполнителя в случае
нештатных ситуаций (при наличии);
 38
– предоставить Заказчику рассчитанный показатель защищенности инфраструктуры
Исполнителя, в том числе значения частных показателей безопасности (по форме
в соответствии с Приложением А к настоящему ТЗ), с подтверждающими документами
и материалами, на основании которых показателю присваивается значение, в соответствии
с методическим документом «Методика оценки показателя состояния технической защиты
информации в информационных системах и обеспечения безопасности значимых объектов
критической информационной инфраструктуры Российской Федерации», утвержденным
ФСТЭК России 11 ноября 2025 года.
В случае изменения состава указанных ответственных лиц Исполнитель обязан
уведомлять Заказчика о фактах таких изменений в течение 1 рабочего дня.
Исполнитель несет ответственность в соответствии с действующим законодательством
Российской Федерации за реализацию угроз безопасности при удаленном доступе к Системе с
использованием средств криптографического защиты информации и/или учетных записей,
предоставленных работникам Исполнителя.
Исполнитель должен обеспечивать защиту информации, обрабатываемую в Системе, в
целях:
а) недопущения (снижения возможности) наступления негативных последствий
(событий) от нарушения конфиденциальности, целостности, доступности информации (далее
- нарушение безопасности информации);
б) недопущения (снижения возможности) наступления негативных последствий
(событий) от нарушения функционирования информационных систем вследствие реализации
(возникновения) угроз безопасности информации.
Исполнитель обязан при выполнении работ на развитие руководствоваться
утвержденной Заказчиком политикой защиты информации, а также утвержденными
Заказчиком внутренними регламентами по защите информации.
Исполнитель обязан исключить использование программного обеспечения для
удаленного управления собственными автоматизированными рабочими местами Исполнителя
(например, TeamViewer, AnyDesk, AmmyAdmin, AeroAdmin, Radmin, LiteManager, Удаленный
рабочий стол Chrome, Microsoft Remote Assistance, Microsoft Remote Desktop и аналогичное
схожим функционалом ПО).
Исполнителем во взаимодействии с Заказчиком в указанный 15-дневный срок должны
быть определены каналы для оперативного взаимодействия (в том числе резервные каналы
взаимодействия) ответственных лиц по обеспечению информационной безопасности
со стороны Исполнителя и Заказчика, а также порядок такого взаимодействия. Для
 39
оперативного взаимодействия с Заказчиком должны использоваться не персонализированные,
а официальные каналы взаимодействия.
До начала выполнения работ Исполнитель обязан реализовать следующие базовые
меры по информационной безопасности в собственной ИТ – инфраструктуре (инструментам и
оборудованию Исполнителя, применяемому для выполнения работ), результаты которых
указать в Декларации о выполнении указанных мер и мероприятий по защите информации в
ИТ-инфраструктуре Исполнителя:
– двухфакторная аутентификация пользователей;
– антивирусная защита автоматизированных рабочих мест и серверов;
– защищенное удаленное подключение с использованием средств криптографической
защиты информации;
– защита почтовых сервисов от фишинга;
– защищенный обмен файлами и информацией через файловое хранилище;
– обеспечение процесса управления уязвимостями;
– реализация парольной политики (длина пароля должна быть не менее 15 символов,
пароль должен содержать буквы верхнего и нижнего регистра (А-Я, A-Z, а-я, a-z), цифры (0-9),
специальные
символы
(~!@#$%^&*()-+_={}[]’”<>?/\|),
в
пароле
не
должно
быть
персонифицированной информации (имен, адресов, даты рождения, телефонов). Запретить
использование комбинаций соседних клавиш и словарных слов. Пароли от учетных записей на
разных сервисах должны отличаться. Пароли от учетной записи Исполнителя и учетной
записи заказчика должны отличаться). Не использовать пароли «по умолчанию» (запретить
использование
комбинаций,
которые
присутствуют
в
предустановленных
списках
стандартных паролей производителей; указаны в документации к ПО как заводские; входят
в топ-N наиболее часто используемых паролей. Система должна блокировать установку таких
паролей на этапе создания/смены).
При выполнении работ и при информационном взаимодействии в ходе выполнения
работ Исполнитель обязан использовать электронные почтовые сервисы, инфраструктура
которых полностью расположена на территории Российской Федерации.
Исполнитель обязан уведомлять Заказчика о наступлении в своей инфраструктуре
(непосредственно задействованной в выполнении работ по настоящему ТЗ) компьютерных
инцидентов.
Исполнителем должна вестись запись всех действий работников Исполнителя
(событий)
на
АРМ
Исполнителя
при
осуществлении
удаленного
подключения
к инфраструктуре Заказчика со сроком хранения журналов событий не менее 1 года. В случае
возникновения инцидента информационной безопасности в собственной ИТ-инфраструктуре
 40
Исполнителя, Исполнитель обязан предоставлять указанные журналы событий Заказчику.
Состав передаваемой информации в журналах должен быть определен Исполнителем в своей
инфраструктуре (ГОСТ Р 59709-59712 2022 г.).
Подключения работников Исполнителя к инфраструктуре Заказчика должны
осуществляться в периоды установленного рабочего времени Заказчика. В случае
необходимости доступа к инфраструктуре Заказчика в периоды вне рабочего времени такие
подключения должны быть согласованы с Заказчиком.
Удаленный сетевой доступ должен осуществляться с применением средств
криптографической защиты информации, при этом обмен ключами шифрования необходимо
осуществлять по алгоритмам, исключающим их раскрытие сторонним лицам. Маршруты
сетевого трафика не должны проходить по сторонним сетям в незашифрованном виде.
Система
оснащена
сертифицированными
средствами
защиты
и
должна
эксплуатироваться в соответствии с требованиями по информационной безопасности,
указанными
в
аттестате
соответствия,
внутренними
стандартами,
требованиями
по безопасности информации, требованиями к эксплуатации, техническому обслуживанию,
ремонту и хранению компонентов системы, определяемыми производителями средств защиты
информации, внутренними регламентами Заказчика и Оператора ОЦОД ПК, где размещена
Система.
При реализации функций по защите информации должны использоваться:
– встроенные средства защиты информации: возможности и механизмы защиты
информации, предоставляемые операционными системами, системами управления базами
данных и приложениями;
– иные средства защиты информации: программные, программно-технические
средства, предназначенные для выполнения требований по безопасности информации, не
реализуемые встроенными средствами защиты информации.
Применяемые средства защиты информации должны быть сертифицированы по
требованиям безопасности информации Российской Федерации. Классы защиты и уровни
доверия применяемых при развитии Системы сертифицированных средств защиты
информации и средств криптографической защиты информации должны соответствовать
классу защищенности Системы.
Не допускается применение СрЗИ, странами происхождения которых являются
иностранные государства, совершающие в отношении Российской Федерации, российских
юридических лиц и физических лиц недружественные действия, либо производителями
которых являются организации, находящиеся под юрисдикцией таких иностранных
государств, прямо или косвенно подконтрольные им либо аффилированные с ними.
 41
В случае, если в ходе исполнения настоящего Контракта в адрес Заказчика поступит
решение
ФСБ
России
(или
ФСТЭК
России)
о
необходимости
осуществления
организационных и технических мер, связанных с обеспечением информационной
безопасности, Заказчик совместно с Исполнителем должны определить, затрагивают
ли указанные меры развиваемую Систему, и в случае, если затрагивают – разработать
и согласовать план мероприятий по выполнению указанных мер (в части развиваемой
Системы и в пределах компетенций и ответственности Заказчика и Исполнителя), с указанием
сроков реализации мер и ответственных (Заказчик или Исполнитель). К компетенции
Исполнителя относятся вопросы, связанные с дорабатываемым программным обеспечением
Системы, включая вопросы интеграционного взаимодействия с внешними системами.
Требования к СЗИ должны определяться в зависимости от класса защищенности
и актуальных угроз безопасности информации, включенных в модель угроз безопасности
информации Системы. Указанные требования включаются в ЧТЗ на СЗИ с учетом требований
нормативной
правовой
базы
в
области
защиты
информации
государственных
информационных систем.
Программное обеспечение Системы должно разрабатываться Исполнителем с учетом
ГОСТ Р 56939-2024. «Защита информации. Разработка безопасного программного
обеспечения. Общие требования», ГОСТ Р 71207–2024. «Защита информации. Разработка
безопасного программного обеспечения. Статический анализ программного обеспечения.
Общие требования», ГОСТ Р 58412-2019. «Защита информации. Разработка безопасного
программного обеспечения. Угрозы безопасности информации при разработке безопасного
программного обеспечения» и по согласованию с Заказчиком.
Выполняемые работы в части защиты информации должны осуществляться с учетом
положений Федерального закона от 4 мая 2011 г. № 99-ФЗ «О лицензировании отдельных
видов деятельности».
При возникновении необходимости выполнения работ в части обеспечения защиты
информации, требующих наличия лицензий, Исполнитель обязан предоставить Заказчику
копии действующих лицензий Исполнителя либо субподрядной организации в случае ее
привлечения (в случае выполнения работ в области информационной безопасности,
требующих наличия такой лицензии):
– лицензия ФСБ России, дающая право на осуществление работ, предусмотренных
пунктами 13, 28 Перечня выполняемых работ, составляющих лицензируемую деятельность,
в отношении шифровальных (криптографических) средств, являющегося приложением
к Положению о лицензировании деятельности по разработке, производству, распространению
шифровальных(криптографических)
средств,
информационных
систем
 42
и
телекоммуникационных
систем,
защищенных
с
использованием
шифровальных
(криптографических) средств, выполнению работ, оказанию услуг в области шифрования
информации, техническому обслуживанию шифровальных (криптографических) средств,
информационных систем и телекоммуникационных систем, защищенных с использованием
шифровальных (криптографических) средств (за исключением случая, если техническое
обслуживание шифровальных (криптографических) средств, информационных систем и
телекоммуникационных
(криптографических)
систем,
средств,
защищенных
с
осуществляется
для
использованием
обеспечения
шифровальных
собственных
нужд
юридического лица или индивидуального предпринимателя), утвержденному постановлением
Правительства Российской Федерации от 16 апреля 2012 г. № 313 (далее – Перечень):
на осуществление работ в соответствии с пунктом 13 Перечня. Монтаж, установка
(инсталляция), наладка защищенных с использованием шифровальных (криптографических)
средств информационных систем;
на осуществление работ в соответствии с пунктом 28 Перечня. Изготовление и
распределение ключевых документов и (или) исходной ключевой информации для выработки
ключевых документов с использованием аппаратных, программных и программноаппаратных средств, систем и комплексов изготовления и распределения ключевых
документов для шифровальных (криптографических) средств.
– лицензия ФСТЭК России на деятельность по технической защите конфиденциальной
информации на работы и услуги, предусмотренные подпунктами «б», «в», «д» и «е» пункта 4
Положения о лицензировании деятельности по технической защите конфиденциальной
информации,
утвержденного
постановлением
Правительства
Российской
Федерации
от 3 февраля 2012 г. № 79:
услуги
по
контролю
защищенности
конфиденциальной
информации
от несанкционированного доступа и ее модификации в средствах и системах информатизации
(подпункт «б»);
услуги
по
мониторингу
информационной
безопасности
средств
и
систем
информатизации (подпункт «в»);
работы и услуги по проектированию в защищенном исполнении: средств и систем
информатизации; помещений со средствами (системами) информатизации, подлежащими
защите; защищаемых помещений (подпункт «д»);
услуги по установке, монтажу, наладке, испытаниям, ремонту средств защиты
информации (технических средств защиты информации, защищенных технических средств
обработки информации, технических средств контроля эффективности мер защиты
информации, программных (программно-технических) средств защиты информации,
 43
защищенных программных (программно-технических) средств обработки информации,
программных
(программно-технических)
средств
контроля
эффективности
защиты
информации) (подпункт «е»).
4.5
4.5.1
Требования к Системе в целом
Требования к показателям назначения
Система должна отвечать требованиям обеспечения показателей назначения,
представленным в Таблице 5.
Таблица 5 – Показатели назначения
Операция
Максимальное
время выполнения
Открытие главной страницы Веб-клиента (время аутентификации)
3 секунды
Открытие регистрационной карточки документа (отрисовка первого
элемента карточки)
2 секунды
Открытие карточки задания
2 секунды
Открытие формы создания резолюции
2 секунды
Исполнение задания с предварительно подготовленным отчетом об
исполнении
2 секунды
Создание регистрационной карточки
5 секунд
Создание резолюции
2 секунды
Утверждение резолюции (5 исполнителей)
4 секунды
Предпросмотр файлов PDF не более 10 Мб
3 секунды
Запуск маршрута согласования (5 согласующих)
5 секунд
4.5.2
Требования к надежности
СЭДО должна обеспечивать возможность бесперебойной работы пользователей 7 дней
в неделю и оперативное восстановление работоспособности при возникновении сбоев, аварий
и отказов. Уровень доступности Системы должен быть не менее 99,7%.
Система должна функционировать непрерывно в круглосуточном режиме 365 дней в
году. Допускается временное ограничение полнофункциональной доступности отдельных
частей подсистем Системы:
− в периоды выполнения регламентированных работ по обслуживанию аппаратных и
программных средств Системы, предусмотренных эксплуатационной документацией;
 44
− как результат возникновения внештатных ситуаций, вызванных отказами в работе
аппаратных или программных средств Системы;
− в
случае
частичной
или
полной
потери
работоспособности
внешних
информационных систем-поставщиков первичной информации для Системы;
− во время перехода с одной версии на другую системного или прикладного
программного обеспечения Системы.
Надежность
СЭДО
должна
достигаться
путем
принятия
организационных
и технических мер, обеспечивающих требуемые уровни доступности и надежности.
Технические меры по обеспечению надежности должны предусматривать:
− резервирование критически важных компонентов и данных СЭДО;
− использование технических средств с избыточными компонентами и возможностью
их замены без выключения питания и остановки работы;
− использование программного резервирования (программной избыточности);
− конфигурирование используемых средств и применение ПО, обеспечивающего
высокую надежность.
Организационные меры по обеспечению надежности должны быть обеспечены
Заказчиком и направлены на минимизацию ошибок пользователей (а также обслуживающего
персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени
ремонта или замены вышедших из строя компонентов за счет:
− обеспечения требуемого уровня квалификации пользователей;
− обеспечения требуемого уровня квалификации обслуживающего персонала;
− регламентации и нормативного обеспечения выполнения работ обслуживающего
персонала и пользователей;
− своевременного
оповещения
пользователей
о
случаях
нештатной
работы
компонентов СЭДО;
− своевременной диагностики неисправностей.
4.5.3
Требования к эксплуатации, техническому обслуживанию, ремонту и
хранению компонентов
Система должна быть рассчитана на эксплуатацию в соответствии с требованиями к
эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы,
определяемыми внутренними регламентами Оператора ОЦОД ПК.
Техническая и физическая защита аппаратных компонентов Системы, носителей
данных, бесперебойное энергоснабжение, резервирование ресурсов, создание резервных
 45
копий и текущее техническое обслуживание реализуется техническими и организационными
средствами, предусмотренными в ИТ-инфраструктуре Заказчика.
Для нормальной эксплуатации Системы должно быть обеспечено бесперебойное
питание технических средств, на которых функционирует серверная часть Системы.
Эксплуатация Системы должна быть организована Заказчиком и осуществляться
в соответствии с «Требованиями к порядку создания, развития, ввода в эксплуатацию,
эксплуатации и вывода из эксплуатации государственных информационных систем и
дальнейшего хранения содержащейся в их базах данных информации», утвержденными
постановлением Правительства Российской Федерации от 6 июля 2015 г. № 676.
4.5.4
Требования к режимам функционирования
Функционирование Системы должно предусматривать следующие режимы:
1. Штатный режим: непрерывная круглосуточная работа. В штатном режиме все
основные операции по текущей настройке и обслуживанию Системы выполняются без
приостановки действия Системы. Переход Системы в этот режим должен происходить
автоматически при первоначальном запуске Системы в эксплуатацию или по завершении
других режимов.
Выход из этого режима должен происходить:
− в режим технического обслуживания – вручную по команде администратора
Системы;
− в аварийный режим – автоматически.
2. Технического обслуживания (сервисный): прекращение доступа пользователей к
Системе для выполнения технических работ, обслуживания, реконфигурации Системы. При
переходе в режим технического обслуживания Система завершает обработку данных без
нарушения их целостности и сохраняет свое текущее состояние. Переход в этот режим должен
происходить по команде администратора Системы из штатного или аварийного режима
эксплуатации.
Выход из этого режима должен происходить автоматически при завершении
запланированных операций;
3. Аварийный режим работы – данный режим предполагает полное или частичное
ограничение полнофункциональной доступности Системы, явившееся следствием отказа
аппаратно-программных средств, обеспечивающих их функционирование. Переход Системы
в этот режим должен происходить автоматически.
Выход из этого режима должен происходить:
 46
− автоматически при устранении причины отказа;
вручную по команде администратора Системы в режим технического обслуживания с целью
устранения отказа.
4.5.5
Требования по сохранности информации при авариях
Специалистами, осуществляющими техническую поддержку СЭДО, должна быть
обеспечена защита данных СЭДО от утраты или нарушения целостности в следующих
случаях:
при
сбоях
в
электропитании
серверного
оборудования:
средствами
СУБД,
обеспечивающей сохранность данных в состоянии на момент последней завершенной
транзакции;
при авариях, приведших к невозможности восстановления данных с сервера
СУБД: использованием процедур резервного копирования баз данных СЭДО и хранения
резервных копий на съемном носителе.
Требования к настройкам системы резервного копирования, охват компонентов СЭДО,
глубина отката и параметры резервного копирования устанавливаются в рамках
соответствующего государственного контракта на техническую поддержку СЭДО, а также
зависят от регламентов резервного копирования организации, в инфраструктуре которой
размещена серверная часть СЭДО.
В СЭДО специалистами, осуществляющими техническую поддержку СЭДО, должна
предусматриваться возможность ручного восстановления обрабатываемой информации из
резервной копии в следующих аварийных ситуациях:
физический выход из строя дисковых накопителей;
ошибочные действия обслуживающего персонала.
В СЭДО специалистами, осуществляющими техническую поддержку СЭДО, должно
предусматриваться автоматическое восстановление работоспособности серверной части
СЭДО в следующих ситуациях:
штатное и аварийное отключение электропитания серверной части;
штатная перезагрузка СЭДО и загрузка после отключения;
программный сбой системного ПО, приведший к перезагрузке СЭДО.
В СЭДО специалистами, осуществляющими техническую поддержку СЭДО, должно
предусматриваться полуавтоматическое восстановление работоспособности серверной части
СЭДО в следующих аварийных ситуациях:
физический выход из строя любого аппаратного компонента, кроме дисковых
накопителей: после замены компонента и восстановления конфигурации системного ПО;
 47
аварийная перезагрузка СЭДО, приведшая к не фатальному (исправимому) нарушению
целостности файловой системы: после восстановления файловой системы.
4.5.6
Требования к эргономике и технической эстетике
Взаимодействие пользователей с СЭДО должно осуществляться посредством
визуального графического интерфейса: ввод и вывод данных Системы, прием управляющих
команд и отображение результатов их исполнения должны выполняться в интерактивном
режиме.
Интерфейс должен быть рассчитан на преимущественное использование манипулятора
типа «мышь», управление функциональностью должно осуществляться с помощью набора
экранных меню, кнопок, значков, имеющих однозначную интерпретацию визуализации.
Клавиатурный режим ввода должен использоваться при заполнении и/или редактировании
значений полей экранных форм.
Расположение надписей, элементов управления, ввода и просмотра данных должно
быть логичным и интуитивно понятным.
Надписи экранных форм, а также сообщения, выдаваемые пользователям СЭДО (кроме
служебных системных сообщений), должны быть на русском языке.
СЭДО должна обеспечивать корректную обработку аварийных ситуаций, вызванных
неверными действиями пользователей, неверным форматом или недопустимыми значениями
входных данных. При этом СЭДО должна выдавать пользователям соответствующие
сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной
(недопустимой) команде или некорректному вводу данных.
4.5.7
Требования к информационному обмену между компонентами Системы
Информационный обмен между компонентами Системы и клиентскими приложениями
должен осуществляться по локальной сети и по сети «Интернет».
4.5.8
Требования к патентной чистоте
Патентная чистота СЭДО и ее подсистем должна быть обеспечена в отношении
патентов, действующих на территории Российской Федерации.
Реализация
технических,
программных,
организационных
и
иных
решений,
предусмотренных проектом СЭДО, не должна приводить к нарушению авторских и смежных
прав третьих лиц.
 48
Работы, выполняемые Исполнителем в рамках работ по развитию СЭДО, не должны
включать в себя действия по модификации (переработке) прикладного программного
обеспечения СЭДО. При выполнении работ не должно создаваться новых результатов
интеллектуальной деятельности, в том числе программ для ЭВМ.
4.5.9
Требования по стандартизации и унификации
Экранные формы Системы должны проектироваться с учетом требований
унификации:
–
проводимые работы должны соответствовать требованиям выбора применяемых
решений.
Преимущество
должно
отдаваться
решениям,
основанным
на
стандартизированных технологиях, т.е. прошедшим процедуру стандартизации и
утвержденным в качестве стандарта либо рекомендации каким-либо признанным
международным,
федеральным,
отраслевым,
промышленным
обозначения
типовых
органом
по
стандартизации.
–
термины,
используемые
для
операций,
а
также
последовательности действий пользователя, при их выполнении, должны быть
унифицированы;
–
внешнее поведение сходных элементов интерфейса должно быть реализовано
одинаково для однотипных элементов.
4.6
4.6.1
Требования к видам обеспечений
Требования к организационному обеспечению
В ходе выполнения работ должно обеспечиваться постоянное взаимодействие между
Исполнителем и Заказчиком в части:
–
решения административных вопросов (организация удаленных конференций,
предоставление допусков, рассмотрение и согласование документации и т. п.);
–
решения инженерно-технических вопросов (согласование технических аспектов
реализации и администрирования Системы, определение наличия и размещения
технических средств, коммуникаций и т.п.);
–
нормативно-методического и информационного обеспечения работ (уточнение
функциональных характеристик, предоставление дополнительных сведений).
 49
4.6.2
Требования к методическому обеспечению
Методическое обеспечение включает в себя ознакомление сотрудников Исполнителя с
комплектом проектной и рабочей (эксплуатационной) документацией на Систему и другими
материалами, связанными с выполнением работ (запрашиваемых Исполнителем и
предоставляемых Заказчиком в рабочем порядке).
4.6.3
Требования к лингвистическому обеспечению
Все экранные формы, выходные формы и вся документация разрабатываемая и (или)
актуализируемая в рамках настоящих работ должны быть выполнены на русском языке.
Исключения могут составлять только системные сообщения Системы не подлежащие
русификации и сведения о таких сообщениях, описанные в документации. Набор символов –
кириллица. Цифровая информация должна быть отражена арабскими цифрами.
4.6.4
Требования к программному обеспечению
Программное обеспечение СЭДО должно отвечать следующим требованиям:
обеспечивать совместимость программных продуктов в части используемых
технических
средств,
системного
программного
обеспечения
и
общесистемной
инфраструктуры в пределах требований к техническому обеспечению, а также их
информационную совместимость в пределах требований к информационному обмену при
размещении в ОЦОД;
Веб-клиент Системы должен функционировать в интернет-браузере Яндекс.Браузер
версии 24 и выше;
серверная часть должна функционировать на основе операционных систем,
включенных в Реестр отечественного ПО.
4.7
Требования к функциям (задачам) по развитию Системы
По итогам развития Система должна функционировать в соответствии с требованиями
к развитию, приведенными в разделе 4.7., без утраты существующего функционала Системы,
не затрагиваемого требованиями настоящего ТЗ в части Веб-клиента.
4.7.1
Требования к развитию (адаптации) функционала модуля МЭДО
в части обмена данными с глобальным адресным справочником (ГАС)
Исполнитель должен реализовать взаимодействие со справочником ГАС в части
обеспечения взаимодействия с участниками ГАС второго уровня.
 50
Исполнитель должен выполнить адаптацию функциональности СЭДО путем
интеграции с операторами для обмена документами и уведомлениями в электронном виде
между участниками информационного взаимодействия, поддерживающего формат обмена
МЭДО и схему обмена для оператора, предусмотренной ГАС.
Система должна обеспечивать обмен с организациями, включенными в ГАС, используя
их идентификаторы, полученные из ГАС, в соответствии с форматом МЭДО. Необходимо
произвести настройку Системы для обмена документами и уведомлениями между
участниками информационного взаимодействия (участники второго уровня), через оператора
доставки ГосЭДО, включенного в ГАС.
Исполнитель должен выполнить настройку обмена документами и уведомлениями в
электронном виде с использованием МЭДО с организациями-участниками информационного
взаимодействия, подключенными к ГИС «ТОР СЭД» (далее – организации-участники ГИС
«ТОР СЭД»).
Исполнитель должен выполнить адаптацию СЭДО в части обеспечения отправки
документов ДСП адресату на основании данных, полученных из ГАС. Система должна
выполнять отправку ДСП документов. При отсутствии у адресата возможности приема
документов ДСП, Система не должна выполнять отправку.
Исполнитель должен реализовать вывод уведомления о невозможности передачи ДСП
документа адресату в случае, если адресат не принимает ДСП документы через МЭДО.
Возможность приема адресатом документов ДСП, полученных по МЭДО, должно
проверяться Системой автоматически.
Полный перечень операций, при выполнении которых Система должна осуществлять
проверку возможности приема адресатом документов ДСП, подлежит уточнению на этапе
ЧТЗ.
Исполнитель должен выполнить актуализацию справочника контрагентов СЭДО путем
приведения сведений о юридических лицах в соответствие со справочником контрагентов
ГАС в части наименований (полных и кратких) и адресов. При этом актуализации подлежат
только записи о юридических лицах. В рамках выполнения задач по актуализации данных
контрагентов не должен быть изменен функционал вывода результатов поиска в поисковых
полях.
Исполнитель должен обеспечить обработку Системой входящего технологического
транспортного контейнера со сведениями ГАС, поступающего от организатора или оператора
межведомственного электронного взаимодействия.
 51
4.7.2
Требования к развитию (адаптации) функционала модуля МЭДО
в части поддержки формата обмена данными МЭДО 3.0
Для функционала интеграции с МЭДО должна быть обеспечена адаптация Системы
в части возможности работы с форматом МЭДО 3.0.
В рамках адаптации Веб-клиента Исполнитель должен обеспечить:
 реализацию формирования, приема и отправки ТК «Документ в электронном виде»
в формате 3.0, в том числе содержащего цифровой документ (при необходимости),
и ТК «Цифровой документ ГосЭДО» в формате 3.0. Перечень процессов
взаимодействия и видов документов, для которых применяется транспортный
контейнер «Цифровой документ ГосЭДО», а также состав транспортного
контейнера подлежат уточнению на этапе ЧТЗ:
 реализацию формирования, приема и отправки уведомлений в формате
взаимодействия
МЭДО
3.0
в
составе
документов-уведомлений
в
виде
структурированных данных цифрового документа (файла digital.xml). Перечень
уведомлений и требований к ним должны быть определены на этапе ЧТЗ;
 реализацию формирования, приема и отправки квитанций о техническом приеме
или отказе в приеме электронного сообщения в формате взаимодействия МЭДО
3.0. Требования к квитанциям должны быть уточнены на этапе ЧТЗ;
 реализацию подписания электронной подписью файла структурированных данных
цифрового документа при наличии требования о его подписании. Информация о
подписании документа должна включаться в состав файла digital.xml в формате
XMLDSig. Структура подписи подлежит уточнению на этапе ЧТЗ;
 реализацию формирования файла описания электронного сообщения (message.xml)
в формате 3.0 с заполнением обязательных полей, их состав подлежит уточнению
на этапе ЧТЗ;
 реализацию
формирования
файла
описания
транспортного
контейнера
(passport.xml) в формате 3.0 с заполнением обязательных полей, их состав
подлежит уточнению на этапе ЧТЗ.
Также Исполнитель должен обеспечить создание в СЭДО РК с заполненными
обязательными реквизитами на основании входящих транспортных контейнеров формата 3.0.
и создание внешней резолюции на основании данных ТК, содержащих событие по ЦП.
 52
4.7.3
Требования к развитию (адаптации) функционала СЭДО в части
обмена данными по событиям цифровых поручений второй очереди
Исполнитель должен выполнить адаптацию Веб-клиента для обеспечения поддержки
дополнительных событий при взаимодействии с Аппаратом Правительства Российской
Федерации в части получения и передачи информации по цифровым поручениям (далее – ЦП)
Правительства Российской Федерации в адрес Минэкономразвития России.
Для
указанных
событий
должна
быть
обеспечена
реализация
следующего
функционала:
1.
Пользователь должен иметь возможность направить в Аппарат Правительства
Российской Федерации событие «Запрос изменения срока» по пункту ЦП в случае
необходимости продления срока выполнения поручения.
2.
Пользователь должен иметь возможность направить в Аппарат Правительства
Российской Федерации событие «Представление промежуточного доклада» по пункту ЦП в
случае необходимости отправки промежуточного ответа на поручение.
3.
Прием входящих ТК по событиям «Изменение срока поручения» и «Принятие
информации об исполнении». Определение таких пакетов должно осуществляться по наличию
в составе ТК структурированного файла digital.xml, содержащего данные событий «Изменение
срока поручения» или «Принятие информации об исполнении».
При поступлении вышеуказанных входящих событий в Веб-клиенте должна
автоматически формироваться РК входящего документа.
В сформированных РК должен отображаться читаемый файл формата .html,
преобразованный из файла структурированных данных digital.xml, для обеспечения
возможности просмотра информации по входящим событиям «Изменение срока поручения»
или «Принятие информации об исполнении». Сформированные файлы в формате .html
должны выводиться в область предпросмотра, область файлов, а также должны быть доступны
для загрузки и печати в соответствии с правами доступа на основании ролевой модели Вебклиента. Макеты экранных форм HTML-файлов подлежат уточнению на этапе ЧТЗ.
4.7.4
Требования к развитию (адаптации) функционала СЭДО интеграции с
сайтом Минэкономразвития России в части передачи контактной информации
структурного подразделения Министерства по запросу юридического лица
Исполнитель должен подготовить PG отчет в СЭДО, который будет вызываться
интеграционным
интерфейсом
Минэкономразвития
России.
при
создании
Результаты
запроса
с
официального
отчета
по
искомому
вызова
предоставляются в виде согласованного набора данных.
сайта
документу
 53
Состав поступающих по запросу данных:
1.
номер документа;
2.
дата документа.
Состав возвращаемых данных:
1.
регистрационный номер входящего документа;
2.
дата регистрации документа в СЭДО;
3.
корреспондент;
4.
наименование
структурного
подразделения
(первого
структурного
подразделения - ответственного исполнителя по ветке резолюции).
Если по заданным параметрам запросу удовлетворяют несколько документов, то в PG
отчете должны возвращаться данные по всем отобранным в формате согласованного набора
данных. Формат представления возвращаемых данных по запросу должен быть уточнен на
этапе ЧТЗ.
Исполнитель должен обеспечить консультацию разработчиков официального сайта
Минэкономразвития России в части описания доступных методов интеграционного
интерфейса для вызова отчета PG.
4.7.5
Требования к развитию (адаптации) функционала СЭДО в части
отправки одного исходящего события по нескольким пунктам цифрового
поручения
В рамках адаптации функционала отправки одного исходящего события по нескольким
пунктам ЦП в Веб-клиенте должно быть реализовано:
1. Возможность прикрепления одной исходящей РК в реализацию ЦП к нескольким КЗ
по пунктам ЦП. К данным исходящим событиям должны относиться:
Представление итогового доклада;
Представление промежуточного доклада;
Запрос изменения срока;
Представление предложения соисполнителя.
2. Формирование единого ТК с одним файлом digital.xml.
При отправке исходящей РК с событием ЦП, прикрепленной к нескольким пунктам
ЦП, должен формироваться один контейнер с одним файлом digital.xml, в котором указаны все
данные по сопоставленным пунктам ЦП, к которым прикреплена данная исходящая РК;
3. Формирование записей в журнале обмена по каждому пункту ЦП.
 54
После успешной регистрации и передачи исходящей РК получателям в зависимости от типа
события ЦП в журнал обмена должны добавляться записи по каждой КЗ, на которую была
отправлена исходящая РК.
При возникновении ошибок в ходе передачи ТК с событием ЦП статус записи должен
измениться на «Ошибка». Уведомление должно содержать тип сообщения и комментарий,
соответствующий событиям ЦП.
Состав событий, по которым формируются записи, карточки, в которых формируются
записи, тип сообщений и комментарии к ним должны быть определены на этапе ЧТЗ.
4.7.6
Требования к развитию (адаптации) функционала СЭДО в части
автоматической простановки вида контроля «ВК» по пунктам цифрового
поручения, где Минэкономразвития России является соисполнителем
Для функционала формирования проекта внешней резолюции по событию «Выдача
поручения» для пунктов поручения, в которых Минэкономразвития России является
соисполнителем, Исполнитель должен реализовать автоматическую установку вида контроля
«ВК».
4.7.7
Требования к развитию (адаптации) функционала СЭДО в части
отображения подписанта цифрового поручения в дереве резолюций РК
Для функционала определения подписанта внешней резолюции входящей РК,
сформированной по ЦП, Исполнитель должен реализовать вывод ФИО автора ЦП
на основании данных digital.xml ЦП в поле «Подписал» внешней резолюции РК.
При создании внешней резолюции ЦП в качестве подписанта должны использоваться
сведения об авторе первого по порядку пункта ЦП из digital.xml для текущей организации.
4.7.8
Требования к развитию (адаптации) функционала СЭДО в части
изменения последовательности отображения значений в поле «Номер пункта»
в резолюциях по событиям Цифровых поручений
Исполнитель должен реализовать в Веб-клиенте отображение номеров пунктов ЦП
в формате «разд. 7, п. 4, пп. 2». Указанный формат должен отображаться при создании
внешней резолюции в поле «Номер пункта», в дереве резолюции, а также в записях журнала
МЭДО по событиям ЦП.
Новый формат должен использоваться только для новых РК ЦП.
 55
4.7.9
Требования к развитию (адаптации) функционала СЭДО в части
автоматического указания Министра экономического развития Российской
Федерации исполнителем по пунктам цифрового поручения
Исполнителем в Веб-клиенте должна быть выполнена реализация автоматического
назначения Министра экономического развития Российской Федерации в качестве
исполнителя (с типом исполнения ответственный/соисполнитель) во всех пунктах внешней
резолюции, сформированных автоматически на основании цифрового поручения, в которых
Минэкономразвития России указан в качестве исполнителя/соисполнителя.
Функционал должен распространяться на взаимодействие в формате МЭДО 3.0.
4.7.10
Требования к развитию (адаптации) функционала СЭДО в части
изменения порядка отображения пунктов цифрового поручения
Исполнителем должно быть реализовано отображение пунктов ЦП в автоматически
создаваемой внешней резолюции РК и дереве резолюции в порядке возрастания номеров
разделов, пунктов и подпунктов.
4.7.11
Требования к развитию (адаптации) функционала СЭДО в части
реализации возможности вывода информации в поле «Текст поручения»
в пункте внешней резолюции РК
Исполнителем должна быть выполнена реализация отображения расширенного состава
сведений о поручении в поле «Текст поручения» пункта внешней резолюции РК, создаваемой
по ЦП в Веб-клиенте.
В поле «Текст поручения» пункта внешней резолюции должны отображаться текст
пункта ЦП, сведения об исполнителях, соисполнителях, сроке исполнения и авторе поручения,
сформированные на основании данных digital.xml ЦП. Порядок и формат вывода информации
должны быть уточнены на этапе ЧТЗ.
4.7.12
Требования к развитию (адаптации) функционала СЭДО в части
реализации возможности направления исходящего документа по пунктам
цифрового поручения, созданным вручную во внешней резолюции
Исполнителем должна быть выполнена адаптация механизма формирования
транспортного контейнера исходящих документов по пунктам цифрового поручения,
созданным вручную.
При формировании исходящего транспортного контейнера должно выполняться
сопоставление пунктов, по которым направляется исходящая РК с пунктами ЦП,
 56
полученными из digital.xml входящей РК. Если пункт исходящей РК отсутствует среди
пунктов, содержащихся в digital.xml, такой пункт должен рассматриваться, как созданный
вручную.
Для пунктов, созданных вручную, транспортный контейнер ЦП с файлом digital.xml не
должен формироваться. По таким пунктам должен формироваться исходящий транспортный
контейнер в формате МЭДО 3.0 без файла структурированной информации digital.xml.
Если один исходящий документ связан с несколькими пунктами, созданными вручную,
должен формироваться один транспортный контейнер формата МЭДО 3.0.
Если один исходящий документ связан одновременно с пунктами ЦП, созданными
автоматически на основании файла digital.xml, и пунктами, созданными вручную, должен
формироваться единый исходящий транспортный контейнер ЦП с одним файлом digital.xml. В
файл digital.xml должны включаться только данные по пунктам ЦП, присутствующие в
digital.xml входящей РК. Для пунктов, созданных вручную, отдельный транспортный
контейнер формата МЭДО 3.0 не должен формироваться.
4.7.13
Требования к разработке Частного технического задания на развитие
Системы
Частное техническое задание на развитие Автоматизированной информационной
системы «Система электронного документооборота Минэкономразвития России» (далее –
ЧТЗ, ЧТЗ на развитие Системы) должно быть разработано Исполнителем не позднее 25 ноября
2026 г. и согласовано с Заказчиком.
В ЧТЗ на развитие Системы должны быть учтены требования по размещению Системы
в ОЦОД ПК, включая доработку и дополнительную настройку, обеспечивающую готовность к
проведению аттестации Системы по требованиям информационной безопасности в
соответствии с установленным в Акте классификации системы классом защищенности
государственной информационной системы, уровнем защищенности персональных данных,
обрабатываемых в Системе. При необходимости внесения корректировок в архитектуру
Системы, изменения количества, технических характеристик виртуальных машин, их сетевой
связанности должно быть актуализировано и согласовано с Заказчиком и (или) Оператором
ОЦОД ПК Техническое решение по размещению Системы в облачной инфраструктуре ОЦОД
ПК.
По итогам выполнения данного вида работы и в срок, обозначенный в текущем пункте
настоящего ТЗ, Исполнитель формирует документ ЧТЗ на развитие Системы и направляет его
 57
Заказчику официальным письмом для согласования и утверждения, дублируя на адрес
электронной почты Заказчика.
Заказчик в срок не более 5 (пяти) рабочих дней с даты получения от Исполнителя ЧТЗ
на развитие Системы, утверждает документ, а в случае выявления замечаний, документ
направляется Исполнителю на доработку официальным письмом и дублируется на адрес
электронной почты Исполнителя.
Исполнитель в срок не более 5 (пяти) рабочих дней с даты получения замечаний к
документу, дорабатывает его согласно полученным замечаниям и направляет Заказчику на
повторное согласование официальным письмом и дублируя в электронном виде. В случае
отсутствия разногласий между Исполнителем и Заказчиком, документ ЧТЗ на развитие
Системы утверждается Заказчиком.
4.7.14
Требование к актуализации Модели угроз и Модели нарушителя
информационной безопасности Системы
Документ Модель угроз и модель нарушителя безопасности информации (далее МУиН) должен быть актуализирован с учетом Методики оценки угроз безопасности
информации, утвержденной ФСТЭК России 5 февраля 2021 года. В случае, если в период
действия контракта ФСТЭК России будут утверждены новые (или актуализированы
существующие) материалы, Исполнитель должен их учитывать при актуализации указанного
в настоящем пункте документа.
Содержание документа МУиН должно соответствовать, требованиям о защите
информации, не составляющей государственную тайну, содержащейся в государственных
информационных системах, утверждёнными приказом ФСТЭК России от 11 апреля 2025 г. №
117 «Об утверждении требований о защите информации, содержащейся в государственных
информационных системах, иных информационных системах государственных органов,
государственных унитарных предприятий, государственных учреждений», Методикой оценки
угроз безопасности информации ФСТЭК России от 5 февраля 2021 года, а также учитывать
угрозы безопасности информации, актуальные для информационной телекоммуникационной
инфраструктуры центра обработки данных (далее – ИТКИ ЦОД).
Должны быть актуализированы угрозы безопасности информации, реализация которых
может привести к нарушению безопасности информации в Системе, и разработана
на их основе МУиН.
Документ МУиН не должен противоречить требованиям инфраструктурной площадки,
на которой размещается Система ТУ ИС ФОИВ ОЦОД ПК.
 58
МУиН подлежит согласованию силами Заказчика с ФСБ России и ФСТЭК России
(далее также – уполномоченные органы) в соответствии с требованиями постановления
Правительства Российской Федерации от 6 июля 2015 г. № 676.
В случае, если по результатам указанного согласования потребуется доработка
документа МУиН в соответствии с замечаниями Заказчика, Исполнитель обязан в срок,
установленный Заказчиком и составляющий не менее 10 (десяти) рабочих дней, провести
указанную доработку. МУиН должны быть разработаны и (или) актуализированы
в соответствии с текущим уровнем значимости и с учетом класса защищенности
информационной системы.
МУиН должны быть разработаны и (или) актуализированы Исполнителем с учетом
актуализации перечня мер, подлежащих реализации при развитии Системы в целях
предотвращения появления и устранения уязвимостей Системы в процессе её жизненного
цикла. Выбор и уточнение мер по разработке безопасного СПО должен основываться на
результатах
проводимого
Исполнителем
анализа
угроз
безопасности
информации,
в результате которого должны быть определены актуальные для среды разработки СПО
угрозы безопасности информации.
При определении угроз безопасности информации необходимо использовать банк
угроз ФСТЭК России, а также описания векторов (шаблонов) компьютерных атак,
содержащиеся в базах данных и иных источниках, опубликованных в сети «Интернет»
(CAPEC, ATT&CK, OWASP, STIX, WASC и др.).
4.7.15
Требование
к
актуализации
Частного
технического
задания
на модернизацию системы защиты информации Системы
В случае актуализации модели угроз и модели нарушителя информационной
безопасности Системы и (или) в случае, если это обусловлено составом доработок в ЧТЗ
на развитие Системы, Исполнителем должно быть актуализировано ЧТЗ на модернизацию
системы защиты информации Системы (далее – ЧТЗ на СЗИ), состоящее из комплекта
проектной
и эксплуатационной
документации
на
систему
защиты
информации,
определяющее в том числе требования к средствам защиты информации (далее – СрЗИ).
Требования к СЗИ должны определяться в зависимости от класса защищенности
и актуальных угроз безопасности информации, включенных в модель угроз безопасности
информации Системы. Указанные требования включаются в ЧТЗ на СЗИ с учетом требований
нормативной
правовой
базы
в
области
защиты
информации
государственных
информационных систем.
При реализации функций по защите информации должны использоваться:
 59
–
встроенные средства защиты информации: возможности и механизмы защиты
информации, предоставляемые операционными системами, системами
управления базами данных и приложениями;
–
средства защиты информации: программно-технические средства,
предназначенные для выполнения требований по безопасности информации,
не реализуемые встроенными средствами защиты информации.
Применяемые средства защиты информации должны быть сертифицированы
по требованиям безопасности информации Российской Федерации. Классы защиты и уровни
доверия применяемых при развитии Системы сертифицированных средств защиты
информации и средств криптографической защиты информации должны соответствовать
классу защищенности Системы.
Не допускается применение СрЗИ, странами происхождения которых являются
иностранные государства, совершающие в отношении Российской Федерации, российских
юридических лиц и физических лиц недружественные действия, либо производителями
которых являются организации, находящиеся под юрисдикцией таких иностранных
государств, прямо или косвенно подконтрольные им либо аффилированные с ними.
При актуализации ЧТЗ на СЗИ Исполнителем должны быть рассмотрены следующие
базовые меры защиты информации и адаптированы с учетом определенных для Системы
актуальных угроз безопасности (в части развиваемой Системы и в пределах компетенций
и ответственности Заказчика и Исполнителя):
а) идентификация и аутентификация;
б) управление доступом;
в) регистрация событий безопасности;
г) защита виртуализации и облачных вычислений;
д) защита технологий контейнерных сред и их оркестрации;
е) защита сервисов электронной почты;
ж) защита веб-технологий;
з) защита программных интерфейсов взаимодействия приложений;
и) защита конечных устройств;
к) защита мобильных устройств;
л) защита технологий интернета вещей;
м) защита точек беспроводного доступа;
н) антивирусная защита;
о) обнаружение и предотвращение вторжений на сетевом уровне;
п) сегментация и межсетевое экранирование;
 60
р) защита от компьютерных атак, направленных на отказ в обслуживании;
с) защита каналов передачи данных и сетевого взаимодействия.
При актуализации ЧТЗ на СЗИ Исполнитель должен учитывать требования приказа
ФСБ России от 22.08.2026 № 321 «Об утверждении Требований о защите информации,
содержащейся в государственных информационных системах, иных информационных
системах
государственных
органов,
государственных
унитарных
предприятий,
государственных учреждений, а также при использовании технических средств и программ
для электронных вычислительных машин и баз данных в соответствии с частью 5.1 статьи 13
Федерального закона от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных
технологиях и о защите информации» с использованием шифровальных (криптографических)
средств», требования формуляров и оценки влияния среды функционирования на СКЗИ при
разработке. Исполнитель обязан неукоснительно соблюдать требования формуляров
на средства криптографической защиты информации (далее — СКЗИ), в частности,
на требование, касающееся проведения оценки влияния среды функционирования СКЗИ
на выполнение предъявленных к СКЗИ требований. Проведение работ по оценке влияния
среды функционирования СКЗИ на выполнение предъявленных к СКЗИ требований является
обязательным условием действия сертификата на СКЗИ, в соответствии с которым СКЗИ
обеспечивает заданный уровень информационной безопасности при выполнении требований
эксплуатационной документации согласно формуляру, на СКЗИ.
При актуализации ЧТЗ на СЗИ Исполнитель должен учитывать требования Указа
Президента Российской Федерации от 10 октября 2019 г. № 490 «О развитии искусственного
интеллекта в Российской Федерации», Приказа ФСТЭК России от 11 апреля 2025 г. № 117
«Об утверждении требований о защите информации, содержащейся в государственных
информационных системах, иных информационных системах государственных органов,
государственных
обеспечения
унитарных
защиты
предприятий,
информации
при
государственных
учреждений»
использовании
для
в
части
функционирования
информационных систем искусственного интеллекта.
Актуализация ЧТЗ на СЗИ также не должна противоречить требованиям к размещению
Системы в ОЦОД ПК. ЧТЗ на СЗИ должно отражать необходимый перечень изменений
и
дополнительных
настроек
Системы,
обеспечивающих
после
их
реализации
беспрепятственное размещение Системы в ОЦОД ПК.
ЧТЗ на СЗИ должно предусматривать требования к разработке (актуализации в случае,
если ранее такие документы были разработаны) Исполнителем проектных документов
на систему защиты информации Системы, в соответствии с пунктом 8 настоящего ТЗ.
 61
ЧТЗ на СЗИ должно предусматривать требования к разработке и (или) актуализации
Исполнителем проектных и эксплуатационных документов на СЗИ. Перечень проектной
и эксплуатационной документации на СЗИ уточняется Исполнителем у Заказчика в рабочем
порядке в согласованные сроки и предоставляется в каждом отчетном периоде выполнения
работ после завершения работ по развитию Системы и перед проведением предварительных
испытаний, в соответствии с пунктом 6.1 настоящего ТЗ. В случае наличия замечаний
по результатам испытаний Исполнитель должен доработать проектную и эксплуатационную
документацию на СЗИ.
ЧТЗ на СЗИ и МУиН направляются Заказчиком на согласование с федеральным
органом исполнительной власти, уполномоченным в области безопасности, и с федеральным
органом исполнительной власти, уполномоченным в области противодействия техническим
разведкам и технической защиты информации, в пределах их полномочий в части, касающейся
выполнения установленных требований по защите информации. В случае наличия замечаний
к ЧТЗ на СЗИ в процессе согласования, Исполнитель обеспечивает устранение указанных
замечаний, в том числе в рамках гарантийных обязательств.
 62
5
Состав и содержание работ по развитию Системы
Сроки выполнения работ и виды отчётной документации приведены в Таблице 6.
№
п/п
1.
2.
3.
Таблица 6 – Сроки выполнения работ и виды отчетной документации
Результаты работ (материалы,
Содержание работ этапов
Сроки
предоставляемые Заказчику)
Лицензионные
соглашения
и/или лицензионный договор на
Передача
простых
предоставление
простых
В течение 7 календарных
(неисключительных) прав на
(неисключительных) лицензий
дней с даты заключения
программное
обеспечение
на программное обеспечение
контракта
СЭДО
СЭДО
Акт
передачи
неисключительных прав
− Частное
техническое
задание;
даты
заключения
− Модель угроз безопасности
Разработка ЧТЗ, актуализация С
контракта до 25 ноября информации СЭДО;
Модели угроз безопасности
2026 г.
− Частное
техническое
информации СЭДО и ЧТЗ ИБ
задание на создание системы
защиты информации СЭДО
Актуализированная
эксплуатационная
и
программная
документация,
включая:
− Актуализированное
руководство администратора;
− Актуализированное
руководство пользователя.
Комплект документации по
предварительным испытаниям:
− Программа и методика
предварительных испытаний;
− Протокол
проведения
предварительных испытаний;
− Акт о приемке (готовности)
С даты завершения
Проведение работ по адаптации
СЭДО к вводу в опытную
и
проведение
испытаний этапа работ № 2 до 11 эксплуатацию.
декабря 2026 г.
(тестовый контур)
Комплект документации по
опытной эксплуатации:
− Программа и методика
опытной эксплуатации;
− Отчет
о
проведении
опытной эксплуатации;
− Журнал
проведения
опытной эксплуатации;
− Акт о завершении опытной
эксплуатации.
Комплект документации по
приемочным испытаниям:
− Программа и методика
приемочных испытаний;
− Протокол
проведения
приемочных испытаний;
 63
− Акт о приемке (готовности)
СЭДО
в
промышленную
эксплуатацию.
4.
Перенос
функционала
промышленный
контур
аттестационные испытания
Для
выполнения
работ
Актуализированная проектная
документация
на
систему
защиты информации СЭДО,
включая:
− Проект
акта
классификации СЭДО;
− Проектные
решения
системы защиты информации
СЭДО
в С даты завершения этапа Программа
и
методика
и работ № 3 по 20 декабря аттестационных испытаний;
2026г.
−
Протокол
аттестационных испытаний;
−
Заключение
по
результатам
проведения
аттестационных испытаний;
−
Аттестат соответствия
требованиям
по
защите
информации
СЭДО
(при
положительном заключении).
Исполнитель
должен
передать
Заказчику
простые
(неисключительные) лицензии на использование программного обеспечения СЭДО в составе,
необходимом для выполнения требований настоящего ТЗ и перечисленном в таблице 7.
Исполнитель должен предоставить Заказчику неисключительные права на программное
обеспечение в комплекте с лицензионными ключами, передаваемыми на носителе (CD или
DVD) и позволяющими точно идентифицировать программное обеспечение, на которое
передаются неисключительные права. Исполнителем должен быть в явном виде указан весь
перечень передаваемого программного обеспечения и его регистрационные номера в Едином
реестре российских программ для ЭВМ и баз данных.
Таблица 7 – Спецификация программного обеспечения
№
1
Наименование
программы для ЭВМ
из Единого реестра
российских программ
для ЭВМ и баз данных
Простая
(неисключительная)
лицензия
на
ПО
Цифровой КУПОЛ (или
эквивалент)
Состав лицензии
Кол
-во
Класс программ
для электронных
вычислительных
машин
Цифровой
КУПОЛ
(или
эквивалент), Серверный модуль.
Бессрочная лицензия.
Поддерживаются
следующие
способы
проверки
учетных
данных:
− постоянный пароль,
1
03.01 Средства
защиты от
несанкционирова
нного доступа к
информации
 64
№
Наименование
программы для ЭВМ
из Единого реестра
российских программ
для ЭВМ и баз данных
Состав лицензии
−
одноразовый
пароль
(TOTP/sms/e-mail).
Поддерживается
двухфакторная
авторизация с использованием
TOTP,
sms,
e-mail,
push,
аппаратный токен.
Функции
управления
подключенными
информационными системами:
− просмотр/ создание/ удаление
записи об ИС;
−
управление
парольной
политикой для ИС;
− управление политикой токенов
для ИС.
Функции
управления
пользователями/
учетными
записями:
− просмотр/ создание/ удаление
групп пользователей;
− просмотр/ создание/ удаление УЗ
пользователя;
− настройка групп пользователей –
включение/исключение
УЗ
в
группы;
− блокировка/разблокировка УЗ;
− сброс пароля УЗ;
−
настройка
параметров
подключения УЗ, управление
факторами
авторизации
и
аутентификации;
− настройка утверждений для
доступа для УЗ/групп УЗ к ИС.
Функции управления доступом к
ИС:
− предоставления прав доступа к
ИС для УЗ/групп УЗ;
− программная интеграция ЦК и
ИС на уровне ролевой модели ИС
(посредством API ЦК).
Функции журналирования:
− настройка событий, подлежащих
регистрации
(события
Кол
-во
Класс программ
для электронных
вычислительных
машин
 65
№
2
3
4
5
6
Наименование
программы для ЭВМ
из Единого реестра
российских программ
для ЭВМ и баз данных
Состав лицензии
Кол
-во
Класс программ
для электронных
вычислительных
машин
1
03.01 Средства
защиты от
несанкционирова
нного доступа к
информации
Система документационного
управления
«Приоритет»,
Корпоративная редакция, Модуль
интеграции с МЭДО с поддержкой
формата 3.0, Серверная лицензия.
Бессрочная лицензия.
1
Система
документационного
управления
«Приоритет»,
Корпоративная редакция, Модуль
обмена цифровыми поручениями
1.0, Серверная лицензия, пакет
обновлений. Бессрочная лицензия.
1
Docsvision
5,
Core
ЕСМ
корпоративная редакция, набор
серверных компонентов в составе:
Серверная лицензия, 2 серверов в
Кластере баз данных, 6 серверов в
Кластере Сервера приложений,
пакет обновлений. Бессрочная
лицензия.
Система
документационного
1
06.12
Программное
обеспечение
средств
внутреннего
электронного
документооборота
06.12
Программное
обеспечение
средств
внутреннего
электронного
документооборота
06.12
Программное
обеспечение
средств
внутреннего
электронного
документооборота
безопасности,
события
администрирования);
− установление срока хранения
записей журналов;
−
журналирование
действий
пользователей;
− возможность выгрузки журналов
во внешние системы анализа логов.
Функции контроля целостности:
−
выполнение
контроля
целостности
ЦК
(снятия
контрольных сумм ПО);
−
выполнение
контроля
целостности внешних систем.
Простая
Цифровой
КУПОЛ
(или
(неисключительная)
эквивалент),
коннектор,
1
лицензия
на
ПО информационная
система.
Цифровой КУПОЛ (или Бессрочная
лицензия
эквивалент)
(характеристики в соответствии с
пунктом 1).
Простая
(неисключительная)
лицензия
на
ПО
Система
документационного
управления
«Приоритет»
Простая
(неисключительная)
лицензия
на
ПО
Система
документационного
управления
«Приоритет»
Простая
(неисключительная)
лицензия
на
ПО
Docsvision
Простая
1
06.12
 66
№
7
8
9
10
11
12
Наименование
программы для ЭВМ
из Единого реестра
российских программ
для ЭВМ и баз данных
(неисключительная)
лицензия
на
ПО
Система
документационного
управления
«Приоритет»
Простая
(неисключительная)
лицензия
на
ПО
Система
документационного
управления
«Приоритет»
Простая
(неисключительная)
лицензия
на
ПО
Docsvision
Состав лицензии
Кол
-во
управления
«Приоритет»,
Корпоративная
редакция,
Серверный модуль, версия 8.0,
пакет обновлений. Бессрочная
лицензия.
Система
документационного
управления
«Приоритет»,
Корпоративная редакция, АРМ
Руководителя, серверная лицензия,
версия 8.0, пакет обновлений.
Бессрочная лицензия.
1
Docsvision
5,
Core
ЕСМ
корпоративная
редакция,
Универсальный
клиент,
1200
пользователей, пакет обновлений.
Бессрочная лицензия.
1
Простая
(неисключительная)
лицензия
на
ПО
Система
документационного
управления
«Приоритет»
Простая
(неисключительная)
лицензия
на
ПО
Docsvision
Система документационного
управления
«Приоритет»,
Корпоративная
редакция,
Универсальный
клиент,
1200
пользователей, пакет обновлений.
Бессрочная лицензия.
1
Docsvision
5,
Core
ЕСМ
корпоративная
редакция,
Универсальный
клиент,
150
пользователей, пакет расширений.
Бессрочная лицензия.
1
Простая
(неисключительная)
лицензия
на
ПО
Система
документационного
управления
«Приоритет»
Простая
(неисключительная)
лицензия
на
ПО
Система
Система документационного
управления
«Приоритет»,
Корпоративная
редакция,
Универсальный
клиент,
150
пользователей, пакет расширений.
Бессрочная лицензия.
1
Система
документационного
управления
«Приоритет»,
Корпоративная редакция, Модуль
автоматической маршрутизации
1
Класс программ
для электронных
вычислительных
машин
Программное
обеспечение
средств
внутреннего
электронного
документооборота
06.12
Программное
обеспечение
средств
внутреннего
электронного
документооборота
06.12
Программное
обеспечение
средств
внутреннего
электронного
документооборота
06.12
Программное
обеспечение
средств
внутреннего
электронного
документооборота
06.12
Программное
обеспечение
средств
внутреннего
электронного
документооборота
06.12
Программное
обеспечение
средств
внутреннего
электронного
документооборота
06.12
Программное
обеспечение
средств
 67
№
13
14
15
Наименование
программы для ЭВМ
из Единого реестра
российских программ
для ЭВМ и баз данных
документационного
управления
«Приоритет»
Простая
(неисключительная)
лицензия на Средство
криптографической
защиты
информации
«КриптоПро
CSP»
версии 5.0»
Простая
(неисключительная)
лицензия на Программу
«КриптоПро .NET»
Состав лицензии
документов, Серверная лицензия,
пакет обновлений. Бессрочная
лицензия.
Лицензия на обновление СКЗИ
"КриптоПро CSP" до версии 5.0 на
сервере. Бессрочная лицензия.
Лицензия на право использования
ПО "КриптоПро .NET" версии 2.0
на одном сервере. Бессрочная
лицензия.
Простая
(неисключительная)
лицензия
на
ПО
Операционная система
специального
назначения «Astra Linux
Special Edition»
Кол
-во
1
1
Класс программ
для электронных
вычислительных
машин
внутреннего
электронного
документооборота
03.10 Средства
криптографическо
й защиты
информации и
электронной
подписи
03.10 Средства
криптографическо
й защиты
информации и
электронной
подписи
02.07 Средство
управления
базами данных
Лицензия
на
операционную 164
систему специального назначения
«Astra Linux Special Edition» для
64-х разрядной платформы на базе
процессорной архитектуры х86-64,
со встроенным программным
модулем "Защищенная СУБД ОС
ALSE", (Лицензия "Защищенная
СУБД"), уровень защищенности
«Максимальный» («Смоленск»),
РУСБ.10015-01 (ФСТЭК), способ
передачи электронный, на 1
физическое или виртуальное ядро
сервера, сроком на 12 мес. с даты
передачи несключительных прав, с
включенными обновлениями Тип 1
на 12 мес.
OS2101X8618DIGZDBSR02-SO12
В соответствии с п. 1 ч. 1 ст. 33 Федерального закона от 5 апреля 2013 г. № 44-ФЗ
«О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения
государственных и муниципальных нужд» возможность поставки «эквивалента» ПО
по п. 3-15 не предусмотрена, в связи с необходимостью обеспечения взаимодействия
с ПО, используемым Государственным заказчиком.
При необходимости, лицензии на сертифицированную СУБД и иное необходимое для
аттестации ПО предоставляет Исполнитель.
 68
6
Порядок контроля и приемки выполненных работ
6.1
Виды, состав, объем и методы испытаний Системы и ее составных частей
Для приемки адаптированной Системы в промышленную эксплуатацию Исполнитель
при участии Заказчика должен провести ее испытания.
Испытания Системы должны быть проведены в следующем порядке:
–
Предварительные испытания;
–
Опытная эксплуатация;
–
Приемочные испытания;
–
выполнение квалификационного тестирования СПО в соответствии с ГОСТ Р
56939-2024. Национальный стандарт Российской Федерации. «Защита
информации. Разработка безопасного программного обеспечения. Общие
требования», ГОСТ Р 71207—2024 «Национальный стандарт Российской
Федерации. Защита информации. Разработка безопасного программного
обеспечения. Статический анализ программного обеспечения. Общие
требования».
Методы проведения всех видов испытаний Системы и сценарии их проведения должны
быть определены в соответствующих программах и методиках испытаний, которые должны
быть согласованы и утверждены Исполнителем и Заказчиком не позднее 3 (трех) рабочих дней
до даты проведения испытаний.
Испытания
должны
проводиться
в
присутствии
представителей
Заказчика
и Исполнителя, согласно соответствующему документу Программа и методика испытаний.
Порядок устранения замечаний и реализации рекомендаций Заказчика должен быть определен
соответственно виду испытания в документах «Программа и методика предварительных
испытаний», «Программа и методика опытной эксплуатации» и «Программа и методика
приемочных испытаний».
6.1.1
Требования к проведению предварительных испытаний
Предварительные испытания проводят с целью предварительной оценки соответствия
СЭДО требованиям ТЗ и ЧТЗ, а также определения работоспособности и готовности СЭДО к
вводу в опытную эксплуатацию.
Порядок проведения и методы испытаний должны быть приведены в документе
«Программа и методика предварительных испытаний».
При выявлении в ходе испытаний критичных замечаний, исключающих передачу
доработанной СЭДО в опытную эксплуатацию, Исполнитель должен устранить замечания в
 69
согласованные с Заказчиком сроки, и предварительные испытания должны быть проведены
повторно. Критичными замечаниями считаются выявленные ошибки, после которых СЭДО не
может продолжать свою работу.
При выявлении в ходе испытаний некритичных замечаний, не влияющих на решение о
передаче СЭДО в опытную эксплуатацию, они устраняются Исполнителем в рамках опытной
эксплуатации.
Результаты
проведения
предварительных
испытаний
должны
быть
отражены
в Протоколе проведения предварительных испытаний. Протокол проведения предварительных
испытаний должен содержать заключение о готовности (неготовности) СЭДО к опытной
эксплуатации, а также перечень необходимых доработок (при наличии) и рекомендуемые сроки
их выполнения.
В случае успешного проведения предварительных испытаний оформляется Акт
о приемке (готовности) СЭДО к вводу в опытную эксплуатацию.
6.1.2
По
Требования к проведению опытной эксплуатации
результатам
завершения
предварительных
испытаний
(в
соответствии
с требованиями пункта 6.1.1 настоящего ТЗ) должна быть проведена опытная эксплуатация
СЭДО.
Опытную эксплуатацию СЭДО проводят с целью обнаружения и устранения ошибок,
допущенных при развитии (адаптации) СЭДО, проверки готовности пользователей к работе
в условиях функционирования СЭДО, а также корректировки (при необходимости)
документации на СЭДО. Порядок проведения, состав участников и методы испытаний должны
быть приведены в документе «Программа и методика опытной эксплуатации».
Опытная
эксплуатация
проводится
в
течении
7
(семи)
календарных
дней.
По согласованию с Заказчиком сроки проведения опытной эксплуатации могут быть
сокращены.
Пользователи, назначенные Заказчиком для участия в опытной эксплуатации, должны
ознакомиться с актуализированной версией Руководства пользователя.
В ходе опытной эксплуатации Исполнителем ведется Журнал проведения опытной
эксплуатации, в который заносят сведения о продолжительности функционирования Системы,
об отказах, сбоях аварийных ситуациях, изменениях параметров объектов автоматизации,
проводимых корректировках документации и программных средств, наладке технических
средств, а также замечания и пожелания пользователей по удобству эксплуатации Системы.
При выявлении в ходе опытной эксплуатации критичных замечаний, исключающих
передачу доработанной СЭДО на приемочные испытания, срок проведения опытной
 70
эксплуатации продлевается на срок, установленный по согласованию с Заказчиком в целях
устранения Исполнителем выявленных замечаний.
При выявлении в ходе опытной эксплуатации некритичных замечаний, не влияющих на
решение о передаче СЭДО на приемочные испытания, они устраняются Исполнителем до
начала проведения приемочных испытаний. Проверка устранения некритичных замечаний
производится в ходе приемочных испытаний.
Результаты проведения опытной эксплуатации должны быть отражены в Отчете о
проведении опытной эксплуатации.
Опытная эксплуатация завершается оформлением Акта о завершении опытной
эксплуатации.
6.1.3
Требования к проведению приемочных испытаний
По завершении опытной эксплуатации (в соответствии с требованиями пункта 6.1.2
настоящего ТЗ) должны быть проведены приемочные испытания СЭДО. Приемочные
испытания должны быть проведены на территории Заказчика.
Приемочные испытания СЭДО проводят для определения соответствия Техническому
заданию, оценки качества опытной эксплуатации и решения вопроса о возможности приемки в
постоянную эксплуатацию.
Приемочные
испытания
должны
проводиться
комиссией,
состоящей
из
уполномоченных представителей Заказчика и Исполнителя.
Порядок проведения и методы испытаний должны быть приведены в документе
«Программа и методика приемочных испытаний».
При выявлении в ходе испытаний критичных замечаний, исключающих передачу
доработанной СЭДО в промышленную эксплуатацию, Исполнитель должен устранить
замечания в согласованные с Заказчиком сроки, и приемочные испытания должны быть
проведены повторно. Критичными замечаниями считаются выявленные ошибки, после которых
СЭДО не может продолжать свою работу.
При выявлении в ходе испытаний некритичных замечаний, не влияющих на решение о
передаче СЭДО в промышленную эксплуатацию, они устраняются Исполнителем не позднее
срока завершения работ по развитию СЭДО.
Результаты проведения приемочных испытаний должны быть отражены в Протоколе
проведения приемочных испытаний.
По результатам проведения приемочных испытаний оформляется Акт о приемке
(готовности) СЭДО в промышленную эксплуатацию».
 71
6.1.4
Требования
к
мероприятиям
по
подготовке
и
проведению
аттестационных испытаний Системы
По завершению приемочных испытаний (в соответствии с требованиями пункта 6.1.3
настоящего ТЗ) в объеме выполненных работ по развитию Системы, Исполнителем должны
быть проведены мероприятия по подготовке Системы к аттестационным испытаниям,
в соответствии с актуальным Комплектом проектной и эксплуатационной, организационнораспорядительной документацией на систему защиты информации.
Исполнитель должен обеспечить:
–
контроль проверки выполнения требований к защите ПДн при их обработке
в ИСПДн, где результату выполнения работ предоставить Заказчику Проект Акта
проверки выполнения требований к защите ПДн при их обработке в ИСПДН;
–
поставку СрЗИ (в случае необходимости) в соответствии с Ведомостью покупных
изделий, разработанной в рамках ЧТЗ на СЗИ, кроме СрЗИ, поставляемых
Оператором ОЦОД ПК;
–
установку и настройку СрЗИ, находящихся в зоне ответственности Исполнителя
(при необходимости совместно с Заказчиком) после проектирования СЗИ
в соответствии с требованиями нормативных правовых документов в области
защиты информации и эксплуатационной документацией СрЗИ;
–
предоставить Акт установки и настройки средств защиты информации (в случае
необходимости), по результату успешной установки и настройки Исполнителем
СрЗИ.
По завершении мероприятий по подготовке к аттестационным испытаниям должны быть
проведены работы по аттестации СЭДО. В рамках этих мероприятий Исполнитель должен:
–
разработать и согласовать с Заказчиком программу и методики аттестационных
испытаний СЭДО;
–
провести аттестационные испытания на соответствие СЭДО требованиям
безопасности информации;
–
оформить протокол по результатам аттестационных испытаний СЭДО;
–
подготовить заключение о соответствии СЭДО требованиям безопасности
информации;
–
выдать, в случае положительных результатов аттестационных испытаний,
Аттестат соответствия СЭДО требованиям безопасности информации.
Для выполнения работ по аттестации СЭДО Исполнитель вправе привлечь
субподрядную организацию, обладающую соответствующими лицензиями.
 72
Исполнитель приступает к разработке программы и методики аттестационных
испытаний СЭДО и самим испытаниям после предоставления Заказчиком согласованных ФСБ
России и ФСТЭК России модели угроз безопасности информации и частного технического
задания на разработку систему защиты информации.
Аттестационные
испытания
должны
проводиться
с
соблюдением
требований
следующих документов:
–
ГОСТ РО 0043-004-2013. «Аттестация объектов информатизации. Программа и
методика аттестационных испытаний»;
–
Приказ ФСТЭК России от 29 апреля 2021 г. № 77 «Об утверждении Порядка
организации и проведения работ по аттестации объектов информатизации на соответствие
требованиям о защите информации ограниченного доступа, не составляющей государственную
тайну».
По результатам аттестационных испытаний Исполнитель должен актуализировать
комплект организационно-распорядительной документации на СЭДО (состав определяется в
ЧТЗ на разработку систему защиты информации).
В случае, если по результатам аттестационных испытаний будут получены
отрицательное заключение и вывод о невозможности выдачи Аттестата соответствия
требованиям по защите информации на объект информатизации, то Исполнитель обязан в срок,
согласованный Заказчиком, провести устранение недостатков и доработку Системы в рамках
исполнения гарантийных обязательств выполненных работ. При этом срок действия
гарантийных обязательств приостанавливается до даты выдачи Аттестата соответствия
требованиям по защите информации на объект информатизации.
 73
7
Объем и сроки гарантий качества
Предметом
адаптированной
технического
гарантийного
согласно
задания,
обязательства
требованиям
разработанного
является
настоящего
функциональность
Технического
Исполнителем
в
рамках
задания
и
Системы,
Частного
выполнения
работ
и согласованного с Государственным заказчиком.
Если в период гарантийного срока к материалам выполненных работ будут выявлены
замечания со стороны федерального органа исполнительной власти, уполномоченного в области
безопасности, и (или) федерального органа исполнительной власти, уполномоченного в области
противодействия техническим разведкам (в пределах их полномочий), то такие замечания
подлежат устранению Исполнителем в срок, установленный Заказчиком, и составляющий не более
10 (десяти) рабочих дней.
В случае, если по результатам аттестационных испытаний и аттестации Системы на
соответствие требованиям по защите информации будут получены отрицательное заключение
вследствие наличия несоответствий (недостатков) системы защиты информации Системы
требованиям по защите информации и вывод о невозможности выдачи Аттестата соответствия
требованиям по защите информации, то Исполнитель обязан в срок, согласованный Заказчиком,
провести устранение недостатков и доработку Системы за свой счет. При этом срок действия
гарантийных обязательств приостанавливается до даты выдачи Аттестата соответствия Системы
требованиям о защите информации.
На все результаты выполненных Работ устанавливается гарантийный срок 12 (Двенадцать)
месяцев с даты подписания документа о приемке по Государственному контракту.
 74
8
Требования к документированию
8.1
Перечень подлежащих разработке документов
Перечень подлежащих разработке и актуализации комплектов и видов документов
приведен в разделе 5.
8.2
Требования к эксплуатационной и программной документации
Комплект эксплуатационной и программной документации на Систему должен содержать
сведения, обеспечивающие эксплуатацию Системы в соответствии с требованиями к порядку
эксплуатации систем, установленным постановлением Правительства Российской Федерации
от 6 июля 2015 г. № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию,
эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего
хранения содержащейся в их базах данных информации».
При
актуализации
документов
«Руководство
пользователя»
и
«Руководство
администратора» Исполнитель должен отразить в них все изменения в функционировании
системы, реализованных в рамках ГК.
По окончанию выполнения соответствующих этапов работ, а также по Государственному
контракту в целом Исполнитель передает Заказчику отчетные документы, перечисленные
в разделе 5.
Исполнитель представляет Заказчику все отчетные документы по итогу выполнения работ
по Государственному контракту в электронном варианте на носителе без возможности перезаписи
и в 2-х экземплярах в печатном виде.
8.3
Требования по использованию ЕСКД и ЕСПД при разработке документов
При разработке документации дополнительные требования не предъявляются.

=== ФАЙЛ: Извещение_СЭДО_р | docs/0173100008626000034/Извещение_СЭДО_р.pdf
Приложение № 1
к приказу Минэкономразвития России
от «___» _________ 2026 г. № ___
ИЗВЕЩЕНИЕ
о проведении аукциона в электронной форме на право заключить
государственный контракт на выполнение работ по развитию Системы
электронного документооборота Минэкономразвития России
1. Наименование, место нахождения, почтовый адрес Государственного заказчика,
адрес электронной почты, номер контактного телефона, ответственное должностное лицо
Государственного заказчика, специализированной организации:
Наименование Государственного заказчика: Министерство экономического развития
Российской Федерации;
Почтовый адрес (место нахождения): 123112, г. Москва, Пресненская наб., д. 10, стр. 2.
Адрес электронной почты Государственного заказчика: zakupki@economy.gov.ru.
Номер контактного телефона Государственного заказчика: + 7 (495) 870-29-21
(доб. 18363, доб. 18454).
Ответственное должностное лицо Государственного заказчика: Арчаков Магомет
Салангиреевич.
Сведения о специализированной организации: специализированная организация
не привлекается.
2. Идентификационный код закупки: 26 1 7710349494 770301001 0079 001 0000 242.
Информация о проведении закупки в соответствии со статьей 15 Федерального
закона от 5 апреля 2013 г. № 44-ФЗ «О контрактной системе в сфере закупок товаров,
работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Закон):
Закупка в соответствии со статьей 15 Закона не осуществляется.
Информация об осуществлении закупки Работ по государственному оборонному
заказу в соответствии с Федеральным законом от 29 декабря 2012 г. № 275-ФЗ
«О государственном оборонном заказе»:
Закупка Работ по государственному оборонному заказу в соответствии с Федеральным
законом от 29 декабря 2012 г. № 275-ФЗ «О государственном оборонном заказе»
не осуществляется.
3. Используемый способ определения исполнителя: аукцион в электронной форме
(далее – электронный аукцион).
4. Адрес электронной площадки в информационно-телекоммуникационной сети
«Интернет»: www.sberbank-ast.ru.
5. Краткое изложение условий государственного контракта (далее – Контракт):
Наименование объекта закупки: работы по развитию Системы электронного
документооборота Минэкономразвития России (далее – Работы).
Подробное описание объекта закупки, объем выполняемых Работ приведены
в Приложении № 1 к Извещению «Техническое задание».
6. Информация об объеме Работ, о единице измерения:
Наименование Работ
Код по ОКПД2/
КТРУ
Работы по развитию
Системы электронного
58.29.50.000/
58.29.11.000-00000004
Единица
измерения
Условная
единица
Кол-во
Цена за ед., руб.
Стоимость, руб.
1
73 944 099,99
73 944 099,99
 2
документооборота
Минэкономразвития
России
62.01.11.000
7. Информация о месте выполнения Работ: 123112, г. Москва, Пресненская наб., д.10,
стр.2.
Адрес приемки выполненных Работ: 123112, г. Москва, Пресненская наб., д.10, стр.2.
8. Срок исполнения Контракта: с даты заключения Контракта до полного исполнения
Сторонами своих обязательств по Контракту.
Срок выполнения Работ с даты заключения Контракта по 20 декабря 2026 г. включительно,
в том числе:
- этап Работ № 1: в течение 7 календарных дней с даты заключения Контракта;
- этап Работ № 2: с даты заключения Контракта по 25 ноября 2026 г. включительно;
- этап Работ № 3: с даты завершения этапа Работ № 2 по 11 декабря 2026 г. включительно;
- этап Работ № 4: с даты завершения этапа Работ № 3 по 20 декабря 2026 г. включительно.
9. Начальная (максимальная) цена Контракта: 73 944 099 (Семьдесят три миллиона
девятьсот сорок четыре тысячи девяносто девять) рублей 99 копеек, включая НДС, в том числе:
этап Работ № 1 – 26 605 741 (Двадцать шесть миллионов шестьсот пять тысяч семьсот
сорок один) рубль 30 копеек, НДС не облагается в соответствии с пп. 26 п. 2 ст. 149 Налогового
кодекса Российской Федерации;
этап Работ № 2 – 13 797 458 (Тринадцать миллионов семьсот девяносто семь тысяч
четыреста пятьдесят восемь) рублей 15 копеек, включая НДС;
этап Работ № 3 – 31 407 709 (Тридцать один миллион четыреста семь тысяч семьсот
девять) рублей 33 копейки, включая НДС;
этап Работ № 4 – 2 133 191 (Два миллиона сто тридцать три тысячи сто девяносто один)
рубль 21 копейка, включая НДС.
Обоснование начальной (максимальной) цены Контракта приведено в Приложении № 2 к
Извещению «Обоснование начальной (максимальной) цены контракта».
Источник финансирования: федеральный бюджет.
Наименование валюты в соответствии с общероссийским классификатором валют:
Российский рубль.
10. Размер аванса, устанавливаемый в соответствии с Законом:
Выплата аванса не осуществляется.
11. Требования, предъявляемые к участникам электронного аукциона
в соответствии с частью 1 статьи 31 Закона:
1) соответствие требованиям, установленным в соответствии с законодательством РФ
к лицам, осуществляющим поставку товара, выполнение работы, оказание услуги, которые
являются объектом закупки — не установлено;
2) непроведение ликвидации участника электронного аукциона – юридического лица
и отсутствие решения арбитражного суда о признании участника электронного аукциона –юридического лица или индивидуального предпринимателя несостоятельным (банкротом)
и об открытии конкурсного производства;
3) неприостановление деятельности участника электронного аукциона в порядке,
установленном Кодексом Российской Федерации об административных правонарушениях;
4) отсутствие у участника закупки недоимки по налогам, сборам, задолженности
по иным обязательным платежам в бюджеты бюджетной системы РФ (за исключением сумм,
на которые предоставлены отсрочка, рассрочка, инвестиционный налоговый кредит
в соответствии с законодательством РФ о налогах и сборах, которые реструктурированы
в соответствии с законодательством РФ, по которым имеется вступившее в законную силу
 3
решение суда о признании обязанности заявителя по уплате этих сумм исполненной
или которые признаны безнадежными к взысканию в соответствии с законодательством РФ
о налогах и сборах) за прошедший календарный год, размер которых превышает 25 процентов
балансовой стоимости активов участника закупки, по данным бухгалтерской отчетности
за последний отчетный период. Участник закупки считается соответствующим установленному
требованию в случае, если им в установленном порядке подано заявление об обжаловании
указанных недоимки, задолженности и решение по такому заявлению на дату рассмотрения
заявки на участие в определении поставщика (подрядчика, исполнителя) не принято;
5) отсутствие у участника закупки — физического лица либо у руководителя, членов
коллегиального исполнительного органа, лица, исполняющего функции единоличного
исполнительного органа, или главного бухгалтера юридического лица – участника закупки
судимости за преступления в сфере экономики и (или) преступления, предусмотренные
статьями 289, 290, 291, 291.1 Уголовного кодекса (за исключением лиц, у которых такая
судимость погашена или снята), а также неприменение в отношении указанных физических лиц
наказания в виде лишения права занимать определенные должности или заниматься
определенной деятельностью, которые связаны с поставкой товара, выполнением работы,
оказанием услуги, являющихся объектом осуществляемой закупки, и административного
наказания в виде дисквалификации;
6) непривлечение участника закупки — юридического лица в течение двух лет
до момента подачи заявки на участие в закупке к административной ответственности
за совершение административного правонарушения, предусмотренного статьей 19.28 Кодекса
об административных правонарушениях;
7) обладание участником закупки исключительными правами на результаты
интеллектуальной деятельности, если в связи с исполнением контракта заказчик приобретает
права на такие результаты, за исключением случаев заключения контрактов на создание
произведений литературы или искусства, исполнения, на финансирование проката или показа
национального фильма, — не установлено;
8) отсутствие обстоятельств, при которых должностное лицо заказчика (руководитель
заказчика, член комиссии по осуществлению закупок, руководитель контрактной службы
заказчика, контрактный управляющий), его супруг (супруга), близкий родственник по прямой
восходящей или нисходящей линии (отец, мать, дедушка, бабушка, сын, дочь, внук, внучка),
полнородный или неполнородный (имеющий общих с должностным лицом заказчика отца или
мать) брат (сестра), лицо, усыновленное должностным лицом заказчика, либо усыновитель
этого должностного лица заказчика является:
а) физическим лицом (в том числе зарегистрированным в качестве индивидуального
предпринимателя), являющимся участником закупки;
б) руководителем, единоличным исполнительным органом, членом коллегиального
исполнительного органа, учредителем, членом коллегиального органа унитарной организации,
являющейся участником закупки;
в) единоличным исполнительным органом, членом коллегиального исполнительного
органа, членом коллегиального органа управления, выгодоприобретателем корпоративного
юридического лица, являющегося участником закупки. Выгодоприобретателем для целей
настоящей статьи является физическое лицо, которое владеет напрямую или косвенно (через
юридическое лицо или через несколько юридических лиц) более чем десятью процентами
голосующих акций хозяйственного общества либо владеет напрямую или косвенно (через
юридическое лицо или через несколько юридических лиц) долей, превышающей десять
процентов в уставном (складочном) капитале хозяйственного товарищества или общества;
9) участник закупки не является офшорной компанией, не имеет в составе участников
(членов) корпоративного юридического лица или в составе учредителей унитарного
юридического лица офшорной компании, а также не имеет офшорных компаний в числе лиц,
владеющих напрямую или косвенно (через юридическое лицо или через несколько
юридических лиц) более чем 10 процентами голосующих акций хозяйственного общества либо
долей, превышающей 10 процентов в уставном (складочном) капитале хозяйственного
 4
товарищества или общества;
10) участник закупки не является иностранным агентом;
11) отсутствие у участника закупки ограничений для участия в закупках, установленных
законодательством РФ.
11.1 Требование, предъявляемое к участникам электронного аукциона
в соответствии с пунктом 1 части 1 статьи 31 Закона:
Не установлено.
Информация и исчерпывающий перечень документов, которые подтверждают
соответствие участника электронного аукциона требованиям, предъявляемым
в соответствии с пунктом 1 части 1 статьи 31 Закона:
Не установлено.
11.2 Дополнительные требования, предъявляемые к участникам электронного
аукциона в соответствии с частями 2 и 2.1 статьи 31 Закона:
Требования в соответствии с частью 2 статьи 31 Закона не установлены.
В соответствии с частью 2.1 статьи 31 Закона установлено требование об исполнении
участником электронного аукциона (с учетом правопреемства) в течение трех лет до даты
подачи заявки на участие в электронном аукционе контракта или договора, заключенного
в соответствии с Федеральным законом от 18 июля 2011 г. № 223-ФЗ «О закупках товаров,
работ, услуг отдельными видами юридических лиц» при условии исполнения таким участником
электронного аукциона требований об уплате неустоек (штрафов, пеней), предъявленных при
исполнении таких контракта, договора. Стоимость исполненных обязательств по таким
контракту, договору должна составлять не менее двадцати процентов начальной
(максимальной) цены Контракта.
Информация и исчерпывающий перечень документов, которые подтверждают
соответствие участника электронного аукциона требованиям, предъявляемым
в соответствии с частями 2 и 2.1 статьи 31 Закона:
Предоставление информации и документов в соответствии с частью 2 статьи 31 Закона
не предусмотрено.
В соответствии с пунктом 4 постановления Правительства Российской Федерации
от 29 декабря 2021 г. № 2571 «О дополнительных требованиях к участникам закупки отдельных
видов товаров, работ, услуг для обеспечения государственных и муниципальных нужд, а также
об информации и документах, подтверждающих соответствие участников закупки указанным
дополнительным требованиям, и признании утратившими силу некоторых актов и отдельных
положений актов Правительства Российской Федерации» установлено, что информацией
и документами, подтверждающими соответствие участника электронного аукциона
дополнительному требованию, установленному в соответствии с частью 2.1 статьи 31 Закона,
являются:
а) номер реестровой записи в предусмотренном Законом реестре контрактов,
заключенных заказчиками (в случае исполнения участником электронного аукциона контракта,
информация и документы в отношении которого включены в установленном порядке в такой
реестр и размещены на официальном сайте единой информационной системы
в информационно-телекоммуникационной сети «Интернет»);
б) выписка из предусмотренного Законом реестра контрактов, содержащего сведения,
составляющие государственную тайну (в случае исполнения участником электронного
аукциона контракта, информация о котором включена в установленном порядке в такой реестр);
в) исполненный контракт, заключенный в соответствии с Законом, или договор,
заключенный в соответствии с Федеральным законом от 18 июля 2011 г. № 223-ФЗ «О закупках
товаров, работ, услуг отдельными видами юридических лиц», а также акт приемки
 5
поставленных товаров, выполненных работ, оказанных услуг, подтверждающий цену
поставленных товаров, выполненных работ, оказанных услуг.
В соответствии с пунктом 3 части 6 статьи 43 Закона документы, подтверждающие
соответствие участника электронного аукциона дополнительным требованиям, установленным
в соответствии с 2.1 статьи 31 Закона, и предусмотренные подпунктом «н» пункта 1 части 1
статьи 43 Закона, не включаются участником электронного аукциона в заявку на участие
в электронном аукционе. Такие документы в случаях, предусмотренных Законом, направляются
(по состоянию на дату и время их направления) Государственному заказчику оператором
электронной площадки из реестра участников закупок, аккредитованных на электронной
площадке.
В целях обеспечения доступа к участию в проводимых на электронной площадке закупках
отдельных видов товаров, работ, услуг, в отношении участников которых установлены
дополнительные требования в соответствии с частями 2 и 2.1 статьи 31 Закона, участник
закупки, аккредитованный на электронной площадке, направляет оператору этой электронной
площадки в отношении каждого такого вида информацию и документы, предусмотренные
перечнем, установленным Правительством Российской Федерации в соответствии с частью 3
статьи 31 Закона.
В течение 5 (Пяти) рабочих дней со дня, следующего за днем получения в соответствии
с частью 12 статьи 24.2 Закона информации и документов, оператор электронной площадки,
оператор специализированной электронной площадки по каждому виду товаров, работ, услуг,
в отношении которых участником закупки предоставлены такие информация и документы,
принимает решение:
1) о размещении таких информации и документов в реестре участников закупок,
аккредитованных на электронной площадке, реестре участников закупок, аккредитованных
на специализированной электронной площадке;
2) об отказе в размещении таких информации и документов в реестре участников закупок,
аккредитованных на электронной площадке, реестре участников закупок, аккредитованных
на специализированной электронной площадке, в случае:
а) несоответствия перечня представленных информации и документов перечню, который
установлен Правительством Российской Федерации в соответствии с частью 3 статьи 31 Закона;
б) нарушения порядка, установленного Правительством Российской Федерации
в соответствии с частью 15 статьи 24.2 Закона, при направлении таких информации
и документов.
11.3 Требование, предъявляемое к участникам электронного аукциона
в соответствии с частью 1.1 статьи 31 Закона:
Установлено.
Документы, подтверждающие соответствие работ требованиям, установленным
в соответствии с законодательством Российской Федерации (в случае, если в соответствии
с законодательством Российской Федерации установлены требования к работам):
Требования не установлены.
12. Информация
о
предоставлении
преимуществ,
предоставляемых
Государственным заказчиком в соответствии со статьей 28 Закона учреждениям
и предприятиям уголовно-исполнительной системы в отношении предлагаемой ими цены
Контракта:
Преимущества не предоставляются.
Информация о предоставлении преимуществ, предоставляемых Государственным
заказчиком в соответствии со статьей 29 Закона организациям инвалидов в отношении
предлагаемой ими цены Контракта:
Преимущества не предоставляются.
 6
13. Преимущества участия в определении исполнителя в соответствии с частью 3
статьи 30 Закона:
Не установлено.
Требование, установленное в соответствии с частью 5 статьи 30 Закона с указанием
в соответствии с частью 6 статьи 30 Закона объема привлечения к исполнению
контрактов
субподрядчиков,
соисполнителей
из
числа
субъектов
малого
предпринимательства, социально ориентированных некоммерческих организаций:
Исполнитель обязан привлечь к выполнению Работ соисполнителей из числа субъектов
малого предпринимательства, социально ориентированных некоммерческих организаций
в объеме 30 % от цены Контракта.
14. Информация о запрете или об ограничении закупок товаров, о преимуществе
в отношении товаров российского происхождения в соответствии с пунктом 1 части 2
статьи 14 Закона:
В соответствии со статьей 14 Закона и постановлением Правительства Российской
Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима
при осуществлении закупок товаров, работ, услуг для обеспечения государственных
и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»
(далее – Постановление № 1875) установлен запрет на допуск программ для электронной
вычислительной машины и (или) базы данных происходящих из иностранных государств
за исключением государства –- члена Евразийского экономического союза.
Информация и документы, определенные в соответствии с пунктом 2 части 2
статьи 14 Закона:
Информацией и документами, подтверждающими страну происхождения, являются:
- для подтверждения происхождения программ для электронных вычислительных машин и
(или) баз данных (далее – программное обеспечение), указанных в позиции 146 приложения
№ 1 к Постановлению № 1875, из Российской Федерации – порядковый номер реестровой
записи из единого реестра российских программ для электронных вычислительных машин и баз
данных (далее - реестр российского программного обеспечения);
- для подтверждения происхождения программного обеспечения, указанного в позиции
146 приложения № 1 к Постановлению № 1875, из государств – членов Евразийского
экономического союза, за исключением Российской Федерации, – порядковый номер
реестровой записи из единого реестра программ для электронных вычислительных машин и баз
данных из государств – членов Евразийского экономического союза, за исключением
Российской Федерации.
15. Размер и порядок внесения денежных средств в качестве обеспечения заявок
на участие в электронном аукционе, а также условия независимой гарантии:
Размер обеспечения заявки на участие в электронном аукционе составляет 739 441
(Семьсот тридцать девять тысяч четыреста сорок один) рубль 00 копеек, что составляет 1 %
от начальной (максимальной) цены Контракта.
Обеспечение заявки на участие в электронном аукционе может предоставляться
участником электронного аукциона в виде денежных средств или независимой гарантии. Выбор
способа обеспечения заявки на участие в электронном аукционе осуществляется участником
электронного аукциона.
Независимая гарантия, выданная участнику электронного аукциона для целей
обеспечения заявки на участие в электронном аукционе, должна соответствовать требованиям,
указанным в статье 45 Закона. Срок действия независимой гарантии, предоставленной
в качестве обеспечения заявки, должен составлять не менее месяца с даты окончания срока
подачи заявок.
Порядок внесения денежных средств в качестве обеспечения заявок на участие
в электронном аукционе указан в статье 44 Закона.
 7
Участники
электронного
аукциона,
являющиеся
юридическими
лицами,
зарегистрированными на территории государства – члена Евразийского экономического союза,
за исключением Российской Федерации, или физическими лицами, являющимися гражданами
государства
–
члена
Евразийского
экономического
союза,
за
исключением
Российской Федерации, вправе предоставить обеспечение заявок в виде денежных средств
с учетом следующих особенностей:
а) денежные средства вносятся такими участниками электронного аукциона на счет,
указанный в настоящем пункте на котором в соответствии с законодательством Российской
Федерации учитываются операции со средствами, поступающими Государственному
заказчику;
б) заявка на участие в электронном аукционе должна содержать информацию
и документы, подтверждающие предоставление обеспечения заявки на участие в электронном
аукционе, в форме электронных документов или в форме электронных образов бумажных
документов;
в) участник электронного аукциона признается непредоставившим обеспечение заявки
на участие в электронном аукционе в случае непоступления денежных средств, информация
и документы о внесении которых в качестве обеспечения заявки представлены в заявке
на участие в электронном аукционе, до даты подведения итогов определения исполнителя
на счет, указанный в настоящем пункте, на котором в соответствии с законодательством
Российской Федерации учитываются операции со средствами, поступающими
Государственному заказчику. При этом заявка на участие в электронном аукционе, поданная
таким участником электронного аукциона, отклоняется в порядке, установленном для случая,
предусмотренного пунктом 7 части 12 статьи 48 Закона;
г) Государственный заказчик возвращает денежные средства, внесенные
в качестве обеспечения заявки на участие в электронном аукционе, не позднее 5 (Пяти) рабочих
дней со дня, следующего за днем наступления случаев, предусмотренных пунктами 1 – 6 части
10 статьи 44 Закона. Возврат таких денежных средств участнику электронного аукциона
не осуществляется в случае, предусмотренном пунктом 7 части 10 статьи 44 Закона.
Предприятия
уголовно-исполнительной
системы,
организации
инвалидов,
предусмотренные частью 2 статьи 29 Закона, предоставляют обеспечение заявки на участие
электронном аукционе в размере одной второй процента начальной (максимальной) цены
Контракта. Государственные, муниципальные учреждения не предоставляют обеспечение
подаваемых ими заявок на участие в электронном аукционе.
Реквизиты счета, на котором в соответствии с законодательством Российской
Федерации учитываются операции со средствами, поступающими Государственному
заказчику:
Министерство экономического развития Российской Федерации
Почтовый адрес (место нахождения): 123112, г. Москва, Пресненская наб., д. 10, стр. 2.
ИНН 7710349494 КПП 770301001 ОКТМО 45380000
Получатель: Межрегиональное операционное УФК (Минэкономразвития России)
Лицевой счет получателя: № 05951001390
Банк получателя: ОПЕРАЦИОННЫЙ ДЕПАРТАМЕНТ БАНКА
РОССИИ//Межрегиональное операционное УФК г. Москва
БИК ТОФК: 024501901
Единый казначейский счет: 40102810045370000002
Казначейский счет: 03212643000000019502
Код средств (код цели): 0002
Реквизиты счета для перечисления денежных средств в случае, предусмотренном
частью 13 статьи 44 Закона:
Министерство экономического развития Российской Федерации
Почтовый адрес (место нахождения): 123112, г. Москва, Пресненская наб., д. 10, стр. 2.
 8
ИНН 7710349494 КПП 770301001 ОКТМО 45380000
Получатель: Межрегиональное операционное УФК (Минэкономразвития России)
Лицевой счет получателя: 04951001390
Банк получателя: ОПЕРАЦИОННЫЙ ДЕПАРТАМЕНТ БАНКА
РОССИИ//Межрегиональное операционное УФК г. Москва
БИК ТОФК: 024501901
Единый казначейский счет: 40102810045370000002
Казначейский счет: 03100643000000019500
КБК 13911610051019000140
16. Размер обеспечения исполнения Контракта, требования к такому обеспечению,
порядок предоставления такого обеспечения, устанавливаемые в соответствии с Законом,
гарантийный срок:
Условием заключения Контракта является предоставление Исполнителем обеспечения
исполнения Контракта. Размер обеспечения исполнения Контракта составляет
22 183 230 (Двадцать два миллиона сто восемьдесят три тысячи двести тридцать) рублей
00 копеек, что составляет 30 % от начальный (максимальной) цены Контракта, и обеспечивает
надлежащее исполнение обязательств Исполнителя, установленных разделами 1, 2, 4, 5, 6, 7
и пунктом 3.3 (в части предоставления Исполнителем счета/счета-фактуры) Контракта, а также
надлежащее исполнение всех иных обязательств Исполнителя, предусмотренных Контрактом,
за исключением гарантийных обязательств.
В случае, если предложенная Исполнителем цена Контракта ниже на двадцать пять
и более процентов по отношению к начальной (максимальной) цене Контракта, Контракт
заключается только после предоставления Исполнителем обеспечения исполнения Контракта,
обеспечивающего надлежащее исполнение обязательств Исполнителя, установленных
разделами 1, 2, 4, 5, 6, 7, и пунктом 3.3 (в части предоставления Исполнителем счета/счетафактуры) Контракта, а также надлежащее исполнение всех иных обязательств Исполнителя,
предусмотренных Контрактом, за исключением гарантийных обязательств, в размере,
превышающем в полтора раза размер обеспечения исполнения Контракта, что составляет
33 274 845 (Тридцать три миллиона двести семьдесят четыре тысячи восемьсот сорок пять)
рублей 00 копеек в соответствии с частью 1 статьи 37 Закона.
Исполнение Контракта может обеспечиваться предоставлением независимой гарантии,
соответствующей требованиям статьи 45 Закона, или внесением денежных средств на счет,
на котором в соответствии с законодательством Российской Федерации учитываются операции
со средствами, поступающими Государственному заказчику.
Реквизиты счета, на котором в соответствии с законодательством Российской
Федерации учитываются операции со средствами, поступающими Государственному
заказчику:
Министерство экономического развития Российской Федерации
Почтовый адрес (место нахождения): 123112, г. Москва, Пресненская наб., д. 10, стр. 2.
ИНН 7710349494 КПП 770301001 ОКТМО 45380000
Получатель: Межрегиональное операционное УФК (Минэкономразвития России)
Лицевой счет получателя: № 05951001390
Банк получателя: ОПЕРАЦИОННЫЙ ДЕПАРТАМЕНТ БАНКА
РОССИИ//Межрегиональное операционное УФК г. Москва
БИК ТОФК: 024501901
Единый казначейский счет: 40102810045370000002
Казначейский счет: 03212643000000019502
Код средств (код цели): 0002
Способ обеспечения исполнения Контракта определяется участником электронного
аукциона, с которым заключается Контракт, самостоятельно.
Порядок предоставления обеспечения исполнения Контракта указан в статье 96 Закона.
Контракт заключается после предоставления участником электронного аукциона,
 9
с которым заключается Контракт, обеспечения исполнения Контракта в соответствии
с Законом.
Условия независимой гарантии указаны в статье 45 Закона. Срок действия независимой
гарантии должен превышать предусмотренный Контрактом срок исполнения обязательств,
которые должны быть обеспечены такой независимой гарантией, не менее чем на один месяц,
в том числе в случае его изменения в соответствии со статьей 95 Закона.
В случае, если обеспечение исполнения Контракта осуществляется в форме независимой
гарантии, гарант обязан уплатить Государственному заказчику денежную сумму
по независимой гарантии не позднее 10 (Десяти) рабочих дней со дня, следующего за днем
получения гарантом требования Государственного заказчика, соответствующего условиям
такой независимой гарантии, при отсутствии предусмотренных Гражданским кодексом
Российской Федерации оснований для отказа в удовлетворении этого требования.
Положения об обеспечении исполнения Контракта, включая положения
о предоставлении такого обеспечения с учетом положений статьи 37 Закона, не применяются
в случае заключения Контракта с участником электронного аукциона, являющимся казенным
учреждением.
Гарантийный срок, размер обеспечения гарантийных обязательств, требования
к такому обеспечению, порядок предоставления такого обеспечения, устанавливаемые
в соответствии с Законом:
На все результаты выполненных Работ устанавливается гарантийный срок
12 (Двенадцать) месяцев с даты размещения в единой информационной системе в сфере закупок
документа о приемке выполненных Работ по этапу № 4, подписанного Государственным
заказчиком в соответствии с требованиями Технического задания (Приложение № 1
к Контракту).
Размер обеспечения гарантийных обязательств составляет 739 441 (Семьсот тридцать
девять тысяч четыреста сорок один) рубль 00 копеек, что составляет 1 % от начальный
(максимальной) цены Контракта.
Гарантийные обязательства могут обеспечиваться предоставлением независимой
гарантии, соответствующей требованиям статьи 45 Закона, или внесением денежных средств
на указанный в разделе 13 Контракта счет, на котором в соответствии с законодательством
Российской Федерации учитываются операции со средствами, поступающими
Государственному заказчику.
Обеспечение гарантийных обязательств предоставляется одновременно с уведомлением
о готовности сдать выполненные Работы по этапу № 4 в сроки и в порядке, установленные
в пункте 8.2 Контакта.
Реквизиты счета, на котором в соответствии с законодательством Российской
Федерации учитываются операции со средствами, поступающими Государственному
заказчику:
Министерство экономического развития Российской Федерации
Почтовый адрес (место нахождения): 123112, г. Москва, Пресненская наб., д. 10, стр. 2.
ИНН 7710349494 КПП 770301001 ОКТМО 45380000
Получатель: Межрегиональное операционное УФК (Минэкономразвития России)
Лицевой счет получателя: № 05951001390
Банк получателя: ОПЕРАЦИОННЫЙ ДЕПАРТАМЕНТ БАНКА
РОССИИ//Межрегиональное операционное УФК г. Москва
БИК ТОФК: 024501901
Единый казначейский счет: 40102810045370000002
Казначейский счет: 03212643000000019502
Код средств (код цели): 0002
17. Информация о банковском сопровождении Контракта, о казначейском
сопровождении (если в соответствии с законодательством Российской Федерации расчеты
по Контракту или расчеты по Контракту в части выплаты аванса подлежат
 10
казначейскому сопровождению):
Банковское сопровождение Контракта не предусмотрено.
Казначейское сопровождение Контракта не предусмотрено.
18. Возможность Государственного заказчика заключить контракты, указанные
в части 10 статьи 34 Закона с несколькими участниками электронного аукциона,
количество указанных контрактов:
Возможность Государственного заказчика заключить контракты, указанные в части 10
статьи 34 Закона с несколькими участниками электронного аукциона, не предусмотрена.
19. Информация о возможности Государственного заказчика принять решение
об одностороннем отказе от исполнения Контракта в соответствии с гражданским
законодательством:
Возможность одностороннего отказа от исполнения Контракта предусмотрена.
20. Дата и время окончания срока подачи заявок на участие в электронном
аукционе установлены с использованием единой информационной системы
в сфере закупок (далее - ЕИС) в соответствии с частью 1 статьи 42 Закона:
Требования к содержанию заявки на участие в электронном аукционе и порядок
ее направления участником такого аукциона оператору электронной площадки содержатся
в статье 43 Закона.
21. Дата проведения процедуры подачи предложений о цене Контракта установлена
с использованием ЕИС в соответствии с частью 1 статьи 42 Закона.
22. Дата подведения итогов электронного аукциона установлена с использованием
ЕИС в соответствии с частью 1 статьи 42 Закона.
23.
Ответственность
за
нарушение
требований
антимонопольного
законодательства Российской Федерации.
Участник электронного аукциона несет административную и уголовную
ответственность за нарушение требований антимонопольного законодательства Российской
Федерации о запрете участия в ограничивающих конкуренцию соглашениях, осуществления
ограничивающих конкуренцию согласованных действий.
24. Документы, прилагаемые к извещению об осуществлении закупки в форме
электронных документов или в форме электронных образов бумажных документов,
сформированных без использования ЕИС:
Приложение № 1: Описание объекта закупки в соответствии со статьей 33 Закона
(Техническое задание);
Приложение № 2: Обоснование начальной (максимальной) цены Контракта;
Приложение № 3: Требования к содержанию, составу заявки на участие в электронном
аукционе в соответствии со ст. 43 Закона и инструкция по ее заполнению;
Приложение № 4: Проект государственного контракта.

=== ФАЙЛ: Приложение 4 ПГК_СЭДО_р | docs/0173100008626000034/Приложение 4 ПГК_СЭДО_р.pdf
Приложение № 4 к Извещению
Государственный контракт № ____________
на выполнение работ по развитию Системы электронного документооборота
Минэкономразвития России
г. Москва
______________
Министерство экономического развития Российской Федерации, действующее от имени
Российской Федерации, именуемое в дальнейшем «Государственный заказчик»,
в лице__________, действующего на основании ____________, с одной стороны, и ___________,
именуемое в дальнейшем «Исполнитель», в лице _________, действующего на основании
__________, с другой стороны, именуемые в дальнейшем «Стороны», на основании
______________ заключили настоящий Государственный контракт на выполнение работ
по развитию Системы электронного документооборота Минэкономразвития России (далее
по тексту – Контракт) о нижеследующем:
1. Предмет Контракта
1.1. Исполнитель по заданию Государственного заказчика обязуется в установленный
Контрактом срок выполнить работы по развитию Системы электронного документооборота
Минэкономразвития России (далее – Работы, Система) в соответствии с Техническим заданием
(Приложение № 1 к Контракту), а Государственный заказчик обязуется принять и оплатить
выполненные Работы в порядке и на условиях, определенных Контрактом.
1.2. Работы выполняются Исполнителем в соответствии с национальными стандартами
и государственными стандартами в части требований к проектированию, стадиям создания,
видам, комплектности и обозначению документов, видам испытаний при создании
и (или) развитии (модернизации) государственных информационных систем, а также
в соответствии с качественными, количественными и иными характеристиками работ,
определенными в описании объекта закупки, согласно требованиям Федерального закона
от 5 апреля 2013 г. № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг
для обеспечения государственных и муниципальных нужд» (далее – Закон), Федерального
закона от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите
информации», а также иных нормативных правовых актов в сфере контрактной системы,
информационных технологий, защиты информации, правовой защиты интересов государства
в области интеллектуальной собственности, регулирующих соответствующие отношения
и непосредственно указанных в Техническом задании (Приложение № 1 к Контракту),
являющемся его неотъемлемой частью.
1.3. Идентификационный код закупки: 26 1 7710349494 770301001 0079 001 0000 242.
1.4. Место выполнения Работ: 123112, г. Москва, Пресненская наб., д.10, стр.2.
Место приемки выполненных Работ: 123112, г. Москва, Пресненская наб., д.10, стр.2.
2. Сроки выполнения Работ
2.1. Срок исполнения Контракта: с даты заключения Контракта до полного исполнения
Сторонами своих обязательств по Контракту.
Срок выполнения Работ: с даты заключения Контракта по 20 декабря 2026 г.
включительно, в том числе:
- этап Работ № 1: в течение 7 календарных дней с даты заключения Контракта;
- этап Работ № 2: с даты заключения Контракта по 25 ноября 2026 г. включительно;
- этап Работ № 3: с даты завершения этапа работ № 2 по 11 декабря 2026 г. включительно;
- этап Работ № 4: с даты завершения этапа работ № 3 по 20 декабря 2026г. включительно.
 2
3. Цена Контракта и порядок оплаты выполненных Работ
3.1. Вариант 1.
Цена Контракта составляет ______ (__________) рублей __ копеек, включая НДС (___%)
(____________) рублей __ копеек, в том числе:
- стоимость этапа Работ № 1 составляет ______ (______) рублей _______ копеек, НДС
не облагаются в соответствии с пп. 26 п. 2 ст. 149 Налогового кодекса Российской Федерации1;
- стоимость этапа Работ № 2 составляет ______ (______) рублей _______ копеек, включая
НДС (___%) (_______) рублей ______ копеек;
- стоимость этапа Работ № 3 составляет ______ (______) рублей _______ копеек, включая
НДС (___%) (_______) рублей ______ копеек;
- стоимость этапа Работ № 4 составляет ______ (______) рублей _______ копеек, включая
НДС (___%) (_______) рублей ______ копеек.
Вариант 2. Цена Контракта составляет ______ (__________) рублей __ копеек, НДС
не облагается в соответствии с _________ в том числе:
- стоимость этапа Работ № 1 составляет ______ (______) рублей _______ копеек, НДС
не облагается;
- стоимость этапа Работ № 2 составляет ______ (______) рублей _______ копеек, НДС
не облагается;
- стоимость этапа Работ № 3 составляет ______ (______) рублей _______ копеек, НДС
не облагается;
- стоимость этапа Работ № 4 составляет ______ (______) рублей _______ копеек, НДС
не облагается.
(Вариант применяется в случае, если НДС равен нулю или победителем/участником, с которым
заключается Контракт, используется льготный режим налогообложения, или победитель/участник, с которым
заключается Контракт, освобожден от уплаты НДС).
Вариант 3. Цена Контракта составляет ______ (__________) рублей ____ копеек, в том
числе:
- стоимость этапа Работ № 1 составляет ______ (______) рублей _______ копеек;
- стоимость этапа Работ № 2 составляет ______ (______) рублей _______ копеек;
- стоимость этапа Работ № 3 составляет ______ (______) рублей _______ копеек;
- стоимость этапа Работ № 4 составляет ______ (______) рублей _______ копеек.
(Вариант применяется в случае, если в соответствии с законодательством Российской Федерации
о налогах и сборах налоги, сборы и иные обязательные платежи подлежат уплате в бюджеты бюджетной
системы Российской Федерации Государственным заказчиком).
В цену Контракта включены все расходы, связанные с выполнением Исполнителем всех
обязательств по Контракту, в том числе с уплатой всех пошлин, налогов и иных платежей
в соответствии с законодательством Российской Федерации.
Цена Контракта является твердой и определена на весь срок исполнения Контракта.
3.2 Оплата выполненных Работ по Контракту осуществляется за счет средств
федерального бюджета по главе 139, разделу 01, подразделу 13, целевой статье расходов
9990090020, виду расходов 242 классификации расходов бюджетов Российской Федерации.
1
Статья 149. Операции, не подлежащие налогообложению (освобождаемые от налогообложения).
2. Не подлежит налогообложению (освобождается от налогообложения) реализация (а также передача,
выполнение, оказание для собственных нужд) на территории Российской Федерации:
26) исключительных прав на программы для электронных вычислительных машин и базы данных,
включенные в единый реестр российских программ для электронных вычислительных машин и баз данных и (или)
единый реестр результатов научно-исследовательских, опытно-конструкторских и технологических работ
военного, специального или двойного назначения, прав на использование таких программ и баз данных (включая
обновления к ним и дополнительные функциональные возможности), в том числе путем предоставления
удаленного доступа к ним через информационно-телекоммуникационную сеть, в том числе через информационнотелекоммуникационную сеть «Интернет».
 3
3.3. Форма оплаты – безналичный расчет.
Оплата за фактически выполненные Работы осуществляется поэтапно, в соответствии
с Расчетом цены Контракта (Приложение № 2 к Контракту) после выполнения Работ
за соответствующий этап и принятия их Государственным заказчиком на основании
размещенного в единой информационной системе документа о приемке выполненных Работ
за соответствующий этап, Акт передачи (неисключительных) прав (по этапу Работ № 1),
подписанных Государственным заказчиком, и предоставленного Исполнителем счета/счетафактуры2, в течение 7 (Семи) рабочих дней со дня размещения в единой информационной
системе в сфере закупок (далее - единая информационная система) документа о приемке
выполненных Работ за соответствующий этап, подписанного Государственным заказчиком.
Счет/счет-фактура на оплату предоставляется Исполнителем в составе документа
о приемке, который Исполнитель формирует и подписывает в единой информационной системе
в соответствии с пунктом 5.1 Контракта.
Оплата за выполненные Работы за соответствующий этап производится Государственным
заказчиком путем перечисления денежных средств на указанный в Контракте расчетный счет
Исполнителя.
Датой оплаты считается дата списания денежных средств со счета Государственного
заказчика.
3.4. В случае, если в соответствии с законодательством Российской Федерации о налогах и
сборах налоги, сборы и иные обязательные платежи подлежат уплате в бюджеты бюджетной
системы Российской Федерации Государственным заказчиком, сумма, подлежащая уплате
Государственным заказчиком юридическому лицу или физическому лицу, в том числе
зарегистрированному в качестве индивидуального предпринимателя, уменьшается на размер
налогов, сборов и иных обязательных платежей в бюджеты бюджетной системы Российской
Федерации, связанных с оплатой Контракта.
3.5. В случае сокращения потребности Государственного заказчика в объеме
выполняемых Работ допускается осуществление Сторонами сверки взаиморасчетов, результаты
которой оформляются Актом сверки взаиморасчетов, либо расторжение настоящего Контракта
по соглашению Сторон. При этом Государственный заказчик обязан оплатить Исполнителю
фактически выполненные Работы в порядке и на условиях, предусмотренных настоящим
Контрактом.
4. Порядок предоставления (передачи)
результатов выполнения Работ Государственному заказчику
4.1. Передача исходных кодов, разработанных в ходе выполнения Работ программ
для электронных вычислительных машин (далее – программа для ЭВМ) и дистрибутивов
должна сопровождаться передачей всех необходимых для сборки и запуска программы
для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов)
для проведения компиляции, создания дистрибутива и установки (развертывания) программы
для ЭВМ.
4.2. Для проведения компиляции, создания дистрибутива и установки (развертывания)
программы для ЭВМ должны использоваться свободно распространяемые компиляторы,
интерпретаторы и иное программное обеспечение, необходимое для указанных целей,
дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных
(доработанных) в ходе выполнения Работ программ для ЭВМ.
4.3. В случае использования для проведения компиляции, создания дистрибутива
и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного
программного обеспечения, права на использование, копирование и модификацию которых
принадлежат третьим лицам Исполнитель за свой счет передает Государственному заказчику
2
Требование о предоставлении счета-фактуры не предъявляется в случае, если участник открытого аукциона, с которым
заключается Контракт, не является плательщиком НДС.
 4
дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного
программного обеспечения.
4.4. Исполнитель в процессе приемки выполненных Работ по Контракту должен провести
демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания)
разработанных (доработанных) программ для ЭВМ с использованием средств, указанных
в пункте 4.1 Контракта, а также в соответствии с инструкциями, приведенными в рабочей
документации на Систему.
4.5. Документация на Систему и ее части (техническая и рабочая) должна содержать
исчерпывающее описание принятых проектных решений в объеме, достаточном
для ее дальнейшего развития и эксплуатации.
4.6. Техническая и рабочая документация должна содержать описание разработанных
результатов Работ, в том числе программ для ЭВМ, прикладных программных интерфейсов,
алгоритмов и протоколов информационного взаимодействия, технических требований,
спецификаций и форматов обмена данными для взаимодействия с другими информационными
системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития
в дальнейшем без привлечения Исполнителя.
4.7. Передача Государственному заказчику комплекта документов, материалов
и сведений, предусмотренных нормативными правовыми актами Российской Федерации
в сфере информационных технологий, защиты информации, правовой защиты интересов
государства в области интеллектуальной собственности, включая документы, подтверждающие
отказ авторов (разработчиков) от исключительных прав на передаваемые объекты
интеллектуальной собственности в пользу Исполнителя, с проектами заявок
на государственную регистрацию в установленном порядке прав Государственного заказчика
на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения,
полезные модели, промышленные образцы, программы для электронных вычислительных
машин, базы данных, топологии интегральных микросхем, а также исключительные права
на результаты Работ, включая объекты авторских прав и потенциально патентоспособные
технические решения, секреты производства (ноу-хау), созданные в рамках Контракта,
осуществляется Исполнителем в составе отчетной документации, предусмотренной условиями
Контракта.
5. Порядок приемки выполненных Работ
5.1. В течение 2 (Двух) рабочих дней с даты окончания выполнения Работ
за соответствующий этап Исполнитель передает Государственному заказчику уведомление
о готовности сдать выполненные Работы за соответствующий этап и предусмотренные
Техническим заданием (Приложение № 1 к Контракту) отчетные документы. Одновременно
с уведомлением о готовности сдать выполненные Работы по этапу № 4 Исполнитель
предоставляет обеспечение исполнения гарантийных обязательств, предусмотренных разделом
11 Контракта.
Исполнитель в указанный срок также формирует и подписывает документ о приемке
выполненных Работ за соответствующий этап в единой информационной системе в сфере
закупок и направляет Государственному заказчику с приложением документов,
предусмотренных условиями Контракта по его исполнению (по этапу Работ № 4, в т. ч.
с приложением обеспечения исполнения гарантийных обязательств), при условии соблюдения
действующего законодательства Российской Федерации о защите государственной тайны
и о персональных данных.
Датой поступления Государственному заказчику документа о приемке выполненных
Работ за соответствующий этап, подписанного Исполнителем, считается дата размещения
такого документа в единой информационной системе в соответствии с часовой зоной, в которой
расположен Государственный заказчик.
5.2. Для приемки выполненных Работ за соответствующий этап Государственным
заказчиком создается приемочная комиссия, которая в течение 5 (Пяти) рабочих дней (для
 5
этапов Работ № 1, № 2 и № 3) и 2 (Двух) рабочих дней (для этапа Работ № 4) с даты
предоставления Исполнителем указанного в пункте 5.1 Контракта уведомления обязана
провести экспертизу соответствия качества выполненных Работ за соответствующий этап
требованиям Контракта, проверить выполнение обязательств по Контракту в установленные им
сроки.
К проведению экспертизы могут привлекаться эксперты, экспертные организации.
При этом при необходимости от Исполнителя могут запрашиваться необходимые для приемки
документы и материалы, а также разъяснения по представленным документам и материалам.
5.3. Исполнитель обязан направить к Государственному заказчику своего (-их)
уполномоченного (-ых) представителя (-ей) для участия в приемке.
5.4. При положительном заключении приемочной комиссии Акт передачи
(неисключительных) прав (по этапу Работ № 1), Акт приемки выполненных Работ
за соответствующий этап, в течение 2 (Двух) рабочих дней подписывается уполномоченными
представителями Сторон и утверждается Государственным заказчиком. При этом Акт приемки
выполненных Работ по этапу № 4 подписывается уполномоченными представителями Сторон и
утверждается Государственным заказчиком при положительном заключении приемочной
комиссии и при соблюдении Исполнителем условия о предоставлении обеспечения
гарантийных обязательств в соответствии с пунктами 5.1 и 6.1.12 Контракта в течение 2 (Двух)
рабочих дней. В Акте приемки выполненных Работ за соответствующий этап указывается
сумма, подлежащая оплате в соответствии с условиями Контракта.
По факту приемки выполненных Работ за соответствующий этап Государственный
заказчик и члены приемочной комиссии подписывают усиленными квалифицированными
электронными подписями документ о приемке выполненных Работ за соответствующий этап
в единой информационной системе, к которому прилагаются скан-копии документов,
указанных в настоящем пункте.
При этом, если приемочная комиссия включает членов, не являющихся работниками
Государственного заказчика, допускается осуществлять подписание документа о приемке
выполненных Работ за соответствующий этап без использования усиленных
квалифицированных электронных подписей и единой информационной системы. В этом
случае, Государственный заказчик прилагает в единой информационной системе подписанные
членами приемочной комиссии документы в форме электронных образов бумажных
документов.
5.5. При выявлении несоответствий и/или недостатков в Работах за соответствующий этап
препятствующих их приемке, в указанные в пункте 5.2 Контракта сроки составляется
отрицательное заключение приемочной комиссии, содержащее перечень нарушений условий
Контракта и критерии их существенности для Государственного заказчика.
Отрицательное заключение приемочной комиссии подписывается всеми членами
приемочной комиссии с ознакомлением Исполнителя (либо уполномоченного представителя
Исполнителя). В случае отказа Исполнителя (либо уполномоченного представителя
Исполнителя) от подписания отрицательного заключения, членами комиссии делаются
соответствующие записи в заключении.
На основании отрицательного заключения приемочной комиссии в сроки, установленные
пунктом 5.4 Контракта, составляется мотивированный отказ от подписания документа
о приемке выполненных Работ за соответствующий этап, который также формируется
с использованием единой информационной системы и подписывается Государственным
заказчиком усиленными квалифицированными электронными подписями с приложением
скан-копий документов, указанных в настоящем пункте.
При этом, если приемочная комиссия включает членов, не являющихся работниками
Государственного заказчика, допускается осуществлять составление мотивированного отказа
и его подписание без использования усиленных квалифицированных электронных подписей
и единой информационной системы.
 6
5.6. Приемочная комиссия вправе не отказывать в приемке выполненных Работ
за соответствующий этап если выявленные несоответствия и/или недостатки не препятствуют
приемке выполненных Работ за соответствующий этап и установить Исполнителю срок
для устранения несоответствий и/или недостатков. При этом приемочной комиссией
составляется заключение с указанием выявленных несоответствий и/или недостатков,
а также срока устранения таких несоответствий и/или недостатков.
На основании заключения об устранении выявленных несоответствий и/или недостатков
членами приемочной комиссии в единой информационной системе формируется
и
подписывается
усиленными
квалифицированными
электронными
подписями
мотивированный отказ от подписания документа о приемке Работ за соответствующий этап
с указанием выявленных несоответствий и/или недостатков, а также срока устранения таких
несоответствий и/или недостатков, с приложением скан-копий документов, указанных
в настоящем пункте.
При этом, если приемочная комиссия включает членов, не являющихся работниками
Государственного заказчика, допускается осуществлять составление мотивированного отказа
и его подписание без использования усиленных квалифицированных электронных подписей
и единой информационной системы. В этом случае, Государственный заказчик прилагает
в единой информационной системе подписанные членами приемочной комиссии документы
в форме электронных образов бумажных документов.
Исполнитель после устранения выявленных несоответствий и (или) недостатков повторно
направляет Государственному заказчику документ о приемке выполненных Работ
за соответствующий этап в единой информационной системе.
После устранения выявленных несоответствий и/или недостатков выполненные Работы
за соответствующий этап, принимаются повторно в порядке, установленном настоящим
разделом.
5.7. В случае, если приемочной комиссией установлен(-ы) факт(-ы) ненадлежащего
исполнения, и (или) неисполнения, и (или) просрочки исполнения Исполнителем обязательств,
предусмотренных Контрактом в Акте приемки выполненных Работ за соответствующий этап
указывается размер неустойки (штрафа, пени), подлежащий взысканию; основания применения
и порядок расчета неустойки (штрафа, пени); итоговая сумма, подлежащая оплате Исполнителю
по Контракту.
5.8. При возникновении между Государственным заказчиком и Исполнителем спора
по поводу нарушений условий Контракта по требованию любой из Сторон должна быть
назначена независимая экспертиза. Выбор независимого эксперта осуществляется
исключительно по обоюдному согласию Сторон. Расходы по проведению независимой
экспертизы несет Исполнитель.
5.9. Работы за соответствующий этап считаются принятыми с даты размещения в единой
информационной системе документа о приемке Работ за соответствующий этап, подписанного
Государственным заказчиком. Работы в целом считаются принятыми с даты размещения
в единой информационной системе документа о приемке Работ за этап № 4, подписанного
Государственным заказчиком.
6. Права и обязанности Сторон
6.1. Исполнитель обязуется:
6.1.1. Своевременно и надлежащим образом выполнить Работы, предусмотренные
Контрактом в соответствии с Техническим заданием (Приложение № 1 к Контракту),
с использованием своих материалов и средств.
6.1.2. Привлечь к исполнению Контракта соисполнителей из числа субъектов малого
предпринимательства,
социально
ориентированных
некоммерческих
организаций
в соответствии со статьей 30 Закона в объеме 30 % от цены Контракта. При этом Исполнитель
несет ответственность за действия и бездействия таких соисполнителей, в том числе за качество
выполняемых Работ за соответствующий этап, сроки их выполнения, как за свои собственные.
 7
Указанное требование не применяется, если исполнитель является субъектом малого
предпринимательства, социально ориентированной организацией.
6.1.3. В срок не более 5 (Пяти) рабочих дней со дня заключения договора с соисполнителем
представить Государственному заказчику:
а)
декларацию
о
принадлежности
соисполнителя
к
субъектам
малого
предпринимательства,
социально
ориентированной
некоммерческой
организации,
составленную в простой письменной форме, подписанную руководителем (иным
уполномоченным лицом) субъекта малого предпринимательства, социально ориентированной
некоммерческой организации и заверенную печатью (при наличии печати);
б) копию договора (договоров), заключенного (заключенных) с соисполнителем,
заверенную Исполнителем.
Указанное требование не применяется, если исполнитель является субъектом малого
предпринимательства, социально ориентированной организацией.
6.1.4. В случае замены соисполнителя на этапе исполнения Контракта на другого
соисполнителя представлять Государственному заказчику документы, указанные в пункте 6.1.3
Контракта, в течение 5 (Пяти) дней со дня заключения договора с новым соисполнителем.
Указанное требование не применяется, если исполнитель является субъектом малого
предпринимательства, социально ориентированной организацией.
6.1.5. В течение 10 (Десяти) рабочих дней со дня оплаты Исполнителем выполненных
обязательств по договору с соисполнителем представлять Государственному заказчику
следующие документы:
а) копии документов о приемке выполненных Работ за соответствующий этап которые
являются предметом договора, заключенного между Исполнителем и привлеченным
им соисполнителем;
б) копии платежных поручений, подтверждающих перечисление денежных средств
Исполнителем соисполнителю, в случае если договором, заключенным между Исполнителем
и привлеченным им соисполнителем, предусмотрена оплата выполненных обязательств
до сроков оплаты выполненных Работ за соответствующий этап предусмотренных Контрактом,
заключенным с Государственным заказчиком (в ином случае указанный документ
представляется Государственному заказчику дополнительно в течение 5 (Пяти) дней со дня
оплаты Исполнителем обязательств, выполненных соисполнителем).
Указанное требование не применяется, если исполнитель является субъектом малого
предпринимательства, социально ориентированной организацией.
6.1.6. Оплачивать выполненные соисполнителем Работы, отдельные этапы исполнения
договора, заключенного с таким соисполнителем, в течение 7 (Семи) рабочих дней с даты
подписания Исполнителем документа о приемке выполненных Работ за соответствующий этап,
отдельных этапов исполнения договора.
Указанное требование не применяется, если исполнитель является субъектом малого
предпринимательства, социально ориентированной организацией.
6.1.7. Нести гражданско-правовую ответственность перед Государственным заказчиком
за неисполнение или ненадлежащее исполнение условия о привлечении к исполнению
Контракта соисполнителей, в том числе:
а) за представление документов, указанных в пунктах 6.1.3 – 6.1.5 Контракта, содержащих
недостоверные сведения, либо их непредставление или представление таких документов
с нарушением установленных сроков;
б) за непривлечение соисполнителей в объеме, установленном в Контракте.
Требования пунктов 6.1.2 – 6.1.7 не применяются, если Исполнитель является субъектом
малого предпринимательства, социально ориентированной организацией.
6.1.8. Предоставлять Государственному заказчику информацию, касающуюся
выполнения Работ за соответствующий этап.
6.1.9. Предупреждать
Государственного
заказчика
о
конкретных
событиях
или обстоятельствах в будущем, которые могут негативно повлиять на качество выполнения
 8
Работ за соответствующий этап.
6.1.10. Исполнитель должен выполнить Работы за соответствующий этап качественно
и в установленный срок, за свой счет устранить допущенные по своей вине при выполнении
Работ за соответствующий этап несоответствия и (или) недостатки.
6.1.11. В случае изменения банковских реквизитов в течение 2 (Двух) рабочих дней
письменно известить об этом Государственного заказчика. В противном случае все риски,
связанные
с
перечислением
Государственным
заказчиком
денежных
средств
на расчетный/лицевой счет, несет Исполнитель.
6.1.12. Предоставить Государственному заказчику одновременно с уведомлением
о готовности сдать выполненные Работы обеспечение гарантийных обязательств,
предусмотренное разделом 11 Контракта.
6.1.13. Не допускать действий (бездействия), которые могут причинить или повлечь
за собой причинение вреда деловой репутации или материального ущерба Государственного
заказчика.
6.1.14. Для осуществления контроля за ходом и качеством выполнения Работ
за соответствующий этап Исполнитель представлять Государственному заказчику (или по его
требованию третьим лицам) необходимую документацию, относящуюся к выполняемым
Работам за соответствующий этап и создавать условия для проверки хода и качества
выполняемых Работ за соответствующий этап.
6.1.15. Исполнитель несет перед Государственным заказчиком ответственность
за действия и (или) бездействие соисполнителей, привлеченных к исполнению Контракта
в соответствии с пунктом 6.1.2 настоящего Контракта, как за свои собственные.
Указанное требование не применяется, если исполнитель является субъектом малого
предпринимательства, социально ориентированной организацией.
6.1.16. Без увеличения цены Контракта передать Государственному заказчику
исключительное право на разработанные в ходе выполнения Работ за соответствующий этап
результаты в полном объеме, включая исходные коды программ для ЭВМ, библиотеки
зависимостей, базы данных, а также проектную, техническую, рабочую, сопроводительную
и методическую документацию к Системе или ее частям.
6.1.17. Без увеличения цены Контракта передать Государственному заказчику права
на использование охраняемых результатов интеллектуальной деятельности, права на которые
принадлежат Исполнителю и которые использовались при выполнении Работ
за соответствующий этап, в объеме, необходимом для использования Государственным
заказчиком результатов Работ за соответствующий этап по их целевому назначению
и в соответствии с условиями настоящего Контракта на весь срок действия использованных
исключительных прав или на иной срок, установленный Государственным заказчиком.
Исполнитель передает заказчику указанные права посредством заключения лицензионного
договора.
Данный пункт не применяется в случае, если в ходе исполнения Контракта
не используются ранее созданные Исполнителем результаты интеллектуальной
деятельности.
6.1.18. Согласовать с Государственным заказчиком необходимость использования
при выполнении Работ за соответствующий этап охраняемых результатов интеллектуальной
деятельности, права на которые принадлежат третьим лицам, объем и порядок приобретения
прав на их использование.
Данный пункт не применяется в случае, если в ходе исполнения Контракта
не используются результаты интеллектуальной деятельности, права на которые
принадлежат третьим лицам.
6.1.19. Обеспечить передачу Государственному заказчику полученных по Контракту
результатов Работ, не нарушающих исключительных прав других лиц и не являющихся
предметом залога, ареста или иного обременения.
 9
6.1.20. В случае использования при выполнении Работ за соответствующий этап программ
для электронных вычислительных машин (программных комплексов или компонентов),
разработанных третьими лицами, условия, на которых передаются права на их использование
(исполнение), должны обеспечить отсутствие ограничений, препятствующих использованию
результатов Работ по их назначению. При этом права, полученные Государственным
заказчиком, должны позволять ему передавать, дорабатывать, развивать результаты Работ,
созданные в процессе исполнения Контракта, а в случае явного указания в Техническом задании
(Приложение № 1 к Контракту), являющемся неотъемлемой частью Контракта, осуществлять
переработку программ для электронных вычислительных машин (программных комплексов
или компонентов), разработанных ранее третьими лицами в соответствии с требованиями
законодательства Российской Федерации.
6.1.21. Обеспечить отсутствие нарушений исключительных, авторских и смежных прав
третьих лиц при реализации технических, программных, организационных и иных решений,
предусмотренных Техническим заданием (Приложение № 1 к Контракту) на выполнение Работ.
6.1.22. Обеспечить выполнение требований к порядку создания (развития)
государственных (муниципальных) и (или) иных информационных систем, предусмотренных
пунктом 3 части 1 статьи 13 Федерального закона от 27 июля 2006 г. № 149-ФЗ
«Об информации, информационных технологиях и о защите информации», устанавливаемых
к таким информационным системам указанным Федеральным законом и иными нормативными
правовыми актами Российской Федерации.
6.1.23. В течение 3 (Трех) рабочих дней с даты заключения Контракта направить
Государственному заказчику список работников Исполнителя представляющих Исполнителя
на территории Государственного заказчика с указанием их паспортных данных.
6.1.24. Строго соблюдать определенную Государственным заказчиком систему допуска
и пребывания на территории Государственного заказчика.
6.1.25. В течение 3 (Трех) календарных дней с момента получения от Государственного
заказчика требования о замене любых представителей Исполнителя заменить указанных
Государственным заказчиком представителей Исполнителя.
6.2. Исполнитель вправе:
6.2.1. Самостоятельно, если иное не указано в Техническом задании (Приложение № 1
к Контракту), определять способы выполнения Работ за соответствующий этап.
6.2.2. В случае неисполнения или ненадлежащего исполнения соисполнителем
обязательств, предусмотренных договором, заключенным с Исполнителем, осуществлять
замену соисполнителя, с которым ранее был заключен договор, на другого соисполнителя.
6.3. Государственный заказчик обязан:
6.3.1. Принять у Исполнителя в соответствии с условиями Контракта выполненные
Работы
за
соответствующий
этап
и
оплатить
их
в
соответствии
с условиями Контракта.
6.3.2. Воздерживаться от получения, сохранения, использования или предоставления
третьим лицам доступа к результатам Работ способом, который может привести к нарушению
любых действующих правил экспортного контроля или режима экономических санкций,
законов и нормативных актов какой-либо страны.
6.3.3. Использовать полученные в рамках выполнения Работ за соответствующий этап
информацию и материалы только для своих внутренних целей.
6.3.4. Обеспечить предоставление доступа сотрудникам Исполнителя в места выполнения
Работ.
6.4. Государственный заказчик вправе:
6.4.1. Требовать отчеты о ходе выполнения Работ за соответствующий этап.
6.5. Стороны обязуются:
6.5.1. В течение срока действия Контракта и в течение 3 (Трех) лет после прекращения его
действия не передавать третьим лицам конфиденциальную информацию, связанную
с Контрактом, в том числе полученную в ходе его исполнения, а также информацию, связанную
 10
с деловыми отношениями Сторон, за исключением информации,
для официального опубликования в соответствии с Законом.
предназначенной
7. Ответственность Сторон
7.1. Стороны несут ответственность за неисполнение или ненадлежащее исполнение
обязательств по Контракту, в том числе за просрочку исполнения обязательств, в соответствии с
действующим законодательством Российской Федерации.
7.2. В случае просрочки исполнения Исполнителем обязательств, предусмотренных
Контрактом (в том числе гарантийного обязательства), а также в иных случаях неисполнения
или ненадлежащего исполнения Исполнителем обязательств, предусмотренных Контрактом
(в том числе гарантийного обязательства, а также обязательства, предусмотренного пунктом
6.1.2 Контракта), Государственный заказчик направляет Исполнителю требование об уплате
неустоек (штрафов, пени).
7.3. Пеня начисляется за каждый день просрочки исполнения Исполнителем
обязательства, предусмотренного Контрактом (в том числе гарантийного обязательства),
начиная со дня, следующего после дня истечения установленного Контрактом срока
исполнения обязательства. Пеня устанавливается в размере одной трехсотой действующей
на дату уплаты пени ключевой ставки Центрального банка Российской Федерации
от цены исполнения отдельного этапа Контракта, уменьшенной на сумму, пропорциональную
объему обязательств, соответствующим отдельным этапом исполнения Контракта и фактически
исполненных Исполнителем.
7.4. За каждый факт неисполнения или ненадлежащего исполнения Исполнителем
обязательств, предусмотренных Контрактом, в том числе за выявленные несоответствия и/или
недостатки при приемке выполненных Работ за соответствующий этап за исключением
просрочки исполнения обязательств (в том числе гарантийного обязательства),
предусмотренных Контрактом, Исполнитель выплачивает Государственному заказчику штраф
в размере3:
- по этапу Работ № 1 – _________ (____________) рублей ____ копеек, что составляет __%
от цены этапа Работ № 1;
- по этапу Работ № 2 – _________ (____________) рублей ____ копеек, что составляет __%
от цены этапа Работ № 2;
- по этапу Работ № 3 – _________ (____________) рублей ____ копеек, что составляет __%
от цены этапа Работ № 3;
- по этапу Работ № 4 – _________ (____________) рублей ____ копеек, что составляет __%
от цены этапа Работ № 4.
7.5. За каждый факт неисполнения или ненадлежащего исполнения Исполнителем
обязательства, предусмотренного Контрактом, которое не имеет стоимостного выражения,
Исполнитель выплачивает Государственному заказчику штраф в размере ___ (__) рублей ___
копеек4.
3
Размер штрафа включается в контракт в виде фиксированной суммы в соответствии с пунктом 3 Правил
определения размера штрафа, начисляемого в случае ненадлежащего исполнения заказчиком, неисполнения
или ненадлежащего исполнения поставщиком (подрядчиком, исполнителем) обязательств, предусмотренных контрактом
(за исключением просрочки исполнения обязательств заказчиком, поставщиком (подрядчиком, исполнителем), утвержденных
постановлением Правительства Российской Федерации от 30.08.2017 № 1042 (далее – Правила):
а) 10 процентов цены этапа в случае, если цена этапа не превышает 3 млн. рублей;
б) 5 процентов цены этапа в случае, если цена этапа составляет от 3 млн. рублей до 50 млн. рублей (включительно).
в) 1 процент цены этапа в случае, если цена этапа составляет от 50 млн. рублей до 100 млн. рублей (включительно);
4
Размер штрафа включается в контракт в виде фиксированной суммы, рассчитанной в соответствии с пунктом 6
Правил:
а) 1000 рублей, если цена Контракта не превышает 3 млн. рублей;
б) 5000 рублей, если цена Контракта составляет от 3 млн. рублей до 50 млн. рублей (включительно).
в) 10000 рублей, если цена Контракта составляет от 50 млн. рублей до 100 млн. рублей (включительно);
 11
За неисполнение Исполнителем условия о привлечении к исполнению Контракта
соисполнителей из числа субъектов малого предпринимательства, социально ориентированных
некоммерческих организаций штраф устанавливается в размере 5 (Пять) процентов от объема
такого привлечения, установленного пунктом 6.1.2. Контракта.
Указанное требование не применяется, если Исполнитель является субъектом малого
предпринимательства, социально ориентированной организацией.
7.6. Общая сумма начисленных штрафов за неисполнение или ненадлежащее исполнение
Исполнителем обязательств, предусмотренных Контрактом, не может превышать цену
Контракта.
7.7. В случае просрочки исполнения Государственным заказчиком обязательств,
предусмотренных Контрактом, а также в иных случаях неисполнения или ненадлежащего
исполнения Государственным заказчиком обязательств, предусмотренных Контрактом,
Исполнитель вправе потребовать уплаты неустоек (штрафов, пени).
7.8. Пеня начисляется за каждый день просрочки исполнения Государственным
заказчиком обязательства, предусмотренного Контрактом, начиная со дня, следующего после
дня истечения установленного Контрактом срока исполнения обязательства. Пеня
устанавливается в размере одной трехсотой действующей на дату уплаты пени ключевой ставки
Центрального банка Российской Федерации от неуплаченной в срок суммы.
7.9. За каждый факт неисполнения Государственным заказчиком обязательств,
предусмотренных Контрактом, за исключением просрочки исполнения обязательств,
предусмотренных Контрактом, Исполнитель вправе взыскать с Государственного заказчика
штраф в размере ___ (__) рублей ___ копеек5.
7.10. Общая сумма начисленных штрафов за ненадлежащее исполнение Государственным
заказчиком обязательств, предусмотренных Контрактом, не может превышать цену Контракта.
7.11. В случае составления отрицательного заключения, указанного в пункте 5.5
Контракта, а так же заключения, указанного в пункте 5.6 Контракта, при котором выявленные
несоответствия и/или недостатки не препятствуют приемке, Государственный заказчик имеет
право начислять штрафы и пени начиная со дня, следующего после дня истечения
установленного Контрактом срока исполнения обязательства до момента составления
мотивированного отказа от подписания Акта приемки выполненных Работ за соответствующий
этап (включительно) или до даты направления повторного уведомления о готовности сдать
Работы за соответствующий этап, направленного после устранения выявленных несоответствий
и недостатков и по которому принято положительное решение приемочной комиссии
(включительно).
В случае просрочки исполнения Контракта без составления заключения, указанного
в пункте 5.6 настоящего Контракта, Государственный заказчик имеет право начислять пени
начиная со дня, следующего после дня истечения установленного Контрактом срока
исполнения обязательства до даты направления уведомления о готовности сдать Работы
за соответствующий этап, по которому принято положительное решение приемочной комиссии.
(включительно).
В случае просрочки исполнения Контракта без составления заключения, указанного
в пункте 5.6, и мотивированного отказа от подписания Акта приемки выполненных Работ
за соответствующий этап и в случае расторжения Контракта в соответствии с пунктом 12.3.1
Контракта Государственный заказчик имеет право начислять пени начиная со дня, следующего
после дня истечения установленного Контрактом срока исполнения обязательства, до дня
5
Размер штрафа включается в контракт в виде фиксированной суммы, рассчитанной исходя из цены контракта
на момент заключения контракта в соответствии с пунктом 9 Правил:
а) 1000 рублей, если цена Контракта не превышает 3 млн. рублей (включительно)
б) 5000 рублей, если цена Контракта составляет от 3 млн. рублей до 50 млн. рублей (включительно);
в) 10000 рублей, если цена Контракта составляет от 50 млн. рублей до 100 млн. рублей (включительно);
 12
вступления в силу одностороннего отказа Государственного заказчика от исполнения
Контракта (включительно).
7.12. Под существенными нарушениями условий Контракта понимаются существенные
нарушения, предусмотренные законодательством Российской Федерации, а также следующие
условия, о которых договорились Стороны:
а) несоблюдение Исполнителем пункта 5.3 Контракта;
б) нарушение установленных сроков выполнения Работ за соответствующий этап;
в) выявление нарушений условий Контракта при повторной приемке Работ
за соответствующий этап либо нарушение сроков устранения несоответствий
и/или недостатков;
г) не предоставление Исполнителем нового обеспечения исполнения Контракта
в соответствии с пунктом 10.4, 10.8 – 10.9 Контракта;
д) не предоставление обеспечения гарантийных обязательств, предусмотренных
разделом 11 Контракта;
e) не предоставление Исполнителем нового обеспечения гарантийных обязательств
в соответствии с пунктом 11.5 Контракта;
ж) не предоставление Исполнителем счета, счета-фактуры на оплату выполненных Работ
за соответствующий этап в соответствии с пунктом 3.3 Контракта;
з) несоблюдение Исполнителем пунктов 6.1.2 – 6.1.6 Контракта, в том числе
представление документов, указанных в пунктах 6.1.3 – 6.1.5 Контракта, содержащих
недостоверные сведения, либо их непредставление или представление таких документов
с нарушением установленных сроков, и непривлечение соисполнителей в объеме,
установленном в Контракте. Положения настоящего пункта не применяются, если
Исполнитель является субъектом малого предпринимательства, социально ориентированной
организацией.
7.13. Сторона освобождается от уплаты неустойки (штрафа, пени), если докажет,
что неисполнение или ненадлежащее исполнение обязательства, предусмотренного
Контрактом, произошло вследствие наступления обстоятельств непреодолимой силы
или по вине другой стороны.
7.14. Уплата неустойки (штрафа, пени) не освобождает Стороны от выполнения
обязательств по Контракту.
8. Исключительные права и права собственности
8.1. Исключительные права на результаты интеллектуальной деятельности, в том числе,
но не исключая: изобретения, полезные модели, промышленные образцы, программы
для электронных вычислительных машин, базы данных, а также исключительные права
на результаты работ, включая объекты авторских прав и потенциально патентоспособные
технические решения, секреты производства (ноу-хау), созданные в рамках Контракта,
принадлежат в лице Государственного заказчика Российской Федерации.
Право собственности на результаты Работ, отчетные документы и материалы, полученные
в ходе выполнения работ по Контракту, считаются переданными с момента размещения
в единой информационной системе документа о приемке выполненных Работ по этапу № 4,
подписанного Государственным заказчиком.
В случае если при осуществлении Работ по Контракту осуществляется доработка
программ для электронных вычислительных машин Государственного заказчика, осуществлять
ее в соответствии с предоставляемыми в обязательном порядке Государственным заказчиком
правами на их использование на период исполнения Работ по Контракту.
8.2. На все результаты выполненных Работ устанавливается гарантийный срок
12 (Двенадцать) месяцев с даты размещения в единой информационной системе документа
о приемке выполненных Работ по этапу № 4, подписанного Государственным заказчиком
в соответствии с требованиями Технического задания (Приложение № 1 к Контракту).
 13
9. Обстоятельства непреодолимой силы
9.1. Если в ходе выполнения Работ обнаруживается невозможность исполнения
Сторонами обязательств по Контракту вследствие наступления обстоятельств непреодолимой
силы (стихийные бедствия, эпидемии, массовые беспорядки и военные действия, а также
запретительные меры государства, включая введение санкционных мер и др.), которые Стороны
не могли предвидеть и неблагоприятные последствия которых не могут предотвратить
в предусмотренные Контрактом сроки, Сторона обязана в трехдневный срок письменно
известить другую Сторону о наступлении таких обстоятельств, принять все возможные меры по
уменьшению их неблагоприятных последствий на выполнение обязательств по Контракту
и вступить в переговоры о продлении или прекращении действия Контракта, либо об изменении
условий Контракта. В результате переговоров составляется двухсторонний акт, подписанный
Сторонами.
9.2. В случае прекращения действия указанных обстоятельств Стороны обязуются
предпринять все разумные меры, чтобы в кратчайшие сроки преодолеть невозможность
выполнения своих обязательств по Контракту.
10. Обеспечение исполнения контракта
10.1. Условием заключения Контракта является предоставление Исполнителем
обеспечения исполнения Контракта. Размер обеспечения исполнения Контракта составляет
22 183 230 (Двадцать два миллиона сто восемьдесят три тысячи двести тридцать) рублей
00 копеек, что составляет 30 % от начальный (максимальной) цены Контракта, и обеспечивает
надлежащее исполнение обязательств Исполнителя, установленных разделами 1, 2, 4 – 7
и пунктом 3.3 (в части предоставления Исполнителем счета/счета-фактуры) Контракта, а также
надлежащее исполнение всех иных обязательств Исполнителя, предусмотренных Контрактом,
за исключением гарантийных обязательств.
В случае, если предложенная Исполнителем цена Контракта ниже на двадцать пять
и более процентов по отношению к начальной (максимальной) цене Контракта, Контракт
заключается только после предоставления Исполнителем обеспечения исполнения Контракта,
обеспечивающего надлежащее исполнение обязательств Исполнителя, установленных
разделами 1, 2, 4 – 7, и пунктом 3.3 (в части предоставления Исполнителем счета/счетафактуры) Контракта, а также надлежащее исполнение всех иных обязательств Исполнителя,
предусмотренных Контрактом, за исключением гарантийных обязательств, в размере,
превышающем в полтора раза размер обеспечения исполнения Контракта, что составляет
33 274 845 (Тридцать три миллиона двести семьдесят четыре тысячи восемьсот сорок пять)
рублей 00 копеек в соответствии с частью 1 статьи 37 Закона.
10.2. В случае, если обеспечение исполнения Контракта осуществляется в форме
независимой гарантии, срок действия независимой гарантии определяется в соответствии
с требованиями Закона Исполнителем самостоятельно. При этом срок действия
предоставленной Исполнителем независимой гарантии в качестве обеспечения исполнения
Контракта должен превышать предусмотренные Контрактом сроки исполнения обязательств
Исполнителя, которые должны быть обеспечены такой независимой гарантией, в том числе
с учетом сроков выполнения Работ по этапу № 4, установленных разделом 2 Контракта,
и сроков, установленных пунктами 3.3 (в части предоставления Исполнителем счета, счетафактуры), 5.1, 5.2, 5.4 – 5.6 Контракта, не менее чем на один месяц, в том числе в случае его
изменения в соответствии со статьей 95 Закона.
10.3. В ходе исполнения Контракта Исполнитель вправе изменить способ обеспечения
исполнения Контракта и (или) предоставить Государственному заказчику взамен ранее
предоставленного обеспечения исполнения Контракта новое обеспечение исполнения
Контракта, размер которого может быть уменьшен в порядке и случаях, которые
предусмотрены частями 7.2 и 7.3 статьи 96 Закона.
В связи с тем, что Контрактом предусмотрены отдельные этапы его исполнения
и установлено требование обеспечения исполнения Контракта, в ходе исполнения данного
 14
Контракта размер этого обеспечения подлежит уменьшению в порядке и случаях, которые
предусмотрены частями 7.2 и 7.3 статьи 96 Закона.
Уменьшение в соответствии с настоящим пунктом размера обеспечения исполнения
Контракта, предоставленного в виде независимой гарантии, осуществляется Государственным
заказчиком путем отказа от части своих прав по этой гарантии. При этом датой такого отказа
признается дата включения предусмотренной пунктом 10.6 Контракта информации
в соответствующий реестр контрактов, предусмотренный статьей 103 Закона.
10.4. В случае отзыва в соответствии с законодательством Российской Федерации
у органа, предоставившего независимую гарантию в качестве обеспечения исполнения
Контракта лицензии на осуществление банковских операций Исполнитель обязан предоставить
новое обеспечение исполнения Контракта не позднее одного месяца со дня надлежащего
уведомления Государственным заказчиком Исполнителя о необходимости предоставить
соответствующее обеспечение.
В случае предоставления нового обеспечения исполнения Контракта возврат независимой
гарантии Государственным заказчиком гаранту, предоставившему указанную независимую
гарантию, не осуществляется, взыскание по ней не производится.
Размер такого обеспечения может быть уменьшен в порядке и случаях, которые
предусмотрены пунктами 10.3, 10.6, 10.7 Контракта.
10.5. За каждый день просрочки исполнения Исполнителем обязательства,
предусмотренного пунктом 10.4 Контракта, начисляется пеня в размере, определенном
в порядке, установленном пунктом 7.3 Контракта.
10.6. Размер обеспечения исполнения Контракта уменьшается посредством направления
Государственным заказчиком информации об исполнении Исполнителем обязательств
по выполнению Работ за соответствующий этап и стоимости исполненных обязательств
для включения в соответствующий реестр контрактов, предусмотренный статьей 103 Закона.
Уменьшение размера обеспечения исполнения Контракта производится пропорционально
стоимости исполненных обязательств, приемка и оплата которых осуществлены в порядке
и сроки, которые предусмотрены Контрактом.
В случае, если обеспечение исполнения Контракта осуществляется путем предоставления
независимой гарантии, требование Государственного заказчика об уплате денежных сумм
по этой гарантии может быть предъявлено в размере не более размера обеспечения исполнения
Контракта, рассчитанного Государственным заказчиком на основании информации
об исполнении Контракта, размещенной в соответствующем реестре контрактов.
В случае, если обеспечение исполнения Контракта осуществляется путем внесения
денежных средств на счет, указанный Государственным заказчиком, по заявлению
Исполнителя Государственным заказчиком возвращаются ему денежные средства в сумме,
на которую уменьшен размер обеспечения исполнения Контракта, рассчитанный
Государственным заказчиком на основании информации об исполнении Контракта,
размещенной в соответствующем реестре контрактов, в срок, не превышающий 30 (Тридцать)
календарных дней с даты исполнения Исполнителем обязательств, предусмотренных
Контрактом.
10.7. Предусмотренное пунктом 10.3 Контракта уменьшение размера обеспечения
исполнения Контракта осуществляется при условии отсутствия неисполненных Исполнителем
требований об уплате неустоек (штрафов, пеней), предъявленных Государственным заказчиком
в соответствии с Законом, а также приемки Государственным заказчиком выполненных Работ за
соответствующий этап.
10.8. В случае, если по истечению срока действия независимой гарантии по вине
Исполнителя обязательства по Контракту не исполнены и в качестве нового обеспечения
исполнения Контракта предоставляется независимая гарантия, срок действия такой
независимой гарантии должен не менее чем на один месяц превышать срок, установленный
приемочной комиссией для устранения несоответствий и/или недостатков, с учетом сроков,
предусмотренных для повторной приемки выполненных Работ за соответствующий этап.
 15
10.9. Непредоставление Исполнителем нового обеспечения исполнения Контракта
признается существенным нарушением условий Контракта и может служить основанием
для расторжения Контракта в порядке, установленном Контрактом.
10.10. В случае, если обеспечение исполнения Контракта осуществляется в форме
независимой гарантии, Государственный заказчик вправе при неисполнении либо
ненадлежащем исполнении Исполнителем обязательств, предусмотренных Контрактом,
предъявить требование по независимой гарантии.
10.11. Денежные средства, внесенные в качестве обеспечения исполнения Контракта
(в случае если такая форма обеспечения исполнения Контракта определена Исполнителем),
в том числе часть этих денежных средств в случае уменьшения размера обеспечения
исполнения Контракта в соответствии с пунктами 10.3 и 10.6 Контракта, возвращаются
Исполнителю после исполнения (прекращения) всех обязательств по Контракту. Денежные
средства возвращаются Государственным заказчиком на банковский счет Исполнителя,
указанный в Контракте, в течение 30 (Тридцати) календарных дней с даты исполнения
Исполнителем всех обязательств, предусмотренных Контрактом.
10.12. В случаях, указанных в пунктах 7.2, 7.3, 7.4, 7.5 Контракта, Государственный
заказчик оставляет за собой право на взыскание неустойки за счет обеспечения исполнения
Контракта, предоставленного в виде денежных средств, если Исполнителем в срок не более чем
10 (Десять) рабочих дней не исполнено требование Государственного заказчика о добровольной
оплате неустойки.
11. Обеспечение гарантийных обязательств
11.1. Размер обеспечения гарантийных обязательств, предусмотренных пунктом 8.2
Контракта, составляет 739 441 (Семьсот тридцать девять тысяч четыреста сорок один) рубль
00 копеек, что составляет 1 % от начальный (максимальной) цены Контракта.
11.2. Гарантийные обязательства могут обеспечиваться предоставлением независимой
гарантии, соответствующей требованиям статьи 45 Закона, или внесением денежных средств
на указанный в разделе 13 Контракта счет, на котором в соответствии с законодательством
Российской Федерации учитываются операции со средствами, поступающими
Государственному заказчику.
Обеспечение гарантийных обязательств предоставляется одновременно с уведомлением
о готовности сдать выполненные Работы по этапу № 4 в сроки и в порядке, установленные
в пункте 5.1 Контакта.
11.3. В случае, если обеспечение гарантийных обязательств осуществляется в форме
независимой гарантии, срок действия независимой гарантии, предоставленной Исполнителем
в качестве обеспечения гарантийных обязательств должен превышать не менее чем на один
месяц от окончания гарантийного срока на результаты Работ, предусмотренного пунктом 8.2
Контракта.
11.4. Исполнитель вправе изменить способ обеспечения гарантийных обязательств
и (или) предоставить Государственному заказчику взамен ранее предоставленного обеспечения
гарантийных обязательств новое обеспечение гарантийных обязательств.
11.5. В случае отзыва в соответствии с законодательством Российской Федерации у банка,
предоставившего независимую гарантию в качестве обеспечения гарантийных обязательств
лицензии на осуществление банковских операций Исполнитель обязан предоставить новое
обеспечение гарантийных обязательств не позднее одного месяца со дня надлежащего
уведомления Государственным заказчиком Исполнителя о необходимости предоставить
соответствующее обеспечение.
В случае предоставления нового обеспечения гарантийных обязательств возврат
независимой гарантии Государственным заказчиком гаранту, предоставившему указанную
независимую гарантию, не осуществляется, взыскание по ней не производится.
 16
11.6. За каждый день просрочки исполнения Исполнителем обязательства,
предусмотренного пунктом 11.5 Контракта, начисляется пеня в размере, определенном
в порядке, установленном пунктом 7.3 Контракта.
Непредоставление Исполнителем нового обеспечения гарантийных обязательств
признается существенным нарушением условий Контракта и может служить основанием
для расторжения Контракта в порядке, установленном Контрактом.
11.7. В случае, если обеспечение гарантийных обязательств осуществляется в форме
независимой гарантии, Государственный заказчик вправе при неисполнении либо
ненадлежащем исполнении Исполнителем гарантийных обязательств предъявить требование
по независимой гарантии.
11.8. Денежные средства, внесенные в качестве обеспечения гарантийных обязательств
(в случае если такая форма обеспечения гарантийных обязательств определена Исполнителем)
возвращаются Исполнителю на банковский счет Исполнителя, указанный в разделе 13
Контракта, в течение 30 (Тридцати) календарных дней с даты истечения указанного
в пункте 8.2 Контракта гарантийного срока на результаты Работ.
11.9. В случаях, указанных в пунктах 7.2, 7.3, 7.4, 7.5 Контракта, Государственный
заказчик оставляет за собой право на взыскание неустойки за счет обеспечения гарантийных
обязательств, предоставленного в виде денежных средств, если Исполнителем в срок не более
чем 10 (Десять) рабочих дней не исполнено требование Государственного заказчика
о добровольной оплате неустойки.
12. Прочие условия
12.1. Контракт составлен в форме электронного документа, подписанного усиленными
квалифицированными электронными подписями Сторон.
12.2. Контракт вступает в силу и становится обязательным для Сторон с момента
размещения в единой информационной системе подписанного Государственным заказчиком
Контракта и действует до полного исполнения Сторонами своих обязательств по Контракту.
12.3. Контракт может быть расторгнут по соглашению Сторон, в одностороннем порядке,
по решению суда по основаниям, предусмотренным гражданским законодательством
Российской Федерации. При этом факт подписания Сторонами соглашения о расторжении
Контракта не освобождает Стороны от обязанности урегулирования взаимных расчетов.
12.3.1. Основания расторжения Контракта в связи с односторонним отказом
от исполнения Контракта по инициативе Государственного заказчика:
- выполнение Работ за соответствующий этап ненадлежащего качества, если
несоответствия и/или недостатки не могут быть устранены в приемлемый для Государственного
заказчика срок;
- нарушение срока и объема выполнения Работ за соответствующий этап
предусмотренных Контрактом;
- Исполнитель не приступает к исполнению Контракта в срок, установленный
Контрактом, или выполняет Работы за соответствующий этап так, что окончание
их выполнения к сроку, предусмотренному Контрактом, становится явно невозможно, либо
в ходе выполнения Работ за соответствующий этап стало очевидно, что они не будут выполнены
надлежащим образом в установленный Контрактом срок;
- в случае, если по результатам экспертизы выполненных Работ за соответствующий этап с
привлечением экспертов, экспертных организаций, в заключении эксперта, экспертной
организации будут подтверждены нарушения условий Контракта;
- если в ходе исполнения Контракта установлено, что Исполнитель не соответствует
установленным извещением о проведении открытого аукциона в электронной форме
требованиям к участникам открытого аукциона в электронной форме, или предоставил
недостоверную информацию о своем соответствии таким требованиям, что позволило ему стать
победителем по результатам проведения данной закупки.
 17
12.3.2. Основания расторжения Контракта в связи с односторонним отказом
от исполнения Контракта по инициативе Исполнителя:
- нарушение Государственным заказчиком срока оплаты выполненных Работ
за соответствующий этап допущенное по вине Государственного заказчика, при условии
своевременного доведения лимитов финансирования до Государственного заказчика;
- необоснованный отказ Государственного заказчика от приемки выполненных Работ
за соответствующий этап. При этом необоснованным отказом считается отказ
Государственного заказчика от подписания Акта приемки выполненных Работ
за соответствующий этап в срок, предусмотренный Контрактом, без письменного объяснения
причин такого отказа.
Расторжение Контракта в одностороннем порядке осуществляется с соблюдением
требований частей 8 – 25 статьи 95 Закона.
12.3.3. Расторжение Контракта по соглашению сторон определяется в порядке,
установленном действующим гражданским законодательством Российской Федерации.
Сторона, которой направлено предложение о расторжении Контракта по соглашению сторон,
должна дать письменный ответ по существу в срок, не превышающий 5 (Пяти) календарных
дней с даты его получения.
12.4. Все спорные вопросы и разногласия, которые могут возникнуть между
Государственным заказчиком и Исполнителем в ходе исполнения Контракта, Стороны
обязуются решать путём прямых переговоров, взаимных консультаций и приложат все усилия
для их урегулирования. При невозможности разрешения споров и разногласий путём
переговоров спорные вопросы разрешаются в соответствии с действующим законодательством
Российской Федерации в Арбитражном суде г. Москвы.
12.4.1. При применении мер ответственности и совершении иных действий в связи
с нарушением Исполнителем или Государственным заказчиком условий Контракта обмен
документами в отношении Контракта осуществляется с использованием единой
информационной системы путем направления электронных уведомлений. Такие уведомления
формируются с использованием единой информационной системы, подписываются усиленной
электронной подписью лица, имеющего право действовать от имени Государственного
заказчика, Исполнителя, и размещаются в единой информационной системе без размещения
на официальном сайте.
12.5. Изменение существенных условий Контракта при его исполнении не допускается,
за исключением их изменения по соглашению сторон в следующих случаях:
12.5.1. При снижении цены Контракта без изменения предусмотренных Контрактом
объема Работ, качества выполняемых Работ и иных условий Контракта;
12.5.2. Если по предложению Государственного заказчика увеличивается
предусмотренный Контрактом объем выполняемых Работ не более чем на десять процентов или
уменьшается предусмотренный Контрактом объем выполняемых Работ не более чем на десять
процентов. При этом по соглашению сторон допускается изменение с учетом положений
бюджетного законодательства Российской Федерации цены Контракта пропорционально
дополнительному объему Работ исходя из установленной в Контракте цены единицы Работ,
но не более чем на десять процентов от цены Контракта. При уменьшении предусмотренного
Контрактом объема Работ стороны Контракта обязаны уменьшить цену Контракта исходя
из цены единицы Работ.
12.6. При изменении в ходе исполнения Контракта межгосударственных стандартов,
национальных (государственных) стандартов Стороны вправе:
12.6.1. Внести изменения в Контракт в части их корректировки и актуализации, которые
оформляются соответствующим соглашением.
12.6.2. Расторгнуть Контракт по соглашению Сторон в порядке, предусмотренном
пунктом 12.3.3. Контракта.
12.7. Изменения и дополнения по основаниям, предусмотренным пунктами 12.5. и 12.6.
Контракта, а также изменения и дополнения по иным основаниям, вносятся по соглашению
 18
Сторон, которое оформляется соответствующим соглашением и является неотъемлемой частью
Контракта.
12.8. К Контракту прилагаются и являются его неотъемлемыми частями следующие
приложения:
Техническое задание (Приложение № 1 к Контракту);
Расчет цены Контракта (Приложение № 2 к Контракту).
13. Реквизиты Сторон:
ГОСУДАРСТВЕННЫЙ ЗАКАЗЧИК:
Министерство экономического развития Российской Федерации;
Почтовый адрес (место нахождения): 123112, г. Москва, Пресненская наб., д. 10, стр. 2.
ИНН 7710349494 КПП 770301001 ОКТМО 45380000
Банковские реквизиты:
Межрегиональное операционное УФК (Минэкономразвития России)
Лицевой счет: № 03951001390
Банк:
ОПЕРАЦИОННЫЙ
ДЕПАРТАМЕНТ
БАНКА
РОССИИ//Межрегиональное
операционное УФК г. Москва
БИК ТОФК: 024501901
Единый казначейский счет: 40102810045370000002
Казначейский счет: 03211643000000019503
Банковские реквизиты Государственного заказчика для перечисления денежных средств
в качестве обеспечения исполнения государственного контракта:
Министерство экономического развития Российской Федерации
Почтовый адрес (место нахождения): 123112, г. Москва, Пресненская наб., д. 10, стр. 2.
ИНН 7710349494 КПП 770301001 ОКТМО 45380000
Получатель: Межрегиональное операционное УФК (Минэкономразвития России)
Лицевой счет получателя: № 05951001390
Банк получателя: ОПЕРАЦИОННЫЙ ДЕПАРТАМЕНТ БАНКА РОССИИ//Межрегиональное
операционное УФК г. Москва
БИК ТОФК: 024501901
Единый казначейский счет: 40102810045370000002
Казначейский счет: 03212643000000019502
Код средств (код цели): 0002
Банковские реквизиты Государственного заказчика для оплаты неустойки (штрафа, пени):
Министерство экономического развития Российской Федерации
Почтовый адрес (место нахождения): 123112, г. Москва, Пресненская наб., д. 10, стр. 2.
ИНН 7710349494 КПП 770301001 ОКТМО 45380000
Получатель: Межрегиональное операционное УФК (Минэкономразвития России)
Лицевой счет получателя: 04951001390
Банк получателя: ОПЕРАЦИОННЫЙ ДЕПАРТАМЕНТ БАНКА РОССИИ//Межрегиональное
операционное УФК г. Москва
БИК ТОФК: 024501901
Единый казначейский счет: 40102810045370000002
Казначейский счет: 03100643000000019500
ИСПОЛНИТЕЛЬ:
_____________________________.
Адрес (место нахождения): ____________________, почтовый адрес: _________________.
Банковские реквизиты:
р/с _______________ в________________, к/с ______________ в __________________.
 19
ИНН ____________, КПП ____________, БИК________, КБК ______________, ОКОПФ _____,
ОКФС _____, ОКСМ ____, ОКПО __________, ОКТМО ________, ОКВЭД ______, телефон:
_______________,
e-mail: ____________.
От Государственного заказчика:
____________________
От Исполнителя:
____________________
_____________ ___________
(подпись)
Ф.И.О.
м. п.
м. п.
_____________ ___________
(подпись)
Ф.И.О.
 20
Приложение № 1 к Контракту
от ______________________
№ _______________
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на выполнение работ по развитию Системы электронного документооборота
Минэкономразвития России
(Формируется на основании приложения № 1 к Извещению)
м. п.
От Государственного заказчика:
____________________
От Исполнителя:
____________________
_____________ ___________
(подпись)
Ф.И.О.
_____________ ___________
(подпись)
Ф.И.О.
м. п.
 21
Приложение № 2 к Контракту
от _______________________
№ ____________________
РАСЧЕТ ЦЕНЫ КОНТРАКТА
на выполнение работ по развитию Системы электронного документооборота
Минэкономразвития России
№
этапа
1.
2.
3.
4.
Стоимость Работ (в том числе
НДС/НДС не облагается), руб.*
Наименование
Итого:
Цена Контракта составляет ______ (______) рублей _______ копеек, включая НДС
(___%) (_______) рублей ______ копеек / НДС не облагается в соответствии с _________.
* При заключении Контракта с участником открытого аукциона в электронной форме, с которым заключается
государственный контракт, стоимость Работ будет указана путем снижения стоимости, указанной в столбце
«Начальная (максимальная) цена контракта с учетом выделенных и доведенных лимитов бюджетных
обязательств» Приложения № 2 к Извещению о проведении электронного аукциона «Обоснование начальной
(максимальной) цены контракта» на процент снижения по результатам электронного аукциона.
м. п.
От Государственного заказчика:
____________________
От Исполнителя:
____________________
_____________ ___________
(подпись)
Ф.И.О.
_____________ ___________
(подпись)
Ф.И.О.
м. п.

=== ФАЙЛ: ПК.ТУ.ЦОД.ПК.v7.6 для публикации | docs/0173100008626000034/ПК.ТУ.ЦОД.ПК.v7.6 для публикации.docx
ПАО «Ростелеком»
УТВЕРЖДАЮ
ПАО «Ростелеком» 
 «_____» _________ 2025 г.
Технические условия по размещению информационных систем федеральных органов исполнительной власти в центре обработки данных Правительственного комплекса
АГРВ.466459.301-01ТУ
Согласовано:
Разработали:
Содержание
 TOC \o "1-1" \h \z \t "Заголовок 2;2;Заголовок 3;3;td_toc_caption_level_2;2;td_toc_caption_level_3;3;РТК_ПриложГ_2заг;2;РТК_ПриложГ_3заг;3;ОТЗ_Заг_прил_2_уровень;2;РТК_ПриложА_2заг;2" Термины и определения PAGEREF _Toc199394412 \h 7
Перечень сокращений и обозначений PAGEREF _Toc199394413 \h 8
1 Общие сведения PAGEREF _Toc199394414 \h 11
1.1 Область применения PAGEREF _Toc199394415 \h 11
1.2 Перечень документов, использованных при разработке PAGEREF _Toc199394416 \h 11
1.3 Участвующие стороны и зоны ответственности PAGEREF _Toc199394417 \h 11
2 Описание ЦОД Правительственного комплекса PAGEREF _Toc199394418 \h 13
2.1 Структура ЦОД правительственного комплекса PAGEREF _Toc199394419 \h 13
2.2 Описание сегмента «Colocation» PAGEREF _Toc199394420 \h 14
2.3 Описание Облака PAGEREF _Toc199394421 \h 14
2.4 Архитектура Облака PAGEREF _Toc199394422 \h 14
2.5 Логические зоны Облака PAGEREF _Toc199394423 \h 17
2.5.1 Зона разработки и тестирования ИС PAGEREF _Toc199394424 \h 17
2.5.2 Предпродуктивная зона ИС PAGEREF _Toc199394425 \h 17
2.5.3 Продуктивная зона ИС PAGEREF _Toc199394426 \h 18
2.5.4 Подготовительная зона ИС PAGEREF _Toc199394427 \h 18
2.6 Обеспечение ИБ в ЦОД ПК PAGEREF _Toc199394428 \h 19
2.6.1 Сервисы обеспечения ИБ PAGEREF _Toc199394429 \h 19
2.6.2 Требования по обеспечению удаленного доступа PAGEREF _Toc199394430 \h 20
2.6.3 Требования ИБ, выполняемые ФОИВ при размещении оборудования и миграции ИС в сегменте «Colocation» PAGEREF _Toc199394431 \h 21
2.6.4 Описание СЗИ и требований по обеспечению ИБ в сегменте «Colocation» PAGEREF _Toc199394432 \h 22
2.6.5 Требования по обеспечению ИБ в ЦОД ПК PAGEREF _Toc199394433 \h 24
2.6.6 Использование свободно распространяемого ПО PAGEREF _Toc199394434 \h 27
2.6.7 Дополнительные требования ИБ по размещению ИС в Подготовительной зоне (ОК и ЗК) ЦОД ПК PAGEREF _Toc199394435 \h 28
2.6.8 ФПД ФОИВ ЦОД ПК PAGEREF _Toc199394436 \h 29
2.6.9 Сегментация сети в Облаке ЦОД ПК и размещение модулей ИС ФОИВ PAGEREF _Toc199394437 \h 30
3 Размещение оборудования в сегменте «Colocation» PAGEREF _Toc199394438 \h 34
3.1 Предоставляемые ресурсы и услуги в сегменте «Colocation» ЦОД ПК PAGEREF _Toc199394439 \h 34
3.2 Описание процедуры по размещению оборудования Функционального Заказчика в сегменте «Colocation» PAGEREF _Toc199394440 \h 35
3.3 Условия оказания услуги «Предоставление телекоммуникационной стойки» PAGEREF _Toc199394441 \h 36
3.3.1 Требования к эксплуатационно-техническому состоянию оборудования Функционального Заказчика для размещения в сегменте «Colocation» PAGEREF _Toc199394442 \h 37
3.3.2 Требования к документированию для размещения оборудования Функционального Заказчика в сегменте «Colocation» PAGEREF _Toc199394443 \h 38
3.3.3 Требования по размещению и монтажу оборудования в стойках PAGEREF _Toc199394444 \h 39
3.4 Условия оказания услуги «Предоставление сетевого оборудования для телекоммуникационной стойки» PAGEREF _Toc199394445 \h 40
3.5 Условия оказания услуги «Администрирование инфраструктуры ЦОД ПК для телекоммуникационной стойки» PAGEREF _Toc199394446 \h 40
3.6 Условия оказания услуги «Сервисное сопровождение серверной инфраструктуры ФОИВ в сегменте «Colocation» ЦОД ПК PAGEREF _Toc199394447 \h 41
3.7 Условия оказания услуги «Межсетевое экранирование информационного обмена» PAGEREF _Toc199394448 \h 42
3.8 Условия оказания услуги «Защита от атак типа «отказ в обслуживании» (AntiDDoS)» PAGEREF _Toc199394449 \h 43
3.9 Условия оказания услуги «Обеспечение антивирусной защиты на серверах в сегменте «Colocation» PAGEREF _Toc199394450 \h 43
3.10 Условия оказания услуги «Контроль и анализ защищенности для компонентов ИС, подлежащих миграции» PAGEREF _Toc199394451 \h 43
4 Предоставление ресурсов в Облаке ЦОД ПК PAGEREF _Toc199394452 \h 45
4.1 Общие сведения о предоставлении ресурсов и сервисов PAGEREF _Toc199394453 \h 45
4.2 Предоставление виртуального процессора vCPU PAGEREF _Toc199394454 \h 45
4.3 Предоставление виртуальной оперативной памяти vRAM PAGEREF _Toc199394455 \h 45
4.4 Предоставление виртуального жесткого диска типа 1 vHDD SATA PAGEREF _Toc199394456 \h 46
4.5 Предоставление виртуального жесткого диска типа 2 vHDD SAS PAGEREF _Toc199394457 \h 46
4.6 Предоставление виртуального жесткого диска типа 3 vHDD SSD PAGEREF _Toc199394458 \h 47
4.7 Предоставление сервиса по резервному копированию объектов, размещенных в Облаке ЦОД PAGEREF _Toc199394459 \h 47
4.7.1 Описание СТРК PAGEREF _Toc199394460 \h 47
4.7.2 Описание СРК пользовательских информационных объектов PAGEREF _Toc199394461 \h 48
5 Размещение ИС ФОИВ в Облаке PAGEREF _Toc199394462 \h 52
5.1 Общие требования к ИС, размещаемым в Облаке PAGEREF _Toc199394463 \h 52
5.2 Матрица и управление правами доступа обслуживающего персонала ИС PAGEREF _Toc199394464 \h 54
5.2.1 Условия администрирования и управления учетными записями PAGEREF _Toc199394465 \h 57
5.2.2 Условия использования технологических учетных записей PAGEREF _Toc199394466 \h 58
5.2.3 Требования к парольной защите PAGEREF _Toc199394467 \h 58
5.3 Условия взаимодействия модулей ИС, размещаемых в разных контурах PAGEREF _Toc199394468 \h 59
5.4 Условия взаимодействия с СУБД ИС PAGEREF _Toc199394469 \h 60
5.5 Условия обеспечения взаимодействия между различными ИС PAGEREF _Toc199394470 \h 60
5.6 Условия обеспечения безопасности программных компонентов на АРМ пользователя PAGEREF _Toc199394471 \h 61
5.7 Условия организационно-технического взаимодействия при размещении ИС в Облаке PAGEREF _Toc199394472 \h 61
5.8 Условия и требования по размещению инфраструктурных систем ФОИВ PAGEREF _Toc199394473 \h 63
5.8.1 Общие сведения об ИПО PAGEREF _Toc199394474 \h 64
5.8.2 Участники и этапы размещении ИПО в Облаке PAGEREF _Toc199394475 \h 64
5.8.3 Условия организационно-технического взаимодействия при размещении ИПО в Облаке PAGEREF _Toc199394476 \h 65
5.8.4 Пилотирование ИПО PAGEREF _Toc199394477 \h 67
5.9 Требования по обеспечению ИБ при использовании технологии контейнеризации приложений PAGEREF _Toc199394478 \h 68
5.9.1 Обеспечение защиты информации при управлении доступом PAGEREF _Toc199394479 \h 68
5.9.2 Обеспечение защиты вычислительных сетей PAGEREF _Toc199394480 \h 69
5.9.3 Автоматизированный контроль защищенности системы управления контейнеризацией PAGEREF _Toc199394481 \h 70
5.9.4 Защита от вредоносного кода PAGEREF _Toc199394482 \h 70
5.9.5 Управление инцидентами защиты информации PAGEREF _Toc199394483 \h 70
5.9.6 Защита среды виртуализации (контейнеризации) PAGEREF _Toc199394484 \h 71
5.10 Обеспечение ИБ АРМ администратора ГИС//ИСПДн PAGEREF _Toc199394485 \h 72
5.10.1 Общие требования к АРМ администратора ГИС/ИС ФОИВ PAGEREF _Toc199394486 \h 72
5.10.2 Обеспечение ИБ АРМ администратора ГИС/ИС ФОИВ на базе стационарного персонального компьютера Исполнителя PAGEREF _Toc199394487 \h 72
5.10.3 Обеспечение ИБ АРМ администратора ГИС/ИС ФОИВ в ИТ-инфраструктуре подрядчика PAGEREF _Toc199394488 \h 73
5.10.4 Обязательные требования к конфигурированию АРМ администратора ГИС/ИС ФОИВ PAGEREF _Toc199394489 \h 73
5.11 Условия, определяющие возможность проведения аттестации ИС ФОИВ PAGEREF _Toc199394490 \h 74
Приложение А (справочное) Схемы ЦОД ПК PAGEREF _Toc199394491 \h 77
Приложение Б (обязательное) Условия обеспечения ИБ в веб-приложениях PAGEREF _Toc199394492 \h 79
Приложение В (обязательное) Условия обеспечения аудита действий в ИС PAGEREF _Toc199394493 \h 84
Приложение Г (обязательное) Критерии качества паролей PAGEREF _Toc199394494 \h 89
Приложение Д (справочное) ФПД. Схема информационного обмена через ФПД между ЗК и ОК ЦОД ПК PAGEREF _Toc199394495 \h 90
Приложение Е (обязательное) Предотвращение реализации угроз безопасности информации PAGEREF _Toc199394496 \h 95
Приложение Ж (обязательное) Повышение уровня защищённости веб-приложений, размещенных в ЦОД ПК PAGEREF _Toc199394497 \h 97
Приложение И (обязательное) Правила наименования серверов/оборудования в ЦОД ПК PAGEREF _Toc199394498 \h 100
Приложение К (обязательное) Размещение модулей/подсистем/серверов ИС по сегментам сети в зависимости от их функционального назначения PAGEREF _Toc199394499 \h 104
Приложение Л (обязательное) Организация удаленного доступа администратору ИС и пользователей PAGEREF _Toc199394500 \h 107
Приложение М (обязательное) Порядок восстановления при проверке целостности объектов резервного копирования информационных систем ФОИВ в Облаке ЦОД Правительственного комплекса PAGEREF _Toc199394501 \h 119
Приложение Н (обязательное) Организация почтовых рассылок и отправка электронных сообщений средствами ИС ФОИВ PAGEREF _Toc199394502 \h 126
Термины и определения
Сервисная служба ПК – служба Исполнителя, обеспечивающая техническую поддержку и администрирование инфраструктуры ПК; включает подразделение, отвечающее за ИТ, и подразделение, отвечающее за ИБ, в инфраструктуре ПК.
Технологическая учетная запись – учетная запись, используемая процессами (сервисами) прикладного и системного уровня, для реализации функций ИС. 
Удаленный АРМ, удаленная ИС – АРМ и/или ИС считаются удаленными, если каналы связи, по которым осуществляется взаимодействие, выходят за пределы контролируемой зоны и не расположены в ПК. Взаимодействие удаленных АРМ и ИС с ресурсами/оборудованием ЦОД ПК осуществляется только посредством VPN.
Государственный контракт – Государственный контракт в текущей редакции, заключенный между ФКУ «Центр поддержки» и ПАО «Ростелеком». 
ИТ-инфраструктура – совокупность программных, аппаратных и телекоммуникационных ресурсов, средств вычислительной техники, необходимых для разработки, тестирования, предоставления, мониторинга, контроля или поддержки оказания ИТ-услуг. 
Тестирование – отработка протоколов/технологии взаимодействия с существующими элементами (или их обезличенными копиями в соответствующих зонах проведения пилотного проекта) действующей инфраструктуры ПК. Проводится на тестовой инфраструктуре ПК (с копиями компонент инфраструктуры ПК) без использования защищаемой информации только в Зоне разработки и тестирования (TST) ИТинфраструктуры, отделенной от Продуктивной (PRD), Предпродуктивной зон (PPD).
Пилотирование – проверка взаимодействия с действующей инфраструктурой. Допускается использование реальных данных и защищаемой информации. Осуществляется в Препродуктивной (PPD) или Продуктивной (PRD) зонах.
Перечень сокращений и обозначений
АВПО
–
Антивирусное программное обеспечение
АВР
–
Автомат включения резерва
АРМ
–
Автоматизированное рабочее место
БД
–
База данных
ВМ
–
Виртуальная машина
ГИС
–
Государственная информационная система
ГК
–
Государственный контракт
ДСП
–
Для служебного пользования
ЕСИА
–
Единая система идентификации и аутентификации
Заказчик
–
Федеральное казенное учреждение «Центр поддержки»
ЗК
–
Закрытый контур
ЗНО
–
Заявка на обслуживание
ИБ
–
Информационная безопасность
ИС
–
Информационная система
ИСПДн
–
Информационная система персональных данных
Исполнитель
–
ПАО «Ростелеком»
ИПО
–
Информационные системы, реализующие функции инфраструктурного ПО/решений
ИТ
–
Информационные технологии
КИИ
–
Критическая информационная инфраструктура
ЛВС
–
Локальная вычислительная сеть
МСЭ
–
Межсетевой экран
НДВ
–
Недокументированные возможности
НСДИ
–
Национальная система доменных имен
НПА
–
Нормативный правовой акт
НСД
–
Несанкционированные действия
ОК
–
Открытый контур
ОС
–
Операционная система
ПДн
–
Персональные данные
ПК
–
Правительственной комплекс
ПО
–
Программное обеспечение
Подрядная организация ФОИВ
Организация, являющаяся исполнителем ГК с ФОИВ на разработку, модернизацию, обслуживание или на размещение ИС в Облаке ЦОД ПК
РК
–
Резервное копирование
РТК ЦТ
–
ООО «РТК Цифровые Технологии»
СЗИ
–
Средства защиты информации
СКЗИ
–
Средства криптографической защиты информации
СКС
–
Структурированная кабельная сеть
СКУД
–
Система контроля и управления доступом
СОВ
–
Система обнаружения вторжений
СОИБ
–
Система обеспечения информационной безопасности
СРК
–
Система резервного копирования
СТРК
–
Система технологического резервного копирования
СУБД
–
Система управления базами данных
СХД
–
Система хранения данных
ТРП
–
Техно-рабочий проект
ТС
–
Терминальный сервер
ТУ
–
Технические условия
УД
–
Удаленный доступ
ФОИВ
–
Федеральные органы исполнительной власти
ФПД
–
Фонд программ и документации
ФСБ России
–
Федеральная служба безопасности Российской Федерации
ФСТЭК России
–
Федеральная служба по техническому и экспортному контролю
Функциональный заказчик
–
ФОИВ, организации, размещающие свои ИС в ЦОД правительственного комплекса
ЦОД
–
Центр обработки данных
ЦОД ПК
–
ЦОД правительственного комплекса
ЭП
–
Электронная подпись
API
–
Application Programming Interface, интерфейс программирования приложений
EDR
–
Endpoint Detection and Response, обнаружение и анализ вредоносной активности на конечных точках
GFS
–
Grand-Father-Son, алгоритм резервного копирования «дед-отец-сын»
IOPS
–
Input/Output Operations Per Second, количество операций ввода-вывода в секунду
NTA
–
Network Traffic Analysis, система анализа трафика
PPD
–
Предпродуктивная зона ИС
PRD
–
Продуктивная зона ИС
PREP
–
Подготовительная зона ИС
SIEM
–
Security Information and Event Management, система сбора и обработки событий информационной безопасности
SMTP
–
Simple Mail Transfer Protocol, простой протокол передачи почты
SPF
–
Sender Policy Framework, инфраструктура политики отправителя – расширение для протокола отправки электронной почты через SMTP
TST
–
Зона разработки и тестирования ИС
URL
–
Uniform Resource Locator, унифицированный указатель ресурса
VLAN
–
Virtual Local Area Network, виртуальная локальная компьютерная сеть
VPN
–
Virtual Private Network, виртуальная частная сеть
WAF
–
Web Application Firewall, межсетевой экран для веб-приложений.
WMI
–
Windows Management Instrumentation, инструментарий управления в ОСWindows
Общие сведения
Область применения
Настоящие технические условия (далее – ТУ) определяют техническую возможность размещения информационных систем (далее – ИС) федеральных органов исполнительной власти и организаций (далее – ФОИВ) в инфраструктуре Правительственного комплекса (далее – ПК).
Перечень документов, использованных при разработке
При подготовке ТУ использовались следующие нормативные документы:
Раздел «Общие критерии» ГОСТ Р ИСО/МЭК 15408 «Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий) часть 2 «Функциональные требования безопасности».
Приказ ФСТЭК России от 11.02.2013 № 17 (ред. от 28.05.2019) «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах».
Методический документ Меры защиты информации в Государственных информационных системах. Утвержден ФСТЭК России 11 февраля 2014 г.
Методический документ «Методика тестирования обновлений безопасности программных и программно-аппаратных средств». Утвержден ФСТЭК России 22.10.2022 г.
Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации».
Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».
Приказ Минкомсвязи от 26.11.2019 № 763 «Об утверждении требований, необходимых для проведения эксперимента по переводу информационных систем и информационных ресурсов федеральных органах исполнительной власти и государственных внебюджетных фондов в государственную единую облачную платформу, а также по обеспечению федеральных органов исполнительной власти и государственных внебюджетных фондов автоматизированными рабочими местами и программным обеспечением».
Модель угроз и нарушителя безопасности информации центра обработки данных ИТинфраструктуры Правительственного комплекса.
Участвующие стороны и зоны ответственности
Заказчик – Федеральное казенное учреждение «Центр поддержки». 
Функциональный заказчик – ФОИВ, размещающий свои ИС в ЦОД правительственного комплекса.
Исполнитель – ПАО «Ростелеком», организация, которая оказывает услугу по предоставлению ресурсов ЦОД и прочих услуг в ЦОД правительственного комплекса.
С учетом требований, указанных в настоящем документе, Функциональный заказчик принимает решение о составе оборудования, объеме виртуальных ресурсов, перечне и объеме услуг и ИС, подлежащих размещению в ЦОД правительственного комплекса.
Заказчик обеспечивает заказ и приемку выполнения Исполнителем услуг, предоставления информационно-технологических сервисов, в том числе по ИБ для целей обеспечения деятельности федеральных органов исполнительной власти и организаций, расположенных в здании ПК по адресу г. Москва, Пресненская наб., д. 10, строение 2 (Башня 2) (далее – Башня ПК).
Функциональный заказчик дает рекомендации по составу переносимого оборудования, объему виртуальных ресурсов, перечню и объему услуг и ИС, подлежащих размещению в ЦОД правительственного комплекса, с учетом требований настоящего документа. Исполнитель оказывает услуги по размещению ИС с учетом требований настоящего документа.
Исполнитель обеспечивает ресурсы ЦОД правительственного комплекса, осуществляет прием и постановку на учет оборудования, обеспечивает выполнение заказанных и согласованных услуг, реализует организационно-режимные меры по физической безопасности и обеспечивает сервисное сопровождение серверной инфраструктуры в сегменте «Colocation» и сегменте «Облако» в соответствии с положениями и условиями Государственного контракта и настоящего документа.
Описание ЦОД Правительственного комплекса
Структура ЦОД правительственного комплекса
ЦОД Правительственного комплекса (далее – ЦОД ПК) расположен в дата-центре ПАО «Ростелеком» «Москва II» по адресу пл. Академика Курчатова, д. 1, стр. 14.
В ЦОД ПК для размещения оборудования и компонентов ИС ФОИВ предусмотрены следующие физически независимые разделённые контуры:
Открытый контур (далее – ОК) – группа выделенных VLAN, предназначенных для размещения оборудования, виртуальных ресурсов и компонент ИС ФОИВ, к которым предоставляется доступ из сети «Интернет». В ОК предусмотрена возможность размещения как в формате услуги «Colocation» (размещение аппаратных компонентов Заказчика в монтажных конструктивах и помещениях Исполнителя), так и в формате услуги «Облако» (размещение ИС Заказчика на виртуальных вычислительных ресурсах в среде виртуализации Исполнителя). В ОК ЦОД ПК в рамках услуги «Облако» не может храниться, обрабатываться в открытом виде служебная, конфиденциальная информация ФОИВ, а также информация, которую можно отнести к персональным данным.
Закрытый контур (далее – ЗК) – группа выделенных VLAN, предназначенных для размещения компонент ИС ФОИВ, не взаимодействующих непосредственно с сетью «Интернет». В ЗК допускается хранение, обработка служебной, конфиденциальной информации, а также персональных данных. В ЗК предусмотрена возможность размещения компонент ИС ФОИВ только в формате услуги «Облако». Таким образом, в ЗК ИТ-инфраструктуры ПК возможно размещение только виртуальных компонент ИС ФОИВ.
Контур подключения к сети «Интернет» – реализует возможности подключения к сетям связи общего пользования.
Шлюзовой контур – представляет собой изолированный сетевой сегмент с развернутыми инструментами, обеспечивающими контролируемый обмен данными между контурами ОК и ЗК.
Сегмент «Colocation» – представляет собой совокупность логически раздельных на уровне L2 сетевых сегментов, отделенных от других сетей МСЭ Исполнителя. 
ЦОД ПК имеет аттестат соответствия ФСТЭК России по требованиям безопасности информации для государственных информационных систем (К1), информационных систем персональных данных (УЗ1). Допускается размещение в ЦОД ПК информационных систем общего пользования II класса, при условии реализации необходимого дополнительного набора мер защиты информации, включая не предоставляемые в ЦОД ПК по контракту. 
Структурная схема и Cхема покрытия ЦОД ПК сервисами ИБ после завершения миграции представлены в Приложении REF _Ref35436307 \r \h \* MERGEFORMAT Приложение А.
Описание сегмента «Colocation»
Сегмент «Colocation» физически представляет собой выделенную часть инфраструктуры ЦОД ПК, оборудованную необходимыми инженерными системами, монтажными конструктивами, СКС и коммутационным/маршрутизирующим сетевым оборудованием, предназначенную для размещения оборудования Функционального Заказчика.
Логически, сегмент «Colocation» представляет собой изолированный сертифицированными ФСТЭК России средствами межсетевого экранирования сетевой сегмент с возможностью сетевой связности с сетями общего пользования, Облачной инфраструктурой (далее – Облако) в ЦОД ПК и ресурсами ИТ-инфраструктуры ПК.
Описание Облака 
Облако для размещения ИС ФОИВ представляет собой программно-аппаратный комплекс, в который входят вычислительные ресурсы и ресурсы хранения данных, управляемые с помощью средств виртуализации VMWare (в ЗК и ОК установлена версия компонентов среды виртуализации – 7.0.3).
Архитектура Облака
Облако размещается на виртуальных серверных ресурсах ЗК и ОК ЦОД ПК.
Предполагается, что ИС ФОИВ, размещаемые в Облаке, имеют модульную архитектуру, в которой модули этих ИС осуществляют информационное взаимодействие через IP-сеть.
Для каждой ИС в каждом контуре выделяется IP-сеть в соответствии с IP-адресацией, определенной в Облаке. Сегментация сети в Облаке и размещение модулей (серверов) ИС ФОИВ в сегментах описаны в подразделе REF _Ref111048176 \r \h 2.6. Сетевые взаимодействия между разными IP-сетями по умолчанию не разрешены.
При сетевом взаимодействии между разными IP-сетями необходимо учитывать следующие ограничения:
Для модулей ИС ФОИВ, размещаемых в ЗК Облака, могут быть разрешены следующие сетевые взаимодействия:
с АРМ пользователей ИС, расположенных в ЗК ФОИВ в Башне ПК;
с АРМ администраторов ИС, расположенных в ЗК ФОИВ в Башне ПК и только через терминальный сервер администраторов;
с удалёнными АРМ администраторов, при условии использования ГОСТ VPN и Сервиса контроля действий привилегированных пользователей (предоставляется в рамках ГК) и только через терминальный сервер администраторов;
с модулями других ИС (ведомственных/ФОИВ/инфраструктурных), расположенных в ЗК;
с другими модулями этой же ИС, расположенными в ЗК и ОК;
с технологическими серверами ИТ и ИБ систем в ЗК, на базе которых Исполнителем предоставляются сервисы и услуги в рамках Государственного контракта. 
Для модулей ИС ФОИВ, размещаемых в ОК Облака, могут быть разрешены следующие сетевые взаимодействия:
с удаленными АРМ пользователей ИС, при условии использования VPN или ГОСТ VPN;
с удаленными АРМ администраторов ИС, при условии использования VPN или ГОСТ VPN и только через терминальный сервер администраторов;
с АРМ пользователей, расположенных в ОК ФОИВ в Башне ПК;
с АРМ администраторов ИС, расположенных в ОК ФОИВ в Башне ПК, но только через терминальный сервер администраторов;
с АРМ пользователей сетей передачи данных общего пользования (для публичных информационных ресурсов);
с другими удаленными ИС; 
с модулями других ИС (ведомственных/ФОИВ/инфраструктурных), расположенных в ОК;
с серверами ИТ и ИБ систем в ОК, на базе которых Исполнителем предоставляются сервисы и услуги в рамках Государственного контракта;
с другими модулями этой же ИС, расположенными в ЗК и в ОК;
с ресурсами в сети «Интернет» в соответствии с условиями и ограничениями на доступ, приведенными в подразделе REF _Ref111048176 \r \h \* MERGEFORMAT 2.6.
Все сетевые взаимодействия должны быть описаны в матрице межсетевого взаимодействия и оформлены в соответствующих заявках на сетевое взаимодействие и разделах пояснительной записки на размещение ИС в Облаке.
ИС ФОИВ, размещаемые в Облаке, должны иметь модульную (трёхзвенную) архитектуру, в которой модули/компоненты этой ИС осуществляют информационное взаимодействие через IP-сеть и размещены на разных ВМ согласно трёхзвенной архитектуре. Запрещается размещать компоненты приложения (АРР) и СУБД (DB) на одной ВМ, или размещать APP на клиентских АРМ (Client), а также совершать любые другие действия, нарушающие принципы размещения компонентов ИС, при использовании трехзвенной архитектуры (Client-APP-DB).
Для обеспечения жизненного цикла ИС, имеющих собственный цикл разработки, в Облаке организуется несколько логических зон, предназначенных для размещения функциональных модулей ИС:
Зона разработки и тестирования ИС (TST);
Предпродуктивная зона ИС (PPD);
Продуктивная зона ИС (PRD);
Подготовительная зона ИС (PREP).
Размещение средств разработки допускается только на ресурсах ИС в Зоне разработки и тестирования ИС и в Предпродуктивной зоне ИС, то есть на виртуальных серверах самой ИС. Размещение средств разработки на терминальных серверах администраторов запрещается. На терминальных серверах допускается использование клиентов RDP до Windows-серверов и SSH до *nix-серверов.
Удаленный доступ в инфраструктуру ОЦОД c использованием сервисов ГОСТ VPN разрешен только по протоколу RDP к терминальным серверам. При этом в рамках RDP – сессии, проводится блокировка (запрет использования) буферов обмена. Таким образом, заблокирована возможность файлового обмена с ИТ-инфраструктурой ЦОД.
Логические зоны Облака
Зона разработки и тестирования ИС
Зона разработки и тестирования ИС располагается в Облаке ОК ЦОД ПК и может иметь доступ в сеть «Интернет» через соответствующий прокси сервер. При этом доступ из сети «Интернет» к серверам в Зоне разработки и тестирования ИС не предоставляется.
Зона разработки и тестирования ИС:
предназначена для разработки ПО ИС и не содержит данных, подлежащих защите (обеспечение целостности ПО и отсутствие НДВ являются зоной ответственности ФОИВ и его подрядчиков);
предназначена для тестирования работоспособности обновлений/ПО ИС в Облаке с общесистемным ПО определенной версионности и наложенными средствами ИБ;
не содержит данных, подлежащих защите, т.е. в работе используются только обезличенные или тестовые данные;
располагается в Облаке ОК ЦОД ПК;
доступна для разработчиков, тестировщиков, администраторов ИС;
безопасность удаленного доступа в зону обеспечивается на безе технологий ГОСТ VPN.
Предпродуктивная зона ИС 
Предпродуктивная зона ИС предназначена для тестирования ПО в условиях, приближенных к продуктивными. Содержит технологические копии системного и прикладного ПО, используемого в Продуктивной зоне ИС.
Предпродуктивная зона ИС:
предназначена для работы с обезличенными данными, обезличенными в соответствии с требованиями регулятора;
может быть расположена в Облаке ОК и ЗК ЦОД ПК (определяется архитектурой ИС);
компоненты ИС, размещенные в ОК, могут иметь доступ в сеть «Интернет» через соответствующий прокси сервер;
доступна для разработчиков, тестировщиков, администраторов ИС по согласованию с Функциональным Заказчиком (владельцем системы);
безопасность удаленного доступа в зону обеспечивается на безе технологий ГОСТ VPN (раздел REF _Ref112245013 \r \h 2.6.2).
Продуктивная зона ИС 
Продуктивная зона ИС:
предназначена для работы пользователей с ИС ФОИВ;
содержит данные, подлежащие защите, согласно результатам категорирования ИС;
ИС, размещенная в зоне PROD, может быть аттестована;
располагается в Облаке ОК и ЗК ЦОД ПК (определяется архитектурой ИС);
компоненты ИС, размещенные в ОК, соответственно могут устанавливать соединение с сетью «Интернет» только через соответствующий прокси сервер;
доступна для администраторов и пользователей ИС;
запрещается размещение программных средств разработки;
безопасность удаленного доступа в зону обеспечивается на безе технологий ГОСТ VPN (раздел REF _Ref112245013 \r \h 2.6.2).
Подготовительная зона ИС 
Подготовительная зона ИС предназначена для размещения ИС, находящихся в процессе подготовки и проведения миграции в ЦОД ПК в соответствии с настоящими ТУ.
Подготовительная зона ИС является аналогом сегмента «Colocation» на вычислительных ресурсах Облака ЦОД ПК.
Подготовительная зона ИС:
содержит данные, подлежащие защите согласно результатам категорирования ИС, т.к. используются продуктивные данные;
может быть расположена в Облаке ОК и ЗК ЦОД ПК (определяется архитектурой ИС);
компоненты ИС, содержащие данные, подлежащие защите, и/или к которым осуществляется доступ пользователей с АРМ ЗК, должны быть размещены в Облаке ЗК;
фронтальные компоненты ИС, предназначенные для информационного обмена с сетью «Интернет», должны быть размещены в Облаке ОК (для программных компонентов) или в сегменте «Colocation» (для отдельных физических компонентов);
ресурсы ИС, размещенные в PREP, доступны в режимах опытной и опытно-промышленной эксплуатации;
ИС, размещенная в зоне PREP, не может быть аттестована;
ресурсы ИС, размещаемой в данной зоне, по согласованию с Функциональным Заказчиком (владельцем системы), доступны для пользователей, разработчиков, тестировщиков и администраторов ИС.
Обеспечение ИБ в ЦОД ПК
Сервисы обеспечения ИБ
В целях обеспечения определенного ФСТЭК России уровня категорирования ИС Исполнителем развернуты сертифицированные СЗИ и СКЗИ, с использованием которых в ЦОД предоставляется необходимый полный комплекс услуг ИБ в рамках сервисной модели:
сервис антивирусной защиты автоматизированной конечной точки;
сервис межсетевого экранирования и защиты от сетевых атак для ЦОД Исполнителя и общего узла взаимодействия с сетью «Интернет»;
сервис защиты от распределённых атак вида «отказ в обслуживании»;
сервис управления уязвимостями, инцидентами и компьютерными атаками (SOC); 
сервис защиты среды виртуализации;
сервис предоставления шлюза удаленного доступа для администраторов;
сервис контроля действий привилегированных пользователей;
сервис расширенной антивирусной защиты серверов ГИС и ИСПДн;
сервис системы защиты конечных точек от сложных кибератак Endpoint Detection and Response (EDR);
сервис анализа сетевого трафика (NTA);
сервис по комплексному анализу защищенности информационной системы;
сервис антивирусная защита почтового сервера;
сервис предоставления криптографической защиты доступа внешних пользователей к государственным информационным системам;
сервис по предоставлению мультимодального межсетевого экранирования уровня приложения.
сервис предоставления второго фактора аутентификации привилегированных пользователей (администраторов);
сервис обеспечения дополнительного фактора аутентификации при удаленном доступе в ИТ-инфраструктуру.
Требования по обеспечению удаленного доступа 
Удаленный защищенный доступ к ЦОД ПК: сегменту «Colocation», виртуальным средам ЗК и ОК Облака ЦОД ПК – реализуется на базе сертифицированных СКЗИ класса КС3. Криптографическая защита информационного обмена обеспечивается построением VPN на уровне протоколов TLS, так и на IP-уровне. При этом для доступа администраторов ИС/ГИС/Системного ПО используются решения фирмы «ИнфоТеКС» «VipNet», для доступа пользователей ИС/ГИС КриптоПро «nGate». Для получения VPN-доступа ФОИВ необходимо самостоятельно приобрести ViPNet-клиентов. Порядок организации удалённого доступа администраторами ИС приведён в Приложении REF _Ref112103390 \n \h \* MERGEFORMAT Приложение Л.
Доступ удалённых администраторов и удалённых пользователей к ресурсам ЦОД ПК (помимо VPN-соединения) осуществляется через терминальный сервер.
Терминальный сервер администраторов относится к средствам ИБ ЦОД ПК. Терминальный сервер администраторов не является сервером администрирования ИС. Терминальный сервер не должен иметь стороннего ПО для администрирования и работы с ИС кроме RDP-клиента, Интернет-браузера и PuTTY для осуществления подключения к Windows- и Linux-серверам, на которых размещаются ИС ФОИВ.
В рамках удаленного доступа осуществляется полнотекстовый аудит действий администраторов и других привилегированных пользователей терминального сервера.
При необходимости размещения средств администрирования (консоль доступа к СУБД, скрипты администрирования, средства мониторинга и СРК и т.д.).) необходимо включить отдельную ВМ в состав ИС и размещать средства администрирования и разработки на выделенной ВМ.
На терминальном сервере также не допускается размещение данных ФОИВ, обрабатываемых ГИС/ИС, учетных данных привилегированных и иных пользователей. Организация удаленного доступа администраторов ИС описана в Приложении Л.
Файловый обмен между контурами и зонами возможен только через Фонд программ и документации (далее – ФПД). Информация о ФПД представлена в разделе REF _Ref114085073 \n \h 2.6.7 и Приложении Д.
Организация сетевого взаимодействия через МСЭ в ЦОД ПК осуществляется после подачи заявки на сетевой доступ.
Требования ИБ, выполняемые ФОИВ при размещении оборудования и миграции ИС в сегменте «Colocation»
Выполнение данных требований необходимо для обеспечения ИБ в сегменте «Colocation», а также для возможности проведения аттестации ИС ФОИВ, являющихся ГИС и/или ИСПДн, на соответствие требованиям по защите информации.
Все ПО, обеспечивающее ИБ на оборудовании, должно быть лицензировано и иметь действующие сертификаты ФСТЭК России (в том числе, в случае наличия сертификатов ФСТЭК России на прикладное ПО), а лицензии должны быть сроком не менее 3 месяцев с момента размещения оборудования в сегменте «Colocation».
Количество лицензий на ПО в части ИБ должно быть не меньше актуального количества перевозимого оборудования, ОС или пользователей (в зависимости от типа применимости). В случае недостаточности Функциональный заказчик должен осуществить дополнительную поставку необходимого количества действующих лицензий.
ОС серверов и гипервизоры в сегменте «Colocation» должны соответствовать актуальным на момент миграции требованиям совместимости производителей СЗИ, применяемых в инфраструктуре ЦОД ПК: «Лаборатория Касперского», «Код Безопасности». В случае несоответствия указанным требованиям Функциональному заказчику рекомендуется произвести обновление (замену) ОС и гипервизора до актуальных версий.
В случае невозможности обновления ОС/гипервизоров до актуальных версий, поддерживаемых сертифицированными СЗИ, или в случае отсутствия поддержки ОС/гипервизоров в технической документации производителей СЗИ, такие ОС/гипервизоры не могут быть подключены к контуру безопасности ИТ-инфраструктуры ПК и не могут быть использованы для оказания услуг и сервисов ИБ ПК.ЦОД ПК. Такие технические средства размещаются в сегменте «Colocation» без подключения каких-либо услуг и сервисов ИБ ЦОД ПК. Обеспечение ИБ таких технических средств находится в зоне ответственности Функционального заказчика и выполняется текущими СЗИ ФОИВ, которые также перемещаются в сегмент «Colocation» ЦОД ПК.
На оборудовании Функционального заказчика должно быть установлено антивирусное ПО (далее – АВПО). Лицензии на АВПО могут быть предоставлены Исполнителем в рамках оказания им сервиса антивирусной защиты. Возможно применение лицензий АВПО производства компании «Лаборатория Касперского», имеющихся у Функционального Заказчика.
В случае применения виртуализации на оборудовании Функционального заказчика рекомендуется установить АВПО для виртуальных сред и сертифицированное средство защиты среды виртуализации. Возможно применение ранее установленного АВПО для виртуальных сред и сертифицированного средства защиты среды виртуализации Функционального заказчика. При необходимости аттестации ИС/ГИС, размещаемой в виртуальной среде «Colocation», требуется установка сертифицированного средства защиты среды виртуализации.
В случае наличия применяются установленные в серверы на момент перевозки аппаратно-программные модули доверенной загрузки, обладающие действующими сертификатами ФСТЭК России (в случае отсутствия действующих сертификатов модули не подлежат миграции).
До и/или после осуществления миграции ИС в сегменте «Colocation» Исполнитель проводит анализ защищенности (инструментальное сканирование), а Функциональный заказчик должен устранить выявленные уязвимости. После устранения проводится повторный анализ защищенности (инструментальное сканирование) и устранение уязвимостей.
Описание СЗИ и требований по обеспечению ИБ в сегменте «Colocation»
Обеспечение ИБ внутри сегмента «Colocation» находится зоне ответственности Функционального заказчика. Вместе с тем Исполнитель, разместивший физическое оборудование Функционального заказчика в ЦОД ПК, накладывает ограничения на информационный обмен сегмента «Colocation», который может негативно повлиять на информационные ресурсы ЦОД ПК и сегментов «Colocation» иных Функциональных Заказчиков, а также АРМ ФОИВ, размещенные в Башне ПК.
Исполнитель обеспечивает контроль информационного обмена сегмента «Colocation» посредством применения сертифицированных МСЭ, а также сертифицированных средств обнаружения вторжений.
Политика межсетевого экранирования обеспечивает возможность сетевой связности с сетями общего пользования, ЦОД ПК и ресурсами ИТ-инфраструктуры ПК. МСЭ Исполнителя реализуют политику ИБ, обеспечивающую ограничение, в том числе проксирование входящего и исходящего информационного обмена.
Требования по организации информационного обмена сегмента «Colocation» Заказчика с сетью «Интернет»:
По умолчанию установление соединения с сетью «Интернет» с серверов ОК сегмента «Colocation» невозможно. Организация такого взаимодействия возможна при условии принятия ФОИВ рисков ИБ и организации проксирования исходящих соединений на уровне L7.
Перенос ресурсов (хостов, серверов) Заказчика, имеющих «белые» (публичные) IP-адреса в сегменте «Colocation», производится путем изменения адресации этих узлов на частные IP-адреса. В дальнейшем для выхода в сеть «Интернет» такие хосты используют «белые» (публичные) адреса, предоставляемые Исполнителем. Исключение может составлять случай переноса хостов, используемых для построения VPN на базе отечественных алгоритмов шифрования. 
Блокировка доступа к разделяемым серверным ресурсам (каталогам хранения и обмена), реализованного с использованием небезопасных протоколов взаимодействия (SMB, FTP и т.д.).
Блокировка удаленного доступа пользователей и администраторов к серверам по небезопасным протоколам удаленного управления (Telnet, HTTP и т.д.). Доступ администраторов из Башни ПК к серверам в сегменте «Colocation» возможен только через терминальный сервер, а удалённых администраторов – через терминальный сервер и при наличии шифрования по ГОСТ VPN.
Ограничение использования внешних ИТ-сервисов таких как NTP, DNS. Доступ к серверам ОК будет разрешен по NTP только на адрес NTP-сервера ЦОД ПК. Доступ к серверам ОК по DNS может быть разрешен только на ограниченный перечень предварительно согласованных внешних DNS-серверов, при условии принятия ФОИВ возникающих рисков ИБ. Требуется использовать российские DNS-серверы, корпоративные DNS-серверы и/или DNS-серверы вашего оператора связи в целях недопущения перенаправления пользователей организации на вредоносные ресурсы или осуществления иной вредоносной активности.
В соответствии с «Регламентом эксплуатации ИТ-инфраструктуры Правительственного комплекса, осуществляемой Исполнителем, проводится периодический контроль защищенности путём сетевого сканирования внешних и внутренних IP-адресов и анализа полученных данных на предмет наличия уязвимостей. По результатам проведенной работы Исполнитель предоставляет Функциональному заказчику отчет, содержащий требования и рекомендации по усилению мер ИБ.
Для защиты от вирусов в сегменте «Colocation» используются средства антивирусной защиты производства компании «Лаборатория Касперского». Политика ИБ и настройки антивирусной защиты контролируются Исполнителем.
В Приложении REF _Ref112082507 \n \h \* MERGEFORMAT Приложение Е приведена более подробная информация по предотвращению реализации угроз безопасности информации.
В Приложении REF _Ref112082516 \n \h \* MERGEFORMAT Приложение Ж приведена более подробная информация по повышению уровня защищённости веб-приложений, размещенных в ЦОД ПК.
Требования по обеспечению ИБ в ЦОД ПК
Все сетевые взаимодействия между физическими контурами и логическими сетевыми сегментами/зонами ЦОД ПК осуществляются посредством сертифицированных ФСТЭК России МСЭ. Все сетевые взаимодействия отслеживаются сертифицированными ФСТЭК России средствами обнаружения вторжений. 
Все компоненты ИС, требующие взаимодействия с сетью «Интернет», размещаются в ОК, все компоненты ИС, не требующие непосредственного взаимодействия с сетью «Интернет», размещаются в ЗК.
Доступ из сети «Интернет» к ресурсам зон ОК определяется политикой информационного обмена, реализованной на МСЭ. При оформлении заявки на развертывание ГИС/ИС в ЦОД ПК Функциональный Заказчик должен указать минимальный перечень IP-адресов, портов и протоколов, необходимых для организации работы серверов ГИС/ИС в сети «Интернет». 
Инициирование информационного обмена с сетью «Интернет» возможно только для серверов, размещенных в ОК ЦОД ПК: Зоне разработки и тестирования (TST) ОК, Подготовительной зоне (PREP) ОК. 
Серверы Предпродуктивной зоны ИС (PPD) ОК, Продуктивной зоны (PRD) ОК в общем случае не должны являться инициаторами соединения с ресурсами сети «Интернет».
Контроль и ограничение инициирования соединения серверов ИС/ГИС ОК с сетью «Интернет» осуществляется с помощью прокси-сервера, определяющего политику информационного взаимодействия только по заранее согласованным URL-ссылкам и IP-адресам этих URL. При этом политика прокси-сервера не должна допускать взаимодействие с облачными ресурсами, например, GitHub, Google Drive и т.п. в целом. Получение доступа через прокси-сервер в сеть «Интернет» возможно только к отдельным разделам облачных ресурсов. Доступ к отдельным официальным серверам производителей ПО с целью получения дистрибутивов, исходных кодов, документации, используемой для разработки и сопровождения прикладного ПО ИС/ГИС ФОИВ, запрещён. Передача дистрибутивов, исходных кодов, документации реализуется только через ФПД. 
Безопасность информационного взаимодействия модулей одной ИС, расположенных в разных контурах (ОК и ЗК), может обеспечиваться посредством шлюзов прикладного уровня (например, XML-шлюза), размещаемых в шлюзовом контуре. В ИС должна быть заложена возможность перехода на взаимодействие между серверами в ОК и в ЗК через шлюз прикладного уровня на этапе подготовки и доработки ИС к размещению ИС в Облаке. До момента реализации шлюза прикладного уровня, как временное решение, допускается организация взаимодействия напрямую между ОК и ЗК посредством XML-схем, передаваемых по протоколу HTTPS. Прямой доступ по портам управления, файловый и блочный доступ, (например, 22 порт по протоколам SSH, SMB, NFS, FTP, SFTP, Rsync) между ОК и ЗК запрещён, даже как временное решение.
В виртуальных средах ЗК и ОК Облака устанавливается сертифицированное средство защиты среды виртуализации.
Для защиты от вирусов каждой ВМ в виртуальных средах ЗК и ОК Облака на усмотрение Исполнителя используются антивирусные решения производства компании «Лаборатория Касперского». На серверах под управлением ОС Windows, входящих в состав ГИС/ИСПДн, в целях минимизации рисков, связанных с доступностью и целостностью обрабатываемой информации, рекомендуется применять расширенные лицензии АВПО производства компании «Лаборатория Касперского»,», обеспечивающие усиленный контроль//блокировку запускаемых программ по заранее определенному («черному списку»), а также расширенный аудит событий. Расширенные лицензии АВПО производства компании «Лаборатория Касперского» по согласованию с ФОИВ могут быть предоставлены Исполнителем в рамках оказания услуги «Сервис расширенной антивирусной защиты серверов ГИС и ИСПДн».
Для ГИС, подлежащих аттестации в соответствии с требованиями ФСТЭК России, на каждую ВМ в виртуальных средах ЗК и ОК Облака должно быть установлено СЗИ от НСД. Установка данного СЗИ и его сопровождение находится в зоне ответственности Заказчика и/или подрядчика Заказчика по сопровождению ГИС/ИС. Альтернативным вариантом установки на сервер ГИС /ИС СЗИ от НСД является использование в составе ГИС сертифицированного ФСТЭК России системного ПО северной ОС и СУБД. 
В Облаке осуществляется периодический контроль уязвимостей платформы и среды виртуализации путём сетевого сканирования внешних и внутренних IP-адресов и анализа полученных данных на предмет наличия уязвимостей, а также дополнительных сетевых и программных сенсоров различных уровней, средств поведенческого анализа, средств защиты от направленных (таргетированных) атак.
Для своевременного устранения известных уязвимостей на платформу виртуализации, ОС и системное ПО регулярно, по мере появления, должны устанавливаться актуальные обновления, опубликованные производителем ПО, что подразумевает проверки совместимости обновлений и ПО на зоне разработки и тестирования ИС, в соответствии с регламентом обновления ИС.
Необходимо выполнить обеспечение следующих мер по защите от внешних угроз:
Минимизировать прямые сетевые доступы между контурами ОК и ЗК. В списке доступов могут присутствовать взаимодействия с СУБД и средствами мониторинга по следующим портам:
MySQL/MariaDB: 3306;
PostgreSQL: 5432, 5433;
SQLite: 1433;
MongoDB: 27017, 27018, 27019;
Zabbix: 10050;
SNMP: 161, 162;
syslog: 514.
Исключить возможность использования встроенных видео- и аудиофайлов, интерфейсов взаимодействия API, «виджетов» и других ресурсов, загружаемых со сторонних сайтов, заменив их при необходимости гиперссылкой на такие ресурсы.
По возможности применить на серверах электронной почты технологию Sender Policy Framework (SPF) для подтверждения их легитимности, а также в целях контроля входящей электронной почты. Включить компонент «Контентная фильтрация» для форматов исполняемых файлов.
Использовать только российские DNS-серверы. Использовать только корпоративные DNS-серверы и/или DNS-серверы вашего оператора связи в целях недопущения перенаправления пользователей организации на вредоносные ресурсы или осуществления иной вредоносной активности. Если DNS-зона обслуживается иностранным оператором связи – перенести ее в информационное пространство Российской Федерации.
Исключить применение сервисов подсчета и сбора данных о посетителях, сервисов предоставления информации о местоположении и иных сервисов, разработанных иностранными организациями (например, onthe.io, ReCAPTCHA, YouTube, Google Analytics, Google Maps, Google Translate, Google Analytics).
Использовать средства удаленного администрирования, функционирование которых не осуществляется через иностранные информационные ресурсы. 
Запретить возможность размещения защищаемой информации в облачных сервисах cети «Интернет», передачу защищаемой информации через мессенджеры, Google Docs и другие сервисы.
В Приложении REF _Ref112082507 \n \h \* MERGEFORMAT Приложение Е приведена более подробная информация по предотвращению реализации угроз безопасности информации.
В Приложении REF _Ref112082516 \n \h \* MERGEFORMAT Приложение Ж приведена более подробная информация по повышению уровня защищённости веб-приложений, размещенных в ЦОД ПК.
Использование свободно распространяемого ПО
В составе ИС\ГИС ФОИВ допускается использование свободно распространяемого прикладного ПО. Вместе с тем, нарушение регуляторных требований ФСТЭК России по использованию данного ПО может негативно сказаться на результатах аттестационных испытаний ИСПДн/ГИС. Перед принятием решения о включении в состав серверов ИСПДн/ГИС такого ПО Функциональным заказчиком должна быть проведена оценка ИТ и ИБ рисков.
ПО отечественного производителя в реестре МЦ_
Перед использованием необходимо проведение тестирования свободно распространяемого ПО на совместимость с иным ПО ИС/ГИС, а также проверка источника распространения, путем сверки контрольных сумм либо сверки сертификатов производителя. Все проверки и последующее тестирование ПО в составе ИС/ГИС должны проводиться в Предпродуктивной зоне ИС.
Прикладное ПО иностранного производителя
Свободно распространяемого ПО с открытым кодом подлежит проверке по (п.2.6.6.1), а также последующему тестированию в объеме, аналогичному определенному ФСТЭК России [4].
Прикладное ПО с закрытым кодом также подлежит тестированию. Использование такого ПО несет в себе повышенные ИТ и ИБ риски. При условии отсутствия альтернативы среди отечественного ПО, использование иностранного ПО с закрытым кодом возможно только после принятия возникающих рисков уполномоченным работником Функционального заказчика или Исполнителя.
Дополнительные требования ИБ по размещению ИС в Подготовительной зоне (ОК и ЗК) ЦОД ПК
В Подготовительной зоне принимается следующий порядок размещения ИС:
Лицензии на системное ПО предоставляются в соответствии с контрактом на ИТ-инфраструктуру ПК в установленным порядке, либо предоставляются подрядчиком ФОИВ.
В случае инсталляции ИС с дистрибутивов:
установку ОС производит Исполнитель с официальных дистрибутивов, полученных от вендоров, либо разработчиков ИС ФОИВ;
прикладное ПО устанавливает и настраивает администратор ИС ФОИВ;
В случае переноса/копирования образа существующей ВМ:
создание копии/образа ВМ осуществляет администратор ИС;
установку/копирование образа ВМ в Облако осуществляет Исполнитель.
Неудовлетворительное состояние ИБ любой из ИС, размещенных в ЦОД ПК, может оказать негативное влияние на работу ИС других ФОИВ в ЦОД ПК. В этой связи перед проведением переноса образа существующей ВМ в ЦОД ПК Исполнитель может выполнить анализ архитектуры, состояния ИС, а также ОС ВМ на предмет соответствия регуляторным требованиям ИБ. В случае наличия в ИС рисков ИБ, которые невозможно компенсировать наложенными средствами ИБ, миграция ИС в ЦОД ПК путем переноса существующей ВМ не производится. Перенос ИС в ЦОД ПК в этом случае может быть выполнен только инсталляцией ИС с дистрибутивов, предоставляемых ФОИВ.
Ответственным за обеспечение ИБ в Подготовительной зоне является Функциональный заказчик. Это обусловлено тем, что при подготовке/проведении миграции ИС в Облако со стороны Функционального Заказчика и его соисполнителей требуется комплекс мер по приведению компонентов ИС в соответствие требованиям настоящих ТУ, в том числе, доработка прикладной части ИС, что выходит за пределы зоны ответственности Исполнителя.
Для ГИС, имеющих в своём составе публичные веб-приложения, по запросу Функционального Заказчика может оказываться сервис межсетевого экранирования уровня приложения (WAF).
При этом, в зоне ответственности Заказчика находится обеспечение: 
актуальности прикладного и системного ПО, входящего в пакет программ ИС, развернутых в Подготовительной зоне;
тестирование и, в случае успеха, применение публикуемых на сайтах производителей обновлений ПО, устраняющих критичные уязвимости;
лицензионной чистоты прикладного и специального ПО, полученного из доверенных источников.
ФПД ФОИВ ЦОД ПК
ФПД обеспечивает хранение эталонных образов дистрибутивов и документации на ИС ФОИВ, а также передачу данных между контурами и зонами Облака.
Назначение ФПД:
размещение, развертывание ПО, используемого в составе ИС/ГИС ФОИВ в Продуктивной зоне ИС, Предпродуктивной зоне ИС, производится исключительно с дистрибутивов, находящихся в ФПД;
хранение эталонных образов, дистрибутивов ПО ИС/ГИС ФОИВ, установленного в Подготовительной зоне ИС; Продуктивной зоне ИС, Предпродуктивной зоне ИС;
хранение документации на ПО ИС/ГИС ФОИВ, развернутого в ЦОД ПК;
загрузка/перенос данных в Подготовительную, Предпродуктивную и Продуктивную зоны ИС из внешних источников, зоны разработки и тестирования или сегмента «Colocation». В ходе загрузки/переноса выполняются процедуры контроля на предмет отсутствия вредоносного программного кода;
обеспечение возможности оперативного восстановления ИС/ГИС из актуальных эталонных копий ПО;
передача данных из одной зоны в другую в ЗК и ОК.
ФПД по сути является файловым хранилищем и предполагает заказ ФОИВ дополнительных объемов по услуге «Файловый сервис». Заказ данной услуги является обязательным условием размещения ИС/ГИС в ЦОД ПК. Выделяемый объём памяти на одну ИС/ГИС по умолчанию составляет 50 ГБ в ФПД ОК и 50 ГБ в ФПД ЗК. Изменение выделяемого объёма производится после согласования с ФОИВ.
В целях оптимизации места размещения данные для размещения в ФПД могут быть сформированы в виде архива в форматах ZIP, ARG. Архивы, защищенные паролем, в ФПД предоставлять запрещено/не принимаются. 
Данные в ФПД могут передаваться как по сети, так и на съёмных носителях.
В Приложении REF _Ref112082645 \n \h \* MERGEFORMAT Приложение Д приведена более подробная информация по организации ФПД и схеме информационного взаимодействия зон ЗК и ОК ЦОД ПК.
Сегментация сети в Облаке ЦОД ПК и размещение модулей ИС ФОИВ
Сеть Облака ЦОД ПК разделяется на сетевые сегменты, имеющие отдельные VLAN и IP-подсеть. Взаимодействие между сетевыми сегментами осуществляется через МСЭ.
Модули/серверы ИС ФОИВ располагаются в разных сетевых сегментах в соответствии со следующими правилами:
в Зоне разработки и тестирования ИС модули/серверы каждой ИС располагаются в ОК в отдельном сегменте;
в Подготовительной, Предпродуктивной и Продуктивной зонах ИС:
для ИС, которые не подлежат аттестации:
модули/серверы каждой ИС, недоступные в сети «Интернет» располагаются в ЗК в отдельном сегменте;
модули/серверы каждой ИС, доступные в сети «Интернет», располагаются в ОК в одном общем сегменте Продуктивной зоны;
модули/серверы СУБД каждой ИС располагаются в ЗК в отдельном сегменте (в сегменте СУБД);
модули/серверы хранения файлов каждой ИС располагаются в ЗК в отдельном сегменте;
модули/серверы, отвечающие за загрузку/выгрузку файлов, могут располагаться как в ОК, так и в ЗК в отдельных сегментах. Не допускается создание для ОК и ЗК одного сервера (одной группы серверов), используемых для процедур файлового обмена между модулями/серверами ОК и ЗК. Допустимый формат обмена данными между модулем/сервером ОК, отвечающим за загрузку/выгрузку файлов, и модулем/сервером ЗК, отвечающим за хранение файлов, для разных контуров как сегмента одной ИС, так и сегментов разных ИС – XML/JSON. Запрещено взаимодействие между такими модулями/серверами по FTP, SMB, SSH, NFS и другими протоколам, обеспечивающим файловый и блочный доступ для разных контуров как сегмента одной ИС, так и сегментов разных ИС;
модули/серверы каждой ИС, отвечающие за загрузку/выгрузку/обработку файлов, должны блокировать загрузку исполняемых файлов, бинарных файлов и архивов с установленными паролями;
для ИС, которые являются ГИС, ИСПДн или КИИ (подлежат аттестации): 
модули/серверы каждой ИС, доступные из сети «Интернет», располагаются в ОК в отдельном сегменте;
модули/серверы каждой ИС, которые взаимодействуют с внешними организациями и внешними ИС, расположенными в сети «Интернет» или в ОК ЦОД ПК или ОК Башни ПК, располагаются в ОК в отдельном сегменте (в сегменте взаимодействия с внешними организациями);
модули/серверы СУБД каждой ИС располагаются в ЗК в отдельном сегменте (в сегменте СУБД);
модули/серверы приложений каждой ИС располагаются в ЗК в отдельном сегменте (в сегменте приложений);
модули/серверы резервного копирования (далее – СРК) каждой ИС располагаются в ОК и ЗК в отдельных сегментах (в сегменте Baсkup). Резервные копии для хранения передаются по протоколу SFTP. Серверы ИС, размещенные в ОК, могут хранить резервные копии только на серверах СРК, размещенных в ОК сегмента сети данной ИС. Серверы ИС, размещенные в ЗК, могут хранить резервные копии только на серверах СРК, размещенных в ЗК сегмента сети данной ИС. Запрещено копировать/переносить/хранить резервные копии с серверов ИС, размещенных в ОК, на серверах СРК, размещенных в ЗК как сегмента данной ИС, так и сегментов других ИС и наоборот;
модули/серверы, предназначенные для тестирования процедур восстановления из подготовленных ранее резервных копий, размещаются только в отдельных сегментах ОК и ЗК Предпродуктивной зоны. Доступ к сегментам, предназначенным для тестирования восстановительных процедур, из сети Интернет не предоставляется;
инфраструктурные модули/серверы ИС размещаются в ЗК в отдельном общем сегменте для всех ИС ФОИВ;
модули/серверы хранения файлов каждой ИС располагаются в ЗК в отдельном сегменте;
модули/серверы, отвечающие за загрузку/выгрузку файлов, могут располагаться, как в ОК, так и в ЗК в отдельных сегментах. Не допускается создание для ОК и ЗК одного сервера (одной группы серверов), используемого(-мых) для процедур файлового обмена между модулями/серверами ОК и ЗК. Допустимый формат обмена данными между модулем/сервером ОК, отвечающим за загрузку/выгрузку файлов, и модулем/сервером ЗК, отвечающим за хранение файлов, для разных контуров как сегмента одной ИС, так и сегментов разных ИС – XML/JSON. Запрещено взаимодействие между такими модулями/серверами по FTP, SMB, SSH, NFS и другими протоколам, обеспечивающим файловый и блочный доступ, для разных контуров как сегмента одной ИС, так и сегментов разных ИС;
модули/серверы хранения файлов каждой ИС располагаются в ЗК в отдельном сегменте. Модули/серверы, отвечающие за загрузку/выгрузку/обработку файлов, могут так же располагаться на этом же сервере в ЗК, при выполнении следующих условий:
ИС не доступна из сети «Интернет»;
пользователи ИС имеют доступ к ИС только с аттестованных АРМ, размещенных в ЗК ИТ-инфраструктуры ПК;
модули/серверы каждой ИС, отвечающие за загрузку/выгрузку/обработку файлов, должны блокировать загрузку исполняемых файлов, бинарных файлов и архивов с установленными паролями. 
В Приложении REF _Ref112103573 \n \h \* MERGEFORMAT Приложение К приведены правила и пример размещения модулей/подсистем/серверов ИС по сегментам сети Облака, в зависимости от их функционального назначения.
Размещение оборудования в сегменте «Colocation»
Предоставляемые ресурсы и услуги в сегменте «Colocation» ЦОД ПК
Исполнитель, в соответствии с требованиями настоящего документа, обеспечивает, в случае заказа, следующие ресурсы и услуги в сегменте «Colocation» ЦОД ПК, при выполнении данных технических условий:
предоставление телекоммуникационной стойки с совокупным энергопотреблением оборудования, размещенного в ней, до 5 кВт (с возможностью увеличения до 7.5 кВт при наличии технических условий);
предоставление сетевого оборудования для телекоммуникационной стойки;
предоставление СКС ЦОД ПК для телекоммуникационной стойки;
администрирование инфраструктуры ЦОД ПК для телекоммуникационной стойки;
сервисное сопровождение серверной инфраструктуры ФОИВ в сегменте «Colocation»:
конфигурирование оборудования и системного ПО, за исключением ИС ФОИВ;
устранение неисправностей в работе оборудования и системного ПО, за исключением ИС ФОИВ, и восстановление его работоспособности в случае внезапного отказа,
замена неисправного оборудования, удовлетворяющего требованиям настоящего документа;
межсетевое экранирование информационного обмена, в составе:
между сегментом «Colocation» и сетью «Интернет»;
между сегментом «Colocation» и ресурсами сети ПК;
анализ трафика и обнаружение вторжений;
защита от атак типа «отказ в обслуживании» (Anti-DDoS);
обеспечение антивирусной защиты на серверах в сегменте «Colocation», в составе:
предоставление лицензии на АВПО производства компании «Лаборатория Касперского»;»;
мониторинг вирусной активности на серверах в сегменте «Colocation»;
информирование Функционального Заказчика о вирусных инцидентах в инфраструктуре, размещенной в сегменте «Colocation»;
контроль и анализ защищенности (включая инструментальное сканирование) для компонентов ИС, подлежащих миграции. 
Описание процедуры по размещению оборудования Функционального Заказчика в сегменте «Colocation»
Функциональный заказчик по результатам проверки соответствия оборудования требованиям настоящего документа и рекомендациям Исполнителя принимает решение о составе оборудования, которое подлежит переносу в сегмент «Colocation» в ЦОД Исполнителя.
Функциональный заказчик разрабатывает и передает Исполнителю матрицы доступа пользователей к ИС сегмента «Colocation» и ИС сегмента «Colocation» в сеть «Интернет».
В случае необходимости взаимодействия ИС Функционального Заказчика с технологическими системами ПК (серверы контроллеров домена, почтовые серверы и т.д.), Функциональный заказчик предоставляет Исполнителю список необходимых взаимодействий, включая IP-адреса конкретных серверов ИС Заказчика, протоколы и порты взаимодействия. Взаимодействия вида «сеть-сеть» и «любой адрес-сеть» не допускаются.
Исполнитель готовит техно-рабочий проект (далее – ТРП) на миграцию оборудования Функционального заказчика в сегмент «Colocation» ЦОД Исполнителя. Функциональный Заказчик и Исполнитель согласовывают ТРП.
При необходимости приведения оборудования в соответствие с требованиями настоящего документа Функциональный заказчик проводит требуемые подготовительные работы с оборудованием, подлежащим перемещению в сегмент «Colocation» ЦОД Исполнителя. Исполнитель проводит подготовительные работы в ЦОД ПК в соответствии с задачами и требованиями, определенными в настоящем документе и ТРП.
Совместная комиссия, в которую входят представители Функционального Заказчика и Исполнителя, осуществляет тестирование работоспособности планируемого к перемещению и подключенного к сети электропитания оборудования и ИС, размещённых на них, в соответствии с регламентами производителя.
Исполнитель производит физическое перемещение оборудования Функционального Заказчика в телекоммуникационные стойки, предоставленные Исполнителем. 
Оборудование принимается Исполнителем на основании Акта приёма-передачи и ставится на учет в соответствии с серийными номерами оборудования.
Исполнитель монтирует оборудование, переданное Функциональным Заказчиком, коммутирует его, подключает к электропитанию, к ЛВС ЦОД ПК и к ЛВС администрирования инфраструктуры ЦОД ПК, а также включает оборудование в сегменте «Colocation» ЦОД Исполнителя в соответствии с инструкцией включения оборудования. Функциональный Заказчик вводит в эксплуатацию ИС и проверяет их работоспособность.
Совместная комиссия, в которую входят представители Функционального заказчика и Исполнителя, осуществляет тестирование работоспособности смонтированного и подключенного к сети электропитания оборудования в соответствии с регламентами производителя.
По завершению вышеуказанных работ оборудование Функционального заказчика, в случае выполнения условий настоящего документа, передается Исполнителю на сервисное обслуживание в соответствии с требованиями настоящего документа. 
Каналы сегмента «Colocation», за исключением сети «Интернет», с внешними ЦОД и иными внешними системами терминируются на оборудовании МСЭ/VPN-box Функционального Заказчика сегмента «Colocation». Канал сети «Интернет» терминируется на МСЭ Исполнителя.
При подключении к инфраструктуре ПК требуется обеспечить настройки политик аудита на ОС и СУБД ИС в соответствии с инструкциями Исполнителя, для обеспечения возможности расследования инцидентов ИБ.
После переезда в сегмент «Colocation» ЦОД ПК Функциональный заказчик на контроллере домена (AD), находящемся на обслуживании у Функционального заказчика, применяет, в случае его отсутствия, групповую политику (GPO), обеспечивающую установку агента управления на все АРМ и серверы ИС Функционального заказчика. 
Условия оказания услуги «Предоставление телекоммуникационной стойки»
В рамках услуги «Предоставление телекоммуникационной стойки» Исполнителем организуется предоставление телекоммуникационных стоек размером 600х1000 и 800х1000 (по отдельному письменному запросу) с обеспечением постоянных условий эксплуатации в части бесперебойного гарантированного электропитания оборудования, необходимых параметров окружающей среды (температура, влажность), пожарной и физической безопасности.
Оборудование Функционального заказчика должно соответствовать требованиям к эксплуатационно-техническому состоянию оборудования, указанным в настоящем документе, для возможности размещения его в сегменте «Colocation» ЦОД ПК. 
Передача оборудования Функционального Заказчика после проверки его эксплуатационно-технического состояния Исполнителю должна быть документально оформлена. Для этого Функциональный заказчик должен предоставить документы на оборудование в соответствии с требованиями настоящего документа. Оборудование принимается Исполнителем и ставится на учет в соответствии с серийными номерами оборудования и без его агрегирования в программно-аппаратные комплексы.
Ввод стойки в эксплуатацию (подключение стойки и установленного в ней оборудования Функционального заказчика к электропитанию) Исполнитель осуществляет в соответствии с указанными ниже техническими условиями.
Требования к эксплуатационно-техническому состоянию оборудования Функционального Заказчика для размещения в сегменте «Colocation»
Оборудование должно передаваться Исполнителю в комплектном, технически исправном состоянии, без предупреждающих (желтых/оранжевых) и аварийных (красных) индикаций и без ошибок в интерфейсе управления оборудования.
Эксплуатационные характеристики оборудования должны соответствовать требованиям по размещению и монтажу оборудования в стойках. 
Корпус оборудования не должен иметь механических повреждений, препятствующих его надлежащей эксплуатации; используемые кабели электропитания должны быть без дефектов. 
В корпусе оборудования не должно быть не закрепленных деталей.
Оборудование должно передаваться Исполнителю в очищенном от пыли виде.
Гипервизоры и ОС, установленные на оборудовании, должны иметь действующие лицензии правообладателя на момент передачи оборудования Исполнителю.
Целостность наклеек и (или) защитных пломб, подтверждающих соблюдение гарантийных обязательств, а также места их расположения, предусмотренные изготовителем оборудования, не должны быть нарушены. 
В случае невыполнения требований данного пункта ответственность за обслуживание оборудования, размещённых на нем ИС ФОИВ и обеспечение ИБ возлагается на ФОИВ.
Требования к документированию для размещения оборудования Функционального Заказчика в сегменте «Colocation»
Для документального оформления размещения оборудования в ЦОД Исполнителя Функциональный заказчик должен предоставить следующие данные о пассивном и активном оборудовании, обладающем серийным номером, без его агрегирования в программно-аппаратные комплексы: 
тип;
наименование; 
производитель;
серийный номер;
стоимость каждой позиции оборудования (которая обладает серийным номером).
Дополнительно к вышеуказанным документам Функциональному заказчику рекомендуется предоставить следующие данные о пассивном и активном оборудовании, обладающем серийным номером, без его агрегирования в программно-аппаратные комплексы: 
регистрационные реквизиты контракта на поддержку оборудования (при его наличии);
наличие действующих сертификатов на оборудование: сертификат соответствия средств связи, Ростест, электромагнитной безопасности.
Функциональный заказчик также должен предоставить инструкцию с указанием порядка/последовательности включения оборудования Функционального заказчика, обеспечивающую правильный ввод в эксплуатацию ИС, размещенных на оборудовании.
Окончательная приемка смонтированного в сегменте «Colocation» ЦОД Исполнителя оборудования Функционального заказчика производится по окончанию работ по монтажу и тестированию такого оборудования в соответствии с регламентами производителя оборудования. 
Требования по размещению и монтажу оборудования в стойках
Размещаемое оборудование в стойке подключается к сети 220–230 В переменного тока, частотой 50 Гц.
Совокупное энергопотребление размещаемого оборудования, размещенного в одной стойке, составляет 5 кВт, с возможностью увеличения до 7.5 кВт при наличии технических условий.
Максимальная подведённая мощность к стойке составляет не более 7,5кВт. Электрическая нагрузка на стойку рассчитывается, как алгебраическая сумма максимальной мощности устанавливаемого оборудования согласно паспорту производителя, с учетом количества всех установленных подключённых основных и резервных блоков питания. Стойки в ЦОД размещаются рядами – до 26 стоек в ряду. Общая подведенная мощность к ряду стоек составляет не более 130кВт.
Размещаемое в стойке оборудование должно по весовым характеристикам соответствовать ограничениям по нагрузочной способности фальшпола.
Размещение оборудования в телекоммуникационных стойках должно быть организовано так, чтобы «холодный» воздух поступал с передней стороны телекоммуникационной стойки (из холодного коридора), а «горячий» воздух выдувался с задней стороны телекоммуникационной стойки (в горячий коридор).
Оборудование принимается в стоечном исполнении.
Требуется наличие салазок (рельс) для серверов и кронштейнов для телекоммуникационного оборудования. 
В стойки требуется устанавливать оборудование, имеющее специализированные крепежи для размещения в стойках.
Допускается размещение оборудования на полках в стойках (эти решения должны быть отражены в ТРП и согласованы с Исполнителем).
Допускается размещение оборудования с альтернативными схемами охлаждения. При этом такое оборудование должно быть при размещении сгруппировано по стойкам (эти решения должны быть отражены в ТРП и согласованы с Исполнителем).
Стандартный тип подключения размещаемого оборудования в стойке имеет два независимых электрических ввода с номинальным выходным напряжением 220-230 В.
Размещаемое в стойке оборудование должно иметь два блока питания в режиме active-active в целях организации питания от двух независимых источников питания. В случае отсутствия в конструктиве оборудования двух и более блоков питания требуется установка устройства АВР (автомат включения резерва) силами и средствами Функционального заказчика.
Условия оказания услуги «Предоставление сетевого оборудования для телекоммуникационной стойки»
Исполнитель обеспечивает подключение оборудования Функционального заказчика к ЛВС ЦОД со скоростью 1Гб/с и 10Гб/с по медным и оптическим интерфейсам.
Предоставление сетевого оборудования возможно по двум схемам:
предоставление сетевого оборудования для подключения перемещаемого в сегмент «Colocation» ЦОД ПК сетевого оборудования ФОИВ;
предоставление сетевого оборудования для подключения перемещаемого в сегмент «Colocation» ЦОД ПК серверного оборудования ФОИВ.
В связи с тем, что ЛВС ЦОД ПК входит состав ИТ-инфраструктуры ПК, Функциональный заказчик должен обеспечить выполнение требований ИБ на перемещаемом в сегмент «Colocation» ЦОД ПК оборудовании и ИС. 
Условия оказания услуги «Администрирование инфраструктуры ЦОД ПК для телекоммуникационной стойки»
В рамках оказания услуги «Администрирование инфраструктуры ЦОД ПК для телекоммуникационной стойки» Исполнитель осуществляет по заявке Заказчика или Функционального заказчика следующие операции:
смена/переустановка жёстких дисков (только поддерживающих возможность горячей замены и при наличии четких письменных инструкций) в рамках регламента взаимодействия основной услуги размещения;
подключение KVM-консолей (при наличии четких письменных инструкций) в рамках регламента взаимодействия основной услуги размещения;
перекоммутация промаркированных патч-кордов (при наличии четких письменных инструкций) в рамках регламента взаимодействия основной услуги размещения;
организация сетевых соединительных линий от помещений кроссовой до уровня стойки ЦОД ПК;
предоставление информации в рамках регламента взаимодействия основной услуги размещения; предоставление Заказчику или Функциональному заказчику записи с камер видеонаблюдения, логов СКУД.
Условия оказания услуги «Сервисное сопровождение серверной инфраструктуры ФОИВ в сегменте «Colocation» ЦОД ПК
Для обеспечения сервисной поддержки серверного оборудования Функционального Заказчика в сегменте «Colocation» ЦОД Исполнителя организуется ЛВС мониторинга оборудования Функционального заказчика. Исполнитель обеспечивает порты Gigabit Ethernet для подключения портов управления оборудованием. Для подключения к ЛВС мониторинга оборудование Функционального заказчика должно соответствовать следующим условиям:
Наличие активированной системы удаленного управления оборудованием по IP-сети (IPMI):
система должна обладать графическим веб-интерфейсом и/или интерфейсом командной строки;
система должна отображать состояние оборудования, а также должна позволять удаленно управлять оборудованием;
система должна обеспечивать мониторинг, управление, журналирование и инвентаризацию удаленного оборудования;
в системе должен быть настроен протокол SNMP в режиме «Read Only».
Функции управления оборудованием должны быть доступны, даже если оборудование находится в выключенном состоянии.
Оборудование должно соответствовать всем требованиям к эксплуатационно-техническому состоянию для размещения в сегменте «Colocation» ЦОД Исполнителя, указанным в настоящем документе.
Должна быть предоставлена документация, указанная в настоящих требованиях.
Функциональный заказчик обеспечивает предоставление программно-административного доступа, необходимого для выполнения работ по сервисной поддержке, в частности, реквизиты доступа на управляющие интерфейсы оборудования и в BIOS.
Оборудование, передаваемое на сервисную поддержку, должно обладать действующей технической поддержкой производителя. Целостность наклеек и (или) защитных пломб, подтверждающих соблюдение гарантийных обязательств, а также места их расположения, предусмотренные изготовителем оборудования, не должны быть нарушены. В случае снятия производителем оборудования с поддержки или нарушение целостности защитных пломб (места их расположения) также снимается сервисная поддержка оборудования Исполнителем (поддержка производителем оборудования должна включать возможность получения/приобретения вышедших из строя комплектующих). 
Должна быть обеспечена возможность подключения оборудования к системе мониторинга ИТ-инфраструктуры ПК по протоколу SNMP, если на серверном оборудовании установлена ОС Windows –, то по протоколу WMI.
Условия оказания услуги «Межсетевое экранирование информационного обмена»
Услуга «Межсетевое экранирование информационного обмена» предоставляется Исполнителем на базе сертифицированных ФСТЭК России по требованиям безопасности информации МСЭ/СОВ. В рамках данной услуги межсетевое экранирование информационного обмена и анализ трафика для обнаружения вторжений обеспечивается:
между сегментом «Colocation» и сетью «Интернет»;
между сегментом «Colocation» и ресурсами сети ИТ-инфраструктуры ПК.
Политика безопасности, применяемая на МСЭ Исполнителя, разрабатывается на основании матрицы доступа, предоставленной Функциональным заказчиком, в рамках процедуры подготовки к миграции. В случае необходимости взаимодействия ИС Функционального заказчика с технологическими системами ПК (серверы контроллеров домена, почтовые серверы и другие инфраструктурные сервисы), Функциональный заказчик включает список необходимых взаимодействий в матрицу доступа, с указанием IP-адресов конкретных серверов ИС Функционального заказчика, протоколов и портов взаимодействия. Взаимодействия вида «сеть-сеть» и «любой адрес-сеть» не допускаются. Взаимодействия вида «все порты» или «все протоколы» также не допускаются.
Любые изменения политики межсетевого экранирования возможны на основании должным образом оформленной заявки. При этом, запрашиваемые изменения не должны нарушать требования регулятора по защите информации в ГИС/ИСПДн, а также не создавать рисков ИБ для ИС других ФОИВ ПК. В случае необходимости организации трансляции сетевых адресов (NAT) на МСЭ Функционального заказчика, установленный внутри периметра ЦОД Исполнителя, такая заявка может быть выполнена только с оговоркой, что ответственное лицо на стороне Функционального заказчика принимает ответственность за возможные последствия в виде инцидентов ИБ, и понимает все риски, связанные с выполнением такой заявки.
Условия оказания услуги «Защита от атак типа «отказ в обслуживании» (AntiDDoS)»
Услуга Anti-DDoS предоставляется Исполнителем для ИС Функционального Заказчика, имеющих подключение к сети «Интернет» с «белым» (публичным) IP-адресом. Услуга предназначена для выявления и предотвращения атак типа «отказ в обслуживании», путем фильтрации вредоносного трафика. При оформлении заказа на данную услугу Функциональный заказчик предоставляет ФИО и контакты ответственного работника, которому поручено оперативное взаимодействие с представителями Исполнителя. 
Условия оказания услуги «Обеспечение антивирусной защиты на серверах в сегменте «Colocation»
Услуга «Обеспечение антивирусной защиты на серверах в сегменте «Colocation» может предоставляется Исполнителем на базе сертифицированных по требованиям безопасности информации средств антивирусной защиты, в составе:
предоставление лицензии на АВПО производства компании «Лаборатория Касперского»;
мониторинг вирусной активности на серверах в сегменте «Colocation»;
информирование Функционального заказчика о вирусных инцидентах в ИТ-инфраструктуре в сегменте «Colocation». 
Предоставление услуги для серверов ИС Функционального заказчика возможно только при условии соответствия версии ОС на серверах ИС Функционального заказчика требованиям совместимости применяемого АВПО. 
Возможно применение ранее установленного АВПО Функционального заказчика (за исключением ПО производства компании «Лаборатория Касперского»).
Условия оказания услуги «Контроль и анализ защищенности для компонентов ИС, подлежащих миграции»
Услуга «Контроль и анализ защищенности для компонентов ИС, подлежащих миграции» предоставляется Исполнителем на базе сертифицированных по требованиям безопасности информации средств анализа защищенности. Услуга может быть предоставлена как в процессе подготовки ИС Функционального заказчика к миграции, так и после завершения миграции ИС Функционального заказчика в ЦОД Исполнителя. При этом, в процессе подготовки к миграции должен использоваться режим тестирования на проникновение, а в случае, если анализ защищенности производится после миграции – в режиме аудита (с использованием учетной записи, имеющей административные привилегии в целевой системе). В каждом отдельном случае, решение о формате предоставлении услуги прорабатывается отдельно в рамках подготовки проектного решения по миграции ИС Функционального заказчика.
Предоставление ресурсов в Облаке ЦОД ПК
Общие сведения о предоставлении ресурсов и сервисов
В Облаке ЦОД ПК предоставляются следующие ресурсы:
виртуальный процессор vCPU;
виртуальная оперативная память vRAM;
виртуальный жёсткий диск типа 1 vHDD тип 1 (SATA);
виртуальный жёсткий диск типа 2 vHDD тип 2 (SAS);
виртуальный жёсткий диск типа 3 vHDD тип 3 (SSD).
В Облаке ЦОД ПК оказывается сервис по резервному копированию размещенных в нем объектов.
Предоставление виртуального процессора vCPU
В Облаке ЦОД ПК предоставляются виртуальные процессоры, доступные для ВМ Заказчика.
Вычислительные мощности предоставляются на базе Intel Xeon с базовой тактовой частотой 2,4 ГГц. Переподписка CPU в Облаке ЦОД ПК возможна с коэффициентом не больше 5.
На одну ВМ может быть выделено целое число vCPU: от 1 vCPU до 40 vCPU (с учётом переподписки CPU).
В случае, если для ВМ требуется от 41 vCPU до 320 vCPU (с учётом переподписки CPU), то требуется дополнительно заказать vCPU в количестве не менее 50% от требуемых для ВМ. (Требование вызвано тем, что необходимо дополнительное резервирование ресурсов на другом физическом хосте для обеспечения беспрепятственной миграции ВМ в случае отказа физического оборудования.)
Предоставление для одной ВМ более 320 vCPU (с учётом переподписки CPU) невозможно.
Предоставление виртуальной оперативной памяти vRAM
В Облаке ЦОД ПК предоставляется виртуальная оперативная память vRAM, доступная для ВМ заказчика.
Переподписка (RAM Swapped) по оперативной памяти отсутствует.
На одну ВМ может быть выделено целое число vRAM от 1 ГБ до 128 ГБ.
В случае, если для ВМ требуется от 129 ГБ до 870 ГБ, то необходимо дополнительно заказать vRAM в объеме не менее 100% от требуемых для ВМ. (Требование вызвано тем, что необходимо дополнительное резервирование ресурсов на другом физическом хосте для обеспечения беспрепятственной миграции ВМ в случае отказа физического оборудования.) Возможно уменьшение совокупного объема дополнительно резервируемых ресурсов для двух и более ВМ, работающих в кластерном режиме и/или в случае упрощения требований по времени переноса/восстановления ВМ на другом физическом хосте.
Предоставление для одной ВМ более 870 ГБ vRAM невозможно.
Предоставление виртуального жесткого диска типа 1 vHDD SATA
В Облаке ЦОД ПК предоставляются виртуальные ресурсы хранения, доступные для ВМ заказчика.
Виртуальный жесткий диск типа 1 (SATA) рекомендован для долгосрочного хранения больших объемов данных.
Размер одного диска для ВМ должен иметь целое значение от 2 ГБ до 10000 ГБ.
Один диск для одной ВМ объемом более 10000 ГБ не может быть предоставлен. Если для ВМ требуется объем хранения более 10000 ГБ, то следует заказывать 2 и более дисков. 
Производительность диска типа 1 (SATA) составляет не более 40 IOPS на 1000 ГБ. Предоставляется максимальная суммарная дисковая производительность данных типов дисков до 400 IOPS на машину.
Предоставление виртуального жесткого диска типа 2 vHDD SAS
В Облаке ЦОД ПК предоставляются виртуальные ресурсы хранения, доступные для ВМ Заказчика.
Виртуальный жесткий диск типа 2 (SAS) рекомендован как для хранения данных, так и для ВМ со средней интенсивностью операций ввода-вывода.
Размер одного диска для ВМ должен иметь целое значение от 2 ГБ до 10000 ГБ.
Один диск для одной ВМ объемом более 10000 ГБ не может быть предоставлен. Если для ВМ требуется объем хранения более 10000 ГБ, то следует заказывать 2 и более дисков.
Производительность диска тип 2 (SAS) составляет не более 100 IOPS на ВМ на 1000 ГБ. Предоставляется максимальная суммарная дисковая производительность данных типов дисков до 1000 IOPS на ВМ.
Предоставление виртуального жесткого диска типа 3 vHDD SSD
В Облаке ЦОД ПК предоставляются виртуальные ресурсы хранения, доступные для ВМ Заказчика.
Виртуальный жесткий диск типа 3 (SSD) рекомендован для ВМ с высокими требованиями по скорости доступа к дискам и интенсивности операций ввода-вывода.
Размер одного диска для ВМ должен иметь целое значение от 2 ГБ до 10000 ГБ.
Один диск для одной ВМ объемом более 10000 ГБ не может быть предоставлен. Если для ВМ требуется объем хранения более 10000 ГБ, то следует заказывать 2 и более дисков.
Производительность диска тип 3 (SSD) не менее 400 IOPS на 1000 ГБ. 
Предоставляется максимальная суммарная дисковая производительность данных типов дисков до 10000 IOPS на ВМ.
Предоставление сервиса по резервному копированию объектов, размещенных в Облаке ЦОД
В Облаке ЦОД есть две СРК:
система технологического резервного копирования (далее – СТРК); 
СРК пользовательских информационных объектов.
Описание СТРК
Система технологического резервного копирования (СТРК) предназначена для обеспечения возможности восстановления работоспособности ВМ в случае выхода из строя систем хранения данных. СТРК не предназначена для замены стандартных процедур обеспечения консистентности данных при резервном копировании (Application Consistent Backup).
Не допускается включение СТРК в план резервного копирования и восстановления ИС.
В СТРК используется схема GFS (Grand-Father-Son) и в общем случае расписание резервного копирования выглядит следующим образом:
полное резервное копирование (Full backup) делается каждые 6 месяцев;
каждую неделю делается синтетическое резервное копирование – хранится только 1 полная копия для каждой ВМ;
один раз в день осуществляется инкрементальное резервное копирование (Incremental backup) – хранится 6 инкрементальных копий, позволяющих выполнить создание синтетической полной копии.
СТРК проводит резервное копирование данных без какого-либо влияния на функционирование ВМ. Ограничение составляют ВМ с большими объемами данных. Максимальный объем ВМ, для которой производится СТРК составляет 2,5 ТБ.
Технологическое резервное копирование не производится ввиду невозможности или нецелесообразности для следующих ВМ: 
ВМ содержит БД или приложения с БД (например, MS SQL, MS Exchange, MS SharePoint и другие);
ВМ, данные которых расположены на независимых (independent) дисках;
ВМ, данные которых расположены на RDM (raw device mapping) дисках.
Описание СРК пользовательских информационных объектов 
В Облаке ЦОД ПК обеспечивается резервное копирование и восстановление объектов резервного копирования, размещаемых на ресурсах Облака. Объектами резервного копирования являются разделы файловых систем (диски, папки, отдельные файлы) и ВМ. 
При резервном копировании разделов файловых систем обеспечивается создание, хранение резервных копий и консистентность данных объектов резервного копирования, а также восстановление, включая:
установку агентов СРК на запрашиваемые ФОИВ ВМ;
установку обновлений агентов СРК;
управление расписанием резервного копирования;
восстановление объектов резервного копирования по запросу ФОИВ.
Определение состава и консистентность данных ИС находятся в зоне ответственности ФОИВ. В зоне ответственности ФОИВ также находится определение длительности хранения резервной копии (по точкам или по времени) и периодичность или последовательность выполнения резервного копирования.
При резервном копировании ВМ не гарантируется консистентность данных ИС, функционирующих на данной ВМ. Максимальный объем ВМ, для которой производится резервное копирование, составляет 2,5 ТБ.
Для обеспечения резервного копирования пользовательских информационных объектов требуется заказать следующие услуги:
услуга управления резервным копированием;
услуга предоставления виртуального жесткого диска типа 1.
Особенности и ограничения при восстановлении пользовательских информационных объектов в рамках оказания услуги «Услуга управления резервным копированием в Облаке ЦОД ПК»
По запросу ФОИВ, при использовании услуги «Услуга управления резервным копированием в Облаке ЦОД ПК», осуществляется восстановление объектов резервного копирования данных из резервных копий. Типовые сценарии восстановления: 
восстановление ВМ ИС вместо/поверх существующих ВМ;
восстановление разделов файловых систем (диски, папки, отдельные файлы) на существующие ВМ;
восстановление ВМ ИС, как копии существующих ВМ ИС
При восстановлении ВМ ИС вместо/поверх существующих ВМ существуют следующие особенности и ограничения:
имя ВМ не изменяется;
IP-адрес ВМ изменяется;
VLAN восстановленной ВМ не изменяется;
контур безопасности не изменяется;
зона размещения не изменяется;
организация информационного взаимодействия между ВМ и доступ к ВМ не изменяются;
существующая ВМ, вместо/поверх которой восстанавливается ВМ, удаляется.
При восстановлении разделов файловых систем (диски, папки, отдельные файлы) на существующие ВМ существуют следующие особенности и ограничения:
разделы файловых систем (диски, папки, отдельные файлы) могут восстанавливаться вместо/поверх существующих на исходной ВМ;
разделы файловых систем (диски, папки, отдельные файлы) могут восстанавливаться на любой другой указанный в заявке диск или папку, но в рамках исходной ВМ;
при восстановлении разделов файловых систем (диски, папки, отдельные файлы) на существующие ВМ, оценка требуемого объема виртуального жесткого диска на ВМ инициируется и производится силами и средствами ФОИВ
при необходимости/недостаточности вычислительных ресурсов на существующих ВМ, ФОИВ необходимо заполнить заявку на изменение характеристик существующих ВМ.
При восстановлении копии ВМ существуют следующие особенности и ограничения:
все копии ВМ восстанавливаются только в Предпродуктивную зону;
имя копии ВМ не изменяется;
изменяется IP адрес копии ВМ;
контур безопасности не изменяется;
изменяется VLAN копии ВМ:
все копии ВМ ИС/ГИС в ОК восстанавливаются в один VLAN (отдельный сегмент для данной ИС/ГИС) ОК Предпродуктивной зоны,
все копии ВМ ИС/ГИС в ЗК восстанавливаются в один VLAN (отдельный сегмент для данной ИС/ГИС) ЗК Предпродуктивной зоны;
сетевые взаимодействия возможны только между VLAN (отдельный сегмент для данной ИС/ГИС) ОК Предпродуктивной зоны и VLAN (отдельный сегмент для данной ИС/ГИС) ЗК Предпродуктивной зоны в соответствии с поданной матрицей взаимодействия
сетевые доступы организуются только между копиями ВМ, 
отсутствует возможность организации сетевых доступов от копии ВМ к другим ВМ в других VLAN, IP-сетях;
ресурсы для копии ВМ предоставляются на 3 дня, не чаще раза в 14 календарных дней. При необходимости работы восстановленных ВМ более продолжительное время, ФОИВ должен сформировать и направить заявку «Заявка на вычислительные ресурсы и ОС»;
тип диска для копии ВМ – в соответствии с услугой предоставления виртуального жесткого диска типа 1 («медленный диск»), другие типы жесткого диска в рамках оказания услуги не предоставляются;
при этом в рамках предоставления услуги может быть выделен следующий объем ресурсов в каждом из контуров не более: 64 vCPU, 128 ГБ RAM, 2 ТБ HDD тип 1 на все ИС/ГИС всех ФОИВ. При необходимости большего количества ресурсов, ФОИВ должен сформировать и направить заявку «Заявка на вычислительные ресурсы и ОС»;
доступ к копии ВМ осуществляется только с терминального сервера администраторов по 22 порту для ВМ с ОС Linux и по порту 3389 для ВМ с ОС Windows.
В Приложение М приведен рекомендуемый порядок восстановления при проверке целостности объектов резервного копирования информационных систем ФОИВ в Облаке ЦОД ПК.
Размещение ИС ФОИВ в Облаке
Общие требования к ИС, размещаемым в Облаке
ИС, перемещаемые в ЦОД ПК, должны быть построены на основе трехзвенной архитектуры (согласно приложению К), которая в терминах клиент-серверной модели: представляется следующим образом: 
сервер приложений (уровень прикладной логики); 
сервер СУБД (уровень доступа к ресурсам); 
клиент/тонкий клиент, (уровень представления данных) на АРМ. 
Все вычисления (бизнес-логика) должны быть реализованы на сервере приложения и/или СУБД.
Резервное копирование информации в ИС может быть реализовано на базе услуги СРК, описанной в п.4.7.2 настоящего документа, в противном случае в составе ИС выделяется отдельная ВМ, для хранения резервных копий данных ИС, имеющая соответствующий размер дискового пространства для хранения. При этом функции резервирования компонент ИС должны быть реализованы внутренними (встроенными) средствами ИС. 
Для организации резервного копирования и восстановления данных ИС должен быть разработан документ («Порядок резервного копирования и восстановления данных» сокращенно «Порядок РК и ВД»), предусматривающий порядок создания, проверки целостности и возможности восстановления данных, порядок восстановления данных ИС. Порядок РК и ВД должен учитывать требования, указанные в п.п.4.7.2 и в приложении М. 
ВМ, на которых размещаются модули ИС, должны быть названы с учетом требований к наименованию серверов. В Приложении REF _Ref112103606 \n \h \* MERGEFORMAT Приложение И приведены правила наименования серверов/оборудования при размещении ИС в ПК.ЦОД ПК.
Модули ИС должны иметь возможность быть установленными в виртуальной среде под управлением гипервизора VMWare версии не ниже 7.0.3. Модули ИС, размещаемые в Облаке, должны иметь поддержку стандартной архитектуры x86. 
Каждый модуль ИС должен иметь определенные IP-адреса в соответствии с IP-адресацией, определенной в Облаке. В Приложении REF _Ref112103679 \n \h \* MERGEFORMAT Приложение К приведены правила и пример размещения модулей/подсистем/серверов ИС по сегментам сети Облака, в зависимости от их функционального назначения Модули ИС ОК, модули ИС ЗК и пользователи ИС должны находиться в разных IP-сетях, т.е. взаимодействие модулей ИС из разных контуров и пользователей ИС на уровне L2 не допустимо.
При организации взаимодействия между модулями ИС передача информации должна осуществляться непосредственно между этими модулями ИС. Обмен информацией между модулями ИС через АРМ пользователя должен быть исключен.
В случае, если ИС имеет выход в сеть «Интернет» и, при этом, предназначена для работы пользователей с аттестованных АРМ, в обязательном порядке должны соблюдаться следующие требования:
ИС должна быть архитектурно разделена на модули/сервисы: часть модулей будет располагаться в ОК, другая часть в ЗК;
данные, с которыми работают модули ОК, должны быть отделены от данных, с которыми работают модули ЗК, т.е. храниться соответственно в системе хранения данных (далее – СХД) ОК и СХД ЗК. Для Сервера приложений, размещенного в ОК, должен использовать выделенный сервер СУБД или выделенные модуль хранения файлов в ЗК;
должна быть обеспечена возможность определения авторства каждой операции в ИС за счет использования уникальных персонифицированных идентификаторов каждого пользователя, процедуры аутентификации и протоколирования действий пользователей. Проведение неавторизованных операций должно быть запрещено.
При установке программных модулей ИС на платформе ОС Windows в определенные каталоги файловой системы следует соблюдать следующие ограничения:
запрещено осуществлять запись в системные разделы реестра; приложения должны при необходимости создавать собственные разделы реестра вне системных разделов;
запрещено осуществлять запись в системные директории (%windir%, %windir%/REPAIR, %windir%/SYSTEM, %windir%/SYSTEM32).
При установке программных модулей ИС на платформе с ОС семейства *NIX запрещено осуществлять запись в системные директории (\bin, \sbin).
При настойках ОС семейства Linux, имеющих сертификат соответствия ФСТЭК России по заданному уровню безопасности, необходимо руководствоваться требованиями, изложенными в Linux Red Books (документации) на данную ОС. 
В ИС использование внешних программных средств допускается только в том случае, если их вызов не создает предпосылок к нарушению функциональной замкнутости среды, нарушению требований сертификата ФСБ России и ФСТЭК России, таких как: расширение возможностей по работе с файловой системой, возможность создания исполняемого программного кода, возможность запуска из используемых внешних программных средств программ, не предназначенных для нормального функционирования ИС и т.д.
В случае использования аппаратных средств (токенов) для аутентификации пользователей и администраторов в ПО ИС или лицензирования ПО, электронный ключ (токен) должен быть с интерфейсом USB (HASP или USB-flash).
Запрещается использовать r-протоколы (RSH, Rlogin, Rexec, Rsync и пр.) при организации взаимодействия между модулями одной ИС или же различными ИС.
В целях обеспечения требований и рекомендаций регуляторов (ФСБ России и ФСТЭК России) при проектировании и развертывании ГИС/ИС должны выполняться требования ИБ, приведенные в приложениях к настоящему документу, имеющих статус «обязательное».
Матрица и управление правами доступа обслуживающего персонала ИС 
В целях соблюдения требований ИБ в части разделения доступа обслуживающего персонала в Облаке ЦОД ПК определены роли и разрешения доступа к различным зонам ИС, приведенные в таблице 1.
1 –Таблица 1Матрица доступа обслуживающего персонала ИС
Роль
TST
PPD
PRD
PREP
Пользователь
-
-
x
х
Администратор
x
x*
x*
x*
Тест-инженер
x
-
-
x*
Разработчик
x
x*
-
x*
* при условии использования ГОСТ VPN для удаленного доступа и Сервиса контроля действий привилегированных пользователей (Privileged Access Management - PAM)
Помимо этого, в Облаке ЦОД ПК действуют следующие условия аутентификации и управления правами доступа:
ИС должна требовать от пользователя ввода аутентификационной информации (имя и пароль пользователя) при каждом запуске клиентского приложения т.е. доступ к информации и функциям ИС должен предоставляться пользователю только после предъявления уникального персонифицированного идентификатора (имени) пользователя и проведения процедуры аутентификации на основе некоторой, представленной пользователем информации (пароль, ключи).
Аутентификация пользователя не должна требовать создания учетной записи пользователя в ОС модуля ИС и в СУБД.
После успешной аутентификации в системе и открытия сеанса работы пользователю должна предоставляться информация о предыдущем успешном входе в систему (как минимум, дата и время).
При взаимодействии модулей ИС, реализованных на разных хостах (или ВМ), необходимо реализовывать двухстороннюю межмодульную аутентификацию. 
При взаимодействии модулей ИС, размещенных на одном хосте (или ВМ), аутентификация инициатора взаимодействия является обязательной.
В алгоритмах аутентификации не должны использоваться сужающие преобразования аутентификационных данных (например, приведение букв идентификатора пользователя и/или пароля к одному регистру, ограничение количества значащих символов пароля).
Должно быть исключено наличие аутентификационных данных, необходимых для доступа компонентов ИС к другим ИС, в программном коде компонентов ИС и (или) в доступных пользователям конфигурационных файлах.
По окончании определенного периода неактивности пользователя система должна принудительно завершать сеанс работы пользователя и освобождать затребованные пользователем ресурсы. Наличие запущенного пользователем длительного процесса обработки (например, формирование сложного объемного отчета) должно рассматриваться как признак активности. Принудительное завершение сеанса работы до завершения данного процесса осуществляться не должно. Значение периода неактивности пользователя должно задаваться в параметрах системы администратором и быть одинаковым для всех групп пользователей.
Должно ограничиваться количество одновременно открытых сеансов от имени одного пользователя в ИС. Максимальное значение должно задаваться в параметрах системы администратором отдельно для каждого пользователя (по умолчанию – один сеанс).
Основным механизмом управления доступом и предоставления полномочий пользователям ИС должен быть ролевой механизм (механизм ролевого разграничения доступа). Доступ к объектам системы должен в явном виде разрешаться или запрещаться на основе атрибутов безопасности пользователя.
При первичном заведении в системе пользователю должен быть предоставлен минимальный набор прав доступа к объектам данной системы.
Пользовательские права (определяющие группы, к которым пользователь принадлежит, назначенные ему роли и доступные ему объекты) должны предоставляться из единого дерева прав по единым непротиворечивым правилам.
Механизм распределения прав доступа к ресурсам и функциям системы должен обеспечивать предоставление пользователям прав, минимально необходимых для выполнения их функциональных обязанностей. 
Приложения не должны требовать наличия у пользователей ИС (включая администратора ИС) административных полномочий в ОС персонального компьютера пользователя.
Модулю ИС при функционировании и подключении к СУБД не должно требоваться прав администратора ОС, администратора СУБД.
Модуль ИС необходимо ограничить правами выделенной технологической учетной записи, не имеющей прав локального входа в ОС или сервера СУБД. При этом в случае необходимости более высокие привилегии могут быть использованы, но после выполнения требуемых операций их необходимо освобождать.
Выполнение административных задач в рамках ИС не должно требовать предоставления администратору ИС расширенных прав, равнозначных правам администраторов системного слоя: администратор СУБД (DBA, semi DBA), владельца (DBO) базы данных, администратор сервера приложений, администратор LDAP-каталога и т.п.
Запрещается назначать группе пользователей базы данных PUBLIC какие-либо права по доступу к таблицам и хранимым процедурам (пакетам) в ИС. Для распределения прав пользователей на уровне СУБД должны использоваться специализированные группы, созданные для пользователей ИС. Использование штатных групп СУБД для распределения прав доступа запрещено.
Должны быть реализованы встроенные возможности контроля и мониторинга с целью проведения аудита неактивных учетных записей пользователей, например, с помощью периодического запуска отчета по пользователям, которые не осуществляли вход в систему в течение установленного периода времени. По окончании данного периода, который должен задаваться администратором в настройках ИС (значение по умолчанию – 60 дней), учетная запись такого пользователя должна блокироваться до разблокировки администратором.
Условия администрирования и управления учетными записями
Выполнение административных функций ИС должно быть вынесено на прикладной уровень в виде отдельной ВМ в составе ИС, размещенной в Облаке с установленными средствами администрирования ИС (АРМ управления ИС) или модуля «Администрирование», чья функциональность должна позволять осуществлять все необходимые при эксплуатации ИС административные операции. Выполнение администратором ИС своих функций не должно требовать привилегированного доступа в СУБД и ОС.
Реализация механизма администрирования должна исключать возможность прямого соединения администратора с БД системы в обход прикладного ПО, «АРМ Управления ИС» или модуля «Администрирование». 
Возможность осуществления административных функций пользователями, не являющимися администраторами ИС, должна быть исключена. Допускается назначение пользователю определенного набора административных прав в рамках специализированной роли «Администратор предметной области».
Должна быть исключена возможность доступа к личным паролям пользователей.
ИС должна обладать минимальными полномочиями в выполняемой среде:
клиентская часть ИС (АРМ пользователя) должна выполняться с правами, соответствующими правам непривилегированного пользователя в ОС (например, группа «Пользователи/Users», и не требовать предоставления пользователю дополнительных прав в рамках ОС;
серверную часть ИС рекомендуется максимально изолировать от внешнего окружения (должны быть установлены разрешения на файловую систему, ветки реестра, доступ к сети, а также на использование политики доступа для Java или .NET приложений, или режима «safe mode» для PHP-приложений и пр.);
Для ИС, использующих интегрированную доменную аутентификацию, создание учетных записей пользователей в домене должно осуществляться администраторами домена. Администраторы ИС, включая администраторов узлов нижестоящего уровня, должны иметь возможность сопоставления пользователей ИС с уже созданными в домене учетными записями и управления правами пользователей в ИС.
Для интеграции с контроллером домена необходимо использовать протокол аутентификации Kerberos или LDAP. Взаимодействие с контроллером домена осуществляется по портам TCP 3268, TCP/UDP 464 и TCP/UDP 88.
Условия использования технологических учетных записей
Пароли для технологических учетных записей должны задаваться двумя сотрудниками (например, администратором сервера приложений и сотрудником службы безопасности).
Присутствие в ИС учетных технологических записей со стандартными (устанавливаемыми производителем по умолчанию) паролями должно быть исключено.
Пароли для технологических учетных записей в процессе работы системы должны храниться в модуле ИС в защищенном от несанкционированного ознакомления виде.
Определение прав технологической учётной записи должно осуществляться на уровне технологической группы, которой присваиваются необходимые права для работы данной учётной записи. 
Технологическая учетная запись, от имени которой функционирует модуль ИС, должна обладать только теми правами доступа, которые являются безусловно необходимыми для выполнения операций, предусмотренных для этого модуля ИС проектной документацией, в том числе у технологических учетных записей, используемых составными частями ИС для доступа к СУБД, должны быть только те права, которые являются безусловно необходимыми для выполнения предусмотренных документацией операций.
Требования к парольной защите
В случае отсутствия интеграции с внешней системой управления доступом, определяющей политику парольной защиты, контроль качества используемых паролей должен быть реализован ИС. Критерии качества паролей, допускаемых к использованию в ИС, изложены в приложении.
При попытке подбора паролей при входе в ИС (неправильный набор пароля пять раз подряд) система должна блокировать работу пользователя не менее чем на 30 минут или до разблокировки учетной записи администратором, данное событие должно регистрироваться в журнале аудита; также в журнале аудита должен фиксироваться любой неправильный набор пароля с указанием IP-адреса или имени компьютера, с которого осуществлялась данная попытка.
Условия взаимодействия модулей ИС, размещаемых в разных контурах
Т.к. взаимодействие модулей ИС ЗК с модулями ИС в ОК осуществляется через шлюзы прикладного уровня, то протоколы взаимодействия должны позволять проводить анализ информации, передаваемой между ОК и ЗК, на предмет выявления потенциально небезопасного содержимого. 
Взаимодействие модулей ИС ЗК с модулями ИС в ОК и наоборот, по портам управления, файловый и блочный доступ, (например, 22 порт SSH, SMB, NFS, FTP, SFTP, Rsync) запрещено даже как временное решение для разных контуров как сегмента одной ИС, так и сегментов разных ИС.
Передаваемые данные должны быть структурированы и типизированы. Формат передаваемых данных должен позволять осуществлять парсинг (разбор) данных на составные части для последующей проверки и строго соответствовать стандарту: XML, JSON. В случае получения сообщения в формате, отличном от перечисленных, необходимо провести его конвертацию во внутренний формат XML, JSON для дальнейшей проверки, анализа и обработки.
В случае использования XML и соответствующих XSD-схем каждое поле XML-сообщения вида «request» и «response» с помощью политик обработки запроса по согласованным XSD-схемам (либо другим шаблонам разбора передаваемого сообщения) на шлюзах прикладного уровня проходит контроль на соответствие разрешенному формату и валидацию на соответствие содержимого и используемым символам, поэтому тип запросов и ответов в конфигурации должен быть указан как «XML».
В XML, JSON-сообщениях (либо аналогичных) должна отсутствовать передача SQL-команд (SQL-injection), в частности управляющих SQL-команд (UNION, UNION SELECT, DELETE и пр.).
Запрещена и будет заблокирована передача данных из ОК в ЗК, не прошедших проверку корректности:
сообщений или вложений, содержащих вирус, архивный с паролем или исполняемый файл;
файлов в бинарном виде.
Условия взаимодействия с СУБД ИС
При доступе модулей ИС к функциям СУБД ИС аутентификация является обязательной.
Соединение сервера приложений с базой данных должно устанавливаться с использованием выделенной технологической учетной записи, пароль для которой должен задаваться двумя сотрудниками (например, администратором сервера приложений и сотрудником службы безопасности) и в процессе работы системы храниться на сервере приложений в защищенном от несанкционированного ознакомления вида. 
В ИС прямой доступ к серверам СУБД должен быть открыт только серверам приложений ИС, находящимся в одном контуре; а также владельцам СУБД и системным администраторам СУБД. Полномочия пользователей ИС не должны прописываться в СУБД.
В целях обеспечения безопасности приложений введен запрет прямого обращения к СУБД из другого контура и между СУБД, размещенными в разных контурах.
С АРМ администратора в Башне ПК запрещено получение прямого доступа к СУБД. 
С АРМ пользователя в Башне ПК запрещено получение прямого доступа к СУБД. 
Для обеспечения анализа состояния базы данных ИС SQL-запросы разрешается выполнять исключительно в режиме «только чтение», т.е. запросы, не изменяющие информацию в СУБД.
Условия обеспечения взаимодействия между различными ИС
Организация информационного взаимодействия между компонентами различных ГИС/ИС возможно только при условии согласования такого взаимодействия между владельцами данных ГИС/ИС. 
Взаимодействие между ГИС/ИС может быть организовано внутри одного контура безопасности, например, только внутри ЗК или только внутри ОК. В случае необходимости, возможно взаимодействие между модулями различных ИС, размещенных в сегменте «Colocation» или в сети «Интернет», взаимодействие возможно только с модуля ИС, размещенного в контуре ОК.
Возможность взаимодействия между модулями различных ГИС/ИС, размещенных в разных зонах (TST, PPD, PRD, PREP), не предоставляется.
Взаимодействие разрешается при выполнении перечисленных условий:
допустимыми являются протоколы сетевого взаимодействия: HTTPS (в текстовых форматах обмена данными XML, JSON и т.п.);
организация прямого обращения из прикладного модуля ГИС/ИС к СУБД иной ГИС/ИС не допускается;
при взаимодействии модулей различных ГИС/ИС необходимо реализовывать двухстороннюю межмодульную аутентификацию, например, по протоколу HTTPS c использованием самоподписанных сертификатов;
взаимодействие с ГИС/ИС, размещенных в сети «Интернет», осуществляется с помощью прокси-сервера;
ГИС/ИС может осуществлять почтовые рассылки и отправку почтовых сообщений, как с использованием почтового сервера Исполнителя, так и с использованием почтового сервера ФОИВ, при наличии такого. Допускается организация взаимодействия с почтовым сервером только в рамках одного контура: только в рамках ЗК или только в рамках ОК. В Приложении Н приведены требования к организации почтовых рассылок и отправка электронных сообщений средствами ИС ФОИВ.
Условия обеспечения безопасности программных компонентов на АРМ пользователя
Программные компоненты (Java-апплеты, ActiveX-компоненты), загружаемые на АРМ пользователей ФОИВ, должны подписываться сертификатом разработчика ПО.
Потенциально опасными функциями ActiveX-компонента можно считать: RunCode, PrintDoc, EraseFile, Shell, Call, Write, Read и т.п. поэтому рекомендуется добавлять в компоненты проверку на вызов функций только из разрешенного домена (в соответствии с описанием механизма в статье Microsoft Knowledge Base «HOWTO: Tie ActiveX control to a Specific Domain»).
Недопустимо хранить в Java-апплетах критичную информацию (пароли доступа к СУБД, ресурсам и т.п.) т.к. исходный код Java-апплетов может быть восстановлен и проанализирован.
Условия организационно-технического взаимодействия при размещении ИС в Облаке
Условия, описанные в данном разделе, не распространяются на размещение в Зоне разработки и тестирования ИС и Подготовительной зоне (см. раздел REF _Ref112237701 \r \h 2.6.6).
Для размещения в Предпродуктивной и Продуктивной зонах ИС Облака допускается только ПО, переданное в ФПД ФОИВ (с обязательной фиксацией значения хэш-функции дистрибутива) и прошедшее в установленном в ФОИВ порядке процедуру приемо-сдаточных испытаний.
ИС не должны требовать установки ПО, не имеющего отношения к реализации прикладных функций. Необходимые для функционирования ИС программные компоненты определенных версий должны входить в комплект поставки ПО.
При необходимости размещения обрабатываемых в ИС данных в зоне разработки и тестирования и предпродуктивной зоне в состав дистрибутива ИС должен быть включен специализированный конвертор, необратимо обезличивающий информацию одним из следующих способов:
использования необратимых алгоритмов хеширования (ГОСТ);
использования набора данных, логически не связанных с продуктивными данными.
Все общесистемное ПО, устанавливаемое в Облаке, должно быть лицензировано – лицензии предоставляются ФОИВ или получаются в рамках предоставления услуг у Исполнителя.
ПО должно быть актуальной версии и включать обновления, опубликованные и рекомендованные производителем.
Первоначальную установку общесистемного ПО операционной системы сервера и его минимальные настройки для обеспечения работы ОС сервера производит Сервисная служба Исполнителя с официальных дистрибутивов, полученных от вендоров, либо разработчиков ИС ФОИВ.
Администрирование системного ПО в зоне разработки и тестирования производит разработчик или администратор ИС.
Администрирование системного ПО в Предпродуктивной и Продуктивной зонах ИС производит администратор ИС, а контроль за действиями администраторов ИС выполняет Сервисная служба ПК Исполнителя (подразделение, отвечающее за ИБ). Сервисная служба ПК Исполнителя загружает в WSUS или репозиторий обновления и патчи. Обновление ОС (Windows или Linux) выполняет Функциональный заказчик или его обслуживающая организация, используя подготовленные сервисным подразделением файлы.
Установку и администрирование прикладного ПО в Зоне разработки и тестирования ИС производит разработчик или администратор ИС.
Установку и администрирование прикладного ПО в Предпродуктивной и Продуктивной зонах ИС производит администратор ИС.
Выгрузка из ИС информации категории «ДСП» и ПДн должна производиться при обязательном согласовании с подразделением ФОИВ – владельцем информации.
Возможность фактической выгрузки информации должна предоставляться пользователю только после подтверждения владельцем информации права на осуществление выгрузки для этого пользователя, для чего в системе должен быть предусмотрен алгоритм согласования и предоставления пользователям полномочий на выгрузку.
При проведении критичной операции в ИС должна быть исключена возможность единоличного проведения данной операции от начала до конца. Пользователь, вводящий данные в систему, не должен осуществлять функции, относящиеся к компетенции пользователя, контролирующего введенную информацию (принцип «two persons»). Пользователь, подтверждающий информацию, не должен вносить в нее изменения; при необходимости он может только вернуть информацию на предыдущий этап обработки.
Для обеспечения взаимодействия ИС с инфраструктурными и технологическими сервисами Облака ЦОД ПК (серверы контроллеров домена, почтовые серверы, другие технологические и инфраструктурные сервисы), Функциональный заказчик должен включить список необходимых взаимодействий в матрицу доступа, с указанием IP-адресов конкретных серверов ИС, протоколов и портов взаимодействия. 
Детальные настройки для взаимодействия с инфраструктурными и технологическими сервисами Облака ЦОД ПК, которые могут быть использованы ИС в ЦОД ПК, должны запрашиваться Функциональным заказчиком по отдельному обращению в Сервисной службе ПК по адресу на адрес hd@rtk-it.ru или service@rtk-it.ru.
Условия и требования по размещению инфраструктурных систем ФОИВ
Информационные системы Заказчика и/или ФОИВ, реализующие функции Инфраструктурного ПО/решений для нужд ФОИВ (далее, ИПО) и влияющие/затрагивающие технические решения Исполнителя , на базе которых предоставляются услуги ЦОД ПК Исполнителя, и размещаемые на ресурсах ЦОД ПК, рассматриваются отдельно от прикладных ИС/ГИС, условия по размещению которых описаны в разделе 5.7. Условия и требования к размещению ИПО на ресурсах ЦОД ПК описаны в настоящем разделе, в котором предъявляются специфические условия и требования.
Общие сведения об ИПО
Основные отличительные от прикладных ИС/ГИС признаки/свойства ИПО:
должно непосредственно не использоваться конечными пользователями ПК;
не должно быть связано напрямую с функциональными обязанностями ФОИВ, должно обеспечивать вспомогательные функции для функционирования или обеспечения прикладных ИС/ГИС, в том числе для соблюдения требований ИБ к ИС/ГИС;
должно влиять на работоспособность других ИС/ГИС и сервисов, а также влияет на бизнес-процессы ФОИВ;
должно использоваться одной инсталляцией в интересах одного или нескольких ФОИВ.
Базовые необходимые для функционирования ИС ФОИВ функции ИПО предоставляются ФОИВ и Заказчику в виде сервисов/услуг Исполнителя в соответствии с ГК. 
Примеры ИПО, которые предоставляются ФОИВ и Заказчику в виде сервисов/услуг: 
контроллер домена;
антивирусное ПО.
Примеры ИПО, которые могут быть у ФОИВ и Заказчика: 
ПО мониторинга ИС ФОИВ/Заказчика;
почтовые системы под полным управлением ФОИВ/Заказчика;
ПО для организации почтовых рассылок.
Заказчик и/или ФОИВ должен организовать проверку работоспособности нового ИПО в рамках существующей инфраструктуры ПК. В случае запроса Исполнителя должна быть организована дополнительная и совместная проверка работоспособности и совместимости ИПО с сервисами и техническими решениями в ЦОД и Здании ПК, которые предоставляет Исполнитель .
Участники и этапы размещении ИПО в Облаке
Участники процесса размещения ИПО:
ФОИВ или Заказчик (далее в разделе – ФОИВ);
Исполнитель (ПАО «Ростелеком») - провайдер инфраструктуры ПК и услуг по ГК;
Подрядная организация ФОИВ или организации ПК по пилотированию, размещению, проверке работоспособности нового ИПО в инфраструктуре ПК. Этапы полного цикла размещения ИПО:
Проектирование и согласование документации по ИПО
Тестирование ИПО
Пилотирование ИПО
Организация промышленной эксплуатации ИПО
Условия организационно-технического взаимодействия при размещении ИПО в Облаке
Начальные условия:
ФОИВ оформляет решение о проведении работ по ИПО оформляется Заказчиком в виде внутреннего распоряжения по ФОИВ или организации ПК;
Подрядная организация ФОИВа и Исполнитель подписывают соглашение о конфиденциальности (NDA).
Проектирование и согласование документации по ИПО
Исполнитель выполняет проектирование; 
проектная документация на проведение пилота в целях размещения ИС ИПО в Облаке ПК согласно ТУ, подготовленная Подрядной организацией ФОИВа, должна содержать:
описание целей, задач и функционала ИПО;
описание требований к Аттестации/сертификации предъявляемых к ИПО;
сведения о размещении ИПО с привязкой к существующей инфраструктуре, с учетом требований ИТ и ИБ по размещению компонентов ИС в Облаке;
описание смежных ИС/ГИС ФОИВ, Заказчика и/или Исполнителя, с которыми будет взаимодействие в процессе функционирования ИПО;
оценка потенциального влияния ИПО на смежные ИС ФОИВ;
уровни SLA, предъявляемое к новой ИПО и SLA смежных ИС;
распределение зон ответственности, если ИПО внедряется для организации внутренней работы/взаимодействия ИС Заказчика или ФОИВ; 
план внедрения и план отката изменений на случае неуспешного размещения/тестирования;
Подрядная организация ФОИВа согласовывает проектную документацию с Исполнителем и Заказчиком до начала работ по предоставлению ресурсов в Облаке;
Исполнитель оценивает риски воздействия размещаемого ИПО на действующую инфраструктуру ПК и, в случае необходимости, информирует Заказчика об изменениях SLA на период проведения работ по размещаемой ИПО;
Тестирование ИПО
Цель тестирования ИПО отработка протоколов/технологии взаимодействия с существующими элементами (или их обезличенными копиями в соответствующих зонах проведения пилотного проекта) действующей инфраструктуры ПК. 
В зависимости от рисков воздействия на инфраструктуру ПК по результатам анализа документации на этапе Согласования документации по ИПО этап Тестирования ИПО может быть опущен и возможен переход сразу к этапу Пилотирования ИПО.
Тестирование ИПО проводится на тестовой инфраструктуре ПК (с копиями компонент инфраструктуры ПК) без использования защищаемой информации. Тестирование ИПО проводится только в Зоне разработки и тестирования (TST) ИТинфраструктуры, отделенной от Продуктивной (PRD), Предпродуктивной зон (PPD). К контуру тестирования не подключаются элементы ИТинфраструктуры, задействованные в работе Сервисных служб Исполнителя для оказания услуг по ГК.
Порядок действий и зон ответственности:
ФОИВ – запрос через заявку, оформленную установленным порядком, ресурсов Облака в Зоне разработки и тестирования (TST), сетевых взаимодействий и доступов, в соответствии с согласованной ПЗ для размещения на них ИПО;
Исполнитель – исполнение заявки ФОИВ, выделение ресурсов Облака, сетевых взаимодействий и доступов;
Подрядная организация ФОИВа – передача дистрибутивов и установка на полученные ресурсы Облака и настройка компонент, модулей и ПО ИПО в соответствии с согласованной проектной документацией;
Подрядная организация ФОИВа – проверка работоспособности ИПО в инфраструктуре ПК в соответствии с согласованной проектной документацией;
Подрядная организация ФОИВа – тестирование взаимодействия ИПО на тестовой инфраструктуре ПК в Зоне разработки и тестирования (TST);
ФОИВ, Исполнитель, Подрядная организация ФОИВ – подведение итогов тестирования ИПО; 
Подрядная организация ФОИВ – доработка документации по ИПО, при необходимости;
ФОИВ, Исполнитель – принятие решения о проведении следующего этапа «Пилотирование ИПО» в Продуктивной (PRD) или Предпродуктивной (PPD) зонах;
Пилотирование ИПО
Цель пилотирования ИПО – проверка взаимодействия с действующей инфраструктурой и оценка влияния этого ИПО на существующую инфраструктуру ПК. 
В процессе Пилотирования ИПО допускается использование реальных данных и защищаемой информации.
Пилотирование ИПО осуществляется в Препродуктивной (PPD) или Продуктивной (PRD) зонах.
Решение о проведении Пилотирования ИПО оформляется в виде внутреннего распоряжения по ФОИВ. На случай возможных ИТ-, ИБ-инцидентов, возникших в результате проведения пилотирования, в распоряжении указывается согласованные с Исполнителем возможные отклонения от сроков восстановительных работ в ИТ-инфраструктуры ПК (SLA), определенных в рамках действующих договорных отношений между Заказчиком и Исполнителем.
Порядок действий и зон ответственности:
ФОИВ – выпускает внутреннего распоряжения по ФОИВ о проведении пилотирования ИПО;
Исполнитель – оценивает риски воздействия ИПО на ИТ-инфраструктуру ПК и выдает рекомендации по необходимому изменению SLA по услугам, в связи с проведением пилотирования ИПО;
ФОИВ – утверждает изменению SLA по услугам на период пилотирования ИПО;
ФОИВ – запрос через заявку, оформленную установленным порядком, ресурсов Облака в Препродуктивной (PPD) или Продуктивной (PRD) зонах, сетевых взаимодействий и доступов, в соответствии с согласованной ПЗ для размещения на них ИПО;
Исполнитель – исполнение заявки ФОИВ, выделение ресурсов Облака, сетевых взаимодействий и доступов;
Подрядная организация ФОИВа – передача дистрибутивов и установка на полученные ресурсы Облака и настройка компонент, модулей и ПО ИПО в соответствии с согласованной проектной документацией;
Подрядная организация ФОИВа – проверка работоспособности ИПО в инфраструктуре ПК в соответствии с согласованной проектной документацией;
Подрядная организация ФОИВа – опытная эксплуатация и, при необходимости, донастройка и доработка ИПО;
ФОИВ, Исполнитель, Подрядная организация ФОИВа – подведение итогов опытной эксплуатации; 
Подрядная организация ФОИВа – доработка документации по ИПО, при необходимости;
ФОИВ, Исполнитель – завершение тестирования/пилотирования, возврат SLA к контрактным параметрам;
ФОИВ, Исполнитель – принятие решения о применимости ИПО и о проведении следующего этапа «Организация промышленной эксплуатации ИПО».
Требования по обеспечению ИБ при использовании технологии контейнеризации приложений
Обеспечение защиты информации при управлении доступом
Управление доступом должно быть реализовано как в самом контейнеризированном приложении, так и в средах управления системы контейнеризации с учетом следующих требований:
административные и системные учетные записи внутренним распорядительным документом должны быть закреплены за конкретными работниками ФОИВ или подрядчиками ФОИВ;
аутентификацию пользователей необходимо проводить с использованием службы каталогов, предоставляемой Исполнителем в качестве инфраструктурного сервиса ЦОД;
аутентификацию сервисных учетных записей системы управления контейнеризацией рекомендуется проводить также во внешней базе УЗ, обеспечивающей: парольную политику, а также хранение парольных последовательностей в зашифрованном виде. Хранение парольных последовательностей в закодированном (base64 и других вариантах простой кодировки) может привести к реализации рисков НСД; доступ пользователей должен реализовываться на базе принятой ролевой модели, определяющей с минимально необходимые для выполнения задач права доступа. При этом должны быть определены группы пользователей, выполняющие роли: разработчик образов контейнеров; администратор системы контейнеризации; администратор ИС. 
должен быть ограничен доступ непривилегированных пользователей к конфигурационным файлам контейнера, к системе управления контейнерами и репозиторию образов контейнеров (обеспечение целостности настроек контейнеров). Расширенные привилегии, такие опции, как –uts=host, --net=host, --ipc=host, --privileged, --cap-add=<CAP> и другие опции, непривилегированным пользователям не предоставляются;
должно быть выполнено отключение возможности повышения привилегий при работе в контейнерах (--security-opt=no-new-privileges).
Обеспечение защиты вычислительных сетей
При проектировании и размещении системы управления контейнеризации необходимо руководствоваться требованиями и правилами сетевого взаимодействия, изложенными в разделе REF _Ref114514051 \n \h 2.6.8 данного документа. В соответствии с этими условиями в каждой зоне безопасности ЦОД (TST, PPD, PREP, PRD), при необходимости, для организации работы каждой отдельной ИС должна быть развернута отдельная система управления контейнеризацией. Размещение одной системы управления в двух зонах безопасности ЦОД не допускается.
Контроль сетевого взаимодействия между контейнерами и контроль доступа контейнеров к сети «Интернет», а также к репозиториям образов контейнеров может реализовываться только с использованием сертифицированных средств межсетевого экранирования, применяемых в составе ЦОД Исполнителя. 
Реализация разграничения доступа между различными ГИС \ ИСПДн, использующими технологии контейнеризации приложений, допускается только путем применения сертифицированных ФСТЭК РФ средств межсетевого экранирования.
Автоматизированный контроль защищенности системы управления контейнеризацией
Автоматизированный контроль защищенности системы управления контейнеризацией обеспечивается средствами Исполнителя в рамках соответствующего сервиса. Администраторы ИС ФОИВ, эксплуатирующие систему контейнеризации, либо контейнеризированное приложение, должны проводить своевременную установку обновлений ПО системы управления контейнерами, с предварительным резервным копированием ПО контейнеров и конфигурационных файлов. 
Защита от вредоносного кода
Для обеспечения ИБ при использовании технологии контейнеризации необходимо использовать ПО системы управления контейнеризацией, образы контейнеров, ПО для подготовки контейнеров, полученное только из доверенных источников. 
Перед началом использования технологии контейнеризации необходимо обеспечить проведение процедур: контроля целостности ПО, анализ используемого ПО на предмет отсутствия уязвимостей и вредоносного ПО.ПО При этом проверка контейнеров проводится силами Исполнителя в рамках «Сервиса антивирусной защиты автоматизированной конечной точки» при перемещении файлов системы управления контейнеризацией и контейнеров через ФПД (см. Приложение Д).
После проведения проверок запуск системы управления контейнеров должен проводиться в режиме, не позволяющем программному коду, выполняемому в контейнерах, выполнить деструктивные действия в ОС хостов с ролями «Nod», «Master Nod».
Управление инцидентами защиты информации
В ОС хостов с ролями «Nod», «Master Nod»,» включенных в состав системы управления контейнеризацией, должен быть активирован аудит критичных событий: 
Login/LogOut; 
изменение полольной политики, политики аудита;
изменение системного времени; 
запуск/остановка сервисов ОС.
В системе управления контейнеризацией и контейнерах должен вестись аудит перечисленных, а также иных критичных событий. 
На уровне кластера необходимо настроить политику аудита, фиксирующую следующие критичные события: 
назначение роли «Cluster Admin»какому-либо пользователю; 
запуск привилегированных контейнеров; 
манипуляции с секретами; 
создание экземпляров приложения (pods) в определенных пространствах имен (namespaces), (например, в kube-system).
Срок хранения журналов аудита должен составлять не менее 30 суток.
Системное время в системе контейнеризации, а также внутри контейнера быть синхронизировано с временем NTP сервера, предоставляемого в инфраструктуре ЦОД Исполнителем. 
В целях обеспечения оперативного реагирования на инциденты ИБ кластер системы управления контейнеризацией, контейнеры, Nod(ы) системы должны быть подключены к SIEM Исполнителя.
Защита среды виртуализации (контейнеризации)
Размещение системы управления контейнеризацией и контейнеризированных приложений должно осуществляться в составе сертифицированных ФСТЭК России ОС, а в случае использования иных ОС, необходимо применять сертифицированные СЗИ, для защиты ОС от НСД. 
Система управления контейнеризацией должна реализовывать следующие манизмы изоляции контейнеров:
- изоляция пространств идентификаторов процессов;
- изоляция пространств имен для межпроцессорного взаимодействия;
- изоляция пространств имен для пользователей и групп;
- изоляция пространств имен хостов и доменов;
- изоляция сетевых имен;
- изоляция пространств имен для иерархии каталогов.
Для обеспечения в полной мере требований информационной безопасности и успешного прохождения аттестации разработчикам ГИС и ИСПДн целесообразно использовать системы управления контейнеризацией, реализованные в составе ОС, имеющие сертификаты ФСТЭК России. В таких ОС реализуется механизм контейнеризации, обеспечивающий режим виртуализации и изоляции ресурсов на уровне ядра операционной системы. 
Обеспечение ИБ АРМ администратора ГИС//ИСПДн
Общие требования к АРМ администратора ГИС/ИС ФОИВ
АРМ администратора ГИС/ИС ФОИВ может быть реализовано:
на базе стационарного персонального компьютера Исполнителя в типовой конфигурации, предоставляемого ФОИВ в рамках оказания ИТ-услуг на территории Правительственного комплекса по адресу г. Москва, Пресненская наб., д.10, стр.2 (Башня 2), на территории Московского международного делового центра «Москва-Сити»;
на базе персонального компьютера подрядчика, размещаемого в помещении подрядчика, либо на базе мобильного персонального компьютера подрядчика, удовлетворяющих описанным ниже требованиям.
Обеспечение ИБ АРМ администратора ГИС/ИС ФОИВ на базе стационарного персонального компьютера Исполнителя 
АРМ типовых конфигурации, предоставляемые Исполнителем для ФОИВ по действующему Государственному Контракту, имеют актуальный Аттестат № 0059/2021 от 29.12.2021 г. на соответствие требованиям защищенности, предъявляемым к ГИС второго класса защищенности (К2), утвержденным Приказом ФСТЭК России от 11.02.13 г. № 17, и к ИС персональных данных второго уровня защищенности (УЗ2).
Настойки механизмов безопасности средств защиты информации АРМ выполнены в соответствии с требованиями Приказа ФСТЭК России от 11.02.13 г. № 17. Дополнительной настройки систем защиты информации, используемых на типовом АРМ, не требуется. Для использования в работе администратору ГИС/ИС ФОИВ в ОС выделенного для администрирования АРМ могут быть предоставлены права локального администратора.
Обеспечение ИБ АРМ администратора ГИС/ИС ФОИВ в ИТ-инфраструктуре подрядчика
АРМ для удаленного администрирования ГИС/ИС ФОИВ, размещенный в инфраструктуре подрядчика, безусловно должен удовлетворять требованиям защищенности, предъявляемым к ГИС второго класса защищенности (К2), утвержденным Приказом ФСТЭК России от 11.02.13 г. № 17, и к ИС персональных данных второго уровня защищенности (УЗ2). Аналогичные требования предъявляются к АРМ подрядчика, организованным на базе мобильного персонального компьютера. 
В этой связи под задачу администрирования и управления ГИС/ИС ФОИВ необходимо использовать выделенный АРМ на аппаратной платформе, устанавливаемой стационарно, либо на мобильной платформе. Использование для этих целей выделенного виртуального АРМ потребует либо применения сертифицированной ФСТЭК России платформы виртуализации, либо использования в составе среды виртуализации подрядчика наложенных сертифицированных средств безопасности.
Обязательные требования к конфигурированию АРМ администратора ГИС/ИС ФОИВ
В состав ПО АРМ администратора ГИС/ИС ФОИВ должны входить средства администрирования, мониторинга, конфигурирования сетевого оборудования либо установленные с дистрибутивов на официальном физическом носителе, либо полученные с официальных сайтов производителей ПО. Установка на АРМ нелицензионного ПО, а также ПО, полученного из не доверенных источников, не допускается.
На АРМ администратора ГИС/ИС ФОИВ должны регулярно устанавливаться актуальные обновления (патчи) ОС, используемого прикладного и системного ПО, опубликованные производителем данного ПО; 
Для размещения АРМ администратора ГИС/ИС ФОИВ в инфраструктуре подрядчика должен быть организован выделенный VLAN с ограниченным доступом. Информационное взаимодействие таких АРМ с ресурсами сети «Интернет» должно быть заблокировано средствами МСЭ типа А, Б не ниже 4 класса защиты.
При организации АРМ администратора ГИС/ИС ФОИВ на базе мобильного персонального компьютера для ограничения работы с сетью «Интернет» должны применяться сертифицированные решения МСЭ типа В не ниже 4 класса защиты;
Удаленный доступ в ИТ-инфраструктуру ЦОД Исполнителя обеспечивается только с использованием сертифицированных решений криптографической защиты информации класса КС3. Для реализации данного требования на АРМ необходима установка ПО ViPNet Client for Windows/Linux 4.х производства компании «ИнфоТеКС».
На АРМ администратора ГИС/ИС ФОИВ должна быть установлена сертифицированная ФСТЭК России версия АВПО производства компании «Лаборатория Касперского», подключенного к системе управления Kaspersky Security Center под управлением Исполнителя. В составе АВПО активируется модуль Kaspersky Endpoint Detection and Response (системы обнаружения целевых, сложных атак на конечных точках). Настройки должны обеспечивать ежедневное обновление антивирусных баз, а также защиту АВПО сервисным паролем. Отключение АВПО или его удаление, даже кратковременные, не допускаются.
На АРМ администратора ГИС/ИС ФОИВ должно быть выполнено отключение неиспользуемых служб, в частности Сервис Сервер (Server)) для ОС семейства Windows, а также настроен запрет установки не используемого ПО.
На АРМ администратора ГИС/ИС ФОИВ должно быть реализовано применение парольной политики, определенной для ГИС/ИС соответствующей категории.
Защита АРМ администратора ГИС/ИС ФОИВ от несанкционированного доступа обеспечивается:
использованием пароля для входа в настройки BIOS или диспетчер загрузки по паролю;
установкой системы защиты от НСД по 4 уровню доверия, 5 классу защищенности СВТ.
Условия, определяющие возможность проведения аттестации ИС ФОИВ
Для проведения аттестационных испытаний ГИС и/или ИСПДн в качестве исходных данных должны быть представлены:
технический паспорт на объект информатизации;
акт классификации информационной системы;
модель угроз безопасности информации;
техническое задание на создание (модернизацию) информационной системы и (или) техническое задание (частное техническое задание) на создание (модернизацию) системы защиты информации информационной системы;
письма о согласовании с ФСБ России и ФСТЭК России в пределах их полномочий в части, касающейся выполнения установленных требований о защите информации, модели угроз и нарушителя безопасности информации и технического задания;
проектная и эксплуатационная документация на систему защиты информации информационной системы;
организационно-распорядительные документы по защите информации;
результаты анализа уязвимостей информационной системы (не содержащие реализуемых уязвимостей);
результаты испытаний ГИС, ИСПДн путем осуществления попыток НСД в обход применяемых средств защиты информации;
материалы предварительных испытаний, опытной эксплуатации и приемочных испытаний системы защиты информации информационной системы;
А также, иные документы, разрабатываемые в соответствии с применимыми НПА в области защиты информации.
Для проведения аттестационных испытаний ГИС и/или ИСПДн необходимо обеспечить выполнение следующих требований:
при реализации мер защиты информации разработанным специальным ПО необходимо провести оценку соответствия указанного ПО в форме обязательной сертификации ФСБ России и ФСТЭК России на соответствие требованиям по безопасности информации;
при реализации мер защиты информации разработанным специальным ПО, при этом используя функции и компоненты сертифицированных СЗИ, необходимо оценить степень влияния данного специального ПО и однозначно установить факт и указать в документации на ИС отсутствие реализации мер защиты информации не сертифицированным разработанным специальным ПО;
при реализации мер защиты информации наложенными СЗИ, такие СЗИ должны быть совместимы с ОС, на которую они устанавливаются, а также иметь официальную поддержку версии ядра ОС разработчиком наложенного СЗИ; 
класс СКЗИ, размещенных на АРМ и (или) мобильных технических средствах с предполагаемым удаленным доступом к размещаемой ИС, должен быть не ниже класса СКЗИ, определенного на этапе моделирования угроз и нарушителя безопасности информации и согласованного с ФСБ России;
применяемые в размещаемой ИС технологии и инфраструктура ИС должны соответствовать технологиям и инфраструктуре, заявленным на этапе моделирования угроз и нарушителя безопасности информации;
в ИС должен быть реализован функционал по разделению ролей пользователей на сервере, на имеющих право RO (Чтение) или RW (чтение и запись) или RWD (чтение, запись и удаление);
в документации к ИС должно быть определено/прописано, что назначение ролей той или иной группе пользователей входит в компетенции подрядной организации ФОИВ или ФОИВ;
в размещаемой ИС не осуществляется обработка информации, содержащей сведения, составляющие государственную тайну;
уровень защищенности размещаемой ИСПДн не должен превышать УЗ-2;
класс СКЗИ в размещаемой ИС не должен превышать КС3 (возможность размещения и последующей аттестации ИС, для которой определена необходимость применения СКЗИ более высокого класса определяется индивидуально);
при реализации мер защиты информации без заказа услуг и сервисов ИБ ЦОД ПК, меры защиты информации должны быть реализованы Заказчиком в полном объеме самостоятельно;
размещаемая ИС не является объектом критической информационной инфраструктуры Российской Федерации (возможность размещения и последующей аттестации ИС, которая является объектом критической информационной инфраструктуры Российской Федерации, определяется индивидуально).
Дополнительные условия
На этапе проектирования ГИС/ИС необходимо выбирать ОС, сертифицированную ФСТЭК России, по соответствующему уровню защиты информации, без использования наложенных средств защиты от НСД. Это позволит исключить возможные конфликты между ОС, СЗИ и Прикладным ПО в процессе жизненного цикла ГИС /ИС. В случае использования на серверах ГИС/ИС наложенных средств защиты от НСД их эксплуатация входит в зону ответственности подрядной организации, сопровождающей ГИС/ИС ФОИВ. 
На серверах ГИС/ИС Исполнитель предоставляет Сервис антивирусной защиты автоматизированной конечной точки. 
(обязательное)
Условия обеспечения ИБ в веб-приложениях
Требования к подсистеме управления сессиями пользователей
Авторизованному пользователю ИС должна быть предоставлена возможность самостоятельного завершения сеанса работы. По завершению сеанса работы ИС должна удалить идентификатор соответствующей сессии и считать данного клиента неавторизованным. 
Администратор WEB приложения должен иметь возможность ограничить время жизненного цикла сессии пользователя (время выбирается на усмотрение администратора при условии, что сессия не должна быть непрерывна). 
Требования к подсистеме разграничения доступа
Необходимо исключить возможность прямого обращения неавторизованного пользователя к защищенным ресурсам по известному URL. Доступ к защищенным ресурсам должен быть возможен только после проведения процедуры аутентификации.
Учетные данные пользователей должны храниться в защищенном виде. Хранение учетных данных в файлах, доступных путем обращения к ним через веб-сервер по URL, должно быть исключено.
Хранение критичной информации (учетные записи, пароли, пути к конфигурационным файлам и пр.) в HTML-страницах должно быть исключено.
В случае если в ИС предусматривается возможность внесения изменений пользователем в собственный профиль, внесенные изменения необходимо подтверждать проведением дополнительной процедуры аутентификации.
Использование заголовка REFERER, указывающего веб-серверу URL того ресурса, с которого пользователь попал на текущую страницу, в качестве основного механизма авторизации недопустимо.
Администратор WEB приложения должен обеспечивать, используя механизмы разграничения доступа к каталогам файловой системы ОС серверов ИС, блокировку создания, (появление новых файлов – create) PHP файлов, Python файлов во всех директориях WEB сервера. Ограничение необходимо сделать на всех серверах WEB – сайта.
Защита от внедрения управляющих SQL-команд
Для построения в ИС SQL-запросов должны использоваться параметризованные запросы (например, хранимые процедуры).
В случае, если применение параметризованных запросов невозможно, получаемые от пользователя данные должны проходить процедуру предварительной обработки, в ходе которой из них необходимо удалять метасимволы « ` -- /*», а также следующие SQL-операторы SELECT, UNION, ALTER, UPDATE, EXEC, DROP, DELETE, INSERT. Контентная фильтрация может быть реализована с помощью специализированных регулярных выражений.
Защита от атак «Cross-site scripting»
Для защиты от подобных атак передаваемые данные должны быть представлены текстом или к ним должны быть применены описанные ниже методы защиты. 
Приведение данных к каноническому виду, а затем в случае обнаружения в них HTML-тегов выполнение следующих преобразований:
заменить < > на &lt и &gt;
заменить ( ) на &#40 и &#41;
заменить # на &#35;
заменить & на &#38.
Обработка выходного потока данных – например, с использованием методов Server.HTMLEncode и HttpServerUtility.HTMLEncode в ASP и ASP.NET, преобразующих потенциально опасные символы, в том числе HTML-теги, во внутреннее безопасное представление.
Вставка данных в свойство innerText, которое обрабатывает любую информацию как текст (пассивная информация). При этом использование свойства innerHTML является недопустимым, так как данное свойство возвращает текст в виде HTML-кода.
Использование метода ValidateRequest, который осуществляет проверку записи HTML-кода или сценариев в cookie-файлы (HttpRequest.Cookies), строки запросов (HttpRequest.QueryString) и HTML-формы (HttpRequest.Form).
Запретить пользователю ввод данных, в которых допустимы HTML-теги <IMG> или <TABLE>. Безопасными можно считать тэги: <PRE>, <BR>, <P>, <I></I>, <B></B>, в случае если дополнительно используются регулярные выражения (например, (/^(?:[\s\w\?\!\,\.\’\»]*|(?:\<\/?(?:i|b|p|br|em|pre)\>))*$/i).
При этом защитой не является перевод полученных данных в верхний регистр, а также фильтрация тэгов JScript, VBScript и т.д.
Вывод сообщений об ошибках в веб-приложениях 
ИС должна обрабатывать все сообщения об ошибках, полученные от сервера, и возвращать клиенту минимальное количество информации об ошибочных ситуациях, возникающих на сервере. При возникновении ошибки пользователю должна предоставляться только общая информация и идентификатор записи в журнале аудита с расшифровкой ошибки.
В случае нарушения работоспособности приложения следующую информацию запрещено предоставлять пользователю:
данные о структуре файловой системы (информация о версии ОС, директориях с системными файлами и системным ПО, включая пути к директориям и файлам);
фрагменты программного или конфигурационного кода;
сообщения об ошибках при передаче запросов в СУБД;
SQL-выражения, используемые при доступе к базе данных.
В случае выявления в приложении критичной ошибки рекомендуется перенаправлять пользователя на HTML-страницу, при этом статус HTTP-ответа веб-сервера должен соответствовать «200».
Полный текст сообщения об ошибке, включая системные сообщения, должен сохраняться в журнале аудита так, чтобы администратор ИС мог отыскать его по идентификатору записи, сообщенной пользователю, а также посредством указания комбинации учетной записи пользователя (выполнявшего операции) и интервала времени возникновения ошибки.
Пользователю должны выводиться исчерпывающие и понятные сообщения об ошибках, когда невозможно записать текст сообщения в журнал аудита серверной части. Это касается ошибок, связанных с некорректным функционированием клиентского приложения и невозможностью установления полноценной связи с сервером.
Безопасность веб-сервисов 
В веб-сервисах должны быть реализованы механизмы аутентификации вызывающей системы, а также механизмы разграничения доступа к веб-сервисам и их методам. Анонимные вызовы веб-сервисов запрещены. 
В процессе обработки сообщения, полученного веб-сервисом, в системе-получателе необходимо проверить:
соответствие структуры полученного сообщения утвержденной XML-схеме обмена сообщениями;
наличие разрешения у системы-отправителя на выполнение операций, указанных в сообщении.
Помимо этого, в системе-получателе сообщения должен быть реализован аудит сообщений, полученных соответствующим веб-сервисом. В журнале аудита должно быть отражено: время, идентификатор ИС, отправившей сообщение, IP-адрес сервера-отправителя, запрошенная операция и её результат, а также результат проверки контрольного значения процедуры проверки ЭП.
Публикация UDDI-каталогов и WSDL-схем разрешается только при условии проведения аутентификации и авторизации пользователей при доступе к указанным объектам с использованием защищенных протоколов (NTLM, Kerberos).
Требования к веб-приложениям по протоколам аутентификации 
Для аутентификации пользователей должны использоваться защищенные протоколы аутентификации, допускающие передачу информации только в зашифрованном виде. 
Для этих целей могут использоваться, например, протоколы аутентификации NTLM/Kerberos (при интегрированной доменной аутентификации) или криптографический протокол TLSv1.2 (и выше).
При аутентификации на основе форм ввода регистрационную информацию (например, имя пользователя и его пароль) необходимо передавать в POST-запросах. Правильной практикой является использование сервиса ЕСИА в качестве универсального средства аутентификации пользователей.
Все API интерфейсы, используемые Заказчиком (администратором WEB приложения) для технического сопровождения WEB-сайта, должны при подключении к ним через сеть Интернет требовать аутентификации в ЕСИА.
Безопасность XML-документов и XML-схемы 
Использование при обработке данных в формате XML внешних сущностей (External Entity), внешних параметров сущностей (External Parameter Entity) и внешних описаний типа документа (External Doctype) должно быть исключено.
Должна быть обеспечена защита XML-схемы от несанкционированного изменения. 
Защита данных веб-приложений
В параметрах веб-формы, предназначенных для ввода конфиденциальной информации, должны присутствовать директивы, запрещающие кеширование данных. 
У параметров cookie, значения которых не должны быть доступны сценариям, выполняемым веб-браузером, должен быть выставлен атрибут HTTPOnly. 
У параметров cookie, содержащих чувствительную информацию, должен быть выставлен атрибут «Secure».
Работа WEB приложения с обращениями граждан
Настройками WEB приложения должна быть исключена возможность получения обращений по формам обратной связи (сервисы «Прием обращений граждан и организаций»), размещенным на официальном сайте с IP-адресов (доменов), страной происхождения которых являются недружественные Российской Федерации государства. 
Настройками WEB приложения должна быть исключена возможность выполнения загрузки файлов любых форматов, кроме тех, что имеют расширение (жесткий белый список *.txt, *.scv), или белый список (более мягкий к перечисленным + *.jpg, *.pdf). 
 Защита API
В целях обеспечения защиты WEB приложения, опубликованного в сети Интернет, необходимо обеспечить выполнение следующих мер информационной безопасности: 
Исполнителем на периметровом оборудовании WAF выполнять блокировку всех POST запросов, в которых присутствуют следующие расширения : php|py|pak|sql|exe|dll|so|bat|cmd|sh|ps1|vbs|jar|class|py|php|phtml|rb|pl|js|sql|mjs|ini|config|yaml|xml|htm|html|svg|zip|rar|tar|gz|bz2|7z.
ФОИВ, Заказчик должен информировать Исполнителя об используемых для работы WEB приложения API интерфейсах, публикуемых в сети Интернет. Исполнителю на периметровом WAF (PTAF) предоставить доступ из сети Интернет только к API – интерфейсам, заявленным Заказчиком. 
ФОИВ, Заказчику необходимо отказаться от использования на веб-ресурсах (в том числе вебсайтах) компонентов и контента, подгружаемых с внешних ресурсов, не контролируемых организацией.
Обработка ввода и вывода 
Должна выполняться проверка корректности вводимых пользователем данных не только на стороне клиента (с использованием сценариев, исполняемых веб-браузерам), но и на стороне сервера.
В заголовках HTTP-сообщений должны использоваться директивы, определяющие используемую кодировку. Использование разных кодировок для разных источников входных данных должно быть исключено.
(обязательное)
Условия обеспечения аудита действий в ИС
Требования общего назначения
В ИС должен быть реализован механизм аудита с протоколированием следующих действий и событий:
действий администратора ИС;
событий, связанных с выполнением технологических процессов внутри системы, и событий безопасности;
действий пользователей, связанных с выполнением бизнес-операций (фискальные события);
изменений состояния каждого документа, включая возврат документа на предыдущий этап обработки. Аудит по документам является обязательным элементом для ИС, обрабатывающих финансовые документы.
Протоколирование действий администратора ИС и событий безопасности должно осуществляться средствами ИС в соответствии с требованиями данного Приложения. 
Должна осуществляться визуализация информации из журнала аудита в соответствии с требованиями данного Приложения.
Невозможность несанкционированной модификации данных аудита
Журнал подсистемы аудита должен вестись таким образом, чтобы исключить возможность его несанкционированной модификации как путем штатных действий внутри ИС, так и осуществляемых извне.
Необходимо исключить возможность редактирования, отключения и удаления журнала аудита средствами ИС, а также его импорта в ИС из какого-либо источника.
Данные журнала аудита 
Наличие в журнале аудита ИС чувствительных данных (пароли пользователей, ПДн и т.п.) должно быть исключено.
Централизованное ведение журнала аудита 
Регистрация отдельных событий только составными частями ИС, потенциально доступными нарушителю (например, АРМ пользователя, общедоступные веб-серверы), должна быть исключена.
Обязательные реквизиты данных аудита 
Информация в журнале подсистемы аудита должна представляться в структурированном виде в терминах прикладной области, т.е. события должны фиксироваться с бизнес-сущностями, а не с объектами баз данных. В журнале в обязательном порядке указываются следующие реквизиты события: дата и время; идентификатор пользователя, действия которого привели к возникновению события; наименование; идентификатор/наименование данных, на которые происходило воздействие; параметры; результат (успешный/неуспешный).
Время, фиксируемое в данных аудита 
При протоколировании событий в журнале аудита ИС должно фиксироваться время (в формате UTC с точностью до секунды) прикладного сервера, т.е. сервера приложений.
Синхронизация времени ОС 
Отсутствие или отключение средств синхронизации времени ОС на АРМ или сервере ИС должно быть исключено.
Разграничение доступа к данным аудита 
Возможность доступа к данным аудита должна предоставляться только уполномоченным пользователям. Для выполнения данного требования работа с журналами в самой ИС должна осуществляться через прикладной уровень, а не через технологические интерфейсы веб-серверов, СУБД, серверов приложений.
Очистка данных аудита 
Должны быть предусмотрены средства системы для очистки журнала аудита за определенный промежуток времени (за исключением как минимум шести последних месяцев) с фиксацией данного события в журнале аудита.
Должна быть исключена возможность очистки, в том числе средствами системы, журнала аудита до его архивирования или распечатки.
Возможность подключения архивных данных аудита 
Журналы аудита на внешнем накопителе должны храниться не менее трех лет.
Для обеспечения работы с журналами аудита за предыдущие периоды должна быть реализована функция подключения, выгруженного на внешний накопитель журнала, при котором загружаемые данные только дополняют существующий журнал аудита, но не изменяют уже хранящейся в нем информации.
Обеспечение целостности архивных данных аудита 
Должен обеспечиваться контроль целостности архивных журналов аудита, в том числе защита от ошибочных или преднамеренных действий администраторов ИС. Например, организована реализация механизма периодического автоматического сброса журнала на внешние носители с помощью роботизированных средств. При этом желательно использовать носители, не допускающие перезапись. Действия при переполнении журнала аудита.
При достижении журналом первого порогового значения объема, определенного параметрами ИС, администратору ИС должно выдаваться соответствующее предупреждение. При превышении журналом второго порогового значения объема, определенного параметрами ИС, администратору ИС должно выдаваться повторное предупреждение, а при записи в журнал сначала должны перезаписываться наиболее «старые» данные.
Параметры для анализа данных аудита 
В ИС должен быть реализован фильтр, позволяющий производить выборку и печать/выгрузку информации из журнала аудита по следующим параметрам: 
событию (например, нарушение контрольного значения процедуры создания ключевых пометок);
действиям конкретного пользователя;
действиям над конкретным пользователем;
действиям над конкретным документом/объектом, с разделением понятий создавшего и подтвердившего документ пользователя;
дате (периоду дат);
времени (периоду времени);
комбинации вышеперечисленных параметров.
Комбинация параметров для анализа данных аудита 
Должна предоставляться возможность произвольной группировки задаваемых параметров, например, получения выборки по документам, ввод и подтверждение которых совершались одним пользователем (нарушение принципа разделения полномочий). Названия событий и пользователей могут вводиться вручную либо выбираться из списка.
Управление журналом аудита 
Управление журналом аудита (очистка за определенный промежуток времени, настройка списка протоколируемых операций и т.д.) должно осуществляться администратором ИС. При этом все действия администратора ИС (успешные и неуспешные) по управлению журналом аудита, включая также пассивные операции (просмотр данных), должны фиксироваться в этом же журнале.
Перечень фискальных событий журнала аудита
Для ИС в документации или условиях эксплуатации должен быть определен минимально необходимый перечень фискальных событий, которые заносятся в журнал аудита. Желательно наличие возможности настройки в ИС перечня фискальных событий, подлежащих аудиту. При этом протоколирование расчетно-денежных операций является обязательным и должно осуществляться постоянно (возможность отключения их протоколирования должна отсутствовать в системе).
Протоколирование пассивных бизнес-операций
Целесообразно реализовать в ИС протоколирование пассивных бизнес-операций (просмотр данных).
Степень видимости данных журнала аудита
Область видимости данных журнала аудита (для случая иерархического администрирования) не должна превышать области видимости журналируемых данных ИС, определенной для пользователя его правами доступа. При выборке на просмотр информации из журнала аудита должны проверяться права доступа пользователей к данным. Информация, доступ к которой пользователю запрещен, в выборку входить не должна. 
Передача событий аудита в систему управления событиями ИБ (SIEM)
Должна быть возможность передачи в SIEM событий аудита по протоколу Syslog.
Должна быть обеспечена возможность задать одного или нескольких получателей, как по IP-адресу, так и по DNS имени, указать порт назначения, выбрать протокол (UDP/TCP).
Должна быть возможность задать порт назначения.
Должна быть возможность выбора протокола работы Syslog (UDP/TCP).
Опционально должна быть возможность для каждого получателя задать свой набор передаваемых событий.
Опционально должна быть возможность повторной отправки событий аудита по заданным диапазону времени и типам событий на указанного получателя.
Требования к журналу аудита
Регистрация события создания нового пользователя 
Должны фиксироваться все атрибуты создаваемого пользователя.
Регистрация назначения/изменения пользовательских прав 
Должно фиксироваться назначение пользователю прав доступа к данным и функциям ИС, а также изменение прав доступа. Должна фиксироваться полная информация по назначаемым или изменяемым правам.
Регистрация блокирования пользователя 
Должны фиксироваться все атрибуты блокируемого пользователя.
Регистрация входов пользователей в систему
Должны фиксироваться как входы пользователей в систему, так и выходы из нее. Должна фиксироваться информация по компьютеру, с которого осуществлен вход (IPадрес или имя).
Регистрация попыток совершения НСД 
Должны фиксироваться попытки совершения НСД (неправильный ввод пароля) или превышения полномочий. Должна фиксироваться информация по компьютеру, с которого был выполнен вход или была осуществлена попытка входа (IP-адрес или имя).
Регистрация изменений параметров и настроек 
Должны фиксироваться изменения параметров и системных настроек ИС с указанием старых и новых значений параметров и настроек.
Регистрация нарушений целостности 
Должны фиксироваться отрицательные результаты проверок целостности данных в системе, включая базы открытых ключей ЭП.
Регистрация случаев недоступности интерфейсов составных частей ИС 
Должны фиксироваться все случаи недоступности интерфейсов составных частей ИС.
Регистрация автоматического завершения пользовательской сессии 
Должны фиксироваться все атрибуты пользователя, сессия которого была автоматически завершена по истечении установленного периода времени.
(обязательное)
Критерии качества паролей
Пароль для входа в ИС считается качественным, если он удовлетворяет следующим условиям:
длина пароля пользователя составляет не менее 8 символов;
длина пароля администратора составляет не менее 14 символов;
длина пароля технологической учетной записи составляет не менее 14 символов;
в качестве пароля не используется имя учётной записи;
пароль образован из цифр, строчных и прописных букв;
в пароле используется минимум 6 разных символов;
в пароле отсутствуют три рядом стоящих знака из следующих последовательностей (как слева направо, так и справа налево):
1234567890-=
йцукенгшщзхъфывапролджэячсмитьбю
qwertyuiop[]asdfghjkl;’zxcvbnm,./
qazwsxedcrfvtgbyhnujmik,ol.p;/[‘]
йфяцычувскамепинртгоьшлбщдюзж.хэъ
741852963
ЙЦУКЕНГШЩЗХЪФЫВАПРОЛДЖЭЯЧСМИТЬБЮ
QWERTYUIOP[]ASDFGHJKL;’ZXCVBNM,./
QAZWSXEDCRFVTGBYHNUJMIK,OL.P;/[‘]
ЙФЯЦЫЧУВСКАМЕПИНРТГОЬШЛБЩДЮЗЖ.ХЭЪ
1йфя2цыч3увс4кам5епи6нрт7гоь8шлб9щдю0зж.-хэ=ъ
1ЙФЯ2ЦЫЧ3УВС4КАМ5ЕПИ6НРТ7ГОЬ8ШЛБ9ЩДЮ0ЗЖ.-ХЭ
1QAZ2WSX3EDC4RFV5TGB6YHN7UJM8IK,9OL.0P;/-[‘=]
1qaz2wsx3edc4rfv5tgb6yhn7ujm8ik,9ol.0p;/-[‘=]
1q2w3e4r5t6y7u8i9o0p-[=]azsxdcfvgbhnjmk,l.;/’qawsedrftgyhujikolp;[‘]
1Q2W3E4R5T6Y7U8I9O0P-[=]AZSXDCFVGBHNJMK,L.;/’QAWSEDRFTGYHUJIKOLP;[‘]
1Й2Ц3У4К5Е6Н7Г8Ш9Щ0З-Х=ЪФЯЫЧВСАМПИРТОЬЛБДЮЖ.ЭЙФЦЫУВКАЕПНРГОШЛЩДЗЖХЭЪ
1й2ц3у4к5е6н7г8ш9щ0з-х=ъфяычвсампиртоьлбдюж.эйфцыувкаепнргошлщдзжхэъ
(справочное)
ФПД. Схема информационного обмена через ФПД между ЗК и ОК ЦОД ПК
Структура ФПД 
ФПД каждого ФОИВ состоит из двух частей:
В ОК – ФПД ОК;
В ЗК – ФПД ЗК.
ФПД ОК имеет следующие области:
IN OK – область, куда поступают данные извне;
CONТROL OK – область, в которой производится проверка поступивших данных;
OUT OK – область, где хранятся оригиналы проверенных файлов дистрибутивов, исходников, документации, данных для чтения в ОК.
ФПД ЗК имеет следующие области:
IN ZK – область, куда выкладываются данные из одной зоны в ЗК для передачи в другую зону в ЗК;
CONTROL ZK – область, в которой производится проверка поступивших данных;
OUT ZK – область, где хранятся оригиналы проверенных файлов дистрибутивов, исходников, документации, данных для чтения в ЗК.
Описание процесса внесения данных в ФПД
Рисунок Д.1 – Схема внесения данных в ФПД
Шаг 1. Разработчик/администратор ИС:
формирование пакета дистрибутивов, документации или данных ИС;
запись в область IN OK ФПД ОК подготовленного пакета, размер пакета не должен превышать объем, выделенный под данную ИС;
формирование и регистрация ЗНО (Запрос на обслуживание) с указанием места размещения данных. ЗНО формируется и регистрируется с помощью отправки сообщения по электронной почте в адрес сервисной службы ПК HD@RTK-IT.RU или service@rtk-it.ru сотрудником ФОИВ.
Шаг 2. Сервисная служба ПК, подразделение, отвечающее за ИТ:
перенос загруженных в область IN OK данных в область CONTROL OK для дальнейшей проверки (папка в области IN OK освобождается от данных, перенесённых в область CONTROL OK);
дальнейшие действия по заявке совершаются только с данными, перенесёнными в область CONTROL OK;
уведомление подразделения, отвечающего за ИБ, сервисной службы ПК, о наличии данных для проверки средствами СОИБ.
Шаг 3. Сервисная служба ПК, подразделение, отвечающее за ИБ:
проведение проверки поступивших в CONTROL OK данных ИС/ГИС средствами обеспечения ИБ;
уведомление подразделения, отвечающего за ИТ, сервисной службы ПК, об успешной проверке СОИБ данных в области CONTROL OK
или уведомление разработчика/администратора ИС/ГИС о выявленных проблемах, в случае неуспешной проверки СОИБ. 
В случае неуспешной проверки уведомляется разработчик/администратор ИС/ГИС и ЗНО завершается (после устранения проблем должна быть создана новая ЗНО).
Шаг 4. Сервисная служба ПК, подразделение, отвечающее за ИТ:
перемещение данных, успешно прошедших проверку в области CONTROL ОК, в область OUT OK и/или область OUT ZK в соответствии с указаниями ЗНО (см. шаг 1).
Исполнитель подразделения, отвечающего за ИТ, сервисной службы ПК в ЗНО делает пометку о размещении данных в соответствии с заявкой. По факту перемещения данных ЗНО с отметкой «исполнено» закрывается.
По факту размещения дистрибутивных пакетов и документации в ФПД ЗК и/или ФПД ОК Исполнитель информирует представителя ФОИВ, ответственного за информатизацию.
Шаг 5. Разработчик/администратор ИС:
подтверждение полноты и доступности данных в ФПД ОК и/или ФПД ЗК.
Описание процесса внесения данных в ФПД в ЗК
Рисунок Д.2 – Схема внесения данных в ФПД ЗК
Шаг 1. Разработчик/администратор ИС:
формирование пакета данных ИС;
запись в область IN ZK ФПД ЗК подготовленных данных, размер данных не должен превышать объем, выделенный под данную ИС;
формирование и регистрация ЗНО (Запрос на обслуживание) с указанием места размещения данных. ЗНО формируется и регистрируется с помощью отправки сообщения по электронной почте в адрес сервисной службы ПК HD@RTK-IT.RU или service@rtk-it.ru сотрудником ФОИВ.
Шаг 2. Сервисная служба ПК, подразделение, отвечающее за ИТ:
перенос загруженных в область IN ZK данных в область CONTROL ZK для дальнейшей проверки (папка в области IN ZK освобождается от данных, перенесённых в область CONTROL ZK);
дальнейшие действия по ЗНО совершаются только с данными, перенесёнными в область CONTROL ZK;
уведомление подразделения, отвечающего за ИБ, сервисной службы ПК о наличии данных для проверки средствами СОИБ.
Шаг 3. Сервисная служба ПК подразделение, отвечающее за ИБ:
проведение проверки поступивших в CONTROL ZK данных ИС/ГИС средствами обеспечения ИБ;
уведомление подразделения, отвечающего за ИТ, сервисной службы ПК об успешной проверке СОИБ данных в CONTROL ZK;
или уведомление разработчика/администратора ИС/ГИС о выявленных проблемах, в случае неуспешной проверке СОИБ. 
В случае неуспешной проверки уведомляется разработчик/администратор ИС/ГИС и ЗНО завершается (после устранения проблем должен быть создан новый ЗНО).
Шаг 4. Сервисная служба ПК, подразделение, отвечающее за ИТ:
перемещение данных, успешно прошедших проверку в CONTROL ZК, в OUT ZK в соответствии с указаниями ЗНО (см. шаг 1).
Исполнитель подразделения, отвечающего за ИТ, сервисной службы ПК в ЗНО делает пометку о размещении данных в соответствии с заявкой. По факту перемещения данных, ЗНО с отметкой «исполнено» закрывается.
По факту размещения данных в ФПД ЗК Исполнитель информирует представителя ФОИВ, ответственного за информатизацию.
Шаг 5. Разработчик/администратор ИС:
подтверждение полноты и доступности данных в ФПД ЗК.
Описание процесса удаления, перемещения или копирования данных в ФПД
Шаг 1. Разработчик/администратор ИС:
регистрация соответствующего ЗНО (Запрос на обслуживание) с указанием выполняемых действий (удаления, перемещения или копирования) с данными. ЗНО формируется и регистрируется с помощью отправки сообщения по электронной почте в адрес сервисной службы ПК hd@rtk-it.ru или service@rtk-it.ru сотрудником ФОИВ.
Шаг 2. Сервисная служба ПК, подразделение, отвечающее за ИБ:
в случае переноса или копирования данных из ФПД ЗК в ФПД ОК согласование ЗНО или выдача обоснованного отказа.
Шаг 3. Сервисная служба ПК, подразделение, отвечающее за ИТ:
осуществление удаления, переноса или копирования данных в соответствии с ЗНО (в случае переноса или копирования данных из ФПД ЗК в ФПД ОК операция производится только после согласования возможности выполнения действия в подразделении, отвечающего за ИБ, сервисной службы ПК ).
Схема информационного взаимодействия зон ЗК и ОК ЦОД ПК
Рисунок Д.3 – Схема информационного взаимодействия зон ЗК и ОК ЦОД ПК
(обязательное)
Предотвращение реализации угроз безопасности информации
№
С целью предотвращения реализации угроз безопасности информации, связанных с эксплуатацией уязвимостей, просим обратить внимание на необходимость устранения следующих уязвимостей:
Что необходимо выполнить 
1
Уязвимость компонента Zabbix Frontend системы мониторинга Zabbix (BDU:2022-00884, уровень опасности по CVSS 2.0 – средний, по CVSS 3.0 критический) позволяет нарушителю обойти аутентификацию на серверах с настроенным языком разметки подтверждения безопасности SAML (открытый стандарт, обеспечивающий единую точку аутентификации (единый вход), которая обеспечивает обмен данными между поставщиком удостоверений и поставщиком услуг)
В случае использования данного ПО: необходимо отключить аутентификацию SAML
2
Уязвимость системы мониторинга Zabbix (BDU:2022-00876, уровень опасности по CVSS 2.0 – средний, по CVSS 3.0 – средний), связанная с ошибками контроля доступа, которая позволяет злоумышленникам изменить файл конфигурации (скрипт setup.php) и получить доступ к панели управления с повышенными привилегиями
В случае использования данного ПО: необходимо удалить setup.php файл
3
Уязвимость ОС Cisco NX-OS (BDU:2022-01004, уровень опасности по CVSS 2.0 критический, по CVSS 3.0 – высокий) позволяет нарушителю, действующему удаленно, осуществлять команды от имени пользователя root
В случае использования данного ПО в ФОИВ (сегмент «Colocation»): необходимо отключить функцию NXAPI в настройках ПО Cisco NX-OS
4
Уязвимость сетевого ПО Mozilla VPN (BDU:2022-00972, уровень опасности по CVSS 2.0 – средний, по CVSS 3.0 – высокий) позволяет запускать произвольный код с привилегиями SYSTEM при использовании возможности загрузки файла конфигурации OpenSSL из незащищенного каталога
В случае использования данного ПО: необходимо исключить использование Mozilla VPN
5
Уязвимость маршрутизаторов Huawei Engine (BDU:2022-00994, уровень опасности по CVSS 2.0 – высокий, по CVSS 3.0 – высокий) позволяет нарушителю повысить свои привилегии в ИС
В случае использования данного ПО: Рекомендовано обновление до актуальной версии
6
Уязвимость демона обработки потоков (flowd) ОС Juniper Networks Junos на устройствах серий MX и SRX (BDU2022-00995, уровень опасности по CVSS 2.0 – высокий, по CVSS 3.0 – высокий) позволяет нарушителю, действующему удаленно, вызвать сбой потока и тем самым реализовать атаку «отказ в обслуживании»
В случае использования данного ПО в ФОИВ (сегмент «Colocation»): необходимо отключить функции SIP ALG в настройках сетевого устройства
7
Для службы доменных имен (DNS)
Обеспечить разнесение ролей DNS-серверов «User Primary DNS Server» и «Domain Primary DNS Server» на разные физические и/или виртуальные серверы.
Запретить в качестве «User Primary DNS Server» использовать DNS-серверы, расположенные за пределами Российской Федерации (например, перейти на использование НСДИ).
В части «Domain Primary DNS Server»: 
запретить рекурсивные запросы разрешения доменных имён; 
запретить разрешение доменных имён объектов, не относящихся к информационным ресурсам организации; 
настроить механизмы защиты от спуфинг-атак; 
запретить уведомления и перенос зон произвольными объектами сети Интернет;
настроить список доверенных DNS-серверов
8
Уязвимости в конфигурации серверов MS SQL Server
В случае использования данной конфигурации ПО в ФОИВ (сегмент «Colocation»): необходимо заблокировать доступ к сети «Интернет», а также заблокировать доступ к серверам по порту TCP 1433
(обязательное)
Повышение уровня защищённости веб-приложений, размещенных в ЦОД ПК
В целях защиты от компьютерных атак на веб-приложения в российском сегменте сети «Интернет», в том числе через внешние компоненты кода веб-страниц (к таким компонентам могут относиться: подключаемые JavaScript-библиотеки, CSS-фреймворки, плагины защиты от вредоносной активности (CAPTCHA), информационные и аналитические плагины (новостные ленты, интерактивные карты, подсчёт посещений информационного ресурса и т.д.), а также веб-шрифты, подгружаемые со сторонних серверов) рекомендуется принять следующие меры:
Организовать авторизованному пользователю веб-приложения возможность самостоятельного завершения сеанса работы в веб-приложении.
Обеспечить гарантированное удаление идентификатора соответствующей сессии по завершению сеанса работы клиента веб-приложения.
Ограничить время жизни активной сессии пользователя.
Организовать доступ к защищенным ресурсам веб-приложения только после прохождения процедуры аутентификации.
Обеспечить хранение аутентификационных данных пользователей веб-приложения только в криптографически защищенном виде.
Исключить хранение аутентификационных данных от веб-приложений, СУБД, телекоммуникационного оборудования, FTP-ресурсов и т.п. и на HTML-страницах в файлах, доступных по URL, а также информации, позволяющей сделать вывод о структуре каталогов веб-приложения на веб-сервере.
В случае, если в веб-приложении предусматривается возможность внесения изменений пользователем в принадлежащий ему профиль, то эти изменения необходимо подтверждать дополнительной процедурой аутентификации.
Запретить использование заголовка REFERER в качестве основного механизма авторизации.
Для построения SQL-запросов необходимо использовать параметризованные запросы (например, хранимые процедуры). В случае отсутствия такой возможности, организовать процедуру предварительной обработки получаемых от пользователя данных (путем удаления метасимволов « ` – / *», а также следующих SQL-операторов: SELECT, UNION, ALTER, UPDATE, EXEC, DROP, DELETE и INSERT). 
Осуществлять преобразование HTML-кода входного потока данных следующим образом:
заменить символы < > на &ltи &gt; 
заменить символы () на &#40 и &#41; 
заменить символ # на &#35; 
заменить символ & на &#38.
Осуществлять фильтрацию входного потока данных (например, с использованием методов Server.HTMLEncode и HttpServerUtility.HTMLEncode в ASP и ASP.NET).
Запретить пользователю ввод данных, в которых допустимы HTML-теги <IMG> или <TABLE>.
При возникновении ошибки в веб-приложении запретить предоставлять следующую информацию в выводе сообщений об ошибках:
данные о структуре файловой системы (информация о версии ОС, директориях с системными файлами и системным программным обеспечением, включая пути к директориям и файлам);
фрагменты программного или конфигурационного кода;
сообщения об ошибках при передаче запросов в СУБД;
SQL-выражения, используемые при доступе к базе данных.
При обработке ошибок веб-сервером выдавать пользователю страницу-заглушку с кодом НТТР-ответа веб-сервера «200».
При прохождении процедуры аутентификации пользователей в веб-приложении должны использоваться защищенные протоколы Kerberos (в случае доменной аутентификации) или TLS v1.2 (и выше).
Передачу аутентификационных данных на веб-сервер осуществлять методом POST.
Исключить использование при обработке веб-сервером данных в формате XML внешних сущностей (External Entity), внешних параметров сущностей (External Parameter Entity) и внешних описаний типа документа (External Doctype), а также данных в формате JSON.
Запретить кеширование веб-форм ввода конфиденциальной информации. Выставить атрибут HTTPOnly у параметров cookie, значения которых не должны быть доступны сценариям, выполняемым браузером. У параметров cookie, содержащих чувствительную информацию, необходимо выставить атрибут Secure.
Проводить проверку корректности вводимых пользователем данных как на стороне клиента (с использованием сценариев, исполняемых браузером), так и на стороне сервера.
Использовать директивы в заголовках сообщений HTTP, определяющие применяемую кодировку. Исключить использование разных кодировок для разных источников входных данных.
Отказаться от использования на веб-ресурсах (в том числе веб-сайтах) компонентов и контента, подгружаемых с внешних, не контролируемых организацией, ресурсов.
В случае невозможности отказа от использования указанных компонентов и контента осуществлять их проверку на предмет вредоносного воздействия на отображаемую в браузерах пользователя информацию и возможность кражи аутентификационных данных и файлов-cookie пользователей. Далее осуществлять периодическую проверку их хэш-сумм. В случае изменения хэш-сумм – блокировать использование указанных компонентов и контента на веб-ресурсе и осуществлять их повторную проверку функциональности. В случае отсутствия потенциально вредоносного функционала – проводить дальнейшее сравнение по новой хэш-сумме.
Осуществлять периодическую проверку хэш-сумм используемых JavaScript. В случае изменения хэш-сумм отключать использование JavaScript на сайте и выполнять повторную проверку функциональности.
Отказаться от использования динамически формируемых кодов JavaScript на веб-ресурсе.
Отдавать предпочтение загрузке внешних зависимостей (JavaScript, CSS и др.) из контролируемых источников.
Разработать и поддерживать в актуальном состоянии планы реагирования на основные типы инцидентов:
DDoS-атака (сетевого уровня, прикладного уровня); 
дефейс сайта; 
несанкционированный доступ к интерфейсу управления; 
обнаружение утечки административных учетных данных, ключа или секрета; ⎯ обнаружение утечки пользовательских данных.
(обязательное)
Правила наименования серверов/оборудования в ЦОД ПК
Данные правила так же распространяются на наименование физического оборудования и виртуальных серверов, которые размещаются в Colocation ФОИВ, при условии, что они входят в состав ИС, размещаемой в Облаке ЦОД Ростелеком. 
Наименование серверов основывается на следующих принципах:
имя должно быть уникальным;
идентифицироваться принадлежность ВМ к ФОИВ;
идентифицироваться принадлежность к зоне и контуру безопасности, в которой размещается сервер;
идентифицировать принадлежность к ИС;
идентифицировать роль сервера в архитектуре ИС.
Ограничения в наименование серверов:
имя сервера может содержать только алфавитные символы (A-Z), численные символы (01-99) и знак минус (-);
максимальная длина имени сервера: 16 (20 для временных ВМ в целях проверки восстановления) символов. 
доменное имя сервера и имя сервера в vCenter Server должны быть одинаковыми.
Для наименования серверов используется следующий шаблон: XХX-YYY-ZZZ-TTN (XХX-YYY-ZZZ-TTNN-BRK),
где:
XXX – Принадлежность сервера к ФОИВ. Состоит из трех символов латинского алфавита.
YYY – Название зоны и контура безопасности, в которой размещается сервер. Состоит из двух символов латинского алфавита и символа O (Open)(ОК) или С (Closed)(ЗК).
ZZZ – Название ИС РТК ЦТ/ФОИВ/Заказчиков. Состоит из трех символов латинского алфавита.
TT – Назначение роли сервера (компонента/модуля) в ИС. Состоит из двух символов латинского алфавита.
NN – Номер по порядку. Применяется, если в составе ИС несколько серверов с одинаковой ролью (несколько одинаковых модулей/компонентов ИС). Состоит из одной или двух цифр от 1 до 99.
BR – Обозначение восстановленной ВМ из сохранённой ранее копии другой существующей ВМ с уже существующей ролью (Backup Recovery). 
K –Номер по порядку. Применяется, для обозначения восстановленных ВМ, из копии существующих ВМ, в случае если восстановленных копий ВМ несколько. Восстановленная ВМ, размещается только в том же контуре, той же зоне, в том же VLAN, в котором расположена существующая/оригинальная ВМ.
Примеры:
MER-PRO-SED-AP15 – Минэкономразвития России, Продуктивная зона, Открытый контур, Система электронного документооборота, сервер приложений номер 5.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
M
E
R
-
P
R
O
-
S
E
D
-
A
P
1
5
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
M
E
R
-
P
R
O
-
S
E
D
-
A
P
1
5
-
B
R
1
Перечень возможных сокращении, используемых в название серверов, приведены в Таблице И.1.
Таблица И. SEQ Таблица \* ARABIC 1 – Перечень сокращений, используемых в название серверов, размещаемых в Облаке Исполнителя
Код
Расшифровка кода
Возможные значения
Расшифровка значений
XХX
Принадлежность
сервера к ФОИВ
MPT
Минпромторг
RTZ
Ростуризм
MER
Минэкономразвития
RAK
Росаккредитация
RST
Росстандарт
FKU
Федеральное казенное учреждение
TEK
Технологические РТК ЦТ
FDN
Федеральное агентство по делам национальностей
RTR
Ростелеком
FAS
Федеральная антимонопольная служба
FMB
Федеральное медико-биологическое агентство 
FMS
Федеральный фонд обязательного медицинского страхования 
LSH
Рослесхоз
MHS
МЧС России
MPS
МинПросвет
MST
МинСпорт
PFR
Пенсионный фонд Российской Федерации
RSZ
Россельхознадзор
RSD
Роструд
RPN
Роспотребнадзор
RSR
Росреестр
RSS
Росстат 
MKS
Минцифраз
YYY
Название зоны
PRO
Продуктивная зона ИС Открытый контур
PRC
Продуктивная зона ИС Закрытый контур
PPO
Предпродуктивная зона ИС Открытый контур
PPC
Предпродуктивная зона ИС Закрытый контур
TTO
Зона разработки и тестирования ИС Открытый контур
PEO
Подготовительная зона ИС Открытый контур
PEC
Подготовительная зона ИС (Закрытый контур)
CHW
Colocation ФОИВ, зона серверного оборудования
CVM
Colocation ФОИВ, зона виртуальных ресурсов
CDS
Colocation ФОИВ, вычислительного оборудования (системы хранения данных)
CNT
Colocation ФОИВ, зона сетевого оборудования
ZZZ
Название ИС ФОИВ
Состоит из трех символов латинского алфавита
TT
Назначение роли сервера (компонента/модуля ИС)
AA
AAA-сервер (Общее название серверов, связанных с обеспечением защиты данных в информационных системах, включая обеспечение аутентификации, авторизации и аудита, но без обеспечения доступности данных (защиты от DOS-атак). )
AE
Сервер шлюза аутентификации ЕСИА
AG
Сервер шлюза доступа
AP
Сервер приложений
AS
ADFS сервер
AV
Сервер антивирусной защиты
BC
Сервер резервного копирования
BL
Сервер балансировки нагрузки
CA
Сервер сертификатов
CL
Кластер
DB
Сервер баз данных
DC
Контроллер домена
DS
DNS сервер
EL
ETL Steamsets сервер
EN
Encog ML (Сервер нейронной сети)
EX
Почтовый сервер (MS Exchange)
FG
FortiGate сервер
FS
Файловый сервер
FT
FTP сервер
GL
Graylog (управление записями структурированных и неструктурированных данных)
IS
Сервер интеграций
KC
Keycloak сервер
KK
Картографический сервер
KM
KMS сервер
LC
Сервер публикации и лицензирования RDS
LS
Сервер логирования
MG
Сервер миграции
MM
Сервер сервиса СМС
MO
Сервер мониторинга
MR
Mail Relay сервер
NS
NTP сервер
OL
OLAP сервер
PH
Сервер телефонии
PN
Сервер аутентификации 
PS
Сервер печати
PX
Прокси сервер
RD
Radius сервер (Сервер управления доступом)
RS
Radius сервер
SC
Сервер ИБ
SD
Сервер управления ИТ процессами
SF
SFTP сервер
SM
Сервер управления
SR
Серверы сопровождения
ST
Stream Сервер
TM
Сервер точного времени
TK
Сервер тонкого клиента
TS
Терминальный сервер
VI
SVC сервер (Видеокодирования)
WI
Сервер среды изоляции
WB
ВЕБ-сервер
NN
Номер по порядку
1-99
Применяется, если в составе ИС несколько серверов с одинаковой ролью (несколько одинаковых модулей/компонентов системы)
BR
Восстановленная ВМ
BR
Обозначения восстановленных ВМ, из копии существующих ВМ (Backup Recovery)
K
Номер по порядку
1-9
Номер по порядку. Применяется, для обозначения восстановленных ВМ, из копии существующих ВМ в случае, если восстановленных копий ВМ несколько.
(обязательное)
Размещение модулей/подсистем/серверов ИС по сегментам сети в зависимости от их функционального назначения
Распределение модулей/подсистем/серверов ИС по сегментам сети в зависимости от их функционального назначения приведено в таблице К.1.
Таблица К.1
№ п/п
Описание
Тип сетевого сегмента
Продуктивная зона ИС
1
Общий инфраструктурный (вспомогательный) сегмент для ИС ФОИВ – первый VLAN Продуктивной зоны ОК
Инфраструктур-ный ОК
ИС, которые не являются ГИС, ИСПДн или КИИ
2
Общий инфраструктурный сегмент для ИС, которые не являются ГИС, ИСПДн или КИИ – первый VLAN Продуктивной зоны ЗК
Инфраструктур-ный ЗК
3
Серверы «backend» каждой ИС, которая не является ГИС, ИСПДн или КИИ, располагаются в ЗК в отдельном сегменте Продуктивной зоны
Бэкенд ЗК
4
Серверы «frontend» недоступные в сети «Интернет» каждой ИС, которая не является ГИС, ИСПДн или КИИ, располагаются в ЗК в отдельном сегменте Продуктивной зоны
Внутренний
5
Серверы «frontend» доступные в сети «Интернет» каждой ИС и требующие доступа к сети «Интернет», которая не является ГИС, ИСПДн или КИИ, располагаются в ОК в общем сегменте Продуктивной зоны
Публичный
ИС, которые являются ГИС, ИСПДн или КИИ
6
Серверы доступные из сети «Интернет» каждой ИС, которая является ГИС, ИСПДн или КИИ, располагаются в ОК в отдельном сегменте Продуктивной зоны
Публичный
7
Серверы для взаимодействия с внешними организациями каждой ИС и требующие доступа к сети «Интернет», которая является ГИС, ИСПДн или КИИ, располагаются в ОК в отдельном сегменте Продуктивной зоны
Внешний
8
Серверы, обрабатывающие незащищаемую, общедоступную или статическую информацию и недоступные из сети «Интернет», и не взаимодействующие с сетью «Интернет» и другими ИС в сети «Интернет» каждой ИС, которая является ГИС, ИСПДн или КИИ, располагаются в ОК в отдельном сегменте Продуктивной зоны 
Бэкенд ОК
9
Серверы СУБД каждой ИС, которая является ГИС, ИСПДн или КИИ, располагаются в ЗК в отдельном сегменте Продуктивной зоны (сегмент СУБД)
СУБД
10
Серверы, обрабатывающие защищаемую информацию и недоступные из сети «Интернет», и не взаимодействующие с сетью «Интернет» и другими ИС в сети «Интернет», каждой ИС, которая является ГИС, ИСПДн или КИИ, располагаются в ЗК в отдельном сегменте Продуктивной зоны 
Внутренний
11
Серверы инфраструктуры каждой ИС, которая является ГИС, ИСПДн или КИИ, располагаются в ЗК в отдельном сегменте Продуктивной зоны
Инфраструктур-ный ЗК
12
Серверы резервного копирования каждой ИС, которая является ГИС, ИСПДн или КИИ, располагаются в ЗК в отдельном сегменте Продуктивной зоны
Резервное копирование ЗК
Предпродуктивная зона ИС
13
Общий инфраструктурный (вспомогательный) сегмент для ИС ФОИВ – первый VLAN Предпродуктивной зоны ИС ОК
Инфраструктур-ный ОК
ИС, которые не являются ГИС, ИСПДн или КИИ
14
Общий инфраструктурный сегмент для ИС, которые не являются ГИС, ИСПДн или КИИ – первый VLAN Предпродуктивной зоны ИС ЗК
Инфраструктур-ный ЗК
15
Копии серверов «backend» Продуктивной зоны каждой ИС, которая не является ГИС, ИСПДн или КИИ, располагаются в ЗК в отдельном сегменте Предпродуктивной зоны ИС
Бэкенд ЗК
16
Копии серверов «frontend» Продуктивной зоны ИС недоступные в сети «Интернет» каждой ИС, которая не является ГИС, ИСПДн или КИИ, располагаются в ЗК в отдельном сегменте Предпродуктивной зоны ИС
Внутренний
17
Копии серверов «frontend» Продуктивной зоны доступные в сети «Интернет» каждой ИС, которая не является ГИС, ИСПДн или КИИ, располагаются в ОК в общем сегменте Предпродуктивной зоны ИС
Публичный
ИС, которые являются ГИС, ИСПДн или КИИ
18
Копии серверов Продуктивной зоны ИС доступные из сети «Интернет» каждой ИС, которая является ГИС, ИСПДн или КИИ, располагаются в ОК в отдельном сегменте Предпродуктивной зоны ИС
Публичный
19
Копии серверов Продуктивной зоны, обрабатывающие незащищаемую, общедоступную или статическую информацию и недоступные из сети «Интернет», и не взаимодействующие с сетью «Интернет» и другими ИС в сети «Интернет» каждой ИС, которая является ГИС, ИСПДн или КИИ, располагаются в ОК в отдельном сегменте Предпродуктивной зоны ИС
Бэкенд ОК
20
Копии серверов СУБД Продуктивной зоны каждой ИС, которая является ГИС, ИСПДн или КИИ, располагаются в ЗК в отдельном сегменте Предпродуктивной зоны ИС
СУБД
21
Копии серверов приложений Продуктивной зоны каждой ИС, которая является ГИС, ИСПДн или КИИ, располагаются в ЗК в отдельном сегменте Предпродуктивной зоны ИС
Внутренний
22
Копии серверов инфраструктуры Продуктивной зоны каждой ИС, которая является ГИС, ИСПДн или КИИ, располагаются в ЗК в отдельном сегменте Предпродуктивной зоны ИС
Инфраструктур-ный ЗК
23
Копии серверов резервного копирования Продуктивной зоны каждой ИС, которая является ГИС, ИСПДн или КИИ, располагаются в ЗК в отдельном сегменте Предпродуктивной зоны ИС (сегмент backup)
Резервное копирование ЗК
Зона разработки и тестирования ИС
Сегменты ИС
24
Серверы каждой ИС располагаются в ОК в отдельном сегменте Зоны разработки и тестирования ИС
Публичный или Бэкенд ОК
Рисунок К.1 – Пример схемы размещения модулей по сегментам сети
(обязательное)
Организация удаленного доступа администратору ИС и пользователей
Общие сведения по организации УД администраторов ИС
Более подробно информация представлена в документе «Инструкция по организации удаленного доступа администратору ИС».
Общие принципы обеспечения УД администраторов ИС
Для получения УД к ИС в инфраструктуре ПК администратор должен иметь:
VPN-клиент с действующей лицензией.
Файл-контейнер с конфигурацией и ключевой информацией для VPN-клиента.
Учетную запись на терминальном (-ых) сервере (-ах), через который осуществляется доступ к ресурсам в Облаке ПК.
Доступы к ВМ по протоколам/портам отличным от предусмотренных по умолчанию.
Администратор устанавливает на своем АРМ VPN-клиент. Администратор может подключиться к инфраструктуре ПК через VPN-сервер инфраструктуры ПК.
Для УД администраторов к ВМ (серверам ИС), размещенных в Облаке ПК, предусмотрено по два терминальных сервера для каждого ФОИВ:
Терминальный сервер сегмента «Colocation» и Зоны разработки и тестирования ИС Облака (далее – ТС Colocation), предназначенный для доступа к соответствующих зонам.
Терминальный сервер для Продуктивной, Предпродуктивной и Подготовительной зон ИС (далее – ТС Продуктивной зоны).
Все действия администратора, осуществляемые с ТС Продуктивной зоны, фиксируются в PAM (SafeInspect).
После авторизации на ТС администратору открыт доступ по протоколам/портам, предусмотренным по умолчанию: для доступа к Windows-серверам – TCP порт 3389, к Linux-серверам – TCP порт 22. Если требуется доступ по другим портам или протоколам, то он запрашивается дополнительно. На ТС устанавливается только ПО, которое позволяет установить сетевое соединение до серверов ИС (RDP клиент, SSH клиент и веб-интернет-браузер). На ТС не допускается установка специализированного ПО, необходимого для непосредственного управления, администрирования ИС.
Схема организации удаленного доступа
Удаленный доступ администраторов ИС ФОИВ осуществляется через защищенную ViPNet сеть 14218. При этом для доступа к целевым серверам ИС ФОИВ используются терминальные серверы. Терминальный сервер обеспечивает доступ администраторов к ИС ФОИВ, находящимся в их зоне ответственности. Терминальный сервер не является полноценным рабочим местом администратора ИС ФОИВ и не предусматривает установку ПО, необходимого для работы в терминальной сессии с инфраструктурой ИС, размещенной в ЦОД. Общая схема организации УД приведена на рисунке Л.1.
Рисунок Л.1 – Общая схема организации удаленного доступа администратором ИС ФОИВ
Общая последовательность действий при организации УД
Для организации (подключение, отключение, изменение параметров) удаленного доступа администратора ИС ФОИВ необходимо выполнить следующие действия:
(При отсутствии лицензии на ПО ViPNet) подрядной организации обратиться в ФОИВ за получением лицензии на ПО ViPNet Client или приобрести лицензию для подключения к защищаемой ViPNet сети.
Подать через ответственного в ФОИВ необходимые заявки:
заявка на VPN-доступ, 
заявка на предоставление доступа администраторов к ИС ФОИВ,
заявка на организацию информационного взаимодействия между ТС и ВМ ИС.
Результатом исполнения заявок будет получение следующего:
по заявке на VPN-доступ – файл-контейнер с конфигурацией и ключевой информацией для работы с ПО ViPNet Client,
по заявке на предоставление доступа администраторов к ИС ФОИВ – логин и пароль для авторизации на ТС и в ОС на ВМ ИС.
по заявке на организацию информационного взаимодействия – открываются запрашиваемые сетевые взаимодействия.
(При необходимости) установить ПО ViPNet Client на АРМ администратора. 
Описание действий при организации удаленного доступа администраторам ИС
Мероприятия по получению лицензии для подключения к VPN сети на базе ViPNet
Для удаленного доступа администраторов к ИС ФОИВ, можно использовать следующие виды лицензий для подключения:
лицензия, для подключения к защищенной ViPNet сети ПК – ViPNet-сеть 14218.
лицензия, для подключения к защищенной ViPNet сети ФОИВ, в случае интеграции ViPNet-сети ФОИВ и ViPNet-сети 14218 (ViPNet-сеть ПК).
Действия для получения лицензии для подключения к ViPNetсети 14218
Владельцем ViPNet-сети 14218 является Исполнитель.
Варианты получения лицензии для подключения к защищенной ViPNet-сети 14218:
приобретает ФОИВ; 
приобретает самостоятельно администратор ИС ФОИВ (подрядная организация ФОИВ, разрабатывающая или обслуживающая ИС).
Количество лицензий должно соответствовать количеству администраторов ИС, для которых запрашивается УД.
Если приобретение лицензии осуществляется через ФОИВ, то лицензию для подключения к защищенной ViPNet-сети 14218 получает и выдает сотрудник ФОИВ, ответственный за ИБ/ИТ в ФОИВ.
При самостоятельном приобретении требуется разрешение от владельца ViPNetсети 14218., Исполнителя (ПАО «Ростелеком»). Запрос на получение разрешения оформляется с помощью формирования и регистрации ЗНО (Запрос на обслуживание). Для формирования и регистрации ЗНО необходимо отправить сообщение по электронной почте в адрес сервисной службы ПК HD@RTK-IT.RU или service@rtk-it.ru сотрудником ФОИВ, ответственным за ИБ/ИТ в ФОИВ.
Действия для получения лицензии для подключения к ViPNet сети 14218, но с использованием лицензии от ViPNet сети ФОИВ
Удаленный доступ администраторов ИС к облачным ресурсам ПК, осуществляется исключительно через ViPNet-сети 14218 Исполнителя.
Но если у ФОИВ существует своя защищённая сеть и ФОИВ выполнил интеграцию своей защищенной ViPNet-сети и защищенной ViPNet-сети 14218 Исполнителя, то администратор ИС для удаленного доступа может использовать лицензию от защищенной ViPNet-сети ФОИВ. 
После согласования сотрудниками ФОИВ заявки на «предоставление доступа администратора к ИС», лицензию можно получить у ответственного за ИБ/ИТ ФОИВ или приобрести самостоятельно.
Если администратор ИС, планирует самостоятельное приобретение лицензии для подключения к защищенной сети ViPNet-сети ФОИВ, то ему необходимо получить письменное согласование ФОИВ.
Получение файла-контейнера с конфигурацией и ключевой информацией для работы с ПО ViPNet Client
Для получения файла-контейнера с конфигурацией и ключевой информацией необходимо подать заявку через ответственного за ИБ/ИТ ФОИВ.
Исполнитель предоставляет доступ к защищенной ViPNet сети 14218, на основе полученных заявок от ФОИВ.
Исполнитель передает сотруднику ФОИВ, ответственному за ИБ/ИТ в ФОИВ, всю необходимую информацию для удаленного подключения администраторов ИС.
Выдача и учет ранее выданных файл-контейнеров с конфигурацией и ключевой информацией для работы с ПО ViPNet Client находится в зоне ответственности ФОИВ.
Первичное получение удаленного доступа администратором ИС через защищённую ViPNet-сеть
В случае, если удаленный администратор ранее не имел доступ в защищенную сеть ViPNet, то ему необходимо выполнить следующие действия:
Получить у сотрудника ФОИВ, ответственного за ИБ, файл-контейнер с конфигурацией и ключевой информацией для работы с ПО ViPNet Client.
Использовать защищенное подключение с помощью ПО ViPNet Client при доступе посредством публичной сети «Интернет» к терминальным серверам ФОИВ для администрирования целевых серверов ИС ФОИВ.
Действия администратора ИС, имеющего подключение к ViPNet-сети ФОИВ
В случае, если удаленный администратор уже включен в какую-либо стороннюю защищенную сеть ViPNet ФОИВ, то ему необходимо выполнить следующие действия:
Обратиться к сотруднику ФОИВ, ответственному за ИБ/ИТ. 
Сотрудник ФОИВ, ответственный за ИБ/ИТ связывается с администратором защищенной ViPNet сети ФОИВ и уточняет информацию о наличии интеграции защищенной ViPNet сети ФОИВ и защищенной ViPNet сети 14218.
В случае наличия интеграции защищенной ViPNet сети ФОИВ и защищенной ViPNet сети 14218 – получить обновления справочников и ключей по защищенной сети ViPNet. Если получить обновления по защищенной сети ViPNet не удается, то необходимо получить у сотрудника ФОИВ или администратора сторонней защищенной сети файл-контейнер с обновленной конфигурацией и ключевой информацией для работы с ПО ViPNet Client.
В случае отсутствия интеграции защищенной ViPNet сети ФОИВ и защищенной ViPNet сети 14218 – необходимо приобрести лицензию для работы с защищенной ViPNet сетью 14218.
Использовать защищенное подключение с помощью ПО ViPNet Client при доступе посредством публичной сети «Интернет» к терминальным серверам ФОИВ для администрирования целевых серверов ИС ФОИВ.
Организация доступа администраторов к ИС ФОИВ
Заявка на организацию доступа для администраторов к ИС ФОИВ подается представителем ФОИВ, являющимся владельцем ИС, к которой организуется доступ. Заявка заполняется одна – на каждую подрядную организацию, выполняющую функции администрирования ИС.
Заполнение заявки на доступ администратора к ИС
Заявки на организацию доступа для администраторов к ИС ФОИВ необходимо получить следующие данные о сотруднике, которому наделяются права администратора ИС ФОИВ:
Фамилия имя отчество сотрудника, для которого запрашивается доступ.
Роль сотрудника при взаимодействии с ИС: администратор, разработчик, тестировщик.
Контактный телефон для оперативного взаимодействия в случае возникновения вопросов или нештатных ситуаций.
Уровень доступа, который требуется сотруднику для работы, например, Полный, Чтение/запись, Чтение и др.
Наименование организации или отдела, в которой работает сотрудник.
Действие, которое необходимо сделать по организации доступа: добавить, удалить или изменить удаленной доступ администраторам
Согласование заявки с ответственным за ИС в ФОИВ
Отправить оформленную заявку ответственному за ИС в ФОИВ. 
Сотрудник ФОИВ, ответственный за ИС в ФОИВ, проверяет правомерность предоставления доступа к ИС.
Сотрудник ФОИВ, ответственный за ИБ/ИТ в ФОИВ консолидирует/получает все заявки по доступу к ИС ФОИВ.
Регистрация заявки в сервисной службе ПК
Сотрудник ФОИВ, формируют и регистрирует ЗНО (Запрос на обслуживание), путем отправки оформленной и согласованной, с ответственным за ИБ/ИТ в ФОИВ, заявки в адрес сервисной службы ПК на адрес hd@rtk-it.ru или service@rtk-it.ru. 
Результатом выполнения заявки является предоставление RDP-доступа из ViPNet сети 14218 к терминальному серверу ФОИВ 10.ХХХ.255.13 для Продуктивной и Предпродуктивной зон ИС, и/или 10.ХХХ.255.11 для сегмента «Colocation» и Зоны разработки и тестирования ИС, создаются персонифицированные учётные записи пользователей в домене и наделяются правами доступа, согласно данным в заявке.
Формат учетной записи (логина) для входа на терминальный сервер
При доступе на терминальный сервер администратором используются следующий формат учетной записи (логин):
на терминальном сервере сегмента «Colocation» и Зоны разработки и тестирования ИС (IP-адрес: 10.ХХХ.255.11)
логин: “epk-opn.local\«user»”, где «user» – имя доменной учетной записи, которые создает в рамках выполнения заявки на предоставление доступа пользователей к ИС ФОИВ;
на терминальном сервере Продуктивной зоны в ОК и ЗК (IP-адрес: 10.ХХ.255.13)
логин: “epk.local\«user»@10.ХХ.255.13”, где «user» – имя доменной учетной записи, которые создает в рамках выполнения заявки на предоставление доступа пользователей к ИС ФОИВ.
Заполнение заявки на организацию информационного взаимодействия для администрирования ИС 
Для администрирования ИС открывается доступ по протоколам/портам, предусмотренным по умолчанию: для доступа к Windows-серверам – TCP порт 3389, к Linuxсерверам – TCP порт 22. Если требуется доступ по другим портам или протоколам, то заполняется заявка на организацию сетевого информационного взаимодействия между Терминальным сервером и ИС/ГИС. 
Заявка заполняется на каждую обслуживающую организацию и на каждую ИС отдельно. Если требуется предоставить доступ к одной ИС для нескольких администраторов, то рекомендуется использовать одну заявку.
Заполнение заявки на организацию информационного взаимодействия для администрирования ИС
В заявке на организацию информационного взаимодействия для администрирования ИС, указывается следующая информация
Фамилия имя отчество заявителя, оформившего заявку.
Название организации, которая запрашивает внесение изменений в информационное взаимодействие ИС.
Электронная почта и контактный телефон заявителя для оперативного взаимодействия в случае возникновения вопросов или нештатных ситуаций.
Тип заявки: «Предоставить доступ/ Изменить доступ/ Продлить доступ/ Отозвать доступ».
Описание задачи, в рамках которой запрашивается предоставление/ изменение доступа.
Срок предоставления доступа: Постоянный / до указанной даты.
Указание на терминальный сервер: ТС Продуктивной зоны или ТС Colocation.
Наименование ИС.
Зона размещения ИС: сегмент «Colocation», Зона разработки и тестирования ИС, Продуктивная зона ИС, Предпродуктивная зона ИС, Открытый/Закрытый контур.
Направление информационного обменам – указывается какая ИС инициирует информационный обмен между модулями сопрягаемых ИС.
Техническая спецификация доступа (данные предоставляет организация, обслуживающая ИС). Указываются для всех администраторов обслуживающей организации без персонификации, то есть в общем виде. Предоставляются следующие сведения:
IP-адрес источника (инициатора соединения/информационного взаимодействия). В Данном случае это IP-адрес терминального сервера ФОИВ: 10.ХХХ.255.13, в Продуктивной и Предпродуктивной зонах ИС и 10.ХХХ.255.11 в сегменте «Colocation» и Зоне разработки и тестирования ИС; 
IP-адрес назначения (к кому происходит соединение/информационное взаимодействие)
протоколы и порты, по которым производится информационное взаимодействие;
описание, для чего необходимо данное информационное взаимодействия. Если запрашиваются не стандартные порты, то необходимо указать обоснование такого доступа. Например, администрирование серверов, отправка почтовые сообщение с системы мониторинга.
Доступ администраторов ИС до серверов ИС, осуществляется с ТС. ТС является одним из элементов Системы контроля действий привилегированных пользователей. Поэтому на ТС устанавливается только ПО, которое позволяет установить сетевое соединение до серверов ИС (RDP- клиент, SSH- клиент и веб-интернет браузер). На ТС не допускается установка специализированного ПО, необходимого для непосредственного управления, администрирования ИС. 
Разъяснения по дополнительным информационным взаимодействиям:
 Для доступа к серверам, под управлением Windows Server нужен только порт 3389 для RDP.
Для доступа к серверам, под управлением Linux нужен только порт 22 для SSH подключения.
Если для администрирования ИС осуществляется через интернет браузер, то доступ нужен запрашивать только по портам 80/8080/443. 
Если для администрирования ИС осуществляется через «нестандартный» порт, то необходимо указать порт и дать описание/обоснование, например: 
«TCP Port 8551 – веб интерфейс для администрирования ИС, т.к. на стандартном порту 443 доступен пользовательских интерфейс ИС или данный порт является стандартным для ИС, согласно документации к ИС, с которой можно ознакомиться на таком-то веб сайте разработчика и в проектной документации, которая была передана в ФОИВ согласно ГК номер».
Согласование заявки с ответственным за ИБ в ФОИВ
Отправить оформленную заявку ответственному за ИБ и ИС в ФОИВ. Если в ФОИВ нет ответственного за ИБ, то отправить заявку ответственному за ИТ в ФОИВ.
Сотрудник ФОИВ, ответственный за ИБ/ИТ в ФОИВ консолидирует/получает все заявки по доступу к ИС ФОИВ.
Сотрудник ФОИВ, ответственный за ИС в ФОИВ, проверяет необходимость информационного взаимодействия ИС и контролирует, что организация, разрабатывающая или обслуживающая ИС, внесла необходимые изменения в документацию по ИС.
Сотрудник ФОИВ, ответственный за ИБ/ИТ в ФОИВ согласовывает доступ или отказывает.
Регистрация заявки в сервисной службе ПК
Сотрудник ФОИВ ответственный за ИС отправляет согласованную с ответственным за ИБ/ИТ в ФОИВ, заявку на адрес сервисной службы ПК HD@RTK-it.ru или service@rtk-it.ru. 
Результатом выполнения заявки является предоставление доступа с терминального сервера ФОИВ до серверов ИС согласно данным в заявке.
Отслеживание статуса выполнение заявки на организацию удаленного доступа администраторам ИС
Последовательность действий:
После отправки заявок на адрес HD@RTK-it.ru или service@rtk-it.ru, представитель ФОИВ – инициатор (далее инициатор заявки), получает номера заявок от системы регистрации заявок Исполнителя.
Уведомления о статусе заявки приходит на почту инициатора заявки.
Если по заявке есть технические вопросы от исполнителей ответственных за ИБ, то заявка переходит в статус приостановлено. Вопросы по заявке через сервисную службу ПК адресуются инициатору заявки, для уточнения данных в заявке. По необходимости инициатор заявки дорабатывает заявку, уточняет детали сразу или берёт время на доработку. Статус заявки остаётся «Приостановлено».
После решения и доработки заявки, исправленная версия заявки отправляется на согласование ответственному за ИБ/ИТ в ФОИВ и исполнителю по заявке, после чего инициатор заявки отвечает на письмо о приостановке заявки (с обязательным указанием темы с идентификатором заявки) и прикладывает к письму доработанную заявку.
Как только доступ будет настроен и предоставлен, инициатору заявки приходит уведомление о выполнении заявки.
Администратор ИС проверяет доступ через ViPNet клиент к терминальному серверу с помощью предоставленной учётной записи.
Администратор ИС проверяет доступ с терминального сервера до серверов ИС ФОИВ по запрошенным протоколам и портам.
В случае выявления проблем с подключением к терминальному серверу через защищенную часть ViPNet администраторы ИС обращаются напрямую в службу поддержки ФОИВ через ответственного за ИБ/ИТ в ФОИВ (инициатора заявки). 
В случае выявления отсутствия доступа с терминального сервера к серверам ИС, администраторы обращаются в ФОИВ. Представитель ФОИВ – инициатор заявки, возвращает заявку на доступ в работу с обязательным указанием идентификатора заявки в теме письма.
Требования к пользовательскому устройству для организации защищенного удаленного доступа 
Для подключения к услуге «Защищенный удаленный доступ» пользователь должен иметь оборудование и ПО, соответствующие следующим ниже требованиям. 
Минимальные требования к пользовательскому устройству зафиксированы в таблице 
Параметр
Значение
CPU
Не менее 2 GHz dual-core
RAM
Не менее 2 GB
Video *
AMD: R100, RV100, RS100, RV200, RS200, RS250, R200, RV250, RV280, RS300, RS350, RS400/RS480, R300, R350, R360, RV350, RV360, RV370, RV380, RV410, R420, R423/R430, R480/R481, RV505/RV515/RV516/RV550, R520, RV530/RV560, RV570/R580, RS600/RS690/RS740, R600, RV610/RV630, RV620/RV635, RV670, RS780/RS880, RV710/RV730, RV740/RV770/RV790, CEDAR, REDWOOD, JUNIPER, CYPRESS, HEMLOCK, PALM, SUMO/SUMO2, BARTS, TURKS, CAICOS, CAYMAN, ARUBA, TAHITI, PITCAIRN, VERDE, OLAND, HAINAN, BONAIRE, KABINI, MULLINS, KAVERI, HAWAII.
Intel: i810, i815, i830, i845, i855, i865, i915, i945 and i965 series chips
NVIDIA GPU product: GeForce GTX 480, GeForce GTX 465, GeForce GTX 480M, GeForce GTX 470, Tesla, C2050 / C2070, Tesla C2050, Tesla C2070, Tesla M2070, Tesla X2070, Quadro 6000, Quadro 5000, Quadro 5000M, Quadro 4000, Tesla T20 Processor, Tesla S2050, Tesla M2050, Tesla M2070-Q, GeForce GT 440, GeForce GTS 450, GeForce GT 555M, GeForce GTX 460M, GeForce GT 445M, GeForce GT 435M, GeForce GT 550M, Quadro 2000, Quadro 2000D, Quadro 2000M, GeForce GT 430, GeForce GT 420, GeForce GT 635M, GeForce GT 520, GeForce GT 530, GeForce GT 610, GeForce GT 620M, GeForce GT 630M, GeForce GT 640M LE, GeForce 610M, GeForce 615, GeForce GT 525M, GeForce GT 520M, GeForce GT 415M, NVS 5400M, GeForce GT 425M, GeForce GT 420M, GeForce GT 540M, Quadro 600, Quadro 500M, Quadro 1000M, NVS 5200M, GeForce GTX 460, GeForce GTX 460 SE, GeForce GTX 470M, GeForce GTX 485M, Quadro 3000M, Quadro 4000M, GeForce GT 630, GeForce GT 620, GeForce GT 730, GeForce 510, GeForce 605, GeForce GT 625 (OEM), GeForce GT 625, GeForce GT 705, GeForce GT 520MX, GeForce 410M, NVS 4200M, GeForce 610, GeForce 800A, GeForce 705A, GeForce 705M, NVS 315, NVS 310, GeForce GTX 580, GeForce GTX 570, GeForce GTX 560 Ti, GeForce GTX 560, GeForce GTX 590, Tesla M2090, Tesla X2090, Tesla M2075, Tesla C2075, Quadro 5010M, Quadro 7000, GeForce 820M, GeForce GT 720M, GeForce 710M, GeForce 810M, GeForce GT 625M, GeForce GT 720A, GeForce 710A, GeForce GT 710M, GeForce 720M, GeForce 620M, GeForce GT 820M ,GeForce 820A ,GeForce 720A, GeForce 800M, GeForce GTX 560, GeForce GTX 460, GeForce GTX 555, GeForce GT 645, GeForce GTX 570M, GeForce GTX 580M, GeForce GTX 675M, GeForce GTX 670M, GeForce GT 545, GeForce GTX 550, GeForce GT 640, GeForce GTX 560M
USB
как минимум один свободный порт USB
USB-токен
JaCarta PRO, Рутокен S, Рутокен lite, Рутокен ЭЦП
eToken PRO
* при использовании видеокарты, не соответствующей требованиям, возможно пониженное разрешение (не менее 1024х768).
Требования к домашнему ПК с операционной системой (ОС) Windows
Требования обеспечиваются Заказчиком, либо его сотрудниками.
Требования к аппаратной части 
Процессор – тип x86 или x86-64 с частотой более 1 ГГц с поддержкой инструкций SSE2
Intel – не младше Pentium 4 (т.е. выпуска не ранее 2001 года)
AMD – не младше Athlon 64 (т.е. выпуска не ранее 2004 года)
Память (ОЗУ) – не менее 2 ГБ
Жёсткий диск – от 150 МБ свободного места
Видеокарта – с поддержкой Direct3D 11 (т.е. выпуск после 2008 года) 
Наличие USB-порта
Требования к версии ОС Windows
Windows 10 (32-bit или 64-bit) Home, Pro, Pro for Workstations, Enterprise
Windows 8 или 8.1 (32-bit или 64-bit) Pro, Enterprise
Windows 7 SP1 (32-bit или 64-bit) Home, Enterprise, Professional
Требования к домашнему ПК с ОС MacOS 
Требования обеспечиваются Заказчиком, либо его сотрудниками.
Требования к аппаратной части 
Модель 64-bit Intel-based Mac
Память (ОЗУ) – не менее 2 ГБ
Жёсткий диск – от 150 МБ свободного места
Наличие USB-порта
Требования к версии ОС MacOS
macOS High Sierra (10.13) 
macOS Mojave (10.14) 
macOS Catalina (10.15)
Требования к домашнему ПК с ОС Linux
Требования обеспечиваются Заказчиком, либо его сотрудниками.
Требования к аппаратной части 
Архитектура процессора - i386, x86_64, ARM
Память (ОЗУ) – не менее 2 ГБ
Жёсткий диск – от 150 МБ свободного места
Наличие USB-порта
Требования к версии ОС Linux
Ubuntu 32-bit версия 16.04
Ubuntu 64-bit версия 16.0.4, 18.04
Red Hat Enterprise Linux (RHEL) 64-bit 7.7, 8
Требования к ПО на домашнем ПК любого типа 
Требования обеспечиваются Заказчиком, либо его сотрудниками.
Должно быть установлено сертифицированное СЗКИ:
VPN клиент КриптоПро NGate (на базе CryptoPro CSP версии 5.0 и выше)
Должна быть установлена лицензионная антивирусная программа от следующих производителей: 
Лаборатория Касперского;
ДокторВЕБ.
Допускается временное (не более 1 месяца) использование только:
ESET NOD32;
Symantec Endpoint Protection,
подключённые к сайтам производителя, получающие обновления вирусных баз.
Использование иных антивирусных средств при подключении к информационным ресурсам Правительственного комплекса не допускается.
(обязательное)
Порядок восстановления при проверке целостности объектов резервного копирования информационных систем ФОИВ в Облаке ЦОД Правительственного комплекса
Общие положения
Согласно требованиям регулирующих органов, каждая ИС ФОИВ должна иметь следующие согласованные и утверждённые документы:
Порядок резервного копирования и восстановления данных из резервных копий; 
Процедура проверки целостности и возможности восстановления данных.
Данные документы должны быть разработаны с учетом требований настоящего ТУ.
Приложение описывает следующие составляющие процесса проверки целостности объектов резервного копирования информационных систем ФОИВ в Облаке ЦОД ПК с использованием услуги «Услуга управления резервным копированием в Облаке ЦОД ПК»:
состав и порядок взаимодействия участвующих сторон;
порядок восстановления данных и ВМ ИС в Облаке ЦОД ПК; 
состав и последовательность действий при выполнении мероприятий по контролю целостности.
Участвующие стороны процесса проверки целостности:
ФОИВ;
подрядная организация ФОИВ, разрабатывающая или обслуживающая ИС (далее – Подрядная организация);
Исполнитель.
Объектами резервного копирования являются разделы файловых систем (диски, папки, отдельные файлы) и виртуальные машины на ресурсах Облака ЦОД ПК. 
Общий порядок взаимодействия при подготовке к проверке целостности резервных копий ИС
При размещении (модернизации) ИС ФОИВ в Облаке ЦОД ПК для организации резервного копирования и восстановления данных устанавливается следующий порядок взаимодействия.
Подрядная организации ФОИВ, по результатам выполнения работ на разработку, модернизацию, размещение или обслуживание/поддержку ИС в Облаке ПК, разрабатывает или актуализирует/дорабатывает следующие документы с учётом требований настоящего ТУ:
Порядок резервного копирования и восстановления данных из резервных копий; 
Процедура проверки целостности и возможности восстановления данных.
ФОИВ и его сотрудники, ответственные за ИС/ИТ/ИБ проверяют и согласовывают разработанные выше документы.
ФОИВ и Подрядные организации ФОИВ отвечают за подготовку и подачу заявок на выполнение резервного копирования данных и ВМ ИС в Облаке ПК в случае использования услуги «Услуга управления резервным копированием в Облаке ЦОД ПК».
Порядок взаимодействия при проведении проверки целостности резервных копий ИС
Порядок взаимодействия при проведении проверки целостности резервных копий ИС в Облаке ЦОД ПК и работах, связанных с восстановлением объектов резервного копирования (данных и ВМ) в Облаке ЦОД ПК с использованием услуги «Услуга управления резервным копированием в Облаке ЦОД ПК».
При эксплуатации (сопровождении) ИС ФОИВ в Облаке ЦОД для выполнения мероприятий проверки целостности данных ИС, устанавливается следующий порядок взаимодействия. 
ФОИВ перед выполнением мероприятий по проверке целостности данных ИС:
информирует Подрядную организацию ФОИВ о необходимости проверки целостности резервных копий ИС.
Подрядная организация для организации выполнения мероприятий по проверке целостности данных ИС:
разрабатывает план работ по проверке целостности резервных копий ИС, согласно документу «Процедура проверки целостности и возможности восстановления резервных копий»;
определяет и согласовывает дату/время выполненной резервной копии, на данных которой предполагается выполнение работ по проверки целостности; 
при использовании «Услуги управления резервным копированием», формирует «Заявку на восстановление объектов резервного копирования»; 
формирует «Заявку на организацию информационного взаимодействия ИС/ГИС». 
формирует «Заявку на вычислительные ресурсы и ОС»;
разрабатывает/актуализирует схему внутреннего взаимодействия восстановленных ВМ;
разрабатывает/актуализирует схему доступа пользователей, которые участвуют в тестирование, и администраторов ИС.
ФОИВ для организации выполнения мероприятий по проверке целостности данных ИС:
согласовывает план работ по проверке целостности данных ИС;
согласовывает дату/время выполненной резервной копии, на данных которой предполагается выполнение работ по проверки целостности резервных копий;
согласовывает сроки проведения работ по проверке целостности данных ИС;
согласовывает разработанные/актуализированные схемы;
согласовывает заявки:
на «Восстановление объектов резервного копирования»;
на «Организацию информационного взаимодействия ИС/ГИС»;
на «Вычислительные ресурсы и ОС»;
формирует и регистрирует ЗНО (Запрос на обслуживание), путем отправки оформленных и согласованных, с ответственным за РК/ИБ/ИТ в ФОИВ заявок в адрес сервисной службы ПК на адрес hd@rtk-it.ru или service@rtk-it.ru:
Заявка на «Восстановление объектов резервного копирования»;
Заявка на «Вычислительные ресурсы и ОС»;
Заявка на «Организацию информационного взаимодействия ИС/ГИС».
.
Исполнитель в ходе выполнения мероприятий по проверке целостности данных ИС:
проверяет заявку на организацию информационного взаимодействия ИС/ГИС между восстановленными ВМ на соответствие ТУ;
проверяет подготовленные схемы на соответствие ТУ;
подготавливает, при необходимости, замечания к схемам и к заявкам «на организацию информационного взаимодействия ИС/ГИС», если они не соответствуют ТУ;
выполняет заявки:
на «Восстановление объектов резервного копирования»,
на «Вычислительные ресурсы и ОС», 
на «Организацию информационного взаимодействия ИС/ГИС»;
передает в ФОИВ таблицу соответствия имен восстановленных ВМ, IP-адресов и VLAN восстановленных машин.
Подрядная организация, после получения информации от ФОИВ о согласовании представленных схем:
в случае наличия, исправляет замечания к схемам и заявке на организацию информационного взаимодействия ИС/ГИС и повторно запускает процедуру согласования схем и заявок;
проверяет доступ к восстановленным ВМ, и доступ между ВМ;
настраивает логическую связность между модулями/компонентами ИС, в связи со сменой IP-адресов ВМ;
выполняет работы, согласно плану по проверке целостности данных ИС;
информирует ФОИВ о результатах завершения работ по проверке целостности данных ИС;
при успешном завершении проверки целостности резервных копий ИС формирует следующие заявки:
«Заявка на высвобождение вычислительных ресурсов и ОС» (удаление восстановленных ВМ);
«Заявка на изменение организации информационного взаимодействия ИС» (удаление правил межсетевого взаимодействия, между восстановленными ВМ);
при неуспешном завершении проверки целостности данных ИС:
проводит комплекс мероприятий по диагностике причин не успешной проверки целостности данных и готовит отчет;
предлагает ФОИВ другую дату/время выполненной резервной копии, на данных которой предполагается повторное выполнение работ по проверки целостности данных;
повторно выполняет мероприятия по проверке целостности данных ИС.
дорабатывает/актуализирует документы «Порядок резервного копирования и восстановления данных из резервных копий» и «Процедура проверки целостности и возможности восстановления данных», с учетом выявленных и исправленных ошибок при проведении работ по проверке целостности резервных копий ИС.
ФОИВ в ходе выполнения мероприятий по проверке целостности данных ИС:
при получении сообщения о наличии ошибок при выполнении проверки целостности резервных копий ИС, собирает рабочую группу в составе: Исполнителя, Подрядная организация ФОИВ, с целью локализации и устранения ошибок, которые приводят к невозможности успешно завершить проверку целостности восстановленных резервных копий ИС;
формирует и регистрирует ЗНО (Запрос на обслуживание), путем отправки оформленной и согласованной, с ответственным за РК/ИБ/ИТ в ФОИВ заявки в адрес сервисной службы ПК на адрес hd@rtk-it.ru или service@rtk-it.ru:
«Заявка на высвобождение вычислительных ресурсов и ОС» (удаление восстановленных ВМ);
«Заявка на изменение организации информационного взаимодействия ИС» (удаление правил межсетевого взаимодействия, между восстановленными ВМ).
Исполнитель проводит следующие мероприятия:
выполняет «Заявку на высвобождение вычислительных ресурсов и ОС» и «Заявку на изменение организации информационного взаимодействия ИС»;
при получении сообщения о наличии ошибок при выполнении резервного копирования, проводит диагностику работы системы резервного копирования в Облаке ЦОД ПК и информирует ФОИВ о результатах диагностики.
Условия и ограничения выполнения процедуры восстановления резервных копий для проверки целостности
Порядок восстановления ВМ ИС для проведения проверки целостности данных, должен быть приведен в документе «Процедура проверки целостности и возможности восстановления данных». 
При восстановлении резервных копий для проведения проверки целостности резервных копий используется подход создания копий ВМ ИС внутри Предпродуктивной зоны.
При создании копий ВМ ИС внутри Предпродуктивной зоны действуют следующие условия и ограничения:
имя ВМ не изменяется;
изменяется IP-адрес ВМ;
контур безопасности не изменяется;
изменяется VLAN восстановленной ВМ изменяется:
все копии ВМ ИС/ГИС в ОК восстанавливаются в один VLAN (отдельный сегмент для данной ИС/ГИС) ОК Предпродуктивной зоны (распределение восстановленных ВМ по VLAN отсутствует);
все копии ВМ ИС/ГИС в ЗК восстанавливаются в один VLAN (отдельный сегмент для данной ИС/ГИС) ЗК Предпродуктивной зоны (распределение восстановленных ВМ по VLAN отсутствует);
персональные и другие данные, требующие защиты на время проведения проверки целостности данных удалять с восстановленных ВМ не требуется;
для организации сетевого взаимодействия между копиями ВМ ИС (взаимодействие с другими ВМ ИС), необходимо предоставить Исполнителю:
схему внутреннего взаимодействия ИС;
схему доступа пользователей и администраторов;
матрицу межсетевого взаимодействия всех ВМ ИС. При этом доступ из сети Интернет к «копии ИС» не предоставляется. Доступ из ПК предоставляется только для ограниченного числа сотрудников ФОИВ, которые будут задействованы в процедуре тестирования целостности данных;
Подрядная организация вносит изменения в настройки ВМ, ОС и ПО с учетом изменения IP адреса и VLAN размещения ВМ;
Подрядная организация ФОИВ несет ответственность за возможный конфликт взаимодействия между модулями/компонентами при неполных/некоренных внесенных изменениях в ОС и ПО, связанных с изменением IP-адресов и VLAN;
максимальное время, которое могут работать восстановленные машины составляет 3-е суток (72 календарных часа) с момента выполнения заявки на восстановление данных из резервных копии. После этого времени восстановленные ВМ и правила информационного взаимодействия между ВМ удаляются. При необходимости работы восстановленных ВМ более продолжительное время, ФОИВ должен сформировать «Заявку на вычислительные ресурсы и ОС»;
Предоставляется только ограниченный пул вычислительных ресурсов на все ИС/ГИС всех ФОИВ В:
не более 64 vCPU
не более 128 Гб vRAM
не более 2 ТБ vHDD тип 1 (SATA)
диски vHDD тип 2 (SAS) и тип 3 (SSD) в рамках «Услуги управления резервным копированием в Облаке ЦОД ПК» не предоставляются.
при необходимости задействовать больший пул вычислительных ресурсов. необходимо сформировать «Заявка на вычислительные ресурсы и ОС»;
на все копии ВМ устанавливаются все требуемые сервисы ИБ, согласно требованиям ТУ.
(обязательное)
Организация почтовых рассылок и отправка электронных сообщений средствами ИС ФОИВ
ГИС/ИС может осуществлять почтовые рассылки и отправку почтовых сообщений, как с использованием почтового сервера Исполнителя (ПК) продуктивной зоны, так и с использованием почтового сервера ФОИВ из сегмента Colocation, при наличии такого. 
Обращение к почтовому серверу РТК (ЕПК) производится только по DNS-имени. IP-адреса почтовых серверов в явном виде могут использоваться только в диагностических целях (для просмотра логов и при отладке взаимодействия)
Отправка почтовых сообщений через почтовую систему ЕПК осуществляется от Email-адреса из следующих доменов:
epk.local – технологический, не маршрутизируемый (отправка писем возможна только внутри почтовой организации)
почтовый домен ФОИВ – у каждого ФОИВ свой почтовый домен. (Для использования необходимо согласование через ответственных лиц за ИТ в ФОИВ).
Отправка почтовых сообщений через почтовую систему ЕПК на адреса, включающие в себя внешних получателей, производится с использованием процедуры аутентификацией пользователя и протокола TLS, по порту 587. Учетная запись, под которой производится аутентификация, должна иметь права на почтовый ящик, указанный в поле «From» отправляемых писем. Так же необходимо учитывать, что в этом случае создаётся почтовый ящик, на который приходят отчёты о невозможности доставки, и возможно получение других почтовых сообщений (ответы от пользователей и т.д.). Рекомендуется следить за используемым объемом данного п/я или настроить автоматическую очистку, т.к. при превышении установленной квоты становится недоступна отправка и получение почтовых сообщений.
Отправка почтовых сообщений через почтовую систему ЕПК внутри почтовой организации (список доменов получателей приведён в пункте 3) возможна по упрощенной схеме, без шифрования и аутентификации. В этом случае, в качестве SMTP сервера следует указать mail.epk.local, порт 25, обратный адрес должен быть в домене @epk.local, ящика с таким адресом не должно существовать. При отправке сообщения в поле from должен быть адрес типа «название_ИС»@epk.local, но такой, чтобы реального ящика «название_ИС»@epk.local не существовало. Получать ответы от пользователей и отчёты о доставке в таком режиме невозможно.
Отправка почтовых сообщений через почтовую систему ЕПК на адреса внешних получателей возможна по упрощенной схеме, без шифрования и аутентификации. В этом случае, в качестве SMTP сервера следует указать mail.epk.local, порт 25. В почтовой системе ЕПК создается коннектор, осуществляющий пересылку почтовых сообщений внешним получателям от имени отправителя. Для использования данного взаимодействия требуется согласование с Солар.
Для создания коннектора, в заявке следует указать имя информационной системы и список ip-адресов серверов, с которых почта в такой конфигурации будет приниматься. Имя коннектора будет создано на усмотрение СЦ. 
Формат наименование коннектора – XXX_zzz 
где XXX-код ФОИВ, 
zzz – код ИС ФОИВ. 
Подробное описание кода ФОИВ и кода ИС приведено в Приложение И, в заявке должно быть указано, что отправка почты настраивается путём создания отдельного коннектора без аутентификации и шифрования.
Для настройки отправки почтовых сообщений через почтовую систему ЕПК в ЗК требуется соответствующий уровень компетенций Администратора прикладной системы (ИС) (минимум в части установки сертификатов и настройки в прикладном ПО задержек в отправке между письмами, в случае одновременного формирования большого количества писем).
Отправка и получение почтовых сообщений из ОК в сеть Интернет производится через почтовые шлюзы. Для домена epk.gov.ru развернуто два MX-сервера с сервисом SMTP Relay осуществляющие пересылку почтовых сообщений между почтовыми серверами ЕПК и внешними получателями. К внутренним IP-адресам MX-серверов подключается почтовые серверы ЕПК, с внешних IP- адресов производится отправка почтовых сообщений на внешние почтовые системы (в сети Интернет). Почтовые сообщения от внешних почтовых систем принимаются на внешний (публичный) IP-адрес MX-сервера. MX-сервер проверяет почтовые сообщения и ретранслирует их на внутренние IP-адреса. Отправка почтовых сообщений на внешние почтовые системы производится в обратном порядке. Для использования данного взаимодействия требуется согласование с Исполнителем. При использование почтового шлюза:
ФОИВ, подрядной организации ФОИВ в заявке необходимо указать: имя ИС/ГИС; адреса хостов ИС/ГИС, которые будут взаимодействовать с почтой; доменное имя (полное), для добавления в правила почтового шлюза. После формирования заявки формирует и регистрирует ЗНО (Запрос на обслуживание), путем отправки оформленной и согласованной, с ответственным за РК/ИБ/ИТ в ФОИВ заявки в адрес сервисной службы ПК на адрес hd@rtk-it.ru или service@rtk-it.ruдля создания коннектора на почтовых серверах и для создания правил на почтовом шлюзе.
Так же необходимо указание сетевого взаимодействия в Матрице сетевых взаимодействий, а именно, взаимодействие хостов ИС/ГИС (тех, что указываются в заявке, тех кто будет осуществлять формирование и пересылку почтовых пакетов) с почтовыми серверами ЕПК.
Со стороны подрядной организации ФОИВ, разрабатывающей или обслуживающей ИC необходимо взаимодействие с ФОИВ, в части подготовки (настройки) почтового сервера ФОИВ к приему писем с полем «From to» (как в заявке) от почтовых серверов ЕПК. 
Лист регистрации изменений
Изм.
Номера листов (страниц)
Всего
листов
(страниц)
в доку-менте
Номер
доку-мента
Входящий
номер сопроводи-тельного
документа
и дата
Подпись
Дата
изменен-ных
заменен-ных
новых
аннулиро-ванных
1
76
76
93
-
106
СМФР.
001-2022ИИ
21.
09.
2022

=== ФАЙЛ: Приложение 3 ТкС_СЭДО_р | docs/0173100008626000034/Приложение 3 ТкС_СЭДО_р.pdf
Приложение № 3 к Извещению
Требования к содержанию, составу заявки на участие в электронном аукционе
в соответствии со статьей 43 Федерального закона от 5 апреля 2013 г. № 44-ФЗ
«О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения
государственных и муниципальных нужд» (далее – Закон) и инструкция
по ее заполнению
1. Для участия в электронном аукционе заявка на участие в электронном аукционе, если
иное не предусмотрено Законом, должна содержать:
1) информацию и документы об участнике электронного аукциона:
а) полное и сокращенное (при наличии) наименование юридического лица, в том числе
иностранного юридического лица (если участником электронного аукциона является
юридическое лицо), аккредитованного филиала или представительства иностранного
юридического лица (если от имени иностранного юридического лица выступает
аккредитованный филиал или представительство), наименование обособленного подразделения
юридического лица (если от имени участника электронного аукциона выступает обособленное
подразделение юридического лица), фамилия, имя, отчество (при наличии) (если участником
электронного аукциона является физическое лицо, в том числе зарегистрированное в качестве
индивидуального предпринимателя);
б) фамилия, имя, отчество (при наличии), идентификационный номер налогоплательщика
(при наличии) и должность лица, имеющего право без доверенности действовать от имени
юридического лица, либо действующего в качестве руководителя юридического лица,
аккредитованного филиала или представительства иностранного юридического лица, либо
исполняющего функции единоличного исполнительного органа юридического лица;
в) идентификационный номер налогоплательщика (при наличии) членов коллегиального
исполнительного органа, лица, исполняющего функции единоличного исполнительного органа,
управляющего (при наличии), управляющей организации (при наличии), участников (членов)
корпоративного юридического лица, владеющих более чем двадцатью пятью процентами акций
(долей, паев) корпоративного юридического лица, учредителей унитарного юридического лица
или в соответствии с законодательством соответствующего иностранного государства аналог
идентификационного номера налогоплательщика таких лиц;
г) адрес юридического лица, в том числе иностранного юридического лица (если
участником электронного аукциона является юридическое лицо) в пределах места нахождения
юридического лица, адрес (место нахождения) аккредитованного филиала или
представительства на территории Российской Федерации (если от имени иностранного
юридического лица выступает аккредитованный филиал или представительство), адрес (место
нахождения) обособленного подразделения юридического лица (если от имени участника
электронного аукциона выступает обособленное подразделение юридического лица), место
жительства физического лица, в том числе зарегистрированного в качестве индивидуального
предпринимателя (если участник электронного аукциона является физическим лицом, в том
числе зарегистрированным в качестве индивидуального предпринимателя), адрес электронной
почты, номер контактного телефона;
д) копия документа, удостоверяющего личность участника электронного аукциона
в соответствии с законодательством Российской Федерации (если участник электронного
аукциона является физическим лицом, не являющимся индивидуальным предпринимателем);
 2
е) идентификационный номер налогоплательщика юридического лица (если участником
электронного аукциона является юридическое лицо), аккредитованного филиала или
представительства иностранного юридического лица (если от имени иностранного
юридического лица выступает аккредитованный филиал или представительство), физического
лица, в том числе зарегистрированного в качестве индивидуального предпринимателя (если
участником электронного аукциона является физическое лицо, в том числе зарегистрированное
в качестве индивидуального предпринимателя), аналог идентификационного номера
налогоплательщика в соответствии с законодательством соответствующего иностранного
государства (если участником электронного аукциона является иностранное лицо), код
причины постановки на учет юридического лица (если участником электронного аукциона
является юридическое лицо), аккредитованного филиала или представительства иностранного
юридического лица (если от имени иностранного юридического лица выступает
аккредитованный филиал или представительство), обособленного подразделения юридического
лица (если от имени участника закупки выступает обособленное подразделение юридического
лица);
ж) выписка из единого государственного реестра юридических лиц (если участником
электронного аукциона является юридическое лицо), выписка из единого государственного
реестра индивидуальных предпринимателей (если участником электронного аукциона является
индивидуальный предприниматель);
з) надлежащим образом заверенный перевод на русский язык документов
о государственной регистрации юридического лица или физического лица в качестве
индивидуального предпринимателя в соответствии с законодательством соответствующего
государства (если участником электронного аукциона является иностранное лицо);
и) декларация о принадлежности участника электронного аукциона к учреждению или
предприятию уголовно-исполнительной системы (если участник электронного аукциона
является учреждением или предприятием уголовно-исполнительной системы);
к) декларация о принадлежности участника электронного аукциона к организации
инвалидов, предусмотренной частью 2 статьи 29 Закона (если участник электронного аукциона
является такой организацией);
л) декларация о принадлежности участника электронного аукциона к социально
ориентированным некоммерческим организациям в случае установления преимущества,
предусмотренного частью 3 статьи 30 Закона;
м) решение о согласии на совершение или о последующем одобрении крупной сделки,
если требование о наличии такого решения установлено законодательством Российской
Федерации, учредительными документами юридического лица и для участника электронного
аукциона заключение контракта на поставку товара, выполнение работы или оказание услуги,
являющихся объектом закупки, либо внесение денежных средств в качестве обеспечения заявки
на участие в электронном аукционе, обеспечения исполнения контракта является крупной
сделкой;
н) информацию и документы, которые подтверждают соответствие участника
электронного аукциона требованиям, установленным пунктом 1 части 1 статьи 31 Закона (могут
не включаться в заявку на участие в электронном аукционе в случае, если указанные
информация и документы содержатся в открытых и общедоступных государственных реестрах,
размещенных в информационно-телекоммуникационной сети «Интернет», и в такую заявку
включена предусмотренная подпунктом «о» пункта 1 части 1 статьи 43 Закона декларация
о соответствии участника электронного аукциона требованиям, установленным пунктом 1
 3
части 1 статьи 31 Закона), информацию и документы, которые подтверждают соответствие
участника электронного аукциона дополнительным требованиям, установленным
в соответствии с частями 2 и 2.1 (при наличии таких требований) статьи 31 Закона, если иное не
предусмотрено Законом;
о) декларация о соответствии участника электронного аукциона требованиям,
установленным пунктами 3 - 5, 7 - 11 части 1 статьи 31 Закона (если информация и документы,
которые подтверждают соответствие участника электронного аукциона требованиям,
установленным пунктом 1 части 1 статьи 31 Закона, содержатся в открытых и общедоступных
государственных реестрах, размещенных в информационно-телекоммуникационной сети
«Интернет», в указанную декларацию может быть также включено положение о соответствии
участника электронного аукциона требованиям, установленным пунктом 1 части 1 статьи 31
Закона, с указанием адреса сайта или страницы сайта в информационно-телекоммуникационной
сети «Интернет», на которых размещены такие информация и документы);
п) реквизиты счета участника электронного аукциона, на который в соответствии
с законодательством Российской Федерации осуществляется перечисление денежных средств
в качестве оплаты поставленного товара, выполненной работы (ее результатов), оказанной
услуги, а также отдельных этапов исполнения контракта, за исключением случаев, если
в соответствии с законодательством Российской Федерации такой счет открывается после
заключения контракта;
2) предложение участника закупки в отношении объекта закупки:
а) с учетом положений части 2 статьи 43 Закона характеристики предлагаемого
участником электронного аукциона товара, в том числе поставляемого при выполнении
закупаемых работ, соответствующие показателям, установленным в описании объекта закупки
в соответствии с частью 2 статьи 33 Закона, товарный знак (при наличии у товара товарного
знака);
б) наименование страны происхождения товара в соответствии с общероссийским
классификатором, используемым для идентификации стран мира, с учетом положений части 2
статьи 43 Закона;
в) документы, подтверждающие соответствие товара, работы или услуги требованиям,
установленным в соответствии с законодательством Российской Федерации (в случае, если
в соответствии с законодательством Российской Федерации установлены требования к товару,
работе или услуге и представление указанных документов предусмотрено извещением
об осуществлении закупки, документацией о закупке, если настоящим Федеральным законом
предусмотрена документация о закупке). Государственный заказчик не вправе требовать
представление указанных документов, если в соответствии с законодательством Российской
Федерации они передаются вместе с товаром;
г) иные информация и документы, в том числе эскиз, рисунок, чертеж, фотография, иное
изображение предлагаемого участником электронного аукциона товара. При этом отсутствие
таких информации и документов не является основанием для отклонения заявки на участие
в электронном аукционе;
3) информация и документы, определенные в соответствии с пунктом 2 части 2 статьи 14
Закона (в случае, если в извещении об осуществлении электронного аукциона установлены
предусмотренные указанной статьей запрет, ограничение, преимущество). В случае отсутствия
таких информации и документов в заявке на участие в закупке такая заявка приравнивается
к заявке, в которой содержится предложение о поставке товаров, происходящих из
 4
иностранного государства, работ, услуг, соответственно выполняемых, оказываемых
иностранными лицами.
2. При формировании предложения участника электронного аукциона в отношении
объекта закупки:
1) информация о товаре, предусмотренная подпунктами "а" и "б" пункта 2 части 1 статьи 43
Закона, включается в заявку на участие в электронном аукционе в случае осуществления
закупки товара, в том числе поставляемого Государственному заказчику при выполнении
закупаемых работ. Информация, предусмотренная подпунктом "а" пункта 2 части 1 статьи 43
Закона, может не включаться в заявку на участие в электронном аукционе в случае указания
Государственным заказчиком в описании объекта закупки товарного знака и предложения
участником электронного аукциона товара, в том числе поставляемого Государственному
заказчику при выполнении закупаемых работ, обозначенного таким товарным знаком;
2) информация, предусмотренная подпунктами "а" и "г" пункта 2 части 1 статьи 43 Закона,
не включается в заявку на участие в электронном аукционе в случае включения
Государственным заказчиком в соответствии с пунктом 8 части 1 статьи 33 Закона в описание
объекта закупки проектной документации, или типовой проектной документации, или сметы
на капитальный ремонт объекта капитального строительства;
В соответствии с пунктом 2 части 6 статьи 43 Закона информация и документы,
предусмотренные подпунктами "а" - "л" пункта 1 части 1 статьи 43 Закона, не включаются
участником электронного аукциона в заявку на участие в электронном аукционе. Такие
информация и документы в случаях, предусмотренных Законом, направляются (по состоянию
на дату и время их направления) Государственному заказчику оператором электронной
площадки путем информационного взаимодействия с единой информационной системой;
В соответствии с пунктом 3 части 6 статьи 43 Закона информация и документы, которые
подтверждают соответствие участника электронного аукциона дополнительным требованиям,
установленным в соответствии с частью 2 или 2.1 (при наличии таких требований) статьи 31
Закона, и предусмотренные подпунктом «н» пункта 1 части 1 статьи 43 Закона, не включаются
участником электронного аукциона в заявку на участие в электронном аукционе. Такие
информация и документы в случаях, предусмотренных Законом, направляются (по состоянию
на дату и время их направления) Государственному заказчику оператором электронной
площадки из реестра участников закупок, аккредитованных на электронной площадке.
В случаях, установленных Постановлением Правительства Российской Федерации
от 10.04.2023 № 579 «Об особенностях порядка предоставления обеспечения заявок на участие в
закупках товаров, работ, услуг для обеспечения государственных или муниципальных нужд
участниками таких закупок, являющимися иностранными лицами» заявка на участие в закупке
должна содержать информацию и документы, подтверждающие предоставление обеспечения
заявки на участие в закупке, в форме электронных документов или в форме электронных
образов бумажных документов.
Инструкция по заполнению заявки на участие в открытом аукционе в электронной
форме.
Подать заявку на участие в электронном аукционе вправе только зарегистрированный
в единой информационной системе в сфере закупок (далее – единая информационная система) и
аккредитованный на электронной площадке участник электронного аукциона закупки путем
направления такой заявки в соответствии с Законом оператору электронной площадки.
Участник электронного аукциона вправе подать только одну заявку на участие
в электронном аукционе в любое время с момента размещения в единой информационной
 5
системе извещения о проведении электронного аукциона до окончания установленного
в извещении в соответствии с Законом срока подачи заявок на участие в электронном аукционе.
Подача заявки на участие в электронном аукционе означает согласие участника
электронного аукциона подавшего такую заявку, на выполнение работ на условиях,
предусмотренных извещением о проведении электронного аукциона и в соответствии с заявкой
такого участника электронного аукциона на участие в электронном аукционе.
Заявка на участие в электронном аукционе должна содержать информацию и документы:
- решение о согласии на совершение или о последующем одобрении крупной сделки, если
требование о наличии такого решения установлено законодательством Российской Федерации,
учредительными документами юридического лица и для участника электронного аукциона
заключение контракта на выполнение работ, являющихся объектом закупки, либо внесение
денежных средств в качестве обеспечения заявки на участие в электронном аукционе,
обеспечения исполнения контракта является крупной сделкой;
- декларация о соответствии участника электронного аукциона требованиям,
установленным пунктами 3 - 5, 7 - 11 части 1 статьи 31 Закона;
- реквизиты счета участника электронного аукциона, на который в соответствии
с законодательством Российской Федерации осуществляется перечисление денежных средств
в качестве оплаты выполненной работы, а также отдельных этапов исполнения контракта,
за исключением случаев, если в соответствии с законодательством Российской Федерации
такой счет открывается после заключения контракта.
- информация и документы, предусмотренные нормативными правовыми актами,
принятыми в соответствии с частями 3 и 4 статьи 14 Закона (в случае, если в извещении
об осуществлении закупки, документации о закупке (если Законом предусмотрена
документация о закупке) установлены предусмотренные указанной статьей запреты,
ограничения, условия допуска):
для подтверждения происхождения программ для электронных вычислительных машин
и (или) баз данных (далее – программное обеспечение), указанных в позиции 146
приложения № 1 к Постановлению № 1875, из Российской Федерации – порядковый номер
реестровой записи из единого реестра российских программ для электронных вычислительных
машин и баз данных (далее - реестр российского программного обеспечения);
для подтверждения происхождения программного обеспечения, указанного в позиции 146
приложения № 1 к Постановлению № 1875, из государств – членов Евразийского
экономического союза, за исключением Российской Федерации, – порядковый номер
реестровой записи из единого реестра программ для электронных вычислительных машин и баз
данных из государств – членов Евразийского экономического союза, за исключением
Российской Федерации.
- в случае если участник электронного аукциона, являющийся юридическим лицом,
зарегистрированным на территории государства – члена Евразийского экономического союза,
за исключением Российской Федерации, или физическим лицом, являющимися гражданином
государства - члена Евразийского экономического союза, за исключением Российской
Федерации, предоставляет обеспечение заявки в виде денежных средств на счет, обеспечение
заявки должно предоставляться с учетом следующих особенностей:
а) заявка на участие в электронном аукционе должна содержать информацию и документы,
подтверждающие предоставление обеспечения заявки на участие в электронном аукционе,
в форме электронных документов или в форме электронных образов бумажных документов;
б) участник электронного аукционе признается непредоставившим обеспечение заявки
на участие в электронном аукционе в случае непоступления денежных средств, информация
и документы о внесении которых в качестве обеспечения заявки представлены в заявке
на участие в электронном аукционе, до даты подведения итогов электронного аукциона
на указанный в извещении счет, на котором в соответствии с законодательством Российской
Федерации учитываются операции со средствами, поступающими Государственному заказчику.
При этом заявка на участие в электронном аукционе, поданная таким участником электронного
 6
аукциона, отклоняется в порядке, установленном для случая, предусмотренного пунктом 7
части 12 статьи 48 Закона.
