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

3.1 Определение границ защищаемой инфраструктуры

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

Рис. 3.1 - Уровни облачной инфраструктуры

3.2 Настройка RAID массива

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

Рис. 3.2 - устройство RAID 1 массива

3.3 Настройка шифрования дисков и отдельных каталогов

В операционной системе Linux есть несколько методов для шифрования дисков при помощи разных криптографических алгоритмов. Все данные при использовании данного метода шифруются и расшифровываются на лету. Мы будем использовать блочное шифрование на уровне устройства, так как этот метод в отличии от шифрования на уровне файловой системы не позволяет узнать какую-либо информацию о хранящихся внутри зашифрованного тома данных. Используемая нами система LUKS/dm-crypt для шифрования защищена от Watermark-атаки, которая позволяет определить какого типа информация хранится в зашифрованном томе. LUKS/dm-crypt может использовать различные алгоритмы шифрования, такие как, например, AES-256, Serpent или Twofish [6].

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

Рис. 3.3 - Установка пакета cryptsetup-luks

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

Рис. 3.4 - Создание шифрованного раздела



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

Рис. 3.5 - Предупреждение системы об удаление данных

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

Рис. 3.6 - Открытие зашифрованного Luks раздела

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

Рис. 3.7 - Информация о зашифрованном каталоге



Для удаления остаточной информации в разделе, который мы будем в дальнейшем использовать для хранения бэкапов, перезапишем его нулями. Это можно сделать при помощи стандартной Linux утилиты “dd” (рис. 3.8).

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

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

Рис. 3.9 - Форматирование в файловую систему ext4

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

Рис. 3.10 - Примонтирование каталога

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

Рис. 3.11 Отключение каталога

И выполнить команду представленную на (рис. 3.12) для отключения Luks каталога.

Рис. 3.12 - Отключение Luks устройства

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

3.4 Настройка аутентификации и списков доступа

По умолчанию вход в панель управления Sunstone осуществляется при помощи логина и пароля, что не является хорошо защищенным методом аутентификации. Поэтому нами было принято решение о внедрении более защищенных методов аутентификации в панель управления облаком. Разработчики Opennebula добавили несколько возможностей аутентификации в свою облачную инфраструктуру. Мы выбрали аутентификацию с проверкой подлинности сертификатов x509. Сертификаты x509 в OpenNebula можно использовать двумя различными способами. Первый способ, позволяет использовать сертификаты для подключения к интерфейсу командной строки (Command Line Interface, далее - CLI). В этом случае пользователь генерирует маркер входа в систему с помощью своего закрытого ключа, OpenNebula проверяет сертификат и дешифрует маркер для аутентификации пользователя [3].

Второй способ позволяет использовать сертификаты для подключения к web-интерфейсу Sunstone и серверам Public Cloud, включенных в OpenNebula. В этом случае необходимо установить и настроить web-сервер, который будет выступать в роли HTTPS прокси, и проверять корректность SSL сертификатов, расшифровывать информацию и передавать её Sunstone.

Приступим к настройке web-сервера Nginx как HTTPS прокси. Чтобы установить Nginx достаточно выполнить команду представленную на (рис. 3.13).

Рис. 3.13 - Установка web-сервера Nginx

Теперь необходимо настроить virtualhosts в конфигурационном файле Nginx. Для конфигурирования виртуальных хостов в Nginx необходимо создать отдельный файл в директории /etc/nginx/conf.d/nebula.conf

Создадим данный файл и добавим в него следующие настройки представленные на (рис. 3.14).

Рис. 3.14 - Конфигурирование виртуальных хостов в Nginx



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

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

1) Создать пользователя oneadmin для дальнейшего использования аутентификации на основе сертификатов x509 (рис. 3.15);

Рис. 3.15 - Создание пользователя oneadmin для аутентификации на основе сертификатов x509

2) Изменить способ аутентификации пользователя oneadmin на аутентификацию с применением сертификатов x509 (рис. 3.16);

Рис. 3.16 - Изменение способа аутентификации для пользователя oneadmin

3) Добавить сертификат пользователя oneadmin в директорию сертификатов (рис. 3.17);

Рис. 3.17 - Добавление сертификата пользователя в директорию сертификатов



4) Скорректировать настройки в конфигурационном файле /etc/one/sunstone-server.conf в соответствии с новым методом аутентификации. Для этого изменим значение параметра “:auth: opennebula”, на “:auth: x509” (рис. 3.18).

Рис. 3.18 - Изменения значения “:auth:” в файле sunstone-server.conf

Страница аутентификации в Sunstone больше не будет запрашивать логин и пароль пользователя, так как эта информация будет извлекаться из сертификата пользователя.

Рис. 3.19 - Аутентификации с использованием сертификатов x509

3.5 Написание правил Linux файрвола NetFilter

NetFilter - это межсетевой экран, встроенный в ядро операционной системы Linux. Netfiler управляется при помощи утилиты iptables. Использование данного файрвола необходимо для фильтрации нежелательного трафика. Межсетевой экран NetFilter позволяет предотвращать различные типы вторжений. При написании правил используем подход - разрешить только тот трафик, который будет использоваться, а весь остальной запретить. На (рис. 3.20) представлены некоторые из правил, которые мы использовали на серверах созданной нами облачной инфраструктуры.

Рис. 3.20 - Правила iptables

3.6 Настройка OpenVPN сервера

Так как сервера располагаются за пределами корпоративной сети компании, для обеспечения защищенной передачи данных по сети интернет необходимо настроить VPN соединение, для удаленного подключения к Opennebula и безопасной работы с данными в облаке. В качестве VPN сервера мы будем использовать open source проект - OpenVPN.

OpenVPN - это open source проект для реализации технологии VPN с использование шифрования на основе протоколов SSLv3 и TLSv1.2. Огромным плюсом данного решения является тот факт, что OpenVPN Client доступен для большого числа операционных систем, среди которых Linux, Windows, MacOS, IOS и Android [4].

Устанавливаем OpenVPN сервер (рис. 3.21).

Рис. 3.21 - Установка OpenVPN

Для работы VPN на основе протоколов SSL и TLS потребуется создать соответствующие сертификаты. Создадим директорию для VPN ключей (рис. 3.22).

Рис. 3.22 - Создание директории для ключей

Для создания сертификатов openssl скачаем и установим программу Easy-RSA (рис. 3.23)

Рис. 3.23 - Скачивание программы Easy-RSA

Распаковываем скачанный архив (рис. 3.24)

Рис. 3.24 - Распаковка архива с программой Easy-RSA



Создаем инфраструктуру публичных ключей PKI (рис. 3.25)

Рис. 3.25 - Создание структуры публичных ключей

Теперь создаём удостоверяющий центр (рис. 3.26)

Рис. 3.26 - Создание удостоверяющего сервера

После создания удостоверяющего центра мы получим два ключа:

1) публичный ключ ca.crt, который мы будет отдавать клиентом вместе с пользовательскими сертификатами;

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

Создаём запрос сертификата для нашего Frontend сервера (рис. 3.27)

Рис. 3.27 - Создание запроса сертификата для Frontend сервера

Теперь подпишем запрос на получение сертификата удостоверяющим центром (рис. 3.28)

Рис. 3.28 - Подписание запроса на получение сертификата

В результате мы получим сертификат server.crt, который подписан удостоверяющим центром. Также создадим файл Диффи-Хеллмана, который позволит обеспечить защиту трафика от расшифровки, если ключи будут скомпрометированы. Однако стоит заметить, что будет защищен только тот трафик, который был прослушан и записан до компрометации ключей [4].

Генерируем ключ Диффи-Хеллмана (рис. 3.29)

Рис. 3.29 - Создание ключа Диффи-Хеллмана

Копируем созданные ранее сертификаты в каталог /etc/openvpn (рис. 3.30)

Рис. 3.30 - Копирование сертификатов

Создадим файлы сертификата для клиента VPN сервера (рис. 3.31)

Рис. 3.31 - Создание файлов сертификатов для клиента

В результате мы получим сертификаты клиента, приватный и публичный ключ. Для подключения к OpenVPN серверу клиенту потребуется передать на компьютер клиента три файла: ca.crt (сертификат сервера), client.key (приватный ключ клиента), client.cert (сертификат клиента). Передавать ключи клиенту лучше при помощи внешних носителей, однако серверы облачной инфраструктуры находятся в дата-центре, поэтому мы передадим файлы при помощи защищенного протокола передачи данных - scp.

После создания всех необходимых сертификатов, приступаем к настройке OpenVPN сервера. Создадим и настроим конфигурационный файл Opennebula (рис. 3.32)

Рис. 3.32 - Конфигурационный файл OpenVPN сервера

Запускаем OpenVPN сервер (рис. 3.33)

Рис. 3.33 - Запуск OpenVPN сервера



Если выполнение команды завершилось без ошибок, в Linux появится виртуальный интерфейс tun0 и откроется сокет для подключения клиентов по порту 13555. Проверяем что интерфейс создан (рис. 3.34).

Рис. 3.34 - Проверка интерфейса tun0

Проверим что OpenVPN “слушает” именно порт 13555 (рис. 3.35)

Рис. 3.35 - Проверка корректности настроек OpenVPN

После того как VPN сервер запущен и готов к подключению клиентов приступим к настройке OpenVPN на стороне клиента. Устанавливаем OpenVPN клиент (рис. 3.36)

Рис. 3.36 - Установка OpenVPN на стороне клиента

Создадим конфигурационный файл client.ovpn, который будет использоваться при подключении к VPN серверу (рис. 3.37)

Рис. 3.37 - Конфигурационный файл client.ovpn

Подключаемся к VPN серверу (рис. 3.38).

Рис. 3.38 - Подключение к VPN серверу

Убедимся в корректности настройки VPN подключения, для этого проверим наличие маршрута командой “ip route” и выполним команду “ping” до VPN сервера (рис. 3.39)

Рис. 3.39 - Проверка корректности подключения к VPN серверу



Итак, мы настроили сеть VPN, и сотрудники, работающие удаленно, могут подключиться к облачной инфраструктуре Opennebula с помощью безопасного туннеля с шифрованием трафика. Скорректировав настройки web-сервера nginx мы сможем ограничить доступ к веб-интерфейсу Sunstone, разрешив подключение только с IP-адреса VPN сервера, что позволит обезопасить облачную инфраструктуру от несанкционированного доступа.

3.7 Настройка системы аудита auditd

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

1) инициация сетевых соединений;

2) чтение, запись, изменение файлов или прав доступа к ним;

3) запуск и завершение работы системы;

4) неудачные попытки авторизации;

5) системные вызовы;

6) запуск и остановка приложений.

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

1) task - события связанные с созданием процессов;

2) user - события, которые используют параметры пользовательского пространства, такие как gid, uid;

3) exit - события, связанные с завершением системного вызова;

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

Рис. 3.40 - Схема работы системы аудита auditd

Устанавливаем систему аудита auditd (рис. 3.41).

Рис. 3.41 - Установка auditd

После установки утилиты auditd можно приступать к созданию правил, используемые мною правила представлены в приложении Б.

3.8 Настройка IPS/IDS Suricata

Для обеспечения безопасности и уменьшения рисков от угроз проникновения злоумышленников в защищаемую среду необходимо использовать IDS/IPS системы. Системы обнаружения и предотвращения вторжений способны изучать в пакетах поле данных и осуществлять проверку на уровне приложения по определённым сигнатурам. В рамках данной дипломной работы мы использовали IPS/IDS систему Suricata.

В Suricata режим IPS работает по следующему принципу: IP пакет попадает в файрвол iptables и направляется в очередь NFQUEUE, которая позволяет обрабатывать пакеты на уровне пользователя. Suricata проверяет пакет по заданным правилам и в зависимости от них может применить одно из правил: NF_ACCEPT, NF_DROP и NF_REPEAT. NF_ACCEPT пропускает пакет, NF_DROP отбрасывает, а пакеты помеченные NF_REPEAT будут направлены в начало текущей таблицы iptables и пройдут повторную проверку по всем правилам [5].

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

Suricata не добавлена в стандартный репозиторий Centos 7, поэтому мы будем собирать данную IPS/IDS из исходного кода, для этого потребуется установить все необходимые зависимости (рис. 3.42).

Рис. 3.42 - Установка зависимостей для Suricata

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

Рис. 3.43 - Загрузка дистрибутива

Рис. 3.44 - Распаковка дистрибутива



Устанавливаем Suricata c поддержкой режима NFQUEUE, для работы в режиме IPS (рис. 3.45).

Рис. 3.46 - Установка Suricata

