Leggere in inglese

Condividi tramite

Ripristinare il database del registro dopo la manomissione

  • Articolo

Si applica a: SQL Server 2022 (16.x) Database Azure SQLIstanza gestita di SQL di Azure

Come eseguire il recupero dopo la manomissione?

Il modo più semplice per riparare qualsiasi tipo di manomissione consiste nel ripristinare il database al backup più recente che può essere verificato. A tale scopo, è possibile ripristinare il database in momenti diversi e verificare il libro mastro usando i riepiloghi del database precedenti. L'ultimo punto nel tempo che può essere verificato correttamente è quello che garantisce di non essere stato manomesso e può essere utilizzato per continuare l'elaborazione delle transazioni. Per questo motivo, è fondamentale che i backup siano abbastanza frequenti in modo che siano più vicini possibile al momento della manomissione. La pianificazione del backup viene eseguita automaticamente per il database SQL di Azure. Sebbene questa tecnica sia semplice, occorre fare un’importante precisazione: se le transazioni sono state eseguite dopo la manomissione, è necessario accettare che queste transazioni andranno perse o che dovranno riparare manualmente la tabella libro mastro reinserendo le informazioni per le transazioni verificate e ricalcolando gli hash per queste nuove transazioni che si sono verificate dopo il primo evento di manomissione nel libro mastro del database.

Categorie di manomissione

A seconda del tipo di manomissione, esistono casi in cui è possibile riparare il libro mastro senza perdere i dati. È bene considerare due categorie di eventi di manomissione.

La manomissione non ha influenzato ulteriori transazioni

L'evento di manomissione ha modificato alcuni dati archiviati nel libro mastro ma non ha influenzato altre transazioni. Questo potrebbe essere dovuto al fatto che l'attacco è stato rilevato prima che qualsiasi transazione operasse sui dati manomessi o perché l'attacco ha interessato solo i dati in modo che non influiscano sulle nuove transazioni. Ad esempio, se si usa una tabella libro mastro per archiviare i dettagli delle transazioni bancarie, la manomissione dei dettagli delle transazioni esistenti non influisce sulle nuove transazioni, che funzioneranno sui saldi correnti.

Poiché la manomissione non ha influenzato le transazioni che si sono verificate dopo l'evento di manomissione, la nuova esecuzione della transazione e i risultati generati sono corretti. In base a questo, è consigliabile portare il libro mastro in uno stato coerente senza influire su queste transazioni.

Se l'utente malintenzionato non ha manomesso il libro mastro a livello di database, il rilevamento e la riparazione saranno di facile esecuzione. Il libro mastro del database è coerente con tutti i riepiloghi del database generati e tutte le nuove transazioni accodate a esso sono state oggetto di hashing usando gli hash validi delle transazioni precedenti. In base a questo, tutti i riepiloghi del database generati, anche per le transazioni successive alla manomissione, sono ancora validi. Puoi tentare di recuperare il payload corretto del ledger della tabella per le transazioni manomesse dai backup che possono comunque essere convalidati come sicuri (usando la convalida del ledger su di essi) e ripristinare il database operativo sovrascrivendo i dati manomessi nel ledger della tabella. Verrà creata una nuova transazione che registra le transazioni di riparazione.

Manomissione dei dati compromessi utilizzati in ulteriori transazioni

L'evento di manomissione ha interessato i dati usati successivamente da altre transazioni, influendo pertanto sulla loro esecuzione. Ad esempio, in un'applicazione bancaria in cui i saldi correnti del conto sono archiviati in una tabella libro mastro, la modifica dello stato corrente della tabella può essere disastrosa per altre transazioni poiché può consentire un eccesso nella spesa delle nuove transazioni.

Se l'utente malintenzionato ha manomesso il libro mastro del database, ricalcolando gli hash dei blocchi per renderlo coerente internamente (fino a quando non viene verificato rispetto ai riepiloghi del database esterno), le nuove transazioni e i riepiloghi del database verranno generati su hash non validi. Questo porta a un fork nel libro mastro, poiché i nuovi riepiloghi del database generati si collegano a uno stato non valido e, anche se si ripristina il libro mastro usando backup precedenti, tutti questi riepiloghi del database rimangono permanentemente non validi. Inoltre, poiché il libro mastro del database è danneggiato, non è possibile considerare attendibili i dettagli sulle transazioni che si sono verificate dopo la manomissione fino a quando non vengono verificate. In base a questo, la manomissione può essere potenzialmente ripristinata da:

  1. Uso dei backup per ripristinare lo stato per le transazioni manomesse.
  2. Controllo della parte del libro mastro dopo l'ultima transazione recuperata dal backup fino alla fine del documento. A tale scopo, è necessario usare i riepiloghi del database dalla parte derivata dalla biforcazione della catena. Anche se i riepiloghi del database non corrispondono alla parte originale del libro mastro, è comunque possibile verificare che la parte forksata del libro mastro non sia stata manomessa. Se questi indicano anche manomissioni, ciò significa che si sono verificati più eventi di manomissione e il processo deve essere applicato in modo ricorsivo per recuperare le diverse parti del libro mastro dai backup.
  3. Ripristinare manualmente i libri mastro della tabella reinserendo le informazioni per le transazioni verificate e ricalcolando gli hash per queste nuove transazioni che si sono verificate dopo il primo evento di manomissione nel libro mastro del database.

Contenuto correlato