Verificatie en autorisatie in Microsoft Foundry

Verificatie en autorisatie in Microsoft Foundry bepalen hoe principals identiteit bewijzen en toestemming krijgen om bewerkingen uit te voeren. Foundry verdeelt bewerkingen in het regelvlak (resourcebeheer) en het gegevensvlak (runtimegebruik), elk met een eigen verificatie en op rollen gebaseerd toegangsbewakingsoppervlak (RBAC).

Foundry ondersteunt twee verificatiemethoden: Microsoft Entra ID en API-sleutels. Microsoft Entra ID maakt voorwaardelijke access, beheerde identiteiten en gedetailleerde RBAC mogelijk. API-sleutels blijven beschikbaar voor snelle prototypen, maar ontbreken traceerbaarheid per gebruiker. In dit artikel worden deze methoden vergeleken, identiteiten toegewezen aan rollen en worden veelvoorkomende scenario's met minimale bevoegdheden beschreven.

Belangrijk

Gebruik Microsoft Entra ID voor productieworkloads om voorwaardelijke toegang, beheerde identiteiten en RBAC met het principe van minimale bevoegdheden in te schakelen. API-sleutels zijn handig voor snelle evaluatie, maar bieden grofkorrelige toegang.

Vereiste voorwaarden

Een Azure-abonnement. Als u nog geen account hebt, maakt u een gratis account.
Een Microsoft Foundry-resource met een aangepast subdomein geconfigureerd.
Inzicht in Azure RBAC-concepten.
Als u rollen wilt toewijzen, hebt u de rol Owner of Gebruikerstoegang-beheerder rol nodig voor de juiste scope.
(Optioneel) De Azure CLI of Azure SDK voor Python geïnstalleerd voor programmatische verificatie.
(Optioneel) Python-pakketten voor codevoorbeelden: pip install azure-identity requests

Besturingsvlak en gegevensvlak

Azure bewerkingen worden onderverdeeld in twee categorieën: besturingsvlak en gegevensvlak. Azure scheidt resourcebeheer (besturingsvlak) van operationele runtime (gegevensvlak). Daarom gebruikt u het besturingsvlak om resources in uw abonnement te beheren en gebruikt u het gegevensvlak om mogelijkheden te gebruiken die beschikbaar zijn voor uw exemplaar van een resourcetype. Zie Azure besturingsvlak en gegevensvlak voor meer informatie over besturingsvlak en gegevensvlak. In Foundry is er een duidelijk onderscheid tussen besturingsvlakbewerkingen versus gegevensvlakbewerkingen. In de volgende tabel wordt het verschil uitgelegd tussen de twee, het bereik in Foundry, typische bewerkingen van een gebruiker, voorbeeldhulpprogramma's en functies, en de autorisatie-surface om elk te gebruiken.

Vliegtuig	Bereik in Foundry	Typische bewerkingen	Voorbeeldhulpprogramma's	Autorisatie-oppervlak
beheerlaag	Resource, projecten, netwerken, versleuteling en verbindingen instellen en configureren	Resources maken of verwijderen, rollen toewijzen, sleutels draaien, Private Link instellen	Azure portal, Azure CLI, ARM-sjablonen, Bicep, Terraform	Azure RBAC-acties
Gegevensvlak	Modeldeductie uitvoeren en gebruiken, interactie tussen agents, evaluatietaken en veiligheidsoproepen voor inhoud	Chatvoltooiingen, insluitingsgeneratie, fijn-afstemmingsopdrachten starten, agentberichten verzenden, analyse- en classificatiebewerkingen uitvoeren	SDK's, REST API's, Foundry Portal-speeltuin	Azure RBAC dataActions

Zie de opslagplaats foundry-samples op GitHub voor Foundry voor alle Bicep-, Terraform- en SDK-voorbeelden.

De volgende lijsten en diagrammen illustreren de scheiding tussen besturingsvlak- en gegevensvlakacties in detail. Besturingsvlakacties in Foundry zijn onder andere:

Foundry-resource aanmaken
Foundry-project aanmaken
Account Capability Host maken
Project Mogelijkheidshost maken
Modellenimplementatie
Account- en projectverbinding maken

Acties voor het datavlak in Foundry omvatten:

Agents bouwen
Een evaluatie uitvoeren
Tracering en monitoring
Fine-tuning

In het volgende diagram ziet u de scheiding tussen het besturingsvlak en het datavlak in Foundry, samen met rolgebaseerde toegangscontrole (RBAC)-toewijzingen en welke toegang een gebruiker kan hebben in het besturingsvlak, datavlak of beide. Zoals u in het diagram ziet, worden RBAC -acties gekoppeld aan het besturingsvlak, terwijl RBAC 'dataActions' zijn gekoppeld aan het gegevensvlak.

Verificatiemethoden

Foundry ondersteunt Microsoft Entra ID (op tokens gebaseerde, sleutelloze) en API-sleutels.

Microsoft Entra ID

Microsoft Entra ID gebruikt OAuth 2.0 bearer-tokens die zijn gericht op https://ai.azure.com/.default.

Gebruik Microsoft Entra ID voor:

Productiewerkbelastingen.
Voorwaardelijke access, meervoudige verificatie (MFA) en Just-In-Time-access.
Integratie van RBAC en beheerde identiteit met minimale bevoegdheden.

Voordelen: fijnmazige roltoewijzingen, controle per principal, controleerbare tokenlevensduur, automatische geheime hygiëne en beheerde identiteiten voor services.

Beperkingen: hogere complexiteit van de eerste installatie. Vereist inzicht in op rollen gebaseerde access control (RBAC). Zie Rolgebaseerde toegangscontrole voor Microsoft Foundry voor meer informatie over RBAC in Foundry.

API-sleutels

API-sleutels zijn statische geheimen die verbonden zijn aan een Foundry-resource.

API-sleutels gebruiken voor:

Snelle prototypen.
Geïsoleerde testomgevingen waarbij het rouleren van een enkel geheim acceptabel is.

Voordelen: Eenvoudig, taalneutraal en vereist geen tokenverwerving.

Beperkingen: Kan gebruikersidentiteit niet uitdrukken, is moeilijk om gedetailleerd te bepalen en is moeilijker te controleren. Over het algemeen niet geaccepteerd door bedrijfsproductieworkloads en niet aanbevolen door Microsoft.

Zie Sleutelloze verificatie configureren met Microsoft Entra ID voor meer informatie over het inschakelen van sleutelloze verificatie.

Verifiëren met Microsoft Entra ID (Python)

In het volgende voorbeeld ziet u hoe u zich kunt verifiëren met Microsoft Entra ID met behulp van de bibliotheek azure-identity en een aanvraag kunt indienen bij een Foundry-eindpunt:

from azure.identity import DefaultAzureCredential
import requests

# Create a credential object using DefaultAzureCredential
# This automatically uses environment variables, managed identity, or Azure CLI credentials
credential = DefaultAzureCredential()

# Get an access token for the Cognitive Services scope
token = credential.get_token("https://ai.azure.com/.default")

# Use the token in your API request
headers = {
    "Authorization": f"Bearer {token.token}",
    "Content-Type": "application/json"
}

# Replace with your Foundry endpoint
endpoint = "https://<your-resource-name>.cognitiveservices.azure.com"

# Example: List deployments (adjust the path for your specific API)
response = requests.get(f"{endpoint}/openai/deployments?api-version=2024-10-21", headers=headers)
print(response.json())

Verwachte uitvoer: een JSON-antwoord met uw modelimplementaties of een verificatiefout als referenties ontbreken of als de roltoewijzing niet is geconfigureerd.

Referentie: DefaultAzureCredential | azure-identity library

Verifiëren met een API-sleutel (Python)

In het volgende voorbeeld ziet u hoe u kunt verifiëren met behulp van een API-sleutel. Gebruik deze benadering alleen voor snelle prototypen; Microsoft Entra ID wordt aanbevolen voor productie.

import requests

# Replace with your actual API key and endpoint
api_key = "<your-api-key>"
endpoint = "https://<your-resource-name>.cognitiveservices.azure.com"

headers = {
    "api-key": api_key,
    "Content-Type": "application/json"
}

# Example: List deployments
response = requests.get(f"{endpoint}/openai/deployments?api-version=2024-10-21", headers=headers)
print(response.json())

Waarschuwing

API-sleutels bieden volledige access aan de resource en kunnen niet worden afgestemd op specifieke gebruikers of acties. Wissel sleutels regelmatig en voorkom dat ze in bronbeheer worden opgeslagen.

Verwachte uitvoer: een JSON-antwoord met uw modelimplementaties of een 401-fout als de API-sleutel ongeldig is.

Referentie: Rotatie van API-toegangssleutels

Matrix voor functieondersteuning

Raadpleeg de volgende matrix om te begrijpen welke mogelijkheden in Foundry API-sleutels ten opzichte van Microsoft Entra ID ondersteunen.

Mogelijkheid of functie	API-sleutel	Microsoft Entra ID	Aantekeningen
Basismodeldeductie (chat, insluitingen)	Ja	Ja	Volledig ondersteund.
Het verfijnen van operaties	Ja	Ja	Entra ID voegt controle voor iedere principal toe.
Agentendienst	Nee.	Ja	Gebruik Entra ID voor toegang tot het hulpprogramma voor beheerde identiteit.
Evaluations	Nee.	Ja	Gebruik entra-id.
Veiligheidsgesprekken voor inhoud analyseren	Ja	Ja	Gebruik RBAC om bewerkingen met een hoog risico te beperken.
Batch-analysetaken (Inhoudskennis)	Ja	Ja	Aanbevolen Entra ID voor schaalbaarheid.
Gebruik van portalspeeltuin	Ja	Ja	Playground gebruikt project verbindingsmodus.
Netwerkisolatie met Private Link	Ja	Ja	Entra ID voegt voorwaardelijke access toe.
Principe van minimale bevoegdheden met ingebouwde en aangepaste rollen	Nee.	Ja	Sleutels zijn alles-of-niets per hulpbron.
Beheerde identiteit (door het systeem of door de gebruiker toegewezen)	Nee.	Ja	Hiermee schakelt u authenticatie zonder geheimen in.
Gebruikerstoewijzing per aanvraag	Nee.	Ja	Token bevat tenant- en object-id's.
Intrekking (onmiddellijk)	Sleutel draaien	Rol verwijderen of principal uitschakelen	Korte levensduur van tokens is van toepassing.
Ondersteuning bij automatiseringspijplijnen	Ja (geheim)	Ja (service-principal of beheerde identiteit)	Entra-id vermindert de rotatie van geheimen.
Api voor assistenten	Ja	Ja	Aanbevolen om Entra-id te gebruiken.
Batch-inferentie	Ja	Ja

Identiteitstypen

Azure resources en toepassingen worden geverifieerd met behulp van verschillende identiteitstypen, die elk zijn ontworpen voor specifieke scenario's. Gebruikersprinciplen vertegenwoordigen menselijke gebruikers, service-principals vertegenwoordigen toepassingen of geautomatiseerde processen en beheerde identiteiten bieden een veilige, referentievrije manier voor Azure resources om andere services te access. Als u deze verschillen begrijpt, kunt u de juiste identiteit kiezen voor interactieve aanmeldingen, app-naar-app-communicatie of workloadautomatisering.

Azure ondersteunt de volgende identiteitstypen.

Identiteitstype	Description
Gebruikersprincipaal	Individuele gebruiker in Microsoft Entra ID
Service principal (app-registratie)	Toepassingsidentiteit die gebruikmaakt van een clientgeheim of certificaat
Managed identity (door het systeem toegewezen)	Azure resourcegebonden identiteit automatisch beheerd door het platform.
Beheerde identiteit (door de gebruiker toegewezen)	Zelfstandige identiteit die aan meerdere resources wordt gekoppeld.

Overzicht van ingebouwde rollen

Gebruik in Foundry de ingebouwde rollen om de toegestane acties voor een gebruiker te scheiden. De meeste ondernemingen willen een scheiding van besturings- en gegevensvlakacties voor hun ingebouwde rollen. Anderen verwachten dat een gecombineerde gegevens- en besturingsvlakrol het aantal vereiste roltoewijzingen minimaliseert. De volgende tabel bevat scenario's en de bijbehorende ingebouwde Foundry-rollen die het beste bij elk scenario passen.

