Свои подходы к устранению уязвимостей облачных вычислений. Угрозы безопасности облачных вычислений

К вопросу безопасности облачных вычислений Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Климачев С.А.

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

Похожие книги на litres.ru

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Климачев С.А.

Текст научной работы на тему «К вопросу безопасности облачных вычислений»

МЕЖДУНАРОДНЫЙ НАУЧНЫЙ ЖУРНАЛ «ИННОВАЦИОННАЯ НАУКА» №10-2/2016 ISSN 2410-6070

Оренбургский государственный университет г. Оренбург, Российская Федерация

К ВОПРОСУ БЕЗОПАСНОСТИ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ

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

Облачные вычисления, SaaS, PaaS, IaaS, проблемы безопасности, системы обнаружения

аномалий облачной среды.

Популярность облачных вычислений начала возрастать к 2007-му году. В 2012 году данная концепция стала настоящим трендом в науке и бизнесе. Согласно данным Международной компании IDC и исследованиям Forbes, в 2015 году суммарные затраты организаций на инфраструктуру и услуги, связанные с облачными вычислениями, достигли уровня $200 млрд. Прирост российского рынка в данном сегменте на 2015 год составил более 30% в рублевом эквиваленте [1]. Подобная популярность технологии, прежде всего, обусловлена ее функциональностью, которая предоставляет не только широкие возможности для обработки и хранения данных, но и является способом избежать затратных инвестиций. При этом, по расчетам аналитиков, объем рынка облачных вычислений на данный момент близок к среднему и в ближайшие годы лишь продолжит свой рост. Все это делает актуальным рассмотрение данной технологии, ее достоинств и проблемных мест.

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

Существует три модели предоставления услуг облачных вычислений (SaaS – Software-as-a-Service, PaaS – Platform-as-a-Service, IaaS – Infrastructure-as-a-Service) и четыре модели развертывания (Public Cloud, Private Cloud, Community Cloud, Hybrid Cloud). Вне зависимости от модели облачные вычисления характеризуются рядом общих достоинств: возможностью совместного доступа к ресурсам и услугам, гибкостью управления услугами и возможностью динамического масштабирования ресурсов, удобной системой оплаты используемых сервисов (pay-per-usage model) [2].

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

Нарушение функционирования облака может быть спровоцировано как атаками злоумышленников, так и сбоями облачной инфраструктуры. Согласно исследованиям [3], в 2016 году проблемы безопасности облачных вычислений коснулись 13% российских компаний. При этом около трети из них (32%) столкнулось с потерей данных. Определенные сложности в решение подобных проблем вносит отсутствие единого стандарта безопасности облачных вычислений. В ряде случаев безопасность в облаке достигается за счет контроля третьей стороны, либо реализацией провайдерами облачных сервисов своих собственных стандартов и моделей безопасности.

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

МЕЖДУНАРОДНЫЙ НАУЧНЫЙ ЖУРНАЛ «ИННОВАЦИОННАЯ НАУКА» №10-2/2016 ISSN 2410-6070

(угроза доступа злонамеренных инсайдеров к пользовательским данным, хранимым в облаке; угроза несанкционированного доступа к данным в результате атак внешних нарушителей; угроза компрометации данных в результате человеческого фактора или неисправности аппаратного обеспечения), целостность (недостаточный контроль доступа; предоставление части пользователей в рамках одной инфраструктуры неисправных или неправильно сконфигурированных компонент), доступность (изменение инфраструктуры, повлекшее изменение программно-аппаратной части существующих облачных сервисов; угроза отказа в обслуживании) [4]. Cloud Security Alliance (CSA) в 2016 году определила 12 главных угроз безопасности облачных вычислений. К ним относятся:

– компрометация учетных записей и обход аутентификации;

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

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

– недостаточная осведомленность о возможностях облака;

– злоупотребление облачными сервисами;

– отказ в обслуживании;

– угрозы совместно используемых технологий [5].

