Куда я попал?
Приказ Минцифры № 935 от 01.11.2023
Об утверждении требований к вычислительной мощности, используемой провайдером хостинга, для проведения УГО, осуществляющими ОРД или обеспечение безопасности РФ, в случаях, установленных ФЗ, мероприятий в целях реализации возложенных на них задач
Требования к вычислительной мощности, используемой провайдером хостинга, для проведения уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность или обеспечение безопасности Российской Федерации, в случаях, установленных федеральными законами, мероприятий в целях реализации возложенных на них задач
Для проведения оценки соответствия по документу войдите в систему.
Для оценки соответствия
- авторизуйтесь
- авторизуйтесь
Планируемый уровень
Текущий уровень
Группы областей
66
%
Входящая логистика
48
%
Создание продукта
72
%
Исходящая логистика
43
%
Маркетинг, продажа
67
%
Обслуживание клиента
45
%
Инфраструктура
37
%
HR-менеджмент
82
%
Технологии
95
%
Закупки / Снабжение
82
%
Опыт клиента
Список требований
-
7. С использованием ТС ОРМ провайдера хостинга должны обеспечиваться поиск согласованной с уполномоченным государственным органом, определяемым в порядке, установленном Правительством Российской Федерации в соответствии с частью 3 статьи 10.2-1 Федерального закона от 27 июля 2006 г. N 149-ФЗ "Об информации, информационных технологиях и о защите информации", информации, хранящейся в ИС и обрабатываемой с использованием ТС ОРМ провайдера хостинга согласно приложению N 1 к настоящим требованиям, а также поддерживать согласованную с уполномоченным государственным органом схему ее предоставления.
-
18. С использованием ТС ОРМ реализуются:1) подключение к ПУ в соответствии техническими условиями, согласованными с уполномоченным государственным органом;2) протокол взаимодействия ТС ОРМ с ПУ в соответствии с приложением N 2 к настоящим требованиям;3) прием от ПУ поисковых запросов;4) поиск информации, хранящейся в ИС, в соответствии с поступившими с ПУ поисковыми запросами. Для ТС ОРМ, осуществляющих поиск информации в ИС со среднесуточным объемом новых данных свыше 1 Гбайт, устанавливаются требования к поддерживаемым критериям поиска согласно пункту 21 приложения N 2 к настоящим требованиям;5) передача от ТС ОРМ на ПУ данных в соответствии с поступившими с ПУ поисковыми запросами (в том числе постранично);6) прием от ПУ критериев поиска и передачу на ПУ статистической, текстовой, мультимедийной, звуковой, графической и иной информации в исходном (декодированном) виде, хранящейся в ИС и отбираемой по критериям поиска, без дополнительной обработки (далее - неформатированные данные);7) передача на ПУ схемы данных, в соответствии с поступившим с ПУ специальным запросом согласно приложению N 5 к настоящим требованиям;8) защита от несанкционированного доступа со стороны производителей ТС ОРМ, неавторизованных пользователей, технического персонала, третьих лиц к хранящейся в ТС ОРМ информации и информации, непосредственно связанной с проведением ОРМ (информации, поступающей в ТС ОРМ с ПУ, и информации, подготовленной к передаче из ТС ОРМ в ПУ);9) информирование ПУ о следующих попытках несанкционированного доступа к ТС ОРМ:
- доступ к данным, связанным с проведением ОРМ, с использованием команд или сервисных программ;
- резервное копирование данных, связанных с проведением ОРМ;
- доступ к ТС ОРМ через интерфейсы, не предусмотренные для доступа к ним;
- вскрытие корпуса технических средств ОРМ (для варианта исполнения ТС ОРМ в виде отдельного аппаратно-программного комплекса и для комбинированного варианта исполнения ТС ОРМ);
10) контроль работоспособности и загруженности ТС ОРМ;11) контроль за соблюдением предоставленных прав доступа к хранящейся в ТС ОРМ информации;12) круглосуточный удаленный доступ со стороны операторов ПУ к хранящейся в ИС информации по протоколу взаимодействия ПУ и ТС ОРМ, описанному в приложении N 2 к настоящим требованиям;13) ведение в автоматическом режиме системных журналов, содержащих информацию о работе ТС ОРМ, а также связанных с проведением ОРМ данных:- о сеансах связи с ПУ, а также о попытках установления таких сеансов;
- о поисковых запросах;
- об ответах на поисковые запросы;
- о текущей конфигурации ТС ОРМ, системного и прикладного ПО;
- об изменениях в конфигурации ТС ОРМ, системного и прикладного ПО;
- о сбоях в ТС ОРМ, системном и прикладном ПО;
- об изменениях схемы данных;
- об обращении и доступе обслуживающего технического персонала к ТС ОРМ;
14) доступ уполномоченного технического персонала для обслуживания ТС ОРМ в соответствии с установленными правами доступа;15) доступ технического персонала к системным файлам и ПО, в соответствии с правами, установленными парольной системой доступа;16) сохранность и доступность для дальнейшего использования ранее накопленных данных при модернизации ТС ОРМ;17) автоматическое определение способа выполнения поисковых запросов (в режиме реального времени или в отложенном режиме согласно пункту 20 приложения N 2 к настоящим требованиям), поступивших с ПУ, в соответствии с заданными временными параметрами;18) временное хранение результатов выполнения поисковых запросов в отложенном режиме с учетом заданных временных параметров (согласно пункту 21 настоящих требований). -
21. Максимальное время предварительной обработки информации с момента ее поступления в ТС ОРМ до момента, когда она становится доступной для выполнения поисковых запросов с ПУ, и максимальное время выполнения поисковых запросов определено в ходе внедрения ТС ОРМ в информационную систему провайдера хостинга. ТС ОРМ провайдеров хостинга должны соблюдать согласованные с уполномоченным государственным органом временные параметры для определения способа выполнения поисковых запросов (в режиме реального времени или в отложенном режиме, пункт 20 приложения N 2 к настоящим требованиям) и максимального времени хранения результатов выполнения поисковых запросов в отложенном режиме должны.
-
19. Для получения текущей схемы данных согласно приложению N 3 к требованиям, утвержденным настоящим приказом, ТС ОРМ необходимо предусмотреть возможность получения запроса "getSchema" согласно приложению N 5 к требованиям, утвержденным настоящим приказом, на интерфейс "/query". В ответ ТС ОРМ должны направить схему данных, описанную на языке SDL GraphQL.
-
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" с указанием идентификатора запроса. ТС ОРМ должны осуществлять передачу на ПУ результатов выполнения отложенных запросов и запросов в режиме реального времени постранично, согласно пункту 10 приложения N 3 к требованиям, утвержденным настоящим приказом;7) в ответ на полученный запрос ТС ОРМ должны передавать на ПУ результаты выполнения отложенного поискового запроса в режиме реального времени в формате JSON. Структура результатов выполнения отложенного поискового запроса должна соответствовать структуре исходного поискового запроса, направленного ПУ на интерфейс "/query";8) в момент выполнения отложенного запроса (от момента получения идентификатора запроса от ТС ОРМ до получения статуса выполнения запроса "READY") ПУ может прервать данную операцию, направив запрос "_cancelOfflineRequest" согласно приложению N 5 к требованиям, утвержденным настоящим приказом) на интерфейс "/query" с указанием идентификатора запроса. В ответ ТС ОРМ должны направить результат выполнения данного запроса.ТС ОРМ должны удалять промежуточные результаты прерванного отложенного запроса. -
24. ТС ОРМ должны хранить результаты выполнения отложенных запросов согласно пункту 21 настоящих требований и незамедлительно их удалять при получении запроса от ПУ.
Для удаления на ТС ОРМ результатов выполнения отложенного поискового запроса ПУ направляет запрос "_delOfflineRequest" согласно приложению N 5 к требованиям, утвержденным настоящим приказом, на интерфейс "/query" с указанием идентификатора запроса. В ответ ТС ОРМ направляют результат выполнения данного запроса. -
26. ТС ОРМ должны осуществлять контроль функционирования собственных параметров и передачу на ПУ следующих сигналов:
- "Перезапуск ПО" (RESTARTDB);
- "Попытка несанкционированного доступа" (UNAUTHORIZEDACCESS);
- "Критическая ошибка ПО, потеря данных, дальнейшая работа невозможна" (CRITICALERROR);
- "Серьезная ошибка ПО, потеря данных, но дальнейшая работа возможна" (MAJORERROR);
- "Незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна" (MINORERROR);
- "Изменение схемы данных" (SCHEMACHANGED);
- "Предупреждение о проблеме с контролируемыми параметрами (метриками)" (METRICALERTS). Для данного сигнала ТС ОРМ должны возвращать на ПУ дополнительную информацию о предупреждениях (согласно приложению N 5 к настоящим требованиями). ТС ОРМ должны осуществлять обработку контролируемых метрик и предупреждений о проблемах согласованные с уполномоченным государственным органом.
Для получения сигналов ПУ необходимо отправить запрос "_trap" (запрос Subscription языка GraphQL) на интерфейс "/subscription" по протоколу WebSocket согласно приложению N 5 к требованиям, утвержденным настоящим приказом. ТС ОРМ в непрерывном режиме (без дополнительных запросов от ПУ) отправляет ПУ сигналы сразу после их возникновения на ТС ОРМ. Если в момент получения запроса "_trap" на ТС ОРМ есть сигналы, которые не были отправлены ранее ПУ (по причине разрыва соединения или по иным причинам), то ТС ОРМ должны незамедлительно передать на ПУ все данные сигналы. -
5. Для схемы данных определяется перечень базовых типов. Базовый тип данных на языке GraphQL должен содержать информацию, которая должна быть доступна для поиска в ТС ОРМ по запросам ПУ. Перечень базовых типов отражает перечень идентифицирующих признаков объектов физического мира (в том числе, номер паспорта, номер телефона, банковские реквизиты, государственный регистрационный номер транспортного средства). Перечень базовых типов и их определения на языке GraphQL приведены в приложении N 4 к требованиям, утвержденным настоящим приказом.
-
6. Для схемы данных определяется перечень сервисных типов. Сервисный тип данных на языке GraphQL должен отражать информацию о схеме данных, или описывать HTTP URI для неформатированных данных, или предназначаться для получения статуса отложенных поисковых запросов или сигналов о функционировании ТС ОРМ. Перечень сервисных типов, их определения и запросы для доступа к информации на языке GraphQL приведены в приложении N 4 к требованиям, утвержденным настоящим приказом.
-
8. Схема данных в части базовых, пользовательских и сервисных типов должна удовлетворять следующим требованиям:1) каждое поле пользовательского типа, которое отражает идентифицирующий признак объекта физического мира и будет доступно в качестве критерия поиска в ТС ОРМ по запросам ПУ, должно представляться базовым типом (или его списком);2) поля пользовательского типа, которые представляют собой ссылки (HTTP URI) на неформатированные данные (файлы), должны представляться сервисным типом "Media", определенным в приложении N 5 к требованиям, утвержденным настоящим приказом;3) остальные поля пользовательских типов (то есть за исключением указанных в подпунктах 1 и 2 настоящего пункта) должны описываться встроенными типами языка GraphQL или любыми другими пользовательскими типами, определенными в схеме данных;4) для каждого пользовательского типа, имеющего хотя бы одно поле базового типа, или связанного с другим пользовательским типом, имеющим хотя бы одно поле базового типа, должны быть определены следующие объекты языка GraphQL: тип для представления результатов выполнения поисковых запросов и входной объект для задания параметров поиска (далее - входной объект);5) тип для представления результатов выполнения поисковых запросов должен иметь следующую структуру:
Имя поля | Тип поля | Назначение поля cursor | String | значение курсора для последнего элемента списка (поле "result") с результатами выполнения поискового запроса для данного пользовательского типа hasNextPage | Boolean | признак наличия следующей страницы с результатами выполнения поискового запроса для данного пользовательского типа (может использоваться с любым видом постраничного получения результатов выполнения запроса) result | список соответствующего пользовательского типа | результат выполнения поискового запроса для данного пользовательского типа
Формат типа для представления результатов выполнения поисковых запросов должен быть следующим:type {{UserTypeResult}} { cursor: String hasNextPage: Boolean result: [{{UserType}}!] },
в котором:- {{UserTypeResult}} - произвольное имя типа для представления результатов выполнения поисковых запросов,
- {{UserType}} - имя пользовательского типа, для которого определен тип {{UserTypeResult}};
6) каждый входной объект для пользовательского типа должен иметь следующую структуру:Имя поля | Тип поля | Назначение поляand | список исходных входных объектов | для задания параметров поиска с логической функцией "И" or | список исходных входных объектов | для задания параметров поиска с логической функцией "ИЛИ" not | исходный входной объект | для задания параметров поиска с логической функцией "НЕ" все имена полей пользовательского типа, представленные базовыми типами | входные объекты для базовых типов, определенные в приложении N 5 к требованиям, утвержденным настоящим приказом | для задания параметров поиска конкретных полей пользовательского типа, представленных базовыми типами
Формат входного объекта для пользовательского типа:input {{UserTypeFilterInput}} { and: [{{UserTypeFilterInput}}] or: [{{UserTypeFilterInput}}] not: {{UserTypeFilterInput}} {{baseField1}}: {{BaseFilterInput1}} ... {{baseFieldN}}: {{BaseFilterInputN}} },
в котором:- {{UserTypeFiiterInput}} - произвольное имя входного объекта для пользовательского типа,
- {{baseField1}...{{baseFieldN}} - поля пользовательского типа, представленные одним из базовых типов,
- {{baseFilterInput1}}...{{baseFilterInputN}} - входные объекты для базовых типов, определенные в приложении N 6 к требованиям, утвержденным настоящим приказом;
7) все пользовательские типы, их поля и аргументы должны иметь описание на русском языке;
8) связь между двумя произвольными пользовательскими типами должна быть двухсторонней за исключением случаев, если один из пользовательских типов не имеет ни одного поля базового типа;9) схема данных должна содержать все сервисные типы из перечня, определенного в приложении N 6 к настоящим требованиям. -
1. Схема данных, описанная на языке SDLСервисный тип: Отсутствует
Запрос:type Query { """ Запрос схемы данных """ getSchema: String! }
Описание запроса: Запрос схемы данных, описанной на языке SDL GraphQL2. Идентификатор отложенного запроса
Сервисный тип: Отсутствует
Запрос:type Query { """ Запрос результата выполнения отложенного запроса """ getOfflineRequest (requestID: String!, offset: Int, limit: Int, cursor: String): QueryMessage!}
Описание запроса: Запрос результата выполнения отложенного запроса по его идентификатору либо постраничное получение результатов с использованием аргументов "offset", "limit" и "cursor" согласно пункту 9 приложения N 2 к требованиям, утвержденным настоящим приказом. Ответ (результат выполнения запроса) предоставляется в виде данных в формате JSON в соответствии с изначальным GraphQL запросом. Если отложенный запрос с указанным идентификатором не найден, то должно быть возвращено сообщение об ошибке GraphQL с кодом REQUEST_NOT_FOUND. Если отложенный запрос еще не выполнен или результаты его выполнения уже удалены, то должно быть возвращено сообщение об ошибке GraphQL с кодом NO_REQUEST_RESULT.
Запрос:type Query { """ Удаление результатов отложенного запроса """ delOfflineRequest (requestID: String!): Boolean! }
Описание запроса: Удаление результатов отложенного запроса по его идентификатору. Если удаление произошло успешно, то должен быть возвращен ответ True. Если удаление не удалось выполнить, то должен быть возвращен ответ False и описание ошибки GraphQL. Если отложенный запрос с указанным идентификатором не найден, то должно быть возвращено сообщение об ошибке GraphQL с кодом REQUEST_NOT_FOUND.
Запрос:type Query { """ Отмена выполнения отложенного запроса """ cancelOfflineRequest (requestID: String!): Boolean! }
Описание запроса: Прерывание (отмена) выполнения отложенного запроса по его идентификатору. Если прерывание произошло успешно, то должен быть возвращен ответ True. Если прерывание не удалось выполнить, то должен быть возвращен ответ False и описание ошибки GraphQL. Если отложенный запрос с указанным идентификатором не найден, то должно быть возвращено сообщение об ошибке GraphQL с кодом REQUEST_NOT_FOUND. -
8. ТС ОРМ и ПУ взаимодействуют по протоколу WebSocket с использованием следующих типов сообщений:
- сообщение "ConnectionInit". Данное сообщение направляется ПУ в адрес ТС ОРМ для открытия сессии. ПУ может передавать дополнительную информацию о сессии в поле "payload". ТС ОРМ должны получить данное сообщение в течение заданного периода времени (определяется во время внедрения ТС ОРМ и согласовывается с уполномоченным государственным органом). В случае не поступления от ПУ в ТС ОРМ данного сообщения в течение заданного периода времени, ТС ОРМ должны закрыть соединение по протоколу WebSocket с кодом 4408 и причиной закрытия "Connection initialization timeout". В случае получения ТС ОРМ более одного сообщения "ConnectionInit", ТС ОРМ должны закрыть соединение по протоколу WebSocket с кодом 4429 и причиной закрытия "Too many initialization requests".
Формат сообщения "ConnectionInit" (поле "payload" опциональное):{ "type": "connection_init", "payload": "string" }
- сообщение "ConnectionAck". Данное сообщение подтверждает успешное создание сессии и направляется ТС ОРМ в адрес ПУ в ответ на сообщение "ConnectionInit". ТС ОРМ могут передавать дополнительную информацию о сессии в поле "payload". ПУ после получения данного сообщения может отправлять запросы на языке GraphQL с помощью сообщений "Subscribe" согласно подпункту 3 пункта 8 настоящего приложения.
Формат сообщения "ConnectionAck" (поле "payload" опциональное):{ "type": "connection_ack", "payload": "string" }
- сообщение "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" } }
- сообщение "Next". Данное сообщение направляется ТС ОРМ в адрес ПУ и содержит полные или частичные результаты выполнения запроса, ранее направленного ПУ в сообщении "Subscribe". Поле "id" должно содержать уникальный идентификатор запроса, ранее сформированный ПУ. Поле "payload" должно содержать результаты выполнения запроса в формате аналогичном для интерфейса "/query" согласно спецификации языка GraphQL.
Формат сообщения "Next:{ "id": "<unique-operation-id>", "type": "next", "payload": "ExecutionResult" }
- сообщение "Error". Данное сообщение направляется ТС ОРМ в адрес ПУ и содержит информацию об ошибке в ходе выполнения запроса, ранее направленного ПУ в сообщении "Subscribe". Поле "id" должно содержать уникальный идентификатор запроса, ранее сформированный ПУ. Поле "payload" должно содержать информацию об ошибке в формате согласно спецификации языка GraphQL. В случае возникновения ошибки на начальном этапе выполнения запроса (в том числе, ошибки валидации запроса) либо в ходе выполнения запроса ТС ОРМ прекращают выполнение запроса и не направляют в сторону ПУ никаких сообщений.
Формат сообщения "Error":{ "id": "<unique-operation-id>", "type": "error", "payload": "GraphQLError" }
- сообщение "Complete". Данное сообщение может направляться в обоих направлениях. Поле "id" должно содержать уникальный идентификатор запроса, ранее сформированный ПУ. Отправка данного сообщения ТС ОРМ в адрес ПУ означает завершение выполнения запроса с соответствующим идентификатором. В случае отправки ТС ОРМ сообщения "Error" до сообщения "Complete", данное сообщение не отправляется. Отправка данного сообщения ПУ в адрес ТС ОРМ означает, что ПУ прерывает выполнение запроса с соответствующим идентификатором и с данного момента не принимает результаты его выполнения.
Формат сообщения "Complete:{ "id": "<unique-operation-id>", "type": "complete" }
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.