Data protection is critical for ensuring that your organization is compliant with regulatory compliance standards like the GDPR and for meeting the expectations of your clients and business partners. Não só as violações de dados podem resultar em multas grandes, mas os danos reputacionais podem ser igualmente grandes. Para ajudar, o Microsoft SQL Server suporta 5 tipos diferentes de criptografia para proteger dados. Este artigo explica cada um deles e onde devem ser utilizados.

SSL Transport Encryption

Like websites that secure traffic between browser and server, SQL Server can be configured to use Secure Sockets Layer (SSL) to encrypt traffic as it travels between the server instance and client application. Além disso, o cliente pode validar a identidade do servidor usando o certificado do servidor. SSL só protege os dados enquanto viaja através da rede, mas, ao contrário da maioria das outras formas de criptografia de servidor SQL, SSL está disponível em todas as versões suportadas do servidor SQL e em todas as edições.

Antes de activar o SSL, terá de instalar um certificado no servidor SQL. A melhor forma de o fazer é solicitar um certificado à sua própria autoridade de certificação da empresa (CA). O Windows Server pode ser configurado como uma AC e você pode configurar os clientes para que eles confiem nos certificados que ele emite. Alternativamente, é possível usar certificados autossignados, embora este seja o mais adequado para ambientes de teste.

SQL Server Transparent Data Encryption (TDE)

Transparent Data Encryption (TDE) in SQL Server protects data at rest by encrypting database data and log files on disk. Ele funciona de forma transparente para aplicações existentes clientes, para que eles não precisam ser alterados quando o TDE está habilitado. O TDE usa encriptação em tempo real ao nível da página. As páginas são criptografadas antes de serem escritas em disco, sem aumentar o tamanho de 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 empresariais do servidor SQL. Ele também trabalha para Azure SQL Database, Azure SQL Data Warehouse e Parallel Data Warehouse.

a encriptação TDE tem uma estrutura hierárquica, com a API de protecção de dados do Windows (DPAPI) no topo da hierarquia e sendo usada para cifrar a chave-mestra do serviço (SMK). Poderá usar o SMK para cifrar as credenciais, as senhas do servidor ligadas e as chaves-mestras da base de dados (DMKs) que residem em diferentes bases de dados. Um DMK SQL é uma chave simétrica que protege as chaves privadas de certificados e chaves assimétricas armazenadas em bancos de dados.

SQL Server can generate self-signed certificates for use with TDE or you can request a certificate from a CA (which is the more common approach). Se você decidir ativar o TDE, você deve fazer backup do certificado e da chave privada associada ao certificado. Você terá que restaurar ou anexar a base de dados em um servidor SQL diferente. Se activar o TDE em qualquer outra base de dados do servidor SQL, a base de dados do sistema tempdb também é encriptada. Se desactivar o TDE, deverá manter o certificado e a chave privada, porque as partes do registo de transacções poderão permanecer encriptadas até efectuar uma cópia de segurança completa.

TDE também requer uma chave de criptografia de banco de dados (dek), que é ou uma chave simétrica que é protegida usando um certificado armazenado na base de dados principal, ou uma chave assimétrica que é protegida por um serviço que usa gerenciamento de Chave extensível (Ekman), como Microsoft Azure Key Vault. Os arquivos de Backup de bases de dados ativadas pelo TDE são criptografados usando o DEK, então durante as operações de restauração, o certificado que protege o DEK deve estar disponível.

chaves simétricas usam a mesma senha para encriptar 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 Criar Certificado para criar certificados, e a chave simétrica criar comandos Transact-SQL chave assimétrica para criar chaves de criptografia de banco de dados.

Backup Encryption

Backup Encryption works like TDE but encrypts SQL backups instead of the active data and log files. Criptografia de Backup está disponível no servidor SQL 2014 e mais tarde. Você pode especificar AES 128, AES 192, AES 256 ou Triple DES encriptação, e usar um certificado ou chave assimétrica armazenada no EKM. Além disso, é possível ativar a encriptação TDE e Backup simultaneamente, embora você deva usar diferentes certificados ou chaves.

tal como no TDE, se activar a encriptação de salvaguarda, deverá também fazer backup do certificado ou da chave. Sem a chave ou certificado, o arquivo de backup não pode ser usado para restaurar os dados. Backups também podem ser criptografados ao usar SQL Server gerenciado Backup para Microsoft Azure.

vale a pena notar que, se estiver a usar um certificado para cifrar cópias de segurança, deverá ter o certificado original ao repor os dados. Isso significa que o certificado deve ter a mesma impressão digital que quando o backup foi criado. Renovar certificados ou alterá-los de alguma forma pode fazer com que a impressão digital mude.

encriptação ao nível da coluna/célula

Disponível em todas as edições do servidor SQL, a encriptação ao nível da célula pode ser activada em colunas que contenham 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á-lo. Portanto, embora os dados SQL sejam criptografados, não é seguro além de simplesmente usar uma função no contexto do Usuário para descriptografá-lo. Além disso, como uma função é necessária para descriptografar os dados, as aplicações cliente devem ser modificadas para trabalhar com criptografia de nível celular.

Gestão da chave de encriptação

tal como no TDE, é necessário criar uma chave-mestra (DMK) antes de usar a cifra ao nível da célula. Existem quatro opções para cifrar a informação usando a encriptação ao nível das células:

• poderá usar uma frase-senha para cifrar e descodificar os dados, mas deverá cifrar os procedimentos e funções armazenados; caso contrário, a frase-senha pode ser acessada nos metadados.as chaves assimétricas proporcionam uma forte segurança, mas podem ter um impacto no desempenho.chaves simétricas são geralmente fortes o suficiente e proporcionam um bom equilíbrio entre Segurança e desempenho.os certificados também fornecem um bom equilíbrio entre Segurança e desempenho, e podem ser associados a um usuário de banco de dados.

sempre criptografado

sempre criptografado encripta dados sensíveis em aplicações clientes 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 sempre criptografado habilitado, você pode ter certeza de que seus administradores de banco de dados não será capaz de ler dados sensíveis. Como o nome sugere, os dados são criptografados em repouso e se usados em um sistema de terceiros, como Azure.

sempre encriptado pode ser configurado para as colunas individuais da base de dados. Dois tipos de chaves são usadas: chaves de encriptação de colunas e chaves-mestras de colunas. As chaves de cifra das colunas protegem os dados numa coluna e as chaves-mestras das colunas são as ‘chaves de protecção de chaves’ que encriptam uma ou mais Chaves de cifra das colunas. As chaves mestras da coluna são guardadas em lojas de chaves externas de confiança, como o Cofre de chaves Azure.

O processo de encriptação é transparente para as aplicações do cliente, mas requer um controlador especial nos computadores do cliente. Sempre criptografado está disponível no servidor SQL 2016 e mais tarde, mas apenas em Edições empresariais. Devido aos requisitos adicionais do lado cliente, sempre criptografado é mais adequado para situações em que a separação de proprietários de dados e gerentes é um requisito primário.consultor de TI e autor especializado em tecnologias de gestão e segurança. Russell tem mais de 15 anos de experiência nele, ele escreveu um livro sobre Segurança do Windows, e ele co-autor de um texto para a série oficial de curso acadêmico da Microsoft (MOAC).