Categories
Najnowsze Wiadomości

Dlaczego NAS nie powinien pełnić funkcji systemu zarządzania kluczami (KMS): analiza architektury klienta KMIP i rozdziału obowiązków

KMS musi być oddzielony od danych produkcyjnych

Gdy firmy zaczynają wdrażać Key Management Interoperability Protocol (KMIP), KMS powinien być oddzielony od urządzenia przechowującego dane produkcyjne, zamiast powierzać oba zadania uniwersalnemu urządzeniu pamięci masowej. To podstawowa zasada rozdziału obowiązków (Separation of Duties, SoD): KMS i administrator danych produkcyjnych to dwa odrębne role.

Key Management System (KMS) pełni rolę fundamentu zaufania dla całego środowiska, wymagając środowiska o minimalnym śladzie i maksymalnym utwardzeniu. Natomiast NAS został zaprojektowany jako wysokopojemnościowy, wielousługowy system pamięci masowej, który działa jako klient KMIP, co sprawia, że oba rozwiązania są z natury przeciwstawne.

Filozofia projektowa QNAP: decyzja QNAP o niesupportowaniu QNAP NAS jako KMS to celowy zabieg architektoniczny mający na celu utrzymanie zasady rozdziału obowiązków — zarządzanie kluczami powierza się dedykowanemu, audytowalnemu KMS, a NAS odpowiada wyłącznie za żądanie kluczy kryptograficznych w razie potrzeby, co zapewnia zgodność i skuteczność architektury szyfrowania w organizacji.

Wykorzystanie NAS jako KMS: często pomijana pułapka zgodności

W praktyce zespoły często potrzebują KMS do centralnego zarządzania kluczami szyfrowania dla folderów współdzielonych i wolumin, aby spełnić wymagania audytu bezpieczeństwa. Jednak ze względu na kosztowność komercyjnych rozwiązań KMS, wykorzystują urządzenia pamięci masowej w celu obniżenia kosztów.

Jest to jednak niebezpieczna pozorna oszczędność: organizacje mogą sądzić, że zaoszczędziły na KMS, ale opierają się na niewłaściwej architekturze do realizacji najważniejszej funkcji. Zaoszczędzone środki nie przekładają się automatycznie na realne bezpieczeństwo, a także odbiegają od podstawowej filozofii projektowej KMS.

Niektóre rozwiązania pamięci masowej dostępne na rynku oferują wbudowaną rolę KMS, jednak z perspektywy audytu projekt, w którym dane i klucze znajdują się w tym samym systemie, nie zapewnia wyraźnego rozdziału odpowiedzialności. Pojedynczy interfejs zarządzania z kontrolą zarówno nad danymi, jak i kluczami stanowi pojedynczy punkt awarii, którego audytorzy raczej nie zaakceptują, niezależnie od siły zastosowanej technologii szyfrowania.

Root of Trust: Dlaczego KMS ma znacznie wyższe wymagania bezpieczeństwa niż zwykłe systemy

Kluczem do zrozumienia tego zagadnienia jest koncepcja pojedynczego źródła zaufania (Single Root of Trust).

Gdy organizacja dochodzi do momentu, w którym wymagany jest KMIP, oznacza to, że klucze szyfrujące muszą być centralnie zarządzane w całym środowisku, a nie używane wyłącznie przez systemy NAS. Typowe scenariusze korporacyjne on-premises obejmują:

  • Platformy wirtualizacyjne: szyfrowanie maszyn wirtualnych i magazynów danych VMware vSphere/vSAN, Hyper-V oraz Nutanix
  • Transparentne szyfrowanie danych w bazach danych (TDE): Oracle i SQL Server
  • Systemy backupu: klucze szyfrujące dla oprogramowania backupowego klasy enterprise, takiego jak Veeam i Commvault
  • Serwery współdzielonej pamięci masowej (NAS)
  • Samoszyfrujące macierze pamięci masowej
  • Samoszyfrujący sprzęt: Self-Encrypting Drives (SED), biblioteki taśmowe i samoszyfrujące macierze pamięci masowej

Gdy KMS staje się jedynym źródłem zaufania (Single Root of Trust) dla wszystkich powyższych urządzeń, jego wymagania bezpieczeństwa są znacznie wyższe niż jakiegokolwiek zarządzanego przez niego urządzenia. W szczególności, rozwiązania KMS klasy korporacyjnej muszą zwykle zapewniać: repozytorium kluczy obsługiwane przez moduł HSM (Hardware Security Module), ścisłą separację obowiązków, pełny i audytowalny cykl życia klucza oraz niezależną walidację modułu kryptograficznego.

Dlatego KMS pełni funkcję na wyższym poziomie bezpieczeństwa niż systemy, którymi zarządza.

