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

Курсовая работа по дисциплине Программно-аппаратные средства обеспечения информационной безопасности

" Информационная безопасность в облачных вычислениях: уязвимости, методы и средства защиты, инструменты для проведения аудита и расследования инцидентов. «

• Введение
• 1. История и ключевые факторы развития
• 2. Определение облачных вычислений
• 3. Референтная архитектура
• 4. Соглашение об уровне сервиса
• 5. Методы и средства защиты в облачных вычислениях
• 6. Безопасность облачных моделей
• 7. Аудит безопасности
• 8. Расследование инцидентов и криминалистика в облачных вычислениях
• 9. Модель угроз
• 10. Международные и отечественные стандарты
• 11. Территориальная принадлежность данных
• 12. Государственные стандарты
• 13. Средства обеспечения защиты в облачных технологиях
• 14. Практическая часть
• Вывод
• Литература

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

Uptime системы достигает 99,9% что также позволяет сэкономить на вычислительных ресурсах. И что еще важно — практически неограниченные возможности по масштабируемости. Приобретая обычный хостинг и попытавшись прыгнуть выше головы (при резком всплеске нагрузки) есть риск получить упавший на несколько часов сервис. В облаке дополнительные ресурсы предоставляются по первому запросу.

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

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

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

1. История и ключевые факторы развития

Впервые идея того, что мы сегодня называем облачными вычислениями была озвучена J. C. R. Licklider, в 1970 году. В эти годы он был ответственным за создание ARPANET (Advanced Research Projects Agency Network). Его идея заключалась в том, что каждый человек на земле будет подключен к сети, из которой он будет получать не только данные, но и программы. Другой ученый John McCarthy высказал идею о том, что вычислительные мощности будут предоставляться пользователям как услуга (сервис). На этом развитие облачных технологий было приостановлено до 90-х годов, после чего ее развитию поспособствовал ряд факторов.

1. Расширение пропускной способности Интернета, в 90-е годы не позволило получить значительного скачка в развитии в облачной технологии, так как практически ни одна компания и технологии того времени не были готовы к этому. Однако сам факт ускорения Интернета дал толчок скорейшему развитию облачных вычислений.

2. Одним из наиболее значимых событий в данной области было появление Salesforce.com в 1999 году. Данная компания стала первой компанией предоставившей доступ к своему приложению через сайт. По сути данная компания стала первой компанией предоставившей свое программное обеспечение по принципу — программное обеспечение как сервис (SaaS).

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

4. В 2006, Amazon запустила сервис под названием Elastic Compute cloud (EC2), как веб-сервис который позволял его пользователям запускать свои собственные приложения. Сервисы Amazon EC2 и Amazon S3 стали первыми доступными сервисами облачных вычислений.

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

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

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

2. Определение облачных вычислений

Согласно определению Национального института стандартов и технологий CША:

Облачные вычисления (Cloud computing) (англ. Cloud - облако; computing — вычисления) — это модель предоставления повсеместного и удобного сетевого доступа по мере необходимости к общему пулу конфигурируемых вычислительных ресурсов (например, сетей, серверов, систем хранения, приложений и сервисов), которые могут быть быстро предоставлены и освобождены с минимальными усилиями по управлению и необходимостью взаимодействия с провайдером услуг (сервис-провайдером).

Облачная модель поддерживает высокую доступность сервисов и описывается пятью основными характеристиками (essential characteristics), тремя сервисными моделями/моделями предоставления услуг (service models) и четырьмя моделями развертывания (deployment models).

Программы запускаются и выдают результаты работы в окно стандартного веб-браузера на локальном ПК, при этом все приложения и их данные, необходимые для работы, находятся на удаленном сервере в интернете. Компьютеры, осуществляющие cloud computing, называются «вычислительным облаком». При этом нагрузка между компьютерами, входящими в «вычислительное облако», распределяется автоматически. Простейшим примером cloud computing являются p2p-сети.

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

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

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

