Editar

Compartilhar via

Conexões de entrada e de saída da Internet para SAP no Azure

Máquinas Virtuais do Azure
Rede Virtual do Azure
Gateway de Aplicativo do Azure
Azure Load Balancer

Este artigo fornece um conjunto de práticas comprovadas para melhorar a segurança das conexões de entrada e saída da Internet para sua infraestrutura SAP no Azure.

Arquitetura

Diagrama que mostra uma solução para comunicação voltada para a Internet para SAP no Azure.

Baixe um Arquivo Visio das arquiteturas neste artigo.

Esta solução ilustra um ambiente de produção comum. Você pode reduzir o tamanho e o escopo da configuração para atender aos seus requisitos. Essa redução pode se aplicar ao cenário SAP: menos VMs (máquinas virtuais), sem alta disponibilidade ou SAP Web Dispatchers inseridos em vez de VMs discretas. Ela também pode se aplicar a alternativas ao design de rede, conforme descrito mais adiante neste artigo.

Os requisitos do cliente, orientados pelas políticas de negócios, exigirão adaptações à arquitetura, especialmente ao design da rede. Sempre que possível, incluímos alternativas. Muitas soluções são viáveis. Escolha uma abordagem adequada para seus negócios. Ela precisa ajudar a proteger seus recursos do Azure, mas ainda fornecer uma solução com bom desempenho.

A DR (recuperação de desastres) não é abordada nessa arquitetura. Para o design de rede, aplicam-se os mesmos princípios e design válidos para regiões de produção primária. Em seu design de rede, dependendo dos aplicativos que estão sendo protegidos pela DR, considere habilitar a DR em outra região do Azure. Para obter mais informações, veja o artigo Visão geral da recuperação de desastres e as diretrizes de infraestrutura para cargas de trabalho SAP.

Workflow

  • A rede local se conecta a um hub central por meio do Azure ExpressRoute. A rede virtual hub contém uma sub-rede de gateway, uma sub-rede do Firewall do Azure, uma sub-rede de serviços compartilhados e uma sub-rede do Gateway de Aplicativo do Azure.
  • O hub se conecta a uma assinatura de produção SAP por meio do emparelhamento de rede virtual. Essa assinatura contém duas redes virtuais spoke:
    • A rede virtual de perímetro SAP contém uma sub-rede de aplicativo de perímetro SAP.
    • A rede virtual de produção SAP contém uma sub-rede de aplicativo e uma sub-rede de banco de dados.
  • A assinatura de hub e a assinatura de produção SAP se conectam à Internet por meio de endereços IP públicos.

Componentes

Assinaturas. Essa arquitetura implementa a abordagem de zona de destino do Azure. Uma assinatura do Azure é usada para cada carga de trabalho. Uma ou mais assinaturas são usadas para serviços de TI centrais que contêm o hub de rede e serviços centrais compartilhados, como firewalls ou Active Directory e DNS. Outra assinatura é usada para a carga de trabalho de produção SAP. Use o guia de decisão no Cloud Adoption Framework para Azure a fim de determinar a melhor estratégia de assinatura para seu cenário.

Redes virtuais. A Rede Virtual do Azure conecta os recursos do Azure entre si com segurança avançada. Nessa arquitetura, a rede virtual se conecta a um ambiente local por meio de um ExpressRoute ou gateway de VPN (rede virtual privada) implantado no hub de uma topologia hub-spoke. O cenário de produção SAP usa suas próprias redes virtuais spoke. Duas redes virtuais spoke distintas executam tarefas diferentes, e as sub-redes fornecem segregação de rede.

A separação em sub-redes por carga de trabalho facilita o uso de NSGs (grupos de segurança de rede) para definição de regras de segurança para VMs de aplicativos ou serviços do Azure implantados.

Gateway com redundância de zona. Um gateway conecta redes distintas, estendendo sua rede local para a rede virtual do Azure. É recomendável usar o ExpressRoute para criar conexões privadas que não usam a Internet pública. Mas você também pode usar uma conexão site a site. Use gateways de VPN ou do Azure ExpressRoute com redundância de zona para se proteger contra falhas de zona. Confira Gateways de rede virtual com redundância de zona para obter uma explicação das diferenças entre uma implantação zonal e uma implantação com redundância de zona. Para uma implantação de zona dos gateways, é preciso usar endereços IP do SKU Standard.

