Editar

Conexiones entrantes y salientes a Internet para SAP en Azure

Azure Virtual Machines
Azure Virtual Network
Azure Application Gateway
Azure Load Balancer

En este artículo se proporciona un conjunto de prácticas probadas para mejorar la seguridad de las conexiones entrantes y salientes a Internet para la infraestructura de SAP en Azure.

Architecture

Diagrama en el que se muestra una solución para la comunicación accesible desde Internet para SAP en Azure.

Descargue un archivo de Visio de las arquitecturas de este artículo.

Esta solución muestra un entorno de producción común. Puede reducir el tamaño y el ámbito de la configuración para que se ajuste a sus requisitos. Esta reducción se puede aplicar al entorno de SAP: menos máquinas virtuales (VM), ninguna alta disponibilidad ni distribuidores web de SAP insertados en lugar de máquinas virtuales discretas. También se puede aplicar a alternativas al diseño de red, como se describe más adelante en este artículo.

Los requisitos de los clientes, controlados por directivas empresariales, requerirán adaptaciones a la arquitectura, especialmente al diseño de red. Hemos incluido alternativas cuando ha sido posible. Muchas soluciones son viables. Elija un enfoque adecuado para su empresa. Debe ayudarle a proteger los recursos de Azure, pero seguir proporcionando una solución eficaz.

La recuperación ante desastres (DR) no se trata en esta arquitectura. Para el diseño de red, se aplican los mismos principios y diseños que son válidos para las regiones de producción primarias. En el diseño de red, en función de las aplicaciones protegidas por la DR, considere la posibilidad de habilitar la DR en otra región de Azure. Para más información, consulte el artículo Introducción a la recuperación ante desastres e instrucciones de infraestructura para la carga de trabajo de SAP.

Flujo de trabajo

  • La red local se conecta a un centro de conectividad central a través de Azure ExpressRoute. La red virtual del centro contiene una subred de puerta de enlace, una subred de Azure Firewall, una subred de servicios compartidos y una subred de Azure Application Gateway.
  • El centro se conecta a una suscripción de producción de SAP mediante el emparejamiento de redes virtuales. Esta suscripción contiene dos redes virtuales de radio:
    • La red virtual perimetral de SAP contiene una subred de aplicación perimetral de SAP.
    • La red virtual de producción de SAP contiene una subred de aplicación y una subred de base de datos.
  • La suscripción del centro de conectividad y la suscripción de producción de SAP se conectan a Internet a través de direcciones IP públicas.

Componentes

Suscripciones. Esta arquitectura implementa el enfoque de la zona de aterrizaje de Azure. Se usa una suscripción de Azure para cada carga de trabajo. Una o varias suscripciones se usan para los servicios de TI centrales que contienen el centro de red y los servicios compartidos centrales, como firewalls o Active Directory y DNS. Se usa otra suscripción para la carga de trabajo de producción de SAP. Use la guía de decisiones de Cloud Adoption Framework para Azure para determinar la mejor estrategia de suscripción para su escenario.

Redes virtuales.Azure Virtual Network conecta entre sí los recursos de Azure con una seguridad mejorada. En esta arquitectura, la red virtual se conecta a un entorno local mediante ExpressRoute o una puerta de enlace de red privada virtual (VPN) implementada en el concentrador de una topología en estrella tipo hub-and-spoke. El entorno de producción de SAP usa sus propias redes virtuales de radio. Dos redes virtuales de radio distintas realizan diferentes tareas y las subredes proporcionan segregación de red.

La separación en subredes por carga de trabajo facilita el uso de grupos de seguridad de red (NSG) para establecer reglas de seguridad para máquinas virtuales de aplicación o servicios de Azure implementados.

Puerta de enlace con redundancia de zona. Una puerta de enlace conecta redes distintas, y extiende la red local a la red virtual de Azure. Se recomienda el uso de ExpressRoute para crear conexiones privadas que no usen la red pública de Internet. También puede usar una conexión de sitio a sitio. Puede implementar ExpressRoute o puertas de enlace de VPN entre zonas para ayudar a evitar errores de zona. Consulte Puertas de enlace de red virtual con redundancia de zona en Azure Availability Zones para una explicación sobre las diferencias entre una implementación zonal y una implementación con redundancia de zona. Para una implementación de zona de las puertas de enlace, debe usar direcciones IP de SKU Estándar.

NSG. Para restringir el tráfico de red hacia y desde la red virtual, cree grupos de seguridad de red y asígnelos a subredes específicas. Proporcionar seguridad para subredes individuales mediante grupos de seguridad de red específicos de la carga de trabajo.

Grupos de seguridad de aplicaciones. Para definir directivas de seguridad de red pormenorizadas en sus grupos de seguridad de red en función de las cargas de trabajo que se centran en aplicaciones, use grupos de seguridad de aplicación en lugar de direcciones IP explícitas. Mediante el uso de grupos de seguridad de aplicaciones, puede agrupar máquinas virtuales según los fines, por ejemplo, SID de SAP. Los grupos de seguridad de aplicación ayudan a proteger las aplicaciones mediante el filtrado del tráfico de segmentos de confianza de la red.

Punto de conexión privado. Muchos servicios de Azure funcionan como servicios públicos, por diseño accesibles a través de Internet. Para permitir el acceso privado a través del intervalo de red privado, puede usar puntos de conexión privados para algunos servicios. Los puntos de conexión privados son interfaces de red en la red virtual. Incorporan eficazmente el servicio al espacio de red privada.

Azure Application Gateway.Application Gateway es un equilibrador de carga del tráfico web. Con su funcionalidad de Web Application Firewall, es el servicio ideal para exponer aplicaciones web a Internet con una seguridad mejorada. Application Gateway puede dar servicio a clientes públicos (internet), privados o ambos, en función de la configuración.

En la arquitectura, Application Gateway permite conexiones entrantes al entorno de SAP a través de HTTPS mediante una dirección IP pública. Su grupo de back-end es dos o más máquinas virtuales de SAP Web Dispatcher, a las que se accede mediante round-robin y proporciona alta disponibilidad. La puerta de enlace de aplicaciones es un proxy inverso y un equilibrador de carga de tráfico web, pero no reemplaza a SAP Web Dispatcher. SAP Web Dispatcher proporciona integración de aplicaciones con los sistemas SAP e incluye características que Application Gateway no proporciona por sí solo. La autenticación de cliente, cuando llega a los sistemas SAP, se realiza mediante el nivel de aplicación de SAP de forma nativa o mediante el inicio de sesión único. Al habilitar la protección contra DDoS de Azure, considere la posibilidad de usar la SKU de protección de red contra DDoS, ya que verá descuentos para Application Gateway Web Application Firewall.

Para obtener un rendimiento óptimo, habilite la Compatibilidad con HTTP2 para Application Gateway, SAP Web Dispatcher y SAP NetWeaver.

Azure Load Balancer. Azure Standard Load Balancer proporciona elementos de red para el diseño de alta disponibilidad de los sistemas SAP. En el caso de los sistemas en clúster, Standard Load Balancer proporciona la dirección IP virtual para el servicio de clúster, como las instancias de ASCS/SCS y las bases de datos que se ejecutan en máquinas virtuales. También puede usar Standard Load Balancer para proporcionar la dirección IP para el nombre de host virtual de SAP de sistemas no agrupados cuando las direcciones IP secundarias de las tarjetas de red de Azure no son una opción. El uso de Standard Load Balancer en lugar de Application Gateway para abordar el acceso saliente a Internet se trata más adelante en este artículo.

Diseño de red

La arquitectura usa dos redes virtuales discretas, ambas redes virtuales de radio que están emparejadas con la red virtual del centro de conectividad central. No hay ningún emparejamiento red a red. Se usa una topología de estrella, en la que la comunicación pasa a través del centro. La separación de redes ayuda a proteger las aplicaciones de brechas.

Una red perimetral específica de la aplicación (también conocida como DMZ) contiene las aplicaciones accesibles desde Internet, como SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent y otras. En el diagrama de arquitectura, la red perimetral se denomina Perímetro de SAP: red virtual de radios. Debido a las dependencias de los sistemas SAP, el equipo de SAP suele realizar la implementación, la configuración y la administración de estos servicios. Es por eso que estos servicios perimetrales de SAP no se encuentran con frecuencia en la suscripción y la red de un centro. A menudo, los desafíos de la organización se deben a la naturaleza central de la ubicación de la carga de trabajo de aplicaciones o servicios del centro.

Estas son algunas de las ventajas de usar una red virtual perimetral de SAP independiente:

  • Aislamiento rápido e inmediato de los servicios en peligro si se detecta una brecha. Al quitar el emparejamiento de red virtual del perímetro de SAP al centro de conectividad, las cargas de trabajo perimetrales de SAP y las aplicaciones de red virtual de aplicaciones de SAP de Internet se aíslan de forma inmediata. Cambiar o quitar una regla de NSG que permita el acceso afecta solo a las nuevas conexiones y no corta las conexiones existentes.
  • Controles más estrictos en la red virtual y la subred, con un bloqueo hermético en los asociados de comunicación dentro y fuera de la red perimetral de SAP y las redes de aplicaciones de SAP. Puede ampliar el mayor control a los usuarios autorizados y a los métodos de acceso en aplicaciones perimetrales de SAP, con diferentes back-ends de autorización, acceso con privilegios o credenciales de inicio de sesión para aplicaciones perimetrales de SAP.

Las desventajas son una mayor complejidad y costos adicionales de emparejamiento de red virtual para el tráfico de SAP enlazado a Internet (porque la comunicación debe pasar a través del emparejamiento de red virtual dos veces). El impacto de la latencia en el tráfico de emparejamiento en estrella tipo hub-and-spoke depende de cualquier firewall que esté en su lugar y deba medirse.

Arquitectura simplificada

Para abordar las recomendaciones de este artículo, pero limitar las desventajas, puede usar una única red virtual de radio para el perímetro y las aplicaciones de SAP. La arquitectura siguiente contiene todas las subredes de una única red virtual de producción de SAP. Si La ventaja del aislamiento inmediato mediante la finalización del emparejamiento de red virtual con el perímetro de SAP está en peligro, no está disponible. En este escenario, los cambios en los grupos de seguridad de red solo afectan a las nuevas conexiones.

Diagrama en el que se muestra una arquitectura simplificada para la comunicación accesible desde Internet para SAP en Azure.

Descargue un archivo de Visio de las arquitecturas de este artículo.

En el caso de las implementaciones de menor tamaño y ámbito, la arquitectura simplificada podría ser una mejor opción y sigue siendo compatible con los principios de la arquitectura más compleja. Este artículo, a menos que se indique lo contrario, hace referencia a la arquitectura más compleja.

La arquitectura simplificada usa una puerta de enlace NAT en la subred perimetral de SAP. Esta puerta de enlace proporciona conectividad saliente para SAP Cloud Connector y SAP Analytics Cloud Agent y actualizaciones del sistema operativo para las máquinas virtuales implementadas. Dado que SAProuter requiere conexiones entrantes y salientes, su ruta de comunicación pasa por el firewall en lugar de usar la puerta de enlace NAT. La arquitectura simplificada también coloca a Application Gateway con su propia subred designada en la red virtual perimetral de SAP, como un enfoque alternativo a la red virtual del centro.

Una puerta de enlace NAT es un servicio que proporciona direcciones IP públicas estáticas para la conectividad saliente. La puerta de enlace NAT se asigna a una subred. Todas las comunicaciones salientes usan las direcciones IP de la puerta de enlace NAT para el acceso a Internet. Las conexiones entrantes no usan la puerta de enlace NAT. Las aplicaciones como SAP Cloud Connector o los servicios de actualización del sistema operativo de máquina virtual que acceden a los repositorios de Internet pueden usar la puerta de enlace NAT en lugar de enrutar todo el tráfico saliente a través del firewall central. Con frecuencia, las reglas definidas por el usuario se implementan en todas las subredes para forzar el tráfico enlazado a Internet desde todas las redes virtuales a través del firewall central.

En función de sus requisitos, es posible que pueda usar la puerta de enlace NAT como alternativa al firewall central, solo en las conexiones salientes. Al hacerlo, puede reducir la carga en el firewall central mientras se comunica con los puntos de conexión públicos permitidos por el grupo de seguridad de red. También obtiene el control IP de salida, ya que puede configurar reglas de firewall de destino en una lista de direcciones IP establecidas de la puerta de enlace NAT. Algunos ejemplos son llegar a los puntos de conexión públicos de Azure que usan los servicios públicos, los repositorios de revisiones del sistema operativo o las interfaces de terceros.

Para una configuración de alta disponibilidad, tenga en cuenta que la puerta de enlace NAT solo se implementa en una zona específica y actualmente no es redundante entre zonas. Con una sola puerta de enlace NAT, no es ideal para las implementaciones de SAP que usan la implementación con redundancia de zona (entre zonas) para máquinas virtuales.

Uso de componentes de red en un entorno horizontal de SAP

Normalmente, un documento de arquitectura representa solo un sistema SAP o un entorno horizontal. De esta forma, serán más fáciles de comprender. El resultado es que, con frecuencia, la imagen completa, es decir, la forma en que la arquitectura se ajusta a un entorno horizontal de SAP más grande que incluye varias pistas y niveles del sistema, no se aborda.

Los servicios de red centrales, como el firewall, la puerta de enlace NAT y los servidores proxy, si se implementan, se usan mejor en todo el entorno horizontal de SAP de todos los niveles: producción, preproducción, desarrollo y espacio aislado. En función de los requisitos, el tamaño de la organización y las directivas empresariales, es posible que quiera considerar implementaciones independientes por nivel o un entorno de producción y un entorno de prueba o espacio aislado.

Los servicios que suelen servir a un sistema SAP se separan mejor, como se describe aquí:

  • Los equilibradores de carga deben estar dedicados a servicios individuales. La directiva de empresa dicta la nomenclatura y la agrupación de recursos. Se recomienda un equilibrador de carga para ASCS/SCS y ERS y otro para la base de datos, separados para cada SID de SAP. Como alternativa, un único equilibrador de carga para los clústeres (A)SCS, ERS y DB de un sistema SAP también es un buen diseño. Esta configuración ayuda a garantizar que la solución de problemas no sea compleja, con muchos grupos de servidores front-end y back-end y reglas de equilibrio de carga en un único equilibrador de carga. Un único equilibrador de carga por SID de SAP también garantiza que la ubicación en los grupos de recursos coincida con la de otros componentes de infraestructura.
  • Application Gateway, como un equilibrador de carga, permite varios back-end, front-end, configuración HTTP y reglas. La decisión de usar una puerta de enlace de aplicaciones para varios usos es más común aquí porque no todos los sistemas SAP del entorno requieren acceso público. Varios usos en este contexto incluyen diferentes puertos de distribuidor web para los mismos sistemas SAP S/4HANA o diferentes entornos de SAP. Se recomienda al menos una puerta de enlace de aplicaciones por nivel (producción, no producción y espacio aislado), a menos que la complejidad y el número de sistemas conectados sean demasiado altos.
  • Losservicios de SAP, como SAProuter, Cloud Connector y Analytics Cloud Agent, se implementan en función de los requisitos de la aplicación, ya sea de forma centralizada o dividida. Se suele querer una separación entre producción y no producción.

Dimensionamiento y diseño de subredes

Al diseñar subredes para el entorno de SAP, asegúrese de seguir los principios de dimensionamiento y diseño:

  • Varios servicios de plataforma como servicio (PaaS) de Azure requieren sus propias subredes designadas.
  • Application Gateway recomienda una subred de /24 para el escalado. Si se elige limitar la escala de Application Gateway, se podría usar una subred más pequeña, como mínimo de /26 o más grande. No se pueden usar ambas versiones de Application Gateway (1 y 2) en la misma subred.
  • Si usa Azure NetApp Files para los recursos compartidos NFS/SMB o el almacenamiento de base de datos, se requiere una subred designada. El valor predeterminado es una subred /24. Use sus requisitos para determinar el dimensionamiento adecuado.
  • Si usa nombres de host virtuales de SAP, necesita más espacio de direcciones en las subredes de SAP, incluido el perímetro de SAP.
  • Los servicios centrales, como Azure Bastion o Azure Firewall, normalmente administrados por un equipo de TI central, requieren sus propias subredes dedicadas de tamaño suficiente.

Mediante el uso de subredes dedicadas para bases de datos y aplicaciones de SAP, puede establecer grupos de seguridad de red más estrictos, lo que ayuda a proteger ambos tipos de aplicaciones con sus propios conjuntos de reglas. Después, puede limitar el acceso a la base de datos a las aplicaciones de SAP con más facilidad, sin necesidad de recurrir a grupos de seguridad de aplicaciones para un control granular. La separación de las subredes de base de datos y aplicaciones de SAP también facilita la administración de las reglas de seguridad en los grupos de seguridad de red.

Servicios de SAP

SAProuter

Puede usar SAProuter para permitir que terceros, como el soporte técnico de SAP o sus asociados, accedan al sistema SAP. SAProuter se ejecuta en una máquina virtual de Azure. Los permisos de ruta para usar SAProuter se almacenan en un archivo plano denominado saprouttab. Las entradas saprouttab permiten la conexión desde cualquier puerto TCP/IP a un destino de red detrás de SAProuter, normalmente las máquinas virtuales del sistema SAP. El acceso remoto por parte del soporte técnico de SAP se basa en SAProuter. La arquitectura principal usa el diseño descrito anteriormente, con una máquina virtual SAProuter que se ejecuta dentro de la red virtual perimetral de SAP designada. A través del emparejamiento de redes virtuales, SAProuter se comunica con los servidores SAP que se ejecutan en su propia red virtual y subredes de radio.

SAProuter es un túnel a SAP o a sus asociados. En esta arquitectura se describe el uso de SAProuter con SNC para establecer un túnel de aplicación cifrado (nivel de red 7) para SAP/asociados. El uso del túnel basado en IPSEC no se trata actualmente en esta arquitectura.

Las siguientes características ayudan a proteger la ruta de acceso de comunicación a través de Internet:

  • Azure Firewall o una NVA de terceros proporciona el punto de entrada de IP pública en las redes de Azure. Las reglas de firewall limitan la comunicación a direcciones IP autorizadas. Para la conexión con el soporte técnico de SAP, la nota de SAP 48243: la integración del software SAProuter en un entorno de firewall documenta las direcciones IP de los enrutadores de SAP.
  • Al igual que las reglas de firewall, las reglas de seguridad de red permiten la comunicación en el puerto de SAProuter, normalmente 3299 con el destino designado.
  • Mantiene las reglas de permiso/denegación de SAProuter en el archivo saprouttab, especificando quién puede ponerse en contacto con SAProuter y a qué sistema SAP se puede acceder.
  • Hay más reglas de NSG en las subredes respectivas de la subred de producción de SAP que contiene los sistemas SAP.

Para conocer los pasos para configurar SAProuter con Azure Firewall, consulte Configuración de SAProuter con Azure Firewall.

Consideraciones de seguridad de SAProuter

Dado que SAProuter no funciona en la misma subred de aplicación que los sistemas SAP, los mecanismos de inicio de sesión del sistema operativo pueden ser diferentes. En función de las directivas, puede usar un dominio de inicio de sesión independiente o credenciales de usuario de solo host para SAProuter. Si se produce una infracción de seguridad, el acceso en cascada a los sistemas SAP internos no es posible debido a la base de credenciales diferente. La separación de red en tal caso, como se ha descrito anteriormente, puede desacoplar todavía más el acceso de SAProuter en peligro a las subredes de la aplicación. Para lograr este aislamiento, desconecte el emparejamiento de red virtual perimetral de SAP.

Consideraciones de alta disponibilidad de SAProuter

Como SAProuter es un archivo ejecutable simple con una tabla de permisos de ruta basada en archivos, se puede iniciar con facilidad. La aplicación no tiene alta disponibilidad integrada. Si se produce un error en una máquina virtual o aplicación, el servicio debe iniciarse en otra máquina virtual. El uso de un nombre de host virtual para el servicio SAProuter es ideal. El nombre de host virtual está enlazado a una dirección IP, que se asigna como una configuración IP secundaria con la NIC de la máquina virtual o a un equilibrador de carga interno que está conectado a la máquina virtual. En esta configuración, si hay que mover el servicio SAProuter a otra máquina virtual, se puede quitar la configuración de IP del nombre de host virtual del servicio. Después, agregue el nombre de host virtual en otra máquina virtual sin necesidad de cambiar las tablas de rutas o la configuración del firewall. Todos están configurados para usar la dirección IP virtual. Para más información, consulte Uso de nombres de host virtuales de SAP con Linux en Azure.

SAProuters en cascada

