Derzeit läuft mein Kurs zu den Azure-AI-Services erwartungsgemäß ganz gut, weil das Thema AI im Trend liegt. Entwickeln Sie eine eigene Anwendung, die im Backend Azure-AI-Services nutzt, muss sich die Anwendung gegen den verwendeten Azure-AI/KI-Dient authentifizieren. Dazu gibt es mehrere Möglichkeiten.
Aufgehängt an diesem spezifischen Szenario möchte ich die Gelegenheit nutzen, das Thema Token-basierte Authentifizierung noch etwas zu verallgemeinern, da ich in der Praxis häufig feststellen, dass bei einigen Nutzern noch Klärungsbedarf hinsichtlich der kursierenden Begriffe Dienstprinzipal, OAuth-Token, API-Schlüssel usw. besteht.
Azure-AI-Services und API-Schlüssel
Beginnen wir mit dem speziellen Fall Azure-AI-Services. Der Zugriff auf Azure-AI-Services-Ressourcen wird per Default mithilfe von Abonnementschlüsseln eingeschränkt. Es gibt aber auch die Token-basierte Authentifizierung und die Authentifizierung via Entra ID.
Bei API-Schlüsseln besteht die unbedingte Notwendigkeit, dass Sie sich Gedanken um die Verwaltung des Zugriffs auf diese Schlüssel machen. Das ist ein wichtiger Sicherheitsaspekt, weil die Zugriffsverwaltung mit Hilfe von Subscription-Keys – der Begriff „Abonnement/Subscription“ bezieht sich hier auf die AI-Dienst-Ressource – ein ziemlich grobes (im Sinne von wenig granulares) Verfahren darstellt. Die Schlüssel werden verwendet, um den Zugriff auf Azure AI Services zu authentifizieren, d. h. der jeweilige Schlüssel wird stets im HTTP-Header der API-Anforderung eingefügt und ermöglich den Zugriff für alles und jeden, der über den Schlüssel verfügt. Jeder KI-Dienst wird mit zwei Schlüsseln bereitgestellt. Sie finden die Schlüssel im Azure-Portal beim jeweiligen Azure-AI-Dienst – hier am Beispiel eines „Azure AI services multi-service account“ im Menü „Ressourcenverwaltung / Schlüssel und Endpunkt“.
… oder per Azure-CLI-Aufruf
az cognitiveservices account keys list –name <Ressourcenname> –resource-group <Ressourcengruppe>
Da Schlüssel ggf. vollen Zugriff auf die entsprechende KI-Ressourcen gewähren, sollten Sie die Schlüssel regelmäßig neu generieren. Das minimiert das Risiko der Freigabe von Schlüsseln für oder des Zugriffs durch nicht autorisierte Benutzer. Das klappt mit der Schaltflächen „Key 1 neu generieren“ / „Key 2 neu generieren“ oder mit dem Azure-CLI-Aufruf
az cognitiveservices account keys regenerate –key-name {Key1, Key2} –name –resource-group <Ressourcengruppe>
Um das Risiko der Offenlegung weiter zu minimieren, könnten Sie die Keys auch in einem Azure Schlüsseltresor (Key Vault) ablegen und den Zugriff auf den Schlüsseltresor durch einen Dienstprinzipal gewähren, der wiederrum durch Entra ID authentifiziert wird. Sie müssen dann Ihrer Anwendung einen Dienstprinzipal zuweisen.
Summa Summarum wird bei der Authentifizierung mit Subscriptions Key der Schlüssel verwendet, um den Zugriff auf Azure AI Services zu authentifizieren. Der Schlüssel wird in den HTTP-Header der API-Anforderung eingefügt. Das Verfahren birgt folgende Vor- und Nachteile:
Vorteile:
- Einfachheit: Leicht zu implementieren und zu verwenden.
- Schnell: Keine zusätzliche Konfiguration erforderlich.
Tokenbasierte Authentifizierung
Bei Verwendung der REST-API unterstützen einige (bei weitem nicht alle) AI-Dienste auch die „direkte“ tokenbasierte Authentifizierung. Mit „direkt“ ist gemeint: Das Token wird in diesem Fall von der Azure AI-Ressource selbst erzeugt und nicht vom Entra ID. Die Azure-AI-Ressource stellt dann in einer ersten Anforderung den Abonnementschlüssel zum Abrufen eines Authentifizierungstokens mit einer Gültigkeitsdauer von exakt 10 Minuten bereit. Sämtliche nachfolgenden Anforderungen müssen dieses Token bereitstellen, um zu überprüfen, ob der Aufrufer authentifiziert wurde.
Summa Summarum wird bei der Authentifizierung mit Subscriptions Key der Schlüssel verwendet, um den Zugriff auf Azure AI Services zu authentifizieren. Der Schlüssel wird in den HTTP-Header der API-Anforderung eingefügt. Das Verfahren birgt folgende Vor- und Nachteile:
EntraID-basierte Authentifizerung
Wir können uns jetzt getrost vom Use Case „Authentifizierung gegen Azure-AI-Services“ lösen, denn die folgenden Erläuterungen gelten für die Authentifizierung einer Vielzahl von Anwendungstypen und Szenarien. Sie können die Entra-basierte Authentifizierung gleichermaßen für andere Azure-Dienste nutzen, wie für Anwendungen die Sie selbst betreiben, egal ob in Azure oder lokal. Diese müssen lediglich über eine Identität im Entra ID verfügen. Hier kommen die Begriffe „App Registration“ und/oder „Unternehmensanwendung“, sowie die „Microsoft Identity Plattform“ ins Spiel. Ich habe diese Themen bereits an anderer Stelle vertieft und möchte hier nur noch Mal allgemein auf die Vorteile der Entra-ID-basierten Authentifizierung eingehen.
Das Grundprinzip hierbei ist die Verwendung von OAuth 2.0-Token zur Authentifizierung. Diese werden vom Authentifizierungsserver generiert und vom Client bei jeder Anfrage verwendet.
Es gibt grundsätzlich zwei Authentifizierungsmethoden innerhalb von Microsoft Entra ID, je nachdem, ob Sie den Zugriff auf einen Azure-Dienst gewähren wollen oder auf eine eigene Anwendung, nämlich Verwaltete Identitäten und Dienstprinzipale. Hier die jeweiligen Vor- und Nachteile:
Verwaltete Identitäten (Managed Identities): Azure-Dienste können verwaltete Identitäten verwenden, um sich bei anderen Azure-Diensten zu authentifizieren, ohne dass Geheimnisse verwaltet werden müssen
- Vorteile: Keine Notwendigkeit zur Verwaltung von Geheimnissen, automatische Verwaltung und Rotation.
- Nachteile: Funktioniert nur innerhalb von Azure
Ein Dienstprinzipal: ist eine Identität, die von Anwendungen oder Diensten verwendet wird, um sich bei Azure zu authentifizieren.
- Vorteile: Sicher und auch für automatisierte Prozesse geeignet.
- Nachteile: Erfordert Verwaltung und Rotation von Geheimnissen.
Für beide Verfahren gilt gleichermaßen:
Vorteile:
- Sicherheit: Bietet eine sichere und robuste Authentifizierung.
- Berechtigungen: Feingranulare Kontrolle über Berechtigungen und Zugriff.
Nachteile:
- Komplexität: Erfordert mehr Konfiguration und Verwaltung.
- Abhängigkeit: Abhängig von der Verfügbarkeit und Konfiguration von Entra ID.
Ich fasse noch Mal zusammen:
Die Hauptmethoden zur Authentifizierung für Azure AI Services sind Abonnement-Schlüssel, Token-basiert und Microsoft Entra ID. Innerhalb von Microsoft Entra ID erfolgt die Authentifizierung über Dienstprinzipale oder Verwaltete Identitäten.
Letzteres gilt aber nicht nur für Azure-AI-Services, sondern für nahezu jeden Anwendungstyp, der eine Identität/Repräsentation im Entra ID hat.
Die Autorisierung erfolgt nach der Authentifizierung und bestimmt, welche Aktionen und Ressourcen einem Benutzer oder Dienst erlaubt sind. Dann spielen Token eine zentrale Rolle bei der Authentifizierung über Microsoft Entra ID und den darin enthaltenen Methoden wie Dienstprinzipale und Verwaltete Identitäten. So ein Token wird verwendet, um die Identität eines Benutzers oder Dienstes zu bestätigen. Das Token wird bei jeder Anfrage an den Server gesendet.
Token können in verschiedenen Authentifizierungsprotokollen verwendet werden, einschließlich OAuth 2.0. OAuth 2.0 selbst ist ein Autorisierungsframework, das Token verwendet, um den Zugriff auf Ressourcen zu gewähren, ohne dass Benutzer ihre Anmeldedaten weitergeben müssen. Auth 2.0 generiert und verwendet Token sowohl zur Authentifizierung, als auch zur Autorisierung. Das Token bestätigen die Identität des Benutzers oder Dienstes UND gewährt Zugriff auf Ressourcen. Entra ID verwendet OAuth-2.0-Token.
Ist die Identität einmal bestätigt, verwenden sowohl Dienstprinzipalen als auch verwalteten Identitäten (Managed Identities) Azure-Rollen im Rahmen der rollenbasierten Zugriffssteuerung (RBAC). Dies ermöglicht die präzise Steuerung, welche Ressourcen und Aktionen einem Dienstprinzipal oder einer verwalteten Identität erlaubt sind und reduziert das Risiko durch das Prinzip der geringsten Privilegien, indem nur die notwendigen Berechtigungen gewährt werden.