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 besturingsvlak (resourcebeheer) en het gegevensvlak (runtimegebruik), elk met een eigen RBAC-oppervlak (verificatie en op rollen gebaseerd toegangsbeheer).

Foundry ondersteunt twee verificatiemethoden: Microsoft Entra ID en API-sleutels. Microsoft Entra ID maakt voorwaardelijke toegang, 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.

Voorwaarden

• Een Azure-abonnement. Als u nog geen account hebt, maakt u een gratis account.
• Een Microsoft Foundry-resource met een geconfigureerd aangepast subdomein.
• Inzicht in Azure RBAC-concepten.
• Als u rollen wilt toewijzen, hebt u de rol Eigenaar of Beheerder van gebruikerstoegang nodig voor het juiste bereik.
• (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 het autorisatieoppervlak om elk te gebruiken.

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 maken
• Het maken van een Foundry-project
• Account Capability Host maken
• Project Mogelijkheidshost maken
• Modelimplementatie
• Account- en projectverbinding maken

Acties voor het gegevensvlak in Foundry omvatten:

• Bouwagenten
• Een evaluatie uitvoeren
• Traceren en monitoren
• Fijnregeling

In het volgende diagram ziet u de weergave van besturingsvlak versus gegevensvlakscheiding in Foundry, naast RBAC-toewijzingen (op rollen gebaseerd toegangsbeheer) en welke toegang een gebruiker mogelijk heeft in het besturingsvlak of gegevensvlak 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 toegang, meervoudige verificatie (MFA) en Just-In-Time-toegang.
• 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 gebaseerd toegangsbeheer (RBAC). Zie Toegangsbeheer op basis van rollen voor Microsoft Foundry voor meer informatie over RBAC in Foundry.

API-sleutels

API-sleutels zijn statische geheimen die betrekking hebben op een Foundry-resource.

API-sleutels gebruiken voor:

• Snelle prototypen.
• Geïsoleerde testomgevingen waarbij rotatie van één 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.

Naslaginformatie: 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())

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

Documentatie: API-toegangssleutels vernieuwen

Matrix voor functieondersteuning

Raadpleeg de volgende matrix om te begrijpen welke mogelijkheden in Foundry ondersteuning bieden voor API-sleutels versus Microsoft Entra ID.

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 voor toegang tot andere services. 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.

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.

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

Microsoft Entra ID instellen

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

1. Zorg ervoor dat uw Microsoft Foundry-resource een aangepast subdomein heeft geconfigureerd. Zie Aangepaste subdomeinen. Een aangepast subdomein is vereist voor verificatie op basis van tokens.

2. Wijs de benodigde ingebouwde of aangepaste rol toe aan elke principal. U hebt de rol Eigenaar of Beheerder van gebruikerstoegang in het doelbereik 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: Beheerders die volledig resourcebeheer nodig hebben en Azure AI-gebruiker voorwaardelijk kunnen toewijzen voor toegang tot gegevensvlakken.
   • Azure AI-eigenaar: voor gebruikers die volledige toegang tot resourcebeheer en 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.

3. (Optioneel) Voor een serviceprincipal maakt u een app-registratie, voegt u een clientgeheim of certificaat toe en noteert u de tenant ID, client ID en geheim of certificaat.

4. (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.

5. Verwijder verificatie op basis van sleutels nadat alle bellers tokenverificatie hebben gebruikt. Schakel optioneel lokale verificatie uit in implementatiesjablonen.

Referentie: Assign Azure roles | Role-based access control for Foundry

Veelvoorkomende verificatiefouten oplossen

Verwante inhoud

• Op rollen gebaseerd toegangsbeheer voor Foundry
• Sleutelloze verificatie configureren met Microsoft Entra ID
• API-toegangssleutels roteren
• Azure geïntegreerde rollen (AI + Machine Learning)
• Verificatie versus autorisatie (Microsoft Entra ID)
• Basisprincipes van identiteiten