Criptografia em repouso no Google Cloud Platform

O conteúdo aqui apresentado foi editado em abril de 2017 e representa o estado do momento em que foi escrito. As políticas e os sistemas de segurança do Google Cloud Platform poderão mudar no futuro, à medida que melhoramos a proteção para os clientes.

Botão de reprodução

Criptografia em repouso no Google Cloud

Resumo para diretores de TI

  • O Google usa diversas camadas de criptografia para proteger os dados em repouso dos clientes nos produtos do Google Cloud Platform.
  • O Google Cloud Platform usa um ou mais mecanismos para criptografar o conteúdo armazenado em repouso, sem a necessidade de qualquer ação por parte do cliente. Há pequenas exceções, que são citadas mais adiante neste documento.
  • 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) com 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 no mundo inteiro.
  • Os dados armazenados no Google Cloud Platform são criptografados no nível de armazenamento usando AES256 ou AES128.
  • O Google usa a Tink, uma biblioteca criptográfica comum, para implementar a criptografia de maneira consistente em quase todos os produtos do Google Cloud Platform. Como essa biblioteca comum é de fácil acesso, basta apenas uma pequena equipe de criptógrafos para implementar esse código corretamente e mantê-lo rigorosamente controlado e revisado.

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 constantemente 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, 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 Platform e como o Google a utiliza para manter suas informações mais seguras.

Este documento é voltado para diretores de segurança da informação e equipes de operações de segurança que já utilizam ou querem utilizar o Google Cloud Platform. 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?

A 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, na sigla em inglês), 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 guardar 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, o foco será a criptografia em repouso. Ela é a criptografia utilizada para proteger dados armazenados em um disco (incluindo unidades de estado sólido) ou mídias de backup.

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 acrescenta 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 os engenheiros ofereçam suporte à nossa infraestrutura, sem permitir acesso ao conteúdo.

O que consideramos dados de clientes

Conforme definido nos Termos de Serviço do Google Cloud Platform, o termo dados do cliente refere-se 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 Platform usados pela conta desse cliente. Os dados do cliente incluem o conteúdo e os metadados.

O conteúdo do cliente são os dados que os clientes do Google Cloud Platform geram ou fornecem para o Google, como dados armazenados no Google Cloud Storage, snapshots de disco utilizados pelo Google Compute Engine e políticas do Cloud IAM. 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 todos os dados que não podem ser classificados como conteúdo do cliente. Isso pode incluir números de projeto gerados automaticamente, carimbos de data/hora, endereços IP, bem como o tamanho em bytes de um objeto no Google Cloud Storage ou o tipo de máquina no Google 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

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: diversas camadas de criptografia são utilizadas para proteger os dados armazenados no Google Cloud Platform. 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 Google Cloud Storage, é importante compreender como o Google armazena os dados dos clientes. Os dados são divididos em blocos de subarquivos para armazenamento. Cada bloco pode ter vários gigabytes 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 de criptografia, ainda que façam parte do mesmo objeto do Google Cloud Storage, pertençam ao mesmo cliente ou estejam armazenados na mesma máquina1. Se um bloco de dados for atualizado, ele será criptografado com uma nova chave, em vez de reutilizar a chave atual. Essa partição de dados, cada uma utilizando uma chave diferente, significa que o "raio de explosão" de um potencial comprometimento na criptografia de dados estará limitado somente àquele bloco.

O Google criptografa os dados antes de serem 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, que operam sob papéis autorizados com acesso recebido 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 conhecer e saber acessar (1) todos os blocos de armazenamento correspondentes aos dados pretendidos 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 utiliza o algoritmo Padrão de Criptografia Avançado (AES) para criptografar os dados em repouso. 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) e (2) ele é frequentemente incluído como parte dos requisitos de conformidade do cliente.

Os dados armazenados no Google Cloud Storage são criptografados no nível do armazenamento usando o AES no modo Contador/Galois (GCM, na sigla em inglês) em quase todos os casos. Isso é implementado na biblioteca BoringSSL mantida pelo Google. Essa biblioteca foi criada a partir do OpenSSL para uso interno após muitas falhas no OpenSSL terem sido expostas. Em alguns casos, o AES é utilizado 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 é utilizado no modo Contador (CTR) com o HMAC. Veja mais detalhes sobre os algoritmos neste documento. Em outros produtos do Google Cloud Platform, o AES é utilizado de diversos modos.

Criptografia na camada do dispositivo de armazenamento

Além da criptografia de nível de sistema de armazenamento descrita acima, na maior parte dos casos, os dados também são criptografados no nível do dispositivo de armazenamento. Para isso, usa-se pelo menos o AES128 para discos rígidos (HDD) e o AES256 para novas 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, diferente da chave utilizada para criptografar os dados no nível do armazenamento. À medida que os dispositivos mais antigos forem substituídos, somente o AES256 será utilizado para a criptografia no nível do dispositivo.

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, na sigla em inglês) do Google. Além disso, ele também criptografa uma semente gerada aleatoriamente por arquivo no momento do backup. Outra DEK é 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.

Há casos em que os dados não são criptografados em repouso?

O Google Cloud Platform criptografa o conteúdo do cliente armazenado em repouso, sem nenhuma ação do cliente, utilizando um ou mais mecanismos de criptografia, com as seguintes exceções.

  • Registros do console serial de máquinas virtuais no Google Compute Engine. Isso está sendo solucionado no momento.
  • Arquivos de despejo gravados em unidades locais quando um processo falha inesperadamente. Isso está sendo solucionado no momento.
  • Registros de depuração gravados no disco local. Isso está sendo solucionado no momento.
  • Arquivos temporários utilizados por sistemas de armazenamento. Isso está sendo solucionado no momento.
  • Alguns registros que podem incluir o conteúdo do cliente, bem como metadados do cliente. Isso será solucionado no futuro.

Esses dados ainda são amplamente protegidos pelo restante da infraestrutura de segurança do Google e, em quase todos os casos, também são protegidos por criptografia no nível de armazenamento.

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 grupo é 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 DEKs 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 Platform. Elas são armazenadas centralmente no serviço de gerenciamento de chaves (KMS, na sigla em inglês) 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 tornam o armazenamento e a criptografia de dados gerenciáveis na escala do Google. Isso nos permite rastrear e controlar o acesso a dados a partir de um ponto central.

Para cada cliente do Google Cloud Platform, todos os recursos2 não compartilhados são divididos em blocos de dados e criptografados com chaves diferentes daquelas utilizadas com outros clientes3. Essas DEKs são separadas até mesmo das chaves que protegem outras partes dos dados de propriedade 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. Depois, o serviç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 tempos de chegada entre pacotes, e a instrução RDRAND da Intel, quando disponível (em CPUs Ivy Bridge ou mais recentes).

Os dados armazenados no Google Cloud Platform são criptografados com DEKs utilizando AES256 ou AES128, conforme descrito acima, e todos os novos dados criptografados em discos permanentes no Google Compute Engine são criptografados utilizando AES256. As DEKs são encapsuladas com as KEKs usando os algoritmos AES256 ou AES128, dependendo do serviço do Google Cloud Platform. 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 Google Cloud Storage alterna suas KEKs especificamente a cada 90 dias e pode armazenar até vinte 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 são recuperáveis 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 Platform 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 desvinculada 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 desvinculada para o serviço. Então, o sistema de armazenamento envia o bloco de dados criptografados 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. Depois, 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 um (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 do mundo todo. 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 Platform. É 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 a um com o KMS raiz. O distribuidor de chaves mestras do KMS raiz fornece um mecanismo de distribuição por meio de um protocolo de gossiping: 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 este modelo, a infraestrutura do Google não dependerá de um nó central. Isso permite que ele 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 implementa algoritmos criptográficos por meio do BoringSSL6. A Tink está disponível para todos os desenvolvedores do Google. Graças à facilidade de acesso, basta apenas uma pequena equipe de criptógrafos para implementar corretamente esse código rigorosamente controlado e revisado, não sendo necessário a cada equipe do Google implantar a própria criptografia. 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 Platform

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

  Serviço do Google Cloud Platform Granularidade da criptografia de dados do cliente8 (tamanho dos dados criptografados com uma única DEK)
Storage Cloud Bigtable Por bloco de dados (vários por tabela)
Cloud Datastore Por bloco de dados9
Cloud 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 Google 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
Kubernetes Engine Vários por disco, para discos permanentes
Container Registry Armazenado no Google Cloud Storage, por bloco de dados
Big Data BigQuery Vários por conjunto de dados
Cloud Dataflow Armazenado no Google Cloud Storage, por bloco de dados
Cloud Datalab Armazenado no Cloud Bigtable, por arquivo de notebook
Cloud Dataproc Armazenado no Google Cloud Storage, por bloco de dados
Cloud 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 Platform, estamos trabalhando para oferecer uma criptografia adicional aos clientes, além de opções de gerenciamento de chaves para um controle maior.

Queremos permitir que os clientes do Google Cloud Platform:

  • sejam os guardiões finais dos 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 utilizar chaves de criptografia gerenciadas com o Google Cloud Platform por meio do uso do recurso de chaves de criptografia fornecidas pelo cliente. Esse recurso está disponível no Google Cloud Storage e no Google Compute Engine para criptografia da camada de armazenamento.

Os clientes também podem gerenciar suas próprias chaves de criptografia no Google Cloud Platform por meio do Google Cloud Key Management Service (Cloud KMS). 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 alto nível, 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, a criptografia baseada em reticulados é 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 para aplicar a criptografia baseada 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 duplicar o tamanho das chaves.

Outras referências

Segurança do Google Cloud Platform

Para informações gerais sobre a segurança do Google Cloud Platform, consulte a seção de Segurança do site do Google Cloud Platform.

Conformidade do Google Cloud Platform

Para informações sobre conformidade e os respectivos certificados do Google Cloud Platform, consulte a seção sobre esse tópico no site do Google Cloud Platform, que inclui o relatório de auditoria pública do 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 Cloud Datastore, no App Engine e no Cloud 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, não aplicável a essa segregação, seria uma imagem de base compartilhada no Google Compute Engine. Naturalmente, diversos clientes consultam uma única cópia, que foi criptografada por uma única DEK.
3Com exceção dos dados armazenados no Cloud Datastore, no App Engine e no Cloud 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 permanece em uso em alguns locais no Google Cloud Storage.
7 Há outros protocolos criptográficos na biblioteca que anteriormente eram compatíveis, mas essa lista abrange os principais usos no Google Cloud Platform.
8 Refere-se à granularidade da criptografia relacionada ao 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 é única para um cliente individual.
10 Inclui o código e as configurações do aplicativo. Os dados usados no App Engine são armazenados no Cloud 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 Cloud Pub/Sub.