Antes del Global Azure Bootcamp, estuve buscando cómo podría permitir que un equipo distribuido desarrolle e implemente una aplicación web para acceder a una instancia de Azure SQL Server de forma segura. Hay algunas formas diferentes en las que podría compartir credenciales para acceder a mi base de datos de Azure SQL:
- Variables de entorno:esto mantiene secretos (como contraseñas) fuera del código y mitiga el riesgo de que se comprometan con el código fuente. Pero las variables de entorno se almacenan en texto sin formato, por lo que si el host se ve comprometido, esos secretos se pierden.
- Herramienta .NET Core Secret Manager:hay un paquete NuGet que permite al usuario mantener los secretos de la aplicación (como una contraseña) en un archivo JSON que se almacena en el directorio del perfil del usuario; nuevamente, esto mitiga el riesgo de que los secretos estar comprometido con el código fuente, pero aún tendría que compartir ese secreto para almacenarlo en texto sin formato.
Ninguna de estas opciones es ideal para mí:prefiero otorgar acceso a mi base de datos de Azure SQL por función y no compartir contraseñas con desarrolladores que deban escribirse en algún lugar, ya sea en JSON o en mis scripts de implementación automatizados. Y aunque las dos opciones anteriores mitigan el riesgo de que las contraseñas se comprometan con el código fuente, no eliminan el riesgo.
Así que estaba muy emocionado de leer acerca de Azure Key Vault (AKV), una forma de almacenar secretos de forma segura en la nube y evitar cualquier riesgo de que los secretos se comprometan con el código fuente.
Esta página de Microsoft presenta algunas historias de usuarios diferentes y cómo AKV satisface estas necesidades, específicamente en torno a:
- Aislamiento de secretos de aplicaciones y desarrolladores
- Claves cifradas:ni siquiera Microsoft puede verlas
- Se registra cualquier acceso a secretos en AKV
- Los secretos se almacenan en módulos de seguridad de hardware que están validados FIPS 140-2 nivel 2 (enlace de wikipedia aquí)
(Hay más información sobre Stack Overflow aquí)
Pero después de leer el documento aquí, me sorprendió un poco que la implementación descrita todavía usara la herramienta Administrador de secretos; parecía que solo estábamos intercambiando el almacenamiento de secretos en un lugar por otro. Busqué para encontrar cómo se podía hacer esto sin la herramienta Administrador de secretos, y en numerosas publicaciones de blog y videos vi a los desarrolladores configurando un secreto en AKV, pero luego copiando un "secreto de cliente" de Azure en su código, y pensé esto realmente anuló el propósito de tener una bóveda para secretos.
Afortunadamente, encontré lo que debo hacer para usar AKV con mi aplicación web .NET Core y no tengo que agregar ningún secreto al código:protejo mi aplicación con una identidad de servicio administrado. He descrito cómo hacer esto a continuación, con el código C# que necesitaba para usar la función.
Cómo mantener los secretos fuera de su código fuente.
- Primero crea una bóveda
- Añade un secreto a tu bóveda
- Proteja su servicio de aplicaciones mediante la identidad de servicio administrado
- Acceda al secreto desde su código fuente con KeyVaultClient
Cubriré cada uno de estos a su vez, con ejemplos de código al final para mostrar cómo acceder al AKV.
Primero crea una bóveda
Abra Azure Portal e inicie sesión; haga clic en el elemento de menú "Todos los servicios" en el lado izquierdo y busque "almacén de claves". Esto debería filtrar las opciones para que tenga una pantalla como la que se muestra a continuación.
Una vez que tenga la opción Key Vaults, haga clic en ella para ver una pantalla como la siguiente que enumerará los Key Vaults de su suscripción. Para crear una nueva bóveda, haga clic en el botón "Agregar", resaltado en el documento a continuación.
Esto abrirá otra "hoja" (que solo veo como jerga para una ventana flotante) en el portal donde puede ingresar información sobre su nueva bóveda.
Como puede ver en la imagen a continuación, llamé a mi bóveda "MyWebsiteSecret" y creé un nuevo grupo de recursos para él llamado "Development_Secret". Elegí la ubicación para que sea "UK West" y, de manera predeterminada, mi usuario se agregó como el primer principal que tiene permiso para acceder a esto.
Hice clic en el botón Crear en la parte inferior de la pantalla y el portal presenta un brindis en la parte superior derecha para decir que mi bóveda está en proceso de creación.
Eventualmente, esto cambia cuando la implementación ha tenido éxito.
Entonces, la pantalla de Azure Portal ahora muestra la página de lista nuevamente, y mi nueva bóveda está en esta página.
Añadir un secreto a la bóveda
Ahora que se crea la bóveda, podemos crear un nuevo secreto en ella. Haga clic en la bóveda creada en el paso anterior para ver los detalles de esta bóveda (que se muestra a continuación).
Ahora haga clic en el elemento del menú "Secretos" para abrir una hoja que muestra los secretos en esta bóveda. Obviamente, como lo acabo de crear, todavía no hay secretos. Podemos crear haciendo clic en el botón "Generar/Importar", resaltado en la imagen a continuación.
Después de hacer clic en el botón "Generar/Importar", se abre una nueva hoja donde puede ingresar los detalles de su secreto. Elegí un nombre de "TheSecret", ingresé un valor secreto que está enmascarado e ingresé un poco de texto para el tipo de contenido para describir el tipo de secreto.
Una vez que hago clic en "Crear" en la parte inferior de la hoja, el sitio me devuelve a la lista de secretos en esta bóveda, pero esta vez, puede ver mi secreto en la lista, como se muestra a continuación.
Proteja el servicio de aplicaciones mediante la identidad de servicio administrado
Anteriormente implementé mi aplicación .NET Core en Azure. No entraré en muchos detalles sobre cómo implementar una aplicación .NET Core, ya que está en un millón de publicaciones y videos de blogs más. Básicamente, creé un nuevo App Service a través de la Azure Portal y lo vinculé a una aplicación .NET Core en mi perfil de GitHub. Ahora, cuando envío código a esa aplicación en GitHub, Azure lo compilará e implementará automáticamente.
Pero quiero mostrar cómo crear una identidad de servicio administrado para esta aplicación; como se muestra en la imagen a continuación, busqué mi servicio de aplicaciones en Azure.
Seleccioné mi servicio de aplicaciones para abrir una hoja con opciones para este servicio y seleccioné "Identidad de servicio administrado", como se muestra a continuación. De forma predeterminada, está desactivado:dibujé una flecha debajo junto al botón que presioné para activarlo para el servicio de la aplicación y luego hice clic en Guardar para conservar mis cambios.
Una vez que se guardó, tuve que volver a la bóveda de claves y al secreto que creé anteriormente y seleccionar "Políticas de acceso", como se muestra a continuación. Como mencioné anteriormente, mi nombre está ahí como si tuviera permiso de forma predeterminada, pero quiero que mi aplicación también tenga permiso, así que hice clic en la opción "Agregar nuevo", que he resaltado con una flecha roja a continuación.
Se abre la hoja a continuación:en principio, seleccioné mi servicio de aplicaciones (llamado "MyAppServiceForTestingVaults"). De manera predeterminada, no se selecciona nada, por lo que solo debe hacer clic en la opción para abrir otra hoja donde puede buscar su servicio de aplicaciones. Solo estará disponible si configuró correctamente la identidad del servicio administrado como se describe anteriormente.
Además, seleccioné dos "Permisos secretos" del menú desplegable:Obtener y Listar.
Una vez que hago clic en Aceptar, ahora puedo ver que mi aplicación está en la lista de servicios de aplicaciones que tienen acceso al secreto que creé anteriormente.
Añadir código a mi aplicación .NET para acceder a estos secretos
Uso la extensión de autenticación de servicios de Azure para simplificar el desarrollo con mi cuenta de Visual Studio.
Voy a elegir un ejemplo realmente simple:modificar la acción de índice de una clase HomeController en el sitio web predeterminado de .NET Core MVC. También necesito agregar un paquete NuGet a mi proyecto:
Install-Package Microsoft.Azure.Services.AppAuthentication -Version 1.1.0-preview
El siguiente código me permite autenticarme en mi instancia de Azure y obtener el secreto de mi bóveda.
public class HomeController : Controller
{
public async Task<ActionResult> Index()
{
var azureServiceTokenProvider = new AzureServiceTokenProvider();
var keyVaultClient = new KeyVaultClient(new KeyVaultClient.AuthenticationCallback(azureServiceTokenProvider.KeyVaultTokenCallback));
var secret = await keyVaultClient.GetSecretAsync("https://mywebsitesecret.vault.azure.net/secrets/TheSecret").ConfigureAwait(false);
ViewBag.Secret = secret.Value;
return View();
}
// rest of the class...
}
Ahora solo puedo modificar la vista Index.cshtml y agregar código para mostrar el secreto (tan simple como agregar @ViewBag.Secret en el cshtml), y cuando ejecuto el proyecto localmente, ahora puedo ver que mi aplicación ha podido acceder a la bóveda y descifrar mi secreto (como se destaca en la imagen a continuación) sin ninguna identificación de cliente o información secreta de cliente en mi código – esto se debe a que mi máquina reconoce que estoy autenticado para acceder a mi propia instancia de Azure.
También puedo implementar este código en mi Azure App Service y obtendré los mismos resultados, porque la identidad del servicio administrado de la aplicación garantiza que mi aplicación en Azure tenga permiso para acceder al secreto.
Resumiendo
Este fue un ejemplo realmente simple, y es solo para ilustrar cómo permitir que los desarrolladores accedan a los secretos de AKV sin tener que agregar información secreta al código fuente. Obviamente, si un desarrollador está decidido a comprometer la seguridad, obviamente podría descifrar las contraseñas y difundirlas de otra manera, por lo que tendríamos que reforzar la seguridad para una aplicación del mundo real. Por ejemplo, podríamos tener diferentes secretos almacenados en diferentes grupos de recursos ambientales a medida que promovemos nuestra aplicación desde Dev a QA/Staging y finalmente a Production.
https://codehollow.com/2017/11/get-started-azure-key-vault/
https://odetocode.com/blogs/scott/archive/2018/03/08/decryption-with-azure-key-vault.aspx
https://docs.microsoft.com/en-us/azure/app-service/app-service-managed-service-identity
https://azure.microsoft.com/en-us/resources/samples/app-service-msi-keyvault-dotnet/