Приказ Минцифры России от 16.12.2025 N 1174

Минцифры обновило требования к сетям связи для оперативно-разыскных мероприятий

Минцифры утвердило новые требования к сетям и средствам связи, которые должны обеспечивать возможность проведения уполномоченными органами оперативно-разыскных мероприятий. Прежний приказ Минкомсвязи 2019 года признан утратившим силу.

Документ касается собственников и иных владельцев технологических сетей связи, имеющих уникальный идентификатор в интернете. В нем определены варианты построения программно-технических средств и обязательные функции таких систем.

Приказ Минцифры России от 16.12.2025 № 1174 зарегистрирован в Минюсте 22 мая 2026 года. Он устанавливает обновленные технические и организационные требования в этой сфере.

Скачать_ДОКУМЕНТ в PDF

Скачать_ ДОКУМЕНТ в Word

МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ

И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ

 ПРИКАЗ

от 16 декабря 2025 г. N 1174

Зарегистрировано в Минюсте России 22 мая 2026 г. N 86587

 

ОБ УТВЕРЖДЕНИИ ТРЕБОВАНИЙ

К СЕТЯМ И СРЕДСТВАМ СВЯЗИ СОБСТВЕННИКОВ ИЛИ ИНЫХ

ВЛАДЕЛЬЦЕВ ТЕХНОЛОГИЧЕСКИХ СЕТЕЙ СВЯЗИ, ИМЕЮЩИХ УНИКАЛЬНЫЙ

ИДЕНТИФИКАТОР СОВОКУПНОСТИ СРЕДСТВ СВЯЗИ И ИНЫХ ТЕХНИЧЕСКИХ

СРЕДСТВ В ИНФОРМАЦИОННО-ТЕЛЕКОММУНИКАЦИОННОЙ СЕТИ

«ИНТЕРНЕТ», ДЛЯ ПРОВЕДЕНИЯ УПОЛНОМОЧЕННЫМИ ГОСУДАРСТВЕННЫМИ

ОРГАНАМИ, ОСУЩЕСТВЛЯЮЩИМИ ОПЕРАТИВНО-РАЗЫСКНУЮ ДЕЯТЕЛЬНОСТЬ

ИЛИ ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ РОССИЙСКОЙ ФЕДЕРАЦИИ,

В СЛУЧАЯХ, УСТАНОВЛЕННЫХ ФЕДЕРАЛЬНЫМИ ЗАКОНАМИ,

МЕРОПРИЯТИЙ В ЦЕЛЯХ РЕАЛИЗАЦИИ ВОЗЛОЖЕННЫХ

НА НИХ ЗАДАЧ

 

В соответствии с подпунктом 3 пункта 9 статьи 56.2 Федерального закона от 7 июля 2003 г. № 126-ФЗ «О связи», подпунктами 5.2.54 и 5.2.55 пункта 5 Положения о Министерстве цифрового развития, связи и массовых коммуникаций Российской Федерации, утвержденного постановлением Правительства Российской Федерации от 2 июня 2008 г. № 418,

приказываю:

1. Утвердить прилагаемые Требования к сетям и средствам связи собственников или иных владельцев технологических сетей связи, имеющих уникальный идентификатор совокупности средств связи и иных технических средств в информационно-телекоммуникационной сети «Интернет», для обеспечения безопасности Российской Федерации по направлению деятельности федеральной службы безопасности.
2. Признать утратившим силу приказ Минкомсвязи России от 5 ноября 2019 г. № 646 «Об утверждении Требований к сетям и средствам связи собственников или иных владельцев технологических сетей связи, имеющих номер автономной системы, для проведения уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность или обеспечение безопасности Российской Федерации, в случаях, установленных федеральными законами, мероприятий в целях реализации возложенных на них задач»(зарегистрирован Министерством юстиции Российской Федерации 22 января 2020 г., регистрационный № 57223).

 

Министр

М.И.ШАДАЕВ

УТВЕРЖДЕНЫ

приказом Министерства

цифрового развития, связи

и массовых коммуникаций

Российской Федерации

от 16 декабря 2025 года № 1174

 

Требования к сетям и средствам связи собственников или иных владельцев технологических сетей связи, имеющих уникальный идентификатор совокупности средств связи и иных технических средств в сети «Интернет», для обеспечения безопасности Российской Федерации по направлению деятельности федеральной службы безопасности

I. Общие положения

1. Настоящие Требования устанавливают требования к программным и техническим средствам, используемым собственником или иным владельцем технологических сетей связи, имеющих уникальный идентификатор совокупности средств связи и иных технических средств в информационно-телекоммуникационной сети «Интернет» (далее — сеть «Интернет»), в эксплуатируемых им информационных системах (далее — ИС АС).
2. Настоящие Требования направлены на обеспечение безопасности Российской Федерации по направлению деятельности федеральной службы безопасности.

II. Общие требования к программным и техническим средствам, направленные на обеспечение безопасности Российской Федерации по направлению деятельности федеральной службы безопасности

3. Состав и построение программных и технических средств, направленных на обеспечение безопасности Российской Федерации по направлению деятельности федеральной службы безопасности (далее — ПТС), определяются особенностями построения ИС АС, перечнем предоставляемых информационных услуг и коммуникационных интернет-сервисов.
4. При реализации ПТС должен быть использован один из вариантов их построения:

а) отдельный аппаратно-программный комплекс;

б) отдельный программный модуль в ИС АС;

в) комбинированный вариант, предусматривающий совместное использование элементов в соответствии с подпунктами «а» и «б» настоящего пункта.

