Padrão de Descarregamento de Gateway

Descarregue funcionalidade de serviço partilhado ou especializado para um proxy de gateway. Esta abordagem simplifica o desenvolvimento de aplicações ao centralizar preocupações transversais, como a terminação de certificados TLS voltada para o cliente, no gateway, em vez de as duplicar entre serviços.

Quando múltiplos serviços partilham responsabilidades como autenticação, monitorização ou tradução de protocolos, consolidar essas preocupações num único gateway reduz a sobrecarga de configuração por serviço e o risco de implementação.

Contexto e problema

Algumas funcionalidades são frequentemente utilizadas em vários serviços, mas essas funcionalidades exigem configuração, gestão e manutenção. Um serviço partilhado ou especializado que distribui em cada implementação da aplicação acrescenta sobrecarga administrativa e aumenta a probabilidade de erro de implementação. Deve implementar quaisquer atualizações de uma funcionalidade partilhada em todos os serviços que partilham essa funcionalidade.

Questões de segurança, como validação de tokens, encriptação e gestão de certificados TLS, podem exigir que os membros da equipa possuam competências altamente especializadas. Por exemplo, sem um gateway, pode ser necessário configurar e implementar um certificado orientado para o cliente em cada instância de aplicação. Deve acompanhar a sua expiração e atualizar, testar e verificar ao longo dessas instâncias.

Outros serviços comuns, tais como a autenticação, a autorização, o registo, a monitorização ou a limitação podem ser difíceis de implementar e gerir num grande número de implementações. Consolidar este tipo de funcionalidade reduz a sobrecarga e a possibilidade de erros.

Solução

Transfira algumas funcionalidades para um gateway. O gateway trata então de questões transversais como gestão de certificados orientada para o cliente, autenticação, terminação TLS, monitorização, tradução de protocolos e limitação em nome dos serviços backend.

O diagrama seguinte mostra um gateway que termina as ligações TLS de entrada e aplica capacidades partilhadas. O gateway valida o certificado backend e volta a encriptar o tráfego através de uma ligação TLS separada para o serviço backend.

Diagrama de um cliente a ligar-se a um gateway via TLS.

Vantagens deste padrão:

  • Simplifique o desenvolvimento dos serviços centralizando a configuração partilhada, como autenticação, redução de limites e registo de pedidos, em vez de a implementar em cada serviço backend. A centralização melhora a consistência e torna as atualizações de serviço mais simples.

  • Permite que equipas dedicadas implementem funcionalidades que requerem conhecimentos especializados, tal como segurança. A sua equipa principal pode então concentrar-se na funcionalidade da aplicação, deixando estas preocupações especializadas mas transversais para os especialistas relevantes.

  • Fornece alguma consistência para o registo e a monitorização de pedidos e respostas. Mesmo que um serviço não esteja corretamente instrumentado, o gateway pode fornecer um nível base de monitorização e registo.

  • Centralizar a gestão do tráfego sensível ao carbono. Um gateway pode ajustar os comportamentos de cache, limitação de taxa e registo com base em sinais de intensidade de carbono em tempo real. O API Management do Azure oferece estas capacidades em pré-visualização limitada, em regiões selecionadas e níveis clássicos (Developer, Basic, Standard e Premium). Para detalhes sobre disponibilidade e configuração, consulte APIs ambientalmente sustentáveis no API Management do Azure.

  • Lidar com mapeamentos de URL estáticos do antigo para o novo. O gateway pode devolver um redirecionamento sem invocar um backend, mantendo o tratamento de URLs legado fora do pipeline de pedidos de cada serviço.

Problemas e considerações

