Защита информации в облачной инфраструктуре

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение

высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

Факультет Телекоммуникаций и радиотехники

Направление (специальность) Информационная безопасность телекоммуникационных систем

Кафедра Мультисервисных сетей и информационной безопасности

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

(ДИПЛОМНАЯ РАБОТА)

Защита информации в облачной инфраструктуре

Руководитель доцент к.т.н А.С. Раков

Н. контролер доцент к.т.н Н.М. Бельская

Разработал ИБТС-11 К.А.Жигалов

Самара 2017



Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение

высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

ЗАДАНИЕ

по подготовке выпускной квалификационной работы

Утверждена приказом по университету от 28.10.2016 265-2

2 Срок сдачи студентом законченной ВКР 28.01.17

3 Исходные данные и постановка задачи

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

2) Ознакомиться с open source проектами и выбрать оптимальный для реализации облачной инфраструктуры

3) Развернуть облачную инфраструктуру на основе выбранного open source проекта

4) Произвести необходимые настройки для повышения уровня информационной безопасности облачной инфраструктуры

5) Сделать вывод о целесообразности и возможности реализации достаточного уровня информационной безопасности в облачной инфраструктуре



Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение

высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

ПОКАЗАТЕЛИ КАЧЕСТВА ВКР

1 Работа выполнена :
- по теме, предложенной студентом
- по заявке предприятия	V	ООО «Регистратор доменных имён РЕГ.РУ»
		наименование предприятия
- в области фундаментальных и поисковых научных исследований
		указать область исследований
2 Результаты ВКР:
- рекомендованы к опубликованию
		указать где
- рекомендованы к внедрению
		указать где
- внедрены	V	в ООО «Регистратор доменных имён РЕГ.РУ»
		акт внедрения
3 ВКР имеет практическую ценность	V	Облачная инфраструктура, настроенная для использования
		в чем заключается практическая ценность
4 Использование ЭВМ при выполнении ВКР:
(ПО, компьютерное моделирование, компьютерная обработка данных и др.)
5. ВКР прошла проверку на объем заимствований		% заимствований (ФИО, подпись)
		эл. версия сдана (ФИО, подпись)



Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение

высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

РЕФЕРАТ

Название	Защита информации в облачной инфраструктуре
Автор	Жагалов Константин Андреевич
Научный руководитель	Раков Александр Сергеевич
Ключевые слова	Облачная инфраструктура, ОС Linux, Opennebula, IDS/IPS Suricata, угрозы облачной инфраструктуры, auditd, iptables.
Дата публикации	2017
Библиографическое описание	Жигалов, К.А. Обеспечение безопасности облачной инфраструктуры. [Текст]: дипломная работа / К.А. Жигалов. Поволжский государственный университет телекоммуникаций и информатики (ПГУТИ). Факультет телекоммуникаций и радиотехники (ФТР). Кафедра Мультисервисных сетей и информационной безопасности: науч. рук. А.С. Раков - Самара. 2017. - 78 с.
Аннотация	В дипломной работе рассматривается создание защищённой облачной инфраструктуры на основе программного обеспечения с открытом исходным кодом и операционной системы Linux. Произведена настройка облачной инфраструктуры Opennebula и реализована её защита от актуальных угроз безопасности облачных систем.

Руководитель ВКР ____________ _____________ А.С. Раков



Содержание

• Задание
• Отзыв руководителя
• Показатели качества ВКР
• Рецензия
• Реферат
• Введение
• 1. Облачные технологии
• 1.1 История и ключевые факторы развития облаков
• 1.2 Развитие облаков в XXI веке
• 1.3 Модели обслуживания пользователей в облаке
• 1.4 Типы облаков
• 1.5 Информационная безопасность облачной инфраструктуры
• 2. Практическая реализация облачной инфраструктуры
• 2.1 Выбор open source проекта, для его дальнейшего внедрения
• 2.2 Инфраструктура облачной платформы Opennebula
• 2.3 Установка облачной платформы Opennebula на ОС Linux
• 3. Обеспечение информационной безопасности облачной инфраструктуры
• 3.1 Определение границ защищаемой инфраструктуры
• 3.2 Настройка RAID массива
• 3.3 Настройка шифрования дисков и отдельных каталогов
• 3.4 Настройка аутентификации и списков доступа
• 3.5 Написание правил Linux файрвола Iptables
• 3.6 Настройка OpenVPN сервера
• 3.7 Настройка системы аудита auditd
• 3.8 Настройка IPS/IDS Suricata
• 3.9 Рекомендации и оптимальные методы для защиты гипервизор
• 3.10 Защита от DDoS-aтак
• Заключение

