Authentifizierung und Autorisierung in Microsoft Foundry

Die Authentifizierung und Autorisierung in Microsoft Foundry steuern, wie Prinzipale Identität nachweisen und die Berechtigung zum Ausführen von Vorgängen erhalten. Foundry unterteilt Vorgänge in Steuerungsebene (Ressourcenverwaltung) und Datenebene (Laufzeitnutzung), wobei jeweils eine eigene Authentifizierung und rollenbasierte Zugriffskontroll-Oberfläche (RBAC) vorhanden ist.

Foundry unterstützt zwei Authentifizierungsmethoden: Microsoft Entra ID und API-Schlüssel. Microsoft Entra ID ermöglicht bedingten Zugang, verwaltete Identitäten und granulare RBAC. API-Schlüssel bleiben für die schnelle Prototyperstellung verfügbar, aber es fehlt an der Rückverfolgbarkeit pro Benutzer. In diesem Artikel werden diese Methoden verglichen, Identitäten Rollen zugeordnet und allgemeine Szenarien mit den geringsten Berechtigungen beschrieben.

Voraussetzungen

• Ein Azure-Abonnement. Wenn Sie kein Konto haben, ein kostenloses Konto erstellen.
• Eine Microsoft Foundry-Ressource mit einer konfigurierten benutzerdefinierten Subdomain.
• Grundlegendes zu Azure RBAC-Konzepten.
• Zum Zuweisen von Rollen benötigen Sie die Owner-Rolle oder die User Access Administrator-Rolle im entsprechenden Bereich.
• (Optional) Das Azure CLI oder Azure SDK für Python für die programmgesteuerte Authentifizierung installiert.
• (Optional) Python-Pakete für Codebeispiele: pip install azure-identity requests

Steuerungsebene und Datenebene

Azure Vorgänge unterteilen sich in zwei Kategorien: Steuerebene und Datenebene. Azure trennt die Ressourcenverwaltung (Kontrollebene) von der Betriebslaufzeit (Datenebene). Daher verwenden Sie die Steuerebene zum Verwalten von Ressourcen in Ihrem Abonnement und verwenden die Datenebene, um Funktionen zu verwenden, die von Ihrer Instanz eines Ressourcentyps verfügbar gemacht werden. Weitere Informationen zu Steuerungsebenen und Datenebenen finden Sie unter Azure Steuerungsebene und Datenebene. In Foundry gibt es einen klaren Unterschied zwischen Steuerungsebenenvorgängen und Datenebenenvorgängen. In der folgenden Tabelle wird der Unterschied zwischen den beiden, die Reichweite in Foundry, typische Vorgänge eines Benutzers, Beispieltools und -funktionen sowie die Autorisierungsoberfläche erläutert, die jeweils verwendet werden sollen.

Alle Bicep-, Terraform- und SDK-Beispiele finden Sie im Repository foundry-samples on GitHub for Foundry.

Die folgenden Listen und Diagramme veranschaulichen die Trennung zwischen Steuerungsebene und Datenebenenaktionen im Detail. Innerhalb von Foundry gehören zu den Aktionen der Steuerungsebene:

• Erstellen von Foundry-Ressourcen
• Gründung eines Foundry-Projekts
• Erstellung von Kontofunktionshosts
• Projekt-Funktionalitäten Host-Erstellung
• Modellbereitstellung
• Konto- und Projekt-Verbindungserstellung

Zu den Datenebenenaktionen innerhalb von Foundry gehören:

• Erstellen von Agents
• Ausführen einer Auswertung
• Ablaufverfolgung und Überwachung
• Fine-tuning

Das folgende Diagramm zeigt die Trennung von Steuer- und Datenebene in Foundry im Vergleich zu rollenbasierten Zugriffskontroll-Zuordnungen (RBAC) und den möglichen Zugriff eines Benutzers auf entweder die Steuer- oder Datenebene oder auf beide. Wie im Diagramm dargestellt, werden RBAC-"Aktionen" der Steuerungsebene zugeordnet, während RBAC "dataActions" mit der Datenebene verknüpft sind.

Authentifizierungsmethoden

Foundry unterstützt Microsoft Entra ID (tokenbasierte, schlüssellose) und API-Schlüssel.

Microsoft Entra ID

Microsoft Entra ID verwendet OAuth 2.0-Bearertoken, die auf https://cognitiveservices.azure.com/.default festgelegt sind.

Verwenden Sie Microsoft Entra ID für:

• Produktions-Workloads.
• Bedingter Zugriff, Multifaktor-Authentifizierung (MFA) und Just-in-Time-Zugriff.
• RBAC mit geringsten Rechten und Integration verwalteter Identitäten

Vorteile: Differenzierte Rollenzuweisungen, Prinzipalüberwachung, steuerbare Tokenlebensdauern, automatische Geheimnisschutzfunktionen und verwaltete Identitäten für Dienste.

Einschränkungen: Höhere Anfängliche Einrichtungskomplexität. Erfordert Kenntnisse der rollenbasierten Zugangskontrolle (RBAC). Weitere Informationen zu RBAC in Foundry finden Sie unter Rollenbasierte Zugriffskontrolle für Microsoft Foundry.

API-Schlüssel

API-Schlüssel sind statische Geheimnisse, die einer Foundry-Ressource zugeordnet sind.

Verwenden von API-Schlüsseln für:

• Schnelle Prototyperstellung.
• Isolierte Testumgebungen, in denen die Drehung eines einzigen geheimen Schlüssels zulässig ist.

Vorteile: Einfach, sprachunabhängig und erfordert keinen Token-Erwerb.

Einschränkungen: Die Benutzeridentität kann nicht ausgedrückt werden, es ist schwierig, sie granular abzugrenzen, und sie ist schwerer zu überwachen. Wird in der Regel nicht von Produktionsworkloads für Unternehmen akzeptiert und nicht von Microsoft empfohlen.

Weitere Informationen zum Aktivieren der schlüssellosen Authentifizierung finden Sie unter Configure key-less authentication with Microsoft Entra ID.

Authentifizieren mit Microsoft Entra ID (Python)

Das folgende Beispiel zeigt, wie Sie sich mit Microsoft Entra ID mithilfe der bibliothek azure-identity authentifizieren und eine Anforderung an einen Foundry-Endpunkt stellen:

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://cognitiveservices.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())

Erwartete Ausgabe: Eine JSON-Antwort, die Ihre Modellbereitstellungen auflistet, oder ein Authentifizierungsfehler, wenn Anmeldeinformationen fehlen oder die Rollenzuweisung nicht konfiguriert ist.

Reference: DefaultAzureCredential | azure-identity library

Authentifizieren mit einem API-Schlüssel (Python)

Das folgende Beispiel zeigt, wie Sie sich mithilfe eines API-Schlüssels authentifizieren. Verwenden Sie diesen Ansatz nur für schnelle Prototyperstellung; Microsoft Entra ID wird für die Produktion empfohlen.

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

Erwartete Ausgabe: Eine JSON-Antwort, die Ihre Modellbereitstellungen auflistet, oder ein 401-Fehler, wenn der API-Schlüssel ungültig ist.

Referenz: API-Zugriffsschlüssel aktualisieren

Funktionsunterstützungsmatrix

Verweisen Sie auf die folgende Matrix, um zu verstehen, welche Funktionen im Foundry API-Schlüssel unterstützen, verglichen mit Microsoft Entra ID.

Identitätstypen

Azure Ressourcen und Anwendungen authentifizieren sich mithilfe verschiedener Identitätstypen, die jeweils für bestimmte Szenarien entwickelt wurden. Benutzerprinzipale stellen menschliche Benutzer dar, Dienstprinzipale stellen Anwendungen oder automatisierte Prozesse dar, und verwaltete Identitäten bieten eine sichere, anmeldeinformationsfreie Möglichkeit für Azure Ressourcen, um andere Dienste zu access. Wenn Sie diese Unterscheidungen verstehen, können Sie die richtige Identität für interaktive Anmeldungen, App-zu-App-Kommunikation oder Workloadautomatisierung auswählen.

