Выбор поставщика для интеграции с ЕСИА и СМЭВ

Статус кейса

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

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

Задача без аббревиатур

Бизнес-задача звучит просто: клиенту не нужно ехать в офис, а менеджеру не нужно выезжать к клиенту только ради первичной проверки. Нужно удаленно понять, с кем мы работаем, получить актуальные сведения, проверить документы и не превратить процесс в ручную переписку.

Но клиент в нашем сценарии - не только физлицо. Это ООО, ИП или ГКФХ. Значит, вопрос “человек вошел через Госуслуги?” не равен вопросу “мы можем безопасно работать с этим клиентом?”.

На практике задача распадается на четыре разных вопроса:

• кто вошел в процесс;
• от имени кого он действует;
• какие сведения нужны для решения;
• каким защищенным путем эти сведения попадают в нашу систему.

mindmap
  root((Проверка клиента))
    Кто вошел
      ЕСИА
    От чьего имени
      роль
      полномочия
    Какие сведения нужны
      документы
      госисточник
    Как доверяем обмену
      защищенный канал
      ЭП и СКЗИ
    Где граница
      наш контур
      поставщик

Главный риск на старте - назвать все это “подключением к Госуслугам” и начать выбирать поставщика до того, как понятно, какую именно часть процесса он закрывает.

Что такое ЕСИА

Если объяснять без канцелярита, ЕСИА - это слой учетной записи и входа. Пользователь один раз заводит учетную запись, подтверждает ее нужным способом и потом может входить в разные государственные и подключенные информационные системы без отдельного логина и пароля для каждой системы.

ЕСИА хранит и обслуживает не только вход физлица. В документах описаны разные категории пользователей: физические лица, представители юридических лиц, индивидуальные предприниматели. Есть уровни учетной записи, данные пользователя, данные организаций, группы доступа и полномочия сотрудников. Для интеграции информационной системы используются технологический портал ЕСИА и протоколы вроде OAuth 2.0 / OpenID Connect 1.0, а в некоторых сценариях еще встречается SAML 2.0.

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

sequenceDiagram
  actor Rep as Представитель клиента
  participant Portal as Наш сайт / ЛК
  participant Esia as ЕСИА
  participant Account as Учетная запись и профиль
  participant Check as Бизнес-проверка клиента

  Rep->>Portal: Выбирает вход через Госуслуги
  Portal->>Esia: Отправляет запрос входа
  Esia->>Account: Проверяет учетную запись и способ входа
  Account-->>Esia: Возвращает пользовательский контекст
  Esia-->>Portal: Передает результат входа
  Portal->>Check: Запускает проверку роли, организации и данных

  Note over Portal,Check: Вход пользователя - это начало проверки, а не вся проверка клиента

Пример из жизни: человек может быть реальным пользователем Госуслуг, но бизнесу все равно нужно понять, какую организацию он представляет, какие у него полномочия, какие документы нужны, какие сведения можно получить и какой источник этим сведениям доверяет.

Что такое СМЭВ

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

Если совсем просто, ЕСИА похожа на проходную: она помогает понять, кто пришел. СМЭВ похож на регламентированную службу доставки сведений между системами: кто имеет право запросить, у кого запрашивать, в каком формате, с какой подписью, через какой канал, с каким статусом и что делать при ошибке.

В старых версиях СМЭВ вокруг этого много XML, SOAP, WSDL, XSD и электронных сервисов. В СМЭВ 4 добавляется более современный набор сценариев: агенты СМЭВ4, ПОДД СМЭВ, регламентированные SQL-запросы, рассылки, REST-сервисы, синхронные и асинхронные режимы. Но смысл остается тем же: это не свободный API “куда угодно”, а регулируемый обмен между участниками.

sequenceDiagram
  participant App as Наша ИС
  participant Adapter as Адаптер / поставщик
  participant Smev as СМЭВ
  participant Source as Госисточник

  App->>Adapter: Просит сведения для бизнес-сценария
  Adapter->>Smev: Передает регламентированный запрос
  Smev->>Source: Маршрутизирует запрос к источнику
  Source-->>Smev: Возвращает сведения, отказ или ошибку
  Smev-->>Adapter: Возвращает ответ и статус
  Adapter-->>App: Переводит результат в понятный ответ для процесса

  alt Ответ подходит
    App->>App: Продолжает клиентский сценарий
  else Ответа не хватает или есть ошибка
    App->>App: Запускает ручную проверку или альтернативный маршрут
  end

Для бизнеса это означает неприятную, но полезную мысль: “получить данные из государства” - не одна кнопка. Нужно знать, какой вид сведений нужен, кто поставщик сведений, кто потребитель, есть ли доступ, какая версия запроса используется, как обрабатываются ошибки и где остаются технические следы.

Как выглядит СМЭВ 4 и ПОДД простыми словами

В документах по СМЭВ 4 много терминов, но для первого понимания достаточно такой модели.

Есть потребитель данных - система, которой нужны сведения. Есть поставщик данных - система или витрина, где эти сведения доступны. Между ними не просто прямой HTTP-запрос. Появляется агент СМЭВ4, ядро СМЭВ4, регламентированные запросы, статусы, ошибки и разные режимы обмена.

Синхронный режим похож на обычный вопрос-ответ: отправили запрос и ждете результат в рамках одного обращения. Асинхронный режим нужен, когда результат нельзя получить сразу: сначала отправляется запрос, потом отдельно забирается результат или приходит уведомление. Для некоторых сценариев есть рассылки и REST-сервисы.

sequenceDiagram
  participant Consumer as ИС потребителя
  participant ConsumerAgent as Агент потребителя
  participant Core as Ядро СМЭВ 4
  participant ProviderAgent as Агент поставщика
  participant DataMart as Витрина / ИС поставщика

  Consumer->>ConsumerAgent: Отправляет регламентированный запрос
  ConsumerAgent->>Core: Передает запрос в СМЭВ 4
  Core->>ProviderAgent: Маршрутизирует к поставщику
  ProviderAgent->>DataMart: Выполняет запрос к данным
  DataMart-->>ProviderAgent: Возвращает результат или ошибку
  ProviderAgent-->>Core: Передает статус и ответ
  Core-->>ConsumerAgent: Возвращает результат
  ConsumerAgent-->>Consumer: Отдает данные бизнес-системе

  Note over Consumer,DataMart: В реальном проекте нужно отдельно проверить режим, доступ, версии, ошибки и поддержку

Для нашего кейса это важно по двум причинам.

Первая: если поставщик говорит “у нас есть СМЭВ 4”, нужно уточнить, что именно есть. Агент? Витрина? Доступ к конкретному регламентированному запросу? Поддержка тестовой и продуктивной среды? Диагностика ошибок? Сопровождение сертификатов?

Вторая: современный СМЭВ 4 может выглядеть ближе к REST/SQL-сценариям, но это не отменяет регламентированность, роли участников, статусы, тестовую среду, продуктивную среду и защищенный контур.

Почему нельзя просто сделать самим

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

Собственный путь может потребовать:

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

Отдельно важна разница между тестовой и продуктивной средой. Тестовая среда существует для проверки готовности и содержит тестовые данные. Продуктивная среда нужна для реального межведомственного обмена, изолирована от тестовой и требует защищенного подключения. Это уже не похоже на “мы дернули внешний API из backend-сервиса”.

mindmap
  root((Своими силами))
    Разобраться
      ЕСИА
      СМЭВ
      ПОДД
      роли и доступы
    Разработать
      адаптеры
      API
      статусы
      ошибки
    Поднять контур
      тестовая среда
      продуктив
      агент или шлюз
    Закрыть криптографию
      ЭП
      СКЗИ
      сертификаты
    Пройти процедуры
      заявки
      подтверждение
      аттестация
      сертификация
    Сопровождать
      логи
      мониторинг
      инциденты
      версии

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

mindmap
  root((Поставщик))
    Дает вход
      API
      адаптер
    Закрывает контур
      тестовая среда
      продуктив
      сертификаты
    Помогает внедрить
      документы
      настройки
      переход в прод
    Поддерживает
      логи
      статусы
      диагностика
    Фиксирует границы
      SLA
      ответственность
      платные работы

Но это работает только при одном условии: поставщик не должен быть черным ящиком.

Что должен объяснить поставщик

Фраза “мы умеем ЕСИА/СМЭВ” почти ничего не значит. Хороший разговор начинается, когда поставщик показывает границы ответственности.

Нужно понять:

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

sequenceDiagram
  participant Business as Бизнес-процесс
  participant App as Наша ИС
  participant Vendor as Поставщик
  participant Crypto as Защищенный контур
  participant Smev as ЕСИА / СМЭВ
  participant Support as Поддержка

  Business->>App: Нужна удаленная проверка клиента
  App->>Vendor: Передает запрос по согласованному API
  Vendor->>Crypto: Использует подписи, сертификаты и канал
  Crypto->>Smev: Обращается в нужный контур
  Smev-->>Crypto: Возвращает ответ, статус или ошибку
  Crypto-->>Vendor: Передает технический результат
  Vendor-->>App: Возвращает бизнес-результат и диагностику
  App-->>Business: Продолжает сценарий или уводит в ручную проверку

  Support->>Vendor: Разбирает инцидент, логи и ответственность
  Note over Vendor,Support: До выбора нужно понять, что поставщик реально сопровождает

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

Где здесь цифровой профиль, ЦПГ и ЦПО

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

Если поставщик предлагает цифровой профиль, ЦПГ, ЦПО, СМЭВ 4, ПОДД СМЭВ, отдельный API Госуслуг или свой шлюз, он должен показать:

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

Пока этого нет, термин остается гипотезой, а не архитектурным решением.

Что уже стало понятнее

Главный результат сейчас - не “мы внедрили ЕСИА/СМЭВ”. Мы еще не внедрили. Главный результат - задача стала понятной.

Мы больше не обсуждаем аббревиатуру как решение. Мы отдельно проверяем:

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

Такой разбор снижает риск выбрать неверную интеграционную ветку. Еще важнее - он переводит разговор с “купим подключение к Госуслугам” на нормальный инженерный язык: какой бизнес-сценарий закрываем, каким источникам доверяем, как идет обмен, где граница ответственности и сколько стоит самостоятельный путь.

Что я сознательно не публикую

В этом кейсе нет названий поставщиков, внутренних систем, точных цен, маршрутов запросов, видов сведений и деталей инфраструктуры. Такие подробности полезны внутри проекта, но в публичном портфолио они могут создать лишний риск.

Здесь важнее показать ход анализа: как разделить ЕСИА, СМЭВ и бизнес-задачу; почему государственная интеграция не равна обычному API; где появляются криптография и защищенное размещение; и какие вопросы нужно задать поставщику до начала внедрения.

Источники для проверки

Документы по ЕСИА:

• Методические рекомендации по использованию ЕСИА.
• Регламент информационного взаимодействия ЕСИА.
• Руководство оператора центра обслуживания ЕСИА.
• Руководство пользователя технологического портала ЕСИА.
• Руководство пользователя ЕСИА.

Документы по СМЭВ:

• Методические рекомендации по работе с ПОДД СМЭВ.
• Руководство администратора агента ПОДД СМЭВ.
• Регламент подключения к СМЭВ 4.
• Правила и процедуры работы в СМЭВ по методическим рекомендациям версии 2.x.
• Методические рекомендации СМЭВ 2.
• Методические рекомендации СМЭВ 3.

Нормативная база:

• Постановление Правительства РФ от 23.04.2026 N 462.
• Постановление N 697.