Separe a publicação HTTP da execução da aplicação e dos dados persistentes. Um proxy inverso pode organizar o encaminhamento e os limites, mas o acesso à origem, a autorização da aplicação, a capacidade a montante e a recuperação exigem cada um os seus próprios controlos.
Um pedido web atravessa várias responsabilidades
Um servidor web recebe pedidos HTTP e pode servir ficheiros estáticos. Um processo de aplicação executa o comportamento dinâmico do projeto, como verificar uma conta ou consultar uma base de dados. Um proxy inverso recebe pedidos em nome desse processo e encaminha-os para uma origem a montante. Um programa pode desempenhar várias funções, mas separar as responsabilidades torna a configuração e a recuperação mais fáceis de compreender.
Siga um pedido desde a resolução do nome do anfitrião até à resposta. Registe onde termina o TLS, qual o processo que escolhe a rota e qual o componente que pode ler os dados da aplicação. Faça o mesmo para um pedido administrativo. Este exercício revela frequentemente um serviço de escuta ou nome de anfitrião que foi criado para testes e permaneceu acidentalmente acessível. O diagrama deve descrever o caminho implementado e não a arquitetura que esperava construir.
Utilize a periferia para organizar o comportamento HTTP
O NGINX documenta tanto o serviço de conteúdo estático como o encaminhamento de pedidos para uma origem a montante. A sua arquitetura de trabalhadores e os módulos HTTP fornecem mecanismos de configuração, mas é uma configuração específica que determina o comportamento. Defina deliberadamente nomes de anfitrião, origens a montante e raízes do sistema de ficheiros. Restrinja os ficheiros que podem ser servidos para que a configuração, as credenciais e os metadados do repositório nunca se tornem transferíveis só porque estão próximos da aplicação.
Defina limites adequados para corpos de pedido, tempos limite e ligações de acordo com a aplicação. Trate as caches como uma decisão sobre dados: o conteúdo associado a um utilizador ou permissão não pode herdar com segurança uma regra de cache partilhada sem revisão. Teste a autenticação e o comportamento da cache em conjunto. Mantenha uma configuração reproduzível e valide as alterações antes de recarregar o serviço, com uma rota conhecida de regresso à versão funcional anterior.
| Camada | Responsabilidade útil | Verificar antes do lançamento |
|---|---|---|
| Periferia web pública | TLS, encaminhamento por nome de anfitrião e limites HTTP | Certificados, raízes e nomes de anfitrião pretendidos |
| Processo de aplicação | Lógica de negócio e autorização | Autenticação, validação de entradas e falha de dependências |
| Serviço de dados interno | Estado persistente da aplicação | Acesso restrito e restauro testado |
| Rede do fornecedor a montante | O serviço de rede contratado | Âmbito de proteção e caminho de escalonamento |
Um proxy inverso não elimina a exposição da origem
Se a origem permanecer acessível publicamente, um cliente pode alcançá-la sem utilizar a rota de proxy pretendida. Restrinja o acesso à origem através do desenho da rede e da configuração da aplicação quando a implementação exigir essa fronteira. Numa única máquina, um backend pode frequentemente escutar em loopback ou num socket local. Entre máquinas, utilize rotas restritas explícitas e proteção adequada para a ligação a montante.
Os cabeçalhos reencaminhados também precisam de uma regra de confiança. Aceite informações sobre o cliente original apenas de intermediários de confiança e impeça que chamadores arbitrários forneçam valores que a aplicação trate como autoritativos. Decida o que aparece nos registos de acesso e nos relatórios de erros. Um proxy pode alterar a informação disponível em cada camada; não apaga identificadores de conta nem torna a aplicação anónima para o seu próprio operador.
Aplique decisões de acesso dentro da aplicação
A arquitetura Zero Trust do NIST centra-se nas decisões de acesso aos recursos em vez de uma confiança implícita baseada apenas na localização na rede. Aplique esse princípio de forma concreta: autentique o chamador, autorize a operação solicitada e conceda às contas de serviço apenas o âmbito necessário. Um pedido proveniente de uma sub-rede interna não deve tornar-se automaticamente num pedido de administrador.
Separe as funções públicas e administrativas sempre que possível. Verifique novamente a permissão quando um utilizador acede a um registo em vez de confiar apenas no início de sessão inicial. Mantenha distintas as credenciais do proxy, da aplicação e da base de dados. Introduza alterações em fases que possam ser testadas, começando por um caminho sensível restrito. Chamar Zero Trust a uma implementação é menos útil do que demonstrar que uma ação proibida é efetivamente negada no componente responsável por ela.
Planeie a negação de serviço em mais do que uma camada
Uma ligação de rede saturada e um pedido de aplicação dispendioso falham em locais diferentes. A limitação de taxa na periferia web pode ajudar a restringir padrões de pedidos, enquanto os limites da aplicação podem delimitar trabalho como pesquisas, carregamentos ou exportações. O módulo de limitação de pedidos do NGINX fornece um mecanismo; a chave e os limiares têm de se adequar aos utilizadores reais e ser testados para evitar rejeitar tráfego legítimo.
As orientações da OWASP sobre negação de serviço também abordam o esgotamento de recursos no comportamento da aplicação. Coloque limites de tempo e de tamanho em torno de trabalho dispendioso, utilize filas limitadas e monitorize sinais de falha. Os controlos locais não podem criar capacidade numa ligação a montante já saturada. Confirme a proteção de rede específica incluída na oferta escolhida e prepare um caminho de escalonamento. Nunca assuma que a proteção de Camada 3–4 de um catálogo também comprova a proteção para todas as cargas de trabalho HTTP.
Faça da recuperação parte da publicação
Verifique o site a partir de um cliente externo utilizando o nome de anfitrião pretendido. Valide o HTTPS, os redirecionamentos, os recursos estáticos, os inícios de sessão e uma transação representativa da aplicação. Confirme que os serviços de escuta administrativos e os ficheiros privados permanecem inacessíveis. Simule uma origem a montante parada e verifique se a periferia devolve uma falha controlada em vez de expor detalhes internos ou esperar sem limite.
Para o Canvas, leia os controlos disponíveis na conta de alojamento. Para um VPS, mantenha a periferia web e a aplicação como parte do seu próprio plano operacional. Uma porta de rede grande é uma especificação de capacidade, não uma prova de que a aplicação consegue sustentar esse débito. Mantenha a monitorização, o restauro e os contactos do fornecedor no manual de operações. Publique apenas depois de o caminho de pedido real e um caminho de recuperação prático terem sido verificados.
A sua lista de verificação prática.
- Siga um pedido público e um pedido administrativo.
- Defina raízes servidas e serviços de escuta a montante.
- Confie nos cabeçalhos reencaminhados apenas de intermediários aprovados.
- Teste a autorização e os limites da cache.
- Prepare limites e escalonamento para falhas de rede e de aplicação.
Os detalhes que importam.
Um servidor web pode também atuar como proxy inverso?+
Sim. O NGINX é um exemplo documentado. As suas funções dependem da configuração e a aplicação continua a precisar da sua própria autorização e manutenção.
Um proxy inverso oculta automaticamente a origem?+
Não. A origem pode permanecer acessível a menos que o encaminhamento, a firewall e as definições dos serviços de escuta imponham a fronteira pretendida.
A limitação de pedidos irá parar todos os ataques DDoS?+
Não. Aborda padrões de pedidos HTTP selecionados. A saturação da rede e outras falhas de recursos exigem controlos adequados a montante e na aplicação.
Vá à fonte.
Estas referências sustentam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema de produção.
- NGINX: Guia para principiantes nginx.org
- NGINX: Limitação de pedidos HTTP nginx.org
- NIST SP 800-207: Arquitetura Zero Trust nvlpubs.nist.gov
- OWASP: Prevenção de Negação de Serviço cheatsheetseries.owasp.org
Orientação editorial da SwissOctet. Os exemplos são ilustrativos. As especificações de serviço, as opções disponíveis e as condições contratuais devem ser verificadas separadamente.