Delen via

Gegevensversleuteling met door de klant beheerde sleutels voor Azure Database for MySQL - Flexibele server

  • Artikel

VAN TOEPASSING OP: Azure Database for MySQL - Flexibele server

Met gegevensversleuteling met door de klant beheerde sleutels voor Azure Database for MySQL Flexible Server kunt u byok (Bring Your Own Key) gebruiken voor data-at-rest en scheiding van taken implementeren voor het beheren van sleutels en gegevens. Met door de klant beheerde sleutels (CMK's) is de klant verantwoordelijk voor het beheer van de levenscyclus van sleutels (sleutel maken, uploaden, rouleren, verwijderen), sleutelgebruiksmachtigingen en controlebewerkingen voor sleutels.

Notitie

Azure Key Vault Managed HSM (Hardware Security Module) wordt momenteel ondersteund voor door de klant beheerde sleutels voor Azure Database for MySQL Flexible Server.

Vergoedingen

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

  • U kunt de toegang tot gegevens volledig beheren door de sleutel te verwijderen en de database ontoegankelijk te maken
  • Volledige controle over de levenscyclus van de sleutel, inclusief het rouleren van de sleutel, zodat deze overeenkomt met het bedrijfsbeleid
  • Centraal beheer en organisatie van sleutels in Azure Key Vault of beheerde HSM
  • Mogelijkheid om scheiding van taken tussen beveiligingsfunctionarissen, DBA en systeembeheerders te implementeren

Hoe werkt gegevensversleuteling met een door de klant beheerde sleutel?

Beheerde identiteiten in Microsoft Entra ID bieden Azure-services een alternatief voor het opslaan van referenties in de code door een automatisch toegewezen identiteit in te richten die kan worden gebruikt voor verificatie bij elke service die Microsoft Entra-verificatie ondersteunt, zoals Azure Key Vault (AKV). Azure Database for MySQL Flexible Server ondersteunt momenteel alleen door de gebruiker toegewezen beheerde identiteit (UMI). Zie Beheerde identiteitstypen in Azure voor meer informatie.

Als u de CMK wilt configureren voor een Flexibele Azure Database for MySQL-server, moet u de UMI koppelen aan de server en de Azure Key Vault en sleutel opgeven die u wilt gebruiken.

De UMI moet de volgende toegang hebben tot de sleutelkluis:

  • Ophalen: Voor het ophalen van het openbare deel en de eigenschappen van de sleutel in de sleutelkluis.
  • Lijst: Vermeld de versies van de sleutel die zijn opgeslagen in een sleutelkluis.
  • Wrap Key: Om de DEK te kunnen versleutelen. De versleutelde DEK wordt opgeslagen in het exemplaar van Azure Database for MySQL Flexible Server.
  • Sleutel uitpakken: om de DEK te ontsleutelen. Azure Database for MySQL Flexible Server heeft de ontsleutelde DEK nodig om de gegevens te versleutelen/ontsleutelen.

Als RBAC is ingeschakeld, moet de UMI ook de volgende rol krijgen:

  • Key Vault Crypto Service Encryption User of de rol met de machtigingen:
    • Microsoft.KeyVault/vaults/keys/wrap/action
    • Microsoft.KeyVault/vaults/keys/unwrap/action
    • Microsoft.KeyVault/vaults/keys/read like "Key Vault Crypto Service Encryption User"
  • Wijs voor beheerde HSM de rol Versleutelingsgebruiker voor beheerde HSM Crypto Service-versleuteling toe

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 waarmee een specifiek blok wordt versleuteld en ontsleuteld. 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 de KEK te verwijderen. 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 versleutelings-rest voor meer informatie.

Hoe het werkt

Gegevensversleuteling met CMK's wordt ingesteld op serverniveau. Voor een bepaalde server wordt een CMK, de sleutelversleutelingssleutel (KEK) genoemd, gebruikt om de gegevensversleutelingssleutel (DEK) van de service te versleutelen. De KEK is een asymmetrische sleutel die is opgeslagen in een door de klant beheerde Azure Key Vault-instantie. Key Vault is maximaal beschikbare en schaalbare veilige opslag voor cryptografische RSA-sleutels, optioneel ondersteund door DOOR FIPS 140 gevalideerde HSM's (Hardware Security Modules). Key Vault staat geen directe toegang tot een opgeslagen sleutel toe, maar biedt in plaats daarvan versleutelings-/ontsleutelingsservices met behulp van de sleutel voor de geautoriseerde entiteiten. De sleutelkluis, geïmporteerd, kan de sleutel genereren of worden overgedragen naar de sleutelkluis vanaf een on-premises HSM-apparaat.

Wanneer u een flexibele server configureert voor het gebruik van een CMK die is opgeslagen in de sleutelkluis, verzendt 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 flexibele server de beveiligde DEK naar de sleutelkluis voor ontsleuteling wanneer dat nodig is.

Diagram van de werking van gegevensversleuteling met een door de klant beheerde sleutel.

Nadat logboekregistratie is ingeschakeld, kunnen auditors Azure Monitor gebruiken om key Vault-auditgebeurtenislogboeken te controleren. Zie Uw key vault-service bewaken met Key Vault-inzichten om logboekregistratie van Key Vault-controlegebeurtenissen in te schakelen.

Notitie

Het kan tot 10 minuten duren voordat machtigingswijzigingen van invloed zijn op 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 gegevensversleuteling voor Azure Database for MySQL Flexibele server

Voordat u Key Vault of beheerde HSM probeert te configureren, moet u voldoen aan de volgende vereisten.

  • De Key Vault- en Azure Database for MySQL Flexible Server-instantie moeten deel uitmaken van dezelfde Microsoft Entra-tenant. Interactie tussen tenants en flexibele servers moet worden ondersteund. U moet gegevensversleuteling opnieuw configureren als u Key Vault-resources verplaatst nadat u de configuratie hebt uitgevoerd.
  • De Key Vault- en Azure Database for MySQL Flexible Server-instantie moeten zich in dezelfde regio bevinden.
  • Schakel de functie voorlopig verwijderen in de sleutelkluis in met een bewaarperiode die is ingesteld op 90 dagen om te beschermen tegen gegevensverlies als er per ongeluk een sleutel (of Key Vault) wordt verwijderd. De herstel- en opschoningsacties hebben hun eigen machtigingen in een Key Vault-toegangsbeleid. De functie voor voorlopig verwijderen is standaard uitgeschakeld, maar u kunt deze inschakelen via Azure Portal of met behulp van PowerShell of de Azure CLI.
  • Schakel de functie Beveiliging opschonen in de sleutelkluis in en stel de bewaarperiode in op 90 dagen. Wanneer beveiliging tegen opschonen is ingeschakeld, kunnen een kluis of een object met de status Verwijderd pas worden opgeschoond als de bewaarperiode is verstreken. U kunt deze functie inschakelen met behulp van PowerShell of de Azure CLI, en pas nadat u voorlopig verwijderen hebt ingeschakeld.

Voordat u de CMK probeert te configureren, moet u de volgende vereisten afhandelen.

  • De door de klant beheerde sleutel voor het versleutelen van de DEK kan alleen asymmetrisch zijn, RSA\RSA-HSM(kluizen met Premium SKU) 2048,3072 of 4096.
  • 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'.
  • 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).

