Políticas de acceso en conexiones Azure Logic Apps

En pocas palabras: Las API Connection Access Policies son un recurso ARM en Azure Logic Apps Standard que autorizan qué Managed Identity puede usar una conexión managed compartida (recurso Microsoft.Web/connections). Azure valida el token de identidad administrada a nivel Resource Manager antes de permitir la llamada al conector.

Si administrás varias Logic Apps en el mismo grupo de recursos de Azure, tarde o temprano vas a compartir una conexión: un Office 365, un gateway on-premises, un SFTP. Las políticas de acceso a conexiones Azure Logic Apps te dejan provisionar esa conexión una sola vez y decidir, a nivel ARM, qué Logic App puede usarla.

¿Qué es una conexión managed y por qué necesitás controlar su acceso?

Una conexión managed es un recurso ARM completo (Microsoft.Web/connections) que vive en tu grupo de recursos y sirve para que una Logic App hable con servicios como Office 365, SFTP o un filesystem on-premises vía OAuth o Managed Identity. Es distinta de la service provider connection, que se configura por app settings con un connection string. Esa diferencia es la que manda todo lo demás.

Ponele que tenés cinco Logic Apps en el mismo resource group, cada una con su dominio de integración: una factura, otra sincroniza contactos, otra manda mails. Todas necesitan el mismo Office 365. Acá aparecen dos tensiones al mismo tiempo. No querés que la Logic App de facturación pueda usar una conexión pensada solo para RR. HH., pero tampoco querés provisionar cinco copias del mismo Office 365, porque eso duplica infraestructura y te dobla el mantenimiento cada vez que rota un secreto. Esto se conecta con lo que analizamos en nuestra comparativa de plataformas Microsoft.

La respuesta es provisionar la conexión una vez y controlar quién se autentica. Eso son las políticas de acceso.

Aspecto	Managed API connection	Service provider connection
Recurso ARM	Sí (Microsoft.Web/connections)	No (se define en app settings)
Ejemplos	Office 365, SFTP, filesystem on-premises	Service Bus, Azure Blob, FTP
Autenticación	OAuth / Managed Identity vía ARM	Connection string o credencial
Control de acceso	Políticas de acceso a nivel ARM	Depende del secreto en la config

¿Cómo funcionan las políticas de acceso conexiones Azure Logic Apps a nivel ARM?

Funcionan validando identidad en tiempo de ejecución. Cuando una Logic App Standard llama a un conector managed, presenta el token de Managed Identity de su app service, y ARM chequea si esa identidad figura en la política de acceso de la conexión. Si está, pasa. Si no está, corta. Todo esto ocurre antes de que la request toque el endpoint real de Office 365 o del SFTP.

El flujo, en criollo, es este: la Logic App se identifica con su Managed Identity, ARM mira la política de acceso de la conexión compartida, y devuelve permitido o denegado. No hay clave que copiar ni regla de firewall que abrir. El control es puro plano de gestión de Azure Resource Manager. Sobre eso hablamos en riesgos documentados en herramientas Microsoft.

¿Por qué importa que sea a nivel ARM y no de red? Porque podés revocar el acceso de una Logic App sin tocar la conexión ni cortarle el servicio a las otras. Sacás la identidad de la política y listo.

¿Qué diferencia hay entre identidad asignada por sistema y por usuario?

La identidad asignada por sistema (system-assigned) se crea y se borra junto con la Logic App: una por recurso, atada a su ciclo de vida. La asignada por usuario (user-assigned) es un recurso aparte que creás una vez y reutilizás entre varios recursos. Para compartir una conexión entre tres Logic Apps, la user-assigned suele ser más limpia, según la documentación oficial de Microsoft Learn.

• System-assigned: automática, cero mantenimiento, pero única por Logic App. Si borrás la app, se va la identidad. Buena para casos simples y aislados.
• User-assigned: la creás vos, la asignás a las Logic Apps que quieras y las metés todas en la misma política de acceso. Ideal para auditar y para compartir sin repetir configuración.

El caso de uso que se repite: una sola user-assigned identity para el grupo de Logic Apps de un mismo dominio, y esa identidad en la política de la conexión compartida. Un solo lugar donde mirar quién tiene acceso.

Ejemplo práctico: una conexión Office 365 entre 3 Logic Apps

El objetivo es concreto: tres Logic Apps usando el mismo Office 365 sin credenciales duplicadas. Se hace en cuatro pasos, provisionando la conexión una sola vez y agregando las identidades a su política de acceso a nivel ARM. Complementá con pipelines modernos de integración continua.

• Creá la conexión Office 365 una vez como recurso Microsoft.Web/connections en el resource group.
• Asigná Managed Identity a cada Logic App (o una misma user-assigned a las tres, que es lo recomendable para auditar).
• Agregá esas identidades a la política de acceso de la conexión, a nivel ARM.
• Configurá la conexión para autenticarse con Managed Identity en vez de guardar credenciales en cada app.

Resultado: las tres Logic Apps comparten el mismo Office 365, ninguna guarda un secreto, y si mañana querés sacarle acceso a una, la borrás de la política sin tocar a las otras dos. El mismo patrón te sirve para un SFTP compartido o una base de datos on-premises detrás del gateway.

¿Cómo usar el gateway de datos local de forma segura al compartir conexiones?

El gateway de datos local (on-premises data gateway) te deja que varias Logic Apps lleguen a un recurso interno, como un SFTP o una base de datos, a través de una sola conexión managed. La seguridad se apoya en tres cosas: cifrado de datos en tránsito, autenticación vía Microsoft Entra ID y secretos guardados en Azure Key Vault en lugar de hardcodeados en la app.

Acá viene lo bueno: el mismo modelo de política de acceso aplica. La conexión al gateway es una conexión managed, así que decidís por identidad qué Logic App puede autenticarse contra ella. Guardá las credenciales del recurso interno en Key Vault, referencialas desde la conexión, y evitás el clásico connection string tirado en un app setting que después nadie sabe de dónde salió. En herramientas confiables de automatización profundizamos sobre esto.

Buenas prácticas: ¿cuándo compartir una conexión y cuándo crearla aparte?

Compartí cuando varias Logic Apps del mismo dominio de integración pegan al mismo endpoint y querés bajar el mantenimiento. Creá conexiones separadas cuando necesitás distintos niveles de acceso o ciclos de vida diferentes. La regla práctica: si el día de mañana vas a querer revocar el acceso de una app sin afectar a las demás, y con la misma cuenta de servicio no podés, es señal de que van separadas.

• Usá identidad asignada por usuario para el grupo compartido: te da un único punto de auditoría y control granular.
• Aplicá mínimo privilegio: solo las identidades que de verdad necesitan la conexión entran en la política.
• No mezcles RBAC con políticas de acceso: son controles distintos y confundirlos te deja huecos.

Es el mismo criterio de mínimo privilegio que aplicás en cualquier infraestructura, sea Azure o el hosting y los dominios que tengas en donweb.com: dar acceso a lo justo y poder retirarlo sin romper el resto.

Qué está confirmado y qué no

• Confirmado: Logic Apps Standard usa managed API connections (recurso ARM) y service provider connections, según la documentación oficial de Azure.
• Confirmado: el control de acceso a conexiones compartidas se hace a nivel ARM validando el token de Managed Identity, no por red ni por clave.
• Confirmado: Azure bloquea por defecto compartir conexiones entre distintos tenants de Microsoft Entra sin configuración específica, según Microsoft Learn.
• Pendiente de tu escenario: los límites exactos de cantidad de identidades por política dependen de tu suscripción y conviene verificarlos en el portal, no darlos por sentado.

Errores comunes al compartir conexiones

• Olvidar la identidad en la política: agregás la conexión pero no metés la Managed Identity del Logic App en la política de acceso. Resultado: “permission denied” en runtime. Corrección: revisá que la identidad esté listada antes de probar.
• Confundir RBAC con políticas de acceso: darle un rol de Azure al Logic App no es lo mismo que autorizarlo en la conexión. Son dos capas distintas. Corrección: configurá la política de acceso de la conexión, no solo el RBAC del recurso.
• Duplicar conexiones “por las dudas”: creás una copia por cada Logic App y terminás con cinco Office 365 que rotan secretos en momentos distintos. Corrección: una conexión compartida más políticas de acceso.
• Compartir credenciales en vez de identidades: pegar el connection string en cada app en lugar de usar Managed Identity. Corrección: Managed Identity más Key Vault para lo que sea secreto.

Preguntas Frecuentes

¿Cómo comparto una conexión entre varias Logic Apps sin duplicarla?

Provisionás la conexión managed una sola vez en el resource group y agregás la Managed Identity de cada Logic App a la política de acceso de esa conexión, a nivel ARM. Así todas la usan sin credenciales duplicadas y sin copias de infraestructura.

¿Cuál es la diferencia entre conexión managed y service provider?

La conexión managed es un recurso ARM (Microsoft.Web/connections) que se autentica por OAuth o Managed Identity, como Office 365 o SFTP. La service provider se configura por app settings con un connection string, como Service Bus o Azure Blob. Solo las managed se controlan con políticas de acceso.

¿Qué es una identidad administrada en Logic Apps?

Es una identidad de Microsoft Entra que le permite a la Logic App autenticarse contra servicios de Azure sin guardar credenciales. Puede ser asignada por sistema (una por Logic App) o por usuario (reutilizable entre varios recursos), y es la que Azure valida en la política de acceso.

¿Cómo revoco el acceso de una Logic App a una conexión compartida?

Sacás la Managed Identity de esa Logic App de la política de acceso de la conexión, a nivel ARM. La conexión sigue funcionando para las demás apps y no necesitás rotar ningún secreto ni tocar reglas de red.

¿Puedo compartir una conexión entre distintos tenants de Entra?

No por defecto. Azure bloquea las conexiones entre tenants de Microsoft Entra distintos salvo que lo configures explícitamente, según la documentación oficial. Es un control de seguridad pensado para que un tenant no acceda a recursos de otro sin autorización.

Conclusión

Lo que cambia con las políticas de acceso es simple pero pesa en el día a día: dejás de elegir entre “duplico todo” o “le abro la conexión a cualquiera”. Provisionás una vez, autorizás por identidad, y revocás sin drama. Si tenés un entorno de integración con varias Logic Apps Standard en el mismo grupo de recursos, el próximo paso concreto es pasar tus conexiones compartidas a Managed Identity con user-assigned identity y armar la política de acceso a nivel ARM. Menos secretos dando vueltas, más control sobre quién toca qué, y auditoría en un solo lugar.

Fuentes

• Microsoft Learn – Introducción a los conectores en Azure Logic Apps
• Microsoft Learn – Autenticación con identidad administrada
• Microsoft Learn – Crear identidad de servicio administrada
• Microsoft Learn – Bloquear conexiones entre tenants
• dev.to – Securing Shared API Connections in Azure Logic Apps Standard with Access Policies