Delen via

Transparante azure SQL-gegevensversleuteling met door de klant beheerde sleutel

  • Artikel

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

TDE- (Transparent Data Encryption) in Azure SQL met door de klant beheerde sleutel (CMK) maakt BYOK-scenario (Bring Your Own Key) mogelijk voor data protection-at-rest en kunnen organisaties scheiding van taken implementeren in het beheer van sleutels en gegevens. Met door de klant beheerde TDE, is de klant verantwoordelijk voor en heeft hij volledige controle over het beheren van de levenscyclus van sleutels (aanmaken, uploaden, rouleren, verwijderen), machtigingen voor sleutelgebruik en controle 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 door de sleutelkluis worden gegenereerd, geïmporteerd of vanaf een lokaal HSM-apparaat worden overgebracht naar de sleutelkluis.

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 naar een server in SQL Database en 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 Transparent Data Encryption (TDE) met door de klant beheerde sleutels op databaseniveauvoor 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-versleutelingvoor 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 voorheen Azure Active Directory (Azure AD) werd genoemd.

Voordelen van door de klant beheerde TDE

Notitie

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

  • CMK (Customer Managed Key) : de klant beheert de levenscyclus van de sleutel, waaronder het maken, rouleren en verwijderen van sleutels. De sleutel wordt opgeslagen in Azure Key Vault of Azure Key Vault Managed HSM en wordt gebruikt voor de versleuteling van de Database Encryption Key (DEK) in de Azure SQL, de SQL Server op Azure VM en de SQL Server on-premises.
  • BYOK- (Bring Your Own Key) - De klant brengt veilig een eigen sleutel uit een on-premises HSM (Hardware Security Module) naar Azure Key Vault of beheerde HSM van Azure Key Vault of importeert deze. Dergelijke geïmporteerde sleutels kunnen worden gebruikt als elke 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).

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 door de service beheerde TDE gebruiken die door de klant beheerde TDE willen gaan gebruiken, blijven gegevens versleuteld tijdens het overschakelen en zijn 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.

Hoe door de klant beheerde TDE werkt

diagram met de installatie en werking van de door de klant beheerde TDE.

Om ervoor te zorgen dat de logische server in Azure de TDE-beschermer, opgeslagen in AKV, kan gebruiken voor de versleuteling van de DEK, moet de Key Vault-beheerder de server toegang geven via zijn unieke Microsoft Entra-identiteit. 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 Key Vault Crypto Service Encryption User rol is nodig voor de serveridentiteit om de sleutel te kunnen gebruiken voor versleutelings- en ontsleutelingsbewerkingen.

  • 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 moet de volgende machtigingen hebben voor de sleutelkluis:

    • 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 DEK te kunnen ontsleutelen

In het menu Toegangsconfiguratie Azure-portal van de sleutelkluis kunt u Azure-rolgebaseerd toegangsbeheer of Vault-toegangsbeleidselecteren. Zie SQL Server TDE Extensible Key Management instellen met behulp van Azure Key Vault-voor stapsgewijze instructies voor het instellen van een Azure Key Vault-toegangsconfiguratie voor TDE. 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 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 AuditEvent-logboeken van Key Vault te controleren als de registratie 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

  • De soft-delete en verwijderbeveiliging functies moeten zijn ingeschakeld op de sleutelkluis om te beschermen tegen gegevensverlies vanwege onbedoelde verwijdering van sleutels (of de sleutelkluis).

  • Verdeel de server of het beheerde exemplaar toegang tot de sleutelkluis (ophalen, 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 aangemaakt wanneer de server wordt aangemaakt. 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 Key Vault Crypto Service Encryption User.

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

Beveiliging tegen voorlopig verwijderen en opschonen inschakelen voor AKV

Belangrijk

Zowel soft-delete als bescherming tegen verwijdering moeten ingeschakeld zijn in de sleutelkluis bij het configureren van door de klant beheerde TDE op een nieuwe of bestaande server of een beheerd exemplaar.

Zacht verwijderen en verwijderbeveiliging zijn belangrijke functies van Azure Key Vault waarmee verwijderde kluizen en sleutelkluisobjecten kunnen worden hersteld, waardoor het risico wordt verminderd dat een gebruiker per ongeluk of kwaadwillig een sleutel of een sleutelkluis verwijdert.

  • Voorlopig verwijderde resources worden 90 dagen bewaard, tenzij ze zijn hersteld of verwijderd door de klant. De herstellen en acties opschonen hun eigen machtigingen hebben die zijn gekoppeld aan een sleutelkluistoegangsbeleid. 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. Wanneer beveiliging tegen opschonen is ingeschakeld, kunnen een kluis of een object met de status Verwijderd pas worden verwijderd nadat de bewaarperiode is verstreken. De standaardretentieperiode is 90 dagen, maar kan worden geconfigureerd van 7 tot 90 dagen via Azure Portal.

  • Voor Azure SQL moeten zachte verwijdering en verwijderbescherming zijn ingeschakeld in de sleutelkluis die de versleutelingssleutel bevat die wordt gebruikt als de TDE-beschermer voor de server of het beheerde exemplaar. Dit helpt voorkomen dat de situatie van onbedoelde of schadelijke verwijdering van een sleutelkluis of sleutel ertoe leidt dat de database de status niet-toegankelijk krijgt.

  • Wanneer u de TDE-beschermer configureert op een bestaande server of tijdens het creëren van de server, controleert Azure SQL dat de sleutelkluis die wordt gebruikt, soft-delete en verwijderbescherming 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 moeten beveiliging tegen voorlopig verwijderen en beveiliging tegen opschonen eerst worden ingeschakeld in de sleutelkluis en moet vervolgens de TDE-bescherming worden opgezet.

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 tijd 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 en SQL Server op Azure VM ondersteunt met behulp van een RSA-sleutel die is opgeslagen in een beheerde HSM als TDE-beschermer. Beheerde HSM van Azure Key Vault is een volledig beheerde, maximaal beschikbare cloudservice die voldoet aan standaarden en waarmee u cryptografische sleutels voor uw cloudtoepassingen kunt beveiligen met behulp van met FIPS 140-2 Level 3 gevalideerde HSM's. Meer te weten komen over beheerde HSM's en de configuratie- of RBAC-machtigingen die nodig zijn voor SQL Server in het artikel SQL Server TDE Extensible Key Management instellen met Azure Key Vault.

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 door de klant beheerde TDE

Aanbevelingen bij het configureren van AKV

  • Koppel in totaal maximaal 500 algemene of 200 bedrijfskritieke 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 key vault-servicelimieten. Het is de bedoeling om problemen na een serverovergang te voorkomen, omdat er net zoveel belangrijke operaties tegen de kluis worden uitgevoerd als er databases op die server zijn.

  • Stel een resourcevergrendeling in op de sleutelkluis om te bepalen wie deze kritieke resource kan verwijderen en onbedoeld of niet-geautoriseerd verwijderen kan voorkomen. Meer informatie over resource-locks.

  • 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.

  • 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.

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 niet in dezelfde regio te worden geplaatst.

Aanbevelingen bij het configureren van 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).

  • Vorige versies van de sleutel in de sleutelkluis behouden 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. Bij het herstellen heeft elke back-up de TDE-beveiliging nodig waarmee deze tijdens het maken is versleuteld. Sleutelrotaties kunnen worden uitgevoerd volgens de instructies in De transparante gegevensencryptiebeveiliging uitvoeren met behulp van PowerShell.

  • Bewaar alle eerder gebruikte sleutels in AKV, zelfs nadat u overschakelt naar door de service beheerde sleutels. Het 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 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.

Rotatie van de TDE-protector kan handmatig of met behulp van de functie voor automatische rotatie worden uitgevoerd.

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 of database binnen 24 uur automatisch geroteerd naar de nieuwste sleutelversie.

Wanneer deze functie wordt gebruikt met geautomatiseerde sleutelrotatie in Azure Key Vault, maakt dit een end-to-end zero-touch-rotatie mogelijk voor de TDE-beveiliger 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 nieuwste 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, met name voor 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 geografische replicatie bij het configureren van geautomatiseerde rotatie van de TDE-beschermer

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 probeert het systeem 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-replicatieconfiguratiesvoor meer informatie over het instellen van automatische sleutelrotatie voor geo-replicatieconfiguraties met TDE.

Niet-toegankelijke TDE-beveiliging

Wanneer TDE is geconfigureerd voor het gebruik van een door de klant beheerde sleutel, is continue toegang tot de TDE-beveiliging vereist om de database online te houden. 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 Ontoegankelijke. 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. Om de gevolgen van netwerkfouten of storingen tijdens het openen van de TDE-beveiliging in Azure Key Vault te beperken, is er een buffer van 24 uur geïntroduceerd voordat de service probeert de database te verplaatsen naar een niet-toegankelijke status. Als er een failover plaatsvindt voordat de status Niet toegankelijk wordt bereikt, is de database niet meer beschikbaar vanwege het verlies van de versleutelingscache.

Nadat de toegang tot de sleutel is hersteld, zijn extra tijd en stappen nodig om de database weer online te maken. 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 de sleutels na meer dan 30 minuten is hersteld, is automatisch herstel 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, gaan eerder geconfigureerde instellingen op serverniveau, zoals de configuratie van de failovergroep en tags, verloren. Ook verloren gaan de instellingen op databaseniveau, die de configuratie van elastische pools, leesschaal, automatisch onderbreken, herstelgeschiedenis naar een bepaald tijdstip, langetermijnretentiebeleid en andere omvatten. 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.

TDE BYOK Niet-toegankelijke database.

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 intrekken van de sleutelkluis ophalen, wrapKey, uitpakken machtigingen van de server

  • 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 waardoor de database ontoegankelijk wordt.

Geblokkeerde connectiviteit tussen SQL Managed Instance en Key Vault

Het probleem met netwerkconnectiviteit tussen SQL Managed Instance en de sleutelkluis doet zich meestal voor wanneer de sleutelkluisresource bestaat, maar het eindpunt niet bereikbaar is vanuit het beheerde exemplaar. Alle scenario's waarin het eindpunt van de sleutelkluis kan worden bereikt, maar de verbinding wordt geweigerd of machtigingen ontbreken, veroorzaken dat de databases de status wijzigen in Ontoegankelijk.

De meest voorkomende oorzaken voor een gebrek aan netwerkconnectiviteit met Key Vault zijn:

  • Key Vault is toegankelijk gemaakt 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 gekoppeld is aan het subnet van de beheerde instantie.
  • Slechte DNS-oplossing, bijvoorbeeld wanneer de FQDN van de sleutelkluis niet is omgezet of wordt omgezet naar een ongeldig IP-adres.

Test de connectiviteit van SQL Managed Instance naar 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 te testen poort is 443.
  • Het resultaat voor RemoteAddress moet bestaan en het juiste IP-adres zijn
  • Het resultaat voor TCP-test moet worden TcpTestSucceeded: True.

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 op het beheerde exemplaar een uitgaande regel heeft die betrekking heeft op het opgeloste IP-adres op poort 443, met name wanneer het opgeloste adres behoort tot het privé-eindpunt van de sleutelkluis.
    • Controleer andere netwerkconfiguraties, zoals routetabel, het bestaan van een virtueel apparaat en de configuratie, enzovoort.

Bewaking van de 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.

Database backup en restore met 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 raden we u aan alle oude versies van de TDE-beveiliging in de sleutelkluis te bewaren, zodat back-ups van databases kunnen worden hersteld.

Belangrijk

Op elk moment kan er niet meer dan één TDE-protector zijn ingesteld voor een server. Dit is de sleutel met het label 'Maak de sleutel tot de standaard TDE-beschermer' in het deelvenster van de Azure Portal. 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 vanuit 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 <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.

Zie Een database herstellen in SQL Databasevoor meer informatie over back-upherstel voor SQL Database. Voor meer informatie over het herstellen van een back-up voor toegewezen SQL-pools in Azure Synapse Analytics, zie Een toegewezen SQL-pool herstellen. Zie Quickstart voor systeemeigen back-up/herstel van SQL Server met SQL Managed Instance: 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-protector 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 servicebeheerde TDE te gebruiken.

Hoge beschikbaarheid met door de klant beheerde TDE

Met de AKV die meerdere lagen redundantie biedt, kunnen TDEs met behulp van een door de klant beheerde sleutel profiteren van de beschikbaarheid en tolerantie van AKV en volledig afhankelijk zijn van de AKV-redundantieoplossing.

De meerdere redundantielagen van AKV zorgen voor sleuteltoegang, zelfs als afzonderlijke serviceonderdelen mislukken of Azure-regio's of beschikbaarheidszones niet beschikbaar zijn. Zie beschikbaarheid en redundantie van Azure Key Vaultvoor meer informatie.

AKV biedt de volgende onderdelen van beschikbaarheid en tolerantie die automatisch worden geleverd zonder tussenkomst van de gebruiker:

Notitie

Voor alle gekoppelde regio's worden AKV-sleutels gerepliceerd naar beide regio's en zijn er Hardware Security Modules (HSM) in beide regio's die op deze sleutels kunnen werken. Zie Gegevensreplicatievoor meer informatie. Dit geldt voor zowel Standard- als Premium Azure Key Vault-servicelagen en software- of hardwaresleutels.

Geo-DR en door de klant beheerde TDE

In zowel actieve geo-replicatie als failovergroepen scenario's, kunnen de betrokken primaire en secundaire servers worden gekoppeld aan de Azure Key Vault in eender welke regio. De server en de sleutelkluis hoeven niet in dezelfde regio te worden geplaatst. Met dit voor het gemak 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 heeft meerdere redundantielagen om ervoor te zorgen dat de sleutels en sleutelkluizen beschikbaar blijven in geval van service- of regiofouten. De redundantie wordt ondersteund door de niet-gepaareerde en gekoppelde regio's. Zie beschikbaarheid en redundantie van Azure Key Vaultvoor meer informatie.

Er zijn verschillende opties voor het opslaan van de TDE-beveiligingssleutel op basis van de vereisten van de klant:

  • Benut Azure Key Vault en de ingebouwde tolerantie van gekoppelde of niet-gekoppelde regio's.

  • Maak gebruik van HSM van klanten en laad sleutels in Azure Key Vault in afzonderlijke AKV's in meerdere regio's.

  • Maak gebruik van beheerde HSM en de replicatieoptie tussen regio's.

    • Met deze optie kan de klant de gewenste regio selecteren waar de sleutels worden gerepliceerd.

Het volgende diagram vertegenwoordigt een configuratie voor gekoppelde regio (primair en secundair) voor een AKV-crossfailover met Azure SQL-installatie voor geo-replicatie met behulp van een failovergroep:

diagram met failover-ondersteuning voor meerdere regio's in Azure Key Vault voor een gekoppelde regio.

Azure Key Vault-opmerkingen voor Geo-DR

  • Zowel primaire als secundaire servers in Azure SQL hebben toegang tot de AKV in de primaire regio.

  • De AKV-failover wordt geïnitieerd door de AKV-service en niet door de klant.

  • In het geval van AKV-failover naar de secundaire regio heeft de server in Azure SQL nog steeds toegang tot dezelfde AKV. Hoewel intern wordt de AKV-verbinding omgeleid naar de AKV in de secundaire regio.

  • Nieuwe sleutelcreaties, imports en sleutelrotaties zijn alleen mogelijk als de AKV in de primaire beschikbaar is.

  • Zodra de failover plaatsvindt, is sleutelrotatie pas toegestaan als de AKV in de primaire regio van de gekoppelde regio opnieuw toegankelijk is.

  • De klant kan geen handmatig verbinding maken met de secundaire regio.

  • De AKV heeft de status Alleen-lezen, terwijl de AKV in de primaire regio niet beschikbaar is

  • De klant kan niet kiezen of controleren in welke regio de AKV zich momenteel bevindt.

  • Voor niet-gekoppelde regio's hebben beide Azure SQL-servers toegang tot de Azure Key Vault (AKV) in de eerste regio (zoals aangegeven in de grafiek), waarbij de AKV zone-redundante opslag gebruikt om de gegevens binnen de regio te repliceren over verschillende beschikbaarheidszones van dezelfde regio.

Zie Azure Key Vault-beschikbaarheid en -redundantie, Azure-regioparen en niet-gekoppelde regio'sen Service level agreements voor Azure Key Vault-voor meer informatie.

Azure SQL-opmerkingen voor Geo-DR

  • Gebruik de zoneredundante optie van Azure SQL MI en Azure SQL DB om de tolerantie te vergroten. Zie Wat zijn Azure-beschikbaarheidszones?.

  • Gebruik failovergroepen voor Azure SQL MI en Azure SQL DB voor herstel na noodgevallen naar een secundaire regio. Zie Overzicht van failovergroepen & best practicesvoor meer informatie.

  • Voor de configuratie is mogelijk een complexere DNS-zone vereist als privé-eindpunten worden gebruikt in Azure SQL (het kan bijvoorbeeld geen twee privé-eindpunten maken naar dezelfde resource in dezelfde DNS-zone).

  • Zorg ervoor dat toepassingen gebruikmaken van logica voor opnieuw proberen.

Er zijn verschillende scenario's waarin klanten de oplossing Managed Hardware Security Modules (HSM) willen kiezen via AKV:

  • Handmatige verbindingsvereiste voor de secundaire kluis.

  • Leestoegangsvereiste voor de kluis, zelfs als er een fout optreedt.

  • Flexibiliteit om te kiezen naar welke regio hun sleutelmateriaal wordt gerepliceerd

    • Vereist het inschakelen van replicatie tussen regio's waarmee de tweede beheerde HSM-pool in de tweede regio wordt gemaakt.

  • Met behulp van de beheerde HSM kunnen klanten een exacte replica voor HSM maken als het origineel verloren gaat of niet beschikbaar is.

  • Het gebruik van beheerde HSM voor beveiligings- of regelgevingsvereisten.

  • De mogelijkheid om een back-up van de gehele kluis te maken in tegenstelling tot het maken van een back-up van afzonderlijke sleutels.

Zie Replicatie in meerdere regio's inschakelen in Azure Managed HSM- en beheerde HSM-herstel na noodgevallenvoor meer informatie.

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 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 Azure Policy-definitiestructuurvoor meer informatie over Azure Policy.

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

  • SQL-servers moeten door de klant beheerde sleutels gebruiken om data-at-rest te versleutelen
  • Beheerde exemplaren moeten klantbeheerde sleutels gebruiken om data in rust te versleutelen

Het door de klant beheerde TDE-beleid kan worden beheerd door naar de Azure Portalte gaan en te zoeken naar de Policy-service. Zoek onder Definitiesnaar door de klant beheerde sleutel.

Er zijn drie effecten voor dit beleid:

  • Audit : de standaardinstelling en legt alleen een auditrapport vast in de activiteitenlogboeken van Azure Policy
  • Weigeren - Voorkomt het maken of bijwerken van een logische server of beheerd exemplaar zonder een door de klant beheerde sleutel geconfigureerd te hebben
  • Uitgeschakelde: 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 het Azure-beleid voor door de klant beheerde TDE is ingesteld op Weigeren, zal het maken van een logische Azure SQL-server of een beheerd exemplaar mislukken. De details van deze fout worden vastgelegd in het activiteitenlogboek van de resourcegroep.

Belangrijk

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

Verwante inhoud