Notitie

Zie Gegevensversleuteling configureren voor Azure Database for MySQL Flexible Server voor gedetailleerde stapsgewijze instructies over het configureren van datumversleuteling voor Azure Database for MySQL Flexible Server via Azure Portal.

Aanbevelingen voor het configureren van gegevensversleuteling

Wanneer u Key Vault of beheerde HSM configureert voor het gebruik van gegevensversleuteling met behulp van een door de klant beheerde sleutel, moet u rekening houden met de volgende aanbevelingen.

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

Notitie

  • Het is raadzaam om een sleutelkluis uit dezelfde regio te gebruiken, maar indien nodig kunt u een sleutelkluis uit een andere regio gebruiken door de informatie over het invoeren van de sleutel-id op te geven. De beheerde HSM van de sleutelkluis moet zich in dezelfde regio bevinden als de flexibele MySQL-server.

Ontoegankelijke door de klant beheerde sleutelvoorwaarde

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

  • Als u de sleutelkluis verwijdert, heeft het exemplaar van Azure Database for MySQL Flexible Server geen toegang tot de sleutel en wordt de status Niet toegankelijk . Herstel de sleutelkluis en hervalideer de gegevensversleuteling om het azure Database for MySQL Flexible Server-exemplaar beschikbaar te maken.
  • Als u de sleutel uit de sleutelkluis verwijdert, heeft het Exemplaar van Azure Database for MySQL Flexible Server geen toegang tot de sleutel en wordt deze verplaatst naar de status Niet toegankelijk . Herstel de sleutel en hervalideer de gegevensversleuteling om het azure Database for MySQL Flexible Server-exemplaar beschikbaar te maken.
  • Als de sleutel die is opgeslagen in Azure Key Vault verloopt, wordt de sleutel ongeldig en wordt de azure Database for MySQL Flexible Server-instantie overgegaan naar de status Niet toegankelijk . Breid de vervaldatum van de sleutel uit met behulp van CLI envalideer vervolgens de gegevensversleuteling opnieuw om het Azure Database for MySQL Flexible Server-exemplaar beschikbaar te maken.

