È richiesto HTTPS quando non ci sono dati sensibili nel sito

Question

È richiesto HTTPS quando non ci sono dati sensibili nel sito

#1 da (4 voti)
#2 da (3 voti)

1

Attualmente sto costruendo un sito di e-commerce B2B per un cliente che utilizza WordPress. Vendiamo macchinari industriali compresi nell'intervallo superiore di $ 100k - $ 400k. Il mio cliente vorrebbe avere il proprio modulo di finanziamento online dove i clienti / le imprese inseriscono i dati del conto bancario, così come i numeri di previdenza sociale. Vuole che questo modulo venga inviato via email al nostro gruppo di finanziamento per l'elaborazione. Invece di inviare questo modulo per posta elettronica, posso conservare i dati sul mio server SSL e crittografarlo in qualche modo, quindi fornire un collegamento di accesso per il nostro gruppo di finanziamento da utilizzare, inserire una chiave, quindi visualizzare le informazioni sensibili? Stiamo cercando di eliminare la necessità di inviare per fax o posta elettronica un'applicazione.

Abbiamo 2 server, un server interno MS SQL 2008 e un server MySQL / Nginx su cui è installato WordPress.

Dopo aver letto molti post, ciò che il mio cliente vuole fare è un enorme rischio per gli utenti e la nostra azienda. Non sono uno specialista della sicurezza, sto solo cercando un riscontro su ciò che dovrei / potrei fare.

legal financial tls

posta RandomJay 22.07.2015 - 02:33

fonte

2 risposte

Leggi altre domande sui tag legal financial tls

Come pulire SSD potenzialmente infetto? Come analizzare gli URL di e-mail di spam per rilevare gli exploit?

score 4 · Answer 1

Sembra che tu abbia un sacco di informazioni sensibili sul tuo sito web!

Anche se il tuo sito non contiene informazioni sensibili, l'implementazione di HTTPS è una decisione valida. Le connessioni HTTP non sicure sono vulnerabili a un attacco man-in-the-middle ( MITM ), che consente a un utente malintenzionato di impersonare il tuo sito con facilità. I clienti non hanno modo di essere sicuri che siano effettivamente collegati al tuo server, piuttosto che il di qualcuno che finge di essere tuo.

HTTPS offre l'autenticazione consentendo ai client di verificare l'identità del tuo server e la riservatezza impedendo a terzi di spiare il tuo traffico.

score 3 · Answer 2

Prima di tutto, HTTPS protegge i dati solo mentre sono in transito, quindi non protegge i tuoi dati in seguito. Pertanto, sarà necessario implementare la sicurezza per questi dati a riposo.

Progettare un sistema completamente sicuro è un compito veramente, davvero difficile e valutare quale sia un rischio accettabile e ciò che non lo è è tutt'altro che banale. Vi suggerisco di chiedere consiglio a un consulente di sicurezza professionale (le società di revisione hanno accesso a tale profilo).

Detto questo, ecco alcuni suggerimenti su come potresti voler andare dopo questo compito:

Innanzitutto, è necessario stimare il valore dei dati che si desidera proteggere. Questo è MOLTO importante perché ti consente di decidere quali misure di sicurezza sono necessarie e quali sono eccessivi (la sicurezza ha sempre un costo). Non dimenticare che questo valore dovrebbe includere il costo nel caso in cui i dati vengano persi e tali dati vengano sottratti / divulgati.
Assicurati di avere BISOGNO di tutti i dati che stai raccogliendo. Il modo più semplice per proteggere i dati sensibili non è quello di richiederli o memorizzarli in modo da ridurre al minimo i rischi (ei costi) riducendo la quantità di dati che stai memorizzando.
Controlla se avrai bisogno di dati sensibili sul server frontale di nuovo. In caso contrario, un'implementazione piuttosto semplice, ma efficace, consiste nel creare un percorso sicuro e unidirezionale per i dati: implementare un server back-end che accetterà i dati con una semplice API (tramite una connessione sicura) ma non avrà qualsiasi altra cosa esposta. Un altro modo per proteggere questi dati è crittografarlo (ad esempio, utilizzando PGP) con una chiave pubblica e mantenere la chiave privata fuori dal server. In questo modo, i dati sensibili non possono essere recuperati facilmente fintanto che la chiave privata non viene compromessa.
In tutti i casi, sarà meglio servirsi di un server separato per l'archiviazione dei dati sensibili e l'esecuzione del controllo degli accessi. Questo server non dovrebbe essere accessibile dall'esterno, solo dal tuo sistema front-end. Se un utente malintenzionato si impadronisce del tuo server frontale, sarà comunque necessario accedere a questo sistema per raggiungere i tuoi dati sensibili. L'API utilizzata per contattare questo server sicuro dovrebbe essere attentamente progettata, però.
Anche i dati a riposo dovrebbero essere crittografati. Idealmente, utilizzerai un HSM per memorizzare le chiavi e non utilizzare la crittografia trasparente (né nella memoria né nel database ).
Una volta terminato il progetto, è necessario verificarlo.