Padrão de descarregamento de gateway

Descarregue a funcionalidade de serviço especializado ou compartilhado para um proxy do gateway. Essa abordagem simplifica o desenvolvimento de aplicativos centralizando preocupações de corte cruzado, como a terminação de certificado TLS voltada para o cliente, no gateway, em vez de duplicá-las entre serviços.

Quando vários serviços compartilham responsabilidades, como autenticação, monitoramento ou tradução de protocolo, consolidar essas preocupações em um único gateway reduz o risco de implantação e sobrecarga de configuração por serviço.

Contexto e problema

Alguns recursos são comumente usados em vários serviços e esses recursos exigem configuração, gerenciamento e manutenção. Um serviço compartilhado ou especializado que você distribui com cada implantação de aplicativo adiciona sobrecarga administrativa e aumenta a probabilidade de erro de implantação. Você deve implantar todas as atualizações em um recurso compartilhado em todos os serviços que compartilham esse recurso.

Problemas de segurança, como validação de token, criptografia e gerenciamento de certificadoS TLS, podem exigir que os membros da equipe tenham habilidades altamente especializadas. Por exemplo, sem um gateway, talvez seja necessário configurar e implantar um certificado voltado para o cliente em cada instância do aplicativo. Você deve acompanhar sua expiração e atualizar, testar e verificá-la entre essas instâncias.

Outros serviços comuns, como autenticação, autorização, registro em log, monitoramento ou limitação, podem ser difíceis de implementar e gerenciar em várias implantações. A consolidação desse tipo de funcionalidade reduz a sobrecarga e a chance de erros.

Solução

Transferir algumas funcionalidades para um gateway. Em seguida, o gateway lida com aspectos transversais, como, por exemplo, o gerenciamento de certificados voltados ao cliente, autenticação, terminação de TLS, monitoramento, tradução de protocolo e limitação de taxa em nome dos serviços de backend.

O diagrama a seguir mostra um gateway que encerra conexões TLS de entrada e aplica recursos compartilhados. O gateway valida o certificado de back-end e criptografa novamente o tráfego em uma conexão TLS separada para o serviço de back-end.

Os benefícios desse padrão incluem:

• Simplifique o desenvolvimento de serviços centralizando a configuração compartilhada, como autenticação, limitação e registro em log de solicitações, em vez de implementá-la em cada serviço de back-end. A centralização melhora a consistência e torna as atualizações de serviço mais simples.

• Permitir que equipes dedicadas implementem recursos que exigem competências especializadas, como a segurança. Sua equipe principal pode então se concentrar na funcionalidade do aplicativo, deixando essas preocupações especializadas, mas de corte cruzado, para os especialistas relevantes.

• Fornecer alguma consistência para registro em log e monitoramento de solicitações e respostas. Mesmo que um serviço não esteja devidamente instrumentado, o gateway pode fornecer um nível básico de monitoramento e geração de logs.

• Centralize o gerenciamento de tráfego consciente de carbono. Um gateway pode ajustar comportamentos de cache, limitação de taxa e registro de logs com base em sinais de intensidade de carbono em tempo real. Gerenciamento de API do Azure fornece esses recursos em versão prévia limitada, em regiões selecionadas e camadas clássicas (Desenvolvedor, Básico, Standard e Premium). Para obter detalhes de disponibilidade e configuração, consulte APIs ambientalmente sustentáveis em Gerenciamento de API do Azure.

• Manipule mapeamentos de URL estáticos antigos para novos. O gateway pode retornar um redirecionamento sem invocar um back-end, mantendo a manipulação de URL herdada fora do pipeline de solicitação de cada serviço.

Problemas e considerações

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

• Alta disponibilidade e resiliência. Garanta que o gateway seja altamente disponível e resistente a falhas. Evite pontos únicos de falha operando várias instâncias do seu gateway. Como o gateway finaliza as conexões dos clientes e pode armazenar em buffer os corpos das solicitações, considere como as solicitações em andamento são tratadas em caso de falha da instância. Use mecanismos de drenagem de conexões ou de desligamento gracioso para evitar que a remoção ou a reinicialização de uma instância de gateway interrompa as sessões ativas.

• Capacidade e dimensionamento. Assegure que o gateway seja projetado para os requisitos de capacidade e dimensionamento de seu aplicativo e pontos de extremidade. Verifique se o gateway não se torna um gargalo para o aplicativo e é suficientemente escalonável. O gateway deve ser provisionado para lidar com picos de tráfego, não apenas carga média. O subprovisionamento do gateway para reduzir o custo prejudica diretamente o desempenho de cada serviço por trás dele.