Для особо крупных и ресурсоёмких вычислений используются грид-вычисления.

Грид-вычисления (grid - решётка, сеть) — это форма распределённых вычислений, в которой «виртуальный суперкомпьютер» представлен в виде кластеров соединённых с помощью сети, слабосвязанных, гетерогенных компьютеров, работающих вместе для выполнения огромного количества заданий (операций, работ).

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

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

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

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

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

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

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

Модели облачных служб

Варианты предоставления вычислительных мощностей сильно отличаются. Все, что касается Cloud Computing, обычно принято называть словом aaS, — расшифровывается просто — «as a Service», то есть «как сервис», или «в виде сервиса» .

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

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

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

Рис. 1 Типовая схема SaaS

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

Рис. 2 Типовая схема PaaS

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

Рис. 3 Типовая схема IaaS

Дополнительно выделяют такие сервисы, как:

Коммуникации как услуга (Com-aaS) — подразумевается, что в качестве сервисов предоставляются услуги связи; обычно это IP-телефония, почта и мгновенные коммуникации (чаты, IM).

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

Рабочее место как услуга (WaaS) — пользователь, имея в своём распоряжении недостаточно мощный компьютер, может купить у поставщика вычислительные ресурсы и использовать свой ПК как терминал, для доступа к услуге.

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

Модели развёртывания

Среди моделей развёртывания выделяют 4 основных вида инфраструктуры

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

Рис. 4 Частное облако.

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

Рис. 5 Публичное облако.

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

Рис. 6 Гибридное облако.

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

Рис. 7 Описание свойств облаков

Основные свойства

NIST в своем документе `The NIST Definition of Cloud Computing` определяет следующие характеристики облаков:

Самообслуживание по требованию (On-demand self-service). У потребителя есть возможность получить доступ к предоставляемым вычислительным ресурсам в одностороннем порядке по мере потребности, автоматически, без необходимости взаимодействия с сотрудниками каждого поставщика услуг.

Широкий сетевой доступ (Broad network access). Предоставляемые вычислительные ресурсы доступны по сети через стандартные механизмы для различных платформ, тонких и толстых клиентов (мобильных телефонов, планшетов, ноутбуков, рабочих станций и т. п.).

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

Мгновенная эластичность (Rapid elasticity). Ресурсы могут быть эластично выделены и освобождены, в некоторых случаях автоматически, для быстрого масштабирования соразмерно со спросом. Для потребителя возможности предоставления ресурсов видятся как неограниченные, то есть они могут быть присвоены в любом количестве и в любое время.

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

Рис. 8 Структурная схема облачного сервера

Достоинства и недостатки облачных вычислений

Достоинства

· снижаются требования к вычислительной мощности ПК (непременным условием является только наличие доступа в интернет);

· отказоустойчивость;

· безопасность;

· высокая скорость обработки данных;

· снижение затрат на аппаратное и программное обеспечение, на обслуживание и электроэнергию;

· экономия дискового пространства (и данные, и программы хранятся в интернете).

· Живая миграция — перенос виртуальной машины с одного физического сервера на другой без прекращения работы виртуальной машины и остановки сервисов.

· В конце 2010 года в связи с DDoS атаками против компаний, отказавшихся предоставлять ресурсы WikiLeaks, выяснилось еще одно преимущество технологии cloud computing. Атакованы были все компании, выступившие против WikiLeaks, но только Amazon оказалась нечувствительна к этим воздействиям, так как использовала средства cloud computing. («Anonymous: serious threat or mere annoyance», Network Security, N1, 2011).

Недостатки

· зависимость сохранности пользовательских данных от компаний, предоставляющих услугу cloud computing;

· постоянное соединение с сетью — для получения доступа к услугам «облака» необходимо постоянное соединение с сетью Интернет. Однако в наше время это не такой и большой недостаток особенно с приходом технологий сотовой связи 3G и 4G.

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

