Padrão Gatekeeper

Proteja aplicações e serviços utilizando um componente dedicado para intermediar pedidos entre clientes e a aplicação ou serviço. O corretor valida e higieniza os pedidos, podendo fornecer uma camada extra de segurança e limitar a superfície de ataque do sistema.

Contexto e problema

Muitos serviços cloud expõem terminais que permitem às aplicações clientes chamar as suas APIs através da internet ou de outra rede não confiável. O código que implementa as APIs dispara ou executa várias tarefas, incluindo, mas não se limitando a, autenticação, autorização, validação de parâmetros e parte ou todo o processamento de pedidos. O código da API deverá aceder ao armazenamento e a outros serviços em nome do cliente.

Se um usuário mal-intencionado comprometer o sistema e obter acesso ao ambiente de hospedagem do aplicativo, seus mecanismos de segurança e acesso a dados e outros serviços são expostos. Como resultado, o usuário mal-intencionado pode obter acesso irrestrito a credenciais, chaves de armazenamento, informações confidenciais e outros serviços.

Solução

Uma solução para este problema é desacoplar o código que implementa endpoints públicos do código que processa pedidos e acede ao armazenamento. Desacople o código utilizando uma camada de fachada que interage com os clientes e encaminha os pedidos aprovados através de um ponto final interno, de uma fila ou de um broker para os componentes de carga de trabalho que tratam da operação de negócio. O diagrama fornece uma visão geral deste padrão.

Pode usar o padrão Gatekeeper para proteger o armazenamento, ou pode usá-lo como uma fachada mais abrangente para proteger todas as funções da aplicação. Fatores importantes incluem:

Validação controlada: O gatekeeper valida todos os pedidos e rejeita pedidos que não cumpram os requisitos de validação.
Risco e exposição limitados: Os riscos e a exposição são reduzidos porque o gatekeeper não acede às credenciais ou chaves que o anfitrião de confiança usa para aceder ao armazenamento e serviços. Se o gatekeeper for comprometido, os atacantes não conseguem aceder a estas credenciais ou chaves.
Segurança adequada: O gatekeeper funciona num modo de privilégio limitado, enquanto o resto da aplicação corre no modo de confiança total necessário para aceder ao armazenamento e aos serviços. Se o gatekeeper for comprometido, não pode aceder diretamente aos serviços da aplicação ou aos dados.

Este padrão funciona como uma firewall numa topografia de rede típica. Ao contrário de um firewall tradicional, permite ao gatekeeper examinar pedidos em detalhe e tomar uma decisão orientada pela aplicação sobre se deve passar o pedido para o host de confiança que executa as tarefas exigidas. Esta decisão normalmente exige que o guardião valide e higienize o conteúdo do pedido antes de o passar para o anfitrião de confiança. Os controladores podem autorizar o pedido, detetar conteúdo inesperado ou inválido na carga, aplicar limitação de taxa e realizar várias outras verificações.

Problemas e considerações

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

Certifique-se de que os hosts fidedignos expõem apenas endpoints internos ou protegidos, utilizados apenas pelo gatekeeper. Os anfitriões fidedignos não devem expor interfaces nem pontos finais externos.
O gatekeeper deve funcionar num modo de privilégio limitado. Na prática, instala o gatekeeper e o back-end confiável em ambientes de computação separados e mantém privados os pontos finais do back-end.
O guardião não deve realizar o processamento relacionado com a aplicação, serviços ou dados de acesso. A sua função é exclusivamente validar e higienizar pedidos. Os hosts de confiança podem precisar de realizar validação extra de pedidos, mas o gatekeeper deve realizar a validação principal.
Use um canal de comunicação seguro como HTTPS, Secure Sockets Layer (SSL) ou Transport Layer Security (TLS) entre o gatekeeper e os hosts ou tarefas de confiança, sempre que possível. No entanto, alguns ambientes de alojamento não suportam HTTPS em pontos finais internos.
Adicionar a camada extra para implementar o padrão Gatekeeper provavelmente afetará o desempenho devido ao processamento extra e à comunicação de rede necessários.
O gatekeeper pode ser um ponto único de falha (SPoF). Para minimizar o impacto de uma falha, considere implementar instâncias redundantes e utilizar um mecanismo de autoescalonamento para garantir a capacidade e manter a disponibilidade.

Quando utilizar este padrão

Utilize este padrão quando:

Lidas com informações sensíveis.
Expões serviços que requerem forte proteção contra tráfego malicioso.
Executa operações de missão crítica que não podem tolerar a exposição direta dos serviços de backend.
É necessário que a validação e a sanitização das solicitações sejam separadas do processamento central da lógica de negócio.

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

Pode satisfazer os requisitos de segurança e validação através de controlos de plataforma incorporados no serviço back-end sem adicionar um nível de gatekeeper dedicado.
Saltos adicionais de rede e latência de validação violam requisitos rigorosos de latência de ponta a ponta.

Design da carga de trabalho

Avalie como usar o padrão Gatekeeper no design de uma carga de trabalho para abordar os objetivos e princípios abordados nos pilares Azure Well-Architected Framework. A tabela a seguir fornece orientação sobre como esse padrão suporta as metas de cada pilar.

Pilar	Como esse padrão suporta os objetivos do pilar
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.	Um gatekeeper no fluxo de pedidos ajuda-o a centralizar funcionalidades de segurança como firewalls de aplicações web, proteção DDoS, deteção de bots, manipulação de pedidos, iniciação de autenticação e verificações de autorização. - SE:06 Controles de rede - SE:10 Monitorização e deteção de ameaças
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.	Pode usar este padrão para implementar a limitação ao nível do gatekeeper em vez de implementar verificações de taxa ao nível do nó. A coordenação do estado de taxa entre todos os nós não é inerentemente eficiente. - PE:03 Selecionar serviços

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

Example

O padrão Gatekeeper normalmente implementa um caminho de pedido em camadas, onde cada camada tem uma responsabilidade específica e um âmbito de confiança limitado.

Descarregue um ficheiro Visio desta arquitetura.

Neste design, Gateway de Aplicação do Azure com Firewall de Aplicações Web do Azure é o guardião exterior. Inspeciona o tráfego virado para a internet e aplica controlos de segurança antes de o tráfego atingir o nível da API. API Management do Azure é o guardião interior. Aplica controlos específicos da API e encaminha apenas o tráfego aprovado para backends privados.

Por exemplo, o Firewall de Aplicações Web do Azure pode detetar e bloquear padrões de injeção SQL e scripting cross-site, impor regras de protocolo e tamanho de pedido, e aplicar filtragem baseada em bots e IP antes que os pedidos cheguem à Gestão de API ou back-ends privados.

Quando utiliza a Gestão de APIs na camada interna, são aplicadas políticas aos pedidos de entrada e às respostas de saída no pipeline do gateway. Para mais informações sobre como a Gestão de APIs processa pedidos e respostas, consulte Políticas na Gestão de APIs. Para opções de políticas como validação do JSON Web Token (JWT), limitação de taxa, transformação de cabeçalhos e modelagem de respostas, consulte referência de políticas de Gestão de APIs.

Utilize identidades geridas para recursos do Azure de forma consistente para autenticação entre serviços neste percurso. Por exemplo, o API Management pode usar a política autenticar com identidade gerida para obter tokens do Microsoft Entra para chamadas ao back-end sem armazenar segredos.

A parte de trás mantém-se privada. Por exemplo, o backend pode ser uma aplicação Serviço de Aplicações do Azure que utiliza um endpoint privado, para que a aplicação possa ser acedida de forma privada.

Para cargas de trabalho contentorizadas, uma alternativa pode substituir o caminho interno de Gestão de API mais do Serviço de Aplicações por computação baseada em entrada:

Azure Kubernetes Service (AKS), que te dá mais controlo sobre a escolha do controlador de entrada, políticas Kubernetes, topologia de rede e operações do cluster.
Azure Container Apps, que é uma plataforma de contentores gerida sem servidor que oferece capacidades de entrada e reduz a gestão da infraestrutura.

Nestas alternativas, o Ingress pode encaminhar o tráfego com base no host ou no caminho, terminar ligações TLS e expor serviços apenas internos. Capacidades específicas, como limites de pedidos e regras de permitir ou recusar, dependem da implementação de entrada selecionada. Em todos os casos, mantenha os limites do gatekeeper: aplique validação e aplicação de políticas na entrada, e mantenha os serviços back-end acessíveis apenas através desse caminho do gatekeeper.

Cada camada neste percurso emite registos e métricas que deve centralizar. Os registos de diagnóstico do Firewall de Aplicações Web do Azure registam as regras acionadas e bloqueadas por pedido. O API Management gera registos do gateway que capturam a duração dos pedidos, os códigos de resposta e os resultados das políticas. Os serviços de back-end emitem telemetria ao nível da aplicação. Recolha estes registos e métricas em Azure Monitor e encaminhe-os para um espaço de trabalho Log Analytics para consultas unificadas. Normalizar a correlação de solicitações de ponta a ponta, gerando ou encaminhando um ID de correlação na extremidade e propagando-o pela camada de gestão de APIs e pelos serviços de back-end (por exemplo, através de cabeçalhos de solicitação e do contexto de rastreio distribuído), para que uma única transação permaneça rastreável em todas as camadas. Utilize o Microsoft Defender para a Cloud para apresentar recomendações de segurança em todos os componentes do Gatekeeper. Configure alertas sobre taxas de bloqueio anómalas do Firewall de Aplicações Web do Azure ou picos de erro na gestão de API para detetar ameaças antes que cheguem a backends privados.

Passos seguintes

As seguintes orientações podem ser relevantes ao implementar este padrão:

Os seguintes padrões de design de nuvens são frequentemente usados em conjunto com o padrão Gatekeeper:

Comentários

Esta página foi útil?

Last updated on 2026-06-03