Come da oggetto, non so che utente fare SQL per il mio programma.....

dato che i dati di autenticazione vanno in file xml, non vorrei usare un utenza pericolosa per la sicurezza......

Cosa mi consigliate?

Grazie.

I dati su File XML possono sempre essere crittografati in modo semplice usando le funzionalità del framework.

In ogni caso ad un utente SQL applicativo vanno sempre dati diritti minimi di accesso. Se gli utenti lavorano tutti su tutti i dati oserei dire che Datareader + Datawriter sia il ruolo adatto inoltre, solitamente io genero un Ruolo Database a cui assegno i permessi di esecuzione sulle stored procedure, un lavoro tedioso e lungo, ma che con una bellissima Stored procedure che trovate sul mio Blog, opera del mio collega Luca Del Mestre, potete assegnare velocemente.

Puoi anche creare il Ruolo Database, dare a quel ruolo permessi di lettura e scrittura sulle tabelle che ti interessano e assegnargli i diritti di esecuzione sulle SP e poi assegnarlo a tutti i tuoi utenti.

Oppure, potresti anche  fare un doppio accesso, quindi le credenziali utente hanno solo diritto di leggere la tabella di mappatura utenti e su questa metti le vere credenziali crittografate e fai accedere al DB con queste, così anche con un driver ODBC i tuoi utenti non fanno danni...

saluti
Sabrina

Ciao Sabrina,

vorrei riprendere la questione per maggiori approfondimenti. Perché è necessario creare un utente con restrizioni per l'accesso al DB da programma? Non dovrebbe essere la logica del programma a gestire correttamente 'il non far danni' di un utente sui dati? Mi sto trovando con un applicativo in cui la gestione 'per utenti' di un database ci sta creando più problemi che altro, tralascio l'architettura dell'applicativo che abbiamo ereditato, ma ci stavamo chiedendo se piuttosto un oculata gestione da parte del codice non sia più 'comoda' di una assegnazione di diritti a utenti tramite l'applicativo. Ci troviamo con errori disseminati in modo "casuale" dovuti a non visibilità di alcuni oggetti del db e questa cosa ci sta esasperando non poco.

Grazie in anticipo e saluti

Federico

L'utente con restrizioni per uso da programma fa parte delle best practices di SQL Server e comunque di chiunque amministri ed usi un DB, separare sempre l'utente con possibilità di modificare le strutture dall'utente che utilizza il database.

Mai dare agli utenti alcun permesso oltre quelli strettamente necessari.

Se poi mi chiedi perché fare una doppia connessione, è opportuno farlo soprattutto se fai accedere gli utenti con una mappatura via trusted connection, perché in questo modo, gli utenti avendo i permessi diretti potrebbero agganciarsi a SQL Server usando qualsiasi driver ODBC (vedi excel, access o simili) e pasticciare sui dati.

Per risolvere il problema che vi siete trovati voi io procederei in questo modo:
Creerei sul DB un utente di tipo SQL (con  username + password) a cui darei tutti i permessi di lettura e scrittura ed esecuzione, poi farei in modo che il software utilizzasse questo account per la connessione al database eliminando la connessione diretta degli utenti e risolvendo alla radice il problema.

Se necessario, potete ottenerlo modificando la parte di accesso del programma in modo tale che il programma setti la connessione diretta dopo aver fatto l'accesso utente ed eventuale controllo credenziali dello stesso.

saluti

Sabrina