Protección de Azure Functions
En muchos sentidos, la planeación del desarrollo, la implementación y el funcionamiento seguros de las funciones sin servidor es muy similar a la de cualquier aplicación hospedada en la nube o basada en web. Azure App Service proporciona la infraestructura de hospedaje para las aplicaciones de funciones. En este artículo se proporcionan estrategias de seguridad para ejecutar el código de función y cómo App Service puede facilitar la protección de las funciones.
Los componentes de plataforma de App Service, incluidas las máquinas virtuales de Azure, el almacenamiento, las conexiones de red, las plataformas web y las características de administración e integración se protegen y refuerzan activamente. App Service realiza exhaustivas comprobaciones de cumplimiento de forma continua para asegurarse de que:
- Los recursos de aplicación estén protegidos de los recursos de Azure de otros clientes.
- Las instancias de máquina virtual y el software en tiempo de ejecución se actualicen periódicamente para abordar puntos vulnerables recién detectados.
- La comunicación de secretos (por ejemplo, cadenas de conexión) entre su aplicación y otros recursos de Azure (por ejemplo, SQL Database) permanezca dentro de Azure y no cruce ningún límite de la red. Los secretos siempre se cifren al guardarlos.
- Todas las comunicaciones que se realicen con las características de conectividad de App Service, como la conexión híbrida, se cifren.
- Todas las conexiones con herramientas de administración remota como Azure PowerShell, la CLI de Azure, los SDK de Azure o las API REST, se cifren.
- La administración ininterrumpida de amenazas proteja la infraestructura y la plataforma frente a malware, ataques por denegación de servicio distribuido (DDoS), ataques de tipo "Man in the middle" (MITM) y otras amenazas.
Para más información sobre la seguridad de la infraestructura y la plataforma en Azure, consulte Centro de confianza de Microsoft Azure.
Para obtener un conjunto de recomendaciones de seguridad que siguen Azure Cloud Security Benchmark, consulte Base de referencia de seguridad de Azure para Azure Functions.
Operación segura
Esta sección le guía en la configuración y ejecución de la aplicación de funciones de la manera más segura posible.
Defender para la nube
Defender para la nube se integra con la aplicación de funciones en el portal. Proporciona, de forma gratuita, una evaluación rápida de posibles vulnerabilidades de seguridad relacionadas con la configuración. Las aplicaciones de funciones que se ejecutan en un plan dedicado también pueden usar las características de seguridad mejoradas de Defender para la nube con un costo adicional. Para obtener más información, vea Protección de las aplicaciones web y API de Azure App Service.
Registro y supervisión
Una forma de detectar ataques es a través de la supervisión de actividades y el análisis del registro. Functions se integra con Application Insights para recopilar datos de registro, rendimiento y errores para la aplicación de funciones. Application Insights detecta automáticamente anomalías en el rendimiento e incluye herramientas de análisis eficaces que ayudan a diagnosticar problemas y comprender cómo se usan las funciones. Para más información, consulte Supervisión de Azure Functions.
Functions también se integra con los registros de Azure Monitor para que pueda consolidar los registros de la aplicación de funciones con eventos del sistema para facilitar el análisis. Puede usar la configuración de diagnóstico para configurar la exportación de streaming de registros y métricas de la plataforma para las funciones al destino que elija, como un área de trabajo de Log Analytics. Para obtener más información, vea Supervisión de Azure Functions con registros de Azure Monitor.
En el caso de la detección de amenazas de nivel empresarial y la automatización de respuestas, transmita los registros y eventos a un área de trabajo de Logs Analytics. Después, puede conectar Microsoft Sentinel a esta área de trabajo. Para obtener más información, vea ¿Qué es Microsoft Sentinel?
Para obtener más recomendaciones de seguridad para la observación, vea la Base de referencia de seguridad de Azure para Azure Functions.
Requerir HTTPS
De forma predeterminada, los clientes se pueden conectar a puntos de conexión de función mediante HTTP o HTTPS. Debe redirigir HTTP a HTTPs porque HTTPS usa el protocolo SSL/TLS para proporcionar una conexión segura, que está tanto cifrada como autenticada. Para obtener información sobre cómo hacerlo, vea Aplicación de HTTPS.
Cuando requiera HTTPS, también debe requerir la versión más reciente de TLS. Para obtener información sobre cómo hacerlo, vea Exigencia de las versiones TLS.
Para obtener más información, consulte Conexiones seguras (TSL).
Claves de acceso de función
Functions permite usar claves para dificultar el acceso a los puntos de conexión de función HTTP durante el desarrollo. A menos que el nivel de acceso HTTP en una función desencadenada por HTTP se establezca en anonymous, las solicitudes deben incluir una clave de acceso de API.
Aunque las claves proporcionan un mecanismo de seguridad predeterminado, podría plantearse la posibilidad de otras opciones para proteger un punto de conexión HTTP en producción. Por ejemplo, no es recomendable distribuir un secreto compartido en las aplicaciones públicas. Si se llama a la función desde un cliente público, puede que sea conveniente implementar otro mecanismo de seguridad. Para obtener más información, vea Proteger un punto de conexión HTTP en producción.
Al renovar los valores de la clave de función, debe redistribuir manualmente los valores de clave actualizados a todos los clientes que llaman a la función.
Ámbitos de autorización (nivel de función)
Hay dos ámbitos de acceso para las claves de nivel de función:
Función: estas claves se aplican solo a las funciones específicas en las que se definen. Cuando se usan como una clave de API, solo permiten el acceso a esa función.
Host: las claves con un ámbito de host se pueden usar para acceder a todas las funciones dentro de la aplicación de función. Cuando se usan como una clave de API, permiten el acceso a cualquier función dentro de la aplicación de función.
Para cada clave se usa un nombre fácilmente referenciable y hay una clave predeterminada (denominada "predeterminada") en el nivel de función y host. Las claves de función tienen prioridad sobre las claves de host. Si se definen dos claves con el mismo nombre, siempre se usa la clave de función.
Clave maestra (nivel de administrador)
Cada aplicación de función también tiene una clave de host de nivel de administrador denominada _master. Además de proporcionar acceso de nivel de host a todas las funciones de la aplicación, la clave maestra también proporciona acceso administrativo a las API REST del entorno de ejecución. No se puede revocar esta clave. Al establecer un nivel de acceso admin, las solicitudes deben usar la clave maestra; cualquier otra clave da lugar a un error de acceso.
Precaución
Debido a los permisos elevados de la aplicación de funciones otorgados por la clave maestra, no debe compartir esta clave con terceros ni distribuirla en aplicaciones cliente nativas. Tenga cuidado al elegir el nivel de acceso de administrador.
Clave del sistema
Las extensiones específicas pueden requerir una clave administrada por el sistema para acceder a los puntos de conexión de webhook. Las claves del sistema están diseñadas para puntos de conexión de función específicos de la extensión que llaman los componentes internos. Por ejemplo, el desencadenador Event Grid requiere que la suscripción use una clave del sistema cuando se llama al punto de conexión del desencadenador. Durable Functions también usa claves del sistema para llamar a las API de extensión de Durable Task.
El ámbito de las claves del sistema viene determinado por la extensión, pero generalmente se aplica a toda la aplicación de funciones. Las claves del sistema solo se pueden crear mediante extensiones específicas y sus valores no se pueden establecer de forma explícita. Como sucede con otras claves, puede generar un valor nuevo para la clave desde el portal o mediante las API de clave.
Comparación de claves
En la tabla siguiente se comparan los usos de los distintos tipos de claves de acceso:
| Acción | Ámbito | Claves válidas |
|---|---|---|
| Ejecutar una función | Función específica | Función |
| Ejecutar una función | Cualquier función | Función o host |
| Llamada a un punto de conexión de administración | Aplicación de función | Host (solo maestro) |
| Llamada a las API de extensión de Durable Task | Aplicación de funciones1 | Sistema2 |
| Llamada a un webhook específico de la extensión (interna) | Aplicación de funciones1 | Sistema2 |
1Ámbito determinado por la extensión.
2Nombres específicos establecidos por la extensión.
Para obtener más información sobre las claves de acceso, vea el artículo sobre enlace de desencadenadores HTTP.
Repositorios secretos
De forma predeterminada, las claves se almacenan en un contenedor de Blob Storage en la cuenta proporcionada por el valor AzureWebJobsStorage. Puede usar el valor AzureWebJobsSecretStorageType para invalidar este comportamiento y almacenar las claves en una ubicación distinta.
| Location | Value | Descripción |
|---|---|---|
| Segunda cuenta de almacenamiento | blob |
Almacena las claves en el almacenamiento Blob de una cuenta de almacenamiento distinta según la URL SAS en AzureWebJobsSecretStorageSas. |
| Sistema de archivos | files |
Las claves se conservan en el sistema de archivos, que es el valor predeterminado en Functions v1.x. |
| Azure Key Vault | keyvault |
El almacén de claves establecido en AzureWebJobsSecretStorageKeyVaultUri se usa para almacenar claves. |
| Secretos de Kubernetes | kubernetes |
El recurso establecido en AzureWebJobsKubernetesSecretName se usa para almacenar claves. Solo se admite cuando se ejecuta el entorno en tiempo de ejecución de Functions en Kubernetes. Azure Functions Core Tools genera automáticamente los valores al implementar en Kubernetes. |
Al usar Key Vault para el almacenamiento de claves, la configuración de la aplicación que necesita depende del tipo de identidad administrada. La versión 3.x del entorno de ejecución de Functions solo admite identidades administradas asignadas por el sistema.
| Nombre del valor | Asignada por el sistema | Asignada por el usuario | Registro de aplicación |
|---|---|---|---|
| AzureWebJobsSecretStorageKeyVaultUri | ✓ | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientId | X | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientSecret | X | X | ✓ |
| AzureWebJobsSecretStorageKeyVaultTenantId | X | X | ✓ |
Autenticación y autorización
Aunque las claves de función pueden proporcionar cierta mitigación del acceso no deseado, la única manera de proteger realmente los puntos de conexión de la función es mediante la implementación de la autenticación positiva de los clientes que acceden a las funciones. Después, puede tomar decisiones de autorización en función de la identidad.
Habilitación de la autenticación o la autorización de App Service
La plataforma App Service le permite usar Microsoft Entra ID y varios proveedores de identidades de terceros para autenticar a los clientes. Se puede usar esta estrategia para implementar reglas de autorización personalizadas para las funciones y permite trabajar con información de usuario desde el código de función. Para obtener más información, vea Autenticación y autorización en Azure App Service y Uso de identidades de cliente.
Uso de Azure API Management (APIM) para autenticar solicitudes
APIM proporciona una serie de opciones de seguridad de API para las solicitudes entrantes. Para obtener más información, vea Directivas de autenticación de Azure API Management. Con APIM, puede configurar la aplicación de función de modo que solo acepte solicitudes de la dirección IP de la instancia de APIM. Para obtener más información, vea Restricciones de las direcciones IP.
Permisos
Como sucede con cualquier aplicación o servicio, el objetivo es ejecutar la aplicación de funciones con los mínimos permisos posibles.
Permisos de administración de usuarios
Functions admite el control de acceso basado en rol de Azure (Azure RBAC) integrado. Los roles de Azure que admite Functions son Colaborador, Propietario y Lector.
Los permisos son eficaces en el nivel de la aplicación de funciones. El rol Colaborador es necesario para realizar la mayoría de las tareas de nivel de la aplicación de funciones. También necesita el rol Colaborador junto con el permiso Lector de supervisión para poder ver los datos de registro en Application Insights. Solo el rol Propietario puede eliminar una aplicación de funciones.
Organización de funciones por privilegio
Las cadenas de conexión y otras credenciales almacenadas en la configuración de la aplicación proporcionan a todas las funciones de la aplicación de funciones el mismo conjunto de permisos en el recurso asociado. Considere la posibilidad de minimizar el número de funciones con acceso a credenciales específicas moviendo las funciones que no las utilizan a una aplicación de funciones independiente. Siempre puede usar técnicas como el encadenamiento de funciones para pasar datos entre funciones de diferentes aplicaciones de funciones.
Identidades administradas
Una identidad administrada de Microsoft Entra ID permite a la aplicación acceder fácilmente a otros recursos protegidos por Microsoft Entra, como Azure Key Vault. La identidad está administrada por la plataforma Azure y no requiere que aprovisione o rote los secretos. Para obtener más información sobre las identidades administradas en Microsoft Entra ID, consulte Identidades administradas para recursos de Azure.
La aplicación puede tener dos tipos de identidades:
- Una identidad asignada por el sistema está asociada a la aplicación y se elimina si se elimina la aplicación. Una aplicación solo puede tener una identidad asignada por el sistema.
- Una identidad asignada por el usuario es un recurso de Azure independiente que puede asignarse a la aplicación. Una aplicación puede tener varias identidades asignadas por el usuario.
Se pueden usar identidades administradas en lugar de secretos para las conexiones desde algunos desencadenadores y enlaces. Consulte Conexiones basadas en identidades.
Para obtener más información, vea Procedimiento para usar identidades administradas para App Service y Azure Functions.
Restricción del acceso a CORS
Uso compartido de recursos entre orígenes (CORS) es una manera de permitir que las aplicaciones web que se ejecutan en otro dominio realicen solicitudes a los puntos de conexión del desencadenador HTTP. App Service proporciona compatibilidad integrada para entregar los encabezados de CORS necesarios en las solicitudes HTTP. Las reglas de CORS se definen en el nivel de la aplicación de funciones.
Aunque es tentador usar un carácter comodín que permita que todos los sitios accedan al punto de conexión, esto iría en contra del propósito de CORS, que es ayudar a evitar ataques de scripting entre sitios. En su lugar, agregue una entrada de CORS independiente para el dominio de cada aplicación web que tenga que acceder al punto de conexión.
Administración de secretos
Para poder conectarse a los diversos servicios y recursos necesarios para ejecutar el código, las aplicaciones de funciones deben poder acceder a secretos, como cadenas de conexión y claves de servicio. En esta sección se describe cómo almacenar los secretos requeridos por las funciones.
Nunca almacene los secretos en el código de función.
Configuración de la aplicación
De forma predeterminada, las cadenas de conexión y los secretos que usa la aplicación de funciones y los enlaces se almacenan como configuración de la aplicación. Esto hace que estas credenciales estén disponibles tanto para el código de función como para los distintos enlaces que usa la función. El nombre de la configuración de la aplicación (clave) se usa para recuperar el valor real, que es el secreto.
Por ejemplo, todas las aplicaciones de funciones requieren una cuenta de almacenamiento asociada, que la usa por el tiempo de ejecución. De forma predeterminada, la conexión a esta cuenta de almacenamiento se almacena en una configuración de aplicación denominada AzureWebJobsStorage.
La configuración de la aplicación y las cadenas de conexión se almacenan cifradas en Azure. Solo se descifran antes de insertarlas en la memoria de proceso de la aplicación cuando se inicia la aplicación. Las claves de cifrado rotan con regularidad. Si en su lugar prefiere administrar el almacenamiento seguro de los secretos, la configuración de la aplicación debe ser referencias a Azure Key Vault.
También puede cifrar la configuración de forma predeterminada en el archivo local.settings.json al desarrollar funciones en el equipo local. Para obtener más información, vea Cifrar el archivo de configuración local.
Referencias de Key Vault
Aunque la configuración de la aplicación es suficiente para la mayoría de las funciones, es posible que quiera compartir los mismos secretos entre varios servicios. En este caso, el almacenamiento redundante de los secretos genera más vulnerabilidades. Un enfoque más seguro consiste en usar un servicio de almacenamiento secreto central y utilizar referencias a este servicio en lugar de los propios secretos.
Azure Key Vault es un servicio que proporciona administración centralizada de los secretos, con control total sobre las directivas de acceso y el historial de auditoría. Puede usar una referencia de Key Vault en lugar de una cadena de conexión o clave en la configuración de la aplicación. Para obtener más información, vea Uso de referencias de Key Vault para App Service y Azure Functions.
Conexiones basadas en identidades
Se pueden usar identidades en lugar de secretos para conectarse a algunos recursos. Esta opción tiene la ventaja de que no requiere la administración de un secreto y proporciona funciones de control de acceso y auditoría más precisas.
Al escribir el código que crea la conexión a Servicios de Azure que soportan la autenticación Microsoft Entra, puede optar por usar una identidad en lugar de un secreto o cadena de conexión. Los detalles de ambos métodos de conexión se describen en la documentación de cada servicio.
Algunas extensiones de desencadenador y enlace de Azure Functions se pueden configurar mediante una conexión basada en identidades. En la actualidad, se incluyen las extensiones de Blob de Azure y Cola de Azure. Para obtener información sobre cómo configurar estas extensiones para usar una identidad, consulte Cómo usar conexiones basadas en identidades en Azure Functions.
Establecimiento de cuotas de uso
Considere la posibilidad de establecer una cuota de uso en las funciones que se ejecutan en un plan de consumo. Cuando se establece un límite diario de GB por segundo en la suma total de la ejecución de funciones en la aplicación de funciones, la ejecución se detiene cuando se alcanza el límite. Esto podría ayudar a mitigar la posibilidad de que código malintencionado ejecute las funciones. Para obtener información sobre cómo calcular el consumo de las funciones, vea Estimación de los costos según el plan de consumo.
Validación de datos
Los desencadenadores y enlaces que usan las funciones no proporcionan ninguna validación de datos adicional. El código debe validar los datos recibidos de un desencadenador o enlace de entrada. Si un servicio ascendente está en peligro, no querrá que las entradas no validadas fluyan a través de las funciones. Por ejemplo, si la función almacena datos de una cola de Azure Storage en una base de datos relacional, debe validar los datos y parametrizar los comandos para evitar ataques por inyección de código SQL.
No asuma que los datos que entran en la función ya se han validado o saneado. También es recomendable comprobar que los datos que se escriben en los enlaces de salida sean válidos.
errores
Aunque parezca básico, es importante escribir un control de errores adecuado en las funciones. Los errores no controlados se propagan al host y se controlan mediante el tiempo de ejecución. Cada enlace controla el procesamiento de errores de manera distinta. Para obtener más información, vea Control de errores de Azure Functions.
Deshabilitar la depuración remota
Asegúrese de que la depuración remota está deshabilitada, excepto cuando depure las funciones de forma activa. Puede deshabilitar la depuración remota en la pestaña Configuración general de la Configuración de la aplicación de funciones en el portal.
Restricción del acceso a CORS
Azure Functions admite el uso compartido de recursos entre orígenes (CORS). CORS se configura en el portal y mediante la CLI de Azure. La lista de orígenes permitidos de CORS se aplica en el nivel de la aplicación de función. Con CORS habilitado, las respuestas incluyen el encabezado Access-Control-Allow-Origin. Para obtener más información, consulte Uso compartido de recursos entre orígenes.
No use caracteres comodín en la lista de orígenes permitidos. En su lugar, enumere los dominios específicos de los que espera obtener solicitudes.
Almacenamiento de datos cifrados
Azure Storage cifra todos los datos de las cuentas de almacenamiento en reposo. Para más información, consulte Cifrado de Azure Storage para datos en reposo.
De manera predeterminada, los datos se cifran con claves administradas por Microsoft. Para tener un mayor control sobre las claves de cifrado, puede proporcionar claves administradas por el cliente que puede usar para el cifrado de datos de archivos y blobs. Estas claves deben estar presentes en Azure Key Vault para que Azure Functions pueda acceder a la cuenta de almacenamiento. Para más información, consulte Cifrado en reposo con claves administradas por el cliente.
Protege recursos relacionados
Una aplicación de funciones depende con frecuencia de recursos adicionales, por lo que parte de la seguridad de la aplicación consiste en proteger estos recursos externos. Como mínimo, la mayoría de las aplicaciones de funciones incluyen una dependencia de Application Insights y Azure Storage. Consulte la línea de base de seguridad de Azure para Azure Monitor y la línea de base de seguridad de Azure para Storage para obtener instrucciones sobre cómo proteger estos recursos.
Importante
La cuenta de almacenamiento se usa para almacenar datos importantes de la aplicación, a veces incluido el propio código de la aplicación. Debe limitar el acceso desde otras aplicaciones y usuarios a la cuenta de almacenamiento.
También debe consultar la guía para cualquier tipo de recurso del que dependa la lógica de su aplicación, tanto si se trata de desencadenadores y enlaces como del código de función.
Implementación segura
Las herramientas de Azure Functions para la integración facilitan la publicación local de código de proyectos de función en Azure. Es importante entender cómo funciona la implementación a la hora de considerar la seguridad de una topología de Azure Functions.
Credenciales de implementación
Las implementaciones de App Service requieren un conjunto de credenciales de implementación. Estas credenciales de implementación se usan para proteger las implementaciones de aplicaciones de funciones. Las credenciales de implementación se administran mediante la plataforma App Service y se cifran en reposo.
Hay dos tipos de credenciales de implementación:
Credenciales de nivel de usuario: un conjunto de credenciales para toda la cuenta de Azure. Se puede utilizar para implementar App Service en cualquier aplicación o suscripción para la que la cuenta de Azure tenga permiso de acceso. Este es también el conjunto predeterminado que aparece en la interfaz gráfica de usuario del portal (como la información general y las propiedades de la página de recursos de la aplicación). Cuando a un usuario se le otorga acceso a la aplicación a través del Control de acceso basado en rol (RBAC) o mediante permisos de coadministrador, ese usuario puede usar sus propias credenciales de nivel de usuario hasta que se le revoque el acceso. No comparta estas credenciales con otros usuarios de Azure.
Credenciales de nivel de aplicación: un conjunto de credenciales para cada aplicación. Se puede utilizar para implementar únicamente en esa aplicación. Las credenciales de cada aplicación se generan automáticamente cuando se crea la aplicación. Recuerde que no se pueden configurar manualmente, pero se pueden restablecer en cualquier momento. Para que un usuario obtenga acceso a las credenciales de nivel de aplicación a través del control de acceso basado en rol, ese usuario debe ser un colaborador o tener un rol superior en la aplicación (incluido el rol integrado de colaborador de sitio web). A los lectores no se les permite publicar contenido y no pueden obtener acceso a dichas credenciales.
En este momento, no se admite Key Vault para las credenciales de implementación. Para obtener más información sobre la administración de credenciales de implementación, vea Configuración de credenciales de implementación para Azure App Service.
Deshabilitación de FTP
De forma predeterminada, cada aplicación de funciones tiene un punto de conexión FTP habilitado. Para acceder al punto de conexión FTP se usan credenciales de implementación.
No se recomienda FTP para implementar el código de función. Las implementaciones de FTP son manuales y requieren la sincronización de los desencadenadores. Para obtener más información, vea Implementación de FTP.
Si no tiene previsto usar FTP, debe deshabilitarlo en el portal. Si decide usar FTP, debe aplicar FTPS.
Protección del punto de conexión scm
Todas las aplicaciones de funciones tienen un punto de conexión de servicio scm correspondiente que usa el servicio de herramientas avanzadas (Kudu) para las implementaciones y otras scm de App Service. El punto de conexión scm para una aplicación de funciones siempre es una dirección URL con el formato https://<FUNCTION_APP_NAME.scm.azurewebsites.net>. Cuando se usa el aislamiento de red para proteger las funciones, también debe tener en cuenta este punto de conexión.
Al tener un punto de conexión scm independiente, puede controlar las implementaciones y otras funcionalidades de herramientas avanzadas para la aplicación de funciones que están aisladas o se ejecutan en una red virtual. El punto de conexión scm admite la autenticación básica (con credenciales de implementación) y el inicio de sesión único con las credenciales de Azure Portal. Para obtener más información, vea Acceso al servicio Kudu.
Validación continua de la seguridad
Como en todos los pasos del proceso de desarrollo se debe tener en cuenta la seguridad, también tiene sentido implementar validaciones de seguridad en un entorno de implementación continua. Esto se denomina en ocasiones DevSecOps. Al usar Azure DevOps para la canalización de implementación se puede integrar la validación en el proceso de implementación. Para obtener más información, vea Incorporación de un mecanismo continuo para validar la seguridad en la canalización de CI/CD.
Seguridad de las redes
La restricción del acceso de red a la aplicación de funciones permite controlar quién puede acceder a los puntos de conexión de las funciones. Functions aprovecha la infraestructura de App Service para permitir que las funciones accedan a los recursos sin usar direcciones enrutables por Internet o para restringir el acceso a Internet a un punto de conexión de función. Para obtener más información sobre estas opciones de red, vea Opciones de redes de Azure Functions.
Establecimiento de restricciones de acceso
Las restricciones de acceso permiten definir listas de reglas de permiso y denegación para controlar el tráfico a la aplicación. Las reglas se evalúan en orden de prioridad. Si no se define ninguna regla, la aplicación aceptará el tráfico de cualquier dirección. Para obtener más información, vea Restricciones de acceso de Azure App Service.
Seguridad de la cuenta de almacenamiento
Al crear una aplicación de funciones, debe crear una cuenta de Azure Storage de uso general compatible con Blob, Queue y Table Storage, o vincular a una. Puede reemplazar esta cuenta de almacenamiento por una que esté protegida con puntos de conexión de servicio o puntos de conexión privados. Para obtener más información, consulte Restricción de la cuenta de almacenamiento a una red virtual.
El acceso privado a sitios
Un punto de conexión privado de Azure es una interfaz de red que nos conecta de forma privada y segura a un servicio por medio de la tecnología Azure Private Link. Los puntos de conexión privados emplean una dirección IP privada de la red virtual, lo que hace que el servicio se incluya en la red virtual.
Puede usar el punto de conexión privado para las funciones hospedadas en los planes Premium y App Service.
Si quiere realizar llamadas a los puntos de conexión privados, debe asegurarse de que las búsquedas de DNS se resuelvan en el punto de conexión privado. Puede aplicar este comportamiento de una de las siguientes formas:
- Realizar la integración con zonas privadas de Azure DNS. Cuando la red virtual no tiene un servidor DNS personalizado, esto se hace automáticamente.
- Administrar el punto de conexión privado en el servidor DNS que usa la aplicación. Para ello, debe conocer la dirección del punto de conexión privado y, a continuación, apuntar el punto de conexión al que está intentando acceder a esa dirección con un registro A.
- Configurar su propio servidor DNS para reenviarlo a zonas privadas de Azure DNS.
Para más información, consulte cómo usar puntos de conexión privados para aplicaciones web.
Implementación de la aplicación de funciones en aislamiento
Azure App Service Environment (ASE) proporciona un entorno de hospedaje dedicado en el que ejecutar las funciones. ASE le permite configurar una puerta de enlace de front-end única que se puede usar para autenticar todas las solicitudes entrantes. Para obtener más información, vea Configuración de un firewall de aplicaciones web (WAF) para entornos de App Service.
Uso de un servicio de puerta de enlace
Los servicios de puerta de enlace, como Azure Application Gateway y Azure Front Door permiten configurar un firewall de aplicaciones web (WAF). Las reglas de WAF se usan para supervisar o bloquear los ataques detectados, lo que proporciona una capa de protección adicional para las funciones. Para configurar un firewall de aplicaciones web, la aplicación de funciones debe estar en ejecución en un ASE o usar puntos de conexión privados (versión preliminar). Para obtener más información, vea Uso de puntos de conexión privados.