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.
Beheerde identiteiten in Azure bieden een veilige en handige manier om referenties te beheren voor toepassingen die worden uitgevoerd op Azure-resources. In dit artikel vindt u aanbevelingen voor aanbevolen procedures voor het kiezen tussen door de gebruiker toegewezen en door het systeem toegewezen beheerde identiteiten, zodat u identiteitsbeheer kunt optimaliseren en administratieve overhead kunt verminderen.
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 volgende tabel voor een aantal scenario's en de aanbevelingen voor door de gebruiker toegewezen rollen of door het systeem toegewezen rollen.
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 uw verantwoordelijkheden voor het creëren van resources en het 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. Beheeroverhead wordt verminderd, 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 een resource, wordt deze meegeteld voor 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, vermindert het risico op replicatievertragingen die kunnen optreden als er meerdere resources met hun eigen identiteit worden gemaakt. Meer informatie over de servicelimieten voor Azure-abonnementen. |
| Gerepliceerde bronnen/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 worden gemaakt door een goedkeuringsproces, vereist het gebruik van één door de gebruiker toegewezen identiteit voor meerdere resources minder goedkeuringen dan door het systeem toegewezen identiteiten, die worden gemaakt als 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 kan een door het systeem toegewezen identiteit niet op tijd worden gemaakt, zodat een vooraf bestaande door de gebruiker toegewezen identiteit moet worden gebruikt. |
| Auditlogboek | 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, waarbij de roltoewijzingen aan de groep worden toegevoegd in plaats van 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 volgende voorbeeld hebben 'Virtual Machine 3' en 'Virtual Machine 4' toegang tot zowel opslagaccounts als sleutelkluizen, afhankelijk van de door de gebruiker toegewezen identiteit die ze gebruiken tijdens het verifiëren.
In het volgende voorbeeld heeft Virtual Machine 4 zowel een door de gebruiker toegewezen identiteit, waardoor deze toegang heeft tot zowel opslagaccounts als 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 deze identiteitsmachtigingen niet toe te staan 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
Het is belangrijk te weten dat wanneer een Azure-resource, zoals een logische Azure-app of een virtuele machine, een beheerde identiteit wordt toegewezen, alle machtigingen die aan de beheerde identiteit zijn verleend, nu beschikbaar zijn 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 bijvoorbeeld een beheerde identiteit (ClientId = 1234) lees-/schrijftoegang krijgt tot StorageAccount7755- en is toegewezen aan LogicApp3388, dan Alice, wie geen directe toegang heeft tot het opslagaccount, maar gemachtigd is om code uit te voeren binnen LogicApp3388- kan 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 handmatig een door de gebruiker toegewezen identiteit 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 weergegeven met 'Identiteit niet gevonden' wanneer ze worden weergegeven in de portal. Meer informatie.
Roltoewijzingen die niet meer zijn gekoppeld aan een gebruiker of service-principal, worden weergegeven met een ObjectType waarde van 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 de manier waarop 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 het groepslidmaatschap of de roltoewijzing van een beheerde identiteit van kracht worden. Tegenwoordig is het niet mogelijk om het token van een beheerde identiteit te laten vernieuwen voordat het verloopt. 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 uw vereisten, kunt u alternatieven overwegen voor het gebruik van groepen of rollen in het token. 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.