Sam materiał kluczowy jest niezwykle niewielki — klucze, metadane i polityki razem w większości firm zajmują zaledwie kilka megabajtów. Idealny KMS stosuje zasadę minimalizacji (principle of minimization): usuwa wszystkie funkcje niezwiązane z zarządzaniem kluczami, zachowuje tylko jedną odpowiedzialność, utrzymuje granicę zaufania możliwie najmniejszą i ułatwia niezależny audyt.

Dla kontrastu, wartość NAS opiera się na jego wielofunkcyjności, obejmującej dużą pojemność, usługi plikowe, rozbudowany ekosystem aplikacji oraz obsługę różnorodnych protokołów komunikacyjnych. To są atuty NAS jako platformy danych, ale reprezentują one inne założenia projektowe niż „minimalistyczne i jednofunkcyjne” podejście wymagane przez KMS.

QNAP QuTS hero: jak prawidłowo realizować rolę „KMIP Client”

W architekturze QNAP rola NAS polega na działaniu jako zaawansowany klient KMIP — powierza przechowywanie kluczy dedykowanemu KMS, koncentrując się na podstawowych funkcjach pamięci masowej. Klient KMIP QuTS hero oferuje następujące cechy projektowe:

  • Zdalne przechowywanie kluczy: Klucze szyfrujące są przechowywane na zdalnym serwerze KMIP, co minimalizuje ryzyko nieautoryzowanego dostępu lub utraty kluczy na poziomie NAS.
  • Wymiana kluczy zgodna z FIPS 140-3: Proces wymiany kluczy został zaprojektowany zgodnie z wymaganiami bezpieczeństwa FIPS 140-3 oraz standardami zgodności klasy korporacyjnej.
  • Mutual TLS szyfrowany kanał: NAS i serwer KMIP komunikują się przez mutual TLS (mTLS). Domyślnie wykorzystywany jest port 5696, a obie strony muszą mieć zainstalowane ważne, niewygasłe certyfikaty.
  • Automatyczne stosowanie kluczy i odblokowanie przy starcie: Szyfrowane foldery udostępnione oraz szyfrowane jednostki LUN mogą automatycznie pobierać klucze. Dopóki klient i serwer utrzymują łączność, dostęp pozostaje możliwy po restarcie systemu.
  • Pełny cykl życia certyfikatów: Obsługuje generowanie, import, wymianę, pobieranie i usuwanie certyfikatów, umożliwiając użytkownikom podgląd statusu i dat ważności.

Jeśli chodzi o obsługiwane wersje, klient KMIP jest dostępny od QuTS hero h6.0. Aby go zainstalować i skonfigurować, zainstaluj „KMIP Client” z App Center, a następnie przejdź do Panel sterowania > System > Security > KMIP Settings.

To właśnie jest przewaga takiego podziału odpowiedzialności: najwyższy poziom bezpieczeństwa związany z walidacją modułu kryptograficznego CMVP realizuje profesjonalny KMS, a nie każde urządzenie pamięci masowej z osobna. NAS musi jedynie spełnić wymagania projektowe FIPS 140-3 dla wymiany kluczy i przekazać zaufanie odpowiedniemu organowi.

Jak wybrać KMS zgodny z KMIP

Po wdrożeniu modelu „NAS-as-a-client” kolejnym krokiem jest wybór odpowiedniego organu zarządzania kluczami. Zalecanym podejściem jest wybór jednej z dwóch ścieżek w zależności od wymagań audytowych i budżetu:

Scenariusz Zalecane podejście Przykładowe rozwiązania
Wymagania dotyczące rygorystycznego audytu Wykorzystaj istniejące certyfikowane komercyjne rozwiązania KMS Thales CipherTrust Manager, Entrust KeyControl, IBM Guardium Key Lifecycle Manager, HashiCorp Vault Enterprise (KMIP secrets engine)
Budżet jest głównym kryterium Wdróż samodzielnie hostowany serwer KMIP na dedykowanym, kontrolowanym i audytowalnym hoście z użyciem kontenerów HashiCorp Vault / OpenBao (KMIP engine), Cosmian KMS; PyKMIP wyłącznie do testów

Kluczowe nie jest to, na którym hoście działa KMS, lecz czy host jest utwardzony, egzekwowana jest kontrola dostępu, a ścieżki audytu mogą być generowane do weryfikacji. Tak długo, jak organ zarządzający kluczami pozostaje niezależny od produkcyjnej pamięci masowej i spełnia opisane powyżej wymagania ładu, zarówno rozwiązania komercyjne, jak i samodzielnie hostowane mogą stanowić solidną podstawę dla Twojej architektury szyfrowania.

Zrozumienie KMIP i FIPS: pełny przegląd

