Architekturansätze für Identität in mehrinstanzenfähigen Lösungen

  • Artikel

Fast alle mehrinstanzenfähigen Lösungen erfordern ein Identitätssystem. In diesem Artikel erörtern wir häufige Komponenten von Identität, einschließlich Authentifizierung und Autorisierung, und wir beschreiben, wie diese Komponenten in einer mehrinstanzenfähigen Lösung angewendet werden können.

Hinweis

Lesen Sie den Artikel über Architekturaspekte zur Identität in einer mehrinstanzenfähigen Lösung, um mehr über die wichtigsten Anforderungen und Entscheidungen zu erfahren, die Sie treffen müssen, bevor Sie ein Identitätssystem für eine mehrinstanzenfähige Lösung erstellen.

Authentifizierung

Die Authentifizierung ist der Prozess, durch den die Identität eines Benutzers festgestellt wird. Wenn Sie eine mehrinstanzenfähige Lösung erstellen, gibt es spezielle Überlegungen und Ansätze für verschiedene Aspekte des Authentifizierungsprozesses.

Verbund

Möglicherweise müssen Sie sich mit anderen Identitätsanbietern (IdPs) zusammenschließen. Der Verbund kann verwendet werden, um die folgenden Szenarios zu ermöglichen:

  • Anmeldung über soziale Medien, z. B. indem Benutzer*innen ihr Google-, Facebook-, GitHub- oder persönliches Microsoft-Konto verwenden können.
  • Mandantenspezifische Verzeichnisse, z. B. indem Mandaten die Möglichkeit gegeben wird, Ihre Anwendung mit ihren eigenen Identitätsanbietern zu verbinden, damit sie ihre Konten nicht an verschiedenen Stellen verwalten müssen.

Allgemeine Informationen zum Verbund finden Sie im Muster Verbundidentität.

Wenn Sie sich dafür entscheiden, mandantenspezifische Identitätsanbieter zu unterstützen, ist zu klären, welche Dienste und Protokolle unterstützt werden müssen. Möchten Sie beispielsweise das OpenID Connect-Protokoll und das SAML-Protokoll (Security Assertion Markup Language) unterstützen? Oder soll lediglich der Verbund mit Microsoft Entra-Instanzen unterstützt werden?

Wenn Sie einen Identitätsanbieter implementieren, sollten Sie alle Skalierungen und Einschränkungen berücksichtigen, die gelten könnten. Wenn Sie beispielsweise Azure Active Directory (Azure AD) B2C als Ihren eigenen Identitätsanbieter verwenden, müssen Sie möglicherweise benutzerdefinierte Richtlinien bereitstellen, um mit bestimmten Arten von Mandantenidentitätsanbietern zusammenzuarbeiten. Azure AD B2C beschränkt die Anzahl der benutzerdefinierten Richtlinien, die Sie bereitstellen können, wodurch möglicherweise die Anzahl der mandantenspezifischen Identitätsanbieter eingeschränkt wird, mit denen Sie einen Verbund herstellen können.

Sie können auch die Bereitstellung eines Verbunds als Feature in Betracht ziehen, das nur für Kund*innen auf einer höheren Produktklasse gilt.

Einmaliges Anmelden

Mit dem einmaligen Anmelden können Benutzer*innen nahtlos zwischen Anwendungen wechseln, ohne dass sie sich jedes Mal neu authentifizieren müssen.

Wenn Benutzer*innen eine Anwendung öffnen, leitet die Anwendung sie an einen IdP weiter. Wenn der IdP eine laufende Sitzung erkennt, stellt er ein neues Token aus, sodass die Benutzer*innen den Anmeldevorgang nicht erneut durchlaufen müssen. Ein Verbundidentitätsmodell unterstützt das einmalige Anmelden, indem Benutzer*innen eine Identität in mehreren Anwendungen verwenden können.

