Gestione dei riepiloghi
Si applica a: 
SQL Server 2022 (16.x) Database Azure SQL Istanza gestita di SQL di Azure
Digest del database
L'hash del blocco più recente nel libro mastro del database è chiamato riepilogo del database. Rappresenta lo stato di tutte le tabelle del libro mastro nel database al momento della generazione del blocco. La generazione di un riepilogo del database è efficiente, perché prevede l'elaborazione solo degli hash dei blocchi aggiunti di recente.
I riepiloghi del database possono essere generati automaticamente dal sistema o manualmente dall'utente. È possibile usarli in un secondo momento per verificare l'integrità del database.
I riepiloghi del database vengono generati sotto forma di documento JSON che contiene l'hash del blocco più recente, insieme ai metadati per l'ID blocco. I metadati includono l'ora di generazione del riepilogo e data e ora del commit dell'ultima transazione in questo blocco.
Il processo di verifica e l'integrità del database dipendono dall'integrità dei riepiloghi di input. A questo scopo, i riepiloghi del database estratti dal database devono essere archiviati in una risorsa di archiviazione attendibile che gli utenti con privilegi elevati o gli utenti malintenzionati del database non possono manomettere.
Generazione e archiviazione automatiche dei riepiloghi del database
Nota
La generazione e l'archiviazione automatiche dei riepiloghi del database in SQL Server supportano solo gli account Archiviazione di Azure.
Il libro mastro si integra con la funzionalità di archiviazione non modificabile di Archiviazione BLOB di Azure e Azure Confidential Ledger. Questa integrazione fornisce servizi di archiviazione sicuri in Azure per proteggere i riepiloghi del database da potenziali manomissioni. Questa integrazione offre agli utenti un modo semplice ed economico per automatizzare la gestione dei riepiloghi senza doversi preoccupare della disponibilità e della replica geografica. Azure Confidential Ledger offre garanzie di integrità più avanzate per i clienti che si preoccupano dell'accesso degli amministratori con privilegi al riepilogo. Questa tabella confronta la funzionalità di archiviazione non modificabile di Archiviazione BLOB di Azure con Azure Confidential Ledger.
È possibile configurare la generazione e l'archiviazione automatiche dei riepiloghi del database tramite il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure. Per ulteriori informazioni, vedere Abilitare l'archiviazione automatica dei riepiloghi. Quando si configura la generazione e l'archiviazione automatiche, i riepiloghi del database vengono generati in base a un intervallo predefinito di 30 secondi e caricati nel servizio di archiviazione selezionato. Se non si verificano transazioni nel sistema nell'intervallo di 30 secondi, non verrà generato e caricato un riepilogo del database. Questo meccanismo garantisce che i riepiloghi del database vengano generati solo quando i dati sono stati aggiornati nel database. Quando l'endpoint è un'Archiviazione BLOB di Azure, il server logico per database SQL di Azure o Istanza gestita di SQL di Azure creano un nuovo contenitore, denominato sqldbledgerdigests e usano un modello di denominazione come: ServerName/DatabaseName/CreationTime. Il tempo di creazione è necessario perché un database con lo stesso nome può essere eliminato e ricreato o ripristinato, consentendo diverse incarnazioni del database con lo stesso nome. Per ulteriori informazioni, vedere Considerazioni sulla gestione dei riepiloghi.
Nota
Per SQL Server, il contenitore deve essere creato manualmente dall'utente.
Criterio di immutabilità dell'account di archiviazione di Azure
Se si usa un account di archiviazione di Azure per l'archiviazione dei riepiloghi del database, configurare un criterio di immutabilità nel contenitore dopo il provisioning per assicurarsi che i riepiloghi del database siano protetti da manomissioni. Assicurarsi che i criteri di immutabilità consentano scritture di accodamento protette per accodare i BLOB e che i criteri siano bloccati.
Autorizzazione dell'account di archiviazione di Azure
Se si usa database SQL di Azure o Istanza gestita di SQL di Azure, assicurarsi che il server logico o l'istanza gestita (Identità di sistema) dispongano di autorizzazioni sufficienti per il controllo degli accessi in base al ruolo per scrivere riepiloghi aggiungendoli al ruolo Collaboratore ai dati del BLOB di archiviazione. Se si usa la replica geografica attiva o i gruppi di failover automatico, assicurarsi che le repliche secondarie abbiano la stessa autorizzazione di controllo degli accessi in base al ruolo per l'account di archiviazione di Azure.
Se si usa SQL Server, è necessario creare una firma di accesso condiviso (SAS) nel contenitore dei riepiloghi per consentire a SQL Server di connettersi ed eseguire l'autenticazione con l'account di archiviazione di Azure.
- Creare un contenitore nell'account di archiviazione di Azure denominato sqldbledgerdigests.
- Creare un criterio in un contenitore con le autorizzazioni Read, Add, Create, Write e List e generare una chiave di firma di accesso condiviso.
- Per ogni contenitore sqldbledgerdigests utilizzato per l'archiviazione dei file dei riepiloghi, creare credenziali di SQL Server il cui nome corrisponde al percorso del contenitore.
Nell'esempio seguente si presuppone che sia stato creato un contenitore Archiviazione di Azure, un criterio e una chiave SAS. Questa operazione è necessaria da SQL Server per accedere ai file dei riepiloghi nel contenitore.
Nel frammento di codice seguente sostituire <your SAS key> con la chiave SAS. La chiave SAS è simile a 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>'.
CREATE CREDENTIAL [https://ledgerstorage.blob.core.windows.net/sqldbledgerdigests]
WITH IDENTITY='SHARED ACCESS SIGNATURE',
SECRET = '<your SAS key>'
Autorizzazione di Azure Confidential Ledger
Se si usa database SQL di Azure o Istanza gestita di SQL di Azure, assicurarsi che il server logico o l'istanza gestita (Identità di sistema) dispongano di autorizzazioni sufficienti per scrivere riepiloghi aggiungendoli al ruolo Collaboratore. A tale scopo, seguire i passaggi per la gestione degli utenti di Azure Confidential Ledger.
Nota
La generazione e l'archiviazione automatiche dei riepiloghi del database in SQL Server supportano solo gli account Archiviazione di Azure.
Configurare regole NSG dell'Istanza gestita di SQL di Azure per lavorare con Azure Confidential Ledger
Se si usa Istanza gestita di SQL di Azure, assicurarsi di configurare le regole di rete virtuale del Istanza gestita di SQL di Azure per comunicare con Azure Confidential Ledger. Per ulteriori informazioni, vedere Configurare regole NSG dell'Istanza gestita di SQL di Azure per lavorare con Azure Confidential Ledger.
Generazione e archiviazione manuali dei riepiloghi del database
È anche possibile generare un riepilogo del database su richiesta in modo da poterlo archiviare manualmente in qualsiasi servizio o dispositivo considerato una destinazione di archiviazione attendibile. Ad esempio, è possibile scegliere un dispositivo WORM (write once, read many) locale come destinazione. Per generare manualmente un riepilogo del database, eseguire la stored procedure sys.sp_generate_database_ledger_digest in SQL Server Management Studio o Azure Data Studio.
EXECUTE sp_generate_database_ledger_digest;
Il set di risultati restituito è una singola riga di dati. Deve essere salvato nella posizione di archiviazione attendibile come documento JSON come indicato di seguito:
{
"database_name": "ledgerdb",
"block_id": 0,
"hash": "0xDC160697D823C51377F97020796486A59047EBDBF77C3E8F94EEE0FFF7B38A6A",
"last_transaction_commit_time": "2020-11-12T18:01:56.6200000",
"digest_time": "2020-11-12T18:39:27.7385724"
}
Autorizzazioni
La generazione di riepiloghi del database richiede l'autorizzazione GENERATE LEDGER DIGEST. Per conoscere i dettagli sulle autorizzazioni relative alle tabelle del libro mastro, vedere Autorizzazioni.
Considerazioni sulla gestione dei riepiloghi
Ripristino del database
Il ripristino del database a un momento precedente, noto anche come Ripristino temporizzato, è un'operazione spesso usata quando si verifica un errore e gli utenti devono ripristinare rapidamente lo stato del database a un momento precedente. Quando si caricano i riepiloghi generati in Archiviazione di Azure o in Azure Confidential Ledger, viene acquisita l'ora di creazione del database in cui vengono mappati questi riepiloghi. Ogni volta che viene ripristinato, il database viene contrassegnato con un nuovo tempo di creazione e questa tecnica consente di archiviare i riepiloghi in diverse "incarnazioni" del database. Per SQL Server, l'ora di creazione è l'ora UTC corrente in cui il caricamento del riepilogo è abilitato per la prima volta. Il libro mastro conserva le informazioni relative a quando si è verificata un'operazione di ripristino, consentendo al processo di verifica di usare tutti i riepiloghi pertinenti nelle varie incarnazioni del database. Inoltre, gli utenti possono esaminare tutti i riepiloghi per individuare tempi di creazione diversi e identificare quando il database è stato ripristinato e da quanto tempo. Poiché questi dati vengono scritti in una risorsa di archiviazione non modificabile, queste informazioni sono protette.
Nota
Se si esegue un ripristino nativo di un backup del database in Istanza gestita di SQL di Azure, è necessario modificare manualmente il percorso del riepilogo usando il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure.
Replica geografica attiva e gruppi di disponibilità Always On
È possibile configurare la replica geografica attiva o i gruppi di failover automatico per Database SQL di Azure o Istanza gestita di SQL di Azure. La replica tra aree geografiche è asincrona per motivi di prestazioni e, pertanto, consente al database secondario di essere leggermente indietro rispetto al database primario. In caso di failover geografico, tutti i dati più recenti che non sono ancora stati replicati vengono persi. Il libro mastro emetterà solo riepiloghi del database per i dati replicati in repliche geografiche secondarie per garantire che i riepiloghi non facciano mai riferimento a dati che potrebbero andare persi in caso di failover geografico. Questo vale anche per la generazione e l'archiviazione automatiche dei riepiloghi del database. In un gruppo di failover, sia il database primario che quello secondario avranno lo stesso percorso del riepilogo. Anche quando si esegue un failover, il percorso del riepilogo non cambia né per il database primario né per quello secondario.
Se il gruppo di failover viene eliminato o si elimina il collegamento, entrambi i database si comportano come database primari. A questo punto, il percorso del riepilogo del database secondario precedente cambierà e si aggiungerà una cartella RemovedSecondaryReplica al percorso.
Quando il database fa parte di un gruppo di disponibilità Always On o di un collegamento Istanza gestita in SQL Server, viene usato lo stesso principio della replica geografica attiva. Il caricamento dei riepiloghi viene eseguito solo se tutte le transazioni sono state replicate nelle repliche secondarie.