Tienes un par de opciones.
El primero, y preferido, sería establecer una capa de servicios web que la aplicación llame en lugar de ir directamente a la base de datos. Esto, obviamente, va a tomar un poco de tiempo para construir. Sin embargo, esto significaría que podría poner su base de datos detrás de un firewall que solo la capa de servicios web podría atravesar.
El segundo sería usar cifrar la parte de acceso a la base de datos del archivo app.config. Más información aquí: enlace
La tercera opción, que usaría en combinación con las opciones anteriores, sería eliminar todas las consultas directas de SQL de la aplicación y reemplazarlas por llamadas a procs almacenados que requieran un ID de usuario o un parámetro de token de usuario. Luego, cada proceso verificará que el id / token sea válido para la acción dada antes de ejecutarlo. Al mismo tiempo, cambiaría los derechos de la base de datos de modo que solo los procesos almacenados puedan ejecutarse.
Una cuarta opción es implementar SSPI en combinación con usuarios de servidores SQL nombrados (ya sea de directorio activo o de otro tipo). Esto significaría agregar, sin embargo, muchos usuarios (o grupos de usuarios) a su servidor de base de datos. La ventaja es que usted podría controlar de forma individual quién tenía derechos para iniciar sesión en el servidor DB Y no tendría un combo de nombre de usuario / contraseña en el archivo app.config. El inconveniente es que alguien necesita mantener eso.
* Tenga en cuenta que incluso si utiliza secciones de configuración cifradas, el usuario debe tener acceso a la clave de descifrado. Entonces, lo único que esto realmente hace es proteger la clave de las personas que pueden leer el archivo de texto claro app.config. Un usuario determinado con acceso a la computadora en la que se está ejecutando la aplicación todavía podría extraer la información de la cadena de conexión de la memoria de la computadora o descifrar la sección utilizando medios alternativos.