Sobre as chaves de criptografia gerenciadas pelo cliente (CMEK)

Nesta página, você verá como as chaves de criptografia gerenciadas pelo cliente funcionam com o Cloud SQL. Para usá-las imediatamente, consulte esta página.

Uma CMEK é ideal para mim?

As chaves de criptografia gerenciadas pelo cliente são destinadas a organizações com dados confidenciais ou regulamentados que exigem o gerenciamento das próprias chaves de criptografia.

Criptografia gerenciada pelo Google e criptografia gerenciada pelo cliente

Com o recurso de chaves de criptografia gerenciadas pelo cliente, você usa as próprias chaves criptográficas nos dados em repouso no Cloud SQL. Depois de adicionar chaves de criptografia gerenciadas pelo cliente, sempre que uma chamada de API for feita, o Cloud SQL usará as chaves para acessar os dados.

Na criptografia, o Cloud SQL usa chaves de criptografia de dados (DEK, na sigla em inglês) gerenciadas pelo Google e chaves de criptografia de chaves (KEK, na sigla em inglês). Há dois níveis de criptografia:

  1. A DEK criptografa os dados.
  2. A KEK criptografa a DEK.

A instância do Cloud SQL armazena a DEK criptografada com os dados criptografados no DP e o Google controla a própria KEK. Com as chaves de criptografia gerenciadas pelo cliente, você cria uma chave que encapsula a KEK do Google. As chaves de criptografia gerenciadas pelo cliente permitem criar, revogar e excluir a KEK.

As chaves de criptografia gerenciadas pelo cliente, incluindo software, hardware e chaves externas, são gerenciadas pela API Cloud Key Management Service.

Veja nos diagramas abaixo como a criptografia de dados em repouso funciona em uma instância do Cloud SQL ao usar a criptografia padrão do Google, em comparação com as chaves de criptografia gerenciadas pelo cliente.

Sem CMEK

Os dados são enviados ao Google e divididos em blocos. Cada bloco é criptografado com a própria chave de criptografia de dados. As chaves de criptografia de dados são encapsuladas por uma chave de criptografia de chaves. Com a criptografia padrão do Google, a chave de criptografia de chaves é recuperada do keystore interno do Google. Os blocos criptografados e as chaves de criptografia unidas são distribuídos pela infraestrutura de armazenamento do Google.

Com a CMEK

Os dados são enviados ao Google e divididos em blocos. Cada bloco é criptografado com a própria chave de criptografia de dados. As chaves de criptografia de dados são encapsuladas por uma chave de criptografia de chaves. Com a CMEK e o Cloud KMS, a chave de criptografia de chaves é recuperada do Cloud KMS. Os blocos criptografados e as chaves de criptografia unidas são distribuídos pela infraestrutura de armazenamento do Google.

Ao descriptografar dados agrupados com chaves de criptografia gerenciadas pelo cliente, o Cloud SQL usa a KEK para descriptografar a DEK, e a DEK não criptografada para descriptografar dados em repouso.

Bloco de dados criptografado com a DEK e armazenado com a DEK unida. Uma solicitação para desencapsular a DEK é enviada ao armazenamento do KMS, que armazena a KEK não exportável. O armazenamento do KMS retorna a DEK separada.

Quando o Cloud SQL usa as CMEKs?

Operação Observações
Criação de instância Durante a criação da instância, você a configura para usar chaves de criptografia gerenciadas pelo cliente.
Criação do backup Durante os backups de uma instância ativada para CMEK, as chaves de criptografia gerenciadas pelo cliente criptografam os dados do usuário, como consultas e respostas. Os backups de uma instância ativada para CMEK herdam a criptografia com a mesma chave do Cloud KMS que a instância de origem.
Restauração da instância Durante as restaurações de uma instância ativada para CMEK, o Cloud SQL usa a chave para acessar os dados no backup dessa instância. Ao restaurar para uma instância diferente, a instância de destino pode usar outra chave na criptografia.
criação de réplicas; Quando você cria uma réplica de leitura de uma instância do Cloud SQL na mesma região, ela herda a CMEK da instância pai. Se você criar uma réplica de leitura em uma região diferente, precisará selecionar uma CMEK da outra região. Cada região usa seu próprio conjunto de chaves.
Criação de clones Os clones de uma instância ativada para CMEK herdam a criptografia da CMEK com a mesma chave do Cloud KMS que a instância de origem.
Atualização da instância Durante as atualizações de uma instância ativada para CMEK, o Cloud SQL verifica a chave CMEK.

Quais locais são compatíveis com instâncias do Cloud SQL ativadas para CMEK?

O recurso de CMEK está disponível em todos os locais de instâncias do Cloud SQL.

Sobre contas de serviço

Quando as instâncias do Cloud SQL têm a CMEK ativada, você precisa usar uma conta de serviço para solicitar acesso à chave do Cloud KMS.

Para usar uma chave de criptografia gerenciada pelo cliente em um projeto, você precisa ter uma conta de serviço e conceder acesso à chave em questão para essa conta. A conta de serviço precisa existir dentro do projeto. Ela fica visível em todas as regiões.

Se você usar o Console para criar uma instância, o Cloud SQL criará a conta de serviço automaticamente quando você escolher a opção Chave gerenciada pelo cliente (caso a conta ainda não exista). Não é necessário ter permissões especiais na conta de usuário quando o Cloud SQL criar automaticamente a conta de serviço.

Sobre as chaves

No Cloud KMS, é preciso criar um keyring com uma chave criptográfica definida com um local. Ao criar uma nova instância do Cloud SQL, selecione essa chave para criptografar a instância.

É preciso saber qual é o ID e a região da chave ao criar novas instâncias do Cloud SQL que usam chaves de criptografia gerenciadas pelo cliente. Coloque as novas instâncias do Cloud SQL na mesma região que a chave de criptografia gerenciada pelo cliente associada a elas. É possível criar um projeto para as chaves e instâncias do Cloud SQL ou projetos diferentes para cada uma delas.

As chaves de criptografia gerenciadas pelo cliente têm o formato a seguir:

projects/[CMEK_ENABLED_PROJECT]/locations/[REGION]/keyRings/[RING_NAME]/cryptoKeys/[KEYNAME]

Se o Cloud SQL não conseguir acessar a chave, como em um caso em que você desativou a versão da chave, o Cloud SQL suspenderá a instância. Quando a chave ficar acessível novamente, o Cloud SQL retomará a instância automaticamente.

Quando você faz a rotação da chave, as instâncias criptografadas com ela não são criptografadas novamente de maneira automática com a nova versão da chave primária. É possível criptografar novamente qualquer instância ou réplica primária atual ativada para CMEK com a nova versão da chave primária. Para mais informações sobre como criptografar novamente uma instância ou réplica do Cloud SQL após uma rotação de chaves, consulte Criptografar novamente uma instância ou réplica ativada para CMEK.

Gerenciadores de chaves externas

É possível usar chaves armazenadas em gerenciadores de chaves externas, como Fortanix, Ionic ou Thales, como chaves de criptografia gerenciadas pelo cliente. Para saber como usar chaves externas com o Cloud KMS, consulte Gerenciador de chaves externo do Cloud (Cloud EKM).

Justificativas de acesso às chaves

É possível usar as justificativas de acesso às chaves (KAJ, na sigla em inglês) como parte do Cloud EKM. As KAJ permitem ver o motivo de cada solicitação do Cloud EKM. Além disso, com base na justificativa fornecida, é possível aprovar ou negar uma solicitação automaticamente. Para saber mais, consulte a Visão geral.

Portanto, as KAJ fornecem controle extra sobre seus dados fornecendo uma justificativa para cada tentativa de descriptografia dos dados.

Para informações relacionadas sobre como usar chaves com instâncias do Cloud SQL, consulte Como criar uma instância do Cloud SQL com CMEK.

Como tornar os dados criptografados com CMEK permanentemente inacessíveis?

Pode haver casos em que você precise destruir permanentemente os dados criptografados com CMEK. Para isso, destrua a versão da chave de criptografia gerenciada pelo cliente. Não é possível destruir o keyring ou a chave, mas você pode destruir versões da chave.

Como exportar e importar dados de/para uma instância ativada para CMEK?

Se você quiser que os dados permaneçam criptografados com uma chave gerenciada pelo cliente durante uma exportação ou importação, será necessário definir uma chave de criptografia gerenciada pelo cliente no bucket do Cloud Storage antes de exportar dados para ele. Não há requisitos ou restrições específicas para importar dados para uma nova instância quando os dados foram armazenados anteriormente em uma instância ativada com uma chave de criptografia gerenciada pelo cliente.

Restrições

As restrições a seguir se aplicam ao usar chaves de criptografia gerenciadas pelo cliente:

  • Não é possível ativar chaves de criptografia gerenciadas pelo cliente em uma instância atual.
  • Não é possível atribuir uma chave diferente a uma réplica na mesma região da instância primária. Para réplicas entre regiões, você precisa criar uma nova chave para a região da réplica.
  • Não é possível atribuir uma chave diferente a um clone.
  • Não é possível usar chaves de criptografia gerenciadas pelo cliente para criptografar:
    • Servidores externos (instâncias principais externas e réplicas externas)
    • Metadados da instância, como ID, versão do banco de dados, tipo de máquina, sinalizações, programação de backup etc.
  • Não é possível usar chaves de criptografia gerenciadas pelo cliente para criptografar dados de usuários em trânsito, como consultas e respostas.

A seguir