Bezpieczna wirtualizacja wymaga KMS i HSM

Przez: Igor Jardim

Na początku XXI wieku koncepcja wirtualizacji zaczęła wyłaniać się jako sposób na wyjście z sytuacji dla dużych przedsiębiorstw. centra danych którzy zmagali się zarówno z brakiem fizycznej przestrzeni na rozwój, jak i z marnotrawstwem mocy obliczeniowej na serwerach, które w efekcie częściej pozostawały bezczynne niż były faktycznie wykorzystywane.

Na przestrzeni lat te totalizator piłkarski dedykowane serwery fizyczne zaczęły drastycznie wychodzić z użycia, a wirtualizacja stała się fundamentalną częścią infrastruktury IT, zarówno w architekturze, jak i projektach, ze względu na zwinność, jaką zapewnia w zarządzaniu i prowadzeniu firm.

Jednocześnie, w miarę jak czas reakcji działu IT i dostawców usług w chmurze uległ znacznemu skróceniu, zaostrzył się problem, który do tej pory był ignorowany: bezpieczeństwo danych, zwłaszcza tych na dysku.

Dzisiaj, w obliczu licznych wycieków danych i RODO pukając do drzwi każdego z nas, firmy muszą uporać się z tym problemem, który stale rośnie, narażając na ryzyko nie tylko użytkowników systemów, ale także samą ciągłość funkcjonowania właścicieli infrastruktury informatycznej.

Dlaczego zaniedbuje się bezpieczeństwo danych?

Wielu administratorów rezygnuje z szyfrowania dysków na serwerach, ponieważ aby odszyfrować dysk twardy po ponownym uruchomieniu sprzętu, konieczne jest podanie hasła na każdym z nich. Jest to żmudna operacja, która wydłuża czas przestoju infrastruktury, nawet jeśli trwa tylko kilka minut.

Dziś, biorąc pod uwagę łatwość tworzenia serwerów wirtualnych, stało się to zadaniem niemal niepraktycznym, co powoduje, że administratorzy systemów błędnie rezygnują z szyfrowania dysku.

Sytuację komplikuje fakt, że problem jest znacznie poważniejszy na serwerach wirtualnych: za każdym razem, gdy maszyna wirtualna jest wstrzymywana lub snapshoot zostanie utworzony, na fizycznym dysku twardym serwera znajdzie się nie tylko zawartość Twoich dysków, ale także dane w pamięci! Innymi słowy, wszystkie dane znajdujące się w pamięci aplikacji i usług uruchomionych na maszynie wirtualnej, do których zazwyczaj należą klucze kryptograficzne, dane osobowe, hasła, tokeny uwierzytelniające itp., znajdą się na dysku serwera fizycznego, co spowoduje ujawnienie danych, które muszą być chronione.

Rozwiązanie dla bezpieczeństwa

Jeśli pomyślałeś: ale co z Hypervisor, czy to nie rozwiązuje problemu? Krótka odpowiedź brzmi: nie sam.

Aby to zrozumieć, przypomnijmy sobie: hiperwizor to warstwa programowa pomiędzy sprzętem i systemem operacyjnym, która umożliwia maszynom wirtualnym dostęp do zasobów sprzętowych. Działa w warstwie systemu, która umożliwia automatyczne i transparentne szyfrowanie i odszyfrowywanie woluminów danych za pomocą kluczy dla maszyn wirtualnych, kiedy tylko jest to konieczne, eliminując potrzebę wpisywania haseł.

Jednak używanie wyłącznie kluczy do szyfrowania/odszyfrowywania serwera stwarza inny problem: znalezienie sposobu na bezpieczne przechowywanie tych kluczy, ponieważ w wyniku ich wycieku nie tylko pojedynczy serwer, ale cały grupa, czyli kilka połączonych ze sobą urządzeń, które działają równolegle i w efekcie stają się podatne na ataki.

Wykorzystanie KMS do przechowywania kluczy kryptograficznych

Kryptus kNET HSM działający jako KMS.

Aby rozwiązać ten problem i zapewnić bezpieczeństwo kluczy, można skorzystać z usługi KMS (Key Management Service). KMS-y to systemy umożliwiające bezpieczne zarządzanie cyklem życia kluczy kryptograficznych w formie usługi. W ramach tej usługi można podłączyć wiele innych systemów obsługujących szyfrowanie danych, takich jak hiperwizor, baza danych, a nawet systemy SIEM.