Azure unterstützt die folgenden Identitätstypen.

Übersicht über integrierte Rollen

Verwenden Sie in Foundry die integrierten Rollen, um die zulässigen Aktionen für einen Benutzer zu trennen. Die meisten Unternehmen möchten eine Trennung von Steuerungs- und Datenebenenaktionen für ihre integrierten Rollen. Andere erwarten eine kombinierte Daten- und Steuerebenenrolle, um die Anzahl der erforderlichen Rollenzuweisungen zu minimieren. In der folgenden Tabelle sind Szenarien und die entsprechenden integrierten Foundry-Rollen aufgeführt, die für jedes Szenario am besten geeignet sind.

Um die Aufschlüsselung der integrierten Rollen und der Steuerungs- und Datenebenenaktionen zu verstehen, lesen Sie das folgende Diagramm.

Einrichten von Microsoft Entra ID

Eine allgemeine Anleitung zum Einrichten der Entra-ID-Authentifizierung in Foundry finden Sie unter Konfigurieren der Authentifizierung ohne Schlüssel.

1. Stellen Sie sicher, dass Ihre Microsoft Foundry-Ressource eine benutzerdefinierte Unterdomäne konfiguriert hat. Siehe Custom subdomains. Für die tokenbasierte Authentifizierung ist eine benutzerdefinierte Unterdomäne erforderlich.

2. Weisen Sie jedem Prinzipal die erforderliche integrierte oder benutzerdefinierte Rolle zu. Sie benötigen im Zielbereich die Rolle Owner oder User Access Administrator, um Rollen zuzuweisen. Allgemeine Rollenzuweisungen:

   • Azure AI User: Für Entwickler, die vorab bereitgestellte Modelle erstellen und testen müssen.
   • Azure AI Project Manager: Für Teamleiter, die Projekte erstellen und Bereitstellungen verwalten müssen.
   • Azure KI Kontobesitzer: Für Administratoren, die eine vollständige Ressourcenverwaltung benötigen und Azure AI Benutzer für den Zugriff auf die Datenebene bedingt zuweisen können.
   • Azure AI Owner: Für Benutzer, die sowohl vollständige Ressourcenverwaltung als auch Datenebenenzugriff benötigen. Beispiel-CLI-Befehl zum Zuweisen der Azure KI-Benutzerrolle:

   az role assignment create \
     --assignee <principal-id> \
     --role "Azure AI User" \
     --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<resource-name>
   

   Um die Rollenzuweisung zu überprüfen, führen Sie den Befehl az role assignment list --assignee <principal-id> --scope <resource-scope> aus und bestätigen Sie, dass die Rolle in der Ausgabe angezeigt wird.

3. (Optional) Erstellen Sie für einen Dienstprinzipal eine App-Registrierung, fügen Sie einen geheimen Clientschlüssel oder ein Zertifikat hinzu, und notieren Sie sich die Mandanten-ID, die Client-ID und den geheimen Schlüssel oder das Zertifikat.

4. (Optional) Aktivieren Sie für eine verwaltete Identität die vom System zugewiesene Identität für den aufrufenden Dienst, oder fügen Sie eine vom Benutzer zugewiesene Identität an, und weisen Sie ihr dann eine Rolle in der Foundry-Ressource zu.

5. Entfernen Sie die schlüsselbasierte Authentifizierung, nachdem alle Aufrufer die Tokenauthentifizierung verwenden. Deaktivieren Sie optional die lokale Authentifizierung in Bereitstellungsvorlagen.

Reference: Azure-Rollen zuweisen | Rollenbasierte Zugriffskontrolle für Foundry

Häufige Authentifizierungsfehler beheben

Verwandte Inhalte

• Rollenbasierte Zugriffskontrolle für Foundry
• Schlüssellose Authentifizierung mit Microsoft Entra ID konfigurieren
• API-Zugriffsschlüssel wechseln
• Azure integrierte Rollen (AI + machine learning)
• Authentifizierung vs. Autorisierung (Microsoft Entra ID)
• Grundlagen der Identität