Проверим, что Suricata установлена корректно и режим работы NFQUEUE работает (рис. 3.47).

Рис. 3.47 - Проверка работы модуля NFQUEUE

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

3.9 Рекомендации и оптимальные методы для защиты гипервизора

1) Установка исправлений и обновлений от производителя гипервизора должна выполняться сразу же, как только они станут доступны.

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

3) Ненужные сервисы, такие как буфер обмена или совместное обновление файлов должны быть отключены [9]

4) Необходимо постоянно анализировать лог файлы гипервизора и реагировать на любые признаки взлома [9].

5) Интерфейс управления гипервизором не должен быть доступен из внешней сети.

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

7) Необходимо разделять обязанности системных администраторов таким образом, чтобы за виртуальные машины, настройку сети между ними и управлением данных занимались разные люди [9].

3.10 Защита от DDoS-атак

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

1) IP malformed;

2) TCP SYN flood;

3) SYN-ACK Flood;

4) ACK & PUSH ACK Flood;

5) FIN Flood;

6) ICMP flood;

7) TCP-malformed;

8) SlowLoris;

9) ICMP smurf;

10) HTTP POST flood;

11) HTTP SLOW POST;



Заключение

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

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

Рассмотрев актуальные угрозы безопасности облачной инфраструктуры была произведена установка и настройка программных средств для обеспечения информационной безопасности. Были установлены и настроены такие программные средства как: программное обеспечение для аудита - auditd, система обнаружения и предотвращения вторжений Suricata, система шифрования дисков и каталогов LUKS/dm-crypt, RAID массив для обеспечения целостности данных. Была произведена настройка встроенного в ядро операционной системы Linux файрвола Netfilter. Также установлен и настроен VPN сервер OpenVPN для обеспечения безопасного подключения пользователей и управляющего персонала к облачной инфраструктуре.

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

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



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

1) Cloud Computing Reference Architecture [Электронный ресурс] /NIST. - 2011. - Режим доступа: http://www.nist.gov/ customcf/get_pdf.cfm?pub_id=909505, свободный - Загл. с экрана.

2) The Top Threats to Cloud Computing [Text] / Cloud Security Alliance // RSA conference 2016: conf. - February 29, 2016.

3) OpenNebula 5.2 Documentation [Электронный ресурс] / Официальный сайт Opennebula - Режим доступа: http://docs.opennebula.org/5.2/index.html, свободный. - Загл. с экрана.

4) HOWTO [Электронный ресурс] / Официальный сайт OpenVPN - Режим доступа: https://openvpn.net/index.php/opensource/documentation/ howto.html# install, свободный. - Загл. с экрана.

5) Suricata User Guide [Электронный ресурс] / Официальный сайт Suricata - Режим доступа: http://suricata.readthedocs.io/en/latest/, свободный. - Загл. с экрана.

6) Luks readme page [Электронный ресурс] / Официальный сайт Luks - Режим доступа: https://gitlab.com/cryptsetup/cryptsetup/blob/ master/README.md, свободный. - Загл. с экрана.

7) Пингвин под колпаком: Аудит системных событий в Linux [Электронный ресурс] / Журнал Хакер - режим доступа: https://xakep.ru/ 2011/03/30/54897/#toc11, свободный. - Загл. с экрана.

8) День сурка. Осваиваем сетевую IDS/IPS Suricata [Электронный ресурс] / Журнал Хакер - Режим доступа: https://xakep.ru/2015/06/28/suricata-ids-ips-197/, свободный. - Загл. с экрана.

9) PCI DSS Virtualization Guidelines [Электронный ресурс] /PCI. - Режим доступа: https://www.pcisecuritystandards.org/documents/ Virtualization_InfoSupp_v2.pdf, свободный. - Загл. с экрана.

10) Разработка безопасных облачных приложений [Электронный ресурс] /IBM. - 2016. - Режим доступа: http://www.ibm.com/developerworks/ru/ library/cl-develop-secure-cloud-aware-applications/index.html, свободный - Загл. с экрана.

11) Технологии виртуализации: вчера, сегодня, завтра [Электронный ресурс] /CIT Forum. - 2006. - Режим доступа: http://citforum.ru/operating_systems/ virtualization/, свободный - Загл. с экрана.

Размещено на Allbest.ru