Customer-managed TDE for Azure Synapse Analytics

Van toepassing op: Toegewezen SQL-pools van Azure Synapse Analytics (voorheen SQL DW)

Tip

Microsoft Fabric Data Warehouse is een relationeel warehouse op ondernemingsniveau op data lake-basis, met een architectuur die klaar is voor de toekomst, ingebouwde AI en nieuwe functies. Als u nieuw bent in gegevensopslag, begin dan met Fabric Data Warehouse. Bestaande dediceerde SQL-poolworkloads kunnen upgraden naar Fabric voor toegang tot nieuwe mogelijkheden in data science, realtime analyses en rapportage.

Transparante data-encryptie (TDE) met klantbeheerde sleutel (CMK) maakt het Bring Your Own Key (BYOK)-scenario mogelijk voor gegevensbescherming in rust, en stelt organisaties in staat om scheiding van taken te implementeren bij het beheer van sleutels en data. Door gebruik te maken van klantbeheerde TDE, neem je de verantwoordelijkheid voor en heb je volledige controle over het beheer van de levenscyclus van sleutels (sleutelcreatie, upload, rotatie, verwijdering), sleutelgebruiksrechten en het auditen van bewerkingen op sleutels.

In dit scenario is de Transparent Data Encryption (TDE) beschermer een door de klant beheerde sleutel die de Database Encryption Key (DEK) beveiligt. Je slaat de TDE-beschermer op in Azure Key Vault of Azure Key Vault Managed HSM, dit zijn veilige cloudgebaseerde sleutelbeheerdiensten die zijn ontworpen voor hoge beschikbaarheid en schaalbaarheid. Beide diensten ondersteunen cryptografische sleutels die beschermd zijn door FIPS 140-2 gevalideerde hardware: Azure Key Vault ondersteunt FIPS 140-2 Level 2, en Azure Key Vault Managed HSM ondersteunt FIPS 140-2 Level 3. Beide diensten ondersteunen ook asymmetrische en symmetrische sleuteltypes, en de ondersteunde algoritmen en het gebruik zijn afhankelijk van het TDE-implementatiemodel. Je kunt de sleutel in de dienst genereren, importeren of veilig overzetten vanaf lokale HSM's. Directe toegang tot sleutels is beperkt, dus geautoriseerde diensten voeren cryptografische bewerkingen uit zonder het sleutelmateriaal bloot te stellen.

Note

Dit artikel behandelt standalone dedicated SQL-pools (voorheen SQL DW).

  • Voor Azure Synapse Analytics dedicated SQL pools (voorheen SQL DW), stel je de TDE-beschermer in op serverniveau. Alle versleutelde databases die aan die server zijn gekoppeld, erven de TDE-beschermer.
  • Versleutel de data in speciale SQL-pools en serverless SQL-pools in een Synapse-werkruimte door gebruik te maken van de klantbeheerde sleutel die op werkruimteniveau is geconfigureerd. Zie Azure Synapse Analytics-versleuteling voor transparante gegevensversleuteling voor toegewezen SQL-pools in Synapse-werkruimten.

Door de klant beheerde sleutel (CMK) en BYOK (Bring Your Own Key)

In dit artikel worden de termen CMK (Customer Managed Key) en Bring Your Own Key (BYOK) door elkaar gebruikt, maar ze vertegenwoordigen enkele verschillen.

  • Customer Managed Key (CMK) - Je beheert de levenscyclus van de sleutel, inclusief sleutelcreatie, rotatie en verwijdering. Sla de sleutel op in Azure Key Vault of Azure Managed HSM en gebruik deze voor de versleuteling van de Database Encryption Key (DEK).

  • Breng je eigen sleutel mee (BYOK) - Je brengt of importeert veilig je eigen sleutel van een on-premises hardware security module (HSM) naar Azure Key Vault. Dergelijke geïmporteerde sleutels kunnen worden gebruikt als een andere sleutel in Azure Key Vault, inclusief als door de klant beheerde sleutel voor versleuteling van de DEK. Voor meer informatie, zie HSM-beveiligde sleutels importeren in Managed HSM (BYOK).

Voordelen van door de klant beheerde TDE