NSGs. Para restringir o tráfego de rede bidirecional da rede virtual, crie NSGs e atribua-os a sub-redes específicas. Forneça segurança para sub-redes individuais usando NSGs específicos de carga de trabalho.

Grupos de segurança do aplicativo. Para definir políticas de segurança de rede refinadas em seus NSGs baseados em cargas de trabalho que são centralizadas nos aplicativos, use grupos de segurança de aplicativo em vez de endereços IP explícitos. Usando grupos de segurança de aplicativos, é possível agrupar VMs por finalidade, por exemplo, SAP SID. Os grupos de segurança de aplicativos ajudam a proteger aplicativos com a filtragem do tráfego de segmentos confiáveis da rede.

Ponto de extremidade privado. Muitos serviços do Azure operam como serviços públicos, por definição, acessíveis pela Internet. Para permitir o acesso privado por meio do seu intervalo de rede privada, você pode usar pontos de extremidade privados para alguns serviços. Os pontos de extremidade privados são adaptadores de rede em sua rede virtual. Eles efetivamente trazem o serviço para o seu espaço de rede privada.

Gateway de Aplicativo do Azure. O Gateway de Aplicativo é um balanceador de carga do tráfego da Web. Com sua funcionalidade de Firewall de Aplicativo Web, é o serviço ideal para expor aplicativos Web à Internet com mais segurança. O Gateway de Aplicativo pode atender a clientes públicos (Internet) ou privados, ou ambos, dependendo da configuração.

Na arquitetura, o Gateway de Aplicativo, usando um endereço IP público, permite conexões de entrada para o cenário SAP por HTTPS. Seu pool de back-end é de duas ou mais VMs SAP Web Dispatcher, acessadas em round robin e que fornecem alta disponibilidade. O gateway de aplicativo é um proxy reverso e balanceador de carga de tráfego da Web, mas não substitui o SAP Web Dispatcher. O SAP Web Dispatcher fornece integração de aplicativos a seus sistemas SAP e inclui recursos que o Gateway de Aplicativo por si só não fornece. A autenticação do cliente, quando chega aos sistemas SAP, é realizada pela camada de aplicativos SAP nativamente ou por meio de logon único. Ao habilitar a proteção contra DDoS do Azure, considere usar o SKU de proteção de rede contra DDoS, pois você verá descontos para o Firewall do Aplicativo Web do Gateway de Aplicativo.

Para obter o desempenho ideal, habilite o suporte ao HTTP/2 para Gateway de Aplicativo, SAP Web Dispatcher e SAP NetWeaver.

Azure Load Balancer. O Azure Standard Load Balancer fornece elementos de rede para o design de alta disponibilidade dos sistemas SAP. Para sistemas clusterizados, o Standard Load Balancer fornece o endereço IP virtual para o serviço de cluster, como instâncias do ASCS/SCS e bancos de dados em execução nas VMs. Você também poderá usar o Standard Load Balancer para fornecer o endereço IP ao nome de host SAP virtual de sistemas não clusterizados quando IPs secundários em placas de rede do Azure não forem uma opção. O uso do Standard Load Balancer em vez do Gateway de Aplicativo para abordar o acesso de saída à Internet é explicado mais adiante neste artigo.

Design de rede

A arquitetura usa duas redes virtuais discretas, ambas as redes virtuais spoke que são emparelhadas para a rede virtual do hub central. Não há um emparelhamento spoke-to-spoke. Uma topologia em estrela é usada, na qual a comunicação passa pelo hub. A separação das redes ajuda a proteger os aplicativos contra violações.

Uma rede de perímetro específica do aplicativo (também conhecida como DMZ) contém os aplicativos voltados para a Internet, como SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent, entre outros. No diagrama de arquitetura, a rede de perímetro é denominada perímetro SAP – rede virtual spoke. Devido às dependências dos sistemas SAP, a equipe SAP normalmente faz a implantação, a configuração e o gerenciamento desses serviços. Por essa razão, esses serviços de perímetro SAP frequentemente não estão localizados em uma rede e assinatura de hub central. Muitas vezes, os desafios organizacionais se devem ao posicionamento do hub central de aplicativos ou serviços específicos da carga de trabalho.

Estes são alguns dos benefícios de usar uma rede virtual de perímetro SAP separada:

  • Isolamento rápido e imediato de serviços comprometidos se uma violação for detectada. A remoção do emparelhamento de rede virtual do perímetro SAP para o hub isola imediatamente as cargas de trabalho de perímetro SAP e os aplicativos de rede virtual de aplicativos SAP da Internet. A alteração ou remoção de uma regra NSG que permite acesso afeta apenas novas conexões e não corta conexões existentes.
  • Controles mais rigorosos na rede virtual e na sub-rede, com um bloqueio rígido nos parceiros de comunicação dentro e fora da rede de perímetro SAP e das redes de aplicativos SAP. Você pode estender o controle aprimorado a usuários autorizados e métodos de acesso em aplicativos de perímetro SAP, com diferentes back-ends de autorização, acesso privilegiado ou credenciais de entrada para aplicativos de perímetro SAP.

As desvantagens são o aumento da complexidade e os custos extras de emparelhamento de rede virtual para tráfego SAP vinculado à Internet (porque a comunicação precisa passar pelo emparelhamento de rede virtual duas vezes). O impacto da latência no tráfego de emparelhamento spoke-hub-spoke depende de qualquer firewall que esteja em vigor e precisa ser medido.

Arquitetura simplificada

Para aproveitar as recomendações deste artigo, mas limitar as desvantagens, você pode usar uma única rede virtual spoke para o perímetro e os aplicativos SAP. A arquitetura a seguir contém todas as sub-redes em uma única rede virtual de produção SAP. O benefício do isolamento imediato pelo encerramento do emparelhamento de rede virtual para o perímetro SAP, se ele estiver comprometido, não está disponível. Nesse cenário, as alterações nos NSGs afetam apenas novas conexões.

Diagrama que mostra uma arquitetura simplificada para comunicação voltada para a Internet para SAP no Azure.

Baixe um Arquivo Visio das arquiteturas neste artigo.

Para implantações menores em tamanho e escopo, a arquitetura simplificada pode ser mais adequada e ainda adere aos princípios da arquitetura mais complexa. Este artigo, salvo indicação em contrário, refere-se à arquitetura mais complexa.

A arquitetura simplificada usa um gateway da NAT na sub-rede de perímetro SAP. Esse gateway fornece conectividade de saída para o SAP Cloud Connector e o SAP Analytics Cloud Agent, além de atualizações do sistema operacional para as VMs implantadas. Como o SAProuter requer conexões de entrada e saída, o caminho de comunicação do SAProuter passa pelo firewall em vez de usar o gateway da NAT. A arquitetura simplificada também coloca o Gateway de Aplicativo com sua própria sub-rede designada na rede virtual de perímetro SAP, como uma abordagem alternativa à rede virtual hub.

Um gateway da NAT é um serviço que fornece endereços IP públicos estáticos para conectividade de saída. O gateway da NAT é atribuído a uma sub-rede. Todas as comunicações de saída usam os endereços IP do gateway da NAT para acesso à Internet. As conexões de entrada não usam o gateway da NAT. Aplicativos como o SAP Cloud Connector, ou os serviços de atualização do sistema operacional da VM que acessam repositórios na Internet, podem usar o gateway NAT em vez de rotear todo o tráfego de saída pelo firewall central. Frequentemente, as regras definidas pelo usuário são implementadas em todas as sub-redes para forçar o tráfego vinculado à Internet de todas as redes virtuais por meio do firewall central.

Dependendo de seus requisitos, você pode usar o gateway NAT como uma alternativa ao firewall central, para conexões de saída. Ao fazer isso, você pode reduzir a carga no firewall central enquanto se comunica com pontos de extremidade públicos permitidos pelo NSG. Você também obtém controle de IP de saída, pois pode configurar regras de firewall de destino em uma lista definida de IPs do gateway da NAT. Os exemplos incluem alcançar pontos de extremidade públicos do Azure que são usados por serviços públicos, repositórios de patches do sistema operacional ou interfaces de terceiros.

Para uma configuração de alta disponibilidade, lembre-se de que o gateway NAT é implantado apenas em uma única zona e não é redundante entre zonas no momento. Com um único gateway NAT, ele não é ideal para implantações SAP que usam implantação com redundância de zona (entre zonas) para máquinas virtuais.

