Delen via

Transparante azure SQL-gegevensversleuteling met door de klant beheerde sleutel

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 wordt de TDE-beveiliging (Transparent Data Encryption), een door de klant beheerde asymmetrische sleutel die wordt gebruikt voor het beveiligen van de DATABASE-versleutelingssleutel (DEK) opgeslagen in Azure Key Vault of Azure Key Vault Managed HSM. Dit zijn veilige, cloudgebaseerde sleutelbeheerservices die zijn ontworpen voor hoge beschikbaarheid en schaalbaarheid. Azure Key Vault ondersteunt RSA-sleutels en kan worden ondersteund door FIPS 140-2 Level 2 gevalideerde HSMs. Voor klanten die een hogere zekerheid nodig hebben, biedt Azure Key Vault Managed HSM FIPS 140-2 Level 3-niveau beveiligde hardware. De sleutel kan worden gegenereerd in de service, geïmporteerd of veilig worden overgedragen vanuit on-premises HSM's. Directe toegang tot sleutels is beperkt: geautoriseerde services voeren cryptografische bewerkingen uit zonder het sleutelmateriaal weer te geven.

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.

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 Managed HSM en gebruikt voor versleuteling van de Database Encryption Key (DEK) in Azure SQL, SQL Server op Azure VM en ON-premises SQL Server.
  • Bring Your Own Key (BYOK): de klant brengt veilig een eigen sleutel uit een on-premises HSM (Hardware Security Module) naar Azure Key Vault of Azure Managed HSM. 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).

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

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.

Machtigingen voor het configureren van door de klant beheerde TDE

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

Selecteer het type Azure Key Vault dat u wilt gebruiken.

Om ervoor te zorgen dat de logische server in Azure de TDE-protector gebruikt die is opgeslagen in Azure Key Vault voor versleuteling van de DEK, moet de Key Vault-beheerder toegangsrechten verlenen aan de server met behulp van de 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 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 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. 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 een server is geconfigureerd voor het gebruik van een TDE-beveiliging van Azure Key Vault, 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

  • Soft-delete en purge protection-functies moeten zijn ingeschakeld in Azure Key Vault. 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.

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

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, controleert u of deze is opgegeven in een van de ondersteunde bestandsindelingen: .pfx, .byokof .backup. Als u met HSM beveiligde sleutels wilt importeren in Azure Managed HSM, raadpleegt u Met HSM beveiligde sleutels importeren in Beheerde HSM (BYOK).

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 Azure Key Vault 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

  • 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 Servicelimieten van Azure Key Vault. 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 vergrendeling in op de sleutelkluis om te controleren wie deze kritieke resource kan verwijderen en om onbedoeld of ongeautoriseerd verwijderen te voorkomen. Meer informatie 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.

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 Azure Key Vault 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 Azure Key Vault voor het eerst gebruikt. Back-up kan alleen worden hersteld naar een Azure Key Vault. Meer informatie over de opdracht Backup-AzKeyVaultKey. Azure Managed HSM biedt ondersteuning voor het maken van een volledige back-up van de volledige inhoud van de HSM, inclusief alle sleutels, versies, kenmerken, tags en roltoewijzingen. Zie Volledige back-up en herstel en selectief sleutelherstel voor meer informatie.

  • 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 of beheerde HSM 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 Azure Key Vault of Azure Managed HSM, zelfs nadat u bent overgeschakeld naar door de service beheerde sleutels. Het zorgt ervoor dat databaseback-ups kunnen worden hersteld met de TDE-beveiligingen die zijn opgeslagen in Azure Key Vault of Azure Managed HSM. TDE-protectoren die zijn gemaakt met Azure Key Vault of Azure Managed HSM 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 of beheerde HSM 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 of automatische rotatie in Azure Managed HSM, 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 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 of beheerde HSM 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 of beheerde HSM, 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 of beheerde HSM 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 Azure Key Vault of Azure Managed HSM, wordt in maximaal tien minuten alle verbindingen met het bijbehorende foutbericht geweigerd en wordt de status gewijzigd in 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 de impact van netwerkfouten of storingen bij het openen van de TDE-beveiliging in Azure Key Vault of Azure Managed HSM te verminderen, is er een buffer van 24 uur geïntroduceerd voordat de service de database probeert 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.

Als de server geen toegang meer heeft tot de door de klant beheerde TDE-beveiliging in Azure Key Vault of Azure Managed HSM vanwege een Azure Key Vault-fout (zoals een 4XX-fout), wordt de database na 30 minuten verplaatst naar een niet-toegankelijke status.

Databasetoegang herstellen na een Azure Key Vault- of Azure Managed HSM-fout

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 de toegang tot sleutels binnen 30 minuten wordt hersteld, wordt de database binnen het volgende uur automatisch hersteld. Als sleuteltoegang 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 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 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 of Azure Managed HSM

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 de status ervan wijzigen in Ontoegankelijk.

De meest voorkomende oorzaken voor een gebrek aan netwerkconnectiviteit met Azure Key Vault of Azure Managed HSM zijn:

  • Azure Key Vault of Azure Managed HSM wordt weergegeven via een privé-eindpunt en het privé-IP-adres van de Azure Key Vault- of Azure Managed HSM-service is niet toegestaan in de uitgaande regels van de netwerkbeveiligingsgroep (NSG) die zijn gekoppeld aan het subnet van het beheerde exemplaar.
  • 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 met Azure Key Vault of Azure Managed HSM die als host fungeert voor de TDE-beveiliging.

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

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 Azure Key Vault of Azure Managed HSM, worden alle nieuw gegenereerde back-ups ook versleuteld met dezelfde TDE-beveiliging. Wanneer de TDE-beveiliging wordt gewijzigd, worden oude back-ups van de database niet bijgewerkt om de nieuwste TDE-beveiliging te gebruiken.

Als u een back-up wilt herstellen die is versleuteld met een TDE-protector van Azure Key Vault of Azure Managed HSM, 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 of beheerde HSM te bewaren, zodat databaseback-ups kunnen worden hersteld.

Belangrijk

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 voor het beveiligen van de 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 Database voor meer informatie over het herstellen van back-ups in 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 of Azure Managed HSM, is deze sleutel nodig tijdens het herstellen, zelfs als de database in de tussentijd is gewijzigd om door de service beheerde TDE te gebruiken.

Hoge beschikbaarheid met door de klant beheerde TDE

Met de Azure Key Vault of Azure Managed HSM die meerdere lagen redundantie biedt, kunnen TDEs met behulp van een door de klant beheerde sleutel profiteren van azure Key Vault of Azure Managed HSM-beschikbaarheid en -tolerantie en zijn volledig afhankelijk van de Azure Key Vault- of Azure Managed HSM-redundantieoplossing.

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

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

Notitie

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

Met azure Managed HSM-replicatie voor meerdere regio's kunt u een Azure Managed HSM-pool uitbreiden van de ene Azure-regio (de primaire regio genoemd) naar een andere Azure-regio (een uitgebreide regio genoemd). Zodra beide regio's zijn geconfigureerd, kunnen aanvragen worden verwerkt en, met geautomatiseerde replicatie, hetzelfde belangrijke materiaal, rollen en machtigingen delen. Zie Replicatie in meerdere regio's inschakelen in Azure Managed HSM voor meer informatie.

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 de Azure Key Vault of Azure Managed HSM in elke regio. De server en sleutelkluis of beheerde HSM hoeven niet in dezelfde regio te worden geplaatst. Voor het gemak kunnen de primaire en secundaire servers met dezelfde sleutelkluis of beheerde HSM worden verbonden, ongeacht de regio. Dit helpt scenario's te voorkomen waarbij sleutelmateriaal mogelijk niet synchroon is als afzonderlijke sleutelkluizen of beheerde HSM's worden gebruikt voor beide servers. 

Azure Key Vault en Azure Managed HSM beschikken over 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 Azure Key Vaults in meerdere regio's.

  • Maak gebruik van azure Managed HSM en de replicatieoptie voor meerdere 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 Azure Key Vault-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 Azure Key Vault in de primaire regio.

  • De Azure Key Vault-failover wordt gestart door de Azure Key Vault-service en niet door de klant.

  • Bij failover van Azure Key Vault naar de secundaire regio heeft de server in Azure SQL nog steeds toegang tot dezelfde Azure Key Vault. Hoewel de Azure Key Vault-verbinding intern wordt omgeleid naar de Azure Key Vault in de secundaire regio.

  • Nieuwe sleutelcreaties, importbewerkingen en sleutelrotaties zijn alleen mogelijk terwijl de Azure Key Vault in de primaire versie beschikbaar is.

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

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

  • De Azure Key Vault staat in de Alleen-lezen modus terwijl de Azure Key Vault in de primaire regio onbeschikbaar is.

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

  • Voor een niet-gepaarde regio hebben beide Azure SQL-servers toegang tot de Azure Key Vault in de eerste regio (zoals aangegeven in de grafiek), en de Azure Key Vault maakt gebruik van zone-redundante opslag om de gegevens binnen de regio te repliceren, in onafhankelijke 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.

  • Wanneer een database deel uitmaakt van actieve geo-replicatie of failovergroepen en niet meer toegankelijk is, breekt het SQL-besturingsvlak de koppeling en converteert de database naar een zelfstandige database. Nadat de sleutelmachtigingen zijn opgelost, kan de primaire database doorgaans weer online worden gebracht. De secundaire database kan niet online worden gebracht omdat Azure SQL standaard geen volledige back-ups maakt voor secundaire databases. U wordt aangeraden de secundaire databases te verwijderen en de koppeling opnieuw tot stand te brengen.

  • 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 azure managed HSM-oplossing kunnen kiezen via Azure Key Vault:

  • 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

    • Hiervoor is het inschakelen van replicatie tussen regio's vereist, waardoor de tweede beheerde HSM-pool in de tweede regio wordt gemaakt.

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

  • Gebruik van Azure Managed 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
  • Uitgeschakeld - Hiermee wordt het beleid uitgeschakeld en worden gebruikers niet beperkt in het maken of bijwerken van een logische server of beheerd exemplaar zonder dat door de klant beheerde TDE is 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