Облачная электронная подпись в России и мире +9



Добрый день, дорогой читатель!

Я некоторое время активно следил за обновлениями и новостями программы «Цифровая экономика». С точки зрения внутреннего сотрудника системы ЕГАИС, конечно, процесс на десятилетия. И с точки зрения разработки, и с точки зрения тестирования, откатки и дальнейшего внедрения с последующими неизбежными и мучительными корректировками всевозможных багов. Тем не менее дело необходимое, важное и назревшее. Основной заказчик и драйвер всего этого веселья, конечно, государство. Собственно, как и во всем мире.
Все процессы уже давно перетекли в цифру или на пути к ней. Это таки замечательно. Тем не менее, существуют и оборотные стороны медалек за отличия. Я человек, который работает постоянно с цифровой подписью. Я сторонник может и «вчерашних», но «по-дедовски» надежных и беспройгрышных методов защиты электронной подписи с помощью токенов. Но цифровизация показывает нам, что все уже давно в «облаках» и КЭП тоже туда нужно и нужно очень быстро.

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

Почему КЭП в «облаке» привлекательна? На самом деле, есть плюсы. Этих плюсов достаточное количество. Это быстро и удобно. Звучит как рекламный слоган, согласитесь, однако же это объективные характеристики облачной ЭЦП.

Быстрота заключается в возможности подписывать документы без привязки к токенам или смарт-картам. Не обязывает нас использовать только десктоп. Сто процентов кроссплатформенная история для любых ОС и браузеров. Особенно актуально для фанатов продукции 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 уже реализованы. Но об этом чуть подробнее и в новом материале.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (2):

  1. ggo
    /#19926676

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


    Как это реализуется на практике?
    Вот есть некий субъект, с которым у физлица возникают какие-либо отношения, которые надо закрепить формально. Субъект о физлице, очевидно, владеет информацией. Но УЦ про физлицо ничего не знает. Или знает? Но тогда физлицо должно свои отношения с УЦ оформить заранее.

    • saege5b
      /#19928640

      Вот тут для физиков была бы идеальной гос.социалка с функцией свидетеля.