Este documento descreve como usar chaves de criptografia gerenciadas pelo cliente (CMEK) no Cloud Key Management Service (Cloud KMS) para suas instâncias do Memorystore para Redis. O documento também descreve quais dados são criptografados no armazenamento permanente e como as instâncias se comportam durante os principais eventos do ciclo de vida.
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 novas instâncias. Não é possível aplicar a CMEK a instâncias 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 instâncias. Para criptografar esses dados, o Memorystore para Redis 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 na Memorystore para Redis.
- Criptografia KEK: as KEKs criptografam as DEKs.
O Memorystore para Redis 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 na sua instância.
O diagrama a seguir mostra como uma instância 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.
O diagrama a seguir mostra como o Memorystore para Redis descriptografa dados criptografados com a CMEK. Para acessar esses dados criptografados, o Memorystore for Redis 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 a instância usa para descriptografar os dados armazenados.
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 e compartilhamento de dados pessoais e cenários de compliance.
- Persistência: o Memorystore para Redis é compatível com a persistência do banco de dados Redis (RDB), que permite salvar snapshots dos seus dados em um armazenamento durável.
- Metadados relacionados a recursos de segurança, como
AUTHe criptografia em trânsito. Para mais informações, consulte Sobre o Redis AUTH 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 uma instância com CMEK ativada, conceda a função
roles/cloudkms.cryptoKeyEncrypterDecrypter à conta de serviço do Memorystore para Redis
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 uma instância do Memorystore para Redis, selecione essa chave para criptografar a instância. É possível criar um projeto para as chaves e instâncias ou projetos diferentes para cada um deles.
A CMEK está disponível em todos os locais de instâncias do Memorystore para Redis. Crie o keyring e a chave na mesma região em que você quer criar a instância. Uma chave para uma região multirregional ou global não funciona. Se as regiões ou locais não corresponderem, uma solicitação para criar a instância 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.
No console do Google Cloud , uma instância suspensa mostra uma dica de ferramenta com um ponto de exclamação vermelho na página Instâncias. Se você passar o cursor sobre a dica, um status No state vai aparecer. Quando a chave ficar acessível,
o Memorystore para Redis vai retomar a instância automaticamente.
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 ao criar a instância, o Memorystore for Redis não vai criar a instância. Além disso, se a chave externa ficar indisponível a qualquer momento depois que você criar a instância, o Memorystore para Redis vai suspender a instância até que o acesso seja restaurado.
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 as instâncias e os dados protegidos se comportam durante eventos importantes do ciclo de vida, como desativação, destruição, ativação ou restauração de versões de chaves. As seções também explicam o impacto da substituição de uma chave do Cloud KMS, oferecem orientação sobre a recriptografia manual de dados e detalham como importar ou exportar dados de uma instância ativada para CMEK.
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ê quiser garantir que não haja acesso aos dados na sua instância, desative a versão da chave primária. Isso suspende sua instância. Além disso, se uma CMEK em uso for desativada ou destruída, o Memorystore para Redis vai suspender a instância. Isso inclui qualquer versão mais antiga da chave usada pela instância.
Para saber se o Memorystore para Redis suspendeu sua instância, use uma das seguintes interfaces:
- Google Cloud console: na página Instâncias, uma dica de ferramenta com um ponto de exclamação vermelho aparece ao lado da sua instância. Se você passar o cursor sobre a dica, um status Sem estado vai aparecer.
- CLI gcloud: use o comando
gcloud redis instances describe. Verifique o campostate. Uma instância suspensa não mostra um estadoREADYouREPAIRING.
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 for Redis aplicará essa mudança apenas a operações futuras.
A substituição de uma chave protegida afeta seus recursos das seguintes maneiras:
- Backups: o Memorystore para Redis exporta backups para o Cloud Storage. Portanto, as configurações de criptografia do bucket de destino (não a CMEK da instância) controlam como os dados exportados são criptografados.
- Permanência: na próxima vez que a instância for reiniciada 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 dados em repouso.
Recriptografar manualmente dados protegidos por CMEK
O Memorystore para Redis não oferece suporte ao reencapsulamento sob demanda de dados em repouso. Não é possível acionar um processo manualmente para usar uma nova versão de chave e criptografar novamente os backups ou arquivos de persistência ativos. No entanto, é possível usar a nova versão da chave para criptografar dados recém-gravados.
Importar ou exportar dados para uma instância ativada para CMEK
Se quiser que os dados exportados permaneçam protegidos por uma CMEK, configure a CMEK no bucket de destino do Cloud Storage antes de exportar os dados para ele. Se os dados já estiverem armazenados em uma instância ativada para CMEK, não há requisitos ou restrições especiais para importar esses dados para uma nova instância. Para mais informações, consulte Sobre a importação e exportação de dados.
Como ativar ou restaurar a versão principal da chave CMEK
Se você ativar ou restaurar a versão da chave primária, o Memorystore para Redis vai retomar sua instância automaticamente.
Restrições da política da organização
O Memorystore para Redis aceita restrições de política da organização para CMEK. Ao usar essas restrições, é possível aplicar a proteção CMEK às instâncias 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 às suas instâncias. Se a API Memorystore for Redis estiver na lista de serviçosDenyda política para essa restrição, não será possível criar instâncias 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, as instâncias 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 e o Memorystore for Redis Cluster compartilham o mesmo endpoint (redis.googleapis.com), não é possível aplicar a CMEK a instâncias independentemente dos clusters no Memorystore for Redis Cluster.
Para mais informações sobre as restrições da política da organização relacionadas à CMEK que o Google gerencia para o Memorystore for Redis, consulte Restrições da política da organização.
Preços
O Memorystore para Redis cobra por uma instância habilitada para CMEK da mesma forma que qualquer outra instância. Não há custos adicionais. Para mais informações, consulte Preços do Memorystore para Redis.
Você usa a API Cloud KMS para gerenciar a CMEK. Quando você cria uma instância 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 para Redis 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:
- Não é possível ativar a CMEK em uma instância atual.
- A chave, o keyring e a instância 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
- Saiba mais sobre o CMEK.
- Saiba como melhorar a segurança de dados usando a CMEK.
- Saiba mais sobre backups.
- Saiba mais sobre persistência.