¿Copia de seguridad cifrada fuera del sitio utilizando GPG con clave privada nunca en el servidor de copia de seguridad?

Tengo un servidor de respaldo, que crea archivos xzcomprimidos tarde árboles de directorios para respaldar. Estos archivos de alquitrán pueden ser enormes (múltiples TB), están spliten pedazos (2.5TB), y cada pieza está escrita en una cinta LTO-6, y las cintas salen del sitio.

Ahora quiero agregar cifrado. Puedo GPG cifrar el archivo tar antes de dividirlo, usando el cifrado de clave pública-privada y con uno o más destinatarios (claves públicas de administrador).

Sin embargo, en caso de recuperación, al menos un administrador debe poner su clave privada en el servidor de respaldo, ya que los archivos son demasiado grandes para desempaquetarlos en otro lugar.

GPG utiliza un esquema de cifrado híbrido bajo el capó, con un cifrado simétrico como AES con una clave de sesión, y solo esa clave de sesión obtiene una clave pública-privada cifrada para los destinatarios.

¿Hay alguna manera de permitir que un administrador proporcione la clave de sesión para descifrar el archivo a recuperar sin poner la clave privada en el servidor de respaldo ?

Podría reinventar la rueda, por supuesto:

• crear una clave de sesión aleatoria en el servidor de respaldo por cada archivo a respaldar
• usar cifrado simétrico GPG para cifrar el archivo
• use el cifrado asimétrico GPG para cifrar la clave de sesión para cada destinatario

Pero, ¿hay una forma "estándar" o integrada o de mejores prácticas para lograr lo anterior?

Esto es definitivamente posible con las opciones --show-session-keyy --override-session-key.

Primero necesitas el comienzo de tu archivo encriptado. Aquí es donde se almacena la clave de sesión cifrada.

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

Luego cópielo en su estación de trabajo y recupere la clave de sesión

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'

Ahora puede descifrar el archivo con su clave de sesión

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

Parece que la mayor parte de su pregunta ha sido respondida, sin embargo, si su equipo administrador desconfía de las claves privadas que terminan fuera de su control local, podría considerar sshfsmontar las copias de seguridad remotas en una sesión ssh.

Instalar a través de apt en el sistema de cada administrador remoto

sudo apt-get install sshfs

Asumiendo que la configuración ssh de los administradores se parezca a la siguiente

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

Entonces sus administradores pueden usar algo como a continuación para montar

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

Para desmontar después de la inspección, el administrador remoto puede usar lo siguiente

fusermount -u /mnt/remote

Lo bueno de usar sshfs es que solo se necesitan claves públicas para GnuPG y ssh en el servidor remoto, las claves privadas relacionadas permanecen en los sistemas que los poseen. La segunda parte es que hasta que se lea o acceda, la mayor parte de la información del archivo permanece en su sistema de archivos relacionado.

Si todavía está buscando herramientas para facilitar el cifrado automático de registros o directorios, es posible que desee verificar la herramienta de concepto que he introducido en GitHub (específicamente el Escenario Cuatro escrito para su sshsfuso) que con una pequeña personalización cifrará felizmente casi cualquier datos a través de GnuPG. Pero tenga en cuenta que es experimental y que algunas de sus características pueden dañar los datos si se usan incorrectamente. El código fuente tiene menos de ~ 1600 ~ líneas, por lo que es muy posible auditar en menos de un fin de semana.

Se puede obtener seguridad adicional configurando la configuración ssh del servidor remoto para que los usuarios de chroot solo permitan el acceso al directorio encriptado y deshabiliten el shell interactivo para las claves de administrador que se usan de esta manera.

Si desea que la clave secreta se mantenga fuera de los discos duros, puede crear un disco RAM (¿recuerda eso?) Y cargar las claves secretas allí desde su ubicación segura que no está en el servidor según sea necesario. Úselo para descifrar y cuando termine, sobrescríbalo con / dev / random. El secreto tiene que ir a la RAM para que GPG lo use de todos modos, entonces, ¿por qué no dos veces?

Si no puede permitir que una clave secreta esté alguna vez en el servidor, incluso en la RAM, entonces tiene una imposibilidad técnica. GPG debe tener la clave secreta en algún lugar para descifrar cualquier cosa.

Información de Ramdisk: /unix/66329/creating-a-ram-disk-on-linux