Количество формируемых на ОВ сертификатов ЭП-ОВ не может быть меньше количества информационных систем данного ОВ, непосредственно подключенных к СМЭВ.

Ответственность за хранение и использование ключа подписи ЭП-ОВ несет должностное лицо. Порядок хранения и использования ключа подписи ЭП-ОВ контролируется представителями органов власти.

Общие требования к электронной подписи, формируемой узлами СМЭВ

Сертификаты и ключи электронной подписи (п. 3 ст. 14 Федерального закона от 6 апреля 2011 г. «Об электронной подписи»), используемые для формирования электронных подписей в сообщениях, проходящих через федеральный и региональные узлы СМЭВ, выдаются на имя оператора соответствующей системы межведомственного электронного взаимодействия и применяются для формирования ЭП.

Общие требования к электронной подписи, формируемой узлами СМЭВ, представлены в таблице 5.

ЭП-СМЭВ подтверждает:

    факт прохождения электронного сообщения через СМЭВ; факт аутентификации и авторизации в соответствии с правилами, указанными в реестре прав доступа к электронным сервисам (матрице доступа); неизменность сведений, внесенных в электронное сообщение СМЭВ.

Ответственность за хранение и использование ключа подписи ЭП-СМЭВ обеспечивается организационно-техническими мероприятиями оператора СМЭВ.

Таблица 5 – Общие требования к электронной подписи, формируемой узлами СМЭВ

Формат подписи

XMLDSig detached

Трансформация, дополнительно к канонизации

urn://smev-gov-ru/xmldsig/transform

Требования к форматированию

В XML-структуре подписи, между элементами не допускается наличие текстовых узлов, в том числе переводов строки.

Подписываемый элемент

    Для запросов или рассылок – элемент //SendRequestResponse; Для ответов – элемент //MessageMetadata; При выборке сообщения из очереди – элемент //Request; При подтверждении получения сообщения – ЭП СМЭВ отсутствует.

Размещение во входящем сообщении

Тело SOAP конверта, элемент //CallerInformationSystemSignature

Правила формирования электронной подписи информационной системы

Общие требования к электронной подписи, формируемой узлами СМЭВ представлены в таблице 6.

НЕ нашли? Не то? Что вы ищете?

Таблица 6 – Правила формирования электронной подписи информационной системы

Формат подписи

XMLDSig detached

Трансформация, дополнительно к канонизации

urn://smev-gov-ru/xmldsig/transform

Требования к форматированию

В XML-структуре подписи, между элементами не допускается наличие текстовых узлов, в том числе переводов строки.

Подписываемый элемент

Для простых протоколов обмена:

    Для запросов и рассылок – элемент //SenderProvidedRequestData; Для ответов – элемент //SenderProvidedResponseData; При выборке сообщения из очереди – элемент //MessageTypeSelector; При подтверждении получения сообщения – элемент //AckTargetMessage.

Для директивных протоколов обмена:

    Для запросов и рассылок – элемент //SenderProvidedRequestData и /Record каждой записи реестра; Для ответов – элемент //SenderProvidedResponseData и /Record каждой записи реестра; При выборке сообщения из очереди – элемент //MessageTypeSelector; При подтверждении получения сообщения – элемент //AckTargetMessage.

Размещение в исходящем сообщении

Для простых протоколов обмена:

    Элемент //CallerInformationSystemSignature

Для директивных протоколов обмена:

    Элемент //CallerInformationSystemSignature и RecordSignature в каждой записи реестра.

Размещение во входящем сообщении

ЭП-ОВ отправителя попадает к получателю только при вызове методов GetRequest, GetResponse (выборка сообщения из очереди).

Она находится в теле SOAP-конверта, элемент //SenderInformationSystemSignature.

В случаях, когда одна из сторон сеанса обмена использует схему Единого сервиса версии 1.1, а другая схему версии 1.2 (см. п. 3.7) передача элемента //SenderInformationSystemSignature не осуществляется.

Подписание вложений электронной подписью информационной системы

В случае если сообщение содержит вложения и какие-либо из них не подписаны ЭП-СП, информационная система должна перед отправкой сообщения подписать такие вложения ЭП-ОВ. Это необходимо для защиты от подмены вложений.

Подпись формируется по тем же правилам, что и ЭП-СП (таблица 7).

Таблица 7 – Правила формирования ЭП-ОВ

Формат подписи

PKCS#7

Ограничения на использование формата

Описаны в разделе «Подписи в формате PKCS#7»

Способ помещения подписи в сообщение

Передается клиентом веб-сервиса в структуре параметров методов SendRequest, SendResponse.

Способ извлечения подписи для проверки

