Criptografia em repouso no Google Cloud

O conteúdo apresentado nesta página foi atualizado em julho de 2020 e representa o estado do momento em que foi escrito. As políticas e os sistemas de segurança do Google Cloud podem mudar no futuro, à medida que melhoramos continuamente a proteção dos clientes.

Botão de reprodução

Criptografia em repouso no Google Cloud

Resumo para CIOs

  • O Google usa várias camadas de criptografia para proteger os dados em repouso do cliente nos produtos do Google Cloud.
  • O Google Cloud usa um ou mais mecanismos para criptografar todo o conteúdo armazenado em repouso, sem a necessidade de qualquer ação por parte do cliente.
  • Os dados para armazenamento são divididos em blocos, e cada um deles é criptografado com uma chave exclusiva. Essas chaves de criptografia de dados são armazenadas com os dados e criptografadas (ou encapsuladas) por meio de chaves de criptografia de chaves, que são armazenadas e utilizadas dentro do serviço de gerenciamento de chaves central do Google. O serviço de gerenciamento de chaves do Google é redundante e distribuído em todo o mundo.
  • Todos os dados armazenados no Google Cloud Platform são criptografados no nível do armazenamento usando o AES256, exceto um número pequeno de discos permanentes criados antes de 2015 que usam o AES128.
  • O Google usa uma biblioteca criptográfica pública, a Tink, que utiliza nosso módulo validado pelo FIPS 140-2, o BoringCrypto (em inglês), para implementar a criptografia de forma consistente em quase todos os produtos do Google Cloud. O uso consistente de uma biblioteca pública significa que apenas uma equipe pequena de criptógrafos precisa implementar e manter esse código que tem uma revisão e um controle rigorosos.

Introdução

Para muitas pessoas e empresas, a segurança é o fator decisivo ao escolher um fornecedor de nuvem pública. No Google, a segurança é nossa maior prioridade. Levamos a segurança e a privacidade a sério e trabalhamos incansavelmente para proteger seus dados, estejam eles viajando pela Internet, movimentando-se entre nossos data centers ou armazenados em nossos servidores.

A nossa estratégia de segurança abrangente prioriza a criptografia em trânsito e em repouso, o que garante que os dados só possam ser acessados por papéis e serviços autorizados, com acesso auditado às chaves de criptografia. Neste documento, você verá a abordagem de criptografia em repouso no Google Cloud e como o Google a usa para manter suas informações mais seguras.

Este documento é voltado para CISOs e equipes de operações de segurança que já usam ou querem utilizar o Google Cloud. Exceto pela introdução, este documento supõe que os leitores tenham uma compreensão básica de criptografia e primitivas criptográficas.

O que é criptografia?

Criptografia é um processo que coleta dados legíveis como entrada (muitas vezes chamada de texto simples) e os transforma em uma saída (muitas vezes chamada de texto criptografado) que revela pouca ou nenhuma informação a respeito do texto simples. O algoritmo de criptografia utilizado é público, como o Padrão de Criptografia Avançado (AES), mas a execução depende de uma chave, que é mantida em segredo. Para descriptografar o texto criptografado de volta ao formato original, você precisará usar a chave. No Google, o uso de criptografia para manter os dados confidenciais é geralmente combinado com a proteção de integridade. Dessa forma, quem tiver acesso ao texto criptografado não poderá entendê-lo nem fazer modificações nele sem conhecer a chave. Uma boa fonte para saber mais sobre criptografia é o livro Introduction to Modern Cryptography.

Neste whitepaper, nosso foco é a criptografia em repouso, que é a usada para proteger os dados armazenados em um disco, incluindo unidades de estado sólido (SDDs, na sigla em inglês) ou mídias de backup. Para ver informações sobre a criptografia de dados em trânsito no Google Cloud, confira o respectivo whitepaper.

Por que a criptografia ajuda a proteger os dados dos clientes?

A criptografia é um elemento de uma estratégia de segurança mais ampla. Ela adiciona uma camada de segurança avançada para proteger os dados e garante que, caso as informações caiam acidentalmente nas mãos de um invasor, ele não possa acessá-las sem as chaves de criptografia. Mesmo que um invasor consiga o dispositivo de armazenamento que contém os dados, ele não poderá compreendê-los ou descriptografá-los.

A criptografia em repouso reduz a superfície do ataque ao "remover" as camadas inferiores da pilha de hardware e software. Mesmo se as camadas inferiores forem comprometidas (por exemplo, por meio de acesso físico a dispositivos), os dados nesses dispositivos não serão afetados se a criptografia adequada for implantada. A criptografia também funciona como um "ponto de estrangulamento", ou seja, chaves de criptografia gerenciadas centralmente criam um único local onde o acesso aos dados é forçado e pode ser auditado.

A criptografia é um mecanismo importante para garantir a privacidade dos dados dos clientes do Google. Ela permite que os sistemas manipulem dados para fazer backup, por exemplo, e para que engenheiros ofereçam suporte à nossa infraestrutura sem que eles tenham acesso ao conteúdo.

O que consideramos dados de clientes

Conforme definido nos Termos de Serviço do Google Cloud, dados do cliente se refere ao conteúdo fornecido para o Google por um cliente do GCP (ou por instrução dele), direta ou indiretamente, por meio dos serviços do Google Cloud usados pela conta dessa pessoa. Esses dados incluem o conteúdo e os metadados.

Conteúdo do cliente se refere a dados que os clientes do Google Cloud geram por conta própria ou fornecem para o Google. Exemplos disso são informações armazenadas no Cloud Storage, snapshots do disco usados pelo Compute Engine e políticas de gerenciamento de identidade e acesso. A criptografia em repouso do conteúdo do cliente é o foco deste whitepaper.

Os metadados do cliente constituem o restante dos dados do cliente e se referem a todas as informações que não podem ser classificadas como conteúdo do cliente. Isso pode incluir números de projeto gerados automaticamente, carimbos de data/hora e endereços IP, bem como o tamanho em bytes de um objeto no Cloud Storage ou o tipo de máquina no Compute Engine. Os metadados são protegidos em um nível razoável para manter operações e desempenho contínuos.

Criptografia padrão do Google

Criptografia de dados em repouso

O Google Cloud usa um ou mais mecanismos para criptografar todo o conteúdo armazenado em repouso, sem a necessidade de qualquer ação por parte do cliente.

Camadas de criptografia

O Google utiliza diversas camadas de criptografia para proteger os dados. A utilização de várias camadas de criptografia adiciona uma proteção redundante aos dados e nos permite selecionar a abordagem ideal com base nos requisitos do aplicativo.

Gráfico de camadas de criptografia

Figura 1: várias camadas de criptografia são usadas para proteger os dados armazenados no Google Cloud. Quase todos os arquivos são protegidos por criptografia de sistema de arquivos distribuídos, de banco de dados e armazenamento de arquivos ou de dispositivo de armazenamento.

Criptografia na camada do sistema de armazenamento

Para entender exatamente como funciona a criptografia do Cloud Storage, é importante compreender como o Google armazena os dados de clientes. Essas informações são divididas em blocos de subarquivos para armazenamento. Cada bloco pode ter vários GBs de tamanho Cada bloco é criptografado no nível do armazenamento com uma chave de criptografia individual. Dessa forma, dois blocos nunca terão a mesma chave, mesmo que façam parte do mesmo objeto do Cloud Storage, pertençam ao mesmo cliente ou estejam armazenados na mesma máquina. Se um bloco de dados for atualizado, ele será criptografado com uma nova chave, em vez de reusar a chave atual. Essa partição de dados, cada uma utilizando uma chave diferente, significa que o "raio de explosão" de um comprometimento na criptografia de dados estará limitado somente àquele bloco.

O Google criptografa os dados antes que eles sejam gravados em disco. A criptografia é inerente a todos os sistemas de armazenamento do Google, não sendo adicionada posteriormente.