Oczywistym jest, że KMS nie może być maszyną wirtualną, dlatego skuteczne systemy/usługi zarządzania kluczami opierają się na sprzęcie do ochrony kryptograficznej tej klasy lub go wykorzystują. HSM (moduł zabezpieczeń sprzętowych), urządzenie ekranowane, w sensie logicznym i fizycznym, przed kradzieżą i niewłaściwym użyciem kluczy kryptograficznych.

Jeśli szukasz rozwiązania tego problemu, mamy dwie dobre wiadomości!

Pierwsza z nich to fakt, że wraz z wydaniem vSphere 6.5 firma VMware wprowadziła możliwość transparentnego szyfrowania samej maszyny wirtualnej (VM) niezależnie od systemu operacyjnego, na którym działa, co rozwiązuje wspomniane już problemy bezpieczeństwa, a także pomaga w przestrzeganiu przepisów dotyczących ochrony danych, takich jak RODO! Aby zapewnić tę funkcjonalność, vSphere używa usługi KMS do ochrony kluczy szyfrujących!

Drugą wiadomością jest to, że Moduł HSM kNET działa jako KMS i jest w pełni kompatybilny z Vmware vSphere.

Komunikacja między vSphere i kNET

Poniższy rysunek w ogólnym zarysie wyjaśnia, w jaki sposób odbywa się komunikacja między vSphere firmy VMware a kNET firmy Kryptus:

1- Po pierwsze, musi istnieć relacja zaufania między kNET (KMS) a vCenter;

2- vCenter żąda klucza od KMS;

3- KMS wysyła klucz szyfrowania klucza (KEK) do vCenter;

4- vCenter przechowuje tylko identyfikator klucza i wysyła zestaw KEK+ID do ESXi (hiperwizora);

5- ESXi odbiera i przechowuje KEK wyłącznie w pamięci;

6- Po otrzymaniu klucza KEK ESXi generuje klucz szyfrowania danych (DEK) służący do szyfrowania plików maszyny wirtualnej;

7- ESXi teraz szyfruje dyski twarde maszyn wirtualnych za pomocą DEK, a następnie szyfruje DEK za pomocą KEK;

Uwaga: Po ponownym uruchomieniu ESXi vCenter ponownie wyświetli monit KMS o podanie klucza, a cały proces się powtórzy.

Relacja zaufania między VMware vCenter i Kryptus kNET odbywa się w łatwy i praktyczny sposób: z wykorzystaniem protokołu manipulacji kluczami KMIP. Aby to zrobić, należy dodać klaster KMS, który będzie używany do vCenter, podając adres IP, port, użytkownika i hasło kNET. Następnie generowane jest żądanie podpisania certyfikatu (CSR), które musi zostać podpisane przez KMS i zwrócone do vCenter, który od tego momentu nawiązuje relację zaufania z KMS.

Korzyści z integracji VMware i kNET

Dzięki integracji klaster serwerów zyskuje dwie warstwy ochrony! Dzieje się tak, ponieważ każda maszyna wirtualna jest szyfrowana unikalnym kluczem DEK, a każdy klucz DEK jest z kolei szyfrowany unikalnym kluczem KEK. Nawet jeśli atakujący odkryje klucz DEK, bez klucza KEK – który jest bezpiecznie przechowywany w module kNET HSM – nie będzie miał dostępu do plików.

„Zanim zaczęliśmy używać KMS zintegrowanego z VMware do zarządzania i przechowywania kluczy, musieliśmy ręcznie wprowadzać hasła na każdym serwerze. Teraz ten proces stał się o wiele bardziej praktyczny, oprócz znacznej poprawy bezpieczeństwa całego środowiska” — mówi Igor, kierownik ds. IT w Kryptus.

Igor radzi również, aby rozważyć skonfigurowanie więcej niż jednego kNET, tworząc klaster KMS, aby zwiększyć dostępność systemu, ponieważ ESXi po ponownym uruchomieniu i/lub utworzeniu nowej maszyny wirtualnej żąda kluczy, które muszą zostać podane pod groźbą niedostępności.