A encriptação é o processo de ofuscar dados através do uso de uma chave ou password. Esta técnica permite tornar os dados inúteis sem a correspondente chave/password. A encriptação não resolve problemas de acesso.
No entanto, aumenta a segurança limitando a disponibilidade da informação caso o sistema de segurança falhe.
Neste artigo iremos abordar o TDE (Transparent data encryption), que é o modelo de encriptação utilizado pelo SQL Server para cifrar arquivos de dados e logs de uma forma transparente, ou seja, sem a necessidade de alteração de código do software ou dos meios de acesso a instância.
Como funciona o TDE?
O método de encriptação TDE cifra instantaneamente a informação contida nos arquivos de log e de dados nas operações de I/O. A criptografia é feita baseada em uma “database encryption key” (DEK), que fica registrada na página de boot do banco de dados, o que permite a sua disponibilidade durante o recovery do BD.
Mais informações sobre a “boot page”: http://www.sqlskills.com/BLOGS/PAUL/post/Search-Engine-QA-20-Boot-pages-and-boot-page-corruption.aspx
A DEK é uma chave simétrica protegida por um certificado guardado no “master” ou por uma chave assimétrica protegida pelo módulo EKM.
O TDE protege os dados nos arquivos de dados e log, o que faz com que sejam cumpridas algumas leis, regulamentos e guias estabelecidos em vários ramos da indústria. Assim, é permitido aos desenviolvedores a utilização dos algorítmos AES e 3DES sem alteração do código do software.
A encriptação é feita ao nível da página, isto é, as páginas de um banco de dados são encriptadas antes de serem escritas no disco e decifradas quando lidas para a memória.
Algumas considerações:
- O TDE passou a existir a partir do SQL Server 2008 apenas.
- O TDE não encripta a comunicação.
- O tamanho do banco de dados não irá aumentar com a ativação do TDE.
- Backups comprimidos terão pouca efetividade.
- Nenhum filegroup pode estar marcado como read-only, caso contrário o processo de ativação do TDE irá falhar.
- Os dados FILESTREAM não são criptografados, mesmo quando TDE é habilitado.
- A tempdb passa a ser encriptada, se houver pelo menos um banco de dados encriptado na instância. Por este motivo, a performance em BDs não encriptados pode ser prejudicada
- Logo após a ativação do TDE é regra a execução do backup do certificado e chaves, caso contrário a base de dados poderá ser perdida em uma situação de desastre.
Usando o TDE
Para ativar o TDE em um banco de dados, deve-se executar o seguinte:
- Criar uma master key
- Criar ou obter um certificado protegido pela master key
- Criar uma DEK (databse encryption key) e protege-la com o certificado do ponto 2
- Habilitar o uso da criptografia no BD
Como fazer isso na prática?
Abaixo passo o código passo-a-passo de como ativar o TDE em um pseudo banco de dados “Certtest”. Criei uma pasta “temp” no disco “D” com objetivo de guardar os backups, que serão usados na segunda parte do exemplo.
USE master;
– Create a master key
CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘masterkey123′;
– Create or obtain a certificate protected by the master key
CREATE CERTIFICATE MyServerCert WITH SUBJECT = ‘TDE Certificate’
GO
– Backup Master Key
OPEN MASTER KEY DECRYPTION BY PASSWORD = ‘masterkey123′;
BACKUP MASTER KEY TO FILE = ‘d:\temp\MasterKey.dat’
ENCRYPTION BY PASSWORD = ’123′;
– Backup certificate
BACKUP CERTIFICATE MyServerCert TO FILE = ‘d:\temp\MyServerCert.dat’
WITH PRIVATE KEY (FILE = ‘d:\temp\PrivateKey_MyServerCert.dat’,ENCRYPTION BY PASSWORD = ’123′)
– Backup service master key
BACKUP SERVICE MASTER KEY TO FILE = ‘d:\temp\S_Master_Key.dat’ ENCRYPTION BY PASSWORD = ’123′;
GO
use Certtest
go
– Create a database encryption key and protect it by the certificate
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE MyServerCert
GO
– Set the database to use encryption
ALTER DATABASE Certtest
SET ENCRYPTION ON;
GO
No código acima, além dos passos básicos, foram feitos backups do certificado e chaves, o que garante que não iremos perder o banco de dados, caso haja um problema grave com a instância.
Feito isto, podemos verificar a ativação do TDE através das seguintes queries, que usam DMVs como recurso:
USE Master
SELECT DB_NAME(database_id), *
FROM sys.dm_database_encryption_keysSELECT * FROM sys.certificates
A primeira query devrá retornar duas linhas, com informação sobre o tempdb e Certtest, onde campos de interesse são: key_algorithm (algorítmo usado) e encryptor_thumbprint (hash do certificado que protege a chave).
Na segunda query, são exibidos todos os certificados do servidor. No nosso caso o iremos ver o certificado MyServerCert, que deverá ter o thumbprint igual ao apresentado na query anterior para o BD Certtest.
Restaurar um banco de dados encriptado para outra instância
Um grande problema dos BDs criptografados é a movimentação entre instâncias, por exemplo, um refresh de desenvolvimento. O que acontece é que se o BD está criptografado, a outra instância deverá ter o mesmo certificado e master key. Aqui temos duas opções:
- Desativar o TDE do banco antes de fazer a cópia e depois reativa-lo, o que não é recomendado.
- Restaurar as chaves e certificado na outra instância e manter o TDE ativo
A primeira abordagem não é elegante, mas é funcional. A segunda opção é elegante, mas no caso exemplificado (refresh de produção para uma instancia de desenvolvimento) pode fazer com que elementos da equipe de dev tenham acesso ao certificado e chaves de produção, isso porque muitas vezes os desenvolvedores fazem parte da server role Sysadmin na instância de desenvolvimento. Uma forma de dar a volta a este assunto, é restaurar o banco de dados e depois desativar o TDE, apagando o certificado e chaves, ou até mesmo usar uma instância intermédia para copiar o banco encriptado, desativar o TDE e somente depois fazer o refresh.
Independentemente do que for feito, segue o código para restaurar o certificado, as chaves e por fim o banco de dados com o TDE ativo (levando em conta o primeiro exemplo):
– Restore service master key
RESTORE SERVICE MASTER KEY FROM FILE = ‘d:\temp\S_Master_Key.dat’
DECRYPTION BY PASSWORD = ’123′;
– Restore Master Key
RESTORE MASTER KEY FROM FILE = ‘d:\temp\MasterKey.dat’
DECRYPTION BY PASSWORD = ’123′
ENCRYPTION BY PASSWORD = ‘masterkey123′
OPEN MASTER KEY DECRYPTION BY PASSWORD = ‘masterkey123′;
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY;
CLOSE MASTER KEY;
go
– Restore certificate
USE Master;
OPEN MASTER KEY DECRYPTION BY PASSWORD = ‘masterkey123′
CREATE CERTIFICATE MyServerCert FROM FILE = ‘d:\temp\MyServerCert.dat’
WITH PRIVATE KEY (FILE = ‘d:\temp\PrivateKey_MyServerCert.dat’, DECRYPTION BY PASSWORD = ’123′);
CLOSE MASTER KEY;
GO
OPEN MASTER KEY DECRYPTION BY PASSWORD = ‘masterkey123′;
RESTORE DATABASE [Certtest] FROM DISK = N’D:\temp\Certtest.bak’ WITH FILE = 1,
MOVE N’Certtest’ TO N’<path_de_dados>\Certtest.mdf’,
MOVE N’Certtest_log’ TO N’<path_de_logs>\Certtest_1.ldf’,
NOUNLOAD, STATS = 10
CLOSE MASTER KEY;
go
Após esta operação, você terá uma cópia do banco de dados com o TDE ativo em outra instância.
Espero com este artigo ter atingido os principais pontos do TDE. Obviamente existe uma infinidade de situações que podem aparecer, como erros no restore do BD criptografado, mas é difícil expor tudo aqui. Caso surja alguma dúvida, sugestão ou correção de algo estarei disponível para ajudar ou atualizar o texto.
Links e referências:
http://msdn.microsoft.com/en-us/library/bb934049.aspx