Decida a segurança da sua zona de destino Google Cloud

Last reviewed 2025-06-07 UTC

Este documento apresenta decisões de segurança importantes e opções recomendadas a ter em consideração ao conceber uma Google Cloud zona de destino. Faz parte de uma série sobre as zonas de destino, e destina-se a especialistas em segurança, CISOs e arquitetos que querem compreender as decisões que têm de tomar ao conceber uma zona de destino no Google Cloud.

Neste documento, pressupõe-se que uma equipa central, como a equipa de segurança ou a equipa da plataforma, aplica estes controlos de segurança da zona de destino. Uma vez que o foco deste documento é a conceção de ambientes à escala empresarial, algumas estratégias que descreve podem ser menos relevantes para equipas pequenas.

Pontos de decisão para proteger a sua Google Cloud zona de destino

Para escolher o melhor design de segurança para a sua organização, tem de tomar as seguintes decisões:

Diagrama de arquitetura

A arquitetura de exemplo descrita neste documento usa padrões de conceção de segurança comuns. Os seus controlos específicos podem variar com base em fatores como o setor da sua organização, as cargas de trabalho de destino ou os requisitos de conformidade adicionais. O diagrama seguinte mostra a arquitetura dos controlos de segurança que aplica na sua zona de destino quando segue as recomendações neste documento.

Exemplo de arquitetura de controlos de segurança.

O diagrama anterior mostra o seguinte:

  • A gestão de chaves de contas de serviço ajuda a mitigar o risco de credenciais de contas de serviço de longa duração.
  • Os VPC Service Controls definem um perímetro em torno de recursos sensíveis que ajuda a restringir o acesso a partir do exterior do perímetro.
  • O Security Command Center monitoriza o ambiente em busca de configurações inseguras e ameaças.
  • Um sink de registo centralizado recolhe registos de auditoria de todos os projetos.
  • A encriptação em repouso predefinida da Google encripta todos os dados que persistem no disco.
  • A encriptação predefinida da Google em trânsito aplica-se aos caminhos de rede da camada 3 e da camada 4.
  • A Transparência de acesso oferece-lhe visibilidade e controlo sobre a forma como a Google pode aceder ao seu ambiente.

Decida como limitar as credenciais persistentes para contas de serviço

As contas de serviço são identidades de máquinas que usa para conceder funções do IAM a cargas de trabalho e permitir que a carga de trabalho aceda às Google Cloud APIs. Uma chave de conta de serviço é uma credencial persistente e todas as credenciais persistentes são potencialmente de alto risco. Não recomendamos que permita que os programadores criem chaves de contas de serviço livremente.

Por exemplo, se um programador confirmar acidentalmente a chave da conta de serviço num repositório Git público, um atacante externo pode autenticar-se através dessas credenciais. Como outro exemplo, se a chave da conta de serviço estiver armazenada num repositório interno, um insider malicioso que consiga ler a chave pode usar as credenciais para aumentar os seus próprios privilégios. Google Cloud

Para definir uma estratégia de gestão destas credenciais persistentes, tem de fornecer alternativas viáveis, limitar a proliferação de credenciais persistentes e gerir a forma como são usadas. Para informações sobre alternativas às chaves de contas de serviço, consulte o artigo Escolha o método de autenticação adequado para o seu exemplo de utilização.

As secções seguintes descrevem as opções para limitar as credenciais persistentes. Recomendamos a opção 1 para a maioria dos exemplos de utilização. As outras opções abordadas nas secções seguintes são alternativas que pode considerar se a opção 1 não se aplicar à sua organização específica.

Todas as organizações criadas após 23 de maio de 2024 têm Google Cloud restrições de referência de segurança aplicadas quando o recurso da organização é criado pela primeira vez. Esta alteração torna a opção 1 a opção predefinida.

Opção 1: restrinja a utilização de chaves de contas de serviço persistentes