Наряду с общими проблемами безопасности для каждой сервисной модели облачных вычислений можно выделить свои проблемные стороны. Например, в модели SaaS внимания заслуживают вопросы, касающиеся безопасности данных, приложений и развертывания, в PaaS – уязвимости хоста и ресурсов.

Статистика угроз и анализ рынка облачных вычислений показывают, что актуальность выработки методов и разработки средств защиты облачной среды (Cloud Environment) очень высока. Однако на сегодняшний день единый механизм и единая модель защиты облака от существующих угроз (аномалий) безопасности отсутствует. Одним из подходов обеспечения безопасности облачной среды можно считать использование распределенных систем мониторинга и обнаружения уязвимостей (аномалий), основанных на принципах иммунной системы человека [6, 7]. Подобные решения характеризуются распределенностью и самоорганизуемостью, что адаптирует их для работы в облачной среде. Однако проблемной стороной в вопросе использования подобных систем для обнаружения аномалий облачной среды и повышения ее защищенности является оценка их эффективности, поскольку многоуровневая структура среды вносит сложности в использование стандартных методов оценки. Таким образом, возникает противоречие между необходимостью комплексного подхода к обеспечению безопасности облачной среды на основе распределенных систем и недостаточностью методической базы для оценки эффективности этих систем. Данное противоречие является следствием проблемных вопросов теории и практики, касающихся безопасности облачных вычислений (рисунок 1).

МЕЖДУНАРОДНЫЙ НАУЧНЫЙ ЖУРНАЛ «ИННОВАЦИОННАЯ НАУКА» №10-2/2016 ISSN 2410-6070

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

1. Облачный провайдинг 2015-2020: экономика, стратегии, бизнес-модели. [Электронный ресурс]. – Режим доступа: http://www.iksmedia.ru/news/ 5331917-Novyj-otchet-iKSConsulting-oblachny.html

2. Grace Lewis, Basics About Cloud Computing. Software Engineering Institute, Carnegie Mellon University [Электронный ресурс]. – Режим доступа: http://resources.sei.cmu.edu/library/asset-view.cfm?assetro=28873

3. Kaspersky Lab. Новости об угрозах [Электронный ресурс]. – Режим доступа: http://www.kaspersky.ru/about/news/virus/2016/Kaspersky-Lab-about-company-clowd-incidents

4. Security and Privacy Issues in Cloud Computing. Jaydip Sen [Электронный ресурс]. – Режим доступа: https://arxiv.org/ftp/arxiv/papers/1303/ 1303.4814.pdf

5. Cloud Security Alliance. The Treacherous 12 – Cloud Computing Top Threats in 2016 [Электронный ресурс]. – Режим доступа: https://cloudsecurityalliance.org/download/the-treacherous-twelvecloud-computing-top-threats-in-2016/

6. Соловьев Н.А. Мультиагентная иммунная система обнаружения аномалий облачной среды / Соловьев Н.А., Тишина Н.А., Чернопрудова Е.Н.//Безопасность информационных технологий, 2015.- №4.- С.92-97.

7. Маликов А.Ю. Разработка архитектуры облачной мультиагентной системы обнаружения вторжений // T-Comm: Телекоммуникации и транспорт. – 2015. – Том 9. – №8. – С.38-42

© Климачев С.А., 2016

к.ф.-м.н., старший научный сотрудник ФГБУН Институт теплофизики им. С.С. Кутателадзе СО РАН

В.В. Кузнецов д.ф.-м.н., заведующий отделом ФГБУН Институт теплофизики им. С.С. Кутателадзе СО РАН г. Новосибирск, Российская Федерация

СТАТИСТИЧЕСКИЕ ХАРАКТЕРИСТИКИ ВОСХОДЯЩЕГО ГАЗОЖИДКОСТНОГО ТЕЧЕНИЯ В

КАНАЛЕ КОМПАКТНОГО ТЕПЛООБМЕННИКА

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

Миниканал, газожидкостное течение, метод двухлучевого лазерного сканирования.

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

Безопасность в облаках. Изучаем безопасность облачных сервисов на примере инфраструктуры Яндекса

Содержание статьи

