Authentifizierung und Autorisierung in Microsoft Foundry (klassisch)

Zurzeit wird folgendes angezeigt:Foundry (klassische) Portalversion - Wechseln zur Version für das neue Foundry-Portal

Authentifizierung und Autorisierung in Microsoft Foundry steuern, wie Benutzer ihre Identität nachweisen und die Berechtigung erhalten, um Vorgänge auszuführen. Die Gießerei unterteilt Vorgänge in die Steuerungsebene (Ressourcenverwaltung) und die Datenebene (Laufzeitnutzung), die jeweils über eine eigene Authentifizierungs- und rollenbasierte Zugriffssteuerungsoberfläche (RBAC) verfügt.

Foundry unterstützt zwei Authentifizierungsmethoden: Microsoft Entra ID und API-Schlüssel. Microsoft Entra ID ermöglicht bedingten Zugriff, 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, erstellen Sie ein kostenloses Konto.
• Eine Microsoft Foundry-Ressource mit einer konfigurierten benutzerdefinierten Subdomain.
• Grundlegendes zu Azure RBAC-Konzepten.
• Um Rollen zuzuweisen, benötigen Sie die Rolle " Besitzer" oder " Benutzerzugriffsadministrator " im entsprechenden Bereich.
• (Optional) Die 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. Die folgende Tabelle erläutert den Unterschied zwischen den beiden, den Umfang in Foundry, typische Vorgänge eines Benutzers, Beispieltools und Funktionen sowie die Autorisierungsoberfläche zur Nutzung jedes Teils.

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. Zu den Aktionen der Kontrollebene innerhalb von Foundry gehören:

• Erstellen von Foundry-Ressourcen
• Gießerei-Projekterstellung
• Erstellung eines Account Capability Hosts
• Erstellung eines Projektfähigkeits-Hosts
• Modellbereitstellung
• Konto- und Projektverbindungserstellung

Zu den Aktionen der Datenebene innerhalb von Foundry gehören:

• Baumitarbeiter
• Ausführen einer Auswertung
• Ablaufverfolgung und Überwachung
• Feinabstimmung

Das folgende Diagramm zeigt die Ansicht der Steuerungsebene im Vergleich zur Datenebenentrennung in Foundry zusammen mit rollenbasierten Zugriffssteuerungszuweisungen (RBAC) und dem Zugriff, über den ein Benutzer in der Steuerungsebene oder in der Datenebene oder in beidem verfügen könnte. 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://ai.azure.com/.default.

Verwenden Sie Microsoft Entra ID für:

• Produktionsbelastungen
• Bedingter Zugriff, mehrstufige Authentifizierung (MFA) und Just-in-Time-Zugriff.
• Integration von RBAC nach dem Prinzip des minimalen Privilegs und verwalteten Identitäten.

Vorteile: Feinkörnige Rollenzuweisungen, pro-Prinzipal-Überprüfung, kontrollierbare Token-Lebensdauer, automatische Geheimnisverwaltung und verwaltete Identitäten für Dienste.

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

API-Schlüssel

API-Schlüssel sind statische Geheimnisse, die auf eine Foundry-Ressource beschränkt sind.

Verwenden von API-Schlüsseln für:

• Schnelle Prototypisierung.
• Isolierte Testumgebungen, in denen die Rotation eines einzelnen Geheimnisses akzeptiert werden kann.

Vorteile: Einfach, sprachunabhängig und erfordert keine Tokenbeschaffung.

Einschränkungen: Die Benutzeridentität kann nicht ausgedrückt werden, ist schwer granular abzugrenzen und ist schwieriger zu prüfen. Wird in der Regel nicht von Produktionsumgebungen von 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://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())

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

Referenz: DefaultAzureCredential | Azure-Identity-Bibliothek

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: Rotieren der API-Zugriffsschlüssel

Matrix zur Featureunterstützung

Siehe folgende Matrix, um zu verstehen, welche Funktionen in Foundry entweder API-Schlüssel oder Microsoft Entra ID unterstützt.

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 für den Zugriff auf andere Dienste. 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

Ein Leitfaden zum Einrichten der Entra ID-Authentifizierung in Foundry finden Sie unter Configure key-less authentication.

1. Stellen Sie sicher, dass Ihre Microsoft Foundry-Ressource eine benutzerdefinierte Unterdomäne konfiguriert hat. Siehe benutzerdefinierte Unterdomänen. 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 die Rolle "Besitzer" oder " Benutzerzugriffsadministrator " im Zielbereich, 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 AI-Kontobesitzer: Für Administratoren, die die vollständige Ressourcenverwaltung benötigen und Azure AI-Benutzer bedingt für den Zugriff auf die Datenebene zuweisen können.
   • Azure AI Owner: Für Benutzer, die sowohl vollständigen Ressourcenverwaltungs- 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 az role assignment list --assignee <principal-id> --scope <resource-scope> aus und bestätigen Sie, dass die Rolle in der Ausgabe erscheint.

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 Zugriffssteuerung für Foundry

Fehlerbehebung bei häufigen Authentifizierungsfehlern

Verwandte Inhalte

• Rollenbasierte Zugriffssteuerung für Foundry
• Schlüssellose Authentifizierung mit Microsoft Entra ID konfigurieren
• Wechseln von API-Zugriffsschlüsseln
• Azure integrierte Rollen (AI + Maschinelles Lernen)
• Authentifizierung vs. Autorisierung (Microsoft Entra ID)
• Grundlagen der Identität