Список использованных источников

• Приложения



Введение

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

Поиск решения проблем с эффективностью использования вычислительных ресурсов привели к появлению систем виртуализации и популяризации облачных вычислений. Первыми сервер виртуализации представили инженеры компании VMware. Им стал всем хорошо известный гипервизор VMware ESX, который положил начало в развитии таких гипервизоров как Xen, KVM, QEMU, Hyper-V и т.д.

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

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

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

Все вышесказанное определило актуальность темы работы - защита информации в облачной инфраструктуре.

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

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

1) изучить модели и типы облачных сервисов;

2) ознакомиться с open source проектами и выбрать оптимальный для реализации облачной инфраструктуры;

3) развернуть облачную инфраструктуру на основе выбранного open source проекта;

4) произвести необходимые настройки для обеспечения безопасности облачной инфраструктуры;

5) сделать вывод о целесообразности и возможности реализации достаточного уровня информационной безопасности в облачной инфраструктуре;

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

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

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

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



1. Облачные технологии

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

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

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

1) grid--вычисления -- это координирующая система, которая при помощи различных протоколов и интерфейсов соединяет несколько вычислительных машин для выполнения большого объёма операций;

2) utility computing -- пользователь заказывает у провайдера хранение большого массива данных или выполнение сложных вычислений;

3) active Server Pages (ASP) -- технология, позволяющая создавать веб-приложения, разработана компанией Microsoft;

4) open source software -- программы, имеющие доступный для просмотра, изучения и модернизации исходный код, что позволяет всем желающим поучаствовать в развитии программы;

5) web 2.0 -- данным термином принято обозначать проекты и сервисы, которые активно развиваются и модернизируются самими пользователям (социальные сети, вики-проекты, блоги).

1.2 Развитие облаков в XXI веке

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

Одним из первых облачных сервисов на рынке интернет-услуг стала CRM-система запущенная в 1999 году компанией Salesforce, доступ к которой пользователи могли получить на сайте компании salesforce.com. По факту Salesforce первые реализовали свой сервис по принципу SaaS (программное обеспечение как услуга).

В 2002 году уже компания Amazon начала осваивать рынок облачных сервисов, после того как специалисты данной компании посчитали, что в ночное время, когда вычислительные мощности простаивают ввиду отсутствия нагрузки их можно предоставлять пользователям. Таким образом появилось первое публичное облачное хранилище. На этом проекты компании Amazon в области облачных технологий не закончились и благодаря популярности их первого проекта. В 2006 году Amazon разработала и запустила облачный сервис Elastic Compute Сloud (EC2), в котором пользователи получали в распоряжение не только хостинг для хранения данных, но и вычислительные мощности серверов, принадлежащих Amazon. Таким образом, сервисы Amazon EC2 и Amazon S3 стали первыми сервисами облачных вычислений на рынке интернет услуг.

Основываясь на удачном примере внедрения облаков от компании Amazon, гиганты интернет индустрии, такие как Google, IBM, SUN, Microsoft и другие, также запустили множество проектов связанных с облачными технологиями.

В наше время облачные инфраструктуры базируются в огромных дата-центрах, которые включают в себя тысячи серверов. Эти дата-центры способны обеспечить вычислительной мощностью миллионы приложений пользователей [11]. По данным прогноза аналитической компании Forrester Research мировой рынок облачных технологий к 2020 году достигнет объема в 241 млрд. долларов (рис. 1.1). Стоит заметить, что среднегодовой прирост на рынке облачных вычислений и услуг составляет уже более 25%.

Рис. 1.1 - Объем мирового рынка облачных технологий, млрд. долларов

1.3 Модели обслуживания пользователей в облаке

В настоящее время на рынке интернет-услуг присутствует большое множество моделей обслуживания:

1) Данные как услуга (Data as a Service) - предоставление пользователю пространства на жестком диске, для хранения личной информации.

