Приложение N 2

к требованиям к вычислительной

мощности, используемой провайдером

хостинга, для проведения уполномоченными

государственными органами, осуществляющими

оперативно-разыскную деятельность

или обеспечение безопасности

Российской Федерации, в случаях,

установленных федеральными законами,

мероприятий в целях реализации

возложенных на них задач, утвержденным

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

развития, связи и массовых

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

от 1 ноября 2023 г. N 935

ТРЕБОВАНИЯ,

ПРЕДЪЯВЛЯЕМЫЕ К ИНТЕРФЕЙСУ ВЗАИМОДЕЙСТВИЯ МЕЖДУ ПУНКТОМ

УПРАВЛЕНИЯ И ТЕХНИЧЕСКИМИ СРЕДСТВАМИ, ОБЕСПЕЧИВАЮЩИМИ

ВЫПОЛНЕНИЕ УСТАНОВЛЕННЫХ ДЕЙСТВИЙ ПРИ ПРОВЕДЕНИИ

ОПЕРАТИВНО-РАЗЫСКНЫХ МЕРОПРИЯТИЙ

1. Интерфейсы взаимодействия ТС ОРМ с ПУ должны быть организованы по выделенным каналам связи.

2. В качестве набора протоколов передачи данных следует использовать набор протоколов TCP/IP.

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

4. ТС ОРМ должны предусматривать возможность создания виртуальной сети VPN (Virtual Private Network) для туннелирования всего рабочего TCP/IP трафика между ТС ОРМ и ПУ.

5. Взаимодействие ТС ОРМ с оборудованием ПУ на транспортном уровне должно осуществляться по схеме "клиент - сервер":

1) в качестве "сервера" выступают ТС ОРМ;

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

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

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

1) от ПУ в ТС ОРМ поисковых запросов;

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

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

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

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

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

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

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

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

9. Установление соединения ТС ОРМ с ПУ осуществляется по согласованному с уполномоченным государственным органом ТСР-порту с заданным временным интервалом.

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

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

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

2) "/subscription" - для получения от ПУ статуса выполнения поисковых запросов ТС ОРМ, которые выполняются в отложенном режиме (согласно пункта 20 настоящего приложения) и сигналов о функционировании ТС ОРМ согласно пункта 23 настоящего приложения.

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

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

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

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

14. Требования, предъявляемые к формату передачи данных на языке GraphQL по протоколу WebSocket для интерфейса "/subscription", приведены в приложении N 7 к настоящим требованиям.

15. Требования, предъявляемые к запросам мониторинга и формату их передачи по интерфейсу взаимодействия между ПУ и ТС ОРМ для интерфейса "/metric", приведены в приложении N 8 к настоящим требованиям.

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. Для получения текущей схемы данных согласно приложению N 3 к требованиям, утвержденным настоящим приказом, ТС ОРМ необходимо предусмотреть возможность получения запроса "getSchema" согласно приложению N 5 к требованиям, утвержденным настоящим приказом, на интерфейс "/query". В ответ ТС ОРМ должны направить схему данных, описанную на языке SDL GraphQL.

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

21. ТС ОРМ должны выполнять поисковые запросы в соответствии с критериями поиска, заданными на верхнем уровне запроса без вложенных объектов, согласно пункту 10 приложения N 3 к требованиям, утвержденным настоящим приказом, при следующих условиях:

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

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

22. В режиме реального времени ТС ОРМ должны поддерживать (не разрывать) сетевое соединение, по которому поступил запрос от ПУ, и результаты выполнения запроса должны передаваться от ТС ОРМ на ПУ по тому же сетевому соединению, не позднее установленных временных параметров согласно пункту 21 настоящих требований.

23. Отложенный поисковый запрос выполняется по следующему сценарию:

1) ПУ направляет поисковый запрос ТС ОРМ на интерфейс "/query";

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

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

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

5) ПУ отправляет запрос "statusOfflineRequest" (запрос Subscription языка GraphQL), содержащий полученный от ТС ОРМ идентификатор отложенного поискового запроса, на интерфейс "/subscription" по протоколу WebSocket (согласно приложению N 5 к настоящим требованиями). ТС ОРМ в непрерывном режиме (без дополнительных запросов от ПУ) уведомляют ПУ об изменениях статуса выполнения отложенного поискового запроса.

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

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

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

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

ABORTED - выполнение запроса прервано (на стороне сервера - ТС ОРМ);

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

6) при получении от ТС ОРМ на ПУ уведомления о завершении выполнения отложенного поискового запроса (статус "READY"), ПУ направляет запрос "getOfflineRequest" согласно приложению N 5 к требованиям, утвержденным настоящим приказом, на интерфейс "/query" с указанием идентификатора запроса. ТС ОРМ должны осуществлять передачу на ПУ результатов выполнения отложенных запросов и запросов в режиме реального времени постранично, согласно подпункту 2 пункта 10 приложения N 3 к требованиям, утвержденным настоящим приказом;

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

8) в момент выполнения отложенного запроса (от момента получения идентификатора запроса от ТС ОРМ до получения статуса выполнения запроса "READY") ПУ может прервать данную операцию, направив запрос "_cancelOfflineRequest" согласно приложению N 5 к требованиям, утвержденным настоящим приказом) на интерфейс "/query" с указанием идентификатора запроса. В ответ ТС ОРМ должны направить результат выполнения данного запроса.

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

24. ТС ОРМ должны хранить результаты выполнения отложенных запросов согласно пункту 21 настоящих требований и незамедлительно их удалять при получении запроса от ПУ.

Для удаления на ТС ОРМ результатов выполнения отложенного поискового запроса ПУ направляет запрос "_delOfflineRequest" согласно приложению N 5 к требованиям, утвержденным настоящим приказом, на интерфейс "/query" с указанием идентификатора запроса. В ответ ТС ОРМ направляют результат выполнения данного запроса.

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

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

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

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

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

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

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

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

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

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

27. Все запросы мониторинга и неформатированных данных должны выполняться в режиме реального времени.

28. ТС ОРМ должны использовать следующие коды ошибок для языка GraphQL: