Встраивание электронной подписи в системы с WEB-интерфейсом с помощью браузерного плагина и openssl / Хабр

Требования и описание архитектуры

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

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

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

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

Что такое docusign

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

Что такое digital signing service (облачный сервис цифровых подписей)?

(DSS) — это масштабируемая платформа с поддержкой API для быстрого развёртывания цифровых подписей, которая обеспечивает:

Теоретически, можно организовать «облачный» сервис внутри собственной компании на своих серверах, открыв для пользователей доступ к API. Например, в рамках европейского проекта CEF Digital разработано open-source решение Digital Signature Service (

Для собственного сервиса DSS требуется наладить не только рабочий процесс подписи и управление пользователями. Требуются ещё сертификаты подписи для удостоверения личности автора каждого документа. Это включает в себя криптографические элементы, такие как управление ключами, система хранения ключей уровня безопасности FIPS level 2 или выше (например, аппаратные токены или HSM)

, служба OCSP или CRL, а также служба меток времени. Объединение этих компонентов, особенно интеграция с аппаратным модулем безопасности (HSM) напрямую, будь то облако или локально, требует значительных усилий со стороны отдела ИТ и отдела информационной безопасности наряду с хорошими знаниями криптографии и наличием необходимых ресурсов.

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

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

Облачный сервис сильно упрощает развёртывание системы документооборота с поддержкой цифровых подписей. Все операции просто проходят через API.

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

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

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

Адаптация системы делопроизводства

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

ПЭП

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

ПЭП

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

ПЭП

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

ПЭП

контрагента, и этот факт должен быть зафиксирован независимыми источниками. Соответственно, усиленная подпись должна быть с возможностью постановки штампов времени (OID 1.2.643.2.2.34.25). Выполнение этих условий призвано обеспечить как доверие между контрагентом и агентом, так и доверие третьих сторон.

Для чего нужна еще одна электронная подпись?

Многие пользователи Интернета уже и так имеют несколько электронных подписей. Называются они, правда, немного иначе, но суть та же. Сама по себе электронная подпись подтверждает личность человека для заключения, например, договора.

Как мы сегодня подтверждаем свою личность в интернет-сервисах? Через электронную почту, отпечаток пальца, распознавание лица, код безопасности – это самые известные способы. После этого мы получаем доступ к почтовому ящику, интернет-банку, облаку документов (зачастую весьма важных) и многим другим сервисам.

Подробнее о том, что такое электронная подпись и как она работает, читайте здесь.

У всех этих способов одна задача – подтверждение личности. Именно поэтому многие уже давно пользуются подобными сервисами. Иначе, если нет интернет-банка, нужно ехать в банк (с паспортом), дождаться очереди к специалисту и попросить сделать выписку со счета. Интернет-банк в этом случае сокращает весь квест до пары кликов в мобильном приложении.

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

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

Как работает сервис

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

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

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

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

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

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

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

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

Какую эцп лучше купить?

В зависимости от вашего статуса (юридическое лицо, физическое лицо, или ИП), а также целей, определяется, какую электронную цифровую подпись лучше заказать. Существует 3 разновидности ЦП:

Конфигурирование openssl

Openssl поддерживает российские криптоалгоритмы, начиная с версии 1.0. Для того, чтобы их использовать, в openssl требуется подгружать engine gost. В большинстве дистрибутивов openssl эта библиотека присутствует. Чтобы engine подгружалась, можно прописать ее в конфигурационном файле openssl:

[openssl_def]
engines = engine_section

[engine_section]
gost  = gost_section

[gost_section]
engine_id  = gost
default_algorithms = ALL

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

Другим вариантом подгрузки engine gost является ее передача в параметрах командной строки утилиты openssl.

Если engine gost не расположена в стандартном месте, то через переменную окружения OPENSSL_ENGINES можно задать путь к директории, в которой openssl будет ее искать.

Для получения информации о том, успешен ли был вызов утилиты openssl или нет, с возможностью уточнения ошибки, требуется парсить stdout и stderror. В конце статьи приведена ссылка на PHP-скрипт, который использует данную утилиту.

Теперь перейдем к реализации законченных пользовательских сценариев.

Поиск подключенных устройств

Любой клиентский сценарий начинается с поиска подключенных к компьютеру USB-устройств Рутокен. В контексте данной статьи акцент делается на устройство Рутокен ЭЦП.

var devices = Array();

try 
{
    devices = plugin.enumerateDevices();
}
catch (error) 
{
    console.log(error);
}

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

Рутокен Плагин определяет все подключенные к компьютеру USВ-устройства Рутокен ЭЦП, Рутокен PINPad, Рутокен WEB. Поэтому следующим шагом следует определить тип устройства.

Полезные ссылки

Данные ссылки могут быть полезны разработчикам инфосистем с поддержкой ЭЦП на базе Рутокен Плагин и openssl:

Демосистема Рутокен ПлагинWEB-сервис генерации ключей, формирования запросов, управления сертификатами, формирования шаблонов запросов на сертификаты Документация на Рутокен ПлагинДокументация по использованию утилиты openssl с российскими крипталгоритмамиПример скрипта на PHP, использующего утилиту openssl

Получение информации об устройстве

Для определения типа устройства следует использовать функцию

с параметром TOKEN_INFO_DEVICE_TYPE. Значение этой константы содержится в объекте плагина.

var type;

try
{  
  type = plugin.getDeviceInfo(deviceId, plugin.TOKEN_INFO_DEVICE_TYPE);
}
catch (error) 
{
    console.log(error);
}

switch (type) 
{
    case plugin.TOKEN_TYPE_UNKNOWN:
        message = "Неизвестное устройство";
        break;
    case plugin.TOKEN_TYPE_RUTOKEN_ECP:
        message = "Рутокен ЭЦП";
        break;
    case plugin.TOKEN_TYPE_RUTOKEN_WEB:
        message = "Рутокен Web";
        break;
    case plugin.TOKEN_TYPE_RUTOKEN_PINPAD_2:
        message = "Рутокен PINPad";
        break;
}

Также с помощью функции getDeviceInfo можно получить:

Получение электронной подписи онлайн

Как оформить электронную подпись онлайн:

1. Вы оставляете заявку.
2. Наш специалист предоставляет консультации.
3. Вы отправляете нам сканы требуемых документов.
4. Мы проводим необходимые действия, чтобы открыть ЭП для вас.
5. Вы оплачиваете наши услуги.

Обратившись в компанию «Редиссон», вы сможете купить электронную подпись онлайн за рекордно короткое время. Максимум 15 минут, и все будет готово!

Пространство доверия

Следующим этапом является решение вопроса о пространстве доверия

ПЭП

. Если источником

ПД

для хранения в системе обработки

ПД

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

ПД

– с оригиналом паспорта. Именно оригиналом, так как получение скан-копий паспортов через сайт – это просто усложненный ввод

ПД

, и он мало чем отличается от просто ввода

ПД

. Удаленно запрашивать скан-копии паспортов особого смысла не имеет и статуса доверия к данным не повышает, но при этом повышает уровень требований к защите

ПД

. И со стороны контрагентов запрос скан-копий паспортов часто провоцирует негативную реакцию, и от такого варианта стоит отказаться. Для сверки может применяться как отдельный личный визит контрагента, также это может быть совмещено с каким-либо этапом оказания услуги, при котором возникает личное взаимодействие с контрагентом. Государственные электронные услуги используют сверку с

ЕСИА

. Планируется также создание

. Таким образом, запись

ПД

в системе обработки персональных данных может иметь два статуса – подтверждена/не подтверждена. Аналогичные статусы используются и на порталах государственных услуг.

Работа с ключевыми парами гост р 34.10-2001

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

var keys = Array();

try
{   
    plugin.login(deviceId, "12345678");
    keys = plugin.enumerateKeys(deviceId, null);
}
catch (error) 
{
    console.log(error);
}

2. Для генерации ключевой пары требуется ввод PIN-кода. При генерации ключа параметры могут быть выбраны из набора:

Пример генерации ключевой пары ГОСТ Р 34.10-2001:

var options = {};
var keyId;

try 
{
    keyId = plugin.generateKeyPair(deviceId, "A",  null, options);
}
catch (error) 
{
    console.log(error);
}

3. С помощью функции deleteKeyPair ключевая пара может быть удалена с токена.

Работа с сертификатами

1. На токене могут храниться 3 категории сертификатов:

Расшифрование данных, полученных с сервера, на клиенте

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

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

Шифрование данных на сервере для клиента:

Сертификат выдается при регистрации в системе

Последовательность вызовов в клиентском скрипте будет следующей:

Далее запрос отправляется на сервер, где на его основе выдается сертификат.Для этого на сервере должен быть установлен и правильно сконфигурирован openssl версии от 1.0 и развернут функционал УЦ.

1. Генерация улюча УЦ:

openssl genpkey -engine gost -algorithm GOST2001 -pkeyopt paramset:A -out ca.key

После этого в файле ca.key будет создан закрытый ключ

2. Создание самоподписанного сертификата УЦ:

openssl req -engine gost -x509 -new -key ca.key -out ca.crt

После ввода необходимой информации об издателе в файле ca.crt будет создан сертификат УЦ.

Сертификат уже имеется на токене, выдан внешним уц

Ключевая пара при этом должна быть создана в формате, совместимом с библиотекой rtPKCS11ECP для Рутокен ЭЦП.

Последовательность вызовов на клиенте:

Подпись получается в base64-формате. При проверке ее на сервере с помощью openssl подпись следует обрамить заголовками, чтобы сделать из нее PEM. Выглядеть подобная подпись будет примерно так:

-----BEGIN CMS-----
MIIDUQYJKoZIhvcNAQcCoIIDQjCCAz4CAQExDDAKBgYqhQMCAgkFADCBygYJKoZI
hvcNAQcBoIG8BIG5PCFQSU5QQURGSUxFIFVURjg PFY 0JLRi9C/0L7Qu9C90LjR
gtGMINCw0YPRgtC10L3RgtC40YTQuNC60LDRhtC40Y4/PCE c2VydmVyLXJhbmRv
bS1kYXRhZTI6ZGE6MmM6MDU6MGI6MzY6MjU6MzQ6YzM6NDk6Nzk6Mzk6YmI6MmY6
YzU6Mzc6ZGI6MzA6MTQ6NDQ6ODM6NjY6Njk6NmI6OWY6YTU6MDk6MzQ6YmY6YzQ6
NzY6YzmgggGeMIIBmjCCAUegAwIBAgIBATAKBgYqhQMCAgMFADBUMQswCQYDVQQG
EwJSVTEPMA0GA1UEBxMGTW9zY293MSIwIAYDVQQKFBlPT08gIkdhcmFudC1QYXJr
LVRlbGVjb20iMRAwDgYDVQQDEwdUZXN0IENBMB4XDTE0MTIyMjE2NTEyNVoXDTE1
MTIyMjE2NTEyNVowEDEOMAwGA1UEAxMFZmZmZmYwYzAcBgYqhQMCAhMwEgYHKoUD
AgIjAQYHKoUDAgIeAQNDAARADKA/O1Zw50PzMpcNkWnW39mAJcTehAhkQ2Vg7bHk
IwIdf7zPe2PxHyAr6lH stqdACK6sFYmkZ58cBjzL0WBwaNEMEIwJQYDVR0lBB4w
HAYIKwYBBQUHAwIGCCsGAQUFBwMEBgYpAQEBAQIwCwYDVR0PBAQDAgKkMAwGA1Ud
EwEB/wQCMAAwCgYGKoUDAgIDBQADQQD5TY55KbwADGKJRK bwCGZw24sdIyayIX5
dn9hrKkNrZsWdetWY3KJFylSulykS/dfJ871IT 8dXPU5A7WqG4 MYG7MIG4AgEB
MFkwVDELMAkGA1UEBhMCUlUxDzANBgNVBAcTBk1vc2NvdzEiMCAGA1UEChQZT09P
ICJHYXJhbnQtUGFyay1UZWxlY29tIjEQMA4GA1UEAxMHVGVzdCBDQQIBATAKBgYq
hQMCAgkFADAKBgYqhQMCAhMFAARAco5PumEfUYVcLMb1cnzETNOuWC8Goda8pdUL
W5ASK tztCwM7wpXgAy Y6/sLtClO9sh8dKnAaEY2Yavg3altQ==
-----END CMS-----

Проверка подписи на сервере:

Система использования закрытого ключа для передачи открытого ключа

Система достаточно подробно разобрана в

. Архитектура строится на основе статьи 12 ФЗ-63, т.е система обязательно должна обеспечивать:

1. Уведомление контрагента о том, что он запускается процедура подписания. В уведомлении пользователю должны быть показаны реквизиты документа, который он подписывает, в идеале документ должен быть открыт для чтения. Контрагент должен ввести закрытый ключ подписи, конфиденциально известный только ему, для подтверждения и факта и момента подписи;
2. Уведомление пользователя о том, что документ подписан. Технически процедура подписания состоит в том, что создается запись в реестре ПЭП и присваивается уникальный номер. Желательно продублировать регистрационный номер подписи, регистрационный номер документа и время подписания с помощью SMS. Тем самым пользователь виртуально получает «второй экземпляр документа» в свое владение;

Система оформления подписи

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

ПЭП

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

ПЭП

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

ПЭП

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

ПЭП

, где каждая

ПЭП

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

ПЭП

– это вторичный открытый ключ

ПЭП

. Реестр, кроме собственно материализации

ПЭП

, должен связывать связью «один-к-одному»

ПД

контрагента, идентификационный номер и дату документа, время подписания и

ПЭП

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

Конвертируют подписанные документы в формат PDF. При визуализации простой электронной подписи в бумажной форме, должны быть визуализированы открытые ключи ПЭП (первичные и вторичные), т.е., исходя из нашего проектирования, должны быть визуализированы ФИО, СНИЛС, номер телефона (если используется), уникальный идентификационный номер ПЭП. Визуализируются они согласно принятым правилам делопроизводства, обычно под содержимым документа, например так:

Подписано простой электронной подписью:
Иванов Иван Иванович, СНИЛС 000-000-000 00, Телефон (000) 000-00-00.
Регистрационный номер подписи: 0000000 от 31.01.2022 10:05:47

Можно также опереться на методические рекомендации межведомственного электронного документооборота (МЭДО) и визуализировать в стандарте PDF/А.

Система формирования сообщения о персональных данных контрагента

Следующим этапом является решение вопроса о том, как

ПД

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

ПД

в ФЗ-152 и ФЗ-63. Выписка статьи 9 из ФЗ-152 гласит:

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

Проблема в том, что, в случае с

ПЭП

, необходимо получить

ПД

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

ПД

, необходимо получить согласие, уже подписанное электронной подписью. Плюс к этому, согласно выписке статьи 9 из ФЗ-63, необходимо соглашение о использовании простой электронной подписи. Получается замкнутый круг, который, с первого взгляда, можно разорвать лишь собственноручной подписью соглашения и согласия с личным визитом. Но, если использовать определенную форму соглашения об использовании

ПЭП

, а именно договор присоединения(публичную оферту), и совместить получение

ПД

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

ПД

контрагента для использования в системах

ПЭП

, если ставится задача обойтись без личных визитов:

1. Необходимо соглашение об использовании простой электронной подписи, разработанное квалифицированными юристами, которое должно приниматься анонимно, без использования подписи. Это дает правовую основу для электронной подписи согласия на предоставление ПД с помощью ПЭП. Закон предоставляет вариант организации анонимного соглашения: договор присоединения, к которому может присоединиться неограниченный круг пользователей (публичная оферта). Это первое, что должен увидеть пользователь при регистрации. Факт присоединения к оферте(акцепт) подтверждается формированием и вводом закрытого ключа. Процесс зависит от того, будет в дальнейшем использоваться многоразовый закрытый ключ (пароль) или одноразовые закрытые ключи.
2. Форма ввода персональных данных, перечисленных выше, а именно ФИО, место жительства, серия и номер паспорта, СНИЛС и т.д., должна включать в себя согласие на предоставление персональных данных. Само согласие должно быть персональным, и, кроме типовых пунктов, перечисленных в статье 9 ФЗ-152, должно содержать пункт о том, что согласие подписывается ПЭП с перечислением открытых ключей: СНИЛС вторичные ключи (если есть). Подписывается вся форма (персональные данные и согласие) одним действием. Подробнее устройство системы подписи будет описано далее в разделе «Система передачи открытого ключа на основе закрытого ключа»
3. После выполнения этих действий пользователь регистрируется в системе и получает возможность подавать заявления, заявки, обращения и жалобы, подписанные ПЭП. Согласие необходимо сохранить, так как оно может быть отозвано.

Определившись с перечнем сохраняемых

ПД

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

ПД

от несанкционированного доступа. Основные шаги, которые необходимо сделать:

1. Выбрать платформу, сертифицированную ФСТЭК для работы с ПД. Платформа, согласно требованиям закона, в минимальном варианте должна обеспечивать разграничение доступа к ПД и логирование всех операций доступа к ПД. В моей практике обычно рассматривались следующие варианты: MS SharePoint 2022/2022, Битрикс, Alfresco, Liferay, и соответственно, в качестве БД – MS SQL Server, PostgreSQL (в составе сертифицированного AltLinux), MySQL. Естественно, возможны и другие варианты. Выбор в пользу того или иного варианта делается на основе сравнительного анализа стоимости владения и на основе ожиданий технического отдела агента – какую платформу им проще будет сопровождать.
2. Разработать политику обработки персональных данных
3. На основе разработанной политики обработки ПД нужно решить, необходимы ли дополнительные сертифицированные средства защиты ПД и регистрация в качестве оператора персональных данных. Есть определенные методики выполнения этого шага и лучше привлечь лицензированных специалистов, особенно если ПД закон обворачивает в слово «тайна», например – врачебная тайна.

В самом простом случае, если

ПД

невозможно использовать ни для каких других целей, кроме как идентификации субъекта

ПД

в целях оказания услуги и

ПД

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

Система хранения ключей

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

ПД

, и необходимо решить, какие

ПД

контрагента будут локально зарегистрированы в системе делопроизводства агента. Ответ на этот вопрос дает выписка статей 20 и 21 ГК РФ – ФИО и место жительства. Для локального пространства доверия этих

ПД

достаточно, но если есть цель юридической значимости

ПЭП

, то необходимы идентификационные коды, присвоенные этим

ПД

в уполномоченной системе регистрации. Уполномоченная система в РФ – это МВД. МВД для ФИО и места жительства присваивает идентификационный код – серия и номер паспорта. Таким образом, чтобы локальная регистрация потенциально стала уполномочено-локальной, необходимо регистрировать ФИО, место жительства, серию и номер паспорта.

Следующим этапом является определение ключей ПЭП – открытого и закрытого ключа. Теоретически, в качестве ключей ПЭП можно использовать любые уникальные наборы кодов, паролей и иных средств, сопоставленные с ПД.

Выписка из ФЗ-63, а именно статья 4, не конкретизирует, что это за ключи. Но так как нужно добиться значимости подписи, здесь мы можем опереться на документы иного рода – судебную практику. Как показывает судебная практика, основной момент, который оспаривается в судах – это то, что выбранный метод подписи не имеет признаков аналога собственноручной подписи (АЛП).

Разные заинтересованные стороны по разному решают этот вопрос. Самый главный признак АЛП — неотчуждаемость от персональных данных В качестве открытого ключа нельзя выдумывать код, этот код должен однозначно указывать на ПД, аналогично монограмме личной подписи и должен быть зарегистрирован в уполномоченном органе, аналогично, как в паспорте зарегистрирована монограмма.

На текущий момент таким кодом является только СНИЛС. Он и используется в качестве открытого ключа ПЭП при предоставлении государственных услуг, более того, он используется в качестве открытого ключа ПЭП в информации электронных сертификатов ЭЦП.

Дискуссионным является вопрос, насколько СНИЛС уполномочен выполнять это роль, так как законодательно он предназначен совсем для другого использования. На законодательном уровне есть предложения ввести новый код, именно для этих целей, но пока де-факто практика сложилась так, что используется СНИЛС, который является неизменным и уникальным, а также зарегистрирован в уполномоченном органе.

Сколько стоит?

Смотрим сразу на цены по программе TeploDigital. Есть два варианта.

• DocuSign Standard Edition – данное предложение позволяет получить бессрочную подписку на версию DocuSign Standard для одного пользователя. В рамках данного предложения организация оплачивает только административный взнос в пользу TeploDigital.
• DocuSign Business Pro Edition – данное предложение позволяет приобрести годовой тарифный план со скидкой 75%. После оплаты административного взноса в пользу TeploDigital вам необходимо оплатить остаток стоимости после применения скидки на сайте DocuSign с помощью банковской карты.

Для сравнения: вот ссылка на коммерческие расценки. Когда есть выбор, это всегда хорошо.

Смена pin-кода

Пример смены PIN-кода на устройстве:

var options = {};

try
{   
    plugin.changePin(deviceId, "12345678", "12345671", options);
}
catch (error) 
{
    console.log(error);
}

Здесь первым параметром выступает старый PIN-код, а вторым новый PIN-код.

Строгая аутентификация на портале

Общая схема аутентификации, используемая в Рутокен Плагин, выглядит следующим образом:

Реализация данной схемы ничем принципиально не отличается от «Регистрация, сертификат уже имеется, выдан внешним УЦ».

Шифрование данных на клиенте для сервера

Для того, чтобы обеспечить конфиденциальность обмена данными между клиентом и сервером в плагине предусмотрено шифрование/расшифрование данных. Данные шифруются в формате CMS. Для того, чтобы зашифровать данные в формате CMS, требуется сертификат открытого ключа «адресата».

При этом расшифровать такое сообщение сможет только владелец закрытого ключа. При шифровании данных для сервера рекомендуется хранить сертификат сервера на Рутокен ЭЦП. Этот сертификат может быть записан на устройство при регистрации пользователя на портале.

Для этого следует использовать функцию importCertificate, при этом в качестве параметра category следует передать CERT_CATEGORY_OTHER. Для использования в функции cmsEncrypt нужно получить тело сертификата по его дескриптору с помощью функции getCertificate.

При этом дескриптор является уникальным и неизменным и может быть сохранен в учетной записи пользователя на сервере при импорте сертификата сервера. Для того, чтобы использовалось аппаратное шифрование по ГОСТ 28147-89, требуется установить опцию useHardwareEncryption в true. В противном случае будет использована быстрая программная реализация ГОСТ 28147-89.

Последовательность вызовов приведена на картинке:

Шифрование данных на клиенте:

try
{
    var recipientCert = plugin.getCertificate(deviceId, certRecId);        
}
catch (error) 
{
    console.log(error);
}

var options = {};
options.useHardwareEncryption = true;
var cms;

try
{
    cms = plugin.cmsEncrypt(deviceId, certSenderId, recipientCert, data, options);
}
catch (error) 
{
    console.log(error);
}

Расшифрование данных на сервере, перед расшифрованием сообщение нужно обрамить PEM-заголовками «——BEGIN PKCS7——» и «——END PKCS7——«:

openssl smime -engine gost -decrypt -in message.cms -inform PEM -recip recipient.crt -inkey recipient.key

recipient.crt — сертификат того, для кого зашифровано сообщение, recipient.key — ключ того, для кого зашифровано сообщение.

Электронная подпись по доступной цене в москве

Вы можете заказать и купить электронную подпись в КА «Редиссон» по приемлемой цене. Для этого нужно:

1. Собрать документы. Для физлиц это паспорт, СНИЛС, ИНН, контактные данные. От ИП требуется то же самое плюс свидетельство о регистрации ИП, информация о прописке. От юрлиц понадобятся такие же данные вместе с документом, подтверждающим полномочия гендиректора компании.
2. Пройти процедуру идентификации.

Мы поможем все сделать быстро за разумные деньги. Уже в течение 5 – 15 минут будет готов ваш цифровой сертификат. С ценами на изготовление или продление электронной подписи можно ознакомиться в прайс-листе.

Электронная цифровая подпись купить — самая выгодная цена на официальном сайте

Заключение

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

ПЭП

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

ПЭП

при оказании услуг физическим лицам через сеть Интернет.