Connessione dell'applicazione al server di database

L'ho appena fatto anch'io. Supponendo che tu stia utilizzando SQL Server, in realtà ho creato account utente sul server di database per ogni utente (puoi farlo da t-sql). Ho un account utente generale che posso utilizzare per verificare prima di poter effettuare una connessione e selezionare da una tabella Version che si assicura che la versione del software in esecuzione corrisponda alla versione dello schema del database.

Gli utenti che hanno la possibilità di aggiungere / rimuovere utenti nell'applicazione devono disporre dei diritti per amministrare gli utenti sul server del database. Questo è in realtà un problema poiché gli utenti sono definiti a livello di server database, non a livello di database. Ciò significa che qualcuno con la possibilità di aggiungere / rimuovere utenti del server di database potrebbe potenzialmente creare un nuovo utente che potrebbe accedere a un altro database. Per questo motivo, suggerisco di eseguire un'istanza separata del server database per questo.

Ci sono altri modi per farlo:

• Se i tuoi utenti accedono a Windows con account univoci, puoi utilizzare la sicurezza integrata dove si autenticano solo con le credenziali di Windows. Ideale se funziona per te (avevamo alcuni computer condivisi, quindi non funzionava).
• È possibile avere un utente comune e hard-code le credenziali nella stringa di connessione, ma solo dare all'utente l'accesso alle stored procedure, non alle tabelle. Quindi, nelle stored procedure, è necessario passare le credenziali di accesso ogni volta e il proc memorizzato esegue l'autenticazione. Questo ha il vantaggio di consentire una sicurezza più granulare (puoi limitare le righe che possono recuperare, così, ad esempio, non sarebbero in grado di vedere i record della scheda attività di un altro utente, ma potrebbero vederne le proprie).
• Se hai bisogno solo di una protezione rudimentale di alcuni dati, hai solo due utenti: NormalUser e AdministratorUser. Memorizza solo la password di NormalUser nella stringa di connessione. Quando devi fare qualcosa che richiede permessi a livello di amministratore, falli entrare nella password di AdministratorUser e apri una nuova connessione.
• Inserisci il database in modalità solo locale (senza connessioni remote) e crea un servizio Web che gira su quella macchina e funge da livello di accesso ai dati. Questo ti permetterà di fare una sicurezza davvero avanzata (ti dà il controllo totale su ciò che un utente può vedere) e significa che il resto della tua applicazione vede i dati come oggetti di business piuttosto che righe e colonne. Il servizio web, ovviamente, deve gestire l'autenticazione.

Inserisci le informazioni sulle credenziali in <connectionString /> sul file app.config . Quindi, continua a crittografare la sezione <connectionStrings /> .

Vedi il seguente articolo per maggiori informazioni: Crittografia delle password in un file app.config .NET

La migliore pratica consiste nel dare a ciascun utente il proprio account sul database e impostare le autorizzazioni su quell'account per limitare il loro accesso come meglio credi.

Le credenziali dell'utente entrano in un file di configurazione per l'applicazione.

Puoi usare l'autenticazione integrata? Ad esempio, in SQL Server 2008 R2, la seguente stringa di connessione accede al database master locale utilizzando le credenziali di Windows.

Data Source=localhost;Initial Catalog=master;Trusted_Connection=true

E non consiglierei mai di creare utenti SQL per un'applicazione. Ora stai dando accesso diretto al database ai tuoi utenti, che dovrebbero sempre utilizzare l'applicazione (a meno che tu non autorizzi esplicitamente l'accesso diretto). Inoltre, sei limitato dagli strumenti che SQL ti offre per l'autenticazione. Un problema comune è l'accesso per riga, l'applicazione può eseguire il filtraggio abbastanza facilmente, ma la creazione di stored procedure per duplicarlo non è banale.

Per essere onesti, devi preoccuparti dell'escalation degli attacchi con diritti quando usi un account con proxy.