Podczas walidacji audytu szyfrowania trzy pojęcia są często ze sobą mylone, ale audytorzy badają je na zupełnie różnych poziomach:

Pojęcie Co jest weryfikowane Wyjaśnienie
Współdziałanie (interoperacyjność) Czy KMS może połączyć się przez KMIP i działać poprawnie „Połączenie protokołu działa prawidłowo”
Walidacja algorytmów (NIST CAVP) Czy implementacje algorytmów przez dostawcę, takich jak AES/SHA/RSA, są poprawne „Operacje matematyczne są poprawne”
Walidacja modułu kryptograficznego (NIST CMVP, FIPS 140-2/140-3) Czy cały moduł kryptograficzny, w tym zarządzanie kluczami i granica modułu kryptograficznego, przeszedł walidację i uzyskał ważny certyfikat „Cały sejf został zwalidowany pod kątem wymagań bezpieczeństwa”

Dla audytorów najważniejszym i zwykle najbardziej rygorystycznym wymaganiem jest walidacja modułu kryptograficznego. Samo przejście implementacji algorytmu CAVP lub testowanie modułu nie oznacza posiadania ważnego certyfikatu CMVP, który obejmuje komponenty zarządzania kluczami, na których polegasz. Dlatego niezależnie od wybranego rozwiązania KMS zaleca się weryfikację statusu walidacji bezpośrednio na liście walidacyjnej NIST CMVP oraz potwierdzenie zakresu certyfikatu z audytorami.

Sam KMIP to otwarty standard protokołu, który umożliwia komunikację klientom i serwerom KMIP różnych dostawców. Jednak „współpraca” to dopiero punkt wyjścia; prawdziwym wyzwaniem dla firm jest uzyskanie zgodności z wymaganiami formalnymi.

Wniosek: Trzymaj zamek i klucz oddzielnie

W momencie wdrożenia KMIP celem nie jest przekształcenie NAS w KMS, lecz ustanowienie niezależnego, zaufanego i audytowalnego organu zarządzania kluczami dla całego środowiska.

Jako klient KMIP, QNAP NAS powierza zarządzanie kluczami profesjonalnemu KMS w celu scentralizowanego nadzoru, koncentrując się na usługach pamięci masowej i danych. Nie oznacza to braku funkcji, lecz świadomą decyzję o umieszczeniu źródła zaufania tam, gdzie powinno się ono znajdować. Oddzielenie zamka od klucza to fundament skutecznego bezpieczeństwa i udanych audytów.

Aby dowiedzieć się więcej o procesie konfiguracji klienta KMIP (QuTS hero), zapoznaj się z oficjalnym Samouczek QNAP:

https://www.qnap.com/go/how-to/tutorial/article/how-to-use-kmip-client-for-secure-key-management

Często zadawane pytania (Często zadawane pytania)

P: Czy NAS może być używany jako serwer KMIP ?

Odpowiedź: QNAP NAS został celowo zaprojektowany wyłącznie do obsługi roli klienta KMIP, a nie serwera. KMS pełni funkcję źródła zaufania i realizuje zasadę minimalizacji (pojedyncza odpowiedzialność i możliwie najmniejszy obszar zaufania), podczas gdy NAS to wielopojemnościowa, wielozadaniowa platforma danych. Oba rozwiązania mają różne cele projektowe. Nawet zakupienie kolejnego NAS przeznaczonego do roli KMS oznaczałoby wykorzystanie platformy wielozadaniowej do zadania wymagającego systemu jednofunkcyjnego, pozostawiając większość jej zasobów niewykorzystaną. Właściwym podejściem jest użycie NAS jako klienta oraz zarządzanie i ochrona kluczy przez dedykowany, audytowalny, niezależny KMS.

P: Od której wersji oprogramowania QNAP po raz pierwszy obsługuje klienta KMIP ?

Odpowiedź: Klient KMIP jest obsługiwany od wersji QuTS hero h6.0. Zainstaluj KMIP Client z poziomu App Center i włącz go w ustawieniach zabezpieczeń w Panel sterowania.

P: Przy ograniczonym budżecie, czy konieczny jest zakup kosztownego komercyjnego KMS?

Odpowiedź: Niekoniecznie. Przedsiębiorstwa mogą wdrożyć rozwiązania open-source/wspierane przez społeczność z silnikami KMIP, takie jak HashiCorp Vault (Enterprise) lub OpenBao, w niezależnym i utwardzonym środowisku maszyny wirtualnej lub kontenera. Kluczowe jest fizyczne odseparowanie tego środowiska od NAS oraz rozdzielenie kontroli dostępu, przy jednoczesnym zapewnieniu możliwości generowania pełnych ścieżek audytu dostępu.

Leave a comment

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *