Приказ Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 16.12.2025 № 1174"Об утверждении Требований к сетям и средствам связи собственников или иных владельцев технологических сетей связи, имеющих уникальный идентификатор совокупности средств связи и иных технических средств в информационно-телекоммуникационной сети "Интернет", для проведения уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность или обеспечение безопасности Российской Федерации, в случаях, установленных федеральными законами, мероприятий в целях реализации возложенных на них задач"

1. ПТС подключаются к ПУ в точках подключения выделенных каналов связи.

2. Для передачи данных между ПУ и ПТС должен использоваться набор протоколов TCP/IP.

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

4. Посредством использования ПТС обеспечивается возможность создания виртуальной сети VPN (Virtual Private Network) между ПТС и ПУ.

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

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

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

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

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

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

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

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

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

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

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

8. Единый канал передачи данных создается для подключения к ПТС в виде TCP-соединений. Посредством использования ПТС должен выполняться мониторинг данного порта для создания TCP-соединений с ПУ.

9. ПУ должен осуществлять попытки установления подключения к ПТС в соответствии с задаваемым интервалом по предоставленному ПТС ТСР-порту.

10. Обмен данными в едином канале передачи данных на прикладном уровне должен осуществляться по протоколам HTTP 1.1 и WebSocket.

11. В ПТС должны поддерживаться четыре интерфейса (endpoints) взаимодействия с ПУ:

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

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

3) "/download" - для получения от ПУ запросов неформатированных данных и передачи на ПУ результатов выполнения данных запросов;

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

12. Обмен данными для конечных точек "/query", "/download" и "/metric" должен осуществляться по протоколу HTTP 1.1, для конечной точки "/subscription" - по протоколу WebSocket. ПУ и ПТС для конечной точки "/subscription" должны поддерживать сетевое соединение с помощью механизмов протокола WebSocket.

13. Собственники или иные владельцы технологических сетей связи, имеющие уникальный идентификатор совокупности средств связи и иных технических средств в сети "Интернет", обязаны реализовать механизм запросов и ответов в ПТС для конечных интерфейсов "/query" и "/subscription" с использованием версии языка описания данных и запросов GraphQL. Для кодирования содержимого запросов и ответов необходимо применять формат JSON.

14. Посредством использования ПТС должен обеспечиваться функционал передачи данных на языке GraphQL по протоколу WebSocket до конечной точки "/subscription". В соответствии с требованиями, предъявляемыми к формату передачи данных на языке GraphQL по протоколу WebSocket для конечной точки "/subscription", приведенными в приложении № 6 к Требованиям к ПТС.

15. Посредством использования ПТС должен обеспечиваться функционал передачи данных до конечной точки "/metric". В соответствии с требованиями, предъявляемыми к формату передачи данных для конечной точки "/metric", приведенными в приложении № 7 к Требованиям к ПТС.

16. Собственники или иные владельцы технологических сетей связи, имеющие уникальный идентификатор совокупности средств связи и иных технических средств в сети "Интернет", обязаны реализовать механизм запросов и ответов в ПТС для конечной точки "/download" с использованием протокола HTTP 1.1. ПТС для данной конечной точки должны поддерживать механизм передачи данных по частям и механизм частичных запросов.

17. Если результаты выполнения поисковых запросов и запросов постановки объектов на контроль для конечных точек "/query" и "/subscription" содержат неформатированные данные (файлы), то ответ ПТС должен содержать вместо непосредственно неформатированных данных (файлов) ссылки (HTTP URI в полном формате согласно RFC7230 http(s)://<IР-адрес или доменное имя ПTC>:<пopт>/download/<yникaльный путь к файлу>) для каждого файла для конечной точки "/download". В ПТС должна поддерживаться функциональная возможность автоматического формирования уникальной ссылки для каждого файла.

18. Для получения неформатированных данных, ссылки на которые содержатся в ответе ПТС на поисковый запрос, посредством использования ПУ для каждого файла автоматически инициируется запрос на конечную точку "/download" отдельные (от поисковых запросов) запросы получения неформатированных данных (HTTP GET-запросы) в ПТС, содержащие ссылку на запрашиваемые данные.

19. Для отправления на ПУ текущей схемы данных посредством использования ПТС необходимо получить запрос "getSchema" согласно приложению № 4 к Требованиям к ПТС на конечную точку "/query". В ответ посредством использования ПТС автоматически направляется схема данных, описанная на языке SDL GraphQL.

20. Поисковые запросы должны выполняться в ПТС в двух режимах: режиме реального времени и отложенном режиме (далее - отложенный поисковый запрос). Режим выполнения поисковых запросов определяется ПТС в соответствии с установленными временными параметрами согласно пункту 12 Требований к ПТС и параметрами запроса (количество запрашиваемых полей и критериев поиска), количества данных, хранящихся в ИС, и производительностью ПТС. Посредством использования ПТС принимаются все поисковые запросы на конечную точку "/query".

21. В ПТС должна поддерживаться функциональная возможность выполнения поисковых запросов только с критериями поиска, заданными на верхнем уровне запроса (без вложенных объектов "and", "or", "not"), включая базовые фильтры, согласно пункту 8 приложения № 2 к Требованиям к ПТС при следующих условиях:

по согласованию с уполномоченными государственными органами, осуществляющими оперативно-разыскные мероприятия или обеспечение безопасности Российской Федерации в соответствии с правилами взаимодействия, если среднесуточный объем новых данных, поступающих в ИС, составляет от 1 до 10 Гбайт;

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

22. В ПТС до получения поисковых запросов с ПУ должно обеспечиваться выполнение запроса "statusOfflineRequest" (запрос "Subscription" языка GraphQL) через интерфейс "/subscription" по протоколу WebSocket в соответствии с приложением № 4 к Требованиям к ПТС.

23. В режиме реального времени посредством использования ПТС должно автоматически поддерживаться сетевое соединение, по которому поступил запрос от ПУ, и результаты выполнения запроса должны передаваться от ПТС на ПУ по тому же сетевому соединению, не позднее установленных временных параметров согласно пункту 22 настоящего приложения к Требованиям к ПТС.

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

1) получение от ПУ поискового запроса на конечную точку "/query";

