Poniżej przedstawiam kilka sposobów na wykorzystanie przestrzeni dyskowej zdalnej maszyny w sposób zabezpieczający w pełni nasze dane. Założenie konfiguracji jest jedno – maszyna udostępniająca swój dysk nie może mieć wglądu w nasze dane, które przechowujemy ani w klucze, którymi dane są szyfrowane. Całość komunikacji ma być w pełni bezpieczna, a jedyny dostęp do danych ma być możliwy jedynie po ich odszyfrowaniu w locie, już na komputerze klienta.
Dzięki temu przejęcie docelowej maszyny nie będzie oznaczało od razu wycieku naszych danych. Ma to być zapewnione począwszy od dostępu do samego jej dysku, aż po grzebanie w RAM’ie, gdzie mogą być przechowywane klucze szyfrujące, gdyby szyfrowanie odbywało się po zdalnej stronie. Kolejnym wymogiem jest aby sposób przechowywania danych był możliwy w środowisku serwerowym, gdzie chcemy zautomatyzować cały proces montowania i dostępu do danych, a więc bez żadnych UI oraz webowych interfejsów.
Duplicity
Najprostszym i zarazem najmniej funkcjonalnym na codzień rozwiązaniem jest zaprzęgnięcie narzędzia do backupów duplicity. Instalujemy go za pomocą:
sudo apt install duplicity
i od razu możemy korzystać. Jest to jeden z wygodniejszych sposobów na tworzenie backupów:
export PASSPHRASE="ala ma kota" duplicity full /home/shrek rsync://shrek@remote-host//backups/shrek
Plusy:
- Wsparcie dla przeróżnych backendów, od ssh, S3 aż po różne egzotyczne chmury
- Pozwala tworzyć pełne kopie jak również przyrostowe, co może ograniczyć ilość używanego miejsca
Wady:
- Działa jedynie jako backup na żądanie, nie da się wykorzystywać do bieżących operacji, tak jak system plików
- Potrafi się wysypać przy dużych ilościach plików
Ecryptfs po NFS
Kolejnym, trochę wygodniejszym do codziennego użytku narzędziem jest połączenie NFS i ecryptfs. Z racji, że jest to połączenie dwóch różnych systemów plików, potrafi sprawiać problemy podczas usypiania komputera lub gdy wystąpią problemy z siecią.
Instalacja i uruchomienie po stronie klienta (zakładam, że gdzieś stoi serwer NFS):
sudo apt install ecryptfs-utils nfs-utils mkdir /.backup mkdir /backup sudo mount -t nfs zdalny_host:/zasob_nfs /.backup sudo mount -t ecryptfs /.backup /backup # Tutaj ecryptfs poprosi o podanie nowego hasła, metody szyfrowania i kilku innych detali
Korzystając z takiego połączenia systemów plików nasz lokalny komputer pokaże w katalogu /backup odszyfrowaną zawartość katalogu /.backup. Każdy plik lub katalog w /backup odpowiada w ten sposób zaszyfrowanemu plikowi lub katalogowi w /.backup. Dzięki zastosowaniu NFS wszelkie dane, które zapisujemy w /backup są w formie zaszyfrowanej przesyłane przez sieć do hosta, który udostępnia swój katalog przez NFS.
Plusy:
- Działa na żywo, jak zwykły system plików
- Szyfrowanie jest wykonywane w całości po stronie klienta
- Nie angażuje sterownika plików, dzięki czemu trudniej o uszkodzenie plików na poziomie systemu plików
- Łatwe wykonywanie bezpiecznego backupu zaszyfrowanych danych – wystarczy rsync
Wady:
- Czasami potrafi mocno zwolnić, zwłaszcza gdy mamy duży ping lub powolne łącze
- Zawieszenie się lub zerwanie połączenia NFS skutecznie blokuje szyfrowany system plików, przez co procesy utykają na dostępie do plików w przypadku problemów sieciowych
NBD i LUKS
Ostatnim rozwiązaniem jest wykorzystanie serwera Network Block Device, który udostępni przez sieć całe urządzenie blokowe oraz systemu LUKS, który potrafi szyfrować całe urządzenia blokowe, ponad systemem plików. Dla zestawienia powyższych narzędzi nasz serwer będzie jedynie udostępniać pojedynczą partycję przez NBD, a my jako klient wykorzystamy mapowanie i odszyfrowanie jej przez driver LUKS, a następnie zamontujemy tak odszyfrowane urządzenie jako partycję ext4.
Instalacja po stronie klienta:
sudo apt install cryptsetup nbd-client
Instalacja po stronie serwera:
sudo apt install nbd-server
Następnie trzeba dodać plik eksportujący urządzenie (np. partycja /dev/sda4) do pliku /etc/nbd-server/conf.d/backup:
[backup]
exportname = /dev/sda4
Pierwsze montowanie i formatowanie partycji po stronie klienta:
sudo nbd-client -N backup 10.11.22.33 /dev/nbd0 # Sformatowanie dysku do luks i odszyfrowanie go. Po obu poleceniach cryptsetup zapyta o hasło sudo cryptsetup luksFormat /dev/nbd0 sudo cryptsetup luksOpen /dev/nbd0 backup # cryptsetup stworzy plik backup, który reprezentuje odszyfrowane urządzenie /dev/nbd0: sudo mkfs.ext4 /dev/mapper/backup # Na koniec stwórzmy katalog, gdzie będziemy montować naszą partycję mkdir /backup sudo cryptsetup luksClose backup
Montowanie i odszyfrowanie za każdym kolejnym razem:
sudo nbd-client -N backup 10.11.22.33 /dev/nbd0 sudo cryptsetup luksOpen /dev/nbd0 backup sudo mount /dev/mapper/backup /backup
i gotowe!
Zalety:
- W mojej opini najszybsze i najbardziej odporne na problemy sieciowe rozwiązanie
- Pozwala w pełni wykorzystać dowolny system plików
- W razie problemów dane można również odszyfrować na hoście lub dowolnym innym komputerze
Wady:
- Duże ryzyko uszkodzenia systemu plików w razie problemu z siecią
- Utrudniony backup całego dysku
Podsumowanie
Kombinacji i różnych narzędzi umożliwiających podobne zabezpieczenie jest cała masa, zwłaszcza, jeśli nie ograniczymy się do tych typowo konsolowych. Powyższe jednak pozwolą w miarę dobrze zabezpieczyć się na wypadek przejęcia maszyny hostującej nasze dane i to w sposób dość “paranoiczny”. Zarówno dane jak i klucze deszyfrujące nie są znane po stronie serwera. Może to być zetem sposób na ochronę nawet w najbardziej ekstremalnych przypadkach – zapobiega wyciągnięciu kluczy np. z pamięci wirtualnej maszyny po uśpieniu jej. Natomiast z racji tego, że nasz klient nie posiada samych zaszyfrowanych danych bezpośrednio u siebie, to w przypadku przejęcia fizycznej maszyny, która te dane przetwarza pozostają one dalej bezpieczne, w formie zaszyfrowanej.
Do przechowywania dużych ilości danych można w tym przypadku wykorzystać na przykład tanie serwery z oferty kimsufi (nie, nie płacą mi za to :), z dyskami do 2TB w parze z raspberry pi hostowanym u siebie pod biurkiem lub wirtualną maszyną w innej chmurze.