Por predefinição, todos os dados em repouso no Firestore no modo Datastore são encriptados através da encriptação predefinida da Google. O modo Datastore processa e gere esta encriptação por si sem qualquer ação adicional da sua parte.
Se tiver requisitos regulamentares ou de conformidade específicos relacionados com as chaves que protegem os seus dados, pode usar chaves de encriptação geridas pelo cliente (CMEK) para o modo Datastore. Em vez de a Google gerir as chaves de encriptação que protegem os seus dados, a base de dados do modo Datastore é protegida através de uma chave que controla e gere no Cloud Key Management Service (Cloud KMS).
Esta página descreve as CMEK para o modo Datastore. Para mais informações sobre a CMEK em geral, incluindo quando e por que motivo a ativar, consulte a seguinte documentação do Cloud KMS:
Para instruções sobre como realizar tarefas relacionadas com as CMEK com o modo Datastore, consulte o artigo Use CMEK.
Funcionalidades
- Controlo de dados: a CMEK permite-lhe gerir a chave do KMS. Pode rodar, desativar e destruir a chave usada para encriptar os dados em repouso na base de dados do modo Datastore.
- Desempenho: a CMEK não afeta o SLA do Firestore.
- Auditabilidade: se ativar o registo de auditoria para o Cloud KMS, todas as operações na chave são registadas e visíveis no Cloud Logging.
- Restrições da política da organização: pode usar restrições da política da organização da CMEK para especificar os requisitos de conformidade da encriptação para bases de dados no modo Datastore na sua organização.
Preços
O Cloud KMS cobra o custo da chave e quaisquer operações criptográficas realizadas com essa chave. Para mais informações, consulte os preços do Cloud KMS.
Os custos de operação são faturados quando o modo Datastore pede à chave do Cloud KMS para realizar uma operação de encriptação ou desencriptação. A operação de encriptação/desencriptação pela chave gerida pelo cliente ocorre a cada 5 minutos e não está sincronizada com os pedidos da base de dados. Os custos são geralmente baixos, tendo em conta o número esperado de operações criptográficas geradas pelo modo Datastore. Os custos dos registos de auditoria do Cloud são uma despesa adicional, mas também se espera que sejam geralmente baixos, dado o número esperado de operações criptográficas.
Não existem custos adicionais do modo Datastore para usar a base de dados protegida por CMEK. Além disso, a preçário do modo Datastore continua a aplicar-se.
Se revogar a sua chave para uma base de dados, o custo de armazenamento é cobrado com base no tamanho do último dia em que a chave esteve disponível. Vai continuar a incorrer em custos de armazenamento com essa dimensão da base de dados até que a base de dados seja eliminada ou a chave fique novamente disponível.
O que está protegido com a CMEK
Quando cria uma base de dados protegida por CMEK no modo Datastore, a chave do Cloud KMS é usada para proteger os dados em repouso. Isto inclui dados que armazena num disco ou numa unidade flash, incluindo índices e cópias de segurança. Aplicam-se algumas exceções. Os seguintes tipos de dados são encriptados com a encriptação predefinida da Google e não com a chave CMEK:
- Dados em trânsito ou na memória
- Metadados da base de dados
Como é processado um estado de chave indisponível
As operações de encriptação e desencriptação não são emitidas em todos os pedidos de dados. Em alternativa, o sistema do Firestore sondar o Cloud KMS a cada 5 minutos para verificar se a chave ainda está disponível e, em seguida, executa operações de encriptação e desencriptação se a chave estiver disponível.
Se o sistema detetar que a chave não está disponível, no prazo de 10 minutos, todas as chamadas subsequentes à base de dados do Firestore, incluindo leituras, escritas e consultas, devolvem um erro FAILED_PRECONDITION com a mensagem The customer-managed encryption key required by the requested
resource is not accessible.
Se a base de dados tiver políticas de tempo de vida (TTL) e se os tempos de expiração forem excedidos enquanto a chave estiver indisponível, a eliminação de dados por TTL é atrasada até a chave ser reposta. Se a base de dados tiver operações de longa duração em curso, estas serão afetadas da seguinte forma:
- As operações de importação ou exportação de dados vão deixar de progredir e vão ser marcadas como
Failed. As operações com falhas não vão ser repetidas se a chave for reposta. - As operações de criação de índice e as operações que ativam novas políticas de TTL vão parar de progredir. As operações interrompidas vão ser repetidas se a chave for reposta.
As chaves são consideradas indisponíveis em qualquer situação que impeça intencionalmente o Firestore de aceder à chave. Isto inclui:
- Desativar ou destruir a versão da chave em utilização. Tenha cuidado ao destruir uma versão de chave, porque isto pode causar uma perda de dados irrecuperável.
- Remover a autorização para aceder à chave da conta de serviço do Firestore.
Se a chave for reposta, a operação de sondagem deteta que a chave está novamente disponível. O acesso é reativado, normalmente, em poucos minutos, mas pode demorar até algumas horas em casos raros. Tenha em atenção que algumas operações em chaves do Cloud KMS, como desativar ou destruir uma chave, podem demorar até 3 horas a propagar-se. O Firestore não deteta alterações até que estas entrem em vigor no Cloud KMS.
O restabelecimento de uma chave envolve o seguinte, consoante a situação:
- Reativar uma versão de chave desativada.
- Restaurar uma versão de chave destruída. Antes de ser destruída permanentemente, uma versão da chave é agendada para destruição. Só pode restaurar uma chave durante o período em que uma versão da chave está agendada para destruição. Não pode restaurar uma chave que já tenha sido permanentemente destruída.
- Voltar a conceder a autorização do agente do serviço do Firestore para aceder à chave.
Considerações sobre a rotação de chaves
Quando alterna a chave CMEK, o modo Datastore volta a encriptar a base de dados com a versão principal mais recente da chave CMEK. Durante o processo de reencriptação, mantenha a versão antiga e a nova da chave disponíveis. Quando a reencriptação terminar, a desativação ou a eliminação das versões antigas da chave CMEK não desativa o acesso à base de dados, uma vez que esta está encriptada com a nova versão da chave principal.
Também pode ver as versões das chaves que estão a ser usadas para proteger uma base de dados. Para mais informações, consulte o artigo Veja a chave em utilização.
Considerações sobre chaves externas
Quando usa uma chave do Cloud EKM, a Google não tem controlo sobre a disponibilidade da sua chave gerida externamente no sistema de parceiros de gestão de chaves externas.
Se uma chave gerida externamente não estiver disponível, o modo Datastore continua a suportar operações de base de dados completas com base no melhor esforço durante um máximo de uma hora.
Após uma hora, se o modo Datastore ainda não conseguir estabelecer ligação ao Cloud KMS, o modo Datastore começa a colocar a base de dados offline como medida de proteção. As chamadas à base de dados falham com um erro FAILED_PRECONDITION que inclui detalhes adicionais.
Consulte a documentação do Cloud External Key Manager para mais informações sobre a utilização de chaves externas.
Cópia de segurança e restauro
Uma cópia de segurança usa o mesmo mecanismo de encriptação que a base de dados a partir da qual a criou. Quando uma base de dados do modo Datastore protegida por CMEK cria uma cópia de segurança, encripta a cópia de segurança com a versão da chave principal usada no momento da criação da cópia de segurança.
O modo Datastore cria a primeira cópia de segurança de uma base de dados CMEK 24 horas após a ativação das programações de cópias de segurança.
Para mais informações sobre as cópias de segurança do modo Datastore, consulte o artigo Fazer uma cópia de segurança e restaurar dados.
Uma base de dados restaurada a partir de uma cópia de segurança usa o mesmo mecanismo de encriptação que a cópia de segurança por predefinição. Quando restaura uma base de dados, pode especificar um tipo de encriptação diferente de uma das seguintes formas:
- Restaurar para uma base de dados CMEK com uma chave especificada recentemente.
- Restaurar para uma base de dados não CMEK que use a encriptação predefinida da Google.
- Restaurar para uma base de dados que use a mesma encriptação que a cópia de segurança.
Para mais informações sobre como restaurar uma base de dados do modo Datastore a partir de uma cópia de segurança, consulte o artigo Restaure dados a partir de uma cópia de segurança da base de dados. Para mais informações sobre como restaurar uma base de dados do modo Datastore protegida por CMEK a partir de uma cópia de segurança, consulte o artigo Restaure uma base de dados protegida por CMEK.
Clonar
Por predefinição, uma base de dados clonada de outra base de dados usa o mesmo mecanismo de encriptação que a base de dados de origem. Quando clona uma base de dados, pode especificar um tipo de encriptação diferente de uma das seguintes formas:
- Clonar para uma base de dados CMEK com uma chave especificada recentemente.
- Clonar para uma base de dados não CMEK que use a encriptação predefinida da Google.
- (Predefinição) Clonar para uma base de dados que usa a mesma encriptação que a base de dados de origem.
Para mais informações sobre a clonagem de uma base de dados do modo Datastore, consulte o artigo Clone uma base de dados. Para mais informações sobre a clonagem de uma base de dados do modo Datastore protegida por CMEK, consulte o artigo Clone uma base de dados protegida por CMEK.
Acompanhamento de chaves
Pode usar o acompanhamento de chaves para ver os recursos, por exemplo, bases de dados do modo Datastore, que uma chave protege. Para mais informações sobre o acompanhamento de chaves, consulte o artigo Veja a utilização de chaves.
CMEK e disponibilidade das chaves
Quando as chaves estão indisponíveis ou desativadas, tenha em atenção os seguintes comportamentos que podem ocorrer em bases de dados ativadas com CMEK:
- Pode alterar as definições de recuperação num ponto específico no tempo (PITR) do modo Datastore numa base de dados ativada para CMEK, mesmo que a chave esteja indisponível, porque as definições de PITR são metadados da base de dados, que não são encriptados pela CMEK.
- Pode eliminar uma base de dados CMEK que tenha chaves indisponíveis.
- Quando cria uma base de dados com a CMEK ativada, as chaves desativadas não são apresentadas na lista de chaves disponíveis na Google Cloud consola. Se introduzir manualmente uma chave desativada, o processo de criação da base de dados falha com um erro 400
FAILED_PRECONDITION.
Limitações
- Não pode alterar uma chave para uma base de dados protegida por CMEK. Pode rodar, ativar e desativar chaves.
- As bases de dados protegidas por CMEK suportam o Key Visualizer apenas para dados de entidades e documentos, e não para dados de índice.
- Não pode ativar a CMEK em bases de dados existentes. Só pode ativar as CMEK em novas bases de dados e tem de as ativar quando cria a base de dados. Para migrar dados numa base de dados existente não protegida por CMEK para uma base de dados protegida por CMEK, exporte os dados e, em seguida, importe-os para uma nova base de dados protegida por CMEK. Também pode restaurar ou clonar dados de uma base de dados não CMEK para uma base de dados CMEK.
- O Firestore suporta um número limitado de bases de dados protegidas por CMEK.
- Não suportamos a proteção CMEK com a integração das Cloud Functions (1.ª geração). Se quiser ter proteção CMEK, use funções do Cloud Run com acionadores do Firestore (2.ª geração).
Como os dados podem sair de bases de dados protegidas por CMEK
Os dados copiados pela sua aplicação podem ser armazenados pelos respetivos utilizadores de formas arbitrárias. São necessários controlos de segurança adequados para qualquer aplicação que aceda aos dados do Firestore, de modo a garantir que os dados só são acedidos por pessoas com a autorização adequada. Consulte o IAM para mais detalhes.
Os dados de uma base de dados protegida por CMEK podem ser movidos para uma base de dados não CMEK através da opção Cópia de segurança e restauro, Clonar ou Importar e Exportar. Use os controlos do IAM adequados para conceder autorização para estas ações apenas a utilizadores autorizados. Além disso, as restrições da política da organização da CMEK podem ser usadas para exigir que todas as bases de dados criadas por restauro ou clonagem e todos os contentores do Cloud Storage usados para importação sejam protegidos pela CMEK.