Войти

6.2. Порядок использования электронных подписей

6.2.1. Использование электронных подписей при передаче запроса

Передача запроса от системы-инициатора запроса к системе-ответчику, или рассылки от системы-издателя к системе-подписчику сопровождается операциями по формированию и проверке электронных подписей (рисунок 44).

Перед отправкой сообщения с запросом или рассылкой, должностное лицо ОВ может подписать (при необходимости) с помощью ЭП-СП два элемента в сообщении:

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

  • блок структурированных сведений в соответствии с требованиями протокола обмена (подписывается содержимое элемента //MessagePrimaryContent, заключённое между открывающим и закрывающим тегами элемента). ЭП-СП хранится в элементе //PersonalSignature;
  • блок содержимого вложений (файлы, размещённые в элементе //AttachmentContentList). Каждый из файлов, размещённых в элементе //AttachmentContentList, подписывается отдельной ЭП-СП. Соответствующие ЭП-СП передаются в блоке заголовков и ЭП-СП вложений (элемент //AttachmentHeaderList).

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

  • блок структурированных сведений в соответствии с требованиями протокола обмена (подписывается содержимое элемента //RecordContent, заключённое между открывающим и закрывающим тегами элемента). ЭП-СП хранится в элементе //PersonalSignature каждой записи реестра;
  • блок содержимого вложений (файлы, размещённые в элементе //AttachmentContentList). Каждый из файлов, размещённых в элементе //AttachmentContentList, подписывается отдельной ЭП-СП. Соответствующие ЭП-СП передаются в блоке заголовков и ЭП-СП вложений (элемент //AttachmentHeaderList) каждой записи реестра.

В случае подачи заявления на получение государственной услуги в электронном виде, если по требованию ведомства оно должно быть подписано ЭП заявителя, ЕПГУ обеспечивает подписание ЭП-СП:

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

  • каждого из файлов, передаваемых посредством MTOM. Соответствующие ЭП-СП передаются в блоке заголовков и ЭП-СП вложений (элемент //AttachmentHeaderList);
  • каждого из файлов, передаваемых посредством ФХ. Соответствующие ЭП-СП передаются в блоке заголовков и ЭП-СП вложений (элемент //RefAttachmentHeaderList).

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

  • каждого из файлов, передаваемых посредством MTOM. Соответствующие ЭП-СП передаются в блоке заголовков и ЭП-СП вложений (элемент //AttachmentHeaderList) каждой записи реестра;
  • каждого из файлов, передаваемых посредством ФХ. Соответствующие ЭП-СП передаются в блоке заголовков и ЭП-СП вложений (элемент //RefAttachmentHeaderList) каждой записи реестра.

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

Схема использования электронных подписей при передаче запроса от инициатора к ответчику сервиса(Рисунок 40).

38.jpg

Рисунок 40 – Использование электронных подписей при передаче запроса от инициатора к ответчику сервиса.

Если содержимое вложений (файлы, размещённые в элементе //AttachmentContentList) с помощью ЭП-СП должностным лицом не подписываются, то содержимое вложений вместо ЭП-СП должно быть подписано с помощью ЭП-ОВ, которая, в свою очередь, помещается в блок заголовков и ЭП-СП вложений, вместо ЭП-СП вложений.

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

Для директивных протоколов обмена содержимое подписываемого фрагмента записи реестра (данные, размещённые в элементах //Record: //RecordContent, //AttachmentHeaderList, //RefAttachmentHeaderList, //PersonalSignature) должно быть подписано с помощью ЭП-ОВ и размещено в элементе //RecordSignature. Допускается не накладывать подписи ЭП-ОВ на каждую запись реестра при условии доставки получателю сообщения всех записей реестра без изменения.

Сведения, сформированные в соответствии с требованиями Владельца сведений и подписанные, при необходимости, электронной подписью ЭП-СП, дополняются служебной информацией и вместе образуют блок данных запроса (элемент //SenderProvidedRequestData). Этот блок данных запроса подписывается ЭП-ОВ (элемент //CallerInformationSystemSignature).

На этом формирование электронных подписей запроса на стороне ИС инициатора или ИС получателя рассылки завершается. Запрос, подписанный ЭП-ОВ и, при необходимости, ЭП-СП, поступает в СМЭВ.

СМЭВ автоматически осуществляет:

  • проверку ЭП-ОВ, в том числе входящего в состав ЭП-ОВ сертификата;
  • идентификацию ИС отправителя запроса по сертификату ЭП-ОВ;
  • проверку по реестру прав доступа СМЭВ (далее – матрица доступа) возможности обращения ИС отправителя сообщения к ИС получателя сообщения;
  • добавление блока маршрутной информации (в том числе метки времени получения запроса в СМЭВ);
  • для директивных протоколов обмена СМЭВ производит формирование сообщений-клонов.

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

Получив от ответчика такое обращение, СМЭВ автоматически осуществляет:

  • проверку ЭП-ОВ, в том числе входящего в состав ЭП-ОВ сертификата;
  • идентификацию ИС, обратившейся за получением сообщения-запроса, по сертификату ЭП-ОВ;
  • проверку по матрице доступа возможности получения этой ИС электронного сообщения;
  • добавление метки времени отправки сообщения-запроса из СМЭВ и подписание сообщения-запроса с помощью ЭП-СМЭВ.

    Получив из СМЭВ сообщение с запросом, система-инициатор или система-получатель рассылки проверяет сертификат и корректность формирования ЭП-СМЭВ. Успешность проверки гарантирует:

  • поступление сообщения-запроса из СМЭВ, а не из другого источника;
  • поступление сообщения-запроса в СМЭВ от ИС отправителя сообщения и из СМЭВ в ИС получателя сообщения во время, указанное в метках времени;
  • право на обращение ИС отправителя к ИС получателя запроса;
  • целостность запроса на всём маршруте от ИС отправителя до ИС получателя.

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

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

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

6.2.2. Использование электронных подписей при передаче ответа

Формирование и подписание с помощью ЭП сообщений-ответов на сообщения-запросы (Рисунок 41) выполняется подобно формированию и подписанию с помощью ЭП сообщений-запросов.

39.jpg

Рисунок 41 – Использование электронных подписей при передаче сообщения-ответа от системы-ответчика к системе-инициатору.

В отличие от формирования сообщения-запроса, при подготовке и отправке сообщения-ответа отправителем выступает уже не система-инициатор, а система-ответчик. Порядок подписания с помощью ЭП-СП сведений должностным лицом ОВ-ответчика такой же, как и в случае подписания ЭП-СП сведений в запросе. Подписание с помощью ЭП-ОВ блока структурированных данных сообщения-ответа ответчика отличается только структурой подписываемого блока структурированных данных сообщения-ответа (Рисунок 42). Структура данных, которые добавляются к сообщению-ответу в СМЭВ и, затем вместе с подписанным с помощью ЭП-ОВ блоком данных, подписываются в СМЭВ ЭП-СМЭВ, также имеет отличия от соответствующей структуры данных, которые добавляются в СМЭВ к сообщению-запросу. К сообщению-запросу СМЭВ добавляет элемент //ReplyTo, выполняющий функции обратного адреса, а к сообщению-ответу добавляет элемент //OriginalMessageId, в который записывает идентификатор сообщения-запроса, на который сформирован данное сообщение-ответ

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

Авторизуйтесь, чтобы оставить комментарий к статье