Delen via

Digest-beheer

  • Artikel

van toepassing op: SQL Server 2022 (16.x) Azure SQL DatabaseAzure SQL Managed Instance

Database-overzichten

De hash van het meest recente blok in het databasegrootboek wordt de databasesamenvattinggenoemd. Het vertegenwoordigt de status van alle grootboektabellen in de database op het moment dat het blok is gegenereerd. Het genereren van een databasesamenvatting is efficiënt, omdat het alleen de hashes van de blokken betreft die onlangs zijn toegevoegd.

Databasesamenvatingen kunnen automatisch worden gegenereerd door het systeem of handmatig door de gebruiker. U kunt ze later gebruiken om de integriteit van de database te controleren.

Databasesamenvatten worden gegenereerd in de vorm van een JSON-document dat de hash van het meest recente blok bevat, samen met metagegevens voor de blok-id. De metagegevens bevatten de tijd waarop de samenvatting is gegenereerd en het tijdstempel van de doorvoer van de laatste transactie in dit blok.

Het verificatieproces en de integriteit van de database zijn afhankelijk van de integriteit van de invoersamenvatten. Voor dit doel moeten databasesamenvatten die worden geëxtraheerd uit de database worden opgeslagen in vertrouwde opslag waarmee de gebruikers met hoge bevoegdheden of aanvallers van de database niet kunnen knoeien.

Automatische generatie en opslag van databasesamenvatten

Notitie

Het automatisch genereren en opslaan van databasesamenvattingen in SQL Server ondersteunt alleen Azure Storage-accounts.

Ledger integreert met de onveranderbare opslagfunctie van Azure Blob Storage en Azure Confidential Ledger. Deze integratie biedt beveiligde opslagservices in Azure om de databasesamenvatingen te beschermen tegen mogelijke manipulatie. Deze integratie biedt een eenvoudige en rendabele manier voor gebruikers om digestbeheer te automatiseren zonder dat ze zich zorgen hoeven te maken over hun beschikbaarheid en geografische replicatie. Azure Confidential Ledger heeft een sterkere integriteitsgarantie voor klanten die zich zorgen kunnen maken over bevoegde beheerderstoegang tot de samenvatting. Deze tabel vergelijkt de onveranderbare opslagfunctie van Azure Blob Storage met Azure Confidential Ledger.

U kunt automatische generatie en opslag van databasesamenvatingen configureren via Azure Portal, PowerShell of de Azure CLI. Zie Automatische digest-opslag inschakelenvoor meer informatie. Wanneer u automatische generatie en opslag configureert, worden databasesamenvatten gegenereerd op een vooraf gedefinieerd interval van 30 seconden en geüpload naar de geselecteerde opslagservice. Als er in het interval van 30 seconden geen transacties plaatsvinden op het systeem, wordt er geen databasesamenvating gegenereerd en geüpload. Dit mechanisme zorgt ervoor dat databasesamenvatten alleen worden gegenereerd wanneer gegevens in uw database zijn bijgewerkt. Wanneer het eindpunt een Azure Blob Storage is, maakt de logische server voor Azure SQL Database of Azure SQL Managed Instance een nieuwe container met de naam sqldbledgerdigests en maakt gebruik van een naamgevingspatroon zoals: ServerName/DatabaseName/CreationTime. De aanmaaktijd is nodig omdat een database met dezelfde naam kan worden verwijderd en opnieuw kan worden gemaakt of hersteld, waardoor verschillende incarnaties van de database onder dezelfde naam kunnen worden geplaatst. Zie Overwegingen voor samenvattingsbeheervoor meer informatie.

Notitie

Voor SQL Server moet de container handmatig door de gebruiker worden gemaakt.

Onveranderbaarheidsbeleid voor Azure Storage-accounts

Als u een Azure Storage-account gebruikt voor de opslag van de databasesamenvatkingen, configureert u een beleid voor onveranderbaarheid op uw container na het inrichten om ervoor te zorgen dat databasesamenvatingen worden beschermd tegen manipulatie. Zorg ervoor dat met het onveranderbaarheidsbeleid beveiligde schrijfbewerkingen voor toevoeg-blobs zijn toegestaan en of het beleid is vergrendeld.

Machtiging voor Azure Storage-account

Als u Azure SQL Database of Azure SQL Managed Instancegebruikt, moet u ervoor zorgen dat uw logische server of beheerd exemplaar (Systeemidentiteit) voldoende RBAC-machtigingen (op rollen gebaseerd toegangsbeheer) heeft om samenvattingen te schrijven door deze toe te voegen aan de Bijdrager voor opslagblobgegevens rol. Als u actieve geo-replicatie of groepen voor automatische failover gebruikt, moet u ervoor zorgen dat de secundaire replica's dezelfde RBAC-machtiging hebben voor het Azure Storage-account.

Als u SQL Server-gebruikt, moet u een SAS (Shared Access Signature) maken in de digest-container, zodat SQL Server verbinding kan maken en verifiëren met het Azure Storage-account.

  • Maak een container in het Azure Storage-account met de naam sqldbledgerdigests.
  • Maak een beleid voor een container met de Read, Add, Create, Writeen List machtigingen en genereer een handtekeningsleutel voor gedeelde toegang.
  • Maak voor de sqldbledgerdigests-container die wordt gebruikt voor digest-bestandsopslag een SQL Server-referentie waarvan de naam overeenkomt met het containerpad.

In het volgende voorbeeld wordt ervan uitgegaan dat een Azure Storage-container, een beleid en een SAS-sleutel zijn gemaakt. Dit is nodig door SQL Server voor toegang tot de digest-bestanden in de container.

Vervang in het volgende codefragment <your SAS key> door de SAS-sleutel. De SAS-sleutel ziet eruit als '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-machtiging

Als u Azure SQL Database of Azure SQL Managed Instancegebruikt, moet u ervoor zorgen dat uw logische server of beheerd exemplaar (systeemidentiteit) over voldoende machtigingen beschikt om samenvattingen te schrijven door deze toe te voegen aan de rol Inzender. Volg hiervoor de stappen voor Gebruikersbeheer van Azure Confidential Ledger.

Notitie

Het automatisch genereren en opslaan van databasesamenvattingen in SQL Server ondersteunt alleen Azure Storage-accounts.

NSG-regels voor Azure SQL Managed Instance configureren voor gebruik met Azure Confidential Ledger

Als u Azure SQL Managed Instancegebruikt, moet u ervoor zorgen dat u de regels voor het virtuele netwerk van uw Azure SQL Managed Instance configureert om te communiceren met Azure Confidential Ledger. Zie NSG-regels voor Azure SQL Managed Instance configureren voor gebruik met Azure Confidential Ledgervoor meer informatie.

Handmatige generatie en opslag van databasesamenvatten

U kunt ook een databasesamenvating op aanvraag genereren, zodat u de digest handmatig kunt opslaan in elke service of elk apparaat dat u beschouwt als een vertrouwde opslagbestemming. U kunt bijvoorbeeld een lokaal WORM-opslagapparaat (Write Once, Read Many) als bestemming kiezen. U genereert handmatig een databasesamenvatting door de sys.sp_generate_database_ledger_digest opgeslagen procedure uit te voeren in SQL Server Management Studio- of Azure Data Studio-.

EXECUTE sp_generate_database_ledger_digest;

De geretourneerde resultatenset is één rij met gegevens. Deze moet als volgt worden opgeslagen op de vertrouwde opslaglocatie als een JSON-document:

    {
        "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"
    }

Machtigingen

Voor het genereren van databasesamenvatingen is de machtiging GENERATE LEDGER DIGEST vereist. Zie Machtigingenvoor meer informatie over machtigingen met betrekking tot grootboektabellen.

Overwegingen voor samenvattingsbeheer

Database herstel

Het herstellen van de database naar een eerder tijdstip, ook wel bekend als Herstel naar een bepaald tijdstip, is een bewerking die vaak wordt gebruikt wanneer er een fout optreedt en gebruikers de status van de database snel moeten terugzetten naar een eerder tijdstip. Wanneer u de gegenereerde digests uploadt naar Azure Storage of Azure Confidential Ledger, wordt de creatietijd van de database vastgelegd waar deze digests aan zijn gekoppeld. Telkens wanneer de database wordt hersteld, wordt deze getagd met een nieuwe aanmaak tijd en met deze techniek kunnen we de digests opslaan bij verschillende 'incarnaties' van de database. Voor SQL Server is de aanmaaktijd de huidige UTC-tijd wanneer het uploaden van de gegevenssamenvatting voor de eerste keer is ingeschakeld. Ledger bewaart de informatie over wanneer een herstelbewerking heeft plaatsgevonden, zodat het verificatieproces alle relevante digests kan gebruiken over de verschillende versies van de database. Daarnaast kunnen gebruikers alle overzichten controleren voor verschillende aanmaaktijden om te bepalen wanneer de database is hersteld en tot welk punt deze is hersteld. Omdat deze gegevens zijn geschreven in onveranderbare opslag, worden deze gegevens ook beveiligd.

Notitie

Als u een systeemeigen herstel uitvoert van een databaseback-up in Azure SQL Managed Instance, moet u het digest-pad handmatig wijzigen met behulp van Azure Portal, PowerShell of de Azure CLI.

Actieve geo-replicatie en AlwaysOn-beschikbaarheidsgroepen

Actieve geo-replicatie of automatische failovergroepen kunnen worden geconfigureerd voor Azure SQL Database of Azure SQL Managed Instance. Replicatie tussen geografische regio's is asynchroon om prestatieredenen en zorgt er dus voor dat de secundaire database iets achter blijft in vergelijking met de primaire database. In het geval van een geografische failover gaan alle meest recente gegevens die nog niet zijn gerepliceerd verloren. Ledger geeft alleen databasesamenvattingen uit voor gegevens die zijn gerepliceerd naar geografische secundaire locaties, zodat digests nooit verwijzen naar gegevens die verloren kunnen gaan in het geval van een geografische failover. Dit geldt alleen voor het automatisch genereren en opslaan van databasesamenvatten. In een failovergroep hebben zowel de primaire als de secundaire database hetzelfde digestpad. Zelfs wanneer u een failover uitvoert, verandert het digest-pad niet voor zowel de primaire als de secundaire database.

Als de failovergroep wordt verwijderd of als u de koppeling verwijdert, gedragen beide databases zich als primaire databases. Op dat moment wordt het digest-pad van de vorige secundaire database gewijzigd en voegen we een map RemovedSecondaryReplica toe aan het pad.

Wanneer uw database deel uitmaakt van een AlwaysOn-beschikbaarheidsgroep of een managed instance-koppeling in SQL Server, wordt hetzelfde principe gebruikt als actieve geo-replicatie. Het uploaden van de samenvattingen wordt alleen uitgevoerd als alle transacties zijn gerepliceerd naar de secundaire replica's.

Verwante inhoud