REST API для электронной подписи: как встроить ЭП в корпоративную систему

Сотрудники готовят документы в 1С, ЭДО и других корпоративных системах, а для подписания переходят в отдельную программу. При небольшом объёме это почти незаметно. Когда операций становится больше, на переключения уходит всё больше рабочего времени.

REST API позволяет запускать подписание из той же рабочей системы. Разберём, когда такой способ нужен, что меняется после внедрения и что важно предусмотреть заранее.

Когда компании нужен REST API для электронной подписи

REST API нужен, когда электронную подпись нужно встроить в регулярную работу с документами: в 1С, ЭДО, на электронных торговых площадках или при взаимодействии с государственными системами.

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

Как меняется работа после интеграции

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

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

корпоративная система → REST API → сервис подписания → результат

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

Где используют подписание через API

Ниже — чем отличаются основные варианты использования API для электронной подписи.

Где используют	Что подписывают	Что важно в этом сценарии
1С	Счета, акты, первичные документы, договоры, отчётность, заявления	Из 1С можно отправить запрос на подписание и получить результат обратно. Если подписание выполняет отдельный сервис, закрытый ключ не передаётся в 1С и не хранится в её файловой системе.
ЭДО	Договоры и другие документы после согласования	После согласования документ можно передать на подпись в рамках того же маршрута. Дальше важно учесть полномочия подписанта, отправку контрагенту и хранение подписанного экземпляра. Если документ от имени компании подписывает сотрудник, ему нужна машиночитаемая доверенность (МЧД) с соответствующими полномочиями.
ЭТП	Заявки, протоколы и сопроводительные документы	При большом количестве заявок важно отслеживать статус каждого документа и отдельно видеть ошибки подписания.

Что важно учесть при интеграции

Совместимость с системами-получателями

У ЭДО, электронной торговой площадки, государственного сервиса или внутренней системы могут быть свои требования к алгоритмам и формату электронной подписи.

До интеграции нужно проверить, поддерживает ли сервис нужные ГОСТ-алгоритмы, сертификаты российских удостоверяющих центров и формат подписи — например, CAdES, CMS или XMLDSig.

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

Как защитить передачу данных и доступ к подписанию

После проверки совместимости нужно определить, как корпоративная система будет обмениваться данными с сервисом подписания. Документы, хэши и результаты подписания должны передаваться через защищённый канал. Также нужно контролировать целостность данных, чтобы их нельзя было незаметно изменить при передаче.

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

Контроль операций

По каждой операции должна сохраняться история. Она понадобится, если подписание завершилось ошибкой или позже возник спор по документу.

В журнале должна сохраняться информация о запросе: дата и время, система-источник, пользователь или сервисная учётная запись, сертификат, результат и данные об ошибке. По этим сведениям можно установить, кто инициировал подписание и чем оно завершилось. При этом в журнал не должны попадать закрытые ключи и PIN-коды, а доступ к нему нужно ограничить.

Закон рассматривает ключ электронной подписи как персональный инструмент владельца. Не как флешку, которую можно передать по офису.

Методы API, способы авторизации и другие параметры интеграции описаны в технической документации Ключника API: docs.kgost.ru.

Что может пойти не так после интеграции

Ниже — типовые ошибки интеграции и их последствия.

Что произошло	К чему это приводит
Истёк срок действия сертификата	Этим сертификатом больше нельзя подписывать документы.
Не проверили результат подписания	Успешный HTTP-ответ ещё не подтверждает, что подпись относится к нужному документу. Ошибка может возникнуть, если выбран не тот файл, неверно рассчитан хэш или данные изменились при преобразовании кодировки.
По журналу нельзя определить инициатора	При споре нельзя сразу установить, какая система или сотрудник запустили подписание.
Система не получила ответ и повторила запрос	Может появиться вторая подпись или дубликат связанной операции.

Как разграничить права при API-доступе

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

Например, бухгалтерской системе можно разрешить подписывать только счета и акты определёнными сертификатами. Для интеграции с ЭДО доступ можно отдельно ограничить по юридическому лицу, сертификату и типу документа. Права можно разграничивать по системе-источнику, юридическому лицу, подразделению, роли, сертификату, типу документа и операции.

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

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

Получить консультацию по модели доступа

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

Оставить заявку

Ключник API и КриптоПро DSS: чем отличаются

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

Поэтому сравнивать решения только по наличию REST API недостаточно. При выборе нужно учитывать, какая инфраструктура уже есть у компании, где должны храниться ключи и сколько систем и пользователей будут работать с подписью:

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

Ключник API КС3 поставляется как аппаратная платформа с предустановленным и настроенным комплексом сертифицированного ПО. Информационные системы обращаются к устройству через REST API. Производитель указывает, что ключи не покидают устройство, а доступ к ним можно разграничивать между подключёнными системами.

На сайте Ключника API указаны цены: от 37 тыс. ₽ для Ключника API и 3,6 млн ₽ для КриптоПро DSS. Итоговая стоимость КриптоПро DSS зависит от конфигурации и набора лицензий. Подробнее — на сайте КриптоПро.

Подписание без лишних действий

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

При большом объёме документов меньше времени уходит на ручные действия, а статусы и ошибки подписания проще контролировать.

FAQ (юридические и технические вопросы)

Через REST API корпоративная система отправляет документ на подписание и получает результат обратно. Пользователю не нужно устанавливать криптографический плагин на каждое рабочее место.
При локальном подписании операция выполняется на компьютере сотрудника, а ключ хранится на токене или в локальном хранилище. Такой вариант подходит для ручного подписания. Если документов много, централизованно контролировать операции сложнее.

Ростов-на-Дону, пер. Газетный 121/262А, офис 601

Продукты РНДСОФТ

Политика конфиденциальности

Отдел продаж:
+7 (499) 110-99-73

Общие вопросы:
+7 (863) 333-23-49