Aanbevelingen voor best practices voor beheerde identiteit

Beheerde identiteiten voor Azure-resources is een functie van Microsoft Entra ID. Voor alle Azure-services die beheerde identiteiten voor Azure-resources ondersteunen, geldt een eigen tijdlijn. Controleer de beschikbaarheidsstatus van beheerde identiteiten voor uw resource en eventuele bekende problemen voordat u begint.

Kiezen tussen door een systeem toegewezen beheerde identiteiten en door een gebruiker toegewezen beheerde identiteiten

Door de gebruiker toegewezen beheerde identiteiten zijn efficiënter in een breder scala aan scenario's dan door het systeem toegewezen beheerde identiteiten. Zie de onderstaande tabel voor een aantal scenario's en de aanbevelingen voor door de gebruiker toegewezen en door het systeem toegewezen identiteiten.

Door de gebruiker toegewezen identiteiten kunnen door meerdere resources worden gebruikt. Hun levenscycli staan los van de levenscycli van de resources waaraan ze zijn gekoppeld. Lees welke resources beheerde identiteiten ondersteunen.

Met deze levenscyclus kunt u de taken voor het maken van resources en beheren van identiteiten scheiden. Door de gebruiker toegewezen identiteiten en de bijbehorende roltoewijzingen kunnen eerder worden geconfigureerd dan de resources waarvoor ze nodig zijn. Gebruikers die de resources maken, hebben alleen toegang nodig om een door de gebruiker toegewezen identiteit toe te wijzen, zonder dat er nieuwe identiteiten of roltoewijzingen hoeven te worden gemaakt.

Omdat door het systeem toegewezen identiteiten samen met de resource worden gemaakt en verwijderd, kunnen roltoewijzingen niet vooraf worden gemaakt. Deze reeks kan fouten veroorzaken tijdens het implementeren van de infrastructuur als de gebruiker die de resource maakt, geen toegang heeft tot het maken van roltoewijzingen.

Als uw infrastructuur vereist dat meerdere resources toegang hebben tot dezelfde resources, kan er één door de gebruiker toegewezen identiteit aan ze worden toegewezen. De overhead voor beheer wordt verlaagd, omdat er minder afzonderlijke identiteiten en roltoewijzingen zijn om te beheren.

Als u een eigen identiteit voor elke resource wilt, of als u resources hebt waarvoor een unieke set machtigingen is vereist en u wilt dat de identiteit wordt verwijderd wanneer de resource wordt verwijderd, gebruikt u een door het systeem toegewezen identiteit.

Scenario	Aanbeveling	Opmerkingen
Snel resources maken (bijvoorbeeld tijdelijke computing) met beheerde identiteiten	Door de gebruiker toegewezen identiteit	Als u in korte tijd meerdere beheerde identiteiten probeert te maken, bijvoorbeeld het implementeren van meerdere virtuele machines met hun eigen door het systeem toegewezen identiteit, kunt u de frequentielimiet voor het maken van Microsoft Entra-objecten overschrijden en mislukt de aanvraag met een HTTP 429-fout. Als resources snel worden gemaakt of verwijderd, kunt u ook de limiet voor het aantal resources in Microsoft Entra-id overschrijden als u door het systeem toegewezen identiteiten gebruikt. Hoewel een verwijderde door het systeem toegewezen identiteit niet meer toegankelijk is voor resources, wordt deze wel meegeteld bij uw limiet totdat deze na 30 dagen volledig is opgeschoond. Voor het implementeren van de resources die zijn gekoppeld aan één door de gebruiker toegewezen identiteit, is het maken van slechts één service-principal in Microsoft Entra-id vereist, waardoor de frequentielimiet wordt vermeden. Het gebruik van één identiteit die vooraf wordt gemaakt, verkleint ook het risico op replicatievertragingen die kunnen optreden als er meerdere resources met elk een eigen identiteit worden gemaakt. Meer informatie over de servicelimieten voor Azure-abonnementen.
Gerepliceerde resources/toepassingen	Door de gebruiker toegewezen identiteit	Resources die dezelfde taak uitvoeren, bijvoorbeeld dubbele webservers of identieke functionaliteit die wordt uitgevoerd in een app-service en in een toepassing op een virtuele machine, hebben doorgaans dezelfde machtigingen nodig. Als u dezelfde door de gebruiker toegewezen identiteit gebruikt, zijn er minder roltoewijzingen nodig, waardoor de overhead voor beheer wordt verlaagd. De resources hoeven niet van hetzelfde type te zijn.
Naleving	Door de gebruiker toegewezen identiteit	Als uw organisatie vereist dat alle identiteiten via een goedkeuringsproces worden gemaakt, zijn er bij het gebruik van één door de gebruiker toegewezen identiteit voor meerdere resources minder goedkeuringen nodig dan bij door het systeem toegewezen identiteiten, die worden gemaakt wanneer er nieuwe resources worden gemaakt.
Toegang vereist voordat een resource wordt geïmplementeerd	Door de gebruiker toegewezen identiteit	Sommige resources hebben mogelijk toegang tot bepaalde Azure-resources nodig als onderdeel van hun implementatie. In dit geval wordt een door het systeem toegewezen identiteit mogelijk niet op tijd gemaakt. Daarom moet er een bestaande door de gebruiker toegewezen identiteit worden gebruikt.
Auditlogboekregistratie	Door het systeem toegewezen identiteit	Als u wilt vastleggen welke specifieke resource een actie heeft uitgevoerd, in plaats van welke identiteit, gebruikt u een door het systeem toegewezen identiteit.
Levenscyclusbeheer voor machtigingen	Door het systeem toegewezen identiteit	Als u wilt dat de machtigingen voor een resource samen met de resource worden verwijderd, gebruikt u een door het systeem toegewezen identiteit.

Door de gebruiker toegewezen identiteiten gebruiken om de beheertijd te verminderen

De diagrammen tonen het verschil tussen door het systeem toegewezen en door de gebruiker toegewezen identiteiten, wanneer deze worden gebruikt om verschillende virtuele machines toegang te geven tot twee opslagaccounts.

Het diagram toont vier virtuele machines met door het systeem toegewezen identiteiten. Elke virtuele machine heeft dezelfde roltoewijzingen waarmee ze toegang hebben tot twee opslagaccounts.

Wanneer een door de gebruiker toegewezen identiteit aan de vier virtuele machines wordt gekoppeld, zijn er slechts twee roltoewijzingen vereist, vergeleken met acht bij door het systeem toegewezen identiteiten. Als de identiteit van de virtuele machines meer roltoewijzingen vereist, worden deze toegewezen aan alle resources die aan deze identiteit zijn gekoppeld.

Beveiligingsgroepen kunnen ook worden gebruikt om het aantal vereiste roltoewijzingen te verminderen. In dit diagram ziet u vier virtuele machines met door het systeem toegewezen identiteiten, die zijn toegevoegd aan een beveiligingsgroep. De roltoewijzingen zijn toegevoegd aan de groep in plaats van aan de door het systeem toegewezen identiteiten. Hoewel het resultaat vergelijkbaar is, biedt deze configuratie niet dezelfde mogelijkheden met Resource Manager-sjablonen als door de gebruiker toegewezen identiteiten.

Meerdere beheerde identiteiten

Resources die beheerde identiteiten ondersteunen, kunnen zowel een door het systeem toegewezen identiteit als een of meerdere door de gebruiker toegewezen identiteiten hebben.

Dit model biedt de flexibiliteit om een gedeelde, door de gebruiker toegewezen identiteit te gebruiken en om waar nodig gedetailleerde machtigingen toe te passen.

In het onderstaande voorbeeld hebben 'Virtual Machine 3' en 'Virtual Machine 4' toegang tot beide opslagaccounts en sleutelkluizen, afhankelijk van welke door de gebruiker toegewezen identiteit ze gebruiken tijdens het verifiëren.

In het onderstaande voorbeeld heeft Virtual Machine 4 meerdere door de gebruiker toegewezen identiteiten, waardoor de VM toegang heeft tot beide opslagaccounts dn sleutelkluizen, afhankelijk van de identiteit die wordt gebruikt tijdens het verifiëren. De roltoewijzingen voor de door het systeem toegewezen identiteit zijn specifiek voor die virtuele machine.

