Gestion des synthèses
S’applique à : 
SQL Server 2022 (16.x)base de données Azure SQL Azure SQL Managed Instance
Synthèses de base de données
Le hachage du dernier bloc dans le registre de base de données est appelé synthèse de base de données. Il représente l’état de toutes les tables de registre dans la base de données au moment où le bloc a été généré. La génération d’une synthèse de base de données est efficace, car elle implique seulement le calcul des hachages des blocs qui ont récemment été ajoutés.
Les synthèses de base de données peuvent être générées automatiquement par le système ou manuellement par l’utilisateur. Vous pouvez les utiliser ultérieurement pour vérifier l’intégrité de la base de données.
Les synthèses de base de données sont générées sous la forme d’un document JSON qui contient le hachage du dernier bloc et les métadonnées associées à l’ID de bloc. Les métadonnées contiennent notamment l’heure de génération de la synthèse et l’horodatage de validation de la dernière transaction dans ce bloc.
Le processus de vérification et l’intégrité de la base de données dépendent de l’intégrité des synthèses d’entrée. Dans ce but, les synthèses extraites de la base de données doivent être stockées dans des stockages de confiance que ni les utilisateurs dotés de privilèges élevés ni les attaquants de la base de données ne peuvent falsifier.
Génération et stockage automatiques des synthèses de base de données
Remarque
La génération et le stockage automatiques des synthèses de base de données dans SQL Server ne prennent en charge que les comptes stockage Azure.
Le registre s’intègre à la fonctionnalité de stockage immuable du Stockage Blob Azure et au Registre confidentiel Azure. Cette intégration fournit des services de stockage sécurisé dans Azure afin de protéger les synthèses de base de données contre toute éventuelle falsification. Cette intégration fournit un moyen simple et économique aux utilisateurs d’automatiser la gestion des synthèses sans se soucier de leur disponibilité et de la réplication géographique. Le registre confidentiel Azure offre une garantie d’intégrité plus forte pour les clients préoccupés par l’accès des administrateurs privilégiés à la synthèse. Ce tableau compare la fonctionnalité de stockage immuable du Stockage Blob Azure avec celle du registre confidentiel Azure.
Vous pouvez configurer la génération et le stockage automatiques des synthèses de base de données par le biais du portail Azure, de PowerShell ou d’Azure CLI. Pour plus d’informations, consultez Activation du stockage automatique des synthèses. Lorsque vous configurez la génération et le stockage automatiques, les synthèses de base de données sont générées selon un intervalle prédéfini de 30 secondes et chargées dans le service de stockage sélectionné. Si aucune transaction n'a lieu sur le système dans l'intervalle de 30 secondes, une synthèse de base de données ne sera ni générée, ni chargée. Ce mécanisme garantit que les synthèses de base de données sont générées seulement quand des données ont été mises à jour dans votre base de données. Lorsque le point de terminaison est un Stockage Blob Azure, le serveur logique pour la base de données Azure SQL ou Azure SQL Managed Instance crée un conteneur nommé sqldbledgerdigests et utilise un modèle de nommage comme : ServerName/DatabaseName/CreationTime. La date de création est nécessaire. En effet, une base de données portant le même nom peut être supprimée, puis recréée ou restaurée, ce qui permet d'en obtenir différentes incarnations sous le même nom. Pour en savoir plus, reportez-vous à Considérations de gestion de synthèse.
Remarque
Pour SQL Server, le conteneur doit être créé manuellement par l'utilisateur.
Stratégie d'immuabilité de compte de stockage Azure
Si vous utilisez un compte de stockage Azure pour le stockage de synthèses de base de données, configurez une stratégie d'immuabilité sur votre conteneur après l'approvisionnement pour vous assurer que les synthèses de base de données sont protégées contre toute falsification. Assurez-vous que la stratégie d'immutabilité autorise les écritures protégées et ajoutées sur les blobs ajoutés et que la stratégie est verrouillée.
Autorisation du compte de stockage Azure
Si vous utilisez la base de données Azure SQL ou Azure SQL Managed Instance, assurez-vous que votre serveur logique ou Managed Instance (identité système) bénéficie des autorisations de contrôle d’accès en fonction du rôle (RBAC) suffisantes pour écrire des synthèses en les ajoutant au rôle Collaborateur de données d’objet blob de stockage. Si vous utilisez la géoréplication active ou les groupes de basculement automatique, assurez-vous que les réplicas secondaires bénéficient des mêmes autorisations RBAC sur le compte de stockage Azure.
Si vous utilisez SQL Server, vous devez créer une signature d'accès partagé (SAS) sur le conteneur de synthèse pour permettre à SQL Server de se connecter et de s'authentifier auprès du compte de stockage Azure.
- Créez un conteneur sur le compte de stockage Azure, avec pour nom sqldbledgerdigests.
- Créez une stratégie sur un conteneur avec les autorisations Lire, Ajouter, Créer, Écrire et Référencer, puis générez une clé de signature d'accès partagé.
- Pour le conteneur sqldbledgerdigests utilisé pour le stockage de fichiers de synthèse, créez un identifiant SQL Server dont le nom correspond au chemin d'accès du conteneur.
L'exemple suivant suppose qu'un conteneur de stockage Azure, une stratégie et une clé SAS ont été créés. Le SQL Server a besoin des éléments susmentionnés pour accéder aux fichiers de synthèse du conteneur.
Dans l’extrait de code suivant, remplacez <your SAS key> par la clé SAS. La clé SAS ressemble à 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>'.
CREATE CREDENTIAL [https://ledgerstorage.blob.core.windows.net/sqldbledgerdigests]
WITH IDENTITY='SHARED ACCESS SIGNATURE',
SECRET = '<your SAS key>'
Autorisation du registre confidentiel Azure
Si vous utilisez la base de données Azure SQL ou Azure SQL Managed Instance, assurez-vous que votre serveur logique ou Managed Instance (identité système) dispose des autorisations suffisantes pour écrire des synthèses en les ajoutant au rôle Collaborateur. Pour ce faire, suivez les étapes de gestion des utilisateurs du registre confidentiel Azure.
Remarque
La génération et le stockage automatiques des synthèses de base de données dans SQL Server ne prennent en charge que les comptes stockage Azure.
Configurer les règles de NSG Azure SQL Managed Instance pour qu’elles fonctionnent avec le registre confidentiel Azure
Si vous utilisez Azure SQL Managed Instance, veillez à configurer les règles de réseau virtuel de votre Azure SQL Managed Instance pour communiquer à l’aide du registre confidentiel Azure. Pour plus d’informations, consultez Configurer les règles NSG Azure SQL Managed Instance pour qu’elles fonctionnent sur le registre confidentiel d’Azure.
Génération et stockage manuels des synthèses de base de données
Vous pouvez également générer une synthèse de base de données à la demande, et ainsi la stocker manuellement dans un service ou un appareil que vous considérez comme une destination de stockage de confiance. Vous pourriez par exemple choisir un appareil local WORM (Write Once Read Many) comme destination. Vous générez manuellement une synthèse de base de données en exécutant la procédure stockée sys.sp_generate_database_ledger_digest dans SQL Server Management Studio ou Azure Data Studio.
EXECUTE sp_generate_database_ledger_digest;
Le jeu de résultats retourné est une ligne unique de données. Il doit être enregistré dans l’emplacement de stockage de confiance sous la forme d’un document JSON, de la façon suivante :
{
"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"
}
autorisations
La génération de synthèses de base de données nécessite une autorisation GENERATE LEDGER DIGEST. Pour plus d’informations sur les autorisations associées aux tables du registre, consultez Autorisations.
Considérations relatives à la gestion des synthèses
Restauration de base de données
La restauration de la base de données à un point antérieur dans le temps, également appelée Restauration à un instant dans le passé, constitue une opération fréquemment utilisée lorsqu’une erreur se produit et les utilisateurs doivent rétablir rapidement l’état de la base de données jusqu’à une date et heure précises. Lorsque vous chargez les synthèses générées dans le Stockage Azure ou le registre confidentiel Azure, la date de création de la base de données est capturée, et les synthèses y sont associées. Chaque fois que la base de données est restaurée, elle est catégorisée par une nouvelle heure de création. Cette technique nous permet de stocker les synthèses dans différentes « incarnations » de la base de données. Pour SQL Server, l'heure de création est l'heure UTC actuelle à laquelle le chargement de synthèse est activé pour la première fois. Le registre conserve les informations relatives au moment où une opération de restauration s’est produite, ce qui permet au processus de vérification d’utiliser toutes les synthèses pertinentes dans les diverses incarnations de la base de données. En outre, les utilisateurs peuvent inspecter toutes les synthèses à différentes dates de création pour identifier quand la base de données a été restaurée et à quel point dans le temps. Compte tenu du fait que ces données sont écrites dans un espace de stockage immuable, ces informations sont également protégées.
Remarque
Si vous effectuez une restauration native d'une sauvegarde de base de données dans Azure SQL Managed Instance, vous devez modifier le chemin d'accès manuellement en utilisant le portail Azure, PowerShell ou Azure CLI.
Géoréplication active et groupes de disponibilité Always On
La géoréplication active ou les groupes de basculement automatique peuvent être configurés pour la base de données Azure SQL ou Azure SQL Managed Instance. La réplication sur plusieurs régions géographiques est asynchrone pour des raisons de performances. Ainsi, la base de données secondaire se retrouve légèrement en retard par rapport au à la base de données primaire. En cas de basculement géographique, toutes les données récentes qui n’ont pas encore été répliquées sont perdues. Le registre n’émet des synthèses de base de données que pour les données qui ont été répliquées dans des bases de données secondaires géographiques. Cela permet de garantir que les synthèses ne font jamais référence à des données susceptibles d’être perdues en cas de basculement géographique. Ce principe s’applique uniquement à la génération et au stockage automatiques des synthèses de base de données. Dans un groupe de basculement, les bases de données primaire et secondaire ont le même chemin d'accès. Même en cas de basculement, le chemin d'accès à la synthèse n'est pas modifié pour les bases de données primaire et secondaire.
Si le groupe de basculement est supprimé ou si vous supprimez la liaison, les deux bases de données se comporteront comme des bases de données primaires. À ce stade, le chemin d’accès au résumé de la base de données secondaire précédente sera modifié et nous ajouterons un dossier RemovedSecondaryReplica au chemin d’accès.
Lorsque votre base de données fait partie d'un groupe de disponibilité Always On ou d'une liaison Managed Instance dans SQL Server, le même principe que celui de la géoréplication active s'applique. Le chargement des synthèses n'est effectué que si toutes les transactions ont été répliquées sur les réplicas secondaires.