Best practice in application design / SQL authentication

4

Attualmente sono coinvolto nell'implementazione / progettazione di un'applicazione esistente per un cliente su larga scala. L'applicazione ha un modello simile, ad es. vCenter Server in cui un certo numero di componenti memorizzano le informazioni e estraggono le informazioni ei flussi di lavoro formano un database centrale. L'ambiente è gestito da un'applicazione console che utilizza un servizio Windows per connettersi al database.

A causa di considerazioni sulla sicurezza, l'autenticazione SQL non è un'opzione, ma l'applicazione supporta l'autenticazione di Windows. Tuttavia, quando si utilizza l'autenticazione di Windows, vengono passate le credenziali dell'utente che utilizza l'applicazione della console di gestione sul database invece di utilizzare l'account di servizio con cui viene eseguito il servizio.

Ciò si traduce nella situazione in cui i ruoli di sicurezza così come sono definiti all'interno dell'applicazione (utenti / gruppi AD mappati a determinate autorizzazioni) richiede che questi oggetti AD abbiano anche un accesso a SQL Server e determinate autorizzazioni sul database (db-writer per alcune tabelle, a seconda delle autorizzazioni specifiche nell'app).

Oltre all'amministrazione aggiuntiva, questo crea anche un IMO del rischio per la sicurezza perché l'intero punto dei ruoli di sicurezza dell'applicazione in questa specifica applicazione è di consentire agli utenti l'accesso solo a una parte di una determinata tabella (ad esempio un sottoinsieme degli oggetti) . Ma dal momento che ora hanno un accesso SQL e db_writer su quell'intera tabella, potrebbero ignorare l'app e con una connessione diretta al database potrebbero leggere / modificare i record che non sarebbero autorizzati a visualizzare / manipolare attraverso l'applicazione.

Questo rischio potrebbe quindi (in parte) essere mitigato limitando l'accesso al database a livello di rete, o eventualmente utilizzando i trigger per controllare il nome host e il nome del programma di chiamata, ma per quanto ne so non è completamente sicuro.

L'unico vantaggio che mi viene presentato è che ora è disponibile un audit trail completo nel server SQL su chi ha fatto esattamente cosa. Ma questo è già implementato nell'applicazione e quindi mi sembra un po 'discutibile.

Ho cercato freneticamente qualsiasi informazione su questo e quale sarebbe la migliore pratica. Posso trovare solo materiale basato su ASP / Web ma nulla riguardo questo tipo di applicazione.

È davvero il modo migliore per passare dall'autenticazione al server SQL o l'app deve gestire l'autorizzazione e inviare tutte le richieste del database utilizzando l'account del servizio?

P.S .: Questa è la mia prima domanda su stackexchange, se ho postato sul sito secondario sbagliato o trovi la mia domanda inappropriata, per favore fammelo sapere.

    
posta mvdwrd 17.09.2013 - 22:17
fonte

2 risposte

3

In generale, se stai usando questo modello, non dovresti usare alcun metodo di accesso eccetto stored proc e i diritti dovrebbero essere sul procs stesso e mai direttamente su una tabella o vista. Ciò significa che nessun SQL dinamico di alcun tipo (incluso in proc). In questo modo gli utenti che accedono direttamente al database possono ancora fare solo le cose che sono autorizzati a fare dall'applicazione. Questo è un luogo in cui l'utilizzo di un ORM sarebbe un disastro. Non ci saranno accessi SQL Server. Gli utenti dovrebbero invece trovarsi in gruppi di finestre a cui vengono assegnati i diritti in base a ciò che sono autorizzati a fare. Questi diritti potrebbero consistere in diritti di lettura per una tabella ma nessun inserimento / aggiornamento o eliminazione non eseguiti attraverso l'esecuzione di un processo memorizzato. Avrebbero ottenuto i diritti di exec solo per i procs che il loro gruppo di utenti dovrebbe essere in grado di eseguire nell'applicazione.

    
risposta data 17.09.2013 - 22:57
fonte
1

La gestione dell'accesso ai database tramite un account di servizio è più semplice. Separa la consapevolezza dei diritti degli utenti dal database e questo ha i soliti vantaggi di tale segregazione, come la riduzione dei punti di gestione e di insuccesso. Meno di quelli che si hanno, più è facile riunire le procedure di amministrazione e diagnosticare i problemi.

A seconda dell'applicazione, può anche consentire un migliore pool di connessioni e quindi migliori prestazioni.

    
risposta data 18.09.2013 - 04:36
fonte

Leggi altre domande sui tag