Criptografia de Dados Transparente

Artigo
09/05/2023

Você pode adotar várias precauções para ajudar a proteger o banco de dados, como a criação de um sistema seguro, a criptografia de ativos confidenciais e a criação de um firewall em torno de servidores de bancos de dados. No entanto, em um cenário em que a mídia física (como unidades ou fitas de backup) é roubada, uma entidade mal-intencionada pode restaurar ou anexar o banco de dados e procurar os dados. Uma solução é criptografar dados confidenciais no banco de dados e proteger as chaves usadas para criptografar os dados com um certificado. Isso impede que alguém sem as chaves use os dados, mas esse tipo de proteção deve ser planejado antecipadamente.

A Transparent Data Encryption (TDE) executa criptografia de E/S em tempo real e a descriptografia de dados e arquivos de log de transações e arquivos de log especiais do PDW. A criptografia usa uma chave de criptografia de banco de dados (DEK), que é armazenada no registro de inicialização do banco de dados para disponibilidade durante a recuperação. A DEK é uma chave simétrica protegida por um certificado armazenado no banco de dados mestre do SQL Server PDW. A TDE protege os dados “em repouso”, ou seja, os dados e arquivos de log. Fornece a capacidade de se adequar a muitas leis, regulamentos e diretrizes estabelecidos em vários setores. Esse recurso permite que desenvolvedores de software criptografem dados usando algoritmos de criptografia AES e 3DES, sem alterar os aplicativos existentes.

Importante

A TDE não fornece criptografia para dados que trafegam entre o cliente e o PDW. Para obter mais informações sobre como criptografar dados entre o cliente e o SQL Server PDW, consulte Provisão de certificado.

A TDE não criptografa dados em movimento ou em uso. O tráfego interno entre componentes do PDW dentro do SQL Server PDW não é criptografado. Os dados de armazenamento temporário em buffers de memória não são criptografados. Para reduzir esse risco, controle o acesso físico e as conexões ao SQL Server PDW.

Depois de protegido, o banco de dados pode ser restaurado usando o certificado correto.

Observação

Ao criar um certificado para TDE, você deve fazer o backup logo em seguida, junto com a chave privada associada. Se em algum momento o certificado ficar indisponível ou caso você deseje restaurar ou anexar o banco de dados a outro servidor, você precisará dos backups do certificado e da chave privada ou não será possível abrir o banco de dados. O certificado de criptografia deve ser retido até mesmo se o TDE já não estiver habilitado no banco de dados. Mesmo que o banco de dados não seja criptografado, partes do log de transações ainda poderão permanecer protegidas e talvez o certificado seja necessário para algumas operações até a realização do backup completo do banco de dados. Um certificado que excedeu sua data de validade ainda pode ser usado para criptografar e descriptografar dados com TDE.

A criptografia do arquivo de banco de dados é executada em nível de 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.

A ilustração a seguir mostra a hierarquia de chaves para criptografia da TDE:

Displays the hierarchy

Usando Transparent Data Encryption

Para usar a TDE, execute estes procedimentos. As três primeiras etapas são feitas apenas uma vez, ao preparar o SQL Server PDW para dar suporte à TDE.

Crie uma chave mestra no banco de dados mestre.
Use sp_pdw_database_encryption para habilitar a TDE no SQL Server PDW. Essa operação modifica os bancos de dados temporários para garantir a proteção de futuros dados temporários. Ela não poderá ser feita em sessões ativas que tenham tabelas temporárias. sp_pdw_database_encryption ativa o mascaramento de dados do usuário nos logs do sistema do PDW. (Para obter mais informações sobre mascaramento de dados do usuário em logs do sistema do PDW, consulte sp_pdw_log_user_data_masking.)
Use sp_pdw_add_network_credentials para criar uma credencial que possa autenticar e gravar no compartilhamento onde o backup do certificado será armazenado. Se já existir uma credencial para o servidor de armazenamento pretendido, você poderá usar a credencial existente.
No banco de dados mestre, crie um certificado protegido pela chave mestra.
Faça backup do certificado no compartilhamento de armazenamento.
No banco de dados de usuário, crie uma chave de criptografia de banco de dados e use o certificado armazenado no banco de dados mestre para protegê-la.
Use a instrução ALTER DATABASE para criptografar o banco de dados usando a TDE.

O exemplo a seguir ilustra a criptografia do banco de dados AdventureWorksPDW2012 usando um certificado chamado MyServerCert, criado no SQL Server PDW.

Primeiro: habilite a TDE no SQL Server PDW. Você precisará fazer essa ação apenas uma vez.

USE master;  
GO  
  
-- Create a database master key in the master database  
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';  
GO  
  
-- Enable encryption for PDW  
EXEC sp_pdw_database_encryption 1;  
GO  
  
-- Add a credential that can write to the share  
-- A credential created for a backup can be used if you wish  
EXEC sp_pdw_add_network_credentials 'SECURE_SERVER', '<domain>\<Windows_user>', '<password>';

Segundo: crie e faça backup de um certificado no banco de dados mestre. Você precisará fazer essa ação apenas uma vez. Você pode ter um certificado separado para cada banco de dados (recomendado) ou pode proteger vários bancos de dados com um certificado.

-- Create certificate in master  
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate';  
GO  
  
-- Back up the certificate with private key  
BACKUP CERTIFICATE MyServerCert   
    TO FILE = '\\SECURE_SERVER\cert\MyServerCert.cer'  
    WITH PRIVATE KEY   
    (   
        FILE = '\\SECURE_SERVER\cert\MyServerCert.key',  
        ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>'   
    )   
GO

Por último: crie a DEK e use ALTER DATABASE para criptografar um banco de dados de usuário. Essa ação é repetida em cada banco de dados protegido pela TDE.

USE AdventureWorksPDW2012;  
GO  
  
CREATE DATABASE ENCRYPTION KEY  
WITH ALGORITHM = AES_128  
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;  
GO  
  
ALTER DATABASE AdventureWorksPDW2012 SET ENCRYPTION ON;  
GO

As operações de criptografia e descriptografia são agendadas em threads em segundo plano pelo SQL Server. É possível exibir o status dessas operações usando exibições do catálogo e de gerenciamento dinâmico na lista mostrada adiante neste artigo.

Cuidado

Os arquivos de backup de bancos de dados com TDE habilitada também são criptografados usando a chave de criptografia do banco de dados. Como resultado, quando você restaura esses backups, o certificado que protege a chave de criptografia do banco de dados deve estar disponível. Isso significa que, além de fazer backup do banco de dados, você deve assegurar que os backups dos certificados de servidor sejam mantidos para evitar perda de dados. Se o certificado não estiver mais disponível, haverá perda de dados.

Comandos e funções

Os certificados da TDE devem ser criptografados pela chave mestra do banco de dados para serem aceitos pelas instruções a seguir.

A tabela a seguir fornece links e explicações de comandos e funções da TDE.

Comando ou função	Finalidade
CREATE DATABASE ENCRYPTION KEY	Cria uma chave usada para criptografar um banco de dados.
ALTER DATABASE ENCRYPTION KEY	Altera a chave usada para criptografar um banco de dados.
DROP DATABASE ENCRYPTION KEY	Remove a chave usada para criptografar um banco de dados.
ALTER DATABASE	Explica a opção ALTER DATABASE usada para habilitar a 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.

Exibição do catálogo ou exibição de gerenciamento dinâmico	Finalidade
sys.databases	Exibição do catálogo que exibe informações do banco de dados.
sys.certificates	Exibição do catálogo que mostra os certificados em um banco de dados.
sys.dm_pdw_nodes_database_encryption_keys	Exibição de gerenciamento dinâmico que fornece para cada nó informações sobre as chaves de criptografia usadas em um banco de dados e o estado da criptografia de um banco de dados.

Permissões

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

A exibição de metadados envolvidos com a TDE requer a permissão CONTROL SERVER.

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.

É possível localizar o estado da criptografia do banco de dados usando a exibição de gerenciamento dinâmico sys.dm_database_encryption_keys. Para obter mais informações, veja a seção Exibições do catálogo e exibições de gerenciamento dinâmico no início deste artigo.

Restrições

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 KEYou ALTER DATABASE...SET ENCRYPTION.

Descartando o banco de dados.
Usar um comando ALTER DATABASE.
Iniciar um backup de banco de dados.
Iniciar uma restauração do banco de dados.

As operações ou condições a seguir impedirão as instruções CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE ENCRYPTION KEY, DROP DATABASE ENCRYPTION KEY ou ALTER DATABASE...SET ENCRYPTION.

Um comando ALTER DATABASE está em execução.
Algum backup de dados está sendo executado.

Durante a criação de arquivos de banco de dados, a inicialização instantânea do arquivo não está disponível quando a TDE está habilitada.

Áreas não protegidas pela TDE

A TDE não protege tabelas externas.

A TDE não protege sessões de diagnóstico. Os usuários devem ter cuidado para não fazer consultas com parâmetros confidenciais durante o uso de sessões de diagnóstico. As sessões de diagnóstico que revelam informações confidenciais devem ser removidas assim que não forem mais necessárias.

Os dados protegidos pela TDE são descriptografados quando colocados na memória do SQL Server PDW. Os despejos de memória são criados quando ocorrem determinados problemas no dispositivo. Os arquivos de despejo são o conteúdo da memória no momento do surgimento do problema e podem conter dados confidenciais não criptografados. O conteúdo dos despejos de memória deve ser revisado antes do compartilhamento com outras pessoas.

