La sicurezza dei dati dovrebbe essere garantita dal lato del database?

Question

Stiamo creando un nuovo framework e un nuovo modo di fare affari per le nostre nuove app interne.La nostra progettazione attuale prevede che tutta la logica di sicurezza debba essere gestita dal nostro database e che tutte le informazioni (e intendo tutte) entreranno e usciranno dal database tramite procedure memorizzate.

La teoria è che il livello di accesso ai dati richiede informazioni da una procedura memorizzata e trasmette l'autenticazione al database.Il database determina il ruolo/le autorizzazioni dell'utente e decide se eseguire o meno l'attività (che si tratti di recuperare dati o effettuare un aggiornamento).

Immagino che questo significhi meno transazioni nel database.Una chiamata al database.Se la sicurezza fosse nel nostro livello di accesso ai dati, ciò richiederebbe 1 chiamata al database per determinare se l'utente dispone delle autorizzazioni adeguate, quindi 1 chiamata al database separata per eseguire l'azione.

Io, per esempio, trovo che SQL Management Studio sia completamente privo di IDE.La mia preoccupazione principale è che finiremo per dover mantenere una quantità sgradevole di logica aziendale nelle nostre procedure memorizzate per ottenere guadagni di prestazioni minimi.

In questo momento stiamo utilizzando LINQ per il nostro ORM.Sembra leggero e veloce, ma soprattutto è davvero facile svilupparsi rapidamente.

Il costo di manutenzione vale il miglioramento delle prestazioni?Ci stiamo forse illudendo pensando che ci sarà un notevole miglioramento delle prestazioni?O stiamo solo creando un incubo per noi stessi?

Il nostro ambiente:

• App aziendali interne e non mission critical
• C#/ASP.NET 3.5
• Finestre 2003
• MS SQL Server 2005
• 35 App web di medie dimensioni con circa 500 utenti

Answer 1

Non farlo.Recentemente abbiamo avuto un MOLTO BRUTTO esperienza quando il "guru del database" ha deciso di andare in un'altra azienda.Il mantenimento di tutta la logica nelle procedure è semplicemente orribile!!

Sì, avrai qualche miglioramento delle prestazioni, ma non ne vale la pena.In effetti, le prestazioni non sono nemmeno un grosso problema nelle applicazioni interne.Investi più soldi in buoni server.Ti ripagherà.

Answer 2

Sfortunatamente non esiste una “unica risposta vera”.La scelta che devi fare dipende da molteplici fattori, come:

• La familiarità del team con le soluzioni fornite (ovvero, se la maggioranza di loro è a suo agio nello scrivere SQL, può essere nel database, tuttavia se la maggioranza di loro è più a suo agio con C#, dovrebbe essere nel codice)
• Il "potere politico" di ciascun partito
• eccetera

Non c'è alcun vantaggio decisivo in nessuna direzione (come hai detto, i guadagni in termini di prestazioni sono minimi), l'unica cosa da tenere a mente è il principio DRY (Don't Repeat Yourself):non reimplementare la funzionalità due volte (nel codice e nel DB), perché mantenerli sincronizzati sarà un incubo.Scegli una soluzione e attieniti ad essa.

Answer 3

Potresti farlo, ma è un enorme dolore da sviluppare e mantenere.Prendilo da qualcuno che partecipa a un progetto in cui quasi tutta la logica aziendale è codificata in procedure memorizzate.

Per motivi di sicurezza, ASP.NET integra la gestione degli utenti e dei ruoli, quindi potresti risparmiare viaggi nel database, ma e allora?In cambio diventa molto più fastidioso gestire ed eseguire il debug degli errori di sistema e di convalida perché devono emergere dal database.

I test unitari sono molto più difficili poiché i framework disponibili per gli sproc di test unitari sono molto meno sviluppati.

Una corretta progettazione oop e basata sul dominio è quasi fuori dalla finestra.

E il miglioramento delle prestazioni sarà minimo, se non nullo.Ne abbiamo parlato Qui.

Consiglierei, se vuoi salvare la tua sanità mentale come sviluppatore, di combattere con le unghie e con i denti per mantenere il database solo come livello di persistenza

Answer 4

A PARER MIO:

Livello di servizio dell'applicazione -> logica e convalida dell'applicazione
Livello dati dell'applicazione -> logica e sicurezza dei dati
Database -> coerenza dei dati

Prima o poi verrai morso dall'approccio sproc, l'ho imparato nel modo più duro.
I processi sono ottimi per le operazioni one shot che richiedono molte prestazioni, ma la parte CRUD è il lavoro sui livelli di dati

Answer 5

Le procedure memorizzate sono generalmente un vantaggio per la sicurezza.Semplificare la relazione tra l'applicazione e il database riduce il numero di punti in cui è possibile che si verifichino errori;gli errori nel codice che interfaccia la logica aziendale con il database tendono a essere problemi di sicurezza.Pertanto, il tuo DBA non ha torto nel bloccare le cose nelle procedure memorizzate.

Un altro vantaggio derivante dal bloccare l'applicazione sulle procedure memorizzate è che la connessione al database dello stack dell'app può avere i privilegi bloccati su chiamate di procedure memorizzate specifiche e nient'altro.

Un vantaggio di avere un DBA coinvolto nella logica di sicurezza della tua applicazione è che le diverse funzionalità e ruoli dell'app possono essere partizionati nel database fino alle visualizzazioni, in modo che, anche se sono necessarie SQL dinamiche e istruzioni di selezione generiche, il danno derivante da una vulnerabilità SQL può essere vincolato.

Il rovescio della medaglia è, ovviamente, la perdita di flessibilità.Ovviamente sarà più veloce sviluppare un ORM rispetto a una negoziazione costante con un DBA sui parametri della procedura memorizzata.E, man mano che la pressione su tali procedure memorizzate aumenta, è sempre più probabile che le procedure stesse ricorrano all'SQL dinamico, che sarà altrettanto vulnerabile agli attacchi quanto l'SQL composto dall'app.

C'è una felice via di mezzo qui e dovresti provare a trovarla.Recentemente ho lavorato su progetti che sono stati salvati da problemi di SQL injection piuttosto terribili perché un DBA aveva attentamente configurato il database, le sue connessioni e le sue procedure memorizzate per il "privilegio minimo", in modo che ogni utente del database avesse accesso solo a ciò che desiderava. avevo bisogno di sapere.

Ovviamente, mentre scrivi il codice SQL nella logica dell'app, assicurati di utilizzare costantemente istruzioni preparate con parametri, di disinfettare il tuo input, di prestare attenzione all'input internazionalizzato (ci sono molti, molti modi per dire singolo -quote su HTTP) e che sei consapevole di come si comporta il tuo database quando gli input sono troppo grandi per la larghezza delle colonne.

Answer 6

Dipende tutto dal tuo caso, probabilmente è meglio non seguire il percorso SP e fare tutto in modo DDD (crea un modello di dominio nel codice e usalo).

Tuttavia, se disponi di un database che non viene utilizzato solo dalla tua applicazione ma da molte altre, probabilmente dovresti prendere in considerazione i servizi web.In ogni modo, il database dovrebbe essere accessibile solo tramite un livello che applica le regole aziendali, altrimenti ti ritroverai con dati "sporchi" e disinfettare i tuoi dati in seguito è una seccatura molto più grande che scrivere alcune regole aziendali in anticipo.Un buon database dovrebbe avere vincoli di controllo e indici impostati, quindi avrà alcune regole aziendali, che ti piaccia o no.

E se hai a che fare con milioni e miliardi di record sarai felice di avere un bravo DB-ragazzo che risolverà il problema per te.

Answer 7

La mia opinione è che l'applicazione stessa dovrebbe gestire l'autenticazione e l'autorizzazione.Dal lato del database dovresti gestire la crittografia dei dati solo se necessario.

Answer 8

In passato ho creato applicazioni basate su procedure memorizzate.Nel tuo caso forse c'è un modo per mantenere l'autenticazione a livello di database e avere la logica aziendale in C#.Utilizza le visualizzazioni per limitare i dati (vedi solo le righe per cui hai l'autorizzazione).Queste visualizzazioni possono essere utilizzate in LINQ con la stessa facilità delle tabelle.Puoi impostare gli aggiornamenti in modo che avvengano con le procedure memorizzate.

Ciò consente linq, logica aziendale in C# e un livello di autenticazione comune nel database che controlla l'accesso ai dati.