Salvataggio delle informazioni personali (nome, indirizzo, telefono, e-mail) nel database MySQL

4

Creerò un'app Web per consentire alle persone di registrarsi e pagare un abbonamento. Le informazioni sulla transazione verranno elaborate tramite Authorize.NET ma salviamo il resto delle informazioni (Nome, Tipo di iscrizione, Importo, Email, Indirizzo, Telefono) sulla transazione in MySQL in modo che possa essere elaborata tramite un'interfaccia di amministrazione.

Sto pensando di utilizzare AES_Encrypt per salvare le informazioni in un server mysql sicuro e quindi utilizzare AES_Decrypt per inviare le informazioni attraverso un'interfaccia di amministrazione per l'elaborazione.

L'idea è che il server web in cui si svolgerà il regalo (sicuro) sarà diverso dal server mysql in cui verranno archiviate le informazioni e l'interfaccia di amministrazione che accederà alle informazioni sarà anche su un altro server.

La mia domanda è - questo sembra un approccio sano? C'è qualcosa di meglio che dovrei fare per crittografare queste informazioni nel caso in cui fosse compromessa?

    
posta rmlumley 15.12.2015 - 21:53
fonte

2 risposte

4

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.

  1. L'utente accede, sfoglia la sua pagina del profilo e inserisce i suoi dati per essere salvato.
  2. 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.

    
risposta data 18.12.2015 - 00:03
fonte
-1

Se memorizzi informazioni sensibili sui clienti, assicurati di mantenere il possibile rischio di perdere molte informazioni sensibili in una volta piuttosto basso. Generalmente è una buona idea osservare le regole della normalizzazione del database, ad esempio nel caso in cui creerei un database con un ID e un nome come chiave primaria e aggiungerei gli ID delle tabelle posta, indirizzo e telefono e anche il tipo di iscrizione come chiave esterna.

Esempio:

TBL_Customerdata Nome ID FK_ID_Mail FK_ID_Address FK_ID_Phone FK_ID_Membership

TBL_Membership FK_ID_Membership Tipo Importo

TBL_Phone Numero FK_ID_Phone

TBL_Address FK_ID_Address Street House Housepart FK_ID_PoSt Paese

TBL_Post FK_ID_PoSt Codice Postale Città

TBL_Mail FK_ID_Mail Indirizzo FK_ID_Provider

TBL_Provider

Provider FK_ID_Provider

Se usi lo Schema di cui sopra, impedirebbe a un Attaccante di accedere a molti Datapace in una sola volta. AES sembra ok per la crittografia.

Spero che questo aiuti.

    
risposta data 17.12.2015 - 23:31
fonte

Leggi altre domande sui tag