A TDE não protege o banco de dados mestre. O banco de dados mestre não contém dados do usuário, mas armazena informações como nomes de logon.

Transparent Data Encryption e logs de transação

A habilitação de um banco de dados para usar a TDE tem o efeito de zerar a parte remanescente do log de transações virtuais para impor o próximo log de transações virtuais. Isso garante que nenhum texto não criptografado seja deixado nos logs de transações depois que o banco de dados for definido para criptografia. É possível localizar o status da criptografia de arquivo de log em cada nó do PDW na coluna encryption_state na exibição sys.dm_pdw_nodes_database_encryption_keys, como neste exemplo:

WITH dek_encryption_state AS   
(  
    SELECT ISNULL(db_map.database_id, dek.database_id) AS database_id, encryption_state  
    FROM sys.dm_pdw_nodes_database_encryption_keys AS dek  
        INNER JOIN sys.pdw_nodes_pdw_physical_databases AS node_db_map  
           ON dek.database_id = node_db_map.database_id AND dek.pdw_node_id = node_db_map.pdw_node_id  
        LEFT JOIN sys.pdw_database_mappings AS db_map  
            ON node_db_map .physical_name = db_map.physical_name  
        INNER JOIN sys.dm_pdw_nodes AS nodes  
            ON nodes.pdw_node_id = dek.pdw_node_id  
    WHERE dek.encryptor_thumbprint <> 0x  
)  
SELECT TOP 1 encryption_state  
       FROM dek_encryption_state  
       WHERE dek_encryption_state.database_id = DB_ID('AdventureWorksPDW2012 ')  
       ORDER BY (CASE encryption_state WHEN 3 THEN -1 ELSE encryption_state END) DESC;

Todos os dados gravados no log de transações antes de uma alteração na chave de criptografia do banco de dados serão criptografados usando a chave de criptografia do banco de dados anterior.

Logs de atividades do PDW

O SQL Server PDW mantém um conjunto de logs para solução de problemas. (Observação: esse não é o log de transações, o log de erros do SQL Server ou o log de eventos do Windows.) Esses logs de atividade do PDW podem conter instruções completas em texto não criptografado, algumas das quais podem conter dados do usuário. Exemplos comuns são as instruções INSERT e UPDATE. O mascaramento de dados do usuário pode ser ativado ou desativado de forma explícita usando sp_pdw_log_user_data_masking. A habilitação da criptografia no SQL Server PDW ativa o mascaramento de dados do usuário nos logs de atividades do PDW para protegê-los. sp_pdw_log_user_data_masking também pode ser usado para mascarar instruções quando não estiver usando a TDE. No entanto, isso não é recomendado porque dificulta a análise de problemas pela equipe de Suporte da Microsoft.

Transparent Data Encryption e o banco de dados do sistema tempdb

O banco de dados do sistema tempdb é criptografado quando a criptografia é habilitada usando sp_pdw_database_encryption. Isso é necessário antes que um banco de dados possa usar a TDE. Isso pode afetar o desempenho de bancos de dados não criptografados na mesma instância do SQL Server PDW.

Gerenciamento de chaves

A chave de criptografia de banco de dados (DEK) é protegida pelos certificados armazenados no banco de dados mestre. Esses certificados são protegidos pela chave mestra do banco de dados (DMK) do banco de dados mestre. A DMK precisa ser protegida pela chave mestra de serviço (SMK) para ser usada para TDE.

O sistema pode acessar as chaves sem intervenção humana (como o fornecimento de senha). Se o certificado não estiver disponível, o sistema exibirá um erro explicando que a DEK não pode ser descriptografada até que o certificado adequado esteja disponível.

Ao mover um banco de dados de um dispositivo para outro, o certificado usado para proteger a DEK deve ser restaurado primeiro no servidor de destino. Em seguida, o banco de dados poderá ser restaurado como de costume. Para obter mais informações, veja a documentação padrão do SQL Server Mover um banco de dados protegido por TDE para outro SQL Server.

Deve-se manter os certificados usados para criptografar DEKs enquanto houver backups de banco de dados que os utilizem. Os backups de certificado devem incluir a chave privada do certificado. Sem ela, um certificado não pode ser usado para restauração do banco de dados. Esses backups de chave privada do certificado são armazenados em um arquivo separado, protegido por uma senha que deve ser informada para a restauração do certificado.

Restauração do banco de dados mestre

O banco de dados mestre pode ser restaurado usando DWConfig, como parte da recuperação de desastre.

Se o nó de controle não tiver sido alterado, ou seja, se o banco de dados mestre for restaurado no mesmo dispositivo inalterado do qual o backup do banco de dados mestre foi criado, a DMK e todos os certificados ficarão legíveis sem a necessidade de ações adicionais.
Se o banco de dados mestre for restaurado em um dispositivo diferente, ou se o nó de controle tiver sido alterado desde o backup do banco de dados mestre, serão necessárias etapas adicionais para regenerar a DMK.
1. Abra a DMK:
```
OPEN MASTER KEY DECRYPTION BY PASSWORD = '<password>';  
```
2. Adicione a criptografia por SMK:
```
ALTER MASTER KEY   
    ADD ENCRYPTION BY SERVICE MASTER KEY;  
```
3. Reinicie o dispositivo.

Atualizar e substituir máquinas virtuais

Se existir uma DMK no dispositivo no qual a VM de Atualização ou Substituição foi executada, a senha da DMK deverá ser fornecida como um parâmetro.

Exemplo da ação de atualização. Substitua ********** pela senha da DMK.

setup.exe /Action=ProvisionUpgrade ... DMKPassword='**********'

Exemplo da ação para substituir uma máquina virtual.

setup.exe /Action=ReplaceVM ... DMKPassword='**********'

Na atualização, se um BD de usuário for criptografado e a senha da DMK não for fornecida, a ação de atualização falhará. Na substituição, se a senha correta não for fornecida quando existir uma DMK, a operação ignorará a etapa de recuperação da DMK. As outras etapas serão concluídas no final da ação de substituição de VM. No entanto, a ação relatará falha no final para indicar que há a necessidade de etapas adicionais. Nos logs de instalação (localizados em \ProgramData\Microsoft\Microsoft SQL Server Parallel Data Warehouse\100\Logs\Setup\\<time-stamp>\Detail-Setup), será exibido o seguinte aviso perto do final.

*** WARNING \*\*\* DMK is detected in master database, but could not be recovered automatically! The DMK password was either not provided or is incorrect!

Execute estas instruções no PDW de forma manual e reinicie o dispositivo para recuperar a DMK:

OPEN MASTER KEY DECRYPTION BY PASSWORD = '<DMK password>';  
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY;

Siga as etapas informadas no parágrafo Restauração do banco de dados mestre para recuperar o banco de dados e reinicie o dispositivo.

Se a DMK já existia, mas não foi recuperada após a ação, a seguinte mensagem de erro será exibida durante a consulta de um banco de dados.

Msg 110806;  
A distributed query failed: Database '<db_name>' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.

Impacto do Desempenho

O impacto no desempenho da TDE varia de acordo com o tipo de dados que você tem, como eles são armazenados e o tipo de atividade de carga de trabalho no SQL Server PDW. Quando protegida por TDE, a E/S de leitura e descriptografia de dados, ou a criptografia e a gravação de dados, é uma atividade que demanda mais capacidade de CPU e terá mais impacto quando outras atividades que exigem mais do CPU estiverem ocorrendo ao mesmo tempo. Por criptografar tempdb, a TDE pode afetar o desempenho de bancos de dados não criptografados. Para saber o desempenho real, você deve testar todo o sistema com seus dados e atividade de consulta.

Os links a seguir contêm informações gerais sobre como o SQL Server gerencia a criptografia. Os artigos podem ajudá-lo a entender a criptografia do SQL Server, mas não têm informações específicas do SQL Server PDW e abordam recursos que não estão presentes no SQL Server PDW.

Confira também

ALTER DATABASE
CREATE MASTER KEY
CREATE DATABASE ENCRYPTION KEY
BACKUP CERTIFICATE
sp_pdw_database_encryption
sp_pdw_database_encryption_regenerate_system_keys
sp_pdw_log_user_data_masking
sys.certificates
sys.dm_pdw_nodes_database_encryption_keys

Compartilhar via

Criptografia de Dados Transparente

Usando Transparent Data Encryption

Comandos e funções

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

Permissões

Considerações

Restrições

Áreas não protegidas pela TDE

Transparent Data Encryption e logs de transação

Logs de atividades do PDW

Transparent Data Encryption e o banco de dados do sistema tempdb

Gerenciamento de chaves

Restauração do banco de dados mestre

Atualizar e substituir máquinas virtuais

Impacto do Desempenho

Confira também

Comentários

Recursos adicionais

Compartilhar via

Criptografia de Dados Transparente

Usando Transparent Data Encryption

Comandos e funções

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

Permissões

Considerações

Restrições

Áreas não protegidas pela TDE

Transparent Data Encryption e logs de transação

Logs de atividades do PDW

Transparent Data Encryption e o banco de dados do sistema tempdb

Gerenciamento de chaves

Restauração do banco de dados mestre

Atualizar e substituir máquinas virtuais

Impacto do Desempenho

Conteúdo relacionado

Confira também

Comentários

Recursos adicionais