Cada bloco de dados tem um identificador exclusivo. As listas de controle de acesso (ACLs) garantem que cada bloco seja descriptografado somente pelos serviços do Google. Esses serviços operam sob papéis autorizados, que recebem acesso naquele determinado momento. Isso impede o acesso não autorizado aos dados, reforçando tanto a segurança quanto a privacidade deles.

Cada bloco é distribuído nos sistemas de armazenamento do Google e replicado em formato criptografado para backup e recuperação de desastres. Um indivíduo mal-intencionado que quisesse acessar dados de clientes precisaria acessar (1) todos os blocos de armazenamento correspondentes aos dados que quer visualizar e (2) as chaves de criptografia correspondentes aos blocos.

Diagrama de dados armazenados em blocos criptografados

Figura 2: no Google, os dados são divididos em blocos criptografados para armazenamento.

O Google usa o algoritmo do padrão de criptografia avançada (AES) para criptografar dados em repouso. Todos os dados no nível do armazenamento são criptografados com o AES256 por padrão, exceto um pequeno número de discos permanentes criados antes de 2015 que usam o AES128. O AES é amplamente usado porque (1) o AES256 e o AES128 são recomendados pelo Instituto Nacional de Padrões e Tecnologia (NIST, na sigla em inglês) para uso em armazenamento de longo prazo (desde março de 2019, link em inglês) e (2) ele é frequentemente incluído como parte dos requisitos de conformidade do cliente.

Os dados armazenados no Cloud Storage são criptografados no nível do armazenamento usando o AES no modo Galois/Contador (GCM, na sigla em inglês) na maioria dos casos. Em alguns casos, o AES é usado no modo Encadeamento de blocos de criptografia (CBC, na sigla em inglês), que tem um código de autenticação de mensagem com hash (HMAC, na sigla em inglês) para autenticação. Em relação a alguns arquivos replicados, o AES é usado no modo Contador (CTR) com o HMAC. Veja outros detalhes sobre os algoritmos mais adiante neste documento. Em outros produtos do Google Cloud, o AES é usado de vários modos.

Criptografia na camada do dispositivo de armazenamento

Além da criptografia no nível do sistema de armazenamento descrita acima, na maior parte dos casos, os dados também são criptografados no nível do dispositivo de armazenamento, com o AES256 para discos rígidos (HDD, na sigla em inglês) e unidades de estado sólido (SSD, na sigla em inglês). Além disso, também é usada uma chave separada no nível do dispositivo, que é diferente da chave utilizada para criptografar os dados no nível do armazenamento. Um número pequeno de HDDs legados usam o AES128. SSDs utilizados pelo Google Cloud implementam o AES256 apenas para dados de usuários.

Criptografia de backups

O sistema de backup do Google garante que os dados permaneçam criptografados durante o processo de backup. Essa abordagem evita uma exposição desnecessária de dados de texto simples.

Além disso, o sistema de backup criptografa cada arquivo de backup de maneira independente com sua própria chave de criptografia de dados (DEK, na sigla em inglês), derivada de uma chave armazenada no serviço de gerenciamento de chaves (KMS) do Google. Além disso, ele também criptografa uma semente gerada aleatoriamente por arquivo no momento do backup. Outra chave de criptografia de dados (DEK, na sigla em inglês) é utilizada para todos os metadados em backups, que também são armazenados no KMS do Google. Para mais informações sobre gerenciamento de chaves, consulte esta seção.

Conformidade com o FIPS para dados em repouso

O Google Cloud usa um módulo de criptografia validado pelo FIPS 140-2 (certificado 3318, link em inglês) em nosso ambiente de produção.

Gerenciamento de chaves

Chaves de criptografia de dados, chaves de criptografia de chaves e o serviço de gerenciamento de chaves do Google

A chave utilizada para criptografar os dados em um bloco é chamada de chave de criptografia de dados (DEK, na sigla em inglês). Devido ao grande volume de chaves no Google e à necessidade de baixa latência e alta disponibilidade, essas chaves são armazenadas próximas aos dados criptografados. As chaves de criptografia de dados (DEK, na sigla em inglês) são criptografadas ou encapsuladas por uma chave de criptografia de chaves (KEK, na sigla em inglês). Há uma ou mais KEKs para cada serviço do Google Cloud. Elas são armazenadas centralmente no serviço de gerenciamento de chaves (KMS) do Google, um repositório criado especificamente para armazenar chaves. Utilizar menos KEKs do que DEKs e contar com um serviço de gerenciamento central de chaves torna o armazenamento e a criptografia de dados gerenciáveis na escala do Google. Isso nos permite rastrear e controlar o acesso a dados usando um ponto central.

