Szyfrowana kopia zapasowa poza siedzibą przy użyciu GPG z kluczem prywatnym nigdy na serwerze kopii zapasowej?

Mam serwer kopii zapasowych, który tworzy xzskompresowane tararchiwa drzew katalogów, których kopie zapasowe należy wykonać. Te archiwa tar mogą stać się ogromne (wiele TB), są splitpodzielone na kawałki (2,5 TB), a każdy kawałek jest zapisywany na taśmie LTO-6, a taśmy odchodzą poza miejsce.

Teraz chcę dodać szyfrowanie. Mogę zaszyfrować archiwum tar przed podziałem, używając szyfrowania klucza publiczno-prywatnego i jednego lub większej liczby odbiorców (klucze publiczne administratora).

Jednak w przypadku odzyskiwania przynajmniej jeden administrator musi umieścić swój klucz prywatny na serwerze kopii zapasowej, ponieważ pliki są zbyt duże, aby można je było rozpakować w dowolnym innym miejscu.

GPG stosuje hybrydowy schemat szyfrowania pod maską, z symetrycznym szyfrem, takim jak AES z kluczem sesji, i tylko ten klucz sesji jest szyfrowany publiczno-prywatny klucz dla odbiorców.

Czy istnieje sposób, aby administrator udostępnił klucz sesji do odszyfrowania pliku do odzyskania bez umieszczania klucza prywatnego na serwerze kopii zapasowej ?

Mógłbym oczywiście wynaleźć koło:

• utwórz losowy klucz sesji na serwerze kopii zapasowej dla każdego pliku, którego kopię zapasową chcesz utworzyć
• do szyfrowania pliku użyj symetrycznego szyfrowania GPG
• użyj szyfrowania asymetrycznego GPG, aby zaszyfrować klucz sesji dla każdego odbiorcy

Ale czy istnieje „standardowy”, wbudowany lub najlepszy sposób osiągnięcia powyższego?

Jest to zdecydowanie możliwe dzięki opcjom --show-session-keyi --override-session-key.

Najpierw potrzebujesz początku zaszyfrowanego pliku. To tutaj przechowywany jest zaszyfrowany klucz sesji.

root@qwerty:~/gpg# head -c 1024k bigfile.gpg > head.gpg

Następnie skopiuj go na stację roboczą i pobierz klucz sesji

PS C:\Users\redacted\Downloads> gpg --show-session-key .\head.gpg
gpg: encrypted with 2048-bit RSA key, ID DC21D645, created 2016-02-01
  "admin <admin@domain.tld>"
gpg: session key: '9:926EC16DF1248A1C4401F5AD5D86C63C1BD4BF351ECEFB121C57EC209DE3933D'

Teraz możesz odszyfrować plik za pomocą klucza sesji

root@qwerty:~/gpg# gpg -d -o bigfile --override-session-key 9:926EC16DF1248A1C4401F5AD5D86C63C1BD4BF351ECEFB121C57EC209DE3933D bigfile.gpg
gpg: encrypted with 2048-bit RSA key, ID DC21D645, created 2016-02-01
  "admin <admin@domain.tld>"

Wygląda na to, że odpowiedź na większość pytań została jednak udzielona, ​​ale jeśli Twój zespół administratora obawia się, że klucze prywatne nie znajdą się pod ich kontrolą lokalną, możesz rozważyć sshfszamontowanie zdalnych kopii zapasowych podczas sesji ssh.

Zainstaluj za pośrednictwem apt w systemie każdego zdalnego administratora

sudo apt-get install sshfs

Zakładając, że konfiguracja ssh administratora wygląda jak poniżej

# configuration for ssh login to remote server
Host Remote
    Hostname Remote.web.domain
    User admin
    IdentityFile ~/.ssh/private.key

Wtedy twoi administratorzy mogą użyć czegoś takiego jak poniżej do montażu

# make a mount point
mkdir -p /mnt/remote
# mount remote directory to local file system
sshfs Remote:/path/to/encrypted/dir /mnt/remote

Aby odmontować po inspekcji, zdalny administrator może użyć następujących elementów

fusermount -u /mnt/remote

Słodką rzeczą w korzystaniu z sshfs jest to, że tylko klucze publiczne dla GnuPG i ssh są potrzebne na zdalnym serwerze, powiązane klucze prywatne pozostają w systemach, które są ich właścicielami. Drugą zaletą jest to, że do momentu odczytu lub uzyskania dostępu większość informacji o pliku pozostaje w powiązanym systemie plików.

Jeśli nadal szukasz narzędzi ułatwiających automatyczne szyfrowanie dzienników lub katalogów, możesz sprawdzić narzędzie prof concept, które przerzuciłem na GitHub (konkretnie scenariusz czwarty napisany do sshsfużytku), który przy niewielkim dostosowaniu z radością zaszyfruje prawie wszystkie dane za pośrednictwem GnuPG. Ale ostrzegam, że jest eksperymentalny, a niektóre jego funkcje mogą spowodować uszkodzenie danych, jeśli zostaną niewłaściwie wykorzystane. Kod źródłowy ma mniej niż ~ 1600 ~ linii, więc bardzo możliwe jest przeprowadzenie audytu w mniej niż weekend.

Dodatkowe bezpieczeństwo można uzyskać, konfigurując konfigurację ssh zdalnego serwera dla użytkowników chroot, aby umożliwić dostęp tylko do zaszyfrowanego katalogu i wyłączyć interaktywną powłokę dla kluczy administratora używanych w ten sposób.

Jeśli chcesz, aby tajny klucz był przechowywany poza dyskami twardymi, możesz utworzyć ramdysk (pamiętasz te?) I załadować tam tajne klucze z bezpiecznej lokalizacji poza serwerem w razie potrzeby. Użyj go do odszyfrowania, a po zakończeniu zastąp go / dev / random. Sekret musi przejść do pamięci RAM, aby GPG mogła z niego skorzystać, więc dlaczego nie dwa razy?

Jeśli nie możesz pozwolić, aby tajny klucz kiedykolwiek był na serwerze, nawet w pamięci RAM, oznacza to techniczną niemożliwość. GPG musi mieć gdzieś tajny klucz, aby coś odszyfrować.

Informacje o ramdysku: /unix/66329/creating-a-ram-disk-on-linux