Quali alternative sicure devo memorizzare indirizzi postali / numeri di telefono in MySQL?

Naviga le tue risposte
2

Sto lavorando su un sito che ha un corso online sulla salute e la sicurezza in cui si acquista il numero x di periodici da utilizzare. 1 seriale per candidato. Non memorizziamo i dati della carta di credito e i pagamenti vengono elaborati in modo sicuro da una terza parte. Al momento raccogliamo / conserviamo l'indirizzo di qualsiasi iscrizione in un database mysql.

Anche se è ancora piuttosto un nuovo sito con un budget abbastanza limitato, io, in qualità di sviluppatore, sto cercando di rendere il sito il più sicuro possibile. Vorrei rimuovere l'indirizzo / i numeri di telefono dal database, quindi se c'è stata un'intrusione c'è sempre meno per l'autore del reato di tentare di rubare. Non abbiamo bisogno dell'indirizzo / tel memorizzato nel db per far funzionare una delle funzioni e poiché si tratta di un prodotto digitale non è necessario inviarlo all'indirizzo postale. Ma vogliamo mantenere le informazioni e archiviarle localmente se / quando necessario per il marketing.

È abbastanza facile rimuovere l'indirizzo / tel dal DB e aggiornare la procedura di pagamento, quindi questi dettagli vengono inviati via email al mio cliente, che potrebbe quindi copiare e incollare tutti gli indirizzi non appena arrivano in un foglio di calcolo locale ed eliminare l'e-mail. Ma come ho letto, è un tabù inviare password di testo in chiaro ecc. Via email.

Quindi, sarebbe accettabile inviare per e-mail "indirizzi / numeri di telefono" dopo il pagamento in formato testo che il mio cliente potrebbe prontamente trasferire su un foglio di calcolo locale? Questo sarebbe considerato più sicuro rispetto alla memorizzazione di tali informazioni in un database (che potenzialmente potrebbe sempre essere compromesso)? O c'è qualche altro metodo consigliato in questa situazione?

    
posta Robert Sheppard 09.03.2017 - 17:24
fonte

6 risposte

3

Anche se penso che sia bello che tu stia cercando di proteggere la tua applicazione, mi chiedo: stai cercando di proteggere i tuoi utenti da una violazione del database, e sei preoccupato per l'indirizzo postale e il numero di telefono. Questi due elementi sono davvero le cose più importanti da proteggere? Di solito, se si ha un nome e un cognome, è possibile ottenere questi due punti dati da una rubrica telefonica pubblica. Questo non mi sembra un dato molto prezioso, a meno che il tuo servizio non stia cercando di mantenere gli utenti anonimi (ma dovresti anche rimuovere il nome utente e il nome utente dal database e identificarlo semplicemente con un numero casuale).

Quello che mi piace è l'idea di non archiviare dati che non ti servono affatto. André ha ragione nel sottolineare che gli indirizzi di posta elettronica a qualcuno in chiaro non è molto sicuro, ma mi piace l'idea di spostare i dati alla persona che ne ha effettivamente bisogno, e quindi rimuoverla dalla tua posizione. Ciò significa che non puoi essere ritenuto responsabile in caso di violazione dei dati, perché semplicemente non hai i dati.

Tre idee

1) Quello che potresti fare per risolvere il tuo problema è creare un secondo database su un host diverso che fondamentalmente ha appena memorizzato le informazioni personali dei tuoi clienti, e creare un microservizio attorno ad esso per archiviare e interrogare gli indirizzi in base a un ID utente .

Ciò isolerebbe il database degli indirizzi dal resto dell'applicazione e aggiungerà un altro livello di protezione, ma non risolverà il problema, perché probabilmente un hacker che può accedere al tuo database sarà probabilmente in grado di capire come interrogare il servizio di indirizzo remoto.

2) È possibile ottenere una quantità quasi equivalente di sicurezza aggiuntiva crittografando gli indirizzi e i numeri di telefono nel database. Se un utente malintenzionato ruba semplicemente il database, non sarà in grado di fare nulla con i campi crittografati, ma ovviamente, potrebbe anche rubare la chiave di crittografia. Non c'è modo di aggirare questo se si desidera memorizzare i dati e tenerlo accessibile.

3) La terza soluzione utilizza la crittografia a chiave pubblica per proteggere gli indirizzi e i numeri di telefono: crittografate gli indirizzi e i numeri di telefono sul server utilizzando una chiave pubblica. Non si mantiene la chiave privata sul server. Solo il proprietario della chiave privata può quindi decrittografare i dati crittografati e, poiché la chiave privata non è disponibile sul server, significa che un utente malintenzionato non può accedere a dati già crittografati (ma potrebbe em> installa una routine per raccogliere gli indirizzi e i numeri di telefono dei nuovi clienti prima che vengano crittografati). Lo svantaggio di questa soluzione è che l'applicazione non ha accesso ai dati crittografati.

    
risposta data 09.03.2017 - 19:09
fonte
0

