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

20 12

Предыстория

У нас возникла необходимость использование сервиса облачной электронной подписи. Почему? Потому, что это лучше простой раздачи копий токенов. Сотрудники могут использовать носители бесконтрольно и в других сервисах кроме 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. Если планируете использовать усиленную подпись и их сервер штампов времени, то запросите сертификат этого сервера.

Николай Копышков

Отличная инструкция!

Очень пригодится, когда так же буду пробовать это всё добро в деле.

Денис Архипов

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

Сергей Королев

Денис, Опровергаю ваше утверждение. Уже сейчас в DSS у меня привязано несколько сертификатов к одному логину и никакой компрометации не случилось, все работает. То же самое и в RX.

Сергей Королев: обновлено 26.10.2021 в 16:53
Наталия Рвачева

С 1 января 2022 года будут использоваться УКЭП физического лица. Данные подписи тоже (закрытые части) будут импортированы в DSS? Если сотрудник не захочет отдавать свою закрытую часть, как быть?

Не прорабатывали такой вопрос?

Сергей Королев

Наталия, Не прорабатывали. Да и зачем? Пусть используют личный токен на рабочем месте при подписании. И не надо у этого открытого сертификата в RX указывать плагин, тогда будет работать по-старому как обычно без DSS. Нам же никто не мешает комбинировать способы.

Сергей Королев: обновлено 26.10.2021 в 17:08
Сергей Королев

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

Андрей Дозоров

Сергей,  я думаю в данном случае все немного в другой плоскости нужно рассматривать, не в технической.
Я подозреваю ваши пользователи подписывали какие то внутренние распорядительные документы, в которых говорится что теперь вместо их ручной подписи используется ЭЦП, ЭЦП будет такая то, храниться будет там то и она является юридически значимой (пусть даже только на уровне предприятия).
Дальше нужно смотреть на сколько то что описано в этих документах соответствует схеме "все закрытые ключи привязаны к одной технической учетке". Я подозреваю ниразу не соответствует т.к. в документах должно быть что то типа "нельзя передавать ключ третьим лицам, нельзя передавать логин/пароль третьим лицам".
А в этой схеме вообще все получается на добром слове будет жить. Пользователь доступа до своего закрытого ключа не имеет, может сказать "я ничего не видел, никаких закрытых ключей у меня нет, как его посмотреть я не знаю, мне никто не объяснял". А если ему объяснить и показать как добраться до его ключа - ему придется давать доступ до технической учетки DSS, в этот момент у него будет доступ до всех ключей.
Ну и да, с т.з. системы такая схема (в DSS все ключи к одной тех учетке) работает только потому что открытый ключ привязан в системе к нужной учетке. Админ (любой с правами администратора в системе) в любой момент может просто скопировать открытый ключ и привязать к своей учетке и без всяких проблем подписать документ сертификатом другого пользователя, т.к. никакой аутентификации в DSS фактически не выполняется (всегда одна учетка со всеми закрытыми ключами всех пользователей), закрытый ключ подбирается исходя из открытого.

Сергей Королев

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

  1. "только внутренние распорядительные документы" - отнюдь, наши сотрудники хорошо понимают и быстро усваивают, чем отличается подписание от простого согласования, насколько важна УКЭП и несут ответственность за свои действия и последствия уже сейчас
  2. "я ничего не видел" не пройдет, т.к. в истории будет зафиксировано кто и когда подписал утверждающей подписью УКЭП. + Для удобства в 4.2 в веб-клиенте появилась фильтрация действий в истории. Настолько детальная история для некоторых сотрудников уже явилась "сюрпризом" в реальных ситуациях и навсегда отбила охоту "отнекиваться"
  3. "может просто скопировать открытый ключ" Предположим он это сделает. Но это действие также останется в истории RX и то, что именно админ подписал документ.

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

Также мое предложение лежит в русле грядущих нововведений в законодательстве об ЭДО - обязательное использование механизма доверенностей при подписании - Доверенности в RX уже есть и без них просто так потом не подпишешь.   

Сергей Королев

Андрей, PS: И не забываем про правильную практику: оператор DSS (закрытых ключей) и администратор DirectumRX - это должны быть разные роли и сотрудники.

Андрей Дозоров

Сергей, Я не имею юридического образования, не являюсь специалистом в области информационной безопасности и никогда не работал рядом с областью сертификации удостоверяющих центров, т.е. я не могу подтвердить или опровергнуть ваши предположения ссылками на регламентирующие документы (законы, постановления и т.д.).
На самом деле в RX сейчас реализован только один способ авторизации в DSS и этот способ авторизации подразумевает что именно пользователь должен авторизоваться в DSS, а в качестве центра идентификации выступает сам Directum RX.
По документации API DSS есть еще другие способы авторизации, возможно какой то из них не требует создания всех пользователей в самом DSS.
Но, в любом случае, взаимодействие с DSS должно происходить не исходя из наших желаний и фантазий, оно должно происходить исходя из требований и рекомендаций самого КриптоПРО DSS и требований законодательства.

З.Ы. Вы бы оформили идею по этому поводу, т.к. не факт что из статьи кто то взял/когда либо возьмет это именно как пожелание.
И мне кажется идею стоит оформлять просто указав списком проблемы, с которыми вы столкнулись. А как уж это делать (какие то тех учетки, более тесная интеграция систем (что бы RX сам создавал пользователей в DSS), другие способы авторизации) разработчики пусть сами разбираются.

Сергей Королев

Андрей, Нас не смущает, что используется авторизация RX. Она достаточно надежная и сертифицированная даже для госорганов.
Идею Директуму подкинул уже до публикации статьи и они взяли ее в анализ.

Юрий Фокин

Замечательная, полезная статья.

Авторизуйтесь, чтобы написать комментарий