Криптография и электронная подпись в решениях на 1С

Управление - Пользователю системы

электронная подпись ЭДО ЭЦП ЭП криптография ДиректБанк

35
Андрей Глебов, докладчик конференции Infostart Event 2017 Community, делает обзор нормативной базы РФ по теме электронной подписи. Рассказывает о возможностях криптографии в платформе «1С:Предприятие 8» и ее расширении через технологию создания внешних компонент. Также он описывает функционал подсистемы «Электронная подпись» в конфигурации «1С:Библиотека стандартных подсистем», приводит примеры использования криптографии в сервисах «1С-ЭДО» и «1С:ДиректБанк», дает рекомендации по разработке собственных решений с криптографией и устранению проблем при запуске электронного документооборота на предприятиях.

Сегодня мы поговорим о том:

  • чем интересна тема криптографии и электронной подписи сегодня;
  • какие сейчас действуют нормативные акты по этой теме;
  • какие возможности криптографии реализованы в платформе 1С;
  • как можно расширить эти возможности с помощью внешних компонент;
  • поговорим про подсистему «Электронная подпись» в БСП;
  • про реализацию сервисов «1С-ЭДО» и «1С:ДиректБанк», разработку которых я курировал;
  • затронем вопрос разработки собственных решений по работе с криптографией на платформе «1С:Предприятие»;
  • рассмотрим типовые проблемы, которые возникают на внедрениях ЭДО на предприятии – расскажу, как их решать.

 

 

Хочу обратить внимание на два термина, которые будут использоваться в мастер-классе.

  • Первый – это ЭДО, электронный документооборот. Под ним мы понимаем и внутренний электронный документооборот на предприятии, и внешний со сторонними контрагентами.
  • Второе сокращение – это ЭП. В интернете встречаются расшифровки: «электронное правительство» и «электропривод». У нас это будет электронная подпись.

 

 

Почему вопросы криптографии и электронной подписи актуальны на текущий момент?

  • Для современного предприятия скорость бизнес-процессов – это одно из конкурентных преимуществ. При применении электронного документооборота затраты времени по статистике уменьшаются на 75%.
  • При переходе на электронный документооборот происходит экономия собственных ресурсов (бумаги, картриджей для принтеров, места для хранения документов, времени сотрудников на организацию бумажного документооборота). Все это сильно помогает предприятию.
  • Почти каждое предприятие сейчас использует дистанционные каналы банковского обслуживания, и безопасность проведения удаленных платежей на текущий момент очень актуальна.
  • Все крупные налогоплательщики сейчас включают в договор тезисы о том, что если Вы хотите с ними работать – обменивайтесь документами в электронном виде. Все переходит в электронку – электронные счета-фактуры, электронные заказы и т. д. Хотите участвовать в торгах – у Вас должна быть электронная подпись.
  • Все это постепенно становится массовым, но, несмотря на это, наше население информировано недостаточно. Это представляет собой серьезное упущение, а потому цель данного обзора – задать Вам курс, который поможет сориентироваться в данных вопросах и разобраться, что можно изучить и где можно посмотреть.

 

Нормативная база, практика применения

 

 

Какие понятия мы рассмотрим?

Электронный документ

Электронный документ – это любая информация, представленная в электронном виде:

  • Вы сфотографировали свой автомобиль – это изображение является электронным документом;
  • отправили заявление начальнику по электронной почте – это тоже электронный документ.

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

Машинная обработка более перспективна, поэтому множество документов можно разделить на формализованные и неформализованные электронные документы.

  • Под неформализованным документом мы понимаем, что человек смотрит на фотографию и видит, что номер автомобиля такой-то.
  • А для формализованных электронных документов обычно разрабатываются схемы, где прописан состав полей, их ограничения, обязательность или необязательность и т.д. Такие формализованные документы можно распознавать автоматически.

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

  • Например, Арбитражный Суд принимает документы только в формате PDF.
  • А электронные счета-фактуры должны передаваться в формате XML, и есть специальная нормативная база с описанием их обязательных полей. Налогоплательщики, которые хотят обмениваться счетами-фактурами в электронном виде, должны четко соблюдать эти требования.

Раньше была проблема, что ФНС обязывала переходить на новый формат электронных документов примерно так же, как на новый формат электронной отчетности – с 1 марта будет новый формат, и дальше «хоть трава не расти». Сейчас, по истечению пары лет, они публикуют формат, ждут обратную связь и затем предупреждают, что на него нужно плавно перейти в течение этого года. При этом параллельно принимаются и старые, и новые форматы. Налоговая служба всегда должна принимать документы в любом формате, потому что документы могут быть пятилетней давности, и в электронном виде они все равно должны приниматься.

Электронная подпись

Закон № 63-ФЗ вводит понятие электронной подписи. Раньше было понятие «электронная цифровая подпись» (ЭЦП), теперь правильнее использовать термин «электронная подпись». По этому закону есть три вида электронной подписи.

  • Первый вид – это простая электронная подпись. Например, при использовании мобильного банка Вам приходит SMS с одноразовым паролем, и Вы делаете подтверждение – это аналог простой электронной подписи. По такой подписи можно определить только автора.
  • Второй и третий виды – это усиленная электронная подпись. «Усиленная» означает, что используется какое-то криптосредство. Усиленная подпись делится на неквалифицированную и квалифицированную.

Усиленную квалифицированную электронную подпись иногда называют просто квалифицированной электронной подписью (КЭП). Это электронная подпись на базе сертификата, который выдается аккредитованным удостоверяющим центром. Минкомсвязь ведет список удостоверяющих центров, которые выдают сертификаты электронной подписи.

Сертификат электронной подписи (он может еще называться сертификат ключа проверки электронной подписи) – это бумажный или электронный документ, однозначно определяющий, кому принадлежит эта подпись.

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

  • Вы не можете сказать, что это не Ваша подпись;
  • Вы не можете от нее отказаться (отозвать);
  • можно проверить, вносились ли изменения в этот документ после того, как Вы его подписали.

Если говорить про применение электронных подписей, то стоит поделить их на локальные и облачные.

  • Локальная электронная подпись – ситуация, когда Вы подписываете какие-то документы на своем компьютере. В этом случае требуется криптосредство, установка сертификата – много сложностей.
  • Облачная электронная подпись –  ситуация, когда Вы доверяете хранилище закрытых ключей некоему держателю в «облаке», и, чтобы подписать документ, его нужно до этого облака донести. Скорее всего, Вам на телефон придет одноразовый пароль, который надо подтвердить. А после подтверждения электронная подпись сформируется на сервере в «облаке», и Вы получите подписанный документ.

ФСБ выпустила разъяснительное письмо, в котором объяснила, что облачная электронная подпись не является квалифицированной. Поэтому, если в законе написано, что документ должен подписываться именно квалифицированной электронной подписью, а у Вас документ подписывается в «облаке», то имейте в виду, что с этим могут быть проблемы – к этому нужно подходить очень внимательно.

Что можно еще рассказать интересного про законодательство, которое будет нас касаться?

  • В 2016 году появился единый удостоверяющий центр Минкомсвязи России, который позволяет построить цепочку доверия до любого сертификата. Этот головной удостоверяющий центр Минкомсвязи, выдает сертификаты аккредитованным удостоверяющим центрам, а они уже выдают физическим и юридическим лицам. Поэтому для любой электронной подписи всегда можно построить цепочку доверия. Это очень удобно, потому что раньше было сложно проверить на практике, что подпись от другого удостоверяющего центра валидна.
  • Совсем из нового – в начале 2017 года Минкомсвязь выступило с законодательной инициативой, чтобы выпуск всех квалифицированных электронных подписей отдать в государственную монополию. На это Центробанк и Минэкономразвития буквально в Июле ответили, что так делать нельзя, потому что это заберет рабочие места и погубит то, что наработано годами. Скорее всего, эта законодательная инициатива дальше не пойдет, но такая мысль была.

 

Особенности применения ЭДО с ЭП в компаниях

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

Если компания запускает электронный документооборот, то:

  • первая задача – это прописать применение электронного документооборота в учетной политике;
  • далее нужно издать приказ на предприятии, где указать, какие лица могут подписывать документы;
  • если Вы обмениваетесь с контрагентом, у Вас должно быть соглашение, в котором прописано, как Вы будете аннулировать и корректировать документы. Например, если Вам не нравится какой-то бумажный документ, то Вы с вашим контрагентом можете договориться и просто порвать его, и все будет хорошо. А в электронном виде все несколько сложнее, потому что количество экземпляров документа, который Вы сгенерировали и подписали, может быть неограниченное. И даже если Вы и Ваш контрагент договорились этот документ аннулировать, то его электронный эквивалент недостаточно просто удалить из вашей базы. Чтобы скорректировать электронный документ или отказаться от него, нужно сформировать на его основании новый электронный документ, а уже в нем указать, каким образом выглядит Ваша сделка теперь. И только после того, как Вы этот новый электронный документ с двух сторон подпишете, информация о сделке зафиксируется в нужном Вам виде.

Все это нужно прописать и использовать.

 

Готовность нормативной базы

Я бы оценил готовность нашей нормативной базы – уже есть какое-то «здание», но его нужно еще достраивать.

  • Например, нет понимания, как мы через пять лет будем проверять электронную подпись в архиве электронных документов. Потому что сертификат живет один год, и когда его срок действия заканчивается, подпись будет невалидна – непонятно, как проверять.
  • Непонятно, что такое «дата подписи». Для некоторых бухгалтерских документов важно знать, в какой именно момент документ был подписан. Сейчас при подписи документа можно «мухлевать» – перевели дату компьютера, подписали, и это будет выглядеть, как будто документ подписан «задним числом». Поэтому, чтобы однозначно сказать, что документ подписывался тогда-то, должен быть один из вариантов:
    • либо должен существовать единый центр раздачи метки времени, чтобы в момент подписания документов мы обращались в какую-то федеральную сервисную службу, которая выдавала бы нам метку времени для подписи;
    • либо, когда Вы обмениваетесь электронными счетами-фактурами, существует еще третье звено – это оператор электронного документооборота. Он пропускает документы через себя и не дает «смухлевать», потому что генерирует свои квитанции (подтверждения), в которых прописываются дата и время.

В общем, есть куда двигаться.

 

Механизм криптографии в платформе «1С:Предприятие 8»

 

Механизм криптографии в платформе появился с версии 8.2 – это достаточно молодой механизм. Сама платформа не содержит криптоалгоритмы, она содержит только вызовы и объекты, с помощью которых можно обращаться к криптосредствам, находящимся на компьютере:

  • для Windows – это интерфейс CryptoAPI;
  • для Linux таких интерфейсов нет, идет непосредственное обращение к модулям криптографии.

Отсюда становится понятно, что криптографию можно применять, только если на компьютере установлено криптосредство. И, с другой стороны, что саму платформу «1С:Предприятие» не требуется сертифицировать с точки зрения криптографии.

 

 

Основные криптографические операции в платформе «1С:Предприятие 8»:

  • Вы знаете, что платформа может работать в разных режимах: толстый, тонкий, веб-клиент, внешнее соединение и мобильное приложение. Во всех этих режимах запуска криптография поддерживается – для мобильного приложения поддержка криптографических механизмов появилась с версии 8.3.10. Я бы рекомендовал читать «Синтаксис-помощник» и смотреть, какие методы доступны в том или ином режиме запуска, потому что там есть ограничения.
  • Платформа позволяет работать с сертификатами открытого ключа (X.509), которые установлены на компьютер. Мы не можем выпустить новый сертификат или запросить его выпуск, мы работаем только с тем, что имеем – с помощью механизмов платформы мы можем найти сертификат на компьютере, прочитать его атрибуты, выгрузить его в файл и проверить, насколько он валидный.
  • Я на своей практике часто сталкивался с непониманием того, как в платформе работает шифрование и расшифровка. Это особенно важно, когда Вы делаете интеграцию с каким-то внешним подрядчиком, который работает не на 1С. Когда Вы зашифровали документ, отправили его на ту сторону, а там пробуют расшифровать. Например, часто возникают вопросы, если при настройке криптопровайдера в 1С был указан алгоритм ГОСТ 28147-89, который является симметричным, а при расшифровке требуется обращение к закрытому ключу. Напомню, что симметричный алгоритм шифрования подразумевает, что для шифрования и расшифровки Вы используете один и тот же ключ. А ассиметричное шифрование – это когда данные шифруются с помощью открытого ключа, а для расшифровки используется другой, закрытый (секретный) ключ. Подрядчики спрашивают: «Но Вы же сказали, что алгоритм шифрования симметричный, почему тогда при расшифровке нужна закрытая часть ключа?» Давайте разберемся, как работает механизм шифрования в платформе:
    • случайным образом создается некий ключ фиксированной длины, с помощью которого набор данных шифруется по симметричному алгоритму;
    • затем сам ключ шифруется асимметричным алгоритмом с помощью публичного ключа сертификата-получателя;
    • шифрование с помощью симметричного алгоритма работает быстрее – мы им большой объем данных зашифровали, а потом маленький ключ фиксированной длины быстро шифруем с помощью асимметричного алгоритма;
    • зашифрованные данные, список сертификатов-получателей и сам зашифрованный ключ упаковываются в один пакет данных по спецификации PKCS#7;
    • этот пакет отправляется на сторону получателя;
    • а расшифровка работает в обратном порядке.
  • Подписание и проверка электронной подписи. При подписании средствами платформы идет обращение к закрытой части ключа и производится встроенная в платформу проверка целостности (математической валидности) подписи. С точки зрения юридической значимости этого недостаточно. Если Вы хотите проверить электронную подпись под документом, Вы должны проверить:
    • действие сертификата;
    • математическую валидность данных, которые Вы прислали.

Именно так сделано в механизме БСП – об этом речь пойдет чуть позже. Платформа этого не делает.

 

Защищенное соединение TLS для организации шифрованного канала обмена данными. Поддерживаются две версии TLS – 1.0/1.2. Версия TLS задается источником, с которым Вы устанавливаете соединение – если в источнике используется протокол 1.2, то и платформа поднимет шифрованное соединение по 1.2. Если используется БСП, то при обращении к ресурсу, в адресе которого прописан «https», шифрование включается автоматически. Если в адресе прописан «http», то трафик не шифруется. Еще из интересного могу сказать, что раньше шифрованное соединение устанавливалась только на RSA-алгоритмах, а сейчас и на ГОСТ-алгоритмах тоже. Браузеры пока что ГОСТ-алгоритмы не поддерживают, а платформа уже умеет. Но не все так хорошо, к сожалению.

Я уже упоминал, что платформа умеет работать только с теми криптосредствами, которые установлены на самом компьютере. Соответственно, есть ограничение – если Вы хотите использовать криптографию, у Вас должно быть какое-то криптосредство. При этом криптосредство нельзя использовать в портативном режиме, оно должно быть обязательно установлено на ОС. Казалось бы, воткнули токен с криптосредством в компьютер, платформа с ним поработала – так не получится.

Электронная подпись генерируется только в формате PKCS#7 (отдельный, внешний файл), по-другому платформа не умеет.

Некоторые ведомства требуют формат подписи XMLDSig – в упрощенном варианте ситуация, когда в XML-файле Вы можете взять некий набор тегов, подписать их и положить подпись в следующий тег, чтобы в одном документе было несколько подписей. Платформа так делать не умеет.

