Exponha o middleware herdado do SAP com segurança com o Azure PaaS
Permitir que sistemas internos e parceiros externos interajam com back-ends SAP é um requisito comum. Os cenários SAP existentes geralmente dependem do middleware legado SAP Process Orchestration (PO) ou Process Integration (PI) para suas necessidades de integração e transformação. Para simplificar, este artigo usa o termo SAP Process Orchestration 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.
Nota
A SAP menciona o SAP Integration Suite - especificamente, SAP Cloud Integration - executado na Business Technology Platform (BTP) como o sucessor do SAP PO e PI. Tanto a plataforma BTP quanto os serviços estão disponíveis no Azure. Para obter mais informações, consulte SAP Discovery Center. Para obter mais informações sobre o cronograma de suporte de manutenção para os componentes herdados, consulte a nota 1648480 do SAP OSS.
Descrição geral
As implementações existentes baseadas em middleware SAP muitas vezes contam com a tecnologia proprietária de despacho da SAP chamada SAP Web Dispatcher. Esta tecnologia opera na camada 7 do modelo OSI. Ele 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 plataforma como serviço (PaaS), como o Azure Load Balancer, e o SAP Web Dispatcher opinativo. Os conceitos gerais descritos neste artigo aplicam-se às opções mencionadas. Para obter orientação sobre como usar load balancers não-SAP, consulte o wiki do SAP.
Nota
Todas as configurações descritas neste artigo assumem uma topologia de rede hub-and-spoke, onde 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, consulte o guia de design SAP para redes de perímetro.
Serviços principais do Azure
O Gateway de Aplicativo do Azure lida com roteamento HTTP público baseado na Internet e privado interno , juntamente com o túnel criptografado entre assinaturas do Azure. Os exemplos incluem segurança e dimensionamento automático.
O Gateway de Aplicativo do Azure é focado na exposição de aplicativos Web, portanto, oferece um firewall de aplicativo Web (WAF). 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 público baseado na Internet e privado interno para tipos de tráfego nas camadas 4 a 7 do modelo OSI. Ele oferece filtragem e inteligência de ameaças que se alimentam diretamente da Segurança da Microsoft.
O Gerenciamento de API do Azure lida com roteamento público baseado na Internet e privado interno 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 dividir 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 configuração
As necessidades da arquitetura de integração são diferentes, dependendo da interface que uma organização usa. Tecnologias proprietárias da SAP, como a estrutura Intermediate Document (IDoc), Business Application Programming Interface (BAPI), chamadas de função remota transacionais (tRFCs) ou RFCs simples, exigem um ambiente de tempo de execução específico. Eles operam nas camadas 4 a 7 do modelo OSI, ao contrário das APIs modernas que normalmente dependem da comunicação baseada em HTP (camada 7 do modelo OSI). Por causa disso, 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 Declaração de Aplicabilidade 2 (AS2). File Transfer Protocol (FTP) serve como exemplo para lidar com necessidades de integração não-HTTP. Para obter mais informações sobre as soluções de balanceamento de carga da Microsoft, consulte Opções de balanceamento de carga.
Nota
A SAP publica conectores dedicados para suas interfaces proprietárias. Verifique a documentação do SAP para Java e .NET, por exemplo. Eles também são suportados por gateways da Microsoft. Esteja ciente de que IDocs também podem ser postados via HTTP.
As preocupações de segurança exigem o uso de firewalls para protocolos de nível inferior e WAFs para lidar com o tráfego baseado em HTTP com Transport Layer Security (TLS). Para serem eficazes, as sessões TLS precisam ser encerradas no nível 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 Application Gateway para identificar e entender melhor por que a regra é acionada, para que você possa corrigir de forma eficaz e segura. Open Web Application Security Project (OWASP) fornece as regras padrão. Para obter uma sessão de vídeo detalhada sobre este tópico com ênfase na exposição do SAP Fiori, consulte o webcast SAP no Azure.
Você pode melhorar ainda mais a segurança usando TLS mútuo (mTLS), que também é chamado de autenticação mútua. Ao contrário do TLS normal, ele verifica a identidade do cliente.
Nota
Os pools de máquinas virtuais (VM) exigem um balanceador de carga. Para melhor legibilidade, os diagramas neste artigo não mostram um balanceador de carga.
Nota
Se você não precisar dos 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 configuração de infraestrutura como serviço (IaaS).
Cenário: Conectividade HTTP de entrada focada
O SAP Web Dispatcher não oferece um WAF. Por isso, recomendamos o Azure Application Gateway 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 contra sobrecarga de solicitações com orientação de dimensionamento e limites de solicitações simultâneas. 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 a comunicação do SAP Process Orchestration é o fluxo de entrada. O tráfego pode ter origem no local, de aplicações ou utilizadores externos ou de um sistema interno. O exemplo a seguir se concentra em HTTPS.
Cenário: Conectividade HTTP/FTP de saída focada em conectividade
Para a direção de comunicação inversa, o SAP Process Orchestration pode usar o roteamento de rede virtual para alcançar cargas de trabalho locais ou alvos baseados na Internet por meio do breakout 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, consulte Cenário: baseado em arquivo e comparação de componentes de 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: Gerenciamento de API focado
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 com o 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 vinculado à região. Em comparação com os cenários anteriores, o Azure Front Door garante roteamento global entre regiões, incluindo um firewall de aplicativo Web. Para obter detalhes sobre as diferenças, consulte 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, o Gateway de Aplicativo ou a Porta da Frente do Azure, conforme mostrado nos cenários anteriores. Em vez disso, a instância gerenciada do Firewall do Azure ou o dispositivo virtual de rede (NVA) 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 suporta SFTP nativamente.
Opções alternativas de SFTP estão disponíveis no Azure Marketplace, se necessário.
O diagrama a seguir mostra uma variação desse cenário com destinos de integração externos e locais. Diferentes tipos de FTP seguro ilustram o caminho de comunicação.
Para obter informações sobre compartilhamentos de arquivos NFS (Network File System) como uma alternativa ao Armazenamento de Blobs, consulte Compartilhamentos de arquivos NFS em Arquivos do Azure.
Cenário: específico do 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, consulte o guia de referência do SAP RISE.
Importante
Entre em contato com a SAP para garantir que as portas de comunicação para seu cenário sejam permitidas e abertas em 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 no RISE é configurada por meio de emparelhamento de rede virtual, normalmente no hub. Uma possível integração poderia ser IDocs postados no serviço /sap/bc/idoc_xml web SAP ERP por uma parte externa.
Este segundo exemplo mostra uma configuração em que o SAP RISE executa toda a cadeia de integração, exceto a camada de Gerenciamento de API.
Saída de arquivo
Nesse cenário, a instância do Process Orchestration gerenciada pelo SAP grava arquivos no compartilhamento de arquivos gerenciado pelo cliente no Azure ou em uma carga de trabalho local. O cliente lida com a fuga.
Comparação de configurações de gateway
Nota
As métricas de desempenho e custo assumem níveis de nível de produção. Para obter mais informações, consulte a calculadora de preços do Azure. Consulte também os seguintes artigos: Desempenho do Firewall do Azure, Suporte de alto tráfego do Gateway de Aplicativo 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, consulte Firewall do Azure e Gateway de Aplicativo para redes virtuais.
Regra geral de integração
Para determinar quais cenários de integração descritos neste artigo melhor atendem às suas necessidades, avalie-os caso a caso. Considere habilitar os seguintes recursos:
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 recetor
Firewall do Azure para integrações não HTTP
Alta disponibilidade e recuperação de desastres para cargas de trabalho de integração SAP baseadas em VM
Mecanismos de autenticação modernos como OAuth2, quando aplicável
Um armazenamento de chaves gerenciado como o Azure Key Vault para todas as credenciais, certificados e chaves envolvidos
Alternativas ao SAP Process Orchestration com o Azure Integration Services
Com o portfólio do Azure Integration Services, você pode abordar nativamente os cenários de integração cobertos pelo SAP Process Orchestration. Para obter informações sobre como projetar padrões SAP IFlow por meio de meios nativos da nuvem, consulte 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óximos passos
Proteja APIs com o Application Gateway e o Gerenciamento de API
Integre o gerenciamento de API em uma rede virtual interna com o Application Gateway
Compreender o Application Gateway WAF for SAP
Compreender as implicações da combinação do Firewall do Azure e do Gateway de Aplicativo do Azure
Trabalhar com APIs do SAP OData no Gerenciamento de API do Azure