Para cada cliente do Google Cloud, todos os recursos não compartilhados2 são divididos em blocos de dados e criptografados com chaves diferentes daquelas usadas com outros clientes3. Essas DEKs são separadas até mesmo das chaves que protegem outras partes dos dados do mesmo cliente.

As DEKs são geradas pelo sistema de armazenamento utilizando a biblioteca criptográfica comum do Google. Depois disso, elas são enviadas para o KMS para se encapsularem à KEK do sistema de armazenamento, e as DEKs encapsuladas são reenviadas ao sistema de armazenamento para serem mantidas com os blocos de dados. Quando um sistema de armazenamento precisa recuperar dados criptografados, ele recupera a DEK encapsulada e a envia ao KMS. Em seguida, o KMS verifica se esse serviço está autorizado a usar a KEK e, em caso positivo, desencapsula e retorna a DEK de texto simples ao serviço. O serviço, então, utiliza a DEK para descriptografar o bloco de dados em texto simples e verificar sua integridade.

A maioria das KEKs para criptografia de blocos de dados são geradas dentro do KMS. O restante é gerado nos serviços de armazenamento. Para manter a consistência, todas as KEKs são geradas utilizando a biblioteca criptográfica comum do Google por meio de um gerador de números aleatórios (RNG, na sigla em inglês) criado pelo Google. Esse RNG tem como base NIST 800-90Ar1 CTR-DRBG e gera uma KEK AES2564. Ele é propagado a partir do RNG do kernel do Linux que, por sua vez, é propagado a partir de diversas fontes de entropia independentes. Isso inclui eventos de entropia do ambiente do data center, como medições refinadas de buscas de disco e horários de chegada entre pacotes, bem como a instrução RDRAND da Intel, quando disponível (em CPUs Ivy Bridge ou mais recentes).

Os dados armazenados no Google Cloud são criptografados com DEKs usando AES256 ou AES128, conforme descrito acima, e todos os novos dados criptografados em discos permanentes no Compute Engine são criptografados utilizando AES256. As DEKs são encapsuladas com as KEKs usando AES256 ou AES128, dependendo do serviço do Google Cloud. No momento, estamos trabalhando para fazer upgrade de todas as KEKs dos serviços do Google Cloud para o AES256.

O KMS do Google gerencia KEKs e foi criado exclusivamente para essa finalidade. Ele foi projetado para aprimorar a segurança. As KEKs foram criadas para não serem exportadas a partir do KMS do Google. Todas as criptografias e descriptografias com essas chaves precisam ser feitas dentro do KMS. Isso ajuda a evitar vazamentos e uso indevido, além de permitir que o KMS gere uma trilha de auditoria quando as chaves são usadas.

O KMS pode alternar automaticamente as KEKs em intervalos de tempo regulares utilizando a biblioteca criptográfica comum do Google para gerar novas chaves. Muitas vezes nos referirmos a uma única chave, mas o que realmente queremos dizer é que os dados são protegidos utilizando um conjunto de chaves: uma chave ativa para criptografia e um conjunto de chaves históricas para descriptografia, com um número que é determinado pelo cronograma de alternância de chaves. O cronograma de alternância real para uma KEK varia de acordo com o serviço, mas o período de alternância padrão é de 90 dias. O Cloud Storage alterna as próprias KEKs especificamente a cada 90 dias e pode armazenar até 20 versões. Além disso, ele requer uma nova criptografia dos dados pelo menos uma vez a cada cinco anos, mas, na prática, ela acontece com mais frequência. É realizado um backup das chaves armazenadas pelo KMS para fins de recuperação de desastres, e elas podem ser recuperadas por tempo indefinido.

O uso das KEKs é gerenciado por listas de controle de acesso (ACLs) no KMS para cada chave, com uma política por chave. Somente os serviços e usuários autorizados do Google têm acesso a uma chave. O uso de cada chave é rastreado no nível da operação individual que requer essa chave. Assim, cada vez que uma pessoa utiliza uma chave, ela é autenticada e registrada. Todos os acessos aos dados são auditáveis como parte das políticas gerais de segurança e privacidade do Google.

Veja o que acontece quando um serviço do Google Cloud acessa um bloco criptografado de dados:

  1. O serviço faz uma chamada para o sistema de armazenamento em busca dos dados necessários.
  2. O sistema de armazenamento identifica os blocos em que esses dados estão armazenados (os IDs dos blocos) e onde eles estão armazenados.
  3. Para cada bloco, o sistema de armazenamento reconhece a DEK encapsulada e armazenada com esse bloco (em alguns casos, isso é feito pelo serviço) e a envia para o KMS para desencapsulamento.
  4. O sistema de armazenamento verifica se o job identificado tem permissão para acessar esse bloco de dados com base em um identificador de job utilizando o ID do bloco. Em seguida, o KMS verifica se o sistema de armazenamento está autorizado a usar a KEK associada ao serviço e desencapsular essa DEK específica.
  5. O KMS realiza uma das ações abaixo:
    • Envia a DEK desencapsulada para o sistema de armazenamento, que descriptografa o bloco de dados e o envia para o serviço. Ou, em alguns casos raros,
    • Envia a DEK desencapsulada para o serviço. Depois, o sistema de armazenamento envia o bloco de dados criptografado para o serviço, que descriptografa o bloco de dados e o utiliza.

Esse processo é diferente em dispositivos de armazenamento dedicados, como SSDs locais, onde o dispositivo gerencia e protege a DEK no nível do dispositivo.

Diagrama de descriptografia de blocos de dados

Figura 3: para descriptografar um bloco de dados, o serviço de armazenamento chama o serviço de gerenciamento de chaves (KMS) do Google para recuperar a chave de criptografia de dados (DEK) desencapsulada para esse bloco de dados.

Hierarquia de chave de criptografia e raiz de confiança

O KMS do Google é protegido por uma chave raiz chamada chave mestra do KMS, que une todas as KEKs no KMS. Ela é uma é AES2564, armazenada em outro serviço de gerenciamento de chaves chamado KMS raiz. O KMS raiz armazena um número muito menor de chaves (aproximadamente doze). Para ter mais segurança, o KMS raiz não é executado em máquinas de produção comuns, apenas em máquinas dedicadas em cada data center do Google.

O KMS raiz tem a própria chave raiz, chamada chave mestra do KMS raiz, que também é uma AES2564. Ela é armazenada no distribuidor de chaves mestras do KMS raiz, que é uma infraestrutura ponto a ponto capaz de replicar essas chaves globalmente. O distribuidor de chaves mestras do KMS raiz mantém somente as chaves na RAM das mesmas máquinas dedicadas que o KMS raiz, além de usar a geração de registros para verificar o uso adequado. Uma instância do distribuidor de chaves mestras do KMS raiz é executada para cada instância do KMS raiz. O distribuidor de chaves mestras do KMS raiz está substituindo gradualmente um sistema que opera de forma similar, mas que não é ponto a ponto.

Quando uma nova instância do distribuidor de chaves mestras do KMS raiz é iniciada, ela é configurada com uma lista de nomes de host que já executam instâncias do distribuidor. Então, as instâncias do distribuidor podem encontrar a chave mestra do KMS raiz de outras instâncias em execução. Além dos mecanismos de recuperação de desastres descritos abaixo, a chave mestra do KMS raiz existe apenas na RAM em um número limitado de máquinas especialmente protegidas.

