Transparent Data Encryption (TDE) met door de klant beheerde sleutels op databaseniveau

Van toepassing op: Azure SQL Database

In dit artikel wordt transparante gegevensversleuteling (TDE) beschreven met door de klant beheerde sleutels op databaseniveau voor Azure SQL Database.

Notitie

TDE CMK op databaseniveau is beschikbaar voor Azure SQL Database (alle SQL Database-edities). Het is niet beschikbaar voor Azure SQL Managed Instance, on-premises SQL Server, Azure-VM's en Azure Synapse Analytics (toegewezen SQL-pools (voorheen SQL DW)).

Notitie

Microsoft Entra-id is de nieuwe naam voor Azure Active Directory (Azure AD). Op dit moment wordt de documentatie bijgewerkt.

Overzicht

Azure SQL biedt versleuteling-at-rest-mogelijkheden voor klanten via TDE (Transparent Data Encryption). Het uitbreiden van TDE met door de klant beheerde sleutel (CMK) maakt data protection-at-rest mogelijk, waarbij de TDE-beveiliging (de versleutelingssleutel) wordt opgeslagen in een Azure Key Vault waarmee de databaseversleutelingssleutels worden versleuteld. TDE met CMK is momenteel ingesteld op serverniveau en wordt overgenomen door alle versleutelde databases die aan die server zijn gekoppeld. Met deze nieuwe functie kunt u de TDE-beveiliging afzonderlijk instellen als een door de klant beheerde sleutel voor elke database op de server. Elke Microsoft.Sql/servers/databases resource met een geldige, lege encryptionProtector eigenschap wordt geconfigureerd met door de klant beheerde sleutels op databaseniveau.

In dit scenario kan een asymmetrische sleutel die is opgeslagen in een door de klant beheerde Azure Key Vault (AKV) afzonderlijk worden gebruikt voor elke database binnen een server om de versleutelingssleutel (DEK) van de database te versleutelen, genaamd TDE-beveiliging. Er is een optie om sleutels toe te voegen, sleutels te verwijderen en de door de gebruiker toegewezen beheerde identiteit (UMI) voor elke database te wijzigen. Zie Beheerde identiteitstypen in Azure voor meer informatie over identiteiten.

De volgende functionaliteit is beschikbaar:

• Door de gebruiker toegewezen beheerde identiteit: u kunt één door de gebruiker toegewezen beheerde identiteit toewijzen aan de database. Deze identiteit kan worden gebruikt om toegang te krijgen tot Azure Key Vault en versleutelingssleutels te beheren.
• Beheer van versleutelingssleutels: u kunt inschakelen dat een of meer versleutelingssleutels worden toegevoegd op databaseniveau en een van de toegevoegde sleutels instellen als de TDE-beveiliging. De versleutelingssleutels die worden toegevoegd, gebruiken de door de gebruiker toegewezen beheerde identiteit die al aan de database is toegewezen voor toegang tot Azure Key Vault.
• Federatieve clientidentiteit: u kunt ook een door de klant beheerde sleutel (CMK) van Azure Key Vault in een andere Microsoft Entra-tenant instellen als TDE-beveiliging op databaseniveau door federatieve clientidentiteit te gebruiken die is ingesteld op de Azure SQL Database. Hiermee kunt u TDE beheren met sleutels die zijn opgeslagen in de Azure Key Vault van een andere tenant.

Notitie

Door het systeem toegewezen beheerde identiteit wordt niet ondersteund op databaseniveau.

Voordelen van door de klant beheerde TDE op databaseniveau

