Загальні міркування безпеки

Тут мені здається виправданим дати уявлення про відмінності віртуальної інфраструктури з точки зору безпеки

Природно буде виділити кілька рівнів віртуальної інфраструктури, підхід до захисту яких різниться:

Q рівень віртуалізації (гіпервізор, VMkernel)

Q рівень віртуальних машин

Q  ESX Service Console

Q віртуальна мережа на ESX (i)

Q системи зберігання

Q  vCenter Server

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

Скомпрометована віртуальна машина може переміщатися між серверами і компрометувати віртуальні машини на інших серверах

Зверніть увагу VMware пропонує своє вирішення брандмауера для ВМ – vShield Zones Крім того, є достатня кількість засобів забезпечення безпеки від інших виробників

Також VMware пропонує набір програмних інтерфейсів (API) під назвою VMSafe C його допомогою додаток з однієї ВМ може отримувати доступ до інших ВМ на цьому ESX (i) через гіпервізор Наприклад, ми можемо мати одну ВМ з антивірусом, яка буде сканувати память всіх інших ВМ на цьому сервері У якихось продуктах можуть бути реалізовані й інші корисні функції, наприклад сканування вимкнених ВМ

Незважаючи на те що кілька ВМ працюють на одному сервері, якось перерозподіляють його память, їх спільна робота не погіршує ситуацію з безпекою Зсередини однієї ВМ немає способу отримати доступ всередину інший через гіпервізор, крім спеціалізованих API VMsafe Використання цих API вимагає чіткого розуміння механізмів роботи гіпервізора і доцільності включення в цю роботу За замовчуванням ці API не використовуються ніким Щоб вони почали працювати, буде потрібно в явному вигляді зробити ряд дій, як-то: встановити відповідне ПЗ або Appliance, запустити його і налаштувати

VMkernel Гипервизор ESX і ESXi Питання безпеки гіпервізора досить важливий, так як захоплення гіпервізора дозволить зловмисникові перехоплення-

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

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

З коштів внутрішнього захисту присутні тільки брандмауер (на ESX) і система розмежування прав Якщо питання безпеки стоїть гостро, то має сенс звернутися до стороннім виробникам засобів безпеки, в чиїх активах вже є спеціалізовані програмні продукти для ESX (i)

Зате гіпервізор є вузькоспеціалізованою операційною системою, як наслідок – поверхня атаки значно менше, ніж для традиційних операційних систем У простих випадках безпеку гіпервізора обеспечива ється насамперед ізоляцією його мережі Мережа для VMotion, для Fault Tolerance, мережа для трафіку iSCSI і NFS бажано виділяти в окремі фізичні мережі або VLAN

Service Console – Керуючий компонент ESX Собою представляє Red Hat Enterprise Linux 5, в якому залишили в основному тільки необхідні для ESX компоненти Для забезпечення безпеки Service Console рекомендується її інтерфейси знову ж поміщати в ізольовані мережі Також у складі Service Console є брандмауер, який має сенс налаштовувати на блокування всіх незадіяних Service Console портів Про настройку цього брандмауера я розповім пізніше

VMware регулярно випускає оновлення, що закривають уразливості, знайдені в VMkernel (втім, таких було відомо дуже мало) і Service Console Своєчасна установка оновлень – важлива частина забезпечення безпеки VMware пропонує спеціальний компонент – VMware Update Manager, який дає можливість встановлювати оновлення в автоматичному режимі на сервери ESX (i) Про нього буду розповідати в останній главі Зверніть увагу: оновлення для Service Console треба отримувати у VMware, а не у Red Hat Встановлення оновлення від Red Hat (якщо вона взагалі вийде) може замінити деякі бібліотеки, що шкідливо і для нормальної роботи, і для безпеки Service Console

C точки зору безпеки, корисним кроком є ​​налагодження централізованого журналирования Наприклад, VMware пропонує vMA – vSphere Management Appliance Це ВМ з Linux, всередині якої встановлені необхідні для управління vSphere компоненти Управління виконується з командного рядка Так от, наприклад, цю vMA нескладно налаштувати на збір файлів журналів з серверів ESX (i)

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

VMware vCenter – Це додаток для Windows Якихось спеціальних засобів забезпечення безпеки для нього не існує Але стандартні для таких завдань – це знову ж установка оновлень, настройка міжмережевого екрану і антивірус, приміщення vCenter в ізольовану мережу Всім цим треба користуватися

Можливо, у вас доступ до управління віртуальною інфраструктурою, тобто до vCenter через клієнт vSphere, будуть мати кілька людей У такому випадку вкрай бажаним є жорстке розмежування прав Про механізм розмежування прав в vCenter незабаром розповім

Віртуальні мережі Віртуальні комутатори VMware мають деякі відмінності від комутаторів фізичних в силу своєї природи Наприклад, вКоммутатори не підтримують Spanning tree, не встановлюють відповідність MACадресов і портів шляхом аналізу трафіку і т д Дані відмінності випливають з особливостей експлуатації вКомутаторов – для них не передбачається прямого зєднання між собою, тому Spanning tree і не потрібен MAC-адреси ВМ їм повідомляє гіпервізор, що генерує ці MAC-адреси для ВМ, і аналізувати трафік немає потреби

Висновок: з мережевою безпекою немає особливо ускладнюють роботу нюансів Зрозуміло, треба знати і розуміти важливі настройки вКоммутаторов, в першу чергу з групи налаштувань «Security»

Сховища Безпека сховищ для ВМ в основному зводиться до правиль ному зонуванню й маскуванню LUN для серверів ESX (i) Так як самі ВМ не знають про фізичне сховище нічого (у ВМ немає доступу до HBA / iSCSI инициа тору / клієнтові NFS), з їхнього боку загроз безпеки сховищ немає Для повноти картини варто згадати про те, що віртуальна машина може отримати доступ до дискового контролера за допомогою функції VMDirectPath, і про те, що системи зберігання iSCSI і NFS можуть бути підключені по мережі відразу до віртуальної машині, не через гіпервізор Але такі конфігурації вже не повязані з питанням безпеки гіпервізора і його служб

Джерело: Міхєєв М О Адміністрування VMware vSphere 41 – М: ДМК Пресс, 2011 – 448 с: Ил

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*