Implementar a criptografia no Azure Synapse Analytics

Concluído

Nesta seção, vamos passar por Transparent Data Encryption e TokenLibrary para Apache Spark.

O que é Transparent Data Encryption?

A TDE (Transparent Data Encryption) é um mecanismo de criptografia para ajudá-lo a proteger o Azure Synapse Analytics. Ela protegerá o Azure Synapse Analytics contra ameaças de atividades offline mal-intencionadas. A maneira como a TDE fará isso é criptografando os dados inativos. O TDE realiza a criptografia e a descriptografia em tempo real do banco de dados, de backups associados e de arquivos de log de transações em repouso sem a necessidade de fazer alterações no aplicativo. Para usar a TDE para o Azure Synapse Analytics, é preciso habilitá-la manualmente.

O que a TDE faz é executar a criptografia e a descriptografia de E/S de dados no nível de página em tempo real. Quando uma página é lida na memória, ela é descriptografada. Ela é criptografada antes de ser gravada no disco. A TDE criptografa todo o armazenamento de base de dados usando uma chave simétrica chamada DEK (Chave de Criptografia do Banco de Dados). Quando você inicia um banco de dados, a Chave de Criptografia do Banco de Dados criptografada é descriptografada. A DEK será então usada para descriptografia e nova criptografia dos arquivos de banco de dados no mecanismo de banco de dados do SQL Server. A DEK é protegida pelo protetor de Transparent Data Encryption. Esse protetor pode ser um certificado gerenciado por serviço, que é conhecido como Transparent Data Encryption gerenciada por serviço ou uma chave assimétrica armazenada no Azure Key Vault (Transparent Data Encryption gerenciada pelo cliente).

É importante entender que, para o Azure Synapse Analytics, esse protetor de TDE é definido no nível do servidor. Lá, ele é herdado por todos os bancos de dados anexados ou alinhados a esse servidor. O termo servidor refere-se tanto ao servidor quanto à instância.

Transparent Data Encryption de serviço gerenciado

Conforme mencionado acima, a DEK protegida pelo protetor de Criptografia Transparente pode ser composta por certificados gerenciados pelo serviço, o que chamamos de TDE gerenciada pelo serviço. Quando você procura no Azure, essa configuração padrão significa que a DEK é protegida por um certificado interno exclusivo para cada servidor com o algoritmo de criptografia AES256. Quando um banco de dados está em uma relação replicada geograficamente, os bancos de dados primário e geográfico secundário são protegidos pela chave do servidor pai do banco de dados primário. Se os bancos de dados estiverem conectados ao mesmo servidor, eles também compartilharão o mesmo certificado AES 256 interno. Como a Microsoft, giramos automaticamente os certificados em conformidade com a política de segurança interna. A chave raiz é protegida por um repositório de segredo interno da Microsoft. A Microsoft também move e gerencia as chaves conforme necessário para replicação geográfica e restaurações.

Transparent Data Encryption com Bring Your Own Key para Transparent Data Encryption gerenciada pelo cliente

Conforme mencionado acima, a DEK que é protegida pelo protetor de Transparent Data Encryption também pode ser gerenciada pelo cliente, trazendo uma chave assimétrica que é armazenada no Azure Key Vault (Transparent Data Encryption gerenciada pelo cliente). Isso também é conhecido como suporte a BYOK (Bring Your Own Key) para TDE. Quando esse é o cenário que é aplicável a você, o protetor de TDE que criptografa a DEK é uma chave assimétrica gerenciada pelo cliente. Ele é armazenado em seu próprio Azure Key Vault gerenciado. O Azure Key Vault é um sistema de gerenciamento de chave externa baseado em nuvem do Azure. Essa chave gerenciada nunca sai do cofre de chaves. O Protetor de TDE pode ser gerado pelo cofre de chaves. Outra opção é transferir o protetor de TDE, por exemplo, de um dispositivo HSM (módulo de segurança de hardware) local para o cofre de chaves. O Azure Synapse Analytics precisa receber permissões para o cofre de chaves de Propriedade do cliente para descriptografar e criptografar o DEK. Se as permissões do servidor para o cofre de chaves forem revogadas, um banco de dados não poderá ser acessado e todos os dados serão criptografados.

Usando a integração do Azure Key Vault para TDE, você tem controle sobre as principais tarefas de gerenciamento, como rotações de chave, backups de chave e permissões de chave. Ela também permite que você faça auditoria e relatórios em todos os protetores de TDE ao usar a funcionalidade do Azure Key Vault. O motivo para usar o Key Vault é que ele fornece um sistema central de gerenciamento de chaves no qual os HSMs com monitoramento rígido são aproveitados. Ele também permite separar as tarefas de gerenciamento de chaves e dados para cumprir a conformidade com as políticas de segurança.

