Rekommenderade metoder för hanterad identitet
Hanterade identiteter för Azure-resurser är en funktion i Microsoft Entra-ID. Alla Azure-tjänster som stöder hanterade identiteter för Azure-resurser har sin egen tidslinje. Var noga med att kontrollera tillgänglighetsstatus för hanterade identiteter för din resurs och kända problem innan du börjar.
Välja system- eller användartilldelade hanterade identiteter
Användartilldelade hanterade identiteter är effektivare i ett bredare spektrum av scenarier än systemtilldelade hanterade identiteter. Se tabellen nedan för några scenarier och rekommendationerna för användartilldelade eller systemtilldelade.
Användartilldelade identiteter kan användas av flera resurser och deras livscykel frikopplas från resursernas livscykel som de är associerade med. Läs vilka resurser som stöder hanterade identiteter.
Med den här livscykeln kan du separera ansvarsområden för resursskapande och identitetsadministration. Användartilldelade identiteter och deras rolltilldelningar kan konfigureras före de resurser som kräver dem. Användare som skapar resurserna kräver bara åtkomst för att tilldela en användartilldelad identitet, utan att behöva skapa nya identiteter eller rolltilldelningar.
Eftersom systemtilldelade identiteter skapas och tas bort tillsammans med resursen kan rolltilldelningar inte skapas i förväg. Den här sekvensen kan orsaka fel vid distribution av infrastruktur om användaren som skapar resursen inte också har åtkomst till att skapa rolltilldelningar.
Om infrastrukturen kräver att flera resurser kräver åtkomst till samma resurser kan en enda användartilldelad identitet tilldelas till dem. Administrationskostnaderna minskar eftersom det finns färre distinkta identiteter och rolltilldelningar att hantera.
Om du kräver att varje resurs har en egen identitet eller har resurser som kräver en unik uppsättning behörigheter och vill att identiteten ska tas bort när resursen tas bort, bör du använda en systemtilldelad identitet.
| Scenario | Rekommendation | Kommentar |
|---|---|---|
| Snabbt skapande av resurser (till exempel tillfällig databehandling) med hanterade identiteter | Användartilldelad identitet | Om du försöker skapa flera hanterade identiteter på kort tid – till exempel distribuera flera virtuella datorer med sin egen systemtilldelade identitet – kan du överskrida hastighetsgränsen för att skapa Microsoft Entra-objekt, och begäran misslyckas med ett HTTP 429-fel. Om resurser skapas eller tas bort snabbt kan du också överskrida gränsen för antalet resurser i Microsoft Entra-ID om du använder systemtilldelade identiteter. Även om en borttagen systemtilldelad identitet inte längre är tillgänglig för någon resurs räknas den mot din gräns tills den rensas helt efter 30 dagar. Distribution av resurser som är associerade med en enda användartilldelad identitet kräver att endast ett tjänsthuvudnamn skapas i Microsoft Entra-ID, vilket undviker hastighetsgränsen. Om du använder en enda identitet som skapas i förväg minskar också risken för replikeringsfördröjningar som kan uppstå om flera resurser skapas var och en med sin egen identitet. Läs mer om gränserna för Azure-prenumerationstjänsten. |
| Replikerade resurser/program | Användartilldelad identitet | Resurser som utför samma uppgift – till exempel duplicerade webbservrar eller identiska funktioner som körs i en apptjänst och i ett program på en virtuell dator – kräver vanligtvis samma behörigheter. Med samma användartilldelade identitet krävs färre rolltilldelningar, vilket minskar hanteringskostnaderna. Resurserna behöver inte vara av samma typ. |
| Regelefterlevnad | Användartilldelad identitet | Om din organisation kräver att alla identiteter skapas måste gå igenom en godkännandeprocess, kräver användning av en enda användartilldelad identitet över flera resurser färre godkännanden än systemtilldelade identiteter, som skapas när nya resurser skapas. |
| Åtkomst krävs innan en resurs distribueras | Användartilldelad identitet | Vissa resurser kan kräva åtkomst till vissa Azure-resurser som en del av distributionen. I det här fallet kanske en systemtilldelad identitet inte skapas i tid, så en befintlig användartilldelad identitet bör användas. |
| Granskningsloggning | Systemtilldelad identitet | Om du behöver logga vilken specifik resurs som utförde en åtgärd i stället för vilken identitet använder du en systemtilldelad identitet. |
| Livscykelhantering för behörigheter | Systemtilldelad identitet | Om du behöver att behörigheterna för en resurs tas bort tillsammans med resursen använder du en systemtilldelad identitet. |
Använda användartilldelade identiteter för att minska administrationen
Diagrammen visar skillnaden mellan systemtilldelade och användartilldelade identiteter när de används för att tillåta flera virtuella datorer att komma åt två lagringskonton.
Diagrammet visar fyra virtuella datorer med systemtilldelade identiteter. Varje virtuell dator har samma rolltilldelningar som ger dem åtkomst till två lagringskonton.
När en användartilldelad identitet är associerad med de fyra virtuella datorerna krävs endast två rolltilldelningar, jämfört med åtta med systemtilldelade identiteter. Om de virtuella datorernas identitet kräver fler rolltilldelningar beviljas de till alla resurser som är associerade med den här identiteten.
Säkerhetsgrupper kan också användas för att minska antalet rolltilldelningar som krävs. Det här diagrammet visar fyra virtuella datorer med systemtilldelade identiteter, som har lagts till i en säkerhetsgrupp, med rolltilldelningarna tillagda i gruppen i stället för systemtilldelade identiteter. Även om resultatet är liknande erbjuder den här konfigurationen inte samma Resource Manager-mallfunktioner som användartilldelade identiteter.
Flera hanterade identiteter
Resurser som stöder hanterade identiteter kan ha både en systemtilldelad identitet och en eller flera användartilldelade identiteter.
Den här modellen ger flexibiliteten att både använda en delad användartilldelad identitet och tillämpa detaljerade behörigheter vid behov.
I exemplet nedan kan "Virtual Machine 3" och "Virtual Machine 4" komma åt både lagringskonton och nyckelvalv, beroende på vilken användartilldelad identitet de använder när de autentiserar.
I exemplet nedan har "Virtual Machine 4" både en användartilldelad identitet, vilket ger den åtkomst till både lagringskonton och nyckelvalv, beroende på vilken identitet som används vid autentisering. Rolltilldelningarna för den systemtilldelade identiteten är specifika för den virtuella datorn.
Gränser
Visa gränserna för hanterade identiteter och för anpassade roller och rolltilldelningar.
Följ principen om lägsta behörighet när du beviljar åtkomst
När du beviljar någon identitet, inklusive en hanterad identitet, behörighet att komma åt tjänster, bevilja alltid de minsta behörigheter som krävs för att utföra önskade åtgärder. Om till exempel en hanterad identitet används för att läsa data från ett lagringskonto behöver du inte tillåta att identitetsbehörigheterna även skriver data till lagringskontot. Om du till exempel beviljar extra behörigheter, vilket gör den hanterade identiteten till en deltagare i en Azure-prenumeration när den inte behövs, ökar säkerhetsexplosionsradien som är associerad med identiteten. Man måste alltid minimera säkerhetsexplosionsradien så att komprometterande av identiteten orsakar minsta möjliga skada.
Överväg effekten av att tilldela hanterade identiteter till Azure-resurser och/eller bevilja tilldela behörigheter till en användare
Det är viktigt att observera att när en Azure-resurs, till exempel en Azure Logic App, en Azure-funktion eller en virtuell dator och så vidare. tilldelas en hanterad identitet, är alla behörigheter som beviljats till den hanterade identiteten nu tillgängliga för Azure-resursen. Detta är viktigt eftersom om en användare har åtkomst till att installera eller köra kod på den här resursen har användaren åtkomst till alla identiteter som tilldelats/associerats med Azure-resursen. Syftet med hanterad identitet är att ge kod som körs på en Azure-resurs åtkomst till andra resurser, utan att utvecklare behöver hantera eller placera autentiseringsuppgifter direkt i kod för att få den åtkomsten.
Om till exempel en hanterad identitet (ClientId = 1234) har beviljats läs-/skrivåtkomst till StorageAccount7755 och har tilldelats LogicApp3388 kan Alice, som inte har direkt åtkomst till lagringskontot men har behörighet att köra kod i LogicApp3388, även läsa/skriva data till/från StorageAccount7755 genom att köra koden som använder den hanterade identiteten.
Om Alice har behörighet att tilldela den hanterade identiteten själv kan hon tilldela den till en annan Azure-resurs och ha åtkomst till alla behörigheter som är tillgängliga för den hanterade identiteten.
När du beviljar en användare administrativ åtkomst till en resurs som kan köra kod (till exempel en logikapp) och har en hanterad identitet bör du överväga om rollen som tilldelas användaren kan installera eller köra kod på resursen och om ja bara tilldela rollen om användaren verkligen behöver den.
Underhåll
Systemtilldelade identiteter tas bort automatiskt när resursen tas bort, medan livscykeln för en användartilldelad identitet är oberoende av alla resurser som den är associerad med.
Du måste ta bort en användartilldelad identitet manuellt när den inte längre behövs, även om inga resurser är associerade med den.
Rolltilldelningar tas inte bort automatiskt när antingen systemtilldelade eller användartilldelade hanterade identiteter tas bort. Dessa rolltilldelningar bör tas bort manuellt så att gränsen för rolltilldelningar per prenumeration inte överskrids.
Rolltilldelningar som är associerade med borttagna hanterade identiteter visas med "Identitet hittades inte" när den visas i portalen. Läs mer.
Rolltilldelningar som inte längre är associerade med en användare eller tjänstens huvudnamn visas med värdet ObjectType Unknown. För att ta bort dem kan du skicka flera Azure PowerShell-kommandon tillsammans för att först hämta alla rolltilldelningar, filtrera till endast de som har värdet ObjectType Unknown och sedan ta bort rolltilldelningarna från Azure.
Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment
Begränsning av användning av hanterade identiteter för auktorisering
Att använda Microsoft Entra-ID-grupper för att bevilja åtkomst till tjänster är ett bra sätt att förenkla auktoriseringsprocessen. Idén är enkel – bevilja behörigheter till en grupp och lägg till identiteter i gruppen så att de ärver samma behörigheter. Detta är ett väletablerat mönster från olika lokala system och fungerar bra när identiteterna representerar användare. Ett annat alternativ för att styra auktorisering i Microsoft Entra-ID är att använda approller, vilket gör att du kan deklarera roller som är specifika för en app (i stället för grupper, som är ett globalt begrepp i katalogen). Du kan sedan tilldela approller till hanterade identiteter (samt användare eller grupper).
I båda fallen passar inte den exakta mekanismen för hur den här auktoriseringsinformationen presenteras för programmet i dag för icke-mänskliga identiteter som Microsoft Entra-program och hanterade identiteter. Dagens implementering med Microsoft Entra ID och Azure Role Based Access Control (Azure RBAC) använder åtkomsttoken som utfärdats av Microsoft Entra ID för autentisering av varje identitet. Om identiteten läggs till i en grupp eller roll uttrycks detta som anspråk i åtkomsttoken som utfärdats av Microsoft Entra ID. Azure RBAC använder dessa anspråk för att ytterligare utvärdera auktoriseringsreglerna för att tillåta eller neka åtkomst.
Med tanke på att identitetens grupper och roller är anspråk i åtkomsttoken börjar eventuella auktoriseringsändringar inte gälla förrän token har uppdaterats. För en mänsklig användare som vanligtvis inte är ett problem, eftersom en användare kan hämta en ny åtkomsttoken genom att logga ut och in igen (eller vänta på att tokens livslängd upphör att gälla, vilket är 1 timme som standard). Hanterade identitetstoken cachelagras å andra sidan av den underliggande Azure-infrastrukturen i prestanda- och återhämtningssyfte: serverdelstjänsterna för hanterade identiteter upprätthåller en cache per resurs-URI i cirka 24 timmar. Det innebär att det kan ta flera timmar innan ändringar i en hanterad identitets grupp eller rollmedlemskap börjar gälla. I dag går det inte att framtvinga att en hanterad identitetstoken uppdateras innan den upphör att gälla. Om du ändrar en hanterad identitets grupp eller rollmedlemskap för att lägga till eller ta bort behörigheter kan du därför behöva vänta flera timmar på att Azure-resursen med hjälp av identiteten ska ha rätt åtkomst.
Om den här fördröjningen inte är acceptabel för dina krav kan du överväga alternativ till att använda grupper eller roller i token. För att säkerställa att ändringar av behörigheter för hanterade identiteter börjar gälla snabbt rekommenderar vi att du grupperar Azure-resurser med hjälp av en användartilldelad hanterad identitet med behörigheter som tillämpas direkt på identiteten, i stället för att lägga till eller ta bort hanterade identiteter från en Microsoft Entra-grupp som har behörigheter. En användartilldelad hanterad identitet kan användas som en grupp eftersom den kan tilldelas till en eller flera Azure-resurser för att använda den. Tilldelningsåtgärden kan styras med hjälp av rollen Hanterad identitetsdeltagare och hanterad identitetsoperator.