Azure: cadena de conexión en Key Vault frente a la configuración de la aplicación

8

Para Azure Functions y WebJobs, ¿hay algún beneficio al colocar cadenas de conexión como Secretos en Key Vault en lugar de ponerlas directamente en la Configuración de la aplicación (y hacer referencia a ellas usando ConfigurationManager.ConnectionStrings)? ¿Los secretos de Azure Key Vault están destinados principalmente a máquinas virtuales y similares en lugar de Azure Functions y WebJobs?

Parece que solo está agregando un paso adicional en el desarrollo (actualizar el secreto en Key Vault y el identificador secreto en la configuración de la aplicación) y un paso adicional en tiempo de ejecución (una recuperación adicional de Key Vault), con el único beneficio de que el secreto en la Configuración de la aplicación hay un identificador en lugar del secreto real. No veo el beneficio de seguridad aquí, mientras que hay perjuicios.

Anónimo1
fuente
Eso es genial para darle a su cadena de conexión de base de datos pública un error al presionar github :) (Si realmente necesita una razón)
Tensibai
No veo cómo sucedería eso. Estoy hablando de tener la cadena de conexión en la Configuración de la aplicación, que se almacena en la nube y nunca toca la base del código.
Anónimo1
Siempre que se haga en la nube mientras las interacciones gui estén bien, muévase a IaC puro donde toda la configuración de la nube se realiza como código, y esto sucederá algún día, esa es la razón principal para usar una bóveda. Si no lo encuentra necesario, no lo use ...
Tensibai
Sí, es solo que el Identificador Secreto parece tan seguro / inseguro como la cadena de conexión DB. Necesitas cambiar ambos o ninguno.
Anónimo1
Hu ... no realmente, algo llamado 'DB_Cx_String' al que se hace referencia en la configuración de la aplicación es menos problemático que 'jdbc: // host: port / DBname' por ejemplo.
Tensibai

Respuestas:

9

Los beneficios tal como los veo son las razones generales para usar Azure Key Vault

  • Los secretos se almacenan centralmente con opciones de autorización, auditoría, etc.
  • Azure puede ser programado para actualizar los secretos en un temporizador, por lo que en caso de que una cadena de conexión llegue a las manos equivocadas, solo es válida por un día (o una semana, o lo que sea)
  • En caso de que el secreto se comparta entre múltiples aplicaciones, solo tiene que actualizarlo en un solo lugar (no es el mayor beneficio, pero sigue siendo agradable)
Nicolai Skovvart
fuente
1
Me parece que estás diciendo que el almacén de claves solo es útil si varios servidores de aplicaciones comparten los MISMOS secretos. Si la cadena de conexión es utilizada por un único servidor de aplicaciones, entonces el almacén de claves no tiene ninguna ventaja.
John Henckel
3

Tengo la misma opinión que usted, no veo ningún punto en usar Key Vault en tales escenarios.

En su lugar, utilizo la Configuración de la aplicación de Azure https://docs.microsoft.com/en-us/azure/azure-app-configuration/overview , donde simplemente almaceno toda la configuración de la aplicación. Y la única cadena que almaceno en el servicio de la aplicación / func / trabajo web real sería la cadena de conexión para acceder a la Configuración de la aplicación de Azure.

En mi Startup, donde se aplican los ajustes de configuración, leo de ... settings.json y, si no está presente (que no debería estar ejecutándose en Azure), busco la cadena de conexión a la Configuración de la aplicación de Azure.

Si se encuentra ..settings.json, significa que me estoy ejecutando localmente.

..settings.json se cifra si no está en el archivo gitignore.

Se ve algo como esto:

var appConfigEndpoint = Environment.GetEnvironmentVariable("AppConfigEndpoint");
            var appConfigLabel = Environment.GetEnvironmentVariable("AppConfigLabel");

            if (!string.IsNullOrEmpty(appConfigEndpoint))
            {
                config.AddAzureAppConfiguration(options =>
                {
                    options.Connect(appConfigEndpoint);
                    options.Use(keyFilter: "*", labelFilter: appConfigLabel);
                });
            }
            else
            {
                config.AddJsonFile("appsettings.test.json", optional: false);
            }
Janus007
fuente
Llego demasiado tarde, pero si todavía tienes la misma opinión, tienes que cambiarla. La configuración (su referencia) no es para almacenar secretos, es para almacenar la configuración. La cadena de conexión DB es un secreto, no una configuración. KeyVault es para almacenar secretos, la configuración es para almacenar la configuración en una tienda centralizada. Espero que tenga sentido
RAM
0

La recuperación de la bóveda de claves puede ser un problema de rendimiento. Leer desde la bóveda de claves lleva varios segundos. El SLA de Azure solo dice que tomará menos de 5 segundos el 99.9% del tiempo. No garantiza el tiempo promedio, pero según mi experiencia y rumores, el promedio es de aproximadamente 2 segundos.

A menos que su aplicación web esté "siempre activa", se descargará si está inactiva durante 5-20 minutos. Eso significa que, a menos que tenga mucho tráfico, los tiempos de respuesta de su sitio con frecuencia serán malos.

John Henckel
fuente
1
Puede obtener la mayoría de los secretos de la aplicación solo una vez durante el inicio de la aplicación.
Miroslav Holec
0

Estamos planeando usar a continuación

Secretos - Azure Key-Vault

  • Rotación de clave maestra para columnas siempre cifradas
  • Almacén de certificados (puede escribir fácilmente un proveedor en .NET)
  • Elementos sensibles como cadenas de conexión (que ocultan otra información de recursos), contraseñas, etc.

Configuraciones : configuraciones de aplicaciones de Azure (todavía en versión preliminar)

  • Watch es un método maravilloso para el descubrimiento de servicios, especialmente si necesita actualizar indicadores o valores para usos operativos.
  • No es necesario reiniciar un contenedor o instancia.
Vinay
fuente