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, autorizações de acesso e 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.

A chave automática do Cloud KMS cria uma chave predefinida quando é criado um cluster do Bigtable, a menos que o cluster seja criado na consola. A chave automática do Cloud KMS não cria chaves para recursos do Bigtable que não sejam clusters.

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 à API Cloud Bigtable Admin, 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 FAILED_PRECONDITION ou NOT_FOUND.

Além disso, uma vez que a replicação do Bigtable é eventualmente consistente, é possível que um cluster tenha confirmado um pedido de gravação, mas ainda não o tenha replicado para os outros clusters na instância antes de ter sido desativado.

O processo do Bigtable de desativação automática de todos os clusters numa instância após a desativação de uma chave pode demorar várias horas. Para evitar este estado, recomendamos que desative sempre todas as chaves de uma instância ao mesmo tempo.

Quando um cluster do Bigtable está desativado, as seguintes operações de administração estão restritas para toda a instância:

  • Criar um cluster
  • Eliminar um cluster
  • Criar uma tabela
  • Modificar uma família de colunas
  • Restaurar uma tabela

Continua a poder eliminar a instância, eliminar uma tabela e eliminar uma cópia de segurança.

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

Se uma chave do Cloud KMS tiver sido destruída, qualquer instância do Bigtable que tenha um cluster encriptado com essa chave torna-se permanentemente inacessível.

Como é processado um estado de chave indisponível

Em cenários raros, como durante períodos em que o Cloud KMS está indisponível, o Bigtable pode não conseguir obter o estado de uma chave do Cloud KMS.

Se um cluster do Bigtable estiver protegido por uma chave ativada no momento em que o Bigtable não conseguir comunicar com o Cloud KMS, o Bigtable continua a suportar operações de instância completas com base no melhor esforço durante um período máximo de uma hora, para minimizar o impacto de qualquer incidente deste tipo na sua carga de trabalho.

Após uma hora, se o Bigtable ainda não conseguir estabelecer ligação ao Cloud KMS, o Bigtable começa a colocar a instância offline como medida de proteção. Os dados na sua instância do Bigtable permanecem inacessíveis até que a instância consiga voltar a ligar-se ao Cloud KMS e o Cloud KMS responda que a chave está ativa.

Por outro lado, se um cluster na sua instância do Bigtable estiver protegido por uma chave que foi desativada antes do momento em que o Bigtable não consegue comunicar com o Cloud KMS, a sua instância permanece inacessível até conseguir voltar a ligar-se ao Cloud KMS e reativar a chave.

Considerações sobre chaves externas

Quando usa um 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 a chave gerida externamente estiver indisponível, o Bigtable continua a suportar as operações de cluster com base no melhor esforço durante um máximo de uma hora.

Após uma hora, se o Bigtable ainda não conseguir estabelecer ligação ao Cloud KMS, começa a colocar a instância offline como medida de proteção. Os dados na sua instância do Bigtable permanecem inacessíveis até que a instância consiga estabelecer novamente ligação ao Cloud KMS e o Cloud KMS responda que a chave externa está ativa.

Se planeia usar uma chave externa para uma instância do Bigtable que tenha clusters em mais do que uma região, certifique-se de que a chave é suportada nessas regiões. Para ver detalhes, consulte o artigo Gestores de chaves externos e regiões. Além disso, não deve usar uma combinação de chaves externas e não externas na mesma instância.

Para saber mais sobre a utilização de chaves externas com o Cloud Key Management Service, consulte o Cloud External Key Manager (Cloud EKM).

Políticas da organização

O Bigtable suporta restrições de políticas da organização para ajudar a garantir a utilização da CMEK numa organização. Para ver detalhes sobre como usar as políticas de organização, consulte o artigo Políticas de organização da CMEK.

Cópias de segurança

Tal como outros dados, uma cópia de segurança é protegida pela chave CMEK do cluster no qual a cópia de segurança está armazenada. As novas tabelas restauradas a partir de uma cópia de segurança são protegidas pela chave ou pelas chaves CMEK do cluster onde são restauradas. Para mais detalhes sobre como a CMEK afeta as cópias de segurança e as operações de restauro, consulte a secção Cópias de segurança. Para saber como criar ou restaurar a partir de uma cópia de segurança, consulte o artigo Gerir cópias de segurança.

Registo

Pode auditar os pedidos que o Bigtable envia ao Cloud KMS em seu nome no Cloud Logging, se tiver ativado os registos de auditoria do Cloud KMS para a API Cloud KMS no seu projeto. Pode esperar algumas entradas de registo a cada 5 minutos, aproximadamente, por tabela em cada cluster.

Limitações

  • A CMEK só pode ser configurada ao nível do cluster. Não pode configurar o CMEK em cópias de segurança, tabelas nem perfis de apps.

  • A chave CMEK de um cluster tem de estar na mesma região que o cluster. Quando criar um conjunto de chaves do Cloud KMS, certifique-se de que seleciona a região que corresponde à sua configuração zonal planeada do Bigtable.

  • A configuração de encriptação de um recurso do Bigtable (uma instância, um cluster, uma tabela ou uma cópia de segurança) é imutável.

    • Não é possível converter instâncias não CMEK para usar CMEK.
    • Não é possível converter instâncias de CMEK para usar a encriptação predefinida da Google.
    • Não é possível reconfigurar os clusters criados com uma chave CMEK para usar uma chave diferente.

  • Os recursos do Bigtable protegidos por CMEK (instâncias, clusters, tabelas ou cópias de segurança) associados a uma chave que se tornou inacessível como resultado de uma ação acionada pelo utilizador (como desativar ou destruir uma chave, ou revogar a função de encriptador/desencriptador) durante mais de 30 dias consecutivos são eliminados automaticamente.

  • Se reativar uma chave CMEK desativada para restaurar o acesso a instâncias do Bigtable protegidas por essa chave, alguns pedidos da API Data podem atingir o limite de tempo enquanto os seus dados são colocados novamente online.

  • Até cinco minutos após a criação de uma tabela numa instância protegida por CMEK, a versão da chave e o estado da chave podem ser comunicados como desconhecidos. No entanto, todos os dados escritos na tabela continuam protegidos com a chave CMEK durante esse período.

  • A desativação ou a eliminação de apenas uma versão em vez de todas as versões de uma chave que o Bigtable usa pode resultar num comportamento imprevisível. Desative ou elimine sempre todas as versões de uma chave CMEK.

O que se segue?