Criptografia Transparente de Dados - Parte I

Passei essa semana testando a nova funcionalidade de criptografia do SQL Server 2008, a TDE(Transparent Data Encryption), comecei a ler e fiquei muito interessado pois era exatamente o que eu precisava, pois ela funciona a nível dos arquivos (.mdf e .ldf) do banco de dados.

A TDE criptografa os arquivos isso quer dizer que após o acesso ao banco de dados todas as informações estarão disponíveis, mas o problema esta justamente ai, para ter este acesso...

Nesta primeira parte veremos como implementar esta funcionalidade em um banco de dados, nos próximos post veremos os detalhes dos testes realizados.

Estou utilizando o SQL Server 2008 Developer Edition com SP2, build 10.0.4000.

Primeiramente criei um banco de dados simples com somente uma tabela:

USE Master
GO

CREATE DATABASE Criptografia
GO

USE Criptografia
GO

CREATE TABLE Pessoa(
 Codigo int IDENTITY(1,1) NOT NULL PRIMARY KEY,
 Nome varchar(20) NOT NULL,
 Idade int NULL) ON [PRIMARY]
GO

Em seguida inserir alguns registros:

INSERT INTO Pessoa VALUES ('Rodrigo Figueiredo',25)
GO 100

Vamos começar agora a implantar a TDE no banco Criptografia:

--Primeiro passo: Criar Master Key encryption no banco master
USE master
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'MasterKeysenha'
GO

/* Segundo passo: Criar um certificado no banco master.
 A chave privada deste certificado será protegida pela Master Key*/
USE master
GO

CREATE CERTIFICATE CertificadoCriptografia
WITH SUBJECT = 'Certificado Criptografia'
GO

Agora que já criamos a Master Key e o Certificado podemos criptografar o banco de dados:

/* Terceiro passo: criar uma chave de criptografia para a base de dados,
   usando o certificado criado anteriormente.
   Podemos escolher o algoritmo de criptografia que queremos usar:
   triple DES, AES 128, AES 192 ou AES 256 */

USE Criptografia
GO

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

/* Este comando vai retornar um Warning,
 Lembrando que devemos fazer um backup de nosso certificado imediatamente. */

USE master
GO

BACKUP CERTIFICATE CertificadoCriptografia
TO FILE = 'C:\Backup Criptografia\Criptografia_certificate.cer'
WITH PRIVATE KEY (FILE = 'C:\Backup Criptografia\Criptografia_certkey.pvk',
 ENCRYPTION BY PASSWORD = 'MasterKeysenha');
GO

--Quarto passo: habilitar o TDE na nossa base
ALTER DATABASE Criptografia
SET ENCRYPTION ON
GO

Neste momento o banco Criptografia está criptografado utilizando o algoritmo AES_256. Se executarmos a consulta:

SELECT DB_NAME(e.database_id) AS DatabaseName,
            e.encryption_state,
    CASE e.encryption_state
                WHEN 0 THEN 'No database encryption key present, no encryption'
                WHEN 1 THEN 'Unencrypted'
                WHEN 2 THEN 'Encryption in progress'
                WHEN 3 THEN 'Encrypted'
                WHEN 4 THEN 'Key change in progress'
                WHEN 5 THEN 'Decryption in progress'
    END AS encryption_state_desc,
   key_algorithm +'_'+ convert(nvarchar,key_length) [Algoritmo],
            c.name [Nome Certificado],
            set_date [Data Criptografia]
    FROM sys.dm_database_encryption_keys AS e
    LEFT JOIN master.sys.certificates AS c
    ON e.encryptor_thumbprint = c.thumbprint

Veremos que dois bancos estão criptografados usando o algoritmo AES_256, o banco Criptografia utilizando certificado criado por nós e o banco tempdb sem utilizar nenhum certificado. O banco tempdb é criptografado sempre que qualquer banco da instância for criptgrafado, isso acontece porque o tempdb é utilizado por todos os banco de dados existentes na instância.

Como sabemos toda criptogafia tem um custo de I/O e principalmente de CPU, a criptografia após aplicada no banco de dados funciona da seguinte maneira: Toda vez no momento que a informação é gravada no disco ela é criptografada e sempre que for lida do disco para a mémoria ela é descriptograda, isso gera um custo de I/O, mas praticamente imperceptível. O custo maior fica por conta do processamento, devido ao algoritmo usado, quanto mais seguro for o algoritmo maior será o custo de CPU.

Bem galera esta foi a primeira parte e mostrei apenas como implementar TDE em um banco de dados, nós próximos posts falarei dos testes feitos, de backup e restore do banco de um servidor para outro e também detach e attach entre servidores utilizando TDE.

Abraços,
Rodrigo Figueiredo
figueiredo.rodrigo@hotmail.com