Buscar
  • Ignez Mello

Backup criptografado

Desde os primórdios dos bancos de dados ouvimos que "a informação é o bem mais precioso que as empresas possuem". Obviamente, se essa informação é roubada, a empresa pode sofrer grandes prejuízos financeiros e na sua imagem.


Considerando que o backup de um banco de dados é uma cópia fiel das informações que a empresa guarda, então faz sentido protegermos esses arquivos. Se eles forem roubados, mas estiverem criptografados, o "meliante" não terá sucesso em restaurá-lo e acessar seus dados.


O backup criptografado foi implementado na versão 2014 do SQL Server, substituindo a opção de criar o backup com uma senha, e funciona tanto na versão on-premises quanto no Azure.


O backup criptografado garante que o banco de dados só será restaurado numa instância que tenha o certificado ou a chave assimétrica criada no servidor de origem. Para executar backups criptografados, precisamos definir os algoritmos e escolher se vamos usar chave assimétrica ou certificado.



Como criar um backup criptografado


A criação de backup criptografado é dividido em 4 passos:

  1. Criação da chave e do certificado no servidor de origem.

  2. Criação da chave e do certificado no servidor de destino.

  3. Backup do BD no servidor de origem, incluindo os parâmetros de encriptação.

  4. Restore do BD no servidor destino.



Criação da chave e do certificado no servidor de origem


Primeiro, vamos criar a chave mestre e definir sua senha. Para usar a chave mestre em backups, ela deve ser criada no BD master:

Bom, eu nem preciso ressaltar que esta senha "super complicada" é só um exemplo, certo?


Agora, vamos criar o certificado na instância onde está o banco de dados que faremos o backup criptografado. Depois, vamos exportá-lo para a instância onde o backup será restaurado.


IMPORTANTE: o certificado deve ser armazenado em um LOCAL SEGURO porque, sem ele, não conseguiremos restaurar o backup.


Eu criei o certificado com o nome ABC_BKPSeguro, considerando que a instância de origem dos bancos dados é ABC. Eu gosto de criar um certificado específico para cada instância. E, em certos casos, criar um certificado específico para bancos de dados críticos.


O SUBJECT ajuda a identificar o certificado quando usamos a view sys.certificates.


A data definida em EXPIRY_DATE indica até quando o certificado é válido. Se você omitir esse parâmetro, o certificado será válido por 1 ano a partir da sua criação. Se o certificado expirar, é só criá-lo novamente com o mesmo nome. Caso contrário, seus restores já era.


Com o certificado criado, vamos fazer um backup dele e salvar em um local seguro. Só pra deixar claro: lugar seguro não é a mesma pasta onde os backups são gravados, ok? Para o backup do certificado, podemos fazer um backup simples ou usar uma chave privada para deixá-lo ainda mais seguro:




Criação da chave e do certificado no servidor de destino


No servidor de destino, vamos criar a chave mestre e definir sua senha:


Em seguida, criamos o certificado:



Backup do BD no servidor de origem, incluindo os parâmetros de encriptação


Com os certificados criados e copiados nos dois servidores, só falta mesmo executar o backup do banco de dados:


Pronto, nosso backup está feito e está protegido.



Restore do BD


Agora vamos restaurar nosso backup. O comando de Restore é o mesmo, não há nenhum parâmetro específico para identificar o certificado:


Primeiro, vamos tentar num servidor que não tem o certificado cadastrado:


Msg 33111, Level 16, State 3, Line 2

Cannot find server certificate with thumbprint '0xB879EC6E38ED0718686B81C453FC9C5CE8621560'.

Msg 3013, Level 16, State 1, Line 2

RESTORE DATABASE is terminating abnormally.


É... não deu muito certo, né?


Para saber quais certificados existem na instância, usamos a view sys.certificates.


Quando executamos o restore na instância correta, o comando funciona normalmente.



12 visualizações