Esta página foi traduzida pela API Cloud Translation.

Implemente uma arquitetura sem servidor segura através do Cloud Run

Last reviewed 2023-03-10 UTC

Este conteúdo foi atualizado pela última vez em março de 2023 e representa o status quo no momento em que foi escrito. As políticas e os sistemas de segurança da Google podem mudar no futuro, à medida que melhoramos continuamente a proteção dos nossos clientes.

As arquiteturas sem servidor permitem-lhe desenvolver software e serviços sem aprovisionar nem manter servidores. Pode usar arquiteturas sem servidor para criar aplicações para uma vasta gama de serviços.

Este documento fornece orientações fundamentadas para engenheiros de DevOps, arquitetos de segurança e programadores de aplicações sobre como ajudar a proteger aplicações sem servidor que usam o Cloud Run. O documento faz parte de um projeto de segurança que consiste no seguinte:

Um repositório do GitHub que contém um conjunto de configurações e scripts do Terraform.
Um guia para a arquitetura, a conceção e os controlos de segurança que implementa com o esquema (este documento).

Embora possa implementar este plano sem implementar primeiro o Google Cloud plano de bases empresariais, este documento pressupõe que já configurou um conjunto básico de controlos de segurança, conforme descrito no Google Cloud plano de bases empresariais. A arquitetura descrita neste documento ajuda a adicionar controlos adicionais à sua base para ajudar a proteger as aplicações sem servidor.

Para ajudar a definir os principais controlos de segurança relacionados com aplicações sem servidor, a Cloud Security Alliance (CSA) publicou os 12 principais riscos críticos para aplicações sem servidor. Os controlos de segurança usados neste plano foram concebidos para abordar os riscos relevantes para os vários exemplos de utilização descritos neste documento.

Exemplos de utilização sem servidor

O plano detalhado suporta os seguintes exemplos de utilização:

Implementar uma arquitetura sem servidor através do Cloud Run (este documento)
Implementar uma arquitetura sem servidor com funções do Cloud Run

As diferenças entre as funções do Cloud Run e o Cloud Run incluem o seguinte:

As funções do Cloud Run são acionadas por eventos, como alterações aos dados numa base de dados ou a receção de uma mensagem de um sistema de mensagens, como o Pub/Sub. O Cloud Run é acionado por pedidos, como pedidos HTTP.
As funções do Cloud Run estão limitadas a um conjunto de runtimes suportados. Pode usar o Cloud Run com qualquer linguagem de programação.
As funções do Cloud Run gerem contentores e a infraestrutura que controlam o servidor Web ou o tempo de execução da linguagem para que se possa focar no seu código. O Cloud Run oferece-lhe a flexibilidade de executar estes serviços para que tenha controlo da configuração do contentor.

Para mais informações sobre as diferenças entre o Cloud Run e as funções do Cloud Run, consulte o artigo Escolher uma opção de Google Cloud computação.

Arquitetura

Este projeto permite-lhe executar aplicações sem servidor no Cloud Run com a VPC partilhada. Recomendamos que use a VPC partilhada porque centraliza a política de rede e o controlo de todos os recursos de rede. Além disso, a VPC partilhada é implementada no projeto de base empresarial.

Arquitetura recomendada: Cloud Run com uma rede VPC partilhada

A imagem seguinte mostra como pode executar as suas aplicações sem servidor numa rede VPC partilhada.

A arquitetura do projeto sem servidor.

A arquitetura apresentada no diagrama anterior usa uma combinação dos seguintes Google Cloud serviços e funcionalidades:

Um Application Load Balancer externo recebe os dados de que as aplicações sem servidor precisam da Internet e encaminha-os para o Cloud Run. O balanceador de carga de aplicações externo é um balanceador de carga da camada 7.
O Google Cloud Armor funciona como a firewall de aplicação Web para ajudar a proteger as suas aplicações sem servidor contra negação de serviço (DoS) e ataques Web.
O Cloud Run permite-lhe executar código de aplicação em contentores e gere a infraestrutura em seu nome. Neste projeto, a definição de entrada de balanceamento de carga interno e na nuvem restringe o acesso ao Cloud Run para que o Cloud Run aceite pedidos apenas do balanceador de carga da aplicação externo.
O conetor do Acesso a VPC sem servidor liga a sua aplicação sem servidor à sua rede VPC através do Acesso a VPC sem servidor. O Acesso a VPC sem servidor ajuda a garantir que os pedidos da sua aplicação sem servidor à rede VPC não são expostos à Internet. O acesso a VPC sem servidor permite que o Cloud Run comunique com outros serviços, sistemas de armazenamento e recursos que suportam os VPC Service Controls.

Por predefinição, cria o conetor de acesso a VPC sem servidor no projeto de serviço. Pode criar o conetor do Acesso a VPC sem servidor no projeto anfitrião especificando true para a variável de entrada connector_on_host_project quando executar o módulo Rede do Cloud Run segura. Para mais informações, consulte o artigo Comparação de métodos de configuração.
As regras de firewall da nuvem privada virtual (VPC) controlam o fluxo de dados para a sub-rede que aloja os seus recursos, como um servidor da empresa alojado no Compute Engine ou dados da empresa armazenados no Cloud Storage.
Os VPC Service Controls criam um perímetro de segurança que isola os seus serviços e recursos do Cloud Run configurando a autorização, os controlos de acesso e a troca de dados segura. Este perímetro foi concebido para proteger o conteúdo recebido, isolar a sua aplicação configurando controlos de acesso e monitorização adicionais, e separar a sua governação do Google Cloud da aplicação. A sua governação inclui a gestão de chaves e o registo.
A VPC partilhada permite-lhe ligar o conetor do Acesso a VPC sem servidor no seu projeto de serviço ao projeto anfitrião.
O Cloud Key Management Service (Cloud KMS) armazena as chaves de encriptação geridas pelo cliente (CMEKs) usadas pelos serviços neste projeto, incluindo a sua aplicação sem servidor, o Artifact Registry e o Cloud Run.
A gestão de identidade e de acesso (IAM) e o Resource Manager ajudam a restringir o acesso e a isolar recursos. Os controlos de acesso e a hierarquia de recursos seguem o princípio do menor privilégio.

Arquitetura alternativa: Cloud Run sem uma rede VPC partilhada

Se não estiver a usar uma rede de VPC partilhada, pode implementar o Cloud Run e a sua aplicação sem servidor num perímetro de controlo de serviços de VPC sem uma rede de VPC partilhada. Pode implementar esta arquitetura alternativa se estiver a usar uma topologia de hub e raios.

A imagem seguinte mostra como pode executar as suas aplicações sem servidor sem VPC partilhada.

Uma arquitetura alternativa para o esquema sem servidor.

A arquitetura apresentada no diagrama anterior usa uma combinação de Google Cloud serviços e funcionalidades semelhantes aos descritos na secção anterior, Arquitetura recomendada: Cloud Run com uma VPC partilhada.

Estrutura da organização

Agrupa os seus recursos para os poder gerir e separar os ambientes de desenvolvimento e teste do ambiente de produção. O Resource Manager permite-lhe agrupar logicamente os recursos por projeto, pasta e organização.

O diagrama seguinte mostra uma hierarquia de recursos com pastas que representam diferentes ambientes, como bootstrap, common, production, non-production (ou testes) e desenvolvimento. Esta hierarquia de recursos baseia-se na hierarquia descrita no projeto de bases empresariais. Implementa os projetos especificados no esquema nas seguintes pastas: Common, Production, Non-production e Dev.

A estrutura da organização para o projeto sem servidor.

As secções seguintes descrevem este diagrama mais detalhadamente.

Pastas

Usa pastas para isolar o ambiente de produção e os serviços de administração dos ambientes de não produção e de testes. A tabela seguinte descreve as pastas do esquema de bases empresariais que são usadas por este esquema.

Pasta	Descrição
`Bootstrap`	Contém os recursos necessários para implementar o projeto das bases empresariais.
`Common`	Contém serviços centralizados para a organização, como o projeto de segurança.
`Production`	Contém projetos que têm recursos na nuvem que foram testados e estão prontos a ser usados pelos clientes. Neste esquema, a pasta `Production` contém o projeto de serviço e o projeto de anfitrião.
`Non-production`	Contém projetos com recursos na nuvem que estão atualmente a ser testados e preparados para lançamento. Neste esquema, a pasta `Non-production` contém o projeto de serviço e o projeto de anfitrião.
`Dev`	Contém projetos com recursos na nuvem que estão atualmente em desenvolvimento. Neste esquema, a pasta `Dev` contém o projeto de serviço e o projeto anfitrião.

Pode alterar os nomes destas pastas para se alinharem com a estrutura de pastas da sua organização, mas recomendamos que mantenha uma estrutura semelhante. Para mais informações, consulte o artigo Estrutura da organização. Para outras estruturas de pastas, consulte o artigo Decida uma hierarquia de recursos para a sua Google Cloud zona de destino.

Projetos

Isola os recursos no seu ambiente através de projetos. A tabela seguinte descreve os projetos necessários na organização. Pode alterar os nomes destes projetos, mas recomendamos que mantenha uma estrutura de projeto semelhante.

Projeto	Descrição
Projeto anfitrião	Este projeto inclui as regras de entrada da firewall e todos os recursos que tenham endereços IP internos (conforme descrito em Estabeleça ligação a uma rede VPC). Quando usa a VPC partilhada, designa um projeto como projeto anfitrião e anexa-lhe um ou mais projetos de serviço. Quando aplica o código do Terraform, especifica o nome deste projeto e o plano implanta os serviços.
Projeto de serviço	Este projeto inclui a sua aplicação sem servidor, o Cloud Run e o conetor do Acesso a VPC sem servidor. Associa o projeto de serviço ao projeto anfitrião para que o projeto de serviço possa participar na rede VPC partilhada. Quando aplica o código do Terraform, especifica o nome deste projeto. O projeto implementa o Cloud Run, o Cloud Armor, o conetor de acesso a VPC sem servidor e o equilibrador de carga.
Projeto de segurança	Este projeto inclui os seus serviços específicos de segurança, como o Cloud KMS e o Secret Manager. Quando aplica o código Terraform, especifica o nome deste projeto e o esquema implementa o Cloud KMS. Se usar o módulo Secure Cloud Run Harness, o Artifact Registry também é implementado. Se implementar este blueprint depois de implementar o blueprint de bases de segurança, este projeto é o projeto de segredos criado pelo blueprint de bases empresariais. Para mais informações sobre os projetos de base empresarial, consulte Projetos. Se implementar várias instâncias deste projeto sem o projeto de base empresarial, cada instância tem o seu próprio projeto de segurança.

Mapeamento de funções e grupos para projetos

Tem de conceder a diferentes grupos de utilizadores na sua organização acesso aos projetos que compõem a arquitetura sem servidor. A tabela seguinte descreve as recomendações de plano para grupos de utilizadores e atribuições de funções nos projetos que criar. Pode personalizar os grupos para corresponderem à estrutura existente da sua organização, mas recomendamos que mantenha uma segregação de funções e atribuição de funções semelhante.

Grupo	Projeto	Funções
Administrador sem servidor grp-gcp-serverless-admin@example.com	Projeto de serviço	`roles/run.admin` `roles/compute.networkViewer` `compute.networkUser`
Administrador de segurança sem servidor grp-gcp-serverless-security-admin@example.com	Projeto de segurança	`roles/run.viewer` `roles/cloudkms.viewer` `roles/artifactregistry.reader`
Programador do Cloud Run grp-gcp-secure-cloud-run-developer@example.com	Projeto de segurança	`roles/run.developer` `roles/artifactregistry.writer` `roles/cloudkms.cryptoKeyEncrypter`
Utilizador do Cloud Run grp-gcp-secure-cloud-run-user@example.com	Projeto de serviço	`roles/run.invoker`

Controlos de segurança

Esta secção aborda os controlos de segurança no Google Cloud que usa para ajudar a proteger a sua arquitetura sem servidor. Os principais princípios de segurança a ter em consideração são os seguintes:

Acesso seguro de acordo com o princípio do menor privilégio, concedendo às entidades apenas os privilégios necessários para realizar as respetivas tarefas.
Ligações de rede seguras através da conceção de segmentação, das políticas da organização e das políticas de firewall.
Configuração segura para cada um dos serviços.
Compreenda os níveis de risco e os requisitos de segurança para o ambiente que aloja as suas cargas de trabalho sem servidor.
Configure uma monitorização e um registo suficientes para permitir a deteção, a investigação e a resposta.

Controlos de segurança para aplicações sem servidor

Pode ajudar a proteger as suas aplicações sem servidor através de controlos que protegem o tráfego na rede, controlam o acesso e encriptam os dados.

Controlos do sistema de compilação

Quando implementa a sua aplicação sem servidor, usa o Artifact Registry para armazenar as imagens de contentores e os ficheiros binários. O Artifact Registry suporta CMEK para que possa encriptar o repositório com as suas próprias chaves de encriptação.

Tráfego SSL

Para suportar o tráfego HTTPS para a sua aplicação sem servidor, configure um certificado SSL para o balanceador de carga de aplicações externo. Por predefinição, usa um certificado autoassinado que pode alterar para um certificado gerido depois de aplicar o código do Terraform. Para mais informações sobre a instalação e a utilização de certificados geridos, consulte o artigo Usar certificados SSL geridos pela Google.

Regras de rede e de firewall

As regras de firewall da nuvem virtual privada (VPC) controlam o fluxo de dados para os perímetros. Cria regras de firewall que negam todas as saídas, exceto para ligações específicas da porta TCP 443 de nomes de domínio especiais restricted.googleapis.com. A utilização do domínio restricted.googleapis.com tem as seguintes vantagens:

Ajuda a reduzir a superfície de ataque da sua rede através do acesso privado à Google quando as cargas de trabalho comunicam com as APIs Google e os serviços Google.
Garante que usa apenas serviços que suportam os VPC Service Controls.

Para mais informações, consulte o artigo Configurar o acesso privado à Google.

Controlos de perímetro

Conforme mostrado no diagrama de arquitetura recomendado, coloca os recursos para a aplicação sem servidor num perímetro separado. Este perímetro ajuda a proteger a aplicação sem servidor contra o acesso não intencional e a exfiltração de dados.

Política de acesso

Para ajudar a garantir que apenas identidades específicas (utilizadores ou serviços) podem aceder a recursos e dados, ative as funções e os grupos da IAM.

Para ajudar a garantir que apenas recursos específicos podem aceder aos seus projetos, ative uma política de acesso para a sua organização Google. Para mais informações, consulte Atributos do nível de acesso.

Identity and Access Proxy

Se o seu ambiente já incluir o Identity and Access Proxy (IAP), pode configurar o Application Load Balancer externo para usar o IAP para autorizar o tráfego para a sua aplicação sem servidor. O IAP permite-lhe estabelecer uma camada de autorização central para a sua aplicação sem servidor, para que possa usar controlos de acesso ao nível da aplicação em vez de depender de firewalls ao nível da rede.

Para ativar as CAs para a sua aplicação, no ficheiro loadbalancer.tf, defina iap_config.enable como true.

Para mais informações sobre a IAP, consulte a vista geral do Identity-Aware Proxy.

Contas de serviço e controlos de acesso

As contas de serviço são identidades que Google Cloud pode usar para executar pedidos de API em seu nome. Para implementar a separação de funções, crie contas de serviço com funções diferentes para fins específicos. As contas de serviço são as seguintes:

Uma conta de serviço do Cloud Run (cloud_run_sa) que tem as seguintes funções:
- roles/run.invoker
- roles/secretmanager.secretAccessor
Para mais informações, consulte o artigo Permita que o Cloud Run aceda a um segredo.
Uma conta de conetor do Acesso a VPC sem servidor (gcp_sa_vpcaccess) que tem a função roles/compute.networkUser.
Uma segunda conta de conetor do Acesso a VPC sem servidor (cloud_services) que tenha a função roles/compute.networkUser.

Estas contas de serviço para o conetor do Acesso a VPC sem servidor são necessárias para que o conetor possa criar as regras de entrada e saída da firewall no projeto anfitrião. Para mais informações, consulte o artigo Conceda autorizações a contas de serviço nos seus projetos de serviço.
Uma identidade de serviço para executar o Cloud Run (run_identity_services) que tenha a função roles/vpcaccess.user.
Um agente de serviço para as APIs Google (cloud_services_sa) que tem a função roles/editor. Esta conta de serviço permite que o Cloud Run comunique com o conetor de acesso a VPC sem servidor.
Uma identidade de serviço para o Cloud Run (serverless_sa) que tem a função roles/artifactregistry.reader. Esta conta de serviço fornece acesso ao Artifact Registry e às chaves de encriptação e desencriptação da CMEK.

Gestão de chaves

Utiliza as chaves CMEK para ajudar a proteger os seus dados no Artifact Registry e no Cloud Run. Usa as seguintes chaves de encriptação:

Uma chave de software para o Artifact Registry que atesta o código da sua aplicação sem servidor.
Uma chave de encriptação para encriptar as imagens de contentores que o Cloud Run implementa.

Quando aplica a configuração do Terraform, especifica a localização da CMEK, que determina a localização geográfica onde as chaves são armazenadas. Tem de garantir que as suas chaves CMEK estão na mesma região que os seus recursos. Por predefinição, as chaves CMEK são rodadas a cada 30 dias.

Gestão de segredos

O Cloud Run suporta o Secret Manager para armazenar os segredos que a sua aplicação sem servidor pode exigir. Estes segredos podem incluir chaves de API e nomes de utilizadores e palavras-passe de bases de dados. Para expor o segredo como um volume montado, use as variáveis volume_mounts e volumes no módulo principal.

Quando implementa este esquema com o esquema de bases empresariais, tem de adicionar os seus segredos ao projeto de segredos antes de aplicar o código do Terraform. O projeto vai conceder a função Secret Accessor do Secret Manager à conta de serviço do Cloud Run. Para mais informações, consulte o artigo Use segredos.

Políticas da organização

Este projeto adiciona restrições às restrições da política da organização. Para mais informações acerca das restrições usadas no esquema detalhado das bases empresariais, consulte as restrições da política da organização.

A tabela seguinte descreve as restrições adicionais da política da organização que estão definidas no módulo Segurança do Cloud Run seguro deste projeto.

Restrição de política	Descrição	Valor recomendado
`constraints/run.allowedIngress`	Permita o tráfego de entrada apenas de serviços internos ou do Application Load Balancer externo.	`internal-and-cloud-load-balancing`
`constraints/run.allowedVPCEgress`	Exija que as revisões de um serviço do Cloud Run usem um conector de acesso à VPC sem servidor e certifique-se de que as definições de saída da VPC das revisões estão definidas para permitir apenas intervalos privados.	`private-ranges-only`

Controlos operacionais

Pode ativar o registo e as funcionalidades do nível premium do Security Command Center, como as estatísticas de estado de segurança e a deteção de ameaças. Estes controlos ajudam a fazer o seguinte:

Monitorizar quem está a aceder aos seus dados.
Certifique-se de que a auditoria adequada está implementada.
Apoiar a capacidade das suas equipas de gestão de incidentes e operações de responder a problemas que possam ocorrer.

Registo

Para ajudar a cumprir os requisitos de auditoria e obter estatísticas sobre os seus projetos, pode configurar o Google Cloud Observability com registos de dados para os serviços que quer acompanhar. Implemente o Cloud Logging nos projetos antes de aplicar o código Terraform para garantir que o esquema pode configurar o registo para a firewall, o equilibrador de carga e a rede VPC.

Depois de implementar o esquema, recomendamos que configure o seguinte:

Crie um sink de registo agregado em todos os projetos.
Selecione a região adequada para armazenar os seus registos.
Adicione chaves CMEK ao seu destino de registo.

Para todos os serviços nos projetos, certifique-se de que os registos incluem informações sobre leituras e escritas de dados, e certifique-se de que incluem informações sobre o que os administradores acedem. Para mais informações sobre as práticas recomendadas de registo, consulte o artigo Controlos de deteção.

Monitorização e alertas

Depois de implementar o esquema, pode configurar alertas para notificar o seu centro de operações de segurança (SOC) de que pode estar a ocorrer um incidente de segurança. Por exemplo, pode usar alertas para informar os seus analistas de segurança quando uma autorização tiver sido alterada numa função do IAM. Para mais informações sobre a configuração de alertas do Security Command Center, consulte o artigo Configurar notificações de resultados.

O painel de controlo de monitorização do Cloud Run, que faz parte da biblioteca de painéis de controlo de exemplo, fornece-lhe as seguintes informações:

Contagem de pedidos
Latência do pedido
Tempo de instância faturável
Atribuição de CPU do contentor
Atribuição de memória do contentor
Utilização da CPU do contentor
Utilização da memória do contentor

Para ver instruções sobre como importar o painel de controlo, consulte o artigo Instale painéis de controlo de amostra. Para exportar alertas, consulte os seguintes documentos:

Depuração e resolução de problemas

Pode executar Connectivity Tests para ajudar a depurar problemas de configuração de rede entre o Cloud Run e os recursos na sua sub-rede. Os testes de conetividade simulam o caminho esperado de um pacote e fornecem detalhes sobre a conetividade, incluindo a análise de conetividade de recurso para recurso.

Os testes de conetividade não estão ativados pelo código Terraform. Tem de os configurar separadamente. Para mais informações, consulte o artigo Crie e execute testes de conetividade.

Controlos de deteção

Esta secção descreve os controlos de deteção incluídos no projeto.

Cloud Armor e WAF

Usa um Application Load Balancer e o Cloud Armor externos para fornecer proteção contra negação de serviço distribuída (DDoS) para a sua aplicação sem servidor. O Cloud Armor é a firewall de aplicação Web (WAF) incluída no Google Cloud.

Configura as regras do Cloud Armor descritas na tabela seguinte para ajudar a proteger a aplicação sem servidor. As regras foram concebidas para ajudar a mitigar os riscos das 10 principais ameaças da OWASP.

Nome da regra do Cloud Armor	Nome da regra do ModSecurity
Execução remota de código	`rce-v33-stable`
Inclusão de ficheiro local	`lfi-v33-stable`
Ataque de protocolo	`protocolattack-v33-stable`
Inclusão de ficheiros remotos	`rfi-v33-stable`
Deteção de scanner	`scannerdetection-v33-stable`
Ataque de fixação de sessão	`sessionfixation-v33-stable`
Injeção SQL	`sqli-v33-stable`
Cross-site scripting	`xss-v33-stable`

Quando estas regras estão ativadas, o Cloud Armor nega automaticamente qualquer tráfego que corresponda à regra.

Para mais informações sobre estas regras, consulte o artigo Ajuste as regras de WAF pré-configuradas do Google Cloud Armor.

Deteção de problemas de segurança no Cloud Run

Pode detetar potenciais problemas de segurança no Cloud Run através do Recommender. O Recommender pode detetar problemas de segurança, como os seguintes:

Chaves da API ou palavras-passe armazenadas em variáveis de ambiente, em vez de no Secret Manager.
Recipientes que incluem credenciais codificadas em vez de usar identidades de serviço.

Cerca de um dia após a implementação do Cloud Run, o Recomendador começa a fornecer as respetivas conclusões e recomendações. O Recommender apresenta as respetivas conclusões e ações corretivas recomendadas na lista de serviços do Cloud Run ou no Centro de Recomendações.

Modos de implementação do Terraform

A tabela seguinte descreve as formas como pode implementar este projeto, e que módulos do Terraform se aplicam a cada modo de implementação.

Modo de implementação Módulos do Terraform

Modo de implementação	Módulos do Terraform
Implemente este projeto após implementar o projeto de bases empresariais (recomendado). Esta opção implementa os recursos para este projeto no mesmo perímetro do VPC Service Controls que é usado pelo projeto de bases empresariais. Para mais informações, consulte o artigo Como personalizar a Foundation v2.3.1 para a implementação sem servidor segura. Esta opção também usa o projeto de segredos que criou quando implementou o esquema detalhado das bases empresariais.	Use estes módulos do Terraform: `secure-cloud-run-core` `secure-serverless-net` `secure-cloud-run-security` `secure-cloud-run`
Instale este projeto sem instalar o projeto enterprise foundations. Esta opção requer que crie um perímetro dos VPC Service Controls.	Use estes módulos do Terraform: `secure-cloud-run-core` `secure-serverless-harness` `secure-serverless-net` `secure-cloud-run-security` `secure-cloud-run`

Implemente este projeto após implementar o projeto de bases empresariais (recomendado).

Esta opção implementa os recursos para este projeto no mesmo perímetro do VPC Service Controls que é usado pelo projeto de bases empresariais. Para mais informações, consulte o artigo Como personalizar a Foundation v2.3.1 para a implementação sem servidor segura.

Esta opção também usa o projeto de segredos que criou quando implementou o esquema detalhado das bases empresariais.

Use estes módulos do Terraform:

Instale este projeto sem instalar o projeto enterprise foundations.

Esta opção requer que crie um perímetro dos VPC Service Controls.