Beneficio práctico de usar SqlCredential vs nombre de usuario / contraseña en la cadena de conexión

Actualmente estoy usando la autenticación de SQL Server con el nombre de usuario / contraseña como parte de la cadena de conexión para mi aplicación web. Por lo que yo sé, este procedimiento estándar dentro del mundo .NET y posiblemente más allá. Sin embargo, estaba examinando los documentos para el SqlConnection.ConnectionString debido a un asunto no relacionado y notó que dicen:

  

SqlCredential es una forma más segura de especificar credenciales para una conexión que utiliza la autenticación de SQL Server.

Supongo que la mayor parte de esta seguridad se debe al uso de SecureString para almacenar la contraseña. Esta clase viene con su propio conjunto de problemas cuando se usa en el contexto de una aplicación web porque implementa IDisposable . Eso significa que tengo que hacer una de tres opciones malas:

1. A propósito, no desechar el SecureString dejándolo en una variable global estática que lee la contraseña del archivo de configuración una vez.
2. Acepte el impacto de rendimiento al leer la contraseña del archivo de configuración en cada solicitud.
3. Omita los beneficios de SecureString manteniendo la contraseña como string para que pueda deshacerme del SecureString regularmente sin incurrir en la pena de leer el archivo de configuración en cada solicitud.

Teniendo en cuenta esos problemas y el hecho de que si alguien tiene acceso al servidor, está instalado de todos modos . Además, parece que los beneficios de cifrar la cadena de conexión básicamente se reducen a , lo que reduce el riesgo de filtrar accidentalmente los detalles a personas que no deberían tenerlos:

  

Al mantener los detalles de la conexión fuera del control de la fuente y fuera de la distribución general, reduce la posibilidad de pérdida o fuga. ... Debido a esto, si el cifrado está en uso, separar la clave de la cadena de conexión y separar la cadena de conexión de la fuente es una acción esencial. Hacer esto ha separado los deberes y la protección de las claves de cifrado (o archivos de configuración) se convierte en una función de administrador del sistema, en lugar de una función de desarrollador.

Sin embargo, me parece que la forma más eficiente de reducir ese riesgo es restringiendo el acceso al servidor y la cadena de conexión solo a aquellos que necesitan saber a través de la compilación / lanzamiento automatizado ¹ y proteger su servidor es obviamente el primer paso y el más importante para proteger la cadena de conexión. Me parece que probablemente haya un beneficio teórico menor al usar el SqlCredential en una aplicación web ² , pero no hay un beneficio práctico real de tener el nombre de usuario / contraseña en la cadena de conexión.

Dicho esto, probablemente haya un error fundamental en mi razonamiento porque la gente de Microsoft es un grupo inteligente. Entonces, ¿qué me estoy perdiendo?

^{_{1: Transformar / agregar el valor automáticamente en el pipeline de compilación / lanzamiento.}}

^{_{2: estoy usando un Azure Cloud Service y conectarse a una Base de datos SQL de Azure , con la mayor parte de la lógica de la capa de aplicación escrita en C # si importa.}}