Единая система идентификации и аутентификации. Методические рекомендации по использованию Единой системы идентификации и аутентификации Версия 2.20

2 нормативные ссылки

При разработке Регламента взаимодействия были использованы нормы, требования и рекомендации, приведенные в следующих законодательных, нормативных-правовых и иных актах:

– Федеральный закон от 27 июля 2021 г. № 210-ФЗ «Об организации предоставления государственных и муниципальных услуг».

– Федеральный закон от 6 апреля 2021 г. № 63-ФЗ «Об электронной подписи».

– Федеральный закон Российской Федерации от 5 мая 2021 г. № 110-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации» (далее – 110-ФЗ).

– Федеральный закон от 7 августа 2001 г. № 115-ФЗ «О противодействии легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма».

– Федеральный закон Российской Федерации от 4 июня 2021 г. № 149-ФЗ «О внесении изменений в Закон Российской Федерации “Об организации страхового дела в Российской Федерации” и отдельные законодательные акты Российской Федерации» (далее – 149-ФЗ).

– Государственная программа Российской Федерации «Информационное общество (2021 – 2020 годы)», утвержденная распоряжением Правительства Российской Федерации от 20 октября 2021 г. № 1815-р.

– Постановление Правительства Российской Федерации от 28 ноября 2021 г. № 977 «О федеральной государственной информационной системе «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме».

– Постановление Правительства Российской Федерации от 28 декабря 2021 г. № 1184 «О мерах по обеспечению перехода федеральных органов исполнительной власти и органов государственных внебюджетных фондов на межведомственное информационное взаимодействие в электронном виде».

– Постановление Правительства Российской Федерации от 9 февраля 2021 г. № 111 «Об электронной подписи, используемой органами исполнительной власти и органами местного самоуправления при организации электронного взаимодействия между собой, о порядке её использования, а также об установлении требований к обеспечению совместимости средств электронной подписи».

– Постановление Правительства Российской Федерации от 25 января 2021 г. № 33 «Об использовании простой электронной подписи при оказании государственных и муниципальных услуг».

– Постановление Правительства Российской Федерации от 10 июля 2021 г. № 584 «Об использовании федеральной государственной информационной системы «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме».

– Распоряжение Правительства Российской Федерации от 15 октября 2009 г. № 1475-р «Об определении ОАО «Ростелеком» единственным исполнителем работ по эксплуатации инфраструктуры электронного правительства – единым национальным оператором инфраструктуры электронного правительства».

– Положение «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме», утверждённое постановлением Правительства Российской Федерации от 8 июня 2021 г. № 451.

– Положение «О федеральной государственной информационной системе «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме», утверждённое приказом Минкомсвязи России от 13 апреля 2021 г. № 107.

1.2 Аутентификация с использованием OpenID Connect 1.0

1 и 2 шаг: Регистрация ИС

Регистрация ИС осуществляется согласно Регламенту (раздел 6).

При использовании способа аутентификации, основанного на OAuth 2.0 и расширения OpenID Connect, не требуется формирование метаданных.

3 шаг: Доработать систему

Рекомендуемая последовательность действий:

1. Выпустить ключевой контейнер и сертификат ключа квалифицированной электронной подписи для подключаемой информационной системы (должен содержать ОГРН ЮЛ, являющегося оператором информационной системы).

Дополнительно поддерживается работа с ключевым контейнером и сертификатом ключа неквалифицированной электронной подписи в формате X.509 версии 3. В этом случае является допустимым самостоятельно сгенерировать (например, с помощью утилиты keytool из состава Java Development Kit) для своей системы ключевой контейнер и самоподписанный сертификат.

Сертификат требуется для идентификации ИС при взаимодействии с ЕСИА. ЕСИА поддерживает алгоритмы формирования электронной подписи RSA с длиной ключа 2048 бит и алгоритмом криптографического хэширования SHA-256, а также алгоритм электронной подписи ГОСТ Р 34.10-2001 и алгоритм криптографического хэширования ГОСТ Р 34.11-94.

2. Реализовать интерфейсы системы-клиента REST-сервисов ЕСИА и модели контроля доступа, основанной на OAuth 2.0. Детальная информация содержится в приложениях Б и В.

3. Доработать дизайн сайта, выбрав место для размещения кнопки «Войти через ЕСИА» и реализовать в системе логику запроса данных о пользователях, получаемых с помощью программного интерфейса ЕСИА. Недопустимо отображать страницу аутентификации ЕСИА во фрейме сайта.

4. Обеспечить в соответствии с требованиями законодательства комплекс мер, необходимых для обеспечения информационной безопасности и защиты персональных данных пользователей, получаемых информационной системой в процессе ее взаимодействия с системой ЕСИА.

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

6. Осуществить подключение ИС к тестовой среде и отладить взаимодействие с ЕСИА в тестовой среде в соответствии с Регламентом*(10).

4 шаг: Ввести доработку в эксплуатацию

1. Осуществить подключение ИС к промышленной ЕСИА в соответствии с Регламентом*(11).

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

I. права и обязанности участника информационного взаимодействия

1. Осуществляя взаимодействие с ЕСИА, участник информационного взаимодействия гарантирует, что:

a. У участника принят и утверждён внутренним приказом регламент по работе с КЭП в организации;

b. Он осведомлен, что групповое использование КЭП, выданного на одно должностное лицо, иными сотрудниками запрещено;

c. При работе с ЕСИА осуществляется проверка подлинности и действительности ДУЛ, предъявляемого всеми заявителями (в том числе проверка документа техническими средствами на соответствие требованиям, утвержденным ФМС к паспорту гражданина РФ, а также проверка на подлинность для паспортов иностранных граждан на предмет целостности документа и наличия на нем защитных средств).

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

d. Обеспечено принятие заявлений по форме и в порядке, предусмотренном требованиями Регламента и нормативных правовых актов;

e. В организации установлена ответственность для сотрудников за несоблюдение требований Регламента и нормативных правовых актов. Сотрудники оповещены об ответственности.

f. Ввод в ЕСИА данных заявителей вносится в полном соответствии с оригиналами предоставленных документов, внесение сведений на основании заявления без сличения соответствия сведений не осуществляется.

g. Работа специалистов по обслуживанию заявителей и электронное взаимодействие осуществляется исключительно в соответствии с руководством пользователя ЕСИА, руководством пользователя АРМ ЕСИА и руководством пользователя сервиса регистрации пользователей ЕСИА в СМЭВ.

h. Услуги по созданию (замене) и выдаче ПЭП (регистрации в ЕСИА) заявителям оказываются безвозмездно.

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

j. Сотрудники, являющиеся специалистами по выдаче ПЭП, прошли инструктаж по теме электронного правительства, ЕСИА, ЕПГУ, владеют действующей документацией.

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

2. Участник осознает, что нарушение требований и условий, содержащихся в настоящем разделе, повлечет отключение от сервисов и интерфейсов ЕСИА.

3. Право выдачи ПЭП может быть отозвано по усмотрению Оператора эксплуатации ИЭН или оператора ИЭП у участника, если имеются признаки нарушений требований, действующих нормативных правовых актов, в том числе Федерального закона от 06.04.2021 N 63-ФЗ “Об электронной подписи”, Федерального закона от 27.07.

2006 N 152-ФЗ “О персональных данных”, Постановления Правительства РФ от 25.01.2021 N 33 “Об использовании простой электронной подписи при оказании государственных и муниципальных услуг”, Приказа Минкомсвязи России от 13.04.2021 № 107 “Об утверждении Положения о федеральной государственной информационной системе “Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме” .

4. Участник информационного взаимодействия обязуется не хранить и не обрабатывать, не передавать и не собирать (в том числе от самих пользователей) информацию о паролях пользователей ЕСИА. В случае, если в организации имеется информация о таких паролях, то с момента вступления настоящей версии Регламента в силу он обязан прекратить выполнять указанные действия.

5. Участник информационного взаимодействия обязуется принимать заявления от заявителей исключительно силами сотрудников организации, указанной в заявлении на право выдачи ПЭП.

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

7. Хранить заявления в течение трёх лет с момента обращения.

8. Соблюдать требования по уровню безопасности систем, которые Участник подключает к ЕСИА.

9. Участник не в праве:

a. Выполнять операции без личного присутствия заявителя, в том числе по телефону, email и т.д.;

b. Использовать недокументированные в РП функции предоставляемого ПО и сервисов;

c. Использовать функциональность ЕСИА для получения доступа к персональным данным пользователя;

d. Регистрировать пользователя с использованием контактов, полученных от иного лица (не являющегося владельцем указываемых при обращении к ЕСИА персональных данных);

e. Предоставлять доступ к предоставляемому Оператором ЕСИА ПО, интерфейсам и сервисам ЕСИА третьим лицам;

f. Осуществлять передачу функции приёма заявлений, подтверждения личности, доступа к АРМ ЕСИА и сервису ЕСИА в СМЭВ, функцию открытия ЦО или выполнение иных операций в рамках регистрации в ЕСИА или выдачи ПЭП в иные организации, ИП, подведомственные учреждения или иным лицам, не являющимися сотрудниками зарегистрированного действующего оператора выдачи ПЭП.

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

Базовый сценарий аутентификации

Базовым сценарием аутентификации при использовании OpenID Connect 1.0 является сценарий аутентификации физического лица (например, заявителя).

Сценарий включает следующие шаги:

1. Пользователь нажимает на веб-странице системы-клиента кнопку «Войти через ЕСИА».

2. Система-клиент формирует и отправляет в ЕСИА запрос на аутентификацию и перенаправляет браузер пользователя на специальную страницу предоставления доступа.

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

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

5. Если пользователь дает разрешение на проведение аутентификации системой-клиентом, то ЕСИА выдает системе-клиенту специальный авторизационный код.

6. Система-клиент формирует в адрес ЕСИА запрос на получение маркера идентификации, включая в запрос полученный ранее авторизационный код.

7. ЕСИА проверяет корректность запроса (например, что система-клиент зарегистрирована в ЕСИА) и авторизационного кода и передает системе-клиенту маркер идентификации.

8. Система-клиент извлекает идентификатор пользователя из маркера идентификации. Если идентификатор получен, а маркер проверен, то система-клиент считает пользователя аутентифицированным.

После получения маркера идентификации система-клиент использует REST-сервисы ЕСИА для получения дополнительных данных о пользователе, предварительно получив соответствующий маркер доступа (см. приложения Б и В).

Рисунок 4 – Идентификация и аутентификация пользователей при использовании механизма OpenID Connect 1.0

Дополнительный сценарий аутентификации пользователя в качестве представителя организации

ЕСИА также позволяет аутентифицировать пользователя в качестве представителя организации, для этого ИС должна:

– запросить у ЕСИА не только маркер идентификации, но и маркер доступа (на получение данных пользователя);

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

– запросить у пользователя, от имени какой организации он будет работать в данной ИС (если пользователь является сотрудником нескольких организаций).

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

Необходимо помнить, что выбор организации, от имени которой будет работать пользователь в ИС, должен происходить на стороне самой ИС с использованием ее средств.

В.1 общие сведения

OAuth 2.0 определяет протокол взаимодействия следующих сторон:

– владелец ресурса (resource owner) – сущность, которая может предоставить доступ к защищаемому ресурсу (например, конечный пользователь);

– система-клиент (client) – приложение, которое запрашивает доступ к защищаемому ресурсу от имени владельца ресурса;

– сервис авторизации (authorization server) – сервис, который выпускает для клиента маркеры доступа с разрешения владельца ресурса;

– поставщик ресурса (resource server) – сервис, на котором размещены защищаемые ресурсы, и который может принимать запросы на доступ к защищаемым ресурсам и отвечать на эти запросы.

Модель контроля доступа, реализуемая сервисом авторизации ЕСИА, основана на использовании маркера доступа (security access token). Этот маркер несет информацию о подмножестве полномочий системы-клиента, о самой системе-клиенте, а также ряд служебных параметров.

С точки зрения системы-клиента маркер доступа представляет собой набор символов. Системе-клиенту для получения доступа к защищенным ресурсам (т.е. делать успешные вызовы программного интерфейса), как правило, не требуется расшифровывать маркер доступа, достаточно лишь получать по определенным правилам и корректно использовать. В то же время в ЕСИА предусмотрены и «подписанные» маркеры доступа, которые можно проверить без обращения к ЕСИА.

В ЕСИА используются два способа получения маркера доступа:

1. Система-клиент получает маркер доступа в результате делегированного принятия решения сервисом авторизации на основании согласия владельца ресурса. В этом случае сервис авторизации выдает маркер доступа, если явными образом получает разрешение со стороны владельца ресурса.

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

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

Аутентификация пользователя, реализуемая с помощью модели OAuth 2.0 и распишения OpenID Connect, основана на использовании маркера идентификации (ID token). Этот маркер несет информацию об идентификационных данных пользователя, а также ряд служебных параметров.

В.2.1 общие принципы

Данная модель контроля доступа используется в случаях, когда система-клиент при доступе к ресурсу должна получить разрешение на это действие со стороны владельца ресурса.

В общем виде схема взаимодействия выглядит следующим образом:

– система-клиент запрашивает у владельца ресурса разрешение на доступ к соответствующим ресурсам. Обычно этот запрос осуществляется не напрямую к владельцу ресурса, а опосредованно через сервис авторизации (который, в свою очередь, запрашивает разрешение у владельца ресурса), поскольку сам владелец ресурса не может выдать ни маркер доступа, ни авторизационный код;

– система-клиент получает разрешение на доступ (authorization grant) в виде авторизационного кода;

– система-клиент запрашивает маркер доступа, предъявив авторизационный код сервису авторизации;

– сервис авторизации аутентифицирует систему-клиента, проверяет авторизационный код и выдает маркер доступа и маркер обновления;

– система-клиент запрашивает у поставщика защищенный ресурс, предъявляя маркер доступа;

– поставщик ресурса проверяет маркер доступа, если он валиден, то разрешает доступ к защищенному ресурсу;

– система-клиент вновь запрашивает с помощью выданного ранее маркера доступ к защищенному ресурсу;

– поставщик ресурса проверяет маркер, обнаруживает, что срок его действия истек, возвращает сообщение об ошибке;

– система-клиент обращается к сервису авторизации за получением нового маркера доступа, предъявляя маркер обновления;

– сервис авторизации проверяет валидность маркера обновления и возвращает два новых маркера: доступа и обновления.

Схема взаимодействия представлена на рисунке 15.

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

Ключевая особенность этой модели в том, что сам владелец ресурса никогда не получает маркер доступа, его получает сама система-клиент в результате прямой связи с сервисом авторизации (server-side flow).

Рисунок 15 – Общая схема взаимодействия при получении маркера доступа с помощью авторизационного кода

Для оптимизации повторного получения маркера доступа используется механизм маркера обновления (refresh token): в этом случае первоначально в обмен на авторизационный код системе-клиенту выдается не только маркер доступа, но и маркер обновления. Когда маркер доступа перестает действовать, система-клиент обращается к сервису авторизации за получением нового маркера доступа, предъявляя маркер обновления.

Особенности маркера обновления:

– имеет более длительный (или бессрочный) срок действия, чем у маркера доступа;

– предъявляется исключительно при необходимости получить новый маркер доступа (таким образом, минимизируется риск перехвата);

– выдается сервисом авторизации одновременно с маркером доступа;

– может быть отозван владельцем ресурса.

Таким образом, наличие маркера обновления позволяет системе-клиенту получать новый маркер доступа даже тогда, когда пользователь (владелец ресурса) недоступен, при условии, что владелец ресурса явным образом не запретил доступ.

В.7 сведения о структуре маркера идентификации

Структура маркера идентификации аналогична структуре маркера доступа (см. Приложение В.5) и состоит из тех же трех частей: заголовок, набор утверждений и подпись.

Особенность заголовка маркера идентификации состоит в том, что него значение атрибута «sbt» равно «id».

Пример заголовка маркера идентификации в ЕСИА:

Сообщение, включающее в себя содержательные утверждения о маркере идентификации и пользователе, включает следующие атрибуты:

1) время аутентификации («auth_time») – время, когда произошла аутентификация пользователя, указывается в секундах с 1 января 1970 г. 00:00:00 GMT;

2) время прекращения действия («exp»), указывается в секундах с 1 января 1970 г. 00:00:00 GMT;

3) идентификатор субъекта («sub»), в качестве значения указывается oid. Этот идентификатор уникален для каждого субъекта, зарегистрированного в ЕСИА, и остается неизменным при последующих аутентификациях; адресат маркера («aud»), указывается client_id системы, направившей запрос на аутентификацию;

4) организация, выпустившая маркер («iss»), указывается URL ЕСИА;

5) время начала действия («nbf») – в секундах с 1 января 1970 г. 00:00:00 GMT, т.е. маркер нельзя обрабатывать до наступления указанного времени;

6) внутренний идентифивкатор сессии ЕСИА («urn:esia:sid»);

7) начало блока описания субъекта вызова сессии («urn:esia:sbj»);

8) псевдоним субъекта («urn:esia:sbj:nam») – внутренний для ЕСИА псевдоним пользователя;

9) oid субъекта («urn:esia:sbj:oid») – oid учетной записи пользователя;

10) тип субъекта («urn:esia:sbj:typ»), может принимать различные значения, например – «P» (физическое лицо);

11) признак подтвержденности субъекта («urn:esia:sbj:is_tru») – «is trusted» – учетная запись пользователя подтверждена. Параметр отсутствует, если учетная запись не подтверждена;

12) способ авторизации («urn:esia:amd»), может принимать два значения: «DS» (электронная подпись) или «PWD» (пароль);время выдачи («iat»), указывается в секундах с 1 января 1970 г. 00:00:00 GMT;

13) метод аутентификации («amr», приватное обозначение), может принимать два значения: «DS» (электронная подпись) или «PWD» (пароль);

Пример сообщения маркера идентификации в ЕСИА:

Подпись (signature) маркера осуществляется по алгоритму, который указывается в параметре «alg» маркера. Подпись вычисляется от двух предыдущих частей маркера (HEADER.PAYLOAD).

Пользователям 1с-отчётность, 1с:подпись, 1с-этп рекомендуется перевыпустить кэп

Портал госуслуг