Leggere in inglese

Condividi tramite

Ripristinare il database principale dopo la manomissione

  • Articolo

Si applica a: SQL Server 2022 (16.x) Database Azure SQL Istanza 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. È possibile tentare di recuperare il payload corretto del libro mastro della tabella per le transazioni manomesse dai backup che possono comunque essere convalidati per essere sicuri (usando la convalida del libro mastro) e ripristinare il database operativo sovrascrivendo i dati manomessi nella tabella libro mastro. Verrà creata una nuova transazione che registra le transazioni di riparazione.

Manomissione dei dati interessati usati da altre 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. Per questo occorre creae un copia tramite fork nel libro mastro, poiché i nuovi riepiloghi del database generati eseguono il mapping a uno stato non valido, e anche se si ripristina il libro mastro usando backup precedenti, tutti questi riepiloghi del database non sono validi in modo permanente. 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. Verifica della parte del libro mastro dopo l'ultima transazione recuperata dal backup e fino alla fine del libro mastro. A tale scopo, è necessario usare i riepiloghi del database dalla parte copiata tramite fork della catena. Anche se i riepiloghi del database non corrispondono alla parte originale del libro mastro, può comunque verificare che la parte copiata tramite fork 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