As arquiteturas sem servidor permitem-lhe desenvolver software e serviços sem aprovisionar nem manter servidores. Pode usar arquiteturas sem servidor para criar aplicações para uma vasta gama de serviços.
Este documento fornece orientações fundamentadas para engenheiros de DevOps, arquitetos de segurança e programadores de aplicações sobre como ajudar a proteger aplicações sem servidor que usam funções do Cloud Run (2.ª geração). O documento faz parte de um projeto de segurança que consiste no seguinte:
- Um repositório do GitHub que contém um conjunto de configurações e scripts do Terraform.
- Um guia para a arquitetura, a conceção e os controlos de segurança que implementa com o esquema (este documento).
Embora possa implementar este plano sem implementar primeiro o Google Cloud plano de bases empresariais, este documento pressupõe que já configurou um conjunto básico de controlos de segurança, conforme descrito no Google Cloud plano de bases empresariais. A arquitetura descrita neste documento ajuda a adicionar controlos adicionais à sua base para ajudar a proteger as aplicações sem servidor.
Para ajudar a definir os principais controlos de segurança relacionados com aplicações sem servidor, a Cloud Security Alliance (CSA) publicou os 12 principais riscos críticos para aplicações sem servidor. Os controlos de segurança usados neste plano foram concebidos para abordar os riscos relevantes para os vários exemplos de utilização descritos neste documento.
Exemplos de utilização sem servidor
O plano detalhado suporta os seguintes exemplos de utilização:
- Implementar uma arquitetura sem servidor com funções do Cloud Run (este documento)
- Implementar uma arquitetura sem servidor com o Cloud Run
As diferenças entre as funções do Cloud Run e o Cloud Run incluem o seguinte:
- As funções do Cloud Run são acionadas por eventos, como alterações aos dados numa base de dados ou a receção de uma mensagem de um sistema de mensagens, como o Pub/Sub. O Cloud Run é acionado por pedidos, como pedidos HTTP.
- As funções do Cloud Run estão limitadas a um conjunto de runtimes suportados. Pode usar o Cloud Run com qualquer linguagem de programação.
- As funções do Cloud Run gerem contentores e a infraestrutura que controlam o servidor Web ou o tempo de execução da linguagem para que se possa focar no seu código. O Cloud Run oferece-lhe a flexibilidade de executar estes serviços para que tenha controlo da configuração do contentor.
Para mais informações sobre as diferenças entre o Cloud Run e as funções do Cloud Run, consulte o artigo Escolher uma opção de Google Cloud computação.
Arquitetura
Este esquema usa uma arquitetura de VPC partilhada, na qual as funções do Cloud Run são implementadas num projeto de serviço e podem aceder a recursos localizados noutras redes VPC.
O diagrama seguinte mostra uma arquitetura de alto nível, que é descrita mais detalhadamente nas arquiteturas de exemplo que se seguem.
A arquitetura apresentada no diagrama anterior usa uma combinação dos seguintes Google Cloud serviços e funcionalidades:
- As funções do Cloud Run permitem-lhe executar funções como um serviço e gerem a infraestrutura em seu nome. Por predefinição, esta arquitetura implementa funções do Cloud Run apenas com um endereço IP interno e sem acesso à Internet pública.
- O evento de acionamento é o evento que aciona as funções do Cloud Run. Conforme descrito mais detalhadamente nas arquiteturas de exemplo, isto pode ser um evento do Cloud Storage, um intervalo agendado ou uma alteração no BigQuery.
- O Artifact Registry armazena os contentores de origem da sua aplicação de funções do Cloud Run.
- A VPC partilhada permite-lhe ligar um conetor do Acesso a VPC sem servidor no projeto de serviço ao projeto anfitrião. Implementa uma rede de VPC partilhada separada para cada ambiente (produção, não produção e desenvolvimento). Esta estrutura de rede oferece isolamento de rede entre os diferentes ambientes. Uma rede de VPC partilhada permite-lhe gerir centralmente os recursos de rede numa rede comum, ao mesmo tempo que delega responsabilidades administrativas para o projeto de serviço.
O conetor do Acesso a VPC sem servidor liga a sua aplicação sem servidor à sua rede VPC através do Acesso a VPC sem servidor. O Acesso a VPC sem servidor ajuda a garantir que os pedidos da sua aplicação sem servidor para a rede VPC não são expostos à Internet. O acesso a VPC sem servidor permite que as funções do Cloud Run comuniquem com outros serviços, sistemas de armazenamento e recursos que suportam os VPC Service Controls.
Pode configurar o Acesso a VPC sem servidor no projeto anfitrião da VPC partilhada ou num projeto de serviço. Por predefinição, este esquema implementa o acesso a VPC sem servidor no projeto anfitrião da VPC partilhada para se alinhar com o modelo de VPC partilhada de centralização dos recursos de configuração de rede. Para mais informações, consulte o artigo Comparação de métodos de configuração.
Os VPC Service Controls criam um perímetro de segurança que isola os serviços e os recursos das funções do Cloud Run através da configuração da autorização, dos controlos de acesso e da troca de dados segura. Este perímetro foi concebido para isolar a sua aplicação e serviços geridos através da configuração de controlos de acesso e monitorização adicionais, e para separar a sua governação do Google Cloud da aplicação. A sua governação inclui a gestão de chaves e o registo.
O serviço de consumo é a aplicação sobre a qual as funções do Cloud Run atuam. O serviço de consumo pode ser um servidor interno ou outro serviço, como o Cloud SQL. Google Cloud Consoante o seu exemplo de utilização, este serviço pode estar atrás da firewall de nova geração do Google Cloud, noutra sub-rede, no mesmo projeto de serviço que as funções do Cloud Run ou noutro projeto de serviço.
O Secure Web Proxy foi concebido para proteger o tráfego Web de saída, se necessário. Permite políticas flexíveis e detalhadas com base em identidades na nuvem e aplicações Web. Este projeto usa o proxy Web seguro para políticas de acesso detalhadas ao tráfego Web de saída durante a fase de criação das funções do Cloud Run. O projeto adiciona uma lista de URLs permitidos à regra da política de segurança do gateway.
O Cloud NAT fornece uma ligação de saída à Internet, se necessário. O Cloud NAT suporta a tradução de endereços de rede de origem (SNAT) para recursos de computação sem endereços IP públicos. Os pacotes de resposta de entrada usam a tradução de endereços de rede de destino (DNAT). Pode desativar o Cloud NAT se as funções do Cloud Run não precisarem de acesso à Internet. O Cloud NAT implementa a política de rede de saída anexada ao proxy Web seguro.
O Cloud Key Management Service (Cloud KMS) armazena as chaves de encriptação geridas pelo cliente (CMEKs) usadas pelos serviços neste projeto, incluindo a sua aplicação sem servidor, o Artifact Registry e as funções do Cloud Run.
O Secret Manager armazena os segredos das funções do Cloud Run. O esquema monta segredos como um volume para oferecer um nível de segurança mais elevado do que a transmissão de segredos como variáveis de ambiente.
A gestão de identidade e de acesso (IAM) e o Resource Manager ajudam a restringir o acesso e a isolar recursos. Os controlos de acesso e a hierarquia de recursos seguem o princípio do menor privilégio.
O Cloud Logging recolhe todos os registos dos Google Cloud serviços para armazenamento e obtenção pelas suas ferramentas de análise e investigação.
O Cloud Monitoring recolhe e armazena informações de desempenho e métricas sobre os Google Cloud serviços.
Exemplo de arquitetura com uma aplicação sem servidor que usa o Cloud Storage
O diagrama seguinte mostra como pode executar uma aplicação sem servidor que acede a um servidor interno quando ocorre um evento específico no Cloud Storage.
Além dos serviços descritos na secção Arquitetura, esta arquitetura de exemplo usa uma combinação dos seguintes serviços e funcionalidades: Google Cloud
- O Cloud Storage emite um evento quando qualquer recurso na nuvem, aplicação ou utilizador cria um objeto Web num contentor.
- O Eventarc encaminha eventos de diferentes recursos. O Eventarc encripta eventos em trânsito e em repouso.
- O Pub/Sub coloca em fila os eventos que são usados como entrada e acionador para as funções do Cloud Run.
- As regras de firewall da nuvem privada virtual (VPC) controlam o fluxo de dados para a sub-rede que aloja os seus recursos, como um servidor interno.
- O servidor interno é executado no Compute Engine ou no Google Kubernetes Engine e aloja a sua aplicação interna. Se implementar as funções do Cloud Run seguras com o exemplo de servidor interno, implementa um servidor Apache com uma página HTML Hello World. Este exemplo simula o acesso a uma aplicação interna que executa VMs ou contentores.
Exemplo de arquitetura com o Cloud SQL
O diagrama seguinte mostra como pode executar uma aplicação sem servidor que acede a um serviço alojado do Cloud SQL a um intervalo regular que é definido no Cloud Scheduler. Pode usar esta arquitetura quando tiver de recolher registos, agregar dados, etc.
Além dos serviços descritos na secção Arquitetura, esta arquitetura de exemplo usa uma combinação dos seguintes serviços e funcionalidades: Google Cloud
- O Cloud Scheduler emite eventos regularmente.
- O Pub/Sub coloca em fila os eventos que são usados como entrada e acionador para as funções do Cloud Run.
- As regras de firewall da nuvem privada virtual (VPC) controlam o fluxo de dados para a sub-rede que aloja os seus recursos, como os dados da empresa armazenados no Cloud SQL.
- O proxy Auth do Cloud SQL controla o acesso ao Cloud SQL.
- O Cloud SQL aloja um serviço que está em peering com a rede VPC e ao qual a aplicação sem servidor pode aceder. Se implementar o exemplo de funções do Cloud Run seguras com o Cloud SQL, implementa uma base de dados MySQL com uma base de dados de exemplo.
Arquitetura de exemplo com o armazém de dados do BigQuery
O diagrama seguinte mostra como pode executar uma aplicação sem servidor que é acionada quando ocorre um evento no BigQuery (por exemplo, quando são adicionados dados ou é criada uma tabela).
Além dos serviços descritos na secção Arquitetura, esta arquitetura de exemplo usa uma combinação dos seguintes serviços e funcionalidades: Google Cloud
- O BigQuery alberga um armazém de dados. Se implementar o exemplo de funções do Cloud Run seguras acionadas pelo BigQuery, implementa um conjunto de dados e uma tabela de exemplo do BigQuery.
- O Eventarc aciona funções do Cloud Run quando ocorre um evento específico no BigQuery.
Estrutura da organização
O Resource Manager permite-lhe agrupar logicamente os recursos por projeto, pasta e organização.
O diagrama seguinte mostra uma hierarquia de recursos com pastas que representam
diferentes ambientes, como bootstrap, common, production, non-production (ou
testes) e desenvolvimento. Esta hierarquia de recursos baseia-se na hierarquia descrita no projeto de bases empresariais.
Implementa os projetos especificados no esquema nas seguintes pastas:
Common, Production, Non-production e Dev.
As secções seguintes descrevem este diagrama mais detalhadamente.
Pastas
Usa pastas para isolar o ambiente de produção e os serviços de administração dos ambientes de não produção e de testes. A tabela seguinte descreve as pastas do esquema de bases empresariais que são usadas por este esquema.
| Pasta | Descrição |
|---|---|
Bootstrap
|
Contém os recursos necessários para implementar o projeto das bases empresariais. |
Common
|
Contém serviços centralizados para a organização, como o projeto de segurança. |
Production
|
Contém projetos com recursos na nuvem que foram testados e estão prontos a ser usados pelos clientes. Neste esquema, a pasta Production contém o projeto de serviço e o projeto de anfitrião. |
Non-production
|
Contém projetos com recursos na nuvem que estão atualmente a ser testados e preparados para lançamento. Neste plano, a pasta Non-production contém o projeto de serviço e o projeto de anfitrião. |
Development
|
Contém projetos com recursos na nuvem que estão atualmente
em desenvolvimento. Neste plano, a pasta Development
contém o projeto de serviço e o projeto anfitrião. |
Pode alterar os nomes destas pastas para se alinharem com a estrutura de pastas da sua organização, mas recomendamos que mantenha uma estrutura semelhante. Para mais informações, consulte o artigo Estrutura da organização. Para outras estruturas de pastas, consulte o artigo Decida uma hierarquia de recursos para a sua Google Cloud zona de destino.
Projetos
Isola os recursos no seu ambiente através de projetos. A tabela seguinte descreve os projetos necessários na organização. Pode alterar os nomes destes projetos, mas recomendamos que mantenha uma estrutura de projeto semelhante.
| Projeto | Descrição |
|---|---|
| Projeto anfitrião da VPC partilhada | Este projeto inclui as regras de entrada de firewall e todos os recursos que tenham endereços IP internos (conforme descrito em Estabeleça ligação a uma rede VPC). Quando usa a VPC partilhada, designa um projeto como projeto anfitrião e anexa-lhe um ou mais projetos de serviço. Quando aplica o código do Terraform, especifica o nome deste projeto e o esquema implementa o conetor de acesso à VPC sem servidor, o Cloud NAT e o Cloud Secure Web Proxy. |
| Projeto de serviço da VPC partilhada | Este projeto inclui a sua aplicação sem servidor, as funções do Cloud Run e o conetor do Acesso a VPC sem servidor. Associa o projeto de serviço ao projeto anfitrião para que o projeto de serviço possa participar na rede VPC partilhada. Quando aplica o código do Terraform, especifica o nome deste projeto. O projeto implementa funções e serviços do Cloud Run necessários para o seu exemplo de utilização, como o Cloud SQL, o Cloud Scheduler, o Cloud Storage ou o BigQuery. Quando aplica o código Terraform, especifica o nome deste projeto e o esquema implementa o Cloud KMS. Se usar o módulo Secure Serverless Harness no esquema sem servidor para funções do Cloud Run, o Artifact Registry também é implementado. |
| Projeto de segurança | Este projeto inclui os seus serviços específicos de segurança, como o Cloud KMS e o Secret Manager.
O nome predefinido do projeto de segurança é Se implementar várias instâncias deste projeto detalhado sem o projeto detalhado de bases empresariais, cada instância tem o seu próprio projeto de segurança. |
Mapeamento de funções e grupos para projetos
Tem de conceder a diferentes grupos de utilizadores na sua organização acesso aos projetos que compõem a arquitetura sem servidor. A tabela seguinte descreve as recomendações de plano para grupos de utilizadores e atribuições de funções nos projetos que criar. Pode personalizar os grupos para corresponderem à estrutura existente da sua organização, mas recomendamos que mantenha uma segregação de funções e atribuição de funções semelhante.
| Grupo | Projeto | Funções |
|---|---|---|
| Administrador sem servidor grp-gcp-serverless-admin@example.com |
Projeto de serviço | |
| Administrador de segurança sem servidor grp-gcp-serverless-security-admin@example.com |
Projeto de segurança |
|
| Programador de funções do Cloud Run grp-gcp-secure-cloud-run-developer@example.com |
Projeto de segurança | |
| Utilizador das funções do Cloud Run grp-gcp-secure-cloud-run-user@example.com |
Projeto de serviço da VPC partilhada |
Controlos de segurança
Esta secção aborda os controlos de segurança no Google Cloud que usa para ajudar a proteger a sua arquitetura sem servidor. Os principais princípios de segurança a ter em consideração são os seguintes:
- Acesso seguro de acordo com o princípio do menor privilégio, concedendo aos principais apenas os privilégios necessários para realizar tarefas.
- Ligações de rede seguras através da conceção de limites de confiança, que inclui segmentação de rede, políticas da organização e políticas de firewall.
- Configuração segura para cada um dos serviços.
- Identifique os requisitos regulamentares ou de conformidade para a infraestrutura que aloja cargas de trabalho sem servidor e atribua um nível de risco.
- Configure uma monitorização e um registo suficientes para suportar as pistas de auditoria para as operações de segurança e a gestão de incidentes.
Controlos do sistema de compilação
Quando implementa a sua aplicação sem servidor, usa o Artifact Registry para armazenar as imagens de contentores e os ficheiros binários. O Artifact Registry suporta CMEK para que possa encriptar o repositório com as suas próprias chaves de encriptação.
Regras de rede e de firewall
As regras de firewall da nuvem virtual privada (VPC) controlam o fluxo de dados para os perímetros. Cria regras de firewall que negam todas as saídas, exceto para ligações específicas da porta TCP 443 de nomes de domínio especiais restricted.googleapis.com. A utilização do domínio restricted.googleapis.com tem as seguintes vantagens:
- Ajuda a reduzir a superfície de ataque da sua rede através do acesso privado à Google quando as cargas de trabalho comunicam com as APIs Google e os serviços Google.
- Garante que usa apenas serviços que suportam os VPC Service Controls.
Além disso, cria um registo DNS para resolver *.googleapis.com para restricted.googleapis.com.
Para mais informações, consulte o artigo Configurar o acesso privado à Google.
Controlos de perímetro
Conforme mostrado na secção Arquitetura, coloca os recursos da aplicação sem servidor num perímetro de segurança dos VPC Service Controls separado. Este perímetro ajuda a reduzir o impacto generalizado de uma violação de sistemas ou serviços. No entanto, este perímetro de segurança não se aplica ao processo de compilação de funções do Cloud Run quando o Cloud Build compila automaticamente o seu código numa imagem de contentor e envia essa imagem para o Artifact Registry. Neste 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 ajudar a garantir que apenas determinados responsáveis (utilizadores ou serviços) podem aceder a recursos e dados, ative os grupos e as funções da IAM.
Para ajudar a garantir que apenas recursos específicos podem aceder aos seus projetos, ative uma política de acesso para a sua organização Google. Para mais informações, consulte o artigo Atributos do nível de acesso.
Contas de serviço e controlos de acesso
As contas de serviço são contas para aplicações ou cargas de trabalho de computação em vez de para utilizadores finais individuais. Para implementar o princípio do menor privilégio e o princípio da separação de funções, crie contas de serviço com autorizações detalhadas e acesso limitado aos recursos. As contas de serviço são as seguintes:
Uma conta de serviço de funções do Cloud Run (
cloudfunction_sa) que tem as seguintes funções:- Leitor da rede de computação (
roles/compute.networkViewer) - Eventarc Event Receiver (
roles/eventarc.eventReceiver) - Cloud Run Invoker (
roles/run.invoker) - Secret Manager Secret Assessor (
roles/secretmanager.secretAccessor)
Para mais informações, consulte o artigo Permita que as funções do Cloud Run acedam a um segredo.
As funções do Cloud Run usam esta conta de serviço para conceder autorização apenas a tópicos específicos do Pub/Sub e para restringir o sistema de eventos do Eventarc a recursos de computação das funções do Cloud Run em arquitetura de exemplo com uma aplicação sem servidor que usa o Cloud Storage e arquitetura de exemplo com um armazém de dados do BigQuery.
- Leitor da rede de computação (
Uma conta de conetor do Acesso a VPC sem servidor (
gcp_sa_vpcaccess) que tenha a função Utilizador da rede de computação (roles/compute.networkUser).Uma segunda conta de conetor do Acesso a VPC sem servidor (
cloud_services) que tenha a função de utilizador da rede de computação (roles/compute.networkUser).Estas contas de serviço para o conetor do Acesso a VPC sem servidor são necessárias para que o conetor possa criar as regras de entrada e saída da firewall no projeto anfitrião. Para mais informações, consulte o artigo Conceda autorizações a contas de serviço nos seus projetos de serviço.
Uma conta de serviço para as APIs Google (
cloud_services_sa) que tem a função de utilizador da rede de computação (roles/compute.networkUser) para executar processos internos da Google em seu nome.Uma identidade do serviço para funções do Cloud Run (
cloud_serverless_sa) que tenha a função de leitor do Artifact Registry (roles/artifactregistry.reader). Esta conta de serviço fornece acesso ao Artifact Registry e às CMEKs.Uma identidade de serviço para o Eventarc (
eventarc_sa) que tenha as funções desencriptador de CryptoKey do Cloud KMS (roles/cloudkms.cryptoKeyDecrypter) e encriptador de CryptoKey do Cloud KMS (roles/cloudkms.cryptoKeyEncrypter).Uma identidade de serviço para o Artifact Registry (
artifact_sa) com as funções de desencriptador de CryptoKey (roles/cloudkms.cryptoKeyDecrypter) e encriptador de CryptoKey do Cloud KMS (roles/cloudkms.cryptoKeyEncrypter).
Gestão de chaves
Para validar a integridade e ajudar a proteger os seus dados em repouso, usa CMEKs com o Artifact Registry, as funções do Cloud Run, o Cloud Storage e o Eventarc. As CMEKs oferecem-lhe um maior controlo sobre a sua chave de encriptação. São usadas as seguintes CMEKs:
- Uma chave de software para o Artifact Registry que atesta o código da sua aplicação sem servidor.
- Uma chave de encriptação para encriptar as imagens de contentores que as funções do Cloud Run implementam.
- Uma chave de encriptação para eventos do Eventarc que encripta o canal de mensagens em repouso.
- Uma chave de encriptação para ajudar a proteger os dados no Cloud Storage.
Quando aplica a configuração do Terraform, especifica a localização da CMEK, que determina a localização geográfica onde as chaves são armazenadas. Tem de se certificar de que as CMEKs estão na mesma região que os seus recursos. Por predefinição, as CMEKs são rodadas a cada 30 dias.
Gestão de segredos
As funções do Cloud Run suportam o
Secret Manager
para armazenar os segredos que a sua aplicação sem servidor pode exigir. Estes segredos podem incluir chaves de API e nomes de utilizadores e palavras-passe de bases de dados. Para expor o segredo como um volume montado, use as variáveis de objeto service_configs no módulo principal.
Quando implementar este esquema com o esquema de bases empresariais, tem de
adicionar os seus segredos ao projeto de segredos antes de aplicar o código do Terraform. O
projeto vai conceder a função de avaliador de segredos do Secret Manager
(roles/secretmanager.secretAccessor) à conta de serviço das funções do Cloud Run. Para mais informações, consulte o artigo
Usar segredos.
Políticas da organização
Este projeto adiciona restrições às restrições da política da organização que o projeto de bases empresariais usa. Para mais informações acerca das restrições usadas no esquema detalhado das bases empresariais, consulte as restrições da política da organização.
A tabela seguinte descreve as restrições adicionais da política da organização definidas no módulo Segurança das funções do Cloud Run seguro deste projeto.
| Restrição de política | Descrição | Valor recomendado |
|---|---|---|
Definições de entrada permitidas
(Funções do Cloud Run)
constraints/cloudfunctions.allowedIngressSettings |
Permitir tráfego de entrada apenas de serviços internos ou do balanceador de carga HTTP(S) externo.
A predefinição é |
ALLOW_INTERNAL_ONLY
|
Exigir conetor de VPC (funções do Cloud Run)
constraints/cloudfunctions.requireVPCConnector |
Exigir a especificação de um conetor do Acesso a VPC sem servidor quando implementar uma função. Quando esta restrição é aplicada, as funções têm de especificar um conetor do Acesso a VPC sem servidor.
A predefinição é |
true
|
Definições de saída do conetor de VPC permitidas
(funções do Cloud Run)
cloudfunctions.allowedVpcConnectorEgressSettings |
Exigir que todo o tráfego de saída das funções do Cloud Run use um conetor do Acesso a VPC sem servidor.
A predefinição é |
ALL_TRAFFIC
|
Controlos operacionais
Pode ativar o registo e as funcionalidades do nível premium do Security Command Center, como as estatísticas de estado de segurança e a deteção de ameaças. Estes controlos ajudam a fazer o seguinte:
- Monitorize o acesso aos dados.
- Certifique-se de que a auditoria adequada está implementada.
- Apoiar as operações de segurança e as capacidades de gestão de incidentes da sua organização.
Registo
Para ajudar a cumprir os requisitos de auditoria e obter estatísticas sobre os seus projetos, pode configurar o Google Cloud Observability com registos de dados para os serviços que quer acompanhar. Implemente o Cloud Logging nos projetos antes de aplicar o código Terraform para garantir que o esquema pode configurar o registo para a firewall, o equilibrador de carga e a rede VPC.
Depois de implementar o esquema, recomendamos que configure o seguinte:
- Crie um sink de registo agregado em todos os projetos.
- Adicione CMEKs ao seu destino de registo.
Para todos os serviços nos projetos, certifique-se de que os seus registos incluem informações sobre gravações de dados e acesso administrativo. Para mais informações sobre as práticas recomendadas de registo, consulte o artigo Controlos de deteção.
Monitorização e alertas
Depois de implementar o esquema, pode configurar alertas para notificar o seu centro de operações de segurança (SOC) de que ocorreu um evento de segurança. Por exemplo, pode usar alertas para informar os seus analistas de segurança quando uma autorização foi alterada numa função do IAM. Para mais informações sobre a configuração de alertas do Security Command Center, consulte o artigo Configurar notificações de deteção.
O painel de controlo de monitorização das funções do Cloud Run ajuda a monitorizar o desempenho e o estado das suas funções do Cloud Run. Oferece uma variedade de métricas e registos que pode usar para identificar e resolver problemas. O painel de controlo também inclui várias funcionalidades que podem ajudar a melhorar o desempenho das suas funções, como a capacidade de definir alertas e quotas.
Para mais informações, consulte o artigo Monitorizar funções do Cloud Run.
Para exportar alertas, consulte os seguintes documentos:
Depuração e resolução de problemas
Pode executar testes de conetividade para ajudar a depurar problemas de configuração de rede entre as funções do Cloud Run e os recursos na sua sub-rede. Os testes de conetividade simulam o caminho esperado de um pacote e fornecem detalhes sobre a conetividade, incluindo a análise de conetividade de recurso para recurso.
Os testes de conectividade não estão ativados pelo código do Terraform. Tem de os configurar separadamente. Para mais informações, consulte o artigo Crie e execute testes de conetividade.
Modos de implementação do Terraform
A tabela seguinte descreve as formas como pode implementar este projeto, e que módulos do Terraform se aplicam a cada modo de implementação.
| Modo de implementação | Módulos do Terraform |
|---|---|
Implemente este projeto após implementar o projeto de bases empresariais (recomendado). Esta opção implementa os recursos para este projeto no mesmo perímetro do VPC Service Controls que é usado pelo projeto de bases empresariais. Para mais informações, consulte o artigo Como personalizar a Foundation v3.0.0 para a implementação de funções seguras do Cloud Run. Esta opção também usa o projeto de segredos que criou quando implementou o esquema de base empresarial. |
Use estes módulos do Terraform: |
Instale este projeto sem instalar o projeto de bases de segurança. Esta opção requer que crie um perímetro dos VPC Service Controls. |
Use estes módulos do Terraform:
|
Reunir tudo num só lugar
Para implementar a arquitetura descrita neste documento, faça o seguinte:
- Reveja o ficheiro README para o projeto para garantir que cumpre todos os pré-requisitos.
- No seu ambiente de teste, para ver o esquema em ação, implemente um dos exemplos.
Estes exemplos correspondem aos exemplos de arquitetura descritos em Arquitetura.
Como parte do processo de testes, considere fazer o seguinte:
- Use o Security Command Center para analisar os projetos em função dos requisitos de conformidade comuns.
- Substitua a aplicação de exemplo por uma aplicação real (por exemplo, 1) e execute um cenário de implementação típico.
- Trabalhe com as equipas de engenharia e operações de aplicações na sua empresa para testar o respetivo acesso aos projetos e verificar se conseguem interagir com a solução da forma esperada.
- Implemente o projeto no seu ambiente.
O que se segue?
- Reveja o Google Cloud projeto de base empresarial para um ambiente seguro de base.
- Para ver os detalhes do projeto, leia o README da configuração do Terraform.
- Para implementar uma aplicação sem servidor através do Cloud Run, consulte o artigo Implemente uma arquitetura sem servidor segura através do Cloud Run.