Architektura IB wirtualizacji wg RS BR IBBS-2.8-2015

Algorytm projektowania architektury bezpieczeństwa informacji w środowiskach wirtualizowanych według RSC BR IBBS-2.8-2015

Podczas projektowania architektury bezpieczeństwa informacji w środowiskach wirtualizowanych kluczowym krokiem jest określenie konturów bezpieczeństwa. Jeśli system przetwarza operacje płatności (PTP) lub dane osobowe (ISPDDn), wydzielane są oddzielne kontury: PTP i ISPDDn. W przypadku braku takich wymagań kontury ustala się na podstawie krytyczności procesów biznesowych.

Fizyczna izolacja serwerów hosta jest obowiązkowa dla maszyn wirtualnych z różnych konturów. Umieszczenie na osobnych serwerach fizycznych minimalizuje ryzyko rozprzestrzeniania zagrożeń. Gdy maszyny wirtualne znajdują się na wspólnych hostach, stosuje się izolację logiczną na poziomie hipervizora zgodnie z punktem 6.2 dokumentu.

Rozdzielenie dostępu sieciowego realizowane jest za pomocą certyfikowanych zapór ogniowych na poziomie L3. Dostęp do maszyn wirtualnych konturu PTP możliwy jest wyłącznie z ARM PTP, do ISPDDn — z ARM ISPDDn (punkty 6.3, 6.4, 6.9).

Konfiguracja hipervizora i zarządzanie obrazami VM

Hipervizor powinien być preferowany jako certyfikowany (punkt 6.11). Konfiguracja obejmuje:

• przydział odrębnych obszarów pamięci RAM dla poszczególnych konturów (punkt 6.5).
• blokadę nieautoryzowanego wymiany danych między maszynami wirtualnymi a systemem operacyjnym hosta.

Zarządzanie obrazami VM powinno odbywać się zgodnie ze ścisłą procedurą:

• Tworzenie obrazu bazowego.
• Testowanie w izolowanym segmencie na osobnym serwerze.
• Sprawdzenie kodu szkodliwego oraz poprawności systemów zabezpieczeń (SZZ).
• Zatwierdzenie przez służbę bezpieczeństwa przed wdrożeniem (punkty 7.1–7.8).

Jeden komponent serwerowy ABS — jedna maszyna wirtualna, bez łączenia. W przypadku VDI zabrania się zapisywania zmian w obrazie bazowym z wymuszoną rewersją.

Obraz bazowy -> Segment testowy -> Sprawdzenie kodu/SZZ -> Zatwierdzenie BI -> Produkcja

Administracja i ochrona komponentów

Administracja hipervizorem i hostami prowadzona jest z wydzielonych ARM w segmencie zarządzania (punkt 8.1). Stosowane są certyfikowane SZZ chroniące przed nieuprawnionym dostępem (NSD, punkt 8.2). Komponenty wirtualizacji nie mogą znajdować się wewnątrz maszyn wirtualnych (punkt 8.4).

Wymagane jest logowanie:

• uruchamianie/kończenie działania maszyn wirtualnych.
• zmiany konfiguracji sieciowych.
• kopiowanie obrazów.
• logowanie administratorów (punkt 8.7).

Ochrona maszyn wirtualnych skupia się na poziomie hipervizora: antywirus bez agenta w systemach gościnnych (punkt 9.6). Certyfikowane SZZ kontrolują integralność oprogramowania i dostęp (punkt 9.4).

Dla ARM wprowadza się dwustopniową autoryzację (tokeny) do konturów PTP/ISPDDn (punkt 10.5), zaufaną ładowanie systemu operacyjnego oraz kontrolę portów (punkty 10.1, 10.3).

Rozdzielenie ról i ochrona systemów magazynowania danych

Rozdzielenie uprawnień wyklucza połączenie ról (punkt 12.2):

• Administrator VM: obsługa aplikacji wewnątrz maszyn wirtualnych.
• Administrator wirtualizacji: tworzenie VM, zarządzanie obrazami.
• Administrator bezpieczeństwa wirtualizacji: konfiguracja sieci i zasad dostępu.
• Administrator SZZD: zarządzanie macierzami dysków.

Żaden specjalista nie ma dostępu do wszystkich poziomów: hipervizora, magazynu danych i zawartości maszyn wirtualnych.

SZZD segmentowane są na logiczne sekcje według konturów (PTP, ISPDDn, systemowe, punkt 13.1). Dostęp do sekcji PTP możliwy wyłącznie z maszyn wirtualnych PTP (punkt 13.3.1).

Co jest ważne

• Fizyczna izolacja dla różnych konturów PTP/ISPDDn jest obowiązkowa, izolacja logiczna — tylko dla jednego konturu.
• Wszystkie SZZ i hipervizor wymagają certyfikacji FSB/FSTÉK.
• Model ról wyklucza połączenie administracji hipervizora, SZZD i VM.
• Obrazy VM podlegają obowiązkowemu testowaniu i zatwierdzeniu BI.
• Logowanie zdarzeń hipervizora i SZZ jest centralizowane na osobnym serwerze.

— Editorial Team