Para lidar com uma situação na qual todas as instâncias do distribuidor de chaves mestras do KMS raiz são reiniciadas simultaneamente, também é realizado um backup da chave mestra do KMS raiz em dispositivos de hardware seguros. Eles são armazenados em cofres físicos de dois locais globais do Google, fisicamente separados e em áreas altamente protegidas. Esse backup seria necessário somente se todas as instâncias do distribuidor fossem derrubadas ao mesmo tempo. Por exemplo, em uma reinicialização global. Menos de 20 funcionários do Google têm acesso a esses cofres.

Diagrama da hierarquia de criptografia do Google

Figura 4: a hierarquia de chaves de criptografia protege um bloco de dados com uma DEK, encapsulada com uma KEK no KMS, que, por sua vez, é protegida pelo KMS raiz e o distribuidor de chaves mestras do KMS raiz.

Para resumir:

  • Os dados são separados em blocos e criptografados com DEKs.
  • As DEKs são criptografadas com KEKs.
  • As KEKs são armazenadas no KMS.
  • O KMS é executado em diversas máquinas em data centers ao redor do mundo.
    • As chaves KMS são encapsuladas com a chave mestra do KMS, que é armazenada no KMS raiz.
  • O KMS raiz é muito menor que o KMS e é executado apenas em máquinas dedicadas em cada data center.
    • As chaves do KMS raiz são encapsuladas com a chave mestra do KMS raiz, que é armazenada no distribuidor de chaves mestras do KMS raiz.
  • O distribuidor de chaves mestras do KMS raiz é uma infraestrutura ponto a ponto executada simultaneamente na RAM de máquinas dedicadas no mundo todo. Cada uma recebe o material de chave de outras instâncias em execução.
    • Caso todas as instâncias do distribuidor sejam derrubadas (desligamento total), uma chave mestra será armazenada em outro hardware seguro, em cofres físicos de locais limitados do Google.
    • O distribuidor de chaves mestras do KMS raiz está substituindo gradualmente um sistema que opera de forma similar, mas que não é ponto a ponto.

Disponibilidade e replicação globais

Alta disponibilidade, baixa latência e acesso global às chaves são fundamentais em todos os níveis. Essas características são necessárias para que os serviços de gerenciamento de chaves sejam utilizados no Google.

Por esse motivo, o KMS é altamente escalonável e é replicado milhares de vezes nos data centers do Google ao redor do mundo. Ele é executado em máquinas comuns na frota de produção do Google, e as instâncias do KMS são executadas globalmente para dar suporte às operações do Google Cloud. É por isso que a latência de qualquer operação de chave única é muito baixa.

O KMS raiz é executado em diversas máquinas dedicadas a operações de segurança, em cada data center. O distribuidor de chaves mestras do KMS raiz é executado nessas mesmas máquinas, um para um com o KMS raiz. Ele fornece um mecanismo de distribuição por meio de um protocolo de gossiping (em inglês). Em um intervalo de tempo fixo, cada instância do distribuidor escolhe uma outra instância aleatória para fazer uma comparação das chaves delas e reconcilia qualquer diferença nas versões das chaves. Com esse modelo, a infraestrutura do Google não dependerá de um nó central. Isso permite que o Google armazene e proteja o material de chave com alta disponibilidade.

Biblioteca criptográfica comum do Google

A biblioteca criptográfica comum do Google é a Tink5, que usa nosso módulo validado pelo FIPS 140-2, o BoringCrypto6 (links em inglês).

A Tink está disponível para todos os desenvolvedores do Google. O uso consistente de uma biblioteca comum significa que apenas uma equipe pequena de criptógrafos precisa implementar esse código que tem uma revisão e um controle rigorosos. Não será necessário que todas as equipes do Google usem uma criptografia própria. Uma equipe especial de segurança do Google é responsável pela manutenção dessa biblioteca em todos os produtos.

A biblioteca de criptografia Tink é compatível com diversos modos e tipos de chaves de criptografia, que são revisados regularmente para garantir que estejam atualizados com os últimos ataques.

No momento da publicação deste documento, o Google utiliza os algoritmos a seguir para criptografia em repouso de DEKs e KEKs. Eles estão sujeitos a alterações, conforme melhoramos nossos recursos e nossa segurança.

