Progettazione DAL sicura mediante stored procedure

Question

Progettazione DAL sicura mediante stored procedure

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

3

Normalmente evito gli sProcs il più possibile. Non mi piace che il linguaggio sia TSQL o PL / SQL; sembrano arcaici contro Java / Dot-Net che uso. Vado per loro quando una routine ha bisogno di recuperare un sacco di dati, crunch e generare un piccolo insieme di output. Sedersi all'interno del DB rende il processo di recupero molto veloce, senza successo di rete. Ma questo è tutto.

Recentemente mi sono imbattuto in un progetto DAL in cui tutte le operazioni CURD erano state implementate in Stored Procedures. In realtà uno sProc gigante per essere precisi. Ecco lo scheletro:

PROCEDURE myGenericProc(int QueryNo, varchar genericParam1, ..., varchar genericParamN)
BEGIN
    SWITCH queryNo
    CASE 1
        SELECT * FROM table1 INNER JOIN table 2 ON ...

    CASE 2
        DELETE FROM table 3 WHERE ...
    ...

    CASE n
        UPDATE table4 SET a=b WHERE ...
END

La logica del progettista dietro questo è: se faccio queste cose nel codice, quindi la connessione al database deve avere pieni diritti su tutte le tabelle. Le credenziali di connessione sono generalmente nella stringa di connessione, che si trova sul server delle applicazioni. Se il server delle applicazioni viene compromesso, inevitabilmente anche l'intero DB viene compromesso.

In alternativa, disponi di tutte le query nello sProc, quindi concedi a sProc i diritti completi. Chiama solo che sProc. In questo modo, anche se il server delle applicazioni è compromesso, solo l'interfaccia sProc può essere attaccata. Nessuno può fare DROP users_master .

Mentre sono d'accordo con il principio, odio l'implementazione. Sfortunatamente, alcuni clienti paranoici di sicurezza (banche) vogliono che facciamo esattamente questo. Inoltre, i DBA odiano i privilegi di accesso di ottimizzazione su 200+ sProcs, vogliono articoli il più possibile non verificabili.

Domanda:

Esiste un'altra implementazione che fornisce lo stesso livello di sicurezza, ma è più più pulita ?

security database-design stored-procedures

posta inquisitive 30.03.2015 - 09:03

fonte

3 risposte

0

Le moderne librerie di mappatura degli oggetti relazionali e persino le librerie di livello inferiore che consentono di eseguire SQL sul database, dispongono di protezioni per impedire attacchi di SQL injection. Utilizzare le stored procedure perché tutte le altre soluzioni non sono sicure è sia miope che falso. Se è necessario il codice SQL rigido, è possibile utilizzare query con parametri, che proteggono dagli attacchi SQL injection.

Se la ragione per cui usi le stored procedure è quella di centralizzare la logica aziendale, hai un motivo legittimo per utilizzarle, ma sarebbe meglio essere un motivo valido per rendere più difficile il test del tuo sistema. Lanciare un gruppo di unit test alle classi in Java o C # è piuttosto semplice. L'unità di test delle procedure memorizzate è più difficile, ma se si utilizzano diverse tecnologie che richiedono lo stesso database e le stesse regole aziendali, le procedure memorizzate sono utili.

Ho una relazione di amore-odio con loro. Da una parte, odio dover mappare ogni singolo parametro puzzolente e mi piace come un ORM può solo generare automaticamente i comandi INSERT, UPDATE e DELETE. Inoltre, la maggior parte degli ORM consente di chiamare stored procedure, in modo da ottenere la capacità di query dinamica dell'ORM con l'interfaccia avanzata fornita dalle stored procedure.

In realtà, il motivo per cui utilizzi le stored procedure non dovrebbe essere "perché è più sicuro", poiché ciò probabilmente deriva dal non sapere come utilizzare gli altri strumenti disponibili.

risposta data 30.03.2015 - 14:51

fonte

-1

Cerco di evitare stored proc se possibile. Ma quando devo sicurezza, il mio obiettivo è un approccio compromesso. Io uso stored proc per i comandi di aggiornamento (INSERT, UPDATE, DELETE) e l'ORM per tutto il resto.

Inoltre, ogni processo memorizzato esegue una singola operazione su una singola tabella. Il codice dell'applicazione coordina tutte le chiamate e gestisce le transazioni.

Il problema più grande che ho riscontrato con i proc memorizzati è che lo sviluppo diventa più difficile. Stored proc's offusca il lavoro:

Seguire il flusso del programma è più difficile, specialmente se devono essere usati due IDE diversi (uno per i proc memorizzati, uno per il codice)
Tenere traccia degli errori è più difficile a causa dell'interruttore di contesto mentale
Quando memorizzato proc chiama altri proc memorizzati, i problemi diventano esagerati

risposta data 30.03.2015 - 15:37

fonte

Leggi altre domande sui tag security database-design stored-procedures

Che cosa significa "Stateful" in Stateful ViewModel in MVVM Come utilizzare la propria API REST nel front-end Web?

score 2 · Accepted Answer

Gli Sproc sono molto utili per l'implementazione di un livello di accesso sicuro ai dati: si scrivono sproc per leggere e scrivere dati e si consente al client di accedere solo agli sproc, senza accesso alle tabelle o alle viste sottostanti.

Questo fornisce al DB un'API che i client utilizzano, più o meno allo stesso modo di qualsiasi classe implementata nel codice della tua logica aziendale, ma molto più sicura. Evita il tipo di exploit di cui continuiamo a leggere nelle notizie in cui alcuni hacker hanno ottenuto l'accesso alla password di ogni utente - se l'unico modo per accedere a una password era tramite uno sproc, l'hacker che ha ottenuto l'accesso al DB poteva recuperare solo 1 password alla volta, l'esecuzione di select * from users non è possibile una volta che ha ignorato i server che si trovano di fronte.

Inoltre, è possibile suddividere il DB back-end in schemi in modo che alcuni sproc non possano nemmeno accedere ad altre parti del DB.

In breve, è un bel modo di implementare un'API controllata per il DB piuttosto che permettere a chiunque di eseguire qualsiasi query che possa sembrare contraria. Ovviamente è possibile migliorare le prestazioni utilizzando sprocs per l'accesso ai dati che richiede query complesse ed è possibile implementare nuovamente lo schema di back-end senza che nessun client ne realizzi la modifica.

Ho lavorato in un sistema altamente sicuro alcune volte (finanziario) che richiedeva la logica aziendale di accesso al sito Web front-end in un servizio di livello intermedio, il servizio era protetto in modo che solo il server web potesse accedervi, a sua volta chiamati sprocs sul db che erano a loro volta protetti in modo tale che solo i servizi di livello intermedio che necessitavano dell'accesso a loro fossero autorizzati. Potrebbe sembrare troppo complesso, ma una volta eseguito il primo esempio di ciascuna parte, è stato molto facile capire dove inserire altre funzionalità. Significava anche che gli specialisti potessero scrivere le parti rilevanti dell'applicazione (es. Web, servizi o sql) e che si sarebbero uniti più tardi nell'integrazione.

Non mi piacerebbe scrivere un singolo sproc che si rivolge a tutte le chiamate API - questo è un pantalone totale. I DBA dovrebbero essere soddisfatti di diversi sproc, in grado di rivedere e controllare solo le modifiche, quindi non controllare l'intera faccenda per 1 cambiamento pindico.