In einer mehrinstanzenfähigen Lösung können Sie möglicherweise auch eine andere Form des einmaligen Anmeldens aktivieren. Wenn Benutzer*innen berechtigt sind, mit Daten für mehrere Mandanten zu arbeiten, möchten Sie diesen eventuell einen reibungslosen Wechsel ihres Kontexts zwischen den Mandanten ermöglichen. Überlegen Sie, ob Sie nahtlose Übergänge zwischen Mandanten unterstützen müssen, und wenn ja, ob Ihr Identitätsanbieter Token mit bestimmten Mandantenansprüchen neu ausgeben muss. Beispielsweise können Benutzer*innen, die sich beim Azure-Portal angemeldet haben, zwischen verschiedenen Microsoft Entra-Verzeichnissen wechseln. Dies hat eine erneute Authentifizierung zur Folge, und das Token wird von der neu ausgewählten Microsoft Entra-Instanz neu ausgestellt.

Anmelderisikobewertung

Moderne Identitätsplattformen unterstützen eine Risikobewertung während des Anmeldeprozesses. Wenn sich Benutzer*innen beispielsweise von einem ungewöhnlichen Ort oder Gerät aus anmelden, kann das Authentifizierungssystem zusätzliche Identitätsprüfungen verlangen, wie z. B. eine mehrstufige Authentifizierung (MFA), bevor es die Anmeldeanfrage freigibt.

Überlegen Sie, ob Ihre Mandanten gegebenenfalls unterschiedliche Risikorichtlinien haben, die während des Authentifizierungsprozesses anzuwenden sind. Wenn Sie zum Beispiel einige Mandanten in einer stark regulierten Branche haben, können diese andere Risikoprofile und Anforderungen aufweisen als Mandanten, die in einem weniger regulierten Umfeld eingesetzt werden. Oder Sie können Mandanten höherer Preisstufen erlauben, strengere Anmeldungsrichtlinien festzulegen als Mandanten, die eine günstigere Stufe Ihres Diensts erwerben.

Wenn Sie für jeden Mandanten unterschiedliche Risikorichtlinien unterstützen müssen, muss Ihr Authentifizierungssystem den jeweiligen Mandanten kennen, bei dem sich die Benutzer*innen anmelden, um die richtigen Richtlinien anzuwenden.

Wenn Ihr IdP diese Möglichkeit bietet, sollten Sie die nativen Funktionen des IdP für die Anmelderisikobewertung verwenden. Die selbst durchgeführt Implementierung dieser Funktionen kann jedoch komplex und fehleranfällig sein.

Wenn Sie hingegen eine Verbindung zu den jeweiligen Identitätsanbietern der Mandanten herstellen, können deren individuelle Richtlinien zur Risikominderung bei der Anmeldung angewendet werden. Zudem haben sie die Möglichkeit, die Richtlinien und Kontrollen zu steuern, die durchgesetzt werden sollen. Es ist jedoch wichtig, die Benutzer*innen nicht unnötig zu belasten, indem beispielsweise zwei MFA-Anforderungen verlangt werden – eine vom privaten Identitätsanbieter der Benutzer*innen und eine von Ihrem eigenen. Stellen Sie sicher, wie der Verbund mit den Identitätsanbietern ihrer Mandanten und den von ihnen angewendeten Richtlinien interagiert.

Identitätswechsel

Durch die Identitätswechsel können Benutzer*innen die Identität anderer Benutzer*innen annehmen, ohne deren Anmeldeinformationen zu verwenden.

Im Allgemeinen ist der Identitätswechsel riskant, und es kann schwierig sein, ihn umzusetzen und zu kontrollieren. In einigen Szenarien ist der Identitätswechsel jedoch eine Anforderung. Wenn Sie beispielsweise Software-as-a-Service (SaaS) nutzen, muss Ihr Helpdeskteam in bestimmten Fällen die Benutzeridentität annehmen, um sich damit für die Problembehebung anzumelden.

Wenn Sie sich für die Implementierung des Identitätswechsels entscheiden, sollten Sie überlegen, wie Sie die Verwendung überwachen. Stellen Sie sicher, dass Ihre Protokolle sowohl die tatsächlichen Benutzer*innen enthalten, der die Aktionen ausgeführt haben als auch den Bezeichner der Benutzer*innen, die diese imitiert haben.

Einige Identitätsplattformen unterstützen den Identitätswechsel, entweder als integriertes Feature oder mithilfe von benutzerdefiniertem Code. In Azure AD B2C können Sie beispielsweise einen benutzerdefinierten Anspruch für die imitierte Benutzer-ID hinzufügen oder den Antragstellerbezeichneranspruch in den Token ersetzen, die ausgestellt werden.

Autorisierung

Bei der Autorisierung wird festgelegt, was Benutzer*innen ausführen dürfen.

Autorisierungsdaten können an mehreren Stellen wie den folgenden gespeichert werden:

  • In Ihrem Identitätsanbieter. Wenn Sie beispielsweise Microsoft Entra ID als Identitätsanbieter verwenden, können Sie Features wie App-Rollen und Gruppen verwenden, um Autorisierungsinformationen zu speichern. Ihre Anwendung kann dann die zugeordneten Tokenansprüche verwenden, um Ihre Autorisierungsregeln zu erzwingen.
  • in Ihrer Anwendung. Sie können ihre eigene Autorisierungslogik erstellen und dann Informationen darüber speichern, was die einzelnen Benutzer*innen in einer Datenbank oder einem ähnlichen Speichersystem tun kann. Anschließend können Sie detaillierte Steuerelemente für die rollenbasierte oder ressourcenbasierte Autorisierung entwerfen.

In den meisten mehrinstanzenfähigen Lösungen werden Rollen- und Berechtigungszuweisungen vom Mandanten oder Kund*innen verwaltet, nicht von Ihnen als Anbieter*in des mehrinstanzenfähigen Systems.

Weitere Informationen finden Sie unter Anwendungsrollen.

Hinzufügen von Mandantenidentitäts- und Rolleninformationen zu Token

Überlegen Sie, welche Teile Ihrer Lösung Autorisierungsanfragen durchführen und feststellen sollen, ob Benutzer*innen mit Daten eines bestimmten Mandanten arbeiten dürfen.

Ein gängiger Ansatz besteht darin, dass Ihr Identitätssystem einen Mandantenbezeichneranspruch in ein Token einbetten soll. Mit diesem Ansatz kann Ihre Anwendung den Anspruch überprüfen und feststellen, ob Benutzer*innen mit dem Mandanten arbeiten, auf den sie zugreifen dürfen. Wenn Sie das rollenbasierte Sicherheitsmodell verwenden, können Sie das Token mit Informationen zu der Rolle erweitern, die entsprechende Benutzer*innen innerhalb des Mandanten haben.

Wenn einzelne Benutzer*innen jedoch auf mehrere Mandanten zugreifen dürfen, müssen Ihre Benutzer*innen während des Anmeldevorgangs ggf. signalisieren können, mit welchem Mandanten sie arbeiten möchten. Nachdem sie ihren aktiven Mandanten ausgewählt haben, kann der IdP den korrekten Mandantenbezeichneranspruch und die Rolle für diesen Mandanten in das von diesem ausgegebene Token aufnehmen. Sie müssen auch bedenken, wie Benutzer*innen zwischen Mandanten wechseln können, was die Ausgabe eines neuen Tokens erfordert.

Anwendungsbasierte Autorisierung

Ein alternativer Ansatz besteht darin, das Identitätssystem unabhängig von den Bezeichnern und Rollen der Mandanten zu machen. Die Benutzer*innen werden mithilfe ihrer Anmeldeinformationen oder einer Verbundbeziehung identifiziert, und Token enthalten keinen Mandantenbezeichneranspruch. Eine separate Liste oder Datenbank enthält, welchen Benutzer*innen Zugriff auf die einzelnen Mandanten gewährt wird. Anschließend kann die Logikschicht anhand dieser Liste überprüfen, ob die angegebenen Benutzer*innen auf die Daten eines bestimmten Mandanten zugreifen dürfen.

Verwenden von Microsoft Entra ID oder Azure AD B2C?

Microsoft bietet mit Microsoft Entra ID und Azure AD B2C zwei Plattformen für verwaltete Identitäten, die Sie innerhalb Ihrer eigenen mehrinstanzenfähigen Lösung verwenden können.

Viele mehrinstanzenfähigen Lösungen sind SaaS-Anwendungen (Software-as-a-Service). Die Entscheidung, ob Sie Microsoft Entra ID oder Azure AD B2C verwenden, hängt zum Teil davon ab, wie Sie Ihre Mandanten bzw. Ihren Kundenstamm definieren.

Weitere Informationen finden Sie unter Überlegungen zur Nutzung von Azure Active Directory B2C in einer mehrinstanzenfähigen Architektur.

Zu vermeide Antimuster

Aufbauen bzw. Ausführen ihres eigenen Identitätssystems

Der Aufbau einer modernen Identitätsplattform ist kompliziert. Es gibt eine Reihe von Protokollen und Standards, die unterstützt werden müssen. Daher kann es leicht passieren, dass ein Protokoll falsch implementiert wird und eine Sicherheitslücke entsteht. Standards und Protokolle ändern sich, und Sie müssen Ihr Identitätssystem stets aktualisieren, um Angriffe abzuwehren und neue Sicherheitsfunktionen zu unterstützen. Außerdem muss die Resilienz eines Identitätssystems gewährleistet sein, da jeder Ausfall schwerwiegende Folgen für den Rest Ihrer Lösung haben kann. Darüber hinaus bringt die Implementierung eines Identitätsanbieters in den meisten Fällen keinen zusätzlichen Nutzen für das Unternehmen, sondern ist lediglich eine Voraussetzung zur Implementierung eines mehrinstanzenfähigen Diensts. Es empfiehlt sich stattdessen, ein spezielles Identitätssystem zu verwenden, das von Expert*innen entwickelt, betrieben und gesichert wird.

Wenn Sie Ihr eigenes Identitätssystem betreiben, müssen Sie Kennworthashes oder andere Arten von Anmeldedaten speichern, die ein interessantes Angriffsziel darstellen. Selbst das Hashing und Salting von Kennwörtern bietet oft keinen ausreichenden Schutz, da bei einem Angriff die zur Verfügung stehende Rechenleistung ausreicht, um diese Arten von Anmeldeinformationen zu kompromittieren.

Wenn Sie ein Identitätssystem betreiben, sind Sie auch für die Erstellung und Verteilung von MFA- oder OTP-Codes (One-Time Password) zuständig. Aufgrund dieser Anforderungen benötigen Sie einen Mechanismus für die Verteilung dieser Codes, z. B. per SMS oder E-Mail. Darüber hinaus sind Sie für die Erkennung von gezielten und Brute-Force-Angriffen, die Drosselung von Anmeldeversuchen, Überwachungen usw. verantwortlich.

Anstatt ein eigenes Identitätssystem aufzubauen oder zu betreiben, empfiehlt es sich, einen Standarddienst oder eine Standardkomponente zu verwenden. Sie könnten zum Beispiel Microsoft Entra ID oder Azure AD B2C verwenden, bei denen es sich um Plattformen für verwaltete Identitäten handelt. Anbieter von Plattformen für verwaltete Identitäten übernehmen die Verantwortung für den Betrieb der Infrastruktur ihrer Plattformen und unterstützen in der Regel die aktuellen Identitäts- und Authentifizierungsstandards.

Nichtbeachtung der Anforderungen Ihrer Mandanten

