Azure SQL Transparent Data Encryption met door de klant beheerde sleutels

Van toepassing op: Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics (alleen toegewezen SQL-pools)

Azure SQL Transparent Data Encryption (TDE) met door de klant beheerde sleutel (CMK) maakt BYOK-scenario (Bring Your Own Key) mogelijk voor data protection at rest en stelt organisaties in staat om scheiding van taken in het beheer van sleutels en gegevens te implementeren. Met door de klant beheerde TDE is de klant verantwoordelijk voor en heeft volledige controle over het levenscyclusbeheer van sleutels (het maken, uploaden, roteren, verwijderen van sleutels), machtigingen voor sleutelgebruik en het controleren van bewerkingen op sleutels.

In dit scenario is de sleutel die wordt gebruikt voor versleuteling van de Database Encryption Key (DEK), TDE-beveiliging genoemd, een door de klant beheerde asymmetrische sleutel die is opgeslagen in een door de klant beheerde Azure Key Vault (AKV), een extern sleutelbeheersysteem in de cloud. Key Vault is maximaal beschikbare en schaalbare veilige opslag voor cryptografische RSA-sleutels, optioneel ondersteund door FIPS 140-2 Level 2 gevalideerde hardwarebeveiligingsmodules (HSM's). Het biedt geen directe toegang tot een opgeslagen sleutel, maar biedt services van versleuteling/ontsleuteling met behulp van de sleutel voor de geautoriseerde entiteiten. De sleutel kan worden gegenereerd door de sleutelkluis, geïmporteerd of overgebracht naar de sleutelkluis vanaf een on-premises HSM-apparaat.

Voor Azure SQL Database en Azure Synapse Analytics wordt de TDE-beveiliging ingesteld op serverniveau en wordt deze overgenomen door alle versleutelde databases die aan die server zijn gekoppeld. Voor Azure SQL Managed Instance wordt de TDE-beveiliging ingesteld op exemplaarniveau en wordt deze overgenomen door alle versleutelde databases op dat exemplaar. De term server verwijst zowel naar een server in SQL Database als Azure Synapse en naar een beheerd exemplaar in SQL Managed Instance in dit document, tenzij anders vermeld.

Het beheren van de TDE-beveiliging op databaseniveau in Azure SQL Database is beschikbaar. Zie TDE (Transparent Data Encryption) met door de klant beheerde sleutels op databaseniveau voor meer informatie.

Notitie

• Dit artikel is van toepassing op Azure SQL Database, Azure SQL Managed Instance en Azure Synapse Analytics (toegewezen SQL-pools (voorheen SQL DW)). Zie Azure Synapse Analytics-versleuteling voor documentatie over transparante gegevensversleuteling voor toegewezen SQL-pools in Synapse-werkruimten.
• Om Azure SQL-klanten twee lagen versleuteling van data-at-rest te bieden, wordt infrastructuurversleuteling (met behulp van AES-256-versleutelingsalgoritmen) geïmplementeerd met door platform beheerde sleutels. Dit biedt een extra versleutelingslaag in rust, samen met TDE met door de klant beheerde sleutels, die al beschikbaar is. Voor Azure SQL Database en Azure SQL Managed Instance worden alle databases, inclusief de master database en andere systeemdatabases, versleuteld wanneer infrastructuurversleuteling is ingeschakeld. Op dit moment moeten klanten toegang tot deze mogelijkheid aanvragen. Als u geïnteresseerd bent in deze mogelijkheid, neemt u contact op met AzureSQLDoubleEncryptionAtRest@service.microsoft.com.

Notitie

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

Voordelen van door de klant beheerde TDE

Door de klant beheerde TDE biedt de volgende voordelen voor de klant:

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

• Transparantie van het TDE-protectorgebruik;

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

• Key Vault-beheerder kan toegangsmachtigingen voor sleutels intrekken om versleutelde database ontoegankelijk te maken;

• Centraal beheer van sleutels in AKV;

• Meer vertrouwen van uw eindklanten, omdat AKV zodanig is ontworpen dat Microsoft geen versleutelingssleutels kan zien of extraheren;

Belangrijk

Voor degenen die gebruikmaken van door de service beheerde TDE die door de klant beheerde TDE willen gaan gebruiken, blijven gegevens versleuteld tijdens het overschakelen en vindt er geen downtime of herversleuteling van de databasebestanden plaats. 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 onlinebewerking.

Hoe door de klant beheerde TDE werkt

Om ervoor te zorgen dat de logische server in Azure de TDE-protector gebruikt die is opgeslagen in AKV voor versleuteling van de DEK, moet de key vault-beheerder de volgende toegangsrechten voor de server verlenen met behulp van de unieke Microsoft Entra-identiteit:

• ophalen : voor het ophalen van het openbare deel en de eigenschappen van de sleutel in de Sleutelkluis

• wrapKey : om DEK te beveiligen (versleutelen)

• unwrapKey - om de beveiliging (ontsleuteling) DEK op te heffen

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

Wanneer de server is geconfigureerd voor het gebruik van een TDE-beveiliging van AKV, verzendt de server de DEK van elke TDE-database naar de sleutelkluis voor versleuteling. Key Vault retourneert de versleutelde DEK, die vervolgens wordt opgeslagen in de gebruikersdatabase.

Indien nodig verzendt de server beveiligde DEK naar de sleutelkluis voor ontsleuteling.

Auditors kunnen Azure Monitor gebruiken om key vault AuditEvent-logboeken te controleren als logboekregistratie is ingeschakeld.

Notitie

Het kan ongeveer 10 minuten duren voordat wijzigingen in de machtigingen van kracht worden voor de sleutelkluis. Dit omvat het intrekken van toegangsmachtigingen voor de TDE-beveiliging in AKV en gebruikers binnen dit tijdsbestek hebben mogelijk nog steeds toegangsmachtigingen.

Vereisten voor het configureren van door de klant beheerde TDE

Vereisten voor het configureren van AKV

• Beveiligingsfuncties voor voorlopig verwijderen en opschonen moeten zijn ingeschakeld voor de sleutelkluis om te beschermen tegen gegevensverlies vanwege onbedoelde verwijdering van sleutels (of sleutelkluis).

• Verdeel de server of het beheerde exemplaar toegang tot de sleutelkluis (get, wrapKey, unwrapKey) met behulp van de 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. Wanneer u de Azure Portal gebruikt, wordt de Microsoft Entra-identiteit automatisch gemaakt wanneer de server wordt gemaakt. Wanneer u PowerShell of Azure CLI gebruikt, moet de Microsoft Entra-identiteit expliciet worden gemaakt en moet deze worden geverifieerd. Zie TDE configureren met BYOK en TDE configureren met BYOK voor SQL Managed Instance voor gedetailleerde stapsgewijze instructies bij het gebruik van PowerShell.

  • 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 met de rol Versleutelingsgebruiker van de Key Vault-versleutelingsservice.

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

Beveiliging tegen voorlopig verwijderen en opschonen inschakelen voor AKV

Belangrijk

Zowel voorlopig verwijderen als beveiliging tegen opschonen moet zijn ingeschakeld in de sleutelkluis bij het configureren van door de klant beheerde TDE op een nieuwe of bestaande server of een beheerd exemplaar.

Voorlopig verwijderen en opschonen zijn belangrijke functies van Azure Key Vault die herstel van verwijderde kluizen en verwijderde sleutelkluisobjecten mogelijk maken, waardoor het risico van een gebruiker per ongeluk of kwaadwillig verwijderen van een sleutel of een sleutelkluis wordt beperkt.

• Voorlopig verwijderde resources worden 90 dagen bewaard, tenzij ze zijn hersteld of verwijderd door de klant. Aan de acties herstellen en opschonen zijn aparte machtigingen gekoppeld in het toegangsbeleid van een sleutelkluis. De functie voor voorlopig verwijderen is standaard ingeschakeld voor nieuwe sleutelkluizen en kan ook worden ingeschakeld met behulp van Azure Portal, PowerShell of Azure CLI.

• Beveiliging tegen opschonen kan worden ingeschakeld met behulp van Azure CLI of PowerShell. Als bescherming tegen opschonen is ingeschakeld, kan een kluis of een object met de status Verwijderd pas worden opgeschoond als de bewaartermijn is verstreken. De standaardretentieperiode is 90 dagen, maar kan worden geconfigureerd van 7 tot 90 dagen via Azure Portal.

• Voor Azure SQL moet beveiliging tegen voorlopig verwijderen en leegmaken zijn ingeschakeld in de sleutelkluis met de versleutelingssleutel die wordt gebruikt als de TDE-beveiliging voor de server of het beheerde exemplaar. Dit helpt voorkomen dat het scenario van onbedoelde of schadelijke sleutelkluis of sleutelverwijdering die ertoe kan leiden dat de database de status Niet toegankelijk krijgt.

• Wanneer u de TDE-beveiliging configureert op een bestaande server of tijdens het maken van de server, valideert Azure SQL dat de sleutelkluis die wordt gebruikt, voorlopig verwijderen en opschonen is ingeschakeld. Als voorlopig verwijderen en opschonen niet is ingeschakeld voor de sleutelkluis, mislukt de installatie van de TDE-protector met een fout. In dit geval moet beveiliging tegen voorlopig verwijderen en opschonen eerst worden ingeschakeld in de sleutelkluis en moet vervolgens de TDE-beveiliging worden uitgevoerd.

Vereisten voor het configureren van TDE-beveiliging

• TDE-beveiliging kan alleen een asymmetrische, RSA- of RSA-HSM-sleutel zijn. De ondersteunde sleutellengten zijn 2048 bits en 3072 bits.

• De activeringsdatum van de sleutel (indien ingesteld) moet een datum en tijdstip in het verleden zijn. Vervaldatum (indien ingesteld) moet een toekomstige datum en tijd zijn.

• De sleutel moet de status Ingeschakeld hebben.

• Als u een bestaande sleutel in de sleutelkluis importeert, moet u deze opgeven in de ondersteunde bestandsindelingen (.pfx, .byokof .backup).

Notitie

Azure SQL biedt nu ondersteuning voor het gebruik van een RSA-sleutel die is opgeslagen in een beheerde HSM als TDE-beveiliging. Azure Key Vault Managed HSM is een cloudservice van hoge beschikbaarheid en één tenant, die volledig beheerd is en aan de standaarden voldoet. Met deze cloudservice kunt u cryptografische sleutels voor uw cloudtoepassingen waarborgen met behulp van met FIPS 140-2 Level 3 gevalideerde HSM's. Meer informatie over beheerde HSM's.

Notitie

Een probleem met Thales CipherTrust Manager-versies vóór v2.8.0 voorkomt dat sleutels die nieuw zijn geïmporteerd in Azure Key Vault, worden gebruikt met Azure SQL Database of Azure SQL Managed Instance voor door de klant beheerde TDE-scenario's. Meer informatie over dit probleem vindt u hier. Wacht voor dergelijke gevallen 24 uur nadat u de sleutel in de sleutelkluis hebt geïmporteerd om deze te gebruiken als TDE-beveiliging voor de server of het beheerde exemplaar. Dit probleem is opgelost in Thales CipherTrust Manager v2.8.0.

Aanbevelingen bij het configureren van de door klant beheerde TDE

Aanbevelingen bij het configureren van AKV

• Koppel in totaal maximaal 500 algemene of 200 Bedrijfskritiek databases aan een sleutelkluis in één abonnement om hoge beschikbaarheid te garanderen wanneer de server toegang heeft tot de TDE-beveiliging in de sleutelkluis. Deze cijfers zijn gebaseerd op de ervaring en gedocumenteerd in de servicelimieten van de sleutelkluis. Het doel hiervan is om problemen na een serverfailover te voorkomen, omdat er zoveel belangrijke bewerkingen worden geactiveerd voor de kluis als er databases op die server zijn.

• Stel een resourcevergrendeling in voor de sleutelkluis om te bepalen wie deze kritieke resource kan verwijderen en onbedoelde of niet-geautoriseerde verwijdering kan voorkomen. Meer informatie over resourcevergrendelingen.

• Schakel controle en rapportage in voor alle versleutelingssleutels: 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.

• Koppel elke server aan twee sleutelkluizen die zich in verschillende regio's bevinden en hetzelfde sleutelmateriaal bevatten om een hoge beschikbaarheid van versleutelde databases te garanderen. Markeer de sleutel uit een van de sleutelkluizen als de TDE-beveiliging. Het systeem schakelt automatisch over naar de sleutelkluis in de tweede regio met hetzelfde sleutelmateriaal als er een storing optreedt die van invloed is op de sleutelkluis in de eerste regio.

Notitie

Als u meer flexibiliteit wilt bieden bij het configureren van door de klant beheerde TDE, kunnen Azure SQL Database en Azure SQL Managed Instance in één regio nu worden gekoppeld aan de sleutelkluis in een andere regio. De server en de sleutelkluis hoeven zich niet in dezelfde regio te bevinden.

Aanbevelingen bij het configureren van de TDE-beveiliging

• Bewaar een kopie van de TDE-protector op een veilige plaats of borg deze aan de borgservice.

• Als de sleutel wordt gegenereerd in de sleutelkluis, maakt u een sleutelback-up voordat u de sleutel in AKV voor het eerst gebruikt. Back-up kan alleen worden hersteld naar een Azure Key Vault. Meer informatie over de opdracht Backup-AzKeyVaultKey .

• Maak een nieuwe back-up wanneer er wijzigingen in de sleutel worden aangebracht (bijvoorbeeld sleutelkenmerken, tags, ACL's).

• Houd eerdere versies van de sleutel in de sleutelkluis bij het roteren van sleutels, zodat oudere databaseback-ups kunnen worden hersteld. Wanneer de TDE-beveiliging voor een database wordt gewijzigd, worden oude back-ups van de database niet bijgewerkt om de nieuwste TDE-beveiliging te gebruiken. Tijdens het herstellen heeft elke back-up de TDE-beveiliging nodig waarmee deze tijdens het maken is versleuteld. Sleutelrotaties kunnen worden uitgevoerd volgens de instructies bij Transparent Data Encryption Protector Draaien met Behulp van PowerShell.

• Bewaar alle eerder gebruikte sleutels in AKV, zelfs nadat u bent overgeschakeld naar door de service beheerde sleutels. Dit zorgt ervoor dat databaseback-ups kunnen worden hersteld met de TDE-beveiligingen die zijn opgeslagen in AKV. TDE-beveiligingen die zijn gemaakt met Azure Key Vault moeten worden onderhouden totdat alle resterende opgeslagen back-ups zijn gemaakt met door de service beheerde sleutels. Maak herstelbare back-ups van deze sleutels met behulp van Backup-AzKeyVaultKey.

• Als u een mogelijk aangetaste sleutel tijdens een beveiligingsincident wilt verwijderen zonder het risico op gegevensverlies, volgt u de stappen uit de optie Een mogelijk aangetaste sleutel verwijderen.

Rotatie van TDE-protector

Als u de TDE-beveiliging voor een server roteert, moet u overschakelen naar een nieuwe asymmetrische sleutel die de databases op de server beveiligt. Sleutelrotatie is een onlinebewerking en duurt slechts enkele seconden. De bewerking ontsleutelt alleen en versleutelt de databaseversleutelingssleutel opnieuw, niet de hele database.

Het roteren van de TDE-protector kan handmatig worden uitgevoerd of met behulp van de functie voor geautomatiseerde rotatie.

Automatische rotatie van de TDE-protector kan worden ingeschakeld bij het configureren van de TDE-beveiliging voor de server. Automatische rotatie is standaard uitgeschakeld. Wanneer deze optie is ingeschakeld, controleert de server continu de sleutelkluis op nieuwe versies van de sleutel die worden gebruikt als de TDE-beveiliging. Als er een nieuwe versie van de sleutel wordt gedetecteerd, wordt de TDE-beveiliging op de server binnen 60 minuten automatisch geroteerd naar de nieuwste sleutelversie.

Wanneer deze functie wordt gebruikt met geautomatiseerde sleutelrotatie in Azure Key Vault, maakt deze functie end-to-end zero touch-rotatie mogelijk voor de TDE-beveiliging in Azure SQL Database en Azure SQL Managed Instance.

Notitie

Als u TDE instelt met CMK met behulp van handmatige of geautomatiseerde rotatie van sleutels, wordt altijd de nieuwste versie van de sleutel gebruikt die wordt ondersteund. De installatie staat het gebruik van een eerdere of lagere versie van sleutels niet toe. Altijd het gebruik van de meest recente sleutelversie voldoet aan het Azure SQL-beveiligingsbeleid waarmee eerdere sleutelversies die mogelijk worden aangetast, niet worden toegeraakt. De vorige versies van de sleutel zijn mogelijk nodig voor back-up- of hersteldoeleinden van de database, met name in het geval van langetermijnretentieback-ups, waarbij de oudere sleutelversies moeten worden bewaard. Voor geo-replicatie-instellingen moeten alle sleutels die vereist zijn voor de bronserver aanwezig zijn op de doelserver.

Overwegingen voor geo-replicatie bij het configureren van geautomatiseerde rotatie van de TDE-protector

Als u problemen wilt voorkomen tijdens het tot stand brengen of tijdens geo-replicatie, is het belangrijk dat u deze regels volgt bij het configureren van geo-replicatie wanneer automatische rotatie van de TDE-beveiliging is ingeschakeld op de primaire of secundaire server:

• Zowel de primaire als de secundaire servers moeten beschikken over get-, wrapKey - en unwrapKey-machtigingen voor de sleutelkluis van de primaire server (sleutelkluis met de TDE-beveiligingssleutel van de primaire server).

• Voor een server waarvoor automatische sleutelrotatie is ingeschakeld, voegt u voordat geo-replicatie wordt gestart, de versleutelingssleutel toe die wordt gebruikt als TDE-beveiliging op de primaire server aan de secundaire server. De secundaire server vereist toegang tot de sleutel in dezelfde sleutelkluis die wordt gebruikt met de primaire server (en niet een andere sleutel met hetzelfde sleutelmateriaal). Voordat u geo-replicatie start, moet u er ook voor zorgen dat de beheerde identiteit van de secundaire server (door de gebruiker toegewezen of door het systeem toegewezen) vereiste machtigingen heeft voor de sleutelkluis van de primaire server en dat het systeem probeert de sleutel toe te voegen aan de secundaire server.

• Voor een bestaande geo-replicatie-instelling voegt u vóór het inschakelen van automatische sleutelrotatie op de primaire server de versleutelingssleutel toe die wordt gebruikt als TDE-beveiliging op de primaire server aan de secundaire server. De secundaire server vereist toegang tot de sleutel in dezelfde sleutelkluis die wordt gebruikt met de primaire server (en niet een andere sleutel met hetzelfde sleutelmateriaal). Voordat u automatische sleutel inschakelt, moet u er ook voor zorgen dat de beheerde identiteit van de secundaire server (door de gebruiker toegewezen of door het systeem toegewezen) vereiste machtigingen heeft voor de sleutelkluis van de primaire server en probeert het systeem de sleutel toe te voegen aan de secundaire server.

• Scenario's voor geo-replicatie met door de klant beheerde sleutels (CMK) voor TDE worden ondersteund. TDE met automatische sleutelrotatie moet worden geconfigureerd op alle servers als u TDE configureert in Azure Portal. Zie Automatische sleutelrotatie voor geo-replicatieconfiguraties met TDE voor meer informatie over het instellen van automatische sleutelrotatie voor geo-replicatieconfiguraties.

Niet-toegankelijke TDE-beveiliging

Wanneer TDE is geconfigureerd voor het gebruik van een door de klant beheerde sleutel, is voortdurende toegang tot de TDE-beveiliging vereist zodat de database online kan blijven. Als de server geen toegang meer heeft tot de door de klant beheerde TDE-beveiliging in AKV, wordt in maximaal 10 minuten een database gestart met het weigeren van alle verbindingen met het bijbehorende foutbericht en wordt de status gewijzigd in Ontoegankelijk. De enige actie die is toegestaan voor een database met de status Niet toegankelijk, is het verwijderen.

Notitie

Als de database niet toegankelijk is vanwege een onregelmatige netwerkstoring, is er geen actie vereist en worden de databases automatisch weer online gezet.

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 tijd die is verstreken zonder toegang tot de sleutel en de grootte van de gegevens in de database:

Notitie

• Als toegang tot sleutels binnen 30 minuten wordt hersteld, wordt de database binnen het volgende uur automatisch geheald.
• Als toegang tot sleutels na meer dan 30 minuten is hersteld, is automatischheal van de database niet mogelijk. Het terugbrengen van de database vereist extra stappen in Azure Portal en kan een aanzienlijke hoeveelheid tijd in beslag nemen, afhankelijk van de grootte van de database.
• Zodra de database weer online is, zijn eerder geconfigureerde instellingen op serverniveau met configuratie van failovergroepen , tags en instellingen op databaseniveau, zoals configuratie van elastische pools, leesschaal, automatisch onderbreken, geschiedenis van herstel naar een bepaald tijdstip, langetermijnretentiebeleid en andere instellingen verloren. Daarom wordt het aanbevolen dat klanten binnen 30 minuten een meldingssysteem implementeren dat verlies van toegang tot de versleutelingssleutel identificeert. Zodra het venster van 30 minuten is verlopen, raden we u aan alle instellingen op server- en databaseniveau voor de herstelde database te valideren.

Hieronder ziet u een weergave van de extra stappen die nodig zijn voor 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 per ongeluk servertoegang tot de sleutel uitschakelt door:

• het ophalen, verpakken, uitpakken van machtigingen van de sleutelkluis van de server intrekken

• de sleutel verwijderen

• De sleutelkluis verwijderen

• de firewallregels van de sleutelkluis wijzigen

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

Meer informatie over de veelvoorkomende oorzaken voor het ontoegankelijk worden van de database.

Geblokkeerde connectiviteit tussen SQL Managed Instance en Key Vault

In SQL Managed Instance kunnen netwerkfouten tijdens het openen van de TDE-beveiliging in Azure Key Vault ertoe leiden dat de databases de status niet kunnen wijzigen in Ontoegankelijk , maar dat het exemplaar daarna niet beschikbaar is. Dit gebeurt meestal wanneer de sleutelkluisresource bestaat, maar het eindpunt ervan niet kan worden bereikt vanuit het beheerde exemplaar. Alle scenario's waarin het eindpunt van de sleutelkluis kan worden bereikt, maar de verbinding wordt geweigerd, ontbrekende machtigingen, enzovoort, zorgt ervoor dat de databases de status ervan wijzigen in Ontoegankelijk.

De meest voorkomende oorzaken voor het ontbreken van netwerkverbinding met Key Vault zijn:

• Key Vault wordt weergegeven via een privé-eindpunt en het privé-IP-adres van de AKV-service is niet toegestaan in de uitgaande regels van de netwerkbeveiligingsgroep (NSG) die zijn gekoppeld aan het subnet van het beheerde exemplaar.
• Ongeldige DNS-omzetting, bijvoorbeeld wanneer de FQDN van de sleutelkluis niet is omgezet of omgezet in een ongeldig IP-adres.

Test de connectiviteit van SQL Managed Instance met de Key Vault die als host fungeert voor de TDE-beveiliging.

• Het eindpunt is uw kluis-FQDN, zoals <vault_name.vault.azure.net> (zonder de https://).
• De poort die moet worden getest, 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 retourneert: Onwaar, 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 omvat, met name wanneer het opgeloste adres deel uitmaakt van het privé-eindpunt van de sleutelkluis.
  • Controleer andere netwerkconfiguraties, zoals routetabel, het bestaan van een virtueel apparaat en de configuratie, enzovoort.

Bewaking van door de klant beheerde TDE

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 niet-toegankelijke database die geen toegang meer heeft tot de TDE-beveiliging, wordt weergegeven als 'Niet beschikbaar' nadat de eerste verbinding 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 waarschuwingen voor deze gebeurtenissen te maken, kunt u de toegang zo snel mogelijk herstellen.
• Actiegroepen kunnen worden gedefinieerd om u meldingen en waarschuwingen te sturen op basis van uw voorkeuren, bijvoorbeeld e-mail/sms/push/spraak, logische app, webhook, ITSM of Automation Runbook.

Back-up en herstel van SQL Database met door de klant beheerde TDE

Zodra een database is versleuteld met TDE met behulp van een sleutel uit 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-beveiliging van Key Vault, moet u ervoor zorgen dat het sleutelmateriaal beschikbaar is voor de doelserver. Daarom wordt u aangeraden alle oude versies van de TDE-protector in de sleutelkluis te bewaren, zodat back-ups van de database kunnen worden hersteld.

Belangrijk

Op elk moment kan er niet meer dan één TDE-protector zijn ingesteld voor een server. Dit is de sleutel die is gemarkeerd met 'De sleutel de standaard-TDE-beveiliging maken' in de azure-portalblade. Er kunnen echter meerdere extra sleutels aan een server worden gekoppeld zonder ze te markeren als een TDE-beveiliging. Deze sleutels worden niet gebruikt voor het beveiligen van DEK, maar kunnen worden gebruikt tijdens het herstellen vanaf een back-up, als het back-upbestand is versleuteld met de sleutel met de bijbehorende vingerafdruk.

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 <Timestamp #2>. Voer de bewerking opnieuw uit na het herstellen van alle AKV-URI's.

U kunt dit verhelpen door de cmdlet Get-AzSqlServerKeyVaultKey voor de doelserver of Get-AzSqlInstanceKeyVaultKey uit te voeren 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.

Zie Een database herstellen in SQL Database voor meer informatie over back-upherstel voor SQL Database. Zie Een toegewezen SQL-pool herstellen voor meer informatie over back-upherstel voor toegewezen SQL-pools in Azure Synapse Analytics. Voor systeemeigen back-up/herstel van SQL Server met SQL Managed Instance raadpleegt u quickstart: Een database herstellen naar SQL Managed Instance.

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 logboekbestand een TDE-beveiliging gebruikt die is opgeslagen in Azure Key Vault, is deze sleutel nodig tijdens het herstellen, zelfs als de database is gewijzigd om in de tussentijd door de service beheerde TDE te gebruiken.

Hoge beschikbaarheid met door de klant beheerde TDE

Zelfs als er geen geconfigureerde georedundantie voor de server is geconfigureerd, is het raadzaam om de server te configureren voor het gebruik van twee verschillende sleutelkluizen in twee verschillende regio's met hetzelfde sleutelmateriaal. De sleutel in de secundaire sleutelkluis in de andere regio mag niet worden gemarkeerd als TDE-beveiliging en is zelfs niet toegestaan. Als er een storing optreedt die van invloed is op de primaire sleutelkluis en alleen dan schakelt het systeem automatisch over naar de andere gekoppelde sleutel met dezelfde vingerafdruk in de secundaire sleutelkluis, als deze bestaat. Houd er rekening mee dat de schakeloptie niet plaatsvindt als de TDE-beveiliging niet toegankelijk is vanwege ingetrokken toegangsrechten of omdat de sleutel of sleutelkluis wordt verwijderd, omdat de klant mogelijk aangeeft dat de server opzettelijk de toegang tot de sleutel wil beperken. U kunt hetzelfde sleutelmateriaal opgeven voor twee sleutelkluizen in verschillende regio's door de sleutel buiten de sleutelkluis te maken en ze in beide sleutelkluizen te importeren.

U kunt dit ook doen door sleutel te genereren met behulp van de primaire sleutelkluis in één regio en de sleutel te klonen in een sleutelkluis in een andere Azure-regio. Gebruik de cmdlet Backup-AzKeyVaultKey om de sleutel in versleutelde indeling op te halen uit de primaire sleutelkluis en gebruik vervolgens de cmdlet Restore-AzKeyVaultKey en geef een sleutelkluis op in de tweede regio om de sleutel te klonen. U kunt ook Azure Portal gebruiken om een back-up te maken van de sleutel en deze te herstellen. Sleutelback-up-/herstelbewerking is alleen toegestaan tussen sleutelkluizen binnen hetzelfde Azure-abonnement en azure-geografie.

Geo-DR en door de klant beheerde TDE

In zowel actieve scenario's voor geo-replicatie als failovergroepen kunnen de betrokken primaire en secundaire servers 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-secundair synchroon is en dezelfde sleutel kan overnemen van de gekoppelde sleutelkluis als de primaire ontoegankelijk wordt vanwege een storing in de regio en een failover wordt geactiveerd. Maximaal vier secundaire databases kunnen worden geconfigureerd en het koppelen (secundaire bestanden van secundaire bestanden) wordt niet ondersteund.

Om problemen te voorkomen bij het tot stand brengen of tijdens geo-replicatie vanwege onvolledig sleutelmateriaal, is het belangrijk om deze regels te volgen bij het configureren van door de klant beheerde TDE (als er afzonderlijke sleutelkluizen worden gebruikt voor de primaire en secundaire servers):

• Alle betrokken sleutelkluizen moeten dezelfde eigenschappen en dezelfde toegangsrechten hebben voor de respectieve servers.

• Alle betrokken sleutelkluizen moeten identiek sleutelmateriaal bevatten. Het is niet alleen van toepassing op de huidige TDE-beveiliging, maar op alle eerdere TDE-beveiligingen die kunnen worden gebruikt in de back-upbestanden.

• Zowel de eerste installatie als de rotatie van de TDE-protector moeten eerst op de secundaire en vervolgens op de primaire worden uitgevoerd.

Als u een failover wilt testen, volgt u de stappen in het overzicht van actieve geo-replicatie. Testfailover moet regelmatig worden uitgevoerd om te controleren of SQL Database toegangsmachtigingen heeft onderhouden voor beide sleutelkluizen.

Azure SQL Database-server en SQL Managed Instance in één regio kunnen nu worden gekoppeld aan de sleutelkluis in elke andere regio. De server en de sleutelkluis hoeven zich niet samen in dezelfde regio te bevinden. Om het eenvoudig te houden, kunnen de primaire en secundaire servers worden verbonden met dezelfde sleutelkluis (in elke regio). Dit helpt scenario's te voorkomen waarbij sleutelmateriaal mogelijk niet synchroon is als er afzonderlijke sleutelkluizen worden gebruikt voor beide servers. Azure Key Vault beschikt over meerdere redundantielagen om ervoor te zorgen dat uw sleutels en sleutelkluizen beschikbaar blijven in geval van service- of regiofouten. Beschikbaarheid en redundantie van Azure Key Vault

Azure Policy voor door de klant beheerde TDE

Azure Policy kan worden gebruikt om door de klant beheerde TDE af te dwingen tijdens het maken of bijwerken van een Azure SQL Database-server of Azure SQL Managed Instance. Als dit beleid is ingesteld, mislukken pogingen om een logische server in Azure of een beheerd exemplaar te maken of bij te werken als deze niet is geconfigureerd met een door de klant beheerde sleutel. Het Azure Policy kan worden toegepast op het hele Azure-abonnement of alleen binnen een resourcegroep.

Zie Wat is Azure Policy? en de definitiestructuur van Azure Policy voor meer informatie over Azure Policy.

De volgende twee ingebouwde beleidsregels worden ondersteund voor door de klant beheerde TDE in Azure Policy:

• Voor SQL Server moeten door de klant beheerde sleutels worden gebruikt voor het versleutelen van data-at-rest
• Beheerde exemplaren moeten door de klant beheerde sleutels gebruiken om data-at-rest te versleutelen

Het door de klant beheerde TDE-beleid kan worden beheerd door naar Azure Portal te gaan en te zoeken naar de beleidsservice . Zoek onder Definities naar door de klant beheerde sleutel.

Er zijn drie effecten voor dit beleid:

• Controle : de standaardinstelling en legt alleen een auditrapport vast in de activiteitenlogboeken van Azure Policy
• Weigeren : hiermee voorkomt u dat logische server of beheerd exemplaar wordt gemaakt of bijgewerkt zonder dat een door de klant beheerde sleutel is geconfigureerd
• Uitgeschakeld : hiermee wordt het beleid uitgeschakeld en worden gebruikers niet beperkt tot het maken of bijwerken van een logische server of beheerd exemplaar zonder door de klant beheerde TDE ingeschakeld

Als azure Policy voor door de klant beheerde TDE is ingesteld op Weigeren, mislukt het maken van een logische Azure SQL-server of het beheerde exemplaar. De details van deze fout worden vastgelegd in het activiteitenlogboek van de resourcegroep.

Belangrijk

Eerdere versies van ingebouwd beleid voor door de klant beheerde TDE met het AuditIfNotExist effect zijn afgeschaft. Bestaande beleidstoewijzingen die gebruikmaken van het afgeschafte beleid, worden niet beïnvloed en blijven werken zoals voorheen.

Volgende stappen

U kunt ook de volgende PowerShell-voorbeeldscripts controleren voor de algemene bewerkingen met door de klant beheerde TDE:

• De transparante gegevensversleutelingsbeveiliging voor SQL Database draaien

• Een TDE-beveiliging (Transparent Data Encryption) verwijderen voor SQL Database

• Transparante gegevensversleuteling beheren in SQL Managed Instance met uw eigen sleutel met behulp van PowerShell

Bovendien kunt u Microsoft Defender voor SQL inschakelen om uw databases en hun gegevens te beveiligen, met functies voor het detecteren en beperken van potentiële beveiligingsproblemen in databases en het detecteren van afwijkende activiteiten die kunnen duiden op een bedreiging voor uw databases.