Versões de chave em Clusters de Big Data do SQL Server

Aplica-se a: SQL Server 2019 (15.x)

Este artigo fornece detalhes de como as versões de chave são usadas em Clusters de Big Data do SQL Server para o gerenciamento de chaves e a rotação de chaves do HDFS e do SQL Server. O artigo inclui detalhes sobre como as versões podem incorporar as chaves do cliente.

Para obter informações gerais sobre como proteger Clusters de Big Data do SQL Server, confira Conceitos de segurança para Clusters de Big Data do SQL Server.

Para obter informações sobre como configurar e usar o recurso de criptografia em repouso, confira os seguintes guias:

• Guia de configuração e conceitos de criptografia em repouso
• Guia de uso de zonas de criptografia do HDFS nos Clusters de Big Data do SQL Server
• Guia de uso da TDE (Transparent Data Encryption) em repouso dos Clusters de Big Data do SQL Server

Chaves do HDFS

Para usar a criptografia em repouso no HDFS, os seguintes conceitos estão envolvidos:

• EZ (zonas de criptografia): a zona de criptografia é uma pasta no HDFS que está associada a uma chave. Todos os arquivos nessa pasta são criptografados. A EZ padrão provisionada no Clusters de Big Data do SQL Server é chamada de "securelake".
• Chaves de EZ (chaves de zona de criptografia): uma chave simétrica nomeada. O provisionamento padrão gerenciado pelo sistema em Clusters de Big Data do SQL Server é "securelakekey". As chaves de zona de criptografia são gerenciadas usando o Hadoop KMS (servidor de gerenciamento de chaves) em execução dentro dos pods de nó de nome de Clusters de Big Data do SQL Server. As chaves de EZ são protegidas ainda por uma chave de criptografia principal armazenada em controldb (discutida nas seções abaixo). As chaves de EZ são criptografadas no KMS do Hadoop buscando a parte pública da chave de criptografia principal e as solicitações de descriptografia são enviadas para o painel de controle.
• Chave de criptografia de dados criptografados: cada arquivo na zona de criptografia é criptografado por uma DEK (chave de criptografia de dados) gerada para o arquivo. Depois que a DEK é criada, ela é mantida com os dados. Para persistir a DEK, primeiro ela é criptografada pela chave de zona de criptografia e então persistida com os dados. A DEK é gerada aleatoriamente por arquivo e a força da DEK simétrica é igual à força da chave da EZ.

O gráfico abaixo explica como os arquivos são protegidos pela DEK e como a DEK é protegida pela securelakekey de chave da EZ.

Chaves do SQL Server

A chave de criptografia principal gerenciada pelo sistema e as chaves de EZ do HDFS são armazenadas dentro do controldb, que será nomeado controldb-<#>, por exemplo controldb-0. Para obter mais informações, confira Recursos implantados com o cluster de Big Data.

Os bancos de dados SQL Server são criptografados por uma chave simétrica, também conhecida como DEK (chave de criptografia de banco de dados). A DEK é mantida com o banco de dados em um formato criptografado. O protetor da DEK pode ser um certificado ou uma chave assimétrica. Para alterar o protetor de DEK, use a instrução ALTER DATABASE ENCRYPTION KEY. A chave assimétrica no SQL Server tem metadados que contêm um link de URL para a chave dentro do painel de controle. Portanto, todas as operações de criptografia e descriptografia da DEK (chave de criptografia de banco de dados) são feitas dentro do controlador. O SQL Server armazena a chave pública, mas o faz apenas para identificar a chave assimétrica, e não criptografa usando a chave pública.

Chave de criptografia principal do Clusters de Big Data do SQL Server

No painel de controle do Clusters de Big Data do SQL Server, para proteger as chaves de zona de criptografia e para provisionar chaves assimétricas no SQL Server, há um conceito chamado de chave de criptografia principal. Há duas chaves de criptografia principais, uma para o SQL Server e outra para o HDFS. Esse conceito possibilita ao painel de controle do Clusters de Big Data do SQL Server manter a chave de criptografia principal fora do cluster também. As propriedades da chave de criptografia principal são:

1. As chaves de criptografia principais são chaves RSA assimétricas.
2. Uma chave de criptografia principal é criada para a instância mestra do SQL Server e outra para o HDFS.
3. A chave pública correspondente à chave de criptografia principal é sempre armazenada no banco de dados do controlador (controldb). A chave privada é armazenada no banco de dados do controlador para a chave de criptografia principal gerenciada pelo sistema. Para chaves de criptografia de um HSM (módulo de segurança de hardware) ou qualquer outro provedor externo, as chaves privadas não são armazenadas dentro do banco de dados do controlador (a menos que o aplicativo para chaves externas acompanhe a chave privada). No entanto, a chave privada não é necessária dentro do controldb e o Clusters de Big Data do SQL Server não exigirá o material da chave privada.
4. As operações de criptografia que usam a chave pública da chave de criptografia principal podem ser executadas dentro do próprio controlador ou o controlador pode distribuir a chave pública para o KMS do Hadoop, permitindo que ele execute a criptografia localmente. Espera-se que as operações de descriptografia sejam tratadas pelo provedor de chave externa, como o HSM. Esse design nos permite manter a parte confidencial da chave assimétrica fora do cluster e sob a proteção do cliente. Isso garante que a raiz de criptografia para descriptografar todos os dados nunca esteja disponível no ecossistema do Clusters de Big Data do SQL Server para chaves configuradas pelo cliente.

Proteção de armazenamento de chaves diferentes

As DEKs para arquivos HDFS e para SQL Server são armazenada junto com os dados que a DEK protege. A DEK é protegida pela chave de EZ no HDFS ou pela chave assimétrica no SQL Server, respectivamente.

As chaves assimétricas no SQL Server têm metadados que incluem a URL da chave no painel de controle. SQL Server armazena apenas a chave pública da chave assimétrica, para correlação com a chave no painel de controle.

O armazenamento de chaves em controldb é protegido pela chave de criptografia de coluna em controldb. O controldb armazena informações confidenciais sobre o cluster, e todas elas são protegidas por uma chave de criptografia de coluna do SQL Server no controldb, que é protegido ainda por uma senha armazenada nos Segredos do Kubernetes. Para obter mais informações, confira Segredos na documentação do Kubernetes.

A proteção é resumida nos diagramas abaixo. Primeiro, a proteção de armazenamento de chaves de EZ do HDFS:

Proteção de armazenamento da chave de criptografia principal:

Alteração de chaves

Chaves de zona de criptografia do HDFS

Quando o Clusters de Big Data do SQL Server é implantado com o Active Directory, o HDFS é provisionado com uma zona de criptografia padrão chamada securelake, protegida por securelakekey. Usaremos os padrões em exemplos, no entanto, novas zonas e chaves podem ser provisionadas usando azdata. A securelakekey é protegida por uma chave de criptografia principal para HDFS, que é armazenada no painel de controle. No SQL 2019 CU9 e em versões posteriores, é possível usar azdata para girar as chaves de EZ para o HDFS. A rotação de chaves de EZ faz com que um material de chave com o mesmo nome de "securelakekey" seja gerado, mas com uma nova versão da chave apontando para o material de chave. Em qualquer nova operação de criptografia no HDFS (por exemplo, gravações de arquivo), a EZ sempre usa a versão mais recente da chave associada a ela. Para arquivos em uma EZ protegidos por uma versão mais antiga das chaves, o comando azdata bdc hdfs encryption-zone reencrypt pode ser usado para que todos os arquivos possam ser protegidos pela versão mais recente da chave de EZ.

Considere um arquivo chamado file2 colocado em/securelake. A seguir, há uma descrição da cadeia de proteção.

A securelakekey pode ser girada para uma nova versão usando azdata bdc hdfs key roll -n securelakekey. A rotação não faz com que as DEKs que protegem o arquivo sejam criptografadas novamente. A rotação de chave do Hadoop faz com que um material de chave seja gerado e protegido pela versão mais recente da chave de criptografia principal. O diagrama a seguir mostra o estado do sistema após a rotação de securelakekey.

Para verificar se os arquivos nas zonas de criptografia estão protegidos pela securelakekey girada, azdata bdc hdfs encryption-zone -a start -p /securelake.

O diagrama a seguir ilustra o estado do sistema após a nova criptografia da zona de criptografia.

SQL Server

A chave que protege o Banco de Dados SQL é a DEK, que pode ser regenerada. O processo de regeneração faria com que todo o banco de dados fosse criptografado novamente.

Rotação da chave de criptografia principal

A chave de criptografia principal é uma chave RSA de 2.048 bits. A rotação da chave de criptografia principal realizaria uma das seguintes ações, dependendo da origem da chave:

1. Crie uma chave caso a solicitação tenha sido feita para girar a chave principal para uma chave gerenciada pelo sistema. Uma chave gerenciada pelo sistema é uma chave assimétrica, gerada e armazenada dentro do controlador.
2. Crie uma referência a uma chave fornecida externamente, em que a chave privada da chave assimétrica será gerenciada pelo aplicativo do cliente. O aplicativo do cliente não precisa ter a chave privada, mas deve saber como recuperar a chave privada com base na configuração do aplicativo fornecido.

A rotação da chave principal não criptografa nada novamente. As chaves do SQL Server e do HDFS precisam então ser giradas:

