Chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês)

Por padrão, todos os dados em repouso no Bigtable são criptografados usando a criptografia padrão do Google. O Bigtable executa e gerencia essa criptografia automaticamente para você sem que você precise executar nenhuma ação adicional.

Caso você precise atender a requisitos específicos de compliance e conformidade relacionados às chaves que protegem seus dados, use as chaves de criptografia gerenciadas pelo cliente (CMEKs, na sigla em inglês) para o Bigtable. Em vez do Google gerenciar as chaves de criptografia que protegem seus dados, sua instância do Bigtable é protegida usando uma chave que você controla e gerencia no Cloud Key Management Service (Cloud KMS).

Nesta página, você verá a descrição de CMEK para o Bigtable. Para obter mais informações sobre CMEK em geral, como quando e por que ativar, consulte a documentação do Cloud KMS. Para instruções sobre como executar tarefas relacionadas a CMEK com o Bigtable, consulte Como usar CMEK.

Recursos

Segurança: o CMEK oferece o mesmo nível de segurança da criptografia padrão do Google, mas fornece mais controle administrativo.
Controle de acesso a dados: os administradores podem girar, gerenciar o acesso e desativar ou destruir a chave usada para proteger os dados em repouso no Bigtable.
Auditoria: todas as ações nas chaves CMEK são registradas e ficam visíveis no Cloud Logging. As chaves do Cloud EKM são compatíveis com a justificação de acesso de chaves, que adiciona um campo de justificativa a todas as solicitações de chaves. Os parceiros de gerenciamento de chaves externos permitem aprovar ou negar automaticamente essas solicitações com base na justificativa.
Desempenho comparável: as instâncias protegidas do CMEK do Bigtable oferecem desempenho comparável às instâncias do Bigtable que usam criptografia padrão do Google.
Flexibilidade: é possível usar a mesma chave CMEK em vários projetos, instâncias ou clusters ou usar chaves separadas, dependendo das necessidades de seus negócios.
Proteção entre regiões: ative a CMEK em instâncias que tenham clusters em qualquer região em que o Bigtable esteja disponível. Cada cluster é protegido por uma chave de CMEK na região do cluster.

Preços

O Cloud KMS cobra pelo custo da chave e de todas as operações criptográficas executadas usando essa chave. Para mais detalhes, consulte Preços do Cloud KMS.

Você é cobrado pelos custos da operação quando o Bigtable pede para que a chave do Cloud KMS execute uma operação de criptografia ou descriptografia. Cada solicitação de criptografia ou descriptografia é enviada de todas as tabelas em cada cluster na instância. Como o Bigtable usa criptografia de envelope, esses custos por tabela geralmente são baixos, devido ao pequeno número de operações criptográficas esperadas. Se você armazenar muitas tabelas em uma instância protegida pela CMEK, seus custos serão mais altos.

Não há custos adicionais do Bigtable para o uso de instâncias ativadas pela CMEK.

O que é protegido com a CMEK

Em uma instância protegida pela CMEK, o Bigtable usa a chave CMEK para proteger os dados em repouso. Isso inclui dados em todas as tabelas do cluster. Os dados armazenados no armazenamento HDD e SSD estão protegidos.

Alguns dados são protegidos pela criptografia padrão do Google em repouso, e não pela chave CMEK:

Um subconjunto de chaves de linha que marcam limites de intervalo e usado para o roteamento
Como depurar dados, incluindo dumps de núcleo e registros operacionais
Dados em trânsito ou memória
Um subconjunto de valores de carimbo de data/hora usados para a coleta de lixo

O Bigtable usa criptografia de envelope para dados em repouso. A chave CMEK é usada como chave de criptografia (KEK, na sigla em inglês) para criptografar outras chaves usadas pelo Bigtable. Quando você alterna a chave CMEK, o Bigtable só precisa recriptografar as chaves intermediárias.

Como ativar a CMEK

Em geral, para usar a CMEK com o Bigtable, é preciso seguir estas etapas:

Crie e configure uma chave CMEK em cada região onde os clusters da instância estarão.
Crie uma nova instância do Bigtable selecionando uma chave CMEK para cada cluster na instância. A chave CMEK de um cluster precisa estar na mesma região do cluster.
Programe uma rotação de chaves para cada chave.

Os aplicativos que usam o Bigtable não precisam especificar uma configuração de chave ou criptografia ao ler, gravar ou excluir dados. O Bigtable poderá acessar a chave em seu nome depois que você conceder o papel Criptografador/Descriptografador do Cloud KMS a um agente de serviços do Bigtable, que é um tipo de conta de serviços gerenciada pelo Google.

Para instruções detalhadas, consulte Usar CMEK.

Use o seguinte quando trabalhar com a CMEK para o Bigtable.

Console do Google Cloud
Google Cloud CLI
Todas as bibliotecas de cliente com disponibilidade geral (GA, na sigla em inglês) que chamam as APIs do Cloud Bigtable.

Você também pode acessar a API Cloud Bigtable Admin diretamente, mas recomendamos que faça isso apenas se não for possível usar uma biblioteca de cliente do Bigtable que faça chamadas de CMEK para a API.

Gerenciamento de chaves

As operações de gerenciamento de chaves são executadas com o Cloud KMS. O Bigtable não pode detectar nem agir sobre nenhuma alteração de chave até que seja propagado pelo Cloud KMS. Algumas operações, como a desativação ou a destruição de uma chave, podem levar até quatro horas para serem propagadas; as alterações nas permissões de uma chave geralmente se propagam mais rapidamente.

Depois que você cria pelo menos uma tabela em uma instância protegida por CMEK, o Bigtable valida a chave para cada tabela em cada cluster a cada cinco minutos.

Se o Bigtable detectar uma chave desativada, ele desativará um cluster por vez em cascata até que todos os clusters na instância sejam desativados. Depois que o primeiro cluster informa que uma chave é desativada ou destruída e até que a instância seja desativada, algumas solicitações de dados podem ser bem-sucedidas e outras retornam um erro. As operações de dados enviadas a um cluster que foi desativado retornam um erro FAILED_PRECONDITION ou NOT_FOUND.

Além disso, como a replicação do Bigtable tem consistência posterior, é possível que um cluster tenha reconhecido uma solicitação de gravação, mas ainda não o tenha sido replicado para os outros clusters na instância antes da desativação.

O processo do Bigtable que desativa automaticamente todos os clusters em uma instância depois que uma chave é desativada pode levar várias horas. Para evitar esse estado, recomendamos que você sempre desative todas as chaves de uma instância ao mesmo tempo.

Quando um cluster Bigtable é desativado, as seguintes operações de administrador são restritas a toda a instância:

Como criar um cluster
Excluir um cluster
Como criar uma tabela
Como modificar um grupo de colunas
Como restaurar uma tabela

Você ainda pode excluir a instância, excluir uma tabela e excluir um backup.

Se as chamadas do Bigtable para o Cloud KMS detectarem que uma chave desativada anteriormente foi reativada, o Cloud KMS restaurará o acesso ao cluster do Bigtable automaticamente.

Se uma chave do Cloud KMS for destruída, qualquer instância do Bigtable que tenha um cluster criptografado com ela ficará permanentemente inacessível.

Como um status de chave indisponível é tratado

Em cenários raros, como em períodos em que o Cloud KMS não está disponível, o Bigtable talvez não consiga recuperar o status da sua chave do Cloud KMS.

Caso o cluster do Bigtable esteja protegido por uma chave ativada no momento em que o Bigtable não conseguir se comunicar com o Cloud KMS, o Bigtable continuará a oferecer suporte a todas as operações da instância da melhor maneira possível, de maneira eficiente, usando chaves em cache derivadas da chave do Cloud KMS por um período de até uma hora, para minimizar o impacto de qualquer incidente na carga de trabalho.