2) автоматическое определение способа выполнения запроса;

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

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

5) отправка в непрерывном режиме уведомления на ПУ (путем ответа на запрос "statusOfflineRequest") на интерфейс "/subscription" по протоколу WebSocket согласно пункту 22 настоящего приложения к Требованиям к ПТС об изменениях статуса выполнения отложенного поискового запроса.

Посредством использования ПТС должны поддерживаться следующие статусы выполнения отложенного запроса:

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

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

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

"ABORTED" - выполнение запроса прервано сервером;

"CANCELED" - запрос отменен со стороны ПУ;

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

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

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

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

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

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

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

28. В ПТС должна обеспечиваться функциональная возможность получения запросов постановки объектов на контроль от ПУ через интерфейс "/subscription" по протоколу WebSocket. После получения запроса с ПТС автоматически направляются на ПУ результаты выполнения данного запроса по мере появления новых данных (с момента получения запроса) в ИС, соответствующих критериям отбора, заданным в запросе ПУ. Передача результатов выполнения запросов постановки объектов на контроль осуществляется в непрерывном режиме, без дополнительных запросов от ПУ.

29. Для снятия объектов с контроля на ПТС должно быть получено сообщение "Complete" от ПУ в соответствии с подпунктом 6 пункта 8 приложения № 6 к Требованиям к ПТС на интерфейс "/subscription" по протоколу WebSocket. После получения сообщения "Complete" должно прекратиться исполнение запроса постановки объекта на контроль и передача на ПУ результатов выполнения данного запроса.

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

1) "Перезапуск программного обеспечения" ("RESTARTDB");

2) "Попытка несанкционированного доступа" ("UNAUTHORIZED ACCESS");

3) "Критическая ошибка программного обеспечения, потеря данных, дальнейшая работа невозможна" ("CRITICALERROR");

4) "Серьезная ошибка программного обеспечения, потеря данных, но дальнейшая работа возможна" ("MAJORERROR");

5) "Незначительная ошибка программного обеспечения, данные не потеряны, дальнейшая работа возможна" ("MINORERROR");

6) "Изменение схемы данных" ("SCHEMACHANGED");

7) "Предупреждение о проблеме с контролируемыми параметрами (метриками)" ("METRICALERTS"). Для данного сигнала ПТС должны возвращать дополнительную информацию о предупреждениях, указанную в приложении № 4 к Требованиям к ПТС. Список контролируемых метрик и предупреждений о проблемах с ними определяется разработчиком ПТС и согласовывается с уполномоченными государственными органами, осуществляющими оперативно-разыскные мероприятия или обеспечение безопасности Российской Федерации.

31. Для отправки на ПУ сигналов в ПТС необходимо предусмотреть функциональную возможность исполнения запроса от ПУ "trap" (запрос Subscription языка GraphQL) через интерфейс "/subscription" по протоколу WebSocket. Посредством использования ПТС автоматически в непрерывном режиме (без дополнительных запросов от ПУ) отправляются на ПУ сигналы сразу после их возникновения на ПТС. Если в момент получения запроса "trap" на ПТС есть сигналы, которые не были отправлены ранее ПУ, то посредством использования ПТС должна быть обеспечена передача на ПУ данных сигналов.

32. В ПТС должны быть предусмотрены следующие коды ошибок для языка GraphQL:

33. В ПТС должно обеспечиваться выполнение всех запросов мониторинга и неформатированных данных, поступающих на ПТС от ПУ, в режиме реального времени.