Hanterad identitet för lösenordsfri autentisering

Traditionellt ansluter program till Azure-tjänster som Storage eller Key Vault med anslutningssträngar eller API-nycklar som lagras i konfigurationsfiler eller miljövariabler. Dessa autentiseringsuppgifter kan av misstag checkas in i källkodshanteringen, exponeras i loggar eller stjälas vid ett intrång. Managed Identity eliminerar behovet av att program lagrar autentiseringsuppgifter helt och hållet – i stället utfärdar och roterar Azure själv en token för resursens räkning, och programmet ber helt enkelt Azure om den aktuella tokenen vid körning.

En Managed Identity är ett automatiskt hanterat service principal i Microsoft Entra ID som är kopplat till en Azure-resurs, till exempel en VM, App Service eller Function App. Azure-plattformen skapar och underhåller identitetens autentiseringsuppgifter – och roterar dem regelbundet – så att Er kod aldrig hanterar ett lösenord eller en hemlighet. Program som körs på resursen anropar slutpunkten för Azure Instance Metadata Service (IMDS) på http://169.254.169.254 för att hämta en kortlivad OAuth-token, som de sedan presenterar för Azure-tjänster.

Det finns två typer av managed identity: System-assigned är knuten till en enda Azure-resurs. Den skapas när Ni aktiverar den på resursen och tas automatiskt bort när resursen tas bort. User-assigned är en fristående Entra ID-identitet som Ni skapar separat och sedan kopplar till en eller flera Azure-resurser. Användartilldelade identiteter är användbara när flera tjänster (till exempel flera Function Apps) behöver dela samma identitet och RBAC-behörigheter, eftersom dubblerade rolltilldelningar då kan undvikas.

När Ni har aktiverat en managed identity måste Ni bevilja den RBAC-behörigheter på Azure-resursen i fråga. Om Ni till exempel vill tillåta att en App Service läser blobbar tilldelar Ni rollen Storage Blob Data Reader till App Servicens managed identity på lagringskontot. RBAC-tilldelningar följer principen om minsta privilegium – bevilja endast de minsta behörigheter som krävs. Tilldela aldrig Owner eller Contributor till en managed identity om det inte är absolut nödvändigt.

Azure SDK tillhandahåller klassen DefaultAzureCredential, som automatiskt provar flera autentiseringsmetoder i ordning: miljövariabler, workload identity, managed identity, Azure CLI, Visual Studio med flera. När programmet körs i Azure (App Service, VM eller Function App) använder DefaultAzureCredential automatiskt managed identity utan några kodändringar. Lokalt autentiserar utvecklare sig via sin Azure CLI-session. Denna enda autentiseringsklass fungerar i alla miljöer utan villkorslogik.

Ett vanligt mönster är att använda en managed identity för att komma åt hemligheter i Azure Key Vault under körning. I stället för att lagra ett databaslösenord i programinställningarna lagrar Ni det i Key Vault och ger appens managed identity rollen Key Vault Secrets User i det valvet. Vid starten hämtar programmet hemligheten från Key Vault med DefaultAzureCredential. Detta mönster säkerställer att hemligheter aldrig lagras i kod, konfigurationsfiler eller miljövariabler – de finns endast i Key Vault och hämtas tillfälligt.

Azure SQL Database stöder Entra ID-autentisering, vilket innebär att en managed identity kan autentisera mot SQL utan användarnamn och lösenord. Aktivera detta genom att ange en Entra ID-administratör på SQL-servern, köra en CREATE USER-instruktion i måldatabasen för managed identity-identitetens visningsnamn och tilldela den lämplig databasroll. Programmet ansluter med Azure SDK:s DefaultAzureCredential och en åtkomsttoken med omfånget https://database.windows.net/, helt utan lösenord.

I Azure Kubernetes Service kan enskilda pods hämta managed identity-tokens med hjälp av Workload Identity (efterföljaren till AAD Pod Identity). Ni skapar en användartilldelad managed identity, federerar den med AKS OIDC-utfärdaren, annoterar Kubernetes-tjänstkontot och låter Azure Workload Identity-webhooken injicera nödvändiga miljövariabler så att poddens DefaultAzureCredential kan hämta en token. Detta utökar lösenordsfri autentisering till containeriserade mikrotjänster utan att hemligheter behöver lagras i Kubernetes Secrets-objekt.

Även om autentiseringsuppgifterna för managed identity är osynliga för utvecklare loggas alla händelser för tokenutfärdande och resursåtkomst. Entra ID-inloggningsloggar registrerar varje tokenbegäran från en managed identity, inklusive vilken resurs som används, tidpunkten och om begäran lyckades. Aktivitetsloggar för Azure Storage och granskningsloggar för Key Vault registrerar de specifika åtgärder som utförts med tokenen. Dessa loggar är nödvändiga vid säkerhetsgranskningar och incidentutredningar som rör managed identities.

Om programmet för närvarande använder anslutningssträngar eller API-nycklar migrerar Ni till managed identity i tre steg: Steg 1 – Aktivera en managed identity på beräkningsresursen. Steg 2 – Tilldela identiteten lämpliga RBAC-roller på varje måltjänst. Steg 3 – Uppdatera programkoden så att den använder DefaultAzureCredential i stället för anslutningssträngen. Ta bort anslutningssträngen från App Service-konfigurationen och Key Vault när Ni har verifierat migreringen. I moderna Azure SDK-program kan denna migrering vanligtvis genomföras med minimala kodändringar.

Managed Identity ger fyra viktiga säkerhetsfördelar jämfört med autentisering baserad på autentiseringsuppgifter: Ingen lagring av autentiseringsuppgifter – inget kan stjälas eller råka checkas in. Automatisk rotation – Azure roterar de underliggande certifikaten utan driftstopp. Begränsade behörigheter – identiteter tilldelas endast de RBAC-roller de behöver enligt principen om minsta privilegium. Fullständig granskningskedja – alla åtkomstförsök loggas i Entra ID och i den åtkomstade tjänstens granskningsloggar. För alla nya Azure-tjänsteintegrationer bör managed identity vara standardmetoden för autentisering.

I den här lektionen lärde du dig följande: hanterad identitet eliminerar lagrade autentiseringsuppgifter genom att ge Azure-resurser en automatiskt hanterad identitet i Entra ID, DefaultAzureCredential i Azure SDK använder transparent hanterad identitet i Azure och utvecklarautentiseringsuppgifter lokalt, och RBAC-rolltilldelningar på måltjänster styr vad identiteten får åtkomst till. Härnäst utforskar vi Azure Service Bus för frikopplad meddelandekommunikation mellan programkomponenter.