Encriptação predefinida em repouso

Este conteúdo foi atualizado pela última vez em maio de 2024 e representa o status quo no momento em que foi escrito. As políticas e os sistemas de segurança da Google podem mudar no futuro, uma vez que melhoramos continuamente a proteção dos nossos clientes.

Na Google, a nossa estratégia de segurança abrangente inclui a encriptação em repouso, que ajuda a proteger os dados dos clientes contra atacantes. Encriptamos todo o conteúdo do cliente da Google em repouso, sem que seja necessária qualquer ação sua, através de um ou mais mecanismos de encriptação. Este documento descreve a nossa abordagem à encriptação em repouso predefinida para a infraestrutura Google e Google Cloud, e como a utilizamos para manter o conteúdo do cliente mais seguro.

Este documento destina-se a arquitetos de segurança e equipas de segurança que estão atualmente a usar ou a considerar a Google. Este documento pressupõe uma compreensão básica da encriptação e das primitivas criptográficas. Para mais informações sobre criptografia, consulte o artigo Introdução à criptografia moderna.

A encriptação de dados inativos é uma encriptação usada para ajudar a proteger os dados armazenados num disco (incluindo unidades de estado sólido) ou num suporte de cópia de segurança. Todos os dados armazenados pela Google são encriptados na camada de armazenamento através do algoritmo Advanced Encryption Standard (AES), AES-256. Usamos uma biblioteca criptográfica comum, o Tink, que inclui o nosso módulo validado pela FIPS 140-2 (denominado BoringCrypto) para implementar a encriptação de forma consistente em todas as plataformas Google Cloud.

Somos proprietários e gerimos as chaves usadas na encriptação em repouso predefinida. Se usar o Google Cloud, o Cloud Key Management Service permite-lhe criar as suas próprias chaves de encriptação que pode usar para adicionar a encriptação de envelopes aos seus dados. Com o Cloud KMS, pode criar, alternar, monitorizar e eliminar chaves. Para mais informações, consulte o artigo Análise detalhada do Serviço de gestão de chaves na nuvem.

Chaves em Google Cloud

A tabela seguinte descreve as diferentes propriedades das chaves em Google Cloud.

Tipo de chave	Chave automática do Cloud KMS	Gerido pelo cliente do Cloud KMS (manual)	Google-owned and Google-managed encryption key (Encriptação predefinida da Google)
Pode ver os principais metadados	Sim	Sim	Não
Propriedade das chaves^1	Cliente	Cliente	Google
Pode gerir^2 e controlar^3 chaves	A criação e a atribuição de chaves são automáticas. O controlo manual do cliente é totalmente compatível.	Cliente, apenas controlo manual	Google
Compatível com os requisitos regulamentares para chaves geridas pelo cliente	Sim	Sim	Não
Partilha de chaves	Único para um cliente	Único para um cliente	Normalmente, os dados de vários clientes são protegidos por chaves de encriptação de chaves (KEKs) de encriptação de chaves partilhadas.
Controlo da rotação de chaves	Sim	Sim	Não
Políticas de organização CMEK	Sim	Sim	Não
Registe o acesso administrativo e aos dados às chaves de encriptação	Sim	Sim	Não
Separação lógica de dados através da encriptação	Sim	Sim	Não
Preços	Varia	Varia	Grátis

¹ O proprietário da chave indica quem detém os direitos da chave. As chaves que detém têm acesso rigorosamente restrito ou nenhum acesso por parte da Google.

² A gestão de chaves inclui as seguintes tarefas:

• Crie chaves.
• Escolha o nível de proteção das chaves.
• Atribuir autoridade para a gestão das chaves.
• Controle o acesso às chaves.
• Controlar a utilização de chaves.
• Defina e modifique o período de rotação das chaves ou acione uma rotação das chaves.
• Altere o estado da chave.
• Destrua versões de chaves.

³ O controlo das teclas significa definir controlos sobre o tipo de teclas e como são usadas, detetar variações e planear ações corretivas, se necessário. Pode controlar as suas chaves, mas delegar a gestão das chaves a terceiros.

Como a encriptação de dados inativos ajuda a proteger os dados

A encriptação em repouso é um elemento de uma estratégia de segurança mais ampla. A encriptação tem as seguintes vantagens:

• Ajuda a garantir que, se os dados caírem nas mãos de um atacante, este não consegue ler os dados sem também ter acesso às chaves de encriptação. Mesmo que os atacantes obtenham os dispositivos de armazenamento que contêm dados dos clientes, não conseguem compreendê-los nem desencriptá-los.
• Ajuda a reduzir a superfície de ataque, eliminando as camadas inferiores da pilha de hardware e software.
• Atua como um ponto de estrangulamento porque as chaves de encriptação geridas centralmente criam um único local onde o acesso aos dados é aplicado e pode ser auditado.
• Ajuda a reduzir a superfície de ataque porque, em vez de ter de proteger todos os dados, as empresas podem focar as respetivas estratégias de proteção nas chaves de encriptação.
• Oferece um mecanismo de privacidade importante para os nossos clientes. Quando os dados estão encriptados em repouso, limita-se o acesso que os sistemas e os engenheiros têm aos dados

O que são dados de clientes?

Conforme definido nos Google Cloud Termos de Utilização, os dados do cliente são dados que os clientes ou os utilizadores finais fornecem à Google através dos serviços na respetiva conta.

O conteúdo do cliente são dados que gera ou nos fornece, como dados armazenados em contentores do Cloud Storage, volumes de discos persistentes e instantâneos de discos usados pelo Compute Engine. Este documento foca-se na encriptação predefinida em repouso para este tipo de dados de clientes.

Os metadados de clientes são dados sobre o conteúdo dos seus clientes e incluem números de projetos gerados automaticamente, datas/horas, endereços IP, o tamanho em bytes de um objeto no Cloud Storage ou o tipo de máquina no Compute Engine. Os metadados dos clientes estão protegidos a um nível razoável para o desempenho e as operações contínuos. Este documento não se foca nas proteções para metadados.

Em conjunto, o conteúdo do cliente e os metadados de clientes constituem os dados de clientes.

Encriptação predefinida de dados em repouso

A Google encripta todo o conteúdo do cliente armazenado em repouso, sem que seja necessária qualquer ação sua, através de um ou mais mecanismos de encriptação. As secções seguintes descrevem os mecanismos que usamos para encriptar o conteúdo do cliente.

Camadas de encriptação

A Google usa várias camadas de encriptação para ajudar a proteger os dados. A utilização de várias camadas de encriptação adiciona proteção de dados redundante e permite-nos selecionar a abordagem ideal com base nos requisitos da aplicação.

O diagrama seguinte mostra as várias camadas de encriptação que são geralmente usadas para proteger os dados do utilizador nos centros de dados de produção da Google. A encriptação do sistema de ficheiros distribuído ou a encriptação da base de dados e do armazenamento de ficheiros está em vigor para todos os dados do utilizador, e a encriptação do dispositivo de armazenamento está em vigor para todos os dados nos centros de dados de produção da Google.

Encriptação na camada de infraestrutura

Todos os sistemas de armazenamento da Google usam uma arquitetura de encriptação semelhante, embora os detalhes de implementação variem de sistema para sistema. Os dados são divididos em blocos lógicos para armazenamento. Cada bloco pode ter até vários gigabytes. Cada bloco é encriptado ao nível do armazenamento com uma chave de encriptação de dados (DEK) individual: dois blocos não têm a mesma DEK, mesmo que sejam propriedade do mesmo cliente ou estejam armazenados na mesma máquina.

Se um bloco de dados for atualizado, é encriptado com uma nova chave, em vez de reutilizar a chave existente. Esta divisão dos dados, cada um com uma chave diferente, limita o risco de uma potencial violação da chave de encriptação de dados apenas a esse bloco de dados.

A Google encripta os dados antes de serem escritos num sistema de armazenamento de base de dados ou num disco rígido. A encriptação é inerente a todos os nossos sistemas de armazenamento, em vez de ser adicionada posteriormente.

Cada bloco de dados lógico tem um identificador exclusivo. As listas de controlo de acesso (ACLs) ajudam a garantir que cada parte só pode ser desencriptada por serviços Google que funcionam com funções autorizadas, às quais é concedido acesso apenas nesse momento. Esta limitação de acesso ajuda a impedir o acesso aos dados sem autorização, reforçando a segurança e a privacidade dos dados.

Cada parte é distribuída pelos nossos sistemas de armazenamento e é replicada de forma encriptada para cópia de segurança e recuperação de desastres. Um atacante que queira aceder aos dados dos clientes teria de conhecer e conseguir aceder a duas coisas: todos os blocos de armazenamento que correspondem aos dados que quer e todas as chaves de encriptação que correspondem aos blocos.

O diagrama seguinte mostra como os dados são carregados para a nossa infraestrutura e, em seguida, divididos em partes encriptadas para armazenamento.

Usamos o algoritmo AES para encriptar os dados em repouso. Todos os dados ao nível do armazenamento são encriptados por DEKs, que usam o AES-256 por predefinição, com exceção de um pequeno número de Persistent Disks criados antes de 2015 que usam o AES-128. O AES é amplamente usado porque o AES-256 e o AES-128 são recomendados pelo National Institute of Standards and Technology (NIST) para utilização no armazenamento a longo prazo, e o AES é frequentemente incluído como parte dos requisitos de conformidade dos clientes.

Um fragmento de dados lógico pode conter os dados de vários clientes. Se quiser alcançar a separação lógica de dados através da encriptação, tem de ativar o Cloud Key Management Service.

Encriptação na camada do dispositivo de armazenamento

Além da encriptação ao nível do sistema de armazenamento, os dados também são encriptados ao nível do dispositivo de armazenamento com AES-256 para unidades de disco rígido (HDD) e unidades de estado sólido (SSD), através de uma chave ao nível do dispositivo separada (que é diferente da chave usada para encriptar os dados ao nível do armazenamento). Um pequeno número de HDDs antigos usa AES-128. As SSDs usadas pela Google implementam o AES-256 exclusivamente para dados do utilizador.

Encriptação de cópias de segurança

O nosso sistema de cópia de segurança garante que os dados permanecem encriptados durante todo o processo de cópia de segurança. Esta abordagem evita a exposição desnecessária de dados de texto simples.

Além disso, o sistema de cópia de segurança encripta ainda mais a maioria dos ficheiros de cópia de segurança de forma independente com a sua própria DEK. A DEK é derivada de uma chave armazenada no Keystore e de uma semente por ficheiro gerada aleatoriamente no momento da cópia de segurança. É usada outra DEK para todos os metadados nas cópias de segurança, que também são armazenados no Keystore.

Conformidade com a FIPS para dados em repouso

A Google usa um módulo de encriptação validado pela FIPS 140-2 (certificado 4407) no nosso ambiente de produção.

Gestão de chaves

Devido ao elevado volume de chaves na Google e à necessidade de baixa latência e alta disponibilidade, as DEKs são armazenadas perto dos dados que encriptam. As DEKs são encriptadas com (envolvidas por) uma chave de encriptação de chaves (KEK), através de uma técnica conhecida como encriptação em envelope. Estas KEKs não são específicas dos clientes. Em alternativa, existe uma ou mais KEKs para cada serviço.

Estas KEKs são armazenadas centralmente no Keystore, um repositório criado especificamente para armazenar chaves. Ter um número menor de KEKs do que DEKs e usar um keystore central torna o armazenamento e a encriptação de dados à nossa escala geríveis e permite-nos monitorizar e controlar o acesso aos dados a partir de um ponto central.

Nota: o keystore era conhecido anteriormente como o serviço de gestão de chaves da Google. É diferente do Cloud KMS, que gere as chaves de encriptação para Google Cloud clientes e ajuda os clientes a criar as respetivas chaves de inquilino.

No Google Cloud, cada cliente pode ter recursos partilhados e não partilhados. Um exemplo de um recurso partilhado é uma imagem base partilhada no Compute Engine. Para recursos partilhados, vários clientes referem-se a uma única cópia, que é encriptada por uma única DEK. Os recursos não partilhados são divididos em blocos de dados e encriptados com chaves separadas das chaves usadas para outros clientes. Estas chaves estão mesmo separadas das que protegem outras partes dos mesmos dados pertencentes ao mesmo cliente. Existem exceções (por exemplo, Datastore, App Engine ou Pub/Sub) em que os dados de mais do que um cliente podem ser encriptados com a mesma DEK.

Gerar DEKs

O sistema de armazenamento gera DEKs através da biblioteca criptográfica comum da Google. Em geral, as DEKs são enviadas para o Keystore para serem envolvidas com a KEK desse sistema de armazenamento, e as DEKs envolvidas são devolvidas ao sistema de armazenamento para serem mantidas com os fragmentos de dados. Quando um sistema de armazenamento precisa de obter dados encriptados, obtém a DEK envolvida e transfere-a para o Keystore. Em seguida, o Keystore verifica se este serviço está autorizado a usar a KEK e, se estiver, descompacta e devolve a DEK de texto simples ao serviço. Em seguida, o serviço usa a DEK para desencriptar o bloco de dados em texto simples e validar a respetiva integridade.

Todos os Google Cloud sistemas de armazenamento cumprem este modelo de gestão de chaves, mas a maioria dos sistemas também implementa níveis adicionais de KEKs do lado do armazenamento para criar uma hierarquia de chaves. Isto permite que os sistemas ofereçam uma latência baixa enquanto usam o KEK de nível mais elevado (armazenado no Keystore) como raiz de confiança.

Gerar KEKs

A maioria das KEKs para encriptar blocos de dados é gerada no Keystore e o resto é gerado nos serviços de armazenamento. Para garantir a consistência, todas as KEKs são geradas através da biblioteca criptográfica comum da Google, com um gerador de números aleatórios (RNG) criado pela Google. Este RNG baseia-se no CTR-DRBG NIST 800-90Ar1 e gera um KEK AES-256. (Anteriormente, era AES-128 e algumas destas chaves permanecem ativas para desencriptar dados.)

Para processadores Intel e AMD, o RNG é iniciado a partir da instrução RDRAND e do RNG do kernel do Linux. Por sua vez, o RNG do kernel do Linux é iniciado a partir de várias fontes de entropia independentes, incluindo RDRAND e eventos entrópicos do ambiente do centro de dados (por exemplo, medições detalhadas de procura de disco e tempos de chegada entre pacotes). Para processadores Arm, o RNG é iniciado a partir do RNG do kernel do Linux.

As DEKs são protegidas com KEKs através do AES-256 ou do AES-128, consoante o Google Cloud serviço. Estamos atualmente a trabalhar na atualização de todas as KEKs para os serviços doGoogle Cloud para AES-256.

Gestão de KEK

O keystore foi criado exclusivamente para gerir KEKs. Por predefinição, as KEKs usadas pelos sistemas de armazenamento não são exportáveis a partir do keystore. Todas as operações de encriptação e desencriptação com estas chaves têm de ser feitas no keystore. Isto ajuda a evitar fugas e utilização indevida, e permite que o Keystore crie uma trilha de auditoria quando as chaves são usadas.

O Keystore pode rodar automaticamente as KEKs a intervalos de tempo regulares, usando a biblioteca criptográfica comum da Google para gerar novas chaves. Embora nos refiramos frequentemente apenas a uma única chave, na verdade, queremos dizer que os dados estão protegidos através de um conjunto de chaves: uma chave está ativa para a encriptação e um conjunto de chaves do histórico está ativo para a desencriptação. O número de chaves históricas é determinado pela programação de rotação de chaves. As KEKs têm uma cópia de segurança para efeitos de recuperação de desastres e são recuperáveis indefinidamente.

A utilização de KEKs é gerida por ACLs no Keystore para cada chave, com uma política por chave. Apenas os serviços e os utilizadores Google autorizados podem aceder a uma chave. A utilização de cada chave é acompanhada ao nível da operação individual que requer essa chave. Assim, sempre que um utilizador usa uma chave, o utilizador é autenticado e registado. Todos os acessos aos dados por parte dos utilizadores são auditáveis como parte das políticas de privacidade e segurança gerais da Google.

Processo de acesso a blocos de dados encriptados

Quando um serviço Google acede a um fragmento de dados encriptado, ocorre o seguinte:

1. O serviço faz uma chamada ao sistema de armazenamento para os dados de que precisa.
2. O sistema de armazenamento identifica os blocos nos quais esses dados são armazenados (os IDs dos blocos) e onde são armazenados.
3. Para cada bloco, o sistema de armazenamento extrai a DEK envolvida que está armazenada com esse bloco (em alguns casos, isto é feito pelo serviço) e envia-a para o Keystore para desembrulhar.
4. O sistema de armazenamento verifica se a tarefa identificada tem autorização para aceder a esse bloco de dados com base num identificador de tarefa e usando o ID do bloco. O keystore verifica se o sistema de armazenamento está autorizado a usar a KEK associada ao serviço e a desencriptar essa DEK específica.
5. O keystore faz uma das seguintes ações:
   • Transmite a DEK não anulada de volta ao sistema de armazenamento, que desencripta o bloco de dados e transmite-o ao serviço.
   • Em alguns casos raros, transmite a DEK não anulada ao serviço. O sistema de armazenamento transmite o bloco de dados encriptado ao serviço, que desencripta o bloco de dados e o utiliza.

Este processo é diferente nos dispositivos de armazenamento dedicados, em que o dispositivo gere e protege a DEK ao nível do dispositivo.

O diagrama seguinte mostra este processo. Para desencriptar um bloco de dados, o serviço de armazenamento chama o Keystore para obter a DEK não processada desse bloco de dados.

Hierarquia de chaves de encriptação e raiz de confiança

O Keystore está protegido por uma chave principal denominada chave principal do Keystore, que envolve todas as KEKs no Keystore. Esta chave principal do keystore é AES-256 e está armazenada noutro serviço de gestão de chaves, denominado Root Keystore. (Anteriormente, a chave principal do keystore era AES-128 e algumas destas chaves permanecem ativas para desencriptar dados.) Para maior segurança, o Root Keystore não é executado em máquinas de produção gerais, mas sim apenas em máquinas dedicadas em cada centro de dados da Google.

Por sua vez, o Root Keystore tem a sua própria chave principal, denominada chave principal do Root Keystore, que também é AES-256 e está armazenada numa infraestrutura ponto a ponto, denominada distribuidor de chaves principais do Root Keystore, e que replica estas chaves globalmente. (Anteriormente, a chave principal do keystore raiz era AES-128 e algumas destas chaves permanecem ativas para desencriptar dados.) O distribuidor de chaves principal do keystore de raiz apenas detém as chaves na RAM nas mesmas máquinas dedicadas que o keystore de raiz e usa o registo para validar a utilização adequada.

Quando é iniciada uma nova instância do distribuidor de chaves principais do repositório de chaves raiz, esta é configurada com uma lista de nomes de anfitriões de instâncias do distribuidor já em execução. As instâncias do distribuidor podem, em seguida, obter a chave principal do keystore raiz de outras instâncias em execução. Além dos mecanismos de recuperação de desastres descritos em Disponibilidade e replicação globais, a chave principal do keystore de raiz existe apenas na RAM num número limitado de máquinas especialmente seguras.

Para resolver o cenário em que todas as instâncias do distribuidor da chave principal do keystore raiz são reiniciadas em simultâneo numa região, também é feita uma cópia de segurança da chave principal do keystore raiz em dispositivos de hardware seguros armazenados em cofres físicos em áreas altamente seguras em várias localizações geograficamente distribuídas. Esta cópia de segurança só é necessária se todas as instâncias do distribuidor numa região ficarem indisponíveis ao mesmo tempo. Apenas alguns funcionários da Google podem aceder a estes cofres.

O diagrama seguinte mostra a hierarquia das chaves de encriptação. A hierarquia de chaves de encriptação protege um bloco de dados com uma DEK, envolvida com uma KEK no keystore, que, por sua vez, é protegida pelo keystore raiz e pelo distribuidor da chave principal do keystore raiz.

Resumo da gestão de chaves

A lista seguinte resume a gestão de chaves na Google:

• Os dados são divididos em blocos e encriptados com DEKs.
• As DEKs são encriptadas com KEKs.
• As KEKs são armazenadas no keystore.
• O keystore é executado em várias máquinas em centros de dados a nível global.
• As chaves da Keystore são envolvidas com a chave principal da Keystore, que é armazenada na Keystore raiz.
• O Root Keystore é muito mais pequeno do que o Keystore e é executado apenas em máquinas dedicadas em cada centro de dados.
• As chaves do Keystore de raiz são envolvidas com a chave principal do Keystore de raiz, que é armazenada no distribuidor da chave principal do Keystore de raiz.
• O distribuidor da chave principal do Root Keystore é uma infraestrutura ponto a ponto que é executada em simultâneo na RAM em máquinas dedicadas a nível global. Cada máquina recebe o seu material de chaves de outras instâncias em execução na região.
• Caso todas as instâncias do distribuidor numa região ficassem indisponíveis, é armazenada uma chave principal em hardware seguro diferente em cofres físicos em localizações limitadas da Google.

Disponibilidade e replicação globais

Em todos os níveis, a elevada disponibilidade, a baixa latência e o acesso global às chaves são essenciais. Estas caraterísticas são necessárias para que os serviços de gestão de chaves sejam usados na Google.

Por este motivo, o Keystore é altamente escalável e é replicado milhares de vezes nos nossos centros de dados a nível global. É executado em máquinas normais na nossa frota de produção, e as instâncias do Keystore são executadas globalmente para suportar as operações da Google. Como resultado, a latência de qualquer operação de tecla única é muito baixa.

O Root Keystore é executado em várias máquinas dedicadas a operações de segurança em cada centro de dados. O distribuidor da chave principal do Root Keystore é executado nestas mesmas máquinas, individualmente com o Root Keystore. O distribuidor da chave principal do keystore raiz fornece um mecanismo de distribuição através de um protocolo de fofoca. A cada intervalo de tempo fixo, cada instância do distribuidor escolhe outra instância aleatória para comparar as respetivas chaves e reconcilia quaisquer diferenças nas versões das chaves. Com este modelo, não existe um nó central do qual toda a nossa infraestrutura dependa. Este método de distribuição permite-nos manter e proteger material essencial com elevada disponibilidade.

Biblioteca criptográfica comum da Google

A biblioteca criptográfica comum da Google é o Tink, que incorpora o nosso módulo validado pela FIPS 140-2, BoringCrypto. O Tink está disponível para todos os programadores da Google. A utilização consistente de uma biblioteca comum significa que apenas uma pequena equipa de criptógrafos tem de implementar este código rigorosamente controlado e revisto, o que torna desnecessário que todas as equipas na Google desenvolvam independentemente a sua própria criptografia. Uma equipa de segurança especial da Google é responsável pela manutenção desta biblioteca criptográfica comum para todos os produtos.

A biblioteca de encriptação Tink suporta uma grande variedade de tipos e modos de chaves de encriptação, e estes são revistos regularmente para garantir que estão atualizados com os ataques mais recentes.

Nota: a Google também usa outra biblioteca denominada Keymaster. O Keymaster partilha código de criptografia mais recente com o Tink, mas o Keymaster usa uma implementação de controlo de versões de chaves diferente e suporta uma maior variedade de algoritmos mais antigos.

Atualmente, usamos os seguintes algoritmos de encriptação para a encriptação em repouso para DEKs e KEKs. Estas estão sujeitas a alterações à medida que continuamos a melhorar as nossas capacidades e segurança.

Primitiva criptográfica	Protocolos preferenciais	Outros protocolos suportados
Encriptação 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 usadas com AES-CBC e AES-CTR acima para autenticação)	HMAC-SHA256	HMAC-SHA512 HMAC-SHA1

Existem outros protocolos criptográficos na biblioteca que foram suportados historicamente, mas esta tabela abrange as utilizações principais na Google.

Investigação e inovação em criptografia

Para acompanhar a evolução da encriptação, temos uma equipa de engenheiros de segurança de classe mundial encarregada de seguir, desenvolver e melhorar a tecnologia de encriptação. Os nossos engenheiros participam em processos de normalização e na manutenção de software de encriptação amplamente utilizado. Publicamos regularmente a nossa investigação na área da encriptação para que todos, incluindo o público em geral, possam beneficiar dos nossos conhecimentos.

Por exemplo, na investigação de criptografia pós-quântica, estamos a trabalhar nas seguintes áreas:

• Normalização: concebemos em conjunto o esquema de assinatura digital sem estado baseado em hash que é normalizado como FIPS 205. Somos editores da norma da Organização Internacional de Normalização (ISO) sobre assinaturas baseadas em hash de criptografia pós-quântica e contribuímos para orientações sobre a gestão de estados para assinaturas baseadas em hash na IETF.

• Ativação: implementámos a criptografia pós-quântica no nosso protocolo interno para segurança da camada de transporte. Ativámos o suporte para criptografia pós-quântica no Chrome. Adicionámos vários algoritmos de criptografia pós-quântica à nossa biblioteca criptográfica Tink. Este código é experimental e foi concebido para ajudar a educar a comunidade sobre cada abordagem.

• Publicações: publicámos o artigo Transição de organizações para criptografia pós-quântica na revista Nature. Este artigo apresenta uma vista geral dos desafios de migração da criptografia pós-quântica. Também publicámos um artigo de investigação sobre a obtenção de criptografia pós-quântica nas nossas chaves de segurança.

Tenha em atenção que a encriptação simétrica (com AES-128 ou posterior) permanece resistente a ataques quânticos.

O que se segue?

• Para obter informações sobre a utilização das suas próprias chaves de encriptação no Google Cloud, consulte o artigo Chaves de encriptação geridas pelo cliente (CMEK).

• Para informações gerais sobre a Google Cloud segurança, consulte a secção Segurança do Google Cloud Website.

• Para ver informações sobre a Google Cloud conformidade e as certificações de conformidade, consulte a secção de conformidade do Google Cloud Website, que inclui o relatório de auditoria SOC3 público da Google.

• Para obter informações sobre a encriptação e a gestão de chaves do Google Workspace, consulte o artigo Como o Google Workspace usa a encriptação para proteger os seus dados, que abrange grande parte do conteúdo incluído aqui, mas foca-se exclusivamente no Google Workspace.