Сказка — ложь, да в ней намек

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

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

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

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

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

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

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

Подсчет расходов и подведение итогов привели руководство компании к неутешительным выводам: прав был тот админ, который с самого начала предлагал воспользоваться облачной моделью IaaS — «инфраструктура как сервис». Что же касается безопасности таких платформ, то об этом стоит поговорить отдельно. И сделаем мы это на примере самого популярного из подобных сервисов — Яндекс.Облака.

Безопасность в Яндекс.Облаке

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

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

Физический уровень

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

Кроме того, аппаратные средства Облака физически отделены от «большого Яндекса»: они расположены в разных стойках, но в точности так же проходят регулярное регламентное обслуживание и замену комплектующих. На границе этих двух инфраструктур используются аппаратные файрволы, а внутри Облака — программный Host-based Firewall. Кроме того, на коммутаторах Top-of-the-rack применяется система управления доступом ACL (Access Control List), что значительно повышает безопасность всей инфраструктуры.
Яндекс на постоянной основе проводит сканирование Облака извне в поисках открытых портов и ошибок в конфигурации, благодаря чему потенциальную уязвимость можно распознать и ликвидировать заранее. Для работающих с ресурсами Облака сотрудников реализована централизованная система аутентификации по ключам SSH с ролевой моделью доступа, а все сессии администраторов логируются. Такой подход является частью повсеместно применяемой Яндексом модели Secure by default: безопасность закладывается в IT-инфраструктуру еще на этапе ее проектирования и разработки, а не добавляется потом, когда все уже запущено в эксплуатацию.

Инфраструктурный уровень

На уровне «аппаратно-программной логики» в Яндекс.Облаке используются три инфраструктурных сервиса: Compute Cloud, Virtual Private Cloud и Yandex Managed Services. А теперь о каждом из них чуть подробнее.

Compute Cloud

Этот сервис предоставляет масштабируемые вычислительные мощности для различных задач, таких как размещение веб-проектов и высоконагруженных сервисов, тестирование и прототипирование или временная миграция IT-инфраструктуры на период ремонта либо замены собственного оборудования. Управлять сервисом можно через консоль, командную строку (CLI), SDK или API.

Безопасность Compute Cloud базируется на том, что все клиентские виртуальные машины используют минимум два ядра, а при распределении памяти не применяется overcommitment. Поскольку в этом случае на ядре исполняется только клиентский код, система не подвержена уязвимостям вроде L1TF, Spectre и Meltdown или атакам на побочные каналы.

Кроме того, Яндекс использует собственную сборку Qemu/KVM, в которой отключено все лишнее, оставлен только минимальный набор кода и библиотек, необходимых для работы гипервизоров. При этом процессы запускаются под контролем инструментария на базе AppArmor, который с использованием политик безопасности определяет, к каким системным ресурсам и с какими привилегиями может получить доступ то или иное приложение. AppArmor, работающий поверх каждой виртуальной машины, уменьшает риск того, что клиентское приложение сможет получить доступ из ВМ к гипервизору. Для получения и обработки логов Яндекс выстроил процесс поставки данных от AppArmor и песочниц в собственный Splunk.

Virtual Private Cloud

Сервис Virtual Private Cloud позволяет создавать облачные сети, используемые для передачи информации между различными ресурсами и их связи с интернетом. Физически этот сервис поддерживается тремя независимыми ЦОД. В этой среде логическая изоляция осуществляется на уровне многопротокольного взаимодействия — MPLS. При этом Яндекс постоянно проводит fuzzing стыка SDN и гипервизора, то есть со стороны виртуальных машин во внешнюю среду непрерывно направляется поток неправильно сформированных пакетов с целью получить отклик от SDN, проанализировать его и закрыть возможные бреши в конфигурации. Защита от DDoS-атак при создании виртуальных машин включается автоматически.

Yandex Managed Services

