TDE (Transparent Data Encryption)

Aplica-se a: SQL Server Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure Azure Synapse Analytics Analytics Platform System (PDW)

A Transparent Data Encryption (TDE) criptografa de forma transparente os arquivos de dados do SQL Server, do Banco de Dados SQL do Azure e do Azure Synapse Analytics. Essa criptografia é conhecida como criptografia de dados em repouso.

Para ajudar a proteger um banco de dados de usuário, você pode tomar precauções como:

• Projetar um sistema seguro.
• Criptografar ativos confidenciais.
• Criar um firewall em todos os servidores de banco de dados.

No entanto, uma parte mal-intencionada que rouba mídia física, como unidades ou fitas de backup, pode restaurar ou anexar o banco de dados e navegar em seus dados.

Uma solução é criptografar dados confidenciais em um banco de dados e usar um certificado para proteger as chaves que criptografam os dados. Essa solução impede que alguém sem as chaves use os dados. Mas você deve planejar esse tipo de proteção com antecedência.

A TDE realiza a criptografia e a descriptografia de E/S em tempo real dos arquivos de log e de dados. A criptografia usa uma DEK (chave de criptografia de banco de dados). O registro de inicialização do banco de dados armazena a chave para disponibilidade durante a recuperação. A DEK é uma chaev simétrica e é protegido por um certificado que o banco de dados master do servidor armazena ou por uma chave assimétrica que o módulo EKM protege.

A TDE protege os dados "em repouso", que são os dados e os arquivos de log. Ele permite que você siga muitas leis, regulamentos e diretrizes estabelecidos em vários setores. Isso permite que os desenvolvedores de software criptografem dados usando algoritmos de criptografia AES e 3DES, sem alterar os aplicativos existentes.

A TDE não fornece criptografia em canais de comunicação. Para obter mais informações sobre como criptografar dados em canais de comunicação, confira Configurar conexões criptografadas no Mecanismo de Banco de Dados do SQL Server.

Tópicos relacionados:

• Transparent Data Encryption para Banco de Dados SQL, Instância Gerenciada de SQL e Azure Synapse Analytics
• Introdução à criptografia de dados transparente (TDE) no Azure Synapse Analytics
• Mover um banco de dados protegido por TDE para outro SQL Server
• Habilitar TDE no SQL Server usando EKM
• Usar o Conector do SQL Server com recursos de criptografia do SQL
• O blog de segurança do SQL Server na TDE com Perguntas frequentes

Sobre a TDE

A criptografia de um arquivo de banco de dados é feita no nível da página. As páginas em um banco de dados criptografado são criptografadas antes de serem gravadas no disco e descriptografadas quando lidas na memória. A TDE não aumenta o tamanho do banco de dados criptografado.

Informações aplicáveis ao Banco de dados SQL

Quando você usa o TDE com o Banco de Dados SQL do Azure, o banco de dados SQL cria automaticamente o certificado no nível de servidor armazenado no banco de dados master. Para mover um banco de dados TDE no banco de dados SQL, não é necessário descriptografar o banco de dados para a operação de movimentação. Para obter mais informações sobre como usar a TDE com o banco de dados SQL, confira criptografia de dados transparente com o Banco de Dados SQL do Azure.

Informações aplicáveis ao SQL Server

Depois de proteger um banco de dados, você pode restaurá-lo usando o certificado correto. Para obter mais informações sobre certificados, consulte SQL Server Certificates and Asymmetric Keys.

Depois de habilitar o TDE, faça backup imediatamente do certificado e de sua chave privada associada. Se o certificado ficar indisponível ou se você restaurar ou anexar o banco de dados em outro servidor, precisará de backups do certificado e da chave privada. Caso contrário, você não poderá abrir o banco de dados. O backup de certificados armazenados em um banco de dados do sistema independente também deverá ser efetuado.

Mantenha o certificado de criptografia mesmo se você tiver desabilitado a TDE no banco de dados. Embora o banco de dados não esteja criptografado, partes do log de transações podem permanecer protegidas. Você também pode precisar do certificado para algumas operações até fazer um backup completo do banco de dados.

Você ainda pode usar um certificado que exceda sua data de validade para criptografar e descriptografar dados com o TDE.

Hierarquia de criptografia

A API de Proteção de Dados do Windows (DPAPI) está na raiz da árvore de criptografia, protege a hierarquia de chaves no nível do computador e é usada para proteger a chave mestra de serviço (SMK) para a instância do servidor de banco de dados. O SMK protege a chave mestra do banco de dados (DMK), que é armazenada no nível do banco de dados do usuário e protege certificados e chaves assimétricas. Essas chaves, por sua vez, protegem chaves simétricas, que protegem os dados. O TDE usa uma hierarquia semelhante ao certificado. Quando você usa TDE, o DMK e o certificado devem ser armazenados no banco de dados master. Uma nova chave, usada apenas para TDE e chamada de chave de criptografia de banco de dados (DEK), é criada e armazenada no banco de dados do usuário.

A ilustração a seguir mostra a arquitetura de criptografia da TDE. Somente os itens de nível de banco de dados (a chave de criptografia do banco de dados e partes de ALTER DATABASE) são configuráveis pelo usuário quando você usa a TDE no banco de dados SQL.

Habilitar a TDE

Para usar a TDE, execute estes procedimentos.

Aplica-se a: SQL Server.

1. Crie uma chave mestra.
2. Crie ou obtenha um certificado protegido pela chave mestra.
3. Crie uma chave de criptografia de banco de dados e proteja-a usando o certificado.
4. Defina o banco de dados para usar criptografia.

O exemplo a seguir mostra a criptografia e a descriptografia do banco de dados AdventureWorks2022 usando um certificado chamado MyServerCert que está instalado no servidor.

USE master;
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
GO

CREATE CERTIFICATE MyServerCert
    WITH SUBJECT = 'My DEK Certificate';
GO

USE AdventureWorks2022;
GO

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

ALTER DATABASE AdventureWorks2022
    SET ENCRYPTION ON;
GO

As operações de criptografia e descriptografia são agendadas em threads em segundo plano pelo SQL Server. Para ver o status dessas operações, use as exibições do catálogo e de gerenciamento dinâmico na tabela mostrada posteriormente neste artigo.

Comandos e funções

Para as instruções a seguir aceitarem certificados de TDE, use uma chave mestra de banco de dados para criptografá-los. Se você criptografá-los apenas por senha, as instruções os rejeitarão como criptografadores.

A seguinte tabela fornece links e explicações de comandos e funções da TDE:

Exibições do catálogo e exibições de gerenciamento dinâmico

A tabela a seguir mostra exibições do catálogo de TDE e exibições de gerenciamento dinâmico (DMV).

Permissões

Cada recurso e comando da TDE têm requisitos individuais de permissões, conforme descrito nas tabelas anteriores.

A exibição de metadados envolvidos com a TDE requer a permissão VIEW DEFINITION em um certificado.

Considerações

Quando um exame de recriptografia para uma operação de criptografia de banco de dados está em andamento, as operações de manutenção no banco de dados são desabilitadas. Você pode usar a configuração de modo de usuário único para o banco de dados executar as operações de manutenção. Veja mais informações em Definir um banco de dados como modo de usuário único.

Use o modo de exibição de gerenciamento dinâmico sys.dm_database_encryption_keys para descobrir o estado da criptografia de banco de dados. Veja mais informações na seção Exibições do catálogo e exibições de gerenciamento dinâmico no início deste artigo.

Na TDE, todos os arquivos e os grupos de arquivos em um banco de dados são criptografados. Se qualquer grupo de arquivos em um banco de dados estiver marcado como READ ONLY, a operação de criptografia de banco de dados falhará.

Se você usar um banco de dados no espelhamento de banco de dados ou no envio de logs, ambos os bancos serão criptografados. As transações de logs são criptografadas quando enviadas entre eles.

Limitações

As seguintes operações são proibidas durante criptografia de banco de dados inicial, alteração de chave ou descriptografia de banco de dados:

• Descartar um arquivo de um grupo de arquivos em um banco de dados
• Cancelar um banco de dados
• Colocar um banco de dados offline
• Desanexando um banco de dados
• Fazendo a transição de um banco de dados ou grupo de arquivos para um estado READ ONLY

As operações a seguir não são permitidas durante as instruções CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE ENCRYPTION KEY, DROP DATABASE ENCRYPTION KEY e ALTER DATABASE...SET ENCRYPTION:

• Descartar um arquivo de um grupo de arquivos em um banco de dados
• Cancelar um banco de dados
• Colocar um banco de dados offline
• Desanexando um banco de dados
• Fazendo a transição de um banco de dados ou grupo de arquivos para um estado READ ONLY
• Usar um comando ALTER DATABASE
• Iniciar um banco de dados ou backup de arquivo de banco de dados
• Iniciar um banco de dados ou restauração de arquivo de banco de dados
• Criar um instantâneo

As operações ou condições a seguir impedem as instruções CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE ENCRYPTION KEY, DROP DATABASE ENCRYPTION KEY e ALTER DATABASE...SET ENCRYPTION:

• Um banco de dados é somente leitura ou tem grupos de arquivos somente leitura.
• Um comando ALTER DATABASE está em execução.
• Um backup de dados está sendo executado.
• Um banco de dados está em condição de restauração ou offline.
• Um instantâneo está em andamento.
• As tarefas de manutenção do banco de dados estão em execução.

Quando os arquivos de banco de dados são criados, a inicialização instantânea de arquivo fica não disponível quando o TDE está habilitado.

Para criptografar a DEK com uma chave assimétrica, a chave assimétrica deve estar em um provedor de gerenciamento de chaves extensível.

Verificação da TDE

Para habilitar o TDE em um banco de dados, o SQL Server deve fazer uma verificação de criptografia. A verificação lê cada página dos arquivos de dados no pool de buffers e, em seguida, grava as páginas criptografadas de volta no disco.

Para fornecer a você mais controle sobre a verificação de criptografia, o SQL Server 2019 (15.x) apresenta a verificação de TDE, que tem uma sintaxe de suspensão e de retomada. Você pode pausar a verificação, enquanto a carga de trabalho no sistema é pesada ou durante horários críticos para os negócios e então retomar a verificação mais tarde.

Use a sintaxe a seguir para pausar a verificação de criptografia de TDE:

ALTER DATABASE <db_name> SET ENCRYPTION SUSPEND;

Da mesma forma, use a seguinte sintaxe para retomar a verificação de criptografia TDE:

ALTER DATABASE <db_name> SET ENCRYPTION RESUME;

A coluna encryption_scan_state foi adicionada à exibição de gerenciamento dinâmico sys.dm_database_encryption_keys. Ela mostra o estado atual da verificação de criptografia. Há também uma nova coluna chamada encryption_scan_modify_date, que contém a data e a hora da última alteração de estado de verificação de criptografia.

Se a instância do SQL Server for reiniciada enquanto sua verificação de criptografia estiver suspensa, uma mensagem será registrada no log de erros durante a inicialização. A mensagem indica que uma verificação existente foi colocada em pausa.

TDE e logs de transações

A TDE protege arquivos de dados e arquivos de log em repouso. Criptografar todo o banco de dados depois de habilitar a TDE em um banco de dados não criptografado é uma operação de dados considerável e o tempo necessário depende dos recursos do sistema nos quais esse banco de dados está sendo executado. A DMV sys.dm_database_encryption_keys pode ser usada para determinar o estado de criptografia de um banco de dados.

Quando a TDE for ativada, o Mecanismo de Banco de Dados forçará a criação de um novo log de transações, que será criptografado pela chave de criptografia do banco de dados. Qualquer log gerado por transações anteriores ou transações atuais de execução prolongada intercaladas entre a alteração de estado TDE não será criptografado.

Os logs de transações podem ser monitorados por meio da DMV sys.dm_db_log_info DMV, que também mostra se o arquivo de log está criptografado ou não usando a coluna vlf_encryptor_thumbprint, disponível no SQL do Azure e no SQL Server 2019 (15.x) e versões posteriores. Para localizar o status da criptografia do arquivo de log usando a coluna encryption_state na exibição sys.dm_database_encryption_keys, aqui está um exemplo de consulta:

USE AdventureWorks2022;
GO

/* The value 3 represents an encrypted state
   on the database and transaction logs. */
SELECT *
FROM sys.dm_database_encryption_keys
WHERE encryption_state = 3;
GO

Para obter mais informações sobre a arquitetura de arquivos de registro do SQL Server, confira O log de transações.

Antes que uma DEK seja alterada, a DEK anterior criptografa todos os dados gravados no log de transações.

Se você alterar uma DEK duas vezes, deverá fazer um backup de log antes de poder alterá-la novamente.

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.

TDE e replicação

A replicação não replica automaticamente os dados de um banco de dados habilitado para TDE em um formulário criptografado. Habilite separadamente a TDE se quiser proteger a distribuição e os bancos de dados dos assinantes.

A replicação de instantâneo pode armazenar dados em arquivos intermediários não criptografados, como arquivos BCP. A distribuição de dados inicial para replicação transacional e de mesclagem também pode. Durante essa replicação, você pode habilitar a criptografia para proteger o canal de comunicação.

Para obter mais informações, confira Configurar o Mecanismo de Banco de Dados do SQL Server para criptografia de conexões.

TDE e grupos de disponibilidade

Você pode adicionar um banco de dados criptografado a um grupo de disponibilidade Always On.

Para criptografar bancos de dados que fazem parte de um grupo de disponibilidade, crie a chave mestra e os certificados ou a chave assimétrica (EKM) em todas as réplicas secundárias antes de criar a chave de criptografia de banco de dados na réplica primária.

Se um certificado for usado para proteger a DEK, faça backup do certificado criado na réplica primária e, em seguida, crie o certificado a partir de um arquivo em todas as réplicas secundárias antes de criar a DEK na réplica primária.

TDE e os dados FILESTREAM

Os dados FILESTREAM não são criptografados mesmo quando você habilita a TDE.

TDE e backups

Os certificados normalmente são usados na Transparent Data Encryption para proteger a DEK. O certificado deve ser criado no banco de dados master. Os arquivos de backup de bancos de dados com TDE habilitada também são criptografados usando a DEK. Como resultado, quando você restaura a partir desses backups, o certificado que protege a DEK deve estar disponível. Isso significa que, além de fazer backup do banco de dados, você deve manter os backups dos certificados de servidor para evitar perda de dados. Se o certificado não estiver mais disponível, haverá perda de dados.

Remove TDE

Remova a criptografia do banco de dados usando a instrução ALTER DATABASE.

ALTER DATABASE <db_name> SET ENCRYPTION OFF;

Para exibir o estado do banco de dados, use a exibição de gerenciamento dinâmico sys.dm_database_encryption_keys.

Aguarde a conclusão da descriptografia antes de remover a DEK usando DROP DATABASE ENCRYPTION KEY.

TDE e a extensão do pool de buffers

Quando você criptografa um banco de dados usando TDE, os arquivos relacionados à BPE (extensão do pool de buffers) não são criptografados. Para esses arquivos, use ferramentas de criptografia como BitLocker ou EFS no nível do sistema de arquivos.

TDE e OLTP in-memory

Você pode habilitar a TDE em um banco de dados que tem objetos OLTP in-memory. No SQL Server 2016 (13.x) e no Banco de Dados SQL do Azure, os registros e dados de log OLTP in-memory são criptografados se você habilitar o TDE. No SQL Server 2014 (12.x), os registros de log do OLTP in-memory serão criptografados se você habilitar a TDE, mas os arquivos no grupo de arquivos MEMORY_OPTIMIZED_DATA ficarão descriptografados.

Diretrizes sobre o gerenciamento de certificados usados na TDE

Você deve fazer backup do certificado e da chave mestra do banco de dados quando o banco de dados está habilitado para TDE e é usado no envio de logs ou espelhamento de banco de dados. O backup de certificados armazenados em um banco de dados do sistema independente também deverá ser efetuado.

O certificado usado para proteger a DEK nunca deve ser descartado do banco de dados master. Isso faz com que o banco de dados criptografado torne-se inacessível.

Uma mensagem como a que se segue (erro 33091) será gerada após a execução do CREATE DATABASE ENCRYPTION KEY se o backup do certificado usado no comando não tiver sido feito.

A consulta a seguir pode ser usada para identificar os certificados usados no TDE que não foram submetidos a backup desde o momento em que foi criado.

SELECT pvt_key_last_backup_date,
       Db_name(dek.database_id) AS encrypteddatabase,
       c.name AS Certificate_Name
FROM sys.certificates AS c
     INNER JOIN sys.dm_database_encryption_keys AS dek
         ON c.thumbprint = dek.encryptor_thumbprint;

Se a coluna pvt_key_last_backup_date for NULL, o banco de dados correspondente a essa linha foi habilitado para TDE, mas não foi feito backup do certificado usado para proteger a DEK. Veja mais informações sobre como fazer backup de um certificado, em CERTIFICADO DE BACKUP.

Conteúdo relacionado

• Segurança do Mecanismo de Banco de Dados do SQL Server e Banco de Dados SQL do Azure
• FILESTREAM (SQL Server)
• Criptografia do SQL Server
• Chaves de criptografia do SQL Server e banco de dados (Mecanismo de Banco de Dados)