Механизмы единой аутентификации пользователей АС ОАО «РЖД» в подсистеме электронной подписи

[Admin]

Механизмы единой аутентификации пользователей АС ОАО «РЖД» в подсистеме электронной подписи

Галдин А.А.
Игин А.Г.
Калашников А.М.


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

В ОАО «РЖД» в настоящее время насчитывается несколько тысяч информационных систем и в ряде случаев сотрудникам ОАО «РЖД» приходится для выполнения своих функциональных обязанностей работать с несколькими автоматизированными системами (АС) одновременно. При этом пользователям необходимо авторизовываться в нескольких системах, помнить учетные данные для каждой системы, что в случае не частого обращения к данным системам может привести к утере учетных данных и/или их компрометации.
Учитывая актуальность для ОАО «РЖД», а также имеющиеся организационно-технические ограничения по взаимодействию АС в части передачи информации пользователям, было поставлена задача по использованию единой системы аутентификации на базе подсистемы электронной подписи (ПЭП), обеспечивающей применение простой расширенной электронной подписи (ПРЭП) в ОАО «РЖД». ПРЭП -простая электронная подпись с использованием альтернативных методов обеспечения авторства, целостности и неотказуемости для электронного документа (без применения средств электронной подписи).

ПЭП конструировалась как специальная АС, предоставляющая пользователям разных АС единые механизмы простановки электронной подписи (ЭП), аутентификации и авторизации. Изначально ПЭП разрабатывалась в составе интеллектуальной системы управления на железнодорожном транспорте (ИСУЖТ) - управляющей системы ОАО «РЖД», автоматизирующей полный цикл производственного процесса эксплуатационной работы ОАО «РЖД». В 2018 году ПЭП была выделена в единую подсистему для ОАО «РЖД» и была успешно применена в ряде корпоративных проектов, использующих электронную подпись для перехода на безбумажный электронный документооборот. В рамках реализации проекта были разработаны унифицированные программные модули для встраивания в АС различных уровней.
ПЭП была введена в промышленную эксплуатацию в ОАО «РЖД» в 2017 году и к настоящему времени имеет около 60 000 пользователей. На текущем этапе каждый день с использованием сервисов ПЭП подписывается около 120 000 документов. В перспективе при подключении большего количества АС ожидается подключение около 200 000 пользователей с увеличением потока подписания на один-два порядка.
Система аутентификации ПЭП построена на базе унифицированной технологии OAUTH 2.0.
OAUTH 2.0 (RFC 6749) - протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе. Протокол избавляет от необходимости доверять приложению логин и пароль, а также позволяет выдавать ограниченный набор прав, а не все сразу.
OAUTH протокол в ПЭП основан на использовании базовых вебтехнологий: HTTP-запросах, SSL, редиректах и т.п. с использованием отечественных алгоритмов шифрования.
Основные термины в рамках технологии OAUTH:

• • Сервер авторизации - субъект, ответственный за выдачу и проверку маркеров доступа.
• • Клиентское приложение (Клиент) - приложение, которое (А) получит маркер доступа с сервера авторизации и (Б) использует маркер доступа для вызова API с Сервера ресурсов.
• • Владелец ресурса (Пользователь) - конечный пользователь, взаимодействующий с клиентским приложением.
• • Сервер ресурсов (Автоматизированная система) - сущность, которая имеет API и может проверять маркеры доступа.
• • Маркер доступа (accesstoken) - это учетные данные, используемые для доступа к защищенным ресурсам.

Представляет из себя строку, обеспечивающую аутентификацию пользователя для АС. Маркеры представляют информацию для аутентификации с определенной продолжительностью доступа, предоставленные пользователем и применяемые АС и сервером аутентификации ПЭП. Маркер может обозначать идентификатор, используемый для извлечения информации об аутентификации, или может содержать информацию об аутентификации проверяемым образом (т.е. состоящую из некоторых данных и подписи). Маркер доступа заменяет различные конструкции аутентификации (например, имя пользователя и пароль) на один маркер, понятный АС и устраняет необходимость АС понимать широкий спектр методов проверки подлинности.

Технология аутентификации с использованием ПЭП позволяет сторонним приложениям (клиентам) получать ограниченный доступ к службам HTTP автоматизированных систем (серверам ресурсов). Вместо использования учетных данных владельца ресурса (пользователя) для доступа к защищенному ресурсу, клиент получает маркер доступа, на определенные области (scope), имеющий время жизни и другие атрибуты доступа. Маркеры доступа для клиентов выпускает сервер авторизации ПЭП с одобрения пользователя.
Для механизма OAUTH 2.0 существуют типовые библиотеки для различных языков программирования, которые могут быть встроены как в мобильные рабочие места, так и в код серверов приложений АС.
Автоматизированные системы обращаются к ПЭП с использованием зашифрованного SSL-канала с шифрованием по ГОСТ 28147-89 с использованием сертифицированных СКЗИ.
Использование OAUTH возможно на любой платформе с доступом к сети и браузеру: на сайтах, в мобильных и desktop-приложениях, плагинах для браузеров и т.п.
Стандарт имеет поддержку крупнейших площадок:

• • Портал «Госуслуги»
• • Портал налоговой службы РФ
• • Портал «Госуслуги Москвы»
• • Mail.ru
• • Vkontakte.ru и др.

Технология аутентификации с использованием ПЭП реализует механизм OAUTH 2.0 с использованием следующих типов авторизации:
• Implicit (Неявный);
• Resource Owner Password Credentials Grant (Пароль пользователя);
• Authorization Code (Код авторизации);
• Authorization Code with PKCE
(Код авторизации с ключом подтверждения для обмена кода);
• Client Credentials (Учетные данные клиента).
В таблице 1 приведены рекомендации по использованию различных типов авторизации.

Для авторизации пользователей АС ОАО «РЖД» с использованием ПЭП используется тип авторизации Authorization Code with PKCE.
Алгоритм аутентификации с использованием ПЭП состоит из следующих шагов (рис. 1):

1. Запрос программным обеспечением МРМ маркера доступа в ПЭП. На данном шаге пользователь авторизуется в ПЭП с использованием своего логина/ПИН-кода.
2. Получение в ответном сообщении от ПЭП Маркера доступа (AccessToken) и Маркера обновления (RefreshToken).
Маркер доступа выдается с коротким сроком действия - 10 минут (параметры могут быть скорректированы в процессе эксплуатации) и может использоваться неограниченное количество раз за это время. После истечения срока действия Маркера доступа он должен быть заменен с использованием маркера обновления.
Маркер обновления одноразовый и имеет большой срок действия -12 часов (параметры могут быть скорректированы в процессе эксплуатации). Маркер обновления предназначен для получения нового актуального Маркера доступа и Маркера обновления.

Запрос методов автоматизированных систем

• При запросе методов каждой из внешней системы вместо логина/ пароля автоматизированной системы должен передаваться действительный маркер доступа пользователя ПЭП.
• 4. Проверка Маркера доступа в ПЭП.
• Маркер доступа передается в ПЭП или валидируется АС самостоятельно с использованием ключа проверки сервера аутентификации ПЭП (в зависимости от типа выдаваемого маркера доступа).
• 5. Получение результата проверки.
• В случае успешной проверки АС получает идентификатор пользователя ПЭП.
• 6. Поиск пользователя в АС и принтие решения по аутентификации пользователя.
• С использованием идентификатора пользователя ПЭП АС ищет пользователя, определяет его уровень прав и формирует ответ на запрос пользователя.
• 7. Возврат пользователю данных, запрашиваемых на шаге 3.
• 8. Запрос нового Маркера доступа в случае истечения срока действия предыдущего. Новый Маркер доступа запрашивается с использованием ранее полученного на шаге 2 Маркера обновления.
• 9. Получение в ответном сообщении от ПЭП нового Маркера доступа и нового Маркера обновления.

Алгоритм аутентификации с использованием ПЭП с типом авторизации «Authorization Code with PKCE» Диаграмма последовательности действий, представляющая данный тип авторизации представлена на рис.2 и состоит из следующих шагов:

• 1) Владелец ресурса (пользователь) открывает приложение в своем браузере (или в другом клиенте) и нажимаете кнопку входа в систему. Приложение создает случайное значение (v) и хэширует это значение ($).
• 2) Приложение отвечает перенаправлением в браузер, включая хэшированное значение $.
• 3) Браузер следует за перенаправлением на сервер авторизации
• 4) Сервер авторизации сохраняет хэшированное значение $ для использования позже и возвращает форму входа.
• 5) Владелец ресурса (пользователь) отправляет свое имя пользователя и пароль непосредственно на сервер авторизации.
• 6) Сервер авторизации аутентифицирует вас и отправляет перенаправление с помощью недолговечного кода (а).
• 7) Браузер следует за перенаправлением в приложение, которое извлекает код а из URL-адреса.
• 8) Приложение делает POST-запрос на сервер авторизации, содержащий: идентификатор клиента, исходное случайное значение v, и временный код а. Сервер авторизации проверяет идентификатор клиента, генерирует хэш-значение v, сравнивает этот хэш с $-хэшем, который был сохранен ранее, и проверяет значение а.
• 9) Сервер авторизации отвечает на POST-запрос маркером доступа непосредственно в приложение.

Наиболее важным в данной технологии является то, что единственным значением, хранящимся в истории браузера, является одноразовый код временной авторизации: а. Сами маркеры доступа никогда не передаются через URL-адрес. Это связано с тем, что последний этап потока (шаги 8 и 9) является POST-запросом и соответствующим ему ответом.
Случайные значения v и его хэша $: используются для защиты от вредоносных приложений, пытающихся «прослушать» ответ кода авторизации и попытаться использовать его для получения маркера доступа. Это особенно актуально на мобильных платформах, таких как iOS или Android, в которых другое приложение, может прослушать ответ из первой части обмена (шаги 6 и 7). Только оригинальное приложение сможет передать правильное значение v для сервера авторизации (поскольку оно его создало), и сервер авторизации может проверить, что оно правильно на основе хэшированного значения $, сохраненного ранее.
Описанная выше технология использования единой аутентификации на базе ПЭП позволила:

• • Значительно упростить процедуру администрирования пользователей
• • Использовать возможность аутентификации с применением усиленной электронной подписи
• • Повысить защищенность с использованием единых механизмов аутентификации
• • Упростить процедуры ведения мониторинга и разбора инцидентов информационной безопасности
• • Использовать возможность работы с полноценным применением технологии «тонкий клиент».
• • Обеспечить безопасную передачу логина/ПИН-кода без компрометации со стороны внешних систем с использованием отечественной криптографии.
• • Использовать единую базу клиентов ПЭП для аутентификации во внешних системах.