El objetivo de la informática sin servidor y de las plataformas como servicio (PaaS) es dar rienda suelta a la productividad de los desarrolladores reduciendo la carga administrativa para que puedan dedicarse a lo que realmente importa, la lógica de sus aplicaciones. Pero esto no puede hacerse a costa de la seguridad. Además, debe ser fácil conseguir procedimientos recomendados. Afortunadamente, contamos con un gran número de características en la plataforma de App Service y Azure Functions que reducen drásticamente la carga que supone la protección de las aplicaciones.

Hoy anunciamos nuevas características de seguridad que reducen la cantidad de código necesaria para administrar identidades y secretos. Entre ellas se incluyen las siguientes:

• Referencias de Key Vault para Application Settings (versión preliminar pública)
• Identidades administradas asignadas por el usuario (versión preliminar pública)
• Identidades administradas para App Service en Linux y Web App for Containers (versión preliminar pública)
• Datos de enlace como objeto ClaimsPrincipal para Azure Functions
• Funcionalidad de Access-Control-Allow-Credentials en la configuración de CORS

También seguimos invirtiendo en Azure Security Center como centro principal para la seguridad de los recursos de Azure, ya que ofrece una forma fantástica de detectar y resolver vulnerabilidades de configuración, limitar la exposición a amenazas o detectar ataques para poder responder a ellos. Por ejemplo, quizá piensa que ha restringido todas sus aplicaciones a HTTPS, pero Security Center le ayudará a asegurarse totalmente de que es así. Si no lo ha hecho aún, no deje de probarlo.

Así que vamos a hablar sin más demora sobre estas nuevas características.

Referencias de Key Vault para Application Settings (versión preliminar pública)

En Microsoft Ignite 2018, hablamos un poco de una característica nueva que iba a permitir que las aplicaciones tomaran su configuración de Key Vault. Me encanta poder anunciar que, a partir de hoy, esta característica está disponible en versión preliminar pública.

Cada vez son más las organizaciones que utilizan directivas de administración de secretos seguras, lo que es realmente fantástico. Azure Key Vault ofrece una fuente fidedigna para sus secretos, con el control total de las directivas de acceso y del historial de auditoría. Aunque la característica Configuración de la aplicación de App Service y Azure Functions se considera segura, con los secretos cifrados en reposo, no proporciona esta capacidad de administración que usted puede necesitar.

Sin embargo, el trabajo con Key Vault suele implicar la escritura de algún código nuevo. Hemos observado que a muchos equipos no les resulta fácil actualizar todos los lugares donde funciona su aplicación con secretos, sobre todo, en aplicaciones heredadas. Los desencadenadores de Azure Functions son también un problema, porque los administra la plataforma. Ambas situaciones se solucionan con esta nueva característica.

Obtención de la configuración de las aplicaciones de Key Vault

La característica de referencias de Key Vault permite que una aplicación pueda funcionar como si estuviera usando la opción Configuración de la aplicación como venía haciendo, es decir, no es necesario realizar cambios en el código. Encontrará toda la información en la documentación de Key Vault, pero mencionaré aquí algunos aspectos básicos.

Esta característica requiere una identidad administrada asignada por el sistema para la aplicación. Más adelante en esta entrada, hablaré de las identidades administradas asignadas por el usuario, pero, por ahora, vamos a mantener estas versiones preliminares separadas.

Después, deberá configurar una directiva de acceso en su instancia de Key Vault que le dé el permiso GET a la aplicación para obtener secretos. Vea cómo configurar una directiva de acceso.

Por último, establezca el valor de cualquier opción de la aplicación en una referencia con el siguiente formato:

@Microsoft.KeyVault(SecretUri=uri_del_secreto_con_versión)

Donde uri_del_secreto_con_versión es el URI completo de un secreto en Key Vault. Por ejemplo: https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931

Y ya está. No es necesario realizar cambios en el código.

Para esta primera versión preliminar, debe establecer una versión de secreto de forma explícita, ya que todavía no disponemos de control de rotación integrado. Es algo que esperamos ofrecer en cuanto sea posible.

Identidades administradas asignadas por el usuario (versión preliminar pública)

La funcionalidad actual de identidades administradas se denomina “asignadas por el sistema”. La idea es que la plataforma cree la identidad para una aplicación específica y esté ligada a su ciclo de vida. Si elimina la aplicación, la identidad se quita de Azure Active Directory de inmediato.

Hoy vamos a ver un adelanto de las identidades asignadas por el usuario, que se crean como recursos de Azure propios y, después, se asignan a una aplicación determinada. Una identidad asignada por el usuario se puede asignar también a varias aplicaciones. De igual modo, una aplicación puede tener varias identidades asignadas por el usuario.

Para obtener información sobre la creación y el uso de identidades asignadas por el usuario, consulte “Creación, enumeración, eliminación o asignación de un rol a una identidad administrada asignada por el usuario mediante Azure Portal”. Una vez que ha creado una identidad, puede asignarla a una aplicación. Para ello, actualice la configuración de la aplicación con un puntero dirigido a esa identidad. Encontrará más información al respecto en nuestra documentación sobre identidades administradas. Tenga en cuenta que esta versión preliminar no se admite en nubes independientes.

Sugerencia: Aunque se puede usar una identidad para varios recursos, se debe tener cuidado de no compartir demasiado las identidades para no dar permisos a recursos que no los necesitan. Tenga siempre presente el principio de “privilegios mínimos” y , de forma predeterminada, cree identidades diferentes para cada componente de una aplicación. Compártalas solo si es realmente necesario.

Identidades administradas para App Service en Linux y Web App for Containers (versión preliminar pública)

Estamos encantados también de ampliar la funcionalidad de identidades administradas a App Service en Linux y Web App for Containers. Ahora, las aplicaciones para Linux pueden disfrutar también de una gran experiencia de autenticación entre servicios llave en mano sin necesidad de administrar credenciales. Esta versión preliminar incluye funcionalidad de identidades tanto asignadas por el sistema como asignadas por el usuario. Además de un servicio de tokens que facilita la solicitud de acceso a recursos como Key Vault y Azure Resource Manager, esta nueva funcionalidad también concede a las aplicaciones de Linux acceso a la característica de referencias de Key Vault que hemos mencionado antes.

Para comenzar con sus aplicaciones para Linux, puede seguir los pasos de configuración que se indican en la documentación, “Cómo usar identidades administradas para App Service y Azure Functions”.

Datos de enlace como objeto ClaimsPrincipal para Azure Functions

Desde la primera versión preliminar de Azure Functions, ha podido utilizar la característica Autenticación/autorización de App Service para limitar el acceso a sus aplicaciones de función. Ahora lo estamos poniendo más fácil para que pueda aprovechar las identidades entrantes de su código de funciones. En este momento, está terminando la implementación y estará disponible para todas las aplicaciones de función en Azure a finales de semana.

Para .NET, se expone en forma de objeto ClaimsPrincipal, similar a lo que ya pudo ver en ASP.NET. El objeto se insertará automáticamente si agrega un objeto ClaimsPrincipal a la signatura de una función, similar a como se insertaba el objeto ILogger.

using System.Net;
using Microsoft.AspNetCore.Mvc;
using System.Security.Claims;

public static IActionResult Run(HttpRequest req, ClaimsPrincipal principal, ILogger log)
{
     // ...
     return new OkResult();
}

Otros lenguajes podrán acceder de igual forma mediante el objeto de contexto en una próxima actualización. Hasta entonces, esta es una versión preliminar solo para .NET. Si desea obtener más información acerca de esta funcionalidad, consulte la documentación del desencadenador HTTP.

De verdad que me encanta cómo mejora esto las funciones dependientes de identidades. Esta característica, junto con el enlace de tokens, elimina gran parte del código que no es fundamental para su lógica de negocios.

Funcionalidad de Access-Control-Allow-Credentials en la configuración de CORS

Por último, pero no menos importante, tenemos una actualización rápida de la característica CORS que permite establecer el encabezado Access-Control-Allow-Credentials. Este encabezado es necesario cuando se tienen que enviar cookies o un token como parte de una llamada a una API. Si no se establece este encabezado de respuesta, el explorador no pasa los datos.

Encontrará más información acerca de la característica CORS y esta nueva configuración en el tutorial “Hospedaje de una API RESTful con CORS en Azure App Service”. Para habilitar el encabezado, solo tiene que actualizar la configuración de CORS para establecer “supportCredentials” en true.

El encabezado Access-Control-Allow-Credentials se puede habilitar también para desarrollo en el host local de Functions, gracias a una fantástica solicitud de incorporación de cambios de la comunidad.

Resumen

Al igual que con todas nuestras versiones preliminares, nos encantaría que probase estas características y nos diese su opinión.

Si desea solicitar características nuevas, cree una idea en UserVoice (para Functions o para App Service). Para cuestiones específicas de Functions, plantee un problema en nuestro repositorio de GitHub. También puede ponerse en contacto con el equipo en Twitter: @AzureFunctions.

Esperamos tener noticias suyas pronto y poder continuar la conversación. Ahora, ¡vaya y proteja esas aplicaciones!