• Escopo de transferência de carga de trabalho. Delegue funcionalidades compartilhadas por múltiplos serviços ou rotas quando centralizá-las reduzir a duplicação de implementação e gerenciamento.

• Correspondência de redirecionamentos. Faça a correspondência apenas com as URLs legadas pretendidas e preserve o roteamento normal para solicitações sem correspondência. Mantenha no aplicativo os redirecionamentos que dependem do estado de negócio ou da autorização específica do aplicativo. Para obter diretrizes relacionadas, consulte Preservar links quando o conteúdo for movido.

• Separação de lógica de negócios. Nunca transfira a lógica de negócio para o gateway.

• Acompanhamento de transações. Se precisar controlar transações, leve em consideração gerar IDs de correlação para fins de registro de log.

• Sobrecarga de latência. O gateway adiciona um salto de rede a cada solicitação. Cada função delegada ao gateway, como terminação de TLS, autenticação ou inspeção de requisições, aumenta o tempo de processamento no caminho da requisição. O pool de conexões do gateway e as conexões persistentes (keep-alive) com serviços de backend podem compensar parcialmente o custo da latência ao reutilizar conexões, em vez de estabelecer novas conexões para cada solicitação. Avalie se a latência combinada do salto do gateway e das funções descarregadas é aceitável para as metas de desempenho da carga de trabalho.

• Complexidade operacional. Um gateway centralizado consolida o gerenciamento, mas também concentra a responsabilidade operacional. Você deve gerenciar a configuração do gateway, o ciclo de vida do certificado, as atualizações de política e as atualizações de versão como uma preocupação compartilhada. Verifique se a equipe responsável pelo gateway tem a capacidade e as ferramentas para gerenciá-lo na escala de todos os serviços que dependem dele.

• Implicações de segurança. O gateway é um alvo de alto valor porque centraliza funções transversais de segurança, como autenticação, terminação de TLS e inspeção de requisições. Um comprometimento do gateway pode expor todos os serviços downstream. Proteja o gateway, restrinja sua superfície de gerenciamento e monitore-o para comportamento anômalo independentemente dos serviços de back-end que ele protege.

• Prevenção de desvio de gateway. Configure os serviços de back-end para aceitar solicitações somente por meio do caminho de gateway pretendido. Caso contrário, os clientes poderão se conectar diretamente a um back-end e ignorar autenticação, limitação, inspeção de solicitação e registro em log no gateway.

• Propagação de identidade. Defina se cada back-end autoriza o chamador original, a identidade da carga de trabalho do gateway ou ambos. Preserve tokens de chamador ou declarações confiáveis somente quando o back-end exigir contexto de usuário delegado. Sempre autentique o gateway no backend separadamente. Não trate cabeçalhos encaminhados não verificados como prova de identidade.

• Manutenção do TLS. Se o gateway encerrar a conexão TLS, restabeleça a conexão TLS com o backend. Não encaminhe o tráfego por HTTP não criptografado. Trate todas as redes como não confiáveis. Essa topologia ainda requer um processo para emitir, renovar e revogar certificados do back-end.

• Cabeçalhos encaminhados e contexto do cliente. Quando o gateway encerra as conexões do cliente e estabelece novas conexões com serviços de back-end, 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 o encaminhe explicitamente. Para obter estratégias de mitigação, consulte Preservar o nome original do host HTTP entre um proxy reverso e seu aplicativo Web de back-end.

Quando usar esse padrão

Use esse padrão quando:

• Uma implantação de aplicativo tem uma preocupação compartilhada, como certificados TLS ou criptografia.
• Um recurso comum entre implantações de aplicativos pode ter requisitos de recursos diferentes, como recursos de memória, capacidade de armazenamento ou conexões de rede.
• Você deseja transferir a responsabilidade por questões como segurança de rede, limitação de tráfego ou outras questões relacionadas ao perímetro da rede para uma equipe mais especializada.

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

