Гайд із захисту даних з VMware vSphere

Вступ

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

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

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

На щастя, екосистема vSphere спростила захист даних, але не всі засоби захисту однаково ефективні. Мета цього невеличкого посібника – надати деякі ідеї та рекомендації щодо продуктивного захисту вашого середовища VMware vSphere.

Основи

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

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

Правило 3-2-1

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

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

Місце та безпека

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

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

Почніть зі здорового середовища

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

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

• Забезпечення актуальності інструментів VMware;
• Встановлення всіх застосовних патчів або хотфіксів ОС;
• Відсутність необхідності в перезавантаженні.

VMware Tools – важливий компонент надійного резервного копіювання віртуальних машин. У більшості випадків постачальники покладаються на наявність та функціонування інструментів VMware для зв’язку з гостьовою ОС. Загальні взаємодії включають такі завдання, як отримання IP-адрес або імен хостів гостьової ОС або дії як посередника для використання VIX API для виконання дій в гостьовій ОС. У багатьох випадках VIX API використовується для запуску сценаріїв до та після резервного копіювання, особливо для багатьох гостьових операційних систем на базі Unix або Linux. Службу тіньового копіювання томів Microsoft (VSS) можна використовувати в ОС на базі Windows, але для цього потрібна наявність інструментів VMware.

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

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

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

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

Підтримуйте своє середовище в актуальному стані

Завжди рекомендується підтримувати активну угоду про підтримку, особливо для підприємств, які прагнуть уникнути простоїв та ризиків. Хоча кілька версій vSphere можуть підтримуватись одночасно (наприклад, для всіх версій 6.5, 6.7 та 7.0 одночасно були доступні угоди про підтримку), важливо розуміти, що кожна з цих версій має кілька випусків (наприклад, оновлення 1, Оновлення 2 тощо). ) з кількома зборками на гілку.

Розуміння вашого поточного статусу підтримки має вирішальне значення, коли йдеться про загальний стан вашого середовища. Інформація про життєвий цикл VMware, включаючи дати закінчення підтримки, легко доступна за адресою https://lifecycle.vmware.com. Також важливо відзначити, що дати підтримки визначаються основними версіями, а не різними оновленнями, що випускаються. Наприклад, підтримка ESXi 7.0, будь то оновлення 1, оновлення 2 або пізніші версії, закінчується в той самий день. Зазвичай рекомендується запускати останній основний випуск (тобто останнє оновлення) разом із новою збіркою для гілки. Нові випуски, швидше за все, включатимуть усі необхідні виправлення, виправлення, оптимізації та виправлення безпеки.

Коли мова йде про оновлення середовища vSphere, важливим фактором є інтеграція зі сторонніми постачальниками. Програмне забезпечення для резервного копіювання, як правило, є однією з перших областей, де багато клієнтів стикаються з несумісністю, в основному тому, що воно працює цілодобово і без вихідних, принаймні, деякою мірою для багатьох підприємств. Хоча виконання оновлень в одній і тій самій гілці (тобто у гілці «Оновлення 3») зазвичай не викликає проблем, проте рекомендується звертатися до постачальникам, які підтримують сторонні інтеграції в  vSphere. Інші поширені платформи, на які можуть вплинути оновлення, включають мережеву інтеграцію, інтеграцію зі сховищем та програмне забезпечення для зовнішнього керування.

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

У VMware є опублікований список сумісності обладнання (HCL) (https ://www.vmware.com/resources/compatibility/search.php), який можна використовувати для визначення того, які версії драйверів та мікропрограм вже були протестовані з певними апаратними компонентами. Варто зазначити, що можуть бути інші версії, яких немає в списку. Це не означає, що вони не працюватимуть, але вони можуть не підтримуватися конфігурацією та викликати додаткові проблеми при зверненні до служби глобальної підтримки VMware. Нарешті, варто переглянути документацію виробника та примітки до випуску цих драйверів та вбудованого програмного забезпечення. Іноді критичні помилки виправляються у нових версіях. Тим не менш, більш старі версії можуть все ще знаходитись у HCL.

Вибір оптимального методу передачі даних

Коли справа доходить до резервного копіювання та відновлення робочих навантажень vSphere, зазвичай існує три типи режимів, які використовуються для доступу та читання даних віртуальної машини:

• SAN Transport: дані зчитуються безпосередньо з базового сховища, підключеного до хоста ESXi. Це досягається за рахунок прямого підключення до масиву (наприклад, через Fibre Channel).
• HotAdd: VMDK підключаються до резервної проксі/допоміжної віртуальної машини, яка зчитує дані.
• Мережевий блоковий пристрій (NBD): дані копіюються по мережі.

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

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

SAN Transport: При використанні режиму SAN Transport розгортаються фізичні проксі або допоміжні пристрої, які безпосередньо звертаються до системи зберігання. Якщо ваш масив зберігання використовує Fibre Channel або iSCSI, це може бути найшвидший метод резервного копіювання, оскільки він дозволяє уникнути додаткових операцій, які можуть бути викликані гіпервізором. Для досягнення оптимальних результатів проксі-сервер повинен бути фізично близько до сховища, щоб звести до мінімуму потенційні вузькі місця, що викликають затримку. SAN Transport зазвичай забезпечує найкращі можливості резервного копіювання, оскільки хост отримує прямий доступ до сховища і не повинен проходити через будь-які інтерфейси VMkernel. Однак SAN Transport не завжди ідеально підходить для відновлення. Thick disk зазвичай має вищу продуктивність відновлення в порівнянні з thin disk, в основному через кілька рівнів управління дисками, які необхідні для обслуговування дисків з тонкою ініціалізацією. Відновлення в мережевому режимі (див. нижче) забезпечить більш високу продуктивність відновлення дисків з тонкою ініціалізацією. Крім того, SAN Transport не може захистити віртуальні машини, що працюють у сховищах даних VVOL або vSAN.

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

Мережевий блоковий пристрій (NBD) копіюватиме блоки даних по мережі за допомогою протоколу vSphere Network File Copy (NFC). Зазвичай цей режим можна використовувати з фізичного хоста, який не має доступу до базового сховища, або з віртуального пристрою. Цей режим важливо протестувати, оскільки результати можуть відрізнятися залежно від таких факторів, як пропускна здатність мережі та затримка, а також обсяг даних, для яких необхідно виконати резервне копіювання. В ідеалі інтерфейс повинен мати швидкість не менше 10 Гбіт для швидкої передачі даних. Також важливо враховувати, чи потрібне шифрування резервного трафіку. Якщо це так, шифрування додасть накладних витрат, що, ймовірно, вплине на загальну продуктивність. Нарешті, починаючи з vSphere 7, з’явилася можливість явного призначення вSphere Backup NFC адаптеру VMkernel, що створює спеціальний інтерфейс для мережного резервного копіювання.

Використовуйте CBT для ефективного резервного копіювання

Резервне копіювання на основі образів є галузевим стандартом резервного копіювання робочих навантажень vSphere. Частково це пов’язано з простотою та послідовністю їх створення. VMware пропонує API-інтерфейси vSphere Storage – Data Protection (раніше відомі як API-інтерфейси VMware vStorage для захисту даних або VADP), які дозволяють швидко та ефективно виконувати додаткове резервне копіювання за допомогою відстеження змін блоків (CBT).

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

Щоб використовувати CBT, віртуальна машина, що розглядається, повинна відповідати наступним критеріям:

• Хост повинен працювати під керуванням ESXi 4.0 або новішим, а віртуальна машина повинна мати версію віртуального обладнання 7 або новішими.
• ВМ повинна знаходитися в сховищі даних, що підтримується NFS, VMFS або RDM в режимі віртуальної сумісності.
• VMDK віртуальної машини не має бути незалежним диском.

Хоча CBT увімкнено за замовчуванням, при необхідності його можна вимкнути. Якщо CBT необхідно ввімкнути або вимкнути на віртуальній машині, важливо зазначити, що віртуальна машина, що розглядається, не повинна мати моментальних знімків під час переходу.

Додаткові відомості про CBT див. на сторінці https://kb .vmware.com/s/article/1020128.

Коли використовувати резервне копіювання, що враховує програми

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

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

Application-aware резервні копії (іноді звані узгодженими з додатками чи подібним чином) взаємодіють із гостьовою ОС, щоб забезпечити запис будь-яких даних у пам’яті на диск. Якщо гостьова ОС працює під керуванням Windows, використовується служба тіньового копіювання томів (VSS). Якщо гостьова ОС працює під керуванням дистрибутива Linux, постачальники можуть пропонувати сценарії, що дозволяють «заморожувати» та «розморожувати» гостьову ОС для забезпечення узгодженості даних.

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

1. Резервний сервер розгортає гостьовий агент для зв’язку з гостьовою ОС через VIX API
2. Додаток підготовлений для моментального знімка VSS
3. Пам’ять припиняється, і незавершені операції введення-виведення записуються на диск
4. Агент запитує моментальний знімок VSS
5. Моментальний знімок vSphere запускається та містить стабілізовану копію віртуальної машини та програми
6. Гостьова ОС відновлює роботу у звичайному режимі
7. Знімок vSphere резервується

Бекап vs реплікація

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

Реплікація vSphere включена до декількох редакцій vSphere, але має обмеження. Зокрема, на низькому рівні вона обмежена п’ятихвилинною RPO та підтримує до 24 точок відновлення на репліковану віртуальну машину. Сторонні рішення можуть покращити це, використовуючи API-інтерфейси vSphere для фільтрації вводу-виводу (VAIO).

Вперше представлений у vSphere 6.0 Update 1, VAIO дозволяє партнерам вставляти фільтри в шляху введення-виведення між віртуальною машиною та сховищем. Партнери, які використовують ці фільтри, можуть перехоплювати та змінювати дані, які будуть використовуватися для кешування та реплікації. Це, по суті, забезпечує шлюз для збору даних практично без впливу на продуктивність віртуальних машин, що розглядаються.

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

Як і список сумісного обладнання VMware, список партнерів із сертифікованими реалізаціями VAIO можна знайти за адресою https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vaio.

Коли йдеться про резервні копії — довіряйте, але перевіряйте

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

• Сам файл резервної копії пошкоджено
• Резервні копії даних пошкоджені (наприклад, через помилки операційної системи або програми).
• Резервна копія може не містити очікуваних даних

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

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

• Чи достатньо обчислювальної потужності/пам’яті/сховища та пропускної спроможності для запуску цих віртуальних машин?
• Чи вплине це на мережевий трафік?
• Чи є ризик для виробничих віртуальних машин? машин, якщо резервні віртуальні машини включені?
• Чи будуть ці віртуальні машини відповідати правилам безпеки або нормативним вимогам, якщо вони будуть відновлені в іншому місці?

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

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

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

Висновок

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

---

Бажаєте використовувати інноваційні та сучасні технології? Зв’яжіться з нашими експертами вже сьогодні. Зателефонуйте нам за номером +38 (044) 277-23-23 або надішліть нам листа за адресою info@wiseit.com.ua, і ми детальніше розповімо вам про рішення VMware та їх переваги.