Partilhar via

Recuperar banco de dados do razão após adulteração

  • Artigo

Aplica-se a: SQL Server 2022 (16.x) Banco de Dados SQL do AzureInstância Gerenciada de SQL do Azure

Como se recuperar após a adulteração?

A forma mais simples de reparar qualquer tipo de adulteração é restaurar o banco de dados para o backup mais recente que possa ser verificado. Para isso, você pode restaurar o banco de dados para diferentes pontos no tempo e verificar o razão usando códigos hash anteriores do banco de dados. O ponto mais recente no tempo que pode ser verificado com êxito é aquele que tem a garantia de não ter sido adulterado e que pode ser usado para continuar o processamento de transações. Por esse motivo, é essencial que os backups sejam frequentes o suficiente para chegar o mais próximo possível do momento da adulteração. O agendamento do backup é feito automaticamente para Banco de Dados SQL do Azure. Embora essa técnica seja simples, ela tem uma limitação importante: se alguma transação tiver sido executada após a adulteração, você precisará aceitar que essas transações serão perdidas ou elas precisarão reparar manualmente a tabela do razão reinserindo as informações para as transações verificadas e recompilando os hashes dessas novas transações que ocorreram após o primeiro evento de adulteração no razão do banco de dados.

Categorias de adulteração

Dependendo do tipo de adulteração, há casos em que você pode reparar o razão sem perder dados. Você deve considerar duas categorias de eventos de adulteração.

A adulteração não afetou outras transações

O evento de adulteração modificou alguns dados armazenados no razão, mas não afetou nenhuma transação adicional. Isso pode ocorrer porque o ataque foi detectado antes de qualquer transação operar nos dados adulterados ou porque o ataque afetou apenas os dados de uma forma que não afeta novas transações. Por exemplo, se você usar uma tabela de razão para armazenar detalhes de transações bancárias, a adulteração de detalhes das transações existentes não afetará novas transações, que serão realizadas sobre os saldos atuais.

Como a adulteração não afetou nenhuma transação que ocorreu após o evento de adulteração, a nova execução da transação e os resultados gerados estarão corretos. Com base nisso, é ideal que você leve o razão a um estado consistente sem afetar essas transações.

Se o invasor não adulterou o razão no nível do banco de dados, isso será fácil de detectar e reparar. O razão do banco de dados está em um estado consistente com todos os códigos hash do banco de dados gerados e todas as novas transações acrescentadas a ele foram avaliadas usando os hashes válidos de transações anteriores. Com base nisso, os hashes do banco de dados que foram gerados, mesmo para transações após a adulteração, ainda são válidos. Você pode tentar recuperar o conteúdo correto do razão da tabela das transações adulteradas, de backups que ainda possam ser validados quanto à segurança (usando a validação do razão neles) e reparar o banco de dados operacional substituindo os dados adulterados no razão da tabela. Isso criará uma transação registrando as transações de reparo.

Adulteração de dados afetados usados por transações posteriores

O evento de adulteração afetou os dados que foram usados posteriormente por outras transações, afetando, portanto, sua execução. Por exemplo, em um aplicativo bancário em que os saldos de conta atual são armazenados em uma tabela de razão, a modificação do estado atual da tabela poderá ser desastrosa para transações posteriores, pois poderá permitir que novas transações gastem demais.

Se o invasor tiver adulterado o razão do banco de dados, recompilando os hashes de blocos para torná-lo internamente consistente (até que seja verificado com códigos hash de banco de dados externos), as novas transações e os hashes de banco de dados serão gerados com base em hashes inválidos. Isso leva a uma bifurcação no razão, uma vez que o novo hash do banco de dados gerado é mapeado para um estado inválido e, ainda que você repare o razão usando backups anteriores, todos esses hashes de banco de dados ficarão permanentemente inválidos. Além disso, como o razão do banco de dados está corrompido, você não pode confiar nos detalhes das transações que ocorreram após a adulteração até que você as verifique. Com base nisso, a violação pode ser potencialmente revertida por:

  1. Uso de backups para restaurar o estado das transações adulteradas.
  2. Verificando a parte do razão após a última transação recuperada pelo backup e até o final do razão. Para isso, você precisa usar os hashes do banco de dados da parte bifurcada da cadeia. Embora os hashes do banco de dados não correspondam à parte original do razão, ainda é possível verificar se a parte bifurcada do razão não foi adulterada. Se essa parte também indicar adulteração, isso significa que houve mais de um evento de adulteração e o processo precisa ser aplicado recursivamente para recuperar as diferentes partes do razão nos backups.
  3. Repare manualmente os razões de tabela reinserindo as informações das transações verificadas e recompilando os hashes dessas novas transações que ocorreram após o primeiro evento de adulteração no razão do banco de dados.

Conteúdo relacionado