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

Last reviewed 2024-04-04 UTC

Neste documento, apresentamos uma arquitetura de referência para um aplicativo da Web hospedado no Google Cloud. A arquitetura usa um front-end global que incorpora as práticas recomendadas do Google Cloud para ajudar a escalonar, proteger e acelerar a entrega dos seus aplicativos voltados para a Internet. A arquitetura inclui suporte para o Cloud Build, bem como ferramentas de integração contínua (CI) e entrega contínua (CD) de terceiros, como Jenkins e GitLab. Essa arquitetura é desenvolvida para desenvolvedores e proprietários de apps que querem escalonar os aplicativos com um balanceador de carga e proteger os aplicativos contra ataques distribuídos de negação de serviço (DDoS) e baseados na Web com um firewall de aplicativos da Web (WAF).

Arquitetura

O diagrama a seguir mostra a arquitetura descrita neste documento.

Arquitetura de aplicativos da Web.

Nesta arquitetura, a carga do aplicativo é balanceada com balanceadores de carga de aplicativo externos globais, que distribuem tráfego HTTP e HTTPS entre várias instâncias de back-end, em várias regiões. O Cloud CDN acelera aplicativos voltados à Internet usando os pontos de presença (PoPs) do Google e trabalha com o balanceador de carga de aplicativo externo global para fornecer conteúdo aos usuários. Os back-ends são protegidos por políticas de segurança do Google Cloud Armor, que fornecem filtragem da Camada 7 ao refinar solicitações recebidas para ataques comuns da Web ou outros atributos da Camada 7, ajudando a bloquear o tráfego antes de alcançar os serviços de back-end com carga balanceada. A proteção contra ataques volumétricos de DDoS é ativada por padrão.

Quando um usuário solicita conteúdo do seu serviço, essa solicitação é enviada ao front-end global para aplicativos voltados à Internet, que é fornecido pela Rede entre nuvens. A solicitação é avaliada pelas políticas de segurança do Google Cloud Armor, começando pelas políticas de segurança de borda do Google Cloud Armor. Se a solicitação for permitida e puder ser atendida pelo Cloud CDN, o conteúdo será recuperado do cache do Google Cloud Armor e enviado de volta ao usuário. Se a solicitação resultar em uma ausência no cache, ela será avaliada pelas políticas de back-end e, de acordo com as regras da política, negada ou atendida pelo servidor de back-end.

Componentes de arquitetura

O diagrama anterior inclui os seguintes componentes:

  • Balanceador de carga de aplicativo externo global: é um balanceador de carga de Camada 7 baseado em proxy que permite executar e escalonar seus serviços. O balanceador de carga de aplicativo distribui o tráfego HTTP e HTTPS para back-ends hospedados em várias plataformas do Google Cloud. O balanceador de carga de aplicativo tem os seguintes recursos:

    • Back-end configurável: essa arquitetura usa dois grupos de instâncias gerenciados (MIGs) em regiões diferentes, mas é possível configurar qualquer back-end que o balanceador de carga de aplicativo externo global ofereça suporte. É possível usar o mesmo balanceador de carga para aplicativos do GKE, do Cloud Run, do Cloud Functions e do App Engine, além daqueles hospedados no local e em outras nuvens, usando uma configuração de back-end diferente. Para saber mais, consulte Visão geral do balanceador de carga de aplicativo.
    • Divisão de tráfego: use o balanceador de carga de aplicativo para gerenciar o tráfego, incluindo o gerenciamento de versões de software, enviando diferentes usuários para diferentes servidores de back-end. Na arquitetura descrita neste documento, há uma divisão de tráfego simples de 60/40. No entanto, é possível alterar essa divisão para criar esquemas de gerenciamento de tráfego mais complexos. Para saber mais sobre outras opções de configuração, consulte os tempos limite e novas tentativas configuráveis e determine seu modo de balanceamento preferido.
  • Cloud CDN: a plataforma Cloud CDN atua como cache. Ele é implantado com o servidor de origem para fornecer o pacote completo de recursos do Cloud CDN, incluindo QUIC e HTTP/2, bem como controles de roteamento e armazenamento em cache. Essa abordagem permite que seu aplicativo seja escalonado globalmente sem comprometer o desempenho e também reduz os custos de largura de banda e computação de front-end. A configuração padrão que o front-end global usa é baseada nas práticas recomendadas de entrega de conteúdo e de segurança da Web do Cloud CDN.

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

Produtos usados

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

Considerações sobre o design

Nesta seção, fornecemos orientações para ajudar você a usar este documento como ponto de partida para desenvolver uma arquitetura que atenda aos seus requisitos específicos de segurança, confiabilidade, eficiência operacional, custo e desempenho.

segurança, privacidade e conformidade

Nesta seção, descrevemos outros fatores que você precisa considerar ao usar essa arquitetura de referência para implantar o aplicativo da Web.

Estabelecer um valor de referência de segurança

Para melhorar ainda mais sua segurança, a arquitetura descrita neste documento também é compatível com o Blueprint de bases empresariais. O blueprint ajuda as organizações que usam o Google Cloud a estabelecer um valor de referência seguro para todas as cargas de trabalho futuras, incluindo a configuração do Identity and Access Management (IAM), do Cloud Key Management Service e do Security Command Center.

Proteja os dados dos usuários com o Cloud CDN

Nesta arquitetura, recomendamos que você não armazene em cache o conteúdo específico do usuário. Para armazenar tipos de conteúdo HTML (text/html) e JSON (application/json) em cache, defina cabeçalhos explícitos de controle de cache na resposta do Cloud CDN. Não armazene em cache os dados de um usuário e não os exiba para todos os usuários.

Controlar o acesso ao aplicativo com o IAP

A arquitetura também é compatível com o Identity-Aware Proxy (IAP). O IAP verifica a identidade de um usuário e determina se ele tem permissão para acessar um aplicativo. Para ativar o IAP no balanceador de carga de aplicativo para o modo externo global ou o modo clássico, ative-o nos serviços de back-end do balanceador de carga. As solicitações HTTP/HTTPS de entrada são avaliadas pelo Google Cloud Armor antes de serem enviadas para balanceamento de carga pelo balanceador de carga de aplicativo. Se o Google Cloud Armor bloquear uma solicitação, o IAP não avaliará a solicitação. Se o Google Cloud Armor permitir uma solicitação, o IAP avaliará essa solicitação. A solicitação será bloqueada se o IAP não autenticar a solicitação. Saiba mais em Como integrar o Google Cloud Armor a outros produtos do Google.

Otimização de custos

Como diretriz geral, usar o Cloud CDN com o Google Cloud Armor pode ajudar a minimizar o efeito das cobranças de transferência de dados.

Cloud CDN

Objetos estáticos exibidos ao cliente a partir do cache não transitam pelo balanceador de carga. Uma estratégia de armazenamento em cache eficaz pode reduzir a quantidade de dados de saída que estão sendo processados pelo balanceador de carga e reduzir os custos.

Google Cloud Armor

O Google Cloud Armor ajuda a reduzir custos, evitando que sua conta seja cobrada por tráfego indesejado. As solicitações bloqueadas pelo Google Cloud Armor não geram uma resposta do seu app, o que reduz efetivamente a quantidade de dados de saída processados pelo balanceador de carga. O efeito nos custos depende da porcentagem de tráfego indesejado bloqueado pelas políticas de segurança do Google Cloud Armor implementadas.

Os custos finais também podem variar, dependendo de quantos serviços ou aplicativos você quer proteger, do número de políticas e regras do Google Cloud Armor que você tem, do preenchimento e da saída de cache e do volume de dados. Para saber mais, consulte:

Deployment

Para implantar esta arquitetura de referência, use o exemplo do Terraform. Para saber mais, consulte o arquivo README. A pasta web_app_protection_example inclui o arquivo (main.tf). O código neste arquivo cria a arquitetura descrita neste documento e fornece suporte adicional para implantação automática.

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

Quando você confirma uma alteração em qualquer ramificação em que o pipeline se baseia, essas alterações acionam uma execução de pipeline e são integradas a uma nova versão assim que é concluída. Quando você extrair o kit de ferramentas pela primeira vez, a solução será carregada no projeto escolhido do Google Cloud.

A seguir

Saiba mais sobre as práticas recomendadas para os produtos do Google Cloud usados nesta arquitetura de referência:

Colaboradores

Autores:

Outros colaboradores: