Implantar uma arquitetura sem servidor segura usando o Cloud Run

Last reviewed 2023-03-10 UTC

Este conteúdo foi atualizado pela última vez em março de 2023 e representa o momento em que foi escrito. Os sistemas e as políticas de segurança do Google podem mudar futuramente, conforme aprimorarmos a proteção para nossos clientes.

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 detalhada para engenheiros de DevOps, arquitetos de segurança e desenvolvedores de aplicativos sobre como ajudar a proteger aplicativos sem servidor que usam o Cloud Run. 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

Com esse blueprint, é possível executar aplicativos sem servidor no Cloud Run com a VPC compartilhada. Recomendamos que você use a VPC compartilhada, porque ela centraliza a política e o controle de rede para todos os recursos de rede. Além disso, a VPC compartilhada é implantada no Blueprint de bases de segurança.

A imagem a seguir mostra como executar os aplicativos sem servidor em uma rede VPC compartilhada.

A arquitetura do blueprint sem servidor.

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

  • Um balanceador de carga de aplicativo externo recebe os dados que os aplicativos sem servidor exigem da Internet e os encaminha para o Cloud Run. O balanceador de carga de aplicativo externo é um balanceador de carga da camada 7.
  • O Google Cloud Armor atua como o firewall de aplicativos da Web para ajudar a proteger seus aplicativos sem servidor contra ataques de negação de serviço (DoS) e da Web.
  • O Cloud Run permite executar o código do aplicativo em contêineres e gerencia a infraestrutura em seu nome. Nesse blueprint, a configuração de entrada interna e do Cloud Load Balancing restringe o acesso ao Cloud Run para que o Cloud Run aceite solicitações apenas do balanceador de carga de aplicativo externo.
  • 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 o Cloud Run se comunique com outros serviços, sistemas de armazenamento e recursos que são compatíveis com o VPC Service Controls.

    Por padrão, você cria o conector de acesso VPC sem servidor no projeto de serviço. É possível criar o conector de acesso VPC sem servidor no projeto host especificando true para a variável de entrada connector_on_host_project ao executar o módulo Rede segura do Cloud Run. Para mais informações, consulte Comparação de métodos de configuração.

  • As Regras de firewall de nuvem privada virtual (VPC) controlam o fluxo de dados para a sub-rede que hospeda seus recursos, como um servidor da empresa hospedado no Compute Engine ou dados da empresa armazenados no Cloud Storage.

  • O VPC Service Controls cria um perímetro de segurança que isola os serviços e recursos do Cloud Run configurando a autorização, os controles de acesso e a troca de dados segura. Esse perímetro foi projetado para proteger o conteúdo recebido, isolar seu aplicativo configurando mais controles de acesso e monitorando, além de separar a governança do Google Cloud do aplicativo. Sua governança inclui o gerenciamento de chaves e a geração de registros.

  • A VPC compartilhada permite conectar o conector de acesso VPC sem servidor no seu projeto de serviço ao projeto do host.

  • 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 o Cloud Run.

  • 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.

Arquitetura alternativa: o Cloud Run sem uma rede VPC compartilhada

Se você não estiver usando uma rede VPC compartilhada, será possível implantar o Cloud Run e seu aplicativo sem servidor em um perímetro do VPC Service Controls sem uma rede VPC compartilhada. É possível implementar essa arquitetura alternativa se você estiver usando uma topologia hub e spoke.

A imagem a seguir mostra como executar os aplicativos sem servidor sem a VPC compartilhada.

Uma arquitetura alternativa para o blueprint sem servidor.

A arquitetura exibida no diagrama anterior usa uma combinação de serviços e recursos do Google Cloud semelhantes aos descritos na seção anterior, Arquitetura recomendada: Cloud Run com uma VPC compartilhada

Estrutura da organização

Você agrupa os recursos para poder gerenciá-los e separar os ambientes de desenvolvimento e teste do ambiente de produçã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.
Dev Contém projetos que têm recursos de nuvem que estão sendo desenvolvidos no momento. Nesse blueprint, a pasta Dev 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 host 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 os serviços.
Projeto de serviço Esse projeto inclui o aplicativo sem servidor, o 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 o Cloud Run, o Google Cloud Armor, o conector de acesso VPC sem servidor e o balanceador de carga.
Projeto de segurança Esse projeto inclui serviços específicos de segurança, como o Cloud KMS e o Secret Manager.

Ao aplicar o código do Terraform, você especifica o nome desse projeto e o blueprint implanta o Cloud KMS. Se você usa o módulo Secure Cloud Run, o Artifact Registry também é implantado.

Se você implantar esse blueprint depois de implantar o blueprint das bases de segurança, esse será o projeto do secret criado pelo blueprint das bases de segurança. Para mais informações sobre os projetos de blueprint do Enterprise Foundation, consulte Projetos.

Se você implantar várias instâncias desse blueprint sem o blueprint de fundações de segurança, 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 do Cloud Run

grp-gcp-secure-cloud-run-developer@example.com
Projeto de segurança
Usuário do Cloud Run

grp-gcp-secure-cloud-run-user@example.com
Projeto de serviço

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 de privilégio mínimo, concedendo às entidades apenas os privilégios necessários para realizar as tarefas.
  • Conexões de rede seguras por meio da concepção, políticas da organização e políticas de segmentação.
  • Proteja a configuração de cada um dos serviços.
  • Entenda os níveis de risco e os requisitos de segurança do ambiente que hospeda suas cargas de trabalho sem servidor.
  • Configurar o monitoramento e a geração de registros suficientes para permitir a detecção, investigação e resposta.

Controles de segurança para aplicativos sem servidor

É possível proteger seus aplicativos sem servidor usando controles que protegem o tráfego na rede, controlam o acesso e criptografam dados.

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.

Tráfego SSL

Para oferecer suporte ao tráfego HTTPS no aplicativo sem servidor, configure um certificado SSL para o balanceador de carga de aplicativo externo. Por padrão, é possível usar um certificado autoassinado que pode ser alterado para um certificado gerenciado depois de aplicar o código do Terraform. Para mais informações sobre como instalar e usar certificados gerenciados, consulte Como usar certificados SSL gerenciados pelo Google.

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.

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

Controles de perímetro

Conforme mostrado no diagrama recomendado de arquitetura, você coloca os recursos do aplicativo sem servidor em um perímetro separado. Esse perímetro ajuda a proteger o aplicativo sem servidor contra acesso não intencional e exfiltração de dados.

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.

Proxy do Identity and Access

Se o ambiente já inclui o Identity and Access Proxy (IAP), você pode configurar o balanceador de carga de aplicativo externo para usar o IAP e autorizar o tráfego para seu aplicativo sem servidor. Com o IAP, é possível estabelecer uma camada de autorização central para seu aplicativo sem servidor. Assim, é possível usar controles de acesso no nível do aplicativo em vez de confiar em firewalls no nível da rede.

Para ativar o IAP para seu aplicativo, defina iap_config.enable como true no arquivo loadbalancer.tf.

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

Contas de serviço e controles de acesso

As contas de serviço são identidades que o Google Cloud pode usar para executar solicitações de API em seu nome. Para implementar a separação de tarefas, crie contas de serviço com papéis 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 os seguintes papéis:

    • roles/run.invoker
    • roles/secretmanager.secretAccessor

    Para mais informações, consulte Permitir que o Cloud Run acesse um secret.

  • Uma conta do conector de acesso VPC sem servidor (gcp_sa_vpcaccess) que tem o papel roles/compute.networkUser.

  • Uma segunda conta do conector de acesso VPC sem servidor (cloud_services) que tem o papel roles/compute.networkUser.

    Essas contas de serviço do conector de acesso VPC sem servidor são necessárias para que o conector possa criar as regras de entrada e saída de firewall no projeto host. Para mais informações, consulte Conceder permissões para contas de serviço nos seus projetos de serviço.

  • Uma identidade de serviço para executar o Cloud Run (run_identity_services) que tem o papel roles/vpcaccess.user.

  • Um agente de serviço das APIs do Google (cloud_services_sa) que tem o papel roles/editor. Essa conta de serviço permite que o Cloud Run se comunique com o conector de acesso VPC sem servidor.

  • Uma identidade de serviço para o Cloud Run (serverless_sa) que tenha o papel roles/artifactregistry.reader. Essa conta de serviço fornece acesso ao Artifact Registry e às chaves de criptografia e descriptografia do CMEK.

Gerenciamento de chaves

Use as chaves de CMEK para ajudar a proteger seus dados no Artifact Registry e no Cloud Run. Você usa as seguintes chaves de criptografia:

  • 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 pelo Cloud Run.

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 chaves de CMEK estão na mesma região que seus recursos. Por padrão, as chaves CMEK são alternadas a cada 30 dias.

Gerenciamento de secrets

O Cloud Run suporta 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 volume_mounts e volumes no módulo principal.

Ao implantar esse blueprint com o blueprint de princípios básicos de segurança, é necessário adicionar secrets ao projeto antes de aplicar o código do Terraform. O blueprint concederá o papel de acessador de secret do Secret Manager à conta de serviço do Cloud Run. Para mais informações, consulte Usar secrets.

Políticas da organização

Esse blueprint adiciona restrições às restrições da política da organização. 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 do Cloud Run deste blueprint.

Restrição da política Descrição Valor recomendado
constraints/run.allowedIngress Permitir tráfego de entrada apenas de serviços internos ou do balanceador de carga de aplicativo externo. internal-and-cloud-load-balancing
constraints/run.allowedVPCEgress Exigir que as revisões de um serviço do Cloud Run usem um conector de acesso VPC sem servidor e garantir que as configurações de saída da VPC das revisões permitam apenas intervalos particulares. private-ranges-only

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 quem está acessando seus dados.
  • Confira se a auditoria foi realizada de maneira adequada.
  • Ofereça suporte às equipes de gerenciamento e operações de incidentes para responder a problemas que possam ocorrer.

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 leituras e gravações de dados e sobre o que os administradores acessam. Para mais informações sobre as práticas recomendadas de geração de registros, consulte Controles de detecção.

Monitoramento e alertas

Depois de implantar o blueprint, configure alertas para notificar a central de operações de segurança (SOC) que pode ocorrer um incidente de segurança. 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 do Cloud Run Monitoring, que faz parte da biblioteca de painel de amostra, fornece as seguintes informações:

  • Contagem de solicitações
  • Latência da solicitação
  • Tempo faturável da instância
  • Alocação da CPU do contêiner
  • Alocação de memória do contêiner
  • Uso da CPU do contêiner
  • Uso da memória do contêiner

Para instruções sobre como importar o painel, consulte Instalar painéis de amostra. 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 o 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.

Controles de detetive

Esta seção descreve os controles de detecção incluídos no blueprint.

Google Cloud Armor e WAF

Use um balanceador de carga de aplicativo externo e o Google Cloud Armor para oferecer proteção distribuída de negação de serviço (DDoS) para seu aplicativo sem servidor. O Google Cloud Armor é o firewall de aplicativos da Web (WAF) incluído no Google Cloud.

Configure as regras do Google Cloud Armor descritas na tabela a seguir para ajudar a proteger o aplicativo sem servidor. As regras foram projetadas para ajudar a reduzir os 10 principais riscos do OWASP.

Nome da regra do Google Cloud Armor Nome da regra do ModSecurity
Execução remota de código rce-v33-stable
O arquivo local inclui lfi-v33-stable
Ataque de protocolo protocolattack-v33-stable
Inclusão de arquivo remoto rfi-v33-stable
Detecção de verificação scannerdetection-v33-stable
Ataque de fixação de sessão sessionfixation-v33-stable
Injeção de SQL sqli-v33-stable
Scripting em vários locais xss-v33-stable

Quando essas regras são ativadas, o Google Cloud Armor nega automaticamente qualquer tráfego que corresponda à regra.

Para mais informações sobre essas regras, consulte Ajustar as regras WAF pré-configuradas do Google Cloud Armor.

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

