Editar

Partilhar via

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

Azure Virtual Machines
Azure Virtual Network
Azure Application Gateway
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 do 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), sem 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 mais adiante neste artigo.

Os requisitos do cliente, impulsionados por políticas de negócios, exigirão adaptações na arquitetura, particularmente no 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 nesta arquitetura. Para a conceção da rede, aplicam-se os mesmos princípios e conceção válidos para as 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

Fluxo de Trabalho

  • A rede local se conecta a um hub central por meio da Rota Expressa do Azure. A rede virtual do 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 subscrição 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 do hub e a assinatura de produção SAP se conectam à Internet por meio de endereços IP públicos.

Componentes

Subscrições. 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 Ative 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 for Azure para determinar a melhor estratégia de assinatura para seu cenário.

Redes virtuais. A Rede Virtual do Azure conecta recursos do Azure entre si 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 faladas. Duas redes virtuais 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 redundante 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 usem a Internet pública. Você também pode usar uma conexão site a site . Use gateways de VPN ou Rota Expressa do Azure com redundância de zona para se proteger contra 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 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 de aplicativos. Para definir políticas 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 sua rede.

Ponto de extremidade privado. Muitos serviços do Azure operam como serviços públicos, por design acessíveis pela Internet. Para permitir o acesso privado através do seu intervalo de rede privada, pode utilizar terminais 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.

Azure Application Gateway. O Application Gateway é um balanceador de carga de tráfego da Web. Com a sua funcionalidade Web Application Firewall, é o serviço ideal para expor aplicações Web à Internet com segurança melhorada. O Application Gateway 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 é composto por duas ou mais VMs SAP Web Dispatcher, acessadas round-robin e oferecendo 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 aplicação SAP nativamente ou através do 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 Application Gateway Web Application Firewall.

Para um desempenho ideal, habilite o suporte HTTP/2 para Application Gateway, SAP Web Dispatcher e SAP NetWeaver.

Balanceador de Carga do Azure. O Azure Standard Load Balancer fornece elementos de rede para o design de alta disponibilidade dos seus sistemas SAP. Para sistemas clusterizados, o Standard Load Balancer fornece o endereço IP virtual para o serviço de cluster, como instâncias ASCS/SCS e bancos de dados executados em VMs. Você também pode usar o Balanceador de Carga Padrão 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 Balanceador de Carga Padrão em vez do Application Gateway para endereçar o acesso de saída à Internet é abordado mais adiante neste artigo.

Design de rede

A arquitetura usa duas redes virtuais discretas, ambas redes virtuais faladas que são emparelhadas para a rede virtual do hub central. Não há espreitamento falado. Uma topologia em estrela é usada, na qual a comunicação passa pelo hub. A separação das redes ajuda a proteger as aplicações 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 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, configuração e 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 são devidos a esse posicionamento de 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 detetada. A remoção do emparelhamento de rede virtual do perímetro SAP para o hub isola imediatamente as cargas de trabalho do 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 maior controle 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 login para aplicativos de perímetro SAP.

As desvantagens são o aumento da complexidade e os custos extras de emparelhamento de rede virtual para o 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 neste artigo, mas limitar as desvantagens, você pode usar uma rede virtual de raios únicos 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 do 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 do 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 sistema operacional VM que acessam repositórios na Internet podem usar o gateway NAT em vez de rotear todo o tráfego de saída através do firewall central. Frequentemente, as regras definidas pelo usuário são implementadas em todas as sub-redes para forçar o tráfego ligado à Internet de todas as redes virtuais através do firewall central.

Dependendo dos seus requisitos, você poderá 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 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 única zona e não é redundante entre zonas. 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. Isto torna-os mais fáceis de compreender. O resultado é que, frequentemente, 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 NAT e servidores proxy, se implantados, são melhor usados em todo o cenário SAP de todos os níveis: produção, pré-produção, desenvolvimento e sandbox. Dependendo dos 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 produção e um ambiente de teste/área restrita.

Os serviços que normalmente servem 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 front-end e back-end e regras de balanceamento de carga 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 da 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 neste contexto incluem diferentes portas web dispatcher 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, centralmente ou divididos. 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, siga os princípios de dimensionamento e design:

  • Vários serviços de plataforma como serviço (PaaS) 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 ambas as 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ê usa 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 Azure Bastion ou o Firewall do Azure, normalmente gerenciados por uma equipe central de TI, 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 mais facilmente, sem a necessidade de 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 SAP

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 dentro da rede virtual de perímetro SAP designada. Através do emparelhamento de rede virtual, o SAProuter comunica com os seus servidores SAP que são executados na sua própria rede virtual spoke e sub-redes.

