Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Apps können die Azure Identity-Bibliothek verwenden, um sich bei Microsoft Entra-ID zu authentifizieren, die Zugriff auf Azure-Dienste und -Ressourcen gewährt. Diese Authentifizierungsanforderung gilt, ob die App in Azure bereitgestellt, lokal gehostet oder lokal auf einer Entwicklerarbeitsstation ausgeführt wird. In den folgenden Abschnitten werden die empfohlenen Ansätze zum Authentifizieren einer App bei Microsoft Entra-ID in verschiedenen Umgebungen bei Verwendung der Azure SDK-Clientbibliotheken beschrieben.
Empfohlener Ansatz für die App-Authentifizierung
Tokenbasierte Authentifizierung über Microsoft Entra ID ist der empfohlene Ansatz für die Authentifizierung von Apps für Azure, anstatt Verbindungszeichenfolgen oder schlüsselbasierte Optionen zu verwenden. Das Azure Identity-Clientmodul für Go bietet tokenbasierte Authentifizierung und ermöglicht Apps die Authentifizierung bei Azure-Ressourcen, unabhängig davon, ob die App lokal, auf Azure oder auf einem lokalen Server ausgeführt wird.
Vorteile der tokenbasierten Authentifizierung
Die tokenbasierte Authentifizierung bietet die folgenden Vorteile gegenüber Verbindungszeichenfolgen:
- Die tokenbasierte Authentifizierung stellt nur die spezifischen Apps sicher, die für den Zugriff auf die Azure-Ressource vorgesehen sind, während jede oder jede App mit einer Verbindungszeichenfolge eine Verbindung mit einer Azure-Ressource herstellen kann.
- Mithilfe der tokenbasierten Authentifizierung können Sie den Azure-Ressourcenzugriff auf nur die spezifischen Berechtigungen beschränken, die von der App benötigt werden. Dieser Ansatz folgt dem Prinzip der geringsten Rechte. Im Gegensatz dazu gewährt eine Verbindungszeichenfolge vollständige Rechte für die Azure-Ressource.
- Wenn Sie eine verwaltete Identität für die tokenbasierte Authentifizierung verwenden, verarbeitet Azure Administrative Funktionen für Sie, sodass Sie sich keine Gedanken über Aufgaben wie das Sichern oder Drehen von geheimen Schlüsseln machen müssen. Mit diesem Feature wird die App sicherer, da keine Verbindungszeichenfolge oder kein geheimer Anwendungsschlüssel vorhanden ist, der kompromittiert werden kann.
- Verbindungszeichenfolgen sind funktional den Anmeldeinformationen gleichgestellt und erfordern eine spezielle Behandlung, um versehentliche Lecks verhindern zu können. Sie müssen sie sicher (z. B. in Azure Key Vault) speichern und sie niemals in Ihrer Anwendung hartcodieren oder zur Quellcodeverwaltung verpflichten. Die Microsoft Secure Future Initiative (SFI) verbietet die Verwendung von Verbindungszeichenfolgen und ähnlichen geheimen Schlüsseln mit langer Lebensdauer, da sie verwendet werden können, um Ihre Anwendung zu kompromittieren, wenn sie nicht sorgfältig verwaltet werden.
- Die Azure Identity-Bibliothek erwirbt und verwaltet Microsoft Entra-Token für Sie.
Beschränken Sie die Verwendung von Verbindungszeichenfolgen auf Szenarien, in denen die tokenbasierte Authentifizierung keine Option, anfängliche Machbarkeits-Apps oder Entwicklungsprototypen ist, die nicht auf Produktionsdaten oder vertrauliche Daten zugreifen. Verwenden Sie nach Möglichkeit die Anmeldeinformationstypen in der Azure Identity-Bibliothek, um sich bei Azure-Ressourcen zu authentifizieren.
Authentifizierung in verschiedenen Umgebungen
Die Art der tokenbasierten Authentifizierung, die eine App für die Authentifizierung bei Azure-Ressourcen verwendet, hängt davon ab, wo die App ausgeführt wird. Das folgende Diagramm enthält Anleitungen für verschiedene Szenarien und Umgebungen:
Wenn eine App Folgendes tut:
- Gehostet in Azure: Die App sollte sich mit einer verwalteten Identität bei Azure-Ressourcen authentifizieren. Weitere Informationen finden Sie unter Authentifizierung in Serverumgebungen.
- Lokal während der Entwicklung ausgeführt: Die App kann sich bei Azure authentifizieren, indem sie entweder einen Anwendungsdienstprinzipal in der lokalen Entwicklung oder die Azure-Anmeldeinformationen des Entwicklers verwendet. Für weitere Informationen siehe Authentifizierung während der lokalen Entwicklung.
- Lokal gehostet: Die App sollte sich bei Azure-Ressourcen mithilfe eines Dienstprinzipals authentifizieren, oder im Falle von Azure Arc, eine verwaltete Identität verwenden. Weitere Informationen finden Sie unter Authentifizierung in Serverumgebungen.
Authentifizierung für von Azure gehostete Apps
Wenn Sie Ihre App in Azure hosten, kann sie verwaltete Identitäten verwenden, um sich bei Azure-Ressourcen zu authentifizieren, ohne dass Anmeldeinformationen verwaltet werden müssen. Es gibt zwei Arten von verwalteten Identitäten: vom Benutzer zugewiesen und vom System zugewiesen.
Verwenden einer benutzerseitig zugewiesenen verwalteten Identität
Sie erstellen eine vom Benutzer zugewiesene verwaltete Identität als eigenständige Azure-Ressource. Sie können sie einer oder mehreren Azure-Ressourcen zuweisen, sodass diese Ressourcen dieselbe Identität und Berechtigungen gemeinsam nutzen können. Um sich mithilfe einer vom Benutzer zugewiesenen verwalteten Identität zu authentifizieren, erstellen Sie die Identität, weisen Sie sie Ihrer Azure-Ressource zu, und konfigurieren Sie dann Ihre App so, dass diese Identität für die Authentifizierung verwendet wird, indem Sie ihre Client-ID, Ressourcen-ID oder Objekt-ID angeben.
Verwenden einer systemseitig zugewiesenen verwalteten Identität
Sie aktivieren eine vom System zugewiesene verwaltete Identität direkt in einer Azure-Ressource. Die Identität ist an den Lebenszyklus dieser Ressource gebunden und wird automatisch gelöscht, wenn die Ressource gelöscht wird. Um sich mithilfe einer vom System zugewiesenen verwalteten Identität zu authentifizieren, aktivieren Sie die Identität in Ihrer Azure-Ressource, und konfigurieren Sie Ihre App dann so, dass diese Identität für die Authentifizierung verwendet wird.
Authentifizierung während der lokalen Entwicklung
Während der lokalen Entwicklung können Sie sich mit Azure-Ressourcen authentifizieren, indem Sie Ihre Entwickleranmeldeinformationen oder ein Dienstkonto verwenden. Mit dieser Authentifizierungsmethode können Sie die Authentifizierungslogik Ihrer App testen, ohne sie in Azure bereitzustellen.
Verwenden Sie Entwickleranmeldeinformationen
Sie können Ihre eigenen Azure-Anmeldeinformationen verwenden, um sich während der lokalen Entwicklung bei Azure-Ressourcen zu authentifizieren. In der Regel verwenden Sie ein Entwicklungstool, z. B. Azure CLI, das Ihrer App die erforderlichen Token für den Zugriff auf Azure-Dienste bereitstellen kann. Diese Methode ist praktisch, sollte aber nur für Entwicklungszwecke verwendet werden.
Verwenden eines Dienstprinzipals
Sie erstellen einen Dienstprinzipal in einem Microsoft Entra-Mandanten, der eine App darstellt und zur Authentifizierung bei Azure-Ressourcen verwendet wird. Sie können Ihre App so konfigurieren, dass sie während der lokalen Entwicklung Anmeldeinformationen für das Dienstprinzipal verwendet. Diese Methode ist sicherer als die Verwendung von Entwickleranmeldeinformationen und ist näher an der Authentifizierung Ihrer App in der Produktion. Es ist jedoch immer noch weniger ideal als die Verwendung einer verwalteten Identität aufgrund der Notwendigkeit von geheimen Schlüsseln.
Authentifizierung für lokal gehostete Apps
Für Apps, die on-premises gehostet werden, können Sie ein Dienstprinzipal verwenden, um sich bei Azure Ressourcen zu authentifizieren. Diese Methode umfasst das Erstellen eines Dienstprinzipals in Microsoft Entra ID, das Zuweisen der erforderlichen Berechtigungen und das Konfigurieren Ihrer App für die Nutzung seiner Anmeldeinformationen. Mit dieser Methode kann Ihre lokale App sicher auf Azure-Dienste zugreifen.