Explicação do gerenciamento de chaves de criptografia no Snowflake¶
Este tópico apresenta conceitos relacionados a chaves gerenciadas pelo Snowflake e chaves gerenciadas pelo cliente.
Neste tópico:
Visão geral¶
O Snowflake gerencia chaves de criptografia de dados para proteger os dados dos clientes. Esse gerenciamento pode ocorrer automaticamente, sem a necessidade de intervenção do cliente.
Os clientes também 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 cliente no Snowflake. Isto é chamado de Tri-Secret Secure.
Chaves gerenciadas pelo Snowflake¶
Todos os dados de clientes Snowflake são criptografados por padrão. A Snowflake usa criptografia forte AES com um modelo de chave hierárquica enraizado em um módulo de segurança de hardware hospedado pelo provedor de nuvem.
As chaves são automaticamente rotacionadas regularmente pelo serviço Snowflake, e os dados do cliente podem ser automaticamente criptografados novamente (“rechaveados”) regularmente. A criptografia de dados do cliente e o gerenciamento de chaves não exigem 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:
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árquica restringe a quantidade de dados do cliente que cada chave protege e o período de tempo durante o qual ela pode ser usada.
Rotação de chaves de criptografia¶
As chaves na hierarquia de chaves gerenciadas pelo Snowflake são rotacionadas automaticamente 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 do cliente e fica disponível para uso pelo cliente. Quando retirada, a chave é usada exclusivamente para descriptografar os dados do cliente e fica disponível apenas para acessar os dados.
Ao encapsular as chaves secundárias na hierarquia de chaves ou ao inserir dados de clientes em uma tabela, somente a chave ativa atual é 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 do cliente inseridos nessa tabela em abril estão protegidos com a TMK v1.
Em maio, este TMK é alternado: TMK v1 é desativado, e uma nova chave completamente aleatória, TMK v2, é criada. A TMK v1 agora é usada apenas para descriptografar dados de clientes a partir de abril. Os dados de novos clientes inseridos na tabela são criptografados usando a TMK v2.
Em junho, o TMK é alternado novamente: O TMK v2 é desativado e um novo TMK, v3, é criado. A TMK v1 é usada para descriptografar dados de clientes a partir de abril, a TMK v2 é usada para descriptografar dados de clientes a partir de maio e a TMK v3 é usada para criptografar e descriptografar novos dados de clientes inseridos na tabela em junho.
Conforme dito anteriormente, a rotação de chaves limita o período de tempo em que uma chave é usada ativamente para criptografar os dados do cliente. Em conjunto com o modelo de chave hierárquica, a rotação de chaves restringe ainda mais a quantidade de dados do cliente 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 com uma explicação sobre o ciclo de vida da chave mestra da conta e da tabela. A rotação de chaves de criptografia descreve a rotação de chaves, que substitui as chaves ativas por novas chaves periodicamente e retira 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 estiver ativado, quando a chave de criptografia desativada de uma tabela tiver mais de um ano, o Snowflake criará automaticamente uma nova chave de criptografia e criptografará novamente todos os dados do cliente 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 PERIODIC_DATA_REKEYING:
ALTER ACCOUNT SET ENABLE_TRI_SECRET_AND_REKEY_OPT_OUT_FOR_IMAGE_REPOSITORY=True; ALTER ACCOUNT SET PERIODIC_DATA_REKEYING = true;
Isso habilita o Tri-Secret Secure, mas não aplica segurança adicional a nenhuma imagem armazenada em seu repositório de imagens do Snowpark.
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 do cliente protegidos pela TMK v1 geração 1 são descriptografados e recriptografados usando a 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 rechavear os dados do cliente, a Snowflake pode aumentar o tamanho das chaves de criptografia e utilizar algoritmos de criptografia melhores que podem ser padronizados desde a criação da geração de chaves anterior.
O Snowflake rechaveia os arquivos de dados do cliente online, em segundo plano, sem nenhum impacto sobre as cargas de trabalho do cliente em execução no momento. Os dados do cliente que estão sendo redigitados estão sempre disponíveis para você. Não é necessário nenhum tempo de inatividade do serviço para redigitar os dados, e você não encontra nenhum impacto no desempenho da sua carga de trabalho. Este benefício é um resultado direto da arquitetura do Snowflake de separar o armazenamento e os recursos computacionais.
Nota
Você não poderá usar tabelas híbridas se sua conta Snowflake estiver habilitada para usar rechaveamento periódico. Se o rechaveamento periódico estiver ativado em sua conta e você quiser usar tabelas híbridas, deverá usar um comando ALTER ACCOUNT para definir o parâmetro PERIODIC_DATA_REKEYING como FALSE.
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. No entanto, alguns encargos adicionais de armazenamento estão associados ao rechaveamento dos dados do cliente no Fail-safe (consulte a próxima seção).
Impacto do rechaveamento no uso do armazenamento¶
Os clientes Snowflake são cobrados com armazenamento adicional para a proteção Fail-safe dos arquivos de dados do cliente que foram rechaveados. Para estes arquivos, uma proteção Fail-safe de 7 dias é cobrada.
Ou seja, por exemplo, os arquivos de dados do cliente com a chave antiga no Amazon S3 já estão protegidos pelo Fail-safe, e os arquivos de dados do cliente com a nova chave no Amazon S3 também são adicionados ao Fail-safe, o que leva a uma segunda cobrança, mas apenas pelo período de 7 dias.
Módulo de segurança de hardware¶
O Snowflake conta com módulos de segurança de hardware (HSMs) hospedados na nuvem para ajudar a garantir que o armazenamento e o uso de chaves sejam seguros. Cada plataforma de nuvem tem diferentes serviços HSM, 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 HSM, as chaves mestras de conta, as chaves mestras de tabela e as chaves de arquivo:
Chaves gerenciadas pelo cliente¶
Uma chave gerenciada pelo cliente (CMK) é uma chave mestra de criptografia que o cliente mantém no serviço de gerenciamento de chaves do provedor de nuvem que hospeda a conta Snowflake do cliente. Os serviços de gerenciamento de chaves para cada plataforma são:
Google Cloud: Cloud Key Management Service (Cloud KMS)
Microsoft Azure: Azure Key Vault
A CMK 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 isso como Tri-Secret Secure.
Você pode chamar essas funções do sistema em sua conta Snowflake para obter informações sobre suas chaves:
Microsoft Azure: SYSTEM$GET_CMK_AKV_CONSENT_URL
Google Cloud: SYSTEM$GET_GCP_KMS_CMK_GRANT_ACCESS_CMD
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.
O motivo dessa recomendação é que a rotação de chaves pode levar à perda de dados do cliente se a chave rotacionada for excluída, pois o Snowflake não conseguirá descriptografar os dados. Para obter mais informações, consulte Tri-Secret Secure.
O Snowflake oferece suporte ao seguinte:
Configuração da rotação automática de chaves em seu provedor de serviços de nuvem. A configuração da rotação de chaves cria uma nova versão da mesma CMK com material de criptografia atualizado. É possível ativar a rotação automática de chaves usando o recurso de rotação de chaves específico de seu provedor de nuvem sem nenhuma ação no Snowflake. Após uma rotação de CMK, o Snowflake protege os dados existentes usando as versões de chave existentes.
Importante
Não exclua, nem altere ou revogue permissões em versões mais antigas de CMK para nenhum provedor de serviços de nuvem. A exclusão de uma chave girada pode levar à perda de dados. O Snowflake não pode descriptografar dados criptografados com uma chave excluída.
Para obter mais informações sobre como configurar a rotação automática de chaves para chaves gerenciadas pelo cliente na plataforma de nuvem que oferece suporte à sua(s) conta(s) Snowflake, consulte:
Alteração manual de CMK usada pelo Tri-Secret Secure (TSS). Para alterar sua CMK para TSS, é necessário criar e registrar uma nova CMK e, em seguida, atualizar o TSS para usá-lo. Siga o procedimento de autorregistro no Tri-Secret Secure e entre em contato com o suporte Snowflake para coordenar a alteração da chave.
Importante
Não revogue o acesso ou exclua a CMK atual até que a equipe de suporte Snowflake confirme que é seguro fazer isso.
Benefícios das chaves gerenciadas pelo cliente¶
As vantagens das chaves gerenciadas pelo cliente incluem:
- Controle sobre o acesso aos dados do cliente:
Você tem controle total sobre sua chave mestra no serviço de gerenciamento de chaves e, portanto, sobre os dados de seus clientes na Snowflake. Você deve liberar essa chave para descriptografar os dados armazenados em sua conta Snowflake.
- Desativação do acesso devido a uma violação de dados do cliente:
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 do cliente:
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 a chave oferece proteções durante todo o ciclo de vida dos dados do cliente, 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.
O Snowflake foi projetado para lidar com problemas de disponibilidade temporária (até 10 minutos) causados por problemas comuns, como falhas de comunicação de 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.