quali campi devo crittografare in un database contenente informazioni utente? [chiuso]

2

Quindi in un database potrebbero esistere molti campi utente. Normalmente quando installo un database esco dalle raccomandazioni degli esperti di sicurezza su quali campi criptare, ma sono curioso di sapere qual è il set di campi più standard da crittografare? Per quanto ho visto, di solito sono la password (hash), la carta di credito (AES) e il numero di telefono (AES), ma l'indirizzo, il nome e le altre parti sono in chiaro.

Dato che molte persone qui probabilmente crittografano anche altri campi, sono curioso di sapere quali campi crittografate nei database degli utenti?

    
posta Robert Mennell 25.09.2015 - 21:07
fonte

1 risposta

5

La crittografia è solo uno strumento; viene applicato principalmente per tre motivi:

  1. Per ottenere una certa riservatezza. Ciò ha senso in contesti in cui i dati memorizzati (contenuti del database) potrebbero essere esposti a terze parti malevoli, ma alcuni elementi specifici (la chiave di crittografia) potrebbero essere tenuti nascosti alle stesse terze parti malevole.

  2. Per ottenere la conformità ad alcune normative. Ad esempio, quando si ha a che fare con informazioni sulla carta di credito, uno o più deve seguire le prescrizioni di PCI-DSS , inclusa l'applicazione della crittografia per alcune porzioni di dati.

  3. Per dare una sensazione di sicurezza spargendo un po 'di cripto dappertutto. Questo motivo, ovviamente, non è buono ; tuttavia, è molto comune nella pratica.

Per la prima ragione, ciò ha senso solo relativamente a un modello di attacco in cui gli aggressori non possono leggere la chiave di crittografia. L'applicazione che accede al database deve, per definizione, essere in grado di leggere il contenuto dei dati, quindi deve conoscere la chiave di decodifica. Si consideri, ad esempio, una crittografia completa di database completo (ciò che Microsoft e Oracle chiamano TDE ): questo crittografa tutto il contenuto del database; ma l'applicazione che accede al database deve conoscere la chiave, decodificare i dati al volo e vedere i contenuti del testo libero. Se il modello di attacco riguarda gli attaccanti che rubano i nastri di backup o recuperano i dischi rigidi scartati, allora TDE è la strada da percorrere: un tale aggressore vedrà solo una grande pila di dati crittografati, con una chiave che non ha. D'altra parte, se il modello di attacco riguarda Iniezioni SQL , TDE non offre alcuna sicurezza aggiuntiva dal momento che l'SQL iniettato viene interpretato nel contesto della normale applicazione, sui dati decrittografati.

Per la seconda ragione, crittografare ciò che è necessario per ottenere la conformità e farla finita. Questa è la cosa buona della conformità: non devi pensare , solo per seguire le regole.

Per la terza ragione, devi invocare le divinità crittografiche per ogni campo che auditor / boss / clienti sentono essere "importante". Di solito, le persone si sentono nervose per ciò che considerano la loro identità, quindi nomi, indirizzi e-mail, indirizzi, numeri di telefono ... dovrebbero essere tutti criptati. Poiché questo è solo il teatro della sicurezza, la maggior parte delle volte è possibile ottenere lo stesso tipo di effetto psicologico con una "codifica" che non richiede necessariamente la crittografia (ad esempio Base64 ).

    
risposta data 25.09.2015 - 21:35
fonte

Leggi altre domande sui tag