Безопасность при использовании облачных сервисов. Проблемы безопасности облачных вычислений и возможности риск-анализа

Облачные вычисления и проблема безопасности

Маслов Владимир Алексеевич

Пензенский государственный университет

Аннотация:

В статье рассматриваются основные вопросы, связанные с проблемой безопасности и защиты информации при использовании технологий облачных вычислений.

The article examines the main issues related to the problem of security in cloud computing.

Ключевые слова:

безопасность, облачные вычисления, защита информации

security, cloud computing

УДК 004.75

Облачные вычисления - это модель обеспечения удобного и повсеместного сетевого доступа по требованию к конфигурируемым вычислительным ресурсам, которые могут быть оперативно предоставлены и освобождены с минимальными эксплуатационными затратами.

Сегодня облачные вычисления (ОВ) являются объектом пристального внимания. Пользователи видят его потенциал, но также есть много связанных с ними проблем. Эта новая парадигма предлагает привлекательные финансовые и технологические преимущества. Однако, хотя концепция разделения времени удаленных сервисов не нова, инфраструктура ОВ еще не полностью исследована с точки зрения безопасности.

Использование ОВ ставит несколько основных вопросов и проблем: защита данных, достоверность, регулирование и производительность. Целью данного исследования является изучение вопросов, затрагивающих безопасность облачных систем.

Облачные системы достаточно экономичны и удобны для предприятий разных размеров. Эта технология характеризуется следующими свойствами:

• Гибкость - доступ к миллионам различных баз данных с возможностью комбинирования их в конфигурируемые сервисы.
• Высокая надежность и безопасность - пользователю не нужно беспокоиться об аппаратных ошибках или утрате оборудования.
• Расширенные возможности совместной работы - благодаря общему доступу, пользователи получают новые способы совместной работы.
• Переносимость - пользователи могут получить доступ из любой точки.
• Упрощение клиентских устройств - пользователям нужен лишь интерфейс для доступа и использования этих данных.
• Неограниченный объем хранимых данных
• Возможность почти мгновенно нарастить вычислительные мощности

ОВ весьма интересны и перспективны, но есть много открытых вопросов в области безопасности . Одна из проблем заключается в том, что управление данными может оказаться недостаточно надежным; риск вредоносных вторжений в облако и сбои облачных сервисов получили сильное внимание со стороны многих компаний .

Исследование, проведенное группой компаний IDC, подтверждает, что безопасность - одна из главных проблем пользователей ОВ .

Современные проблемы и пути их решения

Основными проблемами, возникающие при ОВ, являются сохранение конфиденциальности и целостности данных. Первичным решением этих проблем является шифрование данных, хранящихся в облаке. Но шифрование данных поднимает новые проблемы. Вот краткий обзор некоторых из основных проблем:

Доверие между поставщиком услуг и клиентом является одним из главных вопросов ОВ, который встает сегодня. У клиента нет никаких оснований, чтобы быть уверенным, что поставщик сервиса заслуживает доверия, и нет риска инсайдерских атак.

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

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

Подлинность (Целостность и полнота)

Целостность это предотвращение неправильной модификации информации. Сохранение целостности, как и конфиденциальность, является еще одним важным вопросом, который должен быть решен. Обычно это также обеспечивается за счет использования шифрования данных.

В СУБД могут быть пользователи с разными правами. Пользователь с ограниченным набором прав может осуществлять доступ к подмножеству данных, и также должен быть уверенным в том, что эти данные подлинные .

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

Основное предложение по решению данной проблемы заключается в предоставлении клиентам подписи ПНД и некоторых метаданных вместе с результатами запроса. Эти метаданные, «проверочные объекты», позволяют клиентам заполнить пробелы данных, к которым нет доступа, и проверить целостность. Существуют две основные вариации этой идеи: основанная на деревьях Меркле и основанная на подписи агрегации .

Шифрование — основной метод, используемый для обеспечения безопасности данных в облаке. Оно кажется идеальным решением, но не лишено недостатков. Шифрование требует вычислительных мощностей и значительно влияет на производительность СУБД. Есть несколько подходов к шифрованию, каждый имеет свои недостатки: одни лучше обеспечивают безопасность, а другие сосредоточены на производительности.

Ранние подходы просто применяли шифрование перед записью в базу данных и расшифровку перед чтением.

Запросы зашифрованных данных. Есть несколько способов, которые были предложены для обработки запросов зашифрованных данных [n]. В предложенной схеме используется шифрование данных в каждой ячейке каждой таблицы. Во время запроса данных, его параметры шифруются и проверяются на сохраненных данных. Расшифровки информации не происходит в облаке, что обеспечивает подлинность и целостность информации.

Управление ключами — другая задача, которая возникает при использовании шифрования. Ключ шифрования не может быть сохранен в облаке, поэтому клиент должен контролировать систему управления ключами . Для простых схем шифрования, это может не быть проблемой, так как один ключ может быть использован для всей системы. Тем не менее, практически любая реальная база данных требует более сложной системы .

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

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

