Anwendung, die mehrinstanzenfähige Authentifizierung zulässt

Anwendungen, die in Microsoft Entra ID registriert wurden, um die Anmeldung zu vereinfachen, können entweder eine einzelinstanzenfähige oder eine mehrinstanzenfähige Authentifizierung beantragen, auch bekannt als „Zielgruppe für die Anmeldung“. Die einzelinstanzenfähige Authentifizierung beschränkt den Zugriff auf Benutzer innerhalb desselben Mandanten, während die mehrinstanzenfähige Authentifizierung Benutzern eines beliebigen Entra-Mandanten den Zugriff erlaubt. Diese Unterscheidung zwischen einzel- und mehrinstanzenfähigen Apps kann Auswirkungen auf die Sicherheit haben. Wenn eine Anwendung nicht in vollem Bewusstsein der Auswirkungen und ohne erforderliche Vorkehrungen als mehrinstanzenfähig konfiguriert wird, kann dies zu Sicherheitsrisiken führen.

Die Gefährdung mehrinstanzenfähiger Apps ist höher, da ein böswilliger Entra-Benutzer eines beliebigen Mandanten die Anwendung erkennen und auf sie zugreifen kann. Wenn der Code der Anwendung diese Konfiguration nicht berücksichtigt, (z. B. wenn der Quellmandant des Benutzers nicht mit einer Liste von autorisierten Mandanten verglichen wird), kann dies zu nicht autorisiertem Zugriff führen. Anfällige Apps sind solche, die davon ausgehen, dass die Authentifizierung legitim ist und den Zugriff ausschließlich basierend auf der Vorlage eines gültigen Tokens gewähren, ohne weitere Prüfungen durchzuführen. Diese Art von Schwachstelle fällt in den Bereich von Sicherheitsmängeln des Typs „Authentifizierung (AuthN) vs. Autorisierung (AuthZ)“. Gemäß dem „Modell der geteilten Verantwortung“ übernimmt Entra ID die Benutzerauthentifizierung, während die Autorisierung in die Verantwortung der App fällt.

Selbst Microsoft wurde im März 2023 Opfer dieser Verwirrung, wie in der Fallstudie „BingBang“ ausführlich beschrieben. Sicherheitsforschern gelang es, diese Fehlkonfiguration auszunutzen, um mehrere Microsoft-Anwendungen zu kompromittieren, einschließlich des Verwaltungsportals für die Suchmaschine Bing. Microsoft hat diese Schwachstelle in seiner Anwendung behoben, wir möchten Sie mit dieser Erwähnung jedoch daran erinnern, dass ähnliche Schwachstellen Ihre eigenen Anwendungen betreffen können und Sie sie überprüfen und Fehlkonfigurationen bei Bedarf beheben sollten.

Mehrinstanzenfähige Apps sind auch anfällig für andere Verwirrungen in Bezug auf die Authentifizierung, wie den nOAuth-Fehler.

Es gibt legitime Anwendungsfälle für mehrinstanzenfähige Apps, insbesondere wenn Ihre Organisation Anwendungen hostet, über die andere Organisationen (z. B. Softwareanbieter oder für die Zusammenarbeit zwischen Organisationen) oder auch Benutzer eines anderen Mandanten, aber innerhalb derselben Organisation (z. B. wenn es einen Mandanten pro Tochtergesellschaft gibt) Zugriff erhalten sollen. Diese Anwendungen sind nur anfällig, wenn sie sich ausschließlich auf eine erfolgreiche Authentifizierung verlassen, ohne zusätzliche Autorisierungsprüfungen durchzuführen. Dieser Indicator of Exposure kann nicht ermitteln, ob eine Anwendung tatsächlich öffentlich sein soll oder ob die mehrinstanzenfähige Authentifizierung absichtlich aktiviert wurde. Außerdem kann er nicht feststellen, ob die Mehrinstanzenfähigkeit wirklich erforderlich ist, und ohne Zugriff auf den Anwendungscode kann er nicht überprüfen, ob die erforderlichen Autorisierungsprüfungen durchgeführt werden. Aus diesen Gründen kennzeichnet der IoE alle mehrinstanzenfähigen Anwendungen als Feststellungen, die Sie einzeln überprüfen müssen. Nach der Bestätigung können Sie sie als ignoriert markieren.

Überprüfen Sie die Anwendung mit Unterstützung des Besitzers, um sicherzustellen, dass der mehrinstanzenfähige Charakter der App so gewollt ist. Stellen Sie sicher, dass diese Konfiguration im vollen Bewusstsein der Unterschiede zwischen einzel- und mehrinstanzenfähigen Apps aktiviert wurde. Bestätigen Sie, dass die Anwendung Benutzer aus anderen Mandanten als dem, in dem sie registriert ist, annehmen kann.

Wenn die Anwendung tatsächlich öffentlich sein soll, können Sie sie natürlich auch angeben, damit der Indicator of Exposure sie ignorieren kann.

Wenn die Anwendung keine mehrinstanzenfähige Authentifizierung erfordert, können Sie sie wieder in den einzelinstanzenfähigen Modus versetzen. Beachten Sie jedoch, dass Entra ID unterschiedliche Validierungsregeln für Apps auf Grundlage der unterstützten Kontotypen durchsetzt. Daher ist es eventuell nicht immer möglich, in den einzelinstanzenfähigen Modus zu wechseln, ohne andere Parameter anzupassen. Gehen Sie mit Vorsicht vor und überprüfen Sie die Auswirkungen von Änderungen sorgfältig. Sie können die Anweisungen von Microsoft zum Ändern der Zielgruppe befolgen oder das folgende Verfahren anwenden:

1. Authentifizieren Sie sich mit einem Entra-Benutzer, der Besitzer der Anwendung ist oder dem eine Entra-Rolle wie „Anwendungsadministrator“ oder „Cloud-Anwendungsadministrator“ zugewiesen wurde, beim Azure-Portal/Entra Admin Center. (Die exakte erforderliche Entra-Berechtigung ist microsoft.directory/applications/audience/update.)
2. Öffnen Sie das Menü „App-Registrierungen“.
3. Suchen Sie nach der Anwendung (verwenden Sie den in der Feststellung angezeigten Namen oder die Objekt-ID).
4. Auf der Seite „Übersicht“ sollte im Abschnitt „Unterstützte Kontotypen“ derzeit „Mehrere Organisationen“ oder „Alle Microsoft-Kontobenutzer“ angezeigt werden.
5. Klicken Sie auf das Menü „Authentifizierung“ und befolgen Sie die Anweisungen, um die Anwendung auf „Einzelinstanzenfähig“ umzustellen.

Wenn die Anwendung hingegen eine mehrinstanzenfähige Authentifizierung erfordert, vergewissern Sie sich bei ihrem Entwickler, dass der Code zusätzliche Autorisierungsprüfungen für das empfangene Authentifizierungstoken enthält, die als Überprüfung von Ansprüchen bezeichnet werden.

• Gegebenenfalls sollte die Anwendung nur Token von Benutzern aus einer vordefinierten Liste von identifizierten Entra-Mandanten akzeptieren, wie z. B. die Mandanten der Tochtergesellschaften der Organisation, basierend auf dem Mandanten-ID-Anspruch.
• Gegebenenfalls kann die Anwendung auch erwägen, Token von bestimmten im Voraus bekannten Benutzern zu akzeptieren, basierend auf deren Objekt-ID-Anspruch.
• Die Anwendung kann das Modell der rollenbasierten Zugriffssteuerung (RBAC) implementieren, wofür verschiedene Methoden verwendet werden können, z. B. Entra-App-Rollen, Entra-Gruppen oder der eigene Datenspeicher.

Wenn Sie feststellen, dass diese Prüfungen vorhanden sind, oder wenn die Anwendung tatsächlich öffentlich sein soll, können Sie angeben, dass die Anwendung von diesem Indicator of Exposure ignoriert werden soll.

Hinweis: Richtlinien für bedingten Zugriff gelten nur für Benutzer im selben Mandanten. Folglich können sie den Zugriff von Benutzern aus anderen Mandanten auf Ihre mehrinstanzenfähigen Anwendungen nicht einschränken.

Darüber hinaus empfehlen wir, den offiziellen Microsoft-Leitfaden zur potenziellen Fehlkonfiguration der Autorisierung für mehrinstanzenfähige Anwendungen mit Entra ID zu befolgen, der zusätzliche spezifische Empfehlungen enthält.

Schließlich sollten Entra- und Azure-Administratoren sensibilisiert werden, um sicherzustellen, dass sie mit Bedacht zwischen einer einzel- und einer mehrinstanzenfähigen Konfiguration wählen, wenn sie Anwendungen über die Entra-Seite zur App-Registrierung oder über einen Azure-App-Dienst erstellen.

Name: Anwendung, die mehrinstanzenfähige Authentifizierung zulässt

Codename: APPLICATION-ALLOWING-MULTI-TENANT-AUTHENTICATION

Schweregrad: Low

Typ: Microsoft Entra ID Indicator of Exposure