Na pierwszy rzut oka to wszystko. Nie można jednak zapominać o komponencie administracyjnym, służącym do zarządzania hostem i hiperwizorem, jak również o rodzaju wirtualizacji. Można wyróżnić dwa rodzaje wirtualizacji: pierwsza - odnosząca się do sytuacji, w której hiperwizor jest uruchamiany bezpośrednio na plaformie sprzętowej, oraz druga, gdy hiperwizor korzysta ze standardowego systemu operacyjnego. Z punktu widzenia organizacji ważniejszy jest pierwszy rodzaj, z klasycznymi jego reprezentantami w postaci: Citrix XEN, Microsoft Hyper-V czy VMware ESX. Drugi rodzaj to najczęściej produkty quasi-desktopowe, np. Oracle Virtual Box.

Dla specjalisty ds. bezpieczeństwa wirtualizacja to samo zło, a jeżeli ktoś do tego dorzuci słowo-klucz "cloud", to lepiej, żeby wypowiadał je z bezpiecznej odległości. Analitycy podkreślają, że obecnie bezpieczeństwo wirtualizacji to w mniejszym stopniu konieczność implementacji dodatkowych technologii ochronnych, a w większym wszczepienie zasad bezpieczeństwa obowiązujących w świecie hardware’u i kabli.

Z jakimi problemami może przyjść nam się zmierzyć? Pierwszy, to jedna z przyczyn popularności wirtualizacji - łatwość i szybkość tworzenia kolejnych maszyn wirtualnych. Kto próbuje zarządzać laboratorium opartym na platformie wirtualnej, zna ten ból. W poniedziałek mieliśmy 3 maszyny, a już w piątek nie wiadomo skąd jest ich 15. Kto je utworzył, po co i czy ktoś wyraził na to zgodę? Z tym wiąże się kolejna bolączka - bardzo ograniczona w środowiskach wirtualnych implementacja zasady segregacji obowiązków (segregation of duties). Z reguły osoba czy zespół administrujący platformą wirtualną może lub wręcz administruje wszystkim, co się na niej znajduje. Może przenieść maszynę na inną platformę, kopiować wykorzystywane przez nią dyski, przekonwertować maszynę (np. do postaci fizycznej lub formatu używanego przez desktopowe oprogramowanie wirtualizacyjne), wykonywać snapshoty itp. Nagle okazuje się również, że uprawnienia nie są przypisane do konkretnej osoby - po prostu korzysta się z "roota". A zatem mówimy o procesie nadawania i kontroli uprawnień, ale także o zarządzaniu zmianą. Platformy wirtualne dają tutaj spore możliwości (np. vCenter Configuration Manager), ale możemy wzmocnić kontrolę narzędziami spoza platformy wirtualnej. Przykładem może być rozwiązanie Hytrust, które przede wszystkim wspiera kontrolę uwierzytelniania i wiązania użytkownika z kontami platformy wirtualnej, a także wspomaga proces zarządzania zmianą. Innym produktem, którego jednym z zadań jest ochrona konta root (jak również pełne logowanie wszystkich wykonanych poleceń z możliwością szczegółowej ich analizy), jest BeyondTrust PowerBroker Virtualization.

Nie bez znaczenia jest również miejsce wirtualizacji, które będzie miało wpływ na poziom ryzyka, a zatem i na bezpieczeństwo. Szczególnie, jeżeli myślimy o coraz częstszym stosowaniu jej w strefach DMZ (tzw. strefa zdemilitaryzowana). Możemy mieć do czynienia z najróżniejszymi scenariuszami. Z reguły nie patrzy się na to, jakiego rodzaju zasoby są przenoszone na platformę wirtualną. Nie do rzadkości należą przypadki, kiedy na tej samej platformie uruchamiane są zarówno systemy i aplikacje krytyczne, jak i te mało istotne. Co więcej, zdarzają się i takie pomysły, jak rozciąganie platformy wirtualnej, tzn. umieszczanie części zasobów w DMZ, a części w strefie zaufanej. Ten ostatni scenariusz to proszenie się o katastrofę, gdyby doszło do przejęcia hiperwizora. Z drugiej strony, nawet jeżeli platforma umieszczana jest w strefie zaufanej, to i tak nie zapewnia to z definicji bezpieczeństwa.

Tradycyjne mechanizmy ochronne, stosowane w przypadku korzystania z tzw. złomu (platformy fizycznej), są bezradne wobec tego, co dzieje się na platformie wirtualnej. Oczywiście, można (i należy) instalować oprogramowanie ochronne na gościach, ale co np. z inspekcją ruchu sieciowego między maszynami wirtualnymi w ramach hiperwizora?