Para implementar SAProuters en cascada, puede definir hasta dos SAProuters para conexiones de soporte técnico de SAP. SAProuter número 1, que se ejecuta en la subred de la aplicación perimetral de SAP, proporciona acceso desde el firewall central y desde SAP o SAProuters de asociado. Los únicos destinos permitidos son más SAProuters, que se ejecutan con cargas de trabajo específicas. SAProuters en cascada puede usar la separación por nivel, por región o por SID, según la arquitectura. SAProuter número 2 solo acepta conexiones internas de SAProuter número 1 y proporciona acceso a máquinas virtuales y sistemas SAP individuales. Este diseño le permite separar el acceso y la administración entre diferentes equipos si es necesario. Para obtener un ejemplo de una SAProuters en cascada, consulte Configuración de SAProuter con Azure Firewall.

SAP Fiori y WebGui

SAP Fiori y otros servidores front-end HTTPS para aplicaciones de SAP a menudo se consumen desde fuera de la red corporativa interna. La necesidad de estar disponible en Internet requiere una solución de alta seguridad para ayudar a proteger la aplicación SAP. Application Gateway con el firewall de aplicaciones web es el servicio ideal para este fin.

Para los usuarios que acceden al nombre de host público de la dirección IP pública asociada a Application Gateway, la sesión HTTPS finaliza en Application Gateway. Un grupo de back-end de dos o más máquinas virtuales de SAP Web Dispatcher obtiene sesiones round-robin de la Application Gateway. Esta puerta de enlace de aplicaciones de tráfico interno a Web Dispatcher puede ser HTTP o HTTPS, en función de los requisitos. El firewall de aplicaciones web ayuda a proteger SAP Web Dispatcher frente a ataques procedentes de Internet con el conjunto de reglas principal de OWASP. SAP NetWeaver, a menudo vinculado a Microsoft Entra ID a través del inicio de sesión único (SSO), realiza la autenticación de usuario. Para conocer los pasos necesarios para configurar el inicio de sesión único para Fiori mediante Application Gateway, consulte configuración de inicio de sesión único mediante SAML e Microsoft Entra ID para direcciones URL públicas e internas.

Tenga en cuenta que debe asegurar SAP Web Dispatcher en cualquier situación. Incluso si solo está abierto internamente, se abre hacia Application Gateway mediante la dirección IP pública o accesible mediante cualquier otro medio de red. Para obtener más información, consulte la Información de seguridad para SAP Web Dispatcher.

Azure Firewall y Application Gateway

Todo el tráfico web proporcionado por Application Gateway se basa en HTTPS y se cifra con el certificado TLS proporcionado. Puede usar Azure Firewall como punto de entrada a la red corporativa, a través de su dirección IP pública y, después, enrutar el tráfico de SAP Fiori desde el firewall hasta Application Gateway a través de una dirección IP interna. Para más información, consulte Application Gateway después de Azure Firewall. Dado que el cifrado TCP/IP de nivel 7 ya está implementado a través de TLS, hay una ventaja limitada para usar un firewall en este escenario, y no puede realizar la inspección de paquetes. Fiori se comunica mediante la misma dirección IP externa para el tráfico entrante y saliente, que no suele ser necesaria para las implementaciones de SAP Fiori.

Hay algunas ventajas en una implementación conjunta de Application Gateway y de firewall de nivel 4:

  • Posible integración con la administración de directivas de seguridad en toda la empresa.
  • Ya se ha descartado el tráfico de red que infringe las reglas de seguridad, por lo que no requiere inspección.

Esta implementación combinada es una buena arquitectura. El método para controlar el tráfico entrante de Internet depende de la arquitectura empresarial general. También debe tener en cuenta cómo encaja la arquitectura de red general con los métodos de acceso desde el espacio de direcciones IP internas, como los clientes locales. Esta consideración se trata en la sección siguiente.

Application Gateway para direcciones IP internas (opcional)

Esta arquitectura se centra en aplicaciones accesibles desde Internet. Hay varias opciones disponibles para los clientes que acceden a SAP Fiori, la interfaz de usuario web de un sistema SAP NetWeaver u otra interfaz HTTPS de SAP a través de una dirección IP privada interna. Un escenario consiste en tratar todo el acceso a Fiori como acceso público, a través de la dirección IP pública. Otra opción es usar el acceso directo a la red a través de la red privada a SAP Web Dispatchers, omitiendo Application Gateway por completo. La tercera opción es usar direcciones IP privadas y públicas en Application Gateway, lo que proporciona acceso a Internet y a la red privada.

Puede usar una configuración similar con una dirección IP privada en Application Gateway para el acceso de red exclusivamente privado al entorno de SAP. La dirección IP pública en este caso solo se usa con fines de administración y no tiene un cliente de escucha asociado.

Como alternativa al uso de Application Gateway, puede usar un equilibrador de carga de forma interna. Puede usar un equilibrador de carga interno estándar con máquinas virtuales de Web Dispatcher configuradas como back-end de round-robin. En este escenario, el equilibrador de carga estándar se coloca con las máquinas virtuales de Web Dispatcher en la subred de la aplicación de producción de SAP y proporciona equilibrio de carga activo/activo entre máquinas virtuales de Web Dispatcher.

En el caso de las implementaciones accesibles desde Internet, se recomienda Application Gateway con Web Application Firewall en lugar de un equilibrador de carga con una dirección IP pública.

SAP Business Technology Platform (BTP)

SAP BTP es un gran conjunto de aplicaciones de SAP, SaaS o PaaS, a la que normalmente se accede mediante un punto de conexión público por Internet. SAP Cloud Connector se usa a menudo para proporcionar comunicación para las aplicaciones que se ejecutan en redes privadas, como un sistema SAP S/4HANA que se ejecuta en Azure. SAP Cloud Connector se ejecuta como una aplicación en una máquina virtual. Requiere acceso saliente a Internet para establecer un túnel HTTPS cifrado con TLS con SAP BTP. Actúa como proxy de invocación inversa entre el intervalo IP privado de la red virtual y las aplicaciones de SAP BTP. Debido a esta compatibilidad con la invocación inversa, no es necesario abrir puertos de firewall u otro acceso para las conexiones entrantes, ya que la conexión de la red virtual es saliente.

De forma predeterminada, las máquinas virtuales tienen acceso saliente a Internet de forma nativa en Azure. La dirección IP pública que se usa para el tráfico saliente, cuando no hay ninguna dirección IP pública dedicada asociada a la máquina virtual, se elige de forma aleatoria del grupo de direcciones IP públicas en la región de Azure específica. No se puede controlar. Para asegurarse de que las conexiones salientes se realizan mediante un servicio controlado e identificable y una dirección IP, puede usar uno de los métodos siguientes:

  • Una puerta de enlace NAT asociada a la subred o al equilibrador de carga y su dirección IP pública.
  • Servidores proxy HTTP que usted opere.
  • Una ruta definida por el usuario que obliga al tráfico de red a fluir a un dispositivo de red como un firewall.

El diagrama de arquitectura muestra el escenario más común: enrutar el tráfico enlazado a Internet a la red virtual del centro de conectividad y mediante el firewall central. Debe configurar más opciones en SAP Cloud Connector para conectarse a su cuenta de SAP BTP.

Alta disponibilidad para SAP Cloud Connector

La alta disponibilidad está integrada en SAP Cloud Connector. Cloud Connector se instala en dos máquinas virtuales. La instancia principal está activa y la instancia de sombra está conectada a ella. Comparten la configuración y se mantienen sincronizadas de forma nativa. Si la instancia principal no está disponible, la máquina virtual secundaria intenta asumir el rol principal y volver a establecer el túnel TLS en SAP BTP. En la arquitectura se muestra un entorno de Cloud Connector de alta disponibilidad. No necesita ninguna otra tecnología de Azure, como un equilibrador de carga o software de clúster, para la configuración. Para más información sobre la configuración y la operación, consulte la documentación de SAP.

SAP Analytics Cloud Agent

En algunos escenarios de aplicación, SAP Analytics Cloud Agent es una aplicación que se instala en una máquina virtual. Usa SAP Cloud Connector para la conectividad de SAP BTP. En esta arquitectura, la máquina virtual de SAP Analytics Cloud Agent se ejecuta en la subred de la aplicación perimetral de SAP, junto con las máquinas virtuales de SAP Cloud Connector. Para conocer el flujo de tráfico desde redes privadas como una red virtual de Azure a SAP BTP mediante SAP Analytics Cloud Agent, consulte la documentación de SAP.