Атака на виртуальную машину на которых, как правило, в облаке хранятся и обрабатываются данные. Эти виртуальные машины выполняется на сервере с другими виртуальными машинами, некоторые из которых могут быть вредоносными. Исследования показали, что атаки между виртуальными машинами возможны.

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

Заключение

ОВ предлагают большие преимущества: неограниченные хранилища, быстрый доступ к вычислительной мощности, возможность легкого обмена информацией и ее обработки. Но есть вопросы, и большинство из которых связаны с безопасностью. Облачные системы должны преодолеть множество препятствий, прежде чем получат широкое распространение, но они могут быть использованы уже сейчас с некоторыми оговорками. Был рассмотрен ряд вопросов безопасности, актуальных для облачных систем, однако, это список может быть неполон.

Важным вопросом облачных систем является шифрование, поскольку это основной способ обеспечения безопасности данных, хранящихся в облаке. Однако, шифрование требует больших вычислительных затрат. Разработаны методы, специфичные для DaaS, однако, более эффективные методы по-прежнему необходимы, чтобы помочь ускорить внедрение облачных систем.

Библиографический список:

1. J.Weis, 2011. Securing Database as a Service. IEEE Security and Privacy, 49-55.
2. М.AlZain, B.Soh, & E.Pardede, 2012. A New Approach Using Redundancy Technique to Improve Security in Cloud Computing. IEEE.
3. A.Behl, 2012. An Analysis of Cloud Computing Security Issues. IEEE, 109-114.
4. B.Purushothama, & B.Amberker, 2013. Efficient Query Processing on Outsourced Encrypted Data in Cloud with Privacy Preservation.

Рецензии:

8.12.2013, 20:29 Назарова Ольга Петровна
Рецензия : Рекомендуется к печати

3.02.2015, 9:55 Оладько Владлена Сергеевна
Рецензия : Рекомендуется к печати

17.02.2015, 18:53 Гужвенко Елена Ивановна
Рецензия : Актуальность темы несомненна, в статье раскрыты проблемы облачных вычислений и указаны пути их разрешения. Рекомендуется к печати.

В 2010 году CSA провела анализ основных угроз безопасности в облачных технологиях. Результатом их труда стал документ "Top threats of Cloud Computing v 1.0" в котором наиболее полно на данный момент описываются модель угроз и модель нарушителя. На данный момент разрабатывается более полная, вторая версия этого документа.

Текущий документ описывает нарушителей для трёх сервисных моделей SaaS, PaaS и IaaS. Выявлены 7 основных направлений атак. По большей части все рассматриваемые виды атак - это атаки, присущие обычным, "необлачным" серверам. Облачная инфраструктура накладывает на них определенные особенности. Так, например, к атакам на уязвимости в программной части серверов добавляются атаки на гипервизор, тоже являющийся их программной частью.

Угроза безопасности №1

Неправомерное и нечестное использование облачных технологий.

Описание:

Для получения ресурсов у облачного провайдера IaaS пользователю достаточно иметь кредитную карту. Простота регистрации и выделения ресурсов позволяет спамерам, авторам вирусов и т.п. использовать облачный сервис в своих преступных целях. Раньше подобного рода атаки наблюдались лишь в PaaS, однако последние исследования показали возможность использования IaaS для DDOS-атак, размещения вредоносного кода, создания ботнет сетей и прочего.

IaaS сервисы были использованы для создания ботнет сети на основе троянской программы "Zeus”, хранения кода троянского коня "InfoStealer" и размещения информации о различных уязвимостях MS Office и AdobePDF.

К тому же ботнет сети используют IaaS для управления своими пирами и для рассылки спама. Из-за этого некоторые IaaS сервисы попали в чёрные списки, а их пользователи полностью игнорировались почтовыми серверами.

Усовершенствование процедур регистрации пользователя

Усовершенствование процедур верификации кредитных карт и мониторинг использования платежных средств

Всестороннее исследование сетевой активности пользователей сервиса

Отслеживание основных черных листов на предмет появления там сети облачного провайдера.

Затронутые сервис-модели:

Угроза безопасности №2

Небезопасные программные интерфейсы (API)

Описание:

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

Анонимный доступ к интерфейсу и передача учетных данных открытым текстом являются основными признаками небезопасных программных интерфейсов. Ограниченные возможности мониторинга использования API, отсутствие систем журналирования, а так же неизвестные взаимосвязи между различными сервисами только повышает риски взлома.

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

Убедиться, что используются устойчивые алгоритмы шифрования

Убедится, что используются надежные методы аутентификации и авторизации

Понять всю цепочку зависимости между различными сервисами.

Затронутые сервис модели:

Угроза безопасности №3

Внутренние нарушители

Описание:

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

