Explicação da Criptografia do SQL Server: TDE, Criptografia em Nível de Coluna e Mais

A proteção de dados é crítica para garantir que sua organização esteja em conformidade com padrões de compliance regulatórios como o GDPR e para atender às expectativas de seus clientes e parceiros de negócios. Não apenas as violações de data breaches podem resultar em multas elevadas, mas o dano à reputação pode ser igualmente grande. Para ajudar, o Microsoft SQL Server suporta 5 diferentes tipos de criptografia para proteção de dados. Este artigo explica cada um deles e onde devem ser utilizados.

Criptografia de Transporte SSL

Assim como sites que protegem o tráfego entre o navegador e o servidor, o SQL Server pode ser configurado para usar o Secure Sockets Layer (SSL) para criptografar o tráfego enquanto ele percorre entre a instância do servidor e a aplicação cliente. Além disso, o cliente pode validar a identidade do servidor usando o certificado do servidor. O SSL só protege os dados enquanto eles viajam pela rede, mas, ao contrário de muitas outras formas de criptografia do SQL Server, o SSL está disponível em todas as versões suportadas do SQL Server e em todas as edições.

Antes de ativar o SSL, será necessário instalar um certificado no SQL Server. A melhor maneira de fazer isso é solicitando um certificado de sua própria autoridade de certificação empresarial (CA). O Windows Server pode ser configurado como uma CA e você pode configurar os clientes para que confiem nos certificados que ele emite. Alternativamente, é possível usar certificados autoassinados, embora isso seja mais adequado para ambientes de teste.

SQL Server Transparent Data Encryption (TDE)

A Transparent Data Encryption (TDE) no SQL Server protege os dados em repouso criptografando os dados do banco de dados e os arquivos de log em disco. Funciona de maneira transparente para as aplicações clientes existentes, de modo que não precisam ser alteradas quando o TDE é habilitado. O TDE utiliza criptografia em tempo real no nível da página. As páginas são criptografadas antes de serem escritas no disco, sem aumentar o tamanho dos seus dados e arquivos de log, e as páginas são descriptografadas quando lidas na memória. O TDE está disponível apenas nas edições Enterprise do SQL Server. Também funciona para Azure SQL Database, Azure SQL Data Warehouse e Parallel Data Warehouse.

A criptografia TDE possui uma estrutura hierárquica, com a Windows Data Protection API (DPAPI) no topo da hierarquia e sendo usada para criptografar a chave mestra de serviço (SMK). Você pode usar a SMK para criptografar credenciais, senhas de servidores vinculados e as chaves mestras de banco de dados (DMKs) residentes em diferentes bancos de dados. Uma DMK SQL é uma chave simétrica que protege as chaves privadas de certificados e chaves assimétricas armazenadas nos bancos de dados.

O SQL Server pode gerar certificados autoassinados para uso com TDE ou você pode solicitar um certificado de uma CA (que é a abordagem mais comum). Se decidir habilitar o TDE, deve fazer backup do certificado e da chave privada associada ao certificado. Será necessário restaurar ou anexar o banco de dados em um SQL Server diferente. Se habilitar o TDE em qualquer outro banco de dados do SQL Server, o banco de dados de sistema tempdb também é criptografado. Se desabilitar o TDE, deve manter o certificado e a chave privada, pois partes do log de transações podem permanecer criptografadas até que você realize um backup completo.

O TDE também requer uma chave de criptografia de banco de dados (DEK), que é uma chave simétrica protegida por um certificado armazenado no banco de dados mestre, ou uma chave assimétrica protegida por um serviço que utiliza o Gerenciamento Extensível de Chaves (EKM), como o Microsoft Azure Key Vault. Os arquivos de backup de bancos de dados habilitados para TDE são criptografados usando a DEK, portanto, durante as operações de restauração, o certificado que protege a DEK deve estar disponível.

Chaves simétricas usam a mesma senha para criptografar e descriptografar dados. Chaves assimétricas usam uma senha para criptografar dados (chave pública) e uma senha diferente para descriptografar dados (chave privada). Você pode usar o comando CREATE CERTIFICATE para criar certificados, e os comandos Transact-SQL CREATE SYMMETRIC KEY e CREATE ASYMMETRIC KEY para criar chaves de criptografia de banco de dados.

Criptografia de Backup

A Criptografia de Backup funciona como o TDE, mas criptografa os backups do SQL em vez dos arquivos de dados ativos e de log. A Criptografia de Backup está disponível no SQL Server 2014 e versões posteriores. Você pode especificar criptografia AES 128, AES 192, AES 256 ou Triple DES, e usar um certificado ou chave assimétrica armazenada no EKM. Além disso, é possível habilitar o TDE e a Criptografia de Backup simultaneamente, embora você deva usar certificados ou chaves diferentes.

Assim como com TDE, se você habilitar a Criptografia de Backup, também deve fazer backup do certificado ou chave. Sem a chave ou certificado, o arquivo de backup não pode ser usado para restaurar dados. Os backups também podem ser criptografados ao usar o SQL Server Managed Backup para Microsoft Azure.

É importante notar que se você estiver usando um certificado para criptografar backups, deve ter o certificado original ao restaurar os dados. Isso significa que o certificado deve ter a mesma impressão digital de quando o backup foi criado. Renovar certificados ou alterá-los de qualquer forma pode fazer com que a impressão digital mude.

Criptografia de Coluna/Célula

Disponível em todas as edições do SQL Server, a criptografia em nível de célula pode ser habilitada em colunas que contêm dados sensíveis. Os dados são criptografados no disco e permanecem criptografados na memória até que a função DECRYPTBYKEY seja usada para descriptografá-los. Portanto, embora os dados do SQL estejam criptografados, eles não são seguros além de simplesmente usar uma função no contexto do usuário para descriptografá-los. Além disso, como é necessária uma função para descriptografar os dados, as aplicações cliente devem ser modificadas para trabalhar com a criptografia em nível de célula.

Gerenciamento de Chave de Criptografia

Assim como com TDE, você precisa criar uma chave mestra (DMK) antes de usar a criptografia em nível de célula. Existem quatro opções para criptografar informações usando criptografia em nível de célula:

• Você pode usar uma frase-senha para criptografar e descriptografar os dados, mas deve criptografar procedimentos armazenados e funções; caso contrário, a frase-senha pode ser acessada nos metadados.
• Chaves assimétricas oferecem alta segurança, mas podem impactar o desempenho.
• Chaves simétricas geralmente são suficientemente seguras e oferecem um bom equilíbrio entre segurança e desempenho.
• Os certificados também oferecem um bom equilíbrio entre segurança e desempenho, e podem ser associados a um usuário de banco de dados.

Sempre Criptografado

Always Encrypted criptografa dados sensíveis em aplicações cliente sem revelar as chaves de criptografia para o motor de banco de dados, proporcionando separação entre proprietários de dados e gestores de dados. Por exemplo, com o Always Encrypted ativado, você pode ter certeza de que seus administradores de banco de dados não poderão ler dados sensíveis. Como o nome sugere, os dados são criptografados em repouso e, se usados em um sistema de terceiros, como o Azure.

Always Encrypted pode ser configurado para colunas individuais do banco de dados. Dois tipos de chaves são utilizados: chaves de criptografia de coluna e chaves mestras de coluna. Chaves de criptografia de coluna protegem os dados em uma coluna e chaves mestras de coluna são ‘chaves que protegem chaves’ que criptografam uma ou mais chaves de criptografia de coluna. Chaves mestras de coluna são armazenadas em repositórios de chaves confiáveis externos, como o Azure Key Vault.

O processo de criptografia é transparente para as aplicações cliente, mas requer um driver especial nos computadores cliente. Always Encrypted está disponível no SQL Server 2016 e versões posteriores, mas apenas nas edições Enterprise. Devido aos requisitos adicionais do lado do cliente, Always Encrypted é mais adequado para situações em que a separação entre proprietários e gestores de dados é um requisito primordial.