Crittografa dati nel codice o stored procedure?

1

Sto lavorando su un'app Web in cui i dati sono piuttosto sensibili e devono essere crittografati prima di essere archiviati nel database. Ora ci sono due modi attraverso i quali posso ottenere questo:

  1. Crittografa dati nel codice
  2. Codifica i dati nelle stored procedure (utilizzando le chiavi simmetriche)

Ora non so quale approccio sarà migliore per quanto riguarda sicurezza e prestazioni.

    
posta Rida Iftikhar 15.06.2017 - 08:23
fonte

2 risposte

2

Il problema non è tanto il luogo in cui si eseguono operazioni di crittografia / decrittografia, ma come si gestiscono le chiavi, i dati crittografati e come si gestisce la crittografia stessa.

La preoccupazione immediata che ho a che fare con l'uso di stored procedure è che la chiave sarà più facilmente accessibile dal livello del database. Questo presenta una vulnerabilità in quanto il tuo database ora si presenta come un componente che se viene compromesso da solo, allora anche i tuoi dati sensibili sono quasi sicuramente compromessi.

Quanto sopra è una VERA vulnerabilità che ti impedirà di raggiungere la conformità agli standard attraverso una serie di standard diversi (ad esempio HIPAA, PCI, ecc.)!

In definitiva, il punto più debole in uno schema di crittografia simmetrica è la debolezza della gestione delle chiavi. Alcune delle soluzioni più sicure (e costose) utilizzano qualcosa chiamato HSM che memorizzerà in modo sicuro le chiavi e le fornirà come necessario per applicazioni in modo sicuro.

Altri modi per risolvere questo problema sono la crittografia del canale tra l'applicazione e i server di database e la richiesta ai server delle applicazioni di fornire la chiave per le stored procedure per la crittografia / decrittografia. Questa è una buona soluzione perché un utente malintenzionato che ha compromesso il database non avrebbe avuto accesso alla chiave, o se l'utente malintenzionato ha compromesso il server delle applicazioni, quindi non avrebbe avuto accesso al database (in teoria). Ciò impedisce un singolo punto di errore.

    
risposta data 16.06.2017 - 13:21
fonte
4

In generale, sconsiglio di utilizzare stored procedure. Ho lavorato in un'azienda che aveva molta logica nelle stored procedure e ha reso davvero difficile ragionare e testare. Abbiamo finito col migrare dalle procedure archiviate nel tempo. Sono specifici del database, quindi se vuoi allontanarti da SQL Server, dovrai gestire i proc.

Il codice è molto più facile da mantenere e testare e sono disponibili librerie di crittografia forti e mature. Per quanto riguarda le prestazioni, il codice è più scalabile orizzontalmente rispetto a SQL Server.

Io voto il codice.

    
risposta data 15.06.2017 - 11:36
fonte

Leggi altre domande sui tag