Salve,
senza pretesa di completezza, come gia' indicato da @PIGI78, SQL Server gestisce la sicurezza in diverse distinte fasi...
la prima fase riguarda l'autenticazione, cioe' la possibilita' di connessione all'istanza stessa.. questa avviene con 2 metodologie
completamente separate, cioe' con autenticazioni "trusted", dove il sid dell'account di logon a Windows viene valutato/accettato da SQL Server stesso quale login riconosciuta; in caso di dominio, SQL Server si basa su quanto gestito/inviato dal DomainController...
come sicuramente gia' sai, l'autenticazione integrata si basa sull'accreditamento di un account WinNT ovvero di un gruppo WinNT mappata su
una login interna di SQL Server, individuale nel primo caso, di gruppo nel secondo... la procedura di sistema da utilizzare in tal senso e' appunto sp_grantlogin (o CREATE/ALTER LOGIN...), che per l'appunto mappa un account/gruppo WinNT su una login SQL Server autorizzata alla connesione.. di default, in questo ambito, SQL Server, al momento dell'installazione, provvede a garantire l'accesso a tutti gli amministratori locali creando la login di gruppo Builtin\Administrator, membri del ruolo del server sysadmin, che comunque e' eliminabile...
quindi la cosa va attentamente amministrata... ed in questo caso devi consentire al tuo account Windows (amministratore o meno che esso sia) la possibilita' di autenticazione all'istanza...
l'altra metodologia, tramite autenticazione standard, che richiede la provvista di credenziali di autenticazione, tipicamente userid e password ...
la seconda macro-parte di sicurezza e' invece relativa agli accessi alle singole basi dati, per la quale, ogni login che non faccia parte del ruolo del server sysadmin, necessita di esplicita autorizzazione (escludiamo le particolarita' dell'utente di database Guest in quanto e' mia abitudine rimuoverlo) per l'accesso ad ognuno di essi, tramite la procedura sp_grantdbaccess (o CREATE USER...), che provvede appunto a mappare gli utenti di database alle relative login di istanza..
all'interno di ogni database esistono dei ruoli standard di database, ai quali e' possibile aggiungerne di personali, anche al fine di avere oculate politiche di assegnazione di privilegi... esiste anche chiaramente un "utente" particolare, dbo, che in fin dei conti e' il proprietario della base dati e puo' per definizione operare in qualisiasi ambito al suo interno... e questo non e' modificabile, fa parte dell'architettura di sicurezza di SQL Server...
C'e' poi la terza macro-parte di sicurezza, relativa all'accesso ai singoli "oggetti", quindi tabelle/viste/stored procecdures etc...
qui la logica di sicurezza volge a garantire "l'accesso" minimo alle funzionalita' desiderate per lo specifico "database user" (NON Login, ma user)... ci sono "ruoli" di database, vedi sopra, che hanno gia' un set specificato di privilegi in tal senso, ma con questa sezione puoi estendere/limitare (non sempre la seconda) l'accesso ad oggetti specifici.
La quarta parte riguarda privilegi/limitazioni ancora piu' specifiche, a livello ad esempio di "colonna" di una specifica tabella, ma qui sorvoliamo
ora, visto il quadro generale, molto spesso ho visto gestire l'accesso applicativo con sistemi "fatti in casa", quindi NON utilizzando il set messo a disposizione da SQL Server, ma gestendo tutto con tecniche di "raggiro" o comunque gestite con logica di business (non di soldi )...
L'applicazione, al primo accesso, richiede un privilegio di connessione (Login) a livello di sysadmin (quindi richiede la pwd della login "sa" o altra login amministrativa), provvede a generare una "propria" Login SQL con pwd conosciuta a livello dell'applicazione, con privilegi almeno di CREATE DATABASE per poter gestire i "propri database" [ma molto spesso ho visto priviegli amministrativi "totali" ]... SE chi ha scritto l'applicativo e' lungimirante, crea anche una Login SQL "senza privilegi", da utilizzare come "utente interattivo" vero e proprio, cioe' quello che accedera' ai dati.
Poi l'applicazione crea i propri database, crea il db_user "interattivo e limitato" in ogni suo db... a questo db_user vengono poi assegnati i privilegi necessari (spesso "troppi")... personalmente non apprezzo molto i privilegi db_datareader e db_datawriter in quanto preferisco permettere l'accesso ai dati solo tramite stored procedures o viste non aggiornabili, ma poi qui si entra in un'altra area di preferenze e flames...
Quindi, tecnicamente, a parte la login amministrativa "personale" dell'applicazione, c'e' anche una "login interattiva" che, come db_user del db applicativo, accede al/ai db, e quindi agli oggetti e "fa cose"
il db applicativo sicuramente conterra' una tabella "utenti", tabella "privilegi", ..., dove l'applicativo stesso gestira' a livello applicativo la granularita' dei privilegi applicativi... ma tutto questo e' business oriented e NON SQL Server oriented
in ogni caso, suggerisco di utilizzare Login amministrative SOLO nei casi necessari, quindi per creare db etc... non per le standard operazioni CRUD...
salutoni romagnoli
--
Andrea