Еще я бы отметил, что с помощью платформы сложно диагностировать возникающие проблемы. Например, на компьютере есть криптосредство, есть сертификат, где-то есть закрытая часть ключа, и если платформа начинает все это вызывать и в какой-то момент что-то не стыкуется, просто выдается ошибка – что произошел сбой, и операция не состоялась. Что там случилось, где проблема – непонятно. Поэтому есть куда двигаться в эту сторону и платформе, и криптосредствам.

 

Криптография во внешних компонентах

 

 

Чтобы снять ограничения платформы, можно попробовать сделать внешнюю компоненту.

  • Для этой цели у фирмы «1С» есть целая методология, она выложена на диске ИТС по адресу https://its.1c.ru/db/metod8dev#content:3221:hdoc. К ней прилагаются примеры, можно использовать.
  • При разработке внешней компоненты Вам придется сделать сборки для всех операционных систем, на которых работают Ваши клиенты. Хорошо, если Вы знаете заранее, что у Вас 100 клиентов, и у всех 32-битный Windows. Если это не так, Вы должны делать сборки:
    • для Linux;
    • для Windows (32-х разрядов и 64-х разрядов);
    • если Ваши клиенты работают через браузер, Вам нужно сделать сборки расширений для каждого браузера в отдельности.

И только после этого Вы можете считать, что у Вас есть готовая функциональность. А если обнаружилась ошибка, Вам нужно не просто исправить внешнюю компоненту, но и пересобрать ее для Windows, Linux и т.д. Это не просто.

  • При эксплуатации бывает еще хуже. Вы работаете с внешней компонентой, как с объектом, свойства которого знаете только Вы. Если при реализации Вы где-то допустили ошибку, программный код по взаимодействию с этим объектом не сможет работать.
  • Есть еще одна проблема – непонятно, как Вы будете доставлять эту внешнюю компоненту до клиента. Платформа у клиента уже стоит, с криптосредствами тоже все понятно, а теперь Вы написали внешнюю компоненту, которая связывает криптосредства и платформу. Но где стоит эта внешняя компонента, как Вы поставили ее клиенту – непонятно.
  • Вы должны поддерживать и актуализировать программный код. Если Вы используете свою внешнюю компоненту в типовом решении, значит, при его обновлении все это нужно учесть. И если выпускается новая версия платформы, Вы должны все перетестировать.
  • Есть готовые примеры внешних компонент. Самый яркий пример на моей практике – это внешняя компонента для «Сбербанка». Точнее, «Сбербанк» выпускает внешнюю компоненту для сервиса «1С:ДиректБанк». В этой внешней компоненте реализован собственный формат электронной подписи и установка зашифрованного соединения.

 

Подсистема БСП «Электронная подпись»

 

 

Теперь о том, как проще работать.

«1С:Библиотека стандартных подсистем» (БСП) – это готовая типовая конфигурация от фирмы «1С», набор универсальных функциональных подсистем, одна из которых называется «Электронная подпись».

Сразу хочу обратить внимание, что сама БСП – это некий изолированный от платформы уровень, у которого есть программный и пользовательский интерфейсы. Подсистема «Электронная подпись» реализует программный и пользовательский интерфейс для работы со средствами криптографии (шифрование, электронная подпись).

 

 

При рассмотрении подсистемы «Электронная подпись» важно понимать, что в ней есть:

  • Базовая функциональность, где реализовано то, что никогда нельзя трогать, если Вы хотите, чтобы все работало.
  • И есть специальная переопределяемая часть для таких разработчиков, как мы, где можно дописать, чтобы что-то работало по-другому. Если там чего-то нет, рекомендую написать ребятам, которые разрабатывают БСП, чтобы они в базовую функциональность заложили возможность переопределения, и тогда Вы в переопределяемой части сможете делать то, что Вам нужно.

Количество объектов в подсистеме не очень большое, справочников всего два:

  • «ПрограммыЭлектроннойПодписиИШифрования»;
  • «СертификатыКлючейЭлектроннойПодписиИШифрования».

Но количество строчек кода в общих модулях очень большое – 11,5 тысяч строчек кода. И сама работа с подсистемой не очень простая.

Как встраивать подсистему «Электронная подпись»?
Предположим, что у Вас есть какая-то конфигурация, Вы решили, что Вам нужно встроить в нее эту подсистему:

  • первым делом нужно прочитать на ИТС, как производится встраивание подсистем;
  • далее – прочитать инструкцию по подсистеме (Глава «Настройка и использование подсистем при разработке конфигурации», подраздел «Электронная подпись») – там написан порядок работы;
  • обязательно нужно ознакомиться в демобазе БСП с примерами вызовов подсистемы «Электронная подпись»;
  • и в конце, после того, как встроили подсистему, нужно сделать проверку:
    • есть расширенная проверка платформы, когда Вы встраиваете объекты;
    • и есть еще отдельная обработка на ИТС «Проверка встраивания подсистем БСП» – с помощью нее можно проверить, как Вы все это встроили.

А если у Вас конфигурация с нуля, то берете подсистему и на ее базе пишете – обновлять будете сами.

Как тестировать электронную подпись?

  • Для тестирования можно использовать самоподписанный сертификат – выпустить его на своем криптосредстве от Microsoft, которое встроено в Windows.
  • Или можно использовать внешние СКЗИ. С помощью «КриптоПро» Вы можете:
    • скачать триал-версию со своего сайта;
    • заказать через тестовый удостоверяющий центр свой тестовый сертификат;
    • установить корневой сертификат тестового удостоверяющего центра;
    • скачать и поставить список отзыва сертификатов (СОС) от этого УЦ.

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

 

