Freigeben über

Zuordnen von Anforderungen an Mandanten in einer mehrinstanzenfähigen Lösung

Azure

Wenn eine Anforderung in Ihre Anwendung eingeht, müssen Sie den Mandantenkontext ermitteln, bei dem es sich um den Mandanten handelt, der die Anforderung vornimmt. Wenn Sie über mandantenspezifische Infrastruktur verfügen, die möglicherweise in verschiedenen geografischen Regionen gehostet wird, müssen Sie die eingehende Anforderung mit einem Mandanten abgleichen. Anschließend müssen Sie die Anforderung an die physische Infrastruktur weiterleiten, die die Ressourcen dieses Mandanten hosten soll, wie im folgenden Diagramm dargestellt:

Diagramm, das die Zuordnung einer Anforderung von Mandanten zu Bereitstellungen zeigt.

Viele mehrinstanzenfähige Anwendungen verfügen auch über benutzerbasierte Berechtigungen. Die Mandantenzuordnung ist eine separate Aktivität. Sie müssen sowohl den Benutzer kennen, der die Anforderung stellt, als auch den Mandanten, in dem er arbeitet.

Dieser Artikel enthält Anleitungen für technische Entscheidungsträger zu den Ansätzen, die Sie berücksichtigen können, um Anforderungen dem entsprechenden Mandanten zuzuordnen, und die in die Ansätze einbezogenen Kompromisse.

Note

Auf dieser Seite werden hauptsächlich HTTP-basierte Anwendungen wie Websites und APIs erläutert. Viele der gleichen zugrunde liegenden Prinzipien gelten jedoch für mehrinstanzenfähige Anwendungen, die andere Kommunikationsprotokolle verwenden.

Ansätze zur Identifizierung von Mandanten

Es gibt mehrere Möglichkeiten, den Mandanten für eine eingehende Anforderung zu identifizieren. Jeder Ansatz erfordert eine Überprüfung eines Aspekts der eingehenden Anforderung.

Domänennamen

Wenn Sie mandantenspezifische Domänen- oder Unterdomänennamen verwenden, können Anforderungen mithilfe des Headers, des HostX-Forwarded-Host Headers oder eines anderen HTTP-Headers, der den ursprünglichen Hostnamen für jede Anforderung enthält, problemlos Mandanten zugeordnet werden.

Berücksichtigen Sie jedoch die folgenden Fragen:

  • Wie wissen Benutzer, welcher Domänenname für den Zugriff auf den Dienst verwendet werden soll?
  • Haben Sie einen zentralen Einstiegspunkt, z. B. eine Startseite oder Anmeldeseite, die alle Mandanten verwenden? Wenn Sie dies tun, wählen Benutzer den Mandanten aus, mit dem sie arbeiten?
  • Welche anderen Informationen verwenden Sie, um den Zugriff auf die Ressourcen des Mandanten zu überprüfen, z. B. Autorisierungstoken? Enthalten die Autorisierungstoken die mandantenspezifischen Domänennamen?

HTTP-Anforderungseigenschaften

Wenn Sie keine mandantenspezifischen Domänennamen verwenden, können Sie möglicherweise dennoch Aspekte der HTTP-Anforderung verwenden, um den Mandanten zu identifizieren, für den eine bestimmte Anforderung gilt. Ziehen Sie beispielsweise eine HTTP-Anforderung in Betracht, die den Mandantennamen als tailwindtraders. Dies kann mit einem der folgenden Ansätze kommuniziert werden:

  • Die URL-Pfadstruktur, z https://app.contoso.com/tailwindtraders/. B. .
  • Eine Abfragezeichenfolge in der URL, z https://contoso.com/app?tenant=tailwindtraders. B. .
  • Ein benutzerdefinierter HTTP-Anforderungsheader, z Tenant-Id: tailwindtraders. B. .

Important

Benutzerdefinierte HTTP-Anforderungsheader sind nicht hilfreich, wenn HTTP GET-Anforderungen von einem Webbrowser ausgegeben werden oder wo die Anforderungen von einigen Arten von Webproxy behandelt werden. Sie sollten nur benutzerdefinierte HTTP-Header für GET-Vorgänge verwenden, wenn Sie eine API erstellen, oder wenn Sie den Client steuern, der die Anforderung ausgibt und kein Webproxy in der Anforderungsverarbeitungskette enthalten ist, die die Header ändern oder entfernen kann.

Wenn Sie diesen Ansatz verwenden, sollten Sie die folgenden Fragen berücksichtigen:

  • Wissen Benutzer, wie sie auf den Dienst zugreifen können? Wenn Sie z. B. eine Abfragezeichenfolge zum Identifizieren von Mandanten verwenden, muss eine zentrale Zielseite Die Benutzer auf die Seite des richtigen Mandanten weiterleiten, indem Sie die Abfragezeichenfolge hinzufügen?
  • Haben Sie einen zentralen Einstiegspunkt, z. B. eine Startseite oder Anmeldeseite, die alle Mandanten verwenden? Wenn Sie dies tun, wählen Benutzer den Mandanten aus, auf den sie zugreifen müssen?
  • Stellt Ihre Anwendung APIs bereit? Ist Ihre Webanwendung beispielsweise eine Einzelseitenanwendung (Single Page Application, SPA) oder eine mobile Anwendung mit einem API-Back-End? Wenn dies der Fall ist, können Sie möglicherweise ein API-Gateway oder Reverse-Proxy verwenden, um die Mandantenzuordnung durchzuführen.

Tokenansprüche

Viele Anwendungen verwenden anspruchsbasierte Authentifizierungs- und Autorisierungsprotokolle wie OAuth 2.0 oder SAML. Diese Protokolle stellen autorisierungstoken für den Client bereit. Ein Token enthält eine Gruppe von Ansprüchen, bei denen es sich um Informationen zur Clientanwendung oder zum Benutzer handelt. Ansprüche können verwendet werden, um Informationen wie die E-Mail-Adresse eines Benutzers zu kommunizieren. Ihr System kann dann die E-Mail-Adresse des Benutzers einschließen, die Zuordnung von Benutzer zu Mandant nachschlagen und dann die Anforderung an die entsprechende Bereitstellung weiterleiten. Sie können auch die Mandantenzuordnung in Ihr Identitätssystem einschließen und dem Token einen Mandanten-ID-Anspruch hinzufügen.

Wenn Sie Ansprüche zum Zuordnen von Anforderungen an Mandanten verwenden, sollten Sie die folgenden Fragen in Betracht ziehen:

  • Verwenden Sie einen Anspruch, um einen Mandanten zu identifizieren? Welchen Anspruch verwenden Sie?
  • Kann ein Benutzer Mitglied mehrerer Mandanten sein? Wenn dies möglich ist, wählen Benutzer den Mandanten aus, mit dem sie für eine bestimmte Anforderung arbeiten möchten?
  • Gibt es ein zentrales Authentifizierungs- und Autorisierungssystem für alle Mandanten? Wenn nicht, wie stellen Sie sicher, dass alle Tokenzertifizierungsstellen konsistente Token und Ansprüche ausstellen?

API-Schlüssel

Viele Anwendungen machen APIs verfügbar. Dies kann für die interne Verwendung innerhalb Ihrer Organisation oder für die externe Verwendung durch Partner oder Kunden erfolgen. Eine gängige Authentifizierungsmethode für APIs besteht darin, einen API-Schlüssel zu verwenden. API-Schlüssel werden für jede Anforderung bereitgestellt. Wenn Sie die Mandanten-ID aufzeichnen, für die ein Schlüssel ausgestellt wurde, können Sie die Mandanten-ID nachschlagen, wenn der verwendete Schlüssel verwendet wird.

Note

API-Schlüssel bieten keine hohe Sicherheit, da sie manuell erstellt und verwaltet werden müssen, sie langlebig und häufig wiederverwendet werden und weil sie keine Ansprüche enthalten. Ein modernerer und sichererer Ansatz besteht darin, einen anspruchsbasierten Autorisierungsmechanismus mit kurzlebigen Token wie OAuth 2.0 oder OpenID Connect zu verwenden.

API-Schlüssel können auf verschiedene Arten generiert werden. Hier sind zwei gängige Ansätze:

  • Generieren Sie einen kryptografisch zufälligen Wert, und speichern Sie ihn zusammen mit der Mandanten-ID in einer Nachschlagetabelle. Wenn eine Anforderung empfangen wird, findet Ihr System den API-Schlüssel in der Nachschlagetabelle und stimmt sie dann mit einer Mandanten-ID überein.
  • Erstellen Sie eine aussagekräftige Zeichenfolge mit einer darin enthaltenen Mandanten-ID. Digital signieren Sie den Schlüssel mithilfe eines Ansatzes wie HMAC. Wenn Sie jede Anforderung verarbeiten, überprüfen Sie die Signatur, und extrahieren Sie dann die Mandanten-ID.

Berücksichtigen Sie die folgenden Fragen:

  • Wie generieren und ausgeben Sie API-Schlüssel?
  • Wie erhalten Ihre API-Clients den API-Schlüssel sicher und speichern sie?
  • Müssen Ihre API-Schlüssel nach einem bestimmten Zeitraum ablaufen? Wie können Sie die API-Schlüssel Ihrer Clients drehen, ohne ausfallzeiten zu verursachen?
  • Bieten vom Kunden generierte API-Schlüssel eine angemessene Sicherheitsstufe für Ihre APIs?

Note

API-Schlüssel sind nicht mit Kennwörtern identisch. API-Schlüssel müssen vom System generiert werden, und sie müssen für alle Mandanten eindeutig sein, damit jeder API-Schlüssel einem einzelnen Mandanten eindeutig zugeordnet werden kann. API-Gateways, z. B. Azure API Management, können API-Schlüssel generieren und verwalten, Schlüssel für eingehende Anforderungen überprüfen und Schlüssel einzelnen API-Abonnenten zuordnen.

Clientzertifikate

Clientzertifikatauthentifizierung, manchmal auch als gegenseitiges TLS (mTLS) bezeichnet, wird häufig für die Dienst-zu-Dienst-Kommunikation und für unbeaufsichtigte Geräte oder Kioske verwendet, die von nicht authentifizierten Benutzern verwendet werden. Clientzertifikate bieten eine sichere Möglichkeit zum Authentifizieren von Clients. Ähnlich wie Token und Ansprüche stellen Clientzertifikate Attribute bereit, mit denen der Mandant bestimmt werden kann. Der Betreff des Zertifikats kann z. B. die E-Mail-Adresse des Benutzers enthalten, die zum Nachschlagen des Mandanten verwendet werden kann.

Berücksichtigen Sie bei der Planung der Verwendung von Clientzertifikaten für die Mandantenzuordnung die folgenden Faktoren:

  • Wie können Sie die Von Ihrem Dienst vertrauenswürdigen Clientzertifikate sicher ausstellen und erneuern? Clientzertifikate können für die Arbeit mit komplexen Daten komplex sein, da sie eine spezielle Infrastruktur zum Verwalten und Ausstellen von Zertifikaten benötigen. Bei unsachgemäßer Behandlung können diese Komplexitäten Ihre Sicherheit reduzieren , anstatt sie zu erhöhen.
  • Werden Clientzertifikate nur für anfängliche Anmeldeanforderungen verwendet oder an alle Anforderungen an Ihren Dienst angefügt?
  • Wird der Prozess der Ausstellung und Verwaltung von Zertifikaten unwaltbar, wenn Sie über eine große Anzahl von Clients verfügen?
  • Wie implementieren Sie die Zuordnung zwischen dem Clientzertifikat und dem Mandanten?

Umgekehrte Proxys

Ein Reverseproxy, auch als Anwendungsproxy bezeichnet, kann zum Weiterleiten von HTTP-Anforderungen verwendet werden. Ein Reverseproxy akzeptiert eine Anforderung von einem Eingangsendpunkt und kann die Anforderung an einen der vielen Back-End-Endpunkte weiterleiten. Reverseproxys sind nützlich für mehrinstanzenfähige Anwendungen, da sie die Zuordnung zwischen einigen Anforderungsinformationen ausführen können, um die Aufgabe aus der Anwendungsinfrastruktur zu entladen.

Viele Reverseproxys können die Eigenschaften einer Anforderung verwenden, um eine Entscheidung über das Mandantenrouting zu treffen. Sie können den Zieldomänennamen, den URL-Pfad, die Abfragezeichenfolge, HTTP-Header und sogar Ansprüche innerhalb von Token oder Teilen des Anforderungstexts überprüfen.

Die folgenden gängigen Reverseproxys werden in Azure verwendet:

  • Azure Front Door ist ein globaler Lastenausgleich und eine Webanwendungsfirewall. Es verwendet das globale Microsoft Edge-Netzwerk, um schnelle, sichere und hoch skalierbare Webanwendungen zu erstellen. Sie können Regelsätze verwenden, um Mandanten-IDs zu extrahieren und sie in einen anderen Teil der Anforderung einzufügen.
  • Das Azure-Anwendungsgateway ist ein verwalteter Lastenausgleich für Webdatenverkehr, den Sie in derselben physischen Region wie Ihr Back-End-Dienst bereitstellen.
  • Azure API Management ist für API-Datenverkehr optimiert. Azure API Management bietet ein umfassendes Richtlinienmodul , das eine große Flexibilität zum Extrahieren von Mandanteninformationen aus Anforderungen bietet.
  • Kommerzielle und Open-Source-Technologien (die Sie selbst hosten) umfassen nginx, Traefik und HAProxy.

Anforderungsvalidierung

Es ist wichtig, dass Ihre Anwendung überprüft, ob alle empfangenen Anforderungen für den Mandanten autorisiert sind. Wenn Ihre Anwendung beispielsweise einen benutzerdefinierten Domänennamen verwendet, um Anforderungen dem Mandanten zuzuordnen, muss Ihre Anwendung dennoch überprüfen, ob jede von der Anwendung empfangene Anforderung für diesen Mandanten autorisiert ist. Obwohl die Anforderung einen Domänennamen oder einen anderen Mandantenbezeichner enthält, bedeutet dies nicht, dass Sie automatisch Zugriff gewähren sollten. Wenn Sie OAuth 2.0 verwenden, führen Sie die Überprüfung durch Prüfen der Zielgruppen - und Bereichsansprüche durch.

Note

Dies ist Teil des Annahme-von-Sicherheitsvorfall-Sicherheitsentwurfsprinzips im Microsoft Azure Well-Architected Framework.

Berücksichtigen Sie bei der Implementierung der Anforderungsüberprüfung die folgenden Faktoren:

  • Wie autorisieren Sie alle Anforderungen an Ihre Anwendung? Sie müssen Anforderungen autorisieren, unabhängig vom Ansatz, den Sie verwenden, um sie physischer Infrastruktur zuzuordnen.
  • Verwenden Sie vertrauenswürdige, weit verbreitete und gut gepflegte Authentifizierungs- und Autorisierungsframeworks und Middleware, anstatt alle Validierungslogik selbst zu implementieren. Erstellen Sie beispielsweise keine Tokensignaturüberprüfungslogik oder Clientzertifikatkryptografiebibliotheken. Verwenden Sie stattdessen Features Ihrer Anwendungsplattform (oder bekannte vertrauenswürdige Pakete), die überprüft und getestet wurden.

Performance

Die Mandantenzuordnungslogik wird wahrscheinlich für jede Anforderung ihrer Anwendung ausgeführt. Überlegen Sie, wie gut der Mandantenzuordnungsprozess skaliert wird, wenn Ihre Lösung wächst. Wenn Sie beispielsweise eine Datenbanktabelle als Teil Ihrer Mandantenzuordnung abfragen, unterstützt die Datenbank eine große Menge an Last? Wenn für Ihre Mandantenzuordnung eine Entschlüsselung eines Tokens erforderlich ist, werden die Berechnungsanforderungen im Laufe der Zeit zu hoch? Wenn Ihr Datenverkehr relativ bescheiden ist, wirkt sich dies wahrscheinlich nicht auf die Gesamtleistung aus. Wenn Sie jedoch über eine anwendung mit hoher Skalierung verfügen, kann der Aufwand, der an dieser Zuordnung beteiligt ist, erheblich werden.

Sitzungscookies

Ein Ansatz zur Verringerung des Leistungsaufwands der Mandantenzuordnungslogik besteht darin, Sitzungscookies zu verwenden. Anstatt die Zuordnung für jede Anforderung durchzuführen, sollten Sie die Informationen nur für die erste Anforderung für jede Sitzung berechnen. Ihre Anwendung stellt dann dem Client ein Sitzungscookies bereit. Der Client übergibt das Sitzungscookies an Ihren Dienst mit allen nachfolgenden Clientanforderungen innerhalb dieser Sitzung.

Note

Viele Netzwerk- und Anwendungsdienste in Azure können Sitzungscookies ausgeben.

Berücksichtigen Sie die folgenden Fragen:

  • Können Sie Sitzungscookies verwenden, um den Aufwand der Zuordnung von Anforderungen an Mandanten zu verringern?
  • Welche Dienste verwenden Sie, um Anforderungen an die physischen Bereitstellungen für jeden Mandanten weiterzuleiten? Unterstützen diese Dienste Cookie-basierte Sitzungen?

Mandantenmigration

Mandanten müssen häufig im Rahmen des Mandantenlebenszyklus in eine neue Infrastruktur verschoben werden. Wenn ein Mandant in eine neue Bereitstellung verschoben wird, können sich die HTTP-Endpunkte, auf die sie zugreifen, ändern. Berücksichtigen Sie in diesem Fall, dass sich der Mandantenzuordnungsprozess ändern muss. Möglicherweise müssen Sie die folgenden Faktoren berücksichtigen:

  • Wenn Ihre Anwendung Domänennamen für Zuordnungsanforderungen verwendet, ist möglicherweise auch eine DNS-Änderung zum Zeitpunkt der Migration erforderlich. Die DNS-Änderung kann je nach Zeit-zu-Live(TTL) der DNS-Einträge in Ihrem DNS-Dienst an Clients weitergegeben werden.
  • Wenn Ihre Migration die Adressen von Endpunkten während des Migrationsprozesses ändert, sollten Sie anforderungen für den Mandanten vorübergehend auf eine Wartungsseite umleiten, die automatisch aktualisiert wird.

Contributors

Dieser Artikel wird von Microsoft verwaltet. Sie wurde ursprünglich von den folgenden Mitwirkenden verfasst.

Hauptautor:

Andere Mitwirkende:

Um nicht öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

Erfahren Sie mehr über Überlegungen beim Arbeiten mit Domänennamen in einer Mehrinstanzenanwendung.