Uso de componentes de rede em um cenário SAP

Um documento de arquitetura normalmente representa apenas um sistema ou cenário SAP. Isso facilita o entendimento. O que ocorre é que, muitas vezes, o panorama geral, como a arquitetura se encaixa em um cenário SAP maior que inclui várias faixas e camadas do sistema, não é abordado.

Os serviços de rede central, como firewall, gateway da NAT e servidores proxy, se forem implantados, são mais bem usados em todo o cenário SAP de todas as camadas: produção, pré-produção, desenvolvimento e área restrita. Dependendo de seus requisitos, do tamanho da sua organização e das políticas de negócios, convém considerar implementações separadas por camada ou um ambiente de área restrita/teste e um de produção.

Os serviços que normalmente atendem a um sistema SAP são melhor separados conforme descrito aqui:

  • Os balanceadores de carga devem ser dedicados a serviços individuais. A política da empresa determina a nomenclatura e o agrupamento de recursos. É recomendável um balanceador de carga para ASCS/SCS e ERS e outro para banco de dados, separados para cada SAP SID. Como alternativa, um único balanceador de carga para os clusters (A)SCS, ERS e DB de um sistema SAP também é um bom design. Essa configuração ajuda a garantir que a solução de problemas não se torne complexa, com muitos pools de front-end e back-end e regras de balanceamento de carga, tudo em um único balanceador de carga. Um único balanceador de carga por SAP SID também garante que o posicionamento em grupos de recursos corresponda ao de outros componentes de infraestrutura.
  • O Gateway de Aplicativo, como um balanceador de carga, permite vários back-ends, front-ends, configurações HTTP e regras. A decisão de usar um gateway de aplicativo para vários usos é mais comum aqui porque nem todos os sistemas SAP no ambiente exigem acesso público. Vários usos nesse contexto incluem diferentes portas de dispatcher da Web para os mesmos sistemas SAP S/4HANA ou diferentes ambientes SAP. É recomendável pelo menos um gateway de aplicativo por camada (produção, não produção e área restrita), a menos que a complexidade e o número de sistemas conectados se tornem muito altos.
  • Os serviços SAP, como SAProuter, Cloud Connector e Analytics Cloud Agent, são implantados com base nos requisitos do aplicativo, de maneira centralizada ou dividida. A separação entre produção e não produção é frequentemente desejada.

Dimensionamento e design da sub-rede

Ao projetar sub-redes para seu cenário SAP, certifique-se de seguir os princípios de dimensionamento e design:

  • Vários serviços de PaaS (plataforma como serviço) do Azure exigem suas próprias sub-redes designadas.
  • O Gateway de Aplicativo recomenda uma sub-rede /24 para dimensionamento. Se optar por limitar a escala do Gateway de Aplicativo, uma sub-rede menor poderá ser usada, no mínimo /26 ou maior. Não é possível usar as duas versões do Gateway de Aplicativo (1 e 2) na mesma sub-rede.
  • Se você usar o Azure NetApp Files para seus compartilhamentos NFS/SMB ou armazenamento de banco de dados, uma sub-rede designada será necessária. Uma sub-rede /24 é o padrão. Use seus requisitos para determinar o dimensionamento adequado.
  • Se você usar nomes de host virtual SAP, será necessário mais espaço de endereço em suas sub-redes SAP, incluindo o perímetro SAP.
  • Serviços centrais, como o Azure Bastion ou o Firewall do Azure, normalmente gerenciados por uma equipe de TI central, exigem suas próprias sub-redes dedicadas de tamanho suficiente.

Usando sub-redes dedicadas para bancos de dados e aplicativos SAP, você pode definir NSGs para serem mais rigorosos, o que ajuda a proteger ambos os tipos de aplicativo com seus próprios conjuntos de regras. Em seguida, é possível limitar o acesso do banco de dados aos aplicativos SAP com mais facilidade, sem precisar recorrer a grupos de segurança de aplicativos para controle granular. Separar o aplicativo SAP e as sub-redes do banco de dados também facilita o gerenciamento das regras de segurança nos NSGs.

Serviços SAP

SAProuter

