Cenário : Você recebe um backup de banco de dados e é instruído a restaurá-lo em um servidor (que já está hospedando outros bancos de dados), mas não recebe nenhuma informação útil sobre o que o backup contém ou se a fonte deve ser confiável.
Pergunta 1 : Quais são as possíveis implicações de restaurar um backup que pode ser malicioso?
Pergunta 2 : O que você pode fazer para proteger seu servidor/os dados em outros bancos de dados do impacto da restauração de um backup potencialmente malicioso? RESTORE VERIFYONLYparece ser um bom primeiro passo. A resposta final provavelmente é 'restaurar o banco de dados em uma VM de sandbox sem acesso ao mundo externo', mas vamos supor que essa opção esteja fora de questão. O que mais deve ser feito nesta situação?
Um banco de dados pode conter código malicioso, possivelmente um procedimento que irá alterar uma senha para o login "sa" ou eliminar todos os bancos de dados. No entanto, a única maneira de ver que está causando um problema é um indivíduo restaurar o banco de dados e, em seguida, executar manualmente qualquer código nesse banco de dados. Ele não seria executado de nenhuma maneira automatizada.
Não há nenhuma configuração que possa ser aplicada em um banco de dados para que o SQL Server execute automaticamente algum código no banco de dados ao restaurá-lo em um servidor. Se o fizesse, esperaria que a Microsoft perdesse a certificação Common Criteria para o produto. Isso é um bug muito grande para permitir um DBMS para mim.
Existem alguns passos de prevenção que você pode fazer.
Como Shawn disse, o código não será executado sozinho, a menos que algum procedimento armazenado que pareça vbalid tenha um exec de outro código malicioso. Esta é a razão de verificar o código dentro de cada um deles antes de colocá-lo em modo multiusuário.
Estou chegando aqui, mas posso pensar em pelo menos um cenário perigoso: se você restaurar um banco de dados que tenha um filetable , esses arquivos agora estarão em sua rede por padrão (e especificamente, em seu SQL Server). Você pode restaurar um vírus.
Isso por si só não fará nada, é claro - o vírus não se torna senciente de repente - mas se seus usuários tentarem acessar o arquivo, eles poderão ser infectados. (Ei, eu disse que estava alcançando.) Estou imaginando um cenário em que um hacker externo deseja obter malware na porta e, em seguida, envia um e-mail para Bob na contabilidade dizendo: "Aqui está o arquivo: \sqlserver\filetableshare\ myvirus.exe" - nesse ponto, ele passou por seus firewalls sem detecção e agora estamos reduzidos às suas ferramentas internas de antivírus e antimalware.
Restaurar verificar apenas verifica a integridade do banco de dados NÃO informará se o backup inclui um código malicioso ou não RESTORE VERIFYONLY não tenta verificar a estrutura dos dados contidos nos volumes de backup. É altamente improvável que, se o backup vier de dentro da empresa onde você trabalha, possa ser malicioso, mas se vier de terceiros, você precisa ter cuidado, como Shawn apontou.
A documentação do Microsoft Online diz que
•Para fins de segurança, recomendamos que você não anexe ou restaure bancos de dados de fontes desconhecidas ou não confiáveis. Esses bancos de dados podem conter código mal-intencionado que pode executar código Transact-SQL não intencional ou causar erros ao modificar o esquema ou a estrutura física do banco de dados. Antes de usar um banco de dados de uma fonte desconhecida ou não confiável, execute DBCC CHECKDB no banco de dados em um servidor que não seja de produção e também examine o código, como procedimentos armazenados ou outro código definido pelo usuário, no banco de dados.
A questão se concentra principalmente em um backup contendo malware, mas também é possível obter um comportamento indesejado e potencialmente malicioso da própria operação de restauração.
Descobri acidentalmente no passado que é possível travar o SQL Server tentando restaurar um arquivo de backup corrompido que faz com que o SQL Server tente ler além do final do arquivo de backup e trave. Não tenho certeza de quais versões são suscetíveis ou exatamente o que é necessário para reproduzir o problema. Documentei alguns detalhes limitados aqui quando encontrei esse problema alguns anos atrás.
Qual é o risco de restaurar um banco de dados desconhecido de uma fonte desconhecida? Nenhum.
Qual é o risco de permitir que um aplicativo desconhecido se conecte usando uma conta sysadmin para se conectar a esse banco de dados e começar a executar o código? GRANDE QUANTIDADE! Se a conta do aplicativo tiver apenas direitos dentro do banco de dados e nenhum acesso no nível do servidor, não há nada que ela possa realmente fazer fora do banco de dados. Isso basicamente se resume a ter uma configuração de estrutura de segurança adequada no servidor para começar.
Agradável. Você exige uma declaração por escrito assinada de quem está lhe dizendo para fazer isso, de que aceita total responsabilidade pelas consequências. Se eles não estiverem dispostos a fazer isso, você deve testar a instalação em uma caixa de areia após examinar o arquivo de backup (se possível) e examinar minuciosamente todas as tabelas, procedimentos etc. o sistema de produção. Mesmo assim, você deve deixar claro (para seu chefe e seus superiores) que nunca confiou no backup e está fazendo isso apenas sob ordens diretas.
Se eles não assinarem tal declaração, alerte seu(s) superior(es) antes de fazer qualquer coisa. Como profissional, é seu dever proteger seu sistema tanto quanto possível, não importa o que algum superior estúpido possa ordenar que você faça. Você pode ser demitido, mas pode manter a cabeça erguida e saber que fez a coisa certa.
Não há muitos perigos por dizer, além de alguns de longo alcance sugeridos aqui. Como foi mencionado, é difícil ter material auto-executável em um backup de banco de dados. Ele precisa de algum tipo de mecanismo de gatilho externo.
Obtenha um laptop/desktop antigo e uma versão de avaliação do seu software de banco de dados (SQLExpress) se o licenciamento for um problema. Copie o arquivo de backup na máquina, desconecte a rede/wireless e faça a restauração. Então comece a cavar. Leve o tempo que precisar, porque há muitos lugares onde as coisas podem se esconder, a maioria deles já coberto por outras postagens neste tópico.
A integridade de seu DBA e o bem-estar de seu ambiente de Produção é mais importante do que qualquer ordem dada por um superior.