SavePearlHarbor

Вход по УКЭП в корпоративных системах: практическая архитектура

—

от автора

admin

Почти в каждой крупной корпоративной или государственной системе рано или поздно возникает задача — авторизация с использованием усиленной квалифицированной электронной подписи (УКЭП)

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

И каждый из них добавляет определенный набор требований:

  • где и как проверять сертификаты;

  • как организовать доверие к удостоверяющим центрам;

  • как встроить УКЭП в веб-приложения;

  • как обеспечить масштабирование и эксплуатацию;

  • как работать с разными типами клиентов и устройств.

В этой статье разберем практическую архитектуру входа по УКЭП, которую можно внедрить в существующую инфраструктуру без изменения кода основных приложений — достаточно добавить специализированный шлюз и настроить компоненты проверки сертификатов.

Контекст и исходная проблема

В современных информационных системах пароль в качестве единственного фактора аутентификации постепенно утрачивает свою актуальность. Причин тому несколько:

  • парольные механизмы плохо масштабируются в условиях корпоративной инфраструктуры;

  • их сложно надежно защитить от компрометации;

  • использование только паролей затрудняет соблюдение требований регуляторов и отраслевых стандартов безопасности.

При этом во многих организациях уже существует готовая технологическая основа — инфраструктура с квалифицированными сертификатами усиленной квалифицированной электронной подписи (УКЭП) и удостоверяющих центров (УЦ).

Применение УКЭП в сценариях аутентификации обеспечивает сразу три ключевых свойства:

  • идентификацию пользователя;

  • аутентификацию;

  • юридическую значимость совершаемых действий.

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

Чего на самом деле ждут от входа по УКЭП

Практическая реализация входа по УКЭП — это не просто проверка наличия сертификата. В реальной системе обычно требуется:

  • поддержка ГОСТ-криптографии;

  • проверка цепочки доверия;

  • проверка статуса сертификата (через CRL — списки отозванных сертификатов, OCSP — протокол онлайн-проверки);

  • проверка квалифицированности сертификата;

  • интеграция с веб-приложениями;

  • масштабируемость;

  • возможность контейнерного развертывания;

  • работа в сертифицированных ОС (например, Astra Linux).

Какие подходы вообще есть

1. TLS-аутентификация (mTLS)

Наиболее очевидный вариант — использование клиентских сертификатов на уровне TLS. Данный механизм обеспечивает:

  • защищенный канал передачи данных;

  • подтверждение факта наличия сертификата у клиента.

Однако здесь присутствует существенное ограничение. В рамках mTLS не учитываются:

  • квалифицированность сертификата;

  • юридическая значимость электронной подписи;

  • бизнес-логика приложения.

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

2. Связка с Identity (OIDC / SSO)

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

  • OIDC (OpenID Connect);

  • SSO (Single Sign-On);

  • сессионные механизмы.

Такой подход позволяет не внедрять криптографию непосредственно в каждое приложение, а вынести логику проверки сертификатов на уровень Identity-провайдера.

3. Серверная проверка УКЭП

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

Такой сервис занимается:

  • проверкой квалифицированности сертификата;

  • управлением доверием к удостоверяющим центрам;

  • обработкой CRL / OCSP;

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

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

Как выглядит архитектура в целом

Если собрать все вместе, получается довольно понятная цепочка:

Клиент → TLS (ГОСТ / обычный)

      → шлюз (Gate)

     → сервис проверки сертификатов

      → identity (OIDC)

      → прикладные системы

Часто встречается требование обслуживать на одной точке входа клиентов с поддержкой ГОСТ-алгоритмов и без нее. Для этого на шлюзе настраивают двойной TLS на одном порту:

  • RSA-сертификат — для установления защищенного канала (работает с любым клиентом);

  • ГОСТ-сертификат — для аутентификации пользователя. 

RSA используется только на этапе TLS-хендшейка. Сама аутентификация выполняется по ГОСТ-сертификату. Такой подход закрывает оба типа клиентов без расширения точек входа.

Роль шлюза (Gate)

Шлюз выполняет первичную проверку сертификата и служит точкой входа для всех клиентских соединений.

Основные функции:

  • работа в режиме HTTPS-прокси;

  • завершение TLS-соединений (включая mTLS);

  • проксирование запросов в backend;

  • извлечение данных сертификата из TLS-сессии.

Типовой сценарий:

  1. Клиент подключается к шлюзу и предъявляет сертификат.

  2. Устанавливается защищенное соединение.

  3. Запускается OIDC-процесс.

  4. Данные сертификата передаются в прикладные системы.

Шлюз преобразует низкоуровневые данные сертификата из TLS-сессии в HTTP-заголовки для последующей обработки вышестоящими системами.

На практике в роли такого шлюза часто выступает Apache HTTP Server с модулем mod_ssl mod_ssl из состава  КриптоПро CSP. Эта конфигурация совместима с ГОСТ-алгоритмами и проверена в промышленной эксплуатации.

Сервис проверки сертификатов

После шлюза задействуется отдельный компонент — сервис проверки сертификатов.

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

  • проверяет цепочку сертификатов до корневого сертификата доверенного УЦ;

  • проверяет статус сертификата (OCSP, CRL);

  • определяет, является ли сертификат квалифицированным.

За счет централизации правила проверки (список доверенных УЦ, настройки OCSP/CRL) задаются один раз и применяются ко всем клиентам. Разработчикам прикладных систем не нужно реализовывать PKI-логику — достаточно вызывать этот сервис.

Такое решение избавляет от дублирования логики в каждом приложении и дает единую точку контроля для аудита и мониторинга.

Identity-слой

Следующий уровень — управление идентификацией (identity).

Здесь происходит:

  • связывание сертификата с пользователем;

  • управление сессиями;

  • выдача OIDC-токенов.

Прикладные системы получают результат аутентификации — подтвержденный идентификатор пользователя в OIDC-токене. Вся криптографическая часть остается на уровнях шлюза и сервиса проверки сертификатов.

Клиентская сторона: где возникает больше всего сложностей

На практике именно клиентская часть становится источником большинства проблем при внедрении.

Есть два основных подхода.

Вариант 1: браузеры с поддержкой ГОСТ-алгоритмов

Плюс:

  • нативная работа с TLS — браузер сам устанавливает защищенное соединение без дополнительных прослоек.

Минусы:

  • сложная установка — требуется установка криптопровайдера и браузерного плагина на каждой рабочей станции (например, КриптоПро CSP + Browser Plugin);

  • проблемы с поддержкой — обновление браузера может нарушить работу плагина; пользователь часто не может самостоятельно определить причину неисправности.

Вариант 2: отдельный клиент

Альтернатива — использовать отдельное приложение, которое:

  • работает как ГОСТ TLS-клиент;

  • управляет сертификатами;

  • само устанавливает защищенное соединение.

Плюсы для эксплуатации:

  • независимость от браузеров — не нужно тестировать под каждый;

  • поддержка мобильных устройств;

  • предсказуемое поведение — версия клиента фиксирована, среда контролируема.

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

Переход к практике: реализация на базе решений КриптоАРМ

Если идти не через кастомную разработку, а опираться на готовые компоненты, такую архитектуру можно собрать достаточно быстро на базе решений КриптоАРМ — в них уже заложено разделение на нужные слои.

В упрощенном виде схема выглядит так:

Клиент → TLS / ГОСТ TLS

→ КриптоАРМ Gate

→ КриптоАРМ Server

→ КриптоАРМ ID (OIDC)

→ прикладные системы

Общая схема аутентификации по УКЭП

Общая схема аутентификации по УКЭП

КриптоАРМ Gate

Точка входа и HTTPS-шлюз:

  • завершает TLS (включая mTLS);

  • принимает сертификат пользователя;

  • извлекает его данные;

  • проксирует запросы в backend.

Пример конфигурации Apache:

<VirtualHost *:443>    ErrorLog ${APACHE_LOG_DIR}/error.log    CustomLog ${APACHE_LOG_DIR}/access.log combined    SSLEngine on    SSLHonorCipherOrder on    SSLCertificateFile /certs/gost/server.cer    SSLCertificateFile /certs/rsa/server.cer    SSLVerifyClient require    RequestHeader unset X-SSL-Client-Verify    RequestHeader unset X-SSL-Client-DN    RequestHeader unset X-SSL-Client-Serial    RequestHeader unset X-SSL-Client-Issuer    RequestHeader unset X-SSL-Client-Cert    RequestHeader set X-SSL-Client-Verify "%{SSL_CLIENT_VERIFY}e"    RequestHeader set X-SSL-Client-DN "%{SSL_CLIENT_S_DN}s"    RequestHeader set X-SSL-Client-Serial "%{SSL_CLIENT_M_SERIAL}e"    RequestHeader set X-SSL-Client-Issuer "%{SSL_CLIENT_I_DN}s"    RequestHeader set X-SSL-Client-Cert "%{SSL_CLIENT_CERT}s"    ProxyPreserveHost On    ProxyPass /api http://backend/    ProxyPassReverse /api http://backend/</VirtualHost>

На практике используется схема двойного TLS (ГОСТ + RSA), чтобы одновременно поддержать и ГОСТ-клиентов, и обычные браузеры.

КриптоАРМ Server

Отвечает за централизованную проверку сертификатов:

  • проверка квалифицированности;

  • проверка доверия к УЦ;

  • работа с CRL и OCSP;

  • использование TSL-списков Минцифры.

Он позволяет вынести всю криптографическую и регуляторную логику из прикладных систем.

Проверка квалифицированности сертификата

Проверка квалифицированности сертификата

Связка с OIDC-mTLS

КриптоАРМ OIDC-mTLS — это дополнительный модуль, который обеспечивает интеграцию проверки сертификатов с OIDC-потоком аутентификации.

В этой схеме:

  • OIDC-mTLS принимает сертификат в рамках аутентификации и управляет OIDC-потоком

  • КриптоАРМ Server используется как сервис проверки сертификата

На основании результата, полученного от сервиса проверки, модуль принимает решение о допуске пользователя и дальнейшем продолжении OIDC-аутентификации.

API модуля КриптоАРМ OIDC-mTLS

API модуля КриптоАРМ OIDC-mTLS

КриптоАРМ ID

Реализует слой identity:

  • связывает сертификат с пользователем;

  • управляет сессиями;

  • обеспечивает OIDC-аутентификацию;

  • интегрируется с корпоративными системами.

Виджет авторизации КриптоАРМ ID

Виджет авторизации КриптоАРМ ID

Клиентская часть

Приложения КриптоАРМ (десктопные и мобильные версии) используются в качестве ГОСТ TLS-клиента.

В этом сценарии КриптоАРМ:

  • работает с сертификатами пользователя;

  • обеспечивает их выбор и использование;

  • устанавливает защищенное соединение с Gate.

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

Что это дает:

  • независимость от браузеров;

  • поддержку мобильных устройств;

  • единый пользовательский сценарий;

  • централизованное управление сертификатами;

  • предсказуемость работы вне зависимости от окружения.

 Выбор сертификата в клиентском приложении КриптоАРМ

 Выбор сертификата в клиентском приложении КриптоАРМ

Пример контейнерного развертывания

services:  cryptoarm-id-back:    image: registry.digtlab.ru/cryptoarm/id/back  cryptoarm-id-mtls:    image: registry.digtlab.ru/cryptoarm/gate/oidc/mtls    env_file:      - ./OIDC/mtls/.env

Пример .env:

ROOT_PATH=/mtls/OIDC_ISSUER=https://id.example.ruOIDC_CLIENT_ID=e4fb09dbeba1498486c839b6cff289b9OIDC_CLIENT_SECRET=f9a6b8b6fc3d4addb0359ed3a58b402cOIDC_REDIRECT_URI=https://id.example.ru/api/interaction/codeMTLS_AUTHORIZATION_URL=https://id.example.ru:3443/mtlsAuthorizationREQUIRE_QUALIFIED_CERT=true

Заключение

Вход по УКЭП — это не отдельная функция и не один сервис. Это архитектура, в которой каждый компонент решает свою конкретную задачу:

  • транспорт (TLS);

  • шлюз (Gate);

  • сервис проверки сертификатов;

  • identity-слой (OIDC);

  • клиентская часть.

Выводы

Изложенная схема построена за счет нескольких ключевых принципов:

  • разделение ответственности между слоями;

  • вынесение криптографии и проверки сертификатов из приложений;

  • использование шлюза (Gate) как точки входа и центра интеграции;

  • применение OIDC для централизованной авторизации;

  • поддержка mTLS как базового механизма аутентификации;

  • централизованная проверка УКЭП через отдельный сервис;

  • поддержка разных типов клиентов (браузеры и нативное приложение) без привязки к одному сценарию.

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

ссылка на оригинал статьи https://habr.com/ru/articles/1028582/