Основные функции подсистемы «Электронная подпись» из БСП

 

Это пример демобазы БСП. В разделе «Администрирование» есть две функциональные опции: «Шифрование» и «Электронная подпись». Если Вы их включили, можно переходить в настройки.

 

 

В настройках находятся два справочника: «Программы» и «Сертификаты». В «Программах» система определяет, какие программы установлены, и сразу показывает, что все хорошо или все плохо. Если у Вас используется какое-то специфичное криптосредство, которого нет в БСП, Вы можете нажать кнопку «Добавить» и указать там параметры обращения к нему.

 

Если Вы работаете через веб-клиент, то подсистема БСП подскажет, что сначала нужно установить расширение для работы с файлами и расширение для работы с криптографией. Это очень удобно, потому что не нужно настраивать самим – система найдет расширение и предложит поставить его.

 

 

Сертификаты можно добавить двумя способами.

  • Первый вариант – «Из установленных на компьютере». В таком случае открывается диалоговое окно, где мы указываем, как мы будем этот сертификат использовать.

  • И второй вариант – Вы можете заказать выпуск нового квалифицированного сертификата. Обратите внимание, что платформа сама не позволяет заказывать выпуск сертификата, а БСП позволяет. В БСП сделали интеграцию с удостоверяющим центром 1С, который выпускает сертификаты квалифицированной электронной подписи. Вы можете пройти по мастеру настроек:
    • система подскажет, какие документы нужно заполнить и распечатать для выпуска сертификата;
    • нужно будет заключить договор с партнером, который сможет провести удостоверение личности и передать документы в 1С;
    • после того, как 1С получит документы, будет выпущен сертификат;
    • система найдет его и установит на компьютер.

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

 

 

Дальше происходит магия – проверка сертификата с помощью диагностики корректности настроек. Этот диалог позволяет проверить, насколько корректно настроена криптография на компьютере – система попытается подписать сертификатом, проверить, зашифровать, расшифровать. Также есть возможность вставить сюда какую-то свою дополнительную диагностику.

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

 

 

Как делать вызовы для подписания и шифрования/расшифрования можно посмотреть на примере справочника «Файлы» в демо-базе БСП или в «1С:Управление торговлей», «1С:ERP» – там есть такая же подсистема.

 

Сервисы «1С-ЭДО» и «1С:Директ-Банк»

 

Как используется криптография в сервисах? Первый сервис, «1С-ЭДО» – это сервис, предназначенный для обмена юридически значимыми электронными документами через дружественных операторов компании «1С».

  • Клиентская функциональность разрабатывается в «Библиотеке электронных документов».
  • При попытке соединиться с сервером происходит шифрованное SSL-соединение (по HTTPS) на алгоритмах RSA.
  • Используется авторизация с криптографией. Поскольку сервер про нас ничего не знает, Вам присылают зашифрованный токен, и, если Вы «правильный» человек, то Вы расшифровываете этот токен с помощью закрытого ключа и используете его потом для обмена данных.
  • Есть возможность просмотреть электронный документ, подписать его, проверить, упаковать в пакет данных и отправить.
  • Проверка и вообще вся криптография работает через БСП. Проверка электронной подписи выполняется в два этапа:
    • сначала проверяется валидность самого сертификата: срок действия, цепочка доверия, атрибуты;
    • если с сертификатом все хорошо, то выполняется расчет математического хэша. Если с математикой все хорошо, подпись считается валидной и прикладывается к документу.
  • Также с помощью БСП реализована расширенная диагностика настроек ЭДО – определяется, что сервера доступны, и что с участником электронного документооборота все в порядке – у него активные тарифные планы и т.д.

 

 

Второй сервис – это «1С:ДиректБанк». Его назначение – обмен с банками электронными документами напрямую, минуя программу клиент-банк.

  • Этот сервис тоже поставляется в «Библиотеке электронных документов».
  • Открытая технология DirectBank описана на GitHub.
  • Из нового – шифрованный канал связи с сервисом может быть поднят на алгоритме ГОСТ.
  • Настройка обмена производится так: 1С делает запрос в банк, чтобы получить настройки для конкретного клиента. При необходимости, вместе с настройками банк отправляет внешнюю компоненту, которая используется при дальнейшем обмене (так реализовано у «Сбербанка»).
  • Авторизация производится либо по шифрованному токену, либо по SMS (через однократный пароль).
  • Подписание и проверка электронной подписи работает либо через БСП, либо через внешние компоненты (в зависимости от того, как сам банк это реализовал).
  • И диагностика здесь сделана даже интереснее, через полный цикл обмена электронными документами специального вида – «Запрос-зонд».
    • Система 1С авторизуется в системе банка и передает туда электронный документ со своей подписью;
    • Банк проверяет электронную подпись клиента, формирует извещение, что все хорошо и своей подписью подписывает извещение;
    • Извещение приезжает в «1С», та проверяет, что подпись банка валидна и говорит после этого, что все в порядке.

Вот такой мини-цикл – по нему становится понятно, насколько у Вас с банком корректно настроен обмен.

 

Собственные решения с криптографией на платформе 1С

 

 

Как разрабатывать собственные решения с криптографией?

Вы можете создать конфигурацию с нуля – открыть «Синтаксис-помощник» и использовать возможности платформы для криптографических операций. Но я бы рекомендовал использовать БСП – там уже много чего написано. В этом случае Вам потребуется написать не 11 тысяч строк кода, а поменьше. Но пять тысяч строк кода – точно.

Как тестировать – я уже рассказывал. Можно получить тестовый сертификат и попробовать поработать.

Если Вы разработали конфигурацию с нуля – Вы ее сопровождаете сами. А если Вы использовали при разработке БСП, а она выпустила какую-то новую возможность, то Вы можете обновить подсистему БСП и попробовать эту возможность. Трудности будут в любом случае, потому что «серебряной пули» здесь нет. Я бы подходил к оценке того, стоит или не стоит что-то изобретать, в зависимости от задачи, которую Вы хотите решить. Рассматривая конкретную задачу, уже выбираете: свое решение или стандартное на базе БСП.

Примером собственного решения является разработка партнера «Индустрия ИТ». Они разработали небольшой модуль для внутреннего электронного документооборота на базе «1С:УПП». Там на основе печатной формы формируется электронный документ, который привязывается к документу информационной базы, и есть возможность подписать его электронной подписью. Простой документооборот внутри компании, но сопровождать его все равно надо.

 

Трудности внедрения криптографии и ЭП в организациях

 

 

Какие бывают основные проблемы?

  • Если Вам потребуется установить на один компьютер два криптосредства, произойдет конфликт. Например, если у Вас отчетность работает через VipNet, а электронный документооборот с контрагентами через «КриптоПро». Как решить эту проблему?

Первый вариант – разнести эти криптосредства по разным компьютерам.

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

  • Иногда у клиентов не работает криптография в браузере IE – требуется установить расширение, но оно не ставится. Банальный совет – запустите браузер от имени администратора. Это позволит установить расширение, и проблема будет решена.
  • Программа 1С не всегда видит токены JaCard. Я не знаю в чем проблема, то ли в JaCard, то ли платформе. Переустанавливаешь криптосредство – оно какое-то время работает, а после перезагрузки системы снова слетает. Почему-то 1С и JaCard не очень дружат.
  • Есть еще одна проблема – при проверке сертификатов платформа всегда пытается проверить, насколько этот сертификат надежный, и иногда ей это не удается. Почему это происходит? Есть список отзывов, куда включаются недействительные сертификаты. Например, когда сотрудник уволился из компании, она должна сообщить в удостоверяющий центр, что сотрудник уволился, и его сертификат не действителен. После чего удостоверяющий центр выпускает список отзывов, куда включается этот сертификат, после чего он начинает считаться невалидным. Иногда почему-то проверить сертификат в списке отозванных не удается. В чем проблема? Эти списки отзывов к 1С никакого отношения не имеют, они обновляются автоматически самим криптосредством. Для этого с удостоверяющим центром должен быть настроен стабильный канал. Если список отзывов автоматически не обновляется, это значит, что в удостоверяющем центре недостаточно слажено настроена служба, либо она вообще отсутствует. Смените удостоверяющий центр, и проблема уйдет.
  • Когда сертификатов становится много (например, больше 30-ти), начинаются сложности. Допустим, Вы перевели бизнес на электронные рельсы, и в разгар рабочего дня выясняется, что подпись невалидна, потому что ее сертификат закончился. Выпуск сертификата занимает некоторое время, бизнес «на ушах», Вы тоже. Для таких случаев нужно использовать специализированное ПО для ведения списка сертификатов. Есть программы, которые позволяют контролировать жизненный цикл сертификата, и когда у него срок действия заканчивается, они отправляют администратору напоминалки. Это банальный вариант, но он позволяет более-менее упорядочить сертификаты.

  • Обмен с данными из 1С происходит с серверов, поэтому:
    • открываете порты на серверах 1С:Предприятия;
    • права учетной записи сервера должны быть «Выход в интернет»;
    • если у Вас кластер серверов, значит, у всех 1С-серверов, входящих в кластер, должны быть открыты порты.
  • Если нет доверия к внешнему ресурсу, есть отдельная статья на ИТС «Диагностика проблемы "Удаленный узел не прошел проверку"».
  • Базовые правила безопасности:
    • пароли на стикерах не храним;
    • поработав, вынимаем токены из машин;
    • регулярно обновляем антивирус.
      Иначе получится так, что Вы поставили сертифицированные криптосредства, ключи, а вокруг ходят вирусы, которые могут этим воспользоваться. Поэтому защищайте периметр.

 

Источники информации

Ресурс ИТС

Ресурс «1С:Предприятие 8»

Ресурс сервиса «1С-ЭДО»

Описание DirectBank на GitHub

Конфигурации «1С:Библиотека стандартных подсистем»

Конфигурации «1С:Библиотека электронных документов»

По поводу криптографии можно почитать ИТС, описание технологии DirectBank есть на GitHub, и можно посмотреть, как реализованы конфигурации, упомянутые в мастер-классе.

 

Вопросы

Какие ты порекомендуешь удостоверяющие центры? С каким из них у тебя был положительный опыт?

