Mi dispiace deluderti, ma il tuo modello di sicurezza non funziona nella realtà. Lascia che ti spieghi utilizzando un flusso di lavoro di esempio di un utente che modifica il suo profilo.
- L'utente accede, sfoglia la sua pagina del profilo e inserisce i suoi dati per essere salvato.
- Quando salvi, hai bisogno della tua chiave simmetrica per AES. Questo può essere
o una password globale, in uso per tutti i dati privati sul tuo server
o una password di proprietà dell'utente che contiene la sua password ad un certo punto (dato che tutti gli altri dati sono pubblicamente disponibili / archiviati)
2a: password globale
L'utilizzo di una password globale, indipendentemente da dove viene memorizzata, sarà sempre facile compromettersi. Supponiamo che il server richieda la password globale da un secondo server (che può essere comunque compromesso) ogni volta che un utente (amministratore o meno) accede ad esso. Questo può essere facilmente sniffato in quanto un utente malintenzionato conosce il tuo endpoint interno. Se lo si codifica, può essere facilmente letto.
2b: password di proprietà dell'utente
Questo deve contenere informazioni così segrete che nessuno con accesso al server può leggerlo, come la password (come dovrebbe essere memorizzata solo all'interno di un hash). In questo modo l'utente sarebbe in grado di leggere & salva i suoi dati privati ma tu come amministratore, avendo le stesse opportunità di un utente malintenzionato, non riuscirebbe a leggerli o modificarli.
E adesso?
È tanto semplice quanto deludente: un utente malintenzionato ha sempre le stesse possibilità di te (l'amministratore), quindi non c'è modo di mantenere i dati perfettamente salvati da nessuno dei due. Quello che dovrebbe essere fatto invece come una questione di best-practice è il concetto di bisogno di sapere - solo salvare i dati che davvero è necessario che il servizio sia sempre disponibile come la sua email, il nome e la data di nascita. Tutti gli altri dati possono essere salvati e crittografati da un token di proprietà dell'utente e utilizzati in runtime (solo!) Per decrittografare i dati per offrirli all'utente come il suo indirizzo per un processo di acquisto. Ciò ridurrà di molto le tue possibilità in termini di analisi dei dati, ma la sicurezza dei dati e l'analisi approfondita non si apprezzano comunque.