Protección del acceso a la red para aplicaciones de funciones

Completado

Una aplicación de funciones con la autenticación configurada controla quién puede llamarla, pero el extremo de la función sigue siendo accesible desde cualquier ruta de red, incluido Internet público. Los controles de red añaden una capa de control independiente: restringir qué rutas de red pueden acceder a la función y controlar qué rutas de red utiliza la función para realizar sus propias llamadas salientes. La autenticación y el aislamiento de red son independientes y complementarios. Ambos deben estar instalados para mantener una posición de seguridad sólida.

Restricción del acceso entrante con listas de direcciones IP permitidas

Las restricciones de acceso le permiten definir una lista de reglas de permiso y denegación ordenada por prioridad en función de la dirección IP de origen, un rango CIDR o una etiqueta de servicio de Azure. Cuando existe una regla explícita, se aplica un denegado implícito a todo el tráfico que no coincide, no es necesario agregar manualmente una regla de denegación.

En el caso de las aplicaciones de funciones que solo deben aceptar llamadas entrantes de servicios de Azure específicos, las reglas de etiquetas de servicio proporcionan una solución limpia. Por ejemplo, para aceptar llamadas de webhook solo desde Azure Event Grid, agregue una regla que permita la etiqueta de servicio AzureEventGrid y deniegue el resto del tráfico. La etiqueta de servicio cubre el intervalo completo de direcciones IP que usa ese servicio Azure, por lo que no es necesario administrar intervalos IP individuales para los servicios que usan grupos de direcciones dinámicas.

Las restricciones de acceso están disponibles en todos los planes de hospedaje de Function App, incluidos Consumo, Consumo flexible, Elastic Premium y Dedicado.

Sugerencia

Configure las restricciones de acceso para denegar todo el tráfico de forma predeterminada y agregue reglas de permiso explícitas para orígenes conocidos antes de realizar la implementación en producción. Partir de un enfoque de denegarlo todo es más sencillo de auditar que crear una lista de bloqueo frente a una política implícita de permitirlo todo.

Implementación de un punto de conexión privado para el acceso entrante

Si el tráfico de la aplicación de funciones nunca debe atravesar la Internet pública, un punto de conexión privado elimina por completo el punto de conexión público. Un punto de conexión privado asigna a la aplicación de funciones una dirección IP privada dentro de la red virtual (red virtual). Todo el tráfico entrante llega a través de esa dirección IP privada: los autores de llamadas externos no pueden acceder a la dirección URL de la función desde Internet porque no existe ninguna ruta pública.

Los puntos de conexión privados para las aplicaciones de funciones se admiten en los planes de hospedaje Flex Consumption, Elastic Premium y Dedicated (App Service). El plan de consumo estándar no admite puntos de conexión privados.

Una vez configurado un punto de conexión privado, los llamadores dentro de la red virtual (incluidos otros servicios de Azure conectados a la misma red) resuelven el nombre de host de la función en la dirección IP privada. Esta resolución de nombres requiere zonas privadas de Azure DNS. Si la función es el back-end de Azure API Management o una instancia de Application Gateway, esos recursos se conectan a la aplicación de funciones a través del punto de conexión privado en lugar de una dirección URL pública, manteniendo todo el tráfico en la red troncal de Azure.

Importante

Después de crear un punto de conexión privado para una aplicación de función, deshabilite el acceso a la red pública para asegurarse de que todo el tráfico entrante fluye solo a través del punto de conexión privado. Si se deja habilitado el acceso público mientras existe un punto de conexión privado, se crea una posición de red de ruta de acceso dividida que es difícil de auditar.

Configuración de la integración de red virtual para el tráfico saliente

Los puntos de conexión privados controlan el acceso entrante: qué puede acceder a la aplicación de función. La integración de red virtual controla el acceso saliente: a qué puede acceder la aplicación Function. Estos son controles distintos y sirven para diferentes propósitos.

