Implementación de controles de seguridad para Azure App Service

Completado

Azure App Service proporciona varios controles de seguridad integrados que funcionan en la capa de plataforma, antes de que cualquier solicitud llegue al código de la aplicación. Para Contoso Retail, la aplicación de estos controles cierra las dos primeras brechas de la prueba de penetración: ninguna aplicación de autenticación de nivel de plataforma y tráfico entrante sin restricciones desde cualquier dirección IP de origen.

Configurar la autenticación con Microsoft Entra ID

La característica de autenticación integrada de App Service, denominada EasyAuth, se ejecuta como una capa de middleware que intercepta todas las solicitudes HTTP entrantes antes de que llegue a la aplicación. Al configurar EasyAuth con Microsoft Entra ID como proveedor de identidades y establecer la acción de solicitud no autenticada en Require authentication, las solicitudes no autenticadas nunca llegan al código de la aplicación. La plataforma devuelve una respuesta 401 para los clientes de API o redirige a los usuarios del explorador a la página de inicio de sesión de Microsoft Entra.

Tres opciones requieren atención al configurar EasyAuth:

• Almacén de tokens: habilite esta configuración para que App Service almacene y administre tokens de OAuth en nombre de los usuarios autenticados. El código de la aplicación puede leer el token de los encabezados de solicitud HTTP insertados sin implementar la propia administración de tokens.
• Audiencias de token permitidas: defina este valor en el ID de cliente del registro de aplicaciones de Microsoft Entra de su aplicación. Esto rechaza los tokens emitidos para otras aplicaciones, incluso si están firmados con un certificado de emisor de confianza.
• Actualización de tokens: configure cuánto tiempo espera la plataforma antes de actualizar los tokens antes de que expiren. El comportamiento predeterminado actualiza los tokens automáticamente.

Para configurar EasyAuth en el portal de Azure, vaya a App Service, seleccione Settings>Authentication y seleccione Add identity provider. Elija Microsoft como proveedor y, a continuación, especifique el inquilino y el registro de aplicaciones de Microsoft Entra.

Note

EasyAuth controla la autenticación: comprueba la identidad. Las decisiones de autorización, como el acceso basado en roles dentro de la aplicación, siguen necesitando la implementación en el código de la aplicación.

Autenticación de llamadas salientes con identidad administrada

Su App Service realiza llamadas salientes a otros servicios de Azure: Azure SQL Database, Key Vault, Azure Storage, servicios de IA de Azure y puntos de conexión de Azure OpenAI. Cada conexión requiere autenticación. El almacenamiento de credenciales en la configuración de la aplicación o las cadenas de conexión es un riesgo de seguridad: si la configuración se expone en registros, canalizaciones o mensajes de error, esas credenciales también se exponen.

Una identidad administrada asignada por el sistema elimina este riesgo. Al habilitar una identidad administrada en App Service, Azure crea una identidad en Microsoft Entra ID enlazada al ciclo de vida de ese recurso de App Service específico. No crea, almacena ni rota las credenciales de esta identidad, Azure las administra automáticamente.

Para usar la identidad administrada para un servicio de bajada, asigne el rol adecuado a la identidad administrada en el recurso de destino. Por ejemplo:

• Asigne Key Vault Secrets User en el Key Vault para recuperar secretos.
• Asigne Storage Blob Data Reader a una cuenta de almacenamiento para poder leer blobs.
• Asigne un rol integrado a un recurso de Azure OpenAI para invocar el punto de conexión de inferencia.

Para habilitar la identidad administrada en el portal de Azure, vaya a Settings>Identity, después, active System assigned status to On y seleccione Save.

Forzar HTTPS y la versión mínima de TLS

Todo el tráfico a App Service debe viajar a través de HTTPS. La plataforma acepta conexiones HTTP de forma predeterminada, lo que significa que las credenciales, los tokens y los datos de la aplicación se pueden transmitir a través de conexiones sin cifrar sin configuración adicional. Dos configuraciones cierran esta brecha.

HTTPS solo obliga a todas las solicitudes HTTP a redirigirse a HTTPS antes de llegar a la aplicación. Habilite en el portal de Azure en Settings>Configuration>Configuración general, a continuación, establezca HTTPS Only en On.

La versión mínima de TLS establece la versión de protocolo más baja aceptada. Establézcalo en 1.2 para rechazar las conexiones de los clientes que usan TLS 1.0 o 1.1, ambas tienen vulnerabilidades y se consideran en desuso. La configuración mínima de la versión de TLS se encuentra en la misma página Configuración general .

Restricción del tráfico entrante con restricciones de acceso