5. Для каждого варианта построения должны обеспечиваться согласованные с органом федеральной службы безопасности требования по информационной безопасности и защите от несанкционированного доступа к информации, связанной с обеспечением безопасности Российской Федерации, в соответствии с подпунктами «з»и «и» пункта 18 настоящих Требований.
6. ПТС должны входить в состав узлов связи технологических сетей связи, имеющих уникальный идентификатор совокупности средств связи и иных технических средств в сети «Интернет».

III. Функциональные требования к ПТС

7. ПТС должны осуществлять поиск, обработку и передачу на пульт управления федеральной службы безопасности (далее — ПУ) по ее запросу или в автоматическом режиме информацию, хранящуюся в ИС АС и передаваемую по технологическим сетям связи.
8. Перечень доступной для поиска информации, хранящейся в ИС АС и передаваемой по технологическим сетям связи, и схема ее представления должны согласовываться с федеральной службой безопасности. Мероприятия по согласованию должны включаться в план мероприятий по внедрению ПТС в сети связи собственника или иного владельца технологической сети связи, имеющих уникальный идентификатор совокупности средств связи и иных технических средств в сети «Интернет».
9. Взаимодействие ПТС с ПУ должно осуществляться по единому каналу передачи данных.
10. Суммарная пропускная способность канала передачи данных между ПТС и ПУ должна соответствовать данным, приведенным в таблице № 1.

Таблица № 1

№ п/п	Среднесуточный объем новых данных, поступающих в ИС АС, Гбайт	Суммарная пропускная способность каналов передачи данных между ПТС и ПУ, не менее Мбит/с
1	<1	10
2	1-10	50
3	10-100	100
4	100 500	500
5	500-1000	800
6	1000-10000	1000
7	>10000	10000

11. Требования, предъявляемые к интерфейсу взаимодействия между ПУ и ПТС, приведены в приложении № 1 к настоящим Требованиям.
12. Требования к схеме представления информации, хранящейся в схеме данных, и выполнению запросов от ПУ приведены в приложении № 2 к настоящим Требованиям.
13. Перечень базовых типов для описания схемы данных приведен в приложении № 3 к настоящим Требованиям.
14. Перечень сервисных типов для описания схемы данных приведен в приложении № 4 к настоящим Требованиям.
15. Перечень входных объектов для задания параметров поиска приведен в приложении № 5 к настоящим Требованиям.
16. Требования, предъявляемые к формату передачи данных на языке GraphQL по протоколу WebSocket, приведены в приложении № 6 к настоящим Требованиям.
17. Требования, предъявляемые к запросам мониторинга и формату их передачи по интерфейсу взаимодействия между ПУ и ПТС, приведены в приложении № 7 к настоящим Требованиям.
18. ПТС должны обеспечивать:

а) подключение к ПУ в соответствии с пунктом 10 Правил взаимодействия собственников или иных владельцев технологических сетей связи, имеющих уникальный идентификатор совокупности средств связи и иных технических средств в информационно-телекоммуникационной сети «Интернет», с уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность или обеспечение безопасности Российской Федерации, утвержденных постановлением Правительства Российской Федерации от 29 октября 2019 г. № 1385;

б) реализацию протокола взаимодействия ПТС с ПУ в соответствии с приложением № 1 к настоящим Требованиям;

в) прием от ПУ поисковых запросов и запросов постановки объектов на контроль;

г) поиск информации, хранящейся в ИС АС, в соответствии с поступившими с ПУ поисковыми запросами и запросами постановки объектов на контроль. Для ПТС, осуществляющих поиск информации в ИС АС со среднесуточным объемом новых данных свыше 1 Гбайт, устанавливаются особые требования к поддерживаемым критериям поиска в соответствии с пунктом 21 приложения № 1 к настоящим Требованиям;

д) передачу на ПУ от ПТС данных в соответствии с поступившими с ПУ поисковыми запросами (в том числе постранично) и запросами постановки объектов на контроль;

е) прием от ПУ критериев поиска и передачу на ПУ статистической, текстовой, мультимедийной, звуковой, графической и иной информации в исходном (декодированном) виде, хранящейся в ИС АС и отбираемой по критериям поиска, без дополнительной обработки (далее — неформатированные данные);

ж) передачу на ПУ схемы данных, в соответствии с поступившим с ПУ специальным запросом согласно приложению № 4 к настоящим Требованиям;

з) защиту от несанкционированного доступа со стороны производителей ПТС, неавторизованных пользователей, технического персонала, третьих лиц как к хранящейся в ПТС информации, так и информации, непосредственно связанной с проведением мероприятий, направленных на обеспечение безопасности Российской Федерации по направлению деятельности федеральной службы безопасности (информации, поступающей в ПТС с ПУ, и информации, подготовленной к передаче из ПТС в ПУ);

и) информирование ПУ о следующих попытках несанкционированного доступа:

для варианта исполнения ПТС в виде отдельного аппаратно-программного комплекса:

доступ к данным, связанным с проведением мероприятий, направленных на обеспечение безопасности Российской Федерации по направлению деятельности федеральной службы безопасности, с использованием команд или сервисных программ;

резервное копирование данных, связанных с проведением мероприятий, направленных на обеспечение безопасности Российской Федерации по направлению деятельности федеральной службы безопасности;

доступ к ПТС через интерфейсы, не предусмотренные для доступа к ним;

вскрытие корпуса технических средств, направленных на обеспечение безопасности Российской Федерации по направлению деятельности федеральной службы безопасности;

для варианта исполнения ПТС в виде отдельного программного модуля в ИС АС:

доступ к данным, связанным с проведением мероприятий, направленных на обеспечение безопасности Российской Федерации по направлению деятельности федеральной службы безопасности, с использованием команд или сервисных программ;

