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

Este tópico apresenta conceitos relacionados a chaves gerenciadas pelo Snowflake, chaves gerenciadas pelo cliente e Tri-Secret Secure.

Neste tópico:

Visão geral

O Snowflake gerencia chaves de criptografia de dados para proteger os dados dos clientes. Esse gerenciamento ocorre automaticamente sem qualquer necessidade de intervenção do cliente.

Os clientes podem usar o serviço de gerenciamento de chaves na plataforma de nuvem que hospeda sua conta Snowflake para manter sua própria chave de criptografia adicional.

Quando ativada, a combinação de uma chave mantida pelo Snowflake e uma chave gerenciada pelo cliente cria uma chave mestra composta para proteger os dados do Snowflake. Isto é chamado de Tri-Secret Secure.

Chaves gerenciadas pelo Snowflake

Todos os dados dos clientes Snowflake são criptografados por padrão usando as mais recentes normas de segurança e práticas recomendadas. O Snowflake usa criptografia forte AES de 256 bits com um modelo de chave hierárquica baseado em um módulo de segurança de hardware.

As chaves são alternadas de forma automática e regular pelo serviço Snowflake, e os dados podem ser automaticamente recriptografados (recodificados) regularmente. A criptografia de dados e o gerenciamento de chaves são totalmente transparentes e não requerem nenhuma configuração ou gerenciamento.

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:

Snowflake's hierarchical key model

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:

Key rotation of one table master key (TMK) over a time period of three months.

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.

Nota

Para as contas Enterprise Edition, os usuários com a função ACCOUNTADMIN (ou seja, seus administradores de conta) podem habilitar o rechaveamento usando o parâmetro ALTER ACCOUNT e o parâmetro PERIODIC_DATA_REKEYING:

ALTER ACCOUNT SET PERIODIC_DATA_REKEYING = true;
Copy

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

Rekeying one table master key (TMK) after one year

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.

Impacto do rechaveamento no Time Travel e no Fail-safe

Os períodos de retenção do Time Travel e Fail-safe não são afetados pelo rechaveamento. O rechaveamento é transparente para ambos os recursos. Entretanto, alguns custos adicionais de armazenamento estão associados ao rechaveamento dos dados no Fail-safe (ver próxima seção).

Impacto do rechaveamento no uso do armazenamento

Clientes Snowflake são cobrados por armazenamento adicional para proteção Fail-safe dos arquivos de dados que foram recodificados. Para estes arquivos, uma proteção Fail-safe de 7 dias é cobrada.

Isto é, por exemplo, os arquivos de dados com a chave antiga no Amazon S3 já estão protegidos pelo Fail-safe, e os arquivos de dados com a nova chave no Amazon S3 também são adicionados ao Fail-safe, levando a uma segunda cobrança, mas apenas para o período de 7 dias.

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:

Key hierarchy rooted in Hardware Security Module

Chaves gerenciadas pelo cliente

Uma chave gerenciada pelo cliente é uma chave mestra de criptografia que o cliente mantém no serviço de gerenciamento de chaves para o provedor da nuvem que hospeda sua conta Snowflake. Os serviços de gerenciamento de chaves para cada plataforma são:

A chave gerenciada pelo cliente pode então ser combinada com uma chave gerenciada pelo Snowflake para criar uma chave mestra composta. Quando isto ocorre, o Snowflake se refere a isto como o Tri-Secret Secure (neste tópico).

Você pode chamar essas funções do sistema em sua conta Snowflake para obter informações sobre suas chaves:

Importante

O Snowflake não suporta a rotação de chaves gerenciadas pelo cliente e não recomenda a implementação de uma política de rotação automática de chaves para a chave gerenciada pelo cliente.

A razão para esta recomendação é que a rotação de chaves pode levar a uma perda de dados se a chave for excluída, porque o Snowflake não será capaz de descriptografar os dados. Para obter mais informações, consulte Tri-Secret Secure (neste tópico).

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.

Tri-Secret Secure

O Tri-Secret Secure é a combinação de uma chave mantida pelo Snowflake e uma chave gerenciada pelo cliente na plataforma do provedor da nuvem que hospeda sua conta Snowflake para criar uma chave mestra composta que protege seus dados Snowflake. A chave mestra composta atua como uma chave mestra de conta e encapsula todas as chaves na hierarquia; no entanto, a chave mestra composta nunca criptografa dados brutos.

Se a chave gerenciada pelo cliente na hierarquia da chave mestra composta for revogada, seus dados não poderão mais ser descriptografados pelo Snowflake, proporcionando um nível de segurança e controle acima da criptografia padrão do Snowflake. Este modelo de criptografia de chave dupla, juntamente com a autenticação de usuário integrada do Snowflake, habilita os três níveis de proteção de dados oferecidos pelo Tri-Secret Secure.

Atenção

Antes de contatar a Snowflake para ativar o Tri-Secret Secure para sua conta, você deve considerar cuidadosamente sua responsabilidade de proteger sua chave, como mencionado na seção Chaves gerenciadas pelo cliente (neste tópico). Se você tiver alguma dúvida ou preocupação, teremos o maior prazer em conversar com você.

Note que a Snowflake também tem a mesma responsabilidade pelas chaves que mantemos. Como em todos os aspectos relacionados à segurança de nossos serviços, tratamos esta responsabilidade com o máximo cuidado e vigilância.

Todas as nossas chaves são mantidas sob políticas rigorosas que nos permitiram obter os mais altos credenciamentos de segurança, incluindo SOC 2 Type II, PCI-DSS, HIPAA e HITRUST CSF.

Nota

O registro de imagem atualmente não oferece suporte ao Tri-Secret Secure.

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.