Primitiva criptográfica Protocolos preferidos Outros protocolos compatíveis7
Criptografia simétrica
  • AES-GCM (256 bits)
  • AES-CBC e AES-CTR (128 e 256 bits)
  • AES-EAX (128 e 256 bits)
Assinaturas simétricas (quando utilizadas com o AES-CBC e o AES-CTR acima para autenticação)
  • HMAC-SHA256
  • HMAC-SHA512
  • HMAC-SHA1

Granularidade de criptografia em cada produto do Google Cloud

Cada serviço do Google Cloud divide os dados em um nível diferente de granularidade para criptografia.

  Serviço do Google Cloud Granularidade da criptografia de dados do cliente8 (tamanho dos dados criptografados com uma única DEK)
Armazenamento Cloud Bigtable Por bloco de dados (vários por tabela)
Datastore Por bloco de dados9
Firestore Por bloco de dados9
Cloud Spanner Por bloco de dados (vários por tabela)
Cloud SQL
  • Segunda geração: por instância, como no Compute Engine. Cada instância pode conter vários bancos de dados
  • Primeira geração: por instância
Cloud Storage Por bloco de dados (geralmente de 256 KB a 8 MB)
Nós App Engine10 Por bloco de dados9
Cloud Functions11 Por bloco de dados9
Compute Engine
  • Vários por disco
  • Por grupo de snapshots, com intervalos individuais derivados da chave mestra do grupo de snapshots
  • Por imagem
Google Kubernetes Engine Várias por disco, para discos permanentes
Container Registry Armazenada no Cloud Storage, por bloco de dados
Big Data BigQuery Várias por conjunto de dados
Dataflow Armazenada no Cloud Storage, por bloco de dados
Datalab Armazenada no Cloud Bigtable, por arquivo de notebook
Dataproc Armazenada no Cloud Storage, por bloco de dados
Pub/Sub Alternada a cada 30 dias9

Opções adicionais de criptografia para clientes do Cloud

Além de fornecer a criptografia por padrão no Google Cloud, estamos trabalhando para oferecer aos clientes mais opções de criptografia adicional e gerenciamento de chaves para fornecer um controle maior.

Queremos permitir que os clientes do Google Cloud:

  • sejam os guardiões finais dos próprios dados e consigam controlar o acesso e o uso deles no melhor nível de granularidade para garantir tanto a segurança quanto a privacidade dos dados;
  • gerenciem a criptografia dos dados hospedados na nuvem da mesma maneira (ou de um jeito melhor) que o fazem hoje localmente;
  • tenham uma raiz de confiança comprovável e auditável sobre os recursos deles;
  • possam separar e segregar os dados para além do uso de ACLs.

Os clientes podem usar chaves de criptografia gerenciadas com o Google Cloud por meio do recurso de chaves de criptografia fornecidas pelo cliente. Essa funcionalidade está disponível no Cloud Storage e no Compute Engine para criptografia da camada de armazenamento.

Os clientes também podem gerenciar as próprias chaves de criptografia no Google Cloud por meio do Cloud Key Management Service. Esse produto permite a criptografia da camada do aplicativo, que é gerenciada pelo cliente.

Pesquisa e inovação em criptografia

Para acompanhar o ritmo da evolução da criptografia, o Google tem uma equipe de engenheiros de segurança de classe mundial, encarregados de acompanhar, desenvolver e aprimorar a tecnologia de criptografia. Nossos engenheiros participam de processos de padronização e manutenção de softwares de criptografia amplamente utilizados. Publicamos frequentemente nossas pesquisas no campo da criptografia para que todos no setor, incluindo o público, em geral, possam se beneficiar do nosso conhecimento. Por exemplo, em 2014 divulgamos uma vulnerabilidade significativa na criptografia SSL 3.0, conhecida como POODLE, e em 2015 identificamos uma vulnerabilidade de alto risco no OpenSSL.