SAP proporciona el servicio Private Link para SAP BTP. Habilita conexiones privadas entre los servicios de SAP BTP seleccionados y los servicios seleccionados en la suscripción de Azure y la red virtual. Cuando se usa el servicio Private Link, la comunicación no se enruta a través de la red pública de Internet. Se mantiene en la espina de la red global de alta seguridad de Azure. La comunicación con los servicios de Azure se produce a través de un espacio de direcciones privado. La protección de filtración de datos mejorada se crea al usar el servicio Private Link, ya que el punto de conexión privado asigna el servicio de Azure específico a una dirección IP. El acceso está limitado al servicio de Azure asignado.

En algunos escenarios de integración de SAP BTP, se prefiere el enfoque de servicio Private Link. Para otros usuarios, SAP Cloud Connector es mejor. Para obtener información que le ayude a decidir qué usar, consulte Ejecución de Cloud Connector y SAP Private Link en paralelo.

SAP RISE/ECS

Si SAP opera el sistema SAP con un contrato SAP RISE/ECS, SAP es el asociado de servicio administrado. SAP implementa el entorno de SAP. En la arquitectura de SAP, la arquitectura que se muestra aquí no se aplica a los sistemas que se ejecutan en RISE con SAP/ECS. Para más información sobre la integración de este tipo de entorno de SAP con los servicios de Azure y la red, consulte la documentación de Azure.

Otros requisitos de comunicación de SAP

Es posible que se apliquen consideraciones adicionales sobre las comunicaciones enlazadas a Internet a un entorno de SAP que funciona en Azure. El flujo de tráfico de esta arquitectura usa un firewall central de Azure para este tráfico saliente. Las reglas definidas por el usuario en las redes virtuales de radio enrutan las solicitudes de tráfico enlazadas a Internet al firewall. Como alternativa, puede usar puertas de enlace NAT en subredes específicas, comunicación de salida predeterminada en Azure, direcciones IP públicas en máquinas virtuales (no recomendado) o un equilibrador de carga público con reglas de salida.

Para las máquinas virtuales que están detrás de un equilibrador de carga interno estándar, como aquellas en entornos de clúster, tenga en cuenta que Standard Load Balancer modifica el comportamiento para la conectividad pública. Para más información, consulte el artículo Conectividad del punto de conexión público para las máquinas virtuales que usan Azure Standard Load Balancer en escenarios de alta disponibilidad de SAP.

Actualizaciones del sistema operativo

Las actualizaciones del sistema operativo a menudo se encuentran detrás de un punto de conexión público y se accede a ellas a través de Internet. Si no hay ningún repositorio empresarial ni administración de actualizaciones, para crear el reflejo de las actualizaciones del sistema operativo de los proveedores en las direcciones IP privadas o las máquinas virtuales, la carga de trabajo de SAP debe acceder a los repositorios de actualización de los proveedores.

En el caso de los sistemas operativos Linux, puede acceder a los siguientes repositorios si obtiene la licencia del sistema operativo de Azure. Si compra licencias directamente y las lleva a Azure (BYOS), póngase en contacto con el proveedor del sistema operativo sobre las formas de conectarse a los repositorios del sistema operativo y sus intervalos de direcciones IP correspondientes.

Administración de clústeres de alta disponibilidad

Los sistemas de alta disponibilidad, como ASCS/SCS o bases de datos de SAP agrupados, pueden usar un administrador de clústeres con el agente de barrera de Azure como un dispositivo STONITH. Estos sistemas dependen de llegar a Azure Resource Manager. Resource Manager se usa para las consultas de estado sobre los recursos de Azure y para las operaciones para detener e iniciar máquinas virtuales. Como Resource Manager es un punto de conexión público, disponible en management.azure.com, la comunicación saliente de la máquina virtual debe ser capaz de acceder a él. Esta arquitectura se basa en un firewall central con reglas definidas por el usuario que enrutan el tráfico desde redes virtuales de SAP. Para ver alternativas, consulte las secciones anteriores.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Otro colaborador:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Comunidades

Considere usar estas comunidades para obtener respuestas a preguntas y ayuda con la configuración de una implementación:

Pasos siguientes