Proteja aplicativos e serviços usando uma instância de host dedicada para intermediar solicitações entre clientes e o aplicativo ou serviço. O corretor valida e limpa as solicitações, e pode fornecer uma camada adicional de segurança e limitar a superfície de ataque do sistema.
Contexto e problema
Os serviços de nuvem expõem pontos de extremidade que permitem que aplicativos cliente chamem suas APIs. O código usado para implementar as APIs aciona ou executa várias tarefas, incluindo, entre outras, autenticação, autorização, validação de parâmetros e parte ou todo o processamento de solicitações. É provável que o código da API acesse o armazenamento e 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 esse problema é dissociar o código que implementa pontos de extremidade públicos, do código que processa solicitações e acessa o armazenamento. Você pode obter o desacoplamento usando uma fachada ou uma tarefa dedicada que interage com os clientes e, em seguida, entrega a solicitação — talvez por meio de uma interface dissociada — para os hosts ou tarefas que lidam com a solicitação. A figura fornece uma descrição geral de alto nível deste padrão.
O padrão gatekeeper pode ser usado para proteger o armazenamento, ou pode ser usado como uma fachada mais abrangente para proteger todas as funções da aplicação. Fatores importantes:
- Validação controlada. O gatekeeper valida todas as solicitações e rejeita as solicitações que não atendem aos requisitos de validação.
- Risco e exposição limitados. O controlador de chamadas não tem acesso às credenciais ou às chaves utilizadas pelo anfitrião fidedigno para aceder ao armazenamento e aos serviços. Se o controlador de chamadas for comprometido, o atacante não obterá acesso a estas credenciais ou chaves.
- Segurança adequada. O controlador de chamadas é executado num modo de privilégios limitados, enquanto o resto da aplicação é executada no modo de fidedignidade total necessário para aceder ao armazenamento e aos serviços. Se o controlador de chamadas for comprometido, não poderá aceder diretamente aos serviços da aplicação ou aos dados.
Este padrão funciona como uma firewall numa topografia de rede típica. Ele permite que o gatekeeper examine as solicitações e tome uma decisão sobre se deve passar a solicitação para o host confiável que executa as tarefas necessárias. Por norma, esta decisão precisa que o controlador de chamadas valide e limpe o conteúdo do pedido antes de o transmitir para o anfitrião fidedigno.
Problemas e considerações
Na altura de decidir como implementar este padrão, considere os seguintes pontos:
- Certifique-se de que os hosts confiáveis exponham apenas pontos de extremidade internos ou protegidos, usados apenas pelo gatekeeper. Os anfitriões fidedignos não devem expor interfaces nem pontos finais externos.
- O gatekeeper deve ser executado em um modo de privilégio limitado, que normalmente requer a execução do gatekeeper e do host confiável em serviços hospedados separados ou máquinas virtuais.
- O gatekeeper não deve realizar qualquer processamento relacionado com a aplicação ou serviços ou aceder a quaisquer dados. A sua função é basicamente validar e limpar os pedidos. Os hosts confiáveis podem precisar executar a validação de solicitação adicional, mas o gatekeeper deve executar a validação principal.
- Use um canal de comunicação seguro (HTTPS, SSL ou TLS) entre o gatekeeper e os hosts ou tarefas confiáveis 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 adicional e à comunicação de rede necessários.
- A instância do controlador de chamadas pode ser um ponto único de falha. Para minimizar o impacto de uma falha, considere implantar instâncias redundantes e usar um mecanismo de dimensionamento automático para garantir a capacidade de manter a disponibilidade.
Quando utilizar este padrão
Esse padrão é útil para aplicativos que:
- lidar com informações confidenciais
- Expor serviços que exigem um alto grau de proteção contra ataques mal-intencionados
- Execute operações de missão crítica que não podem ser interrompidas.
- Exigir que a validação da solicitação seja realizada separadamente das tarefas principais, ou centralizar essa validação para simplificar a manutenção e a administração
Design da carga de trabalho
Um arquiteto deve avaliar como o padrão Gatekeeper pode ser usado no design de sua carga de trabalho para abordar as metas e os princípios abordados nos pilares do Azure Well-Architected Framework. Por exemplo:
| 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. | Adicionar um gateway ao fluxo de solicitações permite centralizar a funcionalidade de segurança, como firewalls de aplicativos da Web, proteção contra DDoS, deteção de bots, manipulação de solicitações, início 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. | Esse padrão é como você pode implementar a limitação em um nível de gateway em vez de implementar verificações de taxa no nível do nó. A coordenação do estado da taxa entre todos os nós não é inerentemente eficiente. - PE:03 Seleção de serviços |
Como em qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com esse padrão.
Exemplo
Em um cenário hospedado na nuvem, esse padrão pode ser implementado desacoplando a função gatekeeper ou a máquina virtual das funções e serviços confiáveis em um aplicativo. A implementação pode usar um ponto de extremidade interno, uma fila ou armazenamento como um mecanismo de comunicação intermediário. A figura ilustra a utilização de um ponto final interno.
Recursos relacionados
O padrão da Chave Valet também pode ser relevante aquando da implementação do padrão do controlador de chamadas. Ao se comunicar entre o Gatekeeper e funções confiáveis, é uma boa prática aprimorar a segurança usando chaves ou tokens que limitam as permissões de acesso a recursos. O padrão descreve o uso de um token ou chave que fornece aos clientes acesso restrito e direto a um recurso ou serviço específico.