Интеграция корпоративной системы с ЕСИА

Как подключить сайт, портал или корпоративный сервис к «Госуслугам» и что для этого нужно

Зачем компании интегрироваться с ЕСИА

Если корпоративная система обменивается данными с государством, принимает обращения граждан или просто хочет надёжно подтверждать личность пользователя, рано или поздно встаёт вопрос об интеграции с ЕСИА. Для одних организаций это требование закона, для других — способ снять с себя часть работы по проверке личности пользователей и получить доступ к вводимым государством данным (СНИЛС, ИНН, паспортные данные, контакты) с согласия самого человека.

Эта статья написана для ИТ-директоров, архитекторов и разработчиков корпоративных систем, для профильных подразделений государственных и муниципальных организаций, а также для бизнеса — банков, страховых, образовательных платформ, маркетплейсов, — которые рассматривают вход через «Госуслуги» как альтернативу или дополнение к собственной регистрации. Материал разбирает, как устроена интеграция технически и организационно, какие требования предъявляет российское законодательство и с какими ограничениями стоит считаться до начала проекта.

Что такое ЕСИА простыми словами

ЕСИА — федеральная государственная информационная система, созданная в соответствии с постановлением Правительства РФ от 28.11.2011 № 977 и положением, утверждённым приказом Минкомсвязи России от 13.04.2012 № 107 [1]. Формально она обеспечивает информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме, а на практике — это тот самый механизм, который стоит за кнопкой «Войти через Госуслуги».

Технический оператор ЕСИА — Минцифры России совместно с подведомственной инфраструктурой электронного правительства; развитием и эксплуатацией занимается «Ростелеком». У системы есть три уровня учётных записей физических лиц, которые определяют, какие данные и какие функции доступны пользователю [2]:

• Упрощённая — создаётся по номеру телефона или e-mail, даёт доступ к небольшому перечню сервисов, не требующих подтверждения личности.
• Стандартная — требует заполнения профиля (ФИО, СНИЛС, паспортные данные) и автоматической проверки этих данных в государственных реестрах.
• Подтверждённая — личность пользователя дополнительно подтверждена одним из способов: визит в МФЦ, подтверждение через онлайн-банк, усиленная квалифицированная электронная подпись или, для жителей Москвы, портал mos.ru. Именно подтверждённая учётная запись даёт доступ к полному перечню государственных услуг и обычно требуется сторонним системам, которым нужны проверенные данные пользователя.

ЕСИА принципиально отличается от Системы межведомственного электронного взаимодействия (СМЭВ): ЕСИА отвечает за идентификацию, аутентификацию и авторизацию пользователей, а СМЭВ — за обмен структурированными данными и документами между информационными системами ведомств и организаций [3]. На практике многие проекты интеграции требуют подключения к обеим системам: ЕСИА — чтобы авторизовать человека, СМЭВ — чтобы затем получить или передать сведения о нём.

Как устроено взаимодействие технически

Актуальные методические рекомендации ЕСИА описывают авторизацию через OpenID Connect поверх OAuth 2.0 и получение разрешённых сведений через REST API. Разделы о SAML удалены из рекомендаций начиная с версии 3.37, поэтому этот вариант стоит рассматривать только для ранее созданного контура, если его поддержку подтвердил оператор. Набор доступных данных определяется выданными областями доступа и согласием пользователя [13].

• вместо обычной секретной строки client_secret используется отсоединённая электронная подпись запроса в формате PKCS#7 от значений параметров scope, timestamp, clientId и state, закодированная в base64 url-safe;
• поддерживаются только два grant type — Authorization Code Flow и Client Credentials Flow;
• нет стандартного UserInfo Endpoint — вместо него используется отдельное REST API ЕСИА с эндпоинтами для персональных данных, контактов и документов пользователя;
• набор scope — собственный, специфичный для ЕСИА, а не стандартный OIDC-справочник;
• из опциональных режимов OIDC доступны только display=page/popup и prompt=none/login;
• подпись строится на алгоритмах ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012, поэтому стандартные библиотеки OAuth/OIDC приходится дорабатывать или подключать отдельный сервис для криптографических операций [4].

Упрощённо процесс выглядит так: пользователь переходит по сформированной и подписанной ссылке авторизации → проходит вход на портале ЕСИА → система перенаправляет его обратно на redirect_uri с кодом авторизации и параметром state → клиентская система обменивает код на токены (access_token, id_token, refresh_token) → по access_token и идентификатору sub из id_token система запрашивает нужные атрибуты пользователя через REST API. Все технические детали, включая примеры кода и сценарии SSO, описаны в «Методических рекомендациях по использованию ЕСИА» — документе объёмом свыше 500 страниц, который выпускает Минцифры вместе с регламентом информационного взаимодействия.

