Sobre as chaves de criptografia gerenciadas pelo cliente (CMEK)

Por padrão, o Cloud SQL para SQL Server criptografa o conteúdo do cliente em repouso. O Cloud SQL para SQL Server realiza a criptografia para você sem que você precise executar de sua parte. Essa opção é chamada de Criptografia padrão do Google.

Se você quiser controlar suas chaves de criptografia, use chaves de criptografia gerenciadas pelo cliente (CMEKs) no Cloud KMS com serviços integrados a CMEK, incluindo o Cloud SQL para SQL Server. O uso de chaves do Cloud KMS permite controlar o nível de proteção, o local, a programação de rotação, as permissões de uso e acesso e os limites criptográficos. O uso do Cloud KMS também permite a você monitorar o uso de chaves, visualizar registros de auditoria e controlar ciclos de vida importantes. Em vez de o Google ser proprietário e gerente de chaves de criptografia de chaves (KEKs) simétricas que protegem seus dados, você controla e gerencia essas chaves no Cloud KMS.

Depois de configurar os recursos com CMEKs, a experiência de acesso aos recursos do Cloud SQL para SQL Server é semelhante à criptografia padrão do Google. Para mais informações sobre suas opções de criptografia, consulte Chaves de criptografia gerenciadas pelo cliente (CMEK).

CMEK com o Cloud KMS Autokey

É possível criar CMEKs manualmente para proteger recursos do Cloud SQL para SQL Server ou usar o Autokey do Cloud KMS. Com o Autokey, keyrings e as chaves são geradas sob demanda como parte da criação de recursos no Cloud SQL para SQL Server. Os agentes de serviço que usam as chaves para operações de criptografia e descriptografia são criados se ainda não existirem e receberem os papéis necessários do Identity and Access Management (IAM). Para mais informações, consulte Visão geral das autokeys.

O Cloud SQL para SQL Server é compatível apenas com autokey do Cloud KMS ao criar recursos usando o Terraform ou a API REST.

Para saber como usar CMEKs criadas manualmente para proteger seus recursos do Cloud SQL para SQL Server, consulte Usar chaves de criptografia gerenciadas pelo cliente (CMEK).

Para usar as CMEKs criadas pela autokey do Cloud KMS para proteger seus recursos do Cloud SQL para SQL Server, use as etapas fornecidas para o Secret Manager em Usar autokey com recursos do Secret Manager como exemplo.

Criptografia gerenciada pelo Google e criptografia gerenciada pelo cliente

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 clone 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/[KMS_PROJECT_ID]/locations/[LOCATION]/keyRings/[KEY_RING]/cryptoKeys/[KEY_NAME]

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, Futurex 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) como parte do Cloud EKM. As justificativas de acesso às chaves permitem que você veja 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 das justificativas de acesso às chaves.

Assim, as Justificativas de acesso às chaves fornecem controle extra sobre seus dados, fornecendo uma justificativa para cada tentativa de descriptografar os 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 a 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