Use o Google Cloud Armor, o balanceamento de carga e o Cloud CDN para implementar front-ends globais programáveis

Last reviewed 2025-04-02 UTC

Este documento fornece uma arquitetura de referência para uma aplicação Web alojada no Google Cloud. A arquitetura usa um front-end global que incorpora Google Cloud práticas recomendadas para ajudar a dimensionar, proteger e acelerar a entrega das suas aplicações viradas para a Internet. A arquitetura inclui suporte para o Cloud Build, bem como ferramentas de integração contínua (IC) e entrega contínua (EC) de terceiros, como o Jenkins e o GitLab. Esta arquitetura destina-se a programadores e proprietários de apps que querem dimensionar a respetiva aplicação com um equilibrador de carga e proteger as respetivas aplicações contra ataques de negação de serviço distribuída (DDoS) e baseados na Web com uma firewall de aplicação Web (WAF).

Arquitetura

O diagrama seguinte mostra a arquitetura descrita neste documento.

Arquitetura de aplicações Web.

Nesta arquitetura, a aplicação tem o balanceamento de carga com balanceadores de carga de aplicações externos globais, que distribuem o tráfego HTTP e HTTPS por várias instâncias de back-end em várias regiões. A RFC do Google Cloud acelera as aplicações viradas para a Internet através dos pontos de presença (PoPs) na periferia da Google e funciona com o Application Load Balancer externo global para fornecer conteúdo aos utilizadores. Os back-ends estão protegidos por políticas de segurança do Google Cloud Armor que fornecem filtragem da camada 7 através da limpeza de pedidos recebidos para ataques Web comuns ou outros atributos da camada 7, o que ajuda a bloquear o tráfego antes de chegar aos serviços de back-end com equilíbrio de carga. A proteção contra ataques DDoS volumétricos está ativada por predefinição.

Quando um utilizador pede conteúdo ao seu serviço, esse pedido é enviado para o front-end global para aplicações viradas para a Internet, que é fornecido pela rede entre nuvens. O pedido é avaliado pelas políticas de segurança do Cloud Armor, começando pelas políticas de segurança de edge do Cloud Armor. Se o pedido for permitido e puder ser cumprido pelo Cloud CDN, o conteúdo é obtido a partir da cache do Cloud Armor e enviado de volta para o utilizador. Se o pedido resultar numa falha de cache, é avaliado pelas políticas de back-end e, em seguida, de acordo com as regras da política, é recusado ou cumprido pelo seu servidor de back-end.

Componentes de arquitetura

O diagrama anterior inclui os seguintes componentes:

  • Balanceador de carga de aplicações externo global: este balanceador de carga de aplicações é um balanceador de carga da camada 7 baseado em proxy que lhe permite executar e dimensionar os seus serviços. O balanceador de carga de aplicações distribui o tráfego HTTP e HTTPS para back-ends alojados numa variedade de Google Cloud plataformas. O balanceador de carga de aplicações tem as seguintes funcionalidades:

    • Back-end configurável: esta arquitetura usa dois grupos de instâncias geridas (GIGs) em regiões diferentes, mas pode configurar qualquer back-end que o balanceador de carga de aplicações externo global suporte. Pode usar o mesmo equilibrador de carga para GKE, Cloud Run, funções do Cloud Run e aplicações do App Engine, bem como para as alojadas no local e noutras nuvens através de uma configuração de back-end diferente. Para saber mais, consulte o artigo Vista geral do Application Load Balancer.
    • Divisão do tráfego: pode usar o Application Load Balancer para a gestão do tráfego, incluindo a gestão de versões de software através do envio de diferentes utilizadores para diferentes servidores de back-end. Na arquitetura descrita neste documento, existe uma divisão de tráfego simples de 60/40. No entanto, pode alterar esta divisão para criar esquemas de gestão de tráfego mais complexos. Para saber mais sobre as opções de configuração adicionais, consulte os tempos limite e as repetições configuráveis e determine o seu modo de equilíbrio preferido.
  • Cloud CDN: a plataforma Cloud CDN funciona como uma cache. É implementado com o servidor de origem para fornecer o conjunto completo de funcionalidades do Cloud CDN, incluindo QUIC e HTTP/2, bem como controlos de encaminhamento e colocação em cache. Esta abordagem permite que a sua aplicação seja dimensionada globalmente sem comprometer o desempenho e também reduz a largura de banda e os custos de computação de front-end. A configuração predefinida usada pelo front-end global baseia-se nas práticas recomendadas de fornecimento de conteúdo da RFC e nas práticas recomendadas de segurança Web.

  • Cloud Armor: este componente inclui proteção contra DDoS e regras de WAF. A arquitetura tem a seguinte configuração básica do Cloud Armor, que ajuda a mitigar vetores de ameaças comuns:

