Escolher a segurança da zona de destino do Google Cloud

Last reviewed 2023-08-31 UTC

Neste documento, apresentamos decisões de segurança importantes e opções recomendadas a serem consideradas ao projetar uma zona de destino do Google Cloud. Ele faz parte de uma série sobre zonas de destino e é destinado a especialistas em segurança, CISOs e arquitetos que querem entender as decisões que precisam tomar ao projetar um zona de destino no Google Cloud.

Neste documento, presume-se que uma equipe central, como a equipe de segurança ou a equipe de plataforma, aplique esses controles de segurança da zona de destino. Como o foco deste documento é o design de ambientes de escala empresarial, algumas estratégias descritas podem ser menos relevantes para equipes pequenas.

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

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

Diagrama da arquitetura

A arquitetura de exemplo descrita neste documento usa padrões comuns de design de segurança. Os controles específicos podem variar de acordo com fatores como setor da empresa, cargas de trabalho pretendidas ou requisitos adicionais de conformidade. O diagrama a seguir mostra a arquitetura de controles de segurança aplicada na zona de destino ao seguir as recomendações neste documento.

Arquitetura de controles de segurança de exemplo.

O diagrama anterior mostra o seguinte:

  • O gerenciamento de chaves da conta de serviço ajuda a reduzir o risco de credenciais de conta de serviço de longa duração.
  • O VPC Service Controls define um perímetro em torno de recursos confidenciais que ajuda a restringir o acesso de fora do perímetro.
  • O Security Command Center monitora o ambiente em busca de configurações inseguras e ameaças.
  • Um coletor de registros centralizado coleta registros de auditoria de todos os projetos.
  • A criptografia em repouso padrão do Google criptografa todos os dados permanentes no disco.
  • A criptografia padrão do Google em trânsito se aplica aos caminhos de rede das camadas 3 e 4.
  • A transparência no acesso oferece visibilidade e controle sobre como o Google pode acessar o ambiente.

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

As contas de serviço são identidades de máquina que você usa para conceder papéis do IAM às cargas de trabalho e permitir que elas acessem as APIs do Google Cloud. Uma chave de conta de serviço é uma credencial permanente, e qualquer credencial persistente é potencialmente de alto risco. Não recomendamos que os desenvolvedores criem chaves de conta de serviço livremente.

Por exemplo, se um desenvolvedor confirmar acidentalmente a chave da conta de serviço em um repositório público do Git, um invasor externo poderá se autenticar usando essas credenciais. Em outro exemplo, se a chave da conta de serviço for armazenada em um repositório interno, uma pessoa mal-intencionada que possa ler a chave poderá usar as credenciais para escalonar os próprios privilégios do Google Cloud.

Para definir uma estratégia de gerenciamento dessas credenciais permanentes, forneça alternativas viáveis, limite a proliferação de credenciais persistentes e gerencie como elas são usadas. Para informações sobre alternativas a chaves de contas de serviço, consulte Escolher o melhor método de autenticação para seu caso de uso.

As seções a seguir descrevem as opções para limitar credenciais persistentes. Recomendamos a opção 1 na maioria dos casos de uso. As outras opções discutidas nas seções a seguir são alternativas que podem ser consideradas caso a opção 1 não se aplique à sua organização em específico.

Opção 1: restringir o uso de chaves de conta de serviço permanentes

Recomendamos não permitir que os usuários façam o download de chaves de contas de serviço, porque as chaves expostas são um vetor de ataque comum. Restringir o uso de chaves permanentes da conta de serviço é uma opção que pode ajudar a reduzir o risco e a sobrecarga do gerenciamento manual dessas chaves.

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

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

Para ver mais informações, consulte os seguintes tópicos:

Opção 2: usar mais ferramentas de gerenciamento de acesso para gerar credenciais de curta duração

Como alternativa para restringir o uso de chaves de conta de serviço permanentes, é possível gerar credenciais de curta duração para contas de serviço. Credenciais de curta duração são menos arriscadas que credenciais permanentes como as chaves da conta de serviço. É possível desenvolver suas próprias ferramentas ou usar soluções de terceiros, como o Hashicorp Vault, para gerar credenciais de acesso de curta duração.

Use essa opção quando você já tiver investido em uma ferramenta de terceiros para gerar credenciais de curta duração para controle de acesso ou tiver orçamento e capacidade suficientes para desenvolver sua própria solução.

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

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

Decida como reduzir a exfiltração de dados com as APIs do Google

As APIs do Google têm endpoints públicos disponíveis para todos os clientes. Todos os recursos da API no seu ambiente do Google Cloud estão sujeitos aos controles de acesso do IAM, mas é possível que os dados sejam acessados usando credenciais roubadas, exfiltradas por pessoas mal-intencionadas com informações privilegiadas, por código comprometido ou expostas devido a uma política de IAM configurada incorretamente.

O VPC Service Controls é uma solução para esses riscos. No entanto, o VPC Service Controls também introduz complexidade no modelo de acesso. Portanto, o VPC Service Controls precisa ser projetado para atender a cada ambiente e caso de uso.

As seções a seguir descrevem as opções para reduzir a exfiltração de dados usando as APIs do Google. Recomendamos a opção 1 para a maioria dos casos de uso. As outras opções das seções a seguir são alternativas que podem ser consideradas se a opção 1 não se aplicar ao seu caso de uso em específico.

Opção 1: configurar o VPC Service Controls em todo o ambiente

Recomendamos projetar o ambiente em um ou mais perímetros do VPC Service Controls que restrinjam todas as APIs compatíveis. Configure exceções ao perímetro com níveis de acesso ou políticas de entrada para que os desenvolvedores possam acessar os serviços necessários, incluindo o acesso ao console quando necessário.

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

  • Os serviços que você pretende usar são compatíveis com o VPC Service Controls, e as cargas de trabalho não exigem acesso irrestrito à Internet.
  • Você armazena dados sensíveis no Google Cloud que podem ser uma perda significativa se forem exfiltrados.
  • Você tem atributos consistentes para acesso de desenvolvedor que podem ser configurados como exceções ao perímetro, permitindo que os usuários acessem os dados de que precisam.

Evite essa opção quando as cargas de trabalho exigirem acesso irrestrito à Internet ou serviços que não são compatíveis com o VPC Service Controls.

Para ver mais informações, consulte os seguintes tópicos:

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

Em vez de configurar amplamente o VPC Service Controls em todo o ambiente, é possível configurá-lo apenas no subconjunto de projetos que contêm dados sensíveis e cargas de trabalho somente internas. Essa opção permite usar um design e operação mais simples para a maioria dos projetos, priorizando ainda a proteção de dados para projetos com dados sensíveis.

Por exemplo, considere essa alternativa quando um número limitado de projetos tiver conjuntos de dados do BigQuery com dados sensíveis. É possível definir um perímetro de serviço apenas para esses projetos e definir regras de entrada e saída que permitam exceções restritas para os analistas que precisam usar esses conjuntos de dados.

Em outro exemplo, em um aplicativo com arquitetura de três níveis, alguns componentes podem estar fora do perímetro. O nível de apresentação que permite a entrada do tráfego de usuários pode ser um projeto fora do perímetro, e o nível do aplicativo e o nível de dados que contêm dados sensíveis podem ser projetos separados dentro do perímetro de serviço. Você define regras de entrada e saída do perímetro para que os níveis possam se comunicar por todo o perímetro com acesso granular.

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

  • Somente projetos limitados e bem definidos contêm dados sensíveis. Outros projetos contêm dados de menor risco.
  • Algumas cargas de trabalho são apenas internas, mas outras exigem acesso público à Internet ou têm dependências em serviços não compatíveis com o VPC Service Controls.
  • Configurar o VPC Service Controls em todos os projetos cria muita sobrecarga ou requer muitas soluções alternativas

Evite essa opção quando muitos projetos contêm dados confidenciais.

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

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

Como alternativa à configuração ampla do VPC Service Controls em todo o ambiente, é possível escolher não usar o VPC Service Controls, especialmente se a sobrecarga operacional superar o valor do VPC Service Controles.

Por exemplo, sua organização pode não ter um padrão consistente de acesso do desenvolvedor que possa formar a base de uma política de entrada. Talvez suas operações de TI sejam terceirizadas para vários parceiros. Por isso, os desenvolvedores não têm dispositivos gerenciados nem acesso a endereços IP consistentes. Nesse cenário, talvez não seja possível definir regras de entrada para permitir as exceções ao perímetro de que os desenvolvedores precisam para concluir as operações diárias.

Use essa opção quando:

  • você usa serviços que não são compatíveis com o VPC Service Controls;
  • as cargas de trabalho são voltadas para a Internet e não contêm dados sensíveis;
  • você não tem atributos consistentes de acesso do desenvolvedor, como dispositivos gerenciados ou intervalos de IP conhecidos.

Evite essa opção quando você tiver dados confidenciais no ambiente do Google Cloud.

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

A adoção de serviços em nuvem apresenta novos desafios e ameaças em comparação com o uso de serviços no local. As ferramentas existentes que monitoram servidores de longa duração podem não ser adequadas para escalonamento automático ou serviços temporários e talvez nem monitorem recursos sem servidor. Portanto, avalie ferramentas de segurança que funcionem com todos os serviços de nuvem que você pretende adotar. Você também precisa monitorar continuamente padrões seguros da nuvem, como o CIS Benchmarks para o Google Cloud.

As seções a seguir descrevem as opções para monitoramento contínuo. Recomendamos a opção 1 na maioria dos casos de uso. As outras opções discutidas nas seções a seguir são alternativas que podem ser consideradas caso a opção 1 não se aplique ao seu caso de uso específico.

Opção 1: usar o Security Command Center Premium

Recomendamos que você ative o nível Premium do Security Command Center no nível da organização, o que ajuda a fortalecer sua postura de segurança fazendo o seguinte:

  • Avaliação da segurança e da superfície de ataque de dados.
  • Fornece inventário e descoberta de recursos.
  • Identifica configurações incorretas, vulnerabilidades e ameaças.
  • Ajuda a reduzir e corrigir riscos.

Quando você ativa o Security Command Center no início da criação da sua zona de destino, a equipe de segurança da sua organização tem visibilidade quase em tempo real sobre configurações não seguras, ameaças e opções de correção. Essa visibilidade ajuda a equipe de segurança a avaliar se a zona de destino atende aos requisitos e está pronta para os desenvolvedores começarem a implantar aplicativos.

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

  • Você quer uma ferramenta de gerenciamento de postura de segurança e detecção de ameaças integrada a todos os serviços do Google Cloud sem esforço extra de integração.
  • Você quer usar a mesma inteligência contra ameaças, machine learning e outros métodos avançados que o Google usa para proteger os próprios serviços.
  • Sua Central de Operações de Segurança (SOC) atual não tem as habilidades ou a capacidade de gerar insights sobre ameaças de um grande volume de registros da nuvem.

Evite essa opção quando as ferramentas de segurança atuais puderem lidar totalmente com os recursos de nuvem temporários ou sem servidor, monitorar as configurações não seguras e identificar as ameaças em escala em um ambiente de nuvem.

Opção 2: usar as ferramentas de segurança existentes para gerenciamento de postura de segurança na nuvem e detecção de ameaças

Como alternativa para Usar o nível Premium do Security Command Center, use outras ferramentas de gerenciamento de postura de segurança na nuvem. Existem diversas ferramentas de terceiros que têm funções semelhantes às do Security Command Center. Talvez você já tenha investido em ferramentas nativas da nuvem com foco em ambientes com várias nuvens.

Também é possível usar o Security Command Center e as ferramentas de terceiros juntos. Por exemplo, é possível ingerir as notificações de descoberta do Security Command Center em outra ferramenta ou adicionar um serviço de segurança de terceiros no painel do Security Command Center. Como outro exemplo, pode ser necessário armazenar registros em um sistema SIEM para que a equipe de SOC analise as ameaças. É possível configurar o SIEM existente para ingerir apenas as notificações de descoberta que o Security Command Center produz, em vez de ingerir um grande volume de registros e esperar que uma equipe de SOC analise os registros brutos para insights.

Use essa opção quando as ferramentas de segurança atuais puderem lidar totalmente com os recursos de nuvem temporários ou sem servidor, monitorar as configurações não seguras e identificar as ameaças em escala em um ambiente de nuvem.

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

  • O SOC existente não tem as habilidades ou a capacidade de gerar insights sobre ameaças do grande volume de registros da nuvem.
  • Integrar várias ferramentas de terceiros a vários serviços do Google Cloud traz mais complexidade do que valor.

Para ver mais informações, consulte os seguintes tópicos:

Decidir como agregar os registros necessários de forma centralizada

A maioria dos registros de auditoria é armazenada no projeto do Google Cloud que os produziu. À medida que o ambiente cresce, fica difícil para um auditor verificar os registros em cada projeto individual. Portanto, você precisa decidir como os registros serão centralizados e agregados para ajudar nas auditorias internas e nas operações de segurança.

As seções a seguir descrevem as opções para agregar registros. Recomendamos a opção 1 para a maioria dos casos de uso. As outras opções discutidas nas seções a seguir são alternativas que podem ser consideradas caso a opção 1 não se aplique ao seu caso de uso específico.

Opção 1: reter registros no Google Cloud usando coletores de registros agregados

Recomendamos que você configure um coletor de registros centralizado de toda a organização para registros de auditoria e outros registros exigidos pela equipe de segurança. Consulte a referência da ferramenta de escopo de registros para identificar os registros que sua equipe de segurança exige e se esses tipos de registro exigem ativação explícita.

Por exemplo, a equipe de segurança espera um registro central dos recursos criados pelos usuários, que a equipe de segurança usa para monitorar e investigar mudanças suspeitas. A equipe de segurança também precisa de um registro imutável do acesso a dados para determinadas cargas de trabalho altamente confidenciais. Portanto, a equipe de segurança configura um coletor de registros para agregar registros de auditoria de atividade do administrador de todos os projetos em um bucket de análise de registros m um projeto central que pode ser visualizado em investigações não programadas. Em seguida, essa equipe configura um segundo coletor de registros de auditoria de acesso a dados de projetos de cargas de trabalho confidenciais em um bucket do Cloud Storage, para retenção de longo prazo.

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

  • A equipe de segurança espera um registro central de todos os registros de auditoria ou de outros tipos específicos.
  • A equipe de segurança precisa armazenar registros em um ambiente com acesso restrito, fora do controle da carga de trabalho ou das equipes que produziram o registro.

Evite essa opção quando: - Sua organização não tiver um requisito central para registros de auditoria consistentes em todas as cargas de trabalho. - Os proprietários individuais de projetos têm total responsabilidade de gerenciar os próprios registros de auditoria.

Para ver mais informações, consulte os seguintes tópicos:

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

Como alternativa ao modelo de armazenar registros apenas no Google Cloud, considere exportar registros de auditoria para fora do Google Cloud. Depois de centralizar os tipos de registros necessários em um coletor de registros agregado no Google Cloud, faça a ingestão do conteúdo desse coletor em outra plataforma fora do Google Cloud para armazenar e analisar os registros.

Por exemplo, é possível usar um SIEM de terceiros para agregar e analisar registros de auditoria em vários provedores de nuvem. Essa ferramenta tem recursos suficientes para trabalhar com recursos de nuvem sem servidor, e a equipe de SOC tem as habilidades e a capacidade de gerar insights desse grande volume de registros.

Essa opção pode ser muito cara devido ao custo de saída da rede no Google Cloud, bem como ao custo e à capacidade de armazenamento no outro ambiente. Em vez de exportar todos os registros disponíveis, recomendamos selecionar quais registros são necessários no ambiente externo.

Use essa opção quando você precisar armazenar registros de todos os ambientes e provedores de nuvem em um único local central.

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

  • Os sistemas atuais não têm a capacidade ou o orçamento para ingerir um grande volume de outros registros de nuvem.
  • Os sistemas atuais exigem esforços de integração para cada tipo e formato de registro.
  • Você está coletando registros sem uma meta clara de como eles serão usados.

Para ver mais informações, consulte os seguintes tópicos:

Decidir como atender aos requisitos regulatórios da criptografia em repouso

O Google Cloud criptografa automaticamente todo o conteúdo armazenado em repouso usando um ou mais mecanismos de criptografia. Dependendo dos requisitos de conformidade, talvez você tenha a obrigação de gerenciar as chaves de criptografia.

As seções a seguir descrevem as opções de criptografia em repouso. Recomendamos a opção 1 na maioria dos casos de uso. As outras opções discutidas nas seções a seguir são alternativas que podem ser consideradas caso a opção 1 não se aplique ao seu caso de uso específico.

Opção 1: aceitar o uso da criptografia padrão em repouso

A criptografia padrão em repouso é suficiente para muitos casos de uso que não têm requisitos de conformidade específicos relacionados ao gerenciamento de chaves de criptografia.

Por exemplo, a equipe de segurança de uma empresa de jogos on-line exige que todos os dados do cliente sejam criptografados em repouso. Eles não têm requisitos regulatórios sobre o gerenciamento de chaves e, após analisar a criptografia em repouso padrão do Google, ficam satisfeitos porque é um controle suficiente para as necessidades deles.

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

  • Você não tem requisitos específicos sobre como criptografar dados ou como chaves de criptografia são gerenciadas.
  • Você prefere um serviço gerenciado em vez do custo e da sobrecarga operacional de gerenciar suas próprias chaves de criptografia.

Evite essa opção quando você tiver requisitos de conformidade para gerenciar suas chaves de criptografia.

Para mais informações, consulte Criptografia em repouso no Google Cloud.

Opção 2: gerenciar chaves de criptografia usando o Cloud KMS

Além da criptografia padrão em repouso, você pode precisar de mais controle sobre as chaves usadas para criptografar dados em repouso em um projeto do Google Cloud. O Cloud Key Management Service (Cloud KMS) oferece a capacidade de proteger seus dados usando chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês). Por exemplo, no setor de serviços financeiros, pode ser necessário informar aos auditores externos como você gerencia suas próprias chaves de criptografia de dados confidenciais.

Para ter mais camadas de controle, configure módulos de segurança de hardware (HSM, na sigla em inglês) ou gerenciamento de chaves externas (EKM, na sigla em inglês) com CMEK. Não são recomendadas as chaves de criptografia fornecidas pelo cliente (CSEK). Os cenários que antes eram abordados pelas CSEKs agora são mais bem abordados pelo Cloud External Key Manager (Cloud EKM), já que ele oferece suporte a mais serviços e maior disponibilidade.

Essa opção transfere alguma responsabilidade para os desenvolvedores de aplicativos seguirem o gerenciamento de chaves que a equipe de segurança exige. A equipe de segurança pode aplicar o requisito bloqueando a criação de recursos que não estão em conformidade com as políticas da organização de CMEK.

Use essa opção quando uma ou mais das seguintes condições se aplicarem:

  • Você precisa gerenciar o ciclo de vida das suas próprias chaves.
  • Você precisa gerar um material de chave criptográfica com um HSM certificado FIPS 140-2 de nível 3 (em inglês).
  • Você precisa armazenar material de chave criptográfica fora do Google Cloud usando o Cloud EKM.

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

  • Você não tem requisitos específicos para a criptografia de dados ou o gerenciamento das chaves de criptografia.
  • Você prefere um serviço gerenciado em vez do custo e da sobrecarga operacional de gerenciar suas próprias chaves de criptografia.

Para ver mais informações, consulte os seguintes tópicos:

Opção 3: tokenizar os dados na camada do aplicativo antes de torná-los permanentes no armazenamento

Além da criptografia padrão fornecida pelo Google, também é possível desenvolver sua própria solução para tokenizar dados antes de armazená-los no Google Cloud.

Por exemplo, um cientista de dados precisa analisar um conjunto de dados com informações de identificação pessoal, mas não pode ter acesso para ler os dados brutos de alguns campos confidenciais. Para limitar o acesso de controle aos dados brutos, é possível desenvolver um pipeline de ingestão com a proteção de dados sensíveis para ingerir e tokenizar dados confidenciais e, em seguida, manter os dados tokenizados no BigQuery

A tokenização de dados não é um controle que pode ser aplicado de maneira centralizada na zona de destino. Em vez disso, essa opção passa a responsabilidade para os desenvolvedores de aplicativos configurarem a própria criptografia ou para uma equipe de plataforma que desenvolve um pipeline de criptografia como um serviço compartilhado para desenvolvedores de aplicativos usarem.

Use essa opção quando cargas de trabalho específicas tiverem dados altamente sensíveis que não podem ser usados na forma bruta.

Evite essa opção quando o Cloud KMS for suficiente para atender aos requisitos, conforme descrito em Gerenciar chaves de criptografia usando o Cloud KMS. A movimentação de dados por outros pipelines de criptografia e descriptografia aumenta o custo, a latência e a complexidade dos aplicativos.

Para ver mais informações, consulte:

Decidir como atender aos requisitos regulamentares da criptografia em trânsito

O Google Cloud tem várias medidas de segurança para ajudar a garantir a autenticidade, integridade e privacidade dos dados em trânsito. Dependendo dos requisitos de segurança e conformidade, também é possível configurar a criptografia da camada de aplicativos.

As seções a seguir descrevem as opções de criptografia em trânsito. Recomendamos a opção 1 na maioria dos casos de uso. A outra opção discutida nas seções a seguir é um recurso extra que pode ser considerado caso a opção 1 não seja suficiente para seu caso de uso específico.

Opção 1: avaliar se a criptografia padrão em trânsito é suficiente

Muitos padrões de tráfego se beneficiam da criptografia padrão do Google em trânsito sem a necessidade de configuração adicional. Todo o tráfego entre VMs em uma rede VPC e em redes VPC conectadas é criptografado na camada 3 ou 4. O tráfego da Internet para os serviços do Google termina no Google Front End (GFE). O GFE também realiza as ações a seguir:

  • Encerra o tráfego de entrada HTTP(S), TCP e de proxy TLS
  • Oferece medidas contra ataques de DDoS.
  • Encaminha e faz o balanceador de carga do tráfego para os serviços do Google Cloud

Por exemplo, se você estiver projetando um aplicativo interno sem servidor usando as APIs do Google, os caminhos de rede dos serviços vão usar automaticamente a criptografia padrão em trânsito. Não é necessário configurar mais criptografia nos controles de trânsito para o tráfego ser criptografado.

Use essa opção quando a criptografia padrão do Google em trânsito for suficiente para as cargas de trabalho internas.

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

  • Você precisa de criptografia para todo o tráfego no Cloud Interconnect.
  • Você permite o tráfego de entrada da Internet na sua rede VPC.
  • Você precisa da criptografia da camada 7 em trânsito entre todos os recursos de computação internos.

Nesses casos, é preciso configurar controles adicionais, conforme discutido na Opção 2: exigir que os aplicativos configurem a criptografia da camada 7 em trânsito. Para mais informações, consulte Criptografia em trânsito no Google Cloud.

Opção 2: exigir que os aplicativos configurem a criptografia da camada 7 em trânsito

Além da criptografia padrão em trânsito, é possível configurar a criptografia da camada 7 para o tráfego do aplicativo. O Google Cloud oferece serviços gerenciados para suportar aplicativos que precisam de criptografia da camada de aplicativos em trânsito, incluindo certificados gerenciados, o Cloud Service Mesh e o Cloud Service Mesh.

