Implantar uma arquitetura sem servidor segura usando as funções do Cloud Run

Last reviewed 2023-08-06 UTC

Arquiteturas sem servidor permitem desenvolver software e serviços sem provisionar ou manter servidores. É possível usar arquiteturas sem servidor para criar aplicativos para uma ampla variedade de serviços.

Neste documento, fornecemos orientação opinativa para engenheiros de DevOps, arquitetos de segurança e desenvolvedores de aplicativos sobre como ajudar a proteger aplicativos sem servidor que usam as funções do Cloud Run (2ª geração). O documento faz parte de um blueprint 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 os controles de arquitetura, design e segurança que você implementa com o blueprint (este documento).

Embora você possa implantar esse blueprint sem implantar o blueprint de segurança empresarial do Google Cloud primeiro, esse documento pressupõe que você já tenha configurado um conjunto básico de controles de segurança, conforme descrito no blueprint de bases empresariais do Google Cloud. A arquitetura descrita neste documento ajuda a sobrepor controles adicionais na sua base para proteger os aplicativos sem servidor.

Para ajudar a definir os principais controles de segurança relacionados a aplicativos sem servidor, a Cloud Security Alliance (CSA) publicou os 12 principais riscos críticos de aplicativos sem servidor Os controles de segurança usados nesse blueprint foram projetados para lidar com os riscos relevantes para os vários casos de uso descritos neste documento.

Casos de uso sem servidor

O blueprint é compatível com os seguintes casos de uso:

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 em dados em um banco de dados ou o recebimento de uma mensagem de um sistema de mensagens, como o Pub/Sub. O Cloud Run é acionado por solicitações, como solicitações HTTP.
  • As funções do Cloud Run são limitadas a um conjunto de ambientes de execução compatíveis. É possível usar o Cloud Run com qualquer linguagem de programação.
  • As funções do Cloud Run gerenciam contêineres e a infraestrutura que controla o servidor da Web ou o ambiente de execução da linguagem para que você possa se concentrar no código. O Cloud Run oferece a flexibilidade de executar esses serviços por conta própria, para que você tenha controle da configuração do contêiner.

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

Arquitetura

Esse blueprint usa uma arquitetura de VPC compartilhada, em que as funções do Cloud Run é implantado em um projeto de serviço e pode acessar recursos localizados em outras redes VPC.

O diagrama a seguir mostra uma arquitetura de alto nível, que é descrita em mais detalhes nos exemplos de arquitetura a seguir.

A arquitetura do blueprint sem servidor usando as funções do Cloud Run.

A arquitetura exibida no diagrama anterior usa uma combinação dos seguintes serviços e recursos do Google Cloud:

  • As funções do Cloud Run permitem que você execute funções como um serviço e gerencie a infraestrutura em seu nome. Por padrão, essa arquitetura implanta as funções do Cloud Run apenas com um endereço IP interno e sem acesso à Internet pública.
  • O evento acionador é o evento que aciona as funções do Cloud Run. Conforme descrito em mais detalhes nas arquiteturas de exemplo, isso pode ser um evento do Cloud Storage, um intervalo programado ou uma alteração no BigQuery.
  • O Artifact Registry armazena os contêineres de origem para seu aplicativo das funções do Cloud Run.
  • A VPC compartilhada permite conectar o conector de acesso VPC sem servidor no projeto de serviço ao projeto host. Você implanta uma rede VPC compartilhada separada para cada ambiente (produção, não produção e desenvolvimento). Esse design de rede fornece isolamento de rede entre os diferentes ambientes. Uma rede VPC compartilhada permite gerenciar centralmente os recursos de rede em uma rede comum enquanto delega responsabilidades administrativas para o projeto de serviço.
  • O conector de acesso VPC sem servidor conecta seu aplicativo sem servidor à sua rede VPC usando o acesso VPC sem servidor. O acesso VPC sem servidor ajuda a garantir que as solicitações do aplicativo sem servidor para a rede VPC não sejam expostas à Internet. O acesso VPC sem servidor permite que as funções do Cloud Run se comunique com outros serviços, sistemas de armazenamento e recursos que são compatíveis com o VPC Service Controls.

    É possível configurar o acesso VPC sem servidor no projeto host da VPC compartilhada ou em um projeto de serviço. Por padrão, esse blueprint implanta o acesso VPC sem servidor no projeto host da VPC compartilhada para se alinhar ao modelo de VPC compartilhada da centralização de recursos de configuração de rede. Para mais informações, consulte Comparação de métodos de configuração.

  • O VPC Service Controls cria um perímetro de segurança que isola os serviços e recursos das funções do Cloud Run configurando a autorização, os controles de acesso e a troca de dados segura. Esse perímetro foi projetado para isolar o aplicativo e os serviços gerenciados configurando controles de acesso e monitoramento adicionais e para separar a governança do Google Cloud do aplicativo. Sua governança inclui o gerenciamento de chaves e a geração de registros.

  • O serviço ao consumidor é o aplicativo em que as funções do Cloud Run atuam. O serviço para consumidores pode ser um servidor interno ou outro serviço do Google Cloud, como o Cloud SQL. Dependendo do seu caso de uso, esse serviço pode estar protegido pelo Cloud Firewall de última geração, em outra sub-rede, no mesmo projeto de serviço das funções do Cloud Run ou em outro projeto de serviço.

  • O proxy da Web seguro é projetado para proteger o tráfego de saída da Web, se necessário. Ele permite políticas flexíveis e granulares com base em identidades da nuvem e aplicativos da Web. Esse blueprint usa o proxy da Web seguro para políticas de acesso granular para sair do tráfego da Web durante a fase de criação das funções do Cloud Run. O blueprint adiciona uma lista de URLs permitidos à regra de política de segurança do gateway.

  • O Cloud NAT fornece conexão de saída com a Internet, se necessário. O Cloud NAT é compatível com a conversão de endereços de rede de origem (SNAT, na sigla em inglês) para recursos de computação sem endereços IP públicos. Os pacotes de resposta de entrada usam a conversão de endereços de rede de destino (DNAT, na sigla em inglês). É possível desativar o Cloud NAT se as funções do Cloud Run não exigirem acesso à Internet. O Cloud NAT implementa a política de rede de saída anexada ao Secure Web Proxy.

  • O Cloud Key Management Service (Cloud KMS) armazena as chaves de criptografia gerenciadas pelo cliente (CMEKs) que são usadas pelos serviços neste blueprint, incluindo seu aplicativo sem servidor, o Artifact Registry e as funções do Cloud Run.

  • O Secret Manager armazena os secrets das funções do Cloud Run. O blueprint monta secrets como um volume para fornecer um nível mais alto de segurança do que a transmissão de chaves secretas como variáveis de ambiente.

  • O Identity and Access Management (IAM) e o Resource Manager ajudam a restringir o acesso e isolar recursos. A hierarquia de recursos e controles de acesso segue o princípio do menor privilégio.

  • O Cloud Logging coleta todos os registros dos serviços do Google Cloud para armazenamento e recuperação pelas ferramentas de análise e investigação.

  • O Cloud Monitoring coleta e armazena informações de desempenho e métricas sobre os serviços do Google Cloud.

Exemplo de arquitetura com um aplicativo sem servidor usando o Cloud Storage

O diagrama a seguir mostra como executar um aplicativo sem servidor que acessa um servidor interno quando ocorre um evento específico no Cloud Storage.

Exemplo de arquitetura sem servidor com o Cloud Storage.

Além dos serviços descritos em Arquitetura, esta arquitetura de exemplo usa uma combinação dos seguintes serviços e recursos do Google Cloud:

  • O Cloud Storage emite um evento quando qualquer recurso, aplicativo ou usuário da nuvem cria um objeto da Web em um bucket.
  • O Eventarc encaminha eventos de diferentes recursos. O Eventarc criptografa eventos em trânsito e em repouso.
  • O Pub/Sub enfileira eventos que são usados como entrada e um acionador das funções do Cloud Run.
  • As regras de firewall da nuvem privada virtual (VPC) controlam o fluxo de dados na sub-rede que hospeda seus recursos, como um servidor interno.
  • O servidor interno é executado no Compute Engine ou no Google Kubernetes Engine e hospeda o aplicativo interno. Se você implantar as funções do Cloud Run seguras com exemplo de servidor interno, também implantará um servidor Apache com uma página HTML Hello World. Este exemplo simula o acesso a um aplicativo interno que executa VMs ou contêineres.

Exemplo de arquitetura com o Cloud SQL

O diagrama a seguir mostra como executar um aplicativo sem servidor que acessa um serviço hospedado do Cloud SQL em um intervalo regular definido no Cloud Scheduler. Use essa arquitetura quando precisar coletar registros, dados agregados e assim por diante.

Exemplo de arquitetura sem servidor com o Cloud SQL.

Além dos serviços descritos em Arquitetura, esta arquitetura de exemplo usa uma combinação dos seguintes serviços e recursos do Google Cloud:

Exemplo de arquitetura com armazenamento de dados do BigQuery

O diagrama a seguir mostra como executar um aplicativo sem servidor que é acionado quando ocorre um evento no BigQuery (por exemplo, dados são adicionados ou uma tabela é criada).

Exemplo de arquitetura sem servidor com o BigQuery.

Além dos serviços descritos em Arquitetura, esta arquitetura de exemplo usa uma combinação dos seguintes serviços e recursos do Google Cloud:

Estrutura da organização

O Resource Manager permite agrupar logicamente recursos por projeto, pasta e organização.

Veja no diagrama a seguir uma hierarquia de recursos com pastas que representam diferentes ambientes, como bootstrap, comum, produção, não produção (ou teste) e desenvolvimento. Essa hierarquia de recursos é baseada na hierarquia descrita no Blueprint de bases empresariais. Implante os projetos que o blueprint especifica nas seguintes pastas: Common, Production, Non-production e Dev.

A estrutura organizacional do blueprint sem servidor.

As seções a seguir descrevem esse diagrama com mais detalhes.

Pastas

Use pastas para isolar o ambiente de produção e os serviços de governança dos ambientes de não produção e teste. A tabela a seguir descreve as pastas do blueprint de bases empresariais que são usadas por esse blueprint.

Pasta Descrição
Bootstrap Contém os recursos necessários para implantar o blueprint de bases empresariais.
Common Contêm serviços centralizados para a organização, como o projeto de governança.
Production Contém projetos com recursos de nuvem que foram testados e estão prontos para serem usados pelos clientes. Nesse blueprint, a pasta Production contém o projeto de serviço e o projeto host.
Non-production Contém projetos com recursos de nuvem em teste e preparo para lançamento. Nesse blueprint, a pasta Non-production contém o projeto de serviço e o projeto host.
Development Contém projetos que têm recursos de nuvem que estão sendo desenvolvidos no momento. Nesse blueprint, a pasta Development contém o projeto de serviço e o projeto host.

Altere os nomes dessas pastas para alinhá-las à estrutura de pastas da sua organização, mas recomendamos manter uma estrutura semelhante. Para mais informações, consulte Estrutura da organização. Para outras estruturas de pasta, consulte Decidir uma hierarquia de recursos para sua zona de destino do Google Cloud.

Projetos

Isole os recursos no ambiente usando projetos. A tabela a seguir descreve os projetos necessários na organização. É possível alterar os nomes desses projetos, mas recomendamos que você mantenha uma estrutura de projeto semelhante.

Projeto Descrição
Projeto de host de VPC compartilhada

Esse projeto inclui as regras de entrada de firewall e todos os recursos que têm endereços IP internos (conforme descrito em Conectar a uma rede VPC). Quando você usa a VPC compartilhada, precisa designar um projeto como host e anexar um ou mais projetos de serviço a ele.

Ao aplicar o código do Terraform, você especifica o nome desse projeto, e o blueprint implanta o conector de acesso VPC sem servidor, o Cloud NAT e o proxy da Web seguro do Cloud.

Projeto de serviço de VPC compartilhada

Esse projeto inclui o aplicativo sem servidor, as funções do Cloud Run e o conector de acesso VPC sem servidor. Você anexa o projeto de serviço ao projeto host para que ele possa participar da rede VPC compartilhada.

Ao aplicar o código do Terraform, você especifica o nome desse projeto. O blueprint implanta as funções do Cloud Run e os serviços necessários para seu caso de uso, como Cloud SQL, Cloud Scheduler, Cloud Storage ou BigQuery.

Ao aplicar o código do Terraform, você especifica o nome desse projeto e o blueprint implanta o Cloud KMS. Se você usar o módulo Secure Serverless Harness no blueprint sem servidor das funções do Cloud Run, o Artifact Registry também será implantado.

Projeto de segurança

Esse projeto inclui serviços específicos de segurança, como o Cloud KMS e o Secret Manager.

O nome padrão do projeto de segurança é prj-bu1-p-sec. Se você implantar esse blueprint depois de implantar o blueprint de bases de segurança, o projeto de segurança será criado junto com o projeto de secrets do blueprint da base corporativa (prj-bu1-p-env-secrets). Para mais informações sobre os projetos de blueprints de bases empresariais, consulte Projetos.

Se você implantar várias instâncias desse blueprint sem o blueprint de bases empresariais, cada instância terá o próprio projeto de segurança.

Como mapear papéis e grupos para projetos

É preciso conceder a grupos de usuários diferentes da organização acesso aos projetos que compõem a arquitetura sem servidor. A tabela a seguir descreve as recomendações de blueprint para grupos de usuários e atribuições de papéis nos projetos que você criar. É possível personalizar os grupos para que correspondam à estrutura da sua organização. No entanto, recomendamos que você mantenha uma segregação semelhante das tarefas e da atribuição de funções.

Grupo Projeto Papéis
Administrador sem servidor
grp-gcp-serverless-admin@example.com
Projeto de serviço
Administrador de segurança sem servidor
grp-gcp-serverless-security-admin@example.com
Projeto de segurança
Desenvolvedor das funções Cloud Run
grp-gcp-secure-cloud-run-developer@example.com
Projeto de segurança
Usuário das funções do Cloud Run
grp-gcp-secure-cloud-run-user@example.com
Projeto de serviço de VPC compartilhada

Controles de segurança

Nesta seção, falamos sobre os controles de segurança usados no Google Cloud para proteger sua arquitetura sem servidor. Os princípios básicos de segurança a serem considerados são os seguintes:

  • Proteja o acesso de acordo com o princípio do menor privilégio, concedendo aos somente os privilégios necessários para executar tarefas.
  • Conexões de rede seguras por meio do design do limite de confiança, que inclui segmentação de rede, políticas da organização e políticas de firewall.
  • Proteja a configuração de cada um dos serviços.
  • Identifique todos os requisitos regulatórios ou de conformidade da infraestrutura que hospeda cargas de trabalho sem servidor e atribua um nível de risco.
  • Configure o monitoramento e a geração de registros suficientes para oferecer suporte a trilhas de auditoria para operações de segurança e gerenciamento de incidentes.

Controle do sistema de build

Ao implantar o aplicativo sem servidor, você usa o Artifact Registry para armazenar as imagens e os binários do contêiner. O Artifact Registry oferece suporte a CMEK para você criptografar o repositório usando suas próprias chaves de criptografia.

Regras de rede e firewall

Regras de firewall da nuvem privada virtual (VPC) controlam o fluxo de dados nos perímetros. Você cria regras de firewall que negam todas as saídas, exceto para conexões de porta TCP 443 específicas dos nomes de domínio especiais restricted.googleapis.com. Usar o domínio restricted.googleapis.com tem os seguintes benefícios:

  • Ele reduz a superfície de ataque à rede usando o Acesso privado do Google quando as cargas de trabalho se comunicam com os serviços e as APIs.
  • Ele garante que você use apenas serviços compatíveis com o VPC Service Controls.

Além disso, você cria um registro DNS para resolver *.googleapis.com to restricted.googleapis.com.

Para mais informações, consulte Como configurar o acesso particular do Google.

Controles de perímetro

Conforme mostrado na seção Arquitetura, você coloca os recursos do aplicativo sem servidor em um perímetro de segurança separado do VPC Service Controls. Esse perímetro ajuda a reduzir o impacto geral de um comprometimento de sistemas ou serviços. No entanto, esse perímetro de segurança não se aplica ao processo de criação das funções do Cloud Run quando o Cloud Build cria automaticamente o código em uma imagem de contêiner e a envia para Artifact Registry. Nesse cenário, crie uma regra de entrada para a conta de serviço do Cloud Build no perímetro de serviço.

Política de acesso

Para garantir que apenas identidades específicas (usuários ou serviços) possam acessar recursos e dados, ative os grupos e os papéis do IAM.

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

Contas de serviço e controles de acesso

As contas de serviço são contas para aplicativos ou cargas de trabalho de computação, e não para usuários finais individuais. Para implementar o princípio do menor privilégio e o princípio da separação de deveres, você cria contas de serviço com permissões granulares e acesso limitado aos recursos. As contas de serviço são as seguintes:

Gerenciamento de chaves

Para validar a integridade e ajudar a proteger os dados em repouso, use as CMEKs com o Artifact Registry, as funções do Cloud Run, Cloud Storage e Eventarc. As CMEKs oferecem maior controle sobre sua chave de criptografia. As seguintes CMEKs são usadas:

  • Uma chave de software para o Artifact Registry que atesta o código do seu aplicativo sem servidor.
  • Uma chave de criptografia para criptografar as imagens de contêiner implantadas pelas funções do Cloud Run.
  • Uma chave de criptografia para eventos do Eventarc que criptografa o canal de mensagens em repouso.
  • Uma chave de criptografia para ajudar a proteger os dados no Cloud Storage.

Ao aplicar a configuração do Terraform, você especifica o local CMEK, que determina a localização geográfica em que as chaves são armazenadas. Verifique se as CMEKs estão na mesma região que seus recursos. Por padrão, as CMEKs são rotacionadas a cada 30 dias.

Gerenciamento de secrets

As funções do Cloud Run suportam o Secret Manager para armazenar os secrets que o aplicativo sem servidor pode exigir. Esses secrets podem incluir chaves de API e nomes de usuário e senhas de bancos de dados. Para expor o secret como um volume montado, use as variáveis service_configs e no módulo principal.

Ao implantar esse blueprint com o blueprint de bases empresariais, é necessário adicionar secrets ao projeto antes de aplicar o código do Terraform. O plano concederá o papel Assessor de secret do Secret Manager (roles/secretmanager.secretAccessor) à conta de serviço das funções do Cloud Run. Para mais informações, consulte Como usar secrets.

Políticas da organização

Esse blueprint adiciona restrições às restrições da política da organização usadas pelo blueprint de bases empresariais. Para mais informações sobre as restrições usadas pelo blueprint ed bases empresariais, consulte Restrições da política da organização.

A tabela a seguir descreve as outras restrições da política da organização definidas no módulo Segurança das funções do Cloud Run deste blueprint.

Restrição da política Descrição Valor recomendado
Configurações de entrada permitidas (funções do Cloud Run) constraints/cloudfunctions.allowedIngressSettings

Permita o tráfego de entrada apenas de serviços internos ou do balanceador de carga HTTP(S) externo.

O padrão é ALLOW_ALL.

ALLOW_INTERNAL_ONLY
Requer um Conector VPC (funções do Cloud Run) constraints/cloudfunctions.requireVPCConnector

Exigir a especificação de um conector de acesso VPC sem servidor ao implantar uma função. Quando essa restrição é aplicada, as funções precisam especificar um conector de acesso VPC sem servidor.

O padrão é false.

true
Configurações de saída permitidas do conector de acesso VPC (funções do Cloud Run) cloudfunctions.allowedVpcConnectorEgressSettings

Exigir todo o tráfego de saída para as funções do Cloud Run usarem um conector de acesso VPC sem servidor.

O padrão é PRIVATE_RANGES_ONLY.

ALL_TRAFFIC

Controles operacionais

