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

Публічна чи приватна хмара?

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

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

Можливості кастомізації

Під індивідуальні вимоги клієнта та його бізнес-застосунків можна побудувати лише приватну хмару. У публічній ви отримуєте пул необхідних ресурсів із конкретними характеристиками, які не можна кастомізувати під конкретні завдання. У приватній хмарі, навпаки, можна обрати бажану кількість процесорів з певними параметрами (частота, покоління, виробник), об’єм та інші характеристики оперативної пам’яті, розміри сховища та отримати інші компоненти для своїх задач – наприклад, конкретні моделі відеокарт.

Обсяги споживаних ресурсів

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

Керування даними

Окремі бізнес-застосунки регулярно обмінюються даними з локальним сховищем на стороні клієнта або зі сторонніми ресурсами. Під час оцінювання можливості міграції всі подібні взаємозв’язки мають бути проаналізовані та збережені або ж архітектура застосунку має бути перебудована з урахуванням нових вимог хмарної ІТ-інфраструктури.

Інтеграція із застарілими застосунками

Деякі сучасні бізнес-застосунки досі працюють із застарілим програмним забезпеченням, що може викликати проблеми в процесі міграції в хмару. Якщо ці залежності не можна адаптувати для роботи в хмарній IT-інфраструктурі, варто розглянути можливість міграції таких застосунків у Private Cloud.

Масштабування

Публічна хмара масштабується практично миттєво – з моменту надсилання запиту до фактичного виділення ресурсів може пройти менш як година. Приватна хмара щодо цього не така гнучка: на замовлення, постачання та введення в експлуатацію допоміжних апаратних ресурсів може знадобитися 2-3 тижні. Але можна спрацювати на випередження: спланувати масштабування та заздалегідь надіслати запит на додаткові ресурси у провайдера.

Вартість володіння

У моделі IaaS до певної конфігурації розміри регулярних платежів за порівнянних обсягів ресурсів будуть нижчими, ніж у Private Cloud. З невеликою кількістю ресурсів у останнього буде вищою сукупна вартість володіння внаслідок появи інсталяційного платежу. Якщо IT-інфраструктура досягла таких розмірів, що її доцільно виносити у приватну хмару, розмір щомісячного платежу здебільшого буде нижчим, ніж при сплаті аналогічного обсягу ресурсів у публічній хмарі.

Відповідність специфічним вимогам

В IaaS ви можете встановлювати ОС та застосунки, в той час, як у Private Cloud у вас буде прямий доступ до апаратної частини IT-інфраструктури та гіпервізору. Це важливо, якщо ви плануєте отримати більше інструментів для контролю та керування, а також самостійно займатись адмініструванням, щоб оптимізувати інфраструктуру під конкретні бізнес-задачі.

Критерії оцінки застосунків

Після вибору хмарної моделі та сервісів необхідно переконатися у відсутності технічних обмежень на міграцію та розпочати підготовку до перенесення бізнес-застосунків.

Архітектура

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

Застосунки з багаторівневою архітектурою

Багато бізнес-застосунків створюються з використанням декількох рівнів, що дозволяє відокремити основні модулі від додаткових функцій. Так виглядає архітектура у трирівневому застосунку:

• рівень управління даними, що включає реляційні та інші компоненти баз даних;
• рівень бізнес-логіки, який використовує платформу застосунків чи контейнери (Java EE/Microsoft.NET);
• рівень подання, що відповідає за взаємодію з інтерфейсами користувача або іншими зовнішніми системами.

Застосунки з багаторівневою архітектурою можна переносити повністю або помодульно всередині кожного рівня. У будь-якому випадку кожен з них, як і компоненти всередині рівнів, необхідно оцінювати окремо, коли йдеться про перенесення в хмару. Також різні рівні застосунків можуть висувати різні вимоги до безпеки.

Вертикально- і горизонтально-масштабовані застосунки

Вертикально-масштабовану (scaling up) архітектуру мають застосунки, які можуть отримувати користь внаслідок виділення додаткових ресурсів (переважно процесорної потужності та пам’яті) на одному й тому ж сервері чи вузлі.

Горизонтально-масштабовану (scaling out) архітектуру мають застосунки, які можуть отримувати користь внаслідок збільшення кількості серверів чи вузлів. Відповідно, коли навантаження виросте, потрібно розгорнути додаткові вузли, а коли потреба в ресурсах зменшиться, невикористані сервери/вузли можна буде відключити. Такі застосунки з’явилися пізніше вертикально-масштабованих, а період їхнього активного поширення пов’язаний з масовим переходом на архітектуру х86.

Географічна доступність

Географія користувачів бізнес-сервісів буває досить широкою або, навпаки, до застосунку можуть звертатися лише з одного регіону. Це також необхідно врахувати до міграції у хмару. Щоб бути ближчим до своїх користувачів, великий бізнес може розмістити застосунки в кількох дата-центрах, розташованих у регіонах з найбільшою інтенсивністю запитів. Можливий інший варіант, коли окремі застосунки потрібно буде цілеспрямовано зробити недоступними в деяких локаціях з міркувань безпеки або інших причин. Таким чином, при виборі хмари важливо переконатися, що ви можете контролювати, оптимізувати та відстежувати їхню локацію та віддаленість від кінцевих користувачів.

Профілювання застосунків

Процедура профілювання дозволяє отримати реальну статистику про використання застосунку ще до міграції та оцінити реальні масштаби розгортання. Дані необхідно збирати протягом 10-15 днів поспіль, щоб зафіксувати всі щоденні та щотижневі відхилення від звичайного навантаження.

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

Додатково до збору статистики важливо виконати профілювання дій користувачів: оцінити кількість одночасно підключених клієнтів, швидкість виконання запитів та транзакцій, тривалість затримок. Ця інформація стане в пригоді для тестування роботи застосунку у хмарі та вибору оптимальної конфігурації хмарних ресурсів на основі результатів тесту, а також прогнозування витрат на хмарну IT-інфраструктуру.

Планування міграції

Останнім етапом перед міграцією застосунків у хмару буде розробка робочого плану та саме перенесення даних. Складність його реалізації безпосередньо залежатиме від типу застосунків та вимог до безперервності їх виконання. Якщо навіть мінімальний час простою критичний для бізнесу, бажано розбити процес міграції на кілька етапів так, щоб на будь-якому з них застосунки залишалися доступними. Перенесення до хмари першої частини сервісів буде тестовим. Використовуючи заздалегідь підготовлений план тестування та автоматичні тести, можна змоделювати дії різних типів користувачів та навантажень на додаток. За результатами буде зрозуміло, на яку кількість хмарних ресурсів вам необхідно надіслати запит до провайдера.

Чому важливо довірити реалізацію проєкту професіоналам

Аналіз, вибір оптимальної моделі хмари, розробка плану міграції та поетапне перенесення застосунків у хмару можуть виявитися складним завданням для компанії, в якій IT не є профільним напрямком. Тоді реалізацію даного проєкту краще довірити професіоналам, які накопичили велику експертизу та досвід у задачах подібної до вашої, а також розуміють, як саме застосунки взаємодіють один з одним, зовнішніми ресурсами та базовою IT-інфраструктурою.

З 2010 року команда сертифікованих фахівців Colobridge накопичила великий практичний досвід у питаннях міграції у хмару і не зупиняється на здобутому: співробітники регулярно підвищують компетенції та актуалізують знання. Вони виконають комплекс робіт з перенесення IT-інфраструктури та даних у публічну або приватну хмару, а також забезпечать цілодобову підтримку кількома мовами включно з українською.

Резюме

Під час вибору хмарної моделі, оцінювання застосунків та плануванні їхнього перенесення в хмару необхідно враховувати безліч факторів. Насамперед треба проаналізувати самі застосунки та їх сумісність з різними хмарними моделями. Після цього скласти плани міграції та тестування на кожному етапі перенесення даних. Хоча універсального підходу до міграції у хмару не існує, наведені в тексті рекомендації експертів допоможуть зробити цей процес максимально м’яким та безболісним для вашого бізнесу, мінімізувати ризики простою застосунків та на виході отримати очікувані результати.

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

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

