Розділяй і володарюй: багатовимірні політики безпеки

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



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



Ми могли б логічно уявити безпека, яка тут необхідна, як послідовність периметрів, перегруппировывающих кінцеві системи, пов'язані політиками фаєрвол:



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



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

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

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

Багатовимірність в віртуальному просторі
Ми не говоримо, що обладнання для забезпечення безпеки більше не потрібно. У контексті центрів обробки даних, вони, як правило, потрібні для фізичної периметра, де North-South traffic сходиться в єдину точку.

Як тоді бути з описаною проблемою в розрізі програмно-визначається середовища?

Щоб проілюструвати цей підхід, ми будемо використовувати Horizon View, VDI рішення VMware, як додаток для захисту. З точки зору мережі і безпеки це досить складне програми для розгортання, оскільки деякі сервери можуть бути доступні з Інтернету, а інші поховані глибоко всередині центрів обробки даних, а віртуальні робочі столи часто знаходяться в різних периметрах безпеки в залежно від того, яка група користувачів до них звертається.

Наступна схема дає уявлення про взаємодії між компонентами в оточенні Horizon View мінімум 4-ма параметри, які слід брати до увага: внутрішні клієнтські мережі, зовнішні клієнтські мережі, DMZ (демілітаризовані зони) і внутрішня мережа.



У контексті NSX ми будемо використовувати Service Composer, який створює «бульбашки», призначені для групування об'єктів у заивисимости від атрибута робочого навантаження і незалежно від  IP-адрес, VLAN або місцезнаходження.

Для початку давайте розглянемо середу, якою ми будемо працювати:



Першим кроком буде угруповання значущих частин програми, які повинні бути захищені. Створимо 3 групи в залежно від типу робочого навантаження: одна для Security Servers, діючих в якості проксі відношенню до Інтернету, інша для Connection Servers, діючих в якості брокерів робочого столу, і, нарешті, для всіх віртуальних робочих столів, які будуть створені. Ідея тут полягає в те, що тепер адміністратори (View admins) зможуть додати будь-який з цих сервісів куди завгодно в ЦОД, і вони будуть автоматично додані в відповідні групи.



Давайте зробимо останній «міхур», щоб охопити всю екосистему Horizon View.



Зверніть увагу, що об'єкти і групи мають жодних посилань на базову інфраструктуру, оскільки вони не визначено IP-адресами, VLan, технологій гіпервізора, конкретного ЦОД і т. д. Ці об'єкти можуть існувати в одному кластері, декількох кластерів, кількох ЦОД або навіть у кількох хмарних провайдерів.



Групова політика, отримана в результаті, потім поширюється і виконується для кожного учасника «бульбашки» Horizon View, мікро-сегментуємо кожен елемент в власний периметр безпеки.

Продовжимо. Наше додаток , як і раніше, має управлятися конкретним адміністратором (View Admin). Як і будь-які інші користувачі, адміністратори будуть використовувати View Client для своїх vDesktop, потім NSX Distributed Firewall розпізнає їх як частину групи «View Admins» в Active Directory і застосує динамічні правила до  vDesktops, дозволяючи їм керувати будь-якими елементами всередині «бульбашки» Horizon View, але і обмежуючи їх тільки цими елементами.



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



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

Додавання «вимірювань» додатком стає простіше, тому що ми підходимо до проблеми з боку функціональних груп, а не з точки зору створення складносурядних політик безпеки. Наприклад, тепер можна легко встановити корпоративні правила безпеки для «всіх MS Win2003srv», використовуючи атрибут віртуальної машини «OS-Type» для динамічного вибору учасників групи.



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

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

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

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.