резервное копирование данных, связанных с проведением мероприятий, направленных на обеспечение безопасности Российской Федерации по направлению деятельности федеральной службы безопасности;

для комбинированного варианта исполнения ПТС:

доступ к данным, связанным с проведением мероприятий, направленных на обеспечение безопасности Российской Федерации по направлению деятельности федеральной службы безопасности, с использованием команд или сервисных программ;

резервное копирование данных, связанных с проведением мероприятий, направленных на обеспечение безопасности Российской Федерации по направлению деятельности федеральной службы безопасности;

доступ к ПТС через интерфейсы, не предусмотренные для доступа к ним;

вскрытие корпуса технических средств, направленных на обеспечение безопасности Российской Федерации по направлению деятельности федеральной службы безопасности;

контроль работоспособности и загруженности ПТС;

контроль за соблюдением предоставленных прав доступа к хранящейся в ПТС информации;

круглосуточный удаленный доступ со стороны операторов ПУ к хранящейся в ИС АС информации по протоколу взаимодействия ПУ и ПТС, описанному в приложении № 1 к настоящим Требованиям;

к) ведение в автоматическом режиме системных журналов, содержащих информацию о работе ПТС, а также данных, связанных с проведением мероприятий, направленных на обеспечение безопасности Российской Федерации по направлению деятельности федеральной службы безопасности:

о сеансах связи с ПУ, а также о попытках установления таких сеансов;

о фактах получения и выполнения поисковых запросов и запросов постановки объектов на контроль ПУ (только идентификаторы запросов, время получения и (или) выполнения, результат выполнения (успешно или неуспешно);

об ответах на поисковые запросы и запросы постановки объектов на контроль ПУ;

о текущей конфигурации ПТС, системного и прикладного ПО;

об изменениях в конфигурации ПТС, системного и прикладного ПО;

о сбоях в ПТС, системном и прикладном ПО;

об изменениях схемы данных;

об обращении и доступе обслуживающего технического персонала к ПТС;

доступ уполномоченного технического персонала для обслуживания ПТС в соответствии с установленными правами доступа;

доступ технического персонала к системным файлам и ПО, в соответствии с правами, установленными парольной системой доступа;

сохранность и доступность для дальнейшего использования ранее накопленных данных при модернизации ПТС;

автоматическое определение способа выполнения поисковых запросов (в режиме реального времени или в отложенном режиме) в соответствии с пунктом 20 приложения № 1 к настоящим Требованиям, поступивших с ПУ, в соответствии с заданными временными параметрами;

временное хранение результатов выполнения поисковых запросов в отложенном режиме с учетом заданных временных параметров согласно пункту 22 настоящих требований.

19. Функционирование ПТС не должно оказывать влияние на работоспособность ИС АС и технологические сети связи.
20. ПТС не должны иметь иных интерфейсов взаимодействия, кроме интерфейсов взаимодействия с ИС АС и ПУ.
21. ПТС, применяемые в распределенных технологических сетях связи и (или) нескольких технологических сетях связи, должны иметь функционал выполнения поисковых запросов для тех технологических сетей связи, которые заданы с ПУ в запросе.

IV. Требования, предъявляемые к ПТС в части обеспечения временных характеристик обработки запроса и поиска информации

22. Максимальное время предварительной обработки информации с момента ее поступления в ПТС до момента, когда она становится доступной для выполнения поисковых запросов с ПУ, и максимальное время выполнения поисковых запросов и запросов постановки объектов на контроль определяется в ходе внедрения ПТС в сети связи собственника или иного владельца технологической сети связи, имеющего уникальный идентификатор совокупности средств связи и иных технических средств в сети «Интернет». Также должны быть установлены временные параметры для определения способа выполнения поисковых запросов (в режиме реального времени или в отложенном режиме) согласно пункту 20 приложения № 1 к настоящим Требованиям) и максимальное время хранения результатов выполнения поисковых запросов в отложенном режиме. Мероприятие по определению указанных временных параметров должно включаться в план мероприятий по внедрению ПТС и согласовываться с федеральной службой безопасности.
23. Временные параметры, указанные в пункте 22 настоящих требований, могут корректироваться во время эксплуатации ПТС по согласованию с федеральной службой безопасности.

Приложение № 1

к Требованиям к сетям и средствам

связи собственников или иных владельцев

технологических сетей связи, имеющих

уникальный идентификатор совокупности

средств связи и иных технических средств

в сети «Интернет», для обеспечения

безопасности Российской Федерации по

направлению деятельности федеральной

службы безопасности

Требования, предъявляемые к интерфейсу взаимодействия между ПУ и ПТС

1. ПТС подключаются к ПУ в точках подключения выделенными каналами связи.
2. В качестве набора протоколов передачи данных следует использовать набор протоколов TCP/IP.
3. Для организации линий (каналов) связи, соединяющих ПТС и ПУ, должен быть использован сетевой интерфейс первого уровня.
4. ПТС должны предусматривать возможность создания виртуальной сети VPN (Virtual Private Network) для туннелирования всего рабочего TCP/IP трафика между ПТС и ПУ.
5. Взаимодействие ПТС с оборудованием ПУ на транспортном уровне должен осуществляться по схеме «клиент — сервер»:

1) в качестве «сервера» выступают ПТС;

2) в качестве «клиента» выступает оборудование ПУ.