Por exemplo, um desenvolvedor está criando um novo aplicativo que aceita tráfego de entrada da Internet. Ele usa um balanceador de carga de aplicativo externo com certificados SSL gerenciados pelo Google para executar e escalonar serviços por trás de um único endereço IP.

A criptografia da camada de aplicativos não é um controle que pode ser aplicado de maneira centralizada na zona de destino. Em vez disso, essa opção transfere alguma responsabilidade para os desenvolvedores de aplicativos, que podem configurar a criptografia em trânsito.

Use essa opção quando os aplicativos exigirem tráfego HTTP(S) ou SSL entre componentes.

Considere permitir uma exceção limitada a essa opção ao migrar cargas de trabalho de computação para a nuvem que não exigem criptografia em trânsito para tráfego interno quando os aplicativos estavam no local. Durante uma migração em grande escala, forçar a modernização de aplicativos legados antes da migração pode causar um atraso inaceitável no programa.

Para ver mais informações, consulte os seguintes tópicos:

Decidir quais controles adicionais são necessários para gerenciar o acesso do provedor de serviços em nuvem

A necessidade de auditar o acesso do provedor de serviços de nuvem pode ser uma preocupação durante a adoção da nuvem. O Google fornece várias camadas de controle que podem ativar a verificação do acesso do provedor de nuvem.

As seções a seguir descrevem as opções para gerenciar o acesso à provedor de serviços de nuvem. Recomendamos a opção 1 na maioria dos casos de uso. A outra opção discutida nas seções a seguir é um recurso extra que pode ser considerado caso a opção 1 não seja suficiente para seu caso de uso específico.

Opção 1: ativar os registros da Transparência no acesso

A Transparência no acesso registra as ações realizadas pela equipe do Google Cloud no seu ambiente, como quando um caso de suporte é resolvido.

Por exemplo, o desenvolvedor solicita a solução de um problema para o Cloud Customer Care e pede que o representante de suporte ao cliente ajude a resolver o problema do ambiente. Um registro da Transparência no acesso é gerado para mostrar quais ações a equipe de suporte realizou, incluindo o número da consulta ao suporte que a justificou.

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

  • Você precisa verificar se a equipe do Google está acessando o conteúdo por motivos comerciais válidos, como corrigir uma interrupção ou atender às suas solicitações de suporte.
  • Você tem um requisito de compliance para rastrear o acesso a dados sensíveis.

Opção 2: ativar os registros da Transparência no acesso e o gerenciamento de acesso do provedor

Se sua empresa tiver um requisito de conformidade para conceder aprovação explícita antes que um provedor de serviços de nuvem possa acessar o ambiente, além da Opção 1, é possível usar a Transparência no acesso com outros controles que permitem que você aprove ou negue explicitamente o acesso aos dados.

A aprovação de acesso é uma solução manual que garante que a equipe de atendimento ao cliente e a equipe engenharia do Google exija sua aprovação explícita (por e-mail ou webhook) sempre que precisar acessar o conteúdo.

As Justificativas de acesso às chaves são uma solução programática que adiciona um campo de justificativa às solicitações de chaves de criptografia configuradas com o Cloud EKM.

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

  • Você quer que uma equipe central gerencie diretamente o acesso ao conteúdo pela equipe do Google.
  • Para a aprovação de acesso, você aceita o risco de que a capacidade central de aprovar ou negar cada solicitação de acesso seja mais importante que a compensação operacional, o que pode levar a uma resolução mais lenta de casos de suporte.
  • Para as Justificativas de acesso às chaves, sua empresa já usa o Cloud External Key Manager como parte da estratégia de criptografia e quer controle programático sobre todos os tipos de acesso a dados criptografados (não apenas o acesso dos funcionários ao Google).

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

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

Para ver mais informações, consulte os seguintes tópicos:

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

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

A seguir