¿Cómo puedo almacenar de forma segura y acceder a los detalles de la cadena de conexión?

Question

Actualmente estoy trabajando en un sitio web de ASP.NET MVC, y yo he llegado a un punto en que necesito para integrar una base de datos en el sitio web.

Normalmente yo sólo tiene que añadir la cadena de conexión adecuada al archivo Web.config:

<add name="MainDB" 
    connectionString="Server=localhost; Database=TopSecretData; User Id=Joe; 
    password=password" providerName="System.Data.SqlClient" /> 

Pero obviamente hay una falla de seguridad evidente si dejo mi ID de usuario y la contraseña correcta en el Web.config, especialmente cuando está bajo la fuente controlar.

En resumen: ¿Cómo puedo guardar mis datos de conexión de cuerda sin tener que públicamente visibles?

Answer 1

La mejor práctica es encriptar la sección de cadenas de conexión. Uso aspnet_regiis.exe, que se puede encontrar en varios lugares:

• Inicio - Visual Studio - Visual Studio Tools - Visual Studio símbolo de sistema
• C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 (asegurándose de ejecutar como administrador)

Antes:

<configuration> 
<connectionStrings> 
<add name="MainConnectionString" 
connectionString="data source=Ratbert;database=Sales;username=ASPNET;password=$Double_Rainbow2011" 
providerName="System.Data.SqlClient"/> 
</connectionStrings> 
</configuration> 

Ejecutar este comando:

aspnet_regiis –pef connectionStrings c:\PathToWebSite 

O bien, si el comando anterior no funciona (y se obtiene el texto aspnet_regiis ayuda), tratan

aspnet_regiis -pe connectionStrings -app "/" -site 6 

donde el "6" es el ID del sitio como se informa en IIS.

Después:

<connectionStrings configProtectionProvider="RsaProtectedConfigurationProvider"> 
    <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" 
    xmlns="http://www.w3.org/2001/04/xmlenc#"> 
    <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" /> 
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> 
    <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#"> 
    <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" /> 
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> 
     <KeyName>Rsa Key</KeyName> 
    </KeyInfo> 
    <CipherData> 
     <CipherValue>Bf677iFrUFW ... +4n4ZZKXCTUAu2Y=</CipherValue> 
    </CipherData> 
    </EncryptedKey> 
    </KeyInfo> 
    <CipherData> 
    <CipherValue>UDEZ ...QfXUmM5rQ==</CipherValue> 
    </CipherData> 
    </EncryptedData> 
</connectionStrings> 

Ahora que es ilegible, no se puede editar. Descifrar así:

aspnet_regiis –pdf connectionStrings c:\PathToWebSite 

O

aspnet_regiis -pd connectionStrings -app "/" -site 6 

Y luego cambiar y volver a cifrar.

Para leer la cadena de conexión, use la clase estática de ConfigurationManager.

string connStr = 
ConfigurationManager 
.Connectionstrings["MainConnectionString"] 
.ConnectionString.ToString(); 

var myConnection = new SqlConnection(connStr); 

myConnection.Open(); 

Answer 2

Los enfoques comunes incluyen encrypting the web.config y storing the connection strings in the registry.

El segundo enlace es una parte de un artículo mucho más grande que cubre la forma de asegurar adecuadamente una aplicación ASP.NET. Fue escrito para WebForms, pero los principios son los mismos. Es una buena lectura y gran parte de ella todavía se aplica hoy, incluso si es un poco viejo.

Answer 3

Tal vez usted quiere mirar en la encriptación de su cadena de conexión: http://chiragrdarji.wordpress.com/2008/08/11/how-to-encrypt-connection-string-in-webconfig/ (artículo es un poco viejo)

Answer 4

Un método consiste en utilizar cualquier seguridad integrada que ofrece su DB, por lo que la contraseña no es un problema. El servidor obtiene acceso directo al servidor sin tener que usar una contraseña, pero debe configurar un usuario que solo tenga acceso desde el servidor web.

por ejemplo. Los DB como MySQL le permiten especificar qué servidores tienen acceso a él, restringir el acceso desde cualquier otro lugar, por lo que un hacker no puede acceder a su base de datos, excepto desde el servidor web. Esto reduce bastante la superficie de seguridad y le permite almacenar sus archivos de cadena de conexión en su SCM.

su todavía no es 100% seguro y cuando el hacker podría (a menudo con facilidad) piratear el servidor web y ver el DB de ella. Puede guardar la contraseña en otro lugar, pero eso simplemente está ocultando el problema: si el servidor web puede acceder a la contraseña, su hacker también puede hacerlo. (Nota, otros lugares para almacenar la contraseña incluyen el registro, un archivo separado como un archivo .udl o algo en/etc). Puede proteger este archivo para que solo el usuario del servidor web pueda leerlo, pero obviamente un servidor web pirateado puede leerlo.

Así que el siguiente paso es abstraer la conexión de DB para que quede fuera del servidor web, el método habitual es tener un proceso separado para almacenar su lógica comercial (por ejemplo, un servicio) que expone los métodos fijos: el servidor web simplemente llama al servicio que hace el trabajo y devuelve datos al código del servidor web.

Si un hacker derrota a su servidor web, lo único que pueden hacer es llamar a métodos en el servicio, que no tienen acceso directo a la base de datos por lo que no podría corromper o modificarla. Por lo general, habría pocos indicios al pirata informático de cuáles eran o cuáles eran los métodos de servicio, y el servicio tendría una buena cantidad de código de validación para todas las entradas, por lo que (con suerte) se rechazaría un mensaje creado por piratas informáticos. (use marcas de tiempo, contadores, etc. para tratar de derrotar el mensaje personalizado al servicio).

Este es el enfoque que utilizamos para un sistema de alta seguridad (hay mucho más que puede hacer para asegurar cada segmento de esta cadena utilizando mecanismos estándar de seguridad del sistema operativo). Las razones para hacer esto se hicieron muy claras para nosotros una vez que nuestro miembro de seguridad demostró un hack de IIS que le dio un shell remoto con privilegios de administrador. Cualquier cosa que haga para proteger sus configuraciones en el servidor web no tiene sentido si un hacker lo consigue.(y fue trivialmente fácil de hacer, ya que se corrigió, pero se encuentran exploits de 0 días todo el tiempo)

Answer 5

Puede almacenar cadenas de conexión cifradas en caché. El servidor de caché está en otro servidor a propósito (esta comunicación puede restringirse a 1 puerto y la dirección IP dificulta mucho más el pirateo). Esto desconectará completamente la cadena de conexión del servidor web e, incluso si un pirata informático obtiene acceso a la memoria caché, están encriptados. La clave es la carga de las cadenas en la memoria caché y eso se puede hacer de forma remota, por lo que esas cadenas de conexión nunca se escriben en el disco duro del servidor. El código solo descifra las cadenas de conexión según sea necesario y nunca se aferra a las cadenas no cifradas en una variable.