Verificatiemethoden die worden ondersteund door Azure OpenAI
Azure OpenAI ondersteunt verschillende verificatiemethoden om veilige en gecontroleerde toegang tot de resources te garanderen. De primaire methoden zijn:
- API-sleutels: Azure OpenAI biedt ook ondersteuning voor verificatie op basis van API-sleutels. API-sleutels worden gegenereerd in Azure Portal en kunnen worden gebruikt voor het verifiëren van aanvragen voor de Azure OpenAI-service. Deze verificatiemethode wordt niet aanbevolen vanuit het oogpunt van beveiliging en mag alleen worden gebruikt als laatste redmiddel. Als u deze verificatiemethode moet gebruiken, is het belangrijk om API-sleutels veilig te verwerken en periodiek te roteren om het risico op onbevoegde toegang te beperken.
- Microsoft Entra-id: Deze methode maakt gebruik van de robuuste mogelijkheden voor identiteits- en toegangsbeheer van Microsoft Entra. Gebruikers en toepassingen verifiëren met behulp van Microsoft Entra-identiteiten. Dit kunnen traditionele gebruikersaccounts of beheerde identiteiten zijn. Deze methode zorgt ervoor dat alleen geverifieerde en geautoriseerde gebruikers toegang hebben tot de Azure OpenAI-resources.
- EntraManaged Identities: Beheerde identiteiten voor Azure-resources bieden een automatisch beheerde identiteit in Microsoft Entra voor toepassingen die kunnen worden gebruikt bij het maken van verbinding met resources die Ondersteuning bieden voor Microsoft Entra-verificatie. Deze identiteiten kunnen worden toegewezen aan het systeem, wat betekent dat ze zijn gekoppeld aan een specifieke Azure-resource of door de gebruiker toegewezen, waardoor één identiteit kan worden gedeeld over meerdere resources. Beheerde identiteiten vereenvoudigen het beheer van referenties en verbeteren de beveiliging door de noodzaak van in code vastgelegde referenties in toepassingscode te elimineren.
Waarom beheerde identiteiten veiliger zijn dan API-sleutels
Beheerde identiteiten in Microsoft Azure bieden om verschillende redenen een veiliger alternatief voor API-sleutels:
- Beheerde identiteiten elimineren de noodzaak voor ontwikkelaars om referenties rechtstreeks te verwerken, waardoor het risico op onbedoelde blootstelling of misbruik wordt verminderd.
- Bij het gebruik van API-sleutels moeten ontwikkelaars deze sleutels insluiten in hun toepassingscode of configuratiebestanden.
API-sleutels kunnen per ongeluk worden weergegeven via broncodeopslagplaatsen, logboeken of andere middelen. Deze blootstelling kan leiden tot onbevoegde toegang en mogelijke beveiligingsschendingen. Beheerde identiteiten bieden daarentegen een automatisch beheerde identiteit die toepassingen kunnen gebruiken bij het maken van verbinding met resources die ondersteuning bieden voor Microsoft Entra-verificatie (voorheen Azure AD). Dit betekent dat referenties niet worden opgeslagen in de toepassingscode, waardoor het risico op lekken en onbevoegde toegang wordt beperkt.
Bovendien stroomlijnen beheerde identiteiten het verificatieproces doordat Azure-services veilig kunnen worden geverifieerd bij andere Azure-services zonder expliciete referenties. Dit wordt bereikt door tokens te gebruiken die zijn uitgegeven door Microsoft Entra, die automatisch worden beheerd en geroteerd, zodat de referenties altijd up-to-date zijn en het risico op diefstal van referenties verminderen. API-sleutels zijn daarentegen statisch en vereisen handmatige rotatie, die foutgevoelig en vaak worden genegeerd, wat leidt tot potentiële beveiligingsproblemen. Door beheerde identiteiten te gebruiken, kunnen ontwikkelaars gebruikmaken van de ingebouwde beveiligingsfuncties van Azure, zoals op rollen gebaseerd toegangsbeheer (RBAC), om nauwkeurige machtigingen te verlenen aan resources, waardoor de beveiliging verder wordt verbeterd.
Microsoft raadt u aan managed identity te gebruiken via API-sleutels bij verificatie bij Azure OpenAI of een andere Azure-service die beheerde identiteit ondersteunt.
Verschillen tussen het gebruik van API-sleutels en beheerde identiteiten in Azure OpenAI
Laten we de impact van een gelekte client-id en een gelekte API-sleutel evalueren.
Een API-sleutel werkt op dezelfde manier als een normaal wachtwoord. Als deze is aangetast, heeft iedereen met de sleutel toegang tot de resource. Voor Azure OpenAI betekent dit onbeperkt gebruik van AI-modellen zoals GPT-4. Als het netwerk openbaar toegankelijk is, kan de beveiligingsimpact nog groter zijn.
Als de client-id echter wordt gelekt, zijn de risico's minimaal. Dit komt doordat de client-id alleen geen verbinding kan maken met Azure OpenAI. Als u een beheerde identiteit wilt gebruiken, moet de service werken in Azure en zelfs als Azure OpenAI openbaar is, kunt u geen verbinding maken vanuit een lokale omgeving of via een netwerk met behulp van een toepassing.
Samenvattend, vergeleken met de gevolgen van een gelekte API-sleutel, omvat het misbruiken van een gelekte client-id verschillende stappen, waardoor het moeilijker wordt voor kwaadwillende actoren om misbruik te maken.
Om deze redenen bieden beheerde identiteiten een veiligere methode voor het beheren van bewerkingen in vergelijking met API-sleutels. Het wordt aanbevolen in de sterkste termen die u gebruikt managed identity via API-sleutels bij verificatie bij Azure OpenAI of een andere Azure-service die beheerde identiteit ondersteunt.
Door het systeem toegewezen identiteiten versus door de gebruiker toegewezen identiteiten
Bij het bouwen van een Azure OpenAI-toepassing is het belangrijk om inzicht te krijgen in het onderscheid tussen door het systeem toegewezen en door de gebruiker toegewezen identiteiten voor optimale beveiliging en resourcebeheer.
- Door het systeem toegewezen identiteiten worden gemaakt en beheerd door Azure voor een specifieke resource. Wanneer een resource wordt verwijderd, wordt de bijbehorende door het systeem toegewezen identiteit ook verwijderd, zodat de identiteitslevenscyclus nauw is gekoppeld aan de resource waartoe deze behoort. Dit type identiteit is ideaal voor scenario's waarbij de identiteit alleen door één resource hoeft te worden gebruikt, wat eenvoud biedt en de administratieve overhead vermindert omdat Azure de referenties van de identiteit beheert.
- Door de gebruiker toegewezen identiteiten worden onafhankelijk van elke specifieke resource gemaakt en kunnen worden gedeeld over meerdere resources. Hierdoor zijn ze zeer veelzijdig voor toepassingen die een consistente identiteit vereisen voor verschillende resources, waardoor het beheer van machtigingen en toegangsbeheer eenvoudiger kan worden beheerd. Door de gebruiker toegewezen identiteiten blijven behouden, zelfs nadat de resources die ze gebruiken, zijn verwijderd, zodat u meer flexibiliteit hebt bij het opnieuw implementeren en hergebruiken van identiteiten.
Het kiezen tussen door het systeem toegewezen en door de gebruiker toegewezen identiteiten is afhankelijk van de specifieke behoeften van uw toepassing. Voor toepassingen met één resource waarbij eenvoud en minimaal beheer prioriteiten zijn, zijn door het systeem toegewezen identiteiten doorgaans de beste keuze. Omgekeerd bieden toepassingen die een gedeelde identiteit vereisen voor meerdere resources, door de gebruiker toegewezen identiteiten meer flexibiliteit en herbruikbaarheid.
