Статья написана в соавторстве с инженером-Linux-администратором - Иваном Синелобовым.
1.Введение
Cуть проблемы: по свежему закону 443-ФЗ, КЭП для подписания электронных документов оформляется только на директора, который представляет интересы компании без доверенности.
Ключ некопируемый, с него невозможно сделать дубликат для главбуха, юриста или специалиста по тендерам. Невозможно его также извлечь и использовать в каких-либо автоматизированных системах. Например, такой КЭП нельзя использовать для автоматической подписи сообщений передаваемых национальному оператору цифровой маркировки товаров "Честный знак". Такие меры предприняты государством для обеспечения безопасности бизнеса.
В очень хорошей статье на популярном ресурсе для бухгалтеров klerk.ru есть статья [1] о том как данная проблема решается переходом на сертификаты физического лица (УКЭП) и машиночитаемые доверенности (МЧД).
Но дедлайн, а он 31 августа 2024 года, уже скоро, а как выяснилось не для всех участников рынка применима схема с УКЭП физического лица с МЧД, который будет использоваться в автоматизированных системах подписи и обмена по API.
Что же делать? Одним из возможных выходов - это получение квалифицированного сертификата ключа проверки электронной подписи (КСКПЭП) Оператора информационной системы (обезличенного сертификата ФНС) по файлу запроса в формате PKCS#10.
2.Юридические основания.
Юридические основания, которые позволят ИТ-шникам и юристам компании разговаривать на одном языке.
2.1.Федеральный закон "Об электронной подписи" от 06.04.2011 N 63-ФЗ [2]
2.2.Об утверждении Порядка реализации Федеральной налоговой службой функций аккредитованного удостоверяющего центра и исполнения его обязанностей [3]
2.3.Выдача квалифицированных сертификатов Операторам информационных систем (обезличенных сертификатов) [4]
2.4.Доверенные лица УЦ ФНС России [5]
2.5.«Обезличенная» электронная подпись: как её получить и где использовать [6]
2.6. Назначение ответственного за «обезличенную» подпись [7]
2.7.УЦ «Основание» [8]
2.8.УЦ «НТССофт» [9]
3.Список необходимых документов для подачи в УЦ.
Образцы Письма и Приказа можно загрузить по приложенным ссылкам с github [10, 11].
Согласно информации от ФНС России [12]:
Удостоверяющий центр ФНС России выдает обезличенные сертификаты, применяемые исключительно для автоматического создания (проверки) электронной подписи в электронном документе.
Для получения «обезличенного» сертификата необходимо являться лицом, действующим от имени юридического лица без доверенности, или индивидуальным предпринимателем и представить в место выдачи Удостоверяющего центра ФНС России:
Письмо на официальном бланке с приложением копии распорядительного документа о создании информационной системы, либо иного документа, на основании которого данное юридическое лицо или индивидуальный предприниматель осуществляет функции оператора информационной системы.
Основной документ, удостоверяющий личность заявителя (паспорт).
Сведения о страховом номере индивидуального лицевого счета.
Сведения об идентификационном номере налогоплательщика – юридического лица и (или) физического лица.
Перейдём к IT-активностям.
4.Подготовка рабочего места.
Пока решаются организационные вопросы можно приступить к подготовке рабочего места и проверки работы с тестовым ОУКЭП.
Для этого необходимо:
4.1. Подготовить Rutoken
Для тестовых целей необходимо выбирать такой же, какой будет использован и в продуктивной среде. Например, Рутокен Lite 1010 (на фото):
4.3.Скачать и установить сертифицированную версию КриптоПро CSP 5 R3 [13]
Перед загрузкой нужно быть авторизованным на сайте cryptorpo.ru
4.4.Скачать программу КриптоПро cryptcp [14]
4.5.В каталог c программой cryptcp.x64.exe сохранить файлы с github PersonalPresence.ext и
RemoteCertificate.ext [15, 16]
4.6.Выполнить в cli команду (представляющую одну строку), файл-шаблон загрузить можно также с github [17]
cryptcp.x64.exe -createrqst MY-REQ.req -rdn "CN=""ООО """"MY-COMPANY"""""", E=MY-EMAIL, C=RU, S=""77 г. Москва"", L=""MY-CITY"", STREET=""MY-STREET"", O=""ООО """"MY-COMPANY"""""", 1.2.643.100.4=MY-INN-10char, 1.2.643.100.1=MY-OGRN-13char" -pin MY-CONTAINER-PASSWORD -provtype 80 -provname "Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider" -certusage 1.3.6.1.5.5.7.3.2 -ext MY_IDENTIFICATION-KIND.ext
ИНН (MY-INN-10char), ОГРН(MY-OGRN-13char), Название компании (MY-COMPANY) и т.д берутся из ЕГРЮЛ даже для тестов [18]
также обратите внимание на:
MY_IDENTIFICATION-KIND.ext, RemoteCertificate.ext - получение без визита в ФНС, наш вариант для тестов.
Генерация запроса:
CriptoPro CSP предложит устройство на выбор для сохранения контейнера. В качестве такого устройства можно выбирать уже упоминавшийся тестовый Rutoken Lite 1010 , который должен быть к этому моменту вставлен в USB-порт компьютера, на котором происходит генерация сертификата.
Генерация:
Результаты:
5.Выбор тестового удостоверяющий центра (УЦ)
Выбор тестового УЦ определяется целью тестирования.
Так, например, для обмена с "Честный знак. МДЛП" тестовый сертификат выданный в Крипто-Про использовать не получиться. Ошибка:
и наоборот, попытка загрузить тестовый сертификат, работающий в МДЛП в "Честный знак. ГИС-МТ" заканчивается ошибкой:
5.1. Тестовый УЦ Крипто-Про [19]
5.2. Тестовый УЦ Инфотекс [20]
5.3. Тестовый УЦ TrueMark [21]
6.Генерация тестового сертификата
Генерация сертификата в тестовом УЦ из файла PKCS#10 на примере УЦ Инфотекс
Сервер сгенерировал сертификат по файлу запроса:
7."Проброс" токена на сервер автоматической подписи.
В современном ландшафте, когда системы виртуализации получили широкое распространение, таким виртуализированным сервером скорее всего будет и машина работающая с электронными подписями.
Для того, чтобы "пробросить" USB-токен с ОУКЭП в виртуализованном окружении можно использовать программно-аппаратный комплекс позволяющий организовать удаленный доступ к USB устройствам через локальную сеть или Internet. Например, Digi AnywhereUSB или аналог российского производителя NIO-EUSB [22] (на фото):
Давайте рассмотрим последнюю чуть более подробно.
Предположим, что в нашем случае хостом для клиента обмена по API будет выступать Linux-машина.
7.1. С сайта производителя [23] скачиваем подходящий для Вашей ОС клиент
7.2. Клиент может быть запущен через cli или в виде службы (более предпочтительный способ)
В случае запуска клиента в виде службы конфигурационный файл /etc/rhcl имеет следующую структуру:
Где ManualHubs - <адрес:порт USB-хаба в Вашей сети>
Параметры для секции [AutoShare] можно получить командой ./ruclientx86_64 -t "LIST"
7.3. В итоге у нас должно получиться:
Вывод команды lsusb:
Вывод команды ./ruclientx86_64 -t "LIST":
Где niousb: XXX <XXX - номер порта USB-hub-а>
Rutoken lite (niousb.XXX) <XXX - номер USB в который вставлен Рутокен>
8.Регистрация ОУКЭП в автоматизированных системах
Регистрация ОУКЭП в автоматизированных системах имеет свои особенности.
Разберём их на примерах систем "Честного знака":
Государственная информационная система мониторинга оборота товаров (ГИС МТ) [24].
Мониторинг Движения Лекарственных Препаратов (МДЛП) [25].
8.1. Регистрация ОУКЭП на примере ГИС-МТ
Общий вид интерфейса (скриншот):
В меню выбираем:
Профиль - Пользователи - Сотрудники - Добавление пользователя - Загрузить сертификат - Выбираем открытую часть сертификата, который мы сделали в разделе 6 (скриншот):
8.2. Регистрация ОУКЭП на примере МДЛП:
В Личном Кабинете МДЛП выбираем: Администрирование - Учётные системы - Добавить учётную систему (скриншот):
Переходим в созданную учётную систему:
Добавляем открытую часть сертификата, который мы сделали в разделе 6 (скриншот):
9.Заключение.
В данной статье представлены варианта решения на случай, когда использование УКЭП с МЧД в компании оказывается не применимым. Приведены примеры генерации ОУКЭП и его записи на носитель (Рутокен), а также использования Рутокен в средах с виртуализованным окружением, а также его регистрации в таких системах как ГИС-МТ и МДЛП.
