Azure Database for MySQL-gegevensversleuteling met een door de klant beheerde sleutel

  • Artikel

VAN TOEPASSING OP: Azure Database for MySQL - enkele server

Belangrijk

Azure Database for MySQL enkele server bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan een upgrade uit te voeren naar een flexibele Azure Database for MySQL-server. Zie Wat gebeurt er met Azure Database for MySQL Enkele server voor meer informatie over migreren naar Azure Database for MySQL Flexibele server ?

Gegevensversleuteling met door de klant beheerde sleutels voor Azure Database for MySQL stelt u in staat om inactieve gegevens te beveiligen met BYOK (Bring Your Own Key). Daarnaast kunnen organisaties hiermee een scheiding van taken implementeren bij het beheer van sleutels en gegevens. Met door de klant beheerde versleuteling bent u verantwoordelijk voor en in een volledig beheer van de levenscyclus van een sleutel, machtigingen voor sleutelgebruik en het controleren van bewerkingen op sleutels.

Gegevensversleuteling met door de klant beheerde sleutels voor Azure Database for MySQL wordt ingesteld op serverniveau. Voor een bepaalde server wordt een door de klant beheerde sleutel, de sleutelversleutelingssleutel (KEK) genoemd, gebruikt voor het versleutelen van de gegevensversleutelingssleutel (DEK) die door de service wordt gebruikt. De KEK is een asymmetrische sleutel die is opgeslagen in een door de klant beheerde Azure Key Vault-instantie . De KEK (Key Encryption Key) en Data Encryption Key (DEK) worden verderop in dit artikel nader beschreven.

Key Vault is een extern sleutelbeheersysteem in de cloud. Het is maximaal beschikbaar en biedt schaalbare, veilige opslag voor cryptografische RSA-sleutels, optioneel ondersteund door DOOR FIPS 140 gevalideerde HSM's (Hardware Security Modules). Het biedt geen directe toegang tot een opgeslagen sleutel, maar biedt wel services van versleuteling en ontsleuteling aan geautoriseerde entiteiten. Key Vault kan de sleutel genereren, importeren of overdragen vanaf een on-premises HSM-apparaat.

Notitie

Deze functie wordt alleen ondersteund voor opslag voor algemeen gebruik v2 (ondersteuning voor maximaal 16 TB) opslag die beschikbaar is in de prijscategorieën Algemeen gebruik en Geoptimaliseerd voor geheugen. Raadpleeg opslagconcepten voor meer informatie. Raadpleeg de sectie beperking voor andere beperkingen.

Vergoedingen

Gegevensversleuteling met door de klant beheerde sleutels voor Azure Database for MySQL biedt de volgende voordelen:

  • Gegevenstoegang wordt volledig beheerd door u door de mogelijkheid om de sleutel te verwijderen en de database ontoegankelijk te maken
  • Volledige controle over de levenscyclus van de sleutel, inclusief het rouleren van de sleutel die overeenkomt met het bedrijfsbeleid
  • Centraal beheer en organisatie van sleutels in Azure Key Vault
  • Mogelijkheid om scheiding van taken tussen beveiligingsfunctionarissen en DBA en systeembeheerders te implementeren

Terminologie en beschrijving

Gegevensversleutelingssleutel (DEK): een symmetrische AES256-sleutel die wordt gebruikt om een partitie of blok gegevens te versleutelen. Het versleutelen van elk gegevensblok met een andere sleutel maakt cryptoanalyseaanvallen moeilijker. Toegang tot DEK's is vereist door de resourceprovider of het toepassingsexemplaren die een specifiek blok versleutelen en ontsleutelen. Wanneer u een DEK vervangt door een nieuwe sleutel, moeten alleen de gegevens in het bijbehorende blok opnieuw worden versleuteld met de nieuwe sleutel.

Sleutelversleutelingssleutel (KEK):een versleutelingssleutel die wordt gebruikt om de DEK's te versleutelen. Met een KEK die Key Vault nooit verlaat, kunnen de DEK's zelf worden versleuteld en beheerd. De entiteit die toegang heeft tot de KEK kan afwijken van de entiteit waarvoor de DEK is vereist. Omdat de KEK is vereist om de DEK's te ontsleutelen, is de KEK effectief een enkel punt waarmee DEK's effectief kunnen worden verwijderd door het verwijderen van de KEK.

