Freigeben über

Implementieren der mandantenübergreifenden Kommunikation mithilfe von mehrinstanzenfähigen Anwendungen

  • Artikel

Diese Anleitung bietet eine Lösung zum Herstellen bidirektionaler, sicherer Kommunikation zwischen den in Azure-Abonnements gehosteten Diensten, die von verschiedenen Microsoft Entra-Mandanten verwaltet werden.

Das Sichern der mehrinstanzenfähigen Kommunikation in Azure kann aufgrund von Einschränkungen, die vielen Diensten eigen sind, eine Herausforderung darstellen. Sie können die direkte Verwaltung von Anmeldedaten vermeiden, indem Sie von Azure verwaltete Identitäten verwenden, um Token von Microsoft Entra ID abzurufen. Von Azure verwaltete Identitäten funktionieren jedoch nicht über Mandantengrenzen hinweg, und die typische Alternative besteht darin, freigegebene geheime Schlüssel wie URLs für gemeinsame Zugriffssignaturen zu verwenden. Denken Sie daran, dass Sie bei Verwendung freigegebener geheimer Schlüssel die geheimen Schlüssel über Microsoft Entra-Mandantengrenzen hinweg sicher verteilen und rotieren müssen.

Eine Option, die diesen Aufwand vermeidet, ist die Erstellung einer mandantenfähigen Anwendung, die die Identität Ihres Workloads darstellt. Durch einen Zustimmungsprozess können Sie diese Workload-Identität einem externen Mandanten bekannt machen und letztendlich zulassen, Dienste im externen Mandanten zu authentifizieren.

In diesem Artikel wird eine Beispielimplementierung dieses Musters mit einem Beispielcode erläutert.

Dieses Muster kann für jedes Szenario mit mehreren Mandanten wiederverwendet werden, das über verschiedene Dienste verfügt, die über Microsoft Entra-Mandantengrenzen hinweg kommunizieren müssen.

Aufbau

Ein Diagramm der mandantenübergreifenden Kommunikationsarchitektur.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Workflow

Der folgende Workflow entspricht dem vorherigen Diagramm:

  1. Ein Administrator auf der Anbieterseite erstellt eine mehrinstanzenfähige Anwendungsregistrierung und richtet einen geheimen Clientschlüssel dafür ein.

  2. Ein Administrator auf der Kundenseite stellt einen Dienstprinzipal in seinem Mandanten bereit. Dieser Dienstprinzipal basiert auf der mehrinstanzenbasierten Anwendung, die der Anbieter erstellt hat. Für die Ausführung dieses Schritts gibt es mehrere Möglichkeiten. Im Beispiel haben wir eine URL erstellt, die dem Kundenmandantenadministrator zur Verfügung gestellt wird, Sie können stattdessen aber auch die Microsoft Graph-API verwenden.

  3. Der Kunde wendet rollenbasierte Zugriffssteuerungsrollen (RBAC) auf diesen neuen Dienstprinzipal an, sodass er für den Zugriff auf Azure Service Bus autorisiert ist.

  4. Die Funktions-App des Anbieters verwendet die Client-ID und den geheimen Clientschlüssel der Anwendungsregistrierung, um eine authentifizierte Nachricht an die Service Bus-Warteschlange des Kunden zu senden.

  5. Die Funktions-App des Kunden verwendet eine verwaltete Identität, um die Nachricht des Anbieters über einen Service Bus-Trigger aus der Warteschlange zu lesen.

  6. Nachdem die Nachricht empfangen wurde, erledigt die Funktions-App des Kunden in der Regel einige Aufgaben, bevor eine Statusmeldung an den Anbieter gesendet wird. In diesem Fall sendet die Funktions-App sofort eine Statusmeldung an den Anbieter in einer separaten Warteschlange im gleichen Service Bus.

  7. Diese Funktions-App liest aus der Statuswarteschlange vom Mandanten des Kunden über einen Timer, den Azure Functions auslöst.

Szenariodetails

Ein Anbieter hat mehrere Kunden. Der Anbieter und jeder seiner Kunden verfügen über einen eigenen individuellen Microsoft Entra ID-Mandanten und Azure-Ressourcen. Der Anbieter und jeder seiner Kunden benötigen eine sichere, bidirektionale Kommunikationsmethode, um Nachrichten über Service Bus-Warteschlangen auszutauschen. Die Lösung sollte über eine überzeugende Identitätsgeschichte verfügen, die unnötige oder geheime Anmeldeinformationen vermeidet.

Wissenswertes zu Mehrinstanzenanwendungen

  • Ein Anwendungsobjekt ist eine global eindeutige Instanz der Anwendung.

  • Wenn eine Anwendung in Microsoft Entra registriert wird, werden automatisch ein Anwendungsobjekt und ein Dienstprinzipalobjekt in dem Mandanten erstellt.

  • Ein Dienstprinzipalobjekt wird in jedem Mandanten erstellt, der die Anwendung verwendet und auf das Anwendungsobjekt verweist. Ein Anwendungsobjekt hat eine 1:n-Beziehung mit dem entsprechenden Dienstprinzipalobjekt.

  • Das Anwendungsobjekt ist die alle Mandanten übergreifende globale Darstellung Ihrer Anwendung. Das Dienstprinzipalobjekt ist die lokale Darstellung, die in einem bestimmten Mandanten verwendet wird.

  • Ein Dienstprinzipalobjekt muss in jedem Mandanten erstellt werden, in dem die Anwendung verwendet wird, sodass es eine Identität für die Anmeldung und den Zugriff auf vom Mandanten gesicherte Ressourcen einrichten kann. Eine Anwendung mit nur einem Mandanten verfügt auf diesem Basismandanten nur über ein Dienstprinzipalobjekt. Dieser Dienstprinzipalobjekt wird während der Anwendungsregistrierung erstellt, und die Zustimmung für die Verwendung wird eingerichtet. Eine Anwendung mit mehreren Mandanten verfügt außerdem über ein Dienstprinzipalobjekt, das in jedem Mandanten erstellt wird, für den ein Benutzer des Mandanten zur Verwendung zugestimmt hat.

  • Um auf Ressourcen zugreifen zu können, die von einem Microsoft Entra-Mandanten geschützt werden, muss ein Sicherheitsprinzipal die Entität darstellen, die Zugriff benötigt.

  • Wenn eine Anwendung die Berechtigung zum Zugriff auf Ressourcen in einem Mandanten erhält (bei der Registrierung oder Zustimmung), wird ein Dienstprinzipalobjekt erstellt. Diese Architektur wird mit dem Einwilligungsflow implementiert.

Wie benachrichtigt der Anbieter den Kunden?

Im Idealfall kann der Anbieter der Azure-Computeressource eine verwaltete Identität zuweisen, die für das Senden von Nachrichten an die Warteschlange eines Kunden zuständig ist. Der Mandant des Kunden ist so konfiguriert, dass verwaltete Identitäten aus dem Mandanten des Anbieters vertrauenswürdig sind. Ein echter Partnerverbund zwischen zwei Microsoft Entra-Mandanten, der im Wesentlichen die „Freigabe“ von Identitäten von einem Mandanten zu einem anderen zulassen würde, ist derzeit nicht möglich. Der Anbieter muss sich also mithilfe einer Identität authentifizieren, die der Kunde erkennt. Der Anbieter muss sich beim Microsoft Entra-Mandanten des Kunden als Dienstprinzipal authentifizieren, den der Kunde kennt.

Es wird empfohlen, dass der Anbieter eine mehrinstanzenfähige Anwendung in seinem eigenen Mandanten registriert und dann jedem Kunden einen zugeordneten Dienstprinzipal in seinem Mandanten bereitstellt. Der Anbieter kann sich dann mit diesem Dienstprinzipal bei dem Mandanten des Kunden und den vom Kunden gehosteten APIs authentifizieren. Bei diesem Ansatz muss der Anbieter niemals einen geheimen Clientschlüssel freigeben. Die Verwaltung von Anmeldeinformationen liegt in der alleinigen Verantwortung des Anbieters.

Wie benachrichtigt der Kunde den Anbieter?

Der Kunde sollte eine Warteschlange erstellen oder hosten, aus der der Anbieter lesen kann. Der Kunde schreibt eine Nachricht in die Warteschlange. Der Anbieter fragt wiederholt jede Kundenwarteschlange auf Nachrichten mithilfe eines Dienstprinzipalobjekts ab. Der Nachteil dieses Ansatzes besteht darin, dass eine Abfragelatenz besteht, wenn der Anbieter eine Nachricht empfängt. Außerdem muss der Code im Anbieter häufiger ausgeführt werden, da er aufwachen und eine Abfragelogik ausführen muss, anstatt auf ein Ereignis zu warten, das ihn auslöst. Die Verwaltung der Anmeldeinformationen bleibt jedoch in der alleinigen Verantwortung des Anbieters, was die Sicherheit erhöht.

Eine weitere mögliche Lösung besteht darin, dass der Anbieter eine Warteschlange für jeden seiner Kunden erstellt oder hostet. Jeder Kunde erstellt eine eigene mehrinstanzenfähige Anwendung und fordert an, dass der Anbieter sie in seinem Mandanten als Dienstprinzipalobjekt bereitstellt. Der Kunde verwendet dann dieses Dienstprinzipalobjekt, um Nachrichten an eine kundenspezifische Warteschlange auf der Anbieterseite zu senden. Die Verwaltung von Anmeldeinformationen bleibt in der alleinigen Verantwortung des Kunden. Ein Nachteil dieses Ansatzes ist, dass der Anbieter Dienstprinzipale bereitstellen muss, die Kundenanwendungen in seinem Mandanten zugeordnet sind. Dieser Prozess ist manuell, und die Anbieter möchten manuelle Schritte als Teil des Ablaufs für das Onboarding eines neuen Kunden möglicherweise vermeiden.

Einrichten von Beispielcode

Die folgenden Schritte führen Sie durch den Prozess der Einrichtung der mandantenübergreifenden Kommunikation zwischen einem Anbieter und einem Kunden.

Anbietereinrichtung

Das Anbietersetup enthält die Schritte zum Generieren und Bereitstellen eines Mehrinstanzendienstprinzipals und der Schritte zum Bereitstellen des Kundenmandanten.

  1. Erstellen Sie eine HTTP-ausgelöste Funktions-App, um eine Nachricht in die Service Bus-Befehlswarteschlange des Kunden innerhalb des Kundenmandanten zu schreiben.

  2. Erstellen Sie eine zeitgesteuerte Funktions-App, um in regelmäßigen Abständen eine Statuswarteschlange im Service Bus des Kunden innerhalb des Kundenmandanten zu überprüfen.

Erstellen einer mehrinstanzenfähigen Anwendung innerhalb des Mandanten des Anbieters

Erstellen Sie zunächst eine mehrinstanzenfähige Anwendung im Mandanten des Anbieters, und stellen Sie diese Identität innerhalb des Mandanten des Kunden bereit. In diesem Szenario ist die Identität ein Dienstprinzipal. Die Architektur weiter oben in diesem Artikel zeigt, wie Sie einen Dienstprinzipal vom Mandanten des Anbieters im Mandanten des Kunden einrichten und bereitstellen. Die Architektur beschreibt auch die Bereitstellung mit mehreren Microsoft Entra-Mandanten.

  1. Wählen Sie die Option „Mehrinstanzenfähige Organisation“ aus.

  2. Fügen Sie die folgende Website als Umleitungs-URI hinzu: https://entra.microsoft.com. Sie können diesen URI entsprechend Ihren Geschäftsanforderungen ändern.

  3. Registrieren Sie und notieren Sie sich den Anwendungs-(Client-)ID-Wert.

Erstellen eines neuen geheimen Clientschlüssels

  1. Nachdem Sie die Mehrinstanzenanwendung erstellt haben, erstellen Sie einen geheimen Clientschlüssel für diesen Dienstprinzipal.

  2. Speichern Sie den generierten geheimen Schlüssel an einem sicheren Ort. Der geheime Schlüssel und die Client-ID sind Ihre Clientanmeldeinformationen, die zum Austauschen des Codes, im Autorisierungscodefluss und für ein ID-Token im nächsten Schritt erforderlich sind.

HTTP-Trigger in Azure Functions

Verwenden Sie die HTTP-Funktion, um die Bereitstellung aus dem Mandanten des Anbieters zu starten, indem Sie eine Nachricht in die Service Bus-Bereitstellungswarteschlange des Kunden senden. Wir haben die HTTP-ausgelöste Funktion als Übermittlungsmethode ausgewählt, um diesen Proof-of-Concept zu starten. Der zuvor generierte Dienstprinzipal fungiert als Anmeldeinformationen für den Zugriff auf den Kundenmandanten und schreibt in eine bestimmte Warteschlange innerhalb von Service Bus. Außerdem müssen Sie das Kundensetup abschließen, damit dieser Schritt ordnungsgemäß funktioniert.

Zeitgesteuerte Trigger in Azure Functions

Verwenden Sie die zeitgesteuerte Funktion, um die Bereitstellungsstatuswarteschlange aus dem Mandanten des Kunden abzufragen. In diesem Proof-of-Concept wird die Bereitstellungsstatuswarteschlange für Demozwecke alle 10 Sekunden abgefragt. Bei diesem Ansatz muss der Kunde keinen Dienstprinzipal haben, um auf den Mandanten des Anbieters zuzugreifen.

Kundensetup

  1. Stellen Sie den Dienstprinzipal bereit, indem Sie die bereitgestellte URL ändern und verwenden.

  2. Beschränken Sie den Anbieterdienstprinzipal auf die Verwendung der entsprechenden RBAC-Steuerelemente.

  3. Erstellen Sie eine ausgelöste Service Bus-Funktion, um eine Nachricht aus einer Service Bus-Nachrichtenwarteschlange zu lesen und eine Nachricht in eine andere Warteschlange zu schreiben. Für Demozwecke ist dieser Fluss optimal, um die Funktionalität zu testen.

  4. Erstellen Sie eine vom System zugewiesene verwaltete Identität für die vom Service Bus ausgelöste Funktion.

  5. Weisen Sie den vom System zugewiesenen verwalteten Identitäts-Service Bus-Bereich zu.

Bereitstellen des Dienstprinzipals vom Mandanten des Anbieters an den Mandanten des Kunden

  1. Besuchen Sie die folgende URL, nachdem Sie den client_id Abfragezeichenfolgenparameter durch Ihre eigene Client-ID ersetzt haben: https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?response_type=code&response_mode=query&scope=openid&client_id=<your_client_ID>

    Sie können den Dienstprinzipal auch in einem anderen Microsoft Entra-Mandanten mit einem Administrator-Microsoft Graph-API-Aufruf, einem Azure PowerShell-Befehl oder einem Azure CLI-Befehl bereitstellen.

  2. Melden Sie sich mit einem Konto des Mandanten des Kunden an.

  3. Wählen Sie auf dem Einwilligungsbildschirm Annehmen aus, um die Anwendung des Anbieters im Kundenmandanten bereitzustellen. Die URL leitet schließlich zu microsoft.com weiter, was immer noch den gewünschten Effekt der Bereitstellung der Identität im Kundenmandanten hat.

  4. Überprüfen Sie die Identität im Microsoft Entra-Mandanten des Kunden, indem Sie zu Unternehmensanwendungen wechseln, um den neu bereitgestellten Dienstprinzipal anzuzeigen.

Einrichten von RBAC für den bereitgestellten Dienstprinzipal

Beschränken Sie den Anbieterdienstprinzipal aus dem Anbieterdienstprinzipalsetup um die Rolle „Service Bus Data Owner“ auf dem Service Bus. Dieser Dienstprinzipal wird sowohl beim Schreiben in eine Warteschlange mit einer HTTP-ausgelösten Funktion als auch beim Lesen aus einer Warteschlange aus einer zeitgesteuerten Funktion verwendet. Stellen Sie sicher, dass Sie dem Dienstprinzipal die Rolle „Azure Service Bus Data Owner“ hinzufügen.

Service Bus-Trigger in Azure Functions

Führen Sie die Schritte im Tutorial für identitätsbasierte Funktionen aus, um den Funktionstrigger aus der Service Bus-Warteschlange zu definieren und zu erfahren, wie Sie eine verwaltete Identität einrichten. Diese Anleitung hilft Ihnen, die Funktions-App aus der Service Bus-Warteschlange auszulösen, wenn eine Nachricht der Warteschlange hinzugefügt wird. Sie verwenden auch die verwaltete Identität, wenn Sie eine Nachricht in eine andere Warteschlange schreiben. Für Demozwecke verwenden wir dieselbe Funktion, um die Nachricht zu senden.

Wählen Sie in Ihrem neu erstellten Service Bus-Namespace die Option Zugriffssteuerung (IAM) aus. Sie können anzeigen und konfigurieren, wer Zugriff auf die Ressource in der Steuerungsebene hat.

Erteilen Sie der Funktions-App mithilfe von verwalteten Identitäten den Zugriff auf den Service Bus-Namespace.

  1. Stellen Sie sicher, dass Sie der verwalteten Identität die Rolle „Azure Service Bus Data Receiver“ hinzufügen.

  2. Wählen Sie in der Auswahl „Verwaltete Identität“ aus der Kategorie Systemseitig zugewiesene verwaltete Identität die Option Funktions-App aus. Die Beschriftung Funktions-App weist möglicherweise eine Zahl in Klammern daneben auf. Diese Zahl gibt an, wie viele Apps mit vom System zugewiesenen Identitäten im Abonnement vorhanden sind.

Herstellen einer Verbindung mit Service Bus in Ihrer Funktions-App

  1. Suchen Sie im Portal nach Ihrer Funktions-App, oder wechseln Sie auf der Seite Funktions-App zu ihr.

  2. Wählen Sie unter Anwendungseinstellungen die Option + Neue Anwendungseinstellung aus, um die neue Anwendungseinstellung in der folgenden Tabelle zu erstellen. Service BusConnection__fullyQualifiedNamespace <SERVICE_BUS_NAMESPACE>.Service Bus.windows.net.

Lebenszyklusverwaltung des geheimen Clientschlüssels des Dienstprinzipals

Wenn Sie geheime Schlüssel in Ihre mandantenübergreifende Architektur einführen, müssen Sie den Lebenszyklus dieser generierten geheimen Clientschlüssel verwalten. Unter Bewährte Methoden für die Verwaltung von Geheimschlüsseln finden Sie weitere Informationen zum sicheren Speichern, Rotieren und Überwachen der geheimen Clientschlüssel.

Lokale Einstellungen

Jedes Unterverzeichnis enthält eine Stubversion der local.settings.json-Dateien, die zum lokalen Ausführen der Azure-Funktionen geändert werden können. Um Einstellungen in Azure zu konfigurieren, aktualisieren Sie die Anwendungseinstellungen.

Der Befehl DefaultAzureCredential listet mehrere Einstellungen auf, bevor er die Azure CLI-Anmeldeinformationen erreicht. Um Verwirrung zu vermeiden, empfehlen wir, beim Entwickeln lokaler Funktionen den Befehl az login -t <tenant ID> auszuführen, um die richtigen Anmeldeinformationen auszuwählen.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Nächste Schritte