Gerenciar Transparent Data Encryption no portal do Azure.

Para o Azure Synapse Analytics, você pode gerenciar TDE para o banco de dados no portal do Azure depois de entrar com a conta de administrador ou colaborador do Azure. As configurações de TDE podem ser encontradas no seu banco de dados de usuário.

Pool de SQL da Transparent Data Encryption no Azure Synapse Analytics

Por padrão, a TDE gerenciada pelo serviço é usada, portanto, um certificado TDE é gerado automaticamente para o servidor que contém esse banco de dados.

Como mover um banco de dados protegido por Transparent Data Encryption

Em alguns casos de uso, você precisa mover um banco de dados protegido com TDE. No Azure, não é necessário descriptografar os bancos de dados. As configurações de TDE no banco de dados de origem ou banco de dados primário serão herdadas no destino. Algumas das operações no Azure que herdaram a TDE são:

  • Restauração geográfica
  • Restauração via autoatendimento point-in-time
  • Restauração de um banco de dados excluído
  • Replicação geográfica ativa
  • Criação de uma cópia do banco de dados
  • Restauração de arquivo de backup para a instância gerenciada do SQL do Azure

Se você exportar um banco de dados protegido por TDE, o conteúdo exportado não será criptografado. Ele será armazenado em um arquivo BACPAC não criptografado. Você precisa proteger esse arquivo BACPAC e habilitar o TDE assim que a importação do arquivo bacpac no novo banco de dados for concluída.

Como proteger suas credenciais por meio de serviços vinculados com a TokenLibrary para Apache Spark

É um padrão muito comum acessar dados de fontes externas. A menos que a fonte de dados externa permita acesso anônimo, é muito provável que você precise proteger sua conexão com uma credencial, um segredo ou uma cadeia de conexão.

No Azure Synapse Analytics, o processo de integração é simplificado fornecendo serviços vinculados. Ao fazer isso, os detalhes da conexão podem ser armazenados no serviço vinculado ou em um Azure Key Vault. Se o Serviço Vinculado for criado, o Apache Spark poderá fazer referência a ele para aplicar as informações de conexão em seu código. Quando você deseja acessar arquivos do Azure Data Lake Storage Gen 2 em seu Workspace do Azure Synapse Analytics, ele usa passagem do AAD para a autenticação. Portanto, não é preciso usar a TokenLibrary. Porém, para conectar-se a outros serviços vinculados, você é habilitado a fazer uma chamada direta à TokenLibrary.

Um exemplo pode ser encontrado abaixo: para se conectar a outros serviços vinculados, você está habilitado para fazer uma chamada direta à TokenLibrary recuperando a cadeia de conexão. Para recuperar a cadeia de conexão, use a função getConnectionString e passe o nome do serviço vinculado.

// Scala
// retrieve connectionstring from TokenLibrary

import com.microsoft.azure.synapse.tokenlibrary.TokenLibrary

val connectionString: String = TokenLibrary.getConnectionString("<LINKED SERVICE NAME>")
println(connectionString)
# Python
# retrieve connectionstring from TokenLibrary

from pyspark.sql import SparkSession

sc = SparkSession.builder.getOrCreate()
token_library = sc._jvm.com.microsoft.azure.synapse.tokenlibrary.TokenLibrary
connection_string = token_library.getConnectionString("<LINKED SERVICE NAME>")
print(connection_string)

Se você deseja obter a cadeia de conexão como mapa e analisar valores específicos de uma chave nessa cadeia, poderá encontrar um exemplo abaixo:

Para analisar valores específicos de um par chave=valor na cadeia de conexão, como

DefaultEndpointsProtocol=https;AccountName=<AccountName>;AccountKey=<AccountKey>

use a função getConnectionStringAsMap e passe a chave para retornar o valor.

// Linked services can be used for storing and retreiving credentials (e.g, account key)
// Example connection string (for storage): "DefaultEndpointsProtocol=https;AccountName=<accountname>;AccountKey=<accountkey>"
import com.microsoft.azure.synapse.tokenlibrary.TokenLibrary

val accountKey: String = TokenLibrary.getConnectionStringAsMap("<LINKED SERVICE NAME">).get("<KEY NAME>")
println(accountKey)
# Linked services can be used for storing and retreiving credentials (e.g, account key)
# Example connection string (for storage): "DefaultEndpointsProtocol=https;AccountName=<accountname>;AccountKey=<accountkey>"
from pyspark.sql import SparkSession

sc = SparkSession.builder.getOrCreate()
token_library = sc._jvm.com.microsoft.azure.synapse.tokenlibrary.TokenLibrary
accountKey = token_library.getConnectionStringAsMap("<LINKED SERVICE NAME>").get("<KEY NAME>")
print(accountKey)