6. Способы защиты линий (каналов) связи должны согласовываться с федеральной службой безопасности. Соединение ПУ и ПТС должно устанавливаться по протоколу TLS версии 1.2 или 1.3. При установлении соединения ПУ и ПТС должны осуществлять взаимную аутентификацию. В случае невозможности аутентифицировать одну из сторон TCP-соединение разрывается. Для аутентификации ПУ и ПТС используются сертификаты в формате Х.509. Для аутентификации ПУ на разных ПТС должны быть созданы и использоваться разные сертификаты.
7. Взаимодействие ПТС с ПУ должно осуществляться по единому каналу передачи данных, предназначенному для передачи:

1) от ПУ в ПТС поисковых запросов и запросов постановки объектов на контроль;

2) от ПТС на ПУ результатов выполнения поисковых запросов (в том числе постранично) и запросов постановки объектов на контроль;

3) от ПУ в ПТС запросов на получение неформатированных данных (далее — запросы неформатированных данных);

4) от ПТС на ПУ ответов на запросы неформатированных данных;

5) от ПУ в ПТС специальных запросов, согласно приложению № 4 к настоящим Требованиям, для получения схемы данных, статуса поисковых запросов в отложенном режиме, согласно пункту 20 настоящего приложения, и сигналов о функционировании ПТС в соответствии с пунктом 29 настоящего приложения;

6) от ПТС на ПУ текущей схемы данных, статуса поисковых запросов в отложенном режиме и сигналов о функционировании ПТС;

7) от ПУ в ПТС запросов о текущей конфигурации оборудования, системного и прикладного ПО ПТС, а также их состоянии (далее — запросы мониторинга);

8) от ПТС на ПУ ответов на запросы мониторинга.

8. Единый канал передачи данных создается для подключения к ПТС в виде TCP-соединений. Номер порта может передаваться на ПУ на внешних носителях (по умолчанию — 443). Посредством ПТС выполняется мониторинг данного порта для создания TCP-соединений с ПУ.
9. ПУ должен осуществлять попытки установления подключения к ПТС в соответствии с задаваемым интервалом по предоставленному ПТС ТСР-порту.
10. Обмен данными в едином канале передачи данных на прикладном уровне должен осуществляться по протоколам HTTP 1.1 и WebSocket.
11. ПТС должны реализовывать четыре конечные точки (endpoints):

1) «/query» — предназначена для получения от ПУ поисковых запросов и специальных запросов согласно приложению № 4 к настоящим Требованиям для получения схемы данных, управления поисковыми запросами в отложенном режиме, а также передачи на ПУ результатов выполнения данных запросов (в том числе постранично) в режиме реального времени в соответствии с пунктом 20 настоящего приложения.

2) «/subscription» — предназначена для получения от ПУ запросов постановки объектов на контроль и передачи на ПУ результатов их выполнения, а также для передачи на ПУ статуса выполнения поисковых запросов ПТС, которые выполняются в отложенном режиме согласно пункту 20 настоящего приложения и сигналов о функционировании ПТС согласно пункту 29 настоящего приложения.

3) «/download» — предназначена для получения от ПУ запросов неформатированных данных и передачи на ПУ результатов выполнения данных запросов.

4) «/metric» — предназначена для получения от ПУ запросов мониторинга и передачи на ПУ результатов выполнения данных запросов.

12. Обмен данными для конечных точек «/query», «/download» и «/metric» должен осуществляться по протоколу HTTP 1.1, для конечной точки «/subscription» — по протоколу WebSocket. ПУ и ПТС для конечной точки «/subscription» должны поддерживать сетевое соединение с помощью механизмов протокола WebSocket.
13. Для запросов ПУ и ответов ПТС для конечных точек «/query» и «/subscription» должен использоваться язык описания данных и запросов GraphQL в спецификации от 6 октября 2021 г. Для кодирования содержимого запросов и ответов должен применяться формат JSON.
14. Требования, предъявляемые к формату передачи данных на языке GraphQL по протоколу WebSocket для конечной точки «/subscription», приведены в приложении № 6 к настоящим Требованиям.
15. Требования, предъявляемые к формату передачи данных для конечной точки «/metric», приведены в приложении № 7 к настоящим Требованиям.
16. Для запросов ПУ и ответов ПТС для конечной точки «/download» должны использоваться стандартные сообщения протокола HTTP 1.1. ПТС для данной конечной точки должны поддерживать механизм передачи данных по частям (Chunked Transfer Coding) и механизм частичных запросов (Range Requests).
17. Если результаты выполнения поисковых запросов и запросов постановки объектов на контроль для конечных точек «/query» и «/subscription» содержат неформатированные данные (файлы), то ответ ПТС должен содержать вместо непосредственно неформатированных данных (файлов) соответствующие ссылки (HTTP URI в полном формате согласно RFC7230 http(s)://<IP-адрес или доменное имя ПТС>:<порт>/download/<уникальный путь к файлу>) для каждого файла для конечной точки «/download». ПТС должны формировать уникальную ссылку для каждого файла.
18. Для получения неформатированных данных, ссылки на которые содержатся в ответе ПТС на поисковый запрос или запрос постановки объектов на контроль, ПУ для каждого файла должен направлять на конечную точку «/download» отдельные (от поисковых запросов) запросы получения неформатированных данных (HTTP GET-запросы) в ПТС, содержащие ссылку на запрашиваемые данные.
19. Для получения текущей схемы данных ПУ необходимо направить специальный запрос «getSchema», согласно приложению № 4 к настоящим Требованиям, на конечную точку «/query». В ответ ПТС должны направить схему данных, описанную на языке SDL GraphQL.
20. Поисковые запросы должны выполняться в ПТС в двух режимах: режиме реального времени и отложенном режиме (далее — отложенный поисковый запрос). Режим выполнения поисковых запросов определяется ПТС в соответствии с установленными временными параметрами согласно пункту 22 настоящих требований, а также с учетом характера (количества запрашиваемых полей и критериев поиска) запроса, количества данных, хранящихся в ИС АС, и производительностью ПТС. Изначально все поисковые запросы от ПУ должны направляться на конечную точку «/query».
21. ПТС могут выполнять поисковые запросы только с критериями поиска, заданными на верхнем уровне запроса (без вложенных объектов and, or, not, включая базовые фильтры, согласно пункту 9 приложения № 2 к настоящим Требованиям, при следующих условиях:

по согласованию с федеральной службой безопасности, если среднесуточный объем новых данных, поступающих в ИС АС, составляет от 1 до 10 Гбайт;

без согласования с федеральной службой безопасности, если среднесуточный объем новых данных, поступающих в ИС АС, превышает 10 Гбайт.

22. ПУ перед направлением поисковых запросов ПТС должен подписаться на получение статуса отложенного поискового запроса — отправить запрос «statusOfflineRequest» (запрос Subscription языка GraphQL) на конечную точку «/subscription» по протоколу WebSocket в соответствии с приложением № 4 к настоящим Требованиям. ПТС не должны выполнять поисковые запросы, если ПУ не подписался на получение статуса отложенного поискового запроса.
23. В режиме реального времени ПТС должны поддерживать (не разрывать) сетевое соединение, по которому поступил запрос от ПУ, и результаты выполнения запроса должны передаваться от ПТС на ПУ по тому же сетевому соединению, не позднее установленных временных параметров согласно пункту 22 настоящих требований.
24. Отложенный поисковый запрос выполняется по следующему сценарию:

1) ПУ направляет поисковый запрос ПТС на конечную точку «/query»;

2) ПТС принимают решение о выполнении запроса в отложенном режиме;