Você pode usar o SAProuter para permitir que terceiros, como o suporte SAP ou seus parceiros, acessem seu sistema SAP. O SAProuter é executado em uma VM no Azure. As permissões de rota para usar o SAProuter são armazenadas em um arquivo simples chamado saprouttab. As entradas saprouttab permitem a conexão de qualquer porta TCP/IP para um destino de rede por trás do SAProuter, normalmente suas VMs do sistema SAP. O acesso remoto pelo suporte SAP depende do SAProuter. A arquitetura principal usa o design descrito anteriormente, com uma VM SAProuter em execução na rede virtual de perímetro SAP designada. Por meio do emparelhamento de rede virtual, o SAProuter se comunica com seus servidores SAP que são executados em sua própria rede virtual spoke e sub-redes.

SAProuter é um túnel para SAP ou para seus parceiros. Essa arquitetura descreve o uso do SAProuter com o uso do SNC para estabelecer um túnel de aplicativo criptografado (camada de rede 7) para SAP/parceiros. Atualmente, o uso de túnel baseado em IPSEC não é coberto nessa arquitetura.

Os seguintes recursos ajudam a proteger o caminho de comunicação pela Internet:

  • O Firewall do Azure ou um NVA de terceiros fornece o ponto de entrada do IP público em suas redes do Azure. As regras de firewall limitam a comunicação apenas a endereços IP autorizados. Para sua conexão com o suporte SAP, a nota SAP 48243 – Integrando o software SAProuter em um ambiente de firewall documenta os endereços IP dos roteadores SAP.
  • Assim como as regras de firewall, as regras de segurança de rede permitem a comunicação na porta do SAProuter, normalmente 3299 com o destino designado.
  • Você mantém as regras de permissão/negação do SAProuter no arquivo saprouttab, especificando quem pode entrar em contato com o SAProuter e qual sistema SAP pode ser acessado.
  • Outras regras NSG estão em vigor nas respectivas sub-redes na sub-rede de produção SAP que contém os sistemas SAP.

Para conhecer as etapas de configuração do SAProuter com o Firewall do Azure, confira Configuração do SAProuter com o Firewall do Azure.

Considerações sobre segurança do SAProuter

Como o SAProuter não opera na mesma sub-rede de aplicativos que seus sistemas SAP, os mecanismos de entrada para o sistema operacional podem ser diferentes. Dependendo das suas políticas, você pode usar um domínio de logon separado ou credenciais de usuário que sejam inteira e exclusivamente de host para o SAProuter. Se houver uma violação de segurança, o acesso em cascata aos sistemas SAP internos não será possível devido à base de credenciais diferente. A separação de rede nesse caso, conforme descrito anteriormente, pode desatrelar outros acessos de um SAProuter comprometido nas sub-redes de aplicativo. Você pode fazer esse isolamento desconectando o emparelhamento de rede virtual do perímetro SAP.

Considerações sobre alta disponibilidade do SAProuter

Como o SAProuter é um arquivo executável simples com uma tabela de permissões de rota baseada em arquivo, ele pode ser facilmente iniciado. O aplicativo não tem alta disponibilidade interna. Se houver uma falha de VM ou aplicativo, o serviço precisará ser iniciado em outra VM. Usar um nome de host virtual para o serviço SAProuter é o ideal. O nome do host virtual é vinculado a um IP, que é atribuído como uma configuração de IP secundário com a NIC da VM ou a um balanceador de carga interno conectado à VM. Nessa configuração, se o serviço SAProuter precisar ser movido para outra VM, a configuração IP do nome do host virtual do serviço poderá ser removida. Em seguida, você adiciona o nome do host virtual em outra VM sem precisar alterar as tabelas de rotas ou a configuração do firewall. Todas elas estão configuradas para usar o endereço IP virtual. Para obter mais informações, confira Usar nomes de host virtual SAP com Linux no Azure.

SAProuters em cascata

Para implementar SAProuters em cascata, você pode definir até dois SAProuters para conexões de suporte SAP. O primeiro SAProuter, em execução na sub-rede do aplicativo de perímetro SAP, fornece acesso a partir do firewall central e do SAP ou SAProuters parceiros. Os únicos destinos permitidos são outros SAProuters, executados com cargas de trabalho específicas. Os SAProuters em cascata podem usar separação por camada, por região ou por SID, dependendo da arquitetura. O segundo SAProuter aceita apenas conexões internas do primeiro SAProuter e fornece acesso a sistemas SAP e VMs individuais. Esse design permite separar o acesso e o gerenciamento entre equipes diferentes, se necessário. Para obter um exemplo de SAProuters em cascata, confira Configuração do SAProuter com o Firewall do Azure.