Российская специфика: что регулирует подключение

Интеграция с ЕСИА — не просто техническая задача, а деятельность, встроенная в довольно плотную нормативную рамку:

• Постановление Правительства РФ от 28.11.2011 № 977 и положение о ЕСИА (приказ Минкомсвязи № 107) — базовые документы, определяющие саму систему и порядок предоставления сведений из неё сторонним организациям.
• Регламент информационного взаимодействия участников с оператором ЕСИА описывает порядок подключения, документы и технические требования. Перед началом проекта нужно брать актуальную редакцию регламента и формы заявки: состав мер зависит от типа участника, характеристик системы и выбранной схемы подключения [14].
• С 30 марта 2025 года электронные обращения по Закону № 59-ФЗ принимаются через Госуслуги либо через другую государственную информационную систему или официальный сайт органа, которые обеспечивают идентификацию и аутентификацию заявителя. Закон не называет ЕСИА единственным возможным механизмом [16].
• Федеральный закон № 569-ФЗ вводит с 1 сентября 2026 года идентификацию через ЕСИА для лица, на которое регистрируется доменное имя в российской национальной доменной зоне. Это требование относится к регистрации домена у регистратора и само по себе не обязывает владельца сайта подключать вход посетителей через Госуслуги [15].
• Требования по защите персональных данных — Федеральный закон от 27.07.2006 № 152-ФЗ, а также нормативные акты ФСТЭК и ФСБ, о которых ниже.

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

1. Криптография и защищённый канал. Нужные средства и класс защиты определяются по действующему регламенту, типу участника и схеме подключения. Универсального требования использовать один и тот же комплект СКЗИ для любого проекта ЕСИА нет [14].
2. Безопасность подключаемой системы. Состав модели угроз, организационных мер и проверок выбирают с учётом категории системы, обрабатываемых данных и условий подключения. Требования нельзя автоматически сводить к УЗ.3 и обязательной аттестации для каждого участника [14].
3. Корректность реализации взаимодействия. Реализация OpenID Connect в системе заявителя должна пройти проверку и оценку влияния на СКЗИ с привлечением лаборатории, аккредитованной ФСБ России (либо использовать уже сертифицированное типовое решение, которое эту проверку прошло за всех своих клиентов).
4. Организационные меры. Отдельные требования Банка России — для кредитных организаций, обязательное использование сертифицированного антивируса, размещение серверов на территории РФ.

Порядок подключения и сроки перехода на отдельные компоненты нужно сверять с актуальной редакцией регламента. В версии 2.54 API Gateway описан как отдельный вариант подключения, проходивший опытную эксплуатацию, а не как единое обязательное решение для всех участников [14].

Варианты реализации интеграции

На практике у организации есть три пути подключения информационной системы к ЕСИА.

Самостоятельная разработка интеграции. Компания реализует OIDC/OAuth 2.0, подпись запросов, работу с токенами и REST API под требования своего контура. Этот путь даёт контроль над кодом, но требует внимательно пройти действующую процедуру регистрации системы, тестовый контур и проверку документов. Объём мер безопасности определяется по регламенту конкретного подключения [13][14].

Готовое типовое решение (шлюз, коннектор). Регламент прямо предусматривает возможность использования «типового технического решения», которое избавляет заявителя от необходимости самостоятельно проходить две наиболее тяжёлые и дорогие процедуры — оценку влияния на СКЗИ и проверку корректности реализации OpenID Connect, — поскольку поставщик уже прошёл их за всех своих клиентов [7]. Это заметно сокращает сроки и стоимость подключения, но добавляет зависимость от конкретного поставщика и его условий обслуживания.

Подключение через предусмотренный регламентом шлюзовой модуль. Возможность и условия такого варианта нужно подтверждать на дату проекта. Архитектуру не стоит строить вокруг анонсированного срока до получения актуальной документации и допуска оператора [14].

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

Практические этапы подключения

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

Организационный этап [9].

1. Назначить сотрудника, ответственного за эксплуатацию информационной системы, — в дальнейшем он администрирует учётную запись организации в ЕСИА.
2. Зарегистрировать или подтвердить учётную запись юридического лица на «Госуслугах» — потребуется квалифицированная электронная подпись на организацию.
3. Получить доступ к технологическому порталу ЕСИА (esia.gosuslugi.ru/console/tech): руководитель или администратор профиля организации включает ответственного сотрудника в группу доступа «Технологический портал».

Технический этап.

1. Зарегистрировать информационную систему через технологический портал — после проверки формируется уникальный код (мнемоника) ИС.
2. Сформировать закрытый ключ и получить сертификат открытого ключа для подписи запросов к ЕСИА; ключ должен быть выпущен аккредитованным удостоверяющим центром и содержать ОГРН юридического лица.
3. Провести тестирование в песочнице — на выделенном тестовом контуре ЕСИА (esia-portal1.test.gosuslugi.ru) отладить обмен данными, работу с токенами и получение атрибутов пользователя.
4. Направить заявку на подключение к промышленной среде — по установленной форме (для коммерческих компаний — по форме соответствующего приложения к регламенту), приложив сертификат ключа; решение о подключении принимает Минцифры России на основании представленных сведений, включая данные об оценке эффективности реализованных мер защиты информации [10].

Блок безопасности.

1. Определить состав защищаемых данных, угрозы и необходимые меры для конкретной информационной системы.
2. Проверить по статусу системы и регламенту, требуется ли аттестация или другая форма подтверждения выполнения мер защиты.
3. Пройти оценку влияния среды функционирования на СКЗИ и проверку корректности реализации OpenID Connect с привлечением лаборатории, аккредитованной ФСБ России, либо использовать типовое решение, для которого эти процедуры уже пройдены поставщиком.

По оценке разработчиков решений для подключения к ЕСИА, при самостоятельной интеграции в зависимости от выбранного способа (OpenID Connect/OAuth 2.0) и сложности проекта на технические работы уходит от нескольких недель до нескольких месяцев [8] — без учёта новых процедур аттестации и оценки СКЗИ, которые добавляют отдельный, часто более длительный трек согласований. Подключение к ЕСИА как таковое остаётся бесплатным: плата взимается за сопутствующие услуги — сертификаты, оборудование, работу аккредитованных лабораторий и, при выборе готового решения, за само решение и его сопровождение [8].

Ограничения, ошибки и риски

Практика показывает несколько повторяющихся сложностей.

• Недооценка объёма требований по безопасности. Многие проекты изначально планируются как «обычная OAuth-интеграция», а затем упираются в необходимость аттестации, лицензирования и привлечения аккредитованных лабораторий — это меняет и бюджет, и сроки проекта на порядок.
• Использование стандартных OIDC-библиотек без доработки. Из-за особенностей ЕСИА (подпись вместо client_secret, ограниченный набор grant type, нестандартные scope) готовые библиотеки OAuth 2.0/OIDC работают лишь частично и требуют кастомизации.
• Рассинхронизация времени между системами. Расхождение показаний часов больше чем на минуту приводит к ошибкам аутентификации, поскольку в подписи запроса участвует временная метка.
• Хранение паролей и избыточный доступ к данным пользователей. Регламент прямо запрещает участникам взаимодействия хранить, обрабатывать, передавать или собирать (в том числе от самих пользователей) информацию о паролях пользователей ЕСИА [11]; запрашивать стоит только те атрибуты (scope), которые действительно необходимы для работы сервиса.
• Путаница между ЕСИА и СМЭВ. Авторизация пользователя через ЕСИА не даёт автоматически доступа к обмену сведениями с ведомствами — для этого отдельно нужно подключение к СМЭВ, со своей регистрацией, регламентом и сертификатами.
• Зависимость от версии регламента. Регламент и методические рекомендации обновляются регулярно (счёт версий идёт на десятки), а срок ввода нового шлюзового модуля уже переносился; закладывать в проект «вечные» технические решения без ревизии требований не стоит.

Как выбрать подход к реализации

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

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

В любом случае до начала работ стоит свериться с актуальной версией регламента на портале digital.gov.ru — требования меняются быстрее, чем успевают устаревать статьи о них.

Как может помочь «Пятый фактор»

Основная сложность интеграции с ЕСИА обычно не в самом протоколе авторизации, а в том, что вокруг него: нужно правильно спроектировать обмен данными с корпоративной системой (1С, CRM, личный кабинет на сайте), предусмотреть обработку ошибок и повторных запросов, разобраться, какие именно атрибуты пользователя действительно нужны сервису, и заложить архитектуру так, чтобы прохождение аттестации и последующие изменения регламента не требовали переписывать интеграцию с нуля.