Yandex Managed Services — это программное окружение для управления различными сервисами: СУБД, кластерами Kubernetes, виртуальными серверами в инфраструктуре Яндекс.Облака. Здесь большую часть работы по обеспечению безопасности сервис берет на себя. Все резервное копирование, шифрование резервных копий, Vulnerability management и так далее обеспечивается автоматически программными средствами Яндекс.Облака.

Инструменты реагирования на инциденты

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

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

И последнее, но не самое маловажное пожелание заключалось в том, чтобы все инструменты имели открытый исходный код. Этим критериям полностью соответствует связка AppArmor + Osquery, которую и решено было использовать в Яндекс.Облаке.

AppArmor

AppArmor уже упоминался выше: это программный инструмент упреждающей защиты, основанный на настраиваемых профилях безопасности. Профили используют технологию разграничения доступа на основании меток конфиденциальности Mandatory Access Control (MAC), реализуемую с помощью LSM непосредственно в самом ядре Linux начиная с версии 2.6. Разработчики Яндекса остановили свой выбор на AppArmor по следующим соображениям:

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

Osquery

Osquery — это инструмент мониторинга безопасности системы, разработанный компанией Facebook, сейчас он успешно применяется во многих IT-отраслях. При этом инструмент кросс-платформенный и имеет открытый исходный код.

С помощью Osquery можно собирать информацию о состоянии различных компонентов операционной системы, аккумулировать ее, трансформировать в стандартизированный формат JSON и направлять выбранному получателю. Этот инструмент позволяет писать и направлять приложению стандартные SQL-запросы, которые сохраняются в базе данных rocksdb. Можно настроить периодичность и условия выполнения или обработки этих запросов.

В стандартных таблицах уже реализовано много возможностей, например можно получить список запущенных в системе процессов, установленных пакетов, текущий набор правил iptables, сущности crontab и прочее. «Из коробки» реализована поддержка получения и парсинга событий из системы аудита ядра (используется в Яндекс.Облаке для обработки событий AppArmor).

Сам Osquery написан на C++ и распространяется с открытыми исходниками, можно их модифицировать и как добавлять новые таблицы в основную кодовую базу, так и создавать свои расширения на C, Go или Python.

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

Выводы

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

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

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

Проблемы безопасности облачных вычислений.
Анализ методов защиты облаков от Сloud Security Alliance

Авторы: Бердник А.В.
Источник: Альманах современной науки и образования. Тамбов: Грамота, 2013. № 10 (77). C. 35-38. ISSN 1993-5552.
URL: http://scjournal.ru/articles/issn_1993-5552_2013_10_09.pdf

Резюме

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

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

В настоящее время на рынке представлен широкий спектр решений для защиты серверов и ЦОД от различных угроз. Их объединяет ориентированность на узкий спектр решаемых задач [1]. Однако он подвергся некоторому расширению вследствие постепенного вытеснения классических аппаратных систем виртуальными платформами. К известным типам угроз (сетевые атаки, уязвимости в приложениях операционных систем, вредоносное программное обеспечение) добавились сложности, связанные с контролем среды (гипервизора), трафика между гостевыми машинами и разграничением прав доступа. Расширились внутренние вопросы и политики защиты ЦОД, требования внешних регуляторов. Работа современных ЦОД в ряде отраслей требует закрытия технических вопросов, а также вопросов, связанных с их безопасностью. Финансовые институты (банки, процессинговые центры) подчинены ряду стандартов, выполнение которых заложено на уровне технических решений. Проникновение платформ виртуализации достигло того уровня, когда практически все компании, использующие эти системы, весьма серьезно занялись вопросами усиления безопасности в них. Отметим, что буквально год назад интерес был скорее теоретический [3; 8]. В современных условиях становится все сложнее обеспечить защиту критически важных для бизнеса систем и приложений [1].

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

Существующие угрозы облачных вычислений

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

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

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

Трудности при перемещении обычных серверов в вычислительное облако

Требования к безопасности облачных вычислений не отличаются от требований безопасности к центрам обработки данных. Однако виртуализация ЦОД и переход к облачным средам приводят к появлению новых угроз.

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

Динамичность виртуальных машин

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

