Share via

Toegangsbeheer voor beheerde HSM

  • Artikel

Door Azure Key Vault beheerde HSM is een cloudservice die versleutelingssleutels beveiligt. Omdat deze gegevens gevoelig en essentieel zijn voor uw bedrijf, moet u uw beheerde HSM's (Hardware Security Modules) beveiligen door alleen geautoriseerde toepassingen en gebruikers toegang te geven tot de gegevens.

Dit artikel bevat een overzicht van het toegangsbeheermodel voor beheerde HSM's. Hierin worden verificatie en autorisatie uitgelegd en wordt beschreven hoe u de toegang tot uw beheerde HSM's kunt beveiligen.

Notitie

De Azure Key Vault-resourceprovider ondersteunt twee resourcetypen: kluizen en beheerde HSM's. Toegangsbeheer dat in dit artikel wordt beschreven, is alleen van toepassing op beheerde HSM's. Voor meer informatie over toegangsbeheer voor beheerde HSM raadpleegt u Toegang bieden tot Key Vault-sleutels, -certificaten en -geheimen met op rollen gebaseerd toegangsbeheer van Azure.

Toegangsbeheermodel

Toegang tot een beheerde HSM wordt beheerd via twee interfaces:

  • Beheerlaag
  • Gegevenslaag

Op het beheervlak beheert u de HSM zelf. Bewerkingen in dit vlak omvatten het maken en verwijderen van beheerde HSM's en het ophalen van beheerde HSM-eigenschappen.

Op het gegevensvlak werkt u met de gegevens die zijn opgeslagen in een beheerde HSM. Dat wil gezegd, u werkt met de versleutelingssleutels met HSM-ondersteuning. U kunt sleutels toevoegen, verwijderen, wijzigen en gebruiken om cryptografische bewerkingen uit te voeren, roltoewijzingen te beheren om de toegang tot de sleutels te beheren, een volledige HSM-back-up te maken, een volledige back-up te herstellen en het beveiligingsdomein te beheren vanuit de gegevensvlakinterface.

Voor toegang tot een beheerde HSM in beide lagen moeten alle bellers over de juiste verificatie en autorisatie beschikken. Met verificatie wordt de identiteit van de beller vastgesteld. Autorisatie bepaalt welke bewerkingen de aanroeper kan uitvoeren. Een beller kan een van de beveiligingsprinciplen zijn die zijn gedefinieerd in Microsoft Entra-id: gebruiker, groep, service-principal of beheerde identiteit.

Beide vliegtuigen gebruiken Microsoft Entra-id voor verificatie. Voor autorisatie gebruiken ze verschillende systemen:

  • Het beheervlak maakt gebruik van op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC), een autorisatiesysteem dat is gebouwd op Azure Resource Manager.
  • Het gegevensvlak maakt gebruik van een beheerd RBAC op HSM-niveau (managed HSM local RBAC), een autorisatiesysteem dat wordt geïmplementeerd en afgedwongen op het niveau van de beheerde HSM.

Wanneer een beheerde HSM wordt gemaakt, biedt de aanvrager een lijst met beheerders van gegevensvlakken (alle beveiligingsprinciplen worden ondersteund). Alleen deze beheerders hebben toegang tot het beheerde HSM-gegevensvlak om belangrijke bewerkingen uit te voeren en roltoewijzingen van gegevensvlakken (lokale RBAC van beheerde HSM) te beheren.

De machtigingsmodellen voor beide vlakken gebruiken dezelfde syntaxis, maar ze worden afgedwongen op verschillende niveaus en roltoewijzingen maken gebruik van verschillende bereiken. Het beheervlak van Azure RBAC wordt afgedwongen door Azure Resource Manager en het gegevensvlak beheerde HSM lokale RBAC wordt afgedwongen door de beheerde HSM zelf.

Belangrijk

Het verlenen van toegang tot een beveiligingsprincipaal verleent de beveiligingsprincipaal geen toegang tot het gegevensvlak van de beveiligingsprincipaal. Een beveiligingsprincipaal met toegang tot het beheervlak heeft bijvoorbeeld niet automatisch toegang tot sleutels of roltoewijzingen voor gegevensvlakken. Deze isolatie is standaard bedoeld om onbedoelde uitbreiding van bevoegdheden te voorkomen die van invloed zijn op de toegang tot sleutels die zijn opgeslagen in beheerde HSM.

Er is echter een uitzondering: leden van de rol Microsoft Entra Global Beheer istrator kunnen altijd gebruikers toevoegen aan de rol Managed HSM Beheer istrator voor hersteldoeleinden, bijvoorbeeld wanneer er geen geldige beheerde HSM-Beheer istratoraccounts meer zijn. Zie best practices voor Microsoft Entra ID voor het beveiligen van de rol Global Beheer strator voor meer informatie.

Een abonnementsbeheerder (omdat ze inzendermachtigingen hebben voor alle resources in het abonnement) kan bijvoorbeeld een beheerde HSM in hun abonnement verwijderen. Maar als ze geen toegang tot het gegevensvlak hebben die specifiek is verleend via lokale RBAC van beheerde HSM, kunnen ze geen toegang krijgen tot sleutels of roltoewijzingen beheren in de beheerde HSM om zichzelf of anderen toegang te verlenen tot het gegevensvlak.

Microsoft Entra-verificatie

Wanneer u een beheerde HSM in een Azure-abonnement maakt, wordt de beheerde HSM automatisch gekoppeld aan de Microsoft Entra-tenant van het abonnement. Alle bellers in beide vliegtuigen moeten worden geregistreerd in deze tenant en moeten worden geverifieerd voor toegang tot de beheerde HSM.

De toepassing wordt geverifieerd met Microsoft Entra-id voordat u een van beide vliegtuigen aanroept. De toepassing kan elke ondersteunde verificatiemethode gebruiken, afhankelijk van het toepassingstype. De toepassing verkrijgt een token voor een resource in het vliegtuig om toegang te krijgen. De resource is een eindpunt in het beheervlak of gegevensvlak, afhankelijk van de Azure-omgeving. De toepassing gebruikt het token en verzendt een REST API-aanvraag naar het beheerde HSM-eindpunt. Bekijk de volledige verificatiestroom voor meer informatie.

Het gebruik van één verificatiemechanisme voor beide vlakken heeft verschillende voordelen:

  • Organisaties kunnen de toegang tot alle beheerde HSM's in hun organisatie centraal beheren.
  • Als een gebruiker de organisatie verlaat, verliest deze direct de toegang tot alle beheerde HSM's in de organisatie.
  • Organisaties kunnen verificatie aanpassen met behulp van opties in Microsoft Entra ID, bijvoorbeeld om meervoudige verificatie in te schakelen voor extra beveiliging.

Resource-eindpunten

Beveiligingsprinciplen hebben toegang tot de vliegtuigen via eindpunten. De toegangsbeheer voor de twee vliegtuigen werken onafhankelijk. Als u een toepassing toegang wilt verlenen tot het gebruik van sleutels in een beheerde HSM, verleent u toegang tot het gegevensvlak met behulp van lokale RBAC van beheerde HSM. Als u een gebruiker toegang wilt verlenen tot een beheerde HSM-resource om de beheerde HSM's te maken, lezen, verwijderen, verplaatsen en andere eigenschappen en tags te bewerken, gebruikt u Azure RBAC.

In de volgende tabel ziet u de eindpunten voor het beheervlak en het gegevensvlak.

Toegangslaag Eindpunten voor toegang Operations Mechanisme voor toegangsbeheer
Beheerlaag Wereldwijd:
management.azure.com:443
 Beheerde HSM's maken, lezen, bijwerken, verwijderen en verplaatsen

