Nesta página, você verá como implementar a criptografia do lado do cliente no Cloud SQL.
Visão geral
A criptografia do lado do cliente é o ato de criptografar dados antes de gravá-los no Cloud SQL. É possível criptografar os dados do Cloud SQL de maneira que apenas seu aplicativo possa descriptografar.
Para ativar a criptografia no cliente, você tem as seguintes opções:
- Usar uma chave de criptografia armazenada no Cloud Key Management Service (Cloud KMS).
- Usar uma chave de criptografia armazenada localmente no aplicativo.
Neste tópico, descrevemos como usar a primeira opção, que oferece a opção de gerenciamento de chaves mais fácil. Criamos uma chave de criptografia no Cloud KMS e implementamos a criptografia de envelope usando a Tink, a biblioteca criptográfica de código aberto do Google.
Por que você precisa de criptografia do lado do cliente?
Você precisará da criptografia do lado do cliente se quiser proteger os dados do Cloud SQL no nível da coluna 1. Imagine que você tem uma tabela de nomes e números de cartão de crédito. Você quer conceder acesso a um usuário à tabela, mas não quer que ele veja os números do cartão de crédito. Os números podem ser criptografados usando a criptografia do lado do cliente. Contanto que o usuário não tenha acesso à chave de criptografia no Cloud KMS, ele não conseguirá ler as informações do cartão de crédito.
Criar chaves usando o Cloud KMS
O Cloud KMS permite criar e gerenciar chaves no Google Cloud Platform.
O Cloud KMS é compatível com muitos tipos diferentes de chave. Para criptografia do lado do cliente, você precisa criar uma chave simétrica.
Para conceder ao seu aplicativo acesso à chave no Cloud KMS, você precisa
conceder o papel cloudkms.cryptoKeyEncrypterDecrypter
à conta de serviço que seu
aplicativo usa. No gcloud, use o seguinte
comando para fazer isso:
gcloud kms keys add-iam-policy-binding key \ --keyring=key-ring \ --location=location \ --member=serviceAccount:service-account-name@example.domain.com \ --role=roles/cloudkms.cryptoKeyEncrypterDecrypter
É possível usar a chave do KMS para criptografar dados diretamente, mas usamos uma solução mais flexível chamada criptografia de envelope. Isso permite criptografar mensagens com mais de 64 KB, que é o tamanho máximo de mensagem compatível com a API Cloud Key Management Service.
Criptografia de envelope do Cloud KMS
Na criptografia do envelope, a chave do KMS atua como uma chave de criptografia de chave (KEK, na sigla em inglês). Ou seja, ela é usada para criptografar chaves de criptografia de dados (DEK, na sigla em inglês), que, por sua vez, são usadas para criptografar dados reais.
Depois de criar uma KEK no Cloud KMS, faça o seguinte para criptografar cada mensagem:
- Gere uma chave de criptografia de dados (DEK, na sigla em inglês) localmente.
- Use essa DEK localmente para criptografar a mensagem.
- Chame o Cloud KMS para criptografar (unir) a DEK com a KEK.
- Armazene os dados criptografados e a DEK unida.
Em vez de implementar a criptografia de envelope do zero, neste tópico usamos a Tink.
Tink
A Tink é uma biblioteca multiplataforma que fornece APIs criptográficas de alto nível. Para criptografar dados com a criptografia de envelope da Tink, você fornece à Tink um URI de chave que aponta para sua KEK no Cloud KMS, e credenciais que permitem que a Tink use a KEK. A Tink gera a DEK, criptografa os dados, une a DEK e retorna um único texto criptografado com os dados criptografados e a DEK unida.
A Tink é compatível com a criptografia de envelope em C++, Java, Go e Python usando a API AEAD:
public interface Aead{
byte[] encrypt(final byte[] plaintext, final byte[] associatedData)
throws…
byte[] decrypt(final byte[] ciphertext, final byte[] associatedData)
throws…
}
Além do argumento normal de mensagem/texto criptografado, os métodos de criptografia e descriptografia
são compatíveis com dados associados opcionais. Esse argumento pode ser usado para vincular o
texto criptografado a um dado. Por exemplo, suponha que você tenha um banco de dados com os
campos user-id
e encrypted-medical-history
. Nesse caso, o campo
user-id
provavelmente será usado como dados associados ao criptografar o histórico
médico. Isso garante que um invasor não possa mover o histórico médico de um usuário
para outro. Ele também é usado para verificar se você tem a linha correta de dados quando
executa uma consulta.
Amostras
Nesta seção, apresentaremos exemplos de código para um banco de dados de informações do eleitor que usa criptografia do lado do cliente. O código de amostra mostra como:
- Criar uma tabela de banco de dados e um pool de conexões
- Configurar a Tink para criptografia de envelope
- Criptografar e descriptografar dados usando a criptografia de envelope da Tink com uma KEK no Cloud KMS
Antes de começar
Crie uma instância do Cloud SQL seguindo estas instruções. Anote a string de conexão, o usuário do banco de dados e a senha do banco de dados que você criar.
Crie um banco de dados para seu aplicativo seguindo estas instruções. Anote o nome do banco de dados.
Crie uma chave do KMS para seu aplicativo seguindo estas instruções. Copie o nome do recurso da chave criada.
Crie uma conta de serviço com as permissões de "Cliente do Cloud SQL" seguindo estas instruções.
Adicione a permissão "Criptografador/Descriptografador do Cloud KMS CryptoKey" da chave à sua conta de serviço seguindo estas instruções.
Crie um pool de conexões e crie uma nova tabela no banco de dados.
Java
Python
Inicialize um primitivo AEAD de envelope com a Tink.
Java
Python
Criptografar dados e inseri-los no banco de dados.
Java
Python
Consultar o banco de dados e descriptografar os dados armazenados.
Java
Python
-
Também é possível restringir o acesso na instância ou do banco de dados. ↩