tiempo - ¿Cuál es la mejor manera de almacenar cadena de conexión en DLL.NET?
no se ha declarado el elemento ''configuration'' (8)
.NET admite el cifrado en valores de configuración como este. Puede dejarlo en un archivo de configuración, pero encriptado.
La aplicación que mi equipo está desarrollando actualmente tiene una DLL que se utiliza para realizar todo el acceso a la base de datos. La aplicación no puede usar una conexión confiable porque la base de datos está detrás de un firewall y el servidor de dominio no. Por lo tanto, parece que la cadena de conexión debe tener un nombre de usuario y contraseña DB. La DLL actualmente tiene la cadena de conexión de la base de datos codificada, pero no quiero hacer esto cuando lancemos, ya que el ensamblaje se puede desmontar y el nombre de usuario y la contraseña estarán ahí al aire libre.
Uno de los requisitos es que la contraseña debe cambiarse cada pocos meses, por lo que tendríamos que implementarla en nuestra base de usuarios internos.
¿Hay alguna forma de almacenar la contraseña cifrada de manera que podamos distribuirla fácilmente a toda la base de usuarios sin almacenarla en el ensamblado?
ACTUALIZACIÓN: Gracias a todos los que respondieron. Trataré de responderme algunas de las preguntas ... La DLL de datos es utilizada tanto por ASP.NET WebForms como por VB.NET WinForms. Entiendo que las aplicaciones pueden tener sus propios archivos de configuración, pero no he visto nada en los archivos de configuración para las DLL. Lamentablemente, no puedo acceder a la publicación de Jon Galloway en el trabajo, así que no puedo juzgar si funcionará. Desde el punto de vista del desarrollo, no queremos utilizar servicios web internos, pero es posible que los proporcionemos a terceros en algún momento del próximo año. No creo que la suplantación funcione porque no podemos autenticar al usuario a través del firewall. Como usuario (o ex usuario) puede ser un atacante, ¡lo estamos ocultando a todos!
Desea poder distribuir el archivo DLL con toda la información de configuración en un lugar configurable, pero el hecho es que no puede tener uno de los archivos de configuración handy-dandy .NET para un archivo DLL a menos que haga algo personalizado.
Tal vez deba replantearse qué responsabilidad debe tener su DLL. ¿Sería posible o tendría sentido exigir que el usuario de su biblioteca pase la cadena de conexión? ¿Realmente tiene sentido que su archivo DLL lea un archivo de configuración?
Odio decir esto, pero tan pronto como pones algo en una máquina cliente, la seguridad de esos datos se va por la ventana.
Si su programa va a descifrar esa cadena, debe suponer que un atacante puede hacer lo mismo. Adjuntar un depurador a su programa sería de una sola manera.
Almacenar la cadena de conexión en un servidor y obtenerla a través de una conexión web suena bien, hasta que se da cuenta de que también necesita seguridad en esa conexión web; de lo contrario, un atacante podría suplantar su programa y hablar con la conexión web.
Déjame hacer una pregunta. ¿De quién estás ocultando la cadena de conexión? El usuario o un atacante? Y si el usuario, ¿por qué?
También hay algunas otras ideas. Siempre puedes usar la suplantación. Además, puede usar la biblioteca de la empresa (biblioteca común).
<section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<enterpriseLibrary.ConfigurationSource selectedSource="Common">
<sources>
<add name="Common" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
filePath="Config/Exception.config" />
</sources>
Solo asuma que los malos obtendrán las credenciales de su archivo de configuración. Esto significa que podrán iniciar sesión en su base de datos y hacer lo que ese usuario sea capaz de hacer. Así que solo asegúrate de que el usuario no pueda hacer nada malo, como acceder directamente a las tablas. Haga que ese usuario solo sea capaz de ejecutar ciertos procedimientos almacenados y estará en mejor forma. Este es un lugar que mejora el brillo.
Varias opciones:
- Almacenar en web.config y encriptar
- Almacenar en dll y ofuscar (dotfuscator)
- Almacene uno en web.config (encriptado, por supuesto) y descanse en la base de datos (si tiene que usar múltiples y el cifrado / descifrado se convierte en un problema)
No estoy seguro, pero creo que puedes ponerlo en un archivo de configuración y encriptar el archivo de configuración.
Actualización: Vea la publicación de Jon Galloway aquí.
Si la aplicación es una aplicación ASP.NET, simplemente encripte la sección de cadenas de conexión de su web.config .
Si la aplicación es una aplicación cliente que se ejecuta en varias máquinas, en lugar de almacenar la cadena de conexión localmente, considere usar un servicio web u otro tipo de mecanismo seguro para almacenarla de manera central. Esto facilitaría actualizaciones más fáciles en el futuro y no está almacenando la cadena de conexión localmente.
Solo algunos pensamientos.
Actualizado: @ lassevk
"Almacenar la cadena de conexión en un servidor y obtenerla a través de una conexión web suena bien, hasta que se da cuenta de que también necesita seguridad en esa conexión web; de lo contrario, un atacante podría suplantar su programa y hablar con la conexión web. "
La seguridad en el servicio web fue implícita. Dependiendo del tipo de implementación, hay numerosas opciones ... por ejemplo, certificados del lado del cliente.