Recomendamos que não permita que nenhum utilizador transfira chaves de contas de serviço, uma vez que as chaves expostas são um vetor de ataque comum. Restringir a utilização de chaves de contas de serviço persistentes é uma opção que pode ajudar a reduzir o risco e a sobrecarga da gestão manual de chaves de contas de serviço.

Para implementar esta opção, considere o seguinte:

Evite esta opção quando já tiver ferramentas implementadas para gerar credenciais da API de curta duração para contas de serviço.

Para mais informações, consulte o seguinte:

Opção 2: use ferramentas de gestão de acesso adicionais para gerar credenciais de curta duração

Em alternativa a restringir a utilização de chaves de contas de serviço persistentes, pode gerar credenciais de curta duração para contas de serviço. As credenciais de curta duração criam menos risco do que as credenciais persistentes, como as chaves de contas de serviço. Pode desenvolver as suas próprias ferramentas ou usar soluções de terceiros, como o Hashicorp Vault, para gerar credenciais de acesso de curta duração.

Use esta opção quando já tiver investido numa ferramenta de terceiros para gerar credenciais de curta duração para o controlo de acesso ou tiver orçamento e capacidade suficientes para desenvolver a sua própria solução.

Evite usar esta opção quando não tiver ferramentas existentes para conceder credenciais de curta duração ou não tiver capacidade para criar a sua própria solução.

Para mais informações, consulte o artigo Crie credenciais de conta de serviço de curta duração.

Decida como mitigar a exfiltração de dados através das APIs Google

As APIs Google têm pontos finais públicos que estão disponíveis para todos os clientes. Embora todos os recursos da API no seu Google Cloud ambiente estejam sujeitos a controlos de acesso do IAM, existe o risco de os dados poderem ser acedidos através de credenciais roubadas, exfiltrados por intervenientes internos maliciosos ou código comprometido, ou expostos através de uma política do IAM configurada incorretamente.

Os VPC Service Controls são uma solução que aborda estes riscos. No entanto, os VPC Service Controls também introduzem complexidade no seu modelo de acesso, pelo que tem de conceber os VPC Service Controls para satisfazer o seu ambiente e exemplo de utilização únicos.

As secções seguintes descrevem as opções para mitigar a exfiltração de dados através das APIs Google. Recomendamos a opção 1 para a maioria dos exemplos de utilização. As outras opções abordadas nas secções seguintes são alternativas que pode considerar se a opção 1 não se aplicar ao seu exemplo de utilização específico.

Opção 1: configure os VPC Service Controls de forma abrangente no seu ambiente

Recomendamos que crie o seu ambiente dentro de um ou mais perímetros do VPC Service Controls que restrinjam todas as APIs suportadas. Configure exceções ao perímetro com níveis de acesso ou políticas de entrada para que os programadores possam aceder aos serviços de que precisam, incluindo o acesso à consola quando necessário.

Use esta opção quando o seguinte for verdadeiro:

  • Os serviços que pretende usar suportam os VPC Service Controls e as suas cargas de trabalho não requerem acesso ilimitado à Internet.
  • Armazena dados confidenciais em Google Cloud que podem representar uma perda significativa se forem roubados.
  • Tem atributos consistentes para o acesso de programadores que podem ser configurados como exceções ao perímetro, o que permite aos utilizadores acederem aos dados de que precisam.

Evite esta opção quando as suas cargas de trabalho exigirem acesso ilimitado à Internet ou serviços que não sejam suportados pelos VPC Service Controls.

Para mais informações, consulte o seguinte:

Opção 2: configure o VPC Service Controls para um subconjunto do seu ambiente

Em vez de configurar os VPC Service Controls de forma abrangente no seu ambiente, pode configurá-los apenas no subconjunto de projetos que contêm dados sensíveis e cargas de trabalho apenas internas. Esta opção permite-lhe usar um design e uma operação mais simples para a maioria dos projetos, ao mesmo tempo que dá prioridade à proteção de dados para projetos com dados confidenciais.

Por exemplo, pode considerar esta alternativa quando um número limitado de projetos contém conjuntos de dados do BigQuery com dados confidenciais. Pode definir um perímetro de serviço apenas em torno destes projetos e definir regras de entrada e saída para permitir exceções restritas para os analistas que precisam de usar estes conjuntos de dados.

Por outro lado, numa aplicação com uma arquitetura de três camadas, alguns componentes podem estar fora do perímetro. A camada de apresentação que permite a entrada de tráfego do utilizador pode ser um projeto fora do perímetro, e a camada de aplicação e a camada de dados que contêm dados confidenciais podem ser projetos separados dentro do perímetro do serviço. Define regras de entrada e saída para o perímetro, de modo que os níveis possam comunicar entre si no perímetro com acesso detalhado.

Use esta opção quando o seguinte for verdadeiro:

  • Apenas projetos limitados e bem definidos contêm dados confidenciais. Outros projetos contêm dados de menor risco.
  • Algumas cargas de trabalho são apenas internas, mas outras requerem acesso público à Internet ou têm dependências de serviços que não são suportados pelos VPC Service Controls.
  • A configuração dos VPC Service Controls em todos os projetos cria uma sobrecarga excessiva ou requer demasiadas soluções alternativas

Evite esta opção quando muitos projetos puderem conter potencialmente dados confidenciais.

Para mais informações, consulte o artigo Práticas recomendadas para ativar o VPC Service Controls.

Opção 3: não configure o VPC Service Controls

Em alternativa à configuração dos VPC Service Controls de forma abrangente no seu ambiente, pode optar por não usar os VPC Service Controls, especialmente se a sobrecarga operacional for superior ao valor dos VPC Service Controls.

Por exemplo, a sua organização pode não ter um padrão consistente de acesso de programadores que possa formar a base de uma política de entrada. Talvez as suas operações de TI sejam subcontratadas a vários terceiros, pelo que os programadores não têm dispositivos geridos nem acesso a partir de endereços IP consistentes. Neste cenário, pode não conseguir definir regras de entrada para permitir exceções ao perímetro que os programadores precisam para concluir as respetivas operações diárias.

Use esta opção quando:

  • Usar serviços que não suportam os VPC Service Controls.
  • As cargas de trabalho estão viradas para a Internet e não contêm dados confidenciais.
  • Não tem atributos consistentes de acesso de programador, como dispositivos geridos ou intervalos de IP conhecidos.

Evite esta opção quando tiver dados confidenciais no seu ambiente Google Cloud.

Decida como monitorizar continuamente as ameaças e as configurações não seguras

A adoção de serviços na nuvem introduz novos desafios e ameaças em comparação com a utilização de serviços localizados no local. As suas ferramentas existentes que monitorizam servidores de longa duração podem não ser adequadas para o dimensionamento automático ou os serviços efémeros e podem não monitorizar recursos sem servidor. Por isso, deve avaliar as ferramentas de segurança que funcionam com a gama completa de serviços na nuvem que pode adotar. Também deve monitorizar continuamente as normas da nuvem, como a referência CIS para o Google Cloud.

As secções seguintes descrevem as opções de monitorização contínua. Recomendamos a opção 1 para a maioria dos exemplos de utilização. As outras opções abordadas nas secções seguintes são alternativas que pode considerar se a opção 1 não se aplicar ao seu exemplo de utilização específico.

Opção 1: use o Security Command Center

Recomendamos que ative o Security Command Center ao nível da organização, o que ajuda a reforçar a sua postura de segurança através das seguintes ações:

  • Avaliar a sua superfície de ataque de segurança e dados
  • Fornecer inventário de recursos e descoberta
  • Identificar configurações incorretas, vulnerabilidades e ameaças
  • Ajudar a mitigar e corrigir riscos

Quando ativa o Security Command Center no início da criação da zona de destino, a equipa de segurança da sua organização tem visibilidade quase em tempo real das configurações não seguras, das ameaças e das opções de remediação. Esta visibilidade ajuda a sua equipa de segurança a avaliar se a zona de destino cumpre os respetivos requisitos e se está pronta para os programadores começarem a implementar aplicações.

Use esta opção quando o seguinte for verdadeiro:

  • Quer uma ferramenta de gestão da postura de segurança e deteção de ameaças que esteja integrada com todos os Google Cloud serviços sem esforço de integração adicional.
  • Quer usar a mesma inteligência contra ameaças, aprendizagem automática e outros métodos avançados que a Google usa para proteger os seus próprios serviços.
  • O seu centro de operações de segurança (SOC) existente não tem as competências nem a capacidade para gerar estatísticas de ameaças a partir de um grande volume de registos na nuvem.

Evite esta opção quando as suas ferramentas de segurança existentes puderem resolver totalmente os recursos de nuvem efêmeros ou sem servidores, monitorizar configurações não seguras e identificar ameaças em grande escala num ambiente de nuvem.

Opção 2: use as suas ferramentas de segurança existentes para a gestão da postura de segurança na nuvem e a deteção de ameaças

Como opção alternativa à utilização do Security Command Center, pode considerar outras ferramentas de gestão da postura de segurança na nuvem. Existem várias ferramentas de terceiros com funções semelhantes às do Security Command Center, e pode já ter investido em ferramentas nativas da nuvem focadas em ambientes de várias nuvens.

Também pode usar o Security Command Center e ferramentas de terceiros em conjunto. Por exemplo, pode carregar as notificações de deteção do Security Command Center para outra ferramenta ou adicionar um serviço de segurança de terceiros ao painel de controlo do Security Command Center. Como outro exemplo, pode ter um requisito para armazenar registos num sistema SIEM existente para que a equipa do SOC os analise em busca de ameaças. Pode configurar o seu SIEM existente para carregar apenas as notificações de deteção produzidas pelo Security Command Center, em vez de carregar um grande volume de registos e esperar que uma equipa do SOC analise os registos não processados para obter estatísticas.

Use esta opção quando as suas ferramentas de segurança existentes puderem resolver totalmente recursos de nuvem efêmeros ou sem servidor, monitorizar configurações não seguras e identificar ameaças em grande escala num ambiente de nuvem.

Evite esta opção quando o seguinte for verdadeiro:

  • O seu SOC existente não tem as competências nem a capacidade para gerar estatísticas de ameaças a partir do grande volume de registos na nuvem.
  • A integração de várias ferramentas de terceiros com vários Google Cloud serviços introduz mais complexidade do que valor.

Para mais informações, consulte o seguinte:

Decida como agregar centralmente os registos necessários

A maioria dos registos de auditoria é armazenada no Google Cloud projeto que os produziu. À medida que o seu ambiente cresce, pode ser insustentável para um auditor verificar os registos em cada projeto individual. Por conseguinte, tem de tomar uma decisão sobre como os registos vão ser centralizados e agregados para ajudar a sua auditoria interna e operações de segurança.

As secções seguintes descrevem as opções de agregação de registos. Recomendamos a opção 1 para a maioria dos exemplos de utilização. As outras opções abordadas nas secções seguintes são alternativas que pode considerar se a opção 1 não se aplicar ao seu exemplo de utilização específico.

Opção 1: retenha registos no Google Cloud através de destinos de registos agregados

Recomendamos que configure um destino de registo centralizado ao nível da organização para registos de auditoria e outros registos exigidos pela sua equipa de segurança. Pode consultar a ferramenta de âmbito dos registos para identificar os registos que a sua equipa de segurança requer e se estes tipos de registos requerem ativação explícita.

Por exemplo, a equipa de segurança espera um registo central de todos os recursos que os seus utilizadores criam para que a equipa de segurança possa monitorizar e investigar alterações suspeitas. A equipa de segurança também requer um registo imutável do acesso aos dados para determinadas cargas de trabalho altamente confidenciais. Por conseguinte, a equipa de segurança configura um sink de registo para agregar os registos de auditoria da atividade do administrador de todos os projetos num contentor do Log Analytics num projeto central que pode ver para investigações improvisadas. Em seguida, configuram um segundo sink de registo para registos de auditoria de acesso a dados de projetos com cargas de trabalho confidenciais num contentor do Cloud Storage para retenção a longo prazo.

Use esta opção quando o seguinte for verdadeiro:

  • A sua equipa de segurança espera um registo central de todos os registos de auditoria ou outros tipos de registos específicos.
  • A sua equipa de segurança tem de armazenar registos num ambiente com acesso restrito, fora do controlo da carga de trabalho ou das equipas que produziram o registo.

Evite esta opção quando o seguinte for verdadeiro:

  • A sua organização não tem um requisito central para registos de auditoria consistentes em todas as cargas de trabalho.
  • Os proprietários de projetos individuais têm total responsabilidade pela gestão dos respetivos registos de auditoria.

Para mais informações, consulte o seguinte:

Opção 2: exporte os registos de auditoria necessários para armazenamento fora do Google Cloud

Como alternativa ao armazenamento de registos apenas Google Cloud , considere exportar registos de auditoria para fora do Google Cloud. Depois de centralizar os tipos de registos necessários num destino de registos agregado no Google Cloud, carregue o conteúdo desse destino para outra plataforma fora doGoogle Cloud para armazenar e analisar registos.

Por exemplo, pode usar um SIEM de terceiros para agregar e analisar registos de auditoria em vários fornecedores de nuvem. Esta ferramenta tem capacidades suficientes para trabalhar com recursos na nuvem sem servidor, e a sua equipa do SOC tem as competências e a capacidade de gerar estatísticas a partir deste grande volume de registos.

Esta opção pode ser potencialmente muito dispendiosa devido ao custo de saída da rede na Google Cloud, bem como ao custo de armazenamento e à capacidade no outro ambiente. Em vez de exportar todos os registos disponíveis, recomendamos que seja seletivo quanto aos registos necessários no ambiente externo.

Use esta opção quando tiver um requisito para armazenar registos de todos os ambientes e fornecedores de nuvem numa única localização central.

Evite esta opção quando o seguinte for verdadeiro:

  • Os seus sistemas existentes não têm capacidade nem orçamento para carregar um grande volume de registos da nuvem adicionais.
  • Os seus sistemas existentes requerem esforços de integração para cada tipo e formato de registo.
  • Está a recolher registos sem um objetivo claro de como vão ser usados.

Para mais informações, consulte os controlos de deteção no projeto de base empresarial.

Decida como cumprir os requisitos de conformidade para a encriptação em repouso

Google Cloud Encripta automaticamente todo o seu conteúdo armazenado em repouso através de um ou mais mecanismos de encriptação. Consoante os seus requisitos de conformidade, pode ter a obrigação de gerir as chaves de encriptação.

As secções seguintes descrevem as opções de encriptação em repouso. Recomendamos a opção 1 para a maioria dos exemplos de utilização. As outras opções abordadas nas secções seguintes são alternativas que pode considerar se a opção 1 não se aplicar ao seu exemplo de utilização específico.

Opção 1: aceite a utilização da encriptação predefinida em repouso

A encriptação predefinida em repouso é suficiente para muitos exemplos de utilização que não têm requisitos de conformidade específicos relativamente à gestão de chaves de encriptação.

Por exemplo, a equipa de segurança de uma empresa de jogos online exige que todos os dados dos clientes sejam encriptados em repouso. Não têm requisitos regulamentares sobre a gestão de chaves e, após reverem a encriptação predefinida em repouso da Google, consideram que é um controlo suficiente para as suas necessidades.

