Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Een veelvoorkomende uitdaging voor ontwikkelaars is het beheer van geheimen, referenties, certificaten en sleutels om communicatie tussen services te beveiligen. Handmatige verwerking van geheimen en certificaten is een bekende bron van beveiligingsproblemen en storingen. Dankzij beheerde identiteiten hoeven ontwikkelaars geen referenties meer te beheren. Toepassingen kunnen beheerde identiteiten gebruiken om Microsoft Entra-tokens te verkrijgen zonder referenties te hoeven beheren.
Wat zijn beheerde identiteiten?
Op hoog niveau zijn er twee soorten identiteiten: menselijke en machine-/niet-menselijke identiteiten. Machine-/niet-menselijke identiteiten bestaan uit apparaat- en workloadidentiteiten. In Microsoft Entra zijn workloadidentiteiten toepassingen, service-principals en beheerde identiteiten. Zie voor meer informatie over workload-identiteiten de sectie workload-identiteiten.
Een beheerde identiteit is een identiteit die kan worden toegewezen aan een Azure-rekenresource (virtuele machine (VM), virtuele-machineschaalset (VMSS), Service Fabric-cluster, Azure Kubernetes-cluster) of een app-hostingplatform dat wordt ondersteund door Azure. Zodra een beheerde identiteit is toegewezen aan de rekenresource, kan deze direct of indirect worden geautoriseerd voor toegang tot downstreamafhankelijkheidsresources, zoals een opslagaccount, SQL-database, CosmosDB, enzovoort. Beheerde identiteit vervangt geheimen, zoals toegangssleutels of wachtwoorden. Daarnaast kunnen beheerde identiteiten certificaten of andere vormen van verificatie vervangen voor service-naar-service-afhankelijkheden.
In de volgende video ziet u hoe u beheerde identiteiten kunt gebruiken:
Hier ziet u een paar voordelen van het gebruik van beheerde identiteiten:
- U hoeft geen referenties te beheren. Inloggegevens zijn niet eens toegankelijk voor je.
- U kunt beheerde identiteiten gebruiken om te verifiëren bij elke resource die ondersteuning biedt voor Microsoft Entra-verificatie, inclusief uw eigen toepassingen.
- Beheerde identiteiten kunnen zonder extra kosten worden gebruikt.
Typen beheerde identiteiten
Er zijn twee typen beheerde identiteit:
Door het systeem toegewezen. Met sommige Azure-resources, zoals virtuele machines, kunt u een beheerde identiteit rechtstreeks op de resource inschakelen. Wanneer u een door het systeem toegewezen beheerde identiteit inschakelt:
- Er wordt een service principal van een speciaal type aangemaakt in Microsoft Entra ID voor deze identiteit. De service-principal is gekoppeld aan de levenscyclus van die Azure-resource. Wanneer de Azure-resource wordt verwijderd, verwijdert Azure automatisch de service-principal voor u.
- Standaard kan alleen die Azure-resource deze identiteit gebruiken voor het aanvragen van tokens van Microsoft Entra ID.
- U machtigt de beheerde identiteit om toegang te hebben tot een of meer services.
- De naam van de door het systeem toegewezen service-principal is altijd dezelfde als de naam van de Azure-resource waarvoor deze is gemaakt. Voor een implementatieslot is de naam van zijn systeemtoegewezen beheerde identiteit
<app-name>/slots/<slot-name>
.
Door de gebruiker toegewezen. U kunt ook een beheerde identiteit maken als een zelfstandige Azure-resource. U kunt een door de gebruiker toegewezen beheerde identiteit maken en deze toewijzen aan een of meer Azure-resources. Wanneer u een door de gebruiker toegewezen beheerde identiteit inschakelt:
- Er wordt een service principal van een speciaal type aangemaakt in Microsoft Entra ID voor deze identiteit. De service-principal wordt afzonderlijk beheerd van de bronnen die deze gebruiken.
- Door de gebruiker toegewezen beheerde identiteiten kunnen door meerdere resources worden gebruikt.
- U machtigt de beheerde identiteit om toegang te hebben tot een of meer services.
Door de gebruiker toegewezen beheerde identiteiten, die onafhankelijk van de berekening worden ingericht en kunnen worden toegewezen aan meerdere rekenresources, zijn het aanbevolen beheerde identiteitstype voor Microsoft-services.
Met resources die door het systeem toegewezen beheerde identiteiten ondersteunen, kunt u het volgende doen:
- Beheerde identiteiten op resourceniveau in- of uitschakelen.
- Op rollen gebaseerd toegangsbeheer (RBAC) gebruiken om machtigingen te verlenen.
- CRUD-bewerkingen (Create, Read, Update en Delete) in Azure-activiteitenlogboeken weergeven.
- Aanmeldingsactiviteiten weergeven in aanmeldingslogboeken van Microsoft Entra ID.
Als u in plaats daarvan een door een gebruiker toegewezen beheerde identiteit kiest:
- U kunt de identiteiten maken, lezen, bijwerken en verwijderen.
- U kunt RBAC-roltoewijzingen gebruiken om machtigingen te verlenen.
- Door de gebruiker toegewezen beheerde identiteiten kunnen voor meer dan één resource worden gebruikt.
- CRUD-bewerkingen zijn beschikbaar voor controle in Azure-activiteitenlogboeken.
- Aanmeldingsactiviteiten weergeven in aanmeldingslogboeken van Microsoft Entra ID.
Bewerkingen op beheerde identiteiten kunnen worden uitgevoerd met behulp van een Azure Resource Manager-sjabloon, in Azure Portal, met Azure CLI, PowerShell en REST API's.
Verschillen tussen door het systeem toegewezen en door de gebruiker toegewezen beheerde identiteiten
Eigendom | Door het systeem toegewezen beheerde identiteit | Door de gebruiker toegewezen beheerde identiteit |
---|---|---|
Creatie | Gemaakt als onderdeel van een Azure-resource (bijvoorbeeld Microsoft Azure Virtual Machines of Azure App Service). | Gemaakt als een zelfstandige Azure-resource. |
Levenscyclus | De levenscyclus wordt gedeeld met de Azure-resource waarmee de beheerde identiteit is aangemaakt. Wanneer de hoofdresource wordt verwijderd, wordt ook de beheerde identiteit verwijderd. |
Onafhankelijke levenscyclus. Moet expliciet worden verwijderd. |
Delen tussen Azure-resources | Kan niet worden gedeeld. Deze kan alleen worden gekoppeld aan één Azure-resource. |
Kan worden gedeeld. Dezelfde door de gebruiker toegewezen beheerde identiteit kan worden gekoppeld aan meer dan één Azure-resource. |
Veelvoorkomende toepassingen | Workloads worden binnen één Azure-resource bevat. Workloads die identiteiten nodig hebben die onafhankelijk zijn. Bijvoorbeeld een toepassing die op één virtuele machine wordt uitgevoerd. |
Workloads die op meerdere resources worden uitgevoerd en die één identiteit kunnen delen. Workloads die vooraf moeten worden geautoriseerd voor een beveiligde resource, als onderdeel van een voorzieningsproces. Werklasten waarbij middelen regelmatig worden gerecycled, maar de machtigingen consistent moeten blijven. Bijvoorbeeld een werkbelasting waarbij meerdere virtuele machines toegang moeten hebben tot dezelfde resource. |
Hoe gebruik ik beheerde identiteiten voor Azure-resources?
U kunt beheerde identiteiten gebruiken door de onderstaande stappen te volgen:
- Maak een beheerde identiteit in Azure. U kunt kiezen tussen een door het systeem toegewezen beheerde identiteit of een door de gebruiker toegewezen beheerde identiteit.
- Wanneer u een door de gebruiker toegewezen beheerde identiteit gebruikt, wijst u de beheerde identiteit toe aan de 'bron'-Azure-resource, zoals een virtuele machine, een logische Azure-app of een Azure-web-app.
- Autoriseer de beheerde identiteit zodat deze toegang heeft tot de 'doelservice'.
- Gebruik de beheerde identiteit om toegang te krijgen tot een resource. In deze stap kunt u de Azure SDK gebruiken met de Azure.Identity-bibliotheek. Sommige 'bronresources' bieden connectors die weten hoe beheerde identiteiten voor de verbindingen moeten worden gebruikt. In dat geval gebruikt u de identiteit als een functie van die 'bronresource'.
Welke Azure-services ondersteunen de functie?
Beheerde identiteiten voor Azure-resources kunnen worden gebruikt voor verificatie bij services die ondersteuning bieden voor Microsoft Entra-verificatie. Zie Services die ondersteuning bieden voor beheerde identiteiten voor Azure-resources voor een lijst met ondersteunde Azure-services.
Werken met beheerde identiteiten
Beheerde identiteiten kunnen rechtstreeks of als federatieve identiteitsreferentie worden gebruikt voor Microsoft Entra ID-toepassingen.
De stappen voor het gebruik van beheerde identiteiten zijn als volgt:
- Maak een beheerde identiteit in Azure. U kunt kiezen tussen een door het systeem toegewezen beheerde identiteit of een door de gebruiker toegewezen beheerde identiteit. Wanneer u een door de gebruiker toegewezen beheerde identiteit gebruikt, wijst u de beheerde identiteit toe aan de azure-bronresource, zoals een virtuele machine, een logische Azure-app of een Azure-web-app.
- Autoriseren van de beheerde identiteit om toegang te hebben tot de doelservice.
- Gebruik de beheerde identiteit om toegang te krijgen tot een resource. In deze stap kunt u een van de clientbibliotheken gebruiken. Sommige bronbronnen bieden connectors die weten hoe beheerde identiteiten voor de verbindingen moeten worden gebruikt. In dat geval gebruikt u de identiteit als een functie van die bronresource.
Beheerde identiteit rechtstreeks gebruiken
Servicecode die wordt uitgevoerd op uw Azure-rekenresource maakt gebruik van de MICROSOFT Authentication Library (MSAL) of Azure.Identity SDK om een token voor beheerde identiteit op te halen van de Entra-id die wordt ondersteund door de beheerde identiteit. Voor deze tokenovername zijn geen geheimen vereist en wordt automatisch geverifieerd op basis van de omgeving waarin de code wordt uitgevoerd. Zolang de beheerde identiteit is geautoriseerd, heeft de servicecode toegang tot downstream-afhankelijkheden die ondersteuning bieden voor Entra ID-verificatie.
U kunt bijvoorbeeld een virtuele Azure-machine (VM) gebruiken als Azure Compute. Vervolgens kunt u een door de gebruiker toegewezen beheerde identiteit maken en deze toewijzen aan de virtuele machine. De workload die wordt uitgevoerd op de VM-interfaces met zowel Azure.Identity (of MSAL) als Azure Storage-client-SDK's voor toegang tot een opslagaccount. De door de gebruiker toegewezen beheerde identiteit is gemachtigd voor toegang tot het opslagaccount.
Beheerde identiteit gebruiken als federatieve identiteitsreferentie (FIC) in een Entra ID-app
Federatie van Workload Identity maakt het mogelijk een beheerde identiteit te gebruiken als aanmeldgegevens, net als een certificaat of wachtwoord, in Entra ID-toepassingen. Wanneer een Entra ID-app is vereist, is dit de aanbevolen manier om referentievrij te zijn. Er geldt een limiet van 20 FIC's bij het gebruik van beheerde identiteiten als FIC in een Entra ID-app.
Een workload die als Entra ID-toepassing werkt, kan worden gehost op elke Azure-rekenkracht met een beheerde identiteit. De workload gebruikt de beheerde identiteit om een token te verkrijgen dat via workload-identiteitsfederatie wordt uitgewisseld voor een Entra ID-toepassingstoken. Deze functie wordt ook wel beheerde identiteit genoemd als FIC (Federatieve identiteitsreferenties). Zie Een toepassing configureren om een beheerde identiteit te vertrouwen voor meer informatie.
Volgende stappen
- Inleiding en richtlijnen voor ontwikkelaars
- Een door het VM-systeem toegewezen beheerde identiteit gebruiken voor toegang tot Resource Manager
- Beheerde identiteiten gebruiken voor App Service en Azure Functions
- Beheerde identiteiten gebruiken met Azure Container Instances
- Beheerde identiteiten implementeren voor Microsoft Azure-resources
- Gebruik identiteitsfederatie voor werkbelasting voor beheerde identiteiten om toegang te krijgen tot met Microsoft Entra beveiligde bronnen zonder geheimen te beheren.