O Google quer continuar sendo o líder do setor em criptografia para serviços em nuvem. Para desenvolver, implementar e pesquisar novas técnicas de criptografia, temos equipes trabalhando nas seguintes áreas:

  • Criptografia parcialmente homomórfica, que permite que algumas operações sejam executadas em dados criptografados para que a nuvem nunca veja os dados em texto simples, mesmo na memória. Essa tecnologia está sendo usada como parte do nosso cliente BigQuery criptografado experimental, que está disponível ao público.
  • Criptografia preservadora de formato e de ordem, que permite que algumas operações de comparação e classificação sejam realizadas em dados criptografados.
  • Criptografia pós-quântica, que permite substituir as primitivas criptográficas atuais mais vulneráveis a ataques quânticos eficientes por candidatos pós-quânticos, que são considerados mais resistentes a esses ataques. O foco principal dessa área é pesquisar e desenvolver protótipos de criptografia de chaves públicas baseada em reticulados, incluindo recomendações do NIST sobre algoritmos pós-quânticos. Atualmente, ela é considerada uma das técnicas de criptografia que mais se adequaria ao mundo pós-quântico. No entanto, ainda estamos na fase inicial do aprimoramento de algoritmos, parâmetros concretos e criptoanálise da criptografia com base em reticulados. A criptografia de chaves simétricas e MACs têm um desempenho inferior se comparados aos algoritmos quânticos conhecidos, mas ainda é possível fazer upgrade deles para bits de segurança semelhantes em um mundo pós-quântico. Isso pode ser feito ao se duplicar o tamanho das chaves.

Outras referências

Segurança do Google Cloud

Para mais informações sobre a segurança do Google Cloud, acesse esta seção no site do Google Cloud.

Compliance do Google Cloud

Para informações sobre conformidade e os respectivos certificados do Google Cloud, consulte a seção sobre esse tópico no site do Google Cloud, que inclui o relatório de auditoria pública de SOC3 do Google.

Segurança do G Suite

Para saber mais sobre criptografia e gerenciamento de chaves no G Suite, consulte o whitepaper sobre criptografia no G Suite. Esse whitepaper abrange grande parte do conteúdo descrito aqui, mas se concentra exclusivamente no G Suite. Nós nos dedicamos a manter os dados do cliente protegidos em todas as soluções do G Suite e tentamos garantir a maior transparência possível sobre a segurança das informações. Mais informações sobre a segurança geral do G Suite estão disponíveis no whitepaper sobre segurança e conformidade do G Suite.

Notas de rodapé

1 É possível que um bloco de dados no Datastore, no App Engine e no Pub/Sub contenha dados de vários clientes. Consulte a seção sobre granularidade da criptografia de dados por serviço.
2 Um exemplo de recurso compartilhado em que a segregação não se aplica seria uma imagem de base compartilhada no Compute Engine. Naturalmente, vários clientes consultam uma única cópia, que foi criptografada por uma única DEK.
3 Com exceção dos dados armazenados no Datastore, no App Engine e no Pub/Sub, em que os dados de mais de um cliente são criptografados com a mesma DEK. Consulte a seção sobre granularidade da criptografia de dados por serviço.
4 Anteriormente, o algoritmo AES128 era usado e algumas dessas chaves permanecem ativas para descriptografar dados.
5 O Google também usa duas bibliotecas: Keymaster e CrunchyCrypt. A Keymaster compartilha o código de criptografia mais recente em comum com a Tink, mas usa uma implementação diferente de versões das chaves e é compatível com uma variedade maior de algoritmos mais antigos. A CrunchyCrypt está sendo mesclada com a Tink.
6 O OpenSSL também é usado em alguns locais no Cloud Storage.
7 Há outros protocolos criptográficos na biblioteca que anteriormente eram compatíveis, mas a lista abrange os principais usos no Google Cloud.
8 Refere-se à granularidade da criptografia para o conteúdo do cliente. Isso não inclui metadados do cliente, como nomes de recursos. Em alguns serviços, todos os metadados são criptografados com uma única DEK.
9 Não é a única para um cliente.
10 Inclui o código e as configurações do aplicativo. Os dados usados no App Engine são armazenados no Datastore, Cloud SQL ou Cloud Storage dependendo das configurações do cliente.
11 Inclui código da função, configurações e dados de eventos. Dados de eventos são armazenados no Pub/Sub.