Na Lynxmind, combinamos as boas práticas de dois mundos, SAP e AWS, para conceber e instalar sistemas SAP de elevada disponibilidade, de forma segura e otimizada em custos.

Este artigo explica a arquitetura do SAP Web Dispatcher na AWS, mostrando padrões e práticas correntes para lidar com pedidos internos, vindos da rede corporativa, e com pedidos externos, vindos da internet pública. Fica também a saber como usar uma firewall de aplicações web para reforçar a segurança no tratamento dos pedidos externos.

Ilustração da cloud Lynxmind

O que é o SAP Web Dispatcher e para que serve?

Nota: o objetivo deste artigo é discutir diferentes arquiteturas para instalar o SAP Web Dispatcher, usando a AWS como exemplo. Não pretende enumerar todas as capacidades e configurações detalhadas da ferramenta. Para mais informação, consulte a documentação da SAP.

O SAP Web Dispatcher situa-se entre o cliente web (o browser) e o sistema SAP que corre a aplicação.

É o ponto de entrada dos pedidos HTTP(S) no seu sistema, composto por um ou mais servidores aplicacionais SAP NetWeaver. Enquanto “comutador web em software”, pode rejeitar ou aceitar ligações.

Quando aceita uma ligação, distribui a carga para garantir um equilíbrio entre servidores. O SAP Web Dispatcher contribui, assim, tanto para a segurança como para o balanceamento de carga no seu sistema SAP. Pode ser usado em sistemas ABAP e Java.

Estas são algumas das tarefas que desempenha:

  • Escolha do servidor aplicacional adequado - Persistência em aplicações com estado, balanceamento de carga, servidor ABAP ou Java.
  • Configuração para vários sistemas - Pode colocar um SAP Web Dispatcher à frente de vários sistemas SAP e definir que pedidos vão para que sistema, ou balancear a carga entre eles.
  • Filtragem de URL - Pode definir URL a rejeitar e, dessa forma, restringir o acesso ao sistema.
  • Cache web - Pode usá-lo como cache para melhorar os tempos de resposta e poupar a cache do servidor aplicacional.
  • Reescrita de URL e manipulação de cabeçalhos HTTP - O Web Dispatcher pode manipular pedidos HTTP recebidos com base em regras definidas.
  • Consoante a configuração de SSL, pode encaminhar, terminar e voltar a cifrar os pedidos.

Padrão 1 - Arquitetura para pedidos internos (rede corporativa)

O diagrama seguinte ilustra a arquitetura de uma rede de cliente ligada a uma VPC da AWS através do AWS Direct Connect.

Nota: este é um exemplo de alto nível, para ilustrar o caso. Em implementações AWS maiores, com várias contas, a arquitetura de rede não seria esta: usar-se-iam contas separadas para tráfego de entrada e de saída, com um Transit Gateway a gerir todas as ligações. Veja este artigo da AWS para mais detalhes.

Percurso do pedido:

  1. Um utilizador envia um pedido HTTP(S) a partir da rede corporativa interna, ligada à VPC da AWS através do AWS Direct Connect.
  2. O Application Load Balancer (ALB) interno recebe o pedido e encaminha-o para o respetivo Target Group.
  3. O Target Group distribui a carga por todos os SAP Web Dispatchers disponíveis (2 servidores, neste exemplo).
  4. O SAP Web Dispatcher que recebeu o pedido encaminha-o para o sistema SAP de backend, usando Logon Groups para balancear a carga na camada aplicacional SAP.

Padrão 2 - Arquitetura para pedidos externos (públicos)

O diagrama seguinte ilustra um pedido externo, vindo da internet pública.

Nota: a parte do DNS foi propositadamente omitida do diagrama. Pode usar o AWS Route 53, ou outra ferramenta de DNS, para gerir os seus domínios e encaminhar os pedidos de determinado serviço para o Application Load Balancer externo.

Percurso do pedido:

  1. Um utilizador envia um pedido HTTP(S) a partir da internet pública, e um gestor de DNS encaminha-o para o seu Application Load Balancer (ALB) externo.
  2. O Application Load Balancer (ALB) externo recebe o pedido e encaminha-o para o respetivo Target Group.
  3. O Target Group distribui a carga por todos os SAP Web Dispatchers disponíveis (2 servidores, neste exemplo).
  4. O SAP Web Dispatcher que recebeu o pedido encaminha-o para o sistema SAP de backend, usando Logon Groups para balancear a carga na camada aplicacional SAP.

Padrão 3 - Arquitetura para pedidos internos e externos

O diagrama seguinte ilustra o uso conjunto dos dois primeiros padrões, num caso em que o cliente recebe pedidos da rede corporativa e da internet pública.

Passa a ter: 2 balanceadores de carga (interno e externo) + 2 Web Dispatchers internos + 2 Web Dispatchers externos

