Mało organizacji (wg opracowań firmy Gartner, zaledwie 24%) dokonuje pełnego oszacowania ryzyka i dostosowuje odpowiednio politykę bezpieczeństwa pod tym kątem. W Polsce nadal przeważa model przeniesienia aplikacji do środowiska wirtualizowanego, bez zmiany w polityce bezpieczeństwa - a jest to poważny błąd. W porównaniu do eksploatacji systemów pracujących bezpośrednio na sprzęcie, środowisko wirtualizowane przynosi potencjalne luki w bezpieczeństwie, które nie występowały w modelu tradycyjnym oraz uwypukla podatności infrastruktury i procedur IT.

Ponieważ migracja do chmury prywatnej wiąże się z bardzo głęboką konsolidacją zasobów, należy przeprowadzić także zmiany w systemach bezpieczeństwa. Nowe środowisko stanie się bardzo zintegrowane, co implikuje zmiany choćby w systemie rejestrowania zdarzeń. Przy wdrożeniu środowiska cloud computing, niezbędny staje się system, który potrafi zebrać i korelować logi z różnych serwerów, obsługujących wiele aplikacji. Zebranie logów w jednym miejscu, ich korelacja i analiza zdarzeń umożliwia wykrycie zjawisk, które mogą być związane z próbą przejęcia kontroli nad maszynami wirtualnymi.

Jedną z zalet wirtualizacji jest możliwość klonowania maszyn wirtualnych, co umożliwia przygotowanie szablonów i znaczące przyspieszenie dostarczania zasobów IT. Jednak technologia ta niesie ze sobą ryzyko związane z możliwością nieautoryzowanego odtworzenia dokładnej kopii systemu w innym środowisku.

Jedną z typowych procedur IT jest aktualizacja systemu i aplikacji, która wiąże się z intensywnym testowaniem łat dostarczonych przez producenta. W środowisku wirtualnym wykorzystuje się do tego celu kopię maszyny, na niej przeprowadza się aktualizacje i testy. Po zakończeniu testów, łata jest aplikowana w środowisku produkcyjnym. Ten schemat sprawia, że w środowisku wirtualizowanym znajduje się kopia danych produkcyjnych, które powinny być tak samo chronione, jak ich oryginał, z którego pochodzą, powinny być także objęte systemem zarządzania zmianami. Ponadto należy się upewnić, czy łata zastosowana w środowisku produkcyjnym jest dokładnie tą, którą testowano. Po zakończeniu prób, maszyna testowa powinna być skasowana, a cała praca - udokumentowana w odpowiednich wpisach w logu razem z zapisami, kto miał dostęp do niej i jakie operacje były przeprowadzane.

Tekst powstał w oparciu o prezentacje na konferencji EMC Forum 2010 w Warszawie, której Computerworld był patronem medialnym.