Я бы порекомендовал использовать тот удостоверяющий центр, с которым Вы будете в дальнейшем работать в части обмена электронными документами. Пример – есть оператор электронного документооборота «Такском», у него есть удостоверяющий центр. Если Вы будете запускать электронный документооборот через «Такском», то имеет смысл и за сертификатом обращаться к ним же.

Ты говорил, что ФСБ давала какое-то разъяснение по поводу облачных сертификатов. Что если сертификат хранить не локально, а в облаке, он не может считаться усиленным. В случае стандартного обмена счетами-фактурами и УПД, мы можем использовать облачный сертификат или там требуется усиленный все-таки?

В законе написано, что при обмене счетами-фактурами требуется усиленная квалифицированная электронная подпись, поэтому "облако" тут не подойдет. А вот для других видов электронных документов - пожалуйста.

Грубо говоря, для любого стандартного ЭДО, которое мы используем в 1С, нам нужен усиленный сертификат?

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

А про УПД там нет ничего? По сути, УПД сейчас это то же самое, что и счет-фактура.

Там есть размытое определение – счет-фактура с расширенными показателями, но это не то же самое, что УПД. Поэтому я думаю, что УПД попадает в разряд неквалифицированной электронной подписи.

А какую функцию во всей этой цепочке выполняет именно оператор – «1С-ЭДО» или «Такском»? Обычно через операторов мы отправляем документы в госорганы и обмениваемся счетами-фактурами, а при обмене другими документами с контрагентами зачем нам нужен оператор?

Операторы на рынке тоже не первый день работают, счета-фактуры ходят через них. Они так и говорят – отправляешь один счет-фактуру, а два другие документа – бесплатно. Вы же все равно счетами-фактурами будете обмениваться через них, поэтому проще и документы сами тоже через них посылать. Другое дело, если Вы сидите на упрощенке, и у Вас нет счетов-фактур, тогда можно попросить оператора поискать для Вас недорогой тарифный план. А так в той же самой «Библиотеке электронных документов» есть возможность обмениваться документами с электронной подписью по электронной почте, через FTP и т.д. Но когда у тебя 100 контрагентов, организовывать для каждого из них свой канал связи будет сложно в плане сопровождения.

А если мы хотим протестить самоподписанный сертификат, через оператора мы можем тестировать какой-то обмен с использованием самоподписанного сертификата?

Нет, через оператора – нет. Если сильно хочется потестировать, напишите в фирму «1С», что Вы хотите подключиться к сервису ЭДО, чтобы протестировать.

Они говорят, что мы не удостоверяющий центр.

Напишите мне, я помогу.

А если мы обмениваемся без оператора ЭДО, мне приносят подписанный электронный документ, и я его хочу загрузить в 1С, чтобы хранить его там. В БСП достаточно средств для проверки, что это КЭП и у него правильные реквизиты, чтобы все это было в автоматическом режиме без модальных окон и т.д.?

Я такие кейсы на своей практике не встречал, но в БСП точно есть возможность загрузить файл и проверить его электронную подпись. Скорее всего, Вам надо будет просто под этот сценарий нарисовать какой-то мастер: проверь папку, забери документ, забери подпись, проверь это все, сложи, куда надо и скажи, что все ок. По поводу синхронности вызова – в БСП все это реализовано, все в браузерах работает в асинхронном режиме.

А если в 1С по терминалу работать? Можно ли поставить «КриптоПро» и в терминале пробросить для него ключи? Какие есть особенности, проблемы? И, соответственно, если у нас более 20 юрлиц и на каждое из них по два ключа, как идет разграничение прав к этим ключам? На уровне 1С или как?

В самом БСП, когда грузишь открытую часть ключа, есть возможность указать, какому пользователю она будет доступна. Там можно, войдя под своим именем, видеть только свои сертификаты. Но при этом они все будут находиться на самом компьютере. Поэтому, сами понимаете, устанавливать закрытую часть в реестр точно не нужно, потому что закрытая часть ключа без проблем переносится с машины на машину. Лучше используйте токены. Есть возможность пробросить токен с закрытой частью ключа до терминального сервера. Ребята-производители ключей сами помогают это настроить так, чтобы в терминале этот ключ был виден. Попробуйте, поэкспериментируйте, найдите другие ключи, найдите людей, которые помогут настроить. Но здесь нужно понимать, что этот туннель от терминального сервера до вашего ключа не безопасен. Ты генеришь электронный документ на терминальном сервере и говоришь – подпиши. Что произойдет? Идет передача данных по незащищенному каналу сначала на локальный компьютер, где установлен ключ, формируется электронная подпись, потом данные передаются обратно на терминальный сервер. Но этот канал не защищен. Его можно защитить только с помощью установки специализированного программного обеспечения, которое делает туннель между терминальным сервером и локальной машиной безопасным. Если хочешь работать безопасно, значит, нужно поставить токен, пробросить его до терминалки и поставить ПО для шифрования канала между терминальным сервером и клиентской машиной.

Скажите, есть ли какая-нибудь разница по скорости работы между подписанием электронного счета-фактуры и отсканированного договора в 100 страниц (где чисто графика).

Чем больше документ, тем он медленнее подписывается, потому что там идет асинхронное шифрование – хэш вычисляется по асинхронному алгоритму. Но с точки зрения того, подписываете ли Вы электронную счет-фактуру в несколько строк или 10Мб файл – визуально разницу Вы не заметите. Заметите только на объемах в 1000-3000 документов.

