Чи буде віртуалізація сервера означати ще один шар ОС для виправлення та оновлення, більше роботи та більший ризик?

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

Як часто оновлюються гіпервізири типу 1 / голі метали? Це має значення? Чи додає той факт, що це додатковий програмний рівень, більше складності та ризику (безпека та надійність)? (наприклад, 99% програмне забезпечення вільного програмного забезпечення x 99% програмне забезпечення вільного програмного забезпечення = 98% системи без помилок)?

(Мій практичний досвід - це робоча станція та сервер VMWare та VirtualBox.)

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

Я буду використовувати приклад VMware ESXi версії 5.0 (не 5.1) ...

ESXi 5.0 має такий графік оновлення:

У період з 9 по 2011 рік до продукту ESXi 5.0 відбулися оновлення TEN . З них SIX були оновленнями, орієнтованими на безпеку, згорнутими в пакети оновлень з описами на зразок:

"Уразливість розбору трафіку ESXi NFS" - CVE-2012-2448 .

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

"Макрос encode_name в misc / mntent_r.c у бібліотеці GNU C (aka glibc або libc6) 2.11.1 і раніше, як використовується ncpmount і mount.cifs, не належним чином обробляє символи нового рядка в іменах точки монтажу, що дозволяє місцевим користувачам викликати відмову в обслуговуванні (пошкодження mtab) або, можливо, змінити параметри монтажу та отримати привілеї за допомогою створеного запиту на монтаж. "

Можливо? Можливо, не.

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

Як бічне зауваження, коли я успадковую налаштування VMware ESXi або працюю в системі, якою я зазвичай не керую, я часто бачу хости, що працюють, які ніколи не застосовували жодних патчів VMware. Це неправильно !! Але я бачу, як адміністратори могли зробити цю помилку, коли системи запрацювали.

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

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

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

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

То чому ми це робимо тоді?

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

Використовуючи такий підхід, мені вдалося по черзі без жодних перебоїв проклеїти 5 хостів ESX на 40 віртуальних серверах, що працюють над ними. Це просто питання економії на масштабі - як тільки у вас буде достатньо потенційних віртуальних гостьових машин, щоб зробити їх доцільним будувати таку складну настройку та керувати нею за допомогою інструментів @ewwhite згадує у своїй відповіді, окупність у зменшенні ризиків Ви хвилюєтесь, що прибуде дуже швидко.

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

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

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