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:
Criação da chave e do certificado no servidor de origem.
Criação da chave e do certificado no servidor de destino.
Backup do BD no servidor de origem, incluindo os parâmetros de encriptação.
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.