Por padrão, o Cloud SQL para MySQL criptografa o conteúdo do cliente em repouso. O Cloud SQL para MySQL processa a criptografia para você sem que você precise fazer nada. Essa opção é chamada de Criptografia padrão do Google.
Se quiser controlar suas chaves de criptografia, use chaves de criptografia gerenciadas pelo cliente (CMEKs) no Cloud KMS com serviços integrados a CMEKs, incluindo o Cloud SQL para MySQL. 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 MySQL é 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 seus recursos do Cloud SQL para SQL Server ou usar o Autokey do Cloud KMS. Com Autokey, keyrings e as chaves são gerados sob demanda como parte da criação de recursos no Cloud SQL para MySQL. 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 Autokey não
cria chaves para recursos BackupRun do Cloud SQL para MySQL. Quando
você cria um backup de uma instância do Cloud SQL para MySQL, o backup é
criptografado com a chave gerenciada pelo cliente da instância principal.
O Cloud SQL para MySQL é compatível apenas com o Autokey do Cloud KMS ao criar recursos usando o Terraform ou a API REST.
Para aprender a usar CMEKs criadas manualmente para proteger seus recursos do Cloud SQL para MySQL, consulte Usar chaves de criptografia gerenciadas pelo cliente (CMEK).
Para usar as CMEKs criadas por autokey do Cloud KMS para proteger seus recursos do Cloud SQL para MySQL, 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
Com a CMEK
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.
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 ou failover 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 ou failover 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.
- Depois de criar uma instância do Cloud SQL, não será possível mudar o tipo de chave de criptografia. Não é possível alternar de uma chave de criptografia gerenciada pelo Google para uma chave do Cloud Key Management Service (KMS, na sigla em inglês) ou vice-versa.
A seguir
- Saiba mais sobre criptografia em repouso no Google Cloud Platform.
- Saiba como criar uma instância com a CMEK ativada.
- Saiba mais sobre o Cloud Key Management Service (Cloud KMS).
- Saiba mais sobre Cotas para recursos do Cloud KMS.
- Saiba mais sobre as contas de serviço do IAM.
- Saiba como adicionar as justificações de acesso às chaves.
- Encontre outros produtos que usam a CMEK.