Szyfrowanie danych na wolumenach w Bacula cz.1
7 kwiecień 2015, autor: Marcin Haba (gani)
Jedną z funkcjonalności Bacula stosowaną w celu podwyższenia ochrony składowanych danych na wolumenach przed dostępem osób niepożądanych jest funkcjonalność szyfrowania danych w Bacula. Opis tej funkcjonalności zamierzam zmieścić w dwuczęściowym artykule, którego pierwszą część stanowi niniejszy tekst.
W odróżnieniu od szyfrowania transmisji danych w Bacula, szyfrowanie na wolumenach nie wymaga tak wiele wysiłku przy konfigurowaniu Bacula, co szyfrowanie transmisji danych. To, co potrzebne nam będzie to jedna para kluczy RSA: publiczny i prywatny jako klucz główny, oraz po dodatkowej parze kluczy (publiczny i prywatny) dla każdego klienta Bacula, dla którego zachodzi potrzeba uruchomienia szyfrowania danych.
Uproszczona teoria
Szyfrowanie danych na wolumenach nie odbywa się, jakby mogło się wydawać po stronie storage daemon'a, lecz już na poziomie serwisu klienta Bacula. W operacji backupu z klienta do storage daemon'a przesyłane są dane już zaszyfrowane przez klienta. Podobnie podczas operacji przywracania danych, od storage daemon'a do klienta trafiają dane zaszyfrowane, i to sam klient deszyfruje te dane, a następnie dostarcza w zdefiniowane lokalizacje na komputerze klienta.
Dzięki tak działającej funkcjonalności szyfrowania, zarówno na komputerach z serwisami storage daemon'a jak i na komputerze director'a nie są potrzebne, a nawet nie powinny znajdować się żadne klucze klientów Bacula, ani tym bardziej klucz główny (czy to prywatny czy publiczny również). Dzięki temu nikt, oprócz określonego klienta Bacula, który używa szyfrowania danych na wolumenach, i administratora nie potrafi odszyfrować danych tego klienta. Potrafi to tylko określony klient i administrator (posiadacz głównego klucza prywatnego).
Typowe rozmieszczenia kluczy szyfrujących w funkcjonalności szyfrowania danych Bacula podstawia poniższa ilustracja.
Z powyższej ilustracji każdy z klientów posiada swoją własną parę kluczy (np. C-prv, C-pub) oraz główny klucz publiczny (GŁÓWNY-pub). Same dane backupu nie są jednak szyfrowane żadnym z tych kluczy. Dla każdej operacji backupu generowany jest losowy klucz sesji. Następnie klucz ten jest szyfrowany przy użyciu kluczy publicznych klienta (np. dla klienta C będzie to C-pub i GŁÓWNY-pub) i składowany w zaszyfrowanej formie w strukturze w standardzie ASN.1. Dopiero wtedy, gdy klucz sesji jest zaszyfrowany dla wszystkich odbiorców (dla serwisu klienta i dla administratora), następuje symetryczne szyfrowanie danych backupu przy użyciu klucza sesji.
Zaszyfrowane w powyższy sposób dane backupu są czymś w rodzaju sejfu z kluczykiem (klucz sesji) zamkniętym w środku, który można otworzyć tylko przy pomocy innego klucza (prywatnego klucza klienta lub prywatnego klucza głównego).
Poniżej przedstawiam dwa diagramy: przepływu dla szyfrowania danych w zadaniu backupu w Bacula i odszyfrowania danych w operacji przywracania danych.
Zakończenie części pierwszej
Na tym kończę wstęp teoretyczny do szyfrowania danych na wolumenach w Bacula. W drugiej i ostatniej części tego artykułu spróbuję przedstawić konfigurację szyfrowania danych od strony klienta Bacula.