O GoogleSQL para BigQuery oferece suporte à criptografia autenticada com de dados associados (AEAD, na sigla em inglês).
Neste tópico, explicamos os conceitos que norteiam a criptografia AEAD no GoogleSQL. Para receber uma descrição das diferentes funções de criptografia AEAD compatíveis com o GoogleSQL, consulte Funções de criptografia AEAD.
Finalidade da criptografia AEAD
O BigQuery mantém seus dados seguros usando a criptografia em repouso. O BigQuery também oferece suporte a chaves de criptografia gerenciadas pelo cliente (CMEKs) que permitem criptografar tabelas usando chaves de criptografia específicas. Em alguns casos, no entanto, talvez você queira criptografar valores individuais em uma tabela.
Por exemplo, você quer manter os dados de todos os seus clientes em uma tabela comum e criptografar os dados de cada cliente usando uma chave diferente. Seus dados estão espalhados por várias tabelas que você quer poder "excluir criptograficamente". Exclusão ou trituração criptográfica é o processo de excluir uma chave de criptografia para tornar ilegíveis quaisquer dados criptografados por essa chave.
É possível criar conjuntos de chaves com chaves para criptografia e descriptografia por meio das funções de criptografia AEAD, usar essas chaves para criptografar e descriptografar valores individuais em uma tabela e girar as chaves dentro de um conjunto de chaves.
Conjunto de chaves
Um conjunto de chaves é uma coleção de chaves criptográficas. Uma delas é a chave criptográfica primária e o restante, se houver, são chaves criptográficas secundárias. Cada chave codifica um algoritmo para criptografia ou descriptografia, o estado da chave (ativada, desativada ou destruída) e, no caso de chaves não destruídas, os próprios bytes de chave. A chave criptográfica primária determina como criptografar o texto simples de entrada. A chave criptográfica primária nunca pode estar desativada. As chaves criptográficas secundárias servem apenas para descriptografia e podem estar no estado ativada ou desativada. Um conjunto de chaves pode ser usado para descriptografar todos os dados que foram usados para criptografar.
A representação de um conjunto de chaves no GoogleSQL é como um buffer de protocolo
google.crypto.tink.Keyset
serializado em BYTES
.
Exemplo
Veja a seguir um exemplo de 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 primária, com o código 569259624
, é a primeira que aparece na string JSON. Há duas chaves criptográficas
secundárias: uma com o ID 852264701
no estado desativada e outra
com o ID 237910588
no estado destruída. Quando uma função de criptografia AEAD usa
esse conjunto de chaves para criptografia, o texto criptografado resultante codifica o
ID da chave criptográfica primária, 569259624
.
Quando uma função AEAD usa esse conjunto de chaves para descriptografia, ela escolhe a chave apropriada com base no código de chave codificado no texto criptografado. No exemplo acima, a tentativa de descriptografar usando o código de chave 852264701
ou 237910588
geraria um erro, porque o código de chave 852264701
está desativado e o código 237910588
está destruído. Restaurar o ID de chave 852264701
para o estado ativado
o tornaria utilizável para descriptografia.
O tipo de chave determina o modo de criptografia a ser usado com essa chave.
Criptografar texto simples mais de uma vez usando o mesmo conjunto de chaves costuma retornar diferentes valores de texto criptografado devido a diferentes vetores de inicialização (IVs, na sigla em inglês), que são escolhidos por meio do gerador de número pseudo-aleatório fornecido pelo OpenSSL.
Conjunto de chaves encapsuladas
Se você precisar gerenciar com segurança um conjunto de chaves ou transmiti-lo em um canal não confiável, use um conjunto encapsulado. Quando você encapsula um conjunto de chaves bruto, esse processo criptografa o conjunto usando uma chave do Cloud KMS.
Os conjuntos de chaves encapsulados podem criptografar e descriptografar dados sem expor os dados deles. Embora possa haver outras maneiras de restringir o acesso a dados no nível do campo, os conjuntos de chaves encapsulados fornecem um mecanismo mais seguro para o gerenciamento de conjuntos em comparação com os brutos.
Assim como os conjuntos de chaves, os conjuntos de chaves encapsulados podem e devem ser rotacionados periodicamente. Os conjuntos de chaves encapsulados são usados nas funções de criptografia de envelope AEAD.
Veja algumas funções com exemplos de conjunto de chaves encapsulados:
KEYS.NEW_WRAPPED_KEYSET
: criar um novo conjunto de chaves encapsulado.KEYS.ROTATE_WRAPPED_KEYSET
: rotacionar um conjunto de chaves encapsulado.KEYS.REWRAP_KEYSET
: reencapsular um conjunto de chaves encapsuladas com novos dados.KEYS.KEYSET_CHAIN
: receba um conjunto de chaves Tink criptografado com uma chave do Cloud KMS.
Padrão de criptografia avançada (AES)
As funções de criptografia AEAD usam o padrão de criptografia avançada (AES, na sigla em inglês). A criptografia AES usa texto simples como entrada junto com uma chave criptográfica e retorna uma sequência criptografada de bytes como saída. É possível descriptografar essa sequência de bytes posteriormente usando a mesma chave usada para criptografá-la. O AES usa um tamanho de bloco de 16 bytes, isto é, o texto simples é tratado como uma sequência de blocos de 16 bytes. O texto criptografado conterá um prefixo específico do Tink indicando a chave usada para realizar a criptografia. A criptografia AES é compatível com vários modos de criptografia em blocos.
Modos de criptografia em blocos
Dois modos de criptografia em blocos compatíveis com as funções de criptografia AEAD são GCM e CBC.
GCM
O Galois/Counter Mode (GCM) é um modo de criptografia AES. A função numera os blocos sequencialmente e, em seguida, combina o número do bloco com um vetor de inicialização (IV, na sigla em inglês). Um vetor de inicialização é um valor aleatório ou pseudo-aleatório que forma a base da ordem aleatória dos dados em texto simples. Em seguida, a função criptografa a combinação de número do bloco e IV usando AES. A função executa uma operação OR lógica exclusiva (XOR, na sigla em inglês) bit a bit no resultado da criptografia e o texto simples para produzir o texto criptografado. O modo GCM usa uma chave criptográfica de 128 ou 256 bits de comprimento.
Modo CBC
O CBC “encadeia” blocos fazendo XOR de cada bloco de texto simples com o bloco anterior de texto criptografado antes de criptografá-lo. O modo CBC usa uma chave criptográfica de 128, 192 ou 256 bits de comprimento. O CBC usa um vetor de inicialização de 16 bytes como bloco inicial e faz XOR desse bloco com o primeiro bloco de texto simples.
O modo CBC não é um esquema AEAD no sentido criptográfico porque não fornece integridade de dados. Em outras palavras, modificações mal-intencionadas nos dados criptografados não serão detectadas, o que também compromete a confidencialidade dos dados. Portanto, o CBC não é recomendado, a menos que seja necessário por motivos legados.
Dados extras
As funções de criptografia AEAD aceitam o uso de um argumento additional_data
,
também conhecido como dados associados (AD, na sigla em inglês) ou dados autenticados extras.
Um texto criptografado só poderá ser descriptografado se houver os mesmos dados adicionais
usados para descriptografia. Portanto, os dados adicionais podem ser usados
para vincular o texto criptografado a um contexto.
Por exemplo, additional_data
pode ser a saída de
CAST(customer_id AS STRING)
quando se criptografa dados para um cliente específico.
Isso garante que, quando os dados forem descriptografados, terão sido criptografados previamente usando
o customer_id
esperado. O mesmo valor additional_data
é necessário para
descriptografia. Para mais informações, consulte a
RFC 46485 (em inglês).
Descriptografia
A saída de AEAD.ENCRYPT
é o texto
criptografado BYTES
. As funções
AEAD.DECRYPT_STRING
ou
AEAD.DECRYPT_BYTES
podem descriptografar este
texto cifrado. Essas funções precisam usar um conjunto de chaves que
tenha a chave usada para criptografia. Essa chave precisa estar no
estado 'ENABLED'
. Elas também precisam usar os mesmos additional_data
usados na
criptografia.
Quando o conjunto de chaves é usado para descriptografia, a chave apropriada é escolhida para descriptografia com base no código de chave codificado no texto criptografado.
A saída de AEAD.DECRYPT_STRING
é uma STRING de
texto simples, enquanto a saída de AEAD.DECRYPT_BYTES
é
de texto simples BYTES
. AEAD.DECRYPT_STRING
pode descriptografar
o texto criptografado que codifica um valor de STRING.
AEAD.DECRYPT_BYTES
pode descriptografar o texto criptografado que codifica um
valor de BYTES
. Usar uma dessas funções para
descriptografar um texto criptografado que codifica o tipo de dados incorreto,
como usar AEAD.DECRYPT_STRING
para descriptografar o texto criptografado que codifica um valor de
BYTES
, causa comportamento indefinido e pode
gerar erro.
Troca de chaves
A principal finalidade do revezamento de chaves de criptografia é reduzir a quantidade de dados criptografados com qualquer chave específica, para que uma chave possivelmente comprometida limite o acesso de um invasor aos dados.
O revezamento do conjunto de chaves envolve:
- Criação de uma nova chave criptográfica primária dentro de cada conjunto de chaves.
- Descriptografia e nova criptografia de todos os dados criptografados.
A primeira etapa é executada pela função
KEYS.ROTATE_KEYSET
ou KEYS.ROTATE_WRAPPED_KEYSET
com a adição de uma nova chave criptográfica primária a um
conjunto de chaves e a transformação da antiga chave criptográfica primária em
secundária.
Chaves do Cloud KMS
O GoogleSQL oferece suporte a funções de criptografia AEAD com chaves do Cloud KMS para proteger ainda mais seus dados. Essa camada extra de proteção criptografa sua chave de criptografia de dados (DEK, na sigla em inglês) com uma chave de criptografia de chaves (KEK, na sigla em inglês). A KEK é um conjunto de chaves de criptografia simétrica armazenada com segurança no Cloud Key Management Service e gerenciada usando permissões e papéis do Cloud KMS.
No tempo de execução da consulta, use a função
KEYS.KEYSET_CHAIN
para fornecer o caminho do recurso KMS da KEK e o texto criptografado da
DEK encapsulada. O BigQuery chama o Cloud KMS para desencapsular a DEK e, em seguida, usa
essa chave para descriptografar os dados na consulta. A versão desencapsulada da DEK
é armazenada apenas na memória durante a consulta e, em seguida, destruída.
Para mais informações, consulte Criptografia na coluna SQL com chaves do Cloud KMS.