2) Рабочее место как услуга (Workplace as a Service) - компания создает образ виртуальной машины с уже настроенными для использования программами и выдает его сотрудникам в качестве уже готового к работе рабочего места.

3) Безопасность как услуга (Security as a Service) - позволяет пользователям разворачивать приложения, для обеспечения безопасности веб-сервисов, операционной системы или деловой переписки.

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

Рис. 1.2 - Модели обслуживания пользователей в облаке

Услуги приложений (Software as a Service - SaaS) данная модель обслуживания позволяет пользователям использовать разработанное провайдером приложение как сервис, которое расположено в облаке [1]. При таком способе предоставления услуг, провайдер полностью берёт на себя ответственность за обновление, лицензирование и устранение ошибок в предоставляемой им услуге. Пользователь должен позаботиться только о защите доступов (логин, пароль). Доступ к приложениям осуществляется посредством веб-браузера, электронной почты или интерфейса программ.

Данная модель обслуживания наиболее знакома пользователям сети интернет. Хорошим примером приложений данного типа являются почтовые сервисы, такие как: Mail.ru, Яндекс почта, Gmail.

Преимущества:

1) Снижение затрат на аппаратное обеспечение;

2) Уменьшение затрат на разработку приложений;

3) Полная поддержка приложения со стороны провайдера, т.е. обновление, тестирование и устранение ошибок.

Недостатки:

1) Клиент должен быть уверен в добропорядочности поставщика услуг;

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

Платформа как услуга (Platform as a Service - PaaS) - при данной модели обслуживания, пользователь получает готовую платформу для размещения своего программного обеспечения и разработки приложений, которые будут работать внутри облака [1]. Модель обслуживания PaaS по сути предлагает то же, что и IaaS. Однако заказчику нет необходимости настраивать платформу под себя, он получает уже готовую среду для разработки и развертывания своих проектов, что порождает следующие преимущества и недостатки.

Преимущества:

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

2) Упрощенная разработка кросс-платформенных приложений;

3) Экономия на использовании продвинутых средств;

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

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

Недостатки:

1) Привязка к поставщику услуг. При разработке программных средств в среде PaaS тонкости и логика работы приложений переплетаются с логикой работы облачной инфраструктуры, что может привести к сложностям при переносе приложения к другому поставщику услуг;

2) Сложность. У каждого поставщика услуг PaaS, свой набор функций и логика работы среды проектирования;

3) Необходимость приобретать новые навыки. Девелоперы будут вынуждены изучать новую среду разработки.

Примеры услуг: Google App, Windows Azure, Amazon Web Services, IBM и другие.

Инфраструктура как услуга (Infrastructure as a Service - IaaS) - это облачная инфраструктура, в которой пользователь получает ресурсы для личного использования вроде хранилищ данных, операционных систем, серверов, и сетевых ресурсов расположенных в облаке [1]. В результате чего, пользователю при необходимости увеличения мощности нет необходимости покупать стойку в дата-центре, физический сервер или программное обеспечение, он может заказать всё это уже в готовом к работе состоянии у своего провайдера облачного сервиса. IaaS поддерживает гораздо большее число пользователей по сравнению с другими моделями обслуживания. Хорошим примеров IaaS является аппаратное обеспечение как услуга (Hardware as a Service - HaaS). Заказчик в качестве услуги получает физическое оборудование, на основе которого он может построить свою собственную инфраструктуру с желаемым программным обеспечением. Пользователь при такой модели обслуживания не управляет аппаратной частью инфраструктуры облака, он имеет контроль лишь над системами хранения данных, операционными системами, приложениями запущенными в облаке, иногда предоставляется возможность управления сетевой инфраструктурой (например, сетевые экраны).

Преимущества:

1) Стоимость. Значительное снижение затрат на аппаратное обеспечение.

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

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

Недостатки:

1) Доступ в интернет. Сложно назвать это минусом в XXI веке, однако некоторые пользователи до сих пор имеют нестабильный доступ к сети интернет или маленькую скорость, что может значительно затруднить их работу с облачной инфраструктурой.

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

3) Отключения. SLA предоставляемый провайдером облачной инфраструктуры зачастую не удовлетворяет потребности заказчика и приводит к колоссальным убыткам для малого бизнеса.

4) Управление мобильными устройствами: Проблема безопасности при использовании пользователями мобильных устройств для работы в облаке.

