Padrão de gatekeeper

Proteja aplicativos e serviços usando um componente dedicado para intermediar solicitações entre clientes e o aplicativo ou serviço. O agente valida e sanita as solicitações e pode fornecer uma camada extra de segurança e limitar a superfície de ataque do sistema.

Contexto e problema

Muitos serviços de nuvem expõem endpoints que permitem que aplicações cliente acessem suas APIs pela internet ou por 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 à autenticação, autorização, validação de parâmetro e algum ou todo o processamento de solicitação. O código da API provavelmente acessará o armazenamento e outros serviços em nome do cliente.

Caso um usuário mal-intencionado comprometa o sistema e obtenha acesso ao ambiente de hospedagem do aplicativo, seus mecanismos de segurança e acesso a dados e outros serviços ficam 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 esse problema é desacoplar o código que implementa pontos de extremidade públicos do código que processa solicitações e acessa o armazenamento. Desacople o código usando uma camada de fachada que interaja com os clientes e encaminhe as solicitações aprovadas por meio de um endpoint interno, fila ou broker para os componentes da carga de trabalho que lidam com a operação de negócio. O diagrama fornece uma visão geral de alto nível desse padrão.

Você pode usar o padrão Gatekeeper para proteger o armazenamento ou usá-lo como uma fachada mais abrangente para proteger todas as funções do aplicativo. Fatores importantes incluem:

• Validação controlada: O gatekeeper valida todas as solicitações e rejeita solicitações que não atendem aos requisitos de validação.

• Risco e exposição limitados: Os riscos e a exposição são reduzidos porque o gatekeeper não acessa as credenciais ou as chaves que o host confiável usa para acessar o armazenamento e os serviços. Se o gatekeeper ficar comprometido, os invasores não poderão acessar essas credenciais ou chaves.

• Segurança apropriada: O gatekeeper é executado em um modo de privilégio limitado, enquanto o restante do aplicativo é executado no modo de confiança total necessário para acessar o armazenamento e os serviços. Se o gatekeeper estiver comprometido, ele não poderá acessar diretamente os serviços ou dados do aplicativo.

Esse padrão funciona como firewall em uma topografia de rede típica. Ao contrário de um firewall tradicional, ele permite que o gatekeeper examine as solicitações em detalhes e tome uma decisão orientada pelo aplicativo sobre se deve passar a solicitação para o host confiável que executa as tarefas necessárias. Essa decisão normalmente exige que o gatekeeper valide e sanitize o conteúdo da solicitação antes de passá-lo para o host confiável. Os gatekeepers podem autorizar a solicitação, procurar conteúdo inesperado ou inválido na carga útil, aplicar limitação de taxa e realizar várias outras verificações.

Problemas e considerações

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

• Verifique se os hosts confiáveis expõem apenas endpoints internos ou protegidos, usados apenas pelo gatekeeper. Os hosts confiáveis não devem expor nenhum endpoint externo ou interfaces.

• O gatekeeper deve ser executado em um modo de privilégio limitado. Na prática, hospede o gatekeeper e o back-end confiável em domínios de computação separados e mantenha privados os endpoints do back-end.

• O gatekeeper não deve executar o processamento relacionado ao aplicativo, serviços ou dados de acesso. Sua função é apenas validar e limpar solicitações. Os hosts confiáveis podem precisar executar a validação de solicitação extra, mas o gatekeeper deve executar a validação principal.

• Use um canal de comunicação seguro, como HTTPS, SSL (Secure Sockets Layer) ou TLS (Transport Layer Security) entre o gatekeeper e os hosts confiáveis ou tarefas sempre que possível. No entanto, alguns ambientes de hospedagem não oferecem suporte a HTTPS em pontos de extremidade internos.

• A adição da camada extra para implementar o padrão Gatekeeper provavelmente afetará o desempenho devido ao processamento extra e à comunicação de rede necessárias.

• O gatekeeper pode ser um único ponto de falha (SPoF). Para minimizar o impacto de uma falha, considere implantar instâncias redundantes e usar um mecanismo de dimensionamento automático para garantir a capacidade e manter a disponibilidade.

Quando usar esse padrão

Use esse padrão quando:

• Você lida com informações confidenciais.

• Você expõe serviços que exigem proteção forte contra tráfego mal-intencionado.

• Você executa operações críticas que não podem tolerar a exposição direta de serviços de back-end.

• Você precisa que a validação e a sanitização de solicitação sejam separadas do processamento de negócios principal.

O padrão pode não ser adequado nestes casos:

• Você pode atender aos requisitos de segurança e validação por meio de controles de plataforma internos no serviço de back-end sem adicionar uma camada de gatekeeper dedicada.

• Os saltos de rede adicionados e a latência de validação violam requisitos estritos de latência de ponta a ponta.

Design de carga de trabalho

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

Se esse 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 solicitação em camadas, em que cada camada tem uma responsabilidade específica e um escopo de confiança limitado.

Carrege um arquivo Visio desta arquitetura.

Neste design, Gateway de Aplicativo do Azure com Firewall de Aplicativo Web do Azure é o gatekeeper externo. Ele inspeciona o tráfego voltado para a Internet e aplica controles de segurança antes que o tráfego atinja a camada de API. Gerenciamento de API do Azure é o gatekeeper interno. Ele aplica controles específicos à API e encaminha apenas o tráfego aprovado para back-ends privados.

Por exemplo, Firewall de Aplicativo Web do Azure pode detectar e bloquear a injeção de SQL e padrões de script entre sites, impor regras de protocolo e tamanho de solicitação e aplicar filtragem baseada em BOT e IP antes que as solicitações cheguem ao Gerenciamento de API ou back-ends privados.

Quando você usa o Gerenciamento de API na camada interna, ele aplica políticas a solicitações de entrada e respostas de saída no pipeline do gateway. Para obter mais informações sobre como o Gerenciamento de API processa solicitações e respostas, consulte Políticas no Gerenciamento de API. Para opções de política, como validação de JWT (Token Web JSON), limitação de taxa, transformação de cabeçalho e formatação de resposta, consulte a referência da política de Gerenciamento de API.

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

O back-end permanece privado. Por exemplo, o back-end pode ser um aplicativo Serviço de Aplicativo do Azure que usa um ponto de extremidade privado, para que o aplicativo possa ser acessado de forma privada.

Para cargas de trabalho em contêineres, uma alternativa pode substituir o Gerenciamento de API mais o caminho interno do Serviço de Aplicativo por computação baseada em entrada:

• AKS (Serviço de Kubernetes do Azure), o que oferece mais controle sobre a escolha do controlador de entrada, as políticas do Kubernetes, a topologia de rede e as operações de cluster.

• Aplicativos de Contêiner do Azure, que é uma plataforma de contêiner gerenciado sem servidor que fornece recursos de ingress e reduz o gerenciamento de infraestrutura.

Nessas alternativas, a entrada pode rotear por host ou caminho, encerrar o TLS e expor serviços somente internos. Recursos específicos, como limites de solicitação e regras de permissão ou negação, dependem da implementação de entrada selecionada. Em todos os casos, mantenha as fronteiras do gatekeeper: aplique a validação e a aplicação de políticas no ponto de entrada e mantenha os serviços de back-end acessíveis somente por meio desse gatekeeper.

Cada camada nesse caminho emite logs e métricas que você deve centralizar. Os logs de diagnóstico do Firewall de Aplicativo Web do Azure registram as regras correspondentes e bloqueadas para cada solicitação. O Gerenciamento de APIs gera logs de gateway que registram a duração da solicitação, os códigos de resposta e os resultados das políticas. Os serviços de back-end emitem telemetria no nível do aplicativo. Colete esses logs e métricas em Azure Monitor e encaminhe-os para um workspace Log Analytics para consulta unificada. Padronize a correlação de requisições de ponta a ponta gerando ou encaminhando um ID de correlação na borda da rede e propagando-o por meio do API Management e dos serviços de backend (por exemplo, por meio de cabeçalhos de requisição e do contexto de rastreamento distribuído), para que uma única transação permaneça rastreável em todas as camadas. Use Microsoft Defender para Nuvem para exibir recomendações de segurança entre os componentes do gatekeeper. Configure alertas sobre taxas de bloqueio anômalas do Firewall de Aplicativo Web do Azure ou picos de erros do API Management para detectar ameaças antes que elas cheguem aos back-ends privados.

Próximas Etapas 

As diretrizes a seguir podem ser relevantes quando você implementa esse padrão:

• Firewall de Aplicativo Web do Azure no Gateway de Aplicativo
• Políticas no Gerenciamento de API
• Usar pontos de extremidade privados para aplicativos do App Service

Recursos relacionados

Os seguintes padrões de design de nuvem geralmente são usados junto com o padrão Gatekeeper:

• Padrão de roteamento de gateway
• Padrão de alívio de gateway
• Padrão de identidade federada
• Padrão de chave de manobrista