Considere os seguintes pontos ao decidir como implementar esse padrão:

  • Alta disponibilidade e resiliência. Certifique-se de que o gateway esteja altamente disponível e resiliente a falhas. Evite pontos únicos de falha ao executar múltiplas instâncias do seu gateway. Como o gateway encerra as ligações de cliente e pode colocar em memória intermédia o corpo dos pedidos, considere como os pedidos em curso são tratados durante falhas da instância. Utilize mecanismos de drenagem de ligações ou de encerramento gracioso para que a remoção ou o reinício de uma instância de gateway não interrompa as sessões ativas.

  • Capacidade e escalabilidade. Confirme se o gateway foi concebido para os requisitos de capacidade e dimensionamento da aplicação e dos pontos finais. Verifique se o gateway não se torna um gargalo para o aplicativo e é suficientemente escalável. O gateway deve ser provisionado para suportar picos súbitos de tráfego, e não apenas a carga média. Sub-provisionar o gateway para reduzir custos degrada diretamente o desempenho de todos os serviços por detrás dele.

  • Descarregar o telescópio. A descarga de funcionalidades partilhadas por múltiplos serviços ou rotas ao centralizá-las reduz a duplicação da implementação e gestão.

  • Correspondência de redirecionamentos. Fazer corresponder apenas os URLs legados pretendidos e preservar o roteamento normal para pedidos não correspondidos. Mantém os redirecionamentos que dependam do estado do negócio ou da autorização específica da aplicação na aplicação. Para orientações relacionadas, consulte Preservar links quando o conteúdo for movido.

  • Separação da lógica de negócio. Nunca delegues a lógica de negócio ao gateway.

  • Rastreio de transações. Se precisar de controlar as transações, considere gerar IDs de correlação para fins de registo.

  • Sobrecarga de latência. O gateway adiciona um salto de rede a cada pedido. Cada função descarregada para o gateway, como a terminação de TLS, a autenticação ou a inspeção de pedidos, acrescenta tempo de processamento ao percurso do pedido. O agrupamento de ligações do gateway e as ligações persistentes aos serviços de retaguarda podem compensar parcialmente o custo da latência, reutilizando ligações em vez de criar novas para cada pedido. Avalie se a latência combinada do salto através do gateway e das funções descarregadas cumpre as metas de desempenho da carga de trabalho.

  • Complexidade operacional. Um gateway centralizado consolida a gestão, mas também concentra a responsabilidade operacional. Deve gerir a configuração do gateway, o ciclo de vida dos certificados, as atualizações de políticas e as atualizações de versões como uma preocupação partilhada. Garantir que a equipa responsável pelo gateway tem a capacidade e as ferramentas para o gerir à escala de todos os serviços que dele dependem.

  • Implicações de segurança. O gateway é um alvo de alto valor porque centraliza funções de segurança transversais como autenticação, terminação TLS e inspeção de pedidos. O comprometimento do gateway pode expor todos os serviços subsequentes. Reforçar o gateway, restringir a sua superfície de gestão e monitorizá-lo para comportamentos anómalos independentemente dos serviços backend que protege.

  • Prevenção de bypass de gateway. Configure os serviços de backend para aceitarem pedidos apenas através do caminho de gateway pretendido. Caso contrário, os clientes podem ligar-se diretamente a um backend e contornar a autenticação, limitação, solicitação de inspeção e registo no gateway.

  • Propagação da identidade. Defina se cada backend autoriza o chamador original, a identidade da carga de trabalho do gateway, ou ambos. Mantenha os tokens do chamador ou as declarações fidedignas apenas quando o backend exigir um contexto de utilizador delegado. Autentique sempre o gateway junto do backend, em separado. Não trate cabeçalhos encaminhados não verificados como prova de identidade.

  • Manutenção do TLS. Se o gateway encerrar a ligação TLS, restabeleça a ligação TLS ao backend. Não encaminhe tráfego por HTTP não encriptado. Trate todas as redes como não confiáveis. Esta topologia continua a exigir um processo para emitir, renovar e revogar certificados de backend.

  • Cabeçalhos reencaminhados e contexto do cliente. Quando o gateway termina as ligações do cliente e estabelece novas ligações a serviços de backend, informações como o endereço IP do cliente, o protocolo original e o nome do host são perdidas, a menos que o gateway as encaminhe explicitamente. Para conhecer estratégias de mitigação, consulte Preservar o nome original do host HTTP entre um proxy inverso e a sua aplicação web de back-end.

Quando utilizar este padrão

Utilize este padrão quando:

  • A implementação de uma aplicação tem uma preocupação comum, como certificados TLS ou encriptação.
  • Uma funcionalidade comum em implementações de aplicações pode ter requisitos de recursos diferentes, como recursos de memória, capacidade de armazenamento ou ligações de rede.
  • Queres transferir a responsabilidade por questões como segurança de rede, limitação ou outras preocupações com limites de rede para uma equipa mais especializada.

Este padrão pode não ser adequado quando:

  • O gateway deve conter regras lógicas ou de encaminhamento específicas do serviço que associem de forma rígida as alterações de backend ao serviço com as alterações de configuração do gateway. Associar a camada de gateway com serviços internos significa que as atualizações do backend podem forçar a redistribuição do gateway, reduzindo a independência da implementação.
  • A tarefa descarregada é ligeira e a carga de trabalho é sensível à latência. O salto adicional de rede através do gateway pode não ser justificado quando a sobrecarga supera o benefício da centralização.
  • Centralizar as preocupações num gateway partilhado cria um estrangulamento na gestão de mudanças. Se o ciclo de lançamento da equipa de gateway for mais lento do que o das equipas de serviço, a transferência pode atrasar atualizações de certificados, políticas de autenticação ou regras de rede.

Design da carga de trabalho

Um arquiteto deve avaliar como o padrão de Descarregamento pelo Gateway pode ser aplicado no design da sua carga de trabalho para cumprir os objetivos e princípios delineados nos pilares do Azure Well-Architected Framework. Por exemplo:

Pilar Como esse padrão suporta os objetivos do pilar
As decisões de projeto de confiabilidade ajudam sua carga de trabalho a se tornar resiliente ao mau funcionamento e garantem que ela se recupere para um estado totalmente funcional após a ocorrência de uma falha. Transferir essa responsabilidade para um gateway reduz a complexidade do código do aplicativo nos nós de back-end. Em alguns casos, a transferência de tarefas substitui completamente a funcionalidade por uma funcionalidade confiável fornecida pela plataforma.