Limieten

Bekijk de limieten voor beheerde identiteiten en voor aangepaste rollen en roltoewijzingen.

Het principe van minimale bevoegdheden volgen bij het verlenen van toegang

Wanneer u een (beheerde) identiteit machtigingen toekent voor toegang tot services, verleent u altijd de minimale machtigingen die nodig zijn om de gewenste acties uit te voeren. Als een beheerde identiteit bijvoorbeeld wordt gebruikt om gegevens uit een opslagaccount te lezen, hoeft u die identiteit niet toe te staan om ook gegevens naar het opslagaccount te schrijven. Wanneer u extra machtigingen verleent, bijvoorbeeld door van de beheerde identiteit een inzender voor een Azure-abonnement te maken wanneer dat niet nodig is, vergroot u de beveiligingsradius van de identiteit. Probeer de straal van de beveiliging altijd zo klein mogelijk te houden, zodat er minimale schade optreedt wanneer de identiteit in gevaar komt.

Overweeg het effect van het toewijzen van beheerde identiteiten aan Azure-resources en/of het verlenen van toewijzingsmachtigingen aan een gebruiker

Wanneer aan een Azure-resource, zoals een logische Azure-app, een Azure-functie of een virtuele machine, een beheerde identiteit wordt toegewezen, worden alle machtigingen die aan de beheerde identiteit zijn verleend, beschikbaar voor de Azure-resource. Dit is belangrijk, want als een gebruiker toegang heeft om code op deze resource te installeren of uit te voeren, heeft de gebruiker toegang tot alle identiteiten die zijn toegewezen/gekoppeld aan de Azure-resource. Het doel van een beheerde identiteit is om code die wordt uitgevoerd op een Azure-resource toegang te geven tot andere resources, zonder dat ontwikkelaars referenties rechtstreeks in code hoeven te verwerken om die toegang te krijgen.

Als een beheerde identiteit (ClientId = 1234) bijvoorbeeld lees-/schrijftoegang heeft gekregen tot StorageAccount7755 en is toegewezen aan LogicApp3388, kan Alice, die geen directe toegang heeft tot het opslagaccount, maar is gemachtigd om code uit te voeren in LogicApp3388 ook gegevens lezen/schrijven naar/van StorageAccount7755 door de code uit te voeren die gebruikmaakt van de beheerde identiteit.

Als Alice machtigingen heeft om de beheerde identiteit zelf toe te wijzen, kan ze deze toewijzen aan een andere Azure-resource en toegang hebben tot alle machtigingen die beschikbaar zijn voor de beheerde identiteit.

Over het algemeen geldt dat wanneer u een gebruiker beheerderstoegang verleent tot een resource die code kan uitvoeren (zoals een logische app) en een beheerde identiteit heeft, u moet controleren of de rol die aan de gebruiker wordt toegewezen, code op de resource kan installeren of uitvoeren. Als dit het geval is, wijs die rol dan alleen toe als de gebruiker deze echt nodig heeft.

Onderhoud

Door het systeem toegewezen identiteiten worden automatisch verwijderd wanneer de resource wordt verwijderd, terwijl de levenscyclus van een door de gebruiker toegewezen identiteit onafhankelijk is van de resources waaraan deze is gekoppeld.

U moet een door de gebruiker toegewezen identiteit handmatig verwijderen wanneer deze niet meer nodig is, zelfs als er geen resources aan zijn gekoppeld.

Roltoewijzingen worden niet automatisch verwijderd wanneer door het systeem toegewezen beheerde identiteiten of door de gebruiker toegewezen beheerde identiteiten worden verwijderd. Deze roltoewijzingen moeten handmatig worden verwijderd om de limiet van roltoewijzingen per abonnement niet te overschrijden.

Roltoewijzingen die zijn gekoppeld aan verwijderde beheerde identiteiten, worden in de portal weergegeven met 'Identiteit niet gevonden'. Meer informatie.

