Облачная электронная подпись в России и мире
Я некоторое время активно следил за обновлениями и новостями программы «Цифровая экономика». С точки зрения внутреннего сотрудника системы ЕГАИС, конечно, процесс на десятилетия. И с точки зрения разработки, и с точки зрения тестирования, откатки и дальнейшего внедрения с последующими неизбежными и мучительными корректировками всевозможных багов. Тем не менее дело необходимое, важное и назревшее. Основной заказчик и драйвер всего этого веселья, конечно, государство. Собственно, как и во всем мире.
Все процессы уже давно перетекли в цифру или на пути к ней. Это таки замечательно. Тем не менее, существуют и оборотные стороны медалек за отличия. Я человек, который работает постоянно с цифровой подписью. Я сторонник может и «вчерашних», но «по-дедовски» надежных и беспройгрышных методов защиты электронной подписи с помощью токенов. Но цифровизация показывает нам, что все уже давно в «облаках» и КЭП тоже туда нужно и нужно очень быстро.
Я постарался разобраться, пока на уровне законодательной и технической базы, где было возможно, как обстоит дело с облачными ЭП у нас и в Европе. На самом деле, на эту тему даже уже не одна научная диссертация вышла. Поэтому призывают профи в этом вопросе подключаться к развитию темы.
Почему КЭП в «облаке» привлекательна? На самом деле, есть плюсы. Этих плюсов достаточное количество. Это быстро и удобно. Звучит как рекламный слоган, согласитесь, однако же это объективные характеристики облачной ЭЦП.
Быстрота заключается в возможности подписывать документы без привязки к токенам или смарт-картам. Не обязывает нас использовать только десктоп. Сто процентов кроссплатформенная история для любых ОС и браузеров. Особенно актуально для фанатов продукции Apple, для которых есть определенные сложности поддержки ЭП в системе MAC. Выход из любой точки мира, свобода выбора УЦ (даже не Российских). В отличи от аппаратных средств КЭП, облачные технологии позволяют избежать сложностей с совместимостью программного и аппаратного обеспечения. Что, да, удобно, и, да, быстро.
И как же тут не соблазниться на такую красоту? Дьявол кроется в деталях. Поговорим о безопасности.
«Облачная» КЭП в России
Безопасность облачных решений, а в особенности ЭЦП – это одна из основных болей безопасников. Что именно мне не нравится, спросит меня читатель, ведь уже все давно используют облачные сервисы, а с СМС-кой еще надежнее сделать банковский перевод.
На самом деле, опять-таки, вернемся к деталям. Облачная ЭЦП – это будущее, с которым сложно спорить. Но не сейчас. Для этого должны произойти нормативно-правовые изменения, которые позволят защищать обладателя облачных ЭЦП.
Что мы имеем сегодня? Существует ряд документов, определяющие понятие ЭП, электронного документооборота (ЭДО), а также законы о защите информации и обороте данными. В том числе нужно учитывать и Гражданский кодекс (ГК РФ), который регламентирует использование ЭП в документах.
Федеральный закон №63-ФЗ «Об электронной подписи» от 06.04.2011. Основной и рамочный закон описывающий общий смысл использования ЭП при совершении сделок различного характера и оказания услуг.
Федеральный закон №149-ФЗ «Об информации, информационных технологиях и о защите информации от 27.07.2006. В настоящем документе конкретизируется понятие электронного документа и всех связанных с ним сегментов.
Есть дополнительные законодательные акты, которые сопричастны регулированию ЭДО
Федеральный закон 402-ФЗ «О бухгалтерском учете» от 06.12.2011. Законодательный акт предусматривает систематизацию требований к бухгалтерии и бухгалтерским документам в электронном виде.
В т.ч. можно учесть Арбитражный процессуальный кодекс РФ, которые допускают документы, подписанные ЭП в качестве доказательств в суде.
И именно тут и пришло мне в голову поковыряться в вопросе обеспечения безопасности, ведь у нас стандарты для средств крипто-защиты обеспечивает ФСБ и обеспечивает выдачу сертификатов соответствия. С 18 февраля ввелись-таки новые ГОСТы. Таким образом, ключи, хранящиеся в облаке напрямую не защищены сертификатами ФСТЭК. Защита самих ключей и безопасного входа в «облако» и являются краеугольными камнями, которые пока еще мы у нас не решили. Далее рассмотрю пример регулирования в Евросоюзе, что наглядно продемонстрирует более продвинутую систему безопасности.
Европейский опыт использования облачных ЭП
Начнем с главного – облачные технологии, не только ЭП имеют четкий стандарт. Основой Группа координации облачных стандартов (Cloud Standard Coordination, CSC) Европейского института телекоммуникационных стандартов (European Telecommunications Standards Institute, ETSI). Однако на территории разных государств все еще имеются различия в стандартах защиты данных.
Базой для комплексной защиты данных является обязательная для провайдеров сертификация по ISO 27001:2013 на системы менеджмента информационной безопасности (соответствующий российский ГОСТ Р ИСО/МЭК 27001-2006 базируется на версии этого стандарта от 2006 года).
В ISO 27017 предусматриваются дополнительные элементы безопасности для облака, отсутствующие в ISO 27002. Полное официальное название этого стандарта: «Свод правил для средств управления информационной безопасностью на базе ISO/IEC 27002 для облачных сервисов» («Code of practice for information security controls based on ISO/IEC 27002 for cloud services»).
Летом 2014 года ISO опубликовала стандарт ISO 27018:2015 о защите персональных данных в облаке, а в конце 2015 года — ISO 27017:2015 о средствах контроля информационной безопасности для облачных решений.
Осенью 2014-го года в силу вступило новое Постановление Европарламента №910/2014, получившее название eIDAS. Новые правила разрешают пользователям хранение и использование ключа КЭП на сервере аккредитованного поставщика доверенных услуг, так называемого TSP (Trust Service Provider).
Европейский комитет по стандартизации (CEN) в октябре 2013-го года принял техническую спецификацию CEN/TS 419241 «Security Requirements for Trustworthy Systems Supporting Server Signing», посвященную регулированию облачный ЭЦП. В документе описано несколько уровней соответствия безопасности. К примеру, для соответствия «уровня 2», предъявляемого для формирования квалифицированной электронной подписи, является поддержка строгих вариантов аутентификации пользователей. По требованиям данного уровня аутентификация пользователя происходит напрямую на сервере подписи, в отличии, к примеру, от допустимой для «уровня 1»аутентификации в приложении, которое от своего имени обращается к серверу подписи. Так же в соответствии с этой спецификацией, пользовательские ключи подписи для формирования квалифицированной ЭП должны обязательно храниться в памяти специализированного защищенного устройства (англ. hardware security module, HSM).
Аутентификация пользователя в облачном сервисе обязана быть как минимум двухфакторной. Как правило наиболее доступный и простой в использовании вариант — это подтверждение входа через код полученный в СМС-сообщении. Так к примеру, реализовано большинство личных кабинетов ДБО российских банков. Помимо привычных криптографических токенов в качестве средства аутентификации может применяться также приложение на смартфоне, и генераторы одноразовых паролей (OTP-токены).
Могу подвести пока промежуточный итог, относительно того, что облачные КЭП пока у нас еще только формируются и отходить от железа рано. В принципе, это естественный процесс, который то и в Европе (о, великая!) длился около 13-14 лет, пока были выработаны более менее точные стандарты.
Пока мы не разработаем хороших ГОСТов, регулирующих наши облачные сервисы, рано говорить о полном отказе от аппаратных решений. Скорее, они сейчас, наоборот, станут двигаться в сторону «гибридов», то есть работать с облачными подписями в том числе. Некоторые примеры, соответствующие евростандартам работы с Cloud уже реализованы. Но об этом чуть подробнее и в новом материале.
Где найти кэп в облаке
В этом выпуске речь пойдет об облачной подписи, ее преимуществах и минусах. Также вы узнаете как настроить облачную подпись для работы в десктопных приложениях.
Разница между облачной электронной подписью и традиционной электронной подписью — в носителе, на котором она содержится. Ключи облачной подписи хранятся, не на токене, флешке или в реестре компьютера, как у привычной нам электронной подписи, а на сервере удостоверяющего центра.
Плюсы такого варианта хранения в том, что ключ невозможно потерять или повредить, в отличии от физического носителя. Еще облачная подпись удобна тем, что она доступна всегда и с любого места. Все что нужно, это наличие интернета и браузера.
Минусы у облачной подписи тоже есть. Нужен интернет, иначе не получится воспользоваться подписью. А главное ключ облачной подписи может быть использован в рамках только одной определенной информационной системы или веб-сервиса.
Типичный пример, это сервис личного кабинета налогоплательщика для физических лиц на сайте налоговой. Здесь можно бесплатно получить ключ неквалифицированной электронной подписи. Подпись облачная, ключ хранится на сервере налоговой. Но использовать ее кроме как для общения с ФНС нигде больше нельзя.
Весной этого года компания КРИПТО-ПРО сообщала о выпуске первого криптопровайдера под названием КриптоПро Cloud CSP. Он реализует стандартный интерфейс Microsoft CSP и позволяет в привычных приложениях, использовать облачную криптографию, обращаясь к ключам пользователя, хранимым в КриптоПро DSS. А КриптоПро DSS это программно-аппаратный комплекс, сочетающий в себе сервер создания и проверки электронной подписи и сервер хранения ключей.
Если вы уже успешно пользуетесь облачной электронной подписью либо собираетесь это делать, то с помощью КриптоПро Cloud CSP можете применять ваш ключ из облака в обычном КриптоАРМ. И подписывать любые документы в ФСРАР, Росреестр, в банки и т.д.
Сделать это просто. Нужно скачать криптопровайдер с сайта и установить его на ваш компьютер. Затем запустить утилиту cptools, в ней указать настройки сервера DSS и установить ваш сертификат локально. После этого сертификат будет установлен на компьютере, но ключ по прежнему будет оставаться в облаке.
Он будет виден в КриптоАРМ и вы сможете подписывать локально документы сертификатом, ключ которого храниться в облаке. Очень здорово!
Где найти кэп в облаке
В традиционном, привычном для подавляющего большинства пользователей понимании электронной подписи (ЭП) ключ этой самой подписи хранится у её владельца. Чаще всего для этого используется некий защищённый ключевой носитель в формате USB-токена или смарт-карты, который пользователь может носить с собой. Этот ключевой носитель тщательно оберегается владельцем от посторонних лиц, поскольку попадание ключа в чужие руки означает его компрометацию. Для использования ключа на устройстве владельца устанавливается специализированное программное обеспечение (СКЗИ), предназначенное для вычисления ЭП.
С другой стороны, в мире ИТ всё шире применяется концепция « облачных вычислений » , которая во многих отношениях имеет массу преимуществ по сравнению с использованием традиционных приложений, установленных на компьютере пользователя. Вследствие этого возникает вполне закономерное желание воспользоваться данными преимуществами облачных технологий для создания « ЭП в облаке » .
Но прежде чем решать данную задачу необходимо определить, что же мы будем понимать под « электронной подписью в облаке » . В настоящее время в разных источниках можно встретить разные же трактовки этого понятия, зачастую годящиеся разве что только для объяснения на пальцах человеку « с улицы » , который зашёл в Удостоверяющий Центр, чтобы « купить электронную подпись » .
Что такое квалифицированная электронная подпись в облаке
Для целей данной статьи, а также других научно-популярных и практических дискурсов об облачной электронной подписи предлагается использовать следующее определение.
Электронная подпись в облаке (облачная электронная подпись) – это вычислительная система, предоставляющая через сеть доступ к возможностям создания, проверки ЭП и интеграции этих функций в бизнес-процессы других систем.
В соответствии с данным определением, для облачной электронной подписи может использоваться в том числе и локальное средство ЭП. Например, используя КриптоПро DSS Lite, пользователь через веб-браузер может подписывать электронный документ с помощью средства ЭП, установленного на его оконечном устройстве (персональный компьютер или планшет). В подобной системе ключ подписи остаётся у владельца и вопросы безопасности решаются с помощью стандартного набора средств, известного в мире « традиционной ЭП » . Если хотите, можно назвать это облачной ЭП с локальным средством ЭП.
Другой вариант облачной ЭП получается при использовании средства ЭП, размещённого в облаке. Для удобства дальнейшего изложения н азовём такую схему полностью облачной ЭП , чтобы отличать её от предыдущей. Эта схема регулярно вызывает жаркие дискуссии среди специалистов, поскольку подразумевает передачу самого ключа подписи « в облако » . Данная же статья призвана прояснить ряд вопросов, связанных с безопасностью полностью облачной ЭП.
Начнём с главного
Основной головной болью при переводе любой ИТ-системы « в облако » становится боль « безопасников » (и помогающих им юристов), связанная с передачей « туда » информации для обработки или хранения. Если раньше эта информация не покидала некоторого защищённого периметра, и можно было сравнительно легко обеспечить её конфиденциальность, то в облаке само понятие периметра отсутствует. При этом ответственность за обеспечение конфиденциальности информации в каком-то смысле « размывается » между её владельцем и поставщиком облачных услуг.
То же самое происходит и с ключом ЭП, передаваемым в облако. Более того, ключ ЭП – это не просто конфиденциальная информация. Ключ должен быть доступен только одному лицу – его владельцу. Таким образом, доверие к облачной подписи определяется не только личной ответственностью пользователя, но и безопасностью хранения и использования ключа на сервере и надежностью механизмов аутентификации.
В настоящее время проводятся сертификационные испытания нашего решения КриптоПро DSS. Это сервер облачной ЭП, хранящий ключи и сертификаты пользователей и предоставляющий аутентифицированный доступ к ним для формирования электронной подписи. Оба упомянутых выше аспекта безопасности облачной ЭП в частности являются предметом исследований, проводимых в ходе испытаний КриптоПро DSS. В то же время, стоит отметить, что существенная часть этих вопросов уже рассмотрена в рамках тематических исследований СКЗИ «ПАКМ КриптоПро HSM» , на котором основывается КриптоПро DSS.
Европейский путь
В октябре 2013 года Европейский Комитет по Стандартизации (CEN) одобрил техническую спецификацию CEN/TS 419241 «Security Requirements for Trustworthy Systems Supporting Server Signing». В этом документе приводятся требования и рекомендации к серверу электронной подписи, предназначенному для создания, в том числе, квалифицированных подписей.
Хочется отметить, что уже сейчас КриптоПро DSS в полном объёме соответствует требованиям данной спецификации в наиболее сильном варианте: требованиям Уровня 2, предъявляемым для формирования квалифицированной электронной подписи (в терминах европейского законодательства).
Одним из основных требований Уровня 2 является поддержка строгих вариантов аутентификации. В этих случаях аутентификация пользователя происходит напрямую на сервере подписи – в противоположность допустимой для Уровня 1 аутентификации в приложении, которое от своего имени обращается к серверу подписи. Все методы аутентификации, поддерживаемые КриптоПро DSS, удовлетворяют данному требованию Уровня 2.
В соответствии с этой спецификацией, пользовательские ключи подписи для формирования квалифицированной ЭП должны храниться в памяти специализированного защищенного устройства (криптографический токен, HSM). В случае КриптоПро DSS таковым устройством является программно-аппаратный криптографический модуль КриптоПро HSM – сертифицированный ФСБ России по уровню KB2 как средство ЭП.
Аутентификация пользователя на сервере электронной подписи для выполнения требований Уровня 2 обязана быть как минимум двухфакторной. КриптоПро DSS поддерживает широкий, постоянно пополняемый спектр методов аутентификации, в том числе и двухфакторных. Помимо привычных криптографических токенов в качестве средства аутентификации может использоваться и специализированное приложение на смартфоне, такое как КриптоПро AirKey, и генераторы одноразовых паролей (OTP-токены). В документе CEN эти методы также упомянуты.
Ещё одним перспективным способом аутентификации по Уровню 2 может стать использование криптографического приложения на SIM-карте в телефоне. По нашему мнению, данный вариант использования SIM-карт с криптографией наиболее реален, поскольку построение функционально законченного СКЗИ (или средства ЭП) по новым требованиям ФСБ на базе только лишь SIM-карты вряд ли возможно.
Рассматриваемая техническая спецификация также допускает использование сервера электронной подписи для формирования подписей сразу для некоторого набора документов. Данная возможность может быть полезна при подписании большого массива однородных документов, отличающихся лишь данными в нескольких полях. При этом аутентификация пользователя производится один раз для всего пакета документов. Поддержка такого варианта использования также имеется в КриптоПро DSS.
В документе CEN содержится также ряд требований к формированию, обработке, использованию и удалению пользовательского ключевого материала, а также к свойствам внутренней ключевой системы сервера электронной подписи и к аудиту. Эти требования полностью и даже «с запасом » покрываются требованиями, предъявляемыми к средствам ЭП класса KB2, по которому сертифицирован отвечающий за данные вопросы ПАКМ « КриптоПро HSM » .
Наше будущее
Решение КриптоПро DSS поддерживает широкий набор методов аутентификации, среди которых для каждой задачи возможно подобрать подходящий. Надёжность наиболее безопасных из них соответствует самым строгим критериям европейских требований CEN/TS 419241 и, как мы рассчитываем, в недалёком будущем будет подтверждена сертификатом соответствия ФСБ России.
ЭЦП физических лиц: скопировать в/из облака через Сертификаты
Операция симметрична для копирования ЭЦП с локального компьютера в облако и обратно. Подключение к облаку должно осуществляться в режиме Удаленного рабочего стола (RDP).
На целевом компьютере (сервере) должен быть установлен КриптоПро.
Рассмотрен случай, когда исходная ЭЦП хранится в реестре Windows и загружается в реестр.
Способ позволяет конвертировать ЭЦП из VipNet в КриптоПро, т.к. для выгрузки сертификата используется стандартная оснастка Сертификаты Windows и формат pfx для закрытого ключа.
Выполнить mmc.exe (win+R – Открыть mmc.exe – Выполнить)
Файл – Добавить или удалить оснастку – Сертификаты – для моей учётной записи – ОК
Настройку консоли можно сохранить для дальнейшего использования: Файл – Сохранить как.
Этапы:
- 1 1. Выгрузка закрытого ключа ЭЦП в файл
- 2 2. Выгрузка сертификата ЭЦП (открытого ключа) в файл
- 3 3. Копирование файлов закрытого ключа и сертификата на целевой компьютер или в облако
- 4 4. Загрузка закрытого ключа ЭЦП в реестр
- 5 5. Загрузка сертификата ЭЦП и привязка его к закрытому ключу
- 6 6. Проверка
- 7 6. Ссылки по теме в интернете:
1. Выгрузка закрытого ключа ЭЦП в файл
Открыть оснастку “Сертификаты пользователя” или “Управление сертификатами пользователя” (в зависимости от версии Windows.
Пуск → Все программы → КриптоПро CSP или поиском в меню Пуск
Найти нужный Сертификат в разделе Личное и открыть его (щелкнуть дважды).
На вкладке Состав выбрать “Копировать в файл…”
Откроется Мастер экспорта сертификатов. Щелкнуть Далее и выбрать “Да, экспортировать закрытый ключ” и нажать Далее:
ВАЖНО! Если данный пункт недоступен, значит сертификат помечен как ”не экспортируемый”,
скопировать или экспортировать его невозможно .
На следующей странице выбрать “Файл обмена личной информацией — PKCS #12 (.PFX)”, отметить все галки, кроме “Удалить…. “, как на скриншоте, нажать Далее:
На следующей странице, по соображениям безопасности, задать новый пароль для файла сертификата, нажать Далее:
На следующей странице задать имя файла сертификата, например my_key_2022.pfx и путь для его сохранения, например, Рабочий стол. Нажать Далее.
На странице “Завершение работы мастера экспорта сертификатов” проверить заданные параметры и нажать Готово.
Если для ЭЦП был задан пароль, откроется окно КриптоПро CSP с предложением ввести пароль. После верного ввода пароля сохранение ЭЦП будет подтверждено – “Экспорт успешно выполнен”.
2. Выгрузка сертификата ЭЦП (открытого ключа) в файл
Возвращаемся в Сертификаты пользователя и повторяем пп. 1, 2 и 3 раздела 1. Выгрузка закрытого ключа ЭЦП в файл. В п. 4. следует выбрать “Нет, не экспортировать закрытый ключ”, нажать Далее:
На следующей странице выбрать “Файлы X.509 (.CER) в кодировке DER), нажать Далее:
На следующей странице задать имя файла сертификата, например my_key_2022.cer и путь для его сохранения, например, Рабочий стол. Нажать Далее.
3. Копирование файлов закрытого ключа и сертификата на целевой компьютер или в облако
Найти файлы с ключами ЭЦП на Рабочем столе (или в той папке, где он был сохранен). Скопировать файл в целевое назначение. Для этого выбрать файл и нажать Crtl+C , затем перейти Рабочий стол целевого компьютера (или сервера) и нажать Ctrl+V .
4. Загрузка закрытого ключа ЭЦП в реестр
На целевом компьютере (или сервере) дважды щелкнуть на файле ЭЦП (my_key_2022.pfx) – откроется окно Мастера импорта сертификатов. Нажать Далее дважды.
Ввести пароль на файл, заданный при экспорте, для запрета экспорта ЭЦП снять соответствующую галку, нажать Далее:
В следующем окне выбрать Хранилище сертификатов Личное, нажать Далее:
На странице “Завершение работы мастера импорта сертификатов” проверить заданные параметры и нажать Готово. Будет открыто окно КриптоПро с предложение выбрать носитель для контейнера ЭЦП. Выбрать реестр и нажать ОК:
Задать пароль сертификата (ЭЦП) в следующем окне, нажать ОК:
Важно! Если это пароль будет забыт, восстановить его невозможно.
В следующем окне КриптоПро предложит ввести пароль еще раз, для проверки, нажать ОК. Откроется окно с подтверждением – “Импорт успешно завершен”.
5. Загрузка сертификата ЭЦП и привязка его к закрытому ключу
На целевом компьютере (или сервере) открыть КриптоПро, перейти на вкладку Сервис и нажать кн. “Установить личный сертификат”: