Editar

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 às suas necessidades. Essa redução pode se aplicar ao cenário SAP: menos máquinas virtuais (VMs), nenhuma alta disponibilidade ou SAP Web Dispatchers incorporados em vez de VMs discretas. Ele também pode se aplicar a alternativas ao design de rede, conforme descrito posteriormente neste artigo.

Os requisitos do cliente, orientados por 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 a abordagem certa para o seu negócio. Ele precisa ajudá-lo a proteger seus recursos do Azure, mas ainda fornecer uma solução de desempenho.

A recuperação de desastres (DR) 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 por DR, considere habilitar a DR em outra região do Azure. Para obter mais informações, consulte o artigo Visão geral da recuperação de desastres e diretrizes de infraestrutura para carga de trabalho SAP

Workflow

  • A rede local se conecta a um hub central por meio da Rota Expressa do Azure. A rede virtual de 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 de emparelhamento de rede virtual. Esta assinatura contém duas redes virtuais faladas:
    • 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 aterrissagem 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 do SAP. Use o guia de decisão na Estrutura de Adoção de Nuvem para Azure para determinar a melhor estratégia de assinatura para seu cenário.

Redes virtuais.A Rede Virtual do Azure conecta os recursos do Azure uns aos outros com segurança aprimorada. Nessa arquitetura, a rede virtual se conecta a um ambiente local por meio de uma Rota Expressa ou gateway de rede virtual privada (VPN) implantado no hub de uma topologia hub-spoke. O cenário de produção SAP usa suas próprias redes virtuais de spoke. Duas redes virtuais de fala 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 definir 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. Recomendamos que você use a Rota Expressa 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. Você pode implantar gateways de Rota Expressa ou VPN em zonas para ajudar a evitar falhas de zona. Consulte 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, você precisa usar endereços IP de SKU padrão.

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

Grupos de segurança do aplicativo. Para definir diretivas de segurança de rede refinadas em seus NSGs com base em cargas de trabalho centradas em aplicativos, use grupos de segurança de aplicativos em vez de endereços IP explícitos. Usando grupos de segurança de aplicativos, você pode agrupar VMs por finalidade, por exemplo, SAP SID. Os grupos de segurança de aplicativos ajudam a proteger aplicativos filtrando o tráfego de segmentos confiáveis da rede.

Ponto de extremidade privado. Muitos serviços do Azure operam como serviços públicos, por design, acessíveis através da Internet. Para permitir o acesso privado através do seu intervalo de rede privada, pode utilizar pontos de extremidade privados para alguns serviços. Pontos de extremidade privados são interfaces 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 Application Gateway é um balanceador de carga de tráfego da Web. Com sua funcionalidade Web Application Firewall, é o serviço ideal para expor aplicativos Web à Internet com maior segurança. O Gateway de Aplicativo pode atender clientes públicos (Internet) ou privados, ou ambos, dependendo da configuração.

Na arquitetura, o Application Gateway, 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 com seus sistemas SAP e inclui recursos que o Application Gateway 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 a SKU de proteção de rede DDoS, pois você verá descontos para o Firewall de Aplicativo Web do Gateway de Aplicativo.

Para obter o desempenho ideal, habilite o suporte HTTP/2 para Application Gateway, 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 pode usar o Standard Load Balancer para fornecer o endereço IP para o nome de host SAP virtual de sistemas não clusterizados quando IPs secundários em placas de rede do Azure não são uma opção. O uso do Standard Load Balancer em vez do Application Gateway para abordar o acesso de saída à Internet é abordado posteriormente 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 peering de fala para falar. Uma topologia estrela é usada, na qual a comunicação passa pelo hub. A separação das redes ajuda a proteger os aplicativos de 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 e outros. No diagrama de arquitetura, a rede de perímetro é denominada SAP perimeter - spoke virtual network. 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 isso que esses serviços de perímetro SAP frequentemente não estão localizados em uma assinatura e rede 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. Alterar ou remover 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 precise ser medido.

Arquitetura simplificada

Para abordar as recomendações deste artigo, mas limitar as desvantagens, você pode usar uma rede virtual de um único raio 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 término 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 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 e 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 NAT. A arquitetura simplificada também coloca o Application Gateway com sua própria sub-rede designada na rede virtual de perímetro SAP, como uma abordagem alternativa à rede virtual de hub.

Um gateway NAT é um serviço que fornece endereços IP públicos estáticos para conectividade de saída. O gateway NAT é atribuído a uma sub-rede. Todas as comunicações de saída usam os endereços IP do gateway NAT para acesso à Internet. As conexões de entrada não usam o gateway NAT. Aplicativos como o SAP Cloud Connector ou os serviços de atualização do VM OS 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ê poderá usar o gateway NAT como uma alternativa ao firewall central, somente em 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, porque pode configurar regras de firewall de destino em uma lista de IP definida do gateway 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 zona específica 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 os torna mais fáceis de entender. O resultado é que, muitas vezes, o panorama geral, como a arquitetura se encaixa em um cenário SAP maior que inclui várias trilhas e camadas do sistema, não é abordado.

Os serviços de rede central, como firewall, gateway NAT e servidores proxy, se forem implantados, são melhor 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 de sua organização e das políticas de negócios, convém considerar implementações separadas por camada ou uma produção e um ambiente de área restrita/teste.

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 nomeação e o agrupamento de recursos. Recomendamos um balanceador de carga para ASCS/SCS e ERS e outro para banco de dados, separados para cada SID SAP. Como alternativa, um único balanceador de carga para 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 fique 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 SID SAP também garante que o posicionamento em grupos de recursos corresponda ao de outros componentes de infraestrutura.
  • O Application Gateway, 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 despachante da Web para os mesmos sistemas SAP S/4HANA ou diferentes ambientes SAP. Recomendamos 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 forma centralizada ou dividida. A separação entre produção e não produção é frequentemente desejada.

Dimensionamento e design de sub-redes

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 Application Gateway recomenda uma sub-rede /24 para dimensionamento. Se optar por limitar a escala do Application Gateway, uma sub-rede menor poderá ser usada, no mínimo /26 ou maior. Não é possível usar as duas versões do Application Gateway (1 e 2) na mesma sub-rede.
  • Se você usar os Arquivos NetApp do Azure 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, precisará de mais espaço de endereço em suas sub-redes SAP, incluindo o perímetro SAP.
  • Serviços centrais como o Bastião do Azure 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 aplicativos com seus próprios conjuntos de regras. Em seguida, você pode limitar o acesso ao banco de dados a 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

Roteador 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 atrá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 e sub-redes faladas.

SAProuter é um túnel para a SAP ou para seus parceiros. Esta 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. O uso de túnel baseado em IPSEC não é coberto nesta arquitetura atualmente.

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 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, consulte Configuração do SAProuter com o Firewall do Azure.

Considerações de 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 de suas políticas, você pode usar um domínio de logon separado ou credenciais de usuário totalmente somente 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 separar o acesso adicional de um SAProuter comprometido em suas sub-redes de aplicativo. Você pode realizar esse isolamento desconectando o emparelhamento de rede virtual de perímetro SAP.

Considerações sobre a 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 é ideal. O nome do host virtual é vinculado a um IP, que é atribuído como uma configuração IP secundária 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, adicione o nome do host virtual em outra VM sem precisar alterar as tabelas de rotas ou a configuração do firewall. Todos eles estão configurados para usar o endereço IP virtual. Para obter mais informações, consulte 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 sua arquitetura. O segundo SAProuter aceita apenas conexões internas do primeiro SAProuter e fornece acesso a sistemas SAP e VMs individuais. Esse design permite que você separe o acesso e o gerenciamento entre equipes diferentes, se necessário. Para obter um exemplo de SAProuters em cascata, consulte Configuração do SAProuter com o Firewall do Azure.

SAP Fiori e WebGui

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 a proteger o aplicativo SAP. O Application Gateway com Web Application Firewall é o serviço ideal para essa finalidade.