Подписи находятся в элементах //AttachmentHeaderList/AttachmentHeader/SignaturePKCS7 входящих сообщений, в том числе в записях реестра


Пересылка вложений с использованием файлового хранилища

В СМЭВ имеется возможность передачи файлов вложений отдельно от сообщения. Для этого используется Файловое хранилище СМЭВ. Использование Файлового хранилища обязательно, если суммарный объем вложений сообщения превышает 5 Мб. При этом суммарный объем файлов сообщения не должен превышать 1 Гб.

Квота файлового хранилища для информационной системы выбирается Участником самостоятельно при регистрации ИС в размере до 1 Гб. При необходимости установления квоты, превышающей 1 Гб, Участнику требуется предоставить обоснованные расчеты. При достижении максимальной квоты отправитель сообщения получит ошибку «Квота на файловое хранилище для получателя превышена!». Участник берет на себя обязательства по своевременному получению вложений из ФХ. Для увеличения / уменьшения ранее выбранной квоты необходимо направить отдельную заявку в адрес СТП СМЭВ с обоснованием причин изменений.

Загрузка файлов в Файловое хранилище осуществляется по протоколу FTP. Каждый участник взаимодействия получает доступ к отдельной директории FTP-сервера Файлового хранилища для загрузки файлов вложений. Для каждого файла ИС отправителя должна создать отдельную директорию, в качестве названия которой должен быть использован UUID, сгенерированный по алгоритму, аналогичному генерации UUID сообщения (см. п. 4.2 «Algorithms for Creating a Time-Based UUID» RFC 4122 http://rfc. /rfc4122/rfc4122.html#section-4.2).

Общий процесс передачи файлов посредством Файлового хранилища представлен на рисунке 38.


Рисунок 38 – Диаграмма последовательности отправки файлов посредством Файлового хранилища

При отправке сообщения, которому принадлежат загруженные файлы, UUID созданных папок с файлами указываются в сообщении в соответствующих тегах SenderProvidedRequestData (для запроса) и SenderProvidedResponseData (для ответа). Данные теги включают элемент RefAttachmentHeaderList, который описывается как лист значений. Отправку сообщения, которому принадлежат загруженные файлы, необходимо осуществлять в течение 1 дня после загрузки файлов. Срок хранения загруженного на файловое хранилище файла (до момента отправки к единому электронному сервису сообщения, содержащего ссылку на данный файл) составляет 1 день. В случае, если в течение суток после загрузки файла на файловое хранилище сообщение, содержащее ссылку на файл, не отправлено в СМЭВ, требуется выполнить повторную загрузку файла.

Очистка выделенной для информационной системы отдельной директории FTP-сервера Файлового хранилища производится автоматически в ходе обработки отправленного сообщения с файлами.

Общий процесс получения сообщения с файлами в Файловом хранилище представлен на рисунке 39.


Рисунок 39 – Диаграмма последовательности получения файлов посредством Файлового хранилища

В составе входящего сообщения содержатся ссылки на пришедшие файлы - тег FSAttachmentsList, представляющий собой лист элементов FSAttachment значений типа FSAuthInfo, содержащих ссылку на файл (uuid), логин (UserName), пароль (Password), имя файла (FileName). В FileName передается значение вида /имя_файла, (например, /filename. txt) где «filename» – наименование передаваемого файла, txt – расширение. Для выгрузки файла на стороне информационной системы получателя необходимо сформировать запрос вида: ftp://логин:пароль@ имя_хоста_шарды:порт/имя_файла. После доставки сообщения и при получении от информационной системы получателя подтверждения о получении сообщения СМЭВ очищает область доставки Файлового хранилища, доступ к доставленным файлам закрывается.

Срок хранения вложения в области доставки составляет 15 дней.


Возврат статусных сообщений

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

Данные сообщения, не содержащие вложений, выносятся на уровень схемы СМЭВ и не включаются в схемы протоколов обмена. При этом следует учитывать, что статусы запросов не связаны со статусами обработки заявлений, поданных с ЕПГУ, требования к которым устанавливаются в документе «Типовые технические требования к разработке интерактивных форм заявлений на предоставление государственных и муниципальных услуг» (опубликован по адресу http://techportal. gosuslugi. ru/).

Сообщение о статусе помещается в элемент //GetResponseResponse/ResponseMessage/Response/SenderProvidedResponseData/RequestStatus. В элемент StatusCode помещается код статуса, значение которого описывается в Руководстве пользователя протокола обмена. Статус может сопровождаться неограниченным количеством параметров (элемент StatusParameter), которые описываются парами «ключ»-«значение» (Key-Value). В поле StatusDescription можно поместить расширенное описание статуса.

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25