На данный момент нет примеров подобного рода злоупотреблений.

Внедрение строгих правил закупок оборудования и использование соответствующих систем обнаружение несанкционированного доступа

Регламентирование правил найма сотрудников в публичных контрактах с пользователями

Создание прозрачной системы безопасности, наряду с публикациями отчетов об аудите безопасности внутренних систем провайдера

Затронутые сервис модели:

Рис. 12

Угроза безопасности №4

Уязвимости в облачных технологиях

Описание:

Провайдеры IaaS сервиса используют абстракцию аппаратных ресурсов с помощью систем виртуализации. Однако аппаратные средства могут быть спроектированы без учета работы с разделяемыми ресурсами. Для того, что бы минимизировать влияние данного фактора, гипервизор управляет доступом виртуальной машины к аппаратным ресурсам, однако даже в гипервизорах могут существовать серьезные уязвимости, использование которых может привести к повышению привилегий или получению неправомерного доступа к физическому оборудованию.

Для того, что бы защитить системы от такого рода проблем необходимо внедрение механизмов изоляции виртуальных сред и систем обнаружения сбоев. Пользователи виртуальной машины не должны получить доступ к разделяемым ресурсам.

Есть примеры потенциальных уязвимостей, а так же теоретические методы обхода изоляции в виртуальных средах.

Внедрение самых передовых методов установки, настройки и защиты виртуальных сред

Использование систем обнаружение несанкционированного доступа

Применение надежных правил аутентификации и авторизации на проведение административных работ

Ужесточение требований к времени применения патчей и обновлений

Проведение своевременных процедур сканирования и обнаружения уязвимостей.

Затронутые сервис модели:

Угроза безопасности №5

Потеря или утечка данных

Описание:

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

Неправильное применение правил аутентификации, авторизации и аудита, неверное использование правил и методов шифрования и поломки оборудования могут привести к потере или утечке данных.

Использование надежного и безопасного API

Шифрование и защита передаваемых данных

Анализ модели защиты данных на всех этапах функционирования системы

Внедрение надежной системы управления ключами шифрования

Отбор и приобретение только самых надежных носителей

Обеспечение своевременного резервного копирования данных

Затронутые сервис модели:

Угроза безопасности №6

Кража персональных данных и неправомерный доступ к сервису

Описание:

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

Запрет на передачу учетных записей

Использование двух факторных методов аутентификации

Внедрение проактивного мониторинга несанкционированного доступа

Описание модели безопасности облачного провайдера.

Затронутые сервис модели:

Угроза безопасности №7

Прочие уязвимости

Описание:

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

Отказ компании Amazon от проведения аудита безопасности EC2 cloud

Уязвимость в процессинговом ПО, приведшая к взлому системы безопасности дата центра Hearthland

Раскрытие журнальных данных

Полное или частичное раскрытие данных об архитектуре системы и деталей об установленном ПО

Использование систем мониторинга уязвимостей.

Затронутые сервис модели:

1. Юридическая база

По заявлениям экспертов 70% проблем с безопасностью в облаке можно избежать, если грамотно составить договор о предоставлении услуг.

Базой для такого договора может послужить "Билль о правах облака"

"Билль о правах облака" был разработан еще в 2008 г. Джеймсом Уркухартом (James Urquhart). Этот материал он опубликовал в своем блоге, который вызвал столько интереса и споров, что автор периодически обновляет свой "манускрипт" в соответствие с реалиями.

Статья 1 (частично): Клиенты владеют своими данными

· Ни один производитель (или поставщик) не должен в процессе взаимодействия с клиентами любого плана обсуждать права на любые данные, загруженные, созданные, сгенерированные, модифицированные или любые другие, права на которые имеет клиент.

· Производители должны изначально обеспечивать минимальную возможность доступа к данным клиентов еще на стадии разработки решений и сервисов.

· Клиенты владеют своими данными, что означает, что они отвечают за то, что данные эти соответствуют законодательным нормам и законам.

· Поскольку вопросы соответствия регуляторным нормам по использованию данных, обеспечению безопасности и соблюдению безопасности являются очень важными, необходимо, чтобы клиент определял географическое месторасположение своих собственных данных. В противном случае, производители должны предоставить пользователям все гарантии, что их данные будут храниться в соответствии со всеми нормами и правилами.

Статья 2: Производители и Клиенты совместно владеют и управляют уровнями сервиса в системе

· Производители владеют, а также должны делать все для того, чтобы соответствовать уровню сервиса для каждого клиента в отдельности. Все необходимые ресурсы и усилия, приложенные для достижения должного уровня сервиса в работе с клиентами, должны быть бесплатны для клиента, то есть не входить в стоимость сервиса.

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

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

· Ни при каких условиях производители не должны закрывать учетные записи клиентов за политические высказывания, некорректную речь, религиозные комментарии, если это не противоречит специфическим законодательным нормам, не является выражением ненависти и т.п.

Статья 3: Производители владеют своими интерфейсами

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

· Клиент, однако, обладает правом использовать приобретенный сервис в собственных целях, а также расширять его возможности, реплицировать и улучшать. Данный пункт не освобождает клиентов от ответственности патентного права и права на интеллектуальную собственность.

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

Взаимоотношения между сторонами

На сегодняшний день лучшим экспертом в сфере облачной безопасности является Cloud Security Alliance (CSA). Эта организация выпустила и недавно обновила руководство, включающее описание сотни нюансов и рекомендаций, которые необходимо принимать во внимание при оценке рисков в облачных вычислениях.

Еще одной организацией, деятельность которой затрагивает аспекты безопасности в облаке, выступает Trusted Computing Group (TCG). Она является автором нескольких стандартов в этой и других сферах, в том числе широко используемых сегодня Trusted Storage, Trusted Network Connect (TNC) и Trusted Platform Module (TPM).

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

1. Сохранность хранимых данных. Как сервис-провайдер обеспечивает сохранность хранимых данных?

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

2. Защита данных при передаче. Как провадйер обеспечивает сохранность данных при их передаче (внутри облака и на пути от/к облаку)?

Передаваемые данные всегда должны быть зашифрованы и доступны пользователю только после аутентификации. Такой подход гарантирует, что эти данные не сможет изменить или прочитать ни одно лицо, даже если оно получит к ним доступ посредством ненадежных узлов в сети. Упомянутые технологии разрабатывались в течение "тысяч человеко-лет" и привели к созданию надежных протоколов и алгоритмов (например TLS, IPsec и AES). Провайдеры, должны использовать эти протоколы, а не изобретать свои собственные.

3. Аутентификация. Как провайдер узнает подлинность клиента?

Наиболее распространенным способом аутентификации является защита паролем. Однако провайдеры, стремящиеся предложить своим клиентам более высокую надежность, прибегают к помощи более мощных средств, таких как сертификаты и токены. Наряду с использованием более надежных к взлому средств аутентификации провайдеры должны иметь возможность работы с такими стандартами как LDAP и SAML. Это необходимо для обеспечения взаимодействия провайдера с системой идентификации пользователей клиента при авторизации и определении выдаваемых пользователю полномочий. Благодаря этому провайдер всегда будет располагать актуальной информацией об авторизованных пользователях. Худший вариант - когда клиент предоставляет провайдеру конкретный список авторизованных пользователей. Как правило, в этом случае при увольнении сотрудника или его перемещении на другую должность могут возникнуть сложности.

4. Изоляция пользователей. Каким образом данные и приложения одного клиента отделены от данных и приложений других клиентов?

Лучший вариант: когда каждый из клиентов использует индивидуальную виртуальную машину (Virtual Machine - VM) и виртуальную сеть. Разделение между VM и, следовательно, между пользователями, обеспечивает гипервизор. Виртуальные сети, в свою очередь, развертываются с применением стандартных технологий, таких как VLAN (Virtual Local Area Network), VPLS (Virtual Private LAN Service) и VPN (Virtual Private Network).

Некоторые провайдеры помещают данные всех клиентов в единую программную среду и за счет изменений в ее коде пытаются изолировать данные заказчиков друг от друга. Такой подход опрометчив и ненадежен. Во-первых, злоумышленник может найти брешь в нестандартном коде, который позволит ему получить доступ к данным, которые он не должен видеть. Во-вторых, ошибка в коде может привести к тому, что один клиент случайно "увидит" данные другого. За последнее время встречались и те, и другие случаи. Поэтому для разграничения пользовательских данных применение разных виртуальных машин и виртуальных сетей является более разумным шагом.

5. Нормативно-правовые вопросы. Насколько провайдер следует законам и правилам, применимым к сфере облачных вычислений?

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

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

6. Реакция на происшествия. Как провайдер реагирует на происшествия, и насколько могут быть вовлечены его клиенты в инцидент?

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

Огромные вычислительные мощности облачных инфраструктур открывают перед пентестерами и блекхатами множество новых возможностей. Сегодня мы посмотрим на cloud computing с новой стороны и рассмотрим конкретные кейсы использования облачных мощностей для взлома и пентестинга.

IaaS на службе у хакера

Облачные вычисления представлены для пользователя следующими услугами:

• SaaS (Software as a Service)
• PaaS (Platform as a Service)
• HaaS (Hardware as a Service)
• WaaS (Workplace as a Service)
• IaaS (Infrastructure as a Service)
• EaaS (Everything as a Service)
• DaaS (Data as a Service)
• SaaS (Security as a Service)

В первую очередь нас интересует сервис IaaS, так как он предоставляет в данный момент наиболее востребованную и «реалистичную» среду для пентестера. Сервис IaaS предоставляет пользователю возможность создания виртуального сервера на основе оборудования провайдера облачных вычислений. Самое очевидное преимущество данного сервиса - практически неограниченные возможности по масштабированию вычислительных мощностей.

Что же такое сервис IaaS для пентестера? Это уникальная возможность использовать десятки идентичных по возможностям серверов с целью эффективной реализации классических задач в области пентеста:

• обман IPS при удаленном сканировании портов;
• распределенный перебор паролей;
• атаки на отказ в обслуживании;
• сканирование сетевого периметра;
• автоматизированный поиск уязвимостей.

Само собой, использование инновационных технологий облачных вычислений может быть направлено как в полезное русло, так и в не очень полезное. Как плохие парни могут использовать сервис в своих целях? Этот вопрос мы постараемся рассмотреть в данной главе на примере наиболее частых злоупотреблений.

Анонимность

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

Сетевая разведка

Термин «сетевая разведка» подразумевает под собой мероприятия, направленные на автоматизированный сбор информации для дальнейшего анализа. Облачные вычисления позволяют создать отличную площадку для проведения такого рода мероприятий, потому что обеспечивают несколько важных факторов, которые необходимы для автоматизации сбора данных. А именно: разные IP-адреса, с которых производится сбор данных, скорость канала связи и вычислительные ресурсы, позволяющие быстро обрабатывать полученную в результате сбора данных информацию.

Сканирование портов

Использование возможностей сервиса IaaS позволяет злоумышленнику преодолевать такие защитные средства, как IPS/IDS. Идея возможности скрытого от IPS/IDS сканирования портов на удаленной системе заключается в том, что сканирование проходит с более чем десятка различных IP-адресов с временными интервалами, по частям. В результате - даже хорошо настроенная IPS/IDS не сможет идентифицировать событие сканирования портов, а если идентифицирует его, то заблокирует только один IP-адрес из множества адресов, сканирующих серверов. Естественно, для реализации такой задачи необходимо разработать программное обеспечение, позволяющее удаленно управлять процессами на серверах, запущенных на площадке провайдера облачных вычислений.

Проведение атак

IaaS-площадки идеально подходят и для атак на удаленные сервисы. Например, для перебора паролей, а также различных видов client-side-атак. Во-первых, на площадке достаточно легко и просто «развернуть» любой боевой арсенал, например, metasploit или canvas. Во-вторых, перебор паролей может быть осуществлен распределенно, как и в случае со сканированием портов удаленного хоста, во избежание блокировки IP-адреса атакующего. В третьих, площадка IaaS может послужить отличным посредником между атакующим и целью с точки зрения того, что история всех действий, совершенных с площадки IaaS, будет уничтожена после выключения сервера.

Брутфорс

Возможность использовать условно «неограниченные» ресурсы облачных вычислений позволяет продуктивно проводить мероприятия по брутфорсу хешей и генерации радужных таблиц с последующим восстановлением по ним зашифрованных строк. Явным плюсом генерации радужных таблиц на базе облачных сервисов является возможность использования огромного устройства хранения данных. На практике генерация радужных таблиц для алгоритма ntlm (mixalpha-numeric-all-space, 8 символов) сводится только к вопросу времени и финансовым затратам. Для генерации такой таблицы на топовом домашнем компьютере потребуется порядка 1290 лет. В случае же облачных вычислений, прямо здесь и сейчас можно купить «машину времени», которая будет создаваться примерно 1,5 года и ее стоимость составит порядка $320k. Я хочу сказать, что такую таблицу, используя облачные вычисления, на практике можно создать всего за 1,5 года. В таблице 1 показана детальная статистика по финансовым затратам для такой разработки. В данном случае использовалось 20 серверов со следующими техническими характеристиками: 2xIntel Xeon X5570 quad-core «Nehalem» architecture, 2 ядра NVidia Tesla M2050, 23 Гб ОЗУ.

Цифры говорят о том, что пора менять парольную политику - расшифровать NTLM-хеш пароля из 8 символов вполне реально и доступно для плохих парней. Но это только теория. На практике же политика безопасности паролей более лояльна и ограничивает пользователя лишь длиной пароля - 8 символов в лучшем случае. Статистика используемых паролей в крупных компаниях, составленная Дмитрием Евтеевым и приведенная в его докладе «Анализ проблем парольной защиты в российских компаниях «, говорит о том, что большинство пользователей всеми возможными способами пытаются обойти ограничения парольной политики и использовать простой пароль.

В таблице 2 представлены необходимые для генерации различных радужных таблиц ресурсы.

Как видно, генерация «универсальной» радужной таблицы для паролей, состоящих из символов английского алфавита (lowcase) и цифр (от 1 до 12 символов) занимает целый миллениум и порядка 80 млн долларов. Для частного лица это на грани фантастики, но для государств и даже крупного бизнеса - вполне подъемно. Если же задаться целью, то используя всего 20 000 серверов вместо 20, можно создать такую таблицу всего за год.

Облачный DDoS

В первую очередь необходимо разобраться со схемой проведения эффективной ДДоС-атаки на сервер/сервис. Гаранты эффективности ДДоС-атаки:

• большое количество атакующих машин;

IaaS в скопе со специализированным DDoS-софтом - этой убойная конструкция, позволяющая осуществлять очень эффективные ДДоС-атаки. Сервис IaaS удовлетворяет пункт о необходимом множестве атакующих машин. Специализированный софт должен отвечать за «умную» нагрузку атакуемых систем с целью «отказа в обслуживании».

Специалистами нашей компании было разработано техническое задание для подобного рода софта. Требования к распределенной системе нагрузочного тестирования:

• мультиплатформенность (Linux/Windows);
• модульность;
• централизованное управление (клиент<->сервер).

Необходимые на первых парах модули:

• SYN flood
• UDP flood
• ICMP flood
• Application flood
• HTTP/HTTPS (GET/POST)
• SMTP/SMTP+SSL/TLS
• POP3/POP3+SSL

Параллельно с разработкой распределенной системы нагрузочного тестирования, мы провели испытания уже существующего софта для нагрузочного тестирования. Большая часть публичного ПО не удовлетворяла пункту централизованного управления, в связи с чем пришлось самостоятельно писать управляющие скрипты для централизации управления атакующими приложениями.

Из публичных утилит мы использовали два продукта:

• Mauszahn - утилита для генерации трафика (как валидного, так и невалидного). В большинстве случаев используется для проведения тестирования сетей VoIP или больших сетей, а также для проведения аудита безопасности в отношении систем, возможно уязвимых для специфических атак на отказ в обслуживании.
• SlowPost.pl (аналог для SlowLoris HTTP DoS Tool) - небольшой скрипт, позволяющий провести атаку на протокол HTTP через POST-запросы к веб-серверу, с целью вызвать отказ в обслуживании (исчерпав максимальное количество подключений к серверу). Более подробное описание данной атаки представлено на странице SlowLoris HTTP DoS . Аналогичный способ Application Flood для протокола HTTP через POST-запросы с использованием облачных вычислений был представлен Дэвидом Брайеном и Михаилом Андерсоном на хакерской конференции Defcon 18 . Они реализовали функционал распределенной системы Application Flood’а для протокола HTTP, но, к сожалению, практический результат в виде «отказа в обслуживании» реального сервера (парнями был использован для презентации один из веб-серверов Defcon’а) не был получен, хотя задумка в теории действительно должна была отлично работать. К такой заминке могло привести либо недостаточно эффективное осуществление Application Flood, либо недостаточное количество атакующих серверов. В разработке скрипта SlowPost.pl основной качественной характеристикой являлось эффективное осуществление Application Flood. В итоге, скрипт позволяет создать и поддерживать одновременно более 900 подключений к атакуемому веб-серверу с одной атакующий машины. Такие характеристики позволяют с помощью всего одной атакующей машины обеспечить атаку на «отказ в обслуживании» для большинства веб-серверов, работающих под управлением веб-сервера Apache. Ведь директива MaxClients по умолчанию равна 256: веб-сервер обеспечивает возможность работы только с 256 пользователям одновременно. Веб-сервер IIS (Windows 2003 Server), в отличие от Apache, использует значение по умолчанию, равное приблизительно 20 000.

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

Технические характеристики запускаемого Instance, выступающего в роли атакующего звена, представляют собой следующее:

• система x86/x64 (1 CPU);
• 613 Мб ОЗУ;
• 10 Гб HDD.

Технические характеристики Instance были выбраны минимальными в силу того, что для реализации атаки на «отказ в обслуживании» приоритет отдается количеству атакующих машин, а не их вычислительным характеристикам. Каждый Instance снабжен каналом с пропускной способностью 100 Mb/s, поэтому проблем в скорости передачи данных до атакуемого сервера теоретически быть не должно.

В первую очередь было очень интересно увидеть реальную мощность предполагаемого «ботнета» на облачных технологиях. Для теста был выбран сценарий упомянутого Брайена Андерсона, представляющий из себя реализацию атаки на «отказ в обслуживании» для HTTP-сервера.

Как было выяснено, связка 1 «Instance» + скрипт SlowPost.pl позволяет эмулировать более чем 900 клиентов веб-сервера. Таким образом, этой связки достаточно, чтобы вывести из строя любой веб-сервер, поддерживающий максимальное число подключений менее чем 900. Бюджет, необходимый для реализации такой атаки сводится к минимуму за счет потребления лишь компьютерного времени, а не ресурсов и трафика. Себестоимость атаки для таких веб-серверов - меньше 7 рублей в час! (см. таблицу 4)

