Loading

NewsyRSS - Newsy

news Bacula 7.4.0 - nowe wydanie
24 styczeń 2016

Nowa wersja Bacula 7.4.0

news Bacula 7.2.0 - nowe wydanie
14 sierpień 2015

Dziś została wydana wersja Bacula 7.2.0

news Baculum webGUI online demo
24 czerwiec 2015

Została przygotowana wersja online interfejsu web dla Bacula.

Bacula 7.4.7

Bacula.pl poleca

Open-E Data Storage Solutions

Jesteśmy na Facebooku

Znajdziesz nas w Google+

drukuj artykuł wersja PDF poleć artykuł znajomym

Szyfrowanie danych na wolumenach w Bacula cz.1

7 kwiecień 2015, autor: Marcin Haba (gani),

news

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.


Bacula w internecie

O nas

Bacula.pl jest niekomercyjnym serwisem poświęconym tematyce oprogramowania Bacula. Ideą witryny jest prezentacja funkcjonalności Bacula.

Jeśli jesteś zainteresowany współtworzeniem serwisu, zachęcamy do skontaktowania się z nami.

Kontakt:

Ta strona używa plików cookies (niezbędnych do prawidłowego działania). (więcej informacji)