· конфиденциальность — конфиденциальность данных хранимых на публичных «облаках» в настоящее вызывает много споров, но в большинстве случаев эксперты сходятся в том, что не рекомендуется хранить наиболее ценные для компании документы на публичном «облаке», так как в настоящее время нет технологии которая бы гарантировала 100% конфиденциальность хранимых данных. Именно поэтому применение шифрования в облаке — обязательно.

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

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

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

3. Референтная архитектура

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

Рис. 9 Концептуальная схема референтной архитектуры

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

Облачные Потребители разбиваются на 3 группы:

SaaS — использует приложения для автоматизации бизнес-процессов.

PaaS — разрабатывает, тестирует, развертывает и управляет приложениями, развернутыми в облачном окружении.

IaaS — создаёт, управляет сервисами ИТ-инфраструктуры.

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

SaaS — устанавливает, управляет, сопровождает и обеспечивает ПО, развернутое на облачной инфраструктуре.

PaaS — предоставляет и управляет облачной инфраструктурой и связующим ПО. Предоставляет инструменты разработки и администрирования.

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

Деятельность Облачных Провайдеров делится на основные 5 типовых действий:

• Развёртывание сервисов:

o Частное облако — обслуживается одна организация. Инфраструктура управляется как самой организацией, так и третьей стороной и может быть развёрнута как у Провайдера (off premise), так и у организации (on premise).

o Общее облако — инфраструктура используется совместно несколькими организациями со схожими требованиями (безопасность, соответствие РД).

o Публичное облако — инфраструктура используется большим количеством организаций с разными требованиями. Только off premise.

o Гибридное облако — инфраструктура объединяет различные инфраструктуры по принципу схожих технологий.

• Управление сервисами

o Уровень сервиса — определяет базовые сервисы, предоставляемые Провайдером.

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

§ PaaS — контейнеры для приложений Потребителя, средства разработки и администрирования.

§ IaaS — вычислительные мощности, базы данных, фундаментальные ресурсы, поверх которых Потребитель развёртывает свою инфраструктуру.

o Уровень абстракции и контроля ресурсов

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

o Уровень физических ресурсов

§ Компьютерное оборудование

§ Инженерная инфраструктура

• Безопасность

o Аутентификация и авторизация

o Доступность

o Конфиденциальность

o Идентефикация

o Мониторинг безопасности и обработка инцидентов

o Политики безопасности

• Приватность

o Защита обработки, хранения и передачи персональных данных.

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

• Может давать собственную оценку безопасности, приватности, производительности и прочего в соответствии с утвержденными документами.

Рис. 10 Деятельность Провайдера

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

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

o Сервисное посредничество — расширение заданного сервиса и предоставление новых возможностей

o Агрегирование — объединение различных сервисов для предоставление Потребителю

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

• Предоставляет доступ через устройства связи

• Обеспечивает уровень соединения, согласно SLA.

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

Ввод акторов обусловлен необходимостью проработки взаимоотношений между субъектами.

4. Соглашение об уровне сервиса

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

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

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

PDD (Post Dial Delay) — параметр, определяющий период времени (в секундах), прошедший с момента вызова до момента установления телефонного соединения.

Коэффициент доступности Услуги — отношение времени перерыва в предоставлении услуг к общему времени, когда услуга должна предоставляться.

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

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

Достоверность передачи информации — отношение количества ошибочно переданных пакетов данных к общему числу переданных пакетов данных.

Периоды проведения работ, время оповещения абонентов и время восстановления сервисов.

Иными словами, доступность услуги 99,99% говорит о том, что оператор гарантирует не более 4,3 минут простоя связи в месяц, 99,9% - что услуга может не оказываться 43,2 минуты, а 99% - что перерыв может длиться более 7 часов. В некоторых практиках встречается разграничение доступности сети и предполагается меньшее значение параметра — в нерабочее время. На разные типы услуг (классы трафика) также предусмотрены разные значения показателей. Например, для голоса важнее всего показатель задержки — он должен быть минимальным. А скорость для него нужна невысокая, плюс часть пакетов можно терять без потери качества (примерно до 1% в зависимости от кодека). Для передачи данных на первое место выходит скорость, и потери пакетов должны стремиться к нулю.