При тестировании в реальных условиях мишенью выступал веб-сайт, обслуживаемый сервером IIS. Балансировка нагрузки была разделена на два IP-адреса. Таким образом, чтобы положить этот сервер, потребовалось создать более чем 20 000 подключений к каждому из IP-адресов. Настройки атакуемого веб-сервера были установлены по умолчанию. В итоге, для обеспечения всех условий для удачной атаки «отказ в обслуживании» было запущено 46 «Instance», каждый из которых эмулировал одновременную работу 900 пользователей. Кстати, обычным пользователям Amazon позволяется работать одновременно только с 20 «Instance». Чтобы полностью пройти путь плохого парня, задумавшего DDoS-атаку, мы просто зарегистрировали три различных аккаунта. Кроме этого, для регистрации нам понадобилось три сим-карты. Естественно, были куплены анонимные карты с балансами 300 рублей - причем абсолютно легально. К каждой сим-карте была приобретена карта оплаты (Prepaid Card For Internet Shopping) с балансами $5 - карта необходима при регистрации на площадке Amazon и верификации. В итоге, бюджет для атаки «отказ в обслуживании» на веб-сайт достаточно крупной компании составил всего 1150 рублей. Детальная стоимость представлена в таблице 5.

Атака проводилась в отношении веб-сервера на протяжении двух часов, чего вполне достаточно для ощутимых потерь в сфере интернет-бизнеса.

Трояны в Instance

Удобство облачных сервисов заключается также в гибкости выбора ОС и ее компонентов через приятный веб-интерфейс. Пользователь может использовать как стандартные решения, предоставленные провайдером, так и образы ОС, созданные пользователями провайдера. Например, сервис от Амазон очень активно использует данную систему. Именно в ней и кроится опасность - провайдер не гарантирует того, что образы систем, предоставленные пользователями для общего использования, не выполняют никаких скрытых действий: например, не ведут логи, не копируют личную информацию, не становятся частью ботнета, не распространяют вредоносное ПО. Проведенные тесты показали, что многие пользователи действительно не следят за такими вещами.

Для проведения теста потребовалось:

• создать образ популярной ОС в формате AMI и выложить его в открытый доступ в интерфейс Амазона;
• составить хорошее описание настроенной системы (установленный софт, полезные «плюшки» и т.д.);

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

Abuse-практика

Теоретически, оперативное реагирование на жалобы должно быть правилом для любого провайдера. В реальности же все обстоит несколько иначе. Проведя небольшое исследование, было выявлено, что даже серьезные провайдеры облачных сервисов (например, Amazon), не спешат реагировать на abuse и расследовать инциденты. Фактически, дело не заходит дальше учета сообщений об инцидентах. Во-первых, чтобы инцидент был рассмотрен провайдером, необходимо предоставить, помимо IP-адреса атакующего, точную дату и время атаки. После предоставления необходимой информации о злоумышленнике, переписка с провайдером будет продолжаться. Но это будет односторонняя переписка: провайдер с радостью выслушает ответы на интересующие его вопросы, но вот на твои - не ответит, за редким исключением, любезно игнорируя.

Что делать в случаях атак

При первом обращении к провайдеру, служба безопасности просит предоставить следующую информацию:

• IP-адрес атакующего;
• IP-адрес жертвы;
• атакуемый порт и протокол, по которому происходила атака;
• точную дату, время и временную зону жертвы;
• логи с машины жертвы, подтверждающие факт атаки (не более 4 Кб);
• контактные данные.

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

Заключение

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

Что следует знать вашей организации о безопасности в облачной среде

Общие сведения

Один из ведущих аналитиков компании Gartner назвал облачные вычисления «фразой дня». Любой, кто хоть сколько-нибудь времени занимается информационными технологиями (ИТ), знает, что эта фраза, по-видимому, будет актуальна и в ближайшем будущем. Действительно, по прогнозам компании Gartner, объем рынка облачных вычислений к концу 2013 года достигнет 150 миллиардов долларов. Компания Merrill Lynch также прогнозирует взрывной рост объема рынка до 160 миллиардов долларов к 2013 году.

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

Рисунок 1. Схема облачной среды

Организации ожидают от облачной технологии даже экономии на кадрах. Передавая ИТ-услуги на аутсорсинг облачным провайдерам, организации получают возможность высвободить ИТ-специалистов, чтобы они могли заниматься исключительно проектами, направленными на продвижение бизнеса, вместо того чтобы тратить время на поддержку сервисов, управление которыми могут взять на себя облачные провайдеры.

Учитывая все эти возможности сокращения затрат, трудно понять, почему организации порой с такой неохотой перемещают в облако свои данные, программное обеспечение и другие сервисы, - но лишь до тех пор, пока вы не вспомните о рисках с точки зрения безопасности, с которыми сопряжено такое перемещение. Согласно результатам большинства опросов, именно безопасность является основной причиной, по которой руководители по ИТ не решаются начать движение в сторону облачных решений. Один из недавних опросов на портале LinkedIn показал, что у 54% из 7053 респондентов проблема безопасности вызывает наибольшую озабоченность, когда речь заходит о миграции в облако.

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