Após uma hora, se o Bigtable ainda não conseguir se conectar ao Cloud KMS, o Bigtable começará a disponibilizar a instância off-line como medida de proteção. Os dados na sua instância do Bigtable permanecem inacessíveis até que a instância possa ser reconectada com o Cloud KMS, e o Cloud KMS responde que a chave está ativa.

Por outro lado, se um cluster na instância do Bigtable estiver protegido por uma chave que foi desativada antes do Bigtable não conseguir se comunicar com o Cloud KMS, sua instância permanecerá inacessível até conseguir se reconectar ao Cloud KMS e reativar sua chave.

Considerações sobre chaves externas

Quando você usa uma chave do Cloud EKM, o Google não tem controle sobre a disponibilidade da sua chave gerenciada externamente no sistema de parceiros de gerenciamento de chaves externas.

Se a chave com gerenciamento externo não estiver disponível, o Bigtable continuará a oferecer suporte a operações de cluster usando uma versão em cache da chave, por até uma hora.

Se você planeja usar uma chave externa para uma instância do Bigtable que tem clusters em mais de uma região, verifique se a chave é compatível nessas regiões. Para saber mais detalhes, consulte Administradores e regiões de chave externos. Além disso, não use uma combinação de chaves externas e não externas na mesma instância.

Para saber mais sobre como usar chaves externas com o Cloud Key Management Service, consulte Gerenciador de chaves externo do Cloud (Cloud EKM).

Políticas da organização

O Bigtable aceita restrições de política da organização para ajudar a garantir o uso de CMEK em uma organização. Para detalhes sobre como usar as políticas da organização, consulte Políticas da organização de CMEK.

Backups

Como outros dados, um backup é protegido pela chave CMEK para o cluster no qual o backup é armazenado. Novas tabelas restauradas de um backup são protegidas pela chave de CMEK ou pelas chaves do cluster em que são restauradas. Para mais detalhes sobre como a CMEK afeta backups e operações de restauração, consulte Backups. Para saber como criar ou restaurar a partir de um backup, consulte Como gerenciar backups.

Geração de registros

Você pode auditar as solicitações que o Bigtable envia para o Cloud KMS em seu nome no Cloud Logging, se você tiver registros de auditoria do Cloud KMS ativados para a API do Cloud KMS no projeto. Você pode esperar algumas entradas de registro a cada cinco minutos por tabela em cada cluster.

Limitações

A CMEK só pode ser configurada no nível do cluster. Não é possível configurar a CMEK em backups, tabelas ou perfis de aplicativo.
A chave CMEK de um cluster precisa estar na mesma região que o cluster. Ao criar um keyring do Cloud KMS, selecione a região que corresponde à configuração por zona planejada do Bigtable.
A configuração de criptografia de um recurso do Bigtable (instância, cluster, tabela ou backup) é imutável.
- Não é possível converter instâncias que não são da CMEK para usar CMEK.
- Não é possível converter instâncias de CMEK para usar a criptografia padrão do Google.
- Clusters criados com uma chave CMEK não podem ser reconfigurados para usar uma chave diferente.
Recursos do Bigtable protegidos por CMEK (instâncias, clusters, tabelas ou backups) vinculados a uma chave que se tornou inacessível como resultado de uma ação acionada pelo usuário (como desativar ou destruir uma chave, ou revogando o papel de criptografador/descriptografador) por mais de 30 dias consecutivos são excluídos automaticamente.
Caso reative uma chave CMEK desativada para restaurar o acesso a instâncias do Bigtable protegidas por essa chave, algumas solicitações de API de dados podem expirar enquanto seus dados estiverem on-line novamente.
Por até cinco minutos após a criação de uma tabela em uma instância protegida pela CMEK, a versão e o status de chave podem ser informados como desconhecidos. No entanto, os dados gravados na tabela ainda serão protegidos com a chave CMEK durante esse período.
Desativar ou excluir apenas uma versão em vez de todas as versões de uma chave que o Bigtable usa pode resultar em um comportamento imprevisível. Sempre desative ou exclua todas as versões de uma chave CMEK.

A seguir

Saiba como usar a CMEK com o Bigtable.