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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• проверка статуса сертификата (через 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-аутентификации.

КриптоАРМ ID

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

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

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

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

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

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

Приложения КриптоАРМ (десктопные и мобильные версии) используются в качестве ГОСТ 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.ru
OIDC_CLIENT_ID=e4fb09dbeba1498486c839b6cff289b9
OIDC_CLIENT_SECRET=f9a6b8b6fc3d4addb0359ed3a58b402c
OIDC_REDIRECT_URI=https://id.example.ru/api/interaction/code
MTLS_AUTHORIZATION_URL=https://id.example.ru:3443/mtlsAuthorization

REQUIRE_QUALIFIED_CERT=true

Заключение

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

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

• шлюз (Gate);

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

• identity-слой (OIDC);

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

Выводы

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

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

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

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

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

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

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

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

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