Share via

Recuperación de una base de datos de libro de contabilidad tras una alteración

  • Artículo

Se aplica a: SQL Server 2022 (16.x) Azure SQL DatabaseAzure SQL Managed Instance

¿Cómo recuperar una base de datos después de una alteración?

La manera más sencilla de reparar cualquier tipo de alteración es restaurar la base de datos a la copia de seguridad más reciente que pueda comprobarse. Para ello, puede restaurar la base de datos a distintos momentos en el tiempo y comprobar el libro de contabilidad a través de resúmenes de base de datos anteriores. El último momento en el tiempo que se puede comprobar correctamente es aquel que hemos confirmado que no se ha alterado y que se puede usar para seguir procesando transacciones. Por este motivo, es fundamental que las copias de seguridad sean lo suficientemente frecuentes como para acercarnos lo más posible al tiempo de alteración. La programación de copias de seguridad se realiza automáticamente en Azure SQL Database. Aunque esta técnica es sencilla, tiene una salvedad importante: si se llevó a cabo alguna transacción después de producirse la alteración, debemos asumir que esa transacción se perderá o que hay que reparar manualmente la tabla del libro de contabilidad volviendo a insertar la información de las transacciones comprobadas y recalculando el hash de esa nueva transacción que tuvo lugar después del primer evento de alteración en el libro de contabilidad de la base de datos.

Categorías de alteración

Dependiendo del tipo de alteración, hay casos en los que el libro de contabilidad se puede reparar sin perder datos. Debemos considerar dos categorías de eventos de alteración.

La alteración no ha afectado a más transacciones

El evento de alteración modificó algunos datos almacenados en el libro de contabilidad, pero no afectó a ninguna transacción más. Esto podría deberse a que el ataque se detectó antes de que las transacciones usaran los datos alterados, o a que el ataque solo afectó a los datos de una forma tal que no tuvo impacto en las nuevas transacciones. Por ejemplo, si usamos una tabla de libro de contabilidad para almacenar detalles sobre transacciones bancarias, la alteración de los detalles de las transacciones existentes no afecta a las nuevas transacciones centradas en los saldos actuales.

Dado que la alteración no afecta a ninguna transacción que se produjo después del evento de alteración, la ejecución de nuevas transacciones y los resultados generados son correctos. En función de esto, lo ideal es llevar el libro de contabilidad a un estado coherente sin repercutir en estas transacciones.

Si el atacante no alteró el libro de contabilidad en el nivel de base de datos, esto es fácil de detectar y reparar. El libro de contabilidad de la base de datos está en un estado coherente con todos los resúmenes de base de datos generados, y se han creado hash para las nuevas transacciones anexadas a él usando los hash válidos de transacciones anteriores. En función de esto, cualquier resumen de base de datos generado, incluso para las transacciones posteriores a la alteración, seguirán siendo válidos. Puede intentar recuperar la carga de libro de contabilidad de tabla correspondiente a las transacciones alteradas de las copias de seguridad que todavía se pueden validar como seguras (usando en ellas la validación del libro de contabilidad) y reparar la base de datos operativa sobrescribiendo los datos alterados en el libro de contabilidad de la tabla. Esto creará una nueva transacción que registrará las transacciones por reparar.

Alteración de datos afectados usados posteriormente por otras transacciones

El evento de alteración afectó a datos que posteriormente usaron otras transacciones, lo que tuvo impacto en su ejecución. Por ejemplo, en una aplicación bancaria en la que los saldos de cuenta actuales se almacenan en una tabla de libro de contabilidad, modificar el estado actual de la tabla puede ser desastroso para transacciones posteriores, ya que puede dar pie a que nuevas transacciones rebasen el presupuesto.

Si un atacante ha alterado el libro de contabilidad de base de datos, vuelva a calcular los hashes de los bloques para que sean coherentes internamente (cosa que se contrastará con los resúmenes de base de datos externos), y se generarán nuevas transacciones y resúmenes de base de datos por encima de los hash no válidos. Esto conduce a una bifurcación en el libro de contabilidad, ya que los nuevos resúmenes de base de datos generados se asignan a un estado no válido, e incluso reparando el libro de contabilidad con copias de seguridad anteriores, todos estos resúmenes de base de datos no serán válidos de manera permanente. Además, como el libro de contabilidad de la base de datos se ha alterado, no se puede confiar en los detalles sobre las transacciones que hayan tenido lugar tras la alteración hasta que se comprueben. A partir de ahí, la alteración se puede revertir en teoría de los siguientes modos:

  1. Usando copias de seguridad para restaurar el estado de las transacciones alteradas.
  2. Comprobando la parte del libro de contabilidad después de la última transacción recuperada por la copia de seguridad y hasta el final del libro de contabilidad. Para ello, debe usar los resúmenes de base de datos de la parte bifurcada de la cadena. Aunque los resúmenes de la base de datos no coincidan con la parte original del libro de contabilidad, siguen sirviendo para comprobar que la parte bifurcada del libro de contabilidad no se ha alterado. Si esto también da señal de alteración, significa que ha habido más de un evento de alteración y que el proceso debe aplicarse de forma recursiva para recuperar las diferentes partes del libro de contabilidad a partir de copias de seguridad.
  3. Repare manualmente los libros de contabilidad de tabla volviendo a insertar la información de las transacciones comprobadas y recalculando los hashes de esas nuevas transacciones que se produjeron después del primer evento de alteración en el libro de contabilidad de la base de datos.

Contenido relacionado