Beheerde identiteiten beveiligen in Microsoft Entra-id
In dit artikel vindt u informatie over het beheren van geheimen en referenties om de communicatie tussen services te beveiligen. Beheerde identiteiten bieden een automatisch beheerde identiteit in Microsoft Entra-id. Toepassingen gebruiken beheerde identiteiten om verbinding te maken met resources die Ondersteuning bieden voor Microsoft Entra-verificatie en om Microsoft Entra-tokens te verkrijgen, zonder referentiesbeheer.
Voordelen van beheerde identiteiten
Voordelen van het gebruik van beheerde identiteiten:
Met beheerde identiteiten worden referenties volledig beheerd, gedraaid en beveiligd door Azure. Identiteiten worden geleverd en verwijderd met Azure-resources. Met beheerde identiteiten kunnen Azure-resources communiceren met services die ondersteuning bieden voor Microsoft Entra-verificatie.
Niemand, met inbegrip van de Global Beheer istrator, heeft toegang tot de referenties, die niet per ongeluk kunnen worden gelekt door in code te worden opgenomen.
Beheerde identiteiten gebruiken
Beheerde identiteiten zijn het meest geschikt voor communicatie tussen services die ondersteuning bieden voor Microsoft Entra-verificatie. Een bronsysteem vraagt toegang tot een doelservice aan. Elke Azure-resource kan een bronsysteem zijn. Een virtuele Azure-machine (VM), een Azure Function-exemplaar en Azure-app Services-exemplaren ondersteunen bijvoorbeeld beheerde identiteiten.
Meer informatie in de video: Waarvoor kan een beheerde identiteit worden gebruikt?
Verificatie en autorisatie
Met beheerde identiteiten verkrijgt het bronsysteem een token van Microsoft Entra-id zonder eigenaarsreferentiebeheer. Azure beheert de referenties. Tokens die door het bronsysteem worden verkregen, worden gepresenteerd aan het doelsysteem voor verificatie.
Het doelsysteem verifieert en autoriseert het bronsysteem om toegang toe te staan. Als de doelservice Microsoft Entra-verificatie ondersteunt, accepteert deze een toegangstoken dat is uitgegeven door Microsoft Entra ID.
Azure heeft een besturingsvlak en een gegevensvlak. U maakt resources in het besturingsvlak en opent ze in het gegevensvlak. U maakt bijvoorbeeld een Azure Cosmos DB-database in het besturingsvlak, maar voert een query uit in het gegevensvlak.
Nadat het doelsysteem het token voor verificatie heeft geaccepteerd, ondersteunt het mechanismen voor autorisatie voor het besturingsvlak en het gegevensvlak.
Bewerkingen in het Azure-besturingsvlak worden beheerd door Azure Resource Manager en gebruiken op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC). In het gegevensvlak hebben doelsystemen autorisatiemechanismen. Azure Storage ondersteunt Azure RBAC op het gegevensvlak. Toepassingen die gebruikmaken van Azure App Services kunnen bijvoorbeeld gegevens lezen uit Azure Storage en toepassingen die gebruikmaken van Azure Kubernetes Service kunnen geheimen lezen die zijn opgeslagen in Azure Key Vault.
Meer informatie:
- Wat is Azure Resource Manager?
- Wat is Azure RBAC op basis van rollen?
- Azure-besturingsvlak en -gegevensvlak
- Azure-services die beheerde identiteiten kunnen gebruiken voor toegang tot andere services
Door het systeem toegewezen en door de gebruiker toegewezen beheerde identiteiten
Er zijn twee typen beheerde identiteiten, systeem- en door de gebruiker toegewezen.
Door het systeem toegewezen beheerde identiteit:
- Een-op-een-relatie met de Azure-resource
- Er is bijvoorbeeld een unieke beheerde identiteit gekoppeld aan elke VIRTUELE machine
- Gekoppeld aan de levenscyclus van Azure-resources. Wanneer de resource wordt verwijderd, wordt de beheerde identiteit die eraan is gekoppeld, automatisch verwijderd.
- Deze actie elimineert het risico van zwevende accounts
Door de gebruiker toegewezen beheerde identiteit
- De levenscyclus is onafhankelijk van een Azure-resource. U beheert de levenscyclus.
- Wanneer de Azure-resource wordt verwijderd, wordt de toegewezen door de gebruiker toegewezen beheerde identiteit niet automatisch verwijderd
- Door de gebruiker toegewezen beheerde identiteit toewijzen aan nul of meer Azure-resources
- Maak vooraf een identiteit en wijs deze later toe aan een resource
Service-principals voor beheerde identiteit zoeken in Microsoft Entra-id
Als u beheerde identiteiten wilt zoeken, kunt u het volgende gebruiken:
- Pagina Bedrijfstoepassingen in Azure Portal
- Microsoft Graph
Azure Portal
Selecteer in azure Portal in het linkernavigatievenster Microsoft Entra-id.
Selecteer Bedrijfstoepassingen in het linkernavigatievenster.
Selecteer in de kolom Toepassingstype onder Waarde de pijl-omlaag om Beheerde identiteiten te selecteren.
Microsoft Graph
Gebruik de volgende GET-aanvraag voor Microsoft Graph om een lijst met beheerde identiteiten in uw tenant op te halen.
https://graph.microsoft.com/v1.0/servicePrincipals?$filter=(servicePrincipalType eq 'ManagedIdentity')
U kunt deze aanvragen filteren. Zie GET servicePrincipal voor meer informatie.
Beveiliging van beheerde identiteiten evalueren
Ga als volgende te werk om de beveiliging van beheerde identiteiten te evalueren:
Bevoegdheden controleren om ervoor te zorgen dat het model met minimale bevoegdheden is geselecteerd
- Gebruik de volgende Microsoft Graph-cmdlet om de machtigingen op te halen die zijn toegewezen aan uw beheerde identiteiten:
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId <String>Zorg ervoor dat de beheerde identiteit geen deel uitmaakt van een bevoorrechte groep, zoals een beheerdersgroep.
- Ga als volgt te werk om de leden van uw groepen met hoge bevoegdheden op te sommen met Microsoft Graph:
Get-MgGroupMember -GroupId <String> [-All <Boolean>] [-Top <Int32>] [<CommonParameters>]
Verplaatsen naar beheerde identiteiten
Als u een service-principal of een Microsoft Entra-gebruikersaccount gebruikt, evalueert u het gebruik van beheerde identiteiten. U kunt voorkomen dat referenties moeten worden beveiligd, gedraaid en beheerd.
Volgende stappen
- Wat zijn beheerde identiteiten voor Azure-resources?
- Beheerde identiteiten configureren voor Azure-resources op een VIRTUELE machine met behulp van Azure Portal
Serviceaccounts