- SQL Server 2008 – Como criptografar seus dados utilizando Transparent Data Encryption (TDE)
- SQL Server 2016 – Como criptografar seus dados utilizando Always Encrypted
- SQL Server 2016 – Mascaramento de dados com o Dynamic Data Masking (DDM)
- Lei Geral de Proteção de Dados Pessoais (LGPDP ou LGPD) aplicada a bancos de dados SQL Server
- SQL Server – Evitando consultas em determinadas colunas com o Column Level Security (CLS)
Introdução
Com o advento do GDPR, a preocupação das empresas com segurança de dados vem crescendo cada vez mais, e uma área que antes era por vezes deixada de lado, está em evidência mais do que nunca agora. Em decorrência disso, os profissionais de TI, em especial os DBAs, vem procurando formas de reduzir os riscos de exposição de dados e uma das formas de se fazer isso, é criptografando os dados para evitar acesso não autorizado por terceiros.
A minha ideia nesse artigo é demonstrar uma solução do SQL Server que permite criptografar os dados, que é o Transparent Data Encryption (TDE), disponível desde a versão 2008 do SQL Server, nas edições Enterprise e Developer.
Não deixe de conferir o meu post SQL Server 2016 – Como criptografar seus dados utilizando Always Encrypted, outra solução de criptografia de dados do SQL Server, disponível desde a versão 2016, nas edições Express, Standard, Enterprise e Developer.
Para os exemplos abaixo, vou utilizar o seguinte script para geração da base:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
IF (OBJECT_ID('dbo.Pessoa') IS NOT NULL) DROP TABLE dbo.Pessoa CREATE TABLE dbo.Pessoa ( [Name] NVARCHAR(101), [BirthDate] DATE, [EmailAddress] NVARCHAR(50), [Phone] NVARCHAR(20) ) INSERT INTO dbo.Pessoa VALUES |
Transparent Data Encryption (TDE)
TDE (Transparent Data Encryption) criptografa os arquivos de dados SQL Server, o que é conhecido como criptografia de dados em repouso (at rest). Em um cenário no qual a mídia física (como unidades ou fitas de backup) é roubada, um terceiro mal-intencionado pode restaurar ou anexar o banco de dados e navegar pelos dados. Uma solução para isso é criptografar dados confidenciais no banco de dados e proteger as chaves usadas para criptografar os dados com um certificado. Isso impede que alguém sem as chaves use os dados, mas esse tipo de proteção deve ser planejada antecipadamente.
O TDE realiza a criptografia e a descriptografia de I/O em tempo real dos arquivos de dados e de log e protege os dados em disco, ou seja, os dados e arquivos de log, fornecendo a capacidade de se adequar a muitas leis, regulamentos e diretrizes estabelecidos em vários setores. Isso permite que os desenvolvedores de software criptografem dados usando algoritmos de criptografia AES e 3DES, sem alterar os aplicativos existentes.
Com essencialmente um toque de mágica, todo o conteúdo de arquivos MDF, arquivos LDF, snapshots, tempdb e backups são criptografados. A criptografia ocorre em tempo real, pois os dados são gravados da memória para o disco, e a descriptografia ocorre quando os dados são lidos do disco e movidos para a memória. A criptografia é feita no nível do banco de dados, portanto, você pode optar por criptografar o número de bancos de dados que desejar.
O TDE é capaz de minimizar a utilização de recursos e ocultar suas atividades dos aplicativos do usuário e do Mecanismo Relacional, pois toda a criptografia / descriptografia ocorre quando as páginas de dados são movidas entre o buffer pool e o disco. Conforme o SQL Server move páginas de dados do buffer pool para o arquivo MDF, o arquivo LDF ou tempdb, os dados são criptografados em tempo real antes de serem gravados no disco. Por outro lado, à medida que as páginas de dados são movidas do arquivo MDF ou tempdb para o buffer pool, elas são descriptografadas. Em outras palavras, quando os dados estão no disco, eles são criptografados, mas quando estão na memória, não são criptografados.
Com relação à performance, a penalidade para se utilizar o Transparent Data Encryption, segundo a Microsoft, é entre 3 a 5% de queda de desempenho apenas. Um valor bem menor quando comparamos com a penalidade de performance ao se utilizar o Always Encrypted, por exemplo.
A criptografia usa uma DEK (chave de criptografia do banco de dados), que é armazenada no registro de inicialização do banco de dados para disponibilidade durante a recuperação. A DEK é uma chave simétrica protegida por um certificado armazenado no banco de dados master do servidor ou uma chave assimétrica protegida por um módulo EKM. O TDE suporta várias opções de criptografia diferentes, como AES com chaves de 128 bits, 192 bits ou 256 bits ou 3 Key Triple DES. Você faz sua escolha ao implementar o TDE.
Always Encrypted vs Transparent Data Encryption (TDE)
Logo abaixo, vou listar algumas semelhanças e diferenças entre essas duas soluções de criptografia do SQL Server:
| Always Encrypted | Transparent Data Encryption (TDE) |
|---|---|
| Nível de coluna | Nível de database |
| Criptografia no cliente (utilizando um driver) | Criptografia no servidor (Database Engine) |
| Servidor não conhece as chaves de criptografia | Servidor conhece as chaves de criptografia |
| Dados na memória são criptografados | Dados na memória são desprotegidos (plain-text) |
| Dados na rede são criptografados | Dados na rede são desprotegidos (plain-text) |
| Apenas os usuários com acesso à chave podem visualizar os dados originais. Nem mesmo o DBA pode visualizar os dados originais sem a chave. | O DBA pode visualizar os dados originais sem a chave |
| Backups e arquivos de log são criptografados | Backups e arquivos de log são criptografados |
| Exige alterações na aplicação (podem ser pequenas ou grandes, de acordo com o algoritmo de criptografia escolhido) | Não exige alterações na aplicação |
| Disponível a partir do SQL Server 2016 - Todas as edições, até Express (Express e Standard a partir do 2016 SP1) | Disponível a partir do SQL Server 2008 - Apenas Enterprise e Developer |
Como utilizar o Transparent Data Encryption (TDE)
Para se implementar o Transparent Data Encryption (TDE), devemos seguir os 4 passos abaixos:
- Criar uma master key: uma master key é criada pela primeira vez. Essa chave, acessível com uma senha, é usada para proteger um certificado, que será criado na próxima etapa. Essa chave é armazenada no banco de dados master em um formato criptografado.
- Criar ou obter um certificado protegido pela master key: Este certificado é usado para proteger a chave de criptografia do banco de dados que criaremos na próxima etapa. Além disso, esse certificado é protegido pela master key que criamos na etapa anterior. O certificado é armazenado no banco de dados master em um formato criptografado.
- Criar uma chave de criptografia do banco de dados: essa é a chave que será usada pelo SQL Server para realmente criptografar os dados. Está protegido pelo certificado criado no passo anterior. Essa chave é armazenada no banco de dados criptografado e armazenada em um formato criptografado.
- Ativar o TDE: Depois que todos os itens acima tiverem sido criados, um comando será executado para informar ao SQL Server para começar a criptografar todos os dados usando a chave de criptografia do banco de dados criada na etapa anterior. Esse processo pode levar algum tempo, dependendo do tamanho do banco de dados. Idealmente, o banco de dados não deve ser usado em produção até que o banco de dados tenha concluído o processo inicial de criptografia.
A imagem abaixo demonstra bem essa arquitetura do TDE:
Para ativar o Transparent Data Encryption (TDE) em um banco de dados, você deve utilizar os comandos abaixo: (lembre-se que a tempdb é criptografada automaticamente quando a criptografia é ativada em qualquer outro database da instância)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
USE [master] GO CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'dirceuresende123_usa_uma_senha_forte_aqui_talquei'; GO CREATE CERTIFICATE MeuCertificadoDoServidor WITH SUBJECT = 'Meu Certificado da Instância'; GO USE [dirceuresende] GO CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE MeuCertificadoDoServidor; GO ALTER DATABASE dirceuresende SET ENCRYPTION ON; GO |
Após executar esses comandos, seu banco estará criptografado. Para verificar quais bancos estão criptografados ou acompanhar o andamento do processo de criptografia, utilize a consulta abaixo:
|
1 2 3 4 5 6 7 8 |
SELECT A.[name], A.is_master_key_encrypted_by_server, A.is_encrypted, B.* FROM sys.databases A JOIN sys.dm_database_encryption_keys B ON B.database_id = A.database_id |
Resultado:
Lembrando que a coluna percent_complete indica o andamento do processo de criptografia do banco de dados e a coluna encryption_state indica em que estado a criptografia se encontra atualmente, cujos valores dessa coluna são:
0 = Nenhuma chave de criptografia de banco de dados presente, nenhuma criptografia
1 = Sem-criptografia
2 = Criptografia em andamento
3 = Criptografado
4 = Alteração de chave em andamento
5 = Descriptografia em andamento
6 = Alteração de proteção em andamento (o certificado ou a chave assimétrica que está criptografando a chave de criptografia do banco de dados está sendo alterado)
Após concluir a criptografia do seu database, você verá uma mensagem de aviso, informando que você TEM que fazer um backup do certificado e da chave privada IMEDIATAMENTE. Caso você perca o certificado ou a chave privada e precise restaurar esse banco em outro servidor, você não irá conseguir.
Warning: The certificate used for encrypting the database encryption key has not been backed up. You should immediately back up the certificate and the private key associated with the certificate. If the certificate ever becomes unavailable or if you must restore or attach the database on another server, you must have backups of both the certificate and the private key or you will not be able to open the database.
Comando para realizar o backup do certificado e da chave privada:
|
1 2 3 4 5 6 7 8 |
USE [master] GO BACKUP CERTIFICATE MeuCertificadoDoServidor TO FILE = 'C:\Backups\Certificados\dirceuresende.cer' WITH PRIVATE KEY ( FILE = 'C:\Backups\Certificados\dirceuresende_Key.pvk', ENCRYPTION BY PASSWORD = 'dirceuresende123_usa_uma_senha_forte_aqui_talquei' ); GO |
Restaurando um banco com Transparent Data Encryption (TDE)
Caso você tente restaurar um arquivo de backup criptografado sem restaurar a master key antes, irá se deparar com essa mensagem de erro:
Msg 33111, Level 16, State 3, Line 12
Cannot find server certificate with thumbprint ‘0xD98C862BF2A4B16D41DC8A96CBE819EFDCF33C00’.
Msg 3013, Level 16, State 1, Line 12
RESTORE DATABASE is terminating abnormally.
Agora vou mostrar como restaurar o banco de dados com TDE em outra instância:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
-- Cria uma nova master key.. Aqui você pode escolher uma nova senha CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'n6ApUO(i<8lRNT,2SF-{3LDzRUR;?MPd-Q-Fg3oec[wqMjKfp^'; GO -- Cria o certificado na master CREATE CERTIFICATE MeuCertificadoDoServidor FROM FILE = 'C:\Backups\Certificados\dirceuresende.cer' WITH PRIVATE KEY ( FILE = 'C:\Backups\Certificados\dirceuresende_Key.pvk', DECRYPTION BY PASSWORD = 'dirceuresende123_usa_uma_senha_forte_aqui_talquei' ) -- Restaura o banco RESTORE DATABASE dirceuresende FROM DISK = 'C:\Backups\dirceuresende.bak' WITH REPLACE, STATS = 5, MOVE 'dirceuresende_Data' TO 'C:\Program Files\Microsoft SQL Server\MSSQL15.SQL2019\MSSQL\DATA\dirceuresende.mdf', MOVE 'dirceuresende_log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL15.SQL2019\MSSQL\DATA\dirceuresende_log.ldf' |
Caso você esteja se deparando com a mensagem de erro abaixo, você provavelmente vai precisar corrigir as permissões da master key e chave privada para habilitar a herança:
The certificate, asymmetric key, or private key file is not valid or does not exist; or you do not have permissions for it.
Para corrigir a herança desses 2 arquivos, siga os passos abaixo:
Transparent Data Encryption e logs de transação
A habilitação de um banco de dados para usar TDE tem o efeito de zerar a parte remanescente do log de transações virtuais para impor o próximo log de transações virtuais. Isso garante que nenhum texto não criptografado seja deixado nos logs de transações depois que o banco de dados for definido para criptografia.
Todos os dados gravados no log de transações antes de uma alteração na chave de criptografia do banco de dados serão criptografados usando a chave de criptografia do banco de dados anterior.
Depois que uma chave de criptografia de banco de dados foi modificada duas vezes, um backup de log deve ser executado para que a chave de criptografia de banco de dados possa ser modificada novamente.
Transparent Data Encryption (TDE) e o In-Memory OLTP
O TDE pode ser habilitado em um banco de dados que tenha objetos OLTP In-Memory. No SQL Server 2016 e nos registros de log OLTP In-Memory, os dados são criptografados se o TDE estiver habilitado. No SQL Server 2014 os registros de log OLTP In-Memory são criptografados se o TDE estiver habilitado, mas os arquivos no filegroup MEMORY_OPTIMIZED_DATA não são criptografados.
Limitações do Transparent Data Encryption (TDE)
- O TDE não protege os dados na memória, portanto, os dados confidenciais podem ser vistos por qualquer pessoa que tenha direitos de DBO em um banco de dados ou direitos de SA para a instância do SQL Server. Em outras palavras, o TDE não pode impedir que os DBAs visualizem os dados que desejam ver.
- TDE não é granular. O banco de dados inteiro é criptografado.
- TDE não protege as comunicações entre aplicativos clientes e o SQL Server, portanto, outros métodos de criptografia devem ser usados para proteger os dados que trafegam pela rede e podem ser interceptados por usuários mal-intencionados.
- No TDE, todos os arquivos e os filegroups do banco de dados são criptografados. Se algum filegroup do banco de dados estiver marcado como READ ONLY, haverá falha na operação de criptografia de banco de dados.
- Dados FILESTREAM não são criptografados.
- Se um banco de dados estiver sendo usado no database mirror ou log shipping, ambos os bancos de dados serão criptografados. As transações de logs serão criptografadas quando enviadas entre eles.
- Quando qualquer banco de dados em uma instância do SQL Server tiver a TDE ativada, o banco de dados tempdb será automaticamente criptografado, o que pode contribuir para um desempenho ruim dos bancos de dados criptografados e não criptografados em execução na mesma instância.
- Embora menos recursos sejam necessários para implementar a TDE do que a criptografia no nível da coluna, ainda haverá um pouco de overhead, o que pode impedir que ela seja usada em SQL Servers que estejam enfrentando problemas de bottlenecks da CPU.
- Os bancos de dados criptografados com o TDE não podem aproveitar a nova compactação de backup do SQL Server 2008. Se você quiser aproveitar a compactação e a criptografia de backup, precisará usar um aplicativo de terceiros, como o SQL Backup, que permite executar essas duas tarefas sem penalidade.
Dynamic Data Masking
Após demonstrar o uso dessa solução de criptografia, você estar se perguntando: “E o Dynamic Data Masking (DDM)???”. Bom, para começar, o DDM não é uma solução de criptografia de dados e sim uma solução de mascaramento de dados.
Enquanto a criptografia de dados efetivamente impede que os seus dados sejam restaurados (inclusive, a partir de backups) e acessados indevidamente, o mascaramento de dados com o Dynamic Data Masking apenas restringe o conteúdo que é mostrado ao final de um comando de SELECT, ou seja, caso você tenha acesso a um arquivo de backup, você pode restaurá-lo em uma instância onde você seja sysadmin e terá acesso livre aos dados antes mascarados.
Para saber mais sobre o Dynamic Data Masking, veja o artigo SQL Server 2016 – Mascaramento de dados com o Dynamic Data Masking (DDM), onde demonstro como utilizá-lo, restrições e até mesmo como “quebrar” o mascaramento e acessar os dados originais (mesmo sem ter permissão para isso).
Bom pessoal, espero que tenham gostado desse artigo e agora comecem a proteger melhor seus dados!
Grande abraço e até a próxima!
Portuguese 
English
1 Response
[…] Criptografia de dados transparente (TDE) – | do SQL Server Microsoft Docs– SQL Server 2008 – Como criptografar seus dados utilizando Transparent Data Encryption …– sys.dm_database_encryption_keys (Transact-SQL) – SQL Server | Microsoft […]