Para usuários que acessam o nome de 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 do SAP Web Dispatcher obtém sessões round-robin do Application Gateway. Esse gateway de aplicativo de tráfego interno para o Web Dispatcher pode ser HTTP ou HTTPS, dependendo dos requisitos. O firewall de aplicativos da Web ajuda a proteger o SAP Web Dispatcher contra ataques vindos pela Internet com o conjunto de regras principais do OWASP. O SAP NetWeaver, geralmente vinculado ao Microsoft Entra ID por meio de logon único (SSO), executa a autenticação do usuário. Para obter as etapas necessárias para configurar o SSO para Fiori usando o Application Gateway, consulte 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 seja aberto apenas internamente, aberto para o Application Gateway via IP público ou acessível por qualquer outro meio de rede. Para obter mais informações, consulte 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 Application Gateway é 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 SAP Fiori do firewall para o Gateway de Aplicativo por meio de um endereço IP interno. Para obter mais informações, consulte Gateway de aplicativo após firewall. Como a criptografia de camada 7 TCP/IP já está em vigor via TLS, há um benefício limitado em usar um firewall nesse cenário e você não pode 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 com o 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ço 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 através da rede privada para os SAP Web Dispatchers, ignorando totalmente o Application Gateway. Uma terceira opção é usar endereços IP privados e públicos no Application Gateway, fornecendo acesso à Internet e à rede privada.

Você pode usar uma configuração semelhante com um endereço IP privado no Application Gateway 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 Application Gateway, você pode usar um balanceador de carga internamente. Você pode usar um balanceador de carga interno padrão com VMs do Web Dispatcher configuradas como um back-end round-robin. Nesse cenário, o balanceador de carga padrão é colocado com as VMs do Web Dispatcher na sub-rede do aplicativo de produção SAP e fornece balanceamento de carga ativo/ativo entre VMs do Web Dispatcher.

Para implantações voltadas para a Internet, recomendamos o Application Gateway com Web Application Firewall em vez de um balanceador de carga com um IP público.

SAP BTP (Business Technology Platform)

SAP BTP é um grande conjunto de aplicativos SAP, SaaS ou PaaS, normalmente acessados por meio de um endpoint público via 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, porque 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. Você não pode 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 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 do hub e através do 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 é 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. Eles compartilham a configuração e são mantidos 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, consulte a documentação do SAP.

Agente do SAP Analytics Cloud

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

A SAP fornece o serviço Private Link para SAP BTP. Ele permite conexões privadas entre serviços SAP BTP selecionados e serviços selecionados em sua assinatura do Azure e rede virtual. Quando você usa o serviço Private Link, a comunicação não é roteada pela Internet pública. Ele 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 serviço de Link Privado, porque 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 SAP BTP, a abordagem de serviço Private Link é preferida. Para outros, o SAP Cloud Connector é melhor. Para obter informações para ajudá-lo a decidir qual usar, consulte 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 do 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 com os serviços do Azure e sua rede, consulte 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 operando 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 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.

Para VMs que estão atrá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 o artigo Conectividade de ponto de extremidade público para VMs usando o Azure Standard Load Balancer em cenários de alta disponibilidade do SAP.

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 pela 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 IP / VMs privados, 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 SAP ASCS/SCS clusterizados ou bancos de dados, podem usar um gerenciador de cluster com o agente de cerca do Azure como um dispositivo STONITH. Esses sistemas dependem de alcançar o Gerenciador de Recursos do Azure. O Gerenciador de Recursos é usado para consultas de status sobre recursos do Azure e para operações para parar e iniciar VMs. Como o Gerenciador de Recursos é um ponto de extremidade público, disponível em management.azure.com, a comunicação de saída da VM precisa ser capaz de alcançá-lo. Essa arquitetura depende de um firewall central com regras definidas pelo usuário roteando o tráfego de redes virtuais SAP. Para obter alternativas, consulte 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 essas comunidades para obter respostas a perguntas e obter ajuda para configurar uma implantação:

Próximas etapas