Implementación de controles de seguridad para aplicaciones lógicas
Los flujos de trabajo de Azure Logic Apps se enfrentan al mismo requisito de seguridad de tres niveles que las aplicaciones de Azure Functions: controlar quién puede invocar un desencadenador del flujo de trabajo, qué identidad usa el flujo de trabajo al autenticarse con conectores y qué ruta de red puede alcanzar el punto de conexión del desencadenador. Los controles disponibles y cómo los configura dependen del plan de hospedaje de Logic Apps que elija. La selección del plan es una decisión de seguridad, no solo un costo o una decisión de escala.
Elegir entre consumo y plan estándar
Los flujos de trabajo de consumo de Logic Apps se ejecutan en un entorno multiinquilino compartido administrado por Microsoft. Los flujos de trabajo estándar se ejecutan en un entorno de un solo inquilino dedicado. Esta diferencia arquitectónica tiene implicaciones de seguridad directas que afectan a los controles que se pueden aplicar.
El plan de consumo ofrece controles de red limitados. Puede configurar restricciones de IP en el punto de conexión del desencadenador y restringir el acceso al historial de ejecución, pero no se admiten la integración de red virtual y los puntos de conexión privados. Si, un flujo de trabajo de consumo debe llamar a recursos privados (un SQL Server sin acceso público o una cuenta de almacenamiento restringida a subredes de red virtual específicas, necesita servicios intermedios como Azure API Management o una puerta de enlace de datos local para salvar la brecha de red.
El plan Estándar admite el conjunto completo de controles de red disponibles en Azure App Service: integración de red virtual para llamadas de conector salientes, puntos de conexión privados para solicitudes de desencadenador entrantes y el mismo modelo de restricción de acceso usado en Azure Functions. Los flujos de trabajo del plan estándar también se ejecutan de forma aislada de los flujos de trabajo de otros inquilinos.
| Capacidad | Consumption | Estándar |
|---|---|---|
| Restricciones de IP en el desencadenador | ✔ | ✔ |
| Integración de red virtual (saliente) | ✗ | ✔ |
| Punto de conexión privado (entrante) | ✗ | ✔ |
| Aislamiento de un solo inquilino | ✗ | ✔ |
En el caso de los flujos de trabajo que controlan datos personales (datos personales), datos financieros, tokens de autenticación o llamadas a recursos privados, el plan Estándar es la opción adecuada. Las limitaciones de red del plan de consumo son una brecha de seguridad significativa para estas cargas de trabajo, no un inconveniente menor.
Uso de la identidad administrada para la autenticación del conector
Los conectores de Logic Apps usan recursos de conexión para autenticarse en servicios externos. De forma predeterminada, esos recursos de conexión almacenan credenciales (un nombre de usuario y una contraseña, una clave de API o un secreto de cliente de OAuth) que persisten en la configuración de conexión y son visibles para cualquier persona con acceso al recurso de aplicación lógica.
La autenticación de identidad administrada para conectores reemplaza las credenciales almacenadas por una identidad administrada Azure. La aplicación lógica usa su identidad administrada asignada por el sistema o asignada por el usuario para autenticarse con los servicios de Azure compatibles a través de conectores. Los conectores admitidos incluyen Azure Blob Storage, Azure Service Bus, Azure SQL Server, Azure Cosmos DB y Azure Key Vault.
Para configurar la identidad administrada para un conector:
- Habilite una identidad administrada en la aplicación lógica, vaya a Identidad y establezca la identidad asignada por el sistema en Activado o configure una identidad asignada por el usuario.
- Al agregar o editar una acción de conector en el diseñador de flujo de trabajo, seleccione Identidad administrada como tipo de autenticación.
- Asigne a la identidad administrada el rol adecuado en el recurso de destino( por ejemplo, Storage Blob Data Contributor para el acceso Azure Blob Storage.
No todos los conectores de Logic Apps admiten la autenticación de identidad administrada. Antes de diseñar un flujo de trabajo en torno a este patrón, compruebe que los conectores necesarios lo admiten. En el caso de los conectores que no admiten la identidad administrada, almacene las credenciales en Azure Key Vault y haga referencia a ellas desde la configuración del recurso de conexión, en lugar de escribir credenciales directamente en la conexión.
Sugerencia
En la documentación del conector de Azure Logic Apps para cada servicio se enumeran los tipos de autenticación admitidos. Compruebe esto antes de compilar el flujo de trabajo, ya que cambiar los métodos de autenticación después de que un flujo de trabajo esté en producción requiere volver a crear las conexiones afectadas.
Restringe el acceso al disparador mediante listas de IP permitidas
Los desencadenadores de puntos de conexión para Logic Apps son puntos de conexión HTTP. Puede restringir qué direcciones IP pueden invocar un desencadenador configurando listas de direcciones IP permitidas, bloqueando todas las demás direcciones de origen antes de que se ejecute el flujo de trabajo.
Para los flujos de trabajo del plan de Consumo, configure restricciones de acceso de desencadenador en Configuración del flujo de trabajo, en Configuración del control de acceso. Especifique los intervalos IP permitidos para llamar al desencadenador. Se rechazan todas las demás direcciones IP de origen.
Para los flujos de trabajo del plan Estándar, configure restricciones de acceso en Networking> Restricciones de acceso, con la misma interfaz que Azure Functions. Puede permitir rangos de IP específicos, bloques CIDR o etiquetas de servicio de Azure.
Las reglas de etiquetas de servicio son útiles para las aplicaciones lógicas que solo controlan eventos de servicios Azure específicos. Por ejemplo, restringir el desencadenador al AzureEventGrid etiqueta de servicio significa que solo las llamadas que se originan en Azure Event Grid pueden invocar el flujo de trabajo: las solicitudes HTTP arbitrarias de otros orígenes se bloquean independientemente de la dirección URL que usen.
Configuración de puntos de conexión privados e integración de red virtual para el plan Estándar
Las aplicaciones lógicas del plan Estándar admiten el mismo punto de conexión privado y el mismo modelo de integración con red virtual que las aplicaciones de funciones Elastic Premium. Estos controles se configuran en el nivel de recurso aplicación lógica (estándar) y se aplican a todos los flujos de trabajo de ese recurso.
Un punto de conexión privado para una aplicación lógica estándar asigna al punto de conexión del desencadenador de flujo de trabajo una dirección IP privada dentro de la red virtual. Los autores de llamadas externos no pueden acceder a la dirección URL del desencadenador desde la red pública de Internet. Solo los recursos de la red virtual (o las redes conectadas a través del emparejamiento o ExpressRoute) pueden invocar el flujo de trabajo. Esta es la configuración correcta para los flujos de trabajo que procesan datos confidenciales y que solo deben ser accesibles desde sistemas internos.
La integración de red virtual para llamadas salientes permite a la aplicación lógica realizar llamadas de conector a recursos que no son accesibles públicamente. Con la integración de red virtual habilitada en una aplicación lógica estándar, las acciones del conector pueden llegar a un SQL Server sin ningún punto de conexión público, una cuenta de almacenamiento bloqueada a una subred específica o una API REST privada hospedada internamente, las mismas funcionalidades de salida disponibles para las aplicaciones de funciones de Elastic Premium.
Nota:
Los puntos de conexión privados y la integración de red virtual para Logic Apps solo están disponibles en el plan Estándar. Si su organización implementó inicialmente flujos de trabajo en el plan de consumo y más adelante identificó un requisito para el acceso a la red privada, se requiere la migración al plan Estándar, no hay ninguna ruta de actualización local entre los tipos de plan.
Protección de datos confidenciales en el historial de ejecución
Logic Apps almacena las entradas y salidas de cada acción en el historial de ejecución, que está visible en el portal de Azure. Este comportamiento predeterminado es útil para la depuración, pero para las acciones que procesan datos confidenciales (contraseñas, tokens de autenticación, datos personales o credenciales), expone esos datos a cualquier persona con acceso de lectura al recurso de aplicación lógica.
La configuración Entradas seguras y Salidas seguras en acciones individuales ofusca los valores almacenados en el historial de ejecución. Cuando está habilitado, el portal se muestra [Redacted] en lugar del contenido real. El flujo de trabajo sigue procesando los datos en tiempo de ejecución; solo se ve afectado el almacenamiento de esos datos en el historial de ejecución.
Habilite entradas y salidas seguras en cualquier acción que controle:
- Tokens de autenticación o claves de API transmitidos entre pasos
- Datos personales recuperados de bases de datos o sistemas externos
- Credenciales a las que se hace referencia desde conexiones de Key Vault
- Campos confidenciales en cuerpos de solicitud o respuesta HTTP
Importante
Las entradas y salidas seguras se configuran por acción, no en el nivel de flujo de trabajo. Revise cada acción en flujos de trabajo sensibles a la seguridad individualmente y habilite ambas opciones cuando corresponda. Una acción anterior en el flujo de trabajo que procesa datos confidenciales sin salidas seguras habilitadas expone esos datos en el historial de ejecución incluso si todas las acciones de bajada están protegidas.
Requerir autenticación de OAuth 2.0 para desencadenadores HTTP (plan estándar)
Los flujos de trabajo de la aplicación lógica del plan Estándar admiten la validación de tokens de OAuth 2.0 en los desencadenadores HTTP mediante Microsoft Entra ID. Cuando se configura, el desencadenador requiere un token de acceso de Microsoft Entra válido antes de que se inicie el flujo de trabajo, el mismo modelo de cumplimiento que EasyAuth en las aplicaciones de funciones.
Para habilitar OAuth 2.0 en un desencadenador HTTP de plan estándar, configure una directiva de autorización en el desencadenador. Agregue una directiva de autorización de Microsoft Entra ID que especifique el público permitido (el identificador de aplicación (cliente) del registro de la aplicación y el inquilino necesario. Las solicitudes sin un token de portador válido que coincida con la directiva se rechazan antes de que se ejecute cualquier acción de flujo de trabajo.
Esta configuración es valiosa para los flujos de trabajo de plan Estándar expuestos como puntos de conexión de API a los que solo se debe llamar mediante aplicaciones o identidades registradas Microsoft Entra específicas. Al combinar la configuración con restricciones de IP o un punto de conexión privado, la validación de tokens de OAuth 2.0 en el desencadenador crea dos barreras de autenticación independientes.