Récupérer la base de données de registre après falsification
S’applique à : 
SQL Server 2022 (16.x)base de données Azure SQL Azure SQL Managed Instance
Comment effectuer une récupération après une falsification ?
La façon la plus simple de réparer n’importe quel type de falsification consiste à restaurer la base de données vers la dernière sauvegarde qui peut être vérifiée. Pour ce faire, vous pouvez restaurer la base de données à différents points dans le temps et vérifier le registre avec des synthèses de base de données antérieures. Le dernier point dans le temps qui peut être correctement vérifié est celui qui est garanti comme étant non falsifié et peut être utilisé pour poursuivre le traitement des transactions. Pour cette raison, il est essentiel que les sauvegardes soient suffisamment fréquentes pour être aussi proches que possible du moment de la falsification. La planification des sauvegardes est effectuée automatiquement pour Azure SQL Database. Même si cette technique est simple, elle appelle une mise en garde importante : si des transactions ont été exécutées après la falsification, vous devez accepter que ces transactions soient perdues ou réparer manuellement la table de registre en réinsérant les informations des transactions vérifiées et en recalculant les hachages pour les nouvelles transactions qui se sont produites après le premier événement de falsification dans le registre de base de données.
Catégories de falsification
Selon le type de falsification, il existe des cas où vous pouvez réparer le registre sans perdre de données. Vous devez prendre en compte deux catégories d’événements de falsification.
La falsification n’a pas affecté d’autres transactions
L’événement de falsification a modifié certaines données stockées dans le registre, mais n’a pas affecté d’autres transactions. Cela peut être dû au fait que l’attaque a été détectée avant que des transactions n’agissent sur les données falsifiées ou au fait que l’attaque a affecté les données sans porter préjudice aux nouvelles transactions. Par exemple, si vous utilisez une table de registre pour stocker les détails des transactions bancaires, la falsification des détails des transactions existantes n’impacte pas les nouvelles transactions, ce qui fonctionne sur les soldes actuels.
Étant donné que la falsification n’a pas affecté les transactions qui se sont produites après l’événement de falsification, l’exécution de nouvelles transactions et les résultats générés sont corrects. Ainsi, vous devez idéalement amener le registre à un état cohérent sans affecter ces transactions.
Si l’attaquant n’a pas falsifié le registre au niveau de la base de données, la détection et la réparation sont faciles. Le registre de base de données est dans un état cohérent avec toutes les synthèses de base de données générées, et toutes les nouvelles transactions ajoutées à celui-ci ont été hachées avec des hachages valides des transactions antérieures. Ainsi, les synthèses de base de données qui ont été générées, même pour les transactions après la falsification, sont toujours valides. Vous pouvez tenter de récupérer la charge utile correcte du registre de tables pour les transactions falsifiées à partir de sauvegardes qui peuvent toujours être validées comme étant sécurisées (en utilisant la validation du registre sur celles-ci) et réparer la base de données opérationnelle en remplaçant les données falsifiées dans le registre de table. Cette opération crée une transaction qui enregistre les transactions de réparation.
La falsification a affecté des données utilisées par d’autres transactions
L’événement de falsification a affecté des données qui ont été utilisées ultérieurement par d’autres transactions, ce qui affecte leur exécution. Par exemple, dans une application bancaire où les soldes de compte courant sont stockés dans une table de registre, la modification de l’état actuel de la table peut être désastreuse pour d’autres transactions, car elle peut permettre aux nouvelles transactions d’engendrer des dépenses excessives.
Si l’attaquant a falsifié le registre de base de données, en recalculant les hachages de blocs pour qu’il soit cohérent en interne (jusqu’à ce qu’il soit vérifié par rapport aux synthèses de base de données externes), les nouvelles transactions et synthèses de base de données sont générées sur des hachages non valides. Cela conduit à une duplication dans le registre, car les nouvelles synthèses de base de données générées correspondent à un état non valide et même si vous réparez le registre avec des sauvegardes antérieures, toutes ces synthèses de base de données sont définitivement non valides. En outre, étant donné que le registre de base de données est rompu, vous ne pouvez pas approuver les détails des transactions qui ont eu lieu après la falsification tant que vous ne les avez pas vérifiés. Ainsi, la falsification peut éventuellement être contrecarrée en :
- Utilisant des sauvegardes pour restaurer l’état des transactions falsifiées.
- Vérifiant la partie du registre après la dernière transaction récupérée par la sauvegarde et jusqu’à la fin du registre. Pour cela, vous devez utiliser les synthèses de base de données à partir de la partie dupliquée de la chaîne. Même si les synthèses de base de données ne correspondent pas à la partie d’origine du registre, l’opération peut toujours vérifier que la partie dupliquée du registre n’a pas été falsifiée. Si elles indiquent également une falsification, cela signifie qu’il y a eu plusieurs événements de falsification et que le processus doit être appliqué de manière récursive pour récupérer les différentes parties du registre à partir de sauvegardes.
- Réparez manuellement les registres de tables en réinsérant les informations des transactions vérifiées et en recalculant les hachages des nouvelles transactions qui se sont produites après le premier événement de falsification dans le registre de base de données.