По поводу роуминга 1С-ЭДО. В «Такском» есть роуминг между операторами. А насколько это работоспособно в «1С-ЭДО»? У Вас есть такой опыт? Потому что все контрагенты сидят на разных операторах и выбрать оператора с максимальным покрытием очень сложно. Кого бы Вы посоветовали?

Если выбирать между «1С-ЭДО» и другими, то конечно, «1С-ЭДО». Но у «1С-ЭДО» есть некоторые проблемы с роумингом – он не так много операторов поддерживает. Есть отдельный ресурс по 1С-ЭДО, там приведен список поддерживаемых операторов, думаю, что он должен со временем пополниться.

А где хранить архив подписанных документов? Локально в компании или в облаке? Можно ли обеспечить валидность сохраняемых в облаке документов?

Где мы храним подписанные документы (в облаке или нет) – неважно. Математически хэш уже вычислен, и содержимое документа бесследно уже не подменить. Вы его потом можете хоть 10 раз куда-нибудь передавать, подпись всегда можно будет проверить чисто математически. Если облачный сервис удобный – пожалуйста, храните в нем, это, наверное, даже интереснее.

А оператор такую услугу предоставляет?

Если с ним отдельный договор заключать для хранения бэкапов – они это делают за отдельные деньги.

А разве подписанные документы у них не хранятся?

Физически они хранятся, но по закону они не обязаны их хранить. Они обязаны хранить только квитанцию. Если к ним налоговая придет и спросит – проходил ли такой-то документ, они покажут, да, вот квитанция, смотрите – подпись такая-то. А что там внутри этого документа – это уже не к ним вопрос.

А для УПП операторы не предоставляют какую-нибудь обработку для ЭДО?

Про операторов не могу сказать, их много, и у каждого есть свои разработки, но в самом УПП электронный документооборот есть.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.

Приглашаем вас на новую конференцию INFOSTART EVENT 2018 Education.

35

См. также

Комментарии
Избранное Подписка Сортировка: Древо
1. a_titeev 6 16.08.18 10:03 Сейчас в теме
Ух. Аж присел. Это по поводу облачной подписи... Как так???
То есть, если я при подключении 1С-Отчетности (https://1cfresh.com/articles/app_rep_connect) во Фреше решил хранить подпись, то это неправильно?
2. chat007 35 16.08.18 20:00 Сейчас в теме
Надо смотреть какую именно отчетность подписываете и требования законодательства к уровню ЭП для этой отчетности. На сколько помню, в 1С-Отчетности, с этим все было хорошо, чего не скажешь про другие сервисы
3. DonAlPatino 42 09.10.18 16:07 Сейчас в теме
"специализированное ПО для ведения списка сертификатов". А можно примеры? Еще бы хорошо чтобы оно на почту предупреждения об окончании сертификата заранее слало....
4. chat007 35 17.10.18 23:30 Сейчас в теме
(3) к сожалению, такого готового ПО не подскажу, чтобы еще и рассылку делало, но в 1С можно легко реализовать, особенно, если ЭДО туда встроено.. ))
6. DonAlPatino 42 18.10.18 17:39 Сейчас в теме
(4) У меня "Контур" внешний... Ну и если я сам писать буду, то это надолго боюсь....
8. chat007 35 18.10.18 21:48 Сейчас в теме
(6) возьмите демо-поставку БСП, там уже есть справочник "Сертификаты" - при выдаче отв.лицу туда вносите запись (программа сама зачитает все данные открытого ключа), за одним будет порядок - понятно, какой сертификат, кому выдан.
Останется прикрутить отправку по smtp письма, можно без визуализации и хранения отправленного (в БСП подсистема работы с почтой тоже есть).
Ну если что найдете готовое, черкните сюда плиз!
Успехов!
5. efsol.d4 18.10.18 16:58 Сейчас в теме
Подскажите, а работает ли 1С под Linux?
К сожалению, на ИТС мануалы только под windows или только о криптопро.
7. chat007 35 18.10.18 21:39 Сейчас в теме
(5) если вопрос "работает ли механизм криптографии в платформе 1С:Предприятие на Linux?", то ответ "Да".
В БСП модуль работал точно. Вероятно придется какое-то время повозиться с настройками, но это придется в любом случае делать. Также важно понимать, где будет располагаться модуль криптографии: на клиенте или на сервере, ну и соответственно, туда ставить Linux нужной версии и битности.
Рекомендую учесть, что сначала надо собрать стенд для экспериментов, полностью выверить состав ПО, аппаратной части, вплоть до конкретного набора токетов и сертификатов, и только потом планировать масштабирование.
9. efsol.d4 19.10.18 15:39 Сейчас в теме
(7) Заказчик просит всенепременно на сервере 1с, 1с сервер на линуксе, и криптопровайдер нужен - VipNet SCP.
Я вот пытаюсь понять, возможна ли эта связка вообще.
10. chat007 35 21.10.18 10:16 Сейчас в теме
(9) Напишите на тех.подержку 1С с нужными вопросами, лучше производителя никто не ответит на этот вопрос + предложите провести пилот с подобной связкой, если получите теоритическое "да". Пилот подразумевает обычно прямое взаимодействие с командой разработки и более оперативное исправление проблем
Оставьте свое сообщение