Beheerde HSM-tags instellen		 Azure RBAC
Gegevenslaag Wereldwijd:
<hsm-name>.managedhsm.azure.net:443
 Sleutels: ontsleutelen, versleutelen,
uitpakken, verpakken, verifiëren, ondertekenen, ophalen, lijst, bijwerken, maken, importeren, verwijderen, back-up maken, herstellen, opschonen

Rolbeheer van gegevensvlak (lokaal RBAC voor beheerde HSM):roldefinities vermelden, rollen toewijzen, roltoewijzingen verwijderen, aangepaste rollen definiëren

Back-up en herstel: back-up maken, herstellen, de status van back-up- en herstelbewerkingen controleren

Beveiligingsdomein: het beveiligingsdomein downloaden en uploaden		 Lokale RBAC van beheerde HSM

Beheervlak en Azure RBAC

In het beheervlak gebruikt u Azure RBAC om de bewerkingen te autoriseren die een beller kan uitvoeren. In het Azure RBAC-model heeft elk Azure-abonnement een exemplaar van Microsoft Entra-id. U verleent toegang tot gebruikers, groepen en toepassingen vanuit deze map. Toegang wordt verleend voor het beheren van abonnementsresources die gebruikmaken van het Azure Resource Manager-implementatiemodel. Als u toegang wilt verlenen, gebruikt u Azure Portal, de Azure CLI, Azure PowerShell of Azure Resource Manager REST API's.

U maakt een sleutelkluis in een resourcegroep en beheert de toegang met behulp van Microsoft Entra-id. U verleent gebruikers of groepen de mogelijkheid om de sleutelkluizen in een resourcegroep te beheren. U verleent de toegang op een specifiek bereikniveau door de juiste Azure-rollen toe te wijzen. Als u toegang wilt verlenen aan een gebruiker voor het beheren van sleutelkluizen, wijst u een vooraf gedefinieerde key vault Contributor rol toe aan de gebruiker op een specifiek bereik. De volgende bereikniveaus kunnen worden toegewezen aan een Azure-rol:

  • Beheergroep: Een Azure-rol die op abonnementsniveau is toegewezen, is van toepassing op alle abonnementen in die beheergroep.
  • Abonnement: Een Azure-rol die op abonnementsniveau is toegewezen, is van toepassing op alle resourcegroepen en resources binnen dat abonnement.
  • Resourcegroep: Een Azure-rol die op het niveau van de resourcegroep is toegewezen, is van toepassing op alle resources in die resourcegroep.
  • Specifieke resource: een Azure-rol die is toegewezen voor een specifieke resource, is van toepassing op die resource. In dit geval is de resource een specifieke sleutelkluis.

Er zijn verschillende rollen vooraf gedefinieerd. Als een vooraf gedefinieerde rol niet aan uw behoeften voldoet, kunt u uw eigen rol definiëren. Zie Azure RBAC: Ingebouwde rollen voor meer informatie.

Gegevensvlak en beheerde HSM lokale RBAC

U verleent een beveiligingsprincipaal toegang om specifieke sleutelbewerkingen uit te voeren door een rol toe te wijzen. Voor elke roltoewijzing moet u een rol en bereik opgeven waarvoor die toewijzing van toepassing is. Voor lokale RBAC van beheerde HSM zijn er twee bereiken beschikbaar:

  • / of /keys: bereik op HSM-niveau. Beveiligingsprinciplen waaraan een rol in dit bereik is toegewezen, kunnen de bewerkingen uitvoeren die zijn gedefinieerd in de rol voor alle objecten (sleutels) in de beheerde HSM.
  • /keys/<key-name>: Bereik op sleutelniveau. Beveiligingsprinciplen waaraan een rol in dit bereik is toegewezen, kunnen de bewerkingen uitvoeren die in deze rol zijn gedefinieerd voor alle versies van de opgegeven sleutel.

Volgende stappen