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 o Cloud Functions (2nd gen). 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 Functions (este documento)
- Como implantar uma arquitetura sem servidor usando o Cloud Run
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
Esse blueprint usa uma arquitetura de VPC compartilhada, em que o Cloud Functions é 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 exibida no diagrama anterior usa uma combinação dos seguintes serviços e recursos do Google Cloud:
- O Cloud Functions permite que você execute funções como um serviço e gerencie a infraestrutura em seu nome. Por padrão, essa arquitetura implanta o Cloud Functions apenas com um endereço IP interno e sem acesso à Internet pública.
- O evento acionador é o evento que aciona o Cloud Functions. 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 do Cloud Functions.
- 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 o 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 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 o Cloud Functions atua. 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 do Cloud Functions 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 do Cloud Functions. 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 o Cloud Functions não exigir 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 o Cloud Run.
O Secret Manager armazena as chaves secretas do Cloud Functions. 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.
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 do Cloud Functions.
- 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 o Exemplo de servidor seguro com 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.
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 Scheduler emite eventos regularmente.
- O Pub/Sub enfileira eventos que são usados como entrada e um acionador do Cloud Functions.
- As regras de firewall da nuvem privada virtual (VPC) controlam o fluxo de dados na sub-rede que hospeda seus recursos, como dados da empresa armazenados no Cloud SQL.
- O Cloud SQL Auth Proxy controla o acesso ao Cloud SQL.
- O Cloud SQL hospeda um serviço que faz peering com a rede VPC e que o aplicativo sem servidor pode acessar. Se você implantar o exemplo seguro do Cloud Functions com o Cloud SQL, implante um banco de dados MySQL com um banco de dados de amostra.
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).
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 BigQuery hospeda um armazenamento de dados. Se você implantar o exemplo seguro do Cloud Functions acionado pelo BigQuery, implantará um conjunto de dados e uma tabela de amostra do BigQuery.
- O Eventarc aciona o Cloud Functions quando um evento específico ocorre no BigQuery.
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.
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, 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 Functions 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 do Cloud Functions, 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 é 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 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 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 do Cloud Functions 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:
Uma conta de serviço do Cloud Run (
cloudfunction_sa) que tem os seguintes papéis:- Leitor da rede do Compute (
roles/compute.networkViewer) - Destinatário do evento do Eventarc (
roles/eventarc.eventReceiver) - Chamador do Cloud Run (
roles/run.invoker) - Avaliador de secrets do Secret Manager (
roles/secretmanager.secretAccessor)
Para mais informações, consulte Permitir que o Cloud Run acesse um secret.
O Cloud Functions usa essa conta de serviço para conceder permissão somente a tópicos específicos do Pub/Sub e para restringir o sistema de eventos do Eventarc dos recursos de computação do Cloud Functions em Exemplo de arquitetura com um aplicativo sem servidor usando o Cloud Storage e Exemplo de arquitetura com o armazenamento de dados do BigQuery.
- Leitor da rede do Compute (
Uma conta do conector de acesso VPC sem servidor (
gcp_sa_vpcaccess) que tenha o papel Usuário de rede do Compute (roles/compute.networkUser).Uma segunda conta do conector de acesso VPC sem servidor (
cloud_services) que tem o papel de usuário da rede do Compute (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 Functions (
cloudfunction_sa) que tem os papéis de [Usuário de acesso VPC sem servidor (roles/vpcaccess.user)](/iam/docs/understanding-roles#vpcaccess.user)e a Usuário da conta de serviço (roles/iam.serviceAccountUser) .Um conta de serviço para as APIs do Google (
cloud_services_sa) que tem o papel de usuário da rede do Compute (roles/compute.networkUser) para executar processos internos do Google em seu nome.Uma identidade de serviço para o Cloud Functions (
cloud_serverless_sa) que tem o papel Leitor do Artifact Registry (roles/artifactregistry.reader). Essa conta de serviço fornece acesso ao Artifact Registry e às CMEKs.Uma identidade de serviço para o Eventarc (
eventarc_sa) que tenha o Descriptografador de CryptoKey do Cloud KMS (roles/cloudkms.cryptoKeyDecrypter) e o criptografador de CryptoKey do Cloud KMSroles/cloudkms.cryptoKeyEncrypter).Uma identidade de serviço para o Artifact Registry (
artifact_sa) com os papéis de criptografia de CryptoKey (roles/cloudkms.cryptoKeyDecrypter) e criptografador de CryptoKey do Cloud KMS (roles/cloudkms.cryptoKeyEncrypter).
Gerenciamento de chaves
Para validar a integridade e ajudar a proteger os dados em repouso, use as CMEKs com o Artifact Registry, Cloud Functions, 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 pelo 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
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 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 do Cloud Functions. 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 do Cloud Run deste blueprint.
| Restrição da política | Descrição | Valor recomendado |
|---|---|---|
Configurações de saída permitidas
(Cloud Functions)
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_INTERNAL_ONLY
|
Requer um Conector VPC (Cloud Functions)
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 é |
true
|
Configurações de saída permitidas do conector de acesso VPC
(Cloud Functions) cloudfunctions.allowedVpcConnectorEgressSettings |
Exigir todo o tráfego de saída para o Cloud Functions usar um conector de acesso VPC sem servidor.
O padrão é |
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:
- Crie um coletor de registros agregado em todos os projetos.
- Adicione CMEKs ao seu coletor de registros.
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 do Cloud Functions Monitoring ajuda a monitorar o desempenho e a integridade do Cloud Functions. 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 Cloud Extensions .
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 Functions 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 do Cloud Functions. 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:
- Leia o arquivo README do blueprint e verifique se você atende a todos os pré-requisitos.
- 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:
- 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 (por exemplo, 1) 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.
A seguir
- Consulte o blueprint de bases empresariais do Google Cloud para um ambiente seguro de referência.
- Para ver detalhes sobre o blueprint, leia o leia o README da configuração do Terraform.
- Para implantar um aplicativo sem servidor usando o Cloud Run, consulte Implantar uma arquitetura sem servidor segura usando o Cloud Run.