Azure SQL Transparent Data Encryption met klantbeheerde sleutel

Van toepassing op:Azure SQL DatabaseAzure SQL Managed Instance

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

Voor Azure SQL Database stel je de TDE-beschermer in op serverniveau, en alle versleutelde databases die aan die server gekoppeld zijn, erven die. Voor Azure SQL Managed Instance stel je de TDE-beschermer in op instance-niveau, en alle versleutelde databases op die instance erven die. De term server verwijst zowel naar een logische server in Azure SQL Database als naar een beheerde instantie in SQL Managed Instance door dit artikel heen, 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

Microsoft Entra ID voorheen Azure Active Directory (Azure AD) werd genoemd.

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

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

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

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 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 de logische server in Azure de TDE-beschermer te gebruiken die in Azure Key Vault is opgeslagen voor de encryptie van de DEK, moet de Key Vault Administrator toegangsrechten geven aan de server met zijn 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.

Belangrijke vereisten voor het configureren van TDE-beveiliging

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

De volgende vereisten zijn van toepassing.

Ondersteunde sleuteltypen en -grootten

Afhankelijk van de Azure SQL-aanbieding en TDE-configuratie kan de TDE-beveiliging worden ondersteund door asymmetrische of symmetrische sleutels die zijn opgeslagen in Azure Key Vault of Azure Key Vault Beheerde HSM.

  • Asymmetrische sleutels (RSA of RSA HSM)

    • Ondersteund in Azure Key Vault en Azure Key Vault Beheerde HSM
    • Ondersteunde sleutelgroottes: 2.048-bit en 3.072-bit
    • Ondersteund voor Azure SQL Database en Azure SQL Managed Instance

  • Symmetrische sleutels (AES)

    • Ondersteund in Azure Key Vault Premium (preview) en Azure Key Vault Managed HSM
    • Ondersteunde sleutelgroottes: 128-bit, 192-bit en 256-bit
    • Alleen ondersteund voor Azure SQL Database, momenteel in publieke preview

Notitie

Transparent Data Encryption met symmetrische sleutels (AES) is momenteel als preview beschikbaar. Preview-functies worden met beperkte mogelijkheden uitgebracht, maar Microsoft stelt ze beschikbaar op previewbasis zodat klanten vroegtijdig toegang krijgen en feedback kunnen geven. Preview-functies zijn onderhevig aan afzonderlijke aanvullende preview-termenen zijn niet onderworpen aan SLA's. Ondersteuning wordt in bepaalde gevallen verleend op basis van best effort. Microsoft Ondersteuning wil echter graag feedback krijgen over de preview-functionaliteit en kan in bepaalde gevallen best effort-ondersteuning bieden. Preview-functies hebben mogelijk beperkte of beperkte functionaliteit en zijn mogelijk alleen beschikbaar in geselecteerde geografische gebieden.

Sleutelbeheergedrag voor symmetrische (AES) sleutels

Je kunt symmetrische (AES) sleutels gebruiken die zijn opgeslagen in Azure Key Vault Premium (preview) of Azure Key Vault Managed HSM als TDE-beschermer. Om te beginnen met een sleutel van een on-premises hardware security module (HSM), importeer je de sleutel in een van beide diensten. Na de initiële import vinden alle lopende sleutellevenscyclusoperaties plaats in Azure Key Vault Premium (preview) of Azure Key Vault Managed HSM. Herstel naar een bepaald tijdstip, geografisch noodherstel en hervalidatie van sleutels zijn er allemaal van afhankelijk dat de sleutel daar beschikbaar blijft. Onderhoud lokale back-ups van geïmporteerde sleutels ter ondersteuning van herstel- en hervalidatiescenario's. Dit gedrag geldt alleen voor symmetrische (AES) sleutels, niet voor asymmetrische (RSA) sleutels.

Status van de sleutel en geldigheidsvereisten

  • Als een activeringsdatum van een sleutel is opgegeven, moet deze worden ingesteld op een datum en tijd in het verleden.
  • Als een vervaldatum van een sleutel is opgegeven, moet deze worden ingesteld op een datum en tijd in de toekomst.
  • De sleutel moet de status Ingeschakeld hebben.

Belangrijke importvereisten

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

  • .pfx
  • .byok
  • .backup

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. Zie de opmerkingen bij de release van CipherTrust Cloud Key Manager voor meer informatie over dit probleem. 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 voor het configureren van door de klant beheerde TDE

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

    Zie voor meer informatie over het gedrag bij throttling de Azure Key Vault richtlijnen voor throttling.

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

    • Gebruik een toegewezen Azure Key Vault voor Azure SQL-resources.

    • Koppel niet meer dan 500 algemene databases aan één Azure Key Vault.

    • Koppel niet meer dan 200 bedrijfskritieke databases aan één Azure Key Vault.

    • Het aantal Hyperscale-databases dat aan één Azure Key Vault kan worden gekoppeld, wordt bepaald door het aantal paginaservers. Elke paginaserver is gekoppeld aan een logisch gegevensbestand. Voer de volgende query uit om het aantal paginaservers te vinden.

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

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

    • Bewaken en configureren van Azure Key Vault-waarschuwingen. Zie Azure Key Vault bewaken en Azure Key Vault-waarschuwingen configureren voor meer informatie over bewaking en waarschuwingen.

  • Om in lijn te zijn met langetermijnplanning van cryptografische veerkracht, overweeg AES-256 symmetrische sleutels als TDE-beschermer te gebruiken.

    Grootschalige quantumcomputing zal naar verwachting publieke-sleutel cryptografische algoritmen zoals RSA breken. Symmetrische cryptografie, inclusief AES, wordt als kwantumbestendig beschouwd bij voldoende grote sleutelgroottes.

    Microsoft's bredere quantum-safe beveiligingsstrategie legt de nadruk op crypto-agility. Adopteer sterkere symmetrische algoritmen waar ze worden ondersteund en plan voor toekomstige cryptografische transities naarmate richtlijnen en standaarden zich ontwikkelen.

    Belangrijk

    Transparent Data Encryption met symmetrische sleutels (AES) wordt momenteel alleen ondersteund voor Azure SQL Database en is in openbare preview.

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

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

  • Bewaar alle eerder gebruikte sleutels in Azure Key Vault 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 in het artikel Een TDE-beveiliging (Transparent Data Encryption) verwijderen met behulp van PowerShell. Draai altijd naar een nieuwe TDE-beveiliging en controleer of alle databases de nieuwe sleutel gebruiken voordat u de geïnfecteerde sleutel verwijdert of uitschakelt. Het verwijderen of uitschakelen van de sleutel zonder eerst te roteren zorgt ervoor dat alle versleutelde databases ontoegankelijk worden en maakt geen sleutelkopieën ongeldig die eerder zijn geback-upt en teruggezet naar een andere kluis.

Aanbeveling

Versiegebonden en versieloze Azure Key Vault-sleutels gebruiken voor TDE

Wanneer u de TDE-beveiliging instelt, kunt u verwijzen naar een Azure Key Vault-sleutel met behulp van een specifieke sleutelversie of een versieloze sleutel-id.

In beide gevallen wordt in Azure SQL Database altijd de meest recente ingeschakelde versie van de sleutel in Azure Key Vault of Azure Key Vault Managed HSM opgelost en gebruikt. Gebruik versieloze sleutel-id's om te voorkomen dat een specifieke sleutelversie wordt ingesloten in de configuratie van de TDE-protector.

Versieloze sleutel-id's worden momenteel alleen ondersteund voor Azure SQL Database.

Voorbeelden:

  • Sleutel-id die een specifieke versie bevat

    https://<key-vault-name>.vault.azure.net/keys/<key-name>/<key-version>

  • Versieloze sleutel-id

    https://<key-vault-name>.vault.azure.net/keys/<key-name>

Rotatie van TDE-protector

Door de TDE-protector te draaien, kunt u de sleutel vervangen die wordt gebruikt om de DATABASEversleutelingssleutel (DEK) te beveiligen. Sleutelrotatie is een onlinebewerking en duurt slechts enkele seconden. De bewerking ontsleutelt alleen en versleutelt de databaseversleutelingssleutel opnieuw, niet de hele database.

U kunt de TDE-protector rouleren door de configuratie te wijzigen zodat een nieuwe sleutel wordt gebruikt die is opgeslagen in Azure Key Vault of Azure Key Vault Managed HSM. Afhankelijk van de Azure SQL-aanbieding en ondersteunde configuratie, kan dit het volgende omvatten:

  • Overschakelen naar een nieuwe sleutelversie van dezelfde sleutel
  • Overschakelen naar een andere sleutel
  • Schakelen tussen ondersteunde sleuteltypen, zoals asymmetrische (RSA) en symmetrische (AES)-sleutels

Notitie

Transparent Data Encryption met symmetrische sleutels (AES) wordt momenteel alleen ondersteund voor Azure SQL Database en is in openbare preview.

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

Het instellen van TDE met CMK met behulp van handmatige of geautomatiseerde rotatie van sleutels maakt altijd gebruik van de nieuwste versie van de sleutel 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 het instellen van een bestaande geo-replicatie voegt u voordat u automatische sleutelrotatie op de primaire server inschakelt, de versleutelingssleutel toe die als TDE-beveiliging op de primaire server wordt gebruikt op 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.

  • Geo-replicatiescenario's met klantbeheerde 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 het effect van netwerkfouten of storingen bij het openen van de TDE-beveiliging in Azure Key Vault of Azure Managed HSM te verminderen, wordt 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 toegang tot sleutels binnen 30 minuten wordt hersteld, wordt de database binnen het volgende uur automatisch hersteld. Als de toegang tot sleutels echter na meer dan 30 minuten wordt hersteld, is automatische herstel van de database niet mogelijk. In dergelijke gevallen omvat het herstellen van de database extra procedures via Azure Portal en kan tijdrovend zijn, afhankelijk van de grootte van de database.

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

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

Schermopname van een niet-toegankelijke TDE BYOK-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 hun status 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.

De door de klant beheerde TDE bewaken

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

  • Azure Resource Health-. Een 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.

Voor meer informatie over back-upherstel voor SQL Database, zie Een database herstellen vanuit een back-up in Azure SQL Database. Voor systeemeigen back-up/herstel van SQL Server met SQL Managed Instance raadpleegt u quickstart: Een database herstellen naar Azure SQL Managed Instance met SSMS.

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 of Azure Managed HSM, is deze sleutel nodig tijdens het herstellen, zelfs als de database in de tussentijd is gewijzigd voor het gebruik van door de service beheerde TDE.

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.

Geografisch noodherstel met door de klant beheerde TDE

Actieve geo-replicatie en failovergroepen ondersteunen door de klant beheerde TDE. De primaire en secundaire servers kunnen een Azure Key Vault of Azure Managed HSM gebruiken in elke ondersteunde regio. De servers en key store hoeven niet in dezelfde regio te zitten.

Voor een succesvolle failover moeten beide servers toegang hebben tot elke Azure Key Vault of Azure Managed HSM die een vereiste sleutel bevat.

Aandachtspunten voor configuratie

De volgende overwegingen gelden wanneer je actieve geo-replicatie of een failover-groep in het Azure-portaal configureert:

  • TDE-beveiligingslocatie: De primaire en secundaire servers kunnen dezelfde Azure Key Vault of Azure Managed HSM gebruiken. Het gebruik van dezelfde sleutelopslag verkleint het risico dat sleutelmateriaal uit sync raakt. Als je aparte sleutelkluizen in meerdere regio's gebruikt, moet je het benodigde sleutelmateriaal gesynchroniseerd houden. Voor informatie over key-store resilientie, zie Azure Key Vault beschikbaarheid en redundantie en Multi-region replicatie in Managed HSM.

  • Zoneredundantie: Waar beschikbaar, biedt zoneredundantie voor Azure SQL Database of Azure SQL Managed Instance extra veerkracht binnen een regio. Zie Wat zijn Azure-beschikbaarheidszones?.

  • Sleutelpermissies: Zowel de primaire als secundaire servers moeten de vereiste permissies hebben op elke Azure Key Vault of Azure Managed HSM die een vereiste TDE-beschermer bevat.

  • Sleutelbeschikbaarheid: Zorg ervoor dat de benodigde sleutels beschikbaar zijn op zowel de primaire als de secundaire servers. De servers hoeven geen identieke TDE-beschermers te gebruiken, maar elke server moet wel hetzelfde sleutelmateriaal hebben. Je kunt sleutels aan een server toevoegen door gebruik te maken van het Azure portal, PowerShell, Azure CLI of de Azure SQL REST API. Als de benodigde sleutels niet beschikbaar zijn op het moment van failover, kan de database ontoegankelijk worden.

  • Privé-endpoints: De configuratie kan een complexere DNS-zone vereisen als je private endpoints in Azure SQL gebruikt (bijvoorbeeld, het kan geen twee private endpoints aanmaken naar dezelfde resource in dezelfde DNS-zone).

  • Applicatieconnectiviteit: Applicaties moeten herkansingslogica gebruiken om tijdelijke storingen tijdens failover te verwerken.

Raadpleeg voor informatie over het configureren van de resource voor geografisch herstel na noodgevallen van Azure SQL Active geo-replication of Overzicht van failovergroepen en best practices.

Belangrijk

Wanneer je een geo-replicatielink of failovergroep aanmaakt, valideert Azure SQL dat beide servers toegang hebben tot alle benodigde door klanten beheerde sleutels. Als een van beide servers geen toegang heeft tot een vereiste sleutel, faalt de creatiebewerking. Als bijvoorbeeld de primaire en secundaire servers respectievelijk Sleutel A en Sleutel B gebruiken, voeg je beide sleutels toe aan beide servers voordat je de geo-replicatielink of failovergroep aanmaakt.

In het volgende diagram wordt Azure SQL-georeplicatie met een failover-groep en Azure Key Vault-regio-overschrijdende failover in een configuratie met gekoppelde regio's weergegeven:

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

Azure Key Vault-gedrag tijdens failover

  • Azure Key Vault initieert de failover, niet jij.
  • Hoewel de sleutelkluis in de primaire regio niet beschikbaar is, is de sleutelkluis alleen-leesbaar.
  • Je kunt sleutels alleen aanmaken, importeren en roteren zolang de sleutelkluis in de primaire regio beschikbaar is. Na een failover blijft de sleutelrotatie geblokkeerd totdat het primaire gebied weer bereikbaar is.
  • Je kunt niet kiezen of controleren in welke regio de sleutelkluis zich momenteel bevindt, en je kunt niet handmatig verbinding maken met de secundaire regio.

Herstellen na een ontoegankelijke TDE-beveiliging

Als een database in een actieve geo-replicatierelatie of failovergroep ontoegankelijk wordt, verbreekt het Azure SQL-besturingsvlak de link en zet de database om in een zelfstandige database.

Nadat je de sleutelrechten hebt hersteld, kun je meestal de primaire database weer online zetten. Je kunt de secundaire database niet weer online brengen omdat Azure SQL geen volledige back-ups van secundaire databases maakt. Verwijder de secundaire database en stel vervolgens de geo-replicatielink of failovergroep opnieuw op.

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

  • Controle : 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 tot het maken of bijwerken van een logische server of beheerd exemplaar zonder dat de door de klant beheerde transparante gegevensversleuteling (TDE) is 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 die het AuditIfNotExists effect bevatten, worden afgeschaft. Bestaande beleidstoewijzingen die gebruikmaken van het afgeschafte beleid, worden niet beïnvloed en blijven werken zoals voorheen.

TDE in Azure Synapse Analytics

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

Verwante inhoud

  • Laatst bijgewerkt om