Backup fuori sede crittografato utilizzando GPG con chiave privata mai sul server di backup?

Ho un server di backup, che crea archivi xzcompressi tardi alberi di directory per il backup. Questi archivi di tar possono ottenere enormi (più TB), sono splitin pezzi (2,5 TB) e ogni pezzo è scritto su un nastro LTO-6 e i nastri vanno fuori sede.

Ora voglio aggiungere la crittografia. Posso GPG crittografare l'archivio tar prima di suddividere, utilizzando la crittografia della chiave pubblica-privata e con uno o più destinatari (chiavi pubbliche dell'amministratore).

Tuttavia, in caso di ripristino, almeno un amministratore deve inserire la propria chiave privata sul server di backup, poiché i file sono troppo grandi per essere decompressi altrove.

GPG utilizza uno schema di crittografia ibrida sotto il cofano, con una cifra simmetrica come AES con una chiave di sessione e solo quella chiave di sessione viene crittografata per i destinatari con la chiave pubblica-privata.

Esiste un modo per consentire a un amministratore di fornire la chiave di sessione per la decrittografia del file da recuperare senza inserire la chiave privata sul server di backup ?

Potrei reinventare la ruota ovviamente:

• creare una chiave di sessione casuale sul server di backup per ciascun file di cui eseguire il backup
• utilizzare la crittografia simmetrica GPG per crittografare il file
• utilizzare la crittografia asimmetrica GPG per crittografare la chiave di sessione per ciascun destinatario

Ma esiste un modo "standard" o integrato o delle migliori pratiche per raggiungere il sopra?

Questo è sicuramente possibile con le opzioni --show-session-keye --override-session-key.

Innanzitutto è necessario l'inizio del file crittografato. Qui è dove è memorizzata la chiave di sessione crittografata.

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

Quindi copiarlo sulla workstation e recuperare la chiave di sessione

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'

Ora puoi decrittografare il file usando la chiave di sessione

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>"

Sembra che la maggior parte della tua domanda abbia ricevuto risposta, tuttavia, se il tuo team di amministratori è diffidente nei confronti delle chiavi private che finiscono fuori dal loro controllo locale, potresti considerare sshfsdi montare i backup remoti su una sessione ssh.

Installa tramite apt sul sistema di ciascun amministratore remoto

sudo apt-get install sshfs

Supponendo che la configurazione ssh degli amministratori sia simile al seguente

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

Quindi i tuoi amministratori possono usare qualcosa di simile al seguito per il montaggio

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

Per smontare dopo l'ispezione l'amministratore remoto può utilizzare quanto segue

fusermount -u /mnt/remote

La cosa dolce dell'uso di sshfs è che sono necessarie solo le chiavi pubbliche per GnuPG e ssh sul server remoto, le relative chiavi private rimangono sui sistemi che possiedono. Il secondo aspetto positivo è che fino a quando non viene letta o consultata la maggior parte delle informazioni sui file rimane sul relativo file system.

Se stai ancora cercando strumenti per facilitare la crittografia automatica di registri o directory, potresti voler controllare il prof of concept tool che ho inviato a GitHub (in particolare lo scenario quattro scritto per l' sshsfuso) che con un po 'di personalizzazione crittograferà felicemente quasi tutti dati tramite GnuPG. Ma tieni presente che è sperimentale e alcune delle sue funzionalità possono causare la corruzione dei dati se utilizzati in modo improprio. Il codice sorgente è inferiore a ~ 1600 ~ righe, quindi è possibile effettuare l'audit in meno di un fine settimana.

È possibile ottenere ulteriore sicurezza impostando la configurazione ssh del server remoto per chroot gli utenti per consentire l'accesso solo alla directory crittografata e disabilitare la shell interattiva per le chiavi degli amministratori utilizzate in questo modo.

Se vuoi che la chiave segreta sia tenuta lontana dai dischi rigidi, potresti creare un ramdisk (ricordi quelli?) E caricare le chiavi segrete lì dalla tua posizione non sul server, se necessario. Usalo per decifrare e quando finito lo sovrascrivi con / dev / random. Il segreto deve essere nella RAM per essere comunque utilizzato da GPG, quindi perché non due volte?

Se non riesci a lasciare una chiave segreta sul server, anche nella RAM, hai un'impossibilità tecnica. GPG deve avere la chiave segreta da qualche parte per decifrare qualsiasi cosa.

Informazioni ramdisk: /unix/66329/creating-a-ram-disk-on-linux