Примеры крупных компаний, которые предоставляют IaaS высокого качества: IT-GRAD, Amazon Web Services CSC, Microsoft, IBM и другие.

1.4 Типы облаков

1.4.1 Частные облака

Частные облака - это облачная инфраструктура, расположенная внутри корпоративной сети, в которой размещены внутренние сервисы и службы компании доступные для использования только её сотрудникам [1].

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

Плюсы частного облака:

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

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

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

4) Оперативность. Значительно возрастает оперативность обработки задач IT-отделом, так как для выполнения большинства задач, специалистам достаточно развернуть нужный образ виртуальной машины и произвести минимальные настройки, что занимает порядка 15-30 минут при должной квалификации администраторов облака.

Недостатки.

5) Увеличиваются расходы на внедрение, поддержание и настройку инфраструктуры.

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

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

1.4.2 Публичные облака

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

Плюсы публичного облака.

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

2) Масштабируемость. Зачастую поставщики используют модель оплаты pay-as-you-go, которая подразумевает оплату по факту использования вычислительной мощности.

3) Доступ. Для доступа к сервисам достаточно стабильного интернет соединения.

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

Минусы публичного облака.

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

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

3) Слабая защищенность данных - самый главный минус публичной среды. Защита частного облака всегда будет на уровень выше публичного.

Рис. 1.3 - Различия публичного и приватного облака

1.4.3 Гибридные облака

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

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

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

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

1.5 Информационная безопасность облачной инфраструктуры

Контроль над процессами, происходящими в облаке, и управление ими является главной задачей, которую необходимо решить специалистам информационной безопасности предприятия для успешного использования облачных сервисов. Обеспечение информационной безопасности облачной инфраструктуры в первую очередь стоит начинать с определения границ сетевого периметра, который обязательно должен включать в себя системы аудита, межсетевые экраны, антивирусное программное обеспечение, системы обнаружения и предотвращения вторжений(IDS/IPS). Также стоит сосредоточиться на выборе подходящего центра обработки данных, в котором будут размещаться серверы и убедиться в должном уровне обеспечения физической защиты дата-центра, а также в контроле допуска инженеров к физическому оборудованию [2].

Для минимизации рисков информационной безопасности в облачной инфраструктуре необходимо определить ключевые угрозы безопасности. Управление рисками ИБ представляет собой непрерывный процесс, который необходимо выполнять постоянно. В мае 2016 года на конференции RSA, лидер в области стандартов, рекомендаций и инициатив, некоммерческая компания Cloud Security Alliance (далее - RSA) представила доклад, который содержит список из двенадцати наиболее критических угроз безопасности облачной инфраструктуры. В данном докладе также описаны рекомендации, выполнение которых позволяет снизить риски информационной безопасности и значительно повысить уровень защищенности облачной инфраструктуры предприятия. Рассмотрим каждую из этих угроз более подробно.

1) Утечка данных

Облачная инфраструктура подвержена тем же угрозам, что и традиционные инфраструктуры без использования виртуализации. Большой объём данных, которые размещаются в облаке, облачные инфраструктуры являются привлекательной целью для злоумышленников. Облачные провайдеры стараются не предавать огласке взломы их инфраструктуры, так как это может привести к штрафам, потери имиджа или даже уголовным делам. Поэтому так важно обеспечивать контроль и защиту данных от утечки. Cloud Security Alliance для защиты от данного вида угроз рекомендуют использовать многофакторную аутентификацию и шифрование. В 2014 - 2015 годах было зафиксировано несколько инцидентов нарушения безопасности в результате халатного отношения компаний к данному виду угроз [2].

Например в антивирусной компании BitDefender, из-за уязвимости в публичном облаке произошла утечка данных, в результате которой было скомпрометировано большое количество учетных записей пользователей(точное количество не разглашается). Злоумышленники требовали выкуп в размере 15 000$ [2].

Британский телекоммуникационный провайдер TalkTalk сообщил о нескольких инцидентах безопасности в 2014 - 2015 годах, которые привели к краже персональных данных более чем четырех миллионов клиентов. Компания подверглась широкой критике за отсутствие шифрования клиентских данных [2].

2) Взлом учетных записей и обход аутентификации

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

От данного вида угроз в 2015 году пострадала компания Anthem Insurance, результатом взлома которой стало хищение более 81 миллиона логинов и паролей пользователей. Эксперты оценили данную атаку в 10 баллов по степени критичности [2].

3) Взлом облачных интерфейсов

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

Cloud Security Alliance рекомендует внедрять и использовать инструменты защиты и раннего обнаружения угроз, такие как IPS/IDS системы. Кроме того, CSA рекомендует уделять особое внимание проверки безопасности кода и запускать программу “bug bounty” [2].

4) Уязвимость используемых систем

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

5) Фишинг и мошенничество

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

6) Инсайдеры-злоумышленники

Сотрудники компании, которые были уволены или считают что их способности не в достаточном объеме оплачиваются руководством. Могут стать хорошей целью для вербовки недобросовестными конкурентами. Угроза раскрытия конфиденциальной информации компании может исходить от сотрудников любого подразделения, особое внимание стоит уделять сотрудникам имеющим доступ к критически важным данным и настройкам инфраструктуры. Это такие сотрудники как системные администраторы, подрядчики или даже партнеры по бизнесу. Инсайдеры могут руководствоваться разными убеждениями, начиная от кражи данных с целью дальнейшей их перепродажи на черном рынке или банальное желание обратить на себя внимание. CSA рекомендует не забывать про шифрование и не доверять контроль над ключами шифрования непроверенным сотрудникам. Также следует использоваться системы логирования, мониторинг и аудита событий по конкретным учетным записям сотрудников компании [2].

7) Кибер-атака

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

8) Потеря данных без возможности восстановления

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

9) Перемещение сервисов в облачную инфраструктуру

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

10) Злоупотребление облачными сервисами

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

11) DDoS-атаки

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

12) Общая уязвимость технологии

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



2. Практическая реализация облачной инфраструктуры

2.1 Выбор open source проекта, для его дальнейшего внедрения

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

Opennebula является open source проектом, позволяющим развернуть IaaS на уже имеющихся физических серверах. Она позволяет использовать разные гипервизоры на одном кластере это KVM, XEN и VMware. Также реализован интерфейс для взаимодействия с Amazon EC2, поддерживается API -- EC2 Query, vCloud, OGF OCCI, и свой. Благодаря модульной архитектуре Opennebula легко интегрируется с платформами виртуализации и хранилищами данных. Присутствует поддержка технологии Live Migration, которая позволяет переносить виртуальные машины пользователей без их отключения. Ядро Opennebula написано на С++, утилиты управления -- на Ruby и shell [3].

2.2 Инфраструктура Opennebula

Инфраструктура Opennebula состоит из трех компонентов: системы хранения данных, сети и виртуализации. Таким образом, основными компонентами системы являются:

1) Frontend c помощью которого управляют инфраструктурой Opennebula;

2) Гипервизор-хосты, которые обеспечивают ресурсы, необходимые виртуальным машинам;

3) Хранилища данных, на которых хранятся базовые образы виртуальных машин;

4) Физические сети, которые используются для поддержания основных услуг, таких как объединение серверов хранения данных со средой Opennebula и VLAN для виртуальных машин [3].

Рис. 2.1 - Инфраструктура Opennebula

Frontend включает в себя систему мониторинга, которая собирает информацию о состоянии виртуальных машин, потреблении ими вычислительной мощности. Эта информация собирается путем выполнения комплекса статических преобразований средой Opennebula по следующим правилам: каждый узел периодически посылает данные мониторинга на Frontend, который обрабатывает сведения в специальном модуле collected. Данная модель мониторинга отличается высокой масштабируемостью и её предел (по количеству виртуальных машин для мониторинга), ограничен производительностью сервера (Frontend), на котором работает Opennebula и сервером базы данных. Обмен данными между управляющей машиной и узлами облачного кластера осуществляется по протоколу SSH[3].

Рис. 2.2 - Сбор информации о состоянии сервисов облачной инфраструктуры

Opennebula поддерживает несколько гипервизоров для управления виртуальными машинами - KVM, XEN и VMware. При установке по умолчанию Opennebula будет использовать KVM.

Подсистема хранения образов дисков поддерживает несколько хранилищ SAN и NAS. Образы виртуальных машин доступны с любого узла, доступ осуществляется по протоколам SSH, NFS, SFTP, HTTP, GlusterFS, Lustre, iSCSI/LVM [3].

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

Поддерживается ряд сетевых технологий: dummy, iptables, ebtables, Open vSwitch, 802.1Q VLAN и VMware.

Рис. 2.3 - Варианты аутентификации

На (рис. 2.3) представлены три модели аутентификации, которые можно реализовать в среде Opennebula.

1) Аутентификация в CLI/API-интерфейсе;

На выбор доступно несколько драйверов аутентификации для доступа к среде Opennebula из командной строки:

a) Аутентификация по паролю и токену;

b) SSH аутентификация;

c) X509 аутентификация;

d) LDAP аутентификация.

2) Аутентификация в графическом интерфейсе Sunstone;

По умолчанию любой драйвер аутентификации настроен на работу со средой Opennebula. Кроме того можно настроить аутентификацию по SSL.

3) Серверная аутентификация

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

Для администрирования физических и виртуальных систем в Opennebula созданы специальные демоны (начинающиеся на one* - onevm, oneuser, onehost и т.п.) и веб-интерфейс Sunstone. Возможности данного интерфейса позволяют создавать виртуальные машины и подключаться к ним по VNC. Также настроены специальные пункты для управления сетями, образами виртуальных машин, файловыми хранилищами, настройка прав доступа пользователей и система мониторинга. Для мониторинга работы серверов в веб-интерфейс интегрирована система Ganglia. Кроме того, существует возможность расширения возможностей Opennebula при помощи различных модулей и дополнений, которые доступны на официальном сайте разработчиков Opennebula [3].

2.3 Установка облачной платформы Opennebula на ОС Linux

В рамках данной работы установка будет производиться на два сервера, но их может быть сколько угодно. На всех серверах установлена ОС Linux Centos 7 (рис. 2.4).

Рис. 2.4 - Проверка версии операционной системы



2.3.1 Установка и настройка Frontend сервера

Frontend сервер имеет следующую конфигурацию:

1) Диски: 2 x SATA объёмом 2TB объединены в RAID 1

2) Процессор: Intel Xeon E5620

3) Оперативная память: 64GB DDR3

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

Рис. 2.5 - Добавления репозитория Opennebula

Установка EPEL репозитория (рис. 2.6).

Рис. 2.6 - Установка epel репозитория

После того как мы подключили репозиторий с необходимыми пакетами Opennebula, можно приступить к установке всех необходимых для работы Frontend демонов (рис. 2.7).

Рис. 2.7 - Установка пакетов Opennebula

После установки мы получаем несколько компонентов для управления:

1) Opennebula: интерфейс командной строки;

2) Opennebula-server: главный демон Opennebula;

3) Opennebula-sunstone: графический интерфейс Sunstone и EC2 API;

4) Opennebula-ruby: Ruby Bindings;

5) Opennebula-java: Java Bindings;

6) Opennebula-gate: OneGate сервер, который обеспечивает связь между виртуальными машинами и средой Opennebula;

7) Opennebula-flow: OneFlow демон для управления услугами;

8) Opennebula-node-kvm: Meta-package, который настраивает oneadmin пользователей, в libvirt и KVM;

9) Opennebula-common: общие файлы для среды Opennebula.

Для корректной работы некоторых сервисов в облачной среде Opennebula требуются библиотеки Ruby. Разработчики Opennebula написали скрипт, который устанавливает все необходимые Ruby пакеты, запускаем его при помощи команды представленной на (рис. 2.8).

Рис. 2.8 - Установка пакетов ruby

Для корректной работы, также потребуется установить базу данных MySQL. Так как в CentOS 7 MySQL заменён на MariaDB произведем установку именно этой СУБД и добавим необходимого пользователя (рис. 2.9).

Рис. 2.9 - Добавление пользователя к базе данных

Перед запуском Opennebula необходимо сконфигурировать подключение к базе данных в файле oned.conf (рис. 2.10).

Рис. 2.10 - Настройка подключения к базе данных

Перед первым запуском всех служб Opennebula необходимо изменить пароль для подключения к веб-интерфейсу Sunstone (рис. 2.11).

Рис. 2.11 - Изменение пароля, для подключения к Sunstone

Мы установили всё необходимое программное обеспечение для запуска Opennebula, произведём запуск облачно инфраструктуры (рис. 2.12).