O SAProuter é um túnel para o SAP ou para os seus parceiros. Esta arquitetura descreve o uso do SAProuter com SNC para estabelecer um túnel de aplicativo criptografado (camada de rede 7) para SAP/parceiros. O uso do 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 - A integração do software SAProuter em um ambiente de firewall documenta os endereços IP dos roteadores SAP.
  • 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 respetivas 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 login 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 SAProuter. Se houver uma violação de segurança, o acesso em cascata aos sistemas internos da SAP não é possível devido à base de credenciais diferente. A separação de rede nesse caso, conforme descrito anteriormente, pode dissociar mais o acesso de um SAProuter comprometido às sub-redes do seu aplicativo. Você pode realizar esse isolamento desconectando o emparelhamento de rede virtual de 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 integrada. 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 está vinculado a um IP, que é atribuído como uma configuração de 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, você adiciona 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.

Roteadores SAP em cascata

Para implementar SAProuters em cascata, você pode definir até dois SAProuters para conexões de suporte SAP. O primeiro roteador SAP, executado na sub-rede do aplicativo de perímetro SAP, fornece acesso a partir do firewall central e de roteadores SAP ou parceiros. Os únicos destinos permitidos são outros SAProuters, executados com cargas de trabalho específicas. Os roteadores 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 individuais e VMs. Este design permite-lhe separar o acesso e a gestão entre diferentes equipas, se necessário. Para obter um exemplo de um 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 e aplicativos que acessam o nome de host público do IP público vinculado ao Application Gateway, a sessão HTTPS é encerrada no Application Gateway. 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. Com HTTPS entre VMs do Application Gateway 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 vindos pela Internet com o conjunto de regras principais do OWASP. O SAP NetWeaver, geralmente vinculado ao Microsoft Entra ID por meio do 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 ID do Microsoft Entra 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 Application Gateway via IP público ou acessível por outros meios de rede. Para obter mais informações, consulte Informações de segurança para 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 do SAP Fiori do firewall para o Application Gateway por meio de um endereço IP interno. Para obter mais informações, consulte Application Gateway after firewall. Como a criptografia TCP/IP layer-7 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 através 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 um Application Gateway tandem e implantação de firewall de camada 4:

  • 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 sua 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. Esta consideração é abordada na próxima seção.

Application Gateway 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 privado. Um cenário é tratar todo o acesso ao Fiori como acesso público, através do IP público. Outra opção é usar o acesso direto à rede privada 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, neste 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.

Plataforma de Tecnologia Empresarial SAP (BTP)

O SAP BPT é um grande conjunto de aplicações SAP, SaaS ou PaaS, normalmente acedido através de um endpoint público através da 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 de saída à Internet 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 aplicativos SAP BTP. Devido a esse suporte de invocação inversa, não há necessidade de portas de firewall abertas ou outro acesso para conexões de entrada, porque a conexão da sua rede virtual é de saída.

Por padrão, as VMs têm acesso de saída à Internet nativamente no Azure. O endereço IP público usado para o 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 controlado e identificável e endereço IP, você pode usar um dos seguintes métodos:

  • Um gateway NAT associado à sub-rede ou 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 ligado à Internet para a rede virtual do hub e através do firewall central. Você precisa definir outras configurações no SAP Cloud Connector para se conectar à sua conta SAP BTP.

Alta disponibilidade para SAP Cloud Connector

A alta disponibilidade está integrada 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 por meio do 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 utiliza o serviço Private Link, a comunicação não é encaminhada através da Internet pública. Ele permanece no backbone de rede global de alta segurança do Azure. A comunicação com os serviços do Azure ocorre por meio de um espaço de endereço privado. A proteção aprimorada contra exfiltração de dados é incorporada quando você usa o serviço Private Link, 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 do SAP BTP, a abordagem do serviço Private Link é preferível. 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 opera seu sistema SAP sob um contrato SAP RISE/ECS, SAP é o parceiro de serviços gerenciados. O ambiente SAP é implantado pela SAP. Na arquitetura 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 ligadas à 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 encaminham solicitações de tráfego ligadas à 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. Os cenários típicos alcançam pontos de extremidade públicos do Microsoft Entra ID, 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 às alterações no acesso de saída padrão no Azure, verifique se um acesso de saída escalável está definido. Para VMs que estão atrás de um balanceador de carga interno padrão, como aquelas em ambientes clusterizados, lembre-se de que o Balanceador de Carga Padrão modifica o comportamento para conectividade pública. Para obter mais informações, consulte Conectividade de ponto de extremidade pública 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 de Rede do Azure.

Atualizações ao sistema operativo

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 obter a licença do sistema operacional do Azure. Se você comprar licenças diretamente e trazê-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 respetivos intervalos de endereços IP.

Gerenciamento de cluster de alta disponibilidade

Sistemas altamente disponíveis, como SAP ASCS/SCS clusterizado 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 Azure Resource Manager. O Gerenciador de Recursos é usado para consultas de status sobre recursos do Azure e para operações para parar e iniciar 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 alcançá-lo. Essa arquitetura depende de um firewall central com regras definidas pelo usuário roteando o tráfego de redes virtuais SAP. Para alternativas, consulte as seções anteriores.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Outros contribuidores:

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

Comunidades

Considere usar essas comunidades para obter respostas a perguntas e ajuda com a configuração de uma implantação:

Próximos passos