Use esta opção quando o seguinte for verdadeiro:

  • Não tem requisitos específicos sobre como encriptar dados ou como as chaves de encriptação são geridas.
  • Prefere um serviço gerido ao custo e à sobrecarga operacional da gestão das suas próprias chaves de encriptação.

Evite esta opção quando tiver requisitos de conformidade para gerir as suas próprias chaves de encriptação.

Para mais informações, consulte o artigo Encriptação em repouso no Google Cloud.

Opção 2: faça a gestão das chaves de encriptação com o Cloud KMS

Além da encriptação predefinida em repouso, pode precisar de mais controlo sobre as chaves usadas para encriptar dados em repouso num Google Cloud projeto. O Cloud Key Management Service (Cloud KMS) oferece a capacidade de proteger os seus dados através de chaves de encriptação geridas pelo cliente (CMEK). Por exemplo, na indústria de serviços financeiros, pode ter um requisito para comunicar aos seus auditores externos como gere as suas próprias chaves de encriptação para dados confidenciais.

Para camadas de controlo adicionais, pode configurar módulos de segurança de hardware (HSM) ou a gestão de chaves externas (EKM) com a CMEK. As chaves de encriptação fornecidas pelo cliente (CSEK) não são recomendadas. Os cenários que eram abordados historicamente pelas CSEK são agora melhor abordados pelo Cloud External Key Manager (Cloud EKM), uma vez que o Cloud EKM tem suporte para mais serviços e uma maior disponibilidade.

Esta opção transfere alguma responsabilidade para os programadores de aplicações, que têm de seguir a gestão de chaves exigida pela sua equipa de segurança. A equipa de segurança pode aplicar o requisito bloqueando a criação de recursos não conformes com políticas da organização CMEK.

Use esta opção quando uma ou mais das seguintes afirmações for verdadeira:

  • Tem um requisito para gerir o ciclo de vida das suas próprias chaves.
  • Tem um requisito para gerar material de chaves criptográficas com um HSM certificado de Nível 3 da FIPS 140-2.
  • Tem um requisito para armazenar material de chaves criptográficas fora do Google Cloud usando o Cloud EKM.

Evite esta opção quando o seguinte for verdadeiro:

  • Não tem requisitos específicos sobre como encriptar dados ou como as chaves de encriptação são geridas.
  • Prefere um serviço gerido ao custo e à sobrecarga operacional da gestão das suas próprias chaves de encriptação.

Para mais informações, consulte o seguinte:

Opção 3: crie símbolos para os dados na camada da aplicação antes de os persistir no armazenamento

Além da encriptação predefinida disponibilizada pela Google, também pode desenvolver a sua própria solução para tokenizar dados antes de os armazenar no Google Cloud.

Por exemplo, um cientista de dados tem de analisar um conjunto de dados com informações de PII, mas não deve ter acesso para ler os dados não processados de alguns campos confidenciais. Para limitar o acesso de controlo a dados não processados, pode desenvolver um pipeline de carregamento com a proteção de dados confidenciais para carregar e tokenizar dados confidenciais e, em seguida, persistir os dados tokenizados no BigQuery.

A tokenização de dados não é um controlo que possa aplicar centralmente na zona de destino. Em alternativa, esta opção transfere a responsabilidade para os programadores de aplicações, que devem configurar a sua própria encriptação, ou para uma equipa de plataforma que desenvolve um pipeline de encriptação como um serviço partilhado para os programadores de aplicações usarem.

Use esta opção quando cargas de trabalho específicas tiverem dados altamente confidenciais que não devem ser usados na sua forma não processada.

Evite esta opção quando o Cloud KMS for suficiente para satisfazer os seus requisitos, conforme descrito em Gerir chaves de encriptação com o Cloud KMS. A movimentação de dados através de pipelines de encriptação e desencriptação adicionais aumenta o custo, a latência e a complexidade das aplicações.

Para mais informações, consulte a vista geral da proteção de dados confidenciais.

Decida como cumprir os requisitos de conformidade para a encriptação em trânsito

Google Cloud tem várias medidas de segurança para ajudar a garantir a autenticidade, a integridade e a privacidade dos dados em trânsito. Consoante os seus requisitos de segurança e conformidade, também pode configurar a encriptação da camada de aplicação.

As secções seguintes descrevem as opções de encriptação em trânsito. Recomendamos a opção 1 para a maioria dos exemplos de utilização. As outras opções abordadas nas secções seguintes são funcionalidades adicionais que pode considerar se a opção 1 for insuficiente para o seu exemplo de utilização específico.

Opção 1: avalie se a Google Cloud encriptação em trânsito é suficiente

Muitos padrões de tráfego na sua zona de destino beneficiam da Google Cloud encriptação em trânsito predefinida.

  • As ligações de VM para VM nas redes VPC e nas redes VPC com peering que se encontram na rede de produção da Google estão protegidas contra a integridade e encriptadas.

  • O tráfego da Internet para os serviços Google e o tráfego da sua rede VPC para os serviços Google terminam no front-end da Google (GFE). O GFE também faz o seguinte:

    • Fornece contramedidas contra ataques DDoS
    • Encaminha e equilibra o tráfego para os Google Cloud serviços

  • A infraestrutura da Google usa o ALTS para a autenticação, a integridade e a encriptação das ligações do GFE a um Google Cloud serviço e de umGoogle Cloud serviço para outro Google Cloud serviço.

Use esta opção quando a Google Cloud encriptação em trânsito predefinida for suficiente para as suas cargas de trabalho internas.

Adicione proteção adicional quando se verificar o seguinte:

  • Permite o tráfego de entrada da Internet na sua rede de VPC.
  • Está a estabelecer ligação ao seu ambiente nas instalações.

Nestes casos, deve configurar controlos adicionais, conforme abordado na Opção 2: Exigir que as aplicações configurem a encriptação da camada 7 em trânsito e na Opção 3: Configurar encriptação adicional no seu ambiente no local.

Para mais informações acerca da Google Cloud encriptação em trânsito predefinida, consulte o artigo Encriptação em trânsito no Google Cloud.

Opção 2: configure a encriptação adicional para o tráfego de ou para as suas aplicações de cliente

Além da encriptação predefinida em trânsito, pode configurar a encriptação da camada 7 para o tráfego de aplicações para as suas aplicações de cliente. Google Cloud fornece serviços geridos para suportar aplicações que precisam de encriptação da camada de aplicação em trânsito, incluindo certificados geridos e Cloud Service Mesh.

Por exemplo, um programador está a criar uma nova aplicação que aceita tráfego de entrada da Internet. Usam um balanceador de carga de aplicações externo com certificados SSL geridos pela Google para executar e dimensionar serviços atrás de um único endereço IP.

A encriptação da camada de aplicação não é um controlo que possa aplicar centralmente na zona de destino. Em alternativa, esta opção transfere alguma responsabilidade para os programadores de aplicações para configurar a encriptação em trânsito.

Use esta opção quando as aplicações exigirem tráfego HTTPS ou SSL entre componentes.

Considere permitir uma exceção limitada a esta opção quando estiver a migrar cargas de trabalho de computação para a nuvem que não exigiam anteriormente encriptação em trânsito para tráfego interno quando as aplicações estavam no local. Durante uma migração em grande escala, forçar a modernização das aplicações antigas antes da migração pode causar um atraso inaceitável no programa.

Para mais informações, consulte o seguinte:

Opção 3: configure a encriptação adicional no seu ambiente no local

Se precisar de uma ligação de Google Cloud ao seu ambiente no local, pode configurar o Cloud Interconnect, que configura uma ligação física direta entre Google Cloud e os seus centros de dados. Quando usa o Cloud Interconnect, o tráfego do seu ambiente no local para o Google Cloud não é encriptado em trânsito por predefinição. Por conseguinte, se estiver a usar o Cloud Interconnect, recomendamos que ative o MACsec para o Cloud Interconnect como parte da sua zona de destino.

Se usar a VPN de alta disponibilidade para ligar tráfego privado entre Google Cloud e os seus centros de dados, o tráfego usa a encriptação IPsec por predefinição.

Para mais informações, consulte o artigo Escolher um produto do Network Connectivity Center.

Decida que controlos adicionais são necessários para gerir o acesso do fornecedor de serviços na nuvem

A necessidade de auditar o acesso do fornecedor de serviços na nuvem (CSP) pode ser uma preocupação durante a adoção da nuvem.O Google Cloud oferece várias camadas de controlo que podem permitir a verificação do acesso do fornecedor de serviços na nuvem.

As secções seguintes descrevem as opções de gestão do acesso de CSPs. Recomendamos a opção 1 para a maioria dos exemplos de utilização. A outra opção abordada nas secções seguintes é uma funcionalidade adicional que pode considerar se a opção 1 for insuficiente para o seu exemplo de utilização específico.

Opção 1: ative os registos da Transparência de acesso

Os registos da Transparência de acesso registam as ações realizadas pelo Google Cloud pessoal no seu ambiente, como quando resolvem um pedido de apoio técnico.

Por exemplo, o seu programador comunica um problema de resolução de problemas ao apoio técnico ao cliente do Google Cloud e pede ao agente de apoio técnico que o ajude a resolver problemas no respetivo ambiente. É gerado um registo de transparência de acesso para mostrar as ações realizadas pelo pessoal de apoio técnico, incluindo o número do registo de apoio técnico que as justificou.

Use esta opção quando o seguinte for verdadeiro:

  • Tem um requisito para validar se o Google Cloud pessoal está a aceder ao seu conteúdo apenas por motivos empresariais válidos, como corrigir uma indisponibilidade ou responder aos seus pedidos de apoio técnico.
  • Tem um requisito de conformidade para acompanhar o acesso a dados confidenciais.

Opção 2: ative os registos da Transparência de acesso e a gestão do acesso de fornecedores

Se a sua empresa tiver um requisito de conformidade para conceder aprovação explícita antes de um CSP poder aceder ao seu ambiente, além da Opção 1, pode usar a Transparência de acesso com outros controlos que lhe permitam aprovar ou negar explicitamente o acesso aos seus dados.

A aprovação de acesso é uma solução manual que garante que o apoio ao cliente e a engenharia da Google precisam da sua aprovação explícita (por email ou através de um webhook) sempre que precisarem de aceder ao seu conteúdo.

As justificações de acesso a chaves são uma solução programática que adiciona um campo de justificação a quaisquer pedidos de chaves de encriptação configuradas com o EKM na nuvem.

Use esta opção quando o seguinte for verdadeiro:

  • Quer que uma equipa centralizada faça a gestão direta do acesso ao seu conteúdo por parte do pessoal da Google.
  • Para a aprovação de acesso, pode aceitar o risco de que a capacidade central de aprovar ou recusar cada pedido de acesso é mais importante do que a compensação operacional, que pode ser uma resolução mais lenta dos registos de apoio técnico.
  • Para as Justificações de acesso às chaves, a sua empresa já está a usar o Cloud External Key Manager como parte da sua estratégia de encriptação e quer o controlo programático sobre todos os tipos de acesso a dados encriptados (não apenas o acesso do pessoal da Google aos dados).

Evite esta opção quando o seguinte for verdadeiro:

  • O atraso operacional que pode ocorrer quando uma equipa central com autoridade de aprovação de acesso tem de responder é um risco inaceitável para as cargas de trabalho que requerem alta disponibilidade e uma resposta rápida do apoio ao cliente.

Para mais informações, consulte o seguinte:

Práticas recomendadas de segurança para Google Cloud zonas de destino

Além das decisões apresentadas neste documento, considere as seguintes práticas recomendadas de segurança:

O que se segue?