Klantbeheerde TDE biedt de volgende voordelen:

  • Volledige en gedetailleerde controle over het gebruik en beheer van de TDE-protector.

  • Transparantie van het gebruik van de TDE-beveiliging.

  • Mogelijkheid om scheiding van taken te implementeren in het beheer van sleutels en gegevens binnen de organisatie.

  • De Azure Key Vault-beheerder kan toegangsmachtigingen voor sleutels intrekken om versleutelde databases ontoegankelijk te maken.

  • Centraal beheer van sleutels in Azure Key Vault.

  • Meer vertrouwen van uw eindklanten, omdat Azure Key Vault zodanig is ontworpen dat Microsoft versleutelingssleutels niet kan zien of extraheren.

Important

Voor degenen die service-managed TDE gebruiken en klantbeheerde TDE willen gaan gebruiken, blijft de data versleuteld tijdens het overstappen en is er geen downtime of herversleuteling van de databasebestanden. Voor het overschakelen van een door de service beheerde sleutel naar een door de klant beheerde sleutel is alleen herversleuteling van de DEK vereist. Dit is een snelle en online bewerking.

Rechten om klantbeheerde TDE te configureren in Azure Key Vault

Selecteer het type Azure Key Vault dat u wilt gebruiken.

Zodat de SQL-logische server in Azure de in Azure Key Vault opgeslagen TDE-beschermer kan gebruiken voor de versleuteling van de DEK, moet de Key Vault Administrator de server toegangsrechten verlenen met behulp van diens unieke Microsoft Entra-identiteit. De serveridentiteit kan een door het systeem toegewezen beheerde identiteit of een door de gebruiker toegewezen beheerde identiteit zijn die is toegewezen aan de server. Er zijn twee toegangsmodellen om de server toegang te verlenen tot de sleutelkluis:

  • Op rollen gebaseerd toegangsbeheer van Azure (RBAC): gebruik Azure RBAC om een gebruiker, groep of toepassing toegang te verlenen tot de sleutelkluis. Deze methode wordt aanbevolen voor de flexibiliteit en granulariteit. De serveridentiteit vereist de rol Key Vault Crypto Service Encryption User om de sleutel te gebruiken voor encryptie- en ontsleutelingsoperaties.

  • Toegangsbeleid voor de kluis: gebruik het toegangsbeleid voor de sleutelkluis om de server toegang te verlenen tot de sleutelkluis. Deze methode is eenvoudiger en rechtlijniger, maar minder flexibel. De serveridentiteit heeft de volgende rechten nodig op de sleutelkluis:

    • ophalen - voor het ophalen van het openbare gedeelte en de eigenschappen van de sleutel in de Azure Key Vault
    • wrapKey : om DEK te beveiligen (versleutelen)
    • unwrapKey - om DEK te kunnen ontsleutelen

In het menu Toegangsconfiguratie Azure-portal van de sleutelkluis kunt u Azure-rolgebaseerd toegangsbeheer of Vault-toegangsbeleidselecteren. Voor stapsgewijze instructies voor het instellen van een Azure Key Vault-toegangsconfiguratie voor TDE, zie Set up SQL Server TDE Extensible Key Management met Azure Key Vault. Zie Azure Key Vault-beveiligingvoor meer informatie over de toegangsmodellen.

Een Key Vault-beheerder kan ook logboekregistratie van key vault-controlegebeurtenisseninschakelen, zodat deze later kunnen worden gecontroleerd.

Wanneer je een server configureert om een TDE-protector van Azure Key Vault te gebruiken, stuurt de server de DEK van elke database waarvoor TDE is ingeschakeld naar de key vault voor encryptie. De sleutelkluis geeft de versleutelde DEK terug, die de server opslaat in de gebruikersdatabase.

Wanneer nodig, stuurt de server de beschermde DEK naar de sleutelkluis voor ontsleuteling.

Auditors kunnen Azure Monitor gebruiken om key vault AuditEvent-logs te bekijken als logging is ingeschakeld.

Note

Het kan ongeveer 10 minuten duren voordat eventuele wijzigingen in machtigingen voor de sleutelkluis van kracht worden. Dit omvat het intrekken van toegangsrechten voor de TDE-beschermer in AKV, en gebruikers kunnen nog steeds toegangsrechten hebben.

Vereisten voor het configureren van klantbeheerde TDE in Azure Key Vault

  • Schakel soft-delete en purge protection-functies in op de Azure Key Vault. Deze configuratie helpt om onbedoelde of kwaadwillige verwijdering van de sleutelkluis of sleutel te voorkomen, waardoor de database in de status Niet toegankelijk kan terechtkomen. Wanneer je de TDE-beveiliging configureert op een bestaande server of tijdens het aanmaken van de server, valideert Azure SQL dat de key vault die je gebruikt soft-delete en purge protection heeft ingeschakeld. Als soft delete en beschermend opschonen niet zijn ingeschakeld voor de sleutelkluis, mislukt de installatie van de TDE-beschermer met een fout. In dit geval activeer je soft-delete en purge-bescherming op de key vault, en voer je vervolgens de TDE-protector-installatie uit.

  • Wanneer u een firewall met Azure Key Vault gebruikt, moet u de optie Vertrouwde Microsoft-services toestaan om de firewall te omzeilen, inschakelen, tenzij u privé-eindpunten voor De Azure Key Vault gebruikt. Zie Azure Key Vault-firewalls en virtuele netwerken configurerenvoor meer informatie.

Belangrijke vereisten voor het configureren van TDE-beveiliging

Transparent Data Encryption met door klanten beheerde sleutels gebruikt een externe sleutel, aangeduid als de TDE-beschermer, opgeslagen in Azure Key Vault om de database-encryptiesleutel (DEK) te beschermen.

De volgende vereisten zijn van toepassing.

Ondersteunde sleuteltypen en -grootten

De TDE-beschermer kan worden beveiligd met asymmetrische sleutels die zijn opgeslagen in Azure Key Vault. Ondersteunde sleutelgroottes zijn 2.048-bit en 3.072-bits.

Status van de sleutel en geldigheidsvereisten

  • Als je een sleutelactivatiedatum opgeeft, zet die dan op een datum en tijd in het verleden.
  • Als je een vervaldatum van de sleutel opgeeft, stel die dan in op een datum en tijd in de toekomst.
  • De sleutel moet de status Ingeschakeld hebben.

Belangrijke importvereisten

Als je een bestaande sleutel importeert in Azure Key Vault, geef de sleutel dan in een van de volgende ondersteunde formaten:

  • .pfx
  • .byok
  • .backup

Aanbevelingen voor het configureren van klantbeheerde TDE in Azure Key Vault

Om hoge beschikbaarheid te behouden en throttlingproblemen te voorkomen, volgt u deze richtlijnen per abonnement:

  • Om optimale prestaties en betrouwbaarheid te garanderen, gebruik je een speciale Azure Key Vault voor Azure SQL. Deel deze sleutelkluis niet met andere services. Als de sleutelkluis zwaar belast wordt door gedeeld gebruik of overmatige sleuteloperaties, kan dit de prestaties van de database negatief beïnvloeden, vooral tijdens de toegang tot encryptiesleutels. Azure Key Vault dwingt beperkingslimieten af. Wanneer deze limieten worden overschreden, kunnen bewerkingen worden vertraagd of mislukt. Dit risico is het grootst tijdens serverfailovers, die sleuteloperaties voor elke database op de server activeren.

    Voor meer informatie over throttling-gedrag, zie de throttling-richtlijnen van Azure Key Vault.

    • Het aantal Hyperscale-databases dat je aan één enkele Azure Key Vault kunt koppelen, hangt af van het aantal paginaservers. Elke paginaserver is gekoppeld aan een logisch gegevensbestand. Om het aantal paginaservers te vinden, voer je de volgende zoekopdracht uit.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      Koppel niet meer dan 500 paginaservers aan één Azure Key Vault. Naarmate de database groeit, neemt het aantal paginaservers automatisch toe, dus het is belangrijk om de databasegrootte regelmatig te controleren. Als het aantal paginaservers meer dan 500 bedraagt, gebruik dan een speciale Azure Key Vault voor elke Hyperscale-database en deel die sleutelvault niet met andere Azure SQL-bronnen.

    • Bewaken en configureren van Azure Key Vault-waarschuwingen. Voor meer informatie over monitoring en waarschuwingen, zie Monitor Azure Key Vault en Azure Key Vault-waarschuwingen configureren.

  • Stel een vergrendeling in op de sleutelkluis om te controleren wie deze kritieke resource kan verwijderen en om onbedoeld of ongeautoriseerd verwijderen te voorkomen. Om meer te weten te komen over resource locks.

  • Schakel controle en rapportage in voor alle versleutelingssleutels: Azure Key Vault biedt logboeken die eenvoudig kunnen worden ingevoerd in andere hulpprogramma's voor beveiligingsinformatie en gebeurtenisbeheer. Operations Management Suite Log Analytics- is een voorbeeld van een service die al is geïntegreerd.

  • Gebruik een sleutelkluis uit een Azure-regio die de inhoud kan repliceren naar een gekoppelde Azure-regio voor maximale beschikbaarheid. Zie Aanbevolen procedures voor het gebruik van Azure Key Vault- en beschikbaarheid en redundantie van Azure Key Vaultvoor meer informatie.

Aanbevelingen voor het configureren van TDE-beveiliging

  • Bewaar een kopie van de TDE protector op een veilige locatie of breng deze onder bij een escrowservice.

  • Als je de sleutel genereert in de sleutelkluis, maak dan een sleutelback-up voordat je de sleutel voor het eerst in Azure Key Vault gebruikt. Je kunt de back-up alleen herstellen naar een Azure Key Vault. Voor meer informatie, zie het commando Backup-AzKeyVaultKey. Azure Managed HSM ondersteunt het maken van een volledige back-up van de volledige inhoud van de HSM, inclusief alle sleutels, versies, attributen, tags en roltoewijzingen. Zie Volledige back-up en herstel en selectief sleutelherstel voor meer informatie.

  • Maak een nieuwe back-up aan telkens wanneer je wijzigingen aanbrengt aan de sleutel (bijvoorbeeld sleutelattributen, tags, ACL's).

  • Bewaar eerdere versies van de sleutel in de sleutelkluis of Managed HSM bij het roteren van sleutels, zodat je oudere database-back-ups kunt herstellen. Wanneer de TDE-beschermer verandert voor een database, worden oude back-ups van de database niet bijgewerkt om de nieuwste TDE-beschermer te gebruiken. Tijdens het herstellen heeft elke back-up de TDE-beveiliging nodig waarmee deze tijdens het maken is versleuteld. Om sleutels te roteren, volg de instructies in het artikel Rotate the Transparent data encryption (TDE) protector.

  • Bewaar alle eerder gebruikte sleutels in Azure Key Vault, zelfs nadat je bent overgestapt op service-managed sleutels. Het zorgt ervoor dat database-back-ups kunnen worden hersteld met de TDE-beveiligingen die in Azure Key Vault zijn opgeslagen. TDE-beschermers die met Azure Key Vault zijn gemaakt, moeten worden onderhouden totdat alle resterende opgeslagen back-ups zijn gemaakt met service-managed sleutels. Maak herstelbare back-upkopieën van deze sleutels door gebruik te maken van Backup-AzKeyVaultKey.

  • Als u een mogelijk aangetaste sleutel tijdens een beveiligingsincident wilt verwijderen zonder het risico op gegevensverlies, volgt u de stappen in het artikel Een TDE-beveiliging (Transparent Data Encryption) verwijderen met behulp van PowerShell. Draai altijd naar een nieuwe TDE-beveiliging en controleer of alle databases de nieuwe sleutel gebruiken voordat u de geïnfecteerde sleutel verwijdert of uitschakelt. Het verwijderen of uitschakelen van de sleutel zonder eerst te roteren zorgt ervoor dat alle versleutelde databases ontoegankelijk worden en maakt geen sleutelkopieën ongeldig die eerder zijn geback-upt en teruggezet naar een andere kluis.

Rotatie van TDE-protector

Wanneer je de TDE-beschermer roteert, vervang je de sleutel die de database-encryptiesleutel (DEK) beschermt. Sleutelrotatie is een online bewerking en duurt slechts enkele seconden. Deze operatie ontsleutelt en versleutelt opnieuw alleen de database-encryptiesleutel, niet de hele database.

Je kunt de TDE-beschermer roteren door de configuratie te veranderen zodat je een nieuwe sleutel gebruikt die in Azure Key Vault is opgeslagen. Afhankelijk van het aanbod en de ondersteunde configuratie kan deze sleutel zijn:

  • Overschakelen naar een nieuwe sleutelversie van dezelfde sleutel
  • Overschakelen naar een andere sleutel

De rotatie van de TDE-beschermer kan handmatig worden uitgevoerd of met behulp van de automatische rotatiefunctie.

Je kunt geautomatiseerde rotatie van de TDE-beschermer inschakelen wanneer je de TDE-beschermer voor de server configureert. Automatische rotatie is standaard uitgeschakeld. Wanneer ingeschakeld, controleert de server continu de sleutelkluis op nieuwe versies van de sleutel die als TDE-beschermer wordt gebruikt. Als de server een nieuwe versie van de sleutel detecteert, roteert hij de TDE-protector op de server of database automatisch naar de nieuwste sleutelversie binnen 24 uur.

Note

Wanneer je TDE met CMK instelt door sleutels handmatig of automatisch te roteren, gebruik je altijd de nieuwste versie van de sleutel die het systeem ondersteunt. De installatie staat het gebruik van een eerdere of lagere versie van sleutels niet toe. Door altijd de nieuwste sleutelversie te gebruiken, voldoet u aan het Azure SQL-beveiligingsbeleid, dat eerdere sleutelversies verbiedt die mogelijk gecompromitteerd zijn.

Niet-toegankelijke TDE-beveiliging

Wanneer je TDE configureert om een door de klant beheerde sleutel te gebruiken, heeft de database continue toegang nodig tot de TDE-protector om online te blijven. Als de server de toegang verliest tot de door de klant beheerde TDE-beschermer in Azure Key Vault, begint de database binnen 10 minuten alle verbindingen te weigeren, toont een foutmelding en verandert de status naar Ontoegankelijk. De enige actie die is toegestaan voor een database met de status Niet toegankelijk, is het verwijderen.

Niet-toegankelijke status

Als de database niet toegankelijk is vanwege een onregelmatige netwerkstoring (zoals een 5XX-fout), is er geen actie vereist, omdat de databases automatisch weer online komen. Om het effect van netwerkfouten of -storingen bij het benaderen van de TDE-protector in Azure Key Vault te verminderen, introduceert de dienst een buffer van 24 uur voordat deze probeert de database naar een ontoegankelijke toestand te brengen. Als er een failover plaatsvindt voordat de status Niet toegankelijk wordt bereikt, is de database niet meer beschikbaar vanwege het verlies van de versleutelingscache.

Als de server de toegang verliest tot het door de klant beheerde TDE-beveiligingselement in Azure Key Vault door een fout in Azure Key Vault (zoals een 4XX-fout), schakelt de database na 30 minuten over naar een ontoegankelijke toestand.

Herstel toegang tot de database na een fout in Azure Key Vault

Nadat de toegang tot de sleutel is hersteld, zijn extra tijd en stappen nodig om de database weer online te brengen. Dit kan variëren op basis van de duur van de sleutel die niet beschikbaar is en de grootte van de gegevens in de database.

Als toegang tot sleutels binnen 30 minuten wordt hersteld, wordt de database binnen het volgende uur automatisch hersteld. Als de toegang tot sleutels echter na meer dan 30 minuten wordt hersteld, is automatische herstel van de database niet mogelijk. In dergelijke gevallen omvat het herstellen van de database extra procedures via Azure Portal en kan tijdrovend zijn, afhankelijk van de grootte van de database.

Zodra de database weer online is, zijn eerder geconfigureerde instellingen op serverniveau, waaronder configuraties van failovergroepen, tags en instellingen op databaseniveau, zoals configuraties voor elastische pools, leesschaal, automatisch onderbreken, geschiedenis van herstel naar een bepaald tijdstip, langetermijnretentiebeleid en andere instellingen verloren. Daarom wordt aanbevolen dat klanten binnen 30 minuten een meldingssysteem implementeren om het verlies van toegang tot de versleutelingssleutel te detecteren. Nadat het venster van 30 minuten is verlopen, raden we u aan alle instellingen op server- en databaseniveau voor de herstelde database te valideren.

Hieronder vindt u een weergave van de extra stappen die nodig zijn in de portal om een ontoegankelijke database weer online te brengen.

Onbedoelde intrekking van toegang tot TDE-beveiliging

Het kan gebeuren dat iemand met voldoende toegangsrechten voor de sleutelkluis of beheerde HSM per ongeluk servertoegang tot de sleutel uitschakelt door:

  • het intrekken van de 'get', 'wrapKey', 'unwrapKey' machtigingen van de sleutelkluis of beheerde HSM van de server

  • de sleutel verwijderen

  • Het verwijderen van de sleutelkluis of de beheerde HSM

  • de firewallregels van de sleutelkluis of beheerde HSM wijzigen

  • de beheerde identiteit van de server in Microsoft Entra-id verwijderen

Meer informatie over de veelvoorkomende oorzaken waardoor de database ontoegankelijk wordt.

Geblokkeerde connectiviteit tussen SQL Managed Instance en Azure Key Vault

Het netwerkconnectiviteitsprobleem tussen een SQL Managed Instance en een sleutelkluis of beheerde HSM doet zich meestal voor wanneer de sleutelkluis of beheerde HSM-resource bestaat, maar het eindpunt niet bereikbaar is vanuit de beheerde instantie. Alle scenario's waarin de sleutelkluis of het beheerde HSM-eindpunt kan worden bereikt, maar de verbinding wordt geweigerd, ontbrekende machtigingen, enzovoort, zorgt ervoor dat de databases hun status wijzigen in Ontoegankelijk.

De meest voorkomende oorzaken van het ontbreken van netwerkconnectiviteit met Azure Key Vault zijn:

  • Azure Key Vault wordt blootgesteld via een privé-endpoint en het privé-IP-adres van de Azure Key Vault-service is niet toegestaan in de uitgaande regels van de Network Security Group (NSG) die aan het beheerde instance subnet zijn gekoppeld.

  • Slechte DNS-resolutie, bijvoorbeeld wanneer de sleutelkluis of beheerde HSM-FQDN niet wordt opgelost of wordt opgelost naar een ongeldig IP-adres.

Test de connectiviteit van SQL Managed Instance naar de Azure Key Vault die de TDE-beschermer host.

  • Het eindpunt is uw kluis-FQDN, bijvoorbeeld <vault_name>.vault.azure.net (zonder de https://).
  • De te testen poort is 443.
  • Het resultaat voor RemoteAddress moet bestaan en het juiste IP-adres zijn
  • Het resultaat voor TCP-test moet TcpTestSucceeded: True zijn.

Als de test TcpTestSucceeded: Falseretourneert, controleert u de netwerkconfiguratie:

  • Controleer het opgeloste IP-adres en bevestig dat het geldig is. Een ontbrekende waarde betekent dat er problemen zijn met DNS-omzetting.

    • Controleer of de netwerkbeveiligingsgroep in het beheerde exemplaar een uitgaande regel heeft die het opgeloste IP-adres op poort 443 behandelt, met name wanneer het opgeloste adres deel uitmaakt van het privé-eindpunt van de sleutelkluis of het beheerde HSM-privé-eindpunt.

    • Controleer andere netwerkconfiguraties, zoals routetabel, het bestaan van een virtueel apparaat en de configuratie, enzovoort.

De door de klant beheerde TDE bewaken

Als u de databasestatus wilt bewaken en waarschuwingen wilt inschakelen voor verlies van toegang tot TDE-beveiliging, configureert u de volgende Azure-functies:

  • Azure Resource Health-. Een ontoegankelijke database die de toegang tot de TDE-beschermer heeft verloren, wordt als "Niet beschikbaar" weergegeven nadat een eerste verbindingspoging met de database is geweigerd.

  • activiteitenlogboek wanneer toegang tot de TDE-beveiliging in de door de klant beheerde sleutelkluis mislukt, worden vermeldingen toegevoegd aan het activiteitenlogboek. Door alerts voor deze gebeurtenissen te maken, kunt u de toegang zo snel mogelijk herstellen.

  • Actiegroepen kunnen worden gedefinieerd om je meldingen en meldingen te sturen op basis van je voorkeuren, bijvoorbeeld e-mail, sms, push, spraak, logica-app, webhook, ITSM of automatiseringsrunbook.

databaseback-up en herstel met door de klant beheerde TDE

Zodra een database is versleuteld met TDE met een sleutel van 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.

Om een back-up te herstellen die versleuteld is met een TDE-beveiliging van Azure Key Vault, zorg ervoor dat het sleutelmateriaal beschikbaar is voor de doelserver. Houd daarom alle oude versies van de TDE-beschermer in key vault of managed HSM, zodat database-back-ups kunnen worden hersteld.

Important

Er kan op elk moment niet meer dan één TDE-protector voor een server zijn ingesteld. De sleutel die is gemarkeerd met De sleutel als standaard-TDE-beschermer instellen in het Azure-portalvenster, is de TDE-beschermer. Meerdere sleutels kunnen echter worden gekoppeld aan een server zonder ze te markeren als een TDE-beveiliging. Deze sleutels worden niet gebruikt om de DEK te beschermen, maar kunnen tijdens het herstellen van een back-up worden gebruikt als het back-upbestand is versleuteld met de sleutel met de bijbehorende duimafdruk.

Als de sleutel die nodig is voor het herstellen van een back-up niet meer beschikbaar is voor de doelserver, wordt het volgende foutbericht geretourneerd bij het herstellen: 'Doelserver <Servername> heeft geen toegang tot alle AKV-URI's die zijn gemaakt tussen <timestamp #1> en <tijdstempel #2>. Voer de bewerking opnieuw uit na het herstellen van alle AKV-URI's."

Als u dit wilt verhelpen, voert u de Get-AzSqlServerKeyVaultKey cmdlet uit voor de doelserver of Get-AzSqlInstanceKeyVaultKey voor het beheerde doelexemplaren om de lijst met beschikbare sleutels te retourneren en de ontbrekende sleutels te identificeren. Om ervoor te zorgen dat alle back-ups kunnen worden hersteld, moet u ervoor zorgen dat de doelserver voor het herstellen toegang heeft tot alle sleutels die nodig zijn. Deze sleutels hoeven niet te worden gemarkeerd als TDE-beveiliging.

Voor meer informatie over het herstellen van een back-up voor toegewezen SQL-pools in Azure Synapse Analytics, zie Een toegewezen SQL-pool herstellen.

Een andere overweging voor logboekbestanden: back-ups van logboekbestanden blijven versleuteld met de oorspronkelijke TDE-beveiliging, zelfs als deze is gedraaid en de database nu een nieuwe TDE-beveiliging gebruikt. Op het moment van herstel zijn beide sleutels nodig om de database te herstellen. Als het logbestand een TDE-beveiliging gebruikt die is opgeslagen in Azure Key Vault, is deze sleutel nodig bij het herstellen, zelfs als de database in de tussentijd is gewijzigd om service-managed TDE te gebruiken.

Hoge beschikbaarheid met door de klant beheerde TDE

Door gebruik te maken van de meerdere lagen redundantie van Azure Key Vault, kunnen TDE's die een door klanten beheerde sleutel gebruiken profiteren van de beschikbaarheid en veerkracht van Azure Key Vault. Ze kunnen volledig vertrouwen op de redundantieoplossing van Azure Key Vault.

De meerdere redundantielagen van Azure Key Vault zorgen voor sleuteltoegang, zelfs als individuele servicecomponenten falen of Azure-regio's of beschikbaarheidszones offline zijn. Zie Azure Key Vault beschikbaarheid en redundantie voor meer informatie.

Azure Key Vault biedt automatisch de volgende componenten van beschikbaarheid en veerkracht zonder tussenkomst van de gebruiker:

Verwante onderwerpen

  • Laatst bijgewerkt om