Cifrar não chega: a gestão de chaves é o verdadeiro teste da segurança com TDE no SQL Server
Há uma afirmação frequente em reuniões de segurança: “Os nossos dados estão cifrados.” Transmite tranquilidade, mas raramente reflete a totalidade do problema. A questão que deve seguir-se imediatamente é: “E as chaves de cifra, onde estão armazenadas e quem as controla?” É precisamente neste ponto que a maioria das implementações de Transparent Data Encryption (TDE) no SQL Server fica aquém das exigências de segurança.
Série: Segurança SQL Server | Artigo 2 de 3
Esta série aborda os pilares fundamentais da proteção de bases de dados em SQL Server: Data Discovery & Classification, Transparent Data Encryption (TDE) e Controlo de Acessos e Row-Level Security.
O que é o TDE e o que realmente protege
O Transparent Data Encryption (TDE) cifra os ficheiros da base de dados em repouso: os ficheiros .mdf, .ndf e .ldf no disco, bem como os respetivos backups. O termo “transparente” significa que a aplicação não necessita de qualquer alteração de código, já que o SQL Server efetua o processo de cifra e decifra automaticamente no motor de dados.
Roubo ou perda física de suportes de armazenamento. Se os discos forem removidos ou se existir uma cópia de backup não autorizada, os dados permanecem ilegíveis sem a chave correspondente.
Acessos efetuados através de ligações autenticadas ao SQL Server. Um utilizador com permissões válidas visualiza os dados normalmente. O TDE é uma camada essencial de proteção, mas não deve ser a única.
A arquitetura de chaves do TDE
O TDE utiliza uma hierarquia criptográfica em três níveis. Compreender esta estrutura é fundamental para gerir a segurança de forma eficiente e prevenir falhas críticas no Disaster Recovery:
Gerada automaticamente na instalação da instância do SQL Server e protegida pela API DPAPI do Windows.
Protege a DEK e fica guardado na base de dados master. Tem de ser exportado e salvaguardado externamente.
A chave (DEK) que cifra efetivamente os dados da base de dados, protegida pelo Certificado do servidor.
-- 1. Criar a Master Key e o Certificado na base de dados master USE master; CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'P@ssw0rd!Forte123'; CREATE CERTIFICATE TDE_Certificado WITH SUBJECT = 'Certificado TDE Produção', EXPIRY_DATE = '2030-12-31'; -- 2. Ativar o TDE na base de dados aplicacional USE MinhaBaseDados; CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE TDE_Certificado; ALTER DATABASE MinhaBaseDados SET ENCRYPTION ON;
O passo crítico: exportar e salvaguardar o certificado
Ativar o TDE sem exportar o certificado e a chave privada equivale a trancar a porta e deixar a única chave no interior. Se o servidor sofrer uma avaria e for necessário restaurar a base de dados noutro equipamento, o backup estará cifrado e será completamente inacessível sem esse certificado.
Atenção: Um backup cifrado com TDE sem o certificado e a chave privada correspondentes não pode ser restaurado. Não existem exceções nem ferramentas de recuperação. Esta é uma das causas mais frequentes de perda definitiva de dados em cenários de Disaster Recovery.
-- Exportar obrigatoriamente o certificado e a chave privada para local seguro BACKUP CERTIFICATE TDE_Certificado TO FILE = 'D:\Backups_Seguros\TDE_Certificado.cer' WITH PRIVATE KEY ( FILE = 'D:\Backups_Seguros\TDE_Certificado_PrivKey.pvk', ENCRYPTION BY PASSWORD = 'OutraPasswordForte!456' );
TDE com Azure Key Vault: Bring Your Own Key (BYOK)
Para empresas com requisitos rigorosos de compliance e regulamentação, o modelo BYOK (Bring Your Own Key) com o Azure Key Vault permite isolar a gestão de chaves num serviço externo. Isto garante a separação efetiva de funções entre quem administra a base de dados e quem detém o controlo das chaves criptográficas.
Isolamento do material
O SQL Server utiliza a chave para operações criptográficas, mas o material da chave nunca é exposto nem armazenado no servidor local.
Auditoria detalhada
Registo completo de cada utilização da chave no Key Vault, identificando quem acedeu, quando e a partir de que endereço IP.
Revogação imediata
Desativar a chave no Key Vault corta o acesso à base de dados em minutos, uma funcionalidade crítica para resposta a incidentes.
Rotação de chaves
Processo automatizável, auditado e sem downtime, substancialmente mais seguro do que a rotação manual de certificados locais.
-- Configurar o conector Extensible Key Management (EKM) para Azure Key Vault CREATE CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov FROM FILE = 'C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault\Microsoft.AzureKeyVaultService.EKM.dll'; CREATE CREDENTIAL Azure_EKM_TDE_cred WITH IDENTITY = 'ClientID=xxxx;ClientSecret=xxxx', SECRET = 'https://meu-keyvault.vault.azure.net' FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov;
TDE On-Premises vs. Azure Key Vault: Comparação técnica
| Característica | TDE Local (On-Premises) | TDE com Azure Key Vault |
|---|---|---|
| Gestão de chaves | Interna na instância SQL Server | Serviço externo gerido |
| Separação de funções | Complexa de implementar | Nativa por permissões IAM |
| Auditoria de utilização | Não disponível | Completa no Key Vault |
| Revogação imediata | Exige intervenção na instância | Imediata ao desativar a chave |
| Rotação de chaves | Manual e sujeita a erro humano | Automatizável e auditada |
| Custos adicionais | Incluído no SQL Server | Custo residual do Azure Key Vault |
4 Questões essenciais para os responsáveis de TI
“A base de dados de produção está cifrada com TDE?”
Verificável em segundos através da query: SELECT name, is_encrypted FROM sys.databases.
“O certificado TDE está salvaguardado fora do servidor e testado?”
Este é o ponto crítico. Muitas empresas ativam o TDE mas nunca testaram a recuperação noutro servidor. Sem o certificado, a cópia de segurança é inutilizável.
“Quem controla o acesso às chaves de cifra?”
Na gestão local, o controlo reside tipicamente no DBA. Com o Azure Key Vault, a gestão passa para a equipa de segurança, garantindo a separação de funções recomendada.
“Existe uma política formal de rotação de chaves?”
As chaves criptográficas devem ser renovadas periodicamente. O Azure Key Vault permite automatizar e auditar este ciclo de vida de forma transparente.
Azure Key Vault
BYOK
Gestão de Chaves
SQL Server
Encriptação em Repouso
Conclusão
O TDE é um pilar indispensável para proteger dados em repouso contra o acesso físico não autorizado. Contudo, a eficácia do TDE depende inteiramente da maturidade na gestão das chaves criptográficas. Definir quem controla as chaves, assegurar cópias de segurança externas dos certificados e testar procedimentos de Disaster Recovery é o que distingue uma arquitetura verdadeiramente protegida de uma ilusão de segurança.
A configuração de TDE da sua empresa está devidamente protegida?
A equipa da Singular Data implementa, audita e otimiza arquiteturas de TDE em ambientes SQL Server e Azure, assegurando a integração com o Azure Key Vault e a formalização de planos de salvaguarda de chaves.