É possível ativar a geração de registros e os recursos do nível Premium do Security Command Center Premium, como análise de integridade de segurança e detecção de ameaças. Esses controles ajudam você a fazer o seguinte:

  • Monitore o acesso aos dados.
  • Confira se a auditoria foi realizada de maneira adequada.
  • Ofereça suporte às operações de segurança e aos recursos de gerenciamento de incidentes da sua organização.

Geração de registros

Para ajudar a atender aos requisitos de auditoria e receber insights sobre seus projetos, configure o Google Cloud Observability com registros de dados dos serviços que você quer rastrear. Implante o Cloud Logging nos projetos antes de aplicar o código do Terraform para garantir que o blueprint configure a geração de registros para o firewall, o balanceador de carga e a rede VPC.

Depois de implantar o blueprint, recomendamos que você configure o seguinte:

Para todos os serviços nos projetos, verifique se os registros incluem informações sobre gravações de dados e acesso administrativo. Para mais informações sobre práticas recomendadas de geração de registros, consulte Controles de detecção.

Monitoramento e alertas

Depois de implantar o blueprint, é possível configurar alertas para notificar a central de operações de segurança (SOC, na sigla em inglês) de que uma ocorrência de segurança ocorreu. Por exemplo, é possível usar alertas para informar aos analistas de segurança quando uma permissão muda em um papel do IAM. Para mais informações sobre como configurar alertas do Security Command Center, consulte Como configurar notificações de localização.

O painel de monitoramento das funções do Cloud Run ajuda a monitorar o desempenho e a integridade das funções do Cloud Run. Ele fornece uma variedade de métricas e registros, que podem ser usados para identificar e resolver problemas. O painel também inclui vários recursos que podem ajudar a melhorar o desempenho das funções, como a capacidade de definir alertas e cotas.

Para mais informações, consulte a página Como monitorar funções do Cloud Run.

Para exportar alertas, consulte os seguintes documentos:

Como depurar e solucionar problemas

Execute testes de conectividade para depurar problemas de configuração de rede entre as funções do Cloud Run e os recursos da sub-rede. Os testes de conectividade simulam o caminho esperado de um pacote e fornecem detalhes sobre a conectividade, incluindo a análise de conectividade recurso a recurso.

Configure os testes de conectividade separadamente, porque eles não são ativados pelo código do Terraform. Consulte mais informações em Criar e executar testes de conectividade.

Modos de implantação do Terraform

A tabela a seguir descreve as maneiras de implantar esse blueprint e quais módulos do Terraform se aplicam a cada modo de implantação.

Modo de implantação Módulos do Terraform

Implante este blueprint depois de implantar o blueprint de bases empresariais (recomendado).

Essa opção implanta os recursos desse blueprint no mesmo perímetro do VPC Service Controls usado pelo blueprint de bases empresariais. Para mais informações, consulte Como personalizar a Foundation v3.0.0 para a implantação segura das funções do Cloud Run.

Essa opção também usa o projeto de secrets que você criou quando implantou o blueprint de bases empresariais.

Use estes módulos do Terraform:

Instale esse blueprint sem instalar o blueprint de bases de segurança.

Essa opção exige a criação de um perímetro do VPC Service Controls.

Use estes módulos do Terraform:

resumo geral

Para implementar a arquitetura descrita neste documento, faça o seguinte:

  1. Leia o arquivo README do blueprint e verifique se você atende a todos os pré-requisitos.
  2. No ambiente de teste, para ver o blueprint em ação, implante um dos exemplos. Esses exemplos correspondem aos exemplos de arquitetura descritos em Arquitetura. Como parte do processo de teste, faça o seguinte:
    1. Use o Security Command Center para verificar os projetos em relação aos requisitos de conformidade comuns.
    2. Substitua o aplicativo de amostra por um aplicativo real (por exemplo, 1) e execute um cenário de implantação típico.
    3. Trabalhe com as equipes de engenharia e operações de aplicativos na sua empresa para testar o acesso delas aos projetos e verificar se elas podem interagir com a solução da maneira esperada.
  3. Implante o blueprint no ambiente.

A seguir