Bacula.pl

- rozwiązanie kopii zapasowych dla wymagających
Kategorie: WSZYSTKIE Newsy Artykuły Blog

Szyfrowanie danych na wolumenach w Bacula cz.2

20 czerwiec 2015, autor: Marcin Haba (gani)

news

W drugiej części artykułu o szyfrowaniu danych na wolumenach postaram się przedstawić etap przygotowania do szyfrowania danych od strony plików konfiguracyjnych Bacula.

Po teoretycznym wstępie z pierwszej części artykułu, teraz spróbuję skonfigurować klienta Bacula do pracy z zaszyfrowanymi danymi w operacji przywracania danych jak i do pracy z szyfrowaniem danych przy akcji backupu.

Przygotowanie Bacula

Przed przystąpieniem do konfiguracji szyfrowania danych na wolumenach potrzeba upewnić się, że klient Bacula został skompilowany z obsługą OpenSSL poprzez przełączniki przy kompilacji:

./configure --enable-openssl --with-openssl ... itd.

Inaczej szyfrowanie danych nie będzie możliwe.

Przygotowanie kluczy RSA

Do wygenerowania kluczy szyfrujących i samopodpisanego (ang. self-signed) certyfikatu wykorzystam program openssl.

Jako pierwszą parę kluczy przygotuję prywatny klucz główny i publiczny wraz z certyfikatem x509 w następujący sposób:

- prywatny klucz główny:

openssl genrsa -out klucz_glowny_prv.pem 4096

- samopodpisany certyfikat x509 zawierający publiczny klucz główny:

openssl req -new -key klucz_glowny_prv.pem -x509 -out klucz_glowny_crt.pem

...wypełniam potrzebne pola dla certyfikatu.

- prywatny klucz klienta ganihome-fd:

openssl genrsa -out ganihome-fd_prv.pem 4096

- samopodpisany certyfikat x509 zawierający publiczny klucz klienta ganihome-fd:

openssl req -new -key ganihome-fd_prv.pem -x509 -out ganihome-fd_crt.pem

...wypełniam potrzebne pola dla certyfikatu.

W wyniku powyższych komend powstały następujące pliki:

(1) ganihome-fd_prv.pem  <---- klucz prywatny klienta ganihome-fd
(2) ganihome-fd_crt.pem  <---- certyfikat x509 (zawiera klucz publiczny klienta)
(3) klucz_glowny_prv.pem <---- główny klucz prywatny
(4) klucz_glowny_crt.pem <---- certifikat x509 (zawiera główny klucz publiczny)

UWAGA!

W tym zestawieniu klucz prywatny z punktu (3) to najważniejszy klucz z tych wszystkich. Za jego pomocą będzie możliwość odszyfrowania danych zaszyfrowanych przez wszystkich klientów Bacula, którzy używają jako publicznego klucza głównego klucz z certyfikatu (4). Z tego powodu warto umieścić klucz (3) w bezpiecznym miejscu i najlepiej z dala od komputerów ze środowiskiem Bacula.

UWAGA!

Główny klucz prywatny (3) będzie używany tylko w przypadku utraty (czy też uszkodzenia) klucza prywatnego klienta (1). Nie będzie natomiast używany w konfiguracji Bacula.

Kolejnym krokiem przygotowania kluczy RSA jest połączenie klucza prywatnego i certyfikatu x509 klienta ganihome-fd w jednym pliku. Można to zrobić poprzez wydanie komendy:

cat ganihome-fd_prv.pem ganihome-fd_crt.pem > ganihome-fd.pem

Konfiguracja klienta Bacula do pracy

Dyrektywy zasobu FileDaemon (w bacula-fd.conf) odpowiedzialne za szyfrowanie danych klienta na wolumenach to:

PKI Signatures = Yes/No - załączenie/wyłączenie podpisywania danych przy użyciu certyfikatu

PKI Encryption = Yes/No - załączenie/wyłączenie szyfrowania danych klienta na wolumenach

PKI Keypair = lokalizacja pliku z kluczem prywatnym i certyfikatem klienta

PKI Master Key = lokalizacja z głównym certyfikatem

W moim przykładzie konfiguracja szyfrowania danych wygląda następująco:

PKI Signatures = Yes
PKI Encryption = Yes
PKI Keypair = "/usr/local/bacula7/etc/ganihome-fd.pem"
PKI Master Key = "/usr/local/bacula7/etc/klucz_glowny_crt.pem"

W kontekście całego zasobu FileDaemon, wygląda to jak poniżej.

FileDaemon {
  Name = ganihome-fd
  FDport = 9102
  WorkingDirectory = /usr/local/bacula7/working
  Pid Directory = /var/run
  Maximum Concurrent Jobs = 20
  PKI Signatures = Yes
  PKI Encryption = Yes
  PKI Keypair = "/usr/local/bacula7/etc/ganihome-fd.pem"
  PKI Master Key = "/usr/local/bacula7/etc/klucz_glowny_crt.pem"
}

Po zapisaniu takiej konfiguracji i restarcie klienta Bacula, można spróbować wykonać backup z szyfrowaniem danych.