Las restricciones de acceso en App Service controlan qué direcciones IP de origen y intervalos de red pueden enviar solicitudes entrantes a la aplicación. Las reglas se configuran en una lista de permitidos o denegados ordenados por prioridad. Cuando la lista contiene al menos una regla, un deny-all implícito se aplica a cualquier origen que no coincida con una regla.

Dos tipos de reglas son útiles al integrar App Service con una instancia de Application Gateway:

• Reglas basadas en IP: permiten una dirección IPv4 específica o un rango CIDR. Úselo cuando la dirección IP pública de Application Gateway sea estática y conocida.
• Reglas de etiquetas de servicio: permite el tráfico identificado por una etiqueta de servicio, como AzureApplicationGateway. Este enfoque es más resistente a los cambios de dirección IP de Application Gateway.

Para configurar las restricciones de acceso, vaya a Configuración>Redes>Acceso a redes públicas. Seleccione Agregar para agregar una regla, establezca Acción en Permitir y especifique el tipo de origen y el valor. Las reglas se evalúan en orden de prioridad: la regla con el número de prioridad más bajo se evalúa primero.

Importante

Configurar restricciones de acceso para permitir solo el tráfico de Application Gateway es el paso que evita que los atacantes eludan el WAF dirigiéndose directamente al nombre de host de App Service. No omita este paso después de implementar Application Gateway.

Habilitación de la integración de red virtual para el acceso de salida privado

La integración de red virtual permite que App Service realice conexiones salientes a recursos dentro de una red virtual de Azure sin esos recursos que tengan un punto de conexión público. Su App Service puede acceder a una base de datos privada de Azure SQL Database, a un Key Vault con el acceso público deshabilitado o a un punto de conexión privado de API, todo ello a través de todo el espacio de direcciones de la red virtual.

La integración con red virtual regional funciona mediante la unión de App Service a una subred delegada en la red virtual. Las conexiones salientes de App Service se originan en el intervalo de direcciones IP de la red virtual, por lo que los recursos privados pueden conceder acceso en función de la subred en lugar de una dirección IP pública.

Configure la integración de red virtual en el portal de Azure en Settings>Networking>VNet integration. Seleccione Agregar integración de red virtual y elija la red virtual y la subred. La subred debe delegarse en Microsoft.Web/serverFarms y no debe usarse para ningún otro recurso de App Service.

Implementación de un punto de conexión privado para el acceso de entrada totalmente privado

Un punto de conexión privado asigna a App Service una dirección IP privada en una subred de la red virtual. Con un punto de conexión privado implementado y el acceso a la red pública deshabilitado, App Service no tiene ningún punto de conexión accesible desde Internet. La única ruta de acceso a la aplicación es a través de la red virtual.

Esta configuración se empareja naturalmente con Application Gateway como punto de entrada público. Application Gateway recibe tráfico de Internet en su dirección IP pública, WAF inspecciona cada solicitud y las solicitudes aprobadas se reenvía al punto de conexión privado de App Service a través de la red virtual. App Service nunca es accesible directamente desde Internet.

Implemente un punto de conexión privado; para ello, vaya a Configuración>Redes>puntos de conexión privados y seleccione Agregar. Especifique la subred en la que se va a crear el punto de conexión privado y permita que Azure cree la entrada de zona DNS privada necesaria.

Referenciar secretos de Key Vault desde la configuración de la aplicación

En lugar de almacenar valores confidenciales, como cadenas de conexión y claves de API, directamente en la configuración de la aplicación, utilice referencias de Key Vault. Una referencia de Key Vault es un valor de configuración de la aplicación con el siguiente formato:

@Microsoft.KeyVault(SecretUri=https://<vault-name>.vault.azure.net/secrets/<secret-name>)

En tiempo de ejecución, App Service resuelve la referencia llamando a Key Vault mediante la identidad administrada que configuró anteriormente y, a continuación, sustituye el valor de secreto real. El código de la aplicación lee normalmente la configuración de la aplicación y recibe el valor secreto; no se necesitan cambios en el código de la aplicación.

Las referencias de Key Vault proporcionan dos ventajas operativas además de la seguridad de las credenciales. Si un secreto gira en Key Vault, App Service recoge el nuevo valor automáticamente en un plazo de 24 horas, o inmediatamente en el siguiente reinicio o cambio de configuración de la aplicación. Y, dado que el valor secreto nunca aparece en los paneles de configuración de App Service ni en los artefactos de implementación, es más difícil que quede expuesto accidentalmente.

Tip

Para ver la sintaxis completa de la cadena de referencia y las instrucciones sobre cómo configurar el acceso a almacenes con acceso restringido por red, consulte Uso de referencias de Key Vault como configuración de la aplicación en Azure App Service.