Exposición segura de middleware heredado de SAP con PaaS de Azure
La activación de sistemas internos y asociados externos para interactuar con back-end de SAP es un requisito común. Los entornos de SAP existentes suelen basarse en el middleware heredado SAP Process Orchestration(PO) o Process Integration(PI) para sus necesidades de integración y transformación. Para simplificar, en este artículo se usa el término Orquestación de procesos de SAP para hacer referencia a ambas ofertas.
En este artículo se describen las opciones de configuración de Azure con énfasis en las implementaciones accesibles desde Internet.
Nota:
SAP menciona SAP IntegrationSuite, específicamente SAP CloudIntegration, que se ejecuta en Business TechnologyPlatform(BTP) como sucesor de SAP PO y PI. Tanto la plataforma BTP como los servicios están disponibles en Azure. Para más información, consulte el SAP Discovery Center. Para obtener más información sobre la escala de tiempo de soporte técnico de mantenimiento para el componente heredado, consulte la nota de OSS de SAP 1648480.
Información general
Las implementaciones existentes basadas en el middleware de SAP a menudo se han basado en la tecnología de distribución propietaria de SAP denominada SAP WebDispatcher. Esta tecnología funciona en la capa 7 del modelo OSI. Actúa como proxy inverso y aborda las necesidades de equilibrio de carga para las cargas de trabajo de la aplicación SAP de bajada, como SAP Enterprise Resource Planning (ERP), SAP Gateway u orquestación de procesos de SAP.
Los enfoques de distribución incluyen servidores proxy inversos tradicionales, como Apache, hasta opciones de plataforma como servicio (PaaS), como Azure Load Balancer y la bien fundamentada SAP WebDispatcher. Los conceptos generales descritos en este artículo se aplican a las opciones mencionadas. Para obtener instrucciones sobre el uso de equilibradores de carga que no son de SAP, consulte la wiki de SAP.
Nota
Todas las configuraciones descritas en este artículo asumen una topología de red en estrella tipo hub-and-spoke, donde los servicios compartidos se implementan en el hub. En función de la importancia de SAP, es posible que necesite aún más aislamiento. Para más información, consulte la guía de diseño de SAP para redes perimetrales.
Servicios principales de Azure
Azure Application Gateway controla el enrutamiento http público basado en Internet, el enrutamiento HTTPprivado interno y la tunelización cifrada entre suscripciones. Algunos ejemplos son la seguridad y el escalado automático.
Azure Application Gateway se centra en exponer aplicaciones web, por lo tanto, incluye Web Application Firewall (WAF). Las cargas de trabajo de otras redes virtuales que se comunicarán con SAP a través de Azure Application Gateway se pueden conectar a través de vínculos privados, incluso entre inquilinos.
Azure Firewall controla el enrutamiento público basado en Internet e interno privado para los tipos de tráfico en la capa 4 a la 7 del modelo OSI. Proporciona fuentes de inteligencia sobre amenazas y filtrado L3-L7 directamente desde Microsoft Security.
Azure API Management controla el enrutamiento público basado en Internet y privado interno específicamente para las API. Ofrece limitación de solicitudes, cuota de uso y límites, características de gobernanza como directivas y claves de API para desglosar los servicios por cliente.
Azure VPN Gateway y Azure ExpressRoute sirven como puntos de entrada a redes locales. Se abrevian en los diagramas como VPN y XR.
Consideraciones sobre la configuración
Las necesidades de la arquitectura de integración difieren en función de la interfaz que usa una organización. Las tecnologías propietarias de SAP, como el marco de documento intermedio (IDoc), la interfaz de programación de aplicaciones empresariales (BAPI),las llamadas a funciones remotas transaccionales (tRFC) o las RFC sin formato requieren un entorno de tiempo de ejecución específico. Funcionan en las capas 4 a 7 del modelo OSI, a diferencia de las API modernas que normalmente se basan en la comunicación basada en HTP (capa 7 del modelo OSI). Debido a esto, las interfaces no se pueden tratar de la misma manera.
Este artículo se centra en las API modernas y HTTP, incluidos escenarios de integración como la instrucción de aplicabilidad 2 (AS2). El Protocolo de transferencia de archivos (FTP) sirve como ejemplo para controlar las necesidades de integración que no son HTTP. Para obtener más información sobre las soluciones de equilibrio de carga de Microsoft, consulte Opciones de equilibrio de carga.
Nota
SAP publica conectores dedicados para sus interfaces propietarias. Consulte la documentación de SAP para Java y .NET, por ejemplo. También son compatibles con las puertas de enlace de Microsoft. Tenga en cuenta que los iDoc también se pueden publicar a través de HTTP.
Los problemas de seguridad requieren el uso de firewalls para protocolos de nivel inferior y WAF para abordar el tráfico basado en HTTP con Seguridad de la capa de transporte (TLS). Para que sean eficaces, las sesiones TLS deben finalizarse en el nivel de WAF. Para admitir enfoques de confianza cero, se recomienda volver a cifrar después para proporcionar el cifrado de un extremo a otro.
Los protocolos de integración como AS2 pueden generar alertas mediante el uso de las reglas de WAF estándar. Se recomienda usar el libro de evaluación de prioridades de WAF de Application Gateway para identificar y comprender mejor por qué se desencadena la regla, para que pueda corregirlo de forma eficaz y segura. Open Web Application Security Project (OWASP) proporciona las reglas estándar. Para ver una sesión de vídeo detallada sobre este tema con énfasis en la exposición de SAP Fiori, consulte la webcast de SAP en Azure.
Puede mejorar aún más la seguridad mediante TLS mutua (mTLS), que también se denomina autenticación mutua. A diferencia de TLS normal, comprueba la identidad del cliente.
Nota
Los grupos de máquinas virtuales (VM) requieren un equilibrador de carga. Para mejorar la legibilidad, los diagramas de este artículo no muestran un equilibrador de carga.
Nota:
Si no necesita características de equilibrio específicas de SAP que proporciona SAP Web Dispatcher, puede reemplazarlas por Azure Load Balancer. Este reemplazo ofrece la ventaja de una oferta de PaaS administrada en lugar de una configuración de infraestructura como servicio (IaaS).
Escenario: Enfoque en la conectividad HTTP de entrada
SAP Web Dispatcher no ofrece un WAF. Por ello, recomendamos usar Azure Application Gateway para una configuración más segura. SAP Web Dispatcher y la Orquestación de procesos siguen siendo responsables de ayudar a proteger el back-end de SAP frente a la sobrecarga de solicitudes con instrucciones de ajuste de tamaño y límites de solicitudes simultáneas. No hay ninguna funcionalidad de limitación disponible en las cargas de trabajo de SAP.
Puede evitar el acceso no intencional a través de listas de control de acceso en SAP Web Dispatcher.
Uno de los escenarios para la comunicación de orquestación de procesos de SAP es el flujo de entrada. El tráfico puede originarse en aplicaciones o usuarios externos locales, o en un sistema interno. El ejemplo siguiente se centra en HTTPS.
Escenario: Enfoque en la conectividad HTTP/FTP de salida
Para la dirección de comunicación inversa, la Orquestación de procesos de SAP puede usar la red virtual para llegar a cargas de trabajo locales o destinos basados en Internet a través de la interrupción de Internet. Azure Application Gateway actúa como proxy inverso en tales escenarios. Para la comunicación sin HTTP, considere la posibilidad de agregar Azure Firewall. Para obtener más información, consulte Escenario: Basado en archivos y comparación de componentes de puerta de enlace más adelante en este artículo.
En el escenario de salida siguiente se muestran dos métodos posibles. Uno usa HTTPS a través de Azure Application Gateway llamar a un servicio web (por ejemplo, adaptador SOAP). El otro usa FTP a través de SSH (SFTP) a través de Azure Firewall transferir archivos al servidor SFTP de un asociado empresarial.
Escenario: Enfoque en API Management
En comparación con los escenarios de conectividad entrante y saliente, la introducción de Azure API Management en modo interno (solo IP privada e integración de red virtual) agrega funcionalidades integradas, como:
- Limitaciones.
- Gobernanza de API.
- Opciones de seguridad adicionales, como flujos de autenticación modernos.
- Integración de Microsoft Entra ID.
- La oportunidad de agregar las API de SAP a una solución de API central para toda la empresa.
Si no necesita un WAF, puede implementar Azure API Management en modo externo mediante una dirección IP pública. La implementación simplifica la configuración, a la vez que mantiene las funcionalidades de limitación y gobernanza de API. La protección básica se implementa para todas las ofertas de PaaS de Azure.
Escenario: Alcance global
Azure Application Gateway es un servicio regional. En comparación con los escenarios anteriores, Azure Front Door garantiza el enrutamiento global entre regiones, incluido un firewall de aplicaciones web. Para más información sobre las diferencias, consulte esta comparación.
En el diagrama siguiente se condensa SAP Web Dispatcher, SAP Process Orchestration y el back-end en una sola imagen para mejorar la legibilidad.
Escenario: basado en archivos
Los protocolos no HTTP como FTP no se pueden abordar con Azure API Management, Application Gateway o Azure Front Door, como se muestra en escenarios anteriores. En su lugar, la instancia de Azure Firewall administrado o la aplicación virtual de red (NVA) equivalente asumen el rol de proteger las solicitudes entrantes.
Los archivos deben almacenarse antes de que SAP pueda procesarlos. Se recomienda que use SFTP. Azure Blob Storage admite SFTP de forma nativa.
Hay opciones de SFTP alternativas disponibles en Azure Marketplace si es necesario.
En el diagrama siguiente se muestra una variación de este escenario con destinos de integración externos y locales. Los diferentes tipos de FTP seguro ilustran la ruta de comunicación.
Para obtener información sobre los recursos compartidos de archivos del Sistema de archivos de red (NFS) como alternativa a Blob Storage, consulte Recursos compartidos de archivos NFS en Azure Files.
Escenario: Específico de SAP RISE
Las implementaciones de SAP RISE son técnicamente idénticas a los escenarios descritos antes, con la excepción de que se administra mediante SAP la carga de trabajo de SAP de destino. Los conceptos descritos se pueden aplicar aquí.
En los diagramas siguientes se muestran dos configuraciones como ejemplos. Para más información, consulte la guía de referencia de SAP RISE.
Importante
Póngase en contacto con SAP para asegurarse de que los puertos de comunicación de su escenario están permitidos y están abiertos en NSG.
Entrada HTTP
En la primera configuración, la capa de integración se rige por el cliente, incluida la "Orquestación de procesos de SAP", y la ruta de acceso de entrada completa. Solo el destino de SAP final se ejecuta en la suscripción RISE. La comunicación con la carga de trabajo hospedada de RISE se configura a través del emparejamiento de redes virtuales, normalmente a través del hub. Una posible integración podría ser iDoc publicados en el servicio web /sap/bc/idoc_xml de SAP ERP por parte de un tercero externo.
En este segundo ejemplo se muestra una configuración, donde SAP RISE ejecuta toda la cadena de integración, excepto la capa de API Management.
Archivo de salida
En este escenario, la instancia de Orquestación de procesos administrada por SAP escribe archivos en el recurso compartido de archivos administrado por el cliente en Azure o en una carga de trabajo que se encuentra en el entorno local. El cliente controla el salto.
Comparación de las configuraciones de puerta de enlace
Nota:
Las métricas de rendimiento y costo presuponen los niveles de producción. Para más información, consulte la Calculadora de precios de Azure. Consulte también los siguientes artículos: Rendimiento de Azure Firewall, Compatibilidad con tráfico elevado de Application Gateway y Capacidad de una instancia de Azure API Management.
En función de los protocolos de integración que está usando, es posible que necesite varios componentes. Para obtener más información sobre las ventajas de las distintas combinaciones de Azure Application Gateway de encadenamiento con Azure Firewall, consulte Azure Firewall y Application Gateway para redes virtuales.
Regla general de integración
Para determinar qué escenarios de integración descritos en este artículo se ajustan mejor a sus requisitos, evalúe los casos por caso. Considere la posibilidad de habilitar las siguientes funcionalidades:
Limitación de solicitudes mediante API Management
Límites de solicitudes simultáneas en SAP Web Dispatcher
TLS mutua para comprobar el cliente y el receptor
Azure Firewall para integraciones que no son HTTP
Alta disponibilidad y recuperación ante desastres para las cargas de trabajo de integración de SAP basadas en máquinas virtuales
Mecanismos de autenticación modernos como OAuth2, cuando corresponda
Un almacén de claves administrado como Azure Key Vault para todos los certificados, credenciales y claves implicados
Alternativas a la orquestación de procesos de SAP con Azure Integration Services
Con la cartera de Azure Integration Services, puede abordar de forma nativa los escenarios de integración que abarca SAP Process Orchestration. Para obtener información sobre cómo diseñar patrones de iFlow de SAP a través de medios nativos de la nube, consulte esta serie de blog. La guía del conector contiene más detalles sobre AS2 y EDIFACT.
Para más información, consulte los conectores de Azure Logic Apps para las interfaces de SAP deseadas.
Pasos siguientes
Protección de las API con Application Gateway y API Management
Integración de API Management en una red virtual interna con Application Gateway
Descripción del WAF de Application Gateway para SAP
Comprender las implicaciones de combinar Azure Firewall y Azure Application Gateway
Trabajar con las API de OData de SAP en Azure API Management