Uma pergunta que surge com frequência é: é obrigatório separar os pedidos internos dos externos em Web Dispatchers distintos?

A resposta curta é: DEPENDE 😊. Alguns clientes querem manter os pedidos internos separados dos externos por razões de segurança. Tecnicamente, porém, é possível colocar 2 Web Dispatchers numa sub-rede privada adicional (a que se pode chamar camada web) e ter ambos os Application Load Balancers, interno e externo, a encaminhar os pedidos para os mesmos Web Dispatchers.

Padrão 4 - Como otimizar recursos e custos (sem descurar a segurança)?

O diagrama seguinte ilustra o uso de 2 Web Dispatchers numa sub-rede privada adicional, chamada camada web, com ambos os Application Load Balancers a encaminhar os pedidos para os mesmos Web Dispatchers. Chamam-se híbridos precisamente por receberem tipos de ligação diferentes, internas e externas.

Esta opção otimiza os custos, já que passa a ter 2 Web Dispatchers em vez de 4. Pondere não só o custo de manter mais recursos ativos, mas também o custo de os operar: atualizações, cópias de segurança, configurações.

Padrão 5 - Usar uma firewall de aplicações web nos pedidos externos

O diagrama seguinte ilustra o uso do padrão 1 (pedidos internos) e do padrão 2 (pedidos externos), mas agora com uma camada de segurança adicional para os pedidos públicos: uma firewall de aplicações web.

O que é uma firewall de aplicações web (WAF)? A AWS WAF ajuda a proteger contra exploits e bots comuns na web, que podem afetar a disponibilidade, comprometer a segurança ou consumir recursos em excesso.

Percurso do pedido:

  1. Um utilizador envia um pedido HTTP(S) a partir da internet pública e uma ferramenta de DNS encaminha-o para o seu Application Load Balancer (ALB) externo.
  2. A firewall de aplicações web (WAF) analisa o pedido com base nas regras da Web ACL configuradas e bloqueia-o ou encaminha-o para o Application Load Balancer externo.
  3. O Application Load Balancer (ALB) externo recebe o pedido e encaminha-o para o respetivo Target Group.
  4. O Target Group distribui a carga por todos os SAP Web Dispatchers disponíveis (2 servidores, neste exemplo).
  5. O SAP Web Dispatcher que recebeu o pedido encaminha-o para o sistema SAP de backend, usando Logon Groups para balancear a carga na camada aplicacional SAP.

Regras da Web ACL

Uma lista de controlo de acesso web (Web ACL) dá-lhe controlo fino sobre os pedidos a que o recurso protegido responde.

Se quiser aprofundar o tema, este artigo é excelente: Securing SAP Fiori with AWS WAF (Web Application Firewall) - ligação

As regras são analisadas de cima para baixo. Se acrescentar mais do que uma regra a uma Web ACL, a AWS WAF avalia cada pedido pela ordem em que as listou.

Primeiro, bloquear por omissão Se o pedido não corresponder a nenhuma regra, a WAF aplica a ação predefinida. Defina-a como “Block”.

As regras da Web ACL, em traços gerais

Há dois tipos de regras: as personalizadas, geridas pelo cliente, e as geridas pela AWS. Cada cliente tem os seus requisitos de segurança, e a análise deve ser feita caso a caso.

  • CustomerIpWhiteList (personalizada): permite o acesso a partir de endereços IP específicos do cliente.
  • AWSManagedRulesAmazonIpReputationList (gerida pela AWS): procura endereços IP identificados como maliciosos.
  • AWSManagedRulesCommonRuleSet (gerida pela AWS): de aplicação geral a aplicações web (OWASP).
  • AWSManagedRulesSQLiRuleSet (gerida pela AWS): bloqueia padrões de injeção de SQL.
  • GeoBlock (personalizada): permite apenas pedidos vindos de determinados países.
  • RateLimits (personalizada): define o número máximo de pedidos a partir de um único IP.

Consulte a documentação oficial da AWS para mais informação.

Notas finais

Quando se desenha a arquitetura do SAP Web Dispatcher, ou de qualquer outro componente, trata-se sempre de fazer escolhas. Se tem requisitos muito exigentes de disponibilidade e de segurança, os custos vão subir.

Fale connosco para saber como otimizar as suas cargas de trabalho SAP na cloud.

Equipa AWS da Lynxmind

Tags
Partilhar
Luiz Machado
Luiz Machado

Como Diretor de Serviços Cloud na Lynxmind, traz uma vasta experiência em arquitetura e estratégia cloud, que lhe permite liderar a transformação digital com visão de futuro. Move-o a vontade de aproveitar as tecnologias cloud mais recentes para ganhar escalabilidade, aumentar a eficiência operacional e sustentar os objetivos de crescimento e inovação da empresa a longo prazo.