• O gateway deve conter regras de roteamento ou lógica específicas do serviço que acoplam rigorosamente as alterações de serviço de back-end às alterações de configuração do gateway. Acoplamento da camada de gateway com serviços internos significa que as atualizações de back-end podem forçar a reimplantação do gateway, reduzindo a independência da implantação.
• A tarefa delegada é leve e a carga de trabalho é sensível à latência. O salto de rede adicional por meio do gateway pode não ser justificado quando a sobrecarga supera o benefício da centralização.
• Centralizar preocupações em um gateway compartilhado cria um gargalo de gerenciamento de alterações. Se o ciclo de lançamento da equipe de gateway for mais lento que o das equipes de serviço, o descarregamento poderá atrasar as atualizações de certificados, políticas de autenticação ou regras de rede.

Design de carga de trabalho

Um arquiteto deve avaliar como o padrão de Descarregamento de Gateway pode ser usado no design das suas cargas de trabalho para abordar os objetivos e princípios abordados nos pilares da estrutura bem arquitetada do Azure. Por exemplo:

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

Example

Gateway de Aplicativo do Azure WAF_v2 pode implementar esse padrão para um aplicativo Web regional. O gateway encerra as conexões TLS do cliente, aplica o WAF e as políticas de roteamento e estabelece novas conexões TLS com os serviços de back-end. Esse design mantém as preocupações de processamento de solicitação compartilhadas fora do código do aplicativo de back-end.

Gateway de Aplicação com descarregamento de TLS

O diagrama a seguir mostra como o Gateway de Aplicativo encerra conexões TLS de entrada, inspeciona e filtra o tráfego e o criptografa novamente antes de encaminhá-lo para um pool de back-end por TLS.

Essa arquitetura usa os seguintes componentes do Gateway de Aplicativo para descarregar recursos compartilhados e criptografar novamente o tráfego de back-end:

• Listener HTTPS. Um serviço de escuta HTTPS na porta 443 aceita conexões TLS de entrada provenientes de clientes.
• Certificado TLS. Um certificado PFX, proveniente de Azure Key Vault, é anexado ao ouvinte HTTPS. O Application Gateway descriptografa o tráfego de entrada para inspecioná-lo e roteá-lo e, em seguida, o criptografa novamente para o pool de back-end. Os servidores de back-end ainda precisam de certificados para as conexões criptografadas novamente, mas, em muitos casos, os certificados gerenciados pela plataforma podem ser usados.
• Pool de backend. Um pool de back-end define o conjunto de servidores HTTPS que recebem o tráfego criptografado novamente. Os destinos de back-end podem ser máquinas virtuais, Conjuntos de Dimensionamento de Máquinas Virtuais do Microsoft Azure, endereços IP ou instâncias de Serviço de Aplicativo do Azure. Restrinja o acesso ao back-end para que os clientes não possam contornar o Application Gateway e sua política de WAF conectando-se diretamente.
• Configurações HTTP de back-end. Defina o protocolo de back-end como HTTPS e a porta para a porta TLS do back-end, como 443. Configure a confiança do certificado e um nome de host que corresponda ao certificado de back-end. Para uma autoridade de certificação privada, configure o certificado raiz confiável. Para obter detalhes, consulte TLS de ponta a ponta com o SKU v2.
• Regra de roteamento. Uma regra de roteamento de solicitações associa o listener ao pool de back-end e às configurações de HTTP do back-end. As regras baseadas em caminhos podem encaminhar diferentes caminhos de URL para diferentes conjuntos de back-end.
• Política do WAF. A política define as regras gerenciadas e personalizadas usadas para inspecionar solicitações, incluindo quaisquer regras de Geomatch.

Como o Application Gateway descriptografa o tráfego, ele pode inspecionar o conteúdo da requisição para realizar roteamento inteligente, reescrever cabeçalhos HTTP e URLs e aplicar regras de WAF. Em seguida, ele criptografa novamente o tráfego antes de encaminhar solicitações para o back-end.

Para obter diretrizes de configuração, consulte criptografia TLS de ponta a ponta com o Gateway de Aplicativo.

Tecnologias de suporte

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

• Use o Application Gateway para tráfego Web regional.

• Use o Gateway de Aplicativo para Contêineres do Azure para Ingress nativo do Kubernetes para cargas de trabalho do AKS.

• Use Azure Front Door para o tráfego da Web global ou de várias regiões.

• Use Gerenciamento de API do Azure para preocupações específicas da API, como autenticação, limitação, transformação e monitoramento.

Próximas Etapas 

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

Recursos relacionados

• Padrão Backends for Frontends
• Padrão de agregação de gateway
• Padrão de roteamento de gateway
• Padrão de limitação
• Proteger APIs usando o Gateway de Aplicativo e o Gerenciamento de API