Roltoewijzingen die niet meer aan een gebruiker of service-principal zijn gekoppeld, worden weergegeven met de ObjectType-waarde Unknown. Als u ze wilt verwijderen, kunt u verschillende Azure PowerShell-opdrachten samenvoegen om eerst alle roltoewijzingen op te halen, ze vervolgens te filteren op alleen die met de ObjectType-waarde Unknown, en deze roltoewijzingen ten slotte uit Azure te verwijderen.

Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment 

Het gebruik van beheerde identiteiten voor autorisatie beperken

Het gebruik van Microsoft Entra ID-groepen voor het verlenen van toegang tot services is een uitstekende manier om het autorisatieproces te vereenvoudigen. Het idee is eenvoudig: verleen machtigingen aan een groep en voeg identiteiten aan de groep toe, zodat ze dezelfde machtigingen overnemen. Dit is een bekend patroon van verschillende on-premises systemen en werkt goed wanneer de identiteiten gebruikers vertegenwoordigen. Een andere optie voor het beheren van autorisatie in Microsoft Entra ID is met behulp van app-rollen, waarmee u rollen kunt declareren die specifiek zijn voor een app (in plaats van groepen, die een globaal concept in de directory zijn). Vervolgens kunt u app-rollen toewijzen aan beheerde identiteiten (en aan gebruikers of groepen).

In beide gevallen is voor niet-menselijke identiteiten, zoals Microsoft Entra Applications en Beheerde identiteiten, het exacte mechanisme voor hoe deze autorisatie-informatie aan de toepassing wordt gepresenteerd, momenteel niet ideaal. De implementatie van vandaag met Microsoft Entra ID en Op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) maakt gebruik van toegangstokens die zijn uitgegeven door Microsoft Entra ID voor verificatie van elke identiteit. Als de identiteit wordt toegevoegd aan een groep of rol, wordt dit uitgedrukt als claims in het toegangstoken dat is uitgegeven door Microsoft Entra ID. Azure RBAC gebruikt deze claims om de autorisatieregels voor het toestaan of weigeren van toegang verder te evalueren.

Aangezien de groepen en rollen van de identiteit claims in het toegangstoken zijn, worden eventuele autorisatiewijzigingen pas van kracht nadat het token is vernieuwd. Voor een menselijke gebruiker is dat meestal geen probleem, omdat een gebruiker een nieuw toegangstoken kan ophalen door zich af te melden en opnieuw aan te melden (of te wachten tot de levensduur van het token, die standaard 1 uur is, is verlopen). Tokens voor beheerde identiteiten worden echter in de cache opgeslagen door de onderliggende Azure-infrastructuur voor prestatie- en tolerantiedoeleinden: de back-endservices voor beheerde identiteiten onderhouden ongeveer 24 uur een cache per resource-URI. Dit betekent dat het enkele uren kan duren voordat wijzigingen in de groep of het rollidmaatschap van een beheerde identiteit van kracht worden. Het is momenteel niet mogelijk om af te dwingen dat het token van een beheerde identiteit vóór de vervaldatum wordt vernieuwd. Als u de groep of het rollidmaatschap van een beheerde identiteit wijzigt om machtigingen toe te voegen of te verwijderen, moet u mogelijk enkele uren wachten totdat de Azure-resource die de identiteit gebruikt, de juiste toegang heeft.

Als deze vertraging niet acceptabel is voor u, kunt u alternatieven voor het gebruik van groepen of rollen in het token overwegen. Om ervoor te zorgen dat wijzigingen in machtigingen voor beheerde identiteiten snel van kracht worden, raden we u aan Azure-resources te groeperen met behulp van een door de gebruiker toegewezen beheerde identiteit met machtigingen die rechtstreeks op de identiteit zijn toegepast, in plaats van toe te voegen aan of te verwijderen van beheerde identiteiten uit een Microsoft Entra-groep die machtigingen heeft. Een door de gebruiker toegewezen beheerde identiteit kan worden gebruikt als een groep, omdat deze kan worden toegewezen aan een of meer Azure-resources voor gebruik. De toewijzingsbewerking kan worden beheerd met behulp van de rollen inzender voor beheerde identiteit en operator voor beheerde identiteit.