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

СМЭВ: транспорт, форматы и регистрация сервисов

СМЭВ строится на SOAP поверх веб-сервисов. Обмен идёт по утверждённым форматам взаимодействия – для каждого вида сведений ведомство-поставщик публикует свой электронный сервис, а потребитель формирует запрос строго по описанию. Сейчас в продуктиве работает СМЭВ 2.x, и интеграция означает разработку адаптера, который умеет собирать конверт по структуре MessageData, заполнять служебный блок СМЭВ-заголовка (идентификаторы запроса, отправителя, получателя, тип сообщения) и корректно маршрутизировать вызов через узел.

Типовые задачи на старте:

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

Главная ошибка – недооценка различий между форматами разных поставщиков. Каждый сервис живёт по своему описанию, и единый универсальный клиент здесь не работает. Мы строим интеграционный слой так, чтобы добавление нового вида сведений не ломало уже подключённые – это и есть базовый принцип интеграции разнородных систем.

Электронная подпись: подписание и проверка

Запросы в СМЭВ подписываются по стандарту WS-Security с использованием ГОСТ-алгоритмов (хеширование 34.11, подпись 34.10). На практике это означает работу через сертифицированный криптопровайдер – как правило, КриптоПро CSP и аккуратную сборку XML с каноникализацией. Любая лишняя правка подписанного фрагмента ломает подпись, поэтому подписание выносим в отдельный, изолированный шаг конвейера.

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

Инфраструктура и предсказуемость окружения

Криптография чувствительна к окружению: версия CSP, библиотеки, сертификаты тестового и продуктивного контуров. Когда сборка «работает у разработчика», но падает на стенде ведомства, причина почти всегда в расхождении версий. Поэтому интеграционные адаптеры мы упаковываем в воспроизводимые контейнеры – см. наш релиз сборки на Docker Compose – а параметры контуров СМЭВ описываем декларативно, через инфраструктуру как код. Это убирает класс ошибок «у нас всё было настроено вручную и кто-то это потерял».

Тестовый и боевой контуры СМЭВ различаются адресами узлов, наборами сертификатов и составом доступных сервисов. Разносить их через конфигурацию, а не через ветки кода – обязательное условие, иначе аттестация и перевод в продуктив превращаются в ручную пересборку.

Вывод

Электронная госуслуга – это не одна форма на портале, а связка из трёх слоёв: транспорт СМЭВ по утверждённым форматам, юридически значимая ЭП по ГОСТ и предсказуемое окружение. Слабое звено в любом из них блокирует ввод услуги в эксплуатацию. Закладывайте интеграционный слой как отдельный компонент с самого начала – переделывать его после аттестации дороже всего.