Posso recuperar um certificado TDE restaurando o banco de dados MASTER?

(Felizmente, não estamos atualmente nessa situação, apenas planejando com antecedência para ver quais seriam nossas opções se alguma vez ocorresse.)

Para um banco de dados criptografado com TDE (Transparent Date Encryption), uma cópia do backup do banco de dados é irrecuperável, a menos que você tenha um backup do certificado usado para criptografá-lo.

E se você não tiver isso? Existem opções adicionais?

No caso de uma falha total do servidor, a restauração de um backup do banco de dados MASTER no novo hardware também restauraria o certificado?

Como o TDE depende de um certificado armazenado no mestre (que é usado para criptografar a chave de criptografia do banco de dados), isso funcionaria apenas se você pudesse restaurar o banco de dados mestre em outro servidor, de forma que o certificado pudesse ser descriptografado.

Esta é a hierarquia de criptografia TDE:

1. Chave mestra de serviço (protegida pelo Windows; vinculada às credenciais da conta de serviço e a uma chave de máquina)
2. Chave mestre do banco de dados (nesse caso, a chave do banco de dados mestre)
3. Certificado
4. Chave de criptografia TDE

Os três primeiros itens são armazenados no banco de dados mestre e podem ser armazenados em backup. O quarto é armazenado (criptografado pelo certificado do no 3) no cabeçalho do banco de dados criptografado.

Portanto, em um cenário de falha, você teria que restaurar o suficiente da hierarquia de criptografia para permitir a leitura da chave TDE. O SQL Server cria a chave mestra de serviço na instalação; portanto, ao restaurar o banco de dados mestre para uma instância diferente, os itens 2 e 3 também serão restaurados, as chaves necessárias para descriptografá-los não estarão presentes. Resultado: dados ilegíveis.

As duas melhores opções são restaurar o certificado (nº 3) de um backup (uma boa opção se o mestre não puder ser restaurado por qualquer motivo) ou restaurar o banco de dados mestre e sua chave mestre (nº 2) de um backup. Restaurar a chave mestra pode ser uma opção melhor se você tiver muitos certificados / chaves protegidos por essa chave e precisar torná-los acessíveis ao mesmo tempo. Isso vem com as mesmas precauções normalmente associadas à restauração do banco de dados mestre (agrupamentos, logins, nomes de bancos de dados e caminhos de arquivos, etc.)

Geralmente, eu recomendaria apenas restaurar o mestre em um cenário de recuperação. Para um cenário de migração / expansão (como usar Grupos de Disponibilidade / espelhamento com um banco de dados criptografado por TDE), é melhor fazer backup / restaurar o certificado (nº 3) para que ele seja criptografado usando as chaves mestras exclusivas de cada instância que está sendo movida para. Você precisará incluir a chave privada no backup do certificado.

De qualquer forma, você precisará fazer backups de chaves / certificados, então proteja-os bem e guarde-os em locais redundantes e seguros. Simplesmente ter um backup do master não o tira de um desastre da TDE; você precisará de um backup de pelo menos uma chave ou certificado.

1.Se desejar restaurar um backup criptografado para outro servidor, como de costume, você encontrará o seguinte erro

 Cannot find server certificate with thumbprint …...

2. Encontre o nome do certificado: neste exemplo, vestacert

   SELECT  * FROM   sys.certificates

3. faça backup do certificado do servidor de origem (Source encryptedserver):

BACKUP CERTIFICATE vestacert
TO FILE = 'c:\Backup\certificate_TDE_Test_Certificate.cer'
WITH PRIVATE KEY
(FILE = 'c:\Backup\certificate_TDE_Test_Key.pvk',
ENCRYPTION BY PASSWORD = 'Password12#')

4.Crie um novo Master Cert no servidor UAT, se ainda não existir

USE master GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'D1ffPa$$w0rd'

5.Restaurar certificados de backup no servidor UAT (UATserver)

CREATE CERTIFICATE vestacert2
FROM FILE = 'C:\tmp\certificate_TDE_Test_Certificate.cer'     
WITH PRIVATE KEY (FILE = 'C:\tmp\LCMS\certificate_TDE_Test_Key.pvk', 
DECRYPTION BY PASSWORD = 'Passsword12#')

6. Após esta etapa, a restauração do backup não apresenta nenhum erro e todos os dados ficaram legíveis.

7.Mas o engraçado é que remover a criptografia de maneira simples e fazer um novo backup e restaurá-lo no servidor final (Servidor Final) não funciona e dá o seguinte erro O arquivo "mydb_log" falhou ao inicializar corretamente. Examine os logs de erros para obter mais detalhes.

8. A maneira correta de remover a criptografia do UAT é remover todos os sinais como abaixo, passo a passo e de baixo para cima

    USE master
    ALTER DATABASE mydb SET ENCRYPTION OFF
    USE mydb
    DROP DATABASE ENCRYPTION KEY 
    USE master
    DROP CERTIFICATE vestacert2 
    DROP MASTER KEY

9.Agora, crie um novo backup do servidor UAT e restaure-o no servidor final

bom artigo: http://sqlserverzest.com/2013/10/03/sql-server-restoring-a-tde-encrypted-database-to-a-different-server/

Se o seu sistema travar e se tornar inutilizável, você poderá criar um novo sistema e restaurar o banco de dados mestre sobre o existente para recuperar o certificado TDE , desde que você use a mesma conta de serviço no novo sistema. Você deve reiniciar o sistema para corrigir a criptografia da Chave Mestra de Serviço pela chave da máquina local. Depois disso, você poderá fazer backup do certificado TDE ou restaurar o banco de dados do usuário e acessar os dados. A Chave Mestra de Serviço é protegida pela API de Proteção de Dados do servidor Windows de duas maneiras, primeiro usando a chave da máquina local que é específica do sistema e depois usando a conta de serviço do mecanismo de banco de dados. Como você não terá mais a chave da máquina local do sistema original devido a uma falha no sistema, você deve usar a mesma conta de serviço. O backup do certificado TDE é feito com o banco de dados, mas inacessível até que a hierarquia de criptografia seja concluída.