*run job=BackupCatalog yes
Using Catalog "MyCatalog"
Job queued. JobId=928
*messages
20-cze 18:29 ganiwork.lan-dir JobId 928: shell command: run BeforeJob "/usr/local/bacula7/scripts/make_catalog_backup.pl MyCatalog"
20-cze 18:29 ganiwork.lan-dir JobId 928: Start Backup JobId 928, Job=BackupCatalog.2015-06-20_18.29.25_03
20-cze 18:29 ganiwork.lan-dir JobId 928: Using Device "FileChgr1-Dev1" to write.
20-cze 18:29 ganiwork.lan-sd JobId 928: Labeled new Volume "Vol-1862" on file device "FileChgr1-Dev1" (/tmp).
20-cze 18:29 ganiwork.lan-sd JobId 928: Wrote label to prelabeled Volume "Vol-1862" on file device "FileChgr1-Dev1" (/tmp)
20-cze 18:29 ganiwork.lan-sd JobId 928: Elapsed time=00:00:11, Transfer rate=3.142 M Bytes/second
20-cze 18:29 ganiwork.lan-sd JobId 928: Sending spooled attrs to the Director. Despooling 290 bytes ...
20-cze 18:29 ganiwork.lan-dir JobId 928: Bacula ganiwork.lan-dir 7.0.5 (28Jul14):
  Build OS:               x86_64-unknown-linux-gnu redhat One)
  JobId:                  928
  Job:                    BackupCatalog.2015-06-20_18.29.25_03
  Backup Level:           Full
  Client:                 "ganihome-fd" 7.0.5 (28Jul14) x86_64-unknown-linux-gnu,redhat,One)
  FileSet:                "Catalog" 2015-06-20 18:22:55
  Pool:                   "File" (From Job resource)
  Catalog:                "MyCatalog" (From Client resource)
  Storage:                "File1" (From Job resource)
  Scheduled time:         20-cze-2015 18:29:25
  Start time:             20-cze-2015 18:29:28
  End time:               20-cze-2015 18:29:39
  Elapsed time:           11 secs
  Priority:               11
  FD Files Written:       1
  SD Files Written:       1
  FD Bytes Written:       34,569,024 (34.56 MB)
  SD Bytes Written:       34,569,718 (34.56 MB)
  Rate:                   3142.6 KB/s
  Software Compression:   None
  VSS:                    no
  Encryption:             yes
  Accurate:               no
  Volume name(s):         Vol-1862
  Volume Session Id:      1
  Volume Session Time:    1434817753
  Last Volume Bytes:      34,596,015 (34.59 MB)
  Non-fatal FD errors:    0
  SD Errors:              0
  FD termination status:  OK
  SD termination status:  OK
  Termination:            Backup OK

O tym, że dane zostały zaszyfrowane podczas backupu może świadczyć linia z powyższego listingu:

  Encryption:             yes

Można również sprawdzić wolumen, czy znajdujące się na nim dane są rzeczywiście w postaci zaszyfrowanej.

Limity szyfrowania danych

1) Warto wiedzieć, że atrybuty plików (lokalizacje, rozmiar, uprawnienia...etc) pozostają na wolumenach w postaci niezaszyfrowanej. Szyfrowane są wyłącznie dane backupu.

Z tego też powodu możliwe jest np. wylistowanie informacji o plikach poprzez narzędzie bls:

# /usr/local/bacula7/sbin/bls -c /usr/local/bacula7/etc/bacula-sd.conf /tmp/Vol-1862 
bls: butil.c:289-0 Using device: "/tmp" for reading.
20-cze 18:43 bls JobId 0: Ready to read from volume "Vol-1862" on file device "FileChgr1-Dev1" (/tmp).
bls JobId 0: -rw-------   1 root     root        34565746 2015-06-20 18:29:28  /opt/bacula/working/bacula.sql
20-cze 18:43 bls JobId 0: End of Volume at file 0 on device "FileChgr1-Dev1" (/tmp), Volume "Vol-1862"
20-cze 18:43 bls JobId 0: End of all volumes.
1 files found.

2) Nie jest wspierane wypakowanie wolumenów zawierających zaszyfrowane dane poprzez narzędzie bextract. Po jego użyciu z takich wolumenów zostaną przywrócone jedynie struktury plików z metadanych volumenów, lecz pliki będą miały zerowy rozmiar (szyfrowanie danych, lecz nie metadanych).

Zakończenie

Na koniec chciałbym zachęcić osoby zainteresowane szyfrowaniem danych na wolumenach do lektury oficjalnej dokumentacji Bacula na ten temat:

http://www.bacula.org/7.0.x-manuals/en/main/Data_Encryption.html

http://www.bacula.org/7.0.x-manuals/en/main/New_Features_in_7_0_0.html#SECTION00316000000000000000

 


Ta strona używa plików cookies (niezbędnych do prawidłowego działania oraz analitycznych). Odmów Wybierz ciasteczka Zezwól na wszystkie (więcej informacji)