Sieciowe aspekty zabezpieczenia środowisk wirtualnych

Rozpowszechnienie technologii wirtualizacji serwerów wymusiło szereg zmian w zakresie projektowania i implementacji statycznej do tej pory infrastruktury informatycznej. Szereg wprowadzonych przez wirtualizację usprawnień wymusił jednocześnie znaczącą zmianę stosowanych wcześniej paradygmatów projektowania infrastruktury. Powszechnie wykorzystywane modele, metodologie czy zestawy najlepszych dostępnych praktyk ze względu na odmienność charakterystyki środowiska wirtualnego od fizycznego przestały do końca spełniać zakładane w nich cele.

W szczególności znacznej komplikacji uległy stosowane modele projektowania architektury sieciowej w warstwach II i III oraz topologie bezpieczeństwa. Wirtualizacja nawet w swojej najprostszej postaci dokłada kolejną warstwę  sieciową oraz logiczną warstwę serwerową.

Dodatkowo terminologia oraz mechanizmy stosowane klasycznie w celu segmentacji i uporządkowania ruchu i systemów zostały w ramach środowisk wirtualnych rozbudowane o dodatkowe właściwe tylko dla nich mechanizmy. Zmiany te jak wspomniałem powyżej nie pozostały bez wpływu na projektowanie rozwiązań bezpieczeństwa. Znaczna mobilność maszyn wirtualnych w ramach serwerowni, dodatkowe warstwy infrastruktury oraz nowe rozwiązania grupujące znacząco utrudniły zaprojektowanie przejrzystej topologii.

Aby jednak powyższe rozważania nie były oderwane od doświadczeń empirycznych postaram się pokrótce porównać klasyczne metodologie tworzenia sieci oraz rozwiązań bezpieczeństwa do tych stosowanych (lub możliwych do zastosowania) w ramach środowisk wirtualnych. Wskaże również nowe zagrożenia i ewentualne metody zapobiegania im.

W przykładach będę posługiwać się terminologią i właściwościami produktów Vmware. Nie tylko ze względu na fakt, że jest to obecnie lider w zakresie wirtualizacji ale również ponieważ u pozostałych liczących się dostawców, oprócz pewnych szczególnych  właściwości budowane topologie i wykorzystywane mechanizmy będą bardzo podobne.

W klasycznej infrastrukturze złożonej z wielu serwerów fizycznych każdy z serwerów utrzymuje jedną bądź kilka usług i komunikuje się z resztą sieci za pomocą fizycznych kart sieciowych podłączonych do przełączników dostępowych. W zależności od zastosowanych mechanizmów wysokiej dostępności, serwer podłączony jest do jednego lub dwóch przełączników a grupy przełączników dostępowych agregowane są w ramach mocniejszych urządzeń dystrybucyjnych. Dystrybucja połączona jest natomiast miedzy sobą poprzez przełączniki rdzeniowe realizujące funkcje szybkiej magistrali wewnątrz lub pomiędzy centrami danych.

W ten sposób mamy trzy poziomy architektury sieciowej z serwerem jako urządzeniem końcowym tworzącym warstwę czwartą.

Wypracowane prze lata metody zabezpieczeń tego typu infrastruktury mogą być bardzo różne i rozbudowane, ale w znakomitej większości przypadków sprowadzają się do podziału serwerów na grupy i przypisania im adresów IP właściwych dla konkretnej grupy.

Tego typu grupa jest klasycznie niczym innym jak VLAN-e. Rozdzielenie ruchu pomiędzy VLAN-ami odbywa się natomiast w oparciu o zewnętrzne urządzenia bezpieczeństwa (np. firewall), w warstwie III bazując na podsieciach przyporządkowanych do VLAN-ów lub też szczegółowych adresów IP.

Dodatkowo aby zapewnić większą granulacje każdy z serwerów może posiadać wewnętrzny firewall skonfigurowany, żeby dopuszczać ruch przeznaczony tylko dla konkretnej serwowanej przez serwer usługi oraz właściwy ruch zarządzający (SSH, RDP, SNMP etc.).

W bardziej krytycznych środowiskach wykorzystuje się jeszcze listy ACL konfigurowane per port w przełączniku dostępowym do którego podłączony jest serwer oraz w miarę potrzeby można wykorzystać PVLAN-y aby zabronić całości ruchu pomiędzy serwerami w obrębie jednego VLAN-u.

Dodatkowe warstwy
W środowisku wirtualnym serwery utrzymujące usługi stają się logicznymi maszynami wirtualnymi działającymi wewnątrz serwerów fizycznych z oprogramowaniem do wirtualizacji (Hypervisor-em). Jednym z elementów Hypervisorów są tzw. wirtualne switch-e do których przyłączone są maszyny logiczne. Fizyczne karty sieciowe serwerów z Hypervisor-ami staja się natomiast portami wyprowadzającymi ruch sieciowy z serwerów logicznych poprzez wirtualne switch-e i serwery fizyczne aż do fizycznych przełączników dostępowych.

Tym samym czterowarstwowa do tej pory architektura zostaje rozbudowana o dodatkowe dwie warstwy tj. serwery fizyczne (Hypervisory) oraz wirtualne przełączniki.

