Hanterad identitet för Azure AI-tjänster: Varför du borde sluta använda API-nycklar

Problemet med API-nycklar

Varje Azure AI-tjänst genererar två API-nycklar som standard. Kopiera en till din appkonfiguration och du är igång. Snabbt att sätta upp, men inte säkert att behålla.

API-nycklar är statiska hemligheter. De förfaller inte om du inte manuellt roterar dem. De hamnar i Git-repon, klistras in i Slack-meddelanden och hårdkodas i miljövariabler som ingen uppdaterar. Om en nyckel läcker kan vem som helst med den strängen anropa din Azure OpenAI-endpoint eller fråga ditt AI Search-index. På din räkning.

Hanterad identitet eliminerar denna risk. Istället för att skicka en hemlighet autentiserar din Azure-resurs genom Entra ID, och Azure hanterar tokenutbytet bakom kulisserna. Inga nycklar att rotera, inga hemligheter att läcka, inga autentiseringsuppgifter i din kod.

Systemtilldelad vs användartilldelad

Azure erbjuder två typer av hanterad identitet:

• Systemtilldelad skapas automatiskt när du aktiverar den på en resurs. Identitetens livscykel är knuten till resursen. Raderar du App Service:n försvinner identiteten med den. Det enklaste alternativet för de flesta scenarion.
• Användartilldelad är en fristående Azure-resurs som du skapar separat och kopplar till en eller flera resurser. Använd detta när flera tjänster behöver samma behörigheter, eller när identiteten behöver finnas kvar oberoende av en enskild resurs.

För en enskild applikation som anropar Azure OpenAI är systemtilldelad rätt standardval. För en mikrotjänstarkitektur där fem appar behöver samma AI Search-index undviker användartilldelad att du hanterar fem separata rolltilldelningar.

Aktivera hanterad identitet och tilldela roller

Så här sätter du upp hanterad identitet för Azure OpenAI, steg för steg.

De viktigaste RBAC-rollerna för Azure AI-tjänster:

• Cognitive Services OpenAI User för inferensanrop (chatt, completions, embeddings)
• Cognitive Services OpenAI Contributor ger även möjlighet att hantera modelldistributioner
• Cognitive Services User täcker alla Cognitive Services-typer (bredare omfång)
• Search Index Data Reader för att fråga Azure AI Search-index

Samma mönster för Document Intelligence och AI Search

Mönstret är identiskt för alla Azure AI-tjänster: aktivera hanterad identitet på beräkningsresursen, tilldela sedan rätt RBAC-roll på måltjänsten. Det enda som ändras är rollnamnet.

Rolltilldelning med Bicep

Om du driftsätter infrastruktur med Bicep är rolltilldelningar deklarativa:

GUID:et 5e0bd9bd-7b93-4f28-af87-19fc36ad61bd är det inbyggda rolldefinitions-ID:t för Cognitive Services OpenAI User. Alla inbyggda roll-ID:n finns listade i Azure RBAC-dokumentationen.

Inaktivera API-nyckelåtkomst

När hanterad identitet fungerar kan du inaktivera API-nyckelautentisering helt. Detta tar bort attackytan fullständigt:

Efter detta fungerar bara Entra ID-tokens. Alla försök att autentisera med en API-nyckel returnerar 403.

Byta över befintliga applikationer

För nya driftsättningar, börja med hanterad identitet från dag ett. För befintliga applikationer som körs med API-nycklar:

• Aktivera hanterad identitet och sätt upp RBAC-roller parallellt med den befintliga API-nyckeln
• Uppdatera din applikationskod till att använda DefaultAzureCredential (mer om detta i nästa inlägg)
• Testa noggrant i en staging-miljö
• Inaktivera API-nyckelåtkomst i produktion när du är säker

Båda autentiseringsmetoderna kan samexistera under migreringen, vilket ger dig en säker återställningsväg. Du behöver inte byta allt på en gång.

Vidare läsning

För mer detaljer, se Azure OpenAI-dokumentation om hanterade identiteter och inbyggda RBAC-roller för Cognitive Services.