Sistema multiutente con database crittografato

Question

Sistema multiutente con database crittografato

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (0 voti)

5

Attualmente sto sviluppando una soluzione ospitata in ASP.NET usando MVC3 e Entity Framework. Questo prodotto verrà quindi reso disponibile a un numero di client come soluzione ospitata.

Poiché i dati memorizzati da ciascun cliente saranno fondamentali per la loro attività, prevediamo che molti di loro insisteranno sul fatto che i dati siano archiviati in un formato crittografato nel database. Pertanto stiamo progettando il sistema con questo in mente.

Esistono procedure consigliate per farlo? Come si fa a criptare i dati dei clienti in modo tale che anche noi con accesso root al database non possiamo accedere ai loro dati?

Credo che non ci sia un supporto integrato in EF per i dati crittografati, è vero? E se sì, come farebbe a criptare / decodificare i dati?

sql-server encryption mvc entity-framework

posta Gavin Coates 10.11.2011 - 14:24

fonte

4 risposte

Leggi altre domande sui tag sql-server encryption mvc entity-framework

Cercando di imparare come usare i servizi WCF in un'app WPF, usando MVVM ___ terminologia qstnhdr ___: perdita di memoria ______ qstntxt ___

Quando sento il termine perdita di memoria con ciò intendo un bug in un programma che non causa nessun problema tranne che non libera risorse di memoria e, se continua a farlo, può consumare molta memoria, danneggiare le prestazioni del sistema e, nel peggiore dei casi, mandare in crash il programma (o un altro programma, se il sistema operativo decide di scegliere di ucciderlo). / p>

Ma ora, in questa sezione di commenti di questa domanda, gli upvotes mi hanno fatto pensare se questo è l'intero significato del termine. In passato l'ho sempre visto usato in quel senso.

link

Quindi, chiameresti qualcosa una semplice perdita di memoria che blocca un programma da qualche altro effetto collaterale o causerebbe un dead-block non liberando un lock?

Aggiornamento - Nota: sfortunatamente alcuni admin hanno cancellato la sezione dei commenti, quindi non posso più fare riferimento a quella discussione: /