5. Методы и средства защиты в облачных вычислениях

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

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

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

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

6. Безопасность облачных моделей

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

Рис. 11. Наиболее актуальные угрозы ИБ

SaaS

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

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

PaaS

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

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

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

IaaS

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

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

Если это перевести на язык методов защиты, то провайдер должен обеспечить:

· надежный контроль доступа к самой инфраструктуре;

· отказоустойчивость инфраструктуры.

При этом потребитель облака берет на себя намного больше функций по защите:

· межсетевое экранирование в рамках инфраструктуры;

· защиту от вторжений в сеть;

· защиту операционных систем и баз данных (контроль доступа, защита от уязвимостей, контроль настроек безопасности);

· защиту конечных приложений (антивирусная защита, контроль доступа).

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

Таблица 1. Разграничение ответственности за обеспечение безопасности между клиентом и поставщиком услуги. (П — поставщик, К — клиент)

7. Аудит безопасности

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

Он состоит из:

инициирование процедуры аудита;

сбор информации аудита;

анализ данных аудита;

выработку рекомендаций;

подготовку аудиторского отчета.

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

В целом аудитор проводит аудит для определения надежности

системы виртуализации, гипервизора;

серверов;

хранилищ данных;

сетевого оборудования.

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

При использовании модели PaaS дополнительно должны быть проверены

операционная система,

связующее ПО,

среда выполнения.

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

системы хранения и обработки данных,

приложения.

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

8. Расследование инцидентов и криминалистика в облачных вычислениях

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

Расследование инцидентов (включая расследование преступлений в информационной сфере) — хорошо известный раздел информационной безопасности. Целями таких расследований обычно являются:

Доказательство, что преступление / инцидент произошли

Восстановление события, окружающие инцидент

Идентификация правонарушителей

Доказательство причастности и ответственности правонарушителей

Доказательство нечестных намерений со стороны правонарушителей.

Новая дисциплина — компьютерно-техническая экспертиза (или форензика) появилась, в виду необходимости криминалистического анализа цифровых систем. Цели компьютерно-техническая экспертиза как правило таковы:

Восстановление данных, которые, возможно, были удалены

Восстановление событий произошедших внутри и вовне цифровых систем, связанных с инцидентом

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

Обнаружение присутствия вирусов и другого вредоносного программного обеспечения

Обнаружение присутствия незаконных материалов и программ

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

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

людях использовавших устройство в определенный момент

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

данных, хранившихся, созданных и обработанных устройством в определенное время.

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

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

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

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

9. Модель угроз

В 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 сервисы попали в чёрные списки, а их пользователи полностью игнорировались почтовыми серверами.

Рекомендации по устранению:

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

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

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

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

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

IaaS

PaaS

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

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

Описание:

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

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

Примеры:

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

Рекомендации по устранению:

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

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

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

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

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

IaaS

PaaS

SaaS

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

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

Описание:

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

Примеры:

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

Рекомендации по устранению:

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

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

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

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

IaaS

PaaS

SaaS

Рис. 12 Пример внутреннего нарушителя

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

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

Описание:

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

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

Примеры:

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

Рекомендации по устранению:

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

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

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

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

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

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

IaaS

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

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

Описание:

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

Примеры:

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

Рекомендации по устранению:

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

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

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

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

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

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

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

IaaS

PaaS

SaaS

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

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

Описание:

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

Примеры:

Использование украденных данных для рассылки спама.

Рекомендации по устранению:

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

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

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

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

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

IaaS

PaaS

SaaS

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

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

Описание:

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

Примеры:

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

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

Рекомендации по устранению:

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

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

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

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

IaaS

PaaS

SaaS

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

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

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

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

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

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

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

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

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

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