Utenti nei database SQL

In realtà c'è un terzo tipo di utenti, forse questo causa un po 'di confusione.

1. C'è l'utente SQL, alias login, in aziende che possono essere utenti o gruppi di Active Directory. Questo tipo di utente ha il diritto di connettere al motore di database SQL e uno o più database. Questo utente non deve usare l'applicazione per fare tutto ciò che può fare.

2. L'utente del database. Questo in genere è collegato a un accesso e viene utilizzato come base per la definizione dei diritti del database. Vi è negato di leggere la tabella B, permesso di selezionare dalla tabella F e aggiornare la tabella U ed eliminare le righe in D? Una tipica applicazione web pubblica deve avere uno o due utenti del database. Fai attenzione all'antimodello di rendere quell'utente il proprietario del database. Più utenti / account di accesso sono più comuni per i report aziendali o per le app desktop. Ancora una volta, questo utente non deve usare l'applicazione per fare tutto ciò che può fare. È possibile utilizzare altri strumenti.

3. L'utente registrato. Questo è l'utente che si è registrato con l'applicazione e riceve quindi le autorizzazioni per fare certe cose all'interno dell'applicazione. Questo utente non può connettersi direttamente al motore del database, tutta l'interazione è attraverso l'applicazione. Questo è il motivo per cui l'utente di login / database non dovrebbe essere dbo, ma ha invece autorizzazioni limitate. Probabilmente hai già sentito parlare di piccoli tavoli Bobby, se l'utente che l'applicazione utilizza per connettersi al database non era dbo, la tabella degli studenti non sarebbe stata eliminata.

Qui ci sono due classi di utenti:

1. utenti del database
2. utenti della tua applicazione web

Sono completamente diversi. (O dovrebbe essere.)

Gli utenti del database sarebbero dell'ordine di root (il database " superuser ") e wordpress (se stavi usando WordPress, per esempio, e lo scegliessi come nome per rappresentare WordPress quando ti connetti al database). Tutte le richieste dell'applicazione sul database verrebbero canalizzate attraverso solo uno (o pochi) account utente del database.

Quindi la tua applicazione avrebbe una propria tabella ( myapp_users dire, o wp_users per WordPress) che memorizza gli utenti dell'applicazione .

Ho visto applicazioni che confondono questi due tipi di utenti e dipendono interamente dai meccanismi di accesso al database. Questa è un'idea molto, molto, molto brutta, che violi un numero di minimo privilegio , separazione delle preoccupazioni e isolamento del fallimento principi dei domini.

La tua domanda di base ha risposto, vorrei anche affrontare un importante problema non menzionato / "elefante nella stanza": costruire l'identificazione dell'utente, l'autenticazione e l'autorizzazione è molto difficile e difficile da ottenere. Le implementazioni semplici quasi invariabilmente non riescono a proteggere la sicurezza e la privacy. Implementazioni per la prima volta e per principianti, anche di più. Se si sta sviluppando un codice da utilizzare in qualsiasi impostazione di produzione, considerare in base a una libreria esistente e comprovata come Laravel , Opauth o uLogin per gestire l'accesso utente invece di scrivere il tuo. (Non sto provando ad approvare alcun framework specifico qui, solo l'idea di non scrivere user management / login da soli.)