Come mitigare il danno da un dump del database?

Hai corretto crittografare i dati a livello di applicazione e archiviarli nel database ha limitazioni sulla ricerca, sebbene l'intelligente architettura delle applicazioni possa aggirare un po 'di ciò consentendo una decrittazione temporanea dei dati mentre l'applicazione è in esecuzione, come ad esempio in memoria: dipende dalla dimensione del set di dati, dai requisiti di sicurezza e dai livelli di conformità necessari.

Penso che l'opzione shard, come probabilmente indichi, non offra molta protezione, e possa complicare il sistema con poco beneficio.

Che ne dici delle opzioni complete di crittografia del database? Questi sono gestiti dal motore del database e sono trasparenti per l'applicazione: link

La crittografia è una buona idea. Ma è una domanda, come l'attaccante sarà in grado di scaricare il DB. Se l'applicazione che crittografa / decodifica non avrebbe alcun effetto. La crittografia completa del DB, come hai detto correttamente, è solo protezione contro gli attacchi interni.

Per quanto riguarda i dati delle carte, ci sono dei requisiti esatti da seguire se si desidera memorizzare, i cosiddetti dati del titolare della carta. Se si desidera passare la certificazione, è molto probabile che venga richiesto di utilizzare il modulo di sicurezza Harware in dipendenza dal tipo di dati che si desidera elaborare e memorizzare. Se è possibile evitarlo, raccomanderei di non memorizzarli affatto e di non rientrare nello standard PCI DSS.

Per quanto ne so non esiste alcun valido schema di protezione contro il dump di DB mentre sarebbe ancora facilmente possibile gestirlo, effettuare ricerche e così via.

È meglio pensare a come può accadere che il DB venga scaricato e proteggere il DB (intero ambiente) contro di esso. E questo richiederebbe molte più righe di scrittura;)

Supponiamo che tu sviluppi la tua soluzione globalmente distribuita, sharded, salted, hash, crittografata e indicizzata. I tuoi dati vengono archiviati come una serie di hash SHA256 token in tabelle valore-chiave cifrate a righe distribuite su tutti i data center di tutto il mondo, tutte con firewall separati l'una dall'altra e tutte dotate di crittografia a disco intero.

• Nessuno può accedere a un singolo server e semplicemente scaricare i dati.
• Nessuno può solo tirare un disco rigido e andare via con i dati.
• Anche se lo facessero, otterrebbero dati arbitrari ('1568de12b5c51ac272fcd9112b5c9': '2b472568deac272fcd9112b5c51880f0ac443d1c').

Che cosa proponi esattamente di fare con ciò che hai archiviato?

Qualsiasi meccanismo sviluppato per cercare, recuperare e decrittografare i dati per il tuo caso aziendale diventerà il vettore con il quale il tuo sistema sarà compromesso. Probabilmente sarà il risultato di ingegneria sociale o malware introdotti tramite ingegneria sociale. Qualcuno con accesso divulga le proprie credenziali in un messaggio di phishing, o alcuni rappresentanti del call center non riescono ad autenticare un chiamante prima di soddisfare la richiesta.

Tutti i controlli di sicurezza possono essere annullati dal fatto che ora esiste un algoritmo per estrarre i dati dal tuo pagliaio.

Quindi, come mitigare? Non complicare eccessivamente la tua architettura. Alla fine non ti salverà e tutto ciò che ti resterà sarà un incubo inutilizzabile.

Implementa solo controlli sensati e potenzia i tuoi link più deboli.

Come hai detto, le password possono essere sottoposte a hash. A volte i dati devono essere ligati che raramente (se mai) devono essere letti, qui la crittografia asimmetrica usando una chiave pubblica (con la chiave privata corrispondente tenuta offline) può essere una soluzione - ma in genere i dati di questo tipo hanno un asset molto basso valore. Tutto il resto deve essere leggibile.

Ciò significa che l'applicazione ha bisogno dei mezzi per decodificare i dati. Pertanto, se non si dispone di backdoor nel database, il percorso verso i dati (crittografati) fornisce anche l'accesso alle chiavi (o al testo in chiaro). Potrebbe impressionare i tuoi azionisti nel sapere che crittografate tutti i vostri dati con AES a 256 bit, ma non è vantaggioso se il testo in chiaro è ancora recuperabile tramite un attacco SQL injection. La crittografia del database ha un overhead delle prestazioni di almeno il 20% (in alcuni casi molto, molto più elevato). La maggior parte delle persone ha un budget limitato per la sicurezza e suggerisco che è meglio spendere tempo e denaro per proteggere la superficie di attacco.

Si noti che la crittografia dei dati del database (o livello dell'applicazione) (che presumo tu stia parlando) è molto diversa dalla crittografia dei dispositivi e dei blocchi, che protegge da accessi indesiderati al tuo supporto fisico. Questo ha un overhead delle prestazioni molto più basso e costante. Molti dbms forniscono la crittografia dei file (spesso descritta come crittografia del database completa ) e la considererei essenziale se non si controlla l'infrastruttura di archiviazione; il filesystem è quindi potenzialmente parte della superficie di attacco.