Czy wirtualizacja serwera oznacza kolejną warstwę systemu operacyjnego do łatania i aktualizacji, więcej pracy i większe ryzyko?

Przeprowadziłem wyszukiwanie i nie znalazłem niczego, co mogłoby rozwiązać problemy dotyczące łatania i aktualizacji systemu. Mam wytyczne, które mówią, że serwery muszą mieć niezbędne poprawki. Jeśli mam hosta maszyny wirtualnej, to czy jest to dodatkowa warstwa do łatania i aktualizacji - nawet w przypadku hiperwizorów typu bare metal W przeciwieństwie do posiadania metalowego serwera? (tj. więcej pracy, testowania i dokumentacji zgodnie z moimi wytycznymi).

Jak często aktualizowane są hyper-daszki typu 1 / goły metal? Czy to ma znaczenie? Czy fakt, że jest to dodatkowa warstwa oprogramowania, powoduje większą złożoność i ryzyko (bezpieczeństwo i niezawodność)? (np. 99% wolnego od błędów oprogramowania x 99% wolnego od błędów oprogramowania = 98% wolnego od błędów systemu)?

(Moje praktyczne doświadczenie dotyczy VMWare Workstation and Server oraz VirtualBox.)

Tak, produkty takie jak VMware powinny być czasem łatane ( aktualizacje są kumulowane ), ale poprawki pojawiają się rzadziej niż główny system operacyjny, a potencjalny wektor ataku jest mniejszy - hiperwizor nie powinien być publicznie dostępny .

Jako przykładu użyję VMware ESXi w wersji 5.0 (nie 5.1) ...

ESXi 5.0 ma następujący harmonogram aktualizacji:

Od 9/2011 do chwili obecnej wprowadzono aktualizacje TEN do produktu ESXi 5.0. Spośród nich SZEŚĆ dotyczyło aktualizacji związanych z bezpieczeństwem w pakietach aktualizacji z opisami takimi jak:

„Luka w zabezpieczeniach ESXi związana z analizowaniem ruchu NFS” - CVE-2012-2448 .

Te luki w zabezpieczeniach są prawdziwe, ponieważ czasami odzwierciedlają ogólne błędy bezpieczeństwa w Linuksie, ale myślę, że większość organizacji nie jest zbyt podatna na ryzyko. Jednak to inżynier musi ocenić to ryzyko. Czy Twoi użytkownicy chcieliby, aby ogromne przestoje naprawiły następujący exploit ?

„Makro nazwa_kodowania w misc / mntent_r.c w bibliotece GNU C (aka glibc lub libc6) 2.11.1 i wcześniejszych, używane przez ncpmount i mount.cifs, nie obsługuje poprawnie znaków nowej linii w nazwach punktów montowania, co pozwala użytkownikom lokalnym powodować odmowę usługi (uszkodzenie mtab) lub ewentualnie modyfikować opcje montowania i uzyskiwać uprawnienia poprzez spreparowane żądanie montowania. ”

Może? Może nie.

Biegnę Update Manager VMware , ale tylko tendencję do aktualizacji jeśli mam wpływ błędu lub wymagają wzmocnienia funkcji. Po uruchomieniu w konfiguracji klastrowej łatanie jest łatwe, bez przestojów uruchomionych maszyn wirtualnych. Jeśli nie ma innych naglących powodów, postaram się aktualizować co kwartał. Poszczególne hosty będą wymagały pełnego ponownego uruchomienia, ponieważ łaty są dostarczane jako obrazy monolityczne.

Na marginesie, za każdym razem, gdy dziedziczę konfigurację VMware ESXi lub pracuję w systemie, którym normalnie nie zarządzam, często widzę działające hosty, w których nigdy nie zastosowano żadnych poprawek VMware. To jest złe!! Ale widzę, jak administratorzy mogą popełnić ten błąd, gdy systemy będą działać.

