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.

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:

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.

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:

• Utilize Application Gateway para tráfego Web regional.

• Utilize o Gateway de Aplicação do Azure for Containers para entrada nativa do Kubernetes para cargas de trabalho do AKS.

• Use o Azure Front Door para tráfego web global ou multirregional.

• Use o API Management do Azure para questões específicas da API, como autenticação, limitação, transformação e monitorização.

Passos seguintes

• Opções de balanceamento de carga
• Utilizar gateways de API em microsserviços

Recursos relacionados

• Padrão de Back-ends para Front-ends
• Padrão de Agregação de Gateway
• Padrão de Encaminhamento do Gateway
• Padrão de limitação
• Proteja APIs usando o Application Gateway e o Gerenciamento de API