10 типових запитань у техпідтримку. Інженери De Novo про безпеку в хмарі

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

1. Чи бачить провайдер мої дані в хмарі?

Коротка відповідь — ні. Для нас ваша інфраструктура має вигляд набору ізольованих «чорних ящиків». Інженери De Novo адмініструють фізичні сервери та рівень віртуалізації, але архітектурно відокремлені від даних усередині ВМ. Файл віртуального диска (VMDK) для інженера експлуатації — це бінарний контейнер. У нас немає доступу до файлової системи вашої гостьової ОС, тому перетворити цей «цифровий шум» назад у файли й прочитати їх практично неможливо.

На мережевому рівні використовується інкапсуляція VXLAN/Geneve, гіпервізор жорстко розділяє адресні простори оперативної пам’яті. Така архітектура гарантує, що трафік і дані різних клієнтів суворо ізольовані один від одного, навіть якщо вони перебувають на одному фізичному хості. Крім цього, як додаткові заходи захисту даних клієнт може задіяти шифрування прикладних даних на рівні гостьової ОС або на рівні ВМ, а також використовувати шифрування резервних копій ВМ.

2. Як захищена передача даних?

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

3. Які права та доступи мають інженери техпідтримки?

Ми працюємо за принципом Zero Trust і найменших привілеїв. У нашій моделі Zero Trust сам факт належності до внутрішньої мережі De Novo нічого не дає: кожен доступ перевіряється, права видаються суворо за ролями (RBAC). Інженер не має прав «суперкористувача» до всієї інфраструктури за замовчуванням. Будь-який вхід адміністратора здійснюється через систему керування привілейованим доступом (PAM, Privileged Access Management), яка виступає єдиною точкою входу. Таке рішення протоколює дії та за потреби дає змогу відновити повну картину сесії.

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

4. Що відбувається у разі виявлення кіберінциденту?

У нас впроваджена ешелонована система збору та кореляції подій безпеки (SIEM — Security Information and Event Management), куди стікаються логи з IDS/IPS, міжмережевих екранів, гіпервізорів і ключових сервісів. SIEM не лише зберігає події, а й обробляє їх, використовуючи кореляційні правила: наприклад, серія невдалих спроб входу разом з аномальним зростанням трафіку на рідкісний порт перетворюються на єдиний інцидент. У разі його виявлення — чи то DDoS-атака, сканування портів або аномальна активність — система автоматично сповіщає відповідальних спеціалістів. Процес реагування відлагоджений до хвилин: чергова зміна фіксує загрозу, спеціалісти ІБ обробляють її, блокуючи шкідливі IP, змінюючи політики фільтрації або перенаправляючи трафік через спеціалізовані вузли й повідомляючи клієнта в максимально стислі строки.

5. Які документи підтверджують безпеку хмари?

Хмара De Novo регулярно проходить перевірки на відповідність міжнародним стандартам безпеки ISO/IEC 27001, 27017, 27018, а також PCI DSS. Крім того, ми маємо атестати відповідності КСЗІ та ОТР, що критично для держсектору й банків. Зовнішні аудитори, яких ми регулярно залучаємо, проводять тести на проникнення периметра та стійкість ключових компонентів безпеки. Такий підхід дає змогу своєчасно виявляти й усувати критичні вразливості та помилки конфігурації до того, як ними скористаються зловмисники.

6. Що буде, якщо співробітник клієнта випадково видалить дані?

Хмарний провайдер гарантує доступність інфраструктури та фізичну цілісність даних на рівні компонентів інфраструктури, але не логічну цілісність файлів усередині прикладної системи. Для захисту даних від цього класу загроз клієнт може використовувати набір сервісів резервного копіювання — BaaS, Flex Backup та опції з георозподіленим зберіганням (Geo). Якщо ваш адміністратор видалив критично важливу базу даних, за наявності бекапу в хмарі відновлення відбувається через портал самообслуговування Veeam або через запит у техпідтримку. Звідти можна повернути як окремий файл, так і всю віртуальну машину з останньої придатної копії.

7. Чи може хтось ззовні отримати доступ до моєї віртуальної інфраструктури?

За замовчуванням хмара De Novo закрита ззовні. Доступ до керування хмарними ресурсами можуть отримати лише попередньо авторизовані контакти клієнта й тільки із зазначених клієнтом зовнішніх IP-адрес

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

Перед підключенням ВМ до мереж ми наполегливо рекомендуємо попередньо виконати необхідні налаштування безпеки (фаєрвольні правила, інспекцію трафіку, IDPS) на мережевих пристроях, дотримуючись політик компанії (за наявності таких) або кращих практик і рекомендацій (наприклад, спочатку налаштувати правило «Deny All», і лише після цього додавати дозволяючі правила за потреби; не публікувати порти керування, такі як RDP та SSH, у відкритий інтернет; для таких цілей слід використовувати захищені VPN-з’єднання; максимально обмежувати доступність прикладних сервісів ззовні тощо).

8. Що станеться, якщо один із майданчиків ЦОД вийде з ладу?

Для таких сценаріїв існує послуга післяаварійного відновлення (DRaaS). За налаштованої реплікації дані регулярно синхронізуються на резервний майданчик із мінімальним інтервалом, який задається політикою DR. У разі фізичної катастрофи в основному ЦОД клієнт ініціює процедуру failover. Віртуальні машини запускаються на резервному майданчику з мінімальним часом простою (RTO) та контрольованою втратою даних (RPO), що підтримує безперервність бізнесу навіть у важких сценаріях.

9. Як хмари захищені від вірусів-шифрувальників та програм-вимагачів?

У цьому питанні діє модель розділеної відповідальності. Ми гарантуємо безпеку на рівні гіпервізора: архітектура віртуалізації захищає від спроб шкідливого ПЗ «перестрибнути» на рівень заліза або мігрувати в інфраструктуру сусіднього клієнта. Захист ОС і даних усередині покладається на користувача. Ефективна протидія досягається використанням підходу 3-2-1-1 захисту даних — мати 3 копії даних, мінімум на 2 різних носіях, одна з них — за межами основного сайту, ще одна — на автономному air-gapped або Immutable репозиторії.

10. Що буде, якщо зловмисник отримає облікові дані мого акаунта?

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

Важливим питанням у розрізі цього класу загроз є розгляд підходу до захисту даних. У разі компрометації облікових записів дуже часто зловмисник реалізує атаку, починаючи зі знищення резервних копій для завдання максимальної шкоди. Рішенням у цьому випадку є незмінювані резервні копії (Immutable Backups). Ми використовуємо технологію Object Lock у режимі WORM (Write Once, Read Many), що працює як «цифровий бетон»: створену копію не можна змінити або видалити до закінчення заданого таймера зберігання. Це захищає дані навіть у сценарії глибокої компрометації — вірус, інсайдер або хакер із правами root чи глобального адміністратора не зможе знищити такі резервні копії до завершення періоду блокування.