W praktyce jak mamy do czynienia z danymi firmowymi, własnymi lub tym bardziej powierzonymi zawsze dobrym pomysłem jest trzymać ja na zaszyfrowanych dyskach. Ułatwia to kilka spraw jak na przykład to, że dane na dyskach opuszczając nasze serwery stają się bezwartościowe. Wbrew pozorom nie zawsze wymieniamy zupełnie nie sprawne dyski. Czasem chcemy poszerzyć pool czasem dyski zaczynają zgłaszać błędy i wymieniem je przed faktycznym ostatecznym uszkodzeniem. Co prawda i tak w przypływie zdrowej paranoi warto się pobawić psycho-dysko-rozwiercacza albo przeprowadzić głębokie czyszczenie przez nadpisanie całego dysku np. zerami.
Pamiętajmy, że zwłaszcza jak wymieniamy uszkodzony dysk to zapisane dane na talerzach w wypadku dysków talerzowych czy chipach w wypadku pamięci „błyskowych” używając niezrozumiałej kalki z angielskiego, dane na nich pozostaną i nie za bardzo może być je jak skasować.
Dodatkowo mam silne przeczucie, że macie lub powinniście mieć w swoich dokumentach RODO, że szyfrujecie dyski.
Jak to działa?
W praktyce szyfrowanie dysków w ZFS jest banalnie proste bo wystarczy je włączyć przy tworzeniu pool. Od razu uwaga o ile mi wiadomo nie ma możliwości zaszyfrowania stworzonego pool. O tym warto pamiętać przy planowaniu naszego NAS. Co prawda w zasadzie nic straconego bo ZFS działa hierarchicznie z perspektywy zasobów dyskowych.
Hierarchiczność ZFS
Już spieszę się wytłumaczyć. W ZFS nasz pool montujemy gdzieś w systemie plików w wypadku TrueNAS jest to katalog /mnt. Sam pool może być szyfrowany lub nie. Teraz każdy dodawany nowy Zvol czy Dataset montowany jest wewnątrz naszego pool czyli dodając dataset „Dane” będzie on miał adres „ /mnt/pool-name/Dane” i domyślnie będzie on dziedziczył wszystkie właściwości samego pool i tyczyć się to będzie zarówno faktu szyfrowania jak i parametrów szyfrowania ale również innych parametrów o których dzisiaj nie będę mówił jak de duplikacja, kompresja i jeszcze kilka innych.
Elastyczność Hierarchiczności ZFS
Domyślne parametry jednak można spokojnie zmieniać podczas tworzenia Dataset czy Zvol. Podkreślam, że tutaj też jak tworzymy zasób z włączonym szyfrowaniem to nie da się go wyłączyć i odwrotnie zaszyfrowanego zasobu nie da się odszyfrować. Jedyną opcją jest skasowanie i stworzenie zasobu jeszcze raz. Ale to i tak większa elastyczność niż stworzenie od nowa całego pool żeby go zaszyfrować. Dosyć jasno widać, że nawet jak stworzymy niezaszyfrowywany pool to łatwo będzie w nim tworzyć szyfrowane Dataset.
Zawsze niezaszyfrowany zasób może zawierać zaszyfrowany. Pamiętajmy jednak, że to działa tylko w jedną stronę. Jeżeli mamy zaszyfrowany pool czy zasób to w nim nie stworzymy niezaszyfrowywanie zasobu. Więc trochę droga w jedną stronę.
Co ciekawe Budując hierarchicznie nasz zestaw danych możemy mieć inne szyfrowanie w poszczególnych Dataset. Daje to bardzo ciekawą sytuacje w której możemy inaczej szyfrować jeden z Dataset i wcale nie mieć dostępu do jego zawartości. Do czego to się może przydać? To jest akurat bardzo przydatne. Wyobraźnie sobie sytuacje, że macie kilka instancji TrueNAS w różnych miejscach czy oddziałach czy nawet u kilku Klientów. No i jedną instancję TrueNAS na którą to wszystko jest replikowanie. O replikacji więcej opowiadam w materiale TrueNAS – replikacja – coś więcej niż backup. Każda z instancji ma szyfrowane dane, każda inaczej. Replikacja sprawia, że replikujemy dane na drugi serwer ,nawet albo zwłaszcza zaszyfrowane dane. Wcale nie podając kluczy do tych danych.
Z perspektywy tej centralnej instancji TrueNAS jesteśmy hostem umożliwiającym tworzenie backupu dla wielu innych TrueNAS. W wyniku tego mamy w naszym pool wiele Dataset zreplikowanych z innych TrueNAS każdy jest szyfrowany i to szyfrowany innych kluczem. Co więcej nie musimy nigdy poznać tego klucza. Zobaczcie jakie to dobre rozwiązanie. Mamy centralny backup który nawet nie musi wiedzieć co przechowuje.
Sposoby szyfrowania ZFS
No dobra szyfrowanie, klucze, hasła, ale jakie hasła, jakie klucze no i gdzie są? Zacznijmy od tego, że możemy zaszyfrować nasz zasób na dwa sposoby. Przy pomocy hasła i przy pomocy klucza.
Szyfrowanie kluczem
Szyfrowanie kluczem poza inna formą zapisu różni się funkcjonalnie tym, że klucze zostają zapisane w konfiguracji naszego TrueNAS. Co za tym idzie zawsze z poziomu naszego TrueNAS nasze zasoby są dla nas dostępne. To jest dobre rozwiązanie, ma jednak tą wadę, że jak ktoś za-ukradnie cały serwer to de facto będzie miał też klucze. Co prawda nie są one oczywiści nigdzie przechowywane w czystej formie ale chociażby jak już serwer się uruchomi to nasze klucze są w RAM żeby dało się na bieżąco odszyfrowywać dane. Raz wpisany klucz zostaje wpisany do koniuracji i już tam pozostaje. Nie mamy prostej możliwości zablokować zasobu raz odblokowanego kluczem.
ZFS szyfrowanie hasłem
Drugim sposobem zabezpieczenia danych jest hasło. Żeby odblokować dostęp do zasobu musimy każdorazowo po uruchomieniu wpisać ręcznie hasło. Na pewno jest to bezpieczniejsze ale każdy restart wymusi na nas ręczne logowanie się do serwer i wpisanie hasła żeby zasób był osiągalny. Z tego powodu nie ma możliwości w TrueNAS szyfrowania pool przy pomocy hasła a wyłącznie kluczem.
Szyfrowanie hasłem to zdecydowanie bardziej bezkompromisowe rozwiązanie niż szyfrowanie kluczem. Zasób szyfrowany hasłem możemy w każdej chwili zablokować i odblokować o odróżnieniu do zasobu szyfrowanego kluczem.
ZFS szyfrowanie – co możemy zmienić?
W trakcie życia zasobu Dataset czy Zvol możemy zmieniać typ szyfrowania z klucza na hasło i odwrotnie, możemy zmieniać zarówno hasło ja i klucze. Nie możemy jednak zmienić ani faktu szyfrowania czyli odszyfrować lub zaszyfrować oraz nie możemy zmienić algorytmu kodowania. Czyli jak już w momencie zakładania danego zasobu wybierzmy szyfrowanie np. AES-256-GCM to tak już pozostanie.
Wymagania szyfrowania ZFS
Jeżeli chodzi o wymagania. Musimy pamiętać, że proces szyfrowania i deszyfrowania obciąża procesor i odbywa się za każdym razem kiedy zapisujemy dane lub je odczytujemy. Bardzo pomocny a wręcz konieczny w wypadku szyfrowania danych jest zestaw procedur procesora AES-NI. I jeśli nasz procesor posiada taki zestaw procedur to narzut pracy procesora na szyfrowanie nie powinien być znaczący zato włączenie szyfrowania w wypadku użytkowania procesora pozbawionego zestawu tych procedur spowoduje znaczną degradację osiągów. Więc raczej nie zalecane.
Wszystkie nowe procesory serwerowe raczej będą posiadały AES-NI. Starsze procesory lub nie przeznaczone serwerowe już nie zawsze będą miał ten zestaw procedur. Możecie to sprawdzić na stronie producenta procesora lub po prostu wpisując polecenie w konsoli.
dmesg | grep -i aes
lub
cpuid | grep -i aes
Podsumowanie
Ważna uwaga na koniec. Mówię to trochę dla zasady ale tez dlatego, żeby uniknąć pytań pod tytułem „Nie zapisałem klucza lub hasła szyfrującego, co mam zrobić?” Odpowiedz jest całkiem prosta „NIC”. Dla tego jeśli zdecydujecie się na szyfrowanie zawsze wrzućcie klucze lub hasło do hasłownika. No i żeby ten nasz hasłownik nie znajdował się czasem na naszym szyfrowanym zasobie. Wydaje się to wam oczywiste? Oj można się naciąć.
Jeśli chcielibyście dowiedzieć się więcej o TrueNAS napiszcie do nas. Opowiemy Wam jak działa i dlaczego warto?