Protezione della chiave di decodifica sul server

Sei certamente sulla buona strada, ma è possibile che tu lo stia rendendo un po 'più complicato del necessario. Hai identificato correttamente che un sistema di crittografia simmetrica crea il problema significativo della chiave di decodifica presente sul sistema.

Se si sceglie di generare chiavi pubbliche / private per ogni parte di dati, potrebbe rendere la vita inutilmente difficile oltre a "gestire" le chiavi private in una posizione non ottimale. Se sei sposato con i dati che vengono crittografati con la chiave pubblica dell'utente, è possibile modificare quanto segue per memorizzare due copie della chiave simmetrica crittografata. In questo caso sarebbe meglio consentire all'utente di generare un custode e fornirti la chiave pubblica piuttosto che generare la coppia di chiavi per l'utente. (In altre parole, non vuoi veramente gestire la chiave privata)

1. In una posizione attendibile, generare una coppia di chiavi pubblica / privata per il server / l'applicazione
2. Copia la chiave pubblica (solo) nel percorso dell'applicazione tra l'utente e il database
3. Ogni volta che arrivano dati sensibili, genera una chiave segreta casuale e utilizza questa chiave per crittografare i dati sensibili utilizzando un algoritmo simmetrico (come AES)
4. Cripta la chiave segreta casuale con la chiave pubblica dell'applicazione

Ci sono un certo numero di cose che sono ideali per questo approccio:

• Sistemi di backend e utenti con esigenze aziendali e i diritti appropriati possono utilizzare la chiave privata in un sistema separato per recuperare i dati sensibili
• Poiché solo la chiave privata può essere utilizzata per decrittografare le chiavi segrete casuali non esiste una superficie di attacco utile a parte la forza bruta cruda per un utente malintenzionato che compromette l'applicazione
• L'efficacia di un attacco di forza bruta è drasticamente ridotta poiché un attacco riuscito contro una qualsiasi delle chiavi segrete casuali fornisce accesso solo a quel singolo pezzo di dati; tutti gli altri tasti sono diversi. Ciò rende molto poco attraente un attacco di forza bruta contro le chiavi simmetriche.
• Attualmente una forza bruta contro una coppia di chiavi pubblica / privata di 4096 bit è considerata intrattabile

Quindi, di nuovo, hai l'idea giusta, ma potresti voler semplificare il tuo approccio un po '!

Innanzitutto @taz ti fa bene a pensare fuori dagli schemi per mantenere i dati dei tuoi clienti più sicuri, tuttavia ho alcune preoccupazioni e possibili suggerimenti per aumentare la sicurezza dell'archiviazione dei dati ...

Alla tua domanda sulla sicurezza del sistema finalizzato, vedo il potenziale di un compromesso nascosto tra server che porta a comprenderne i dati al momento del login e vedo che il potenziale dell'account admin è un singolo punto di errore / compromesso . Mentre il sistema proposto sarebbe più sicuro di quello che ho visto implementato da altri amministratori di server, coprirò alcune altre opzioni che potresti voler prendere ispirazione per rendere la sicurezza ancora più stretta.

opzioni abilitate per Web / app

1. Considera openpgpjs per la decrittografia del client nel browser

2. Considera openpgp-php per la crittografia lato server

3. Considera di estrarre il codice sorgente da ProtonMail o KeyBase per come questi team hanno implementato la crittografia / decrittografia tra server e client.

La soluzione alternativa possibile è la crittografia sshfs + GnuPG ... è un po 'di setup per client e server ma manterrà i client & ammette le chiavi private sul loro file system correlato e completamente fuori dal file system del server.

imposta sshfs sul server cloud per eseguire il chroot dei client

1. Installa sshfs sul server

   apt-get install sshfs
   

2. Crea un nuovo gruppo per i client da riconoscere

   group add sshfsmount
   

3. Aggiungi utenti a nuovo gruppo e utenti al server

   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. Modifica la configurazione ssh del server

   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. Verifica le impostazioni e ricarica la configurazione del server ssh

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

Note Subsystem sftp internal-sftp may cause ssh logins to fail so attempt to login via a normal ssh account after restarting the server before logging out of current ssh terminal that made the above changes.

7. Aggiungi le chiavi ssh pubbliche dei client ad autorizzate

   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
   

Impostazione per bob client sshfs

1. Installa sshfs

   apt-get install sshfs
   

2. Modifica le impostazioni del client ssh per utilizzare i tasti

   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
   

Note host.domain should point to the cloud server's domain name or IP address

3. Crea directory e monta il server cloud sul file system locale dei client

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

Note to unmount use the following

    fusermount -u /mnt/glow_cloud

4. Utilizza la crittografia a chiave pubblica GnuPG per l'utente bob per crittografare un file con l'output salvato sul server cloud

   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
   

Note for text files the user bob may use a vim plugin/script to edit the above encrypted file on the remote server.

Note for non-text files you may wish to checkout the latest build of Paranoid_Pipes for further inspiration and utilize similar steps as above to make encrypting/decrypting between server and clients automatic. However, this last suggestion is experimental and results in clients keeping decryption key's passphrase in their local memory... so with above security mainly rests upon your clients' shoulders because the admin can use similar mounting schemes for keeping their own private keys off the server too.

Ci sono alcune noiose realtà riguardo la memorizzazione di qualsiasi cosa su un cloud pubblico. L'unico modo sicuro per decrittografare / crittografare qualsiasi cosa è sul client locale stesso e tutte le questioni relative alla gestione locale delle chiavi private: furto di telefono, furto di chiavi, ecc. Utilizzare il cloud pubblico significa che devi fidarti di questo, su un sistema multi-tenant , gli altri inquilini non riescono a racimolare in memoria, o il provider di hosting non preleva una copia. Se si dispone di una parte di dati veramente critica, nessuna risposta è fornita da public cloud.