Configuración de la autenticación y autorización para aplicaciones de funciones
Una aplicación de funciones expuesta como un punto de conexión HTTP sin autenticación es directamente accesible para cualquier cliente que detecte la dirección URL. Azure Functions no aplica la autenticación de forma predeterminada: la plataforma confía en la aplicación para implementarla. Para las funciones de procesamiento de pedidos de Contoso Retail, que reciben llamadas entrantes de sistemas asociados externos, ese valor predeterminado es el punto inicial incorrecto.
Descripción de la autenticación de Azure App Service
La autenticación de Azure App Service, comúnmente llamada EasyAuth, es un middleware de autenticación incorporado que se ejecuta como un componente independiente en la misma plataforma que la aplicación de funciones. Cuando está habilitada, cada solicitud HTTP entrante pasa por la capa de autenticación antes de que se ejecute el código de función. EasyAuth valida los tokens, administra las sesiones autenticadas e inserta información de identidad en los encabezados de solicitud. No es necesario agregar bibliotecas de autenticación al código de función ni modificar ninguna lógica de función.
EasyAuth admite varios proveedores de identidades: Microsoft Entra ID, Facebook, Google, X, GitHub y cualquier proveedor compatible con OpenID Connect. En el caso de las cargas de trabajo empresariales, Microsoft Entra ID es la opción correcta. Al configurar Microsoft Entra como proveedor, EasyAuth valida el token de acceso en cada solicitud con tu inquilino; cualquier solicitud sin un token válido se bloquea en la capa de middleware.
Nota:
Al habilitar EasyAuth, se redirigen automáticamente todas las solicitudes entrantes a HTTPS, independientemente de la configuración de cumplimiento de HTTPS existente de la aplicación de funciones. Los tokens de autenticación nunca se transmiten a través de conexiones HTTP sin cifrar.
Configuración de Microsoft Entra ID como proveedor de identidades
Para configurar la autenticación Microsoft Entra ID, vaya a Authentication en la pantalla de configuración de la aplicación de funciones y agregue Microsoft Entra ID como proveedor de identidades. Azure admite dos modos de configuración:
- Configuración rápida: Azure crea automáticamente un nuevo registro de aplicaciones en el inquilino de Microsoft Entra asociado a su suscripción. Esta es la vía más rápida para implementaciones desde cero en las que no se requiere ningún registro previo. El registro tiene como ámbito la aplicación de función y se configura automáticamente con los URI de redireccionamiento correctos.
- Configuración avanzada: proporcionas un registro de aplicaciones existente: el identificador de aplicación (cliente) y la URL del emisor (el punto de conexión del tenant de Microsoft Entra). Use este modo cuando el equipo de identidad administre centralmente el registro de la aplicación, cuando necesite configurar notificaciones o permisos de API específicos, o cuando la función necesite aparecer como una aplicación empresarial conocida en el directorio.
Una vez configurado el proveedor de identidades, EasyAuth aplica la autenticación según la opción Acción que se debe realizar cuando la solicitud no está autenticada :
- Require authentication: cualquier solicitud sin un token de portador Microsoft Entra válido se rechaza con una respuesta 401 o se redirige a la página de inicio de sesión del proveedor de identidades. El código de función nunca se ejecuta para solicitudes no autenticadas. Esta es la configuración correcta para las aplicaciones de Function que solo deberían aceptar llamadas de usuarios autenticados.
- Permitir solicitudes no autenticadas: las solicitudes pasan a la función independientemente del estado de autenticación. EasyAuth sigue validando los tokens cuando están presentes e inserta encabezados de identidad, pero no bloquea a los autores de llamadas no autenticados. Use este modo cuando la propia función controle las decisiones de autenticación, por ejemplo, cuando necesite responder de forma diferente a las solicitudes anónimas y autenticadas.
Para los desencadenadores HTTP entrantes de Contoso Retail, que solo deben aceptar llamadas de sistemas asociados que contengan un token de Microsoft Entra válido, Require authentication es la configuración correcta. No se requieren cambios en el código de función.
Importante
De forma predeterminada, cualquier usuario del inquilino de Microsoft Entra puede obtener un token para la aplicación y llamar a funciones autenticadas. Si necesita restringir el acceso a un grupo, aplicación o conjunto de usuarios específico, configure el registro de la aplicación en Microsoft Entra para requerir asignación, asígnele solo las identidades que quiera permitir.
Comprender los niveles de autorización de las funciones
Además de EasyAuth, Azure Functions incluye su propio mecanismo de autorización ligero: niveles de autorización de función. Este mecanismo usa claves de API para controlar el acceso a los puntos de conexión de funciones y funciona independientemente de EasyAuth.
Los niveles de autorización se establecen por función o en el nivel de aplicación de funciones:
- Anónimo: no se requiere ninguna clave de API. Cualquier llamador puede invocar la función sin una clave. Use este nivel solo cuando EasyAuth o una puerta de enlace ascendente protejan el punto de conexión: una función anónima sin capa de autenticación ascendente es un punto de conexión HTTP totalmente abierto.
- Función: requiere una clave específica de esa función individual. Cada función de la aplicación puede tener su propio conjunto de claves. Quien tiene la clave de una función no puede invocar otras funciones de la misma aplicación.
- Host: requiere la clave de host, que se comparte entre todas las funciones de la aplicación de funciones. Una entidad que llama con la clave del host puede invocar cualquier función de la aplicación. La clave de host también se denomina clave de administrador cuando se usa para las operaciones administrativas.
Las claves de función no son un sustituto de la autenticación basada en identidades. Las claves de API son cadenas estáticas que se pueden extraer del código o la configuración y compartir accidentalmente. En el caso de las aplicaciones de función de producción en las que EasyAuth está configurado con Microsoft Entra ID, los niveles de autorización de función proporcionan defensa en profundidad, una capa secundaria que requiere que el autor de la llamada presente una clave válida y un token de identidad válido.
Importante
No use el nivel de autorización anónimo sin una capa de autenticación ascendente, como EasyAuth o Azure API Management. Una función anónima sin protección es un punto de conexión HTTP totalmente abierto en la red pública de Internet.
Asignación de una identidad administrada para las conexiones salientes
La segunda laguna de Contoso Retail —las cadenas de conexión de Cosmos DB almacenadas como valores de configuración de aplicación en texto sin formato— es un problema de administración de credenciales. La configuración de la aplicación en una aplicación de funciones es visible para cualquier persona con acceso de lectura a la pantalla de configuración de App Service. Una cadena de conexión en texto sin formato en una configuración de la aplicación constituye una vía directa desde el acceso a la configuración de la aplicación de funciones hasta el acceso completo a la base de datos de destino.
Las identidades administradas resuelven esto al proporcionar a la aplicación de funciones una identidad de Microsoft Entra ID que Azure administra automáticamente. La aplicación de funciones se autentica con los servicios posteriores de Azure mediante esta identidad, sin necesidad de cadena de conexión y sin credenciales que almacenar, renovar o exponer accidentalmente.
Para habilitar una identidad administrada asignada por el sistema, vaya a Identidad en la configuración de la aplicación de funciones y establezca Estado en Activado. Azure crea una entidad de servicio para la aplicación de funciones en el inquilino de Microsoft Entra. A continuación, asigne a esa entidad de servicio el rol adecuado en cada recurso de bajada:
| Servicio descendente | Rol recomendado |
|---|---|
| Azure Cosmos DB (la base de datos de Azure Cosmos) | Colaborador de datos integrado de Cosmos DB |
| Azure Service Bus (Autobús de Servicio de Azure) | remitente de datos de Service Bus o receptor de datos de Service Bus |
| Azure Storage | Colaborador de datos de Storage Blob o Colaborador de datos de cola de almacenamiento |
| Azure Key Vault | Usuario de secretos de Key Vault |
| Azure OpenAI | Usuario de OpenAI de Cognitive Services |
Nota:
Las Function Apps actúan cada vez más como orquestadores de agentes de IA, coordinando llamadas a modelos de Azure OpenAI, puntos de conexión de Fundición de IA de Azure o implementaciones personalizadas de prompt flow. Cuando una aplicación de Functions llama a un punto de conexión de Azure OpenAI, la identidad administrada con el rol Cognitive Services OpenAI User es el método de autenticación correcto. Esto elimina el almacenamiento de claves de API en la configuración de la aplicación y garantiza que el acceso al punto de conexión del modelo se controle y audite a través de Azure RBAC.
Con la identidad administrada habilitada y los roles asignados, actualice cada llamada a un servicio posterior en el código de la función para usar DefaultAzureCredential del SDK Azure Identity en lugar de una cadena de conexión. La credencial recoge automáticamente la identidad administrada de la aplicación de funciones en tiempo de ejecución. Para las configuraciones de desencadenadores y enlaces que hacen referencia a servicios de Azure —cuentas de almacenamiento para desencadenadores de cola y Service Bus para desencadenadores de tema—, la propiedad de conexión en la configuración de la función también admite el uso de identidades administradas mediante conexiones basadas en identidades, en lugar de valores de cadena de conexión.