Системные требования к программно-аппаратным средствам:
- Установка СКЗИ КриптоПро CSP версии 5.0.
- Операционная система Windows 7/8.1/10/Server 2008 (x86, x64).
- Серверные ОС Windows Server 2008 R2/2012/2012 R2/2016/2019 (x64).
- Mac OS X 10.9/10.10/10.11/10.12/10.13/10.14 (x64).
Для установки приложения MyDss на смартфоне, он должен работать под управлением операционных систем:
- Android 7.0 и выше.
- iOS 8/9/10/11.
- Назначение
- Что такое квалифицированная ОЭП?
- Как установить ОЭП и начать работать?
- Настройки КриптоПро DSS
- Настройки на стороне DSS
- Настройки в системе
- Настройки в профиле пользователя
- Поддерживаемые форматы электронной подписи
- Требования к окружению
- Безопасность
- Способы аутентификации
- Высокая отказоустойчивость и доступность
- Мониторинг функционирования и доступности
- Предыстория
- Опыт настройки
- Идеи развитии сервиса облачной подписи
- Введение
- Описание проблемы и её решение
- Docker
- Вместо заключения
- Список ресурсов
- Установка СКЗИ КриптоПро CSP 5 #
- Настройка КриптоПро CSP 5. 0 #
- Замена адреса DSS сервера #
- Аутентификация в приложении myDSS #
- Заказать облачную подпись #
- Преимущества решений КриптоПро
- Ответы на самые распространенные вопросы
- Установка и настройка на смартфоне приложения MyDss #
- Установка на смартфоне приложения MyDSS #
- Настройка приложения MyDSS #
- Как работает ОЭП?
- Главные функции
- Защита информации
- Создание ключей шифрования
- Формирование ПИН-кода
- Защита информации от случайных или преднамеренных потерь
- Защита от вредоносного кода и целенаправленного взлома
- Как стали использовать облачные электронные подписи (ОЭП)?
- Преимущества
Назначение
Создание, шифрование и проверка ЭЦП
Защита документа от несанкционированных изменений, закладок, модификаций ПО и вирусов
Конфиденциальность данных при помощи криптографической защиты
Гарантия подлинности, целостности и авторства подписанного документа
Создание, шифрование и проверка ЭЦП
Защита документа от несанкционированных изменений, закладок, модификаций ПО и вирусов
Конфиденциальность данных при помощи криптографической защиты
Гарантия подлинности, целостности и авторства подписанного документа
На чтение 12 мин Просмотров 17.9к. Опубликовано 01.02.2021 Обновлено 01.02.2021
Появление электронных подписей позволило оптимизировать многие бизнес-процессы и работу компаний. Информация о пользователе, записанная на USB-носитель сделала электронный документооборот быстрым и удобным.
Ею пользуются не только ИП и ООО, но и физлица, например, для входа на «Госуслуги» или сайт ИФНС, чтобы получить услугу государственных учреждений.
На смену ставшей привычной ЭП, пришла облачная электронная подпись (ОЭП), которая не требует записи ключа и сертификата на носитель (рутокен), и нет привязки к рабочему месту. Не все еще знают, что это такое, как ей пользоваться, и какие преимущества она дает.
Ввиду того, что нашими читателями, в основном, являются участники и организаторы торгов, рассмотрим этот вопрос с точки зрения участия в тендерах, и какие в этом плюсы. Дадим инструкцию по установке необходимых программ и приложений для компьютера и телефона, чтобы можно было подписывать документы облачной ЭП.
Содержание
- Как стали использовать облачные электронные подписи (ОЭП)?
- Что такое квалифицированная ОЭП?
- Как работает ОЭП?
- Ответы на самые распространенные вопросы
- Как установить ОЭП и начать работать?
- Преимущества
Что такое квалифицированная ОЭП?
На сайте компании «КриптоПро», которая занимается разработкой и внедрением программ и приложений для работы с ЭП дается формулировка ОЭП, которая, по нашему мнению, наиболее соответствует действительности:
«Электронная подпись в облаке (облачная электронная подпись) – это вычислительная система, предоставляющая через сеть доступ к возможностям создания, проверки ЭП и интеграции этих функций в бизнес-процессы других систем».
Эта формулировка не исключает возможности для ОЭП использовать и локальное средство ЭП. Например, используя КриптоПро DSS Lite, пользователь через веб-браузер может подписывать электронный документ с помощью средства ЭП, установленного на его компьютер или планшет. В этом случае ключ подписи остается у пользователя, и защищенность сведений обеспечивается за счет стандартных методов, которые объединены в привычную нам ЭП. Или, проще говоря, это облачная ЭП с локальным средством ЭП.
Другой вариант облачной ЭП получается при использовании средства ЭП, хранящегося на облаке. Чтобы не путать это понятие с первым, назовем такую цепочку «полностью облачной ЭП». В среде специалистов до сих пор не утихают споры по поводу ее безопасности, так как информация передается на облако. Известно, что ЭП должна принадлежать одному собственнику. Записанную на носитель подпись владелец может хранить, например, в сейфе, чтобы ограничить доступ к ней третьих лиц. А как обеспечивается безопасность на облаке? Могут ли его взломать мошенники? Как сами разработчики гарантируют конфиденциальность информации, размещенной на облаке, и имеют ли сами доступ к ней?
Вопросами защищенности облака занимаются «безопасники» и консультирующие их юристы. Сведения должны не просто попасть на облако, но и быть обработаны и сохранены. С локальным средством все понятно: ЭП находится в защищенном пространстве пользователя. Но для облачной ЭП такое пространство отсутствует. При этом ответственность за обеспечение конфиденциальности данных в каком-то смысле «размывается» между её собственником и поставщиком облачных услуг.
Некоторые пользователи не доверяют надежности облака, так как не до конца понимают механизмы его действия. На облако передается ключ ЭП, а это информация, которая конфиденциальна и принадлежит конкретному человеку – собственнику. Защищенность ключа зависит от уровня безопасности средств, которые используются при аутентификации, и от ответственности владельца.
Разработчики КриптоПРО внедрили программу КриптоПро DSS, которая в тестовом режиме испытывалась экспертами. В этот сервер передаются ключи и сертификаты пользователей, а чтобы получить к ним доступ, необходимо пройти аутентификацию, которая возможна только для одного лица – владельца.
Как установить ОЭП и начать работать?
Для работы на локальном компьютере потребуется:
- Скачать СКЗИ КриптоПро CSP версии 5.0.
- ОС Windows 7/8.1/10/Server 2008 (x86, x64).
- Серверные ОС Windows Server 2008 R2/2012/2012 R2/2016/2019 (x64).
- Mac OS X 10.9/10.10/10.11/10.12/10.13/10.14 (x64).
Чтобы пользоваться ОЭП на мобильном устройстве, оно должно работать на базе операционных систем не ниже Android 7.0 или iOS 8/9/10/11. Кроме этого, нужно установить приложение MyDss
Установка и настройка на смартфоне приложения MyDss
- Зайдите в приложение Play Market или Apple Store (зависит от устройства, которое Вы используете).
- В поисковую строку вбейте «MyDss» и запустите установку приложения.
- После завершения скачивания нажмите кнопку «Открыть».
4. Для начала работы система уведомит вас о необходимости сканирования QR-кода. Предоставьте камере доступ к этому действию.
5. Считайте QR-код с сертификата, который получили в УЦ.
6. Придумайте имя для сохраняемого ключа, например, «ОЭП для торгов».
7. Выберите способ авторизации (с паролем, без пароля, отпечаток пальца, Face ID).
8. Программа готова к использованию.
Установка СКЗИ КриптоПро CSP 5
Чтобы пользоваться облачной ЭП потребуется наличие операционной системы Windows 7, 8, 8.1 или 10. Проверьте, что Ваша ОС подходит для работы с ОЭП. Для этого откройте «Центр обновлений Windows» и запустите поиск и обновления компонентов Windows.
Для работы с облачной подписью обязательно нужно скачать и настроить программу КриптоПро CSP 5.0.
- Установите актуальную версию программы КриптоПро CSP 5.0 с официального сайта создателя приложения.
- Откройте скачанный пакет CSPSetup-5.0.exe и нажмите клавишу «Установить».
- Скачайте корневой сертификат Минкомсвязи РФ и сохраните его в «Доверенные корневые центры сертификации».
- Установить корневой сертификат вашего УЦ в «Промежуточные центры сертификации».
Настройка КриптоПро CSP 5.0
- Нажмите «Пуск» в ОС Windows и найдите папку «Крипто-Про».
- Выберите пункт «Инструменты Крипто-Про».
3. Перейдите в раздел «Облачный провайдер».
Замена адреса DSS-системы
- Поменяйте адрес в строке «Сервер авторизации» на адрес Вашей системы DSS (его можно узнать в своем УЦ).
- В строке «Сервер DSS» также измените адрес на информацию, полученную в УЦ.
- Нажмите «Установить сертификаты».
4. Вбейте логин и нажмите «Далее».
5. При первом запуске программы система предложит придумать новый пароль для доступа в личный кабинет. Для этого укажите старый пароль, а ниже – новый пароль, затем подтвердите его. При повторном запуске изменять пароль не нужно.
Аутентификация в приложении myDSS
Следующим шагом потребуется выполнить аутентификацию. Действие выполняется в приложении MyDss c мобильного устройства.
- Откройте приложение MyDss на смартфоне.
- Подтвердите действие по запросу системы.
- Если нет возможности подключиться к интернету, то нажмите строку «Используйте офлайн-подтверждение».
- Отсканируйте QR-код и укажите его на компьютере.
Если Вы выполнили все действия правильно, то система уведомит об успешности процедуры. На экране появится надпись «Установка сертификатов завершилась успехом».
Специалисты АО «НППКТ» и ООО «КРИПТО-ПРО» провели совместное тестирование ОСОН «ОСнова» и СКЗИ «КриптоПро CSP 5.0».
В ходе тестирования специалисты подтвердили полную совместимость ОСОН «ОСнова» в исполнении для архитектур x86-64 и СКЗИ КриптоПро CSP 5.0.12417.
ОСОН “ОСнова” – отечественная защищенная операционная система, предназначенная для построения защищённых автоматизированных систем, обрабатывающих конфиденциальную информацию и персональные данные. Включена в “Единый реестр российских программ для электронных вычислительных машин и баз данных”. Имеет сертификат соответствия ФСТЭК России по 4 уровню доверия.
КриптоПро CSP 5.0 — новое поколение криптопровайдера, развивающее три основные продуктовые линейки компании КриптоПро: КриптоПро CSP (классические токены и другие пассивные хранилища секретных ключей), КриптоПро ФКН CSP/Рутокен CSP (неизвлекаемыe ключи на токенах с защищенным обменом сообщениями) и КриптоПро DSS (ключи в облаке).
Интеграция СКЗИ КриптоПро CSP 5.0 в ОСОН «ОСнова» обеспечивает наивысший уровень безопасности информации для компаний и конечных пользователей.
«Полученное нами подтверждение совместимости средств и продуктов лидера рынка, компании КриптоПро CSP с операционной системой ОСнова – важный шаг для развития экосистем на базе операционной системы ОСнова. Наши партнеры и заказчики в полной мере могут быть уверены в стабильности работы продуктов компании КриптоПро, подтверждением чего является успешное прохождение тестирования» – комментирует коммерческий директор АО «НППКТ» Игорь Семенович Морозов.
«В условиях активного импортозамещения стратегически важным является обеспечение совместимости широко используемых государственными и коммерческими организациями продуктов КриптоПро с прикладным и системным программным обеспечением, особенно с операционными системами, используемыми для построения защищенных автоматизированных систем. И успешно проведенное совместное тестирование КриптоПро CSP с ОС ОСнова – действительно большой шаг в этом направлении» – дополняет директор по развитию бизнеса и работе с партнерами ООО «КРИПТО-ПРО» Павел Луцик.
В наши компетенции входит: импортозамещение в сфере информационных технологий (ИТ), создание доверенной защищённой среды, автоматизированных систем в защищённом исполнении (АИС), разработка операционных систем (ОС), систем управления базами данных (СУБД), программного обеспечения (ПО), защищённых веб-порталов, средств защиты информации (СЗИ), программно-аппаратных комплексов (ПАК, АПК, ПТК), внедрение доверенной системы виртуализации и интеллектуальной системы управления телекоммуникационным оборудованием (SDN) в России и странах СНГ.
КОНТАКТНАЯ ИНФОРМАЦИЯ
Адрес: 127474, Россия, г. Москва, Дмитровское шоссе, д. 60А. БЦ “Лихоборский”
Телефон: +7-499-280-09-70, email: mailnppct.ru
При использовании материалов сайта гиперссылка на сайт обязательна.
© АО “НППКТ”, 2017—2022
Настройки КриптоПро DSS
Криптопровайдер КриптоПро DSS позволяет подписывать документы в ELMA4 без установки на рабочие места пользователей ПО КриптоПро CSP, плагинов и сертификатов. Подписание возможно в любом поддерживаемом ELMA4 браузере (Google Chrome или Mozilla Firefox).
Чтобы подписывать документы в ELMA4 с помощью КриптоПро DSS, требуется ПО КриптоПро DSS одного из двух форматов:
- КриптоПро DSS 2.0 версии 2.0.3210 или выше. Описание продукта: www.cryptopro.ru/products/dss. Это ПО устанавливается на собственный сервер компании.
- Сервис электронной подписи ООО «КРИПТО-ПРО» на базе ПАК «КриптоПро DSS» (далее — облачный DSS).
Описание продукта: www.cryptopro.ru/service/sign#rules_of_uses.
Сайт продукта: dss.cryptopro.ru.
Функциональные возможности облачного DSS абсолютно аналогичны тем, что вы можете получить при внедрении ПАК «КриптоПро DSS» на своей площадке, но при этом вашей организации не придётся самостоятельно устанавливать ПО и поддерживать его работу, так как вы получаете доступ к облачному сервису, развёрнутому на сервере компании КриптоПро.
Настройки на стороне DSS
Выполните следующие действия:
Если у вас нет прав администратора, эти настройки облачного DSS выполняет служба технической поддержки облачного DSS.
Чтобы зарегистрировать клиент, в режиме командлета администрирования нужно выполнить следующие команды.
Add-DssClient -Identifier clientName -Name clientName -AllowedFlow ResourceOwner, RefreshToken -GenerateSecret -SuppressAuthForIssue 1
Вместо clientName нужно задать свой идентификатор OAuth-клиента.
- — идентификатор OAuth-клиента, заданный при выполнении предыдущей команды ;
- — пароль OAuth-клиента: указать свой пароль.
Для облачного DSS нужно направить запрос в службу технической поддержки облачного DSS на выполнение команд создания OAuth-клиента.
Настройки в системе
О них читайте в статье «Настройки ЭП в системе».
Настройки в профиле пользователя
Настроить подписание в профиле пользователя может администратор системы или сам пользователь.
Выполните следующие действия:
- Вверху страницы профиля наведите курсор на кнопку панели инструментов и выберите Подписание — Выбор криптопровайдера для подписания.
- В появившемся окне укажите данные и нажмите .
В первом поле выберите криптопровайдер КриптоПро DSS.
Во втором поле вы можете выбрать тип подписи. Подробнее о типах читайте в статье «Настройки ЭП в системе».
- После этого привяжите сертификат для подписания. Для этого вверху страницы профиля наведите курсор на кнопку панели инструментов и выберите Подписание — Привязать сертификат для подписания. В появившемся окне выберите сертификат пользователя DSS, логин которого вы указали в окне выбора криптопровайдера, введите PIN-код сертификата и нажмите кнопку .
Порядок подписания документов с использованием КриптоПро DSS аналогичен подписанию с использованием КриптоПро CSP. Подробнее об этом читайте в статье «Подписание документа с использованием ЭП».
Нашли опечатку? Выделите текст, нажмите ctrl + enter и оповестите нас
Программно-аппаратный комплекс КриптоПро DSS 2.0 предназначен для централизованного выполнения действий пользователей по созданию электронной подписи (ЭП), управления сертификатами и других криптографических операций с использованием ключей, хранимых в ПАКМ КриптоПро HSM (дистанционная («облачная») подпись), локально в мобильном приложении (мобильная подпись) или на рабочем месте пользователя (DSS Lite).
КриптоПро DSS 2.0 обеспечивает:
- создание электронной подписи любого формата электронного документа;
- отсутствие необходимости в установке клиентской части на стационарное рабочее место при работе с неквалифицированной подписью;
- отсутствие необходимости в установке клиентской части на стационарное рабочее место при установке клиентских компонент на мобильные устройства;
- возможность работы с квалифицированной электронной подписью в случае использования комплектаций, имеющих сертификаты соответствия требованиям ФСБ России (требуется установка указанных в документации на данные комплектации клиентских компонент);
- широкий охват платформ и устройств, с которых пользователь может работать с КриптоПро DSS;
- снижение стоимости развертывания и владения инфраструктурой ЭП, т.к. нет необходимости установки средства ЭП на каждое стационарное рабочее место пользователя, а управление всей инфраструктурой сосредоточено на одном сервере;
- снижение риска компрометации ключей пользователей за счёт их централизованного защищённого хранения;
- возможность использования стандартного интерфейса CryptoAPI с помощью дополнительного модуля КриптоПро Cloud CSP на базе КриптоПро CSP версии 5.0 для обеспечения совместимости с традиционными приложениями;
- возможность работы с локальными ключами электронной подписи на рабочих местах пользователей (режим КриптоПро DSS Lite);
- возможность работы с локальными ключами электронной подписи на мобильных устройствах пользователей (режим мобильной подписи);
- лёгкость встраивания функций создания ЭП в прикладные системы за счёт наличия простых интерфейсов автоматизации на базе стандартных средств протокола HTTP и веб-сервисов (API), включая SOAP и REST;
- возможность усиления ранее созданной электронной подписи до усовершенствованного формата (CAdES-T или CAdES-X Long Type 1) путем добавления штампов времени и информации о статусе сертификата.
- возможность применения различных схем аутентификации пользователя для доступа к его ключам, включая возможность интеграции со сторонними центрами идентификации по протоколам SAML (WS-Security) и OAuth (в т.ч. с корпоративным доменом на безе MS AD и OpenLDAP);
- централизованное /локальное шифрование/расшифрование электронных документов;
- пакетная обработка электронных документов (подписание/шифрование по API одной командой набора однотипных электронных документов);
- Поддержка нескольких экземпляров сервисов электронной подписи и центров идентификации с различными параметрами настройки функционирования на одном сервере КриптоПро DSS
- Визуализация (отображение) подписываемых электронных документов формата PDF, docx, txt, xml. Возможно расширение перечня форматов отображаемых файлов.
- создание видимой подписи с логотипом и текстом и в виде изображения (image appearance) с учетом требований Приказа Минкомсвязи и ФСО России от 27.05.2015 №186/258При для документов формата PDF с использованием API (SOAP/REST);
- возможность интеграции с корпоративными хранилищами документов, поддерживающими стандарт CMIS;
- возможность кастомизации графического веб-интерфейса (цветовой гаммы, логотипов, шрифтов и т.п.) в соответствии с корпоративным стилем и требованиями Заказчика.
Обращаем внимание: до издания ФСБ России требований, предусмотренных пунктом 2.1 части 5 статьи 8 Федерального закона “Об электронной подписи”, и до осуществления подтверждения соответствия КриптоПро DSS 2.0 изданным требованиям комплекс не может применяться для реализации функций, предусмотренных частью 2.2 статьи 15 Федерального закона “Об электронной подписи”.
Поддерживаемые форматы электронной подписи
- Необработанная электронная подпись ГОСТ Р 34.10-2012 (и ГОСТ 34.10-2001);
- Усовершенствованная подпись (CAdES-BES, CAdES-T и CAdES-X Long Type 1);
- Подпись XML-документов (XMLDSig);
- Подпись документов PDF;
- Подпись документов Microsoft Office.
Требования к окружению
КриптоПро DSS 2.0 предоставляет пользователям интерактивный веб-интерфейс для управления криптографическими ключами и создания ЭП под документами, которые пользователь загружает на КриптоПро DSS. Для работы с данным интерфейсом в случае неквалифицированной подписи необходим лишь веб-браузер.
При встраивании КриптоПро DSS в системы возможна работа через мобильное приложение myDSS, которое получает от сервера уведомления о поступлении документов на подпись и после одобрения операции пользователем отправляет криптографически защищенное подтверждение на сервер КриптоПро DSS.
Безопасность
Создание и хранение ключей электронной подписи пользователей осуществляется с использованием специального защищённого модуля КриптоПро HSM. Каждый пользователь получает доступ к своим ключам после прохождения процедуры надёжной многофакторной аутентификации в КриптоПро DSS. Дополнительно каждый ключевой контейнер защищается индивидуальным ПИН-кодом, который знает и может сменить только владелец ключа электронной подписи.
Пользователями КриптоПро DSS управляет оператор, который имеет возможность посредством веб-интерфейса или API выполнять следующие действия:
- создание пользователя;
- блокирование и удаление пользователя;
- генерация ключа электронной подписи пользователя;
- формирование и передача в удостоверяющий центр запроса на создание сертификата ключа проверки электронной подписи;
- установку полученного сертификата пользователю;
- настройку параметров аутентификации пользователей;
- аудит и формирование аналитической отчетности по выполняемым пользователями операциям;
- сброс пароля в случае его утраты пользователем.
Способы аутентификации
В зависимости от настройки, КриптоПро DSS 2.0 может реализовывать следующие способы аутентификации пользователя:
- классическая однофакторная аутентификация по логину и паролю с дополнительной защитой доступа по протоколу TLS (только для неквалифицированной подписи или при работе в одной контролируемой зоне);
- криптографическая аутентификация по алгоритму HMAC в соответствии с Р-50.1.113-2016 с помощью мобильного приложения myDSS или специального апплета на SIM-карте;
- двухфакторная аутентификация с использованием цифровых сертификатов и USB-токенов или смарт-карт;
- двухфакторная аутентификация с дополнительным вводом одноразового пароля, доставляемого пользователю посредством SMS (OTP-via-SMS) (только для неквалифицированной подписи или в качестве дополнительного фактора аутентификации).
Высокая отказоустойчивость и доступность
Обеспечивается с помощью горячего резервирования и кластеризации всех компонент КриптоПро DSS и КриптоПро HSM с помощью специализированных балансировщиков нагрузки (например, HAProxy) и SQL-кластера на базе технологий MS SQL Server AlwaysOn availability groups.
В случае нарушения функционирования любого из зарезервированных компонентов переключение на резервные, в т.ч. размещенные на территориально-удаленных технологических площадках (Резервных ЦОД), осуществляется автоматически без участия обслуживающего персонала и без потери сохраненных данных.
Мониторинг функционирования и доступности
В составе с КриптоПро DSS может использоваться специальный программный комплекс класса Network Performance Monitoring and Diagnostics (NPMD) “КриптоПро Центр Мониторинга” для мониторинга работоспособности и оперативного уведомления администраторов СЭП о выявленных сбоях, ошибках функционирования и прочих внештатных ситуациях.
Сервис электронной подписи ООО «КРИПТО-ПРО»
Тестовый сервис электронной подписи
Приобрести ПАК “КриптоПро DSS 2.0”
Загрузить ПАК “КриптоПро DSS 2.0”
Порядок использования комплектаций ПАКМ «КриптоПро HSM» с компонентом «КриптоПро DSS 2.0» для работы с квалифицированной электронной подписью
Учебный курс по ПАК “КриптоПро DSS 2.0”
Учебный курс по “КриптоПро Центр мониторинга 1.0”
- Страница для печати
Опубликовано:
25 октября 2021 в 08:07
19
12
Предыстория
У нас возникла необходимость использование сервиса облачной электронной подписи. Почему? Потому, что это лучше простой раздачи копий токенов. Сотрудники могут использовать носители бесконтрольно и в других сервисах кроме DirectumRX! А использование “облачных” токенов через RX гарантирует:
- оперативное управление правами подписи,
- оперативное управление полномочиями сотрудников,
- контроль доступа только из одного сервиса,
- подписи недоступны в других сервисах, например, Госуслугах,
- наличие детальной истории всех подписаний.
Покупать локальный сервер DSS да еще с обязательным «железом» оказалось запредельно дорого – итого около 4 млн. ₽!
Поэтому стали прорабатывать вариант подписки на облачный сервис электронной подписи КриптоПро DSS, который уже включает в себя все необходимые компоненты. Кроме того, он дает возможность централизованного использования усовершенствованных подписей со штампом времени с применением их же сервиса штампа времени КриптоПро TSP.
Опыт настройки
К сожалению, справка не включает описание принципов взаимодействия систем для общего понимания и настройки. Отмечу важные неучтенные в справке моменты:
- Пользователи-подписанты из RX, подписывающие с использованием облачного сервиса, должны быть продублированы один-к-одному в DSS.
- Логины подписантов при этом дублировании должны быть точными копиями логинов RX. Даже для доменной Microsoft Active Directory авторизации надо дублировать имя в DSS – “domain\user”.
- Схема того, что делает RX для случая без штампа времени: по запросу пользователя на подписание документа формируется хэш документа; если сервер видит в настройке сертификата есть настройка плагина, то идет к внешнему серверу DSS по заданным в конфиге настройкам и предъявляет свой сертификат генерации системы RX; происходит авторизация, затем предъявляет одноименный логин RX и проходит далее; затем предъявляет свою открытую часть цифрового сертификата пользователя, выбранной при подписании; ищет соответствующий закрытый сертификат в DSS и предъявляет хэш дока; если все успешно, то обратно отсылается подтверждение УКЭПа.
- Можно дополнительно запросить включение сервиса распознавания стороннего удостоверяющего центра (УЦ), чтобы можно было использовать свои старые сертификаты-токены от разных издателей. По-умолчанию подразумевается, что клиент запрашивает и использует сертификаты только КриптоПро.
- Для пользователей СЭП не нужно запрашивать внешние логины для ЦИ DirectumRX. Это может сделать администратор-оператор DSS самостоятельно. Надо лишь будет сделать дополнительную настройку в кабинете DSS.
В начале пошли по инструкции. Но по опыту выяснилось, что лучше следовать с учетом замечаний:
- Пункт 1. Совсем необязательно и даже неправильно сразу заключать договор. Мы предпочли «прощупать» сервис и возможности в тестовом режиме. Его любезно, бесплатно и быстро предоставляет КриптоПро. Составили запрос на подключение к тестовому СЭП с ролью оператора, для возможности регистрации других пользователей и управления их сертификатами.
Имейте ввиду нюанс: если у вас будет свой оператор DSS пользователей и сертификатов, то потом перед заключением рабочего договора КриптоПро запросит наличие сертифицированного сотрудника по курсу «Оператор СЭП «КриптоПро DSS». Это требование законодательства на допуск, как я понял. Обучение 2 дня и у сторонних учебных центров дешевле 😊 около 25 тыс. ₽. - Пункт 2. Отправка запроса. Необязательно писать письмо. Можно также заполнить форму прямо на сайте. При этом указали для себя Схему обслуживания – Распределенная с оператором, чтобы свободно управлять своими подписантами в DSS. В любом случае указываем дополнительно «Требуется установить службы API v2».
- Подпункт 2.1 В инструкции не говорится о том, что КриптоПро помимо настроек присылает в архиве с паролем открытый и закрытый сертификаты авторизации оператора, доверенного и промежуточных своих центров. Они ставятся на рабочем месте оператора с использованием КриптоПро CSP 5. Обратите внимание на инструкцию по установке сертификата авторизации оператора с привязкой к закрытому ключу. Сертификаты центров надо установить и на рабочем сервере.
- Пункт 3. Настройка RX. Далее будьте готовы к тому, что в ответ п.2 КриптоПро присылает гораздо больше параметров, чем надо для настройки в RX. У неискушенного человека возникает проблема – куда какой параметр подставлять в конфиге RX. И вам может показаться, что они пересекаются. Полный набор параметров Директума с комментариями для целей DSS можно посмотреть здесь “..\inetpub\wwwroot\DrxWeb\api\_ConfigSettings.xml.example” в разделе -Список настроек плагина DSS-. Немного противоречивыми и некорректными выглядят примеры в справке в п.3.
Лишним и мешающим работе оказался параметр в примере – «tspServiceAddress = “http://www.cryptopro.ru/tsp/tsp.srf”».
Сложности сопоставления мы прошли и теперь готовое решение публикуем для вас, чтобы вы не тратили время на то же самое. Минимально необходимые параметры Директума – это clientId, identityCenterAddress, signatureServiceAddress, documentsStorageServiceAddress и signServiceResource. В присланном описании КриптоПро они назывались соответственно так – ClientID, «URL-адрес Центра идентификации СЭП», «URL-адрес прикладного интерфейса СЭП», «Сервис Обработки Документов» с добавлением к имени «/api» и «Идентификатор (resource) сервиса подписи». Итоговый блок плагина у нас выглядит так:
<plugin id = “22837f59-e686-4c9b-a8e0-8dec1562aa0a”
clientId = “clientNameX”
identityCenterAddress = “https://stenddss.cryptopro.ru/NameXidp/”
signatureServiceAddress = “https://stenddss.cryptopro.ru/NameXss/rest/api”
documentsStorageServiceAddress =”https://stenddss.cryptopro.ru/NameXds/api”
signServiceResource = “urn:cryptopro:dss:signserver:NameXss”
cadesType = “BES”
qualifiedCAThumbprints = “CC9D********************”
platformTokenLifeTime = “00:05:00” />
Обращаю внимание на дополнительный последний параметр – сколько времени токен остается активным после первого использования. Он позволяет существенно уменьшить отклик на последующие подписания тем же токеном.
Есть замечание по cadesType и чтобы вам решить какой тип использовать, учитывайте нюанс, обозначенный здесь.
И еще одно замечание по параметрам. Мы натолкнулись на то, что в конфиге можно ненароком поставить не тот символ апострофа: вместо ” такой “. Мы на этом обожглись.
После сохранения настроек рестартовать IIS, а не только пулы.
- Пункт 4 справки. Самый малоинформативный, потому что ссылается на самую полную и общую справку.
А на самом деле достаточно сделать следующие шаги:
В результате учетка в списке станет выглядеть так:
- Теперь надо загрузить для нового подписанта в DSS закрытые ключи. Для этого надо экспортировать в файл закрытую часть ключа. Затем нажать у пользователя последнюю кнопку справа . Если сотрудник будет подписывать УКЭП от нескольких НОРов, то загружаем еще и другие закрытые ключи.
- Пункты 5 и 6 делаются как написано.
Идеи развитии сервиса облачной подписи
По завершении настройки возникают идеи о развитии сервиса облачной подписи в RX.
Переработать справку о DSS. Техподдержка Directum уже этим занимается.
Эффективнее и безопаснее было бы настроить схему отношений логинов пользователей RX и DSS не один-к-одному, а многие-к-одному-служебному-логину-DSS, который обладает всеми закрытыми ключами НОРов. Аналогично сервер приложений обращается к SQL-серверу через единую служебную учетку.
Почему текущая конфигурация неэффективна?
- Двойная работа настроек одного пользователя админом и в Directum, и оператором в DSS.
- Дважды загружать сертификаты для сотрудника: открытые в Directum и закрытые в DSS.
- Человеческий фактор рано или поздно приведет к рассинхронизации настроек в системах. При увольнении или переводе сотрудника надо синхронно менять настройки в обоих системах. Ненадежно.
- Сложности и непонятки при замещении.
- Сейчас двойные настройки постоянно производят два разных сотрудника: админ Directum и оператор DSS.
В новой схеме централизованно текучку обрабатывает только админ Directum. В DSS при этом настройка и загрузка всех закрытых сертификатов производится оператором только один раз в начале.
В предлагаемой мной схеме указанных недостатков и «задвоенной» работы нет. В случае же если конкретные сертификаты могут быть использованы только конкретными сотрудниками (например сертификат врача для подписания электронного больничного листа), то можно оставить старую схему как дополнение для комбинирования способов.
КриптоПро в конце сам предложил создать у себя готовый профиль, чтобы по вводным сразу создавать у себя нужные настройки для нового клиента. Для этого надо будет просто назвать ключевое слово «Директум DSS». Но это пока в проработке.
Понятно, что качественно новые сервисы надо дорабатывать. Но главное, что Директум не останавливается на достигнутом, ищет и находит новые правильные пути развития. Спасибо автору идеи использования сервиса подписания из облака – это очень полезная и востребованная возможность.
Послесловие: Настройка рабочего контура с DSS вскрыла еще пару важных моментов, на которые я обращаю ваше внимание. Требуйте или сами устанавливайте:
1. Отмена подтверждений операций в Аутентификации у логинов. Техподдержка сказала, что возможно в будущем RX научится обрабатывать подтверждения.
2. Разрешить подписание документов и по хэшу документа, а не только по телу.
3. Если планируете использовать усиленную подпись и их сервер штампов времени, то запросите сертификат этого сервера.
Всем привет! Я Максим, бэкенд-разработчик команды MSB (корпоративная сервисная шина), занимаюсь интеграциями систем для внутренних нужд компании Tele2, и в этом посте хочу поделиться опытом интеграции с “КриптоПро DSS” поверх ГОСТ TLS.
Введение
В связи с экономией на бумаге ростом цифровизации бизнес-процессов, в частности, с постепенным уходом от традиционных бумажных документов к электронному документообороту, возникла потребность реализовать электронную подпись документов у нас в компании.
В качестве сервера электронной подписи используется комплекс “КриптоПро DSS”, имеющий возможность встроить двухфакторное подтверждение операций подписания в мобильное приложение, посредством своего DSS SDK.
Мы встроили данный SDK в наше корпоративное мобильное приложение, о котором писала моя коллега в своей статье на Хабре.
Но мой рассказ связан с опытом решения задачи со стороны бэкенда, и мы рассмотрим эту задачу подробнее.
Описание проблемы и её решение
В нашей схеме подключение к серверу электронной подписи осуществляется по ГОСТ TLS с аутентификацией клиента по сертификату.
Но не секрет, что стандартные платформы, а именно горячо любимый мной .NET, не поддерживают российские криптошифры по ГОСТу.
В качестве эксперимента пробовал подключить rtengine, но он не завёлся, и, помимо прочего, он не является сертифицированным средством защиты информации. В таких случаях “КриптоПро” советует использовать “КриптоПро Stunnel”.
Изначально, stunnel – это open-source приложение, выступающее в роли шлюза, который принимает незашифрованный трафик и пересылает его на целевой сервер поверх TLS. Часто используется, когда клиент сам не поддерживает TLS-шифрование.
А Stunnel от “КриптоПро” – это практически тот же stunnel, но с поддержкой ГОСТ TLS, а значит, он замечательно подходит для решения нашей проблемы.
Представленная выше схема рабочая, если бы не одно но: согласно политикам безопасности в компании, все запросы во внешнюю сеть Интернет могут осуществляться только через корпоративный прокси. Ванильный stunnel из коробки умеет делать запросы через прокси, но “КриптоПро” эту фичу выпилил в своей редакции.
Чтобы обойти это ограничение, в схему было решено добавить еще одно известное Linux-администраторам приложение socat (еще один шлюз, в своем роде), который умеет делать подключения через HTTP-прокси. Важное условие – HTTP-прокси должен разрешать подключения через метод CONNECT.
В итоге схема станет такой:
Docker
Для упрощения было решено пренебречь правилом “один контейнер – один процесс” и запускать “КриптоПро Stunnel” и socat в одном контейнере. Данный контейнер поднимается в виде sidecar рядом с основным контейнером микросервиса. Это позволяет нашему микросервису общаться с “КриптоПро DSS” так, как будто бы они общались по http-протоколу, а вопросы шифрования трафика по ГОСТ TLS отдаются на откуп контейнеру с stunnel и socat.
Чтобы подготовить образ контейнера, нужно скачать deb-пакет с “КриптоПро CSP” (именно в составе этого дистрибутива и состоит “КриптоПро Stunnel”). К сожалению, скачать пакет нельзя по прямой ссылке, которую можно было бы прописать в Dockerfile (иначе бы статья получилась в два раза короче). Для скачивания нужно пройти регистрацию на сайте “КриптоПро”, и только потом будет дана возможность скачать пакет.
Ниже приведен пример Dockerfile, скриптов инициализации и конфига для “КриптоПро Stunnel”.
Рабочий пример можно также посмотреть здесь.
Dockerfile
FROM debian:buster-slim
EXPOSE 80/tcp
ARG TZ=Europe/Moscow
ENV PATH="/opt/cprocsp/bin/amd64:/opt/cprocsp/sbin/amd64:${PATH}"
# stunnel settings
ENV STUNNEL_HOST="example.cryptopro.ru:4430"
ENV STUNNEL_HTTP_PROXY=
ENV STUNNEL_HTTP_PROXY_PORT=80
ENV STUNNEL_HTTP_PROXY_CREDENTIALS=
ENV STUNNEL_DEBUG_LEVEL=5
ENV STUNNEL_CERTIFICATE_PFX_FILE=/etc/stunnel/certificate.pfx
ENV STUNNEL_CERTIFICATE_PIN_CODE=
# dependencies
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime \
&& echo $TZ > /etc/timezone \
&& apt-get update \
&& apt-get -y install lsb-base curl socat \
&& rm -rf /var/lib/apt/lists/*
# install cryptopro csp
WORKDIR /dist
COPY dist/csp_deb.tgz csp_deb.tgz
RUN tar -zxvf csp_deb.tgz --strip-components=1 \
&& ./install.sh cprocsp-stunnel
WORKDIR /
COPY conf/ /etc/stunnel
COPY bin/docker-entrypoint.sh docker-entrypoint.sh
COPY bin/stunnel-socat.sh stunnel-socat.sh
RUN chmod +x /docker-entrypoint.sh /stunnel-socat.sh
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["stunnel_thread", "/etc/stunnel/stunnel.conf"]
docker-entrypoint.sh
#!/bin/bash
# скрипт инициализации
# ---------------------------------
# настройка csp
echo "Configuring CryptoPro CSP..."
# импорт сертификата с закрытым ключом
if [[ ! -f "$STUNNEL_CERTIFICATE_PFX_FILE" ]]; then
echo "Client certificate not found in ${STUNNEL_CERTIFICATE_PFX_FILE}"
exit 1
fi
certmgr -install -pfx -file "${STUNNEL_CERTIFICATE_PFX_FILE}" -pin "${STUNNEL_CERTIFICATE_PIN_CODE}" -silent || exit 1
echo "Certificate was imported."
echo
# определение контейнера-хранилища закрытых ключей
containerName=$(csptest -keys -enum -verifyc -fqcn -un | grep 'HDIMAGE' | awk -F'|' '{print $2}' | head -1)
if [[ -z "$containerName" ]]; then
echo "Keys container not found"
exit 1
fi
# установка сертификата клиента
certmgr -inst -cont "${containerName}" -silent || exit 1
# экспорт сертификата для stunnel
exportResult=$(certmgr -export -dest /etc/stunnel/client.crt -container "${containerName}")
if [[ ! -f "/etc/stunnel/client.crt" ]]; then
echo "Error on export client certificate"
echo "$result"
exit 1
fi
echo "CSP configured."
echo
# ---------------------------------
# запуск socat
echo "Starting socat..."
nohup bash /stunnel-socat.sh </dev/null >&1 2>&1 &
# ---------------------------------
# запуск stunnel
echo "Configuring stunnel..."
sed -i "s/^debug=.*$/debug=$STUNNEL_DEBUG_LEVEL/g" /etc/stunnel/stunnel.conf
echo "Starting stunnel"
exec "$@"
stunnel-socat.sh
#!/bin/bash
echo Configuring socat...
socatParameters="TCP:${STUNNEL_HOST}"
if [[ -n "$STUNNEL_HTTP_PROXY" ]]; then
# если указан http-прокси, подключение будет происходить через него
socatParameters="PROXY:${STUNNEL_HTTP_PROXY}:${STUNNEL_HOST},proxyport=${STUNNEL_HTTP_PROXY_PORT}"
if [[ -n "$STUNNEL_HTTP_PROXY_CREDENTIALS" ]]; then
socatParameters="${socatParameters},proxyauth=${STUNNEL_HTTP_PROXY_CREDENTIALS}"
fi
fi
socatCmd="socat UNIX-LISTEN:/var/run/socat.sock,reuseaddr,fork ${socatParameters}"
while true; do
rm -f /var/run/socat.sock
echo $(date) "Start socat instance."
${socatCmd}
sleep 1
done
stunnel.conf
foreground=yes
pid=/var/opt/cprocsp/tmp/stunnel_cli.pid
output=/dev/stdout
debug=5
[https]
client=yes
accept=80
cert=/etc/stunnel/client.crt
verify=0
connect=/var/run/socat.sock
Про Dockerfile рассказывать не буду, он достаточно тривиален, а вот скрипт инициализации docker-entrypoint.sh интереснее. Первым делом скрипт импортирует сертификат с закрытым ключом в хранилище ключей, так как “КриптоПро Stunnel” для работы необходим закрытый ключ. Затем из хранилища экспортируется сертификат с открытым ключом в формате DER. В дальнейшем по этому сертификату “КриптоПро Stunnel” будет получать закрытый ключ из хранилища ключей.
После инициализации хранилища ключей происходит настройка и запуск socat. Для конфигурирования socat добавлены переменные окружения, которые позволяют указать, через какой HTTP-прокси необходимо выполнять запросы. Не буду останавливаться на этих переменных – их описание есть в репозитории. Однако не лишним будет уточнить, что, если переменные не указаны, socat будет самостоятельно выполнять TCP-запросы до целевого сервера. Для получения входящих запросов socat открывает unix-сокет, на который и будет обращаться “КриптоПро Stunnel”.
Финальным шагом в скрипте являются конфигурирование Stunnel и его последующий запуск.
“КриптоПро Stunnel” при запуске начинает прослушивать порт 80, то есть принимать голый HTTP-трафик. HTTP-трафик будет шифроваться по ГОСТу и пересылаться на unix-сокет, который слушает socat. Socat, в свою очередь, откроет соединение с целевым сервером, напрямую или через HTTP-прокси, и отправит уже шифрованный запрос.
Шифрованный ответ от целевого сервера пройдет ту же цепочку, только обратном порядке, и вызывающему приложению будет возвращен ответ в виде plain text, что позволит не реализовывать ГОСТ TLS внутри приложений (если такая реализация вообще возможна).
Вместо заключения
К сожалению, документация по отечественным решениям зачастую достаточно скромна. К примеру, на попытки заставить работать “КриптоПро Stunnel” через HTTP-прокси ушло много времени, пока не пришло понимание, что “КриптоПро Stunnel” прокси не поддерживает и что без еще одного инструмента не обойтись.
Данная статья призвана помочь сберечь ваше время, надеюсь, описанное окажется полезным.
Бонус
В качестве бонуса хотелось бы поделиться несколькими советами:
Список ресурсов
stunnel TLS Proxy
Шифрование TLS-трафика по алгоритмам ГОСТ-2012 c Stunnel
Установка СКЗИ КриптоПро CSP 5 #
Для начала работы с вашей облачной подписью необходима установленная ОС Windows 7, 8,8.1 или 10. Необходимо проверить, что у вашей Операционной Системы установлены все последние обновления. Для этого запустите Центр Обновления Windows и произведите поиск и обновления компонентов Windows. Основным элементом для работы с облачной подписью является установленное и настроенное КриптоПро CSP 5.0.
- Скачиваем последнюю версию установочного файла КриптоПро CSP 5.0 с сайта разработчика КриптоПро.
- Запускаем скачанный Файл CSPSetup-5.0.exe и нажимаем кнопку Установить.Подробный процесс установки КриптоПро здесь.
- Скачайте корневой сертификат Минкомсвязи России и установите его в «Доверенные корневые центры сертификации».
- Установить корневой сертификат вашего УЦ в «Промежуточные центры сертификации». Инструкция по установке корневого сертификата Минкомсвязи и УЦ.
Настройка КриптоПро CSP 5. 0 #
В операционной системе Windows: Нажимаем Пуск , переходим в папку Крипто-Про и выбираем пункт Инструменты Крипто-Про.
Далее переходим в раздел Облачный провайдер.
Замена адреса DSS сервера #
- Необходимо поменять текст в строке Сервер авторизации на адрес вашего сервера DSS(Адрес можно уточнить у вашего УЦ).
- Так же измените текст в строке Сервер DSS на адрес предоставленный вашим УЦ.
- Нажимаем на кнопку Установить сертификаты.
На следующем шаге укажите логин полученный вами в точке выдачи и нажмите кнопку далее.
Если это первый ваш вход в систему, то вам предложат изменить пароль для входа в личный кабинет облачной подписи. Чтобы это сделать укажите пароль полученный вами в точке выдачи. Вводим его в графу Старый пароль, а ниже указываем Новый пароль и Подтверждение пароля. После установки вашего нового пароля, обязательно запишите его.
Если вы уже изменяли пароль ранее, то предложения изменить пароль не будет.
Аутентификация в приложении myDSS #
Следующим действием нам потребуется пройти Аутентификацию. Потребуется подтвердить операцию с помощью установленного приложения MyDss. Запустите приложение MyDss на смартфоне, и в открывшемся запросе нажимаем Подтвердить. Если на телефоне нет интернет соединения, то выбираем Используйте офлайн-подтверждение. Сканируем приложением MyDss QR-код и указываем полученный код подтверждения на компьютере.
Конечным результатом успешной авторизации, должно стать уведомление Установка сертификатов завершилась успехом.
На этом установка и настройка облачной электронной подписи закончена.
Купить Электронную Подпись для любых целей вы можете в нашей компании. Срок выдачи один рабочий день.
Заказать облачную подпись #
Преимущества решений КриптоПро
Большой опыт в информационной безопасности
Программа широко распространена среди бизнес сообщества для работы с ЭЦП
Совместимость с альтернативным софтом
Прочитать сертификат можно даже если для его установки использовалось другое ПО. Совместимо с операционными системами Mac, Linux и Windows. Для корректного использования не нужны эмуляторы или дополнительные способы запуска софта
Техническая поддержка
Если пользователь ЭЦП не знает, как обращаться с софтом, можно проконсультироваться с техподдержкой криптопровайдера.
Использование ключей, хранящихся на облачном сервисе
В КриптоПро CSP 5.0 впервые появилась возможность использования ключей, хранящихся на облачном сервисе КриптоПро DSS
Ответы на самые распространенные вопросы
А можно без софта на локальном компьютере?
Да, это возможно, если на ЭТП есть дополнительный сервер, который обрабатывает входящую информацию и выступает в роли этого самого локального средства. В этом случае пользователь может использовать любой браузер.
В чем отличие стандартной ЭП от облачной?
Оба эти варианта имеют общее ядро с сертификатом и уровнем безопасности. По своей сути, они аналогичны, просто меняется схема внутреннего API-шифрования при кодировке информации. В первом случае ключ извлекается из локального средства, а во втором – с виртуального (удаленного).
Для использования облачной ЭП тоже нужна авторизация?
Да. Однако теперь авторизация имеет два уровня защиты, и нет привязки к компьютеру. При этом авторизация для пользователя не вызовет никаких сложностей:
- Скачать приложение на смартфон или плагин браузера на компьютер.
- Вставить логин и пароль в окно.
- Ввести пин-код, который пришлет система.
Таким образом, злоумышленникам трудно будет украсть Вашу подпись, так как для этого они должны еще иметь доступ к Вашему телефону или электронной почте, на которые придет СМС или письмо с паролем.
Где хранится сертификат на стороне удостоверяющего центра?
Каждый удостоверяющий центр имеет свое хранилище, которое называется HSM (hardware security module). Оно имеет защищенное пространство, которое поделено на закрытые ячейки. Массовый доступ к ним запрещен.
Проще говоря, пользователь авторизовался, создал запрос на формирование подписи, запрос попадает в HSM на подпись. Шифр подписи генерируется каждый раз при подписании нового документа. Поэтому электронная подпись – это защищенный объект, а ключ не доступен к просмотру.
HSM подтверждает право владельца подписать форму, как нотариус при сделке подтверждает, что вы – это действительно вы.
УЦ получают лицензию от ФСБ на право использования этого хранилища. HSM имеет многофакторную защиту и снабжено антивзломочными датчиками.
Как выглядит первое подключение?
Сначала нужно произвести нехитрую настойку на устройстве пользователя. Для этого вводится два адреса DSS-системы. В принципе, на этом настройка заканчивается.
Следующий этап – это авторизация на сервере. Собственник ОЭП указывает в полях персональные логин и пароль, которые он получил в удостоверяющем центре. После этого проходит двухэтапную авторизацию. Чаще всего, необходимо считать полученный QR-код и скачать.
Потом сканируется второй код со ссылкой на свою ячейку в HSM. Пользователь получает пин-код на подтверждение операции на свой телефон, идентифицируя себя. Затем нужно сменить пароль для входа.
Последующие операции происходят быстрее: ПИН отправляется push-уведомлением. Подразумевается, что если мобильное устройство защищено FaceID или считыванием отпечатка пальца, то второго уровня авторизации, совместно с указанием логина и пароля, вполне хватает для обеспечения конфиденциальности.
- при потере телефона нужно повторить цепочку с QR-кодами снова;
- заблокированный телефон без пин-кода бесполезен;
- пин-код без логина и пароля бесполезен.
Если клиент потерял «незапароленный» телефон, на котором хранилась фотография с логином и паролем (реальный случай из жизни), он может обратиться в УЦ и попросить заблокировать доступ до выяснения.
Как получить конверт с доступами к ОЭП?
Конверт может получить заявитель (директор организации, должностное лицо, ответственный сотрудник), явившись лично в удостоверяющий центр с паспортом.
Либо может прийти сотрудник с официальной доверенностью, соответствующей требованиям 63-ФЗ (об электронной подписи) и требованиям службы безопасности УЦ.
ОЭП широко используется, или пока это редкость?
Использование ОЭП – это уже массовое явление сегодня. Тысячи клиентов из разных субъектов РФ применяют в своей работе электронную подпись на облаке. Из них большинство пользователей – это юридические лица, на втором месте по популярности использования – ИП. Большинство клиентов – москвичи. Затем идут граждане из Санкт-Петербурга, Новосибирска, Хабаровска, Ростова-на-Дону.
Установка и настройка на смартфоне приложения MyDss #
Установка на смартфоне приложения MyDSS #
Запускаем приложение Play Маркет или Apple store в зависимости от типа вашего устройства. В форме поиске, введите myDSS и нажмите кнопку Установить. После окончания установки нажимаем на кнопку Открыть.
Настройка приложения MyDSS #
Запустите установленное приложение MyDss. Для начала работы вам предложат от сканировать QR-код. Приложение отправит запрос на доступ к камере телефона, нажмите Разрешить. Возьмите бланк сертификата, выданного вам в УЦ и отсканируйте напечатанный QR-код. Укажите имя сохраняемого ключа(Оно может быть любым, например: «Облачная подпись для Торгов»). Так же вам потребуется выбрать способ подтверждения (без пароля, пароль, отпечаток пальца, face ID). После всех этих действий приложение будет готово к работе.
Как работает ОЭП?
Рассмотрим пример, характерный для участников торгов. Допустим, поставщик направляет свое предложение на участие в тендере. До появления ОЭП подписать документ невозможно было без установленного на компьютер пользователя плагина. Этот плагин и софт локального средства сообщались друг с другом и работали в неразрывной связке. Этот софт подключался к софту на USB-токене, который генерировал код (ключ). С помощью ключа транзакция заверялась и уже подписанная переходила в плагин на браузер.
Теперь вытащим из этой схемы флеш-накопитель: софт подключается к облачному хранилищу по защищенному каналу.
Одной из первых площадок, которая оценила возможности новых технологий и внедрила в свои процессы использование облачной ЭП, стала федеральная торговая площадка «Росэлторг».
Главные функции
Защита информации
Программа защищает ЭП от вредоносных вирусов и несанкционированного взлома
Создание ключей шифрования
Допускается использование разных типов носителей
Формирование ПИН-кода
Эта функция используется, чтобы обеспечить пользователя дополнительной защитой и усложнить работу злоумышленнику
Защита информации от случайных или преднамеренных потерь
Последние версии КриптоПро показали надежность софта
Защита от вредоносного кода и целенаправленного взлома
Как стали использовать облачные электронные подписи (ОЭП)?
Использование электронных подписей прочно вошло во многие сферы нашей жизни. В различных компаниях сотрудников переводят на электронный документооборот (ЭДО), что делает все процессы удобными и быстрыми. Для подписания документов (договоров, актов, ведомостей, бухгалтерских отчетов и т.д.) требуется наличие электронной подписи. С помощью нее также осуществляется вход в личный кабинет пользователя ЭДО.
В своей работе применяют ЭП онлайн-специалисты и фрилансеры, которые ведут свою деятельность легально и заключают договора с заказчиками. Физические лица могут приобрести ЭП и пользоваться услугами государственных учреждений: записываться на прием в ФНС, к врачу районной больницы, подавать заявления, справки, заходить на «Госуслуги».
Наши читатели – это, в основном, участники торгов и заказчики, которые такие торги организовывают. Они тоже пользуются ЭП для входа в личный кабинет ЕИС, на электронную торговую площадку, при непосредственном участии в торгах.
Мы уже привыкли к электронной цифровой подписи (ЭЦП), которая записана на рутокен (флеш-накопитель), принадлежит одному конкретному владельцу и обеспечивает безопасность данных о нем. Сегодня аббревиатура ЭЦП уже не используется, так говорить неправильно. В обиход вошло новое сокращение – ЭП (электронная подпись). По своей сути, ЭЦП и ЭП – это одно и то же, однако в статье будем использовать новое общепринятое сокращение – ЭП.
На смену понятию электронной подписи, записанной на цифровой носитель, пришло понятие облачной электронной подписи (ОЭП), которая реализована с помощью современных технологий. Она не требует записи сертификата и ключа на какой-либо носитель, а хранится на специальном облаке, в связи с чем у пользователей возникает вопрос о ее надежности. В статье максимально подробно постараемся на него ответить.
Для ЭП на носителе необходима установка специальных программ на компьютер пользователя (СКЗИ) и дополнительных надстроек. В связи с тем, что на смену таким приложениям пришли облачные приложения, у IT-разработчиков появилось желание внедрить их в работу с ОЭП.
Не все до конца понимают, что такое «электронная подпись в облаке», а те понятия, которые даются на различных сайтах в интернете или на youtube-каналах блогеров, подходят для новичков и объяснению «на пальцах». С одной стороны, это хорошо, так как пользователь ЭП не должен иметь образование программиста и вникать в тонкости шифрования информации. Он просто подписывает документ, а как это происходит, как генерируется каждый отдельный код при подписании, интересно далеко не всем.
Что же такое ОЭП с научной точки зрения, расскажем ниже. Любознательным читателям это определение, а также весь материал данной статьи пригодится для расширения собственного кругозора.
Преимущества
- Владелец стандартной ЭП на USB-носителе при утере флешки должен будет получить новый ключ. Владелец облачной ЭП просто поменяет пароль.
- Мобильность пользователя. Раньше нужно было находиться поблизости к компьютеру, на который установлены все программы и надстройки. Теперь при использовании ОЭП привязка к рабочему месту не нужна.
- Нет привязки к браузеру: раньше это был IE, а это вызывало трудности еще на этапе выбора ОС: Linux-админы находили пути обхода, а вот на Mac-устройствах это невозможно.
- Нет территориальной привязки. Пользователь не обязательно должен находиться в РФ. Раньше владельцы должны были находиться внутри страны, ввиду особенностей защиты подписей на носителях.
- Двухуровневая защита обеспечивает более надежную сохранность информации о пользователе.
- Возможность подписывать документы через приложение на смартфоне.