Onopzettelijke toegang tot sleutel intrekken vanuit Key Vault

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

  • Ophalen, weergeven, verpakken en sleutelmachtigingen van de server intrekken van de sleutelkluis
  • De sleutel verwijderen
  • De sleutelkluis verwijderen
  • De firewallregels van de sleutelkluis wijzigen
  • De door de gebruiker beheerde identiteit verwijderen die wordt gebruikt voor versleuteling op de flexibele server met een door de klant beheerde sleutel in Microsoft Entra-id

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:

  • Activiteitenlogboek: Wanneer de 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 meldingen en waarschuwingen te verzenden op basis van uw voorkeuren.

Replica met een door de klant beheerde sleutel in Key Vault

Zodra een Exemplaar van Azure Database for MySQL Flexible Server 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. Bij het versleutelen van een exemplaar van Azure Database for MySQL Flexible Server met een door de klant beheerde sleutel die al een replica(s) heeft, raden we u aan om de replica('s) te configureren door de beheerde identiteit en sleutel toe te voegen. Stel dat het azure Database for MySQL Flexible Server-exemplaar is geconfigureerd met back-up met georedundantie. In dat geval moet de replica worden geconfigureerd met de beheerde identiteit en sleutel waartoe de identiteit toegang heeft en die zich in de geografisch gekoppelde regio van de server bevindt.

Herstellen met een door de klant beheerde sleutel in Key Vault

Wanneer u probeert een exemplaar van Azure Database for MySQL Flexible Server te herstellen, kunt u de door de gebruiker beheerde identiteit en sleutel selecteren om de herstelserver te versleutelen. Stel dat het azure Database for MySQL Flexible Server-exemplaar is geconfigureerd met back-up met georedundantie. In dat geval moet u de herstelserver configureren met de beheerde identiteit en sleutel waartoe de identiteit toegang heeft en die zich in de geografisch gekoppelde regio van de server bevindt.

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

  • Start het herstel- of leesproces voor het maken van replica's vanuit het Azure Database for MySQL Flexible Server-exemplaar.
  • Op de herstelde/replicaserver moet u de door de klant beheerde sleutel opnieuwvalideren in de instellingen voor gegevensversleuteling om ervoor te zorgen dat de door de gebruiker beheerde identiteit get-, lijst-, sleutel- en uitpaksleutelmachtigingen krijgt voor de sleutel die is opgeslagen in Key Vault.

Notitie

Het gebruik van dezelfde identiteit en sleutel als op de bronserver is niet verplicht bij het uitvoeren van een herstelbewerking.

Volgende stappen