3) ПТС назначают поисковому запросу уникальный в рамках данной ПТС идентификатор;

4) ПТС возвращают ПУ идентификатор отложенного поискового запроса и информацию о том, что запрос выполняется в отложенном режиме;

5) ПТС в непрерывном режиме уведомляют ПУ (путем ответа на запрос «statusOfflineRequest» (запрос Subscription языка GraphQL) на конечную точку «/subscription» по протоколу WebSocket, согласно пункту 22 настоящего приложения об изменениях статуса выполнения отложенного поискового запроса. Возможные статусы выполнения отложенного запроса:

NOTSTARTED — запрос получен, но не запущен на выполнение;

RUNNING — запрос получен и в настоящее время выполняется;

READY — выполнение запроса завершено, результирующие данные готовы;

ABORTED — выполнение запроса прервано (на стороне сервера — ПТС);

CANCELED — запрос отменен клиентом (ПУ);

6) когда ПУ получает от ПТС уведомление о завершении выполнения отложенного поискового запроса (статус «READY»), то ПУ направляет специальный запрос «getOfflineRequest», согласно приложению № 4 к настоящим Требованиям, на конечную точку «/query» с указанием идентификатора запроса. ПУ также может инициировать получение результатов выполнения отложенного запроса постранично аналогично данной процедуре для запросов в режиме реального времени в соответствии с подпунктом 2 пункта 9 приложения № 2 к настоящим Требованиям;

7) в ответ на полученный специальный запрос ПТС начинают передавать на ПУ результаты выполнения отложенного поискового запроса в режиме реального времени в форматe JSON. Структура результатов выполнения отложенного поискового запроса должна однозначно соответствовать структуре исходного поискового запроса, направленного ПУ на конечную точку «/query»;

8) в момент выполнения отложенного запроса (от момента получения идентификатора запроса от ПТС до получения статуса выполнения запроса «READY») ПУ может прервать данную операцию, направив специальный запрос «cancelOfflineRequest», в соответствии с приложением № 4 к настоящим Требованиям, на конечную точку «/query» с указанием идентификатора запроса. В ответ ПТС должны направить результат выполнения данного специального запроса.

ПТС должны удалять промежуточные результаты прерванного отложенного запроса.

25. ПТС должны хранить результаты выполнения отложенных запросов заданное максимальное время в соответствии с пунктом 22 настоящих требованийили немедленно их удалять при получении специального запроса.

Для удаления результатов выполнения отложенного поискового запроса на ПТС, ПУ необходимо направить специальный запрос «delOfflineRequest», в соответствии с приложением № 4 к настоящим Требованиям, на конечную точку «/query» с указанием идентификатора запроса. В ответ ПТС должны направить результат выполнения данного специального запроса.

26. ПТС должны поддерживать два вида постраничной передачи результатов выполнения поисковых запросов: со смещением и курсорную. По согласованию с федеральной службой безопасности может быть реализован только один из видов постраничной передачи результатов.
27. ПУ должен направлять запросы постановки объектов на контроль на конечную точку «/subscription» по протоколу WebSocket. После получения запроса ПТС направляют ПУ результаты выполнения данного запроса по мере появления новых данных (с момента получения запроса) в ИС АС, соответствующих критериям отбора, заданным в запросе ПУ. Передача результатов выполнения запросов постановки объектов на контроль осуществляется в непрерывном режиме, то есть без дополнительных запросов от ПУ.
28. Для снятия объектов с контроля ПУ должен направить сообщение «Complete», в соответствии с подпунктом 6 пункта 8 приложения № 6 к настоящим Требованиям, на конечную точку «/subscription» по протоколу WebSocket. ПТС после получения сообщения должны прекратить отбор данных из ИС АС по критериям, ранее заданным в запросе постановки объекта на контроль, а также прекратить передачу на ПУ результатов выполнения данного запроса.
29. ПТС должны обеспечивать контроль функционирования собственных параметров и передачу на ПУ следующих сигналов:

1) «Перезапуск ПО» (RESTARTDB);

2) «Попытка несанкционированного доступа» (UNAUTHORIZEDACCESS);

связи собственников или иных владельцев

технологических сетей связи, имеющих

уникальный идентификатор совокупности

средств связи и иных технических средств

в сети «Интернет», для обеспечения

безопасности Российской Федерации по

направлению деятельности федеральной

службы безопасности

Требования, предъявляемые к формату передачи данных на языке GraphQL по протоколу WebSocket

1. ПТС и ПУ для передачи данных на языке GraphQL по протоколу WebSocket должны использовать подпротокол graphql-transport-ws.
2. ПТС и ПУ взаимодействуют по протоколу WebSocket посредством сообщений. Для кодирования сообщений применяется формат JSON.
3. Все сообщения должны содержать поле «type», определяющее тип сообщения. Сообщение в зависимости от типа также может содержать дополнительные поля:

«id» — идентификатор запроса, использующийся для последующего определения ответов ПТС и привязки их к запросам ПУ;

«payload» — дополнительные данные для некоторых типов сообщений.

4. В любой момент времени ПТС должны позволять выполнять несколько запросов ПУ с уникальными идентификаторами. При этом передача сообщений, относящихся к различным запросам, может чередоваться.
5. ПТС должны закрывать соединение по протоколу WebSocket при возникновении критической ошибки (сбое в работе) и тем самым уведомлять ПУ о данной ситуации.
6. ПУ может корректно закрывать соединение по протоколу WebSocket с кодом 1000 и причиной закрытия «Normal Closure».
7. ПУ перед отправкой запросов на языке GraphQL должен открыть сессию в соответствии с подпунктом 1 пункта 8 настоящего приложенияповерх протокола WebSocket.
8. ПТС и ПУ взаимодействуют по протоколу WebSocket с использованием следующих типов сообщений:

1) сообщение «ConnectionInit». Данное сообщение направляется ПУ в адрес ПТС для открытия сессии. ПУ может передавать дополнительную информацию о сессии в поле «payload». ПТС должны получить данное сообщение в течение заданного периода времени (определяется во время внедрения ПТС и согласовывается с федеральной службой безопасности). Если ПУ не отправило данное сообщение в течение заданного периода времени, то ПТС должны закрыть соединение по протоколу WebSocket с кодом 4408 и причиной закрытия «Connection initialization timeout». Если ПТС получили более одного сообщения «ConnectionInit», то они должны закрыть соединение по протоколу WebSocket с кодом 4429 и причиной закрытия «Too many initialization requests».

Формат сообщения «ConnectionInit» (поле «payload» опциональное):

	{ «type»: «connection_init», «payload»: «string» }

2) сообщение «ConnectionAck». Данное сообщение подтверждает успешное создание сессии и направляется ПТС в адрес ПУ в ответ на сообщение «ConnectionInit». ПТС могут передавать дополнительную информацию о сессии в поле «payload». ПУ после получения данного сообщения может отправлять запросы на языке GraphQL с помощью сообщений «Subscribe» в соответствии с подпунктом 3 пункта 8 настоящего приложения.

Формат сообщения «ConnectionAck» (поле «payload» опциональное):

	{ «type»: «connection_ack», «payload»: «string» }

3) сообщение «Subscribe». Данное сообщение направляется ПУ в адрес ПТС и содержит запрос на языке GraphQL в поле «query» поля «payload». Поле «id» содержит уникальный идентификатор запроса, формируемый ПУ. Если запрос с таким идентификатором уже выполняется, то ПТС должны закрыть соединение по протоколу WebSocket с кодом 4409 и причиной закрытия «Subscriber for <unique-operation-id> already exists». Разрешается повторное использование идентификатора после завершения выполнения запроса на стороне ПТС. Если ПУ отправил данное сообщение до получения сообщения «ConnectionAck», то ПТС должны закрыть соединение по протоколу WebSocket с кодом 4401 и причиной закрытия «Unauthorized».

Формат сообщения «Subscribe» (поля «operationName», «variables», «extensions» опциональные):

	{ «id»: «<unique-operation-id>», «type»: «subscribe», «payload»: { «operationName»: «string», «query»: «string», «variables»: «string», «extensions»: «string» } }

4) сообщение «Next». Данное сообщение направляется ПТС в адрес ПУ и содержит полные или частичные результаты выполнения запроса, ранее направленного ПУ в сообщении «Subscribe». Поле «id» содержит уникальный идентификатор запроса, ранее сформированный ПУ. Поле «payload» содержит результаты выполнения запроса в формате аналогичном для конечной точки «/query» согласно спецификации языка GraphQL.

Формат сообщения «Next:

	{ «id»: «<unique-operation-id>», «type»: «next», «payload»: «ExecutionResult» }

5) сообщение «Error». Данное сообщение направляется ПТС в адрес ПУ и содержит информацию об ошибке в ходе выполнения запроса, ранее направленного ПУ в сообщении «Subscribe». Поле «id» содержит уникальный идентификатор запроса, ранее сформированный ПУ. Поле «payload» содержит информацию об ошибке в формате согласно спецификации языка GraphQL. Ошибка может возникнуть как на начальном этапе выполнения запроса (например, ошибка валидации запроса), так и в ходе выполнения запроса. После возникновения ошибки ПТС прекращают выполнение запроса и не направляют в сторону ПУ больше никаких сообщений.

Формат сообщения «Error»:

	{ «id»: «<unique-operation-id>», «type»: «error», «payload»: «GraphQLError» }

