ExtraCrypto API для 1С:Предприятие: что это и как применять

ExtraCrypto API — это программный интерфейс (внешняя компонента или библиотека функций), который расширяет стандартные возможности криптографии в 1С:Предприятии. Подобные решения появляются там, где встроенных механизмов платформы — менеджера криптографии и объектов работы с сертификатами — не хватает: нужна поддержка конкретных алгоритмов, аппаратных ключей, нестандартных форматов подписи или интеграция с внешними сервисами, требующими особого порядка шифрования.

Важно понимать: «ExtraCrypto API» — не единый официальный продукт фирмы «1С», а обобщённое название класса решений. Под таким или похожим именем могут распространяться внешние компоненты по технологии Native API, COM-объекты, HTTP-сервисы подписи или обёртки над криптопровайдерами вроде КриптоПро CSP. Перед внедрением конкретного решения нужно выяснить, кто его разработчик, какие алгоритмы поддерживаются и есть ли сертификация, если подпись должна иметь юридическую силу.

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

Что скрывается за названием ExtraCrypto API

Под термином обычно понимают один из трёх вариантов реализации. Первый — внешняя компонента по технологии Native API, которая подключается к 1С методом ПодключитьВнешнююКомпоненту() и предоставляет объекты для шифрования, хеширования и подписи. Второй — COM-объект или библиотека, работающая только на Windows-клиенте и сервере. Третий — HTTP- или REST-сервис, к которому 1С обращается по сети, а криптографические операции выполняются на отдельном сервере.

Общий признак всех вариантов: они расширяют, а не заменяют штатный менеджер криптографии платформы. Типовые объекты МенеджерКриптографии, СертификатКриптографии и механизм подписания в БСП продолжают работать, а внешний API берёт на себя то, что платформа не умеет: редкие алгоритмы, аппаратные токены, пакетную подпись больших массивов документов или специфические форматы вроде усовершенствованной подписи со штампом времени.

Какие задачи решает внешний криптографический API

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

Третья группа задач — защита данных внутри самой базы: шифрование персональных данных, хеширование паролей нестандартными алгоритмами, формирование контрольных сумм файлов выгрузки. Здесь внешний API удобен тем, что криптография выполняется на стороне сервера 1С без передачи ключей клиенту.

• формирование и проверка электронной подписи документов;
• шифрование и расшифровка файлов и строковых данных;
• вычисление хеш-сумм (ГОСТ, SHA и другие, в зависимости от компоненты);
• работа с аппаратными ключевыми носителями и токенами;
• пакетная обработка больших объёмов документов.

Как подключить компоненту к конфигурации

Порядок подключения зависит от формы поставки, но типовая последовательность для внешней компоненты выглядит так. Файл компоненты помещается в макет конфигурации (тип «Двоичные данные») или распространяется отдельно. В коде выполняется установка и подключение, после чего создаётся объект компоненты и вызываются его методы.

УстановитьВнешнююКомпоненту("ОбщийМакет.ExtraCryptoComponent");
ПодключитьВнешнююКомпоненту("ОбщийМакет.ExtraCryptoComponent", "ExtraCrypto", ТипВнешнейКомпоненты.Native);
Крипто = Новый("AddIn.ExtraCrypto.Crypto");
Хеш = Крипто.Hash("данные для подписи");

Если решение поставляется как HTTP-сервис, подключения не требуется: из 1С формируется HTTP-запрос с данными и идентификатором ключа, а сервис возвращает подпись или зашифрованный блок. Такой вариант проще в развёртывании, но создаёт зависимость от доступности сервиса и требует защиты канала связи.

1. 1
   Получите дистрибутив у разработчика и изучите документацию по методам и лицензированию
2. 2
   Разместите файл компоненты в общем макете конфигурации или на сервере 1С
3. 3
   Добавьте код установки и подключения в общий модуль с обработкой ошибок
4. 4
   Создайте тестовую процедуру: подпишите и проверьте тестовую строку
5. 5
   Проверьте работу на клиенте и на сервере отдельно — место выполнения кода влияет на доступность ключей
6. 6
   Только после успешных тестов встраивайте вызовы в продуктивные процедуры

Выбор между встроенной криптографией 1С и внешним API

Прежде чем внедрять внешнее решение, стоит честно оценить, не закрывает ли задачу штатный функционал. Платформа и БСП умеют подписывать и шифровать через установленные в системе криптопровайдеры, включая ГОСТ-алгоритмы при наличии соответствующего CSP. Внешний API оправдан, когда нужен алгоритм или формат, недоступный через системный криптопровайдер, либо когда криптооперации должны выполняться на сервере без установки лицензий на каждое рабочее место.

Безопасность и типичные риски

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

Второй риск — хранение закрытых ключей. Нельзя размещать неизвлекаемые ключи в базе 1С, передавать их в открытом виде через параметры или записывать в журнал регистрации. Если ключи хранятся на токенах, код должен корректно обрабатывать отсутствие носителя и неверный PIN, не блокируя учётную запись носителя повторными попытками.

Проверка корректности работы до продуктива

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

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

Ограничения и альтернативы

У внешних компонент есть устойчивые ограничения: привязка к платформе и разрядности, необходимость обновления при смене версии 1С, сложности с работой в веб-клиенте, где бинарные компоненты недоступны без отдельной установки расширения для браузера. Если решение работает через внешний HTTP-сервис, добавляется точка отказа и требования к сетевой безопасности.

Альтернативы стоит оценивать в таком порядке: сначала штатные средства платформы и БСП, затем возможности установленного криптопровайдера через его собственный API, затем сертифицированные отраслевые решения для ЭДО, и только потом — сторонние компоненты. Такой порядок минимизирует технический долг и риски поддержки.

FAQ