Con la integración de red virtual habilitada, la aplicación de funciones enruta sus llamadas de red salientes a través de una subred delegada en la red virtual. Esto permite que la función llame a recursos que no están expuestos a la red pública de Internet: una cuenta de Cosmos DB sin acceso público, una cuenta de almacenamiento bloqueada a subredes de red virtual específicas o una API REST privada hospedada en una máquina virtual de la misma red.

La integración de red virtual regional está disponible en los planes Flex Consumption, Elastic Premium y Dedicated y es la configuración recomendada para la mayoría de los escenarios. La aplicación de funciones y la red virtual deben estar en la misma región Azure. La integración usa una subred delegada, que no se puede usar para otros recursos, como máquinas virtuales o puntos de conexión privados.

Importante

La integración con la red virtual, por sí sola, no dirige todo el tráfico saliente a través de la red virtual. De forma predeterminada, solo el tráfico destinado a intervalos de direcciones IP privadas (RFC 1918) se enruta a través de la subred de integración. Para forzar todo el tráfico saliente, incluidas las llamadas a direcciones públicas de Internet, a través de la red virtual, establezca la configuración de la aplicación WEBSITE_VNET_ROUTE_ALL en 1, o habilite Enrutar todo el tráfico en la pantalla de configuración de la integración con la red virtual.

Configuración de CORS para clientes basados en explorador

El uso compartido de recursos entre orígenes (CORS) se aplica cuando las aplicaciones web basadas en explorador llaman directamente a aplicaciones de funciones desencadenadas por HTTP. De forma predeterminada, los exploradores bloquean las solicitudes entre orígenes. Azure Functions permite configurar qué orígenes pueden realizar esas solicitudes.

En producción, especifique orígenes permitidos explícitos, por ejemplo, https://contoso-retail.com. Nunca use el carácter comodín (*) en producción. Una configuración de CORS con comodines permite que cualquier origen realice solicitudes a la aplicación de función, lo que elimina la protección de origen cruzado que CORS proporciona a los clientes basados en el explorador.

Las restricciones de CORS solo se aplican a los clientes HTTP basados en explorador. Las llamadas de servidor a servidor —desde servicios de back-end, servicios de Azure o clientes HTTP que no son de navegador— no están sujetas a la aplicación de CORS. CORS es un mecanismo de seguridad del explorador, no un control de acceso del lado servidor.

Hacer referencia a los secretos de Key Vault en la configuración de la aplicación

La configuración de la aplicación en Azure Functions es una de las ubicaciones más comunes en las que las cadenas de conexión y las claves de API terminan almacenadas en texto sin formato. El patrón de referencia de Key Vault reemplaza un valor de configuración de la aplicación en texto sin formato por una referencia que la aplicación de funciones resuelve en tiempo de ejecución mediante su identidad administrada.

La sintaxis de una referencia de Key Vault en una configuración de aplicación es:

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

Si omite el identificador de versión, la aplicación de funciones resuelve la versión más reciente del secreto. Esto es útil para los secretos que giran periódicamente: la función recoge el valor actualizado en un plazo de 24 horas de rotación, sin necesidad de volver a implementarlo.

Para usar referencias de Key Vault:

1. Habilite una identidad administrada asignada por el sistema en la aplicación de funciones.
2. Asigne el rol Key Vault Secrets User a la identidad administrada en el Key Vault.
3. Reemplace el valor de texto sin formato en cada configuración de aplicación por la sintaxis de referencia de @Microsoft.KeyVault(...).

La aplicación de funciones resuelve la referencia al inicio e inserta el valor secreto como valor de configuración de la aplicación. El código de función lee la configuración mediante Environment.GetEnvironmentVariable("SETTING_NAME"): la misma llamada que se usa para cualquier otra configuración de aplicación, sin reconocimiento de la capa de referencia de Key Vault.

Nota:

Si el Key Vault está configurado con restricciones de red —un punto de conexión privado o puntos de conexión de servicio de la red virtual—, la aplicación de función necesita integración con la red virtual para acceder al almacén. Configure la integración con la red virtual antes de agregar referencias a Key Vault en almacenes con acceso restringido por red. Sin una ruta de acceso de red al almacén, la aplicación de función no puede resolver la referencia y no puede iniciarse.