Von Azure OpenAI unterstützte Authentifizierungsmethoden
Azure OpenAI unterstützt mehrere Authentifizierungsmethoden, um einen sicheren und kontrollierten Zugriff auf seine Ressourcen sicherzustellen. Die wichtigsten Methoden sind:
- API-Schlüssel: Azure OpenAI unterstützt auch die Authentifizierung basierend auf API-Schlüsseln. API-Schlüssel werden im Azure-Portal generiert und können verwendet werden, um Anforderungen an den Azure OpenAI-Dienst zu authentifizieren. Diese Authentifizierungsmethode wird aus Sicherheitsgründen nicht empfohlen und sollte nur als letztes Mittel verwendet werden. Wenn Sie diese Authentifizierungsmethode verwenden müssen, ist es wichtig, API-Schlüssel sicher zu verarbeiten und sie regelmäßig zu rotieren, um das Risiko eines nicht autorisierten Zugriffs zu verringern.
- Microsoft Entra ID: Diese Methode nutzt die robusten Identity & Access Management-Funktionen von Microsoft Entra. Benutzer und Anwendungen authentifizieren sich mithilfe von Microsoft Entra-Identitäten, die herkömmliche Benutzerkonten oder verwaltete Identitäten sein können. Diese Methode stellt sicher, dass nur authentifizierte und autorisierte Benutzer auf die Azure OpenAI-Ressourcen zugreifen können.
- EntraVerwaltete Identitäten: Verwaltete Identitäten für Azure-Ressourcen stellen eine automatisch verwaltete Identität in Microsoft Entra bereit, die Anwendungen beim Herstellen von Verbindungen mit Ressourcen verwenden können, welche die Microsoft Entra-Authentifizierung unterstützen. Diese Identitäten können systemseitig zugewiesen sein, was bedeutet, dass sie an eine bestimmte Azure-Ressource gebunden sind, oder benutzerseitig zugewiesen, wodurch eine einzelne Identität über mehrere Ressourcen hinweg gemeinsam genutzt werden kann. Verwaltete Identitäten vereinfachen die Verwaltung von Anmeldeinformationen und verbessern die Sicherheit, indem die Notwendigkeit hartcodierter Anmeldeinformationen im Anwendungscode eliminiert wird.
Warum verwaltete Identitäten sicherer sind als API-Schlüssel
Verwaltete Identitäten in Microsoft Azure bieten aus verschiedenen Gründen eine sicherere Alternative zu API-Schlüsseln:
- Mit verwalteten Identitäten müssen Entwickler Anmeldeinformationen nicht mehr direkt verarbeiten, wodurch das Risiko einer versehentlichen Offenlegung oder eines Missbrauchs verringert wird.
- Wenn Sie API-Schlüssel verwenden, müssen Entwickler diese Schlüssel in ihren Anwendungscode oder ihre Konfigurationsdateien einbetten.
API-Schlüssel können versehentlich über Quellcoderepositorys, Protokolle oder andere Mittel offengelegt gemacht werden. Diese Offenlegung kann zu nicht autorisiertem Zugriff und potenziellen Sicherheitsverletzungen führen. Im Gegensatz dazu stellen verwaltete Identitäten eine automatisch verwaltete Identität bereit, die Anwendungen beim Herstellen von Verbindungen mit Ressourcen verwenden können, welche die Microsoft Entra (früher Azure AD)-Authentifizierung unterstützen. Dies bedeutet, dass Anmeldeinformationen nicht im Anwendungscode gespeichert werden, wodurch das Risiko von Lecks und nicht autorisiertem Zugriff verringert wird.
Darüber hinaus optimieren verwaltete Identitäten den Authentifizierungsprozess, indem sie Azure-Dienste in die Lage versetzen, sich bei anderen Azure-Diensten sicher zu authentifizieren, ohne dass explizite Anmeldeinformationen erforderlich sind. Dies wird mithilfe von durch Microsoft Entra ausgestellten Token erreicht, die automatisch verwaltet und rotiert werden, um sicherzustellen, dass die Anmeldeinformationen immer auf dem neuesten Stand sind und das Risiko des Diebstahls von Anmeldeinformationen verringern. API-Schlüssel hingegen sind statisch und erfordern eine manuelle Rotation, die fehleranfällig sein kann und häufig vernachlässigt wird, was zu potenziellen Sicherheitsrisiken führt. Mithilfe von verwalteten Identitäten können Entwickler die integrierten Sicherheitsfeatures von Azure nutzen, z. B. rollenbasierte Zugriffssteuerung (RBAC), um präzise Berechtigungen für Ressourcen zu gewähren und die Sicherheit weiter zu erhöhen.
Microsoft empfiehlt, beim Authentifizieren bei Azure OpenAI oder einem anderen Azure-Dienst, der verwaltete Identitäten unterstützt, eine verwaltete Identität statt API-Schlüssel zu verwenden.
Unterschiede zwischen der Verwendung von API-Schlüsseln und verwalteten Identitäten in Azure OpenAI
Lassen Sie uns die Auswirkungen einer durchgesickerten Client-ID im Vergleich zu einem durchgesickerten API-Schlüssel bewerten.
Ein API-Schlüssel funktioniert ähnlich wie ein normales Kennwort. Wenn er kompromittiert ist, kann jeder mit dem Schlüssel auf die Ressource zugreifen. Für Azure OpenAI bedeutet dies die uneingeschränkte Verwendung von KI-Modellen wie GPT-4. Wenn das Netzwerk öffentlich zugänglich ist, können die Auswirkungen auf die Sicherheit noch größer sein.
Umgekehrt sind die Risiken minimal, wenn die Client-ID durchsickert. Dies liegt daran, dass die Client-ID allein keine Verbindung mit Azure OpenAI herstellen kann. Um eine verwaltete Identität zu nutzen, muss der Dienst auf Azure ausgeführt werden, und selbst wenn Azure OpenAI öffentlich ist, können Sie keine Verbindung aus einer lokalen Umgebung oder über ein Netzwerk mithilfe einer Anwendung herstellen.
Zusammenfassend lässt sich sagen, dass im Vergleich zu den Auswirkungen eines durchgesickerten API-Schlüssels das Ausnutzen einer durchgesickerten Client-ID mehrere Schritte erfordert, was es für böswillige Akteure schwieriger macht, diese auszunutzen.
Aus diesen Gründen bieten verwaltete Identitäten eine sicherere Methode zum Verwalten von Vorgängen im Vergleich zu API-Schlüsseln. Es wird nachdrücklich empfohlen, bei der Authentifizierung gegenüber Azure OpenAI oder jedem anderen Azure-Dienst, der verwaltete Identitäten unterstützt, eine verwaltete Identität statt API-Schlüssel zu verwenden.
Systemseitig im Vergleich zu benutzerseitig zugewiesene Identitäten
Beim Erstellen einer Azure OpenAI-Anwendung ist das Verständnis der Unterscheidung zwischen vom systemseitig zugewiesenen und benutzerseitig zugewiesenen Identitäten entscheidend für optimale Sicherheits- und Ressourcenverwaltung.
- Systemseitig zugewiesene Identitäten werden von Azure für eine bestimmte Ressource erstellt und verwaltet. Wenn eine Ressource gelöscht wird, wird auch die zugeordnete systemseitig zugewiesene Identität gelöscht, wodurch sichergestellt wird, dass der Identitätslebenszyklus eng mit der Ressource verknüpft ist, zu der sie gehört. Dieser Identitätstyp eignet sich ideal für Szenarien, in denen die Identität nur von einer einzelnen Ressource verwendet werden muss, was Einfachheit bietet und den Verwaltungsaufwand verringert, da Azure die Anmeldeinformationen der Identität verwaltet.
- Benutzerseitig zugewiesene Identitäten werden unabhängig von bestimmten Ressourcen erstellt und können von mehreren Ressourcen gemeinsam genutzt werden. Dies macht sie sehr vielseitig für Anwendungen, die eine konsistente Identität über verschiedene Ressourcen hinweg erfordern, wodurch die Verwaltung von Berechtigungen und Zugriffssteuerungen erleichtert wird. Benutzerseitig zugewiesene Identitäten bleiben auch nach dem Löschen der Ressourcen erhalten, sodass mehr Flexibilität beim erneuten Bereitstellen und Wiederverwenden von Identitäten möglich ist.
Die Auswahl zwischen systemseitig zugewiesenen und benutzerseitig zugewiesenen Identitäten hängt von den spezifischen Anforderungen Ihrer Anwendung ab. Bei Anwendungen mit einer einzelnen Ressource, bei denen Einfachheit und minimale Verwaltung Prioritäten sind, sind systemseitig zugewiesene Identitäten in der Regel die beste Wahl. Für Anwendungen, die eine gemeinsam genutzte Identität für mehrere Ressourcen benötigen, bieten benutzerseitig zugewiesene Identitäten dagegen mehr Flexibilität und Wiederverwendbarkeit.