Уязвимости внутри виртуальной среды

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

Защита бездействующих виртуальных машин

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

Защита периметра и разграничение сети

При использовании облачных вычислений периметр сети размывается или исчезает. Это приводит к тому, что защита менее защищенной части сети определяет общий уровень защищенности. Для разграничения сегментов с разными уровнями доверия в облаке виртуальные машины должны сами обеспечивать себя защитой, перемещая сетевой периметр к самой виртуальной машине (Рис. 1). Корпоративный firewall — основной компонент для внедрения политики IT-безопасности и разграничения сегментов сети — не в состоянии повлиять на серверы, размещенные в облачных средах [4].

Рис. 1. Схема работы механизма разграничения доступа [7]

Атаки на облака и решения по их устранению

Традиционные атаки на ПО

Уязвимости операционных систем, модульных компонентов, сетевых протоколов — традиционные угрозы, для защиты от которых достаточно установить межсетевой экран, firewall, антивирус, систему предотвращения вторжений (Intrusion Prevention System — IPS) и другие компоненты. При этом важно, чтобы данные средства защиты эффективно работали в условиях виртуализации.

Функциональные атаки на элементы облака

Этот тип атак связан с многослойностью облака, общим принципом безопасности. В статье об опасности облаков было предложено следующее решение [4]: для защиты от функциональных атак для каждой части облака необходимо использовать следующие средства защиты: для прокси — эффективную защиту от DoSатак, для веб-сервера — контроль целостности страниц, для сервера приложений — экран уровня приложений, для СУБД — защиту от SQL-инъекций, для системы хранения данных — правильные бэкапы (резервное копирование), разграничение доступа. В отдельности каждые из этих защитных механизмов уже созданы, но они не собраны вместе для комплексной защиты облака, поэтому задачу по интеграции их в единую систему нужно решать во время создания облака.

Атаки на клиента

Большинство пользователей подключаются к облаку, используя браузер. Здесь рассматриваются такие атаки как Cross Site Scripting, угон паролей, перехваты веб-сессий, человек посредине и многие другие. На текущий момент, наиболее эффективной защитой от данного вида атак является правильная аутентификация и использование шифрованного соединения (SSL) с взаимной аутентификацией [5]. Однако данные средства защиты не очень удобны и очень расточительны для создателей облаков. В этой отрасли информационной безопасности есть еще множество нерешенных задач.

Атаки на гипервизор

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

Атаки на системы управления

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

Решения по защите от угроз безопасности от компании Cloud Security Alliance (CSA)

Наиболее эффективные способы защиты в области безопасности облаков опубликовала организация Cloud Security Alliance (CSA). Проанализировав опубликованную компанией информацию, были предложены следующие решения [6]:

Сохранность данных. Шифрование

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

Защита данных при передаче

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

Аутентификация — защита паролем. Для обеспечения более высокой надежности часто прибегают к таким средствам как токены и сертификаты. Для прозрачного взаимодействия провайдера с системой идентификации при авторизации также рекомендуется использовать LDAP (Lightweight Directory Access Protocol) и SAML (Security Assertion Markup Language).

Использование индивидуальной виртуальной машины и виртуальной сети. Виртуальные сети должны быть развернуты с применением таких технологий как VPN (Virtual Private Network), VLAN (Virtual Local Area Network) и VPLS (Virtual Private LAN Service). Часто провайдеры изолируют информацию пользователей друг от друга за счет изменения кода в единой программной среде. Такой подход имеет риски, связанные с опасностью найти дыру в нестандартном коде и получить доступ к данным пользователей. В случае возможной ошибки в коде один пользователь может получить данные другого пользователя.

Заключение

Описанные решения по защите от угроз безопасности облачных вычислений неоднократно были применены системными интеграторами в проектах построения частных облаков. Практические применения и требования по безопасности подробно описаны в тезисах [1; 2]. После применения данных решений количествослучившихся инцидентов существенно снизилось. Но многие проблемы, связанные с защитой виртуализации, до сих пор требуют тщательного анализа и проработанного решения.