Fondamentalmente ho detto che una perdita di memoria è innocua tranne che mangia memoria (e di conseguenza a lungo termine in questo senso può essere dannoso, bloccando l'app / sistema). Hanno detto che non è vero, con C ++ RAII può causare seri problemi. - Sì, se non si elimina un oggetto con un codice importante nel distruttore che può causare problemi, ma nel mio vocabolario è un bug grave e non una perdita di memoria.

______ azszpr108885 ___

La perdita di memoria quintessenziale sarebbe esattamente ciò che hai descritto, l'incapacità di liberare un po 'di memoria che il processo aveva allocato. Le conseguenze sarebbero normalmente che il programma crescesse gradualmente di dimensioni mentre è in esecuzione, con possibili effetti secondari a causa di ciò. Le allocazioni di memoria successive potrebbero non riuscire o il sistema potrebbe comportarsi in modo anomalo a causa delle risorse sprecate.

Tuttavia, un problema può essere descritto con precisione come una perdita di memoria, a condizione che in effetti la perdita di memoria. Può anche fare altre cose che sono potenzialmente più serie. Ad esempio, se non si riesce a chiudere un flusso I / O standard, si verificherà una perdita di memoria perché la memoria associata al flusso verrà interrotta. Tuttavia, può anche eseguire il processo fuori dai descrittori di file o forse causare un successivo flusso aperto in errore a causa di un limite sul numero di flussi I / O standard.

______ azszpr108919 ___

Dipende. Certamente il programma potrebbe essersi arrestato a causa di una perdita di memoria. Ma non chiamerei tutte le perdite di memoria di crash. Una perdita di memoria ha una definizione molto chiara.

Un arresto anomalo dell'applicazione potrebbe essere causato da molte cose diverse.

Eccezione non gestita
Perdita di memoria
Perdita di risorse
Deadlock
Altro (bug nel codice)

Al momento del crash si dovrebbe prendere un crash / memoria dump e usare qualcosa come Windbg per analizzare lo stato del codice al momento del crash per determinare se si trattava di una perdita di memoria, deadlock, bug, ecc.

Una perdita di memoria semplicemente non libera la memoria dopo averla finita. Ciò può causare un arresto anomalo se i limiti delle risorse sono soddisfatti come indicato.

Una perdita di risorse non libera la risorsa dopo averla finita. Un esempio potrebbe essere aprire una connessione al database e non chiuderla dopo aver terminato.

I deadlock sono diversi dalle perdite, perché le perdite possono non essere rilevate e potrebbero essere benigne se le risorse di sistema non vengono consumate. I deadlock sono una condizione che non si accumula nel tempo.

______ azszpr108888 ___

Un significato correlato di "perdita di memoria" si applica alle lingue che usano la garbage collection. Lì, la memoria supposto deve essere trapelata, ma se non lo fai, è lo stesso problema.

______ azszpr108926 ___

Si verificano perdite di memoria Se non si riesce a eliminare la memoria allocata dinamicamente. puntamento la perdita di memoria è uno degli aspetti più lunghi e noiosi della programmazione in ambienti non gestiti.

Un semplice esempio di perdita di memoria può essere seguito.

%pre%

______ azszpr108884 ___

link

%bl0ck_qu0te%

Le perdite di memoria possono causare errori casuali poiché alla memoria possono essere assegnati valori imprevisti.

%bl0ck_qu0te%

I blocchi morti possono essere causati dalla memoria a cui sono stati assegnati valori imprevisti.

Ulteriori letture su questo argomento:

link
link

___

score 2 · Answer 1

Consiglierei di prendere qualcosa come il driver jTDS e aggiungere la crittografia ad esso. Dovresti avere un metodo per mappare i nomi dei client sulle chiavi di crittografia, ma non dovrebbe essere difficile. In questo modo, non devi fare nulla nella tua applicazione stessa - tutta la crittografia e la decrittografia sono gestite dal driver. In questo modo, inoltre, è possibile utilizzare strumenti di gestione di database di terze parti per esaminare il database, assicurandosi che si colleghino al database utilizzando il proprio driver. È un compito non banale, ma penso che offra una bella soluzione pulita. Puoi eseguire lo sviluppo utilizzando un driver standard, in modo che tu possa ancora esaminare i dati una volta nel database e quindi passare a utilizzare il driver di crittografia in produzione.

score 1 · Answer 2

.Net ha librerie di crittografia

Fornisci a ciascun client la propria chiave di crittografia, che è memorizzata in tali server. Il client crittografa i dati quindi li invia per l'inserimento. Il DB restituisce Dati crittografati che il Cliente deve decrittografare.

Il problema è ... Non puoi aiutare il cliente se perde la chiave, NESSUN CAN.

Ma quello sembra essere il business case (da quello che sto leggendo) quindi ...

(Puoi anche crittografare nuovamente i dati dopo che il client ti ha inviato i dati, quindi c'è essenzialmente un blocco "2 Key" sui dati.)

score 1 · Answer 3

Per quanto riguarda la prevenzione dell'accesso, gli schemi di database potrebbero essere utili. Gli schemi possono essere creati e l'accesso può essere concesso a specifici utenti di database, che escludono account a livello di dominio come SA e così via. Quando viene creato il database, gli script di creazione potrebbero essere dinamici per consentirne.

Example:  Database1.ClientX.Table1
          Database2.ClientY.Table1

Se a un utente del database non è stato concesso l'accesso allo schema ClientX, non è stato possibile visualizzare alcun database, indipendentemente dal livello di privilegio del sistema DBMS. Ovviamente un utente aveva un alto privilegio poteva darsi accesso a quello schema, ma presumo che ci sia un po 'di fiducia data ai pochi DBA che hanno effettivamente queste autorizzazioni.

Per quanto riguarda la crittografia, probabilmente una sorta di strato middleware sicuro sarebbe la migliore. Ogni livello del middle ware potrebbe avere una chiave privata diversa, in modo che non possano decrittografare gli altri dati. In questo modo non dovresti memorizzare le chiavi su ciascun client, ma sul livello intermedio, magari in un file di configurazione o qualcosa del genere.

Le chiavi per crittografare i dati sarebbero state probabilmente crittografate, quindi se qualcuno avesse avuto accesso al server, le avrebbe potute semplicemente afferrare e collegare fino al livello intermedio e vedere tutto. Chi ha accesso a quelle chiavi, qualcuno di cui ci si fida.

Client X Data- MiddleWare Layer X Encrypt/Decrypt- Database X
Client Y Data- MiddleWare Layer Y Encrypt/Decrypt - Database Y

Un'istanza DB separata sarebbe la più sicura.

score 0 · Answer 4

In un senso puramente tecnico, crittografare il database in modo tale che gli amministratori non possono leggere i dati è piuttosto complicato - qualcosa deve decrittografare qualcosa per mostrarlo agli utenti, quindi la chiave tende a vivere da qualche parte nel sistema in modo che qualcuno con l'accesso di root potrebbe sempre decifrare i dati.

Per quanto riguarda la crittografia dei dati, se è possibile attivare una licenza Sql Enterprise, il server Sql potrebbe farlo per te. Ma questo in realtà non ti dà molto a meno che il tuo server di database non si trovi su una rete non fidata in primo luogo. Vorrei concentrare i miei sforzi sulla progettazione dell'app in modo che ogni cliente avesse un database separato oltre a costruire una solida pista di controllo per scoraggiare comportamenti malvagi.