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.
Hinweis
Bei kennwortlosen Verbindungen handelt es sich um ein sprachunabhängiges Feature, das sich über mehrere Azure-Dienste erstreckt. Obwohl sich die aktuelle Dokumentation auf einige wenige Sprachen und Dienste konzentriert, sind wir derzeit dabei, zusätzliche Dokumentationen für andere Sprachen und Dienste zu erstellen.
In diesem Artikel werden die Sicherheitsherausforderungen bei Kennwörtern beschrieben und kennwortlose Verbindungen für Azure-Dienste vorgestellt.
Sicherheitsherausforderungen bei Passwörtern und Geheimnissen
Passwörter und geheime Schlüssel sollten mit Vorsicht verwendet werden, und Entwickler dürfen sie niemals an einem unsicheren Ort aufbewahren. Viele Apps stellen eine Verbindung mit Back-End-Datenbanken, Cache-, Messaging- und Ereignisdiensten mithilfe von Benutzernamen, Kennwörtern und Zugriffstasten her. Wenn diese Anmeldeinformationen verfügbar gemacht werden, können diese Anmeldeinformationen verwendet werden, um nicht autorisierten Zugriff auf vertrauliche Informationen wie einen Verkaufskatalog zu erhalten, den Sie für eine bevorstehende Kampagne erstellt haben, oder Kundendaten, die privat sein müssen.
Das Einbetten von Kennwörtern in eine Anwendung selbst stellt aus vielen Gründen ein großes Sicherheitsrisiko dar, einschließlich der Ermittlung über ein Code-Repository. Viele Entwickler externalisieren solche Kennwörter mithilfe von Umgebungsvariablen, damit Anwendungen sie aus verschiedenen Umgebungen laden können. Dies verschiebt jedoch nur das Risiko vom Code selbst in eine Ausführungsumgebung. Jeder, der Zugriff auf die Umgebung erhält, kann Kennwörter stehlen, was wiederum ihr Datenexfiltrationsrisiko erhöht.
Im folgenden Codebeispiel wird veranschaulicht, wie Sie mithilfe eines Speicherkontoschlüssels eine Verbindung mit Azure Storage herstellen. Viele Entwickler fühlen sich zu dieser Lösung hingezogen, weil sie sich mit den Optionen vertraut anfühlt, mit denen sie in der Vergangenheit gearbeitet haben, auch wenn es sich nicht um eine ideale Lösung handelt. Wenn Ihre Anwendung derzeit Zugriffsschlüssel verwendet, sollten Sie die Migration zu kennwortlosen Verbindungen in Betracht ziehen.
// Connection using secret access keys
BlobServiceClient blobServiceClient = new(
new Uri("https://<storage-account-name>.blob.core.windows.net"),
new StorageSharedKeyCredential("<storage-account-name>", "<your-access-key>"));
Entwickler müssen sorgfältig darauf achten, diese Art von Schlüsseln oder Geheimnissen niemals an einem unsicheren Ort verfügbar zu machen. Viele Unternehmen haben strenge Sicherheitsanforderungen, um eine Verbindung mit Azure-Diensten herzustellen, ohne Kennwörter für Entwickler, Operatoren oder andere Personen verfügbar zu machen. Sie verwenden häufig einen Tresor, um Passwörter zu speichern und in Anwendungen zu laden, und reduzieren das Risiko weiter, indem sie Anforderungen und Verfahren für die Passwortrotation hinzufügen. Dieser Ansatz erhöht wiederum die betriebliche Komplexität und führt manchmal zu Ausfällen von Anwendungsverbindungen.
Passwortlose Verbindungen und Zero Trust
Sie können jetzt kennwortlose Verbindungen in Ihren Apps verwenden, um eine Verbindung mit Azure-basierten Diensten herzustellen, ohne Kennwörter rotieren zu müssen. In einigen Fällen benötigen Sie lediglich eine Konfiguration – es ist kein neuer Code erforderlich. Zero Trust verwendet das Prinzip "niemals vertrauen, immer überprüfen und frei von Anmeldeinformationen". Das bedeutet, dass die gesamte Kommunikation durch Vertrauen von Maschinen oder Benutzern erst nach Überprüfung der Identität und vor dem Gewähren des Zugriffs auf Backend-Dienste gesichert wird.
Die empfohlene Authentifizierungsoption für sichere, kennwortlose Verbindungen besteht darin, verwaltete Identitäten und rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Azure in Kombination zu verwenden. Mit diesem Ansatz müssen Sie nicht viele verschiedene Geheimnisse für verwaltete Identitäten manuell nachverfolgen und verwalten, da diese Aufgaben intern sicher von Azure verarbeitet werden.
Sie können passwortlose Verbindungen zu Azure Services mit Hilfe des Konnektors konfigurieren, oder Sie können sie manuell konfigurieren. Der Dienstconnector ermöglicht verwaltete Identitäten in App-Hostingdiensten wie Azure Spring Apps, Azure App Service und Azure Container Apps. Service Connector konfiguriert auch Back-End-Dienste mit kennwortlosen Verbindungen mithilfe verwalteter Identitäten und Azure RBAC und versorgt Anwendungen mit den erforderlichen Verbindungsinformationen.
Wenn Sie die Ausführungsumgebung einer Anwendung überprüfen, die für kennwortlose Verbindungen konfiguriert ist, wird die vollständige Verbindungszeichenfolge angezeigt. Die Verbindungszeichenfolge enthält z. B. eine Datenbankserveradresse, einen Datenbanknamen und eine Anweisung zum Delegieren der Authentifizierung an ein Azure-Authentifizierungs-Plug-In, enthält jedoch keine Kennwörter oder Geheimnisse.
Das folgende Video veranschaulicht kennwortlose Verbindungen von Apps zu Azure-Diensten am Beispiel von Java-Anwendungen. Eine ähnliche Berichterstattung für andere Sprachen ist in Vorbereitung.
Einführung in DefaultAzureCredential
Kennwortlose Verbindungen mit Azure-Diensten über Microsoft Entra ID und rollenbasierte Zugriffssteuerung (Role Based Access Control, RBAC) können mithilfe DefaultAzureCredential der Azure Identity-Clientbibliotheken implementiert werden.
Von Bedeutung
Einige Sprachen müssen DefaultAzureCredential explizit in ihrem Code implementieren, während andere Sprachen DefaultAzureCredential intern durch zugrunde liegende Plug-Ins oder Treiber nutzen.
DefaultAzureCredential unterstützt mehrere Authentifizierungsmethoden und bestimmt automatisch, welche Methode zur Laufzeit verwendet werden soll. Mit diesem Ansatz kann Ihre App unterschiedliche Authentifizierungsmethoden in verschiedenen Umgebungen (lokale Entwicklung gegenüber Produktion) verwenden, ohne umgebungsspezifischen Code zu implementieren.
Die Reihenfolge und die Speicherorte, in denen nach Anmeldeinformationen gesucht wird, DefaultAzureCredential variieren je nach Sprache:
Wenn Sie beispielsweise lokal mit .NET arbeiten, führt DefaultAzureCredential im Allgemeinen eine Authentifizierung mit dem Konto durch, das der Entwickler für die Anmeldung bei Visual Studio, Azure CLI oder Azure PowerShell verwendet hat. Wenn die App in Azure bereitgestellt wird, ermittelt und verwendet DefaultAzureCredential automatisch die verwaltete Identität des zugeordneten Hostingdiensts, z. B. Azure App Service. Für diesen Übergang sind keine Änderungen am Code erforderlich.
Hinweis
Eine verwaltete Identität bietet eine Sicherheitsidentität zur Darstellung einer App oder eines Diensts. Die Identität wird von der Azure-Plattform verwaltet und erfordert nicht, dass Sie Geheimnisse bereitstellen oder rotieren. Weitere Informationen zu verwalteten Identitäten finden Sie in der Übersichtsdokumentation.
Im folgenden Codebeispiel wird veranschaulicht, wie Sie sich über kennwortlose Verbindungen mit Service Bus verbinden. In der anderen Dokumentation wird ausführlicher beschrieben, wie Sie für einen bestimmten Dienst zu diesem Setup migrieren. Eine .NET-App kann eine Instanz von DefaultAzureCredential an den Konstruktor einer Dienstclientklasse übergeben.
DefaultAzureCredential erkennt automatisch die Anmeldeinformationen, die in dieser Umgebung verfügbar sind.
ServiceBusClient serviceBusClient = new(
new Uri("https://<your-service-bus-namespace>.blob.core.windows.net"),
new DefaultAzureCredential());
Siehe auch
Eine ausführlichere Erläuterung kennwortloser Verbindungen finden Sie im Entwicklerhandbuch Konfigurieren kennwortloser Verbindungen zwischen mehreren Azure-Apps und -Diensten.