Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Importante
Aviso de desuso: Este artículo está en desuso y ya no se actualiza. Para asegurarse de que solo se muestran las mejores instrucciones, este artículo se eliminará en mayo de 2026.
Para obtener instrucciones alternativas, consulte Arquitectura de integración en el Centro de arquitectura de Azure.
Si desea guardar esta guía, puede seleccionar Descargar un PDF en la parte inferior izquierda de esta página o descargar los archivos de GitHub.
La buena seguridad es la piedra angular de cualquier aplicación Azure. Azure Integration Services se enfrentan a un desafío determinado, ya que hay muchos recursos que componen una aplicación y cada uno de estos recursos tiene sus propias consideraciones de seguridad. Para asegurarse de que comprende las consideraciones específicas de cada servicio, consulte las siguientes líneas base de seguridad:
Línea Base de Seguridad Azure para Data Factory
Consideraciones de diseño
Al diseñar el modelo de seguridad, hay dos áreas de diseño diferentes: seguridad en tiempo de diseño y seguridad en tiempo de ejecución.
Seguridad en tiempo de diseño implica el acceso a la administración y creación de recursos de Azure a través del portal de Azure o la API Resource Manager. En Azure, usamos Microsoft Entra ID y control de acceso basado en rol (RBAC).
Run-Time seguridad implica el acceso a puntos de conexión y recursos durante el flujo de una aplicación, por ejemplo, autenticación y autorización de un usuario que llama a una aplicación lógica o una operación de API en API Management.
Decida al principio si necesita:
Private Cloud: todos los recursos residen en una Virtual Network (VNet) y solo usan redes privadas, sin acceso a ni desde la red pública de Internet, potencialmente disponibles para los recursos locales a través de VPN o ExpressRoute.
Nube pública : todos los recursos orientados al público tienen acceso a la red pública de Internet, aunque están bloqueados para restringir el acceso desde la red pública de Internet y solo permiten direcciones IP o intervalos específicos.
Híbrido : algunos recursos son privados y algunos son públicos.
La elección que realice afecta al costo de los recursos, junto con la seguridad que puede implementar para las aplicaciones.
Entre las consideraciones generales de seguridad se incluyen:
Usar Azure servicios de red para proteger el tráfico de entrada y salida.
Usar Microsoft Entra ID y OAuth 2.0 para administrar la autenticación y la autorización.
Aplicación de directivas de gobernanza con Azure Policy.
Bloquear el acceso a los recursos (control de acceso).
Cifrado de datos tanto en tránsito como en reposo.
Registro de todos los intentos de acceder a los recursos.
Auditoría del acceso a los recursos.
Recomendaciones de diseño
Recomendaciones de diseño de red
Considere el uso de un Application Gateway (Azure Application Gateway o Azure Front Door) con un Web Application Firewall (WAF) delante de los puntos de conexión accesibles; esto le ayudará con el cifrado automático de datos y le permitirá supervisar y configurar los puntos de conexión más fácilmente.
Front Door es una red de entrega de aplicaciones que proporciona equilibrio de carga global y servicio de aceleración de sitios para aplicaciones web. Front Door ofrece funcionalidades de nivel 7, como la descarga SSL, el enrutamiento basado en rutas de acceso, la conmutación por error rápida y el almacenamiento en caché para mejorar el rendimiento y la disponibilidad de las aplicaciones.
Traffic Manager es un equilibrador de carga de tráfico basado en DNS que le permite distribuir el tráfico de forma óptima a los servicios en regiones globales de Azure, a la vez que proporciona alta disponibilidad y capacidad de respuesta. Dado que Traffic Manager es un servicio de equilibrio de carga basado en DNS, solo equilibra la carga en el nivel de dominio. Por ese motivo, no se puede hacer la conmutación por error de manera tan rápida como lo hace Front Door debido a desafíos comunes en torno al almacenamiento en caché del DNS y los sistemas que no respetan el TTL del DNS.
Application Gateway proporciona un controlador de entrega de aplicaciones administrada con varias funcionalidades de equilibrio de carga de nivel 7. Puede usar Application Gateway para optimizar la productividad de la granja de servidores web al descargar la desencriptación SSL que consume muchos recursos de CPU en la puerta de enlace.
Azure Load Balancer es un servicio de equilibrio de carga entrante y saliente de alto rendimiento y ultra-baja latencia en la capa 4 para todos los protocolos UDP y TCP. Load Balancer controla millones de solicitudes por segundo. El equilibrador de carga es redundante por zonas, lo que garantiza una alta disponibilidad en las Zonas de Disponibilidad.
Implemente el aislamiento de red para los recursos de Servicios de Integración mediante la integración con red virtual para ubicarlos en una subred de aislamiento combinada con el uso de Azure PrivateLink y puntos de conexión privados. Consulte el artículo Topología de red y conectividad de esta serie para obtener una revisión de esta guía de diseño.
Proteja el tráfico de salida con Azure Firewall
Use el filtrado de IP para bloquear los puntos de conexión para que solo las direcciones de red conocidas accedan a ellos (esto es aplicable a los servicios de plataforma como servicio (PaaS) (como Logic Apps, Function Apps, Service Bus) no integrados en redes virtuales).
Si tiene recursos disponibles públicamente, use ofuscación DNS para disuadir a los atacantes. La ofuscación significa nombres de dominio personalizados o nombres de recursos específicos de Azure sin revelar el propósito ni el propietario de un recurso.
Recomendaciones de diseño de cifrado
Al almacenar datos (en Azure Storage o Azure SQL Server, por ejemplo) en servicios PaaS de Azure, siempre se cifran en reposo mediante claves administradas por Microsoft. Bloquear el acceso a los datos, idealmente solo para los servicios y un número limitado de administradores. Recuerde que esto también se aplica a los datos de registro. Para obtener más información, consulte Cifrado de datos en reposo de Azure y Descripción general del cifrado de Azure. Considere si es necesario usar claves administradas de Customer (CMK) o si las claves administradas por Microsoft son suficientes.
Use siempre cifrado en tránsito (tráfico TLS, por ejemplo) al transferir datos entre recursos; nunca envíe datos a través de un canal sin cifrar.
Al usar protocolos TLS, use siempre TLS 1.2 o superior.
Mantenga los secretos en Azure Key Vault y, a continuación, vincule estos a App Settings (Functions, Logic Apps), Named Values (API Management) o Configuration Entries (App Configuration).
Implemente una directiva de rotación de claves para asegurarse de que todas las claves que se usan en el entorno se rotan periódicamente para evitar ataques mediante claves en peligro.
En Logic Apps, utilice la ofuscación para proteger los datos en el historial de ejecución.
Recomendaciones de diseño de autenticación y acceso
Siga siempre el principio de privilegios mínimos al asignar acceso: asigne a una identidad los permisos mínimos que necesita. Si no hay un rol integrado con los permisos mínimos que necesita, considere la posibilidad de crear un rol personalizado con solo estos permisos.
Siempre que sea posible, use siempre identidades administradas cuando un recurso necesite acceder a un servicio. Por ejemplo, si el flujo de trabajo de la aplicación lógica necesita acceder a Key Vault para recuperar un secreto, use el Managed Identity de Logic Apps; Las identidades administradas proporcionan un mecanismo más seguro y fácil de administrar para acceder a los recursos, ya que Azure administra la identidad en su nombre.
Use OAuth 2.0 como mecanismo de autenticación entre puntos de conexión de recursos:
En Logic Apps o Functions, habilite Easy Auth, que requiere que todos los autores de llamadas externos usen una identidad de OAuth (normalmente Microsoft Entra ID, pero podría ser cualquier proveedor de identidades).
En API Management, use el
validate-jwtelemento de directiva para requerir un flujo de OAuth para las conexiones a los puntos de conexión.En Azure Storage y Key Vault, configure directivas de acceso para restringir el acceso a identidades específicas.
Recomendaciones de diseño de gobernanza
Use activamente Azure Policy para buscar problemas de seguridad o errores. Por ejemplo, los puntos de conexión sin filtrado de IP.
Cuando esté disponible, use Microsoft Defender for Cloud para examinar los recursos e identificar posibles puntos débiles.
Revise periódicamente los registros de auditoría (idealmente mediante una herramienta automatizada) para identificar los ataques de seguridad y cualquier acceso no autorizado a los recursos.
Considere el uso de pruebas de penetración para identificar las debilidades del diseño de seguridad.
Use procesos de implementación automatizados para configurar la seguridad. Siempre que sea posible, use una canalización de CI/CD como Acciones de GitHub o Azure DevOps Pipelines e Infraestructura como herramientas de código como Bicep o Terraform para no solo implementar los recursos, sino también para configurar la seguridad. Esto garantiza que los recursos se protegerán automáticamente cada vez que se implementen.
Paso siguiente
Revise las áreas de diseño críticas para realizar consideraciones y recomendaciones completas para la arquitectura.
Contenido recomendado
¿Qué son las identidades administradas para los recursos de Azure?
Autorice el acceso a los recursos de Azure con identidades administradas en Azure Logic Apps
Consideraciones de seguridad para el movimiento de datos en Azure Data Factory
Desencadenar flujos de trabajo en aplicaciones lógicas estándar con Easy Auth
Protege una API en Azure API Management usando la autorización OAuth 2.0 con Microsoft Entra ID