Crittografia a riposo e/o AES_ENCRYPT

Crittografia a riposo

La crittografia a riposo è costituita dai dati nel database quando non vengono utilizzati/accesi o aggiornati. La crittografia in movimento è cose come TLS dove i dati (dal database ) viene trasportato da server a server a browser, server, browser, ecc. TLS è perfettamente valido nella maggior parte delle situazioni se viene gestito con attenzione e affrontato con un atteggiamento che è necessario fare di più del minimo indispensabile per renderlo effettivamente realistico.

Un tipico esempio sono le persone che inseriscono un certificato TLS da LetsEncrypt sul proprio dominio e pensano che improvvisamente tutte le loro cose siano al sicuro; ma non crittografano le loro sessioni oi loro cookie lasciando così un enorme potenziale buco nelle loro difese.

Non utilizzare il sistema di crittografia integrato in MySQL.

Non posso sottolineare abbastanza questo; il sistema di crittografia integrato in MySQL non è adatto per un'effettiva protezione dei dati sicura.

Si prega di leggere la mia risposta a una domanda molto simile qui per quanto riguarda i dettagli (Non voglio semplicemente copiare/incollare ).

Ok, allora, perché insisti.... qui:

Da quello che ho letto nella mia ricerca su questo argomento, il link fornito da Magnus a defuse/php -crittografia è uno dei modi migliori per impedire a MySQL di compromettere i tuoi dati, non permettendo mai al programma/server MySQL di vedere il valore in chiaro dei tuoi dati.

-- Risposta pubblicata il 7 maggio 2017.

Inoltre Risposta di Bill Karwin alla stessa domanda fornisce alcuni preziosi spunti aggiuntivi:

-- Risposta pubblicata il 7 maggio 2017.

Punto di chiusura:

La sicurezza è complessa. Se vuoi farlo correttamente e avere fiducia nelle tue bucce di cipolla protettive, allora devi fare molte cose (vedi i punti elenco sotto); ma la prima cosa che devi fare è:

• Definisci contro chi ti stai proteggendo

Sul serio. Hai bisogno di strategie diverse contro qualcuno che vuole rubare i tuoi nomi e indirizzi in chiaro rispetto a qualcuno che vuole prendere il controllo del tuo server contro qualcuno che vuole semplicemente cestinare i dati solo perché. È un mito che puoi proteggere da tutti in ogni momento, per concetto questo è impossibile*; quindi è necessario definire gli aggressori più probabili e quindi elaborare il modo migliore per mitigare i loro progressi.

In particolare per MySQL, alcuni chiari consigli:

• Mantieni SQL e PHP sullo stesso server. Non accedere in remoto ai dati MySQL.

• Escludi l'accesso esterno all'SQL (quindi è localhost solo)

• Offusca i nomi delle tabelle e delle colonne; se qualcuno accede ai tuoi dati e hai HDTBJ^BTUETHNUYT sotto la colonna username quindi sanno che questo garble è probabilmente un nome utente, quindi hanno un ottimo inizio nel tentativo di violare la tua crittografia.

• IMPORTANTE :Blocca davvero l'accesso al tuo tavolo; configurare molti utenti MySQL, ciascuno con i privilegi minimi necessari per fare ciò di cui hanno bisogno; vuoi che un utente legga la tabella (solo ) e leggere solo alcune tabelle; utenti di scrivere su determinate tabelle ma non hanno accesso ad altre tabelle. È la separazione delle preoccupazioni in modo che se un qualsiasi utente su MySQL sia compromesso; non hai perso automaticamente tutti i dati lì dentro.

• Utilizzare i servizi di crittografia PHP. Archivia le chiavi di crittografia in un luogo completamente separato; ad esempio, hai un altro server che usi esclusivamente per il backup a cui puoi accedere solo per prendere le chiavi di crittografia, quindi se il tuo server PHP/MySQL è compromesso hai spazio per tagliare e bloccare il server delle chiavi in ​​modo che tu possa limitare il danno. Se anche il server delle chiavi dispone di backup, in realtà non sei troppo gravemente compromesso (dipende dalla situazione ).

• Imposta molti osservatori e informatori e-mail per dirti esattamente quando determinati processi sono in esecuzione e quali utenti del server (non persone ma programmi) stanno facendo cosa. Quindi puoi capire perché un processo inaspettato inizia a essere eseguito alle 5 del mattino per provare a misurare le dimensioni delle tabelle MySQL. WTF?

• C'è molto potenziale per avere "sniffati" i tuoi dati MySQL AES_ENCRYPT anche se non sono a riposo nel DB, ma se il sito Web viene compromesso (o peggio, il codice PHP non è sicuro), gli attacchi temporali possono funzionare contenuto dei dati in base al tempo delle ricerche di query e dei pacchetti di dati restituiti.

• La sicurezza è un buco nero; ad un certo punto o nell'altro penserai "Maledizione, ho fatto abbastanza". Nessuno ha mai una sicurezza totale, alcune organizzazioni molto dedicate ne hanno abbastanza sicurezza. Devi capire fino a che punto sei disposto a camminare prima di aver percorso la distanza.

* Perché impossibile? Perché per proteggere i tuoi dati da tutte le minacce, in ogni momento, dovrebbero essere illeggibili, inutilizzabili, come un hash. Un hash è protetto da tutti, sempre. Ma un hash non può mai essere annullato.