Электронная подпись. Просто о сложном - [9]

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

2 — одноразовый пароль. В целях аутентификации в «облаке» способ предусматривал передачу каждый раз уникальной последовательности символов через SMS или ее генерацию ОТР-токеном (One Time Password). Брешь в безопасности данного метода пробивала невозможность привязки одноразового пароля к конкретной операции. Мошенникам было доступно множество вариантов хищения, начиная с фишинга (создание поддельных сайтов и приложений, которым пользователь сообщает пароль) и заканчивая социальной инженерией (манипуляция поведением людей, позволяющая преступникам получить код при личном общении). В качестве дополнительной защиты можно было использовать привязку к реквизитам при отправке аутентифицирующего кода посредством SMS, но злоумышленники разработали ряд способов, позволяющих перехватить и подобные сообщения. При обращении к любым сервисам важно помнить, что защищенность системы определяется надежностью ее «самого слабого звена». Так, например, внедрив для доступа к ключу многоразовый или одноразовый пароль, свойства безопасности «облачной» подписи были бы подменены свойствами безопасности данных механизмов аутентификации. Специалисты не могли допустить подобного ввиду юридически-значимых последствий, к которым ведет участие ЭЦП в бизнес-процессах.

3 — электронный ключ. Этот способ предусматривал аутентификацию в «облаке» при помощи подключаемого к компьютеру токена или смарт-карты. Этот вариант обеспечивал должный уровень безопасности, но на корню «убивал» идею простоты и мобильности, которую пропагандировала «облачная» ЭЦП, снова привязывая электронную подпись к сертифицированным носителям.

Электронная подпись в облачных сервисах

За последние несколько лет в ИТ-индустрии прочно закрепились тренды перехода от эксплуатации собственной ИТ-инфраструктуры к использованию облачных вычислений.

Именно проблема гарантированной аутентификации является пока наиболее существенной.

Неудобства использования традиционной ЭП:

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

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

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

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

Аутентификация пользователя в облачном сервисе обязана быть как минимум двухфакторной. Как правило наиболее доступный и простой в использовании вариант — это подтверждение входа через код полученный в СМС-сообщении.