Sono d'accordo con i commenti di André e Pascal: il database è probabilmente più sicuro della workstation di qualcuno. Tuttavia, se si desidera conservare i dati nell'organizzazione ma non averli sul computer del database, ecco un'altra opzione:

  • Crea una pagina web HTTPS, protetta da una buona password su un buon server.
  • Periodicamente, chiedi al tuo cliente di accedere a quella pagina web.
  • La sua visita alla pagina farà sì che tutte le PII nel database vengano scritte su un file scaricato nella sua macchina tramite il browser.
  • Dopo il download, le PII vengono cancellate dal database.
  • Questo può essere copiato tramite arricciatura usando bash-crontab (iOS / Linux) o Task Scheduler-PowerShell (Windows), in modo che non debba ricordarsi di farlo.
  • I dati vengono crittografati in movimento tramite TLS-HTTPS e quindi sono fuori mano.
risposta data 10.03.2017 - 09:11
fonte
0

Ora ci sono una serie di prodotti commerciali (relativamente convenienti) in grado di gestire la tua situazione esatta.

Alcune soluzioni hanno crittografia a livello di colonna accoppiata a controllo di accesso a livello di colonna e gestione dei privilegi. Ciò significa che per ogni colonna del tuo DB puoi definire chi può accedervi, chi può criptare / decifrare / da quale tipo di applicazione / ea che ora. Questo potrebbe essere molto più economico di dover sviluppare un sito web solo per questo problema (risorse umane, tempi e costi di manutenzione).

    
risposta data 29.03.2017 - 07:17
fonte
0

Il mio consiglio è di iniziare con le due domande fondamentali (funzionalità):

  • per quali dati verranno utilizzati?
  • di cosa vuoi proteggere i dati?

La risposta alla seconda domanda è semplice: vuoi proteggerli dal furto se qualcuno può accedere al tuo sistema. Ciò significa che idealmente, dovrebbe essere impossibile ottenerli dal sistema che li ha memorizzati.

Se ho capito bene, gli indirizzi / numeri di telefono non sono usati dall'applicazione ma per marketing . Se ciò significa che verranno utilizzati solo occasionalmente da un numero limitato di utenti, penso che la terza idea di Pascal sia la migliore qui:

  • memorizzi gli indirizzi e i numeri di telefono in una memoria ausiliaria (server, database o almeno una tabella diversa) - poiché sono dati brevi, puoi crittografarli direttamente con una chiave pubblica
  • la chiave privata è accessibile solo all'applicazione di marketing. Qui mentre elabora le informazioni personali dovrai assicurarti quella parte, ma siccome non hai detto molto, non posso nemmeno dire di più - e IMHO sarebbe una domanda diversa

In questo modo l'applicazione sotto la tua responsabilità è perfettamente sicura, e non imponi ulteriori vincoli sulla parte di marketing poiché essi usano i dati personali che devono comunque proteggere.

    
risposta data 29.03.2017 - 10:32
fonte
0

Sono d'accordo con gli altri qui che mentre i tuoi obiettivi sono lodevoli, questa informazione ha un valore limitato. Sono anche d'accordo sul fatto che il server è probabilmente un luogo più sicuro dove archiviare le informazioni rispetto al PC desktop di qualcuno - ma in realtà non sappiamo nulla sull'infrastruttura del cliente.

Data la bassa sensibilità delle informazioni e il modello di utilizzo, vorrei dare all'account di servizio nessun accesso in lettura e scrittura alle tabelle che contengono questi dati, ma invece a una stored procedure per applicare le scritture - quindi fornire un'alternativa Interfaccia utente in cui il client può fornire la password per un account MySQL con accesso in lettura e scrittura a queste tabelle. cioè buona separazione privilegiata vecchio stile.

I dati sono ancora esposti nei file di dati sottostanti (e nei backup) ma evitano la complessità del codice e dei processi nella gestione delle chiavi asimmetriche.

    
risposta data 29.03.2017 - 12:30
fonte
-2

Una cosa che potresti fare sarebbe criptare i record con la password dell'utente. Sono d'accordo che questa non è davvero una grande opzione a causa del modo in cui le password utente sono in genere brevi, ma hey, è giusto?

    
risposta data 09.03.2017 - 19:11
fonte

Leggi altre domande sui tag

Qualsiasi problema noto con ColdFusion 9 è un controllo numerico? Come fai a sapere se il tuo PC è in reverse shell?