• Depois que a chave principal for girada, o protetor de DEK do banco de dados do SQL Server precisará ser girado para a nova versão da chave principal criada.
• Conceitos semelhantes se aplicam ao HDFS. Quando a chave do HDFS é girada, o novo material é criptografado pela versão mais recente da chave principal. As versões mais antigas das chaves de EZ permanecerão inalteradas. Depois que a chave de EZ do HDFS é girada, as zonas de criptografia associadas à chave de EZ precisam ser criptografadas novamente pela versão mais recente da chave de EZ.

Rotação de chave principal para HDFS

Os diagramas a seguir ilustram o processo de rotação da chave de criptografia principal para o HDFS. Primeiro, o estado inicial do HDFS:

A chave de criptografia principal será girada usando azdata bdc kms set –key-provider SystemManaged. (Observe que o comando causa a rotação da chave de criptografia principal para o SQL e o HDFS, embora elas sejam chaves diferentes dentro do painel de controle.) Depois de usar o comando azdata bdc kms:

Para usar a nova versão da chave de criptografia principal do HDFS, o comando azdata bdc hdfs key roll pode ser usado, o que leva o sistema para o estado a seguir. Depois de girar a securelakekey:

Girar a securelakekey faria com que uma outra versão da securelakekey fosse criada e protegida pela chave de criptografia principal. Para garantir que os arquivos em securelake sejam criptografados por securelakekey@2, a zona de criptografia securelake precisa ser criptografada novamente. Após criptografar novamente a zona de criptografia:

Rotação de chave principal para o SQL Server

A chave de criptografia principal do SQL Server é instalada no banco de dados mestre da instância mestra do SQL Server.

Os diagramas a seguir ilustram o processo de rotação da chave de criptografia principal para o SQL Server.

Em uma nova instalação do Clusters de Big Data do SQL Server, não haverá nenhuma chave assimétrica provisionada no SQL Server. No estado inicial do SQL Server, os bancos de dados podem ser criptografados usando certificados; no entanto, o administrador da instância mestra do SQL Server controla esse aspecto.

A chave de criptografia principal será girada usando azdata bdc kms set –key-provider SystemManaged. (Observe que o comando causa a rotação da chave de criptografia principal ou a cria, se ela não existir, para o SQL e o HDFS, embora elas sejam chaves diferentes dentro do painel de controle.)

A chave assimétrica pode ser vista usando a consulta T-SQL a seguir, com a exibição do catálogo do sistema sys.asymmetric_keys.

USE master;
select * from sys.asymmetric_keys;

A chave assimétrica será exibida com a convenção de nomenclatura "tde_asymmetric_key_<versão>". O administrador do SQL Server pode alterar o protetor da DEK para a chave assimétrica usando ALTER DATABASE ENCRYPTION KEY. Por exemplo, use o seguinte comando T-SQL:

USE db1;
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY tde_asymmetric_key_0;

Agora, o protetor da DEK é alterado para usar a chave assimétrica:

Se o comando azdata bdc kms set for executado novamente, as chaves assimétricas no SQL Server mostrarão outra entrada em sys.asymmetric_keys com o formato "tde_asymmetric_key_<versão>". Esse comando azdata pode ser usado para alterar novamente o protetor da DEK de um banco de dados do SQL Server.

Chave fornecida pelo cliente

Com a capacidade de trazer chaves externas para Clusters de Big Data do SQL Server, a chave de criptografia principal busca a chave pública usando o aplicativo implantado pelo cliente. Quando as chaves do HDFS são giradas e usadas, as chamadas para descriptografar as chaves do HDFS são enviadas para o painel de controle e, depois, redirecionadas para o aplicativo usando o identificador de chave fornecido pelo cliente. Por SQL Server, as solicitações para criptografar são enviadas e atendidas pelo painel de controle, pois ele contém a chave pública. As solicitações para descriptografar a DEK do SQL, são enviadas ao painel de controle também e, depois, redirecionadas para o aplicativo KMS.

O seguinte diagrama explica as interações ao configurar chaves externas no painel de controle:

Depois que a chave é instalada, a criptografia e a descriptografia de conteúdos diferentes são protegidas pela chave de criptografia principal. Essa proteção é semelhante às chaves gerenciadas pelo sistema, exceto pelo fato de que as chamadas de descriptografia roteadas para o painel de controle são então roteadas para o aplicativo de plug-in KMS. O aplicativo de plug-in KMS roteia a solicitação para a localização apropriada, como o HSM ou outro produto.

Confira também

• Conceitos de segurança do Clusters de Big Data do SQL Server
• Configurar um cluster de Big Data do SQL Server
• Perguntas frequentes sobre Clusters de Big Data