Exponha o middleware herdado SAP com segurança com o Azure PaaS
Habilitar sistemas internos e parceiros externos a interagirem com back-ends SAP é um requisito comum. Os cenários SAP existentes geralmente dependem da PO (Orquestração de Processos) SAP do middleware herdado ou da PI (Integração de Processos) para suas necessidades de integração e transformação. Para simplificar, este artigo usa o termo Orquestração de Processo SAP para se referir a ambas as ofertas.
Este artigo descreve as opções de configuração no Azure com ênfase em implementações voltadas para a Internet.
Observação
O SAP menciona o SAP Integration Suite, especificamente o SAP Cloud Integration, em execução no BTP (Business TechnologyPlatform) como o sucessor do PO/PI SAP. A plataforma e os serviços BTP estão disponíveis no Azure. Para obter mais informações, veja SAP Discovery Center. Para obter mais informações sobre a linha do tempo de suporte de manutenção para os componentes legados, veja a nota SAP OSS 1648480.
Visão geral
As implementações existentes baseadas no middleware SAP têm muitas vezes contado com a tecnologia de despacho proprietária da SAP chamada SAP Web Dispatcher. Essa tecnologia opera na camada 7 do modelo OSI. Ela atua como um proxy reverso e atende às necessidades de balanceamento de carga para cargas de trabalho de aplicativos SAP downstream, como SAP Enterprise Resource Planning (ERP), SAP Gateway ou SAP Process Orchestration.
As abordagens de despacho incluem proxies reversos tradicionais, como o Apache, opções de PaaS (plataforma como serviço), como Azure Load Balancer e o conceituado SAP Web Dispatcher. Os conceitos gerais descritos neste artigo se aplicam às opções mencionadas. Para obter diretrizes sobre como usar balanceadores de carga não SAP, veja o wiki do SAP.
Observação
Todas as configurações descritas neste artigo pressupõem uma topologia de rede hub-and-spoke, em que os serviços compartilhados são implantados no hub. Com base na criticidade do SAP, você pode precisar de ainda mais isolamento. Para obter mais informações, veja o guia de design para redes de perímetro do SAP.
Serviços primários do Azure
O Gateway de Aplicativo do Azure lida com roteamento HTTP baseado na internet e privado interno com tunelamento criptografado em assinaturas do Azure. Os exemplos incluem segurança e dimensionamento automático.
O Gateway de Aplicativo do Azure se concentra em expor aplicativos Web, portanto, oferece um (WAF) Firewall de Aplicativo Web. As cargas de trabalho em outras redes virtuais que se comunicarão com o SAP por meio do Gateway de Aplicativo do Azure podem ser conectadas por meio de links privados, mesmo entre locatários.
O Firewall do Azure lida com roteamento privado interno e baseado na Internet pública para tipos de tráfego nas camadas 4 a 7 do modelo OSI. Ele oferece filtragem e inteligência contra ameaças que se alimentam diretamente do Microsoft Security.
O Gerenciamento de API do Azure lida com roteamento privado interno e baseado na Internet pública especificamente para APIs. Ele oferece limitação de solicitações, cota e limites de uso, recursos de governança como políticas e chaves de API para detalhar os serviços por cliente.
O Gateway de VPN do Azure e o Azure ExpressRoute servem como pontos de entrada para redes locais. Eles são abreviados nos diagramas como VPN e XR.
Considerações sobre a instalação
As necessidades da arquitetura de integração diferem, dependendo da interface que uma organização usa. Tecnologias proprietárias da SAP, como Estrutura Intermediate Document (IDoc), Business Application Programming Interface (BAPI), transactional Remote Function Calls (tRFCs) ou RFCs simples requerem um ambiente de runtime específico. Eles operam nas camadas 4 a 7 do modelo OSI, ao contrário das APIs modernas que normalmente dependem de comunicação baseada em HTP (camada 7 do modelo OSI). Por isso, as interfaces não podem ser tratadas da mesma maneira.
Este artigo se concentra em APIs modernas e HTTP, incluindo cenários de integração, como a AS2 (Applicability Statement 2). FTP (File Transfer Protocol) serve como um exemplo para lidar com necessidades de integração não HTTP. Para obter mais informações sobre soluções de balanceamento de carga da Microsoft, veja Opções de balanceamento de carga.
Observação
O SAP publica conectores dedicados para suas interfaces proprietárias. Verifique a documentação do SAP para Java e .NET, por exemplo. Eles também têm suporte com os Gateways da Microsoft. Lembre-se de que os iDocs também podem ser postados por meio de HTTP.
As preocupações de segurança exigem o uso de firewalls para protocolos de nível inferior e WAFs para endereçar o tráfego baseado em HTTP com TLS (Transport Layer Security). Para serem eficazes, as sessões TLS precisam ser encerradas no nível do WAF. Para oferecer suporte a abordagens de confiança zero, recomendamos que você criptografe novamente depois para fornecer criptografia de ponta a ponta.
Protocolos de integração como o AS2 podem gerar alertas usando regras WAF padrão. Recomendamos usar a pasta de trabalho de triagem WAF do Gateway de Aplicativo do Azure para identificar e entender melhor por que a regra é acionada, para que você possa corrigir com eficácia e segurança. O OWASP (Open Web Application Security Project) fornece as regras padrão. Para uma sessão de vídeo detalhada sobre este tópico com ênfase na exposição do SAP Fiori, veja o webcast do SAP no Azure.
Você pode aprimorar ainda mais a segurança usando o mTLS (TLS mútuo), que também é chamado de autenticação mútua. Ao contrário do TLS normal, ele verifica a identidade do cliente.
Observação
Os pools de VM (máquina virtual) exigem um balanceador de carga. Para obter uma melhor legibilidade, os diagramas neste artigo não mostram um balanceador de carga.
Observação
Se você não precisar de recursos de balanceamento específicos do SAP fornecidos pelo SAP Web Dispatcher, poderá substituí-los pelo Azure Load Balancer. Essa substituição oferece o benefício de uma oferta de PaaS gerenciada em vez de uma instalação de IaaS (infraestrutura como serviço).
Cenário: foco em conectividade de entrada HTTP
O SAP Web Dispatcher não oferece um WAF. Por isso, recomendamos o Gateway de Aplicativo do Azure para uma configuração mais segura. O SAP Web Dispatcher e o Process Orchestration permanecem responsáveis por ajudar a proteger o back-end SAP da sobrecarga de solicitações comorientação de dimensionamento e limites de solicitação simultânea. Nenhum recurso de limitação está disponível nas cargas de trabalho SAP.
Você pode evitar o acesso não intencional por meio de listas de controle de acesso no Sap Web Dispatcher.
Um dos cenários para comunicação de Orquestração de Processos SAP é o fluxo de entrada. O tráfego pode ter origem no local, em aplicativos ou usuários externos ou em um sistema interno. O exemplo a seguir se concentra em HTTPS.
Cenário: com foco em conectividade de saída HTTP/FTP
Para a direção de comunicação reversa, o SAP Process Orchestration pode usar roteamento de rede virtual para alcançar cargas de trabalho locais ou destinos baseados na Internet por meio da interrupção da Internet. O Gateway de Aplicativo do Azure atua como um proxy reverso nesses cenários. Para comunicação não HTTP, considere adicionar o Firewall do Azure. Para obter mais informações, veja Cenário: baseado em arquivo e comparação de componentes do Gateway mais adiante neste artigo.
O cenário de saída a seguir mostra dois métodos possíveis. Um usa HTTPS por meio do Gateway de Aplicativo do Azure chamando um serviço Web (por exemplo, adaptador SOAP). O outro usa FTP sobre SSH (SFTP) por meio do Firewall do Azure transferindo arquivos para o servidor SFTP de um parceiro de negócios.
Cenário: foco em Gerenciamento de API
Em comparação com os cenários de conectividade de entrada e saída, a introdução do Gerenciamento de API do Azure no modo interno (somente IP privado e integração de rede virtual) adiciona recursos internos como:
- Limitação.
- Governança de API.
- Opções de segurança adicionais, como fluxos de autenticação modernos.
- Integração do Microsoft Entra ID.
- A oportunidade de adicionar APIs SAP a uma solução de API central em toda a empresa.
Quando você não precisa de um WAF, pode implantar o Gerenciamento de API do Azure no modo externo usando um endereço IP público. Essa implantação simplifica a configuração, mantendo os recursos de limitação e governança de API. A proteção básica é implementada para todas as ofertas de PaaS do Azure.
Cenário: alcance global
O Gateway de Aplicativo do Azure é um serviço regional. Em comparação com os cenários anteriores, o Azure Front Door garante o roteamento global entre regiões, incluindo um firewall de aplicativo Web. Para obter detalhes sobre as diferenças, veja esta comparação.
O diagrama a seguir condensa o SAP Web Dispatcher, o SAP Process Orchestration e o back-end em uma única imagem para melhor legibilidade.
Cenário: baseado em arquivo
Protocolos não HTTP, como FTP, não podem ser abordados com o Gerenciamento de API do Azure, Gateway de Aplicativo do Azure ou Azure Front Door, conforme mostrado nos cenários anteriores. Em vez disso, a instância gerenciada do Firewall do Azure ou o NVA (dispositivo virtual de rede) equivalente assume a função de proteger as solicitações de entrada.
Os arquivos precisam ser armazenados antes que o SAP possa processá-los. Recomendamos que você use SFTP. O Armazenamento de Blobs do Azure dá suporte ao SFTP nativamente.
Opções alternativas de SFTP estão disponíveis no Microsoft Azure Marketplace, se necessário.
O diagrama a seguir mostra uma variação desse cenário com destinos de integração externa e local. Diferentes tipos de FTP seguro ilustram o caminho de comunicação.
Para obter insights sobre compartilhamentos de arquivos do NFS (Network File System) como uma alternativa ao Armazenamento de Blobs, consulte Compartilhamentos de arquivos NFS em Arquivos do Azure.
Cenário: específico para SAP RISE
As implantações do SAP RISE são tecnicamente idênticas aos cenários descritos anteriormente, com a exceção de que o próprio SAP gerencia a carga de trabalho SAP de destino. Os conceitos descritos podem ser aplicados aqui.
Os diagramas a seguir mostram duas configurações como exemplos. Para obter mais informações, veja o Guia de referência RISE do SAP.
Importante
Entre em contato com a SAP para garantir que as portas de comunicação para seu cenário sejam permitidas e abertas nos NSGs.
Entrada HTTP
Na primeira configuração, o cliente controla a camada de integração, incluindo o SAP Process Orchestration e o caminho de entrada completo. Somente o destino final do SAP é executado na assinatura RISE. A comunicação com a carga de trabalho hospedada pelo RISE é configurada por meio de emparelhamento de rede virtual, geralmente pelo hub. Uma integração potencial poderia ser IDocs postados no serviço web SAP ERP /sap/bc/idoc_xml por uma parte externa.
Este segundo exemplo mostra uma configuração em que o RISE SAP executa toda a cadeia de integração, exceto a camada de Gerenciamento de API.
Saída do arquivo
Nesse cenário, a instância de orquestração de processos gerenciada pelo SAP grava arquivos no compartilhamento de arquivos gerenciado pelo cliente no Azure ou em uma carga de trabalho localizada no local. O cliente lida com o rompimento.
Comparação de configurações de gateway
Observação
As métricas de desempenho e custo assumem camadas de grau de produção. Para obter mais informações, confira a Calculadora de preços do Azure. Consulte também os seguintes artigos: Desemepenho do Firewall do Azure, Suporte de alto tráfego do Gateway de Aplicativo do Azure e capacidade de uma instância de Gerenciamento de API do Azure.
Dependendo dos protocolos de integração que você está usando, você pode precisar de vários componentes. Para obter mais informações sobre os benefícios das várias combinações de encadeamento do Gateway de Aplicativo do Azure com o Firewall do Azure, veja Firewall do Azure e Gateway de Aplicativo do Azure para redes virtuais.
Regra prática de integração
Para determinar quais cenários de integração descritos neste artigo melhor atendem aos seus requisitos, avalie-os caso a caso. Considere habilitar as seguintes funcionalidades:
Limitação de solicitações usando o Gerenciamento de API
Limites de solicitações simultâneas no SAP Web Dispatcher
TLS mútuo para verificar o cliente e o receptor
Firewall do Azure para integrações não HTTP
Alta disponibilidade e recuperação de desastre para as cargas de trabalho de integração SAP baseadas em VM
Mecanismos de autenticação modernos, como o OAuth2, quando aplicável
Um armazenamento de chaves gerenciado como Azure Key Vault para todas as credenciais, certificados e chaves envolvidos
Alternativas à Orquestração de Processos SAP com o Azure Integration Services
Com o portfólio do Azure Integration Services, você pode abordar nativamente os cenários de integração que a Orquestração de Processo do SAP aborda. Para obter informações sobre como projetar padrões SAP IFlow por meios nativos da nuvem, veja esta série de blogs. O guia do conector contém mais detalhes sobre AS2 e EDIFACT.
Para obter mais informações, exiba os conectores dos Aplicativos Lógicos do Azure para suas interfaces SAP desejadas.
Próximas etapas
Proteger APIs com o Gateway de Aplicativo e o Gerenciamento de API
Como integrar o Gerenciamento de API em uma rede virtual interna com o gateway de aplicativo
Entender o WAF do Gateway de Aplicativo do Azure para SAP
Entender as implicações da combinação de Firewall do Azure e Gateway de Aplicativo do Azure
Trabalhar com APIs SAP OData no Gerenciamento de API do Azure