Als meer serviceproviders, ook wel onafhankelijke softwareleveranciers (ISV's) genoemd, azure SQL Database gebruiken om hun services te bouwen, maken velen gebruik van elastische pools als een manier om rekenresources efficiënt te distribueren over meerdere databases. Door elk van de databases van hun klanten in een gedeelde elastische pool te hebben, kunnen ISV's profiteren van de mogelijkheid van de pool om het resourcegebruik te optimaliseren en tegelijkertijd ervoor te zorgen dat elke database voldoende resources heeft.

Er is echter een aanzienlijke beperking voor deze benadering. Wanneer meerdere databases worden gehost op dezelfde logische Azure SQL-server, delen ze de TDE-beveiliging op serverniveau. ISV's kunnen geen echte cmk-mogelijkheden (door de klant beheerde sleutels) bieden aan hun klanten. Zonder de mogelijkheid om hun eigen versleutelingssleutels te beheren, kunnen klanten aarzelen om gevoelige gegevens toe te vertrouwen aan de service van de ISV, met name als nalevingsvoorschriften vereisen dat ze volledige controle over hun versleutelingssleutels behouden.

Met TDE CMK op databaseniveau kunnen ISV's CMK-mogelijkheden bieden aan hun klanten en beveiligingsisolatie bereiken, omdat de TDE-beveiliging van elke database mogelijk eigendom kan zijn van de respectieve ISV-klant in een sleutelkluis waarvan ze eigenaar zijn. De beveiligingsisolatie die is bereikt voor klanten van ISV is zowel qua sleutel als de identiteit die wordt gebruikt voor toegang tot de sleutel.

In het onderstaande diagram ziet u een overzicht van de nieuwe functionaliteit die hierboven wordt aangegeven. Het presenteert twee afzonderlijke Microsoft Entra-tenants. De Best Services tenant die de logische Azure SQL-server met twee databases bevat, DB 1 en DB 2de Azure Key Vault 1 tenant met toegang Key 1 tot de database DB 1 met behulp van UMI 1. Beide UMI 1 en Key 1 vertegenwoordigen de instelling op serverniveau. Standaard nemen alle databases die in eerste instantie op deze server zijn gemaakt, deze instelling over voor TDE met CMK. De Contoso tenant vertegenwoordigt een clienttenant die een evaluatie van de database DB 2 in de tenant bevat Azure Key Vault 2 Key 2 als onderdeel van de cmk-ondersteuning op databaseniveau die ondersteuning biedt voor meerdere tenants die deze database gebruiken Key 2 en UMI 2 instellen.

Zie het document Door meerdere tenants beheerde sleutels op serverniveau met transparante gegevensversleuteling voor meer informatie over de configuratie van identiteiten tussen tenants.

Ondersteunde scenario's voor sleutelbeheer

Voor de volgende sectie gaan we ervan uit dat er een server is die bestaat uit drie databases (bijvoorbeeld Database1Database2, en Database3).

Bestaand scenario

Key1 is geconfigureerd als de door de klant beheerde sleutel op het niveau van de logische server. Alle databases onder deze server nemen dezelfde sleutel over.

• Server : Key1 instellen als CMK
• Database1 – Key1 gebruikt als CMK
• Database2 – Key1 gebruikt als CMK
• Database3 – Key1 gebruikt als CMK

Nieuw ondersteund scenario: logische server geconfigureerd met door de klant beheerde sleutel

Key1 is geconfigureerd als de door de klant beheerde sleutel op het niveau van de logische server. Een andere door de klant beheerde sleutel (Key2) kan worden geconfigureerd op databaseniveau.

• Server : Key1 instellen als CMK
• Database1 – Key2 gebruikt als CMK
• Database2 – Key1 gebruikt als CMK
• Database3 – Key1 gebruikt als CMK

Notitie

Als de logische server is geconfigureerd met door de klant beheerde sleutels voor TDE, kan een afzonderlijke database in deze logische server niet worden aangemeld voor het gebruik van door de service beheerde sleutel voor transparante gegevensversleuteling.

Nieuw ondersteund scenario: logische server geconfigureerd met door de service beheerde sleutel

Logische server is geconfigureerd met beheerde sleutel (SMK) voor TDE. Een andere door de klant beheerde sleutel (Key2) kan worden geconfigureerd op databaseniveau.

• Server : door de service beheerde sleutel die is ingesteld als de TDE-beveiliging
• Database1 – Key2 ingesteld als CMK
• Database2 – Door de service beheerde sleutel ingesteld als de TDE-beveiliging
• Database3 – Door de service beheerde sleutel ingesteld als de TDE-beveiliging

Herstellen naar versleuteling op serverniveau

Database1 is geconfigureerd met een door de klant beheerde sleutel op databaseniveau voor TDE, terwijl de logische server is geconfigureerd met een door de service beheerde sleutel. Database1 kan worden teruggezet om de door de service beheerde sleutel op serverniveau te gebruiken.

Notitie

Als de logische server is geconfigureerd met CMK voor TDE, kan de database die is geconfigureerd met CMK op databaseniveau, niet worden teruggezet naar versleuteling op serverniveau.

Hoewel de herstelbewerking alleen wordt ondersteund als de logische server is geconfigureerd met een door de service beheerde sleutel bij het gebruik van TDE, kan een database die is geconfigureerd met CMK op databaseniveau, worden hersteld naar een server die is geconfigureerd met CMK, mits de server toegang heeft tot alle sleutels die door de brondatabase worden gebruikt met een geldige identiteit.

Vereisten voor sleutelkluis en beheerde identiteit

Dezelfde vereisten voor het configureren van Azure Key Vault-sleutels (AKV) en beheerde identiteiten, waaronder sleutelinstellingen en machtigingen die zijn verleend aan de identiteit die van toepassing zijn op de CMK-functie (door de klant beheerde sleutel) op serverniveau, zijn ook van toepassing op de CMK op databaseniveau. Zie Transparent Data Encryption (TDE) met CMK en beheerde identiteiten met CMK voor meer informatie.

Sleutelbeheer

Als u de TDE-beveiliging voor een database roteert, moet u overschakelen naar een nieuwe asymmetrische sleutel die de database beveiligt. Sleutelrotatie is een onlinebewerking en duurt slechts enkele seconden. De bewerking ontsleutelt alleen en versleutelt de databaseversleutelingssleutel opnieuw, niet de hele database. Zodra een geldige door de gebruiker toegewezen beheerde identiteit is toegewezen aan een database, is het roteren van de sleutel op databaseniveau een CRUD-bewerking voor de database waarbij de eigenschap versleutelingsbeveiliging van de database moet worden bijgewerkt. Set-AzSqlDatabase en de eigenschap -EncryptionProtector kunnen worden gebruikt om sleutels te draaien. Als u een nieuwe database wilt maken die is geconfigureerd met CMK op databaseniveau, kan New-AzSqlDatabase worden gebruikt met de -AssignIdentity-EncryptionProtector, en -UserAssignedIdentityId parameters.

Nieuwe sleutels kunnen worden toegevoegd en bestaande sleutels kunnen worden verwijderd uit de database met behulp van vergelijkbare aanvragen en het wijzigen van de eigenschap sleutels voor de databaseresource. Set-AzSqlDatabase met de parameter -KeyList en -KeysToRemove kan worden gebruikt voor deze bewerkingen. Als u de instelling voor versleutelingsbeveiliging, identiteit en sleutels wilt ophalen, kan Get-AzSqlDatabase worden gebruikt. In de Azure Resource Manager-resource Microsoft.Sql/servers/databases wordt standaard alleen de TDE-beveiliging en beheerde identiteit weergegeven die in de database is geconfigureerd. Als u de volledige lijst met sleutels wilt uitbreiden, zijn andere parameters -ExpandKeyList nodig. -KeysFilter "current" Daarnaast kan een bepaald tijdstip (bijvoorbeeld2023-01-01) worden gebruikt om de huidige sleutels op te halen die in het verleden zijn gebruikt en sleutels die in het verleden op een bepaald tijdstip worden gebruikt.

Automatische sleutelrotatie

Automatische sleutelrotatie is beschikbaar op databaseniveau en kan worden gebruikt met Azure Key Vault-sleutels. De rotatie wordt geactiveerd wanneer een nieuwe versie van de sleutel wordt gedetecteerd en wordt automatisch binnen 24 uur geroteerd. Zie Automatische sleutelrotatie op databaseniveau voor informatie over het configureren van automatische sleutelrotatie met behulp van Azure Portal, PowerShell of de Azure CLI.

Machtiging voor sleutelbeheer

Afhankelijk van het machtigingsmodel van de sleutelkluis (toegangsbeleid of Azure RBAC), kan toegang tot de sleutelkluis worden verleend door een toegangsbeleid te maken voor de sleutelkluis of door een nieuwe Azure RBAC-roltoewijzing te maken.

Machtigingsmodel voor toegangsbeleid

Om de database TDE-protector te kunnen gebruiken die is opgeslagen in AKV voor versleuteling van de DEK, moet de key vault-beheerder de volgende toegangsrechten verlenen voor de door de gebruiker toegewezen beheerde identiteit van de database met behulp van de unieke Microsoft Entra-identiteit:

• ophalen : voor het ophalen van het openbare deel en de eigenschappen van de sleutel in Azure Key Vault.
• wrapKey : om DEK te beveiligen (versleutelen).
• unwrapKey : om de beveiliging (ontsleuteling) DEK op te heffen.

Azure RBAC-machtigingenmodel

Om de TDE-protector te kunnen gebruiken die is opgeslagen in AKV voor versleuteling van de DEK, moet een nieuwe Azure RBAC-roltoewijzing met de key vault cryptoserviceversleutelingsgebruiker worden toegevoegd voor de door de database toegewezen beheerde identiteit met behulp van de unieke Microsoft Entra-identiteit.

Door de klant beheerde sleutels voor meerdere tenants

Door de klant beheerde sleutels voor meerdere tenants met transparante gegevensversleuteling beschrijft hoe u een federatieve client-id instelt voor CMK op serverniveau. Er moet een vergelijkbare installatie worden uitgevoerd voor CMK op databaseniveau en de federatieve client-id moet worden toegevoegd als onderdeel van de API-aanvragen Set-AzSqlDatabase of New-AzSqlDatabase .

Notitie

Als de toepassing met meerdere tenants niet is toegevoegd aan het toegangsbeleid voor de sleutelkluis met de vereiste machtigingen (Ophalen, Sleutel verpakken, Sleutel uitpakken), wordt er een fout weergegeven met behulp van een toepassing voor identiteitsfederatie in Azure Portal. Zorg ervoor dat de machtigingen correct zijn geconfigureerd voordat u de federatieve clientidentiteit configureert.

Een database die is geconfigureerd met CMK op databaseniveau, kan worden teruggezet naar versleuteling op serverniveau als de logische server is geconfigureerd met een door de service beheerde sleutel met invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert.

In het geval van een niet-toegankelijke TDE-protector zoals beschreven in Transparent Data Encryption (TDE) met CMK, kan zodra de sleuteltoegang is gecorrigeerd, Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation worden gebruikt om de database toegankelijk te maken.

Notitie

Identiteits- en sleutelbeheer voor TDE met door de klant beheerde sleutels op databaseniveau beschrijft de bewerkingen voor identiteits- en sleutelbeheer voor CMK op databaseniveau, samen met Powershell, de Azure CLI en REST API-voorbeelden.

Aanvullende overwegingen

• Als TDE met CMK al is ingeschakeld op serverniveau, overschrijft het instellen van CMK voor een bepaalde database de CMK-instelling op serverniveau (deK van de database wordt opnieuw versleuteld met de TDE-beveiliging op databaseniveau).
• Sleutelwijzigingen of rotaties op logisch serverniveau zijn niet van invloed op CMK-instellingen op databaseniveau en de database blijft een eigen CMK-instelling gebruiken.
• CMK op databaseniveau wordt niet ondersteund via Transact-SQL (T-SQL).
• De door de gebruiker toegewezen beheerde identiteit (UMI) van de logische server kan worden gebruikt op databaseniveau. Het is echter raadzaam om een aangewezen UMI te gebruiken voor cmk op databaseniveau.
• CMK-instellingen voor meerdere tenants op serverniveau zijn niet van invloed op afzonderlijke databases die zijn geconfigureerd met CMK op databaseniveau en ze blijven hun eigen configuratie voor één tenant of meerdere tenants gebruiken.
• Er kan slechts één door de gebruiker toegewezen beheerde identiteit worden ingesteld op databaseniveau.

Notitie

De beheerde identiteiten in de database moeten opnieuw worden toegewezen als de naam van de database wordt gewijzigd.

Migratie van bestaande databases naar CMK op databaseniveau

Nieuwe databases kunnen worden geconfigureerd met CMK op databaseniveau tijdens het maken en bestaande databases op servers die zijn geconfigureerd met door de service beheerde sleutels, kunnen worden gemigreerd naar CMK op databaseniveau met behulp van de bewerkingen die worden beschreven in Identiteits- en sleutelbeheer voor TDE met door de klant beheerde sleutels op databaseniveau. Als u databases wilt migreren die zijn geconfigureerd met CMK of geo-replicatie op serverniveau, zijn er andere stappen nodig, zoals beschreven in de volgende secties.

Database geconfigureerd met cmk op serverniveau zonder geo-replicatie

1. Gebruik de sys.dm_db_log_info (Transact-SQL) - SQL Server voor uw database en zoek naar virtuele logboekbestanden (VLF's) die actief zijn.
2. Noteer het vlf_encryptor_thumbprint resultaat voor sys.dm_db_log_info alle actieve VLF's.
3. Gebruik de sys.dm_database_encryption_keys (Transact-SQL) - SQL Server-weergave voor uw database om te controleren op encryptor_thumbprint. Noteer de encryptor_thumbprint.
4. Gebruik de cmdlet Get-AzSqlServerKeyVaultKey om alle sleutels op serverniveau op te halen die op de logische server zijn geconfigureerd. Kies in de resultaten de vingerafdrukken met dezelfde vingerafdruk die overeenkomen met de lijst uit het bovenstaande resultaat.
5. Maak een updatedatabase-API-aanroep naar de database die u wilt migreren, samen met de identiteits- en versleutelingsbeveiliging. Geef de bovenstaande sleutels door als sleutels op databaseniveau met behulp van Set-AzSqlDatabase met behulp van de -UserAssignedIdentityIdparameters , -KeyList-AssignIdentity, -EncryptionProtector (en indien nodig-FederatedClientId) .

Belangrijk

De identiteit die wordt gebruikt in de aanvraag voor de updatedatabase, moet toegang hebben tot alle sleutels die worden doorgegeven als invoer.

Database geconfigureerd met CMK op serverniveau met geo-replicatie

1. Volg de stappen (1) tot en met (4) die in de vorige sectie zijn vermeld om de lijst met sleutels op te halen die nodig zijn voor migratie.
2. Maak een updatedatabase-API-aanroep naar de primaire en secundaire database die u wilt migreren, samen met de identiteit en de bovenstaande sleutels als sleutels op databaseniveau met behulp van Set-AzSqlDatabase en de -KeyList parameter. Stel de versleutelingsbeveiliging nog niet in.
3. De sleutel op databaseniveau die u wilt gebruiken als primaire beveiliging op de databases, moet eerst worden toegevoegd aan de secundaire database. Gebruik Set-AzSqlDatabase met -KeyList om deze sleutel toe te voegen aan de secundaire database.
4. Zodra de versleutelingsbeveiligingssleutel is toegevoegd aan de secundaire database, gebruikt u de Set-AzSqlDatabase om deze in te stellen als versleutelingsbeveiliging voor de primaire database met behulp van de -EncryptionProtector parameter.
5. Stel de sleutel in als de versleutelingsbeveiliging op de secundaire database, zoals beschreven in (4) om de migratie te voltooien.

Belangrijk

Als u databases wilt migreren die zijn geconfigureerd met een door de service beheerde sleutel en geo-replicatie op serverniveau, volgt u de stappen (3), (4) en (5) uit deze sectie.

Geo-replicatie en hoge beschikbaarheid

In zowel actieve scenario's voor geo-replicatie als failovergroepen kunnen de betrokken primaire en secundaire databases worden gekoppeld aan dezelfde sleutelkluis (in elke regio) of aan afzonderlijke sleutelkluizen. Als afzonderlijke sleutelkluizen zijn gekoppeld aan de primaire en secundaire servers, is de klant verantwoordelijk voor het consistent houden van het sleutelmateriaal in de sleutelkluizen, zodat geo-secundaire is gesynchroniseerd en het gebruik van dezelfde sleutel van de gekoppelde sleutelkluis kan overnemen als de primaire sleutel niet meer toegankelijk is vanwege een storing in de regio en er een failover wordt geactiveerd. Maximaal vier secundaire databases kunnen worden geconfigureerd en het koppelen (secundaire bestanden van secundaire bestanden) wordt niet ondersteund.

Als u actieve geo-replicatie wilt instellen voor een database die is geconfigureerd met CMK op databaseniveau, moet er een secundaire replica worden gemaakt met een geldige door de gebruiker toegewezen beheerde identiteit en een lijst met huidige sleutels die door de primaire database worden gebruikt. De lijst met huidige sleutels kan worden opgehaald uit de primaire database met behulp van de benodigde filters en queryparameters, of met behulp van PowerShell en de Azure CLI. De stappen die nodig zijn voor het instellen van een geo-replica van een dergelijke database zijn:

1. De lijst met sleutels die door de primaire database worden gebruikt vooraf ingevuld met behulp van de opdracht Get-AzSqlDatabase en de -ExpandKeyList en -KeysFilter "current" parameters. Sluit -KeysFilter uit als u alle sleutels wilt ophalen.
2. Selecteer de door de gebruiker toegewezen beheerde identiteit (en federatieve client-id als u cross-tenanttoegang configureert).
3. Maak een nieuwe database als secundaire database met behulp van New-AzSqlDatabaseSecondary en geef de vooraf ingevulde lijst met sleutels op die zijn verkregen uit de brondatabase en de bovenstaande identiteit (en federatieve client-DI als u cross-tenanttoegang configureert) in de API-aanroep met behulp van de -KeyListparameters , -UserAssignedIdentityId-AssignIdentity, ( -EncryptionProtector en indien nodig -FederatedClientId) .
4. Gebruik New-AzSqlDatabaseCopy om een kopie van de database te maken met dezelfde parameters in de vorige stap.

Belangrijk

Een database die is geconfigureerd met CMK op databaseniveau, moet een replica (of kopie) zijn geconfigureerd met CMK op databaseniveau. De replica kan geen versleutelingsinstellingen op serverniveau gebruiken.

Als u een database wilt gebruiken die is geconfigureerd met CMK op databaseniveau in een failovergroep, moeten de bovenstaande stappen voor het maken van een secundaire replica met dezelfde naam als de primaire replica worden gebruikt op de secundaire server. Zodra deze secundaire replica is geconfigureerd, kunnen de databases worden toegevoegd aan de failovergroep.

Databases die zijn geconfigureerd met CMK op databaseniveau bieden geen ondersteuning voor het automatisch maken van secundaire databases wanneer ze worden toegevoegd aan een failovergroep.

Voor meer informatie wordt beschreven hoe u geo-replicatie en back-upherstel configureert voor transparante gegevensversleuteling met door de klant beheerde sleutels voor het instellen van geo-replicatie en failovergroepen met behulp van REST API's, PowerShell en de Azure CLI.

Notitie

Alle aanbevolen procedures met betrekking tot geo-replicatie en hoge beschikbaarheid die zijn gemarkeerd in TDE (Transparent Data Encryption) met CMK op serverniveau, zijn van toepassing op CMK op databaseniveau.

Back-up en herstel voor databases met behulp van TDE met door de klant beheerde sleutel op databaseniveau

Zodra een database is versleuteld met TDE met behulp van een sleutel uit Azure Key Vault, worden alle nieuw gegenereerde back-ups ook versleuteld met dezelfde TDE-beveiliging. Wanneer de TDE-beveiliging wordt gewijzigd, worden oude back-ups van de database niet bijgewerkt om de nieuwste TDE-beveiliging te gebruiken. Als u een back-up wilt herstellen die is versleuteld met een TDE-protector van Azure Key Vault die is geconfigureerd op databaseniveau, moet u ervoor zorgen dat het sleutelmateriaal wordt verstrekt aan de doeldatabase. We raden u aan alle oude versies van de TDE-beveiliging in een sleutelkluis te bewaren, zodat databaseback-ups kunnen worden hersteld.

Belangrijk

Er kan slechts één TDE-beveiliging worden ingesteld voor een database. Tijdens het herstellen kunnen echter meerdere extra sleutels worden doorgegeven aan een database zonder ze een TDE-beveiliging te markeren. Deze sleutels worden niet gebruikt voor het beveiligen van DEK, maar kunnen worden gebruikt tijdens het herstellen vanuit een back-up, als het back-upbestand is versleuteld met de sleutel met de bijbehorende vingerafdruk.

Herstel naar een bepaald tijdstip

De volgende stappen zijn nodig voor een herstel naar een bepaald tijdstip van een database die is geconfigureerd met door de klant beheerde sleutels op databaseniveau:

1. De lijst met sleutels die door de primaire database worden gebruikt vooraf ingevuld met behulp van de opdracht Get-AzSqlDatabase en de -ExpandKeyList en -KeysFilter "2023-01-01" parameters. 2023-01-01 is een voorbeeld van het tijdstip waarop u de database wilt herstellen. Sluit -KeysFilter uit als u alle sleutels wilt ophalen.
2. Selecteer de door de gebruiker toegewezen beheerde identiteit (en federatieve client-id als u cross-tenanttoegang configureert).
3. Gebruik Restore-AzSqlDatabase met de -FromPointInTimeBackup parameter en geef de vooraf ingevulde lijst met sleutels op die zijn verkregen uit de bovenstaande stappen, en de bovenstaande identiteit (en federatieve client-id als u cross-tenanttoegang configureert) in de API-aanroep met behulp van de -KeyListparameters , -AssignIdentity-UserAssignedIdentityId, -EncryptionProtector (en indien nodig-FederatedClientId) .

Notitie

Als u een database herstelt zonder de -EncryptionProtector eigenschap met alle geldige sleutels, wordt deze opnieuw ingesteld om versleuteling op serverniveau te gebruiken. Dit kan handig zijn om een door de klant beheerde sleutelconfiguratie op databaseniveau terug te keren naar de configuratie van de door de klant beheerde sleutel op serverniveau.

Verwijderde databaseherstel

De volgende stappen zijn nodig voor het herstellen van een database die is geconfigureerd met door de klant beheerde sleutels op databaseniveau:

1. De lijst met sleutels die door de primaire database worden gebruikt vooraf ingevuld met Behulp van Get-AzSqlDeletedDatabaseBackup en de -ExpandKeyList parameter. Het is raadzaam om alle sleutels door te geven die door de brondatabase zijn gebruikt, maar het is ook mogelijk dat herstel wordt geprobeerd met de sleutels die zijn opgegeven door de verwijderingstijd als de -KeysFilter.
2. Selecteer de door de gebruiker toegewezen beheerde identiteit (en federatieve client-id als u cross-tenanttoegang configureert).
3. Gebruik Restore-AzSqlDatabase met de -FromDeletedDatabaseBackup parameter en geef de vooraf ingevulde lijst met sleutels op die zijn verkregen uit de bovenstaande stappen en de bovenstaande identiteit (en de federatieve client-id als u cross-tenanttoegang configureert) in de API-aanroep met behulp van de -KeyListparameters , -AssignIdentity, -UserAssignedIdentityId-EncryptionProtector (en indien nodig-FederatedClientId) .

Geo-herstel

De volgende stappen zijn nodig voor een geo-herstel van een database die is geconfigureerd met door de klant beheerde sleutels op databaseniveau:

• De lijst met sleutels die door de primaire database worden gebruikt vooraf ingevuld met Behulp van Get-AzSqlDatabaseGeoBackup en de -ExpandKeyList om alle sleutels op te halen.
• Selecteer de door de gebruiker toegewezen beheerde identiteit (en federatieve client-id als u cross-tenanttoegang configureert).
• Gebruik Restore-AzSqlDatabase met de -FromGeoBackup parameter en geef de vooraf ingevulde lijst met sleutels op die zijn verkregen uit de bovenstaande stappen en de bovenstaande identiteit (en de federatieve client-id als u cross-tenanttoegang configureert) in de API-aanroep met behulp van de -KeyListparameters , -AssignIdentity, -UserAssignedIdentityId-EncryptionProtector (en indien nodig-FederatedClientId) .

Belangrijk

Het wordt aanbevolen dat alle sleutels die door de database worden gebruikt, behouden blijven om de database te herstellen. Het wordt ook aanbevolen om al deze sleutels door te geven aan het hersteldoel.

Notitie

Back-ups voor langetermijnretentie (LTR) bieden geen lijst met sleutels die door de back-up worden gebruikt. Als u een LTR-back-up wilt herstellen, moeten alle sleutels die door de brondatabase worden gebruikt, worden doorgegeven aan het LTR-hersteldoel.

Zie Geo-replicatie en back-upherstel configureren voor transparante gegevensversleuteling met door de klant beheerde sleutels op databaseniveau voor meer informatie over back-upherstel voor SQL Database met CMK op databaseniveau met powershell, de Azure CLI en REST API's.

Beperkingen

De functie door de klant beheerde sleutels op databaseniveau biedt geen ondersteuning voor sleutelrotaties wanneer de virtuele logboekbestanden van de database worden versleuteld met een oude sleutel die verschilt van de huidige primaire beveiliging van de database. De fout die in dit geval is opgetreden, is:

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: Sleutelrotatie voor de TDE-beveiliging op databaseniveau wordt geblokkeerd wanneer actieve transacties het logboek vasthouden dat is versleuteld met oude sleutels.

Als u dit scenario verder wilt begrijpen, kunt u de volgende tijdlijn overwegen:

• Tijd t0 = Een database wordt gemaakt zonder versleuteling
• Time t1 = Deze database wordt beveiligd door Thumbprint A, een door de klant beheerde sleutel op databaseniveau.
• Time t2 = De databasebeveiliging wordt geroteerd naar een nieuwe door de klant beheerde sleutel op databaseniveau. Thumbprint B
• Tijd t3 = Een protectorwijziging wordt Thumbprint C aangevraagd.
• Als de actieve VLF's worden gebruikt Thumbprint A, is de rotatie niet toegestaan.
• Als de actieve VLF's niet worden gebruikt Thumbprint A, is de rotatie toegestaan.

U kunt de sys.dm_db_log_info (Transact-SQL) - SQL Server-weergave voor uw database gebruiken en zoeken naar virtuele logboekbestanden die actief zijn. Als het goed is, ziet u een actieve VLF die is versleuteld met de eerste sleutel (bijvoorbeeld Thumbprint A). Zodra er voldoende logboek is gegenereerd door gegevensinvoeging, wordt deze oude VLF leeggemaakt en moet u een andere sleutelrotatie kunnen uitvoeren.

Raadpleeg de volgende documentatie voor verdere probleemoplossing als u denkt dat uw logboek langer vasthoudt dan verwacht:

• sys.dm_db_log_stats (Transact-SQL) voor mogelijke log_truncation_holdup_reason waarden.
• Problemen met volledige transactielogboekfout 9002 oplossen.

Volgende stappen

Raadpleeg de volgende documentatie over verschillende CMK-bewerkingen op databaseniveau:

• Identiteits- en sleutelbeheer voor TDE met door de klant beheerde sleutels op databaseniveau

• Geo-replicatie en back-upherstel configureren voor transparante gegevensversleuteling met door de klant beheerde sleutels op databaseniveau