O GoogleSQL para BigQuery suporta a encriptação de encriptação autenticada com dados associados (AEAD).
Este tópico explica os conceitos por detrás da encriptação AEAD no GoogleSQL. Para uma descrição das diferentes funções de encriptação AEAD que o GoogleSQL suporta, consulte o artigo Funções de encriptação AEAD.
Finalidade da encriptação AEAD
O BigQuery mantém os seus dados seguros através da encriptação em repouso. O BigQuery também oferece suporte para chaves de encriptação geridas pelo cliente (CMEKs), que lhe permitem encriptar tabelas com chaves de encriptação específicas. No entanto, em alguns casos, pode querer encriptar valores individuais numa tabela.
Por exemplo, quer manter os dados de todos os seus clientes numa tabela comum e encriptar os dados de cada cliente com uma chave diferente. Tem dados distribuídos por várias tabelas que quer poder "eliminar criptograficamente". A eliminação criptográfica, ou eliminação criptográfica total, é o processo de eliminação de uma chave de encriptação para tornar ilegíveis todos os dados encriptados com essa chave.
As funções de encriptação AEAD permitem-lhe criar conjuntos de chaves que contêm chaves para encriptação e desencriptação, usar estas chaves para encriptar e desencriptar valores individuais numa tabela e rodar chaves num conjunto de chaves.
Conjuntos de chaves
Um conjunto de chaves é uma coleção de chaves criptográficas, uma das quais é a chave criptográfica principal e as restantes, se existirem, são chaves criptográficas secundárias. Cada chave codifica um algoritmo para encriptação ou desencriptação; se a chave está ativada, desativada ou destruída; e, para chaves não destruídas, os bytes da chave propriamente ditos. A chave criptográfica principal determina como encriptar o texto simples de entrada. A chave criptográfica principal nunca pode estar num estado desativado. As chaves criptográficas secundárias destinam-se apenas à desencriptação e podem estar no estado ativado ou desativado. Um conjunto de chaves pode ser usado para desencriptar quaisquer dados que tenha sido usado para encriptar.
A representação de um conjunto de chaves no GoogleSQL é como um buffer de protocolo google.crypto.tink.Keyset serializado em BYTES.
Exemplo
Segue-se um exemplo de um conjunto de chaves AEAD, representado como uma string JSON, com três chaves.
{
"primaryKeyId": 569259624,
"key": [
{
"keyData": {
"typeUrl": "type.googleapis.com/google.crypto.tink.AesGcmKey",
"value": "GiDPhTp5gIhfnDb6jfKOT4SmNoriIJc7ah8uRvrCpdNihA==",
"keyMaterialType": "SYMMETRIC"
},
"status": "ENABLED",
"keyId": 569259624,
"outputPrefixType": "TINK"
},
{
"keyData": {
"typeUrl": "type.googleapis.com/google.crypto.tink.AesGcmKey",
"value": "GiBp6aU2cFbVfTh9dTQ1F0fqM+sGHXc56RDPryjAnzTe2A==",
"keyMaterialType": "SYMMETRIC"
},
"status": "DISABLED",
"keyId": 852264701,
"outputPrefixType": "TINK"
},
{
"status": "DESTROYED",
"keyId": 237910588,
"outputPrefixType": "TINK"
}
]
}
No exemplo acima, a chave criptográfica principal tem um ID de 569259624 e é a primeira chave apresentada na string JSON. Existem duas chaves criptográficas secundárias, uma com o ID 852264701 num estado desativado e outra com o ID 237910588 num estado destruído. Quando uma função de encriptação AEAD usa este conjunto de chaves para encriptação, o texto encriptado resultante codifica o ID da chave criptográfica principal de 569259624.
Quando uma função AEAD usa este conjunto de chaves para desencriptação, a função escolhe a chave adequada para desencriptação com base no ID da chave codificado no texto cifrado. No exemplo acima, a tentativa de desencriptação com os IDs das chaves 852264701 ou 237910588 resultaria num erro, porque o ID da chave 852264701 está desativado e o ID 237910588 está destruído. A reposição do ID da chave 852264701 para um estado ativado
tornaria a chave utilizável para desencriptação.
O tipo de chave determina o modo de encriptação a usar com essa chave.
A encriptação de texto não encriptado mais do que uma vez com o mesmo conjunto de chaves devolve geralmente valores de texto encriptado diferentes devido a vetores de inicialização (VIs) diferentes, que são escolhidos através do gerador de números pseudaleatórios fornecido pelo OpenSSL.
Conjuntos de chaves envolvidos
Se precisar de gerir um conjunto de chaves de forma segura ou transmiti-lo através de um canal não fidedigno, considere usar um conjunto de chaves envolvido. Quando encapsula um conjunto de chaves não processado, este processo encripta o conjunto de chaves não processado através de uma chave do Cloud KMS.
Os conjuntos de chaves envolvidos podem encriptar e desencriptar dados sem expor os dados do conjunto de chaves. Embora possam existir outras formas de restringir o acesso aos dados ao nível do campo, os conjuntos de chaves com encapsulamento oferecem um mecanismo mais seguro para a gestão de conjuntos de chaves em comparação com os conjuntos de chaves não processados.
Tal como com os conjuntos de chaves, os conjuntos de chaves envolvidos podem e devem ser rodados periodicamente. Os conjuntos de chaves envolvidos são usados em funções de encriptação de envelopes AEAD.
Seguem-se algumas funções com exemplos de conjuntos de chaves envolvidos:
KEYS.NEW_WRAPPED_KEYSET: crie um novo conjunto de chaves envolvido.KEYS.ROTATE_WRAPPED_KEYSET: alterne um conjunto de chaves envolvido.KEYS.REWRAP_KEYSET: reembale um conjunto de chaves embalado com novos dados.KEYS.KEYSET_CHAIN: obtenha um conjunto de chaves do Tink encriptado com uma chave do Cloud KMS.
Advanced Encryption Standard (AES)
As funções de encriptação AEAD usam a encriptação Advanced Encryption Standard (AES). A encriptação AES usa texto simples como entrada, juntamente com uma chave criptográfica, e devolve uma sequência de bytes encriptada como saída. Esta sequência de bytes pode ser desencriptada posteriormente com a mesma chave usada para a encriptar. O AES usa um tamanho de bloco de 16 bytes, o que significa que o texto simples é tratado como uma sequência de blocos de 16 bytes. O texto cifrado contém um prefixo específico do Tink que indica a chave usada para realizar a encriptação. A encriptação AES suporta vários modos de cifra de bloco.
Modos de cifra de blocos
Os dois modos de cifra de blocos suportados pelas funções de encriptação AEAD são o GCM e o CBC.
GCM
O modo Galois/contador (GCM) é um modo para a encriptação AES. A função numera os blocos sequencialmente e, em seguida, combina este número de bloco com um vetor de inicialização (IV). Um vetor de inicialização é um valor aleatório ou pseudoraleatório que forma a base da aleatorização dos dados de texto simples. Em seguida, a função encripta o número do bloco e o IV combinados através do AES. Em seguida, a função executa uma operação lógica exclusiva ou (XOU) bit a bit no resultado da encriptação e no texto simples para produzir o texto encriptado. O modo GCM usa uma chave criptográfica com um comprimento de 128 ou 256 bits.
Modo CBC
O CBC "encadeia" blocos através da aplicação de XOR a cada bloco de texto simples com o bloco anterior de texto encriptado antes de o encriptar. O modo CBC usa uma chave criptográfica com um comprimento de 128, 192 ou 256 bits. O CBC usa um vetor de inicialização de 16 bytes como o bloco inicial e aplica XOR a este bloco com o primeiro bloco de texto simples.
O modo CBC não é um esquema AEAD no sentido criptográfico porque não oferece integridade dos dados. Por outras palavras, as modificações maliciosas aos dados encriptados não são detetadas, o que também compromete a confidencialidade dos dados. Por conseguinte, não recomendamos o CBC, a menos que seja necessário por motivos de legado.
Dados adicionais
As funções de encriptação AEAD suportam a utilização de um argumento additional_data, também conhecido como dados associados (AD) ou dados autenticados adicionais.
Um texto cifrado só pode ser desencriptado se os mesmos dados adicionais usados para encriptar
também forem fornecidos para desencriptar. Por conseguinte, os dados adicionais podem ser usados para associar o texto cifrado a um contexto.
Por exemplo, additional_data pode ser o resultado de
CAST(customer_id AS STRING) quando encripta dados de um cliente específico.
Isto garante que, quando os dados são desencriptados, foram encriptados anteriormente com o customer_id esperado. É necessário o mesmo valor additional_data para a descifragem. Para mais informações, consulte a RFC 5116.
Desencriptação
A saída de AEAD.ENCRYPT é
texto cifrado BYTES. As funções AEAD.DECRYPT_STRING ou AEAD.DECRYPT_BYTES podem desencriptar este texto cifrado. Estas funções têm de usar um conjunto de chaves que contenha a chave usada para a encriptação. Essa chave tem de estar num estado 'ENABLED'. Também têm de usar o mesmo additional_data que foi usado na encriptação.
Quando o conjunto de chaves é usado para desencriptação, a chave adequada é escolhida para a desencriptação com base no ID da chave codificado no texto cifrado.
A saída de AEAD.DECRYPT_STRING é uma STRING de texto simples, enquanto a saída de AEAD.DECRYPT_BYTES é um texto simples BYTES. AEAD.DECRYPT_STRING pode desencriptar texto cifrado que codifica um valor STRING;
AEAD.DECRYPT_BYTES pode desencriptar texto cifrado que codifica um valor
BYTES. A utilização de uma destas funções para desencriptar um texto cifrado que codifica o tipo de dados errado, como a utilização de AEAD.DECRYPT_STRING para desencriptar um texto cifrado que codifica um valor BYTES, provoca um comportamento indefinido e pode resultar num erro.
Rotação de chaves
O objetivo principal da rotação das chaves de encriptação é reduzir a quantidade de dados encriptados com uma chave específica, para que uma potencial chave comprometida permita a um atacante o acesso a menos dados.
A rotação do conjunto de chaves envolve:
- Criar uma nova chave criptográfica principal em cada conjunto de chaves.
- Desencriptar e voltar a encriptar todos os dados encriptados.
A função KEYS.ROTATE_KEYSET ou KEYS.ROTATE_WRAPPED_KEYSET executa o primeiro passo, adicionando uma nova chave criptográfica principal a um conjunto de chaves e alterando a chave criptográfica principal antiga para uma chave criptográfica secundária.
Chaves do Cloud KMS
O GoogleSQL suporta funções de encriptação AEAD com chaves do Cloud KMS para proteger ainda mais os seus dados. Esta camada de proteção adicional encripta a sua chave de encriptação de dados (DEK) com uma chave de encriptação de chaves (KEK). O conjunto de chaves de encriptação simétrica é armazenado em segurança no Cloud Key Management Service e gerido através de autorizações e funções do Cloud KMS.
No momento da execução da consulta, use a função KEYS.KEYSET_CHAIN para fornecer o caminho do recurso do KMS da KEK e o texto cifrado da DEK envolvida. O BigQuery chama o Cloud KMS para desembrulhar a DEK e, em seguida, usa essa chave para desencriptar os dados na sua consulta. A versão não anulada da DEK
é armazenada apenas na memória durante a consulta e, em seguida, é destruída.
Para mais informações, consulte o artigo Encriptação ao nível da coluna SQL com chaves do Cloud KMS.