Mandanten haben oft eigene Vorstellungen davon, wie die Identität für die von ihnen genutzten Lösungen verwaltet werden sollte. Viele Unternehmenskund*innen setzen beispielsweise einen Verbund mit ihren eigenen Identitätsanbietern voraus, um das einmalige Anmelden zu ermöglichen und die Verwaltung verschiedener Anmeldeinformationen zu vermeiden. Andere Mandanten benötigen möglicherweise eine mehrstufige Authentifizierung oder sonstige Schutzmaßnahmen für die Anmeldeprozesse. Werden diese Anforderungen nicht berücksichtigt, kann es schwierig sein, sie nachträglich zu erfüllen.

Vergewissern Sie sich, dass Sie die Identitätsanforderungen Ihrer Mandanten kennen, bevor Sie den Entwurf für Ihr Identitätssystem fertig stellen. Lesen Sie Überlegungen zur Identitätsarchitektur in einer mehrinstanzenfähigen Lösung, um mehr über spezielle Anforderungen zu erfahren, die häufig auftreten.

Definition von Benutzer*innen und Mandanten

Es ist wichtig, dass Sie sich genau überlegen, wie Ihre Lösung Benutzer*innen und Mandanten definiert. In vielen Situationen kann die Zuordnung schwierig sein. Ein Mandant kann zum Beispiel mehrere Benutzer*innen enthalten, und ein*e einzelne*r Benutzer*in kann mehreren Mandanten beitreten.

Stellen Sie sicher, dass es einen transparenten Prozess für die Nachverfolgung des Mandantenkontextes innerhalb Ihrer Anwendung und Ihrer Anforderungen gibt. In einigen Fällen kann es erforderlich sein, dass Sie einen Mandantenbezeichner in jedes Zugriffstoken aufnehmen und diesen bei jeder Anforderung überprüfen. In anderen Fällen speichern Sie die Mandantenautorisierungsinformationen getrennt von den Benutzeridentitäten und verwenden ein komplexeres Autorisierungssystem, um zu verwalten, welche Benutzer*innen welche Vorgänge für welche Mandanten ausführen dürfen.

Die Verfolgung des Mandantenkontexts von Benutzer*innen oder Token ist auf jedes Mandantenmodell anwendbar, da eine Benutzeridentität immer einen Mandantenkontext innerhalb einer mehrinstanzenfähigen Lösung aufweist. Es empfiehlt sich sogar, den Mandantenkontext nachzuverfolgen, wenn Sie unabhängige Skalierungseinheiten für einen einzelnen Mandanten bereitstellen, der ihre Codebase für andere Formen von Mehrinstanzenfähigkeit zukunftssicher macht.

Definition von Rollen- und Ressourcenautorisierung

Es ist wichtig, dass Sie für Ihre Lösung ein geeignetes Autorisierungsmodell wählen. Rollenbasierte Sicherheitsansätze können einfach zu implementieren sein, aber mittels ressourcenbasierter Autorisierung haben Sie differenziertere Kontrollmöglichkeiten. Beachten Sie die Anforderungen Ihrer Mandanten, und überlegen Sie, ob Ihre Mandanten einigen Benutzer*innen den Zugriff auf bestimmte Teile Ihrer Lösung erlauben sollten, anderen hingegen nicht.

Fehler beim Schreiben von Überwachungsprotokollen

Überwachungsprotokolle sind ein wichtiges Tool, das wertvolle Einblicke in Ihre Umgebung bietet und auch aufzeigt, wie Benutzer*innen Ihr System implementieren. Durch die Überprüfung aller identitätsbezogenen Ereignisse können Sie oft feststellen, ob Ihr Identitätssystem angegriffen wird. Zudem erfahren Sie, wie Ihr System genutzt wird. Stellen Sie sicher, dass Sie Überwachungsprotokolle innerhalb Ihres Identitätssystems schreiben und speichern. Berücksichtigen Sie, ob die Identitätsüberwachungsprotokolle Ihrer Lösung für Mandanten zur Überprüfung verfügbar gemacht werden sollen.

Beitragende

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

Hauptautoren:

Andere Mitwirkende:

Nächste Schritte

Lesen Sie Überlegungen zur Identitätsarchitektur in einer mehrinstanzenfähigen Lösung.