De DEK's, versleuteld met de KKS, worden afzonderlijk opgeslagen. Alleen een entiteit met toegang tot de KEK kan deze DEK's ontsleutelen. Zie Beveiliging in versleuteling-at-rest voor meer informatie.

Hoe gegevensversleuteling met een door de klant beheerde sleutel werkt

Diagram that shows an overview of Bring Your Own Key

Voor een MySQL-server voor het gebruik van door de klant beheerde sleutels die zijn opgeslagen in Key Vault voor versleuteling van de DEK, geeft een Key Vault-beheerder de volgende toegangsrechten voor de server:

  • get: Voor het ophalen van het openbare deel en de eigenschappen van de sleutel in de sleutelkluis.
  • wrapKey: om de DEK te kunnen versleutelen. De versleutelde DEK wordt opgeslagen in Azure Database for MySQL.
  • unwrapKey: om de DEK te ontsleutelen. Azure Database for MySQL heeft de ontsleutelde DEK nodig om de gegevens te versleutelen/ontsleutelen

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

Wanneer de server is geconfigureerd voor het gebruik van de door de klant beheerde sleutel die is opgeslagen in de sleutelkluis, stuurt de server de DEK naar de sleutelkluis voor versleuteling. Key Vault retourneert de versleutelde DEK, die is opgeslagen in de gebruikersdatabase. Op dezelfde manier verzendt de server, indien nodig, de beveiligde DEK naar de sleutelkluis voor ontsleuteling. Auditors kunnen Azure Monitor gebruiken om key Vault-auditgebeurtenislogboeken te controleren als logboekregistratie is ingeschakeld.

Vereisten voor het configureren van gegevensversleuteling voor Azure Database for MySQL

Hier volgen de vereisten voor het configureren van Key Vault:

  • Key Vault en Azure Database for MySQL moeten deel uitmaken van dezelfde Microsoft Entra-tenant. Interactie tussen tenantsleutels en servers wordt niet ondersteund. Als u de Key Vault-resource later verplaatst, moet u de gegevensversleuteling opnieuw configureren.
  • Schakel de functie voor voorlopig verwijderen in de sleutelkluis in, waarbij de bewaarperiode is ingesteld op 90 dagen, om te beschermen tegen gegevensverlies als er per ongeluk een sleutel (of sleutelkluis) wordt verwijderd. Voorlopig verwijderde resources worden standaard 90 dagen bewaard, tenzij de bewaarperiode expliciet is ingesteld op <=90 dagen. De herstel- en opschoningsacties hebben hun eigen machtigingen gekoppeld aan een Key Vault-toegangsbeleid. De functie voor voorlopig verwijderen is standaard uitgeschakeld, maar u kunt deze inschakelen via PowerShell of de Azure CLI (u kunt deze functie niet inschakelen via Azure Portal).
  • Schakel de functie Beveiliging opschonen in de sleutelkluis in, waarbij de bewaarperiode is ingesteld op 90 dagen. Beveiliging tegen opschonen kan alleen worden ingeschakeld zodra voorlopig verwijderen is ingeschakeld. Deze kan worden ingeschakeld via Azure CLI of PowerShell. Wanneer beveiliging tegen opschonen is ingeschakeld, kunnen een kluis of een object met de status Verwijderd niet worden opgeschoond totdat de bewaarperiode is verstreken. Voorlopig verwijderde kluizen en objecten kunnen nog steeds worden hersteld, zodat het bewaarbeleid wordt gevolgd.
  • Verdeel de Azure Database for MySQL-toegang tot de sleutelkluis met de machtigingen get, wrapKey en unwrapKey met behulp van de unieke beheerde identiteit. In Azure Portal wordt de unieke service-identiteit automatisch gemaakt wanneer gegevensversleuteling is ingeschakeld in MySQL. Zie Gegevensversleuteling configureren voor MySQL voor gedetailleerde, stapsgewijze instructies wanneer u Azure Portal gebruikt.

Hier volgen de vereisten voor het configureren van de door de klant beheerde sleutel:

  • De door de klant beheerde sleutel die moet worden gebruikt voor het versleutelen van de DEK kan alleen asymmetrisch zijn, RSA 2048.
  • De activeringsdatum van de sleutel (indien ingesteld) moet een datum en tijdstip in het verleden zijn. De vervaldatum is niet ingesteld.
  • De sleutel moet de status Ingeschakeld hebben.
  • De sleutel moet voorlopig verwijderen hebben, waarbij de bewaarperiode is ingesteld op 90 dagen. Hiermee stelt u impliciet het vereiste sleutelkenmerk recoveryLevel in: 'Herstelbaar'. Als de retentie is ingesteld op < 90 dagen, is het recoveryLevel: "CustomizedRecoverable", wat niet de vereiste is, dus zorg ervoor dat de bewaarperiode wordt ingesteld op 90 dagen.
  • Voor de sleutel moet beveiliging tegen opschonen zijn ingeschakeld.
  • Als u een bestaande sleutel in de sleutelkluis importeert, moet u deze opgeven in de ondersteunde bestandsindelingen (.pfx, .byok, ). .backup

Aanbevelingen

Wanneer u gegevensversleuteling gebruikt met behulp van een door de klant beheerde sleutel, volgen hier aanbevelingen voor het configureren van Key Vault:

  • Stel een resourcevergrendeling in voor Key Vault om te bepalen wie deze kritieke resource kan verwijderen en onbedoeld of niet-geautoriseerd verwijderen kan voorkomen.

  • 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. Azure Monitor Log Analytics is een voorbeeld van een service die al is geïntegreerd.

  • Zorg ervoor dat Key Vault en Azure Database for MySQL zich in dezelfde regio bevinden, zodat u sneller toegang hebt tot DEK-wrap- en uitpakbewerkingen.

  • Vergrendel azure KeyVault tot alleen privé-eindpunten en geselecteerde netwerken en sta alleen vertrouwde Microsoft-services toe om de resources te beveiligen.

    trusted-service-with-AKV

Hier volgen aanbevelingen voor het configureren van een door de klant beheerde sleutel:

  • Bewaar een kopie van de door de klant beheerde sleutel op een veilige plaats of borg deze naar de borgservice.

  • Als Key Vault de sleutel genereert, maakt u een sleutelback-up voordat u de sleutel voor de eerste keer gebruikt. U kunt de back-up alleen herstellen naar Key Vault. Zie Backup-AzKeyVaultKey voor meer informatie over de back-upopdracht.

Ontoegankelijke door de klant beheerde sleutelvoorwaarde

Wanneer u gegevensversleuteling configureert met een door de klant beheerde sleutel in Key Vault, is continue toegang tot deze sleutel vereist om de server online te houden. Als de server geen toegang meer heeft tot de door de klant beheerde sleutel in Key Vault, begint de server alle verbindingen binnen tien minuten te weigeren. De server geeft een bijbehorend foutbericht en wijzigt de serverstatus in Ontoegankelijk. Enkele van de redenen waarom de server deze status kan bereiken, zijn:

  • Als we een herstelserver voor een bepaald tijdstip maken voor uw Azure Database for MySQL waarvoor gegevensversleuteling is ingeschakeld, heeft de zojuist gemaakte server de status Niet toegankelijk . U kunt dit oplossen via Azure Portal of CLI.
  • Als we een leesreplica maken voor uw Azure Database for MySQL waarvoor gegevensversleuteling is ingeschakeld, heeft de replicaserver de status Niet toegankelijk . U kunt dit oplossen via Azure Portal of CLI.
  • Als u de KeyVault verwijdert, heeft de Azure Database for MySQL geen toegang tot de sleutel en wordt deze verplaatst naar de status Niet toegankelijk . Herstel de sleutelkluis en hervalideer de gegevensversleuteling om de server beschikbaar te maken.
  • Als we de sleutel uit KeyVault verwijderen, heeft De Azure Database for MySQL geen toegang tot de sleutel en wordt de status Niet toegankelijk . Herstel de sleutel en hervalideer de gegevensversleuteling om de server beschikbaar te maken.
  • Als de sleutel die is opgeslagen in Azure KeyVault verloopt, wordt de sleutel ongeldig en wordt de Azure Database for MySQL overgegaan naar de status Niet toegankelijk. Breid de vervaldatum van de sleutel uit met behulp van CLI envalideer de gegevensversleuteling om de server beschikbaar te maken.

Onopzettelijke toegang tot sleutel intrekken vanuit Key Vault

Het kan gebeuren dat iemand met voldoende toegangsrechten voor Key Vault per ongeluk servertoegang tot de sleutel uitschakelt door:

  • Het intrekken van getde sleutelkluis en wrapKeyunwrapKey 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.

De door de klant beheerde sleutel bewaken in Key Vault

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

  • Azure Resource Health: Een niet-toegankelijke database die de toegang tot de klantsleutel heeft verbroken, wordt weergegeven als 'Niet toegankelijk' nadat de eerste verbinding met de database is geweigerd.

  • Activiteitenlogboek: wanneer toegang tot de klantsleutel in de door de klant beheerde sleutelkluis mislukt, worden vermeldingen toegevoegd aan het activiteitenlogboek. U kunt de toegang zo snel mogelijk opnieuw instellen als u waarschuwingen voor deze gebeurtenissen maakt.

  • Actiegroepen: definieer deze groepen om u meldingen en waarschuwingen te sturen op basis van uw voorkeuren.

Herstellen en repliceren met de beheerde sleutel van een klant in Key Vault

Nadat Azure Database for MySQL is versleuteld met de beheerde sleutel van een klant die is opgeslagen in Key Vault, wordt elke nieuw gemaakte kopie van de server ook versleuteld. U kunt deze nieuwe kopie maken via een lokale of geo-herstelbewerking of via leesreplica's. De kopie kan echter worden gewijzigd zodat deze overeenkomt met de beheerde sleutel van een nieuwe klant voor versleuteling. Wanneer de door de klant beheerde sleutel wordt gewijzigd, worden oude back-ups van de server gestart met de meest recente sleutel.

Als u problemen wilt voorkomen bij het instellen van door de klant beheerde gegevensversleuteling tijdens het herstellen of lezen van replica's, is het belangrijk om deze stappen uit te voeren op de bron- en herstelde/replicaservers:

  • Start het herstel- of leesproces voor het maken van replica's vanuit de Azure Database for MySQL-bron.
  • Behoud de zojuist gemaakte server (hersteld/replica) in een niet-toegankelijke status, omdat de unieke identiteit nog geen machtigingen heeft gekregen voor Key Vault.
  • Op de herstelde/replicaserver moet u de door de klant beheerde sleutel opnieuwvalideren in de instellingen voor gegevensversleuteling om ervoor te zorgen dat de zojuist gemaakte server machtigingen voor verpakken en uitpakken krijgt voor de sleutel die is opgeslagen in Key Vault.

Beperkingen

Voor Azure Database for MySQL heeft de ondersteuning voor versleuteling van data-at-rest met behulp van door klanten beheerde sleutel (CMK) enkele beperkingen:

  • Ondersteuning voor deze functionaliteit is beperkt tot prijscategorieën Algemeen gebruik en Geoptimaliseerd voor geheugen.

  • Deze functie wordt alleen ondersteund in regio's en servers, die ondersteuning bieden voor opslag voor algemeen gebruik v2 (maximaal 16 TB). Raadpleeg de sectie Opslag in de documentatie hier voor de lijst met Azure-regio's die ondersteuning bieden voor opslag tot 16 TB

    Notitie

    • Alle nieuwe MySQL-servers die zijn gemaakt in de Azure-regio's die ondersteuning bieden voor opslag voor algemeen gebruik v2, is ondersteuning voor versleuteling met customer manager-sleutels beschikbaar. Point In Time Restored (PITR)-server of leesreplica komt niet in aanmerking, maar in theorie zijn ze 'nieuw'.
    • Als u wilt controleren of de ingerichte opslag v2 voor algemeen gebruik van de server is, gaat u naar de blade prijscategorie in de portal en ziet u de maximale opslaggrootte die wordt ondersteund door de ingerichte server. Als u de schuifregelaar tot 4 TB kunt verplaatsen, bevindt uw server zich op opslag voor algemeen gebruik v1 en biedt deze geen ondersteuning voor versleuteling met door de klant beheerde sleutels. De gegevens worden echter altijd versleuteld met behulp van door de service beheerde sleutels. Neem contact AskAzureDBforMySQL@service.microsoft.com op met als u vragen hebt.

  • Versleuteling wordt alleen ondersteund met een cryptografische RSA 2048-sleutel.

Volgende stappen

  • Meer informatie over het instellen van gegevensversleuteling met een door de klant beheerde sleutel voor uw Azure Database for MySQL met behulp van Azure Portal en Azure CLI.
  • Meer informatie over de ondersteuning van het opslagtype voor Azure Database for MySQL - Enkele server