Explicação do gerenciamento de chaves de criptografia no Snowflake¶

Modelo de chave hierárquica¶

Um modelo de chave hierárquica fornece uma estrutura para o gerenciamento de chaves de criptografia do Snowflake. A hierarquia é composta de várias camadas de chaves nas quais cada camada superior de chaves (chaves pais) criptografa a camada abaixo (chaves filhas). Na terminologia de segurança, uma chave pai que codifica todas as chaves filhas é conhecida como “encapsulamento”.

O modelo de chave hierárquica do Snowflake consiste em quatro níveis de chaves:

• A chave raiz

• Chaves mestras de conta

• Chaves mestras de tabela

• Chaves de arquivo

Cada conta de cliente tem uma hierarquia de chaves separada, para chaves em nível de conta, tabela e arquivo, como mostrado na imagem a seguir:

Em um serviço de nuvem multilocatário como o Snowflake, o modelo de chave hierárquico isola cada conta com o uso de chaves mestras de conta separadas. Além do modelo de controle de acesso, que separa o armazenamento de dados do cliente, o modelo de chave hierárquico fornece outra camada de isolamento de conta.

Um modelo de chave hierárquico reduz o escopo de cada camada de chaves. Por exemplo, uma chave mestra de tabela criptografa uma única tabela. Uma chave de arquivo criptografa um único arquivo. Um modelo de chave hierárquico limita a quantidade de dados que cada chave protege e o período durante o qual ela é utilizável.

Rotação de chaves de criptografia¶

Todas as chaves gerenciadas pelo Snowflake são automaticamente alternadas pelo Snowflake quando têm mais de 30 dias. As chaves ativas são desativadas e novas chaves são criadas. Quando o Snowflake determina que a chave desativada não é mais necessária, a chave é automaticamente destruída. Quando ativa, uma chave é usada para criptografar os dados e está disponível para uso pelo cliente. Quando desativada, a chave é usada somente para descriptografar dados e só está disponível para acessar os dados.

Ao encapsular as chaves filhas na hierarquia de chaves, ou ao inserir dados em uma tabela, somente a chave atual e ativa é usada para criptografar dados. Quando uma chave é destruída, ela não é usada para criptografia ou descriptografia. A rotação regular limita o ciclo de vida das chaves a um período restrito.

A imagem seguinte ilustra a rotação de chaves para uma chave mestra de tabela (TMK) ao longo de um período de três meses:

A rotação TMK funciona da seguinte forma:

• A versão 1 do TMK está ativa em abril. Os dados inseridos nesta tabela em abril são protegidos com TMK v1.

• Em maio, este TMK é alternado: TMK v1 é desativado e uma nova chave completamente aleatória, TMK v2, é criada. TMK v1 agora é usado apenas para descriptografar dados de abril. Os novos dados inseridos na tabela são codificados usando TMK v2.

• Em junho, o TMK é alternado novamente: O TMK v2 é desativado e um novo TMK, v3, é criado. TMK v1 é usado para descriptografar dados de abril, TMK v2 é usado para descriptografar dados de maio e TMK v3 é usado para criptografar e descriptografar novos dados inseridos na tabela em junho.

Como mencionado anteriormente, a rotação de chaves limita o período em que uma chave é usada ativamente para criptografar dados. Em conjunto com o modelo de chaves hierárquico, a rotação de chaves restringe ainda mais a quantidade de dados que uma versão de chave protege. A limitação da vida útil de uma chave é recomendada pelo National Institute of Standards and Technology (NIST) para aumentar a segurança.

Periodic Rekeying¶

Esta seção continua a explicação do ciclo de vida da chave mestra de conta e tabela. Rotação de chaves de criptografia descreveu a rotação de chaves, que substitui as chaves ativas por novas chaves periodicamente e desativa as chaves antigas. O rechaveamento de dados periódico completa o ciclo de vida.

Enquanto a rotação de chaves assegura que uma chave seja transferida de seu estado ativo para um estado desativado, o rechaveamento assegura que uma chave seja transferida de seu estado desativado para ser destruída.

Se o rechaveamento periódico for ativado, então quando a chave de criptografia desativada para uma tabela tiver mais de um ano, o Snowflake cria automaticamente uma nova chave de criptografia e criptografa novamente todos os dados anteriormente protegidos pela chave desativada usando a nova chave. A nova chave é usada para descriptografar os dados da tabela a partir de então.

A imagem a seguir mostra o rechaveamento periódico de um TMK para uma única tabela:

O rechaveamento periódico funciona desta forma:

• Em abril do ano seguinte, após o TMK v1 ter sido desativado por um ano inteiro, ele é recodificado (geração 2) usando uma chave aleatória totalmente nova.

  Os arquivos de dados protegidos por TMK v1 geração 1 são descriptografados e recriptografados usando TMK v1 geração 2. Sem nenhum outro propósito, o TMK v1 geração 1 é destruído.

• Em maio, o Snowflake executa o mesmo processo de rechaveamento sobre os dados de tabela protegidos por TMK v2.

• E assim por diante.

Neste exemplo, o ciclo de vida de uma chave é limitado a uma duração total de um ano.

O rechaveamento limita a duração total do uso de uma chave pelo destinatário, seguindo as recomendações do NIST. Além disso, ao recodificar dados, o Snowflake pode aumentar o tamanho das chaves de criptografia e utilizar melhores algoritmos de criptografia que podem ser padronizados desde que a geração de chaves anterior foi criada.

O rechaveamento, portanto, garante que todos os dados do cliente, novos e antigos, sejam criptografados com a mais recente tecnologia de segurança.

O Snowflake recodifica arquivos de dados online, em segundo plano, sem qualquer impacto para as cargas de trabalho dos clientes em execução no momento. Os dados que estão sendo recodificados estão sempre disponíveis para você. Não é necessário tempo de inatividade de serviço para recodificar dados, e você não encontra nenhum impacto no desempenho de sua carga de trabalho. Este benefício é um resultado direto da arquitetura do Snowflake de separar o armazenamento e os recursos computacionais.

Módulo de segurança de hardware¶

Snowflake depende de módulos de segurança de hardware hospedados na nuvem (HSMs) para garantir que o armazenamento e o uso de chaves sejam seguros. Cada plataforma de nuvem tem serviços HSM diferentes e isso afeta como o Snowflake usa o serviço HSM em cada plataforma:

• No AWS e no Azure, o Snowflake usa o HSM para criar e armazenar a chave raiz.

• No Google Cloud, o serviço HSM é disponibilizado por meio da API do Google Cloud KMS (serviço de gerenciamento de chaves). Snowflake usa o Google Cloud KMS para criar e armazenar a chave raiz em partições de HSM de multilocatários.

Para todas as plataformas de nuvem e todas as chaves na hierarquia de chaves, uma chave armazenada em HSM é usada para desempacotar uma chave na hierarquia. Por exemplo, para descriptografar a chave mestra da tabela, a chave em HSM desempacota a chave mestra da conta. Esse processo ocorre no HSM. Após a conclusão desse processo, uma operação de software descriptografa a chave mestra da tabela com a chave mestra da conta.

A imagem a seguir mostra a relação entre o HSM, as chaves mestras de conta, as chaves mestras de tabela e as chaves de arquivo:

Benefícios das chaves gerenciadas pelo cliente¶

As vantagens das chaves gerenciadas pelo cliente incluem:

Controle sobre o acesso aos dados:

Você tem controle total sobre sua chave mestra no serviço de gerenciamento de chaves e, portanto, sobre seus dados no Snowflake. É impossível descriptografar os dados armazenados em sua conta Snowflake sem que você libere esta chave.

Desativação do acesso devido a uma violação de dados:

Se você experimentar uma violação de segurança, pode desativar o acesso à sua chave e interromper todas as operações de dados em sua conta Snowflake.

Propriedade do ciclo de vida dos dados:

Usando chaves gerenciadas pelo cliente, você pode alinhar suas exigências de proteção de dados com seus processos comerciais. O controle explícito sobre sua chave proporciona proteção durante todo o ciclo de vida dos dados, desde a criação até a exclusão.

Requisitos importantes para chaves gerenciadas pelo cliente¶

As chaves gerenciadas pelo cliente oferecem benefícios significativos de segurança, mas também têm requisitos cruciais e fundamentais que você deve seguir continuamente para proteger sua chave mestra:

Confidencialidade:

Você deve manter sua chave sempre segura e confidencial.

Integridade:

Você deve garantir que sua chave esteja protegida contra modificações ou exclusões impróprias.

Disponibilidade:

Para executar consultas e acessar seus dados, você deve garantir que sua chave esteja continuamente disponível para o Snowflake.

Por projeto, uma chave inválida ou indisponível resultará em uma interrupção de suas operações de dados do Snowflake até que uma chave válida seja novamente disponibilizada ao Snowflake.

Entretanto, o Snowflake foi projetado para lidar com problemas de disponibilidade temporária (até 10 minutos) causados por problemas comuns, tais como falhas de comunicação na rede. Após 10 minutos, se a chave permanecer indisponível, todas as operações de dados em sua conta Snowflake cessarão completamente. Uma vez restabelecido o acesso à chave, as operações de dados podem ser iniciadas novamente.

O não cumprimento destes requisitos pode comprometer significativamente a integridade de seus dados, o que pode significar que seus dados ficam temporariamente inacessíveis ou que estão permanentemente desativados. Além disso, o Snowflake não pode ser responsável por problemas de terceiros ou contratempos administrativos causados por sua organização durante a manutenção de sua chave.

Por exemplo, se um problema com o serviço de gerenciamento de chaves resultar na indisponibilidade de sua chave, suas operações de dados serão impactadas. Estas questões devem ser resolvidas entre você e a equipe de suporte para o serviço de gerenciamento de chaves. Da mesma forma, se sua chave for adulterada ou destruída, todos os dados existentes em sua conta Snowflake se tornarão ilegíveis até que a chave seja restaurada.

Compatibilidade de recursos¶

Os seguintes recursos não são compatíveis com Tri-Secret Secure:

• Registro de imagens.

• Tabelas híbridas:

  Você não poderá usar tabelas híbridas se sua conta Snowflake estiver habilitada para usar Tri-Secret Secure. Antes de usar tabelas híbridas, verifique se sua conta Snowflake está habilitada para Tri-Secret Secure entrando em contato com o suporte Snowflake.

Habilitação do Tri-Secret Secure¶

Para habilitar o Snowflake Tri-Secret Secure para sua conta Business Critical (ou superior), entre em contato com o suporte Snowflake.