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:
- Como implantar uma arquitetura sem servidor usando o Cloud Run (este documento)
- Como implantar uma arquitetura sem servidor usando o Cloud Functions
As diferenças entre o Cloud Functions e o Cloud Run incluem o seguinte:
- O Cloud Functions é acionado 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.
- O Cloud Functions é limitado a um conjunto de ambientes de execução compatíveis. É possível usar o Cloud Run com qualquer linguagem de programação.
- O Cloud Functions gerencia 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 o Cloud Functions, 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.
Arquitetura recomendada: Cloud Run com uma rede VPC compartilhada
A imagem a seguir mostra como executar os aplicativos sem servidor em uma rede VPC compartilhada.
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
truepara a variável de entradaconnector_on_host_projectao 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 projeto de serviço ao projeto 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.
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.
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.invokerroles/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 papelroles/compute.networkUser.Uma segunda conta do conector de acesso VPC sem servidor (
cloud_services) que tem o papelroles/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 papelroles/vpcaccess.user.Um agente de serviço das APIs do Google (
cloud_services_sa) que tem o papelroles/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 papelroles/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:
- Crie um coletor de registros agregado em todos os projetos.
- Selecione a região apropriada para armazenar seus registros.
- Adicione chaves CMEK no coletor de registros.
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:
- Leia o arquivo README do blueprint e verifique se você atende a todos os pré-requisitos.
- 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. - 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:
- Use o Security Command Center para verificar os projetos em relação aos requisitos de conformidade comuns.
- Substitua o aplicativo de amostra por um aplicativo real e execute um cenário de implantação típico.
- 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.
- 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.
| o 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 |
|
Nenhuma |
| 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 |
|
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) | Nenhuma |
| 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. |
|
| 12. Persistência de dados entre execuções | Nenhum | Nenhum |
A seguir
- Para um ambiente seguro de referência, consulte o Blueprint do Security Foundation do Google Cloud.
- Para ver os detalhes do blueprint descrito neste documento, leia o arquivo README de configuração do Terraform.
Para ler sobre as práticas recomendadas de segurança e conformidade, consulte Framework da arquitetura do Google Cloud: segurança, privacidade e conformidade.
Para ver mais práticas recomendadas e blueprints, consulte a central de práticas recomendadas de segurança.