Chaves de encriptação geridas pelo cliente (CMEK)

Por predefinição, o Bigtable encripta o conteúdo do cliente em repouso. O Bigtable processa a encriptação por si sem ações adicionais da sua parte. Esta opção chama-se Encriptação predefinida da Google.

Se quiser controlar as suas chaves de encriptação, pode usar chaves de encriptação geridas pelo cliente (CMEK) no Cloud KMS com serviços integrados com CMEK, incluindo o Bigtable. A utilização de chaves do Cloud KMS dá-lhe controlo sobre o respetivo nível de proteção, localização, programação de rotação, utilização e autorizações de acesso, bem como limites criptográficos. A utilização do Cloud KMS também permite monitorizar a utilização das chaves, ver registos de auditoria e controlar os ciclos de vida das chaves. Em vez de a Google possuir e gerir as chaves de encriptação de chaves (KEKs) simétricas que protegem os seus dados, controla e gere estas chaves no Cloud KMS.

Depois de configurar os seus recursos com CMEKs, a experiência de acesso aos seus recursos do Bigtable é semelhante à utilização da encriptação predefinida da Google. Para mais informações acerca das suas opções de encriptação, consulte o artigo Chaves de encriptação geridas pelo cliente (CMEK).

CMEK com chave automática do Cloud KMS

Pode criar CMEKs manualmente para proteger os seus clusters do Bigtable ou usar a chave automática do Cloud KMS. Com a Autokey, os conjuntos de chaves e as chaves são gerados a pedido como parte da criação de recursos no Bigtable. Os agentes de serviço que usam as chaves para operações de encriptação e desencriptação são criados se ainda não existirem e recebem as funções de gestão de identidade e de acesso (IAM) necessárias. Para mais informações, consulte a vista geral do Autokey.

O Autokey cria uma chave predefinida quando cria clusters do Bigtable.

Para configurar as CMEK manualmente, consulte o artigo Use CMEK.

Funcionalidades

  • Segurança: a CMEK oferece o mesmo nível de segurança que a encriptação predefinida da Google, mas oferece mais controlo administrativo.

  • Controlo de acesso aos dados: os administradores podem rodar, gerir o acesso e desativar ou destruir a chave usada para proteger os dados em repouso no Bigtable.

  • Capacidade de auditoria: todas as ações nas suas chaves CMEK são registadas e visíveis no Cloud Logging. As chaves do EKM na nuvem suportam a justificação de acesso a chaves, que adiciona um campo de justificação a todos os pedidos de chaves. Com determinados parceiros de gestão de chaves externas, pode aprovar ou recusar automaticamente estes pedidos com base na justificação.

  • Desempenho comparável: as instâncias protegidas por CMEK do Bigtable oferecem um desempenho comparável ao das instâncias do Bigtable que usam a encriptação predefinida da Google.

  • Flexibilidade: pode usar a mesma chave CMEK em vários projetos, instâncias ou clusters, ou pode usar chaves separadas, consoante as suas necessidades empresariais.

  • Proteção entre regiões: pode ativar as CMEK em instâncias que tenham clusters em qualquer região onde o Bigtable esteja disponível. Cada cluster é protegido por uma chave CMEK na região desse cluster.

Preços

O Cloud KMS cobra o custo da chave e quaisquer operações criptográficas realizadas com essa chave. Consulte os preços do Cloud KMS para ver detalhes.

Os custos de operação são faturados quando o Bigtable pede à chave do Cloud KMS para realizar uma operação de encriptação ou desencriptação. Cada pedido de encriptação ou desencriptação é enviado de todas as tabelas em todos os clusters na instância. Uma vez que o Bigtable usa encriptação de envelope, estes custos por tabela são geralmente baixos, dado o pequeno número de operações criptográficas esperadas. Se armazenar muitas tabelas numa instância protegida por CMEK, os seus custos são mais elevados.

Não existem custos adicionais do Bigtable para usar instâncias com a CMEK ativada.

O que está protegido com a CMEK

Numa instância protegida por CMEK, o Bigtable usa a sua chave CMEK para proteger os dados em repouso. Isto inclui dados em todas as tabelas no cluster. Os dados armazenados no armazenamento de HDD e SSD estão protegidos.

Alguns dados estão protegidos pela encriptação em repouso predefinida da Google e não pela chave CMEK:

  • Um subconjunto de chaves de linhas que marcam os limites do intervalo e são usadas para o encaminhamento
  • Dados de depuração, incluindo despejos de memória e registos operacionais
  • Dados em trânsito ou na memória
  • Um subconjunto de valores de data/hora usados para a recolha de lixo

O Bigtable usa encriptação de envelope para dados em repouso. A chave CMEK é usada como uma chave de encriptação de chaves (KEK) para encriptar outras chaves usadas pelo Bigtable. Quando altera a chave CMEK, o Bigtable só precisa de voltar a encriptar as chaves intermédias.

Ativar CMEK

Em termos gerais, para usar as CMEK com o Bigtable, siga estes passos:

  1. Crie e configure uma chave CMEK em cada região onde os clusters da sua instância vão estar.
  2. Crie uma nova instância do Bigtable, selecionando uma chave CMEK para cada cluster na instância. A chave CMEK de um cluster tem de estar na mesma região que o cluster.
  3. Agende uma rotação de chaves para cada chave.

As aplicações que usam o Bigtable não precisam de especificar uma chave nem uma configuração de encriptação quando leem, escrevem ou eliminam dados. O Bigtable pode aceder à chave em seu nome depois de conceder a função Cloud KMS Encrypter/Decrypter ao agente de serviço do Bigtable.

Para instruções detalhadas, consulte Use CMEK.

Pode usar o seguinte quando trabalha com CMEK para o Bigtable.

Também pode aceder diretamente à Cloud Bigtable Admin API, mas recomendamos vivamente que o faça apenas se não puder usar uma biblioteca cliente do Bigtable que faça chamadas CMEK para a API.

Gestão de chaves

As operações de gestão de chaves são realizadas através do Cloud KMS. O Bigtable não consegue detetar nem agir em função de alterações de chaves até que sejam propagadas pelo Cloud KMS. Algumas operações, como desativar ou destruir uma chave, podem demorar até 4 horas a serem propagadas. Normalmente, as alterações às autorizações de uma chave são propagadas mais rapidamente.

Depois de criar, pelo menos, uma tabela numa instância protegida por CMEK, o Bigtable valida a chave de cada tabela em cada cluster a cada 5 minutos.

Se o Bigtable detetar uma chave desativada, desativa um cluster de cada vez de forma em cascata até que todos os clusters na instância sejam desativados. Depois de o primeiro cluster comunicar que uma chave está desativada ou destruída e até que a instância seja desativada, alguns pedidos de dados podem ter êxito e outros devolvem um erro. Todas as operações de dados enviadas para um cluster que foi desativado devolvem um erro