# Separe a sua periferia web pública da aplicação | SwissOctet Insights https://swissoctet.com/pt/insights/separate-the-web-edge-from-the-app/ SwissOctet / Informações / Web e onion Web e onion Aplicado · 4 min de leitura Separe a sua periferia web pública da aplicação Atribua responsabilidades distintas ao servidor web, ao proxy inverso e à aplicação, com acesso deliberado à origem, TLS, limites de pedidos e um percurso de incidentes. Por SwissOctet Editorial Guardar guia Copiar ligação NESTA PÁGINA 01 Um pedido web atravessa várias responsabilidades 02 Utilize a periferia para organizar o comportamento HTTP 03 Um proxy inverso não elimina a exposição da origem 04 Aplique decisões de acesso dentro da aplicação 05 Planeie a negação de serviço em mais do que uma camada 06 Faça da recuperação parte da publicação A sua lista de verificação prática Fontes e leitura adicional Voltar à biblioteca A RESPOSTA DIRETA 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. 01 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. 02 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 03 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. 04 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. 05 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. 06 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. TRANSFORME ISTO EM AÇÃO 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. Descarregar lista de verificação PERGUNTAS FREQUENTES 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. REFERÊNCIAS PRIMÁRIAS 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. LIGUE O CONHECIMENTO Infraestrutura relacionada. Canvas Web Suíça Vector VPS Suíça Pulse NVMe Suíça Transit 40 Suíça MANTENHA O FIO As suas próximas notas de campo. Explore todos os guias NOTA DE CAMPO / 01 + Operações do dia-a-dia Aplicado Uma base de endurecimento do Linux VPS que pode manter Administre com segurança, exponha apenas os serviços necessários e estabeleça atualizações e recuperação sem se bloquear a si próprio. 6 min de leitura Leia o guia NOTA DE CAMPO / 02 + Web e onion Fundação Alojamento web ou um VPS: escolha o trabalho que quer assumir Compare os requisitos da aplicação, o controlo e as responsabilidades de manutenção, em vez de tratar um VPS como o passo seguinte automático para todos os sites. 6 min de leitura Leia o guia NOTA DE CAMPO / 03 + Web e onion Aplicado Um manual de transição de domínio, DNS e TLS para um novo servidor Prepare o encaminhamento de nomes de anfitrião, certificados e reversão em conjunto, para que uma migração mude o servidor sem quebrar a identidade do site nem as ligações seguras. 4 min de leitura Leia o guia