Hai un paio di opzioni.
Il primo, e preferito, sarebbe quello di stabilire un livello di servizi Web che l'applicazione chiama invece di andare direttamente al database. Questo, ovviamente, richiederà un po 'di tempo per essere costruito. Tuttavia vorrebbe dire che potresti mettere il tuo DB dietro un firewall che solo il livello dei servizi web potrebbe attraversare.
Il secondo sarebbe utilizzare crittografare la parte di accesso al database del file app.config. Maggiori informazioni qui: link
La terza opzione, che useresti in combinazione con le opzioni di cui sopra, sarebbe quella di rimuovere tutte le query sql dirette dall'app e sostituirle con chiamate ai proc memorizzati che richiedono un parametro token utente o utente. Quindi ogni proc controllerebbe che l'id / token fosse valido per la determinata azione prima di eseguirla. Allo stesso tempo dovresti cambiare i diritti del database in modo tale che solo i proc memorizzati possano essere eseguiti.
Una quarta opzione consiste nell'implementare SSPI in combinazione con gli utenti del server SQL nominati (sia la directory attiva che in altro modo). Ciò significherebbe aggiungere comunque molti utenti (o gruppi di utenti) al server del database. Il vantaggio è che si può controllare su base individuale chi ha i diritti per accedere al server DB E non si avrebbe un nome utente / password combo nel file app.config. Il rovescio della medaglia è che qualcuno deve mantenerlo.
* Tenere presente che anche se si utilizzano sezioni di configurazione crittografate, l'utente deve avere accesso alla chiave di decrittografia. Quindi l'unica cosa che fa veramente è proteggere la chiave da persone che potrebbero leggere il file app.config in chiaro. Un utente determinato con accesso al computer su cui è in esecuzione l'applicazione potrebbe ancora estrarre le informazioni sulla stringa di connessione dalla memoria del computer o decrittografare la sezione utilizzando mezzi alternativi.