- RE:01 Simplicidade e eficiência
As decisões de design de segurança ajudam a garantir a confidencialidade, integridade e disponibilidade dos dados e sistemas da sua carga de trabalho. Adicionar um gateway ao fluxo de pedidos permite-lhe centralizar controlos como firewalls de aplicações web e políticas TLS do cliente. Qualquer funcionalidade transferida fornecida pela plataforma já oferece segurança aprimorada.

- SE:06 Controles de rede
- SE:08 Endurecimento de recursos
A Otimização de Custos foca-se em manter e melhorar o retorno do investimento da sua carga de trabalho. Este padrão permite redirecionar os custos dos recursos que seriam gastos por nó para a implementação do gateway. Os custos no modelo de processamento centralizado são frequentemente mais baixos do que os do modelo distribuído.

- CO:14 Consolidação
A Excelência Operacional ajuda a fornecer qualidade de carga de trabalho por meio de processos padronizados e coesão da equipe. Neste padrão, a configuração e manutenção da funcionalidade descarregada estão associadas a um único ponto em vez de exigir gestão de múltiplos nós. Esta centralização padroniza a forma como as preocupações transversais são aplicadas, tornando as mudanças operacionais rotineiras e ad hoc consistentes e previsíveis.

- OE:02 Padronizar operações
A Eficiência de Desempenho ajuda sua carga de trabalho a atender às demandas de forma eficiente por meio de otimizações em escala, dados e código. A adição de um gateway de descarregamento ao processo de pedidos permite consumir menos recursos por nó, porque a funcionalidade fica centralizada no gateway. Você pode otimizar a implementação da funcionalidade descarregada independentemente do código do aplicativo. É provável que a funcionalidade fornecida pela plataforma descarregada já seja de alto desempenho.

- PE:03 Seleção de serviços

Se este padrão introduzir compensações dentro de um pilar, considere-as em relação aos objetivos dos outros pilares.

Example

Gateway de Aplicação do Azure WAF_v2 pode implementar este padrão para uma aplicação web regional. O gateway termina as ligações TLS do cliente, aplica políticas WAF e de encaminhamento, e estabelece novas ligações TLS aos serviços de backend. Este design mantém preocupações partilhadas de processamento de pedidos fora do código da aplicação backend.

Gateway de Aplicações com descarregamento TLS

O diagrama seguinte mostra como o Application Gateway termina as ligações TLS de entrada, inspeciona e filtra o tráfego, e o volta a encriptar antes de o encaminhar para um pool backend via TLS.

Diagrama que mostra o Application Gateway a terminar o TLS de entrada dos clientes, a aplicar regras de WAF e de encaminhamento, e a reencriptar o tráfego através de TLS para um conjunto de servidores de back-end.

Esta arquitetura utiliza os seguintes componentes do Application Gateway para descarregar funcionalidades partilhadas e voltar a encriptar o tráfego de back-end:

  • Ouvinte HTTPS. Um ouvinte HTTPS na porta 443 aceita ligações TLS de entrada de clientes.
  • Certificado TLS. Um certificado PFX, proveniente do Azure Key Vault, está associado ao ouvinte HTTPS. O Gateway de Aplicação desencripta o tráfego de entrada para o inspecionar e encaminhar, e depois volta a encriptá-lo para o pool de backend. Os servidores backend ainda precisam de certificados para as ligações reencriptadas, mas em muitos casos podem ser usados certificados geridos pela plataforma.
  • Conjunto de servidores de backend. Um pool backend define o conjunto de servidores HTTPS que recebem o tráfego reencriptado. Os alvos backend podem ser máquinas virtuais, Conjuntos de Dimensionamento de Máquinas Virtuais do Azure, endereços IP ou instâncias do Serviço de Aplicações do Azure. Restringa o acesso ao backend para que os clientes não possam contornar o Application Gateway e a sua política WAF ligando-se diretamente.
  • Definições HTTP do backend. Defina o protocolo do backend como HTTPS e a porta como a porta TLS do backend, por exemplo, 443. Configure a confiança do certificado e um nome de host que corresponda ao certificado do backend. Para uma autoridade certificadora privada, configure o certificado raiz de confiança. Para detalhes, veja TLS de ponta a ponta com o SKU v2.
  • Regra de roteamento. Uma regra de encaminhamento de pedidos associa o ouvinte ao pool de backend e às definições HTTP do backend. Regras baseadas em caminhos podem encaminhar diferentes caminhos de URL para diferentes pools de backend.
  • Política WAF. A política define as regras geridas e personalizadas usadas para inspecionar pedidos, incluindo quaisquer regras de Geomatch.

Como o Application Gateway desencripta o tráfego, pode inspecionar o conteúdo dos pedidos para encaminhamento inteligente, reescrever cabeçalhos e URLs HTTP e aplicar regras WAF. Depois, reencripta o tráfego antes de encaminhar os pedidos para o backend.

Para orientações de configuração, consulte Encriptação TLS de ponta a ponta com Gateway de Aplicação.

Tecnologias de apoio

Os seguintes serviços do Azure podem ajudá-lo a implementar este padrão:

Passos seguintes

  • Última atualização a