Sobre as chaves de criptografia gerenciadas pelo cliente (CMEK)

Este documento descreve como usar chaves de criptografia gerenciadas pelo cliente (CMEK) no Cloud Key Management Service (Cloud KMS) para seus clusters no Memorystore para Redis Cluster. O documento também descreve quais dados são criptografados no armazenamento persistente e como os clusters se comportam durante os eventos do ciclo de vida das chaves.

Com a CMEK, você controla as chaves criptográficas que protegem seus dados armazenados. Ao gerenciar suas próprias chaves no Cloud KMS, você tem mais controle sobre o acesso, a rotação e o uso delas, o que ajuda a atender a requisitos regulamentares e de compliance rigorosos.

A implementação da CMEK oferece uma camada extra de segurança e controle sobre seus dados persistentes, como backups e arquivos de persistência. Só é possível ativar a CMEK em clusters novos. Não é possível aplicar a CMEK a clusters atuais.

Quem deve usar a CMEK?

A CMEK é destinada a organizações com dados sensíveis ou regulamentados que precisam de controle sobre as próprias chaves de criptografia. Para mais informações sobre se é necessário usar a CMEK para criptografar esses dados, consulte Escolher onde usar a CMEK.

Criptografia gerenciada pelo cliente

Com a CMEK, você usa suas chaves criptográficas para proteger os dados armazenados em clusters. Para criptografar esses dados, o Memorystore for Redis Cluster usa chaves de criptografia de dados (DEKs) gerenciadas pelo Google e chaves de criptografia de chaves (KEKs) gerenciadas pelo cliente.

Você pode ter os seguintes níveis de criptografia:

  • Criptografia de DEK: as DEKs criptografam dados no Memorystore for Redis Cluster.
  • Criptografia KEK: as KEKs criptografam as DEKs.

O Memorystore para Redis Cluster usa KEKs para criptografar DEKs e DEKs para criptografar os dados armazenados. Se você usa a CMEK, é possível gerenciar as KEKs que criptografam as DEKs no cluster.

O diagrama a seguir mostra como um cluster usa a CMEK para criptografar dados. Os dados enviados para a infraestrutura de armazenamento do Google são divididos em blocos, e cada bloco é criptografado com uma DEK própria. O Cloud KMS fornece a KEK para criptografar as DEKs, e a infraestrutura de armazenamento do Google distribui os blocos de dados criptografados e as DEKs criptografadas pelo sistema.

Os dados são enviados para a infraestrutura de armazenamento do Google e divididos em blocos. Cada bloco é criptografado com uma DEK própria. Em seguida, as DEKs são criptografadas usando uma KEK recuperada do Cloud KMS. Os blocos criptografados e as DEKs criptografadas são distribuídos pela infraestrutura de armazenamento.

O diagrama a seguir mostra como o Memorystore for Redis Cluster descriptografa dados criptografados com a CMEK. Para acessar esses dados criptografados, o Memorystore for Redis Cluster envia uma solicitação ao Cloud KMS, que gerencia a KEK, para descriptografar a DEK. Em seguida, o Cloud KMS retorna a DEK descriptografada, que o cluster usa para descriptografar os dados armazenados.

Bloco de dados criptografado com a DEK e armazenado com a DEK criptografada. Uma solicitação para descriptografar a DEK é enviada ao Cloud KMS, que armazena a KEK. O Cloud KMS retorna a DEK descriptografada.

Quais dados são criptografados usando a CMEK?

A CMEK criptografa os seguintes tipos de dados do cliente armazenados em armazenamento permanente:

  • Backups: com os backups, é possível recuperar seus dados para um determinado momento, além de exportá-los e analisá-los. Os backups também são úteis para recuperação de desastres, migração de dados, compartilhamento de dados pessoais e cenários de conformidade.
  • Persistência: O Memorystore for Redis Cluster oferece suporte a dois tipos de persistência:
    • Persistência do RDB:o recurso de banco de dados do Redis (RDB) protege seus dados salvando snapshots deles em um armazenamento durável.
    • Persistência de AOF:esse recurso prioriza a durabilidade dos dados. Ele armazena dados de forma durável gravando todos os comandos de gravação em um arquivo de registro chamado arquivo somente de anexação (AOF, na sigla em inglês). Se ocorrer uma falha ou reinicialização do sistema, o servidor vai reproduzir os comandos do arquivo AOF sequencialmente para restaurar seus dados.
  • Metadados relacionados a recursos de segurança, como autenticação básica baseada em token e criptografia em trânsito. Para mais informações, consulte Proteger o acesso aos clusters usando a autenticação básica baseada em token e Sobre a criptografia em trânsito.

Componentes da CMEK

As seções a seguir descrevem os requisitos e comportamentos das contas de serviço, chaves criptográficas, versões de chaves e políticas da organização que compõem sua arquitetura de CMEK.

Contas de serviço

Para criar um cluster com CMEK ativada, conceda o papel roles/cloudkms.cryptoKeyEncrypterDecrypter à conta de serviço do Memorystore para Redis Cluster que usa o seguinte formato:

service-PROJECT_NUMBER@cloud-redis.iam.gserviceaccount.com

Ao conceder essa permissão, a conta de serviço pode solicitar acesso à chave do Cloud KMS.

Chaves

No Cloud KMS, é preciso criar um keyring e uma chave criptográfica que use um algoritmo de criptografia simétrica. Ao criar um cluster, você seleciona essa chave para criptografá-lo. É possível criar um projeto para chaves e clusters ou projetos diferentes para cada um deles.

A CMEK está disponível em todos os locais de cluster. Crie o keyring e a chave na mesma região em que você quer criar o cluster. Para um cluster multirregional, defina o keyring e a chave no mesmo local do cluster. Se as regiões ou locais não corresponderem, uma solicitação para criar o cluster vai falhar.

Para o ID do recurso da chave, a CMEK usa o seguinte formato:

projects/CMEK_ENABLED_PROJECT/locations/REGION/keyRings/KEY_RING_NAME/cryptoKeys/KEY_NAME

Para mais informações sobre como encontrar os IDs de recursos de chaves atuais, consulte Como conseguir um ID de recurso do Cloud KMS.

Chaves externas

Como parte da sua estratégia de CMEK, você pode usar chaves externas. Para fazer isso, use o Cloud External Key Manager (Cloud EKM) para criptografar dados no Google Cloud usando chaves externas que você gerencia.

Quando você usa uma chave do Cloud EKM, o Google não tem controle sobre a disponibilidade das suas chaves gerenciadas externamente. Se uma chave não estiver disponível quando você criar o cluster, o Memorystore for Redis Cluster não vai criar o cluster. Além disso, se a chave externa ficar indisponível a qualquer momento depois da criação do cluster, o Memorystore for Redis Cluster vai desativar os backups e a persistência, mas as operações regulares de armazenamento em cache na memória vão continuar atendendo ao tráfego.

Para mais considerações sobre o uso de chaves externas, consulte Considerações.

Versões de chave

O Cloud KMS armazena o material da chave criptográfica usado para criptografar e descriptografar seus dados em uma versão da chave. Uma única chave pode conter várias versões. Sempre que você gira uma chave, cria uma versão dela.

As seções a seguir descrevem como seus clusters e os dados protegidos deles se comportam durante eventos importantes do ciclo de vida, como desativação, destruição, rotação, ativação ou restauração de versões de chaves. As seções também explicam o impacto de revogar o acesso ou substituir uma chave do Cloud KMS e fornecem orientações sobre a recriptografia manual de dados.

Como desativar ou destruir uma versão de chave CMEK

Pode haver casos em que você precise tornar os dados criptografados com CMEK permanentemente inacessíveis, como ao corrigir um vazamento de dados. Para conseguir essa destruição de dados de alta segurança (também conhecida como criptofragmentação), destrua a versão da chave. Para mais informações sobre como destruir versões de chaves, consulte Destruir e restaurar versões de chaves.

Se você desativar ou destruir a versão da chave primária, as seguintes condições serão aplicadas aos backups e à persistência.

Backups

Quando você destrói a versão chave primária da chave, as seguintes restrições se aplicam aos backups do cluster:

  • Não é possível criar backups sob demanda ou automáticos. No entanto, se você ativar uma versão de chave mais antiga, poderá acessar todos os backups criados com essa versão.
  • Não é possível atualizar ou reativar os backups automáticos até que você ative ou restaure a versão da chave primária. Para mais informações, consulte Ativar ou restaurar a versão principal da chave CMEK.
Persistência

Quando você destrói a versão da chave primária, as seguintes restrições se aplicam à persistência do cluster:

  • Se você configurar o cluster para usar a persistência, o Memorystore for Redis Cluster desativará a persistência quando a versão da chave ficar indisponível. Você não vai mais receber cobranças pelo uso da persistência.
  • O Memorystore para Redis Cluster não libera novos dados para o armazenamento permanente usando a CMEK.
  • O Memorystore for Redis Cluster não consegue ler os dados atuais presentes no armazenamento permanente.
  • Não é possível atualizar ou reativar a persistência até que a versão da chave primária seja ativada ou restaurada.

Se você ativar a versão da chave primária, mas desativar ou destruir uma versão mais antiga, as seguintes condições serão aplicadas aos backups e à persistência:

  • Você pode criar backups. No entanto, se um backup for criptografado com uma versão mais antiga da chave que estiver desativada ou destruída, ele vai permanecer inacessível.
  • Se você ativar a persistência, ela vai continuar ativada. Se a versão mais antiga da chave usada na persistência for desativada ou destruída, o Memorystore for Redis Cluster fará uma atualização semelhante à usada na manutenção e criptografará novamente os dados com a versão da chave primária.

Como revogar o acesso a uma chave do Cloud KMS

Se você revogar o acesso a uma chave ativa do Cloud KMS desativando a chave ou removendo as permissões do IAM, o Memorystore for Redis Cluster vai priorizar a disponibilidade do cache principal. As operações regulares de armazenamento em cache na memória continuam atendendo ao tráfego.