Розглянемо організаційні та технічні аспекти міграції бізнес-застосунків у хмару.

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

Міграція бізнес-сервісів є процесом їх повторного розгортання на новій платформі. При цьому, якщо міграція виконується між сумісними платформами, вторинна компіляція застосунку не знадобиться.

У контексті хмарних обчислень нова платформа буде майданчиком – дата-центром, який побудували та обслуговують професіонали, – повністю підготованим для розміщення клієнтських застосунків. Завдання замовника полягає в тому, щоб обрати надійного провайдера: такого, який пропонує розмістити IT-інфраструктуру в сертифікованому дата-центрі, має велику IT-експертизу, хорошу репутацію та може надати професійну допомогу з міграцією та подальшим адмініструванням.

Звідки можна мігрувати бізнес-застосунки:

• окремий сервер (малий і середній бізнес);
• побудований клієнтом дата-центр (великий бізнес);
• орендований клієнтом сервер (локально чи у дата-центрі);
• сервер, розміщений у локально розгорнутій хмарі;
• SaaS-сервіс (імпорт або перенесення даних).

Куди саме у хмару можна мігрувати бізнес-застосунки:

• у загальнодоступну хмару;
• у приватну хмару;
• у гібридне середовище: комбінація приватної та загальнодоступної хмари.

Можливі окремі випадки перенесення даних. Наприклад, міграція типу P2V (Physical-to-Virtual), коли фізичний сервер повністю переноситься у віртуальне середовище включно з операційною системою, застосунками та їхніми даними. Існують спеціальні програмні рішення (конвертери), що дозволяють автоматизувати процес такої міграції та скоротити кількість помилок, які можуть виникнути при цьому. Якщо ж додаток був розміщений на віртуальному сервері, його достатньо змігрувати/конвертувати.

До початку міграції в хмару потрібно визначитися, які технічні та комерційні цілі ви переслідуєте. Часто компанія приймає рішення про міграцію у хмару, коли час оновлювати або масштабувати локальну IT-інфраструктуру з усіма наслідками. У такому випадку організації необхідно погодити модернізацію, виділити бюджет або оформити покупку в лізинг/кредит, а потім дочекатися постачання, розмістити та налаштувати обладнання.

Усе це тягне за собою великі витрати, які не завжди доцільні. Водночас деякі хмарні моделі (зокрема, Public Cloud) дозволяють швидко отримувати необхідні ресурси за запитом, підвищують доступність та ефективність роботи застосунків. Замовнику більше не доведеться витрачати тижні на модернізацію серверів, якщо зростуть потреби в обчислювальних ресурсах. У публічній хмарі їх можна отримати практично миттєво, що дуже важливо для застосунків зі стрибкоподібним попитом.

Є й інші причини, через які бізнес обирає хмарну модель роботи, – це покращена керованість, продуктивність та здатність до масштабування IT-інфраструктури. Можна повністю делегувати провайдеру міграцію даних, а також подальше керування інфраструктурою незалежно від того, в якій хмарі вона розміщуватиметься: приватній або публічній.

В окремих сценаріях хмарне середовище може стати ідеальним майданчиком для розгортання високопродуктивних програм. Балансувальник навантаження автоматично перерозподілятиме навантаження між кількома серверами в межах одного або декількох кластерів (для сервісів високої доступності), щоб гнучкіше реагувати на мінливий попит. А варіант оплати тільки за ресурси, які ви отримали від провайдера для своїх застосунків, дозволяє відчутно скоротити операційні витрати компанії.

Після визначення списку застосунків-кандидатів на перенесення у хмару необхідно детально вивчити технічні та організаційні аспекти міграції. Зробимо це на прикладі Public Cloud, який пропонують постачальники послуг у вигляді продукту з назвою IaaS (Infrastructure as a Service).

Перше, що необхідно зробити – це оцінити можливість перенесення обраних застосунків з урахуванням їх вимог до технічних параметрів обладнання та переліку підтримуваних ОС. Якщо у новій конфігурації обчислювальних ресурсів використовується несумісне з сервісом обладнання, може знадобитися перекомпіляція застосунку.

Що слід передбачити та вивчити до міграції IT-інфраструктури у публічну хмару?

Перш за все звернемо увагу на договір та SLA.

Необхідно зрозуміти, який рівень доступності гарантує постачальник послуг та яку фінансову відповідальність несе у разі невиконання зобов’язань. Тут важливо розрізняти доступність IT-інфраструктури (сервери, системи зберігання даних) від доступності мережної інфраструктури та доступності сервісів самого дата-центру, що обов’язково підтверджується сертифікатами. Якщо для ЦОД, розташованих у США, оцінити надійність можна за рівнем Tier (класифікація Uptime Institute), то якість роботи та надійність європейських дата-центрів зазвичай підтверджують відразу кілька сертифікатів: ISO/IEC 27001:2005, ISAE3402/SSAE16, ISO 9001, ISO/IEC 27001:2005 та інші.

На що ще варто звернути увагу у договорі та SLA:

• які послуги адміністрування можна запросити у провайдера;
• на яких умовах надається підтримка апаратного забезпечення, адміністрування віртуальних машин, ОС та окремих застосунків;
• які рівні обслуговування діють для конкретних продуктів і від чого вони залежать (варіанти: від локації дата-центру, типу дисків і віртуальних машин тощо);
• на які випадки не поширюється гарантія постачальника послуг;
• процедура виплати компенсації та її розміри у разі порушення SLA.

Важливо також звернути увагу на роботу БД на новій платформі.

В процесі міграції даних у Public Cloud застосунки можуть використовувати сервери бази даних, також розгорнуті у хмарі. Тоді провайдер має надати можливість реплікації чи перенесення сховища того типу, що є необхідним для роботи сервера баз даних.

У більшості випадків розгортання застосунків у публічній хмарі дозволяє бізнесу оптимізувати витрати на ІТ-інфраструктуру. Це можливо завдяки переходу від моделі фактичного володіння IT-інфраструктурою (капітальні витрати, CapEx) до оплати необхідних ресурсів за підпискою (операційні витрати, OpEx). Однак для застосунків, які повинні бути доступні постійно і вимагають великих обсягів обчислювальних ресурсів, довгострокова вартість володіння в публічній хмарі може виявитися вищою, ніж вартість розгортання та подальшої підтримки приватної хмари.

Ще одне важливе питання – управління безпекою та надійністю зберігання.

При розгортанні IT-інфраструктури в Public Cloud віртуальні машини, що знаходяться в оренді у різних клієнтів, можуть розміщуватись на єдиній фізичній інфраструктурі. Це зобов’язує ретельно підходити до оцінки того, наскільки відповідально провайдер вирішує завдання повної ізоляції віртуальних машин однієї від іншої. Для цього важливо, щоб постачальник послуг працював відкрито і, відповідно, дозволяв проводити аудит безпекових політик на відповідність вимогам, а також викладав результати аудиту в загальний доступ.

Деякі провайдери пропонують додаткові послуги для підвищення надійності та відмовостійкості клієнтської IT-інфраструктури. Прикладами таких послуг можуть бути BaaS та DRaaS.

BaaS («бекап як сервіс») дозволяє комплексно керувати створенням, зберіганням та відновленням даних із резервних копій. Провайдер надає відповідне за обсягом сховище на базі свого дата-центру, а також спеціалізоване ПЗ, яке дозволяє значною мірою автоматизувати роботу з бекапами та додатково убезпечити дані від випадкового чи навмисного видалення. Це може статися внаслідок несправності або вилучення обладнання, кібератак, пожеж та інших стихійних лих на майданчику клієнта, а також людського чинника.

DRaaS («аварійне відновлення як сервіс») дозволяє в стислі терміни та максимально ефективно відновлювати IT-інфраструктуру після серйозного збою з копії, що зберігається у хмарному репозиторії на боці провайдера. Замовник отримує ПЗ для синхронізації даних, а також допомогу в підготовці та реалізації плану аварійного відновлення.

Принцип роботи сервісу BaaS:

Джерело: veeam.com

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

У наступній частині ми розглянемо ще низку важливих питань у контексті піднятої теми – «Обсяги споживаних ресурсів», «Вартість володіння», «Профілювання застосунків» та ін.

Середній та великий бізнес цінує можливість швидко відновити IT-інфраструктуру після збою та повернути працездатність бізнес-додатків й цифрових сервісів. Щоб реалізувати це на практиці, зазвичай необхідні значні матеріальні та людські ресурси. З огляду на складність реалізації та вартість технічного рішення прийнятним для багатьох компаній може виявитися те, що називають Disaster Recovery, або аварійним відновленням.

Що таке Disaster Recovery

Disaster Recovery (або просто DR) – це набір інструментів та спеціалізоване програмне забезпечення, які вкупі допомагають швидко відновити IT-інфраструктуру, а також дані, роботу всіх систем та сервісів після збою.

Скільки коштують скомпрометовані або вкрадені дані:

До найчастіших причин збою відносяться: несправність серверного обладнання, вихід з ладу систем зберігання даних, вилучення техніки перевірчими органами (наприклад, для проведення експертизи), крадіжки та диверсії, видалення критично важливих для компанії даних помилково (викликається рядом факторів, включаючи людський), пожежа, потоп чи інше стихійне лихо. Компанії, які зберігають резервні копії даних на одному майданчику з робочою версією, також не захищені від подібних інцидентів, адже при їх настанні разом із майданчиком будуть втрачені й бекапи. Своєю чергою, ручне резервування не забезпечує високої швидкості відновлення IT-інфраструктури, може бути надто трудомістким для системного адміністратора і залежить від людського чинника.

Способи організації Disaster Recovery

У бізнеса є щонайменше три способи реалізувати післяаварійне відновлення IT-інфраструктури. Розглянемо кожен із них.

Зробити самостійно на своїй інфраструктурі

Варіант із розгортанням резервного майданчика on-premise, тобто на локальному майданчику – найбільш трудомісткий та дорогий. У цьому випадку компанії фактично доведеться збудувати інфраструктуру, яка дублює основну. А це пов'язане не лише з великими капітальними витратами, а й з необхідністю залучення фахівців із вузькими компетенціями.

Побудувати Disaster Recovery на орендованих фізичних серверах

Даний спосіб передбачає дублювання основної ІТ-інфраструктури на фізичних (окремих) серверах, орендованих в іншому дата-центрі, який може знаходитися в іншому місті, регіоні та навіть країні. Це більш відмовостійке рішення, адже шляхом географічного розподілу підвищується надійність зберігання резервних копій – у разі глобальних аварій на зразок пожежі чи повені резервний майданчик не постраждає разом з основною копією даних. З іншого боку, такий підхід має недоліки: відсутність гнучкості як при внесенні змін, так і при оплаті виділених фізичних ресурсів, коли зростуть і капітальні, і операційні витрати.

Розгорнути Disaster Recovery у хмарі

Хмарна інфраструктура, навпаки, приваблює своєю гнучкістю та простим масштабуванням. Тому багато компаній із сегмента SMB вважають за краще розгортати резервні копії IT-інфраструктури на хмарних платформах. Великий плюс у тому, що у хмарі можна прозоро керувати обсягом ресурсів, необхідних для виконання Disaster Recovery: резервувати продуктивне сховище для копії IT-інфраструктури разом із пулом необхідних потужностей для її розгортання або користуватися лише сховищем, а віртуальні ресурси отримати за фактом (втім, без гарантій з боку провайдера, що необхідні ресурси будуть доступні в потрібний момент).

Disaster Recovery as a Service

DRaaS (Disaster Recovery as a Service) є післяаварійним відновленням за моделлю «як послуга». У разі серйозного збою сисадмін за лічені хвилини зможе розгорнути у хмарі робочу копію IT-інфраструктури на резервному майданчику Disaster Recovery, наданому провайдером. Одночасно на основному майданчику розпочнуться відновлювальні роботи відповідно до заздалегідь розробленого плану післяаварійного відновлення (Disaster Recovery Plan). Іншими словами, сервісна модель Disaster Recovery – клонування інфраструктури в хмару у разі настання аварії та до її усунення на основному майданчику.

Головні переваги DRaaS перед іншими способами реалізації Disaster Recovery:

• швидке відновлення інфраструктури даних;
• оптимізація витрат на післяаварійне відновлення ІТ-інфраструктури;
• можливість реплікації «гарячих даних» як реального часу;
• гнучкі умови ліцензування спеціалізованого ПЗ провідних вендорів;
• після відновлення з архіву дані зберігають консистентність;
• просте масштабування рішення у хмарі.

Характеристики Disaster Recovery

На терміни та вартість післяаварійного відновлення впливають дві ключові характеристики – RTO та RPO. Що вони означають та на що впливають?

RTO

RTO (Recovery time objective, або «цільовий час відновлення») – це часовий проміжок, протягом якого IT-інфраструктура залишатиметься недоступною у разі аварії чи іншого інциденту. Допустиме значення RTO визначається специфікою та потребами бізнес. Фактично це час, протягом якого цифрові послуги компанії можуть простоювати без відчутних наслідків. Чим менше значення RTO, тим дорожче обійдеться послуга Disaster Recovery.

RPO

RPO (Recovery point objective, або «цільова точка відновлення») – це часовий проміжок, дані за який можуть бути втрачені без серйозних наслідків. Наприклад, для RPO, що дорівнює одній годині, резервне копіювання виконується чітко один раз на 60 хвилин. Так само й IT-інфраструктура після відновлення повернеться до того стану, в якому була за годину або менше до аварійного інциденту (на практиці багато залежить від того, коли саме стався збій – через 5, 15, 30 або 55 хвилин після створення копії). Чим меншим є значення RPO, тим частіше виконується резервування IT-інфраструктури та дорожче коштує DR-сервіс відновлення.

Визначити оптимальні значення RTO та RPO – означає знайти компроміс між вартістю вирішення післяаварійного відновлення та серйозністю наслідків простою для бізнесу.

Щоб визначити оптимальні параметри RTO/RPO, достатньо відповісти на два основні питання: чи будуть для вашого бізнесу актуальними дані тижневої/місячної давності, та втрату даних за який період ваш бізнес може пережити? (наприклад, за годину, добу, тиждень або інший час).

Згідно зі статистикою Colobridge, найчастіше клієнти обирають варіант робити резервне копіювання один раз на добу і переважно в нічний час – коли їх IT-системи найменш навантажені, а також зберігають останні сім архівних копій. Тоді максимальний обсяг даних, що теоретично може втратити бізнес, відповідає одному робочому дню. У такому сценарії розміри репозиторію в 1,3-1,4 рази перевищуватимуть обсяг зайнятих даних. Наприклад, віртуальна машина розмірами 100 ГБ займе у репозиторії до 140 ГБ.

Кому потрібний Disaster Recovery?

Зазвичай до послуги Disaster Recovery вдаються компанії, які прагнуть додатково захистити свою IT-інфраструктуру і готові виділити на це певну частку бюджету. Colobridge рекомендує послугу Disaster Recovery as a Service насамперед для корпоративного сектору – зокрема, клієнтам із фінансового та банківського сектору, інтернет-магазинам, аграрним компаніям та будь-яким іншим, у яких від доступності та стабільної роботи їх цифрових сервісів безпосередньо залежать доходи та репутація бізнесу.

Disaster Recovery у банківській сфері

Банки та інші фінансові установи дуже чутливі до простоїв, а втрата даних навіть за порівняно невеликий проміжок часу може призвести до серйозних наслідків як для банку, так і для його клієнтів. Тому саме в банках та компаніях fintech-сфери заведено оперувати мінімальними значеннями RTO та RPO, оскільки у разі збою витрати на відновлення IT-інфраструктури будуть меншими, ніж потенційні збитки від простою.

Disaster Recovery у сфері обслуговування

Тут ситуація із зупинкою IT-сервісів та недоступністю даних може бути не такою критичною, як у банку, проте на практиці все залежить від розмірів бізнесу. Для служби доставлення вантажів із сотнями відділень по всій країні вигідніше оплатити сервіс Disaster Recovery та застрахувати себе від форс-мажорних ситуацій, коли збитки у кілька разів перевищуватимуть витрати на цю послугу. Але, наприклад, для служби доставлення харчових продуктів у місті-стотисячнику залишитися без підключення до основного сервера на кілька годин буде менш критичною подією. Хоча й спричинить як матеріальні збитки, так і репутаційні втрати.

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

Чим відрізняються бекапи від Disaster Recovery?

Сервіси створення бекапів (наприклад, BaaS – Backup as a Service) передбачають використання хмарного репозиторію тільки для зберігання архівних копій, тоді як з DRaaS клієнт отримує сервіс дзеркалювання у хмарі провайдера IT-інфраструктури та можливість запускати віртуальні сервери в автоматичному режимі, якщо виникне аварійна ситуація.

DRaaS має значну перевагу перед BaaS: він дозволяє швидко включити необхідну точку, щоб як велика, так і невелика компанія якнайшвидше і бажано непомітно для клієнтів повернулися до нормального режиму роботи. Це стає можливим завдяки тому, що дані розміщуються на продуктивному сховищі замість того, щоб зберігатися в заархівованому вигляді, як у випадку з BaaS. Крім того, хмарний провайдер Disaster Recovery as Service пропонує більше налаштувань, можливість гнучкого керування частотою створення (за розкладом) та параметрами відновлення віртуальних машин із резервних копій.

Реплікація IT-інфраструктури у хмару за допомогою DRaaS зовсім не означає відмову від традиційних бекапів. Клієнти можуть користуватися цими двома інструментами одночасно: «гарячі дані» копіювати раз на кілька годин і зберігати протягом двох-трьох днів, а копії «негарячих систем» робити щодня та зберігати їх, наприклад, тиждень. Налаштування інфраструктури в концепції Disaster Recovery компанія робить відповідною під свої вимоги.

Глобальний тренд на міграцію в публічні хмари активізувався під час пандемії Covid-19 та відтоді не знижує обертів. Більш того, ключові консалтингові компанії відзначають зростання витрат на перенесення даних у хмару та очікують збереження цієї тенденції принаймні протягом найближчих трьох років. Водночас масовий перехід у хмари дозволив виявити деякі спільні для більшості компаній проблеми та змусив шукати шляхи їх вирішення.

За оцінками експертів McKinsey, у найближчі три роки глобальні витрати на перенесення даних у хмару сягнуть 100 млрд дол.

Бізнес прагне більш ефективно використовувати публічні хмари, але часто не може досягти успіху, тому що стикається з проблемами у процесі міграції даних та на пізніших етапах. Очікується, що до 2024 року більшість компаній витрачатиме на оплату IaaS, PaaS або SaaS до 80% бюджету, закладеного на розміщення IT-ресурсів. Однак для цього будуть потрібні певні зусилля з боку самого бізнесу та постачальників хмарних технологій.

Пандемію Covid-19 часто називають фактором, що значно прискорив темпи цифровізації бізнесу. Однак ще важливішим каталізатором став 1 трлн дол. – сумарна бізнес-цінність, яку потенційно можна отримати шляхом впровадження хмарних технологій. І поки одні компанії все ще не готові зробити хмари своєю конкурентною перевагою, інші втрачають час та гроші через низьку якість організації міграції.

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

З 2019 до 2021 року бізнес переніс близько 45% витрат на IT в хмару. Майже дві третини (65%) опитаних керівників повідомляли, що їхні компанії збільшили свої хмарні бюджети під час пандемії, а 55% – що розмістили більше робочих навантажень у хмарі, ніж планували спочатку. В абсолютній більшості випадків «хмарна історія» довела свою ефективність на практиці, тому ще 40% компаній планують прискорити темпи міграції до публічних хмар у майбутньому.

До 2024 середньостатистична компанія витрачатиме на хмарні продукти до 80% бюджету, виділеного на розміщення робочих навантажень.

Очікується, що з 2021 по 2024 роки у публічній хмарі витрати на розміщення вертикально масштабованих додатків (управління складом у роздрібній торгівлі, управління корпоративними ризиками в банківській сфері та іншими) щороку зростатимуть більш ніж на 40% порівняно з витратами на розміщення горизонтально масштабованих програм (наприклад, платформи для взаємодії з клієнтами). А компанії у сфері охорони здоров’я та виробництва планують витрачати приблизно вдвічі більше на вертикальні програми, ніж на горизонтальні.

Попри те, що компанії переносять дедалі більше робочих навантажень в публічну хмару, помилки в міграції, як і раніше, призводять до невиправданого зростання матеріальних витрат. За даними McKinsey, середньостатистична компанія щорічно витрачає на міграцію в хмару на 14% більше запланованого, а 38% організацій зіткнулися з тим, що перенесення даних на cloud-платформу зайняло як мінімум на 25% більше часу, ніж планувалося спочатку.

У глобальному масштабі підвищення витрат на 14% виражається в сотнях мільярдів доларів. Якщо не контролювати витрати в цьому напрямку, протягом трьох років вартість компаній, що зіткнулися з цією проблемою, може скоротитися більш як на 500 млрд дол.!

Більшість компаній до 35% своїх потреб в управлінні хмарними ресурсами задовольняють коштом залучення штатних IT-фахівців. Проте їхня частка зросте до 50% вже 2024 року. Це означає, що бізнес по всьому світу найближчим часом прагнутиме найняти або перекваліфікувати не менше 1 млн експертів у хмарних обчисленнях. Підвищений попит, мабуть, викличе ще більший дефіцит персоналу з відповідними навичками. Частково розв'язати цю проблему можна залученням системних інтеграторів.

У той час, як більшість компаній розв'язують проблеми з хмарною міграцією, що зайняла часу більш ніж заплановано, близько 15% компаній із загальної вибірки успішно перенесли більш ніж 60% витрат на розміщення бізнес-навантажень в хмару й зробили це в спрогнозовані терміни.

Аналіз показав, що серед тих, хто досяг успіху в питаннях міграції на cloud-платформи, на 32% частіше зустрічаються активно залучені до процесу керівники. У них на 9% більше шансів розробити детальну дорожню карту міграції та на 57% – найняти фахівців з необхідними навичками.

Хмарний продукт «інфраструктура як сервіс» та оренда виділеного сервера – дві популярні послуги, які мають і схожість, і принципові відмінності. В них по-різному реалізовано порядок виділення ресурсів, відрізняється вартість володіння і рівень контролю IT-інфраструктури. Як зробити обґрунтований вибір з урахуванням бюджету та поточних бізнес-потреб?

Головне про послуги IaaS та Dedicated Server

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

IaaS дозволяє швидко, зазвичай за кілька годин, отримати необхідний пул ресурсів і надалі масштабувати їх залежно від навантаження. Клієнт не інвестує в покупку обладнання чи ліцензії на систему віртуалізації, а адміністрування з його боку полягає в тому, щоб підтримувати роботу тільки ОС і встановленого ПЗ.

«Інфраструктура як сервіс» – це хмарна послуга, що орієнтована на клієнтів, які:

• потребують ресурсів найближчим часом (наприклад, стартапи);
• мають труднощі з оцінкою об’єму споживаних послуг навіть у короткостроковій перспективі;
• хочуть відмовитися від капітальних витрат на IT-інфраструктуру та перейти до операційних витрат;
• вже зіштовхувалися чи гарантовано зіштовхнуться з нерівномірним навантаженням на сервіси («високий сезон», дні розпродажі, переддень великих свят);
• планують делегувати непрофільні завдання з адміністрування IT-інфраструктури постачальнику послуги.

В разі Dedicated Server клієнт орендує повністю апаратно-програмний комплекс, що розташований на території ЦОД провайдера. Додатково до виділених серверів можна орендувати мережеве обладнання, СЗД та ПЗ, а також придбати послуги за сервісною моделлю (as a Service), наприклад Firewall as a Service. З Dedicated Server клієнт отримує доступ до обладнання Enterprise-рівня провідних світових вендорів: Dell, HPE, SuperMicro, Cisco, Juniper, Brocade та інших.

Глобальний ринок Dedicated Server зростає швидкими темпами: за даними IDC, до 2025 року він перевищить 7,6 млрд дол, щороку зростаючи в середньому на 150%.

IaaS та Dedicated Server: чим схожі ці продукти?

• Завдання з адміністрування IT-інфраструктури можна частково або повністю делегувати постачальнику послуги;
• Для розміщення даних використовується апаратне забезпечення провідних брендів Enterprise-сегмента;
• Підвищується доступність та відмовостійкість IT-інфраструктури, у тому числі шляхом винесення її за межі регіону/країни;
• Обладнання надійно захищене від фізичного знищення та крадіжки;
• Є можливість заручитися експертною допомогою фахівців з великим досвідом роботи;
• Доступне горизонтальне масштабування IT-інфраструктури.

Принципові відмінності між IaaS та Dedicated Server

Ізоляція. В Dedicated Server вплив «сусідів» виключено, тому що обладнання та дані ізольовані. В IaaS такий вплив теоретично можливий у невеликій кількості випадків, але постачальники послуг постійно працюють над тим, щоб його мінімізувати.

Швидкість введення в експлуатацію. В IaaS користуватися ресурсами у хмарі для розміщення IT-інфраструктури можна вже протягом найближчих кількох годин (максимум доба) після укладення договору. В Dedicated-моделі – через кілька днів або тижнів, якщо клієнт замовив нестандартну конфігурацію та обладнання для неї буде поставлятися за індивідуальним замовленням.

Швидкість масштабування. У Dedicated Server виділення додаткових ресурсів може тривати кілька днів, в IaaS-моделі – кілька годин або хвилин. Навіть якщо на складі є все необхідне обладнання для масштабування виділеного серверу, не можна просто взяти й зупинити його: необхідно як мінімум вибрати вдалий час, коли навантаження буде найменшим. У IaaS можна додавати обчислювальні ресурси без зупинки сервісів, якщо це, наприклад, ресурси зберігання.

Можливості кастомізації. Вони практично безмежні в Dedicated-послузі, але обмежені в моделі «інфраструктура як сервіс». У ній клієнт не може змінювати конфігурацію хмари на запит – наприклад, замість процесорів Intel вибрати AMD.

Фізичний контроль над обладнанням. У IaaS ресурси постачальника розподілені між багатьма клієнтами. Якщо в рамках послуги Dedicated Server клієнт орендує інфраструктуру з кількох серверів, які займають цілу стійку, він має можливість контролювати їх фізично: повісити замки, встановити камери та датчики. З одним-двома серверами, які будуть ділити стійку з обладнанням інших клієнтів, фізичний контроль є недоцільним.

Вартість. Вона залежить від масштабів та вимог до інфраструктури. Якщо клієнту потрібен невеликий пул ресурсів, отримати та в майбутньому масштабувати їх у хмарі буде дешевше. Щойно обсяг необхідних ресурсів можна буде порівняти з можливостями виділеного сервера, орендувати залізо стане дешевше, ніж пул віртуальних ресурсів із додатковими послугами за сервісною (as a Service) моделлю.

Dedicated Server та IaaS: основні помилки при виборі

Іноді здається, що під ваші завдання ідеально підходить IaaS, але на практиці виявляється, що Dedicated Server краще відповідає потребам бізнесу та навпаки. У фахівців Colobridge є кілька подібних кейсів. Чому таке трапляється та коли дійсно має сенс переглянути рішення про вибір?

Не був проведений аудит поточних навантажень. Через це ви первісно неправильно оцінили навантаження на бізнес-додатки. Ситуацію можна легко виправити, якщо врешті решт ви виберете IaaS, але це критично для клієнтів послуги Dedicated Server. В останньому випадку не варто розраховувати на оперативну зміну конфігурації виділеного сервера через низку технічних та організаційних моментів. Водночас в моделі «інфраструктура як сервіс» можна провести тестування навантаження до укладення договору, а потім швидко – практично на льоту – змінювати конфігурації виділених серверів.

Не врахований стрибкоподібний характер навантажень на бізнес-додатки. Dedicated-модель знову програє в гнучкості, тому що не дозволяє в стислий термін отримати додаткові ресурси. Якщо на рівні проєкту не було закладено достатньо запасу потужності, у користувачів можуть виникнути проблеми з доступом. У хмарній моделі IaaS завжди можна відправити запит провайдеру та отримати рівно стільки ресурсів, скільки необхідно найближчого дня або навіть найближчу годину.

Бюджет не відповідає вимогам щодо відмовостійкості. Резервування критично важливих даних коштує грошей. Тому якщо компанія має намір виключити ймовірність появи єдиної точки відмови в її IT-інфраструктурі, але не має у своєму розпорядженні достатніх фінансових ресурсів, вона може зупинитися на IaaS. Це відмовостійке рішення, всі апаратні компоненти якого задубльовані на рівні провайдера.

Немає бажання або можливості адмініструвати IT-інфраструктуру. Клієнт, що замовляє виділений сервер, змушений залучати спеціалістів до адміністрування апаратної частини, гіпервізора та всього, що знаходиться на нижніх рівнях. У IaaS з боку клієнта потрібно лише обслуговувати ОС на віртуальних машинах, решта знаходиться у зоні відповідальності постачальника послуги.

Обчислювальні ресурси потрібні «на вчора». Виділити їх швидко, протягом доби, дозволяє модель «інфраструктура як сервіс». На те, щоб придбати компоненти та ввести виділений сервер в експлуатацію, потрібно більше часу.

Необхідно робити регулярні бекапи даних. В Dedicated Server треба самостійно налаштовувати ПЗ для резервного копіювання. З IaaS клієнт отримує готовий сервіс, де це створення резервних копій відбувається автоматично.

В Colobridge можна не тільки замовити IaaS чи Dedicated Server, але й скористатися гібридною моделлю – практично всі послуги та продукти можна міксувати довільним чином: разом з публічною хмарою орендувати виділене фізичне обладнання, а з виділеним сервером користуватися сервісними послугами у хмарі. Прийняти остаточне рішення на користь конкретного рішення для розміщення IT-інфраструктури допоможуть фахівці.

На відміну від традиційного програмного фаєрволу, що призначений для захисту комп’ютера чи сервера, «фаєрвол як сервіс» використовується для одночасного захисту кількох клієнтських IT-інфраструктур. Втім це не єдина відмінність такого підходу від традиційних апаратних та програмних рішень.

Традиційний фаєрвол (також відомий як міжмережевий екран або брандмауер) захищає від загроз з локальної мережі або інтернету тільки той пристрій, на якому він встановлений. Це програмне забезпечення здійснює базову фільтрацію мережевого трафіку, у разі небезпеки попереджаючи користувача про ймовірні загрози, або блокуючи потенційно небезпечні з’єднання згідно з певними правилами.

«Фаєрвол як сервіс» (Firewall as a Service, FWaaS) працює на стороні провайдера і являє собою відмовостійкий кластер апаратно-програмних міжмережевих екранів, ресурси яких надаються клієнтам за сервісною моделлю. FWaaS так само виконує перевірку безпеки та служить бар’єром між компонентами IT-інфраструктури клієнта та підключеними до неї системами та мережами.

Як працює FWaaS

Фаєрволи можна умовно поділити на два типи.

Програмний встановлюється на фізичні або віртуальні пристрої й призначений для відстеження вхідного та вихідного трафіку, а також блокування потенційних загроз. Це спеціалізоване програмне забезпечення може встановлюватись безпосередньо на комп’ютер або на сервер, що може виступати в ролі програмного маршрутизатора. Ключовими перевагами програмних міжмережевих екранів можна вважати нижчу порівняно з апаратними вартість, здатність захищати окремі сегменти локальних мереж зсередини, а також можливість розгортати їх на користувацьких комп’ютерах та наявних серверах. До недоліків відноситься обмежена на тлі апаратних рішень пропускна спроможність та в деяких випадках досить трудомістке налаштування.

Апаратний фаєрвол являє собою обладнання, що спроєктовано безпосередньо для обробки трафіку, та працює під керуванням спеціального програмного забезпечення. Така система захищає від мережевих атак підключену до нього фізичну або віртуальну ІТ-інфраструктуру.

Серед популярних міжмережевих екранів можна відзначити такі рішення як Cisco ASA, FortiGate, CheckPoint, SonicWALL та WatchGuard. Вони, як і притаманно апаратним брандмауерам, ефективніші за програмні рішення, вирізняються високою продуктивністю, надійністю, а також простотою підключення та використання. Головним недоліком апаратного фаєрволу є висока вартість, що робить недоцільним його використання для індивідуального захисту.

«Фаєрвол як сервіс»

Фаєрвол, який пропонується за сервісною моделлю, по суті є різновидом апаратного. Це обладнання під керуванням спеціалізованого ПЗ, що дозволяє створювати віртуальні домени – кожен з них обслуговуватиме певного клієнта та забезпечуватиме максимально можливу ізоляцію навантажень клієнтів один від одного. За аналогічним принципом працює віртуалізація, де ізоляцію віртуальних машин забезпечує гіпервізор.

Фактично з послугою «фаєрвол як сервіс» клієнт отримує потужне та ефективне апаратне рішення для захисту будь-якої IT-інфраструктури: хмарної, фізичної чи гібридної. Такий підхід дозволяє зробити дорогі апаратні фаєрволи більш доступними, оскільки передбачає використання потужного пристрою для захисту кількох клієнтських IT-інфраструктур. По суті це той самий принцип, що лежить в основі популярної соціальної економічної моделі шерінгу, коли завдяки поділу якісь цінні ресурси стають доступними для спільного одночасного використання.

Як захищають від загроз міжмережеві екрани нового покоління

Наразі провайдери використовують для захисту від загроз міжмережеві екрани наступного покоління – NGFW (Next Generation FireWall). Такі пристрої відповідають за маршрутизацію трафіку та після поділу на віртуальні домени (інстанси) можуть обслуговувати декілька навантажень клієнта. Потрібна кількість віртуальних інстансів на один NGFW-пристрій визначається залежно від продуктивності обладнання та кількості мережевих портів. Відповідно клієнт замовляє стільки інстансів, скільки йому необхідно для ефективного захисту наявної IT-інфраструктури від небажаного трафіку.

Серед NGFW-пристроїв популярністю користуються, наприклад міжмережеві екрани Fortinet FortiGate. Тому саме на їх базі Colobridge побудувала свою платформу Firewall as a Service. Це апаратно-програмні комплекси з великою кількістю мережевих портів та підтримкою кластеризації. У кожному комплексі встановлено кілька мережевих процесорів для обробки мережного трафіку і ще кілька потужних спеціалізованих чипів для забезпечення функцій безпеки.

Що потрібно знати користувачам послуги FWaaS

«Фаєрвол як сервіс» дозволяє забезпечити захищений доступ до IT-інфраструктури клієнта та реалізувати різні сценарії доступу до його ресурсів. Це економічно обґрунтований інструмент для комплексного захисту від різних типів загроз: шкідливого ПЗ, цільових кібератак і розширених постійних загроз, включаючи новітні – завдяки регулярному оновленню відповідних баз NGFW-пристрою.

Ключові можливості FWaaS:

• міжмережева фільтрація трафіку;
• виявлення та запобігання атак;
• контроль за використанням додатків;
• фільтрація вебконтенту;
• захищений віддалений доступ;
• пріоритезація трафіку;
• блокування джерел нелегітимного трафіку;
• захист вебзастосунків.

Клієнти, які обирають FWaaS як додаткову послугу до хмарного або фізичного розміщення своєї IT-інфраструктури, отримують захист мережевого трафіку в режимі реального часу, гарантії відсутності єдиної точки відмови в системі безпеки та можуть прогнозувати свої витрати на відбиття мережних загроз. Фахівці Colobridge рекомендують використовувати «фаєрвол як сервіс» для захисту віртуальних машин у хмарі, приватних та гібридних хмар, виділених серверів – будь-якої реалізації корпоративної IT-інфраструктури, а також загалом для захисту бізнес-додатків.

Тема безпеки ІТ-інфраструктури наразі актуальна як ніколи. Компанії можуть бути атакованими з різних причин: зовнішні загрози, недобросовісні конкуренти або інші зацікавлені особи, хакери-аматори. Але в будь-якому випадку наслідки можуть бути сумними. Тому бізнесу важливо пам’ятати про потенційні загрози для своїх ІТ-систем та застосовувати послідовний підхід до організації цифрового захисту.

Інфраструктура хмарних обчислень включає безліч компонентів на кількох рівнях – фізичні сервери, мережі, системи віртуалізації, сховища, бази даних, програми тощо. Щоб повністю убезпечити свою інфраструктуру, компанії необхідно забезпечити захист кожної її складової.

Захист інформації на сервері

Хоча основа хмарної інфраструктури – віртуалізація, безпека фізичних серверів є дуже важливою. Йдеться не тільки про те, щоб розмістити їх на майданчику, що добре охороняється. Потрібно також забезпечити контроль над вхідними та вихідними з’єднаннями та налаштувати підключення серверів лише до певних діапазонів IP-адрес.

Фахівці Colobridge також наголошують на тому, що обмін даними повинен відбуватися по зашифрованих і добре захищених каналах (наприклад, VPN), щоб уникнути потенційних атак Man-in-the-middle. Не можна використовувати вразливі протоколи, такі як Telnet, FTP, HTTP. Їх можуть замінити безпечні аналоги – SSH, SFTP (Secure FTP), HTTPS.

Крім того, рекомендується використовувати двофакторну аутентифікацію.

Захист мережевих з’єднань

Аби мережа не стала вразливим місцем у хмарній інфраструктурі, рекомендується дотримуватися кількох перевірених правил.

• Налаштуйте списки керування доступом (ACL) для VPN.
• Використовуйте додаткові рішення для безпеки, такі як firewall-as-a-Service (FWaaS) та firewall веб-програм (WAF), щоб швидко та активно виявляти та блокувати шкідливий трафік.
• Якщо можливо, розгорніть інструменти автоматичної перевірки хмарних мереж (Cloud Security Posture Management (CSPM) для виявлення вразливих конфігурацій.

Захист гіпервізора

Компрометація гіпервізора (гіперджекінг) дозволяє зловмиснику отримати доступ до всіх хостів та віртуальних машин компанії. Комп’ютери, де працюють гіпервізори, мають бути добре ізольовані від загальних мереж.

Доступ до гіпервізору потрібно ретельно контролювати, мінімізуючи привілеї для всіх користувачів, які не є адміністраторами. Особливу увагу варто приділити машинам, на яких запущений монітор VM і ПЗ для управління віртуалізацією, таке як VMware vSphere. Засоби для розгортання та тестування нового гіпервізора теж необхідно зробити безпечними.

Захист хмарного сховища

У хмарних системах сховища є віртуалізованими пулами зберігання. Для них діють такі правила захисту.

• Складіть чіткий список пристроїв або програм, які потребують доступу до хмарного сховища.
• Забороніть доступ до сховища внутрішнім користувачам, яким воно не потрібне.
• Видаляйте дані, що не використовуються, щоб зменшити поверхню атаки, а також забезпечити виконання зобов’язань перед клієнтами GDPR (Загальний регламент ЄС із захисту даних). Докладно про цей регламент ми неодноразово писали у своєму блозі.
• Використовуйте інструменти запобігання відтоку даних (DLP – Data Leak Prevention), щоб мати можливість швидко виявляти і блокувати підозрілі вихідні потоки даних, а також не допустити компрометації інформації – як зловмисної, так і випадкової.

Загальні загрози

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

Критоджекінг

Критоджекінг – це досить нова форма кібератаки. Зловмисники можуть отримати доступ до хмарних систем і використовувати їх обчислювальну потужність для майнінгу. Криптоджекінг виявити складно. Коли хакери використовують ресурси вашої хмарної системи, робота сервісів може сповільнюватися, і здається, що це відбувається через погане підключення до Інтернету або відсутність необхідних оновлень. Реальна ж причина проблеми стає зрозумілою пізніше.

Витік даних

Можливо, найбільш поширеною загрозою для хмарних обчислень є саме витік даних. Кіберзлочинці можуть отримати несанкціонований доступ до хмарної мережі або використовувати програми для перегляду, копіювання та передачі даних стороннім особам. Втрата інформації може призвести до порушення GDPR та великих штрафів для бізнесу, а водночас до репутаційної шкоди та втрати довіри клієнтів.

Відмова в обслуговуванні

Одна з найбільш руйнівних для бізнесу – DDoS-атака, яка може надовго зробити послуги компанії недоступними для клієнтів. Кіберзлочинці «забивають» систему дуже великим обсягом трафіку, з яким сервери не в змозі впоратися. Система йде або у відмову, або корисний трафік просто не може «достукатися» до сервера через перевантажені канали.

Злом акаунтів

Можливо, найбільшою загрозою для бізнесу є проблема злому облікових записів. Зловмисники можуть використовувати такі методи, як брутфорс та фішингові електронні листи, щоб отримати доступ до ключових облікових записів компанії.

Ризикові програми

Іноді власна ІТ-система може бути безпечна, а безпосередню загрозу становлять зовнішні додатки, які активно використовуються співробітниками. Працівники компанії повинні обережно підходити до встановлення необхідних для роботи програм. Своєю чергою, ІТ-фахівцям необхідно стежити за тим, щоб ПЗ регулярно оновлювалося, а на робочі комп’ютери встановлювалися всі необхідні патчі.

Висновок

Виклики, пов’язані з безпекою, при використанні хмарної інфраструктури складні, але переборні. Щоб з ними впоратися, компаніям слід виробити єдину стратегію безпеки, грамотно вибудувати процеси, що забезпечують захист усіх компонентів системи, включаючи реагування на інциденти. Важливо вибрати надійного хмарного провайдера, тоді кілька рівнів захисту, наприклад, захист мережі, серверів та гіпервізора, буде його зоною відповідальності, а ІТ-команда зможе звузити пул своїх завдань та сконцентруватися на безпеці сервісів та додатків, що використовуються компанією у хмарі.

Незважаючи на популярність публічних хмар, завжди є клієнти, під бізнес-вимоги яких підходять тільки приватні хмарні інсталяції. Про те, коли дійсно виправдане використання Private Cloud говорено вже немало, але ж на часі ще привернути увагу до цієї теми.

У приватної хмари є кілька специфічних особливостей, які виділяють її на тлі інших продуктів. Важлива відмінність Private Cloud полягає в тому, що клієнт може повністю контролювати свої дані та загалом IT-інфраструктуру, а доступні йому фізичні та віртуальні ресурси, які він використовує монопольно, надійно ізольовані від ресурсів інших клієнтів. Такий підхід дає змогу гнучкіше управляти навантаженнями, розміщеними в приватній хмарі.

За даними LogicMonitor до пандемії в публічних хмарах розміщувалося 23% робочих навантажень, у приватних - 25%. До 2025 року розрив збережеться, але сумарна частка хмар на тлі in-house зросте: 28% робочих навантажень розміщуватимуться в публічній хмарі, і 30% - у приватній.

Можна виділити дві моделі надання приватної хмари як сервісу.

Перша модель - клієнту надаються в оренду всі компоненти приватної хмари: сервери, порти необхідного типу і ємності, IP-адреси, сховище даних і оренда ліцензій. При цьому в зоні відповідальності провайдера залишається забезпечення працездатності кожного компонента інфраструктури, заміна компонентів в обумовлені в SLA терміни, закупівля і розширення ресурсів на вимогу замовника - покомпонентне або серверне. У зоні відповідальності клієнта залишається управління системою віртуалізації та її компонентами, налаштування всіх хмарних служб, їх оновлення та моніторинг. Крім того, клієнт керує самими віртуальними машинами, контролює виділення ресурсів і займається адмініструванням операційних систем.

Друга модель - клієнту надається IT-інфраструктура за першою моделлю, але провайдер бере на себе управління системою віртуалізації, виконує роботи з налаштування, оновлення та моніторингу всіх служб приватної хмари. Ця модель дає змогу клієнту делегувати значну частину рутинних робіт на провайдера, як порівняти з першою моделлю. Моніторинг і підтримка в режимі 24/7 дають змогу постачальнику послуг реагувати на інциденти в дуже короткі строки й оперативно приступати до усунення проблем. Клієнт при цьому керує тільки операційними системами віртуальних машин, вимагаючи від провайдера забезпечити їхню доступність.

Таким чином, в обох випадках клієнт обирає між тим, щоб розгортати свої додатки в середовищі віртуалізації або на "голому" залізі, без віртуалізації. При цьому провайдер опціонально може брати участь у запуску середовища віртуалізації та застосунків або обмежиться тим, що надасть виключно обладнання.

У кожному випадку підбирається індивідуальне рішення під конкретні завдання клієнта і його вимоги до безпеки. При цьому відкриваються можливості для реалізації найрізноманітніших проєктів, адже клієнт може самостійно вибрати відповідний йому рівень відповідальності провайдера та делегувати йому такий обсяг завдань, який вважатиме потрібним з урахуванням специфіки навантаження.

Перша модель реалізації приватної хмари може бути цікава локальним провайдерам, які хочуть запропонувати своїм клієнтам додаткову послугу - розміщення IT-інфраструктури в дата-центрі за межами країни. Наприклад, на орендованих фізичних потужностях платформи Colobridge локальний провайдер може розгорнути хмарну інфраструктуру і продавати її ресурси своїм клієнтам як "хмара в Європі".

Ось декілька цікавих прикладів того, як відомі бренди з усього світу отримують користь від міграції в приватну хмару.

Бренд Villeroy & Boch, який вже багато десятиліть відомий своїми порцеляновими виробами, вирішив оновити підходи до комунікації з клієнтами. Німецькій компанії хотілося краще підготуватися до освоєння цифрового ринку, для чого вона перенесла IT-інфраструктуру в приватну хмару. Результати не змусили на себе чекати: тепер Villeroy & Boch може гнучко розширювати свої бізнес-додатки на нові магазини, підвищити стабільність роботи сервісів, на якісно новому рівні захищати конфіденційні дані клієнтів і збільшити частку продажів через інтернет. Також приватна хмара уможливила перехід на новий рівень автоматизації бізнес-процесів, спростила управління IT-інфраструктурою і дала змогу ефективніше використовувати обчислювальне обладнання.

Один з найбільших північноамериканських банків Regions Bank, у якого працює понад 1300 представництв по всій країні, вибрав Private Cloud, щоб отримати ізольоване середовище для бізнес-навантажень і в перспективі перейти на гібридну інфраструктуру. Розміщення даних у приватній хмарі додатково убезпечило їх від витоку, дало змогу швидше і з точнішими результатами виявляти інциденти, пов'язані з шахрайством. Усього через рік після переходу на модель Private Cloud у банку заощадили 10% витрат на утримання IT-інфраструктури, майже на третину знизили кількість попереджень про шахрайські дії з боку клієнтів, а також удвічі зменшили середній розмір добового збитку.

Некомерційна благодійна організація Hand in Hand India шукала під свої завдання недорогу, але досить гнучку IT-інфраструктуру, яку можна масштабувати в міру відкриття нових філій. З приватною хмарою вона отримала бажаний рівень продуктивності за посильну для неї ціну, а також убезпечила персональні дані людей, які зверталися до Hand in Hand India по допомогу.

Одна з найбільших фінансових організацій Австралії Suncorp Group обрала приватну хмару для розміщення своїх критично важливих застосунків і тестування нових продуктів Використання сховища зі специфічними характеристиками дало змогу компанії зробити її ресурси доступнішими для клієнтів, а віртуальні потужності гіперскейлера - прискорити розгортання нових застосунків.

Компанія Form I-9 Compliance займається обробкою форм I-9 ("Перевірка права на роботу") - її послугами користуються тисячі роботодавців і консалтингових компаній. Раніше персональні дані клієнтів зберігалися в локальному дата-центрі, що забезпечувало необхідний рівень безпеки. Але коли бізнес увійшов у фазу швидкого зростання, виявилося, що економічно доцільно буде перейти в Private Cloud - це повинно було допомогти Form I-9 Compliance скоротити CapEx/OpEx, але при цьому зберегти високий рівень безпеки для своїх сервісів. Компанія перенесла дані на самоврядну приватну хмарну платформу і підключила послугу Data Protection as a Service, щоб краще забезпечувати цілісність сховища даних. Приватна хмара дала змогу скоротити витрати на інфраструктуру і пробачила не тільки масштабування, а й проходження аудиторських перевірок SOC 2, обов'язкових для сервісних IT-компаній (фактично це міжнародний стандарт звіту для системи управління ризиками кібербезпеки).

Серед клієнтів Colobridge інфраструктуру приватної хмари успішно використовує інвестиційна компанія OMEGA FUNDS INVESTMENT. Раніше вона розміщувала свою інфраструктуру в публічній хмарі, проте була не зовсім задоволена прозорістю обробки та зберігання даних. Private Cloud у комплексі з іншими продуктами на платформі Colobridge дали змогу фінтех-компанії значно мінімізувати ризики фізичного пошкодження та втрати критично важливих даних, успішно проходити регулярний аудит ІТ-інфраструктури та оптимізувати витрати на її володіння.

Найбільша в Україні мережа кінотеатрів Multiplex також перенесла частину своєї IT-інфраструктури на технологічну платформу Colobridge, де використовує можливості приватної хмари в комплексі з кількома іншими продуктами. Зараз у Multiplex у приватній хмарі розгорнуто квиткову онлайн-систему. Створено сприятливі умови для цифровізації сервісів і послуг, а також її поширення на нові кінотеатри. Наразі мережа кінотеатрів може оперативно та ефективно масштабуватися, не вкладаючи кошти в надлишкові апаратні ресурси "про всяк випадок". Водночас централізоване управління IT-інфраструктурою на потужностях Colobridge дає змогу отримувати важливі метрики та прогнозувати "високі сезони". Multiplex почала ефективно реагувати не тільки на сезонні тренди, а й на виходи блокбастерів, через які навантаження на каси багаторазово зростало.

Будь-який з перерахованих пунктів може стати прямим "показанням" до вибору на користь приватної хмари.

Для роботи застосунків потрібне обладнання зі специфічними вимогами до компонентів
Приватна хмара дає змогу реалізувати проєкти з обладнанням будь-якої конфігурації від будь-якого виробника. Зазвичай це продиктовано специфікою його бізнес-додатків: тим може знадобитися певна частота процесора або кількість ядер на одну віртуальну машину, модель GPU або СЗД. Також компанія може у своїх вимогах орієнтуватися на обладнання конкретного вендора - наприклад, якщо він повністю влаштовував її якістю продукції та рівнем гарантійного обслуговування.

Специфіка навантаження та/або внутрішні правила СБ визначають високі вимоги до забезпечення безпеки
Якщо компанія планує самостійно керувати хостом або обмежити доступ до гіпервізорів третім особам (у тій же публічній хмарі до нього теоретично можуть отримати доступ співробітники провайдера), публічна хмара їй не підійде. У деяких випадках ініціаторами вибору більш захищеного середовища для розгортання IT-інфраструктури стають співробітники внутрішньої служби безпеки.

Клієнту необхідно оптимізувати витрати на IT-інфраструктуру
При досягненні певного обсягу ресурсів клієнт може відчутно заощадити, якщо вибере саме модель приватної хмари, розгорнутої на виділених серверах. Крім того, він може гнучко варіювати вартість послуг - залучати до роботи штатних сисадмінів або, навпаки, сисадмінів провайдера. Якщо порівнювати з найближчою альтернативою - публічною хмарою, - то виявиться, що впродовж дво- або трирічного періоду за однакового робочого навантаження приватна хмара може виявитися більш економічно ефективною. Це важливо для компаній, які звикли планувати і прогнозувати свої витрати - їм Private Cloud допоможе отримати максимум продуктивності за мінімальних витрат.

Клієнт хоче максимально контролювати обладнання, ПЗ і дані
З приватною хмарою він отримає в розпорядження інструменти для адміністрування на апаратному рівні та на рівні гіпервізора. Це великий плюс до контролю і керованості IT-інфраструктурою: можна оперативно відреагувати на проблему в застосунку, використовувати аналітику для прогнозування простоїв і вибрати найкращі політики для контролю доступу.

Клієнт висуває специфічні вимоги до хмари
Наприклад, у нього є певні очікування до продуктивності роботи серверів або системи зберігання і при цьому вкрай важливо мінімізувати навіть незначний вплив "сусідів".  

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

Десятиліття - значний період у контексті високих технологій. За цей час хмари встигли стати потужним і вкрай потрібним бізнес-інструментом, проте на початку 2010-х на них дивилися зовсім по-іншому. Згадуємо, як тоді бізнес сприймав хмарні технології, і чому сьогодні саме час переглянути свої переконання щодо них.

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

Багато потенційних замовників вважали, що «хмара - це ризик втратити контроль над IT-інфраструктурою».

Передавати щось своє в чужі руки в принципі суперечить людській природі: через це ми починаємо почуватися менш захищеними і більш тривожними. У бізнесі аналогічна ситуація - тут важливе відчуття повного контролю над IT-інфраструктурою. Тому багато компаній побоювалися хмар, продовжуючи зберігати й обробляти дані локально - так вони точно знали, як забезпечується їхня безпека, і могли посилити захист у разі потреби.

Сьогодні десятки тисяч компаній знають, що безпека IT-інфраструктури не завжди залежить від того, в чиїх руках вона перебуває. У світі зростає кількість кіберзагроз, які однаково небезпечні для даних і в хмарі, і в локальній інфраструктурі. У звіті Multicloud Annual Research Report навели результати опитування понад 1400 IT-фахівців і керівників по всьому світу - як виявилося, в абсолютної більшості завданням №1 для бізнесу стала саме безпека.

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

Ще одна поширена думка у минулому - «хмара обійдеться дорожче за локальну IT-інфраструктуру».

На вартість утримання хмарної інфраструктури впливають багато факторів, тому не можна однозначно стверджувати, що розміщувати дані в хмарі дорожче, ніж зберігати їх на локальному сервері. Важливо й те, як компанія використовує хмарні ресурси і наскільки ефективно управляє витратами на IT. Вони будуть тим меншими, чим краще оптимізовано хмару під бізнес-завдання організації. Тим паче, що в найпопулярнішій хмарній моделі "інфраструктура як сервіс" (IaaS) можна гнучко керувати доступними ресурсами - додавати або зменшувати їх за потреби - і платити тільки за фактично використані обсяги. Щоб так само гнучко реагувати на зміни попиту в випадку локальної інфраструктури, доведеться закупити дороге обладнання, ресурси якого простоюватимуть більшу частину часу, а це нераціонально.

Застарілі переконання досі заважають деяким компаніям розглядати хмари як важливу складову успішного ведення бізнесу. Проте ринок хмарних сервісів стрімко зростає, і аналітики продовжують і далі прогнозувати його збільшення рекордними темпами. Очікується, що з 445,3 млрд дол. торік він збільшиться до 947 млрд дол. У 2026-му, щорічно приростаючи в середньому на 16,3%. Хоча хмари все ще складно назвати ідеальним інструментом, вони стали життєво важливими для величезної кількості компаній. Кардинально змінюючи модель володіння IT-інфраструктури, вони відкривають для себе нові можливості, які дають змогу оптимізувати й автоматизувати рутинні процеси, краще реагувати на зміну попиту, швидше масштабуватися і вирішувати інші важливі завдання. Саме на це вказує багаторічний досвід нашої компанії Colobridge.