Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/7758| Title: | Модель хмарного захищеного центру обробки даних на базі технології віртуалізації |
| Authors: | Байрак, Анатолій Володимирович Масляков, Олександр Вікторович |
| Keywords: | хмарні обчислення;центр обробки даних (цод);технології віртуалізації;хмарна інфраструктура;захист інформації;інформаційна безпека хмарних систем |
| Issue Date: | 2021 |
| Abstract: | Мета роботи це створення хмарного захищеного ЦОД з використанням технологій віртуалізації |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/7758 |
| Appears in Collections: | 125 Кібербезпека та захист інформації (Безпека інформаційних і комунікаційних систем) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| М_125_Масляков_Байрак.pdf Restricted Access | 2.37 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет електронних технологій і робототехніки
Кафедра робототехнічних і телекомунікаційних систем та кібербезпеки
Пояснювальна записка
до кваліфікаційної роботи
магістра
(освітньо-кваліфікаційний рівень)
на тему: «Модель хмарного захищеного центру обробки даних на базі
технології віртуалізації»
Виконав: студент 2 курсу, групи БІ–001
Спеціальності 125 – «Кібербезпека» ,
(шифр і назва спеціальності)
освітньої програми «Безпека інформаційних
і комунікаційних систем»
(назва освітньої програми)
Масляков О.В.
(прізвище та ініціали)
Керівник Байрак А.В.
(прізвище та ініціали)
Рецензент Сагун А.В.
(прізвище та ініціали)
Черкаси 2021 р.
Форма № Н-9.01
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
(повне найменування вищого навчального закладу)
Факультет електронних технологій і робототехніки _______________________________________
(повна назва)
Кафедра робототехнічних і телекомунікаційних систем та кібербезпеки
(повна назва)
Освітньо-кваліфікаційний рівень магістр
Спеціальність 125 – «Кібербезпека»
Освітня програма Безпека інформаційних і комунікаційних систем
ЗАТВЕРДЖУЮ
Завідувач кафедри д.т.н., проф.
____________ В.В. Палагін
“___” _____________ 2021 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ МАГІСТРА СТУДЕНТУ
Маслякову Олександру Вікторовичу
(прізвище, ім’я, по батькові)
1. Тема роботи «Модель хмарного захищеного центру обробки даних на базі технології
віртуалізації»
керівник роботи Байрак Анатолій Володимирович, асистент кафедри_____ ___________________
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом Черкаського державного технологічного університету від
«21» Вересня2021 року №289-1/01.
2. Строк подання студентом роботи «20» грудня 2021 р.
3. Вихідні дані до роботи Модель хмарного захищеного центру обробки даних на базі технології
віртуалізації
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити)
Вступ, Розділ 1 Структура та задачі хмарних сервісів та центрів обробки даних, Розділ 2
Планування структури хмарного захищеного центру обробки даних на базі технологій
віртуалізації, Розділ 3 Реалізація моделі хмарного захищеного ЦОД, Висновок, Список
використаних джерел, Додатки
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів):
мультимедійна презентація “ Модель хмарного захищеного центру обробки даних на базі технології
віртуалізації ” – 11 слайдів (додається до роботи).
2
6. Консультанти розділів роботи
Підпис, дата
Розділ Прізвище, ініціали та посада консультанта
завдання видав завдання прийняв
7. Дата видачі завдання __________________
КАЛЕНДАРНИЙ ПЛАН
№ Строк виконання
Назва етапів кваліфікаційної роботи магістра Примітка
з/п етапів роботи
1. П ошук і аналіз інформації по заданій темі 23.09.2021-
30.09.2021
2. Н аписання І розділу “ Структура та задачі хмарних 26.10.2021-
сервісів та центрів обробки даних ” 29.10.2021
3. Н аписання ІІ розділу роботи “ Планування 01.11.2021-
структури хмарного захищеного центру обробки 07.11.2021
даних на базі технологій віртуалізації ”
4. Н аписання ІІІ розділу “Реалізація моделі хмарного 08.11.2021-
захищеного ЦОД ” 24.11.2021
5. Н аписання вступу і висновків, складання списку 25.11.2021
літератури
6. О формлення кваліфікаційної роботи магістра 01.12.2021
7. П одання роботи в ЕК 20.12.2021
8. З ахист роботи в ЕК 23.12.2021
Студент __________________Масляков О.В.
(підпис) (прізвище та ініціали)
Керівник роботи ____________Байрак А.В.
(підпис) (прізвище та ініціали)
3
ЗМІСТ
Вступ ..................................................................................................................... 5
Розділ 1. Структура та задачі хмарних сервісів та центрів обробки даних..7
1.1. Поняття, функції та структура ЦОД ..................................................... 7
1.2. Послуги ЦОД та принципи їх вибору .................................................. 9
1.3. Механізми забезпечення захисту інформації хмарних ЦОД ............. 14
1.4. Функціональний профіль захищеності інформації .......................... 16
Розділ 2. Планування структури хмарного захищеного центру обробки
даних на базі технологій віртуалізації .............................................................. 18
2.1. Існуюча ІКС для розміщення в хмарі ................................................... 18
2.2. Платформи для розміщення віртуальної інфраструктури ЦОД ........ 19
2.3. Вибір засобу адміністрування моделі хмарного захищеного центру
обробки даних ......................................................................................... 27
2.4. Інтеграція технологій віртуалізації для моделі хмарного ЦОД ......... 29
2.5. Система керування додатками хмарного ЦОД .................................... 30
Розділ 3. Реалізація моделі хмарного захищеного ЦОД............................... 33
3.1. Створення проекту Google Cloud Platform (GCP) ............................... 33
3.2. Створення образу та віртуальної машини Ubuntu ............................... 35
3.3. Встановлення середовища моделювання eve-ng ................................ 37
3.4. Встановлення образів ОС для серверів комутаційних вузлів ЦОД .. 45
3.5. Налаштування MAIN роутера ............................................................... 47
3.6. Налаштування роутера Office2 .............................................................. 51
3.7. Розгортання сервісів ЦОД в хмарі ........................................................ 52
Загальні висновки ................................................................................................ 55
Список використаних джерел ............................................................................. 56
Додаток А ........................................................................................................... 58
ЧДТУ.21.20105.008 ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб. Масляков О.В.
Модель хмарного Літ. Арк. Акрушів
Перевір. Байрак А.В.
захищеного центру 4 57
Реценз. Сагун А.В.
обробки даних на базі
Н. Контр. Байрак А.В.
технології віртуалізації ЧДТУ Бі-001
Затверд. Палагін В.В.
ВСТУП
Хмарні технології надалі стають все більш популярними і
продуктивними. Це пояснюється зручністю користування такими системами.
Сучасні бізнес-процеси вимагають продуктивних і швидких рішень в
галузі інформаційних технологій. Такі рішенні повинні бути масштабованими,
бути легкими в обслуговуванні та конфігуруванні. Не в останню чергу
важливим є їх постійна доступність і невисока вартість центрів обробки даних.
З огляду на це традиційні рішення, які використовуються для побудови ЦОД
виявляються не ефективними і дорогими в експлуатації та обслуговуванні.
Фізичне обладнання у вигляді маршрутизаторів, комутаторів, повторювачі,
серверних рішень має зависоку вартість. Всі апаратні засоби, які необхідні для
створення сучасного ЦОД займають велику площу, що збільшує витрати на
оренду та підвищує кінцеву вартість таких рішень, а необхідність
підтримувати роботу традиційних ЦОД часто виливається у доволі серйозні
фінансові витрати. Тому, більш актуальними зараз стають хмарні центри
обробки даних.
Актуальність створення хмарного захищеного ЦОД пояснюється
швидким переходом в хмару існуючих ЦОД та зниження експлуатаційних
витрат на обслуговування та забезпечення поточного захисту даних в ньому.
Мета роботи – створення хмарного захищеного ЦОД з використанням
технологій віртуалізації.
Об’єкт дослідження – модель захищеного хмарного центру обробки
даних.
Предмет дослідження – платформи, технології, системи захисту та
засоби віртуалізації компонентів ЦОД.
Новизна роботи полягає у створенні моделі захищеного ЦОД з
використанням технологій віртуалізації та soft-емуляціями базових компонент
ІКС.
Лист
ЧДТУ.21.20105.008 ПЗ 5
Змін. Лист № докум. Підпис Дата
Для досягнення мети слід вирішити такі задачі:
− проаналізувати структуру та задачі хмарних сервісів та центрів
обробки даних;
− сформувати функціональний профіль захищеності інформації
відповідно до структури інформаційно-комунікаційної системи підприємства;
− обрати платформу та технологію віртуалізації для розміщення
віртуальної інфраструктури ЦОД підприємства;
− провести практичну реалізацію моделі хмарного захищеного ЦОД
та розгорнути тестовий сервіс ЦОД в середовищі віртуалізації.
Структура та обсяг роботи. Робота складається із вступу, 3 розділів та
загальних висновків, переліку використаних джерел, що містить 15
найменувань на 2 сторінках.
Загальний обсяг роботи – 57 сторінок, з них 54 сторінки основного
тексту.
Лист
ЧДТУ.21.20105.008 ПЗ 6
Змін. Лист № докум. Підпис Дата
РОЗДІЛ 1
СТРУКТУРА ТА ЗАДАЧІ ХМАРНИХ СЕРВІСІВ ТА ЦЕНТРІВ
ОБРОБКИ ДАНИХ
1.1 Поняття, функції та структура ЦОД
Центр обробки даних, або, дата-центр, зазвичай являє собою окреме
приміщення, призначене для розміщення та експлуатації продуктивного
комп’ютерного обладнання, призначеного для виконання різного роду
обчислень. ЦОД створює сприятливі умови для функціонування апаратного
забезпечення процесу обчислень та персоналу, який його обслуговує.
Поміщення таких ЦОД частіше за все розміщають поруч з
магістральною точкою обміну трафіком, адже доступ до обладнання дата-
центру часто здійснюється через Інтернет. ЦОД оснащають сучасними
ефективними інженерними системами, адже без таких систем функціонування
ЦОД є складним процесом.
У ЦОДах використовуються різні схеми резервування інженерних
систем, рівень яких повинен підтверджується сертифікатом, а якість і обсяг
наданих послуг можуть бути дуже різними. Отже, подібні центри можуть собі
дозволити лише великі компанії, які мають значні фінансові ресурси.
1.1.1 Інженерні структури традиційних ЦОД
ЦОД мають розвинуті інженерні комунікації. Взагалі, основа будь-якого
дата-центру — це інженерні системи, які представляють собою сукупність
складного і технологічного професійного обладнання. Таке обладнання часто
недоступне для покупок до складу локального серверного приміщення.
Надійність і коректність функціонування ЦОД залежить від правильності
Лист
ЧДТУ.21.20105.008 ПЗ 7
Змін. Лист № докум. Підпис Дата
проектування, монтажу, налаштування та подальшої підтримки інженерних
систем. Можна виділити 5 основних інженерних систем дата-центрів:
- Електропостачання. Є вкрай важливим і критичним ресурсом для
роботи ЦОД. Від того, наскільки правильно та безперебійно здійснюється
електропостачання дата-центру, залежить стабільність роботи розміщеного в
ньому обладнання. Тому, ЦОД підключають до електромережі за декількома
незалежними електролініями, встановлюють системи безперебійного
живлення, а також підключають додаткові автономні генератори на випадок
повного відключення енергії.
- Кондиціювання. Через те, що ЦОД в своїму складі має велику
кількість електронного обладнання, яке під сам роботи доволі суттієво
нагрівається, то важливим питанням є кондиціонування повітря. Перегрів
обладнання ЦОД неприпустимий, тому приміщення машинного залу має дуже
добре охолоджуватися. Для охолодження обладнання ЦОД використовують
професійні прецизійні кондиціонери та інші сучасні системи кондиціонування
повітря, наприклад, такі як фрікулінг.
- Безпека. Для ЦОД важливо не тільки розмістити обладнання
замовника в будівлі, але й забезпечити його повну безпеку та конфіденційність
даних, що зберігаються та оброблюються там. Системи безпеки ЦОД
включають сучасні системи контролю доступу, відеоспостереження, пожежну
сигналізацію, систему екстреного пожежогасіння та інші. Важливо
превентивно усувати проблеми, повязані з безпекою функціонування ЦОД.
Так, наприклад, використання спеціальних датчиків раннього виявлення
пожежі дають змогу уникнути масштабних аварій. Також в ЦОД суворо
регламентується фізичний доступ до розміщеного там критичного серверного
обладнання – за це відповідає власна служба безпеки.
- Передача даних. Стабільний та безперебійний процес передачі
даних важливий для будь-якого дата-центру. Для його забезпечення
використовують, як виділені канали, так і загальнодоступні комп’ютерні
Лист
ЧДТУ.21.20105.008 ПЗ 8
Змін. Лист № докум. Підпис Дата
мережі з широкою смугою пропускання. Канали доступу обовязково мають
резервуються.
- Диспетчеризація. Забезпечення стабільної роботи всього
обладнання та інфраструктури ЦОД неможливе без системи моніторингу та
диспетчеризації. За всіма системами ведеться цілодобове спостереження, а
усунення виявлених проблем відбувається за заздалегідь розробленими
протоколами та алгоритмами. Це мінімізує, або ж, практично виключає
помилки та дозволяє вирішувати проблеми в роботі ЦОД максимально
швидко.
1.2 Послуги ЦОД та принципи їх вибору
Для забезпечення функціонуванні фізичних ЦОД витрачаються
достатньо великі кошти. Практично всі фінансові та трудові витрати при
організації функціонування дата-центру припадають на забезпечення
надійності, безпеки та стійкості до відмови технічних засобів та платформ
обчислювальної інфраструктури. Це легко пояснити тим, що головне завдання
ЦОД полягає у наданні можливості розміщення обчислювальних систем
замовника та забезпечення умов їхньої безперебійної роботи.
Більшість дата-центрів мають своє власне комп’ютерно - обчислювальне
обладнання, на базі якого вони надають низку хмарних послуг. Для клієнта
такий ЦОД виступає в якості хостинг-провайдеру.
1.2.1 Оренда VPS (Virtual Private Server). Клієнтам ЦОД надається
віртуальний сервер, керувати яким можна за допомогою панелі керування.
Користувач сам керує роботою віртуальної машини, а також вносить різні
зміни на рівні операційної системи.
Серверні рішення на базі технології VPS є відносно складним
технологічним явищем: постачальник послуг (провайдер) розгортає на своєму
Лист
ЧДТУ.21.20105.008 ПЗ 9
Змін. Лист № докум. Підпис Дата
фізичному комп’ютерному обладнанні віртуальні сервери. Надалі
постачальник послуг здає в оренду такі віртуальні сервера, дозволяючи
замовнику користуватися обчислювальними потужностями серверів без
необхідності закупки комп’ютерного обладнання та інших компонент.
Концептуально VPS сервер нічим не відрізняється від фізичного,
оскільки він має (рис.1.1):
- операційну систему;
- розташований в мережі Інтернеті;
- управляється, як стандартний комп'ютер (засобами програмного
адміністрування).
Але VPS - сервер розташований на майданчику хостинг-провайдера, має
захист від збоїв і працює цілодобово. Витрати на обслуговування VPS-серверу
лягають на плечі провайдера. Таким чином, замовник такої послуги повністю
позбавлений від проблем з налаштуванням та обслуговуванням VPS [1].
Рис.1.1 – функціональна схема VPS сервера
1.2.2 Оренда сервера (Dedicated Server). Послуга, яка дозволяє повністю
орендувати фізичний сервер.
Лист
ЧДТУ.21.20105.008 ПЗ 10
Змін. Лист № докум. Підпис Дата
Рис.1.2 – функціональна схема Dedicated Server
Виділений сервер (dedicated server) є видом хостингу. В такому випадку
клієнту надається в повне розпорядження окремий фізичний комп’ютер (на
противагу віртуальному хостингу) (рис.1.2). Такі сервери зазвичай
використовується для запуску різноманітних web-додатків, які не можуть
розміщуватися та функціонувати на одному сервері з іншими проектами або
мають підвищені вимоги до обчислювальних ресурсів.
1.2.3 IaaS (Infrastructure as a Service). Цю послугу надають не всі ЦОДи.
Клієнт отримує повну віртуальну інфраструктуру, що відрізняється
надійністю та повним абстрагуванням від фізичних ресурсів (рис.1.3) [2,3].
Послуга IaaS знаходиться на іншому боці хмари. При такому сценарії
клієнт хоче зберегти контроль над програмним середовищем, але не хоче або
не має можливості купити та підтримувати будь-яке комп’ютерне обладнання.
Адже купівля апаратного серверного обладнання є лише першим етапом. Далі
необхідно знайти приміщення для його встановлення. Серверне рішення
вимагає охорони, кондиціонування повітря, оснащення джерелами
безперебійного живлення. Для того, щоб не витрачатися на всі ці послуги,
клієнту достатньо звернутися до провайдера IaaS і орендувати готову
віртуальну інфраструктуру.
Лист
ЧДТУ.21.20105.008 ПЗ 11
Змін. Лист № докум. Підпис Дата
Орендуючи IaaS сервер, клієнт може встановити будь-яке програмне
забезпечення на надану йому віртуальну платформу. В свою чергу, провайдер
надає готові віртуальні сервери, забезпечує їх з’єднання між собою
віртуальною локальною мережею. Також в розпорядженні замовника
надається хмарне сховище доволі великого обсягу (від 100 Гб і вище – залежно
від оплаченого тарифного плану). Все це дозволяє працювати через Інтернет,
або через VPN-з'єднання (якщо клієнту не потрібно, щоб інфраструктура була
доступна через мережу Інтернет).
Віртуальні ресурси IaaS рішень, які не використовуються, можуть
вивільнятися в автоматичному режимі, а при додатковому навантаженні
необхідні ресурси стають автоматично доступними. Така особливість IaaS дає
можливість балансувати навантаження та масштабувати створені ЦОД –
безперечна перевага для бізнесу.
Послуга IaaS особливо зручна для стартапів, чий бізнес тільки робить
перші кроки. Так само, вона комфортна для компаній, що вже довго існують
на ринку, але хочуть оптимізувати свою інфраструктуру, адаптувати її до
швидко змінних умов ринку, зберегти і зміцнити конкурентну перевагу і
знизити рівень невиробничих витрат.
Лист
ЧДТУ.21.20105.008 ПЗ 12
Змін. Лист № докум. Підпис Дата
Рис.1.3 – функціональна схема IaaS (Infrastructure as a Service)
Якщо зважати на список додаткових послуг, то складається враження,
що ЦОД виступає в ролі універсального постачальника рішень для різних
типів користувачів. Теоретично це слушна річ, але на практиці це не зовсім
вірно. Справа в тому, що для надання послуги IaaS потрібно вкладати великі
кошти у парк обладнання та програмного забезпечення. Також важливо мати
висококваліфікований персонал. Адже така послуга спрямована на вирішення
великого спектру задач клієнтів, а звичайний ІТ-фахівець в одній особі не
зможе впоратися з тим широким колом задач, які вимагаються від ЦОД.
Варто зазначити, що оренда VPS часто практикується невеликими
організаціями та приватними особами. Тому, така послуга здатна замінити для
них іншу - IaaS.
Оскільки основна стаття витрат при експлуатації ЦОД це
обслуговування його систем, то надання VPS на обмеженій апаратній
платформі є доцільним, а побудова IaaS може виявитися занадто дорогим
рішенням.
Таким чином, стає зрозуміло, що організація роботи ЦОД має на меті
тонке налаштування безлічі систем, а забезпечення їхньої безперервної роботи
та безпеки — непросте завдання навіть для високопрофесійного персоналу.
Загалом, робота ЦОД залежить від схем резервування, які мають бути
обов'язково сертифіковані. Вибираючи постачальника хмарних послуг, слід
звернути увагу, у якому саме ЦОД розміщено його устаткування. За цією
ознакою можна оцінити рівень надійності такого ЦОД. Проведення міграції
даних та організацію управління віртуальною інфраструктурою слід довірити
професійному сервіс-провайдеру.
Лист
ЧДТУ.21.20105.008 ПЗ 13
Змін. Лист № докум. Підпис Дата
1.3 Механізми забезпечення захисту інформації хмарних ЦОД
З точки зору захисту конфіденційності даних ЦОД, інформаційна
безпека є перевагою технології VPS. Хостинг ЦОД на базі VPS рішень має
певні переваги над традиційним хмарним хостингом. Зокрема всі клієнтські
дані зберігаються на одному сервері, а не розподілені на декілька серверів.
Доступ через права root надає широкі можливості налаштування засобів
безпеки з боку самого клієнта. Таким чином, налаштування, повязані із
захистом інформації клієнт може обрати будь-які, необхідні конкретно йому.
Але якщо на клієнтський сайт буде здійснено атаку з боку зловмисників
(наприклад, DDoS-атаку), то це вплине на інші VPS сервіси, розміщені на тому
ж хості. Таким чином, клієнт може придбати 2 «хмарних» простори і створити
«деркало» основного ЦОД на випадком подібних аварійних ситуацій.
У випадку використання традиційного хмарному хостингу забезпечення
безпеки може виявитися порівняно складнішим завданням, оскільки дані та
ресурси в таких випадках розподіляються по різних серверах та вузлах.
Переважна більшість провайдерів хмарного хостингу надають клієнтам
доступ із правами root. Але, треба розуміти, що дані фізично можуть
зберігатися в кількох різних сховищах. В хмарному середовищі файли одного
клієнту повністю ізольовані від файлів іншого – з цього погляду традиційне
середовище може виявитися безпечнішим.
1.3.1 Надійність функціонування VPS хостингу
Хороший VPS-хостинг взавжди має високі показники часу
безперебійної роботи та швидкості завантаження сторінок. В ситуації з VPS
технологією, при аварії на хост-платформі - збій може відбутися на частині
хоста, але така проблема вплине і на віртуальний сервер: доведеться чекати,
доки провайдер не відновить працездатність хост-платформи. При відмові
однієї платформи VPS решта платформ продовжить працювати в
Лист
ЧДТУ.21.20105.008 ПЗ 14
Змін. Лист № докум. Підпис Дата
нормальному режимі, але доведеться усувати проблему і відновлювати дані та
обладнання (рис.1.4) [4]. При різкому зростанні трафіку одного VPS, це вплине
на інші VPS, розташовані на тому ж хості.
Рис.1.4 – порівняння функціонування VPS та традиційного хостингу при
відмові однієї платформи VPS
VPS-хостинг характеризується високою надійність та швидкість, але при
порівнянні виявляється, що за рахунок кластера серверів надійність хмарного
хостингу набагато вища. В разі використання хмарного хостингу будь-яка
відмова в роботі платформи призводить до зміни маршрутизації трафіку на
інший доступний фізичний ресурс. Час простою в такому випадку є
мінімальним. Оскільки кожний віртуальний сервер не залежить від інших, то
і робота сайти та web-сервісів в такому середовищі не впливають на роботу
інших сторонніх ресурсів, розміщених на VPS.
Таким чином, Web-сайти та ЦОД в хмарі мають досить високу
доступність інформації. Вони тиражуються або реплікуються між серверами
кластера. У випадку різкого зростання трафіку одного сайту запити
Лист
ЧДТУ.21.20105.008 ПЗ 15
Змін. Лист № докум. Підпис Дата
маршрутизуються на менш навантажений сервер у хмарі. При аварії і відмові
одного фізичного сервера у кластері всі віртуальні машини на ньому
продовжать працювати. В результаті хостинг на основі хмарних рішень є
більш стабільним, оскільки відмова одного компонента не впливає на
функціонування сервісу в цілому [4].
1.4 Функціональний профіль захищеності інформації
Враховуючи існуючу топологію комунікаційної частини ЦОД, можна
сформувати функціональний профіль захищеності оброблюваної інформації
даної автоматизованої системи.
В даному випадку автоматизована система ЦОД, являє собою
інформаційно-комунікаційну систему, яка об’єднує віртуальні комутатори,
віртуальне серверне та комп’ютерне обладнання та контейнери, фізичне
середовище і оброблювану інформацію.
Така система працює в середовищі комп’ютерної мережі та містить
набір хмарних сервісів, має безпосередній доступ до потенційно небезпечного
середовища передавання інформації – мережу Internet. Тому, відповідно до
вимог документів НД ТЗІ 2.5-004-99 і НД ТЗІ 2.5-005-99 таку АС може бути
віднесена до 3 класу АС [5,6].
АС класу «3» — це розподілений багатомашинний
багатокористувацький комплекс, що оброблює інформацію з різними
ступенями обмеження доступу. В даній АС необхідно передбачити захист
інформації при її передачі через незахищене середовище. В хмарному ЦОД
наявні вузли, що реалізують різну політику інформаційної безпеки.
Дана АС є системою, в якій існують підвищені вимоги до забезпечення
цілісності і доступності оброблюваної інформації (підкласи «х.ЦД»). Тому,
можна сформувати основні атрибути (клас і підклас) відповідно до вимог
нормативних документів серії НД ТЗІ - 3.ЦД. Дана АС характеризується
Лист
ЧДТУ.21.20105.008 ПЗ 16
Змін. Лист № докум. Підпис Дата
наявністю в своєму складі користувачів з різними повноваженнями по доступу
і/або технічних засобів, які можуть одночасно здійснювати обробку
інформації різних категорій конфіденційності.
На основі рекомендацій НД ТЗІ-2.5-005-99 можна обрати наступний
стандартний профіль захищеності:
3.ЦД.2 = { ЦД-1, ЦА-2, ЦО-1, ЦВ-2,
ДР-2, ДС-1, ДЗ-1, ДВ-2,
НР-2, НИ-2, НК-1, НО-2, НЦ-2, НТ-2, НВ-2, НА-1 }
Даний профіль має номер 7.3.6 - Стандартні функціональні профілі
захищеності в КС, що входять до складу АС класу 3, з підвищеними вимогами
до забезпечення цілісності і доступності оброблюваної інформації.
Лист
ЧДТУ.21.20105.008 ПЗ 17
Змін. Лист № докум. Підпис Дата
РОЗДІЛ 2
ПЛАНУВАННЯ СТРУКТУРИ ХМАРНОГО ЗАХИЩЕНОГО
ЦЕНТРУ ОБРОБКИ ДАНИХ НА БАЗІ ТЕХНОЛОГІЙ ВІРТУАЛІЗАЦІЇ
2.1 Існуюча ІКС для розміщення в хмарі
2.1.1 Інформаційно-комунікаційна система підприємства
Схема серверного вузла комп’ютерної мережі підприємства наведена на
рис.2.1.
Рис.2.1 – Схема інформаційно-комунікаційної системи
Лист
ЧДТУ.21.20105.008 ПЗ 18
Змін. Лист № докум. Підпис Дата
Як видно з рис.2.1, інформаційно-комунікаційна система підприємства
складається з двох сегментів: LAN1, LAN2.
З метою забезпечення кращої доступності інформації передбачено
доступ до мережі інтернет від 2 незалежних каналів: Net1 і Net2.
Комп’ютери VPC6, VPC7, VPC11 в LAN1 мають статичні IP та них
розташований web-сервер, поштовий сервер та файловий сервер. В мережі
LAN2 всі наявні комп’ютери отримують динамічні IP адреси. Вони
використовуються в якості хост-платформ.
2.2 Платформи для розміщення віртуальної інфраструктури ЦОД
Модель хмарного захищеного ЦОД можна базувати на декількох
наявних платформах хмарних обчислень. Розглянемо 3 існуючі базові
платформи хмарних обчислень, придатні для розгортання захищеного центру
обробки даних [7]:
- AWS (Amazon Web Services )
- GCP (Google Cloud Platform)
- Microsoft Azure.
2.2.1 Amazon Web Services або AWS являє собою платформу хмарних
обчислень, яка здається в оренду приватним особам, компаніям та урядам на
основі системи платної підписки. Платформа може бути безкоштовною, але
така можливість доступна тільки протягом перших 12 місяців. Технологія
AWS дозволяє своїм абонентам отримувати у своє розпорядження
повноцінний віртуальний кластер, що складається з комп'ютерів. Такий
кластер завжди доступний для клієнта через мережу Інтернет. Віртуальні
комп'ютери в складі технології AWS володіють практично всіма атрибутами
реальних комп'ютерів, включаючи апаратні пристрої: процесор, відеокарту,
мережевий адаптер, локальну та оперативну пам'ять, жорсткий диск/SSD-
Лист
ЧДТУ.21.20105.008 ПЗ 19
Змін. Лист № докум. Підпис Дата
накопичувач); на них користувач може встановлювати операційну систему на
свій вибір; налаштовувати мережу; і попередньо встановлені програми, такі
як: веб-сервер, база даних, система керування контентом. Кожна клієнтська
система в AWS також віртуалізує засоби консольного вводу/виводу
(клавіатура, дисплей і миша). Все це дозволяє користувачам платформи AWS
підключитися до свого ЦОД AWS за допомогою web-браузера. Через браузер
користувач входить в систему, налаштовує та використовує свої віртуальні
системи аналогічно до того, як фізичний комп'ютер або сервер. Це дозволяє
налаштувати систему таким чином, щоб надавати інтернет-орієнтовані сервіси
та послуги власним клієнтам.
Технологія AWS засновується на серверних кластерах (так званих
фермах), які розташовані по всьому світі. Плата за користування платформи
базується на комбінації використання апаратних засобів, операційних систем,
програмного забезпечення, мережевих функцій, які обирає користувачем, а
також вимог щодо доступності, надлишковості (redundancy), безпеки та інших
додаткових параметрів. Користувач може зарезервувати віртуальний
комп'ютер (VM), кластер віртуальних комп'ютерів (VM Cluster), фізичний
комп'ютер (Server), призначений для його виняткового корисиувацького
використання, або цілий кластер фізичних комп'ютерів (Server Cluster).
2.1.2 Платформа Microsoft Azure є хмарною платформою та
інфраструктурою, розроблена корпорацією Microsoft. Дана платформа
призначена для розробників додатків для хмарних обчислень. Основне
призначення платформи - спрощення процесу створення онлайнових додатків.
Платформа Windows Azure складається з наступних компонент:
1. Windows Azure — це середовище виконання для програмних
додатків, заснованих на операційних системах, зокрема, на Windows Server, а
також це місце зберігання даних. Дана система функціонує на віртуальних
машинах за допомогою технології, аналогічної технології Hyper-V.
Лист
ЧДТУ.21.20105.008 ПЗ 20
Змін. Лист № докум. Підпис Дата
2. Обчислення — відповідає за проведення процедури обчислень для
розміщення додатків.
3. Зберігання — механізм, який відповідає за зберігання даних в
хмарі.
4. Компонент керування реляційною БД SQL Azure надає
можливість використовувати реляційну базу даних для запуску додатків в
хмарі.
Платформа Windows Azure AppFabric — це компонент, який забезпечує
хмарній платформі додаткову функціональність у вигляді комплексу різних
послуг.
2.1.3 Google Cloud Platform. Ця платформа містить та реалізує:
− Інфраструктура як послуга (IaaS)
− Платформа як послуга (PaaS)
− Безсерверні обчислення (Cloud Computing).
Google Cloud Platform – це продукт компанії Google, який розроблений
для роботи з великим обсягом даних і побудові інфраструктури великого
масштабу, доступний широкому колу користувачів і дає можливість
працювати з різними інструментами для хмарних обчислень і хостингу. Це
рішення дозволяє обрати керовану прикладну платформу, використовувати
технології віртуальних контейнерів для отримання більшої гнучкості або
створити власну хмарну інфраструктуру, максимально контрольовану і
безпечну.
Google Cloud Platform (GCP) – це широкий набір інструментів IaaS, PaaS,
ML та різноманітні API для розробників і бізнесу. Віртуальні машини, хостинг
додатків і контейнерів, машинне навчання, сервіси зберігання і обробки даних
– все це та багато іншого входить до складу платформи і може бути
використано для цифрової трансформації та створення цифрових продуктів.
Лист
ЧДТУ.21.20105.008 ПЗ 21
Змін. Лист № докум. Підпис Дата
GCP дозволяє легко створювати, контролювати і використовувати хмари
під різні завдання, такі як:
- створення власних хмарних інфраструктури
- обчислення і хостинг
- міграція в хмару
На базі GCP працюють міжнародна платіжна система PayPal, інтернет-
магазин eBay, інтернет-сервіс Spotify та Twitter.
AWS надає хостинг у кількох місцях по всьому світу. Azure і GCP також
розміщуються в кількох місцях по всьому світу, але різниця полягає в кількості
відповідних зон доступності.
− AWS має 66 зон доступності.
− Azure доступна в 140 країнах світу.
− Google Cloud Platform стала доступною в 20 регіонах.
Відповідно до звітних квартальних прибутків за 2021 рік, дохід від
продажів хмарних платформ Microsoft Azure перевершує дохід від продажу
хмарних рішень AWS і Google Cloud разом взятих.
Зростання продажів рішення AWS від Amazon становило 17,7 мільярдів
доларів США у 1 кварталі 2020 року (зріст доходу на 50% у порівнянні з
попереднім кварталом) відповідно до звіту про фінансові прибутки. В той час
Amazon AWS повідомила про доходи від хмарного бізнесу в 13,5 мільярдів
доларів США за квартал (зростання доходу на 32% за 1 квартал 2021 року).
Рішення Google Cloud Platform збірає 4,05 мільярда доларів США (рис.2.2).
Лист
ЧДТУ.21.20105.008 ПЗ 22
Змін. Лист № докум. Підпис Дата
Рис.2.2 – Динаміка збільшення популярності найбільших трьох хмарних
платформ
У звітах Canalys згадується, що станом на квітень 2021 року світовий
ринок хмарних рішень зріс на 35% у 2 кварталі 2021 року - до 41,8 мільярда
доларів. AWS займає 32% ринку, за ним йдуть Azure з 19% і Google з 7%
вартості продажів на даному ринку (рис.2.3) [7].
З наведених даних можна зробити висновок про велику популярність та
високі перспективи хмарних рішень на ринку ЦОД.
Лист
ЧДТУ.21.20105.008 ПЗ 23
Змін. Лист № докум. Підпис Дата
Рис.2.3 – Обсяг продажу хмарних рішень від 3 найбільших виробників на 1
квартал 2021 року
Завдяки додатковій перевазі, яка полягає в більшому терміні присутності
на ринку обчислювальні послуги хмарної платформи AWS, є найбільш
розвиненими та функціонально багатими, порівняно з рішеннями від Google
та Microsoft.
Хмарна платформа AWS пропонує більше 200сервісів, тоді як Azure
пропонує до 100. Платформ а Google Cloud, з іншого боку, пропонують понад
60 хмарних сервісів, придатних для створення ЦОД [8].
Нижче наведено пропозиції послуг від AWS, Azure та GCP, які належать
до доменів обчислень, баз даних, зберігання та мереж (таблиця 2.1).
Таблиця 2.1
Сервіси хмарних платформ
Сервіси Назва та тип у платформі
AWS Azure GCP
IaaS Amazon Elastic Compute Virtual Machines Google Compute
Cloud Engine
PaaS AWS Elastic Beanstalk App Service and Google App
Cloud Services Engine
Containers Amazon Elastic Compute Azure Kubernetes Google
Cloud Container Service Service (AKS) Kubernetes
Engine
Serverless AWS Lambda Azure Functions Google Cloud
Functions Functions
Всі розглянуті платформи мають компоненти для роботи з базами даних
(таблиця 2.2).
Лист
ЧДТУ.21.20105.008 ПЗ 24
Змін. Лист № докум. Підпис Дата
Таблиця 2.2
Компоненти для роботи з базами даних
Сервіс Назва та тип у платформі
AWS Azure GCP
RDBMS Amazon Relational SQL Google Cloud SQL
Database Service Database
NoSQL: Amazon DynamoDB Table Google Cloud
Key–Value Storage DatastoreGoogle Cloud
Bigtable
NoSQL: Amazon SimpleDB Azure Google Cloud Datastore
Indexed Cosmos DB
Для зберігання даних у кожної з розглянутих хмарних платформ
передбачені декілька видів технологій (таблиця 2.3).
Таблиця 2.3
Сервіс Назва та тип у платформі
AWS Azure GCP
Object Amazon Simple Blob Storage Google Cloud Storage
Storage Storage Service
Virtual Server Amazon Elastic Managed Disks Google Compute Engine
Disks Block Store Persistent Disks
Cold Storage Amazon Glacier Azure Archive Google Cloud Storage
Blob Storage Nearline
File Storage Amazon Elastic File Azure File Storage ZFS/Avere
System
Для реалізації мережевих комунікацій, балансування трафіку та інших
мережевих технологій розглянути хмарні платформи надають наступні
компоненти (таблиця 2.3).
Лист
ЧДТУ.21.20105.008 ПЗ 25
Змін. Лист № докум. Підпис Дата
Таблиця 2.3
Мережеві компоненти хмарних платформ
Services AWS Azure GCP
Virtual Amazon Virtual Private Virtual Networks Virtual Private
Network Cloud (VPC) (VNets) Cloud
Elastic Load Elastic Load Balancer Load Balancer Google Cloud Load
Balancer Balancing
Peering Direct Connect ExpressRoute Google Cloud
Interconnect
DNS Amazon Route 53 Azure DNS Google Cloud DNS
Важливим фактором вибору тієї чи іншої хмарної платформи для
реалізації на ній моделі захищеного ЦОД є вартість володіння та супроводу. В
таблиці 2.4 наведено порівняння цінових моделей AWS, Azure та GCP на
основі типу умовного фізичного комп’ютера, який вони пропонують.
Таблиця 2.4
порівняння цінових моделей AWS, Azure та GCP
Тип AWS Azure GCP
платформи
Найпростіша включає 2 Аналогічна до AWS - Порівняно з AWS,
платформа віртуальні екземпляра з 2 GCP найпростіший
процесори та 8 віртуальними екземпляр, з 2
ГБ оперативної процесорами та 8 ГБ віртуальними
пам’яті, ціна 69 оперативної пам’яті, процесорами, 8 ГБ
доларів США на ціна 70 доларів США оперативної пам’яті з
місяць. на місяць. ціною 52 доларів США
на місяць.
Продуктивна 3,84 ТБ 3,89 ТБ оперативної 3,75 ТБ оперативної
платформа оперативної пам’яті, 128 пам’яті та 160 vCPU.
пам’яті, 128 віртуальних Ціна 5,32 доларів
vCPU, коштує процесорів. Коштує США на годину.
Лист
ЧДТУ.21.20105.008 ПЗ 26
Змін. Лист № докум. Підпис Дата
3,97 доларів 6,79 доларів США на
США на годину. годин
AWS вводить тарифи на оренду хмарної платформи, що передбачають
щохвилинну оплату. Azure давно пропонує оплату за хвилину оренди, а Google
Cloud пропонує моделі з щосекундною оплатою, які дозволяють користувачам
заощадити набагато більше, ніж при використанні платформ AWS або Azure.
Google пропонує систему знижок, щоб допомогти клієнтам заощадити до 50
відсотків у деяких випадках порівняно з платформами від AWS.
В зв’язку з тим, що рішення від AWS та MS Azure мають занадто високу
функціональність, яка не буде затребувана при розгортанні та функціонуванні
хмарного ЦОД та враховуючи більш прийнятну бізнс-модель оренди хмарної
платофрми від google, зупинимо свій вибір на Google Cloud Platform
2.3 Вибір засобу адміністрування моделі хмарного захищеного
центру обробки даних
При тестуванні засобів безпеки, а також під час навчання персоналу
сценаріям атак та захисту мережевої інфраструктури використовуються
засоби віртуалізації. Для цього необхідно налаштувати платформу емуляції.
Існують декілька варіантів платформ емуляції, які можна використати
для створення моделі хмарного захищеного центру обробки даних:
GNS3 – це графічний мережевий симулятор, який дозволяє моделювати
складні компютерні мережі. Для забезпечення повного та точного
моделювання GNS3 тісно пов'язана з Dynamips, емулятором Cisco IOS.
Packet Tracer – це симулятор маршрутизуючого обладнання Cisco, який
широко використовується у навчанні, освіті, а також у дослідженнях для
простого моделювання комп'ютерних мереж.
Лист
ЧДТУ.21.20105.008 ПЗ 27
Змін. Лист № докум. Підпис Дата
Симулятор Verax SNMP Simulator – це інструмент, який може
імітувати кілька агентів SNMPv1/v2c на одному хості на стандартному порту
161 через multi-netting. Індивідуальні відповіді на модельовані агенти можуть
бути спочатку отримані з існуючих пристроїв і змінені під час виконання за
правилами користувача.
NetSim для мережевого симулятора CCNP включає окрім підтримки
класичних технологій маршрутизації також нові технології - ROUTE, SWITCH
та TSHOOT.
Dynamips – це комп'ютерна програма емулятора, яка використовується
для емуляції роботи маршрутизаторів. Dynamips працює на Linux, Mac OS X
або Windows і може емулювати апаратне забезпечення платформ
маршрутизації Cisco-серій, безпосередньо завантажуючи фактичне
зображення програмного забезпечення Cisco IOS в емулятор. Dynamips
емулює платформи маршрутизаторів Cisco 1700, 2600, 2691, 3600, 3725, 3745
та 7200.
Cisco Packet Tracer Mobile – це інструмент моделювання та візуалізації
мережі.
В якості системи емуляції моделі захищеного ЦОД в хмарі оберемо
EVE-NG.
EVE-NG - це емульоване віртуальне середовище наступного покоління,
що дозволяє створити повноцінну віртуальну лабораторію з мережевим
обладнанням і програмним забезпеченням провідних світових виробників.
Дане середовище дозволяє підприємствам, постачальникам/центрам
електронного навчання, окремим співробітникам і співробітникам групи
створювати віртуальні докази концепцій, рішень і навчальних середовищ [9].
Отже перейдемо до інструментальної реалізації моделі захищеної
інформаційно-комунікаційної системи підприємства з метою створення та
перевірки механізмів захисту для сервісів та систем, які сформульовані в
Лист
ЧДТУ.21.20105.008 ПЗ 28
Змін. Лист № докум. Підпис Дата
задачах захисту інформації проектованого вузла інформаційно-
комунікаційної системи.
2.4 Інтеграція технологій віртуалізації для моделі хмарного ЦОД
Для встановлення EVE-NG використовувався Google Cloud Platform -
наданий компанією Google набір хмарних служб, які виконуються на тій же
самій інфраструктурі, яку Google використовує для своїх продуктів,
призначених для кінцевих споживачів, таких як Google Search і YouTube. Крім
інструментів для управління, також надається ряд модульних хмарних служб,
таких як хмарні обчислення, зберігання даних, аналіз даних і машинне
навчання.
Фізично, це цілісна і стабільна віртуальна машина VMware, в основі
якої лежить Linux Ubuntu 16.04 x64. Залежно від обраного способу установки,
EVE-NG також може працювати і безпосередньо на Ubuntu 16.04 із спеціально
зібраним ядром kernel.
Вся емульоване середовище запускається всередині цієї машини, а
доступ до неї здійснюється через звичайний веб браузер. Причому, не
обов'язково з цього ж комп'ютера, це може бути і доступ по мережі,
включаючи Інтернет.
За допомогою браузера можна в візуальному режимі створювати
мережеві топології, що включають різних виробників, запускати емульовані
пристрої, підключатися до них через консоль, а також наочно стежити за
споживаними обчислювальними ресурсами EVE-NG.
Для підключення до цих пристроїв можна скористатися або
спеціальним попередньо встановленим клієнтом, або просто звичайним
HTML5 інтерфейсом.
Залежно від типу пристрою, підключаться через консоль до них можна
по протоколам telnet, RDP або VNC.
Лист
ЧДТУ.21.20105.008 ПЗ 29
Змін. Лист № докум. Підпис Дата
А до вже сконфігурованих відповідним чином пристроїв, можна по
мережі отримувати доступ через SSH, telnet, HTTP, HTTS.
2.3.1 Хмарне сховище функціонування моделі захищеної
інформаційно-комунікаційної системи підприємства
Як вже зазначалося, в якості хмарного сховища будемо використовувати
Google Cloud Platform. Це наданий компанією Google набір хмарних служб, які
виконуються на тій же самій інфраструктурі, яку Google використовує для
своїх продуктів, призначених для кінцевих споживачів, таких як Google Search
і YouTube. Крім інструментів для управління даний сервіс надає ряд
модульних хмарних служб, таких як хмарні обчислення, зберігання даних,
аналіз даних і машинне навчання.
2.5 Система керування додатками хмарного ЦОД
Система docker це легка система контейнеризації програм з відкритим
вихідним кодом. Наприклад, зараз існує декілька сотень типів Linux-
дистрибутивів. Кожний тип Linux-дистрибутива маж свої власні особливості
по встановленню і налаштуванню додатків. Наприклад:
- відмінність процедури встановлення пакетів (apt-get, yum, dnf)
- відмінність пакетної бази (потрібний пакет може бути відсутнім)
- назва пакета, його версія та механізм установки можуть відрізнятися
- пакети зібрані з різними опціями та розширеннями
- файли конфігурації розміщуються в різних місцях
- тощо.
Все це створює серйозні проблеми при перенесенні працюючого додатка
з одного типу Linux-дистрибутиву на інший.
Docker вирішує цю проблему шляхом створення образу файлової
системи, що включає крім програми всі необхідні бібліотеки і файли
Лист
ЧДТУ.21.20105.008 ПЗ 30
Змін. Лист № докум. Підпис Дата
конфігурації. Таким чином, встановивши образ docker-програми, створеної
для одного типу дистрибутива (наприклад, Ubuntu), можна на його основі
запустити контейнер, який виконує програму на іншому дистрибутиві
(наприклад, ALTLinux).
При роботі з web-додатками та їх робочими версіями docker дозволяє
розгорнути найбільш популярні сервери, такі, як: nginx, php, mysql,
phpmyadmin та будь-які інші додатки. Причому, відпадає потреба їх
встановлювати та «засмічувати» систему.
Docker має засоби ізоляції сервісів від інфраструктури, що дає
можливість значно спростити процес розгортання та експлуатації готових
додатків. Така ізоляція підвищує безпеку даних і дозволяє запускати декілька
віртуальних контейнерів на одному хості одночасно. Контейнери не
вимагають наявності гіпервізора. Вони запускаються безпосередньо в ядрі
хост-ПК. Таким чином досягається можливість запуску великої кількості
віртуальних контейнерів, що на порядки більше ніж кількість можливих
запущених віртуальних машин, на одному фізичному обладнанні.
Інструмент Docker надає вбудовані інструменти та платформу для
керування життєвим циклом віртуальних контейнерів. За допомогою Docker
відбувається пакування додатків та їх компонентів до контейнера.
Таким чином, клієнт, який орендує хмарну платформу GCP після
розробки свого додатку може розгорнути на встановлених серверах вручну
або за допомогою оркестратора всі необхідні для функціонування ЦОД
контейнери. Така техніка розгортання буде абсолютно однаковою незалежно
від місця розгортання додатку (локальний дата центр, хмарний провайдер або
гібридне оточення.
Docker використовує звичайну клієнт-серверну архітектуру (рис.2.4)
[10].
Лист
ЧДТУ.21.20105.008 ПЗ 31
Змін. Лист № докум. Підпис Дата
Рис. 2.4 Прицнипова схема представлення архітектури Docker
Docker - клієнт в процесі роботи взаємодіє з фоновим процесом –
серверною частиною Docker, яка, в свою чергу запускає віртуальний
контейнери. Клієнтська частина і фоновий процес можуть виконуватися в
середовищі однієї ОС. Також існує можливість підключати клієнтські
додатки до віддаленого фонового процесу.
Фоновий процес Docker здатен приймає запити і керувати об'єктами
Docker.
Фоновий процес керує наступними об'єктами:
– образи;
– контейнери;
– мережеву взаємодію;
– томи.
Основною задачею Docker - клієнта є взаємодії з сервером. При
виконанні команди клієнтська частина відправляє отриману команду
фонового процесу, а той, в свою чергу, її виконує. Docker- клієнт може
взаємодіяти з великою кількістю різних docker - серверів.
Лист
ЧДТУ.21.20105.008 ПЗ 32
Змін. Лист № докум. Підпис Дата
РОЗДІЛ 3
РЕАЛІЗАЦІЯ МОДЕЛІ ХМАРНОГО ЗАХИЩЕНОГО ЦОД
3.1 Створення проекту Google Cloud Platform (GCP)
Після вибору хмарного простору для розташування моделі ЦОД,
зареєструємо обліковий запис GCP, після чого у стартовому вікні GCP
обираємо пункт «Выберите проект».
В наступному вікні обираємо пункт «Создать проект». Вводимо ім’я
проекту і натискаємо кнопку «Создать» (рис.3.1).
Рис. 3.1 – Cтворення проекту
В створеному хмарному дисковому сховищі розгорнемо програмні
відображення ОС, які відповідають реальним, присутнім в ІКС підприємства,
топологія та компоненти ІКС якого описані в п.2.1.1.
Панель для адміністрування GCP має вид, показаний на рис.3.2.
Лист
ЧДТУ.21.20105.008 ПЗ 33
Змін. Лист № докум. Підпис Дата
Рис.3.2 - Панель для адміністрування GCP
Далі переходимо в Compute Engine і створюємо нову віртуальну
машину, через яку будемо здійснювати розгортання моделі захищеного ЦОД
(рис.3.3).
Рис.3.3 – створення віртуальної машини в Compute Engine
Лист
ЧДТУ.21.20105.008 ПЗ 34
Змін. Лист № докум. Підпис Дата
Задаємо ім’я віртуальної машини та її характеристики в розділі Compute
Engine (рис.3.4).
Рис.3.4 – ім’я віртуальної машини в розділі Compute Engine
3.2 Створення образу та віртуальної машини Ubuntu
Для створення вкладеного образу побудованого на базі Ubuntu 16.04
необхідно спочатку активувати «Cloud Shell», натиснувши піктограму
«Activate Cloud Shell».
Після цього у нижній частині сторінки відкриється панель термінала
Cloud Shell. Для створення вкладеного образу необхідно виконати команду:
«gcloud compute images create nested-ubuntu-xenial --source-image-
family=ubuntu-1604-lts--source-image-project=ubuntu-os-cloud--
licenses=https://compute. googleapis.com/compute/v1/projects/vm-
options/global/licenses/enable-vmx.».
Після того як образ буде створено, термінал повідомить наступним
повідомленням зі статусом «READY» (рис.3.5).
Рис. 3.5 – Cтворення образу Ubuntu
Лист
ЧДТУ.21.20105.008 ПЗ 35
Змін. Лист № докум. Підпис Дата
Таким чином, створено перше програмне відображення – ОС Linux, на
базі якого працює один із сервісів.
Створена і запущена віртуальна машина в дашборді має вигляд,
наведений на рис. 3.6.
Рис.3.6 – Створена і запущена віртуальна машина в дашборді
Підключаємось до створеної віртуальної машини через SSH- з’єднання
(рис.3.7).
Рис.3.7 – підключення до створеної віртуальної машини через ssh
Лист
ЧДТУ.21.20105.008 ПЗ 36
Змін. Лист № докум. Підпис Дата
Для налаштування диску натискаємо «Изменить», переходимо на
вкладку «Пользовательские образы» і в полі «Образ» обираємо створений
користувацький образ Ubuntu. Встановлюємо розмір диску в 100 Гб.
На завершальному етапі налаштування параметрів віртуальної машини
встановлюємо «галочку» напроти пунктів «Разрешить трафик HTTP»,
«Разрешить трафик HTTPS» та натискаємо «Создать» (рис.3.8).
Рис. 3.8 – Налаштування завантажувального диску
3.3 Встановлення середовища моделювання eve-ng
Середовище віртуалізації eve-ng дозволяє створити топологію з
використанням різних моделей маршрутизаторів - mikrotik, cisco тощо. В
ньому існую можливість додавати сервери та багато іншого.
Для того, щоб встановити дане середовище та забезпечити його
функціонування необхідно мати такі ресурси в хмарі:
1) можливість розгортання віртуальної машини
2) Вільне місце від 20 ГБ
3) Підтримка апаратної віртуалізації на рівні CPU (Intel-VT/AMD-V
4) ОЗП від 4 Гб
Встановлюємо EVE NG (рис.3.9).
Лист
ЧДТУ.21.20105.008 ПЗ 37
Змін. Лист № докум. Підпис Дата
Рис.3.9 – Встановлення пакету EVE-NG
Запущена віртуальна машина із встановленим EVE-NG має вигляд, показаний на рис.3.10.
Рис.3.10 – Зовнішній вигляд запущеної віртуальної машини зі встановленим
EVE-NG
Підключаємось через SSH-з’єднання до віртуальної машини для того
щоб загрузити туди образи роутера та маршрутизатора (рис.3.11).
Лист
ЧДТУ.21.20105.008 ПЗ 38
Змін. Лист № докум. Підпис Дата
Рис.3.11 – Підключаємось через SSH-з’єднання до віртуальної машини
Генеруємо ліцензійний ключ для програми EVE-NG (рис.3.12).
Лист
ЧДТУ.21.20105.008 ПЗ 39
Змін. Лист № докум. Підпис Дата
Рис.3.12 – Генерування ліцензійного ключа для роботи з EVE-NG
Вигляд каталогу із згенерованим ключем та завантаженими образами
маршрутизаторів показаний на рис.3.13.
Рис.3.13 – Вигляд каталогу із згенерований ключем та завантаженими
образами маршрутизаторів
В моделі хмарного ЦОД будемо використовувати soft-образи таких
мережевих маршрутизаторів:
- маршрутизатор Cisco 2691 - модульний маршрутизатор для малих
(до 20 осіб) і середніх (до 250 осіб) офісів. В даному маршрутизаторі
передбачено можливість передачі голосу і факсових повідомлень.
Лист
ЧДТУ.21.20105.008 ПЗ 40
Змін. Лист № докум. Підпис Дата
Пропонований до нього набір модулів дозволяє використовувати
маршрутизатор Cisco 2691 в якості серверів доступу та міжмережевих екранів,
для передавання голосу та факсів через мережі TCP/IP. Маршрутизатор Cisco
2691 має 2 порти Fast Ethernet, 2 слоти WAN, один слот для мережевого модуля
та один слот для AIM модуля;
- серія маршрутизаторів Cisco 3700 призначена для віддалених
офісів, які потребують високого рівня інтеграції сервісів. Він пропонує
широкий набір мережевих та голосових інтерфейсів в одному пристрої. При
використанні цієї платформи користувачі, завдяки високопродуктивним
модулям розширення (HDSM) та сервісним модулям (AIM). Даний
маршрутизатор інтегрує високопродуктивну маршрутизацію/комутацію за
допомогою WAN з'єднань. Cisco 3700 надає рішення, здатне підтримувати
велику кількість традиційних телефонних пристроїв спільно з пристроями IP-
телефонії. Використання 16- або 36-портових EtherSwitch модулів з
підтримкою Inline Power, аналогових та цифрових інтерфейсів, а також
голосових можливостей Cisco IOS дозволяє поєднати окремі мережі PBX
телефонії та передачі даних, об'єднавши їх в одну;
- маршрутизатор Cisco серії 7200 відносяться до класу
провайдерських. Даний пристрій здатний забезпечувати швидкісний трафік
інтернету (максимальний показник обробки сягає 2 млн. пакетів за секунду).
За швидкість маршрутизації даних роутерів відповідає технологія Network
Processing Engine G2. До базового функціоналу модельного ряду 7200
належать такі опції:
– забезпечення апаратного VPN-шифрування (здійснюється завдяки
механізму VPN Services Adapter);
– великий асортимент конфігурацій;
– адаптація під інтерфейси від DS-0 до OC-3, а також оптимізація
для роботи з такими сервісами як Fast Ethernet, Packet over SONET і
Gigabit Ethernet.
Лист
ЧДТУ.21.20105.008 ПЗ 41
Змін. Лист № докум. Підпис Дата
Роутер має високу стійкість до відмов. З технічного заповнення
маршрутизаторів серії 7200 виділяється технологія Cisco IP Next-Generation
Network, що забезпечує користувачеві високий показник швидкості передачі.
Також практично весь модельний ряд оснащений інтегрованим вбудованим
сервісом мережі.
Переходимо до EVE-NG і авторизуємося в ній (рис.3.14). Після
завантаження на екрані відобразиться вітання у вигляді IP адреси та рядком
для введення логіну, а після пароля.
Після цього сервер повинен завантажитися повністю. Далі можна
заходити на веб-інтерфейс по ip, з логіном «admin» з паролем «eve» (рис.3.14).
Рис.3.14 – вхід через веб-інтерфейс по ip в EVE-NG
Створюємо новий проект в EVE-NG для подальшого розгортання
частини хмарної мережевої інфраструктури (рис.3.15).
Лист
ЧДТУ.21.20105.008 ПЗ 42
Змін. Лист № докум. Підпис Дата
Рис.3.15 – створення нового проекту в EVE-NG
В новому проекті добавляємо об’єкти моделі хмарного ЦОД на робочу
зону EVE-NG (рис.3.16).
Рис.3.16 – поле проекту EVE-NG для додавання soft-об’єктів ІКС
хмарного ЦОД
3.4 Встановлення образів ОС для серверів комутаційних вузлів ЦОД
Для побудови моделі хмарного ЦОД необхідно встановити образи
маршрутизаторів внутрішньої інфраструктури даного ЦОД.
3.4.1 Встановлення образів Cisco IOL
Лист
ЧДТУ.21.20105.008 ПЗ 43
Змін. Лист № докум. Підпис Дата
Образи Cisco IOU/IOL – це образи L2/L3 комутаторів і
маршрутизаторів, які мають такі ж самі функції, що і оригінальні пристрої. Їх
слід завантажити в директорію /opt/unetlab/addons/iol/bin/.
3.4.2 Windows 10 x64 та Windows Server 2016R
Встановлення Windows 10 x64 та Windows Server 2016R є ідентичним,
виключаючи назви каталогів. Прикладом буде встановлення Windows 10 x64.
Для встановлення Windows 10 на сервері необхідно створити каталог
за шляхом /opt/unetlab/addons/qemu/win-win10. Після створення каталогу
потрібно завантажити образ з ОС Windows 10 і назвати його сdrom.iso. Після
завантаження
образу необхідно створити віртуальний жорсткий диск та назвати його
virtioa.qcow2 (рис.3.17).
Рис. 3.17 – Створення віртуального жорстокого диску
Можна приступити до самого встановлення Windows10 вже в самій
лабораторії eve-ng. Встановлення схоже на інсталяцію ОС Windows 10.
Відмінністю є вибір жорсткого диску, на який встановлюється ОС Windows.
Для цього необхідно обрати «Загрузить», «Обзор», «Дисковод
B»/storage/2003R2/amd64 або x86 (залежить від розрядності ОС).
Після завершення інсталяції вимикаємо віртуальну машину Windows та
зберігаємо її. Для реалізації даного процесу необхідно дізнатись ідентифікатор
роботи (у вкладці «Lab Details» - рис.3.18), POD ID – якщо маніпуляція
Лист
ЧДТУ.21.20105.008 ПЗ 44
Змін. Лист № докум. Підпис Дата
здійснюється від імені адміністратора, то за замовчуванням він буде
дорівнювати нулю. Також необхідно знати номер вузла (рис.3.19).
Рис. 3.18 – Ідентифікатор роботи
Рис. 3.19 – Ідентифікатор вузла
Перейшовши на сервер необхідно перейти в директорію вузла за
допомогою команди сd, і зберегти зміни, які були внесені в вузлі (рис.3.20).
Рис. 3.20 – POD ID
Завдяки цьому, на кожен вузол з ОС Windows не потрібно
встановлювати ОС при його додаванні. Після збереження образу видаляємо
образ cdrom.iso.
Лист
ЧДТУ.21.20105.008 ПЗ 45
Змін. Лист № докум. Підпис Дата
Змінюємо права доступу для всіх доданих образів за допомогою
команди /opt/unetlab/wrappers/unl_wrapper -a fixpermissions (рис.3.21).
Рис. 3.21 – Зміна прав доступу
3.4.3 Встановлення образів vIOS
Встановлення образів – необхідний етап реалізації моделі ЦОД.. Для
цього використовується vIOS - сервер віртуального вводу-виводу [11]. vIOS це
програма, розташована в логічному розділі. Дана програма полегшує спільне
використання фізичних ресурсів введення-виведення між клієнтськими
логічними розділами в межах одного сервера.
Для встановлення vIOS образів необхідно створюємо на сервері два
каталоги viosl2-15 і vios-15. Після цього завантажуємо в створені каталоги
образи і конвертуємо їх в *.qcow2 формат за допомогою команди
/opt/qemu/bin/qemu-img convert -f vmdk -O qcow2 vIOS-L2.vmdk virtioa.qcow2
(рис.3.22). Після цього видаляємо файл з форматом *.vmdk.
Рис. 3.22 – Конвертація образу в *.qcow2 формат
Лист
ЧДТУ.21.20105.008 ПЗ 46
Змін. Лист № докум. Підпис Дата
Змінюємо права на доступ для всіх доданих образів за допомогою
команди /opt/unetlab/wrappers/unl_wrapper -a fixpermissions.
Після встановлюються в середовищі EVE-NG образи Cisco IOL. Під IOL
мається на увазі IOS On Linux або, під IOU - IOS On Unix. IOL це симулятор
Cisco, доступний тільки для внутрішнього використання [12,13,14].
3.5 Налаштування MAIN роутера
Необхідно налаштувати вхідні WAN-ліній від провайдерів для
балансування навантаження сервісів хмарного ЦОД.
Спершу виконуємо ініціалізацію зовнішніх інтерфейсів маршрутизатора
MAIN (рис.3.23)
Рис.3.23 - налаштування балансування вхідних WAN-ліній для 2х
провайдерів на роутері MAIN
Лист
ЧДТУ.21.20105.008 ПЗ 47
Змін. Лист № докум. Підпис Дата
Для створеного у віртуальному емуляторі мережевому soft-середовищі
закладаємо надмірність. Надмірність є одним з найважливіших аспектів для
створюваного хмарного ЦОД на стороні глобальної мережі WAN ( реалізується
кількома каналами WAN, що сходяться на одному маршрутизаторі).
Найоптимальніший спосіб досягнення надмірності WAN на
маршрутизаторі MAIN полягає у використанні надійних резервних статичних
маршрутів з відстеження IP SLA [15].
IP SLA – це функція, включена в програмне забезпечення Cisco IOS, яка
дозволяє аналізувати рівні обслуговування для IP додатків та сервісів,
перевіряти якість обслуговування (QoS) на відповідність параметрам, та
допомагає виявляти та локалізувати проблеми в каналах мережі. IP SLA
використовує технологію активного моніторингу трафіку (коли тестові пакети
додаються до активного з'єднання) для моніторингу безперервності трафіку в
компютерній мережі. В такому випадку маршрутизатори виступають в ролы IP
SLA Responder, які забезпечують точність виміряних даних у мережі. IP SLA
збирає інформацію про затримку, джиттер, втрату пакетів, їх шляхи,
послідовність відправки та багато інших потрібних параметрів.
Маршрутизатор MAIN підключено до двох каналів WAN – ISP1 та ISP2.
При використанні команди ip sla schedule 2 створюється трек, який
відстежуватиме стан операції IP SLA. Якщо від IP-адреси наступного хопу
немає відгуків на пінг, трек відключиться та почне працювати, коли SLA почне
знову отримувати пінг-відповідь (рис.3.24).
Рис.3.24 – створення каналу для відслідковування та балансування трафіку
назовні
Лист
ЧДТУ.21.20105.008 ПЗ 48
Змін. Лист № докум. Підпис Дата
Маршрутизація на основі політик (policy based routing, PBR) дозволяє
маршрутизувати трафік на підставі заданих політик, тоді як у звичайній
маршрутизації, тільки IP-адреса одержувача визначає, яким чином буде
переданий пакет. Параметр permit означає, що пакети, які потрапляють до
опису match, будуть надіслані так як описано в set, тобто через балансування
трафіку з перевіркою доступності IP 1.1.1.1 по каналу 123 за стандартною
таблицею маршрутизації. Аналогічні налаштування виконується по каналу
124 балансування (рис.3.25).
Рис.3.25 -
Перевіряємо роботу створеної системи балансування при нестабільному
трафіку на лініях WAN від провайдерів ISP1 та ISP2. Для цього стану роботи
зовнішнього каналу скористаємося командою sh ip sla statistics
details (рис.3.26)
Лист
ЧДТУ.21.20105.008 ПЗ 49
Змін. Лист № докум. Підпис Дата
Рис.3.26 - перевірка роботи створеної системи балансування при
нестабільному трафіку на лініях WAN від провайдерів ISP1 та ISP2
Налаштування мережевих інтерфейсів Ethernet0/0, Ethernet0/1
Ethernet0/2, Ethernet0/3, системи перенаправлення портів, алгоритмів
шифрування для ssh-протокола клієнта і сервера віддаленого керування
створеною в хмарі GCP мережевою емуляцією ІКС ЦОД показані на рис.3.27.
Лист
ЧДТУ.21.20105.008 ПЗ 50
Змін. Лист № докум. Підпис Дата
Рис.3.27 – налаштування інтерфейсів мережі, протоколі та системи
перенаправлення портів
Таким чином, сегмент мережі LAN2 маршрутизується як одна мережа.
3.6 Налаштування роутера Office2
3.6.1 Створюємо та конфігуруємо сабінтерфейс для роутера Office2. Для
цього обираємо логічний інтерфейс Ethernet 0/1.2. (рис.3.28). Налаштовуємо
інкапсуляцію магістрального з'єднання як dot1q. (802.1Q – стандарт IEEE).Далі
перевіряємо правильність налаштування даного транку (рис.3.28).
Лист
ЧДТУ.21.20105.008 ПЗ 51
Змін. Лист № докум. Підпис Дата
Рис.3.28 - Створення та конфігурування сабінтерфейсу для роутера Office2
Налаштовуємо тунелювання порту. В даному випадку
використовуються тунелювання по стандарту 802.1Q для підтримки цілісності
VLAN клієнта в мережі постачальника послуг. Налаштовуєємо тунельний
порт на граничному комутаторі MAIN в мережі постачальника послуг і
підключаєте його до магістрального порту 802.1Q на інтерфейсі
маршрутизатора, створюючи асиметричне посилання. Тунельний порт
належить до однієї VLAN, яка призначена для тунелювання.
Таким чином, налаштування soft-емуляції комунікаційної інфраструктури
захищеного ЦОД заверешно. Далі необхідно перейти до розгортання сервісів
ЦОД в хмарі GCP.
3.7 Розгортання сервісів ЦОД в хмарі
Для того, щоб створена модель почала виконувати функції з обробки
даних необхідно розгорнути в ній необхідні програмні додатки.
Лист
ЧДТУ.21.20105.008 ПЗ 52
Змін. Лист № докум. Підпис Дата
Використаємо програму Docker для розгортання додатків, що
реалізують функції обробки даних в хмарному ЦОД. Даний інструмент
призначений для управління ізольованими контейнерами в ОС Linux. Docker
має засоби, які дозволяє керувати контейнерами на рівні ізоляції процесів.
Таким чином, програма Docker дозволяє запускати довільні процеси в
режимі ізоляції, після чого переносити та клонувати сформовані для них
контейнери в яких розміщені CMS WordPress. Таким чином, Docker створює,
обслуговує і підтримує контейнери.
3.7.1 Вмикаємо віртуальну машину Windows, необхідну для роботи
Docker for Windows (рис.3.29).
Рис.3.29 - ввімкнення віртуальної машини Windows
Для встановлення CMS WordPress в Dockers достатньо запустити його в
docker командою:
docker run --name love-wordpress -p 8080:80 -d wordpress
Лист
ЧДТУ.21.20105.008 ПЗ 53
Змін. Лист № докум. Підпис Дата
Після створення віртуального контейнеру з образу відкриваємо браузер,
переходимо за посиланням http://localhost:8080, та отримуємо доступ до
WordPress (рис.3.30):
Рис. 3.30 – запущений з віртуального контейнера в Docker CMS WordPress
Аналогічним чином встановлюємо з віртуальних контейнерів інші
необхідні додатки, які забезпечують роботу ЦОД.
Лист
ЧДТУ.21.20105.008 ПЗ 54
Змін. Лист № докум. Підпис Дата
ЗАГАЛЬНІ ВИСНОВКИ
В ході виконання роботи було досягнуто мету – створено модель
хмарного захищеного ЦОД на базі певних, обраних в ході аналізу технологій
віртуалізації. Для цього було:
- проаналізовано структуру та задачі хмарних сервісів та центрів обробки
даних, характерних для конкретної інформаційно-комунікаційної
системи;
- сформовано функціональний профіль захищеності інформації
відповідно до структури інформаційно-комунікаційної системи
підприємства, який ставить вимоги по підвищеним вимогам до захисту
цілісності та доступності інформації в АС класу 3;
- обрано платформу GCP для розміщення віртуальної інфраструктури
ЦОД VSP та технологію віртуалізації EVE-NG;
- проведено практичну реалізацію моделі хмарного захищеного ЦОД та
розгорнутий тестовий сервіс WordPress для ЦОД в середовищі
віртуалізації.
Лист
ЧДТУ.21.20105.008 ПЗ 55
Змін. Лист № докум. Підпис Дата
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Чим VPS відрізняється від VDS? [Електронний ресурс] // Блог
HyperHost – Режим доступу до ресурсу: https://hyperhost.ua/info/uk/chim-vps-
vidriznyaetsya-vid-vds.
2. Mell, Peter and Grance, Timothy. The NIST Definition of Cloud
Computing (англ.). Recommendations of the National Institute of Standards and
Technology. NIST (20 October 2011). Дата звернення: 6 листопада 2011.
Архівовано 21 березня 2012 року.
3. Cloud Computing: Principles, Systems and Applications / Nick
Antonopoulos, Lee Gillam. — L.: Springer, 2010. — 379 p. — (Computer
Communications and Networks). — ISBN 9781849962407.
4. VPS-хостинг и облачный хостинг: что выбрать и в чем разница?
[Електронний ресурс] // «Habr». – 2015. – Режим доступу до ресурсу:
https://habr.com/ru/company/ruvds/blog/320880/.
5. Класифікація автоматизованих систем і стандартні функціональні
профілі захищеності оброблюваної інформації від несанкціонованого доступу.
НД ТЗІ 2.5-005 -99. ДСТСЗІ СБ України. Київ. – 21 с., 1999.
6. Критерії оцінки захищеності інформації в комп’ютерних системах
від несанкціонованого доступу. НД ТЗІ 2.5-004 -99. ДСТСЗІ СБ України. Київ.
– 61 с., 1999.
7. Harvey C. AWS vs. Azure vs. Google Cloud: 2021 Cloud Platform
Comparison [Електронний ресурс] / Cynthia Harvey // TechnologyAdvice –
Режим доступу до ресурсу: https://www.datamation.com/cloud/aws-vs-azure-vs-
google-cloud/.
8. Google Cloud Free Program. Compare AWS and Azure services to
Google Cloud [Електронний ресурс] // Carbon neutral. - August 31, 2021. – Режим
доступу до ресурсу: https://cloud.google.com/free/docs/aws-azure-gcp-service-
comparison.
Лист
ЧДТУ.21.20105.008 ПЗ 56
Змін. Лист № докум. Підпис Дата
9. EVE-NG Community Cookbook. Режим доступу до сайту:
https://www.eve-ng.net/index.php/documentation/community-cookbook/
10. Simonsson, Jesper; Zhang, Long; Morin, Brice; Baudry, Benoit;
Monperrus, Martin (2021). "Observability and chaos engineering on system calls for
containerized applications in Docker". Future Generation Computer Systems. 122:
117–129. arXiv:1907.13039. doi:10.1016/j.future.2021.04.001.
11. Додавання Vios образів. Режим доступу до сайту:
http://blog.netskills.ru/2016/07/10-unetlab-cisco-vios.html
12. Додавання образів Cisco IOL. Режим доступу до сайту:
https://networkhunt.com/how-to-add-cisco-iou-iol-to-eve-ng/.
13. Додання Dynamips образів. Режим доступу до сайту:
https://www.eve-ng.net/index.php/documentation/howtos/howto-add-cisco-
dynamips-images-cisco-ios/
14. Як створити власний хост для Windows EVE. Режим доступу до
сайту: https://www.eve-ng.net/index.php/documentation/howtos/howto-add-cisco-
dynamips-images-cisco-ios/
15. IP SLAs Configuration Guide, Cisco IOS Release 15M&T. Chapter:
Configuring IP SLAs ICMP Echo Operations [Електронний ресурс] // Cisco Inc –
Режим доступу до ресурсу: https://www.cisco.com/c/en/us/td/docs/ios-
xml/ios/ipsla/configuration/15-mt/sla-15-mt-book/sla_icmp_echo.html.
Лист
ЧДТУ.21.20105.008 ПЗ 57
Змін. Лист № докум. Підпис Дата