6) сообщение «Complete». Данное сообщение может направляться в обоих направлениях. Поле «id» содержит уникальный идентификатор запроса, ранее сформированный ПУ. Отправка данного сообщения от ПТС в адрес ПУ означает завершение выполнения запроса с соответствующим идентификатором. Если ранее ПТС отправили сообщение «Error», то данное сообщение не отправляется. Отправка данного сообщения от ПУ в адрес ПТС означает, что ПУ хочет прервать выполнение запроса с соответствующим идентификатором и с данного момента не принимает результаты его выполнения.

Формат сообщения «Complete:

	{ «id»: «<unique-operation-id>», «type»: «complete» }

9. Получение ПУ или ПТС иных сообщений, отличных от указанных в пункте 8 настоящего приложения, должно приводить к закрытию соединения по протоколу WebSocket с кодом 4400 и причиной закрытия, содержащей описание ошибки в типе или формате сообщения.

Приложение № 7

к Требованиям к сетям и средствам

связи собственников или иных владельцев

технологических сетей связи, имеющих

уникальный идентификатор совокупности

средств связи и иных технических средств

в сети «Интернет», для обеспечения

безопасности Российской Федерации по

направлению деятельности федеральной

службы безопасности

Требования, предъявляемые к запросам мониторинга и формату их передачи по интерфейсу взаимодействия между ПУ и ПТС

1. ПТС должны обеспечивать получение ПУ следующей информации о структуре и функционировании ПТС по запросу ПУ:

1) о структуре и составе ПТС, составе и состоянии интерфейса взаимодействия ПТС с ПУ;

2) об установленном в ПТС общесистемном ПО, перечне и состоянии программных модулей в составе ПО ПТС;

3) о точках подключения ПТС к ИС АС и интерфейсах ввода информации в ПТС.

2. ПТС по запросу ПУ должны предоставлять следующую информацию в части структуры и состава ПТС, состава и состояния интерфейса взаимодействия ПТС с ПУ:

1) перечень коммутационного и серверного оборудования, средств хранения данных с его идентификацией;

2) идентификацию интерфейсов подключения оборудования ПТС друг к другу;

3) параметры для серверного оборудования:

общий и занятый объем оперативной памяти;

количество сетевых интерфейсов с их идентификацией, нагрузку;

общее количество процессоров, загрузку;

общий объем дискового пространства, объем свободного пространства.

4) параметры технических средств хранения данных:

перечень модулей, составляющих средства хранения данных с их идентификацией;

для каждого входящего в состав средств хранения данных модуля: общий объем дискового пространства, объем свободного дискового пространства и состояние модуля (штатное функционирование, сбой, не функционирует), текстовую расшифровку сбоя.

3. ПТС по запросу ПУ должны предоставлять информацию в части точек подключения ПТС к ИС АС, интерфейсов ввода информации в ПТС, содержащую:

1) перечень точек подключения к технологической сети связи и точек ввода информации в ПТС с их идентификацией;

2) для каждой точки подключения предоставляет информацию о:

состоянии точки подключения (ввода информации) (штатное функционирование, сбой, не функционирует), текстовую расшифровку сбоя;

объеме информации, поступающей в секунду;

периоде времени, в течение которого на точку подключения и (или) ввода информации в ПТС не поступала информация.

4. ПТС по запросу ПУ должны предоставлять следующую информацию в части состава ПО ПТС и его состояния:

1) перечень установленного общесистемного ПО с его идентификацией;

2) информацию для общесистемного ПО:

идентификатор ПТС, на котором установлено ПО;

наименование ПО;

состояние ПО (штатное функционирование, сбой, не функционирует), текстовую расшифровку сбоя;

3) перечень установленного ПО ПТС с его идентификацией;

4) информацию для ПО ПТС:

идентификатор ПТС, на котором установлено ПО;

назначение (определяется разработчиком ПТС);

состояние (штатное функционирование, сбой, не функционирует), текстовую расшифровку сбоя;

список контролируемых параметров (определяется разработчиком ПТС).

5. Информация о функционировании и состоянии ПТС, указанная в пунктах 1—4 настоящего приложения, должна быть представлена в виде временных рядов (далее — метрики).
6. Метрики должны иметь следующий обязательный набор меток (пара ключ-значение):

systemtype — относится ли метрика к оборудованию или ПО. Может принимать одно из значений: «hardware» или «software»;

moduleid — идентификатор модуля;

modulename — наименование модуля;

moduletype — тип модуля;

blocknumber — номер блока оборудования;

groupname — наименование группы метрик;

softwareparentmoduleid — идентификатор модуля ПО, в состав которого входит модуль с данной метрикой;

hardwareparentmoduleid — идентификатор модуля оборудования, в состав которого входит модуль с данной метрикой.

7. Для метрик также должны быть заданы единицы измерения и описания их назначения на русском языке.
8. Для получения значений метрик ПУ направляет ПТС запросы мониторинга на конечную точку «/metric».
9. Для кодирования содержимого запросов мониторинга и ответов должен применяться формат JSON.
10. ПТС при успешном выполнении запросов мониторинга должны возвращать HTTP код 2xx.
11. ПТС при возникновении ошибки во время выполнения запросов мониторинга должны в ответе возвращать поле «error» с информацией об ошибке и следующие HTTP коды:

400 Bad Request — в запросе отсутствуют или некорректно заданы параметры;

422 Unprocessable Entity — неправильный формат запроса на языке PromQL в соответствии с пунктом 13 настоящего приложения;

503 Service Unavailable — выполнение запроса прервано на стороне ПТС.

12. Ответы на запросы мониторинга должны иметь следующий формат:

	{ «status»: «success» | «error», «data»: <data>, «errorType»: «<string>», «error»: «<string>», «warnings»: [«<string>»] }

