Вход в облака
<br>Экспертный комментарий Алексея Сабанова, заместителя генерального директора компании "Аладдин Р.Д."
Аутентификация пользователей сервисов — ключевая проблема безопасности в облаках
Популярность облачных сервисов растет, ими пользуются и конечные пользователи, и компании самого разного размера, и даже госструктуры. Соответственно растет "цена ошибки" — стоимость последствий несанкционированного проникновения в систему, утечки и порчи данных и т. д. И сообщения о взломах учетных записей социальных сетей, на серверах электронной почты или в других сервисах появляются все чаще. Одной из важнейших мер обеспечения безопасности данных является обеспечение безопасной работы удаленного пользователя, частного или корпоративного, ведь его устройство доступа гораздо менее защищено от технических ухищрений злоумышленников, чем само облако (а сам он — от методов "социальной инженерии").
Пароль и альтернативы
Чаще всего взломы становятся возможны потому, что злоумышленники подсмотрели пароли и смогли выполнить действия от имени легитимных пользователей. Обман системы аутентификации сервисов неприемлем для корпоративных пользователей облаков — им рекомендуется вообще отказаться от использования пароля, полагает Алексей Сабанов, заместитель генерального директора компании "Аладдин Р.Д.". "Идентификация пользователей в облаках — это следующий шаг после удаленной идентификации и аутентификации в распределенных системах, — говорит он. — Если облако частное, то привычные для пользователей корпоративной сети методы аутентификации можно безопасно перенести и в облако. Если облако отраслевое или, уж совсем высший пилотаж, публичное, то лучшей технологией автоматической идентификации будет предъявление цифрового сертификата, выданного доверенным удостоверяющим центром".
Наиболее простой и достаточно надежный метод аутентификации — это технология одноразовых паролей (One Time password, OTP). Такие пароли могут генерироваться либо специальными программами, либо дополнительными устройствами, либо сервисами, с пересылкой пользователю по SMS. "Основное отличие облачной инфраструктуры от корпоративной, по существу, заключается в большей масштабируемости и более широкой географической распределенности, — отметил Михаил Ашарин, технический специалист Rainbow Security. — На первый план выходит использование для получения одноразовых паролей мобильных гаджетов, которые сегодня есть практически у каждого. В самом простом случае одноразовый пароль будет сгенерирован специальным сервером аутентификации и выслан в SMS на мобильный телефон пользователя после ввода правильного статического пароля на страницу доступа к облачному сервису".
Такой механизм аутентификации является одним из наиболее удобных. По мнению Дениса Безкоровайного, технического консультанта Trend Micro, безопасность, как правило, мешает удобству, но при использовании SMS-аутентификации неудобства для пользователей удается свести к минимуму.
Кроме того, такой метод проверки личности можно использовать не только для аутентификации в облаке, но и для рассылки различных оповещений. "Если использовать, к примеру, одно и то же устройство для доставки одноразового пароля и для аутентификации пользователя в различных лотереях и других сервисах, можно значительно повысить маркетинговую привлекательность решения", — считает Неманья Никитович, управляющий директор Optima Infosecurity.
Интеграция с облаками
Для интеграции корпоративных систем аутентификации с облачными можно применять открытые протоколы, такие как SPML. Именно его рекомендует Алексей Андрияшин, системный инженер Fortinet: "Один из эффективных способов интеграции облачных сервисов на корпоративном уровне — использование SPML-схем. У языка Services Provisioning Markup Language, основанного на XML, спецификация открыта. Интерфейсы SPML позволяют обмениваться идентификационными данными не только о пользователях, но и о ресурсах и информационных сервисах". Однако этот протокол пока не очень распространен.
Можно использовать и уже достаточно старый протокол удаленной аутентификции Kerberos, который позволяет осуществить модульную проверку идентификационных данных пользователей. Ашарин дал следующие рекомендации по интеграции систем аутентификации: "С учетом современных высокотехнологических требований к безопасности и обслуживанию облачной инфраструктуры такой сервер аутентификации должен поддерживать разнообразные устройства и методы аутентификации, в том числе и многоуровневые, встроенный механизм интеграции с внешним SMS-шлюзом для доставки одноразового пароля по независимому GSM-каналу, расширяемые политики доступа и ролевой принцип управления. С другой стороны, решение должно предоставлять необходимые сервисы обслуживания для операторов и самообслуживания". В частности, компания Rainbow Security предлагает на российском рынке подобный сервер аутентификации ActivID 4TRESS Authentication Server, разработанный компанией HID.
В случае когда в облако переносится корпоративное приложение, могут возникнуть проблемы с аутентификацией. "При аренде приложений понадобится доработка механизмов обеспечения безопасности приложений, — предупредил Александр Санин, коммерческий директор компании "Аванпост". — Большинство существующих корпоративных приложений не будут обеспечивать достаточной надежности аутентификации пользователей, поскольку они разрабатывались в расчете на использование в демилитаризованной зоне. Для перевода этих приложений в облако может потребоваться доработка внутренних средств аутентификации или интеграция в них стороннего провайдера".
Настроить такую интеграцию обычно помогает провайдер облака. Впрочем, использование методов аутентификации напрямую зависит от оператора, от выбранной им модели предоставления услуг. Сергей Ермаков, системный архитектор компании "Информзащита", считает: "Необходимость тех или иных методов аутентификации определяется оператором. Им же решается вопрос, предоставить ли пользователю возможность использовать усиленные методы аутентификации".
Цена вопроса
Следует отметить, что у различных технологий аутентификации разная "цена вопроса". При двухфакторной аутентификации в стоимость входит и цена устройства — поэтому затраты на такую технологию всегда выше, чем на простую проверку пароля. Но не нужно забывать, что и ресурсы, к которым подключается пользователь, имеют различную ценность. Поэтому при выборе метода аутентификации необходимо придерживаться принципа, что стоимость защиты не должна превышать ценности ресурса. В частности, доступ к почтовым системам особой ценности не представляет, поэтому для аутентификации в системе электронной почты использовать смарт-карты будет не очень удобно. А вот электронный документооборот, платежные поручения, сведения о клиентах представляют большую ценность, а значит, при доступе к соответствующим системам стоит озаботиться адекватными технологиями проверки подлинности личности. Собственно, есть решения для динамической аутентификации — проверка различных по надежности идентификаторов в зависимости от действий, которые производит пользователь в облаке, чтобы на разных этапах работы с системой использовать разные уровни аутентификации — в зависимости от ценности информации.