Рис. 2.12 - Запуск облачной инфраструктуры

Теперь мы можем проверить работу веб-интерфейса Sunstone и Frontend сервера. Для этого нам потребуется открыть в браузере страницу http://37.140.195.166:9869 (рис. 2.13).

Рис. 2.13 - Web-интерфейс входа в панель управления Sunstone

37.140.195.166 - это IP адрес Frontend сервера, а 9869 TCP порт, который использует Sunstone по умолчанию. Для авторизации в панели управления, мы должны использовать логин и пароль, который указали в файле /var/lib/one/.one/one_auth, т.е. Login: “oneadmin” и Password: “aeGe9Faihuam”. Вводим данные на странице авторизации и попадаем в панель управления Opennebula.

Рис. 2.14 - Внутренний web-интерфейс Sunstone



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

облачный сервис ddos aтака

Рис 2.15 Интерфейс обычного пользователя

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

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

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

1) Диски: 2 x SSD объёмом 480Gb объединены в RAID 1

2) Процессор: Intel Xeon E5620

3) Оперативная память: 64Gb DDR3

4) ОC: Centos 7

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

Рис. 2.16 - Проверка работы аппаратной виртуализации

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

Подключаем репозиторий Opennebula аналогично тому, как мы делали на Frontend сервере (рис. 2.17).

Рис. 2.17 - Подключение репозитория Opennebula

Теперь выполним команду для установки необходимого программного обеспечения (рис. 2.18).

Рис. 2.18 - Установка программного обеспечения

После установки необходимо перезапустить демон libvirtd (рис. 2.19). Libvirt это утилита для управления виртуализацией, написанная на языке Ruby, Python и C++. Без данного демона управление гипервизорами XEN и KVM будет невозможно.

Рис. 2.19 - Перезапускт демона libvirtd

Так как Frontend сервер Opennebula взаимодействует с нодами по протоколу SSH, необходимо добавить открытый ключ oneadmin пользователей со всех машин в /var/lib/one/.ssh/authorized_keys на все сервера. Существует множество способов для передачи ключей на другой сервер, мы будем использовать протокол защищенной передачи файлов scp, который устанавливает защищенное соединение между хостами перед передачей файлов. Также нам потребуется добавить hostname всех серверов в файл /var/lib/one/.ssh/known_hosts и скопировать данный файл на все сервера (рис. 2.20).

Рис. 2.20 - Добавления hostname в файл knows_hosts

Теперь можно скопировать файл /var/lib/one/.ssh на все сервера (рис. 2.21).

Рис. 2.21 - Копирование hostname на все сервера

Проверим, что произведенные настройки работают корректно, попробуем подключиться с Frontend на сервер для виртуальных машин (рис 2.22).

Рис. 2.22 - Проверка корректности настройки SSH между серверами

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

Открываем web-интерфейс Sunstone, слева в меню выбираем вкладку Infrastructure -> Hosts и нажимаем на иконку, указанную на (рис. 2.23).

Рис. 2.23 - Создание нового хоста

Заполняем имя узла в поле “Hostname” (рис. 2.24).

Рис. 2.24 - Обозначение имени узла при создание нового Host

И наконец возвращаемся к списку хостов и проверяем что подключённый сервер находится в состоянии ON (рис. 2.25).

Рис. 2.25 - Проверка состояния node2

После того как мы успешно подключили Host к Frontend серверу и проверили что всё работает корректно, можно приступить к созданию первой виртуальной машины. Переходим в раздел Templates -> VMs, затем выбираем образ виртуальной машины ttylinux-kvm и нажимаем “Instantiate” (рис. 2.26).

Рис. 2.26 - Создание виртуальной машины

В появившемся диалоговом окне настраиваем параметры виртуальной машины и нажимаем на кнопку “Instantiate” (рис. 2.27).

Рис. 2.27 - Настройка параметров виртуальной машины

После описанные выше действия виртуальная машина готова к работе и мы можем подключиться к ней по протоколу VNC (рис. 2.28).

Рис. 2.28 - Проверка состояния виртуальной машины



Мы увидим монитор виртуальной машины и сможем удаленно передавать ей команды управления (рис. 2.29).

Рис. 2.29 - Графический интерфейс VNC



3. Обеспечение информационной безопасности облачной инфраструктуры

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