Поле «status» — статус выполнения запроса, может принимать одно из двух значений: «success» или «error».

Поле «data» — результат выполнения запроса, структура поля зависит от конечной точки, на которую был отправлен запрос (в соответствии с пунктом 13 настоящего приложения).

Поля «errorType» и «error» — соответственно тип и описание ошибки, возникшей при выполнении запроса. Данные поля должны быть задана только, если поле «status» имеет значение «error».

Поле «warnings» — незначительные ошибки (предупреждения), возникшие во время выполнения запроса, но существенно не повлиявшие на его выполнение. При этом поле «data» может содержать частичные результаты выполнения запроса.

13. ПТС должны реализовывать внутри конечной точки «/metric» следующие дополнительные конечные точки:

1) «/api/v1/query» — предназначена для приема запросов мониторинга от ПУ в целях получения метрик для конкретного значения времени, а также передачи на ПУ результатов выполнения данных запросов. Данная конечная точка должна поддерживать HTTP методы GET и POST.

Принимаемые параметры:

«query» — запрос на языке PromQL;

«time» (опционально) — дата и время в формате согласно RFC3339 или Unix-время;

«duration» (опционально) — период времени в формате согласно Time Durations языка PromQL.

Поле «data» для ответа на запросы мониторинга для данной конечной точки должно иметь следующий вид:

	{ «resultType»: «matrix» | «vector» | «scalar» | «string», «result»: <value> }

Формат поля «result» зависит от значения поля «resultType», согласно пункту 14 настоящего приложения;

2) «/api/v1/query_range» — предназначена для приема запросов мониторинга от ПУ в целях получения метрик для диапазона времени, а также передачи на ПУ результатов выполнения данных запросов. Данная конечная точка должна поддерживать HTTP методы GET и POST.

Принимаемые параметры:

«query» — запрос на языке PromQL;

«start» — дата и время начала диапазона в формате согласно RFC3339 или Unix-время;

«end» — дата и время конца диапазона в формате согласно RFC3339 или Unix-время;

«step» — временной шаг запроса в формате согласно Time Durations языка PromQL или число с плавающей точкой;

«duration» (опционально) — период времени в формате согласно Time Durations языка PromQL.

Поле «data» для ответа на запросы мониторинга для данной конечной точки должно иметь следующий вид:

	{ «resultType»: «matrix», «result»: <value> }

Формат поля «result» представлен в подпункте 1 пункта 14 настоящего приложения;

3) «/api/v1/series» — предназначена для приема запросов мониторинга от ПУ в целях получения списка метрик, которые имеют заданный набор меток, а также передачи на ПУ результатов выполнения данных запросов. Данная конечная точка должна поддерживать HTTP методы GET и POST.

Принимаемые параметры:

«match[]» — перечень запрашиваемых меток в формате Time series Selectors языка PromQL;

«start» — дата и время начала диапазона в формате согласно RFC3339 или Unix-время;

«end» — дата и время конца диапазона в формате согласно RFC3339 или Unix-время.

Поле «data» для ответа на запросы мониторинга для данной конечной точки должно содержать перечень метрик (представляются перечнем их меток (пара ключ-значение), удовлетворяющих критериям запроса;

4) «/api/v1/labels» — предназначена для приема запросов мониторинга от ПУ в целях получения списка меток, которые имеют заданный набор метрик, а также передачи на ПУ результатов выполнения данных запросов. Данная конечная точка должна поддерживать HTTP методы GET и POST.

Принимаемые параметры:

«match[]» (опционально) — перечень запрашиваемых метрик в формате Time series Selectors языка PromQL;

«start» (опционально) — дата и время начала диапазона в формате согласно RFC3339 или Unix-время;

«end» (опционально) — дата и время конца диапазона в формате согласно RFC3339 или Unix-время.

Поле «data» для ответа на запросы мониторинга для данной конечной точки должно содержать перечень названий меток, удовлетворяющих критериям запроса;

5) «/api/v1/label/<label_name>/values» — предназначена для приема запросов мониторинга от ПУ в целях получения значений заданных меток, а также передачи на ПУ результатов выполнения данных запросов. Данная конечная точка должна поддерживать HTTP метод GET.

Принимаемые параметры:

«match[]» (опционально) — перечень запрашиваемых метрик в формате Time series Selectors языка PromQL;

«start» (опционально) — дата и время начала диапазона в формате согласно RFC3339 или Unix-время;

«end» (опционально) — дата и время конца диапазона в формате согласно RFC3339 или Unix-время.

Поле «data» для ответа на запросы мониторинга для данной конечной точки должно содержать перечень значений меток, удовлетворяющих критериям запроса.

14. Поле «result» в ответах на запросы мониторинга может иметь один из следующих форматов:

1) если поле «resultType» имеет значение «matrix», то поле «result» должно иметь следующий формат:

	[ { «metric»: {«<label_name>»: «<label_value>», … }, «values»: [[<unix_time>, «<sample_value>»], … ], «histograms»: [[<unix_time>, <histogram>], … ] }, … ]

2) если поле «resultType» имеет значение «vector», то поле «result» должно иметь следующий формат:

	[ { «metric»: {«<label_name>»: «<label_value>», … }, «value»: [<unix_time>, «<sample_value>»], «histogram»: [<unix_time>, <histogram>], }, … ]

3) если поле «resultType» имеет значение «scalar», то поле «result» должно иметь следующий формат:

	[<unix_time>, «<scalar_value>»]

4) если поле «resultType» имеет значение «string», то поле «result» должно иметь следующий формат:

	[<unix_time>, «<string_value>»]