No entanto, os backups e a persistência são desativados. O Memorystore for Redis Cluster para imediatamente de gravar novos dados no disco e não lê dados do disco criptografado pelo cliente na memória.

Alternar a versão principal da chave CMEK

Se você girar a versão chave primária da chave e criar uma nova versão chave primária, as seguintes condições se aplicam a backups e persistência:

  • A versão mais recente da chave primária da CMEK criptografa novos backups.
  • Para backups atuais, não é feita uma nova criptografia.
  • Para persistência, os nós não fazem nada. Os nós continuam usando a versão mais antiga da chave até o próximo evento de manutenção.

Recriptografar manualmente dados protegidos por CMEK

O Memorystore for Redis Cluster não oferece suporte à reencriptação sob demanda de dados armazenados. Não é possível acionar um processo manualmente para usar uma nova versão de chave e criptografar novamente backups ou arquivos de persistência ativos. No entanto, é possível usar a nova versão da chave para criptografar dados recém-gravados.

Se você fizer a rotação de uma chave e precisar forçar um cluster a usar a nova versão, as seguintes condições serão aplicadas a backups e persistência:

Backups

Não é possível reencriptar backups atuais. Se a compliance exigir que todos os dados sejam criptografados com a chave mais recente, crie um backup que use essa chave e exclua os backups atuais manualmente. Também é possível exportar esse backup para um bucket do Cloud Storage para que a chave de criptografia do Cloud Storage seja usada.

Persistência

Para forçar o cluster a usar uma nova chave do Cloud KMS, execute uma manutenção simulada nele. Depois de concluir essa operação, o Memorystore for Redis Cluster poderá gravar dados de persistência usando a versão atualizada da chave principal.

Substituir uma chave protegida do Cloud KMS

Se você substituir uma chave protegida do Cloud KMS por uma chave diferente ou uma nova versão da chave primária, o Memorystore para Redis Cluster vai aplicar essa mudança apenas a operações futuras.

A substituição de uma chave protegida afeta seus recursos das seguintes maneiras:

  • Backups: todos os backups subsequentes são criptografados usando a nova chave. Os backups atuais mantêm as chaves originais.
  • Permanência: na próxima vez que o cluster for reiniciado ou tiver um evento de manutenção, a nova chave será usada.
  • Cache principal: substituir essa chave não tem impacto. A CMEK não criptografa dados na memória porque eles não são considerados armazenados.

Como ativar ou restaurar a versão principal da chave CMEK

Se você ativar ou restaurar a versão chave primária da chave, as seguintes condições serão aplicadas a backups e persistência:

  • Você pode criar backups sob demanda e automáticos novamente.
  • O Memorystore for Redis Cluster realiza uma atualização semelhante à usada na manutenção e reativa a persistência.

Restrições da política da organização

O Memorystore for Redis Cluster oferece suporte a restrições de política da organização para CMEK. Ao usar essas restrições, é possível aplicar a proteção por CMEK aos clusters e limitar quais chaves do Cloud KMS podem ser usadas para essa proteção.

É possível configurar as seguintes restrições de política da organização:

  • constraints/gcp.restrictNonCmekServices: use essa restrição para aplicar a proteção da CMEK aos seus clusters. Se a API Memorystore for Redis Cluster estiver na lista de serviços da política Deny para essa restrição, não será possível criar clusters sem proteção da CMEK.
  • constraints/gcp.restrictCmekCryptoKeyProjects: use essa restrição para limitar quais chaves do Cloud KMS podem ser usadas para proteção por CMEK. Se você configurar essa restrição, os clusters que usam a criptografia CMEK precisarão usar uma chave de um projeto, uma pasta ou uma organização permitida.

Como o Memorystore for Redis Cluster e o Memorystore for Redis compartilham o mesmo endpoint (redis.googleapis.com), não é possível aplicar a CMEK a clusters de forma independente das instâncias do Memorystore for Redis.

Para mais informações sobre as restrições da política da organização relacionadas à CMEK que o Google gerencia para o cluster do Memorystore para Redis, consulte Restrições da política da organização.

Preços

O Memorystore for Redis Cluster cobra por um cluster ativado com CMEK da mesma forma que qualquer outro cluster. Não há custos adicionais. Para mais informações, consulte os preços do Memorystore for Redis Cluster.

Você usa a API Cloud KMS para gerenciar a CMEK. Quando você cria um cluster com CMEK, o Memorystore usa a chave periodicamente para criptografar dados.

O Cloud KMS cobra pelo custo da chave e pelas operações de criptografia e descriptografia quando o Memorystore for Redis Cluster usa a chave. Para mais informações, consulte Preços do Cloud KMS.

Limitações

As seguintes limitações se aplicam ao usar a CMEK com o Memorystore para Redis Cluster:

  • Não é possível ativar a CMEK em um cluster atual.
  • A chave, o keyring e o cluster precisam estar na mesma região.
  • É necessário usar o algoritmo de criptografia simétrica para sua chave.
  • As taxas de criptografia e descriptografia do Cloud KMS estão sujeitas a uma cota.

A seguir