Nowe właściwości
Wirtualne switch-e wprowadziły nowe funkcjonalności w zakresie grupowania maszyn logicznych w podsieci. Najmniejszą możliwą do stworzenia komórką jest tzw. port grupa.

Port grupy tworzone są w ramach vswitch-y. Każdy serwer logiczny, aby mieć połączenia z siecią musi należeć do co najmniej jednej port grupy. Maszyny w ramach grup mogą komunikować się pomiędzy sobą lecz nie posiadają komunikacji z maszynami w innych grupach.

Funkcjonalnie port grupa jest odpowiednikiem VLAN-u. Może być również do VLAN-u przyporządkowana. Jednakże, istnieje możliwość rozdzielenia segmentacji w taki sposób, że kilka port grup współdzieli jeden VLAN przy jednoczesnym rozdzieleniu komunikacji w ramach poszczególnych grup.

Istnienie port grup ma istotne znacznie dla realizacja podstawowych właściwości wirtualizacji tj. migracji w locie, budowy klastrów HA, czy równoważeniu obciążenia. Otóż, aby ww. funkcje były możliwa konfiguracja sieci w tym port grup (z zakresie np. etykiet tzn. identyfikatorów port grup) musi być spójna w obrębie całej infrastruktury. W związku z tym wprowadzono możliwość tworzenia tzw. wirtualnych przełączników dystrybucyjnych.  Przełącznik taki, agreguje zarządzanie vswitch-ami na wszystkich serwerach fizycznych dbając, aby ich konfiguracja i nazewnictwo były w pełni koherentne.

Ze względy na własności systemów wirtualizacji, do zarządzania maszynami wirtualnymi używa się specjalnego oprogramowania pozwalającego na dokonywanie modyfikacji w obrębie całej infrastruktury. Zarówno Vmware vsphere jak i inne systemy pozwalają m.in. na grupowanie maszyn logiczny w kontenery a kontenerów w większe grupy (np. centra danych). Pozwala to na osiągnięcie dodatkowego uporządkowania oraz na znaczne zwiększenie granularności uprawnień.

Nowe zagrożenia
Wprowadzenie dodatkowej warstwy sprzętowej nie pozostaje bez wpływu na poziom bezpieczeństwa całej infrastruktury. W środowiskach klasycznych zabezpieczenie koncentrowało się konkretnych maszynach fizycznych. Potencjalny atakujący przejmując kontrole nad maszyną fizyczną otrzymywał dostęp tylko do pojedynczej aplikacji. W przypadku wirtualizacji sytuacja wygląda zgoła odmiennie.
Na pojedynczym serwerze z Hypervisorem rezyduje statystycznie około 20-40 maszyn wirtualnych. Zarządzanie takim maszynami jak i samymi Hypervisor-ami może odbywać się może za pomocą centralnych systemów jak np. vCenter lub też bezpośrednio z systemu Hyperviora z wykorzystaniem CLI lub klienta. Dodatkowo większość systemów wirtualizacji posiada specjalne API powalające na budowę własnych systemów zarządzania.
Konsekwencją ww. stanu jest sytuacja, w której posiadając dostęp do Hypervisora (z wykorzystaniem dowolnej metody) posiadamy dostęp do konsoli maszyn wirtualnych, mamy możliwość ich modyfikacji czy też nawet skopiowania w całości np. na nośnik zewnętrzny.
Co więcej, domyślnie łącząc się do systemu zarządzania administrator widzi wszystkie maszyny wirtualne i ma dostęp do każdej z nich. W wielu środowiskach o znacznym zróżnicowaniu aplikacji, i rozproszeniu zarządzania jest to sytuacja nie pożądana.
W obliczy opisanego stanu kluczowym staje się jak najdokładniejsze zabezpieczenie serwerów z Hypervisorami oraz szczegółowe i przemyślane ustawienie odpowiednich uprawnień do zarządzania nimi.
W pierwszej kolejności powinniśmy skoncentrować się na odpowiednim znacznie bardziej restrykcyjnym zabezpieczeniu fizycznym samych serwerów. Dostęp do nich powinni mieć tylko wybrani administratorzy, tylko i wyłącznie w uzasadnionych ściśle monitorowanych przypadkach.
Powinniśmy, również wykorzystywać wbudowany w Hypervisor firewall i zezwalać tylko na dostęp zarządzający z konkretnej podsieci IP lub najlepiej z konkretnych adresów. W miarę możliwości należy również wymuszać aby zarządzanie odbywało się tylko z wykorzystaniem klienta i wyłączać dostęp za pomocą telnetu, ssh czy konsoli.
Również, samo zarządzanie z poziomu klienta powinno być przemyślane w zakresie uprawnień. Vmware pozwala na bardzo szczegółowe określenie kto i do czego ma dostęp. Możemy przypisywać uprawnienia bazując na kontenerach z wirtualnymi maszynami, na centrach danych czy na poszczególnych funkcjonalnościach. Takie rozdzielenie zwykle jest konsekwencją przyjętej polityki bezpieczeństwa i  jest zaimplementowane w przypadku infrastruktury fizycznej (np. oddzielni administratorzy urządzeń sieciowych, sieci SAN i poszczególnych serwerów) lecz zapomina się o nim w systemach zwirtualizowanych pozwalając administratorom na pełen dostęp zarządzający.