SAP Fiori e WebGui

O SAP Fiori e outros front-ends HTTPS para aplicativos SAP são frequentemente consumidos de fora da rede corporativa interna. A necessidade de estar disponível na Internet requer uma solução de alta segurança para ajudar na proteção do aplicativo SAP. O Gateway de Aplicativo com Firewall de Aplicativo Web é o serviço ideal para essa finalidade.

Para usuários e aplicativos que acessam o nome do host público do IP público vinculado ao Gateway de Aplicativo, a sessão HTTPS é encerrada no Gateway de Aplicativo. Um pool de back-end de duas ou mais VMs SAP Web Dispatcher obtém sessões round robin do Gateway de Aplicativo. Esse gateway de aplicativo de tráfego interno para o Web Dispatcher pode ser HTTP ou HTTPS, dependendo dos requisitos. Com HTTPS entre VMs do Gateway de Aplicativo e do Web Dispatcher, use um certificado e uma cadeia de certificados bem conhecidos pela equipe SAP para qualquer rotação periódica de certificados. O firewall do aplicativo Web ajuda a proteger o SAP Web Dispatcher contra ataques que chegam pela Internet com o conjunto de regras principais OWASP. O SAP NetWeaver, geralmente associado ao Microsoft Entra ID por meio de SSO (logon único), executa a autenticação do usuário. Para ver as etapas necessárias para configurar o SSO para Fiori usando o Gateway de Aplicativo, confira Configuração de logon único usando SAML e Microsoft Entra ID para URLs públicas e internas.

Lembre-se de que você precisa proteger o SAP Web Dispatcher em qualquer situação, mesmo que ele esteja aberto apenas internamente, acessado por meio do Gateway de Aplicativo por meio de IP público ou acessível por outros meios de rede. Para obter mais informações, confira Informações de segurança para o SAP Web Dispatcher.

Firewall do Azure e Gateway de Aplicativo

Todo o tráfego da Web fornecido pelo Gateway de Aplicativo é baseado em HTTPS e criptografado com o certificado TLS fornecido. Você pode usar o Firewall do Azure como um ponto de entrada para a rede corporativa, por meio de seu IP público e, em seguida, rotear o tráfego do SAP Fiori do firewall para o Gateway de Aplicativo por meio de um endereço IP interno. Para obter mais informações, confira Gateway de Aplicativo depois do firewall. Como a criptografia de camada 7 do TCP/IP já está em vigor via TLS, há um benefício limitado em usar um firewall nesse cenário, além de não ser possível executar a inspeção de pacotes. O Fiori se comunica por meio do mesmo endereço IP externo para tráfego de entrada e saída, o que normalmente não é necessário para implantações do SAP Fiori.

Há alguns benefícios de uma implantação de firewall de camada 4 e Gateway de Aplicativo em tandem:

  • Possível integração ao gerenciamento de políticas de segurança em toda a empresa.
  • O tráfego de rede que viola as regras de segurança já foi descartado, portanto, não requer inspeção.

Essa implantação combinada é uma boa arquitetura. O método para lidar com o tráfego de entrada da Internet depende da arquitetura corporativa geral. Você também precisa considerar como a arquitetura de rede geral se ajusta aos métodos de acesso do espaço de endereços IP interno, como clientes locais. Essa consideração é abordada na próxima seção.

Gateway de Aplicativo para endereços IP internos (opcional)

Essa arquitetura se concentra em aplicativos voltados para a Internet. Há várias opções disponíveis para clientes que acessam o SAP Fiori, a interface do usuário da Web de um sistema SAP NetWeaver ou outra interface SAP HTTPS por meio de um endereço IP interno e privado. Um cenário é tratar todo o acesso à Fiori como acesso público, por meio do IP público. Outra opção é usar o acesso direto à rede pela rede privada para os SAP Web Dispatchers, ignorando totalmente o Gateway de Aplicativo. Uma terceira opção é usar endereços IP privados e públicos no Gateway de Aplicativo, fornecendo acesso à Internet e à rede privada.

Você pode usar uma configuração semelhante com um endereço IP privado no Gateway de Aplicativo para acesso de rede somente privada ao cenário SAP. O endereço IP público, nesse caso, é usado apenas para fins de gerenciamento e não tem um ouvinte associado a ele.

Como alternativa ao uso do Gateway de Aplicativo, você pode usar um balanceador de carga internamente. É possível usar um balanceador de carga interno padrão com VMs Web Dispatcher configuradas como um back-end round robin. Nesse cenário, o balanceador de carga padrão é colocado com as VMs Web Dispatcher na sub-rede do aplicativo de produção SAP e fornece balanceamento de carga ativo/ativo entre as VMs Web Dispatcher.

Para implantações voltadas para a Internet, é recomendável o Gateway de Aplicativo com Firewall do Aplicativo Web em vez de um balanceador de carga com um IP público.

SAP BTP (Business Technology Platform)

O SAP BTP é um grande conjunto de aplicativos SAP, SaaS ou PaaS, normalmente acessados por meio de um ponto de extremidade público pela Internet. O SAP Cloud Connector é frequentemente usado para fornecer comunicação para aplicativos executados em redes privadas, como um sistema SAP S/4HANA em execução no Azure. O SAP Cloud Connector é executado como um aplicativo em uma VM. Ele requer acesso à Internet de saída para estabelecer um túnel HTTPS criptografado por TLS com o SAP BTP. Ele atua como um proxy de invocação reversa entre o intervalo de IP privado em sua rede virtual e os aplicativos SAP BTP. Devido a esse suporte de invocação reversa, não há necessidade de portas de firewall abertas ou outro acesso para conexões de entrada, pois a conexão da rede virtual é de saída.

Por padrão, as VMs têm acesso à Internet de saída nativamente no Azure. O endereço IP público usado para tráfego de saída, quando não há nenhum endereço IP público dedicado associado à máquina virtual, é escolhido aleatoriamente no pool de IPs públicos na região específica do Azure. Não é possível controlá-lo. Para garantir que as conexões de saída sejam feitas por meio de um serviço e endereço IP controlados e identificáveis, você pode usar um dos seguintes métodos:

  • Um gateway da NAT associado à sub-rede ou ao balanceador de carga e seu endereço IP público.
  • Servidores proxy HTTP que você opera.
  • Uma rota definida pelo usuário que força o tráfego de rede a fluir para um dispositivo de rede, como um firewall.

O diagrama de arquitetura mostra o cenário mais comum: roteamento de tráfego vinculado à Internet para a rede virtual hub e pelo firewall central. Você precisa definir configurações adicionais no SAP Cloud Connector para se conectar à sua conta SAP BTP.

Alta disponibilidade para o SAP Cloud Connector

A alta disponibilidade está incorporada ao SAP Cloud Connector. O Cloud Connector é instalado em duas VMs. A instância principal está ativa e a instância de sombra está conectada a ela. Elas compartilham a configuração e são mantidas em sincronia nativamente. Se a instância principal não estiver disponível, a VM secundária tentará assumir a função principal e restabelecer o túnel TLS para o SAP BTP. Um ambiente Cloud Connector de alta disponibilidade é mostrado na arquitetura. Você não precisa de nenhuma outra tecnologia do Azure, como um balanceador de carga ou software de cluster, para a configuração. Para obter detalhes sobre configuração e operação, confira a documentação SAP.

SAP Analytics Cloud Agent

Para alguns cenários de aplicativo, o SAP Analytics Cloud Agent é um aplicativo que é instalado em uma VM. Ele usa o SAP Cloud Connector para conectividade do SAP BTP. Nessa arquitetura, a VM SAP Analytics Cloud Agent é executada na sub-rede do aplicativo de perímetro SAP, juntamente com as VMs SAP Cloud Connector. Para fluxo de tráfego de redes privadas, como uma rede virtual do Azure, para o SAP BTP via SAP Analytics Cloud Agent, confira a documentação SAP.

A SAP fornece o Private Link Service para SAP BTP. A solução permite conexões privadas entre serviços selecionados do SAP BTP e serviços selecionados em sua assinatura do Azure e rede virtual. Quando você usa o Private Link Service, a comunicação não é roteada pela Internet pública. Ela permanece no backbone de rede global do Azure de alta segurança. A comunicação com os serviços do Azure ocorre por meio de um espaço de endereço privado. A proteção aprimorada de exfiltração de dados é incorporada quando você usa o Private Link Service, pois o ponto de extremidade privado mapeia o serviço específico do Azure para um endereço IP. O acesso é limitado ao serviço do Azure mapeado.

Para alguns cenários de integração do SAP BTP, a abordagem do Private Link Service é a preferida. Para outros, o SAP Cloud Connector é melhor. Para obter informações que ajudam a decidir qual deles usar, confira Executando o Cloud Connector e o SAP Private Link lado a lado.

SAP RISE/ECS

Se a SAP operar seu sistema SAP sob um contrato SAP RISE/ECS, a SAP será o parceiro de serviços gerenciados. O ambiente SAP é implantado pela SAP. Na arquitetura da SAP, a arquitetura mostrada aqui não se aplica aos seus sistemas que são executados no RISE com SAP/ECS. Para obter informações sobre como integrar esse tipo de cenário SAP aos serviços do Azure e sua rede, confira a documentação do Azure.

Outros requisitos de comunicação SAP

Considerações adicionais sobre comunicações vinculadas à Internet podem se aplicar a um cenário SAP em operação no Azure. O fluxo de tráfego nessa arquitetura usa um firewall central do Azure para esse tráfego de saída. As regras definidas pelo usuário nas redes virtuais spoke roteiam solicitações de tráfego vinculadas à Internet para o firewall. Como alternativa, você pode usar gateways da NAT em sub-redes específicas, comunicação de saída padrão do Azure, endereços IP públicos em VMs (não recomendado) ou um balanceador de carga público com regras de saída. Os cenários típicos alcançam pontos de extremidade públicos da ID do Microsoft Entra, APIs de gerenciamento do Azure em management.azure.com e serviços de aplicativos de terceiros ou aplicativos governamentais por meio do acesso à rede de saída.

Devido a alterações no acesso de saída padrão no Azure, verifique se um acesso de saída escalonável está definido. Para VMs que estão por trás de um balanceador de carga interno padrão, como aqueles em ambientes clusterizados, lembre-se de que o Standard Load Balancer modifica o comportamento para conectividade pública. Para obter mais informações, consulte Conectividade de ponto de extremidade público para VMs usando o Azure Standard Load Balancer em cenários de alta disponibilidade SAP.

Para obter mais informações sobre a conectividade de saída padrão de VMs, consulte Opções de roteamento para VMs de sub-redes privadas no blog Rede do Azure.

Atualizações do sistema operacional

As atualizações do sistema operacional geralmente estão localizadas atrás de um ponto de extremidade público e são acessadas via Internet. Se nenhum repositório corporativo e gerenciamento de atualizações estiverem em vigor espelhando atualizações do sistema operacional de fornecedores em endereços IPs privados/VMs, sua carga de trabalho SAP precisará acessar os repositórios de atualização dos fornecedores.

Para sistemas operacionais Linux, você pode acessar os seguintes repositórios se obtiver a licença do sistema operacional do Azure. Se você comprar licenças diretamente e levá-las para o Azure (BYOS), entre em contato com o fornecedor do sistema operacional sobre maneiras de se conectar aos repositórios do sistema operacional e seus respectivos intervalos de endereços IP.

Gerenciamento de cluster de alta disponibilidade

Sistemas altamente disponíveis, como bancos de dados ou SAP ASCS/SCS clusterizados, podem usar um gerenciador de cluster com o agente limitador do Azure como um dispositivo STONITH. Esses sistemas dependem do acesso ao Azure Resource Manager. O Resource Manager é usado para consultas de status sobre recursos do Azure e para operações de interrupção e inicialização de VMs. Como o Resource Manager é um ponto de extremidade público, disponível em management.azure.com, a comunicação de saída da VM precisa ser capaz de acessá-lo. Essa arquitetura depende de um firewall central com regras definidas pelo usuário roteando o tráfego de redes virtuais SAP. Para ver alternativas, veja as seções anteriores.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Outro colaborador:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Comunidades

Considere usar estas comunidades para obter respostas a perguntas e obter ajuda para configurar uma implantação:

Próximas etapas