Digestverwaltung
Gilt für: 
SQL Server 2022 (16.x) Azure SQL-Datenbank Azure SQL Managed Instance
Datenbank-Digests
Der Hash des letzten Blocks im Datenbankledger wird als Datenbankhash bezeichnet. Er stellt den Status aller Ledgertabellen in der Datenbank zum Zeitpunkt der Blockgenerierung dar. Die Generierung eines Datenbank-Digests ist effizient, da bei diesem Vorgang nur die Hashes der Blöcke berechnet werden, die vor Kurzem angefügt wurden.
Datenbank-Digests können entweder automatisch vom System oder manuell vom Benutzer generiert werden. Später können Sie sie dann verwenden, um die Integrität der Datenbank zu überprüfen.
Datenbank-Digests werden in Form eines JSON-Dokuments generiert, das den Hash des letzten Blocks zusammen mit den Metadaten für die Block-ID enthält. Die Metadaten enthalten den Zeitpunkt der Generierung des Digests und den Commit-Zeitstempel der letzten Transaktion in diesem Block.
Der Überprüfungsprozess und die Integrität der Datenbank hängen von der Integrität der Eingabe-Digests ab. Zu diesem Zweck müssen Datenbankdigests, die aus der Datenbank extrahiert werden, in einem vertrauenswürdigen Speicher abgelegt werden, den Datenbankbenutzer mit umfangreichen Berechtigungen oder Angreifer nicht manipulieren können.
Automatisches Generieren und Speichern von Datenbank-Digests
Hinweis
Die automatische Erzeugung und Speicherung von Datenbank-Digests in SQL Server unterstützt nur Azure Storage-Konten.
Der Ledger ist in das Feature „Unveränderlicher Speicher“ von Azure Blob Storage und in Azure Confidential Ledger integriert. Im Rahmen dieser Integration werden sichere Speicherdienste in Azure bereitgestellt, um die Datenbank-Digests vor potenziellen Manipulationen zu schützen. Diese Integration bietet Benutzern eine einfache und kostengünstige Möglichkeit, die Digest-Verwaltung zu automatisieren, ohne sich um ihre Verfügbarkeit und geografische Replikation kümmern zu müssen. Azure Confidential Ledger bietet eine bessere Integritätsgarantie für Kunden, die Bedenken hinsichtlich des Zugriffs privilegierter Administratoren auf den Digest haben. Diese Tabelle vergleicht das Feature „Unveränderlicher Speicher“ von Azure Blob Storage mit Azure Confidential Ledger.
Sie können die automatische Generierung und Speicherung von Datenbank-Digests über das Azure-Portal, PowerShell oder die Azure CLI konfigurieren. Weitere Informationen finden Sie unter Aktivieren des automatischen Digestspeichers. Beim Konfigurieren der automatischen Generierung und Speicherung werden Datenbank-Digests nach einem vordefinierten Intervall von 30 Sekunden generiert und in den ausgewählten Speicherdienst hochgeladen. Falls im System während des 30-Sekunden-Intervalls keine Transaktionen erfolgen, wird kein Datenbank-Digest generiert und hochgeladen. Mit diesem Mechanismus wird sichergestellt, dass Datenbank-Digests nur generiert werden, wenn Daten in Ihrer Datenbank aktualisiert wurden. Wenn der Endpunkt ein Azure Blob Storage ist, erstellt der logische Server für Azure SQL-Datenbank oder Azure SQL Managed Instance einen neuen Container mit dem Namen sqldbledgerdigests und verwendet ein NamensmusterServerName/DatabaseName/CreationTime. Der Zeitpunkt der Erstellung wird benötigt, weil eine Datenbank mit demselben Namen gelöscht und neu erstellt oder wiederhergestellt werden kann, wodurch verschiedene Versionen der Datenbank unter demselben Namen zulässig sind. Weitere Informationen finden Sie unter Überlegungen zur Digest-Verwaltung.
Hinweis
Für SQL Server muss der Container manuell vom Benutzer erstellt werden.
Richtlinie zur Unveränderlichkeit des Azure Storage-Kontos
Wenn Sie ein Azure Storage-Konto für die Speicherung der Datenbank-Digests verwenden, konfigurieren Sie nach der Bereitstellung eine Unveränderbarkeitsrichtlinie für Ihren Container, um sicherzustellen, dass die Datenbank-Digests vor Manipulationen geschützt sind. Stellen Sie sicher, dass die Unveränderlichkeitsrichtlinie geschützte Schreibzugriffe auf Anfügeblobs zulässt und dass die Richtlinie gesperrt ist.
Azure Storage-Kontoberechtigung
Wenn Sie Azure SQL-Datenbank oder Azure SQL Managed Instance verwenden, stellen Sie sicher, dass Ihr logischer Server oder Ihre verwaltete Instanz (Systemidentität) über ausreichende rollenbasierte Zugriffssteuerung (RBAC)-Berechtigungen verfügt, um Digests zu schreiben, indem Sie sie der Teilnehmerrolle Storage Blob Daten hinzufügen. Falls Sie die aktive Georeplikation oder automatische Failover-Gruppen verwenden, stellen Sie sicher, dass die sekundären Replikate über dieselbe RBAC-Berechtigung für das Azure Storage-Konto verfügen.
Wenn Sie SQL Server verwenden, müssen Sie eine freigegebene Zugriffssignatur (Shared Access Signature, SAS) im Digestcontainer erstellen, damit SQL Server eine Verbindung mit dem Azure Storage-Konto herstellen und authentifizieren kann.
- Erstellen Sie einen Container auf dem Azure Storage-Konto mit dem Namen sqldbledgerdigests.
- Erstellen Sie eine Richtlinie für einen Container mit den Berechtigungen Lesen, Hinzufügen, Erstellen, Schreiben und Auflisten und erzeugen Sie einen Shared Access Signature-Schlüssel.
- Erstellen Sie für den Container sqldbledgerdigests, der für die Speicherung der Digest-Dateien verwendet wird, eine SQL Server-Anmeldeinformation, deren Name mit dem Containerpfad übereinstimmt.
Das folgende Beispiel geht davon aus, dass ein Azure Storage Container, eine Richtlinie und ein SAS-Schlüssel erstellt wurden. Dies wird von SQL Server benötigt, um auf die Digest-Dateien im Container zuzugreifen.
Ersetzen Sie im folgenden Codeausschnitt <your SAS key> durch den SAS-Schlüssel. Der SAS-Schlüssel sieht etwa folgendermaßen aus: 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>'.
CREATE CREDENTIAL [https://ledgerstorage.blob.core.windows.net/sqldbledgerdigests]
WITH IDENTITY='SHARED ACCESS SIGNATURE',
SECRET = '<your SAS key>'
Azure Confidential Ledger-Berechtigung
Wenn Sie Azure SQL-Datenbank oder Azure SQL Managed Instance verwenden, stellen Sie sicher, dass Ihr logischer Server oder Ihre verwaltete Instanz (Systemidentität) über ausreichende Berechtigungen verfügt, um Digests zu schreiben, indem Sie sie der Teilnehmerrolle hinzufügen. Folgen Sie dazu den Schritten für die Benutzerverwaltung von Azure Confidential Ledger.
Hinweis
Die automatische Erzeugung und Speicherung von Datenbank-Digests in SQL Server unterstützt nur Azure Storage-Konten.
Konfigurieren von NSG-Regeln für Azure SQL Managed Instance für die Arbeit mit Azure Confidential Ledger
Wenn Sie Azure SQL Managed Instance verwenden, stellen Sie sicher, dass Sie die virtuellen Netzwerkregeln Ihrer Azure SQL Managed Instance für die Kommunikation mit Azure Confidential Ledger konfigurieren. Weitere Informationen finden Sie unter Konfigurieren von NSG-Regeln für Azure SQL Managed Instance für die Arbeit mit Azure Confidential Ledger.
Manuelles Generieren und Speichern von Datenbank-Digests
Sie können einen Datenbankdigest auch bei Bedarf generieren. Auf diese Weise können Sie den Digest manuell in einem beliebigen Dienst oder Gerät speichern, den bzw. das Sie als vertrauenswürdiges Speicherziel betrachten. Beispielsweise können Sie ein lokales WORM-Gerät (Write Once, Read Many) als Ziel auswählen. Sie generieren einen Datenbank-Digest manuell, indem Sie die gespeicherte Prozedur sys.sp_generate_database_ledger_digest in SQL Server Management Studio oder Azure Data Studio ausführen.
EXECUTE sp_generate_database_ledger_digest;
Das zurückgegebene Resultset enthält nur eine Zeile mit Daten. Es sollte wie folgt als JSON-Dokument an einem vertrauenswürdigen Speicherort gespeichert werden:
{
"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"
}
Berechtigungen
Das Erzeugen von Datenbank-Digests erfordert die GENERATE LEDGER DIGEST-Berechtigung. Weitere Informationen zu Berechtigungen im Zusammenhang mit Ledgertabellen finden Sie unter Berechtigungen.
Überlegungen zur Digestverwaltung
Datenbankwiederherstellung
Die Wiederherstellung der Datenbank zu einem früheren Zeitpunkt – auch bekannt als Zeitpunktwiederherstellung – ist ein Vorgang, der häufig verwendet wird, wenn ein Fehler auftritt und Benutzer den Zustand der Datenbank schnell auf einen früheren Zeitpunkt zurücksetzen müssen. Beim Hochladen der generierten Digests in Azure Storage oder Azure Confidential Ledger wird der Erstellungszeitpunkt der Datenbank erfasst, der diese Digests zugeordnet sind. Bei jeder Wiederherstellung der Datenbank wird sie mit einem neuen Erstellungszeitpunkt versehen. Diese Technik ermöglicht es uns, die Digests über verschiedene „Inkarnationen“ der Datenbank hinweg speichern. Bei SQL Server ist die Erstellungszeit die aktuelle UTC-Zeit, zu der der Digest-Upload zum ersten Mal aktiviert wird. Die Informationen darüber, wann ein Wiederherstellungsvorgang stattgefunden hat, bleiben im Ledger erhalten, sodass der Überprüfungsprozess alle relevanten Digests über die verschiedenen Instanzen der Datenbank hinweg nutzen kann. Darüber hinaus können Benutzer alle Digests für verschiedene Erstellungszeitpunkte einsehen, um festzustellen, wann und bis zu welchem Zeitpunkt die Datenbank wiederhergestellt wurde. Da diese Daten in einen unveränderlichen Speicher geschrieben werden, sind diese Informationen außerdem geschützt.
Hinweis
Wenn Sie eine native Wiederherstellung einer Datenbanksicherung in Azure SQL Managed Instance durchführen, müssen Sie den Digest-Pfad manuell über das Azure-Portal, die PowerShell oder die Azure CLI ändern.
Aktive Georeplikation und Always On-Verfügbarkeitsgruppen
Aktive Georeplikation oder Auto-Failover-Gruppen können für Azure SQL Database oder Azure SQL Managed Instance konfiguriert werden. Die regionsübergreifende Replikation erfolgt aus Leistungsgründen asynchron, wodurch die sekundäre Datenbank im Vergleich zur primären Datenbank einen leichten Rückstand aufweisen kann. Im Falle eines geografischen Failovers gehen alle aktuellen Daten verloren, die noch nicht repliziert wurden. Der Ledger gibt nur Datenbankdigests für Daten aus, die auf geografische Sekundärsysteme repliziert wurden. So wird sichergestellt, dass die Digests niemals auf Daten verweisen, die im Falle eines geografischen Ausfalls verloren gehen könnten. Dies gilt nur für die automatische Erzeugung und Speicherung von Datenbankdigests. In einer Failover-Gruppe haben sowohl die primäre als auch die sekundäre Datenbank denselben Digest-Pfad. Selbst wenn Sie ein Failover ausführen, ändert sich der Digest-Pfad für die primäre und sekundäre Datenbank nicht.
Wenn die Failover-Gruppe gelöscht wird oder Sie die Verknüpfung aufheben, verhalten sich beide Datenbanken wie primäre Datenbanken. Zu diesem Zeitpunkt ändert sich der Digest-Pfad der vorherigen sekundären Datenbank und wir fügen einen RemovedSecondaryReplica-Ordner zum Pfad hinzu.
Wenn Ihre Datenbank Teil einer Always On-Verfügbarkeitsgruppe oder einer Managed Instance-Verknüpfung in SQL Server ist, wird das gleiche Prinzip wie bei der aktiven Georeplikation verwendet. Der Upload der Digests erfolgt nur, wenn alle Transaktionen in die sekundären Replikate repliziert wurden.