È mai buona norma utilizzare un account di database distinto per ciascun utente di un'applicazione?

Le applicazioni a cui sono abituato sono basate su server e utilizzano un account di database per molti utenti, con il codice dell'applicazione che controlla ciò che l'utente può fare o un singolo utente.

Esistono applicazioni aziendali complesse di successo in cui ogni persona ha bisogno del proprio account di database e si fa affidamento sul server di database per applicare le regole di policy su ciò che ogni utente dovrebbe essere autorizzato e non autorizzato a fare?

Sto pensando ad applicazioni in cui più persone contribuiscono alle informazioni in un database e possono accedere alle informazioni memorizzate da altri, ad esempio colleghi di un'organizzazione che devono accedere ai record dei clienti.

C'è anche un nome per questo tipo di installazione?

Se è necessario un controllo molto rigoroso applicato a livello di dati. Ad esempio un controllo approfondito. Il controllo non è molto utile se più utenti condividono lo stesso account. Se hai alcuni utenti che hanno bisogno di accedere direttamente al database dei dati.

Se la sicurezza è così stretta, in genere non è nemmeno possibile esporre direttamente il database. Hai un servizio e il cliente deve ottenere i dati dal servizio.

In un'applicazione Web il database (ad esempio la porta 1433) in genere non è esposto direttamente, quindi si ha un livello di sicurezza. Anche se l'applicazione Web accede direttamente al database, gli utenti non hanno ancora accesso diretto al database.

Se il login e la password si trovano nell'applicazione client, può essere violato. Se un dominio è possibile utilizzare la sicurezza integrata.

Nel database è possibile avere controlli abbastanza accurati. Ma il controllo a livello di riga richiede un po 'di lavoro. Un database non è un buon strumento per le regole aziendali. Le regole aziendali e la sicurezza dettagliata sono in genere applicate a livello di applicazione.

Puoi avere una modalità mista in cui ci sono alcune procedure memorizzate utilizzate dagli amministratori e vuoi monitorare quale amministratore. E puoi dare accesso in sola lettura agli utenti che generano direttamente il rapporto.

La sfida qui è che l'accesso al database è gestito da un'astrazione. Invece di connettersi come se stessi, assumono essenzialmente l'identità di un ruolo applicativo generalizzato. Non solo perdi la visibilità della singola connessione, ma perdi anche la granularità della definizione di diversi tipi di accesso per tutti i tuoi singoli utenti.

Il motivo principale per l'utilizzo di questo approccio è la semplicità. Molte applicazioni sono progettate in modo tale che l'utente dell'applicazione non sia a conoscenza del database. Non ne hanno davvero bisogno, soprattutto se l'applicazione gestisce la propria sicurezza interna. La maggior parte dei singoli utenti non si collegherà mai direttamente al database, quindi non è necessario definire un accesso esplicito per loro.

L'unica volta in cui dovresti considerare di lasciare che il database gestisca la tua sicurezza è se hai utenti che si collegheranno direttamente al tuo database. Ciò significa che stanno girando intorno alla tua applicazione e non può più applicare la sicurezza da sola. Il vantaggio qui è che puoi essere più granulare nel definire la tua sicurezza. Lo svantaggio è il sovraccarico maggiore per la gestione degli utenti e delle loro autorizzazioni.

Se si sente la necessità di questo tipo di accesso, si desidera utilizzare il controllo degli accessi in base al ruolo . È necessario definire i ruoli in base al tipo di autorizzazioni necessarie all'interno del database e quindi raggruppare i singoli utenti in tali ruoli. Ciò offre un controllo e un controllo migliori sul modello di sicurezza, che può sfuggire rapidamente al controllo durante la gestione dell'accesso diretto.

C'è un approccio ibrido a questo. Se si desidera che la propria sicurezza sia parzialmente gestita dal database, è possibile creare più utenti dell'applicazione, ognuno definito dal loro ruolo e concedere esplicitamente l'accesso a quegli utenti in base al ruolo che ricoprono. Ciò significa che puoi sfruttare il motore di database per alcuni dei tuoi modelli di sicurezza, ma devi comunque avere un po 'di gestione all'interno dell'applicazione. Aumenta la complessità del modello utente dell'applicazione, ma offre una granularità più fine sui diversi accessi in uso.

Dovresti iniziare a far rispettare la sicurezza al livello più granulare il più presto possibile. I ruoli aiutano in questo senso: dare alle persone l'accesso a più tavoli contemporaneamente non è un incubo.

Il singolo account per tutti è un'ottima fonte di domande qui e altrove: "il record x è stato eliminato, come faccio a sapere chi è stato?" - la risposta è che non puoi - senza account individuali e controllo .

Con "auditing" intendo che, sebbene sia molto bello avere un account per tutti, ciò non significa che tu abbia una vera sicurezza. Se, per esempio, un record nella tabella delle risorse umane viene eliminato, tutto ciò che puoi dire è che qualcuno con accesso alla tabella delle risorse umane lo ha fatto - questo è il numero x di persone.

Nel sistema sono necessari trigger che registrano le azioni per essere in grado di rintracciare fino al livello individuale che ha eseguito l'azione X (a meno che non si disponga di un RDBMS come Oracle dove questo può essere reso automatico).

In ogni caso, dovresti sempre rendere la tua sicurezza quanto più granulare possibile il più presto possibile - dare alle persone l'accesso ai tavoli solo in base alla "necessità di sapere". E includi sempre i timestamp per le azioni sui tavoli - le persone spesso danno i loro ID agli altri - se puoi dire "Jimmy, eri l'unico in ufficio alle 17:49 ..." - di nuovo, non è ironico, solo un'altra freccia nella tua faretra.

Forse se ci fornissi il tuo RDBMS, potresti ottenere consigli più specifici / pertinenti alla tua situazione?

Sì. La connessione a un database da un'applicazione come un singolo utente potente costituisce una violazione del principio del privilegio minimo . Questa è la causa principale della maggior parte degli attacchi SQL Injection.

Questo di solito viene fatto a causa dell'ignoranza, per motivi di semplicità o talvolta per le prestazioni.

I database sono spesso di lunga durata e utilizzati da più applicazioni contemporaneamente e nel tempo. È possibile risparmiare risorse centralizzando il controllo degli accessi nel database anziché su più applicazioni.

Dovresti scegliere un server db che supporti Row Security, Column Security e Impersonation / Proxy Authentication (che supporta utenti db reali + pool di connessioni)

Sarebbe anche più sicuro per le applicazioni basate su "plugin", come Wordpress, dove è difficile evitare iniezioni di SQL a causa di autori di plugin non qualificati. Ogni plug-in ottiene l'accesso db, anziché l'applicazione nel suo insieme.