Produtos usados

Esta arquitetura de referência usa os seguintes produtos Google Cloud :

Considerações de design

Esta secção fornece orientações para ajudar a usar este documento como ponto de partida para desenvolver uma arquitetura que cumpra os seus requisitos específicos de segurança, fiabilidade, eficiência operacional, custo e desempenho.

Segurança, privacidade e conformidade

Esta secção descreve fatores adicionais que deve considerar quando usa esta arquitetura de referência para implementar a aplicação Web.

Estabeleça uma base de referência de segurança

Para ajudar a melhorar ainda mais a sua segurança, a arquitetura descrita neste documento também é compatível com o projeto de base empresarial. Este plano ajuda as organizações que usam o Google Cloud a estabelecer uma base segura para todas as cargas de trabalho futuras, incluindo a configuração da gestão de identidade e de acesso (IAM), do Cloud Key Management Service e do Security Command Center.Google Cloud

Proteja os dados do utilizador com o Cloud CDN

Nesta arquitetura, recomendamos que não coloque em cache conteúdo específico do utilizador. Para colocar em cache tipos de conteúdo HTML (text/html) e JSON (application/json), defina cabeçalhos de controlo de cache explícitos na resposta do Cloud CDN. Certifique-se de que não coloca em cache os dados de um utilizador e os disponibiliza a todos os utilizadores.

Controle o acesso à sua aplicação com a IAP

A arquitetura também é compatível com o Identity-Aware Proxy (IAP). A IAP valida a identidade de um utilizador e, em seguida, determina se esse utilizador deve ter permissão para aceder a uma aplicação. Para ativar o IAP para o balanceador de carga de aplicações no modo externo global ou no modo clássico, ative-o nos serviços de back-end do balanceador de carga. Os pedidos HTTP/HTTPS de entrada são avaliados pelo Cloud Armor antes de serem enviados para o balanceamento de carga pelo Application Load Balancer. Se o Cloud Armor bloquear um pedido, o IAP não avalia o pedido. Se o Cloud Armor permitir um pedido, o IAP avalia esse pedido. O pedido é bloqueado se a IAP não autenticar o pedido. Para saber mais, consulte o artigo Integrar o Cloud Armor com outros produtos Google.

Otimização de custos

Como diretriz geral, a utilização do Cloud CDN juntamente com o Cloud Armor pode ajudar a minimizar o efeito dos custos de transferência de dados de saída.

Cloud CDN

Os objetos estáticos publicados para o cliente a partir da cache não transitam pelo equilibrador de carga. Uma estratégia de colocação em cache eficaz pode reduzir a quantidade de dados de saída processados pelo balanceador de carga e diminuir os custos.

Google Cloud Armor

O Cloud Armor ajuda a reduzir os custos, impedindo que a sua conta seja cobrada por tráfego indesejado. Os pedidos bloqueados pelo Cloud Armor não geram uma resposta da sua app, o que reduz efetivamente a quantidade de dados de saída processados pelo balanceador de carga. O efeito nos seus custos depende da percentagem de tráfego indesejável bloqueado pelas políticas de segurança do Cloud Armor que implementar.

Os custos finais também podem variar consoante o número de serviços ou aplicações que quer proteger, o número de políticas e regras do Cloud Armor que tem, o preenchimento da cache e a saída, bem como o volume de dados. Para saber mais, consulte o seguinte:

Implementação

Para implementar esta arquitetura de referência, use o exemplo do Terraform. Para saber mais, consulte o ficheiro README. A pasta web_app_protection_example inclui o ficheiro (main.tf). O código neste ficheiro cria a arquitetura descrita neste documento e oferece apoio técnico adicional para a implementação automática.

A estrutura de pastas na pasta do Terraform é a seguinte:

Quando confirma uma alteração a qualquer ramificação na qual a sua pipeline se baseia, essas alterações acionam uma execução da pipeline e as alterações são integradas numa nova versão assim que estiver concluída. Quando extrai o conjunto de ferramentas pela primeira vez, a solução é carregada para o Google Cloud projeto escolhido.

O que se segue?

Saiba mais acerca das práticas recomendadas para os Google Cloud produtos usados nesta arquitetura de referência:

Colaboradores

Autores:

Outros colaboradores: