Dovremmo preoccuparci della crittografia a livello di cella per un'applicazione Web ASP.NET/SQL Server?

Question

Dovremmo preoccuparci della crittografia a livello di cella per un'applicazione Web ASP.NET/SQL Server?

#1 da (6 voti)

4

( Cross-posting questo qui su consiglio di un utente su StackOverflow ...)

Hai una domanda di sicurezza filosofica per tutti. Sto tracciando una progettazione di applicazioni Web ASP.NET in cui i dati sensibili per diverse organizzazioni / client verranno archiviati in un database SQL Server. L'autenticazione dell'utente utilizzerà l'autenticazione basata su form ASP.NET.

Crittografare l'intero database usando Transparent Database Encryption (TDE) è un gioco da ragazzi. Ma sono curioso di sapere se dovremmo preoccuparci della crittografia a livello di cella (usando qualcosa come il Toolkit per la sicurezza delle etichette di SQL Server disponibile in codeplex.com: etichetta SQL Server Security Toolkit ).

Se dovessimo eseguire la crittografia a livello di cella, potremmo associare ciascun utente di un'organizzazione / client a un singolo account utente SQL che abbia la capacità di leggere / scrivere dati per la loro organizzazione. Quindi, nel caso in cui un account utente SQL fosse compromesso, limiterebbe l'accesso ai dati solo a quella singola organizzazione.

Ma supponiamo di aver creato un singolo account utente / password SQL che è destinato esclusivamente all'applicazione web per comunicare in modo sicuro con il database (non sarà consentito alcun accesso diretto al database per scopi di reporting). Possiamo impostarlo con una password sufficientemente lunga generata casualmente, con quelle credenziali memorizzate crittografate nel file web.config.

A questo punto, abbiamo sufficientemente garantito l'accesso ai dati sensibili nel database (supponendo che l'applicazione limiti ciò che viene visualizzato, ovviamente)?

In altre parole, supponiamo di avere più account utente SQL con password incredibilmente lunghe crittografate nel file web.config. Se uno di quegli account utente SQL fosse stato compromesso, ciò significherebbe un difetto di sicurezza che probabilmente significherebbe compromettere tutti gli account utente SQL. Quindi, nessun valore aggiunto di sicurezza esiste realmente.

(La ragione più convincente che posso pensare di fare la crittografia a livello di cella da parte degli utenti SQL specifici del cliente è quella di evitare che un buco di sicurezza nell'applicazione web effettiva possa visualizzare i dati di un altro client.)

Spero che la domanda abbia un senso. Sii interessato a sentire i pensieri degli altri su questo! Grazie in anticipo.

asp.net sql-server

posta wolfpigeon 30.12.2013 - 21:58

fonte

1 risposta

Leggi altre domande sui tag asp.net sql-server

Chiavi pubbliche senza i certificati La CA revocherà un certificato ai siti Web di phishing

score 6 · Answer 1

Penso che la risposta alla tua domanda ruoti su una vista percettiva leggermente diversa - che è, dove avviene la decifrazione?

Tecnologie come la funzione TDE a livello di database. In termini pratici, ciò significa spesso che un DBA - o qualcuno che ha compromesso i privilegi appropriati - può accedere ai dati e alla struttura decrittografati.

La crittografia a livello di cella, d'altra parte, può essere più comunemente implementata a livello di applicazione. Ciò significa che il DBA non avrà mai la possibilità di accedere a qualcosa di diverso da un blob crittografato; la chiave per decriptarlo è (dovrebbe essere) sequestrata a livello di applicazione. Questo è prezioso perché, in entrambi i mondi di sicurezza e conformità, il doppio controllo è un potente alleato. I tecnici dell'applicazione possono decrittografare i dati, ma solo se ne catturano molto dal database, che di solito non è sottile. Gli amministratori del database possono acquisire molti dati, in genere in modo subdolo, ma se non riescono a decrittografarli, il controllo viene mantenuto.

Quando stai pensando a cosa ha senso, devi pensare alle minacce che ti riguardano. Se sei solo preoccupato di dischi freddi e nastri di backup, TDE copre la tua preoccupazione. Se sei preoccupato per i vettori di attacco in una coppia di applicazioni + database funzionante dal vivo, TDE ha meno senso e potresti voler prendere in considerazione più controlli a grana fine che separano la capacità di decrittografia dall'archivio dati.

Se hai più applicazioni in co-localizzazione con chiavi di crittografia diverse che consentono l'accesso a blob crittografati specifici dell'applicazione su un back-end condiviso, allora sì, questo potrebbe offrirti più sicurezza ... ma ha pozzi su cui devi pensare . Un utente malintenzionato che acquisisce un certo controllo sul server delle applicazioni è lo scenario peggiore di serie. Se ottengono l'accesso al server dell'app, può raccogliere le chiavi di decrittografia da più app e annullare la separazione? Non è possibile separare le app con le chiavi di crittografia se sono tutte su disco, in memoria e in esecuzione sullo stesso server delle app, almeno non come controllo di sicurezza. Ecco dove vorresti altri controlli, come ad esempio i server di app separati, per proteggere i tuoi dati.

Tieni presente che ho usato parole donnole come in termini pratici , può essere più comunemente , dovrebbe essere e non sottile / sottilmente . Sono consapevole che potrei non rispondere alla tua domanda diretta date le tecnologie che stai elencando; Sto riformulando la domanda in una più teorica inclinazione in modo che tu possa provare e mappare le tue opzioni sui concetti e tornare indietro da lì.

Buona fortuna!