Scenario	Typische ingebouwde rollen	Aantekeningen
Agents bouwen met vooraf gedeployeerde modellen	AI-gebruiker Azure	Alleen gegevensvlakgebruik; geen schrijfbewerkingen voor beheer.
Implementaties beheren of modellen verfijnen	Azure AI-Projectmanager	Omvat het maken en bijwerken van de modelimplementatie.
Sleutels draaien of resource beheren	Eigenaar van AI-account Azure	Hoge bevoegdheden; overweeg een op maat gemaakte rol volgens het principe van minste bevoegdheid.
Resource beheren, implementaties beheren, buildagents beheren	Azure AI-eigenaar	Zeer bevoorrechte zelfbedieningsrol voor gebruikers die zowel toegang tot het controlevlak als het gegevensvlak nodig hebben. Combineer met Azure Monitor Reader als waarneembaarheid vereist is.
Waarneembaarheid, tracering, bewaking	Azure AI-gebruiker (minimaal)	Voeg Azure Monitor Reader toe aan Application Insights.

Bekijk het volgende diagram om inzicht te hebben in de uitsplitsing van ingebouwde rollen en de acties voor het besturings- en gegevensvlak.

Aanbeveling

Maak een aangepaste rol als een ingebouwde rol overtollige machtigingen verleent voor uw use-case.

Microsoft Entra ID instellen

Zie Sleutelloze verificatie configureren voor richtlijnen op hoog niveau voor het instellen van Entra ID-verificatie in Foundry.

Zorg ervoor dat uw Microsoft Foundry-resource een aangepast subdomein heeft geconfigureerd. Zie Custom-subdomeinen. Een aangepast subdomein is vereist voor verificatie op basis van tokens.
Wijs de benodigde ingebouwde of aangepaste rol toe aan elke principal. U heeft de rol Owner of Gebruikers Toegangsbeheerder nodig om rollen toe te wijzen. Algemene roltoewijzingen:
- Azure AI-gebruiker: voor ontwikkelaars die vooraf geïmplementeerde modellen moeten bouwen en testen.
- Azure AI Project Manager: Voor teamleiders die projecten moeten maken en implementaties moeten beheren.
- Azure AI-accounteigenaar: Voor beheerders die volledig resourcebeheer nodig hebben en Azure AI-Gebruiker voorwaardelijk kunnen toewijzen voor gegevensvlaktoegang.
- Azure AI-eigenaar: voor gebruikers die zowel volledig resourcebeheer als toegang tot het gegevensvlak nodig hebben. Voorbeeld van cli-opdracht om de Azure AI-gebruikersrol toe te wijzen:
```
az role assignment create \
  --assignee <principal-id> \
  --role "Azure AI User" \
  --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<resource-name>
```
Als u de roltoewijzing wilt controleren, voert u deze uit az role assignment list --assignee <principal-id> --scope <resource-scope> en bevestigt u dat de rol wordt weergegeven in de uitvoer.
(Optioneel) Voor een service-principal maakt u een app-registratie, voegt u een clientsleutel of certificaat toe en noteert u de tenant-id, client-id en sleutel of certificaat.
(Optioneel) Voor een beheerde identiteit schakelt u de door het systeem toegewezen identiteit in voor de aanroepende service of koppelt u een door de gebruiker toegewezen identiteit en wijst u er vervolgens een rol aan toe in de Foundry-resource.
Verwijder verificatie op basis van sleutels nadat alle bellers tokenverificatie hebben gebruikt. Schakel optioneel lokale verificatie uit in implementatiesjablonen.

Referentie: Azure-rollen toewijzen | Rolgebaseerde toegangscontrole voor Foundry

Veelvoorkomende verificatiefouten oplossen

Fout	Oorzaak	Resolutie / Besluit
401 Niet geautoriseerd	Ontbrekend of verlopen token; ongeldige API-sleutel	Controleer of het tokenverwervingsbereik is `https://ai.azure.com/.default`. Genereer de API-sleutel opnieuw als u verificatie op basis van sleutels gebruikt.
403 Verboden	Ontbrekende RBAC-roltoewijzing	Wijs de juiste ingebouwde rol (bijvoorbeeld Azure AI-gebruiker) toe aan de resource of project bereik.
AADSTS700016	De toepassing is niet gevonden in de tenant	Controleer of de app-registratie bestaat in de juiste tenant en of de client-id juist is.
Aangepast subdomein vereist	Resource gebruikt een regionaal eindpunt in plaats van een aangepast subdomein	Configureer een subdomein custom op de Foundry-resource. Verificatie op basis van tokens vereist een aangepast subdomein.

Feedback

Is deze pagina nuttig?

Last updated on 2026-03-11