Protegiendo la clave de descifrado en el servidor

Ciertamente estás en el camino correcto, pero es posible que lo estés haciendo un poco más complicado de lo que necesitas. Ha identificado correctamente que un sistema de cifrado simétrico crea el problema importante de la clave de descifrado que está presente en el sistema.

Si elige generar claves públicas / privadas para cada dato, es posible que esté haciendo su vida innecesariamente difícil además de "manejar" las claves privadas en una ubicación no óptima. Si está casado con los datos que se cifran con la clave pública del usuario, se puede modificar lo siguiente para almacenar dos copias de la clave simétrica cifrada. En este caso, sería mejor permitir que el usuario genere un administrador y le proporcione la clave pública en lugar de generar el par de claves para el usuario. (En otras palabras, realmente no quieres manejar la clave privada)

1. En una ubicación de confianza, genere un par de llaves públicas / privadas para el servidor / aplicación
2. Copie la clave pública (solo) en la ruta de la aplicación entre el usuario y la base de datos
3. Siempre que lleguen datos confidenciales, genere una clave secreta aleatoria y use esta clave para cifrar los datos confidenciales mediante un algoritmo simétrico (como AES)
4. Cifre la clave secreta aleatoria con la clave pública de la aplicación

Hay varias cosas que son ideales para este enfoque:

• Los sistemas backend y los usuarios con una necesidad comercial y los derechos adecuados pueden usar la clave privada en un sistema separado para recuperar los datos confidenciales
• Dado que solo se puede usar la clave privada para descifrar las claves secretas aleatorias, no hay una superficie de ataque útil aparte de la fuerza bruta sin procesar para un atacante que comprometa la aplicación
• La efectividad de un ataque de fuerza bruta se reduce drásticamente ya que un ataque exitoso contra cualquiera de las claves secretas aleatorias proporciona acceso solo a esa única pieza de datos; todas las otras claves son diferentes Esto hace que un ataque de fuerza bruta sea poco atractivo contra las claves simétricas.
• Actualmente, una fuerza bruta contra un par de llaves pública / privada de 4096 bits se considera intratable

Nuevamente, tienes la idea correcta, ¡pero quizás quieras simplificar un poco tu enfoque!

En primer lugar, @taz es bueno para usted por pensar fuera de la caja y mantener la seguridad de los datos de sus clientes. Sin embargo, tengo algunas preocupaciones y posibles sugerencias para mejorar el almacenamiento de datos ...

A su pregunta sobre la seguridad del sistema propuesto, veo el potencial de un compromiso de servidor encubierto que lleva a que los datos de sus clientes se integren la próxima vez que inicien sesión y veo el potencial de la cuenta de administrador como un punto único de falla / compromiso . Si bien el sistema propuesto sería más seguro que lo que he visto implementado por otros administradores de servidores, cubriré algunas otras opciones que quizás desee buscar en la inspiración para hacer que la seguridad sea aún más estricta.

opciones web / app habilitadas

1. Considere openpgpjs para el descifrado del cliente en el navegador

2. Considere openpgp- php para el cifrado del lado del servidor

3. Considere extraer el código fuente de ProtonMail o KeyBase sobre cómo esos equipos han implementado el cifrado / descifrado entre el servidor y el cliente.

La solución alternativa posible es sshfs + GnuPG cifrado ... es un poco de configuración para clientes y servidores, pero mantendrá los clientes & Las claves privadas de los administradores en su sistema de archivos relacionado y completamente fuera del sistema de archivos del servidor.

configura sshfs en el servidor de nube para hacer chroot a los clientes

1. Instalar sshfs en el servidor

   apt-get install sshfs
   

2. Haga un nuevo grupo para que los clientes sean reconocidos por

   group add sshfsmount
   

3. Agregar usuarios a un nuevo grupo y usuarios al servidor

   Var_users_list="bob,alise"
   Var_chroot_group="sshfsmount"
   for _user in ${Var_users_list//,/ }; do
       ## Add user
       adduser ${_user}
       ## Lock user account from logins and append to chroot group
       passwd -l ${_user}
       usermod -s /bin/false  -a -G ${Var_chroot_group} ${_user}
       ## Make directory for user to be chrooted to with restricting permissions
       mkdir -p ${Var_chroot_group}/${_user}
       chown root:root ${Var_chroot_group}
       chown ${Var_chroot_group}:${_user} ${Var_chroot_group}/${_user}
       chmod 760 ${Var_chroot_group}/${_user}
   done
   

4. Modificar la configuración del servidor ssh

   nano /etc/ssh/sshd_config
   ## snip, change subsystem settings
   Subsystem      sftp     internal-sftp
   ## snip, append the following to chroot the group
   Match Group sshfsmount
       ChrootDirectory /sshfsmount/%u
       ForceCommand internal-sftp
       AllowTcpForwarding no
       PermitTunnel no
       X11Forwarding no
   

5. Verifique la configuración y vuelva a cargar la configuración del servidor ssh

   sshd -T
   if [ "$?" = "0" ]; then
       /etc/init.d/ssh reload
   fi
   

  

La nota Subsystem sftp internal-sftp puede hacer que falle el inicio de sesión en ssh, así que intente iniciar sesión a través de una cuenta ssh normal después de reiniciar el servidor antes de cerrar sesión en el terminal ssh actual que realizó los cambios anteriores.

7. Agregar las claves públicas ssh de los clientes a autorizado

   Var_users_list="bob,alise"
   Var_key_dir="/ssh_pub_keys"
   for _user in ${Var_users_list//,/ }; do
       find "${Var_key_dir}" -xtype f | while read _key; do
           if grep -qE "${_user}" <<<"${_key}"; then
               mkdir -p /home/${_user}/.ssh
               cat "${_key}" >> /home/${_user}/.ssh/authorized_keys
           fi
       done
   done
   

Configuración para bob client sshfs

1. Instala sshfs

   apt-get install sshfs
   

2. Modificar la configuración del cliente ssh para hacer uso de las teclas

   nano /etc/ssh/ssh_config
   ## append the following config block
   host cloud_server
       User bob
       HostName host.domain
       IdentityFile /some/dir/private_ssh_key
       IdentitiesOnly yes
   

  

La nota host.domain debería apuntar al nombre de dominio o la dirección IP del servidor en la nube

3. Cree el directorio y monte el servidor de la nube en el sistema de archivos local de los clientes

   mkdir -p /mnt/glow_cloud
   sshfs cloud_server:/ /mnt/glow_cloud
   

  

Nota para desmontar usa lo siguiente

    fusermount -u /mnt/glow_cloud

4. Use el cifrado de clave pública GnuPG para que el usuario bob pueda cifrar un archivo con la salida guardada en el servidor en la nube

   cat some_local_file.txt | gpg -a -e -r bob@glow_cloud.domain -r admin@glow_cloud.domain -o /mnt/glow_cloud/enc_file.gpg
   

  

Nota para archivos de texto, el usuario bob puede usar un vim plugin / script para editar el archivo cifrado anterior en el control remoto servidor.

     

Nota para los archivos que no son de texto, es posible que desees revisar la última compilación de Paranoid_Pipes para obtener más inspiración y utilizar pasos similares a los anteriores. para que el cifrado / descifrado entre el servidor y los clientes sea automático. Sin embargo, esta última sugerencia es experimental y hace que los clientes mantengan la frase de paso de la clave de descifrado en su memoria local ... por lo que la seguridad superior descansa principalmente en los hombros de sus clientes porque el administrador puede usar esquemas de montaje similares para mantener sus propias claves privadas fuera del servidor también.

Hay algunas realidades molestas acerca de almacenar cualquier cosa en una nube pública. La única forma segura de descifrar / cifrar cualquier cosa es en el propio cliente local, y todos los problemas de manejo de claves privadas localmente: robo de teléfono, robo de llaves, etc. Usar la nube pública significa que debe confiar en eso, en un sistema de varios inquilinos , los otros inquilinos no pueden raspar en la memoria, o el proveedor de alojamiento no extrae una copia. Si tiene un dato realmente crítico, ninguna nube pública es la respuesta.