TDE no SQL Server

Como habilitar Transparent Data Encryption e proteger dados em repouso

Dentro de uma empresa, há diversas camadas de segurança (rede, identidade, controle de acesso, monitoramento). Ainda assim, um risco frequentemente subestimado é o “offline attack”: alguém copia os arquivos do banco ou um backup e restaura/anexa em outra instância para ler dados. O TDE existe exatamente para reduzir esse vetor, criptografando os arquivos de dados e log em disco.

O que é TDE e o que ele protege (sem mito)

O Transparent Data Encryption criptografa os arquivos de dados e log do banco com criptografia/descriptografia em tempo real durante operações de I/O, no nível de página.

O TDE é uma solução de criptografia em repouso — ele não fornece criptografia em canais de comunicação (rede) e não mantém os dados criptografados na memória. Para criptografia em trânsito, você deve usar TLS/SSL na conexão.

O que mais fica criptografado?

• Backups: arquivos de backup de bases com TDE habilitado também ficam criptografados pela DEK.
• tempdb: é criptografado automaticamente quando qualquer base de usuário na instância habilita TDE, por design.
• Snapshots: páginas derivadas de uma base criptografada permanecem criptografadas.

Como o TDE funciona (hierarquia de chaves em linguagem prática)

O TDE usa uma chave simétrica chamada Database Encryption Key (DEK). A hierarquia envolve o Service Master Key (SMK) e o Database Master Key (DMK), com DPAPI no topo protegendo a cadeia.

O ponto operacional mais crítico: se o certificado e a chave privada não estiverem com backup seguro, você pode perder a capacidade de restaurar/migrar o banco.

Passo a passo para habilitar TDE (com boas práticas)

A sequência recomendada para habilitar o TDE em SQL Server é: criar DMK no master, criar certificado, criar DEK na base de usuário e ativar a criptografia na base.

1) Criar a Master Key no master (DMK)

USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Use_Uma_Senha_Forte_Aqui';
GO

Essa chave é parte da hierarquia de criptografia e é usada para proteger certificados e chaves no contexto necessário ao TDE.

2) Criar o certificado (e fazer backup imediatamente)

USE master;
GO
CREATE CERTIFICATE TdeCert
WITH SUBJECT = 'Certificado para TDE';
GO

Logo após criar o certificado, faça backup do certificado e da chave privada. Sem isso, restaurar/anexar o banco em outro servidor pode se tornar impossível.

-- BACKUP OBRIGATÓRIO (guarde em local seguro e com controle de acesso)
BACKUP CERTIFICATE TdeCert
TO FILE = 'D:\Seguranca\TdeCert.cer'
WITH PRIVATE KEY (
  FILE = 'D:\Seguranca\TdeCert_PrivateKey.pvk',
  ENCRYPTION BY PASSWORD = 'Outra_Senha_Forte_Aqui'
);
GO

3) Criar a DEK na base de usuário (AES_256 recomendado na maioria dos cenários)

O SQL Server suporta algoritmos como AES e 3DES para TDE; na prática moderna, AES (ex.: AES_256) é o padrão mais comum.

USE SuaBase;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TdeCert;
GO

4) Habilitar a criptografia (processo em background)

ALTER DATABASE SuaBase SET ENCRYPTION ON;
GO

A criptografia inicial é executada por threads de background e faz um “scan” de páginas: lê páginas no buffer pool e regrava no disco já criptografadas.

Monitoramento: como saber se a criptografia terminou

A DMV sys.dm_database_encryption_keys retorna o estado de criptografia e o progresso (%), além de descrever estados de recriptografia e descriptografia.

SELECT
  DB_NAME(database_id) AS database_name,
  encryption_state,
  percent_complete,
  key_algorithm,
  key_length
FROM sys.dm_database_encryption_keys;
GO

Interpretação rápida do encryption_state: 0 (sem DEK), 2 (criptografia em andamento), 3 (criptografado), 5 (descriptografia em andamento), entre outros.

Controle do “TDE scan” (SQL Server 2019+)

A partir do SQL Server 2019, existe a possibilidade de suspender e retomar o scan de criptografia para reduzir impacto em horário crítico, usando ALTER DATABASE ... SET ENCRYPTION SUSPEND/RESUME.

-- Pausar o scan
ALTER DATABASE SuaBase SET ENCRYPTION SUSPEND;
GO

-- Retomar o scan
ALTER DATABASE SuaBase SET ENCRYPTION RESUME;
GO

Limitações e cuidados que evitam dor de cabeça

• Não funciona em bases de sistema: TDE não pode criptografar master, model e msdb (e tempdb não é criptografado diretamente; ele é automático quando houver TDE em base de usuário).
• Filegroups READ ONLY: se algum filegroup estiver marcado como READ ONLY, a operação de criptografia falha.
• Operações bloqueadas durante criptografia inicial/troca de chave: algumas ações (detach, offline, criar snapshot, etc.) são restritas enquanto o processo está em andamento.
• FILESTREAM não é criptografado: mesmo com TDE habilitado, dados FILESTREAM não entram no escopo do TDE.
• Tempdb pode impactar todos os bancos: ao criptografar tempdb automaticamente, pode haver efeito de performance inclusive para bases não criptografadas na mesma instância.

Disponibilidade por edição (o que vale hoje)

Em versões atuais como SQL Server 2022, o recurso Transparent data encryption (TDE) está disponível nas edições Enterprise e Standard (e o Developer herda os recursos do Enterprise para dev/test).

Comparativo rápido: TDE vs outras formas de criptografia

Para referência oficial, sintaxe completa, limitações e recomendações, consulte: Documentação Microsoft: Transparent Data Encryption (TDE).

Se você quer transformar TDE em um processo seguro (padrão de backup/rotação de certificados, integração com HA/DR e monitoramento), vale conhecer os serviços de gestão e sustentação de infraestrutura da Tripletech e, se preferir, falar com um especialista para um plano sob medida.