To całkiem dobre pytanie, jeśli dopiero zaczynasz wirtualizację na hostach typu „bare metal”. Robienie rzeczy w ten sposób wymaga innego sposobu myślenia niż podejście, które możesz zastosować w przypadku hiperwizorów działających jako usługa / aplikacja na bazie konwencjonalnego systemu operacyjnego.

Z mojego doświadczenia wynika prawdopodobnie, że ESX i HyperV potrzebują mniej łatania niż konwencjonalne systemy operacyjne. To nie znaczy, że nie potrzeba łatania w ogóle, albo że zastosowanie niektórych poprawek nie byłoby korzystne, niezależnie od „potrzeby”, ale to oznacza, że interuptions do swoich usług załatać gospodarz powinien być rzadsze i więcej pod twoją kontrolą. Istnieje potencjalne zagrożenie bezpieczeństwa dla systemów hiperwizora, tak jak ma to miejsce w przypadku innych systemów, i chociaż można zminimalizować ekspozycję tego ryzyka (np. Ujawniając zarządzanie hiperwizorem tylko na izolowanej sieci VLAN, do której logicznie nie można uzyskać dostępu z zainfekowanego serwera) głupotą byłoby udawać, że w ogóle nie ma ryzyka.

Jeśli więc masz 4 nie-wirtualne serwery, powiedzmy, i przeniesiesz je wszystkie na ten sam indywidualny wirtualny host, to tak, zwiększasz ilość zakłóceń, które mogą być spowodowane koniecznością łatania systemu hosta (lub radzenia sobie z problem sprzętowy itp.).

Chociaż sugeruję szansa tego występującego ryzyka jest stosunkowo niska (mówię o różnicy między łatanie wirtualnego hosta i rodzaj łatanie, który wymaga ponownego uruchomienia komputera, które trzeba by zrobić, aby system autonomiczny w każdym razie ) nie można uciec od faktu, że wpływ jest wysoki.

Dlaczego więc to robimy?

Prawdziwa korzyść z wirtualizacji wynika z możliwości skonfigurowania więcej niż jednego hosta i skonfigurowania hostów do współpracy, umożliwiając gościom przenoszenie się z jednego hosta na drugi w przypadku awarii jednego hosta lub zaplanowania łat systemy hosta.

Korzystając z tego podejścia, udało mi się załatać kolejno 5 hostów ESX bez żadnych zakłóceń na 40 wirtualnych serwerach na nich działających. Jest to po prostu kwestia ekonomii skali - gdy masz wystarczająco dużo potencjalnych wirtualnych maszyn gości, aby warto było zbudować tego rodzaju złożoną konfigurację i zarządzać nią za pomocą narzędzi, o których @wwhite wspomina w swojej odpowiedzi, zwrot w zmniejszeniu ryzyka martwisz się, że przybywa bardzo szybko.

Serwer wirtualny będzie wymagał takiej samej konserwacji i poprawek, jak serwer fizyczny, hiperwizory typu „bare metal” będą wymagały aktualizacji, dla bezpieczeństwa, ale także do naprawy błędów i poprawy wydajności. Im więcej masz serwerów, tym więcej pracy będziesz musiał zrobić, aby je aktualizować, nie ma znaczenia, czy są one fizyczne, czy wirtualne.

W oparciu o powyższe odpowiedzi wydaje się: Wirtualizacja serwera wprowadziła większą złożoność i ryzyko w zakresie bezpieczeństwa i niezawodności, ale należy je porównać z korzyściami płynącymi z możliwości skrócenia przestojów poprzez wirtualizację serwera.

Jeśli twoje środowisko wymaga audytu, testów i dokumentacji, koszt i korzyści związane z dodatkowym obciążeniem środowiska zwirtualizowanego będą musiały być wzięte pod uwagę wraz z liczbą posiadanych serwerów i pracowników systemów. W naszym środowisku nie mamy czasu na utrzymanie ścieżki audytu dla zwirtualizowanego środowiska. W naszych procesach biznesowych możemy trochę przestać, ale nie może zabraknąć ścieżki audytu i dokumentacji.