Autentiseringsmetoder som stöds av Azure OpenAI
Azure OpenAI stöder flera autentiseringsmetoder för att säkerställa säker och kontrollerad åtkomst till dess resurser. De primära metoderna är:
- API-nycklar: Azure OpenAI stöder även API-nyckelbaserad autentisering. API-nycklar genereras inom Azure Portal och kan användas för att autentisera begäranden till Azure OpenAI-tjänsten. Den här autentiseringsmetoden rekommenderas inte ur ett säkerhetsperspektiv och bör endast användas som en sista utväg. Om du måste använda den här autentiseringsmetoden är det viktigt att hantera API-nycklar på ett säkert sätt och rotera dem regelbundet för att minska risken för obehörig åtkomst.
- Microsoft Entra-ID: Den här metoden utnyttjar de robusta funktionerna för identitets- och åtkomsthantering i Microsoft Entra. Användare och program autentiserar med Hjälp av Microsoft Entra-identiteter, som kan vara traditionella användarkonton eller hanterade identiteter. Den här metoden säkerställer att endast autentiserade och auktoriserade användare kan komma åt Azure OpenAI-resurserna.
- Entra-hanteradeidentiteter: Hanterade identiteter för Azure-resurser tillhandahåller en automatiskt hanterad identitet i Microsoft Entra för program som ska användas vid anslutning till resurser som stöder Microsoft Entra-autentisering. Dessa identiteter kan systemtilldelas, vilket innebär att de är knutna till en specifik Azure-resurs, eller användartilldelade, vilket gör att en enda identitet kan delas mellan flera resurser. Hanterade identiteter förenklar hanteringen av autentiseringsuppgifter och förbättrar säkerheten genom att eliminera behovet av hårdkodade autentiseringsuppgifter i programkoden.
Varför hanterade identiteter är säkrare än API-nycklar
Hanterade identiteter i Microsoft Azure erbjuder ett säkrare alternativ till API-nycklar av flera skäl:
- Hanterade identiteter eliminerar behovet av att utvecklare hanterar autentiseringsuppgifter direkt, vilket minskar risken för oavsiktlig exponering eller missbruk.
- När du använder API-nycklar måste utvecklare bädda in dessa nycklar i sin programkod eller konfigurationsfiler.
API-nycklar kan oavsiktligt exponeras via källkodslagringsplatser, loggar eller på annat sätt. Den här exponeringen kan leda till obehörig åtkomst och potentiella säkerhetsöverträdelser. Hanterade identiteter ger däremot en automatiskt hanterad identitet som program kan använda när de ansluter till resurser som stöder Microsoft Entra-autentisering (tidigare Azure AD). Det innebär att autentiseringsuppgifter inte lagras i programkoden, vilket minskar risken för läckor och obehörig åtkomst.
Dessutom effektiviserar hanterade identiteter autentiseringsprocessen genom att låta Azure-tjänster autentisera till andra Azure-tjänster på ett säkert sätt utan att det behövs explicita autentiseringsuppgifter. Detta uppnås genom att använda token som utfärdats av Microsoft Entra, som hanteras och roteras automatiskt, vilket säkerställer att autentiseringsuppgifterna alltid är uppdaterade och minskar risken för stöld av autentiseringsuppgifter. API-nycklar är å andra sidan statiska och kräver manuell rotation, vilket kan vara felbenäget och ofta försummat, vilket leder till potentiella sårbarheter. Med hjälp av hanterade identiteter kan utvecklare utnyttja Azures inbyggda säkerhetsfunktioner, till exempel rollbaserad åtkomstkontroll (RBAC), för att ge exakta behörigheter till resurser, vilket ytterligare förbättrar säkerheten.
Microsoft rekommenderar att du använder Hanterad identitet över API-nycklar när du autentiserar till Azure OpenAI eller någon annan Azure-tjänst som stöder hanterad identitet.
Skillnader mellan att använda API-nycklar och hanterade identiteter i Azure OpenAI
Nu ska vi utvärdera effekten av ett läckt klient-ID jämfört med en läckt API-nyckel.
En API-nyckel fungerar på samma sätt som ett vanligt lösenord. Om den komprometteras kan alla med nyckeln komma åt resursen. För Azure OpenAI innebär detta obegränsad användning av AI-modeller som GPT-4. Om nätverket är offentligt tillgängligt kan säkerhetspåverkan bli ännu större.
Om klient-ID:t däremot läcker ut är riskerna minimala. Det beror på att enbart klient-ID:t inte kan upprätta en anslutning till Azure OpenAI. Om du vill använda en hanterad identitet måste tjänsten fungera i Azure och även om Azure OpenAI är offentligt kan du inte ansluta från en lokal miljö eller över ett nätverk med hjälp av ett program.
Sammanfattningsvis, jämfört med konsekvenserna av en läckt API-nyckel, innebär utnyttjandet av ett läckt klient-ID flera steg, vilket gör det svårare för skadliga aktörer att utnyttja.
Därför erbjuder hanterade identiteter en säkrare metod för att hantera åtgärder jämfört med API-nycklar. Vi rekommenderar att du använder hanterad identitet över API-nycklar när du autentiserar till Azure OpenAI eller någon annan Azure-tjänst som stöder hanterad identitet.
System- och användartilldelade identiteter
När du skapar ett Azure OpenAI-program är det viktigt att förstå skillnaden mellan systemtilldelade och användartilldelade identiteter för optimal säkerhet och resurshantering.
- Systemtilldelade identiteter skapas och hanteras av Azure för en specifik resurs. När en resurs tas bort tas även dess associerade systemtilldelade identitet bort, vilket säkerställer att identitetens livscykel är nära kopplad till den resurs som den tillhör. Den här typen av identitet är perfekt för scenarier där identiteten bara behöver användas av en enda resurs, vilket ger enkelhet och minskar den administrativa kostnaden eftersom Azure hanterar identitetens autentiseringsuppgifter.
- Användartilldelade identiteter skapas oberoende av en specifik resurs och kan delas mellan flera resurser. Detta gör dem mycket mångsidiga för program som kräver en konsekvent identitet för olika resurser, vilket möjliggör enklare hantering av behörigheter och åtkomstkontroller. Användartilldelade identiteter bevaras även efter att de resurser som använder dem har tagits bort, vilket ger större flexibilitet när det gäller att distribuera om och återanvända identiteter.
Valet mellan systemtilldelade och användartilldelade identiteter beror på programmets specifika behov. För program med en resurs där enkelhet och minimal hantering är prioriteringar är systemtilldelade identiteter vanligtvis det bästa valet. För program som kräver en delad identitet mellan flera resurser ger användartilldelade identiteter däremot större flexibilitet och återanvändning.
