Criptografia Dados Transparente – TDE: Como Criptografar sua Database MSSQL?

Olá, espero que você esteja bem! 😉

Neste post vou falar de uma demanda que está aumentando muito atualmente, devido a LGPD.

LGPG: não vou aprofundar muito neste assunto, poder ser assunto para outro post, rsrs. Mas tenho o dever de falar o básico, para vocês entenderem a importância deste “Lab” que faremos hoje.

Com base no que diz a Lei Geral de Proteção de Dados Pessoais (LGPD)
Art. 46 da Lei 13709/18 (jusbrasil.com.br)

Art. 46. Os agentes de tratamento devem adotar medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou qualquer forma de tratamento inadequado ou ilícito.

§ 1º A autoridade nacional poderá dispor sobre padrões técnicos mínimos para tornar aplicável o disposto no caput deste artigo, considerados a natureza das informações tratadas, as características específicas do tratamento e o estado atual da tecnologia, especialmente no caso de dados pessoais sensíveis, assim como os princípios previstos no caput do art. 6º desta Lei.

§ 2º As medidas de que trata o caput deste artigo deverão ser observadas desde a fase de concepção do produto ou do serviço até a sua execução.

Por isso, as Empresas estão se adequando. Adotando algumas medidas relacionadas à segurança do banco de dados, tratamento e armazenamento. Com o propósito de evitar vazamentos de informações e a exposição de dados pessoais.

Portanto, com base nesse processo de gestão e governança de dados, um grande aliado “agregado” ao SQL Server é o TDE (Transparent Data Encryption). A criptografia de dados transparente, criptografa os arquivos de dados (mdf) e arquivos de log (ldf) no SQL Server. Mas infelizmente não são todas as versões que possuem este recurso. O TDE está disponível desde a versão SQL Server 2008 edições Evaluation, Developer e Enterprise.

Esse processo de criptografia transparente lê a página dos arquivos de dados para o buffer pool, criptografa a página, e grava de volta ao disco. E são descriptografadas quando lidas na memória. Contudo, o TDE não protege os dados na memória, sendo assim, dados podem ser vistos por quaisquer pessoas que tenham direitos de “dbo” em um BD, ou direitos de “sa” para a instância do SQL Server. Outra limitação do TDE é que ele não fornece criptografia entre os canais de comunicações. Por isso recomenda-se utilizar outros métodos de criptografia para proteger os dados que trafegam pela rede e podem ser interceptados.

Pronto, agora podemos iniciar nosso “Lab” de hoje. Vamos habilitar a Criptografia (TDE) em uma Database, no SQL Server. Usei uma versão 2019.

Para esse processo de ativar o TDE vamos seguir uma sequência de 5 etapas:
– Criar uma chave mestra
– Criar um certificado
– Criar uma chave de criptografia
– Ativar criptografia
– Fazer backup do Certificado

1) Criar uma chave mestra
É necessário criar uma chave mestra (Master Key), realizada a nível do banco de dados master. Para isso executaremos o seguinte script:

Caso a Master Key já exista no Servidor, não conseguirá cadastrar outra, neste caso uma opção seria fazer um Drop para depois recadastrar.

Após criar a Master Key, que tal validarmos!

2) Criar um certificado (protegido pela chave mestre Master Key, criada anteriormente)
Após a criação da Master Key, é necessário a criação de um certificado.

CREATE CERTIFICATE TDE_Lab –nome do certificado que será criado
WITH SUBJECT = ‘TDE_ Lab’
,EXPIRY_DATE = ‘2099-12-31’; –data de expiração
GO

Vamos também validar!

Pronto, o certificado já foi criado. E agora, você sabe onde ele está? Para fazermos um backup, seguindo as orientações da Microsoft.

Nesse momento, ainda não temos um backup dos arquivos do certificado. O certificado criado está armazenado no banco de dados master em um formato criptografado.

3) Fazer backup do Certificado
Então vamos fazer o backup e guardar em um local seguro (fora do servidor), não apenas por questão de segurança, para caso de invasão, mas também por precaução, pois o servidor pode “cair” e não mais voltar. Nesse caso teremos que restaurar o certificado em outro local, outro servidor.

OBS: O caminho setado abaixo “F:\Certificado_TDE” foi usado apenas para gerar os arquivos e logo em seguida retirei do Servidor e guardei em um cofre de senhas.

BACKUP CERTIFICATE TDE_Lab TO FILE = ‘F:\Certificado_TDE\TDE_Lab’
WITH PRIVATE KEY (
               FILE = ‘F:\Certificado_TDE\TDE_Lab_CertKey.pvk’
              ,ENCRYPTION BY PASSWORD = ‘ChaveMasterkeySenhaForte@#$%’
              ) –mesma senha usada na master key

Validando o local, veja:

Pronto, agora sim, temos o backup e vamos remover ele do servidor e guardar em um local seguro. Ou melhor, super seguro, pois se perder este certificado e a senha, não teremos mais como fazer um restore do banco o qual aplicaremos o TDE.

4) Criar uma chave de criptografia
Agora vamos então criar uma chave de criptografia, fazendo uma associação entre o banco de dados que será criptografado e o certificado criado. É neste momento que definimos qual será o tipo de algoritmo de criptografia que vamos utilizar. Em nosso “Lab” vamos usar o AES_256.

Antes, vamos validar como está o status das Databases.

SELECT DB.NAME
            ,DB.IS_ENCRYPTED
            ,DM.ENCRYPTION_STATE
            ,DM.PERCENT_COMPLETE
            ,DM.KEY_ALGORITHM
            ,DM.KEY_LENGTH
FROM SYS.DATABASES DB
LEFT OUTER JOIN SYS.DM_DATABASE_ENCRYPTION_KEYS DM ON DB.DATABASE_ID = DM.DATABASE_ID;

Segue script para criar a chave e associar a database desejada, portanto é muito importante usar o “USE” para não executar a criptografia na database errada.

Cannot find the certificate ‘TDE_CERT’, because it does not exist or you do not have permission.

Hum, deu erro, e agora, o que fazer? Onde será que errei? ;(

Será que você consegue descobrir o erro sem ver a resposta abaixo?

Esse está muito fácil, concordo com você. O certificado usado no script está errado, não é este que criamos neste post, portanto não foi encontrado o ‘TDE_CERT’. Vamos então corrigir.

USE LabTDE
GO

CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE TDE_Lab;
GO

Usaremos a mesma query acima para validar a database, veja que legal.

Nesse momento, veja que não temos nenhuma database criptografada (is_encrypted=0). Temos também a coluna encryption_state, onde indicará o status da criptografia. Indica se o banco de dados está criptografado ou não.

0 = Nenhuma chave de criptografia de banco de dados presente, nenhuma criptografia
1 = Não criptografada
2 = Criptografia em andamento
3 = Criptografada
4 = Mudança de chave em andamento
5 = Descriptografia em andamento
6 = Mudança 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 alterada.)

E a coluna percent_complete está com 0 pois ainda não ativamos a criptografia.

5) Ativar criptografia
Vamos agora enfim ativar a criptografia em nossa database “LabTDE”, para isso usaremos o seguinte script:

ALTER DATABASE LabTDE

SET ENCRYPTION ON;

Ao validar o status das databases, veja que a LabTDE ficou com o encryption_state = 2, ou seja, criptografia em andamento, e percentual no momento do print estava com 2,19%. O tempo final necessário para criptografar uma database vai depender não apenas do tamanho da database mas também da performance do servidor. Como exemplo, habilitei o TDE em um servidor cujo a database principal (maior) possuía em torno de 800GB, já as demais eram menores. Para termos certeza do tempo que levaríamos para habilitar o TDE no ambiente de produção, fizemos primeiro no ambiente de homologação. Demorou cerca de 5h. Sabendo desse tempo, agendamos uma “janela de manutenção” em um final de semana e realizamos todo o procedimento na produção, gastando portanto o mesmo tempo da homologação.

No print acima apareceu uma novidade, a database tempdb está como criptografada, mas porquê? Não ativamos a criptografia nela.

Segundo a documentação da Microsoft, acontece o seguinte:

TDE e o banco de dados de sistema tempdb

O banco de dados do sistema tempdb será criptografado se qualquer outro banco de dados da instância do SQL Server for criptografado usando TDE. Essa criptografia poderá ter um efeito de desempenho em bancos de dados não criptografados na mesma instância do SQL Server. Para obter mais informações sobre o banco de dados do sistema tempdb, confira Banco de dados tempdb

Como a tempdb pode ser usada por todas as outras databases em alguma consulta temporária, daí dados criptografados de outra database pode também estar presente na tempdb, por isso a Microsoft achou mais viável projetar a tempdb para ser criptografada logo após a ativação da criptografia. Ou seja, se criptografar qualquer database em uma determinada instância, a tempdb é também criptografada por default.

Uma desvantagem que pode acontecer é quando (na mesma instância) existem outras databases a qual não foram habilitadas o TDE. Com isso, o desempenho em suas transações podem ser prejudicado, devido ao fato de atividades de criptografia e descriptografia que pode estar ocorrendo a todo momento envolvendo suas consultas. Portanto a decisão de habilitar o TDE precisa ser bem pensada, se vale a pena criptografar apenas uma database (mais a tempdb) ou se já ativa o TDE em todas as demais databases do servidor.

Pronto, nossa Database LabTDE está criptografada. Faremos agora um backup full por segurança.

Pronto Pessoal, então acabamos, correto?
Sim! Criamos a chave mestra, o certificado, a chave de criptografia. Em seguida ativamos a criptografia e depois fizemos um backup do certificado.

Mas que tal um bônus! Vamos fazer um Restore? Fique por aí, você vai gostar!

Para fazer este Restore, vou pegar o arquivo de backup que tenho armazenado em um blob contêiner, no Azure, e vou usar o SSMS. Achou interessante?

Tenho um Post específico sobre este conteúdo, se ainda não viu, recomendo. Segue o link:

Restore de Backups Armazenados no Azure usando Microsoft SSMS

Vamos então pegar o arquivo de backup da database “Lab_tde“.

Eita, “algo de errado não está certo”! 😊

Acho melhor a gente fazer um Restore usando apenas nosso amigo T-SQL:

Msg 33111, Level 16, State 3, Line 3
Cannot find server certificate with thumbprint ‘0xD051F29EDDA683611B8EA584C7F87720BB4E5D74’.
Msg 3013, Level 16, State 1, Line 3

RESTORE DATABASE is terminating abnormally.

Também não deu certo! Mas digamos que foi proposital, rsrs.

O erro não tem relação com a maneira que é feito o Restore, mas sim da falta do certificado no Servidor ou Instância a qual está sendo feito o Restore.

Cannot find server certificate

Portanto essa é a ideia. Digamos que temos uma database criptografada e queremos fazer um Restore dela, seja em outra instância ou em outro servidor. Antes temos que importar o certificado que foi usado para criptografar a Database.

Vamos validar.

SELECT *
FROM SYS.CERTIFICATES

BÔNUS – Restaurar Certificado/Backup, in Database

Criamos uma pasta no servidor

Adicionamos uma cópia dos arquivos (que está no cofre) do certificado.

Em seguida executaremos o script abaixo, com atenção nos detalhes:

Nome do Certificado, caminho onde está os arquivos, e chave Master Key.

Recomendo sempre a cada execução, fazer um Double Check. Aprendi e sempre faço, afinal, é sempre importante validar se nosso procedimento feito deu certo ou precisamos refazer, antes de passar para próxima etapa.

Agora sim, temos o nosso certificado cadastrado e vamos continuar com o restore.

Vou aproveitar o nosso script T-SQL anterior e executar.

Executado, database in Restoring.

Agora sim, tudo feito. Faltou apenas um detalhe e não menos importante, pelo contrário, super importante.

Acabou de importar o certificado, fez o backup, já sabe que deu tudo certo, volta agora na pasta onde deixou UMA CÓPIA dos arquivos do certificado e delete eles. Se precisar fazer outro Restore, o certificado já estará cadastrado na master como validamos, e ao deletar os arquivos não afetará o cadastro.

LEMBRE-SE: NÃ DEIXE OS ARQUIVOS DO CERTIFICADO SALVOS NA PASTA (NO SERVIDOR) E NEM A SENHA MASTER KEY SALVA EM UM TXT.

Guarde tudo em um cofre confiável, e tenha todo o cuidado de não perder, pois seu futuro pode depender disso.

É isso meus amigos leitores. Espero que tenham gostado. Este assunto é amplo, nem falamos sobre como fazer para cancelar a criptografia, ou seja, desfazer todo o procedimento feito, retirar a criptografia, deletar o certificado ….. quem sabe futuramente farei outro post com este restante. 😊

Quaisquer dúvidas, sugestões, podem mandar mensagens, escrever nos comentários.

Até breve e obrigado. #gogogo

Referências  Bibliográficas:

– Criptografia de dados transparente (TDE) – | do SQL Server Microsoft Docs
– SQL Server 2008 – Como criptografar seus dados utilizando Transparent Data Encryption (TDE) – Dirceu Resende
– sys.dm_database_encryption_keys (Transact-SQL) – SQL Server | Microsoft Docs