В данной статье кратко охарактеризованы некоторые из наиболее распространенных рисков с точки зрения безопасности, связанных с облачными вычислениями, а также приведены шаги, которые может предпринять ваша организация для уменьшения этих рисков.

Совместно используемые технологические ресурсы

Облачные среды можно разделить на четыре категории в соответствии с четырьмя моделями развертывания, перечисленными и описанными в .

Таблица 1. Модели развертывания облачных сред

В моделях частного и коллективного облаков, а также, в некоторой степени, в гибридной модели множество разных заказчиков совместно используют ресурсы с помощью виртуализации. Такая платформа вычислений имеет следующие потенциально слабые стороны:

• Обмен данными между разными виртуальными машинами или между виртуальной машиной и хостом с применением совместно используемых дисков, виртуальных коммутаторов или виртуальных локальных сетей (VLAN) и совместно используемой подсистемы ввода-вывода или кэша.
• Стандартные драйверы, эмулирующие аппаратные средства.
• Уязвимости в гипервизоре, которые позволяют выполнять произвольный код на хосте с привилегиями гипервизора, что дает злоумышленнику возможность осуществлять управление всеми виртуальными машинами и самим хостом.
• Руткиты на виртуальных машинах, позволяющие вносить изменения в системные вызовы гипервизора к операционной системе хоста для выполнения вредоносного кода.
• Уязвимость, известная под названием «побег из виртуальной машины» , когда программе на одной виртуальной машине предоставляется неограниченный доступ к хосту через совместно используемые ресурсы.
• Атаки типа «отказ в обслуживании» на одну виртуальную машину, которые выводят из строя другие виртуальные машины, работающие на том же хосте.

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

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

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

Потеря и утечка данных

В своей статье «Data Leakage Prevention and Cloud Computing» («Предотвращение утечки данных и облачные вычисления») компания KPMG LLP утверждает: «Как только данные оказываются в общедоступном облаке, развернутые в вашей организации средства предотвращения утечки данных (DLP) обесцениваются, поскольку уже не могут помочь в защите конфиденциальности этих данных. При этом ваша организация не имеет возможности прямого контроля над конфиденциальностью своих данных в общедоступном облаке ни в модели предоставления услуг «программное обеспечение как сервис» (SaaS), ни в модели предоставления услуг «платформа как сервис (PaaS)». Ссылка на полный текст статьи приведена в разделе .

Что можно предпринять для предотвращения утечки данных в облаке в ситуации, когда закон США от 1996 года о преемственности и подотчетности медицинского страхования (HIPAA) и стандарт защиты информации в индустрии платежных карт (PCI DSS) требуют от организаций серьезного подхода к обеспечению защиты данных?

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

Между тем ключом к успеху в предотвращении утечки данных является «упрочнение» систем, которые хранят и транспортируют данные.

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

Еще одной мерой для того, чтобы ваша организация соответствовала требованиям стандарта PCI DSS, является наличие должным образом сконфигурированного межсетевого экрана Web-приложений для защиты последних от разнообразных атак. Прежде чем принимать решение в пользу какого-либо поставщика услуг SaaS, отдел ИТ вашей организации должен оценить имеющийся уровень защиты Web-приложений. Если это разрешено, следует провести испытание проникновением, чтобы проверить защиту от несанкционированного доступа всех используемых вашей компанией приложений.

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

Незащищенные интерфейсы API

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

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

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

Для преодоления перечисленных рисков требуется главным образом рассмотрение и анализ модели безопасности поставщика облака с целью удостовериться в том, что поставщик делает все необходимое для защиты таких интерфейсов API.

Ваша организация должна внимательно изучить средства аутентификации и доступа и убедиться в том, что при передаче данных используется шифрование. Кроме того, перед заключением любого соглашения вам следует проанализировать цепочку зависимостей и удостовериться в том, что вам известны все интерфейсы API и все предъявляемые ими требования.

Похищение и несанкционированное использование учетных записей

В то время как борьба с большинством рассмотренных уязвимостей ложится главным образом на плечи поставщика облака, бремя борьбы со всем спектром угроз похищения и несанкционированного использования учетных записей и услуг в равных долях разделяется между поставщиком услуг и клиентом.

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

Помимо понимания политик безопасности вашего поставщика облака, ваша организация также должна осуществлять определенный упреждающий мониторинг пользования облачными сервисами для отслеживания несанкционированного доступа и несанкционированной активности.

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

Угрозы со стороны инсайдеров

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

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

Возможность работы с конфиденциальными и финансовыми данными является очень привлекательной для хакеров и корпоративных шпионов. Работа на компанию, которая предоставляет облачные услуги, может позволить такому злоумышленнику наживаться на продаже конфиденциальных данных или получать полный контроль над облачными сервисами с малым риском или вообще без такового.

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

Заключение

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

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