Команда «Пятого фактора» может изучить задачу, оценить, какой вариант подключения — самостоятельная разработка или готовое решение — подойдёт с учётом текущей инфраструктуры и сроков, и помочь с разработкой или доработкой интеграции корпоративной системы с ЕСИА и смежными госсистемами.

Что подготовить до технического подключения

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

• Описать, зачем системе нужна ЕСИА: вход пользователя, получение подтверждённых атрибутов или участие в конкретном государственном процессе.
• Уточнить, допускается ли выбранный сценарий правилами подключения и кто выступает владельцем системы и ответственным за взаимодействие.
• Определить минимальный набор сведений, который действительно нужен приложению после входа.
• Подготовить адреса тестового и рабочего контуров, сертификаты, контакты ответственных и описание информационной системы.
• Продумать связывание учётной записи ЕСИА с существующим профилем, включая совпадения и расхождения в данных.
• Заранее определить поведение при недоступности ЕСИА, отзыве доступа и изменении атрибутов пользователя.

Вывод

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

Источники

[1] consultant.ru — Постановление Правительства РФ от 28.11.2011 № 977 «О федеральной государственной информационной системе «Единая система идентификации и аутентификации...» — https://www.consultant.ru/document/cons_doc_LAW_122455/

[2] riamo.ru — ЕСИА: что это такое и как создать учетную запись — подробная инструкция — https://riamo.ru/articles/shpargalki/esia-chto-eto-takoe-i-kak-sozdat-uchetnuyu-zapis-podrobnaya-instruktsiya/

[3] securitylab.ru — ЕСИА и СМЭВ – требования к ИБ при подключении к системе — https://www.securitylab.ru/blog/company/Rubikon/359259.php

[4] habr.com — Аутентификация через ЕСИА: ключевые аспекты интеграции — https://habr.com/ru/articles/893544/

[5] redsign.ru — Интеграция сайта с Госуслугами: авторизация через ЕСИА с иллюстрациями и примерами сайтов — https://www.redsign.ru/media/news/integratsiya-sayta-s-gosuslugami-avtorizatsiya-cherez-esia/

[6] vc.ru — Обязательная идентификация доменов через «Госуслуги»: что изменится с 1 сентября — https://vc.ru/legal/2923008-obyazatelnaya-identifikatsiya-domenov-cherez-gosuslugi

[7] esia.ru — Новый регламент ЕСИА — обзор требований — https://esia.ru/reglament_esia

[8] identityblitz.ru — Часто задаваемые вопросы (FAQ) по ЕСИА и подключению к ней — https://identityblitz.ru/products/esia-bridge/faq/

[9] uplab.ru — Интеграция сайта с Госуслугами, авторизация в ЕСИА — руководство и примеры — https://www.uplab.ru/blog/website-integration-with-public-services/

[10] esia.ru — Процедура подключения и интеграции с ЕСИА коммерческих компаний — https://esia.ru/integraciya_esia_kommers

[11] csr43.ru — Раздел 12.4 Регламента информационного взаимодействия Участников с Оператором ЕСИА (версия 2.7) — https://csr43.ru/files/reg-nov-co/Razdel_12.4.pdf

[12] digital.gov.ru — Регламент информационного взаимодействия Участников с Оператором ЕСИА и Оператором эксплуатации инфраструктуры электронного правительства — https://digital.gov.ru/documents/reglament-informaczionnogo-vzaimodejstviya-esia

[13] Минцифры России — методические рекомендации ЕСИА, версия 3.65 — https://sc.digital.gov.ru/documents/20127/35826/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5%2B%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D0%B0%D1%86%D0%B8%D0%B8%2B%D0%BF%D0%BE%2B%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8E%2B%D0%95%D0%B4%D0%B8%D0%BD%D0%BE%D0%B9%2B%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B%2B%D0%B8%D0%B4%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D0%B8%2B%D0%B8%2B%D0%B0%D1%83%D1%82%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D0%B8%2B%28%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8F%2B3.65%29.pdf/4b24b6e2-64af-a6c7-0bc4-0dd120e1ef93?download=true&t=1780324388650&version=1.0

[14] Минцифры России — регламент информационного взаимодействия ЕСИА, версия 2.54 — https://sc.digital.gov.ru/documents/-/document_library/03jzkn2sfJTq/view_file/9270883

[15] Официальное опубликование правовых актов — Федеральный закон № 569-ФЗ — https://publication.pravo.gov.ru/Document/View/0001202512290057

[16] Официальное опубликование правовых актов — Федеральный закон № 547-ФЗ — https://publication.pravo.gov.ru/document/0001202412280052