Куда я попал?
Приказ Минцифры № 935 от 01.11.2023
Требования к вычислительной мощности, используемой провайдером хостинга
Требования к вычислительной мощности, используемой провайдером хостинга, для проведения уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность или обеспечение безопасности Российской Федерации, в случаях, установленных федеральными законами, мероприятий в целях реализации возложенных на них задач
Для проведения оценки соответствия по документу войдите в систему.
Для оценки соответствия
- авторизуйтесь
- авторизуйтесь
Планируемый уровень
Текущий уровень
Группы областей
36
%
Входящая логистика
67
%
Создание продукта
79
%
Исходящая логистика
47
%
Маркетинг, продажа
58
%
Обслуживание клиента
84
%
Инфраструктура
74
%
HR-менеджмент
52
%
Технологии
47
%
Закупки / Снабжение
61
%
Опыт клиента
Список требований
-
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 Гбайт.
-
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" с указанием идентификатора запроса. В ответ ТС ОРМ должны направить результат выполнения данного запроса.ТС ОРМ должны удалять промежуточные результаты прерванного отложенного запроса. -
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.
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.