É possível detectar possíveis problemas de segurança no Cloud Run usando o Recomendador. O recomendador pode detectar problemas de segurança, como os seguintes:

  • Chaves de API ou senhas armazenadas em variáveis de ambiente em vez de no Secret Manager.
  • Contêineres que incluem credenciais codificadas em vez de usar identidades de serviço.

Cerca de um dia após a implantação do Cloud Run, o recomendador começa a fornecer as descobertas e recomendações. O recomendador exibe as descobertas e as ações corretivas recomendadas na lista de serviços do Cloud Run ou no Hub de recomendações.

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 de segurança. Para mais informações, consulte Como personalizar a Foundation v2.3.1 para implantação sem servidor segura.

Essa opção também usa o projeto de secrets que você criou quando implantou o blueprint de bases de segurança.
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. Crie um certificado SSL para uso com o balanceador de carga de aplicativo externo.
    Se você não concluir essa etapa, o blueprint usará um certificado autoassinado para implantar o balanceador de carga, e seu navegador exibirá avisos sobre conexões não seguras quando você tentar acessar seus aplicativo sem servidor.
  3. No seu ambiente de teste, implante o exemplo seguro do Cloud Run para ver o blueprint em ação. 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 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.
  4. Implante o blueprint no ambiente.

Mapeamentos de conformidade

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 ajudam a lidar com a maioria desses riscos, conforme descrito na tabela a seguir.

Risco Redução de blueprints Sua responsabilidade
1. Injeção de dados de evento da função O Google Cloud Armor e os balanceadores de carga de aplicativo externos ajudam a proteger contra OWASP Top 10, conforme descrito em As 10 melhores opções de mitigação do OWASP 2021 no Google Cloud Práticas de programação seguras, como processamento de exceções, conforme descrito nas Práticas de programação seguras do OWASP e nos níveis de cadeia de suprimentos para artefatos de software (SLSA, na sigla em inglês)
2. Autenticação com falha Nenhum o IAP e o Identity Platform para autenticar usuários no serviço.
3. Configuração de implantação sem servidor não segura CMEK com o Cloud KMS
Gerenciamento das suas próprias chaves de criptografia
4. Funções e permissões com privilégios excessivos
  • Conta de serviço personalizada para autenticação de serviço (não a conta de serviço padrão do Compute Engine)
  • Papéis do IAM com escopo restrito na conta de serviço do Cloud Run
  • VPC Service Controls para limitar o escopo do acesso à API Google Cloud, conforme fornecido com as bases de segurança do Google Cloud;
Nenhum
5. Monitoramento e geração de registros inadequados de funções Cloud Logging Painéis e estrutura de alertas do Cloud Monitoring
6. Dependências não seguras de terceiros Nenhum Proteger o pipeline de CI/CD usando a verificação de código e a análise de pré-implantação
7. Armazenamento de secrets de aplicativos não seguros Secret Manager Gerenciamento de secrets no código do aplicativo
8. Negação de serviço e esgotamento de recursos financeiros
  • Google Cloud Armor
  • Tempos limite do serviço do Cloud Run (o padrão é 120 segundos)
Nenhum
9. Manipulação de lógica de negócios sem servidor O VPC Service Controls para limitar o escopo do acesso à API Google Cloud (fornecido usando o blueprint de bases de segurança) Nenhum
10. Processamento incorreto de exceções e mensagens de erro detalhadas Nenhum Práticas recomendadas para programação segura
11. Funções obsoletas, recursos da nuvem e gatilhos de eventos Use revisões para minimizar a superfície de ataque. As revisões ajudam a reduzir a probabilidade de ativar acidentalmente uma iteração anterior e obsoleta de um serviço. As revisões também ajudam a testar a postura de segurança de uma nova revisão usando testes A/B com ferramentas de monitoramento e geração de registros.
  • Infraestrutura como código (IaC) para gerenciar recursos de nuvem
  • Monitoramento de recursos do Cloud usando o Security Command Center
  • Monitoramento do Cloud Billing
  • Limpeza de recursos de nuvem não utilizados para minimizar a superfície de ataque
12. Persistência de dados entre execuções Nenhum Nenhum

A seguir