Подписание УКЭП из локального Directum RX 4.1 в «облаке» КриптоПро DSS

Предыстория

У нас возникла необходимость использование сервиса облачной электронной подписи. Почему? Потому, что это лучше простой раздачи копий токенов. Сотрудники могут использовать носители бесконтрольно и в других сервисах кроме DirectumRX! А использование "облачных" токенов через RX гарантирует:

• оперативное управление правами подписи,
• оперативное управление полномочиями сотрудников,
• контроль доступа только из одного сервиса,
• подписи недоступны в других сервисах, например, Госуслугах,
• наличие детальной истории всех подписаний.

Покупать локальный сервер DSS да еще с обязательным «железом» оказалось запредельно дорого – итого около 4 млн. ₽!

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

Опыт настройки

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

1. Пользователи-подписанты из RX, подписывающие с использованием облачного сервиса, должны быть продублированы один-к-одному в DSS.
2. Логины подписантов при этом дублировании должны быть точными копиями логинов RX. Даже для доменной Microsoft Active Directory авторизации надо дублировать имя в DSS – “domain\user”.
3. Схема того, что делает RX для случая без штампа времени: по запросу пользователя на подписание документа формируется хэш документа; если сервер видит в настройке сертификата есть настройка плагина, то идет к внешнему серверу DSS по заданным в конфиге настройкам и предъявляет свой сертификат генерации системы RX; происходит авторизация, затем предъявляет одноименный логин RX и проходит далее; затем предъявляет свою открытую часть цифрового сертификата пользователя, выбранной при подписании; ищет соответствующий закрытый сертификат в DSS и предъявляет хэш дока; если все успешно, то обратно отсылается подтверждение УКЭПа.
4. Можно дополнительно запросить включение сервиса распознавания стороннего удостоверяющего центра (УЦ), чтобы можно было использовать свои старые сертификаты-токены от разных издателей. По-умолчанию подразумевается, что клиент запрашивает и использует сертификаты только КриптоПро.
5. Для пользователей СЭП не нужно запрашивать внешние логины для ЦИ DirectumRX. Это может сделать администратор-оператор DSS самостоятельно. Надо лишь будет сделать дополнительную настройку в кабинете DSS.

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

• Пункт 1. Совсем необязательно и даже неправильно сразу заключать договор. Мы предпочли «прощупать» сервис и возможности в тестовом режиме. Его любезно, бесплатно и быстро предоставляет КриптоПро. Составили запрос на подключение к тестовому СЭП с ролью оператора, для возможности регистрации других пользователей и управления их сертификатами.
  Имейте ввиду нюанс: если у вас будет свой оператор DSS пользователей и сертификатов, то потом перед заключением рабочего договора КриптоПро запросит наличие сертифицированного сотрудника по курсу «Оператор СЭП «КриптоПро DSS». Это требование законодательства на допуск, как я понял. Обучение 2 дня и у сторонних учебных центров дешевле 😊 около 25 тыс. ₽.
• Пункт 2. Отправка запроса. Необязательно писать письмо. Можно также заполнить форму прямо на сайте.  При этом указали для себя Схему обслуживания – Распределенная с оператором, чтобы свободно управлять своими подписантами в DSS. В любом случае указываем дополнительно «Требуется установить службы API v2».
• Подпункт 2.1 В инструкции не говорится о том, что КриптоПро помимо настроек присылает в архиве с паролем открытый и закрытый сертификаты авторизации оператора, доверенного и промежуточных своих центров. Они ставятся на рабочем месте оператора с использованием КриптоПро CSP 5. Обратите внимание на инструкцию по установке сертификата авторизации оператора с привязкой к закрытому ключу. Сертификаты центров надо установить и на рабочем сервере.
• Пункт 3. Настройка RX. Далее будьте готовы к тому, что в ответ п.2 КриптоПро присылает гораздо больше параметров, чем надо для настройки в RX. У неискушенного человека возникает проблема – куда какой параметр подставлять в конфиге RX. И вам может показаться, что они пересекаются. Полный набор параметров Директума с комментариями для целей DSS можно посмотреть здесь "..\inetpub\wwwroot\DrxWeb\api\_ConfigSettings.xml.example" в разделе -Список настроек плагина DSS-. Немного противоречивыми и некорректными выглядят примеры в справке в п.3.
  Лишним и мешающим работе оказался параметр в примере - «tspServiceAddress = "http://www.cryptopro.ru/tsp/tsp.srf"».
  Сложности сопоставления мы прошли и теперь готовое решение публикуем для вас, чтобы вы не тратили время на то же самое. Минимально необходимые параметры Директума – это clientId, identityCenterAddress, signatureServiceAddress, documentsStorageServiceAddress и signServiceResource. В присланном описании КриптоПро они назывались соответственно так – ClientID, «URL-адрес Центра идентификации СЭП», «URL-адрес прикладного интерфейса СЭП», «Сервис Обработки Документов» с добавлением к имени «/api» и «Идентификатор (resource) сервиса подписи». Итоговый блок плагина у нас выглядит так:
  <plugin id = "22837f59-e686-4c9b-a8e0-8dec1562aa0a"
     clientId = "clientNameX"
     identityCenterAddress = "https://stenddss.cryptopro.ru/NameXidp/"
     signatureServiceAddress = "https://stenddss.cryptopro.ru/NameXss/rest/api"
     documentsStorageServiceAddress ="https://stenddss.cryptopro.ru/NameXds/api"
     signServiceResource = "urn:cryptopro:dss:signserver:NameXss"
     cadesType = "BES"
     qualifiedCAThumbprints = "CC9D********************"
     platformTokenLifeTime = "00:05:00" />

Обращаю внимание на дополнительный последний параметр - сколько времени токен остается активным после первого использования. Он позволяет существенно уменьшить отклик на последующие подписания тем же токеном.

Есть замечание по cadesType и чтобы вам решить какой тип использовать, учитывайте нюанс, обозначенный здесь.

И еще одно замечание по параметрам. Мы натолкнулись на то, что в конфиге можно ненароком поставить не тот символ апострофа: вместо " такой “. Мы на этом обожглись.

После сохранения настроек рестартовать IIS, а не только пулы.

• Пункт 4 справки. Самый малоинформативный, потому что ссылается на самую полную и общую справку.
  А на самом деле достаточно сделать следующие шаги:
  • Использовать можно только следующие браузеры с поддержкой ГОСТ TLS: IE, Яндекс Браузер, Спутник, Chromium ГОСТ. Из других браузеров оператор просто не войдет в кабинет.
  • Оператор заходит в Центр идентификации СЭП https://stenddss.cryptopro.ru/NameXidp/Admins/. При этом для авторизации применяется присланный и установленный ранее (см. п.2.1) сертификат оператора с закрытой частью, без пароля. Видим: это: 
  • Заходим в Пользователи. Здесь уже должна быть учетка Оператора, которую КриптоПро создал по запросу. Создаем логины сотрудников-подписантов с одноименными логинами как в RX.
    Чтобы каждый подписант был внешним пользователем и подключался из нашей системы к DSS извне надо войти в Пользователи, затем в Аутентификацию и настроить так:

В результате учетка в списке станет выглядеть так:
 

• Теперь надо загрузить для нового подписанта в DSS закрытые ключи. Для этого надо экспортировать в файл закрытую часть ключа. Затем нажать у пользователя последнюю кнопку справа . Если сотрудник будет подписывать УКЭП от нескольких НОРов, то загружаем еще и другие закрытые ключи.
• Пункты 5 и 6 делаются как написано.
   

Идеи развитии сервиса облачной подписи

По завершении настройки возникают идеи о развитии сервиса облачной подписи в RX.

Переработать справку о DSS. Техподдержка Directum уже этим занимается.

Эффективнее и безопаснее было бы настроить схему отношений логинов пользователей RX и DSS не один-к-одному, а многие-к-одному-служебному-логину-DSS, который обладает всеми закрытыми ключами НОРов. Аналогично сервер приложений обращается к SQL-серверу через единую служебную учетку.

Почему текущая конфигурация неэффективна?

1. Двойная работа настроек одного пользователя админом и в Directum, и оператором в DSS.
2. Дважды загружать сертификаты для сотрудника: открытые в Directum и закрытые в DSS.
3. Человеческий фактор рано или поздно приведет к рассинхронизации настроек в системах. При увольнении или переводе сотрудника надо синхронно менять настройки в обоих системах. Ненадежно.
4. Сложности и непонятки при замещении.
5. Сейчас двойные настройки постоянно производят два разных сотрудника: админ Directum и оператор DSS.
   В новой схеме централизованно текучку обрабатывает только админ Directum. В DSS при этом настройка и загрузка всех закрытых сертификатов производится оператором только один раз в начале.
   В предлагаемой мной схеме указанных недостатков и «задвоенной» работы нет. В случае же если конкретные сертификаты могут быть использованы только конкретными сотрудниками (например сертификат врача для подписания электронного больничного листа), то можно оставить старую схему как дополнение для комбинирования способов.

КриптоПро в конце сам предложил создать у себя готовый профиль, чтобы по вводным сразу создавать у себя нужные настройки для нового клиента. Для этого надо будет просто назвать ключевое слово «Директум DSS». Но это пока в проработке.

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

Послесловие: Настройка рабочего контура с DSS вскрыла еще пару важных моментов, на которые я обращаю ваше внимание. Требуйте или сами устанавливайте:
1. Отмена подтверждений операций в Аутентификации у логинов. Техподдержка сказала, что возможно в будущем RX научится обрабатывать подтверждения.

2. Разрешить подписание документов и по хэшу документа, а не только по телу.

3. Если планируете использовать усиленную подпись и их сервер штампов времени, то запросите сертификат этого сервера.