Sicheres Anwendungsmodell-Framework

Microsoft führt ein sicheres, skalierbares Framework für die Authentifizierung von CSP-Partnern (Cloud Solution Provider) und CPV (Control Panel Vendors) über die Microsoft Azure Multifactor Authentication (MFA)-Architektur ein. CSP-Partner und Systemsteuerungsanbieter können sich auf das neue Modell verlassen, um die Sicherheit für Partner Center-API-Integrationsaufrufe zu erhöhen. Dies hilft allen Parteien, einschließlich Microsoft, CSP-Partnern und Systemsteuerungsanbietern, ihre Infrastruktur und Kundendaten vor Sicherheitsrisiken zu schützen.

Geltungsbereich

Dieser Artikel bezieht sich auf die folgenden Partner:

• Control Panel Vendors (CPVs) sind unabhängige Softwareanbieter, die Apps für CSP-Partner entwickeln, um sie mit den Partner Center-APIs zu integrieren. Ein CPV ist kein CSP-Partner mit direktem Zugriff auf das Partnerdashboard oder die APIs. Sie sind die Unternehmen, die Anwendungen entwickeln (in der Regel Web-Apps), mit denen CSPs ihre Produkte über Microsoft Marketplace verkaufen können.
• Indirekte CSP-Anbieter und direkte CSP-Partner, die App-ID und Benutzerauthentifizierung verwenden und direkt in Partner Center-APIs integrieren.

Sichere Anwendungsentwicklung

Bei der Bestellung von Bestellungen für Microsoft-Produkte im Auftrag von CSPs interagieren Marketplace-Anwendungen von CPVs mit Microsoft-APIs, um Bestellungen zu tätigen und Ressourcen für Kunden bereitzustellen.

Einige dieser APIs umfassen:

• Partner Center-APIs, die Commerce-Vorgänge implementieren, z. B. das Aufgeben von Bestellungen und das Verwalten von Abonnementlebenszyklen.
• Microsoft Graph-APIs, die Identitätsverwaltung für CSP-Mandanten und die Mandanten des CSP-Kunden implementieren.
• Azure Resource Manager (ARM)-APIs, die Azure-Bereitstellungsfunktionen implementieren.

CSP-Partner sind mit delegierten Berechtigungen berechtigt, im Namen ihrer Kunden beim Aufrufen von Microsoft-APIs zu handeln. Delegierte Berechtigungen ermöglichen CSP-Partnern das Abschließen von Kauf-, Bereitstellungs- und Supportszenarien für ihre Kunden.

Marketplace-Anwendungen sollen CSP-Partner dabei unterstützen, ihre Lösungen für Kunden auflisten zu können. Um dies zu erreichen, müssen Marketplace-Anwendungen die Identität von CSP-Partnerberechtigungen annehmen, um Microsoft-APIs aufzurufen.

Da CSP-Partnerrechte hoch sind und Zugriff auf alle Kunden des Partners bieten, ist es wichtig zu verstehen, wie diese Anwendungen gestaltet sein müssen, um Sicherheitsausnutzungsvektoren zu widerstehen. Sicherheitsangriffe auf diese vertraulichen Anwendungen können zu einer Kompromittierung von Kundendaten führen. Daher müssen Berechtigungserteilungen und die Impersonierung von Partnerprivilegien so konzipiert sein, dass sie dem Prinzip des geringsten Privilegs entsprechen. Die folgenden Prinzipien und bewährten Methoden stellen sicher, dass Marketplace-Anwendungen nachhaltig sind und Kompromissen standhalten können.

Sicherheitsprinzipien für den Identitätswechsel von Anmeldeinformationen

• Marketplace-Anwendungen dürfen keine Anmeldeinformationen von CSP-Partnern speichern.

• CSP-Partnerbenutzerpasswörter sollten nicht geteilt werden.

• Web-App-Schlüssel von CSP-Partnermandanten dürfen nicht für Control Panel Vendors freigegeben werden.

• Eine Marketplace-Anwendung muss die Anwendungsidentität zusammen mit Partnerinformationen darstellen, anstatt nur Partneranmeldeinformationen zu verwenden, wenn Anrufe imitieren einer CSP-Partneridentität ausgeführt werden.

• Der Zugriff auf eine Marketplace-Anwendung muss auf dem Prinzip der geringsten Rechte basieren und in Berechtigungen klar formuliert werden.

• Die Autorisierung für eine Marketplace-Anwendung muss auf mehrere Anmeldeinformationen pivotiert werden.

• Anwendungsanmeldeinformationen und Partneranmeldeinformationen müssen zusammen bereitgestellt werden, um Zugriff zu erhalten.

  Wichtig

  Es ist wichtig, dass es keinen einzigen Kompromisspunkt gibt.

• Der Zugriff muss auf eine bestimmte Zielgruppe oder API beschränkt sein.

• Beim Zugriff muss der Zweck des Identitätswechsels identifiziert werden.

• Zugriffsberechtigungen für eine Marketplace-Anwendung müssen zeitgebunden sein. CSP-Partner müssen in der Lage sein, den Zugriff auf die Marketplace-Anwendung zu verlängern oder zu widerrufen.

• Schnelle Kontrolle oder Korrekturprozesse müssen eingerichtet sein, um Kompromittierungen von Marketplace-Anwendungsanmeldeinformationen zu behandeln.

• Alle Benutzerkonten sollten die zweistufige Authentifizierung (2FA) verwenden.

• Das Anwendungsmodell sollte zusätzlichen Sicherheitsvorkehrungen wie bedingtem Zugriff auf ein verbessertes Sicherheitsmodell entgegenkommen.

Anwendungsidentität und -konzepte

Mehrinstanzenfähige Anwendungen

Eine mehrinstanzenfähige Anwendung ist in der Regel eine SaaS-Anwendung (Software as a Service). Sie können Ihre Anwendung so konfigurieren, dass Anmeldungen von allen Microsoft Entra-Mandanten akzeptiert werden, indem Sie den Anwendungstyp im Azure-Dashboard als mehrinstanzenfähig konfigurieren. Benutzende in jedem Microsoft Entra-Mandanten können sich nach der Zustimmung zur Verwendung ihres Kontos mit Ihrer Anwendung bei Ihrer Anwendung anmelden.

Weitere Informationen zum Erstellen einer mehrinstanzenfähigen Anwendung finden Sie unter Anmelden beliebiger Microsoft Entra-Benutzender mithilfe des mehrinstanzenfähigen Anwendungsmusters.

Zustimmungsrahmen

Damit sich ein Benutzer bei einer Anwendung in Microsoft Entra ID anmelden kann, muss die Anwendung im Mandanten des Benutzers repräsentiert sein. Dadurch kann die Organisation beispielsweise einzigartige Richtlinien anwenden, wenn sich Benutzer aus ihrem Mandanten bei der Anwendung anmelden. Bei einer einzelnen Mandantenanwendung ist diese Registrierung einfach: Sie ist die, die beim Registrieren der Anwendung im Azure-Dashboard geschieht.

Bei einer mehrinstanzenfähigen Anwendung erfolgt die anfängliche Registrierung für die Anwendung im Microsoft Entra-Mandanten, der von der entwickelnden Person verwendet wird. Wenn sich ein Benutzer von einem anderen Mandanten zum ersten Mal bei der Anwendung anmeldet, fordert Microsoft Entra ID ihn auf, den Berechtigungen zuzustimmen, die von der Anwendung angefordert werden. Wenn die Person zustimmt, wird eine Darstellung der Anwendung, die als Dienstprinzipal bezeichnet wird, im Mandanten der benutzenden Person erstellt, und der Anmeldeprozess kann fortgesetzt werden. Eine Delegierung wird auch im Verzeichnis erstellt, in dem die Zustimmung der benutzenden Person für die Anwendung erfasst wird.

Die Zustimmungserfahrung ist von den berechtigungen betroffen, die von der Anwendung angefordert werden. Die Microsoft Entra-ID unterstützt zwei Arten von Berechtigungen: app-only und delegiert.

• Die Nur-App-Berechtigung wird der Identität der Anwendung direkt gewährt. Sie können beispielsweise einer Anwendung die Berechtigung zum Lesen der Liste der Benutzer in einem Mandanten erteilen, unabhängig davon, wer bei der Anwendung angemeldet ist.
• Delegierte Berechtigung gewährt einer Anwendung die Möglichkeit, als angemeldeter Benutzer für eine Teilmenge der Aktionen zu handeln, die der Benutzer ausführen kann. Sie können beispielsweise einer Anwendung die delegierte Berechtigung zum Lesen des Kalenders des angemeldeten Benutzers erteilen.

Einige Berechtigungen können von einem normalen Benutzer genehmigt werden, während andere die Zustimmung eines Mandantenadministrators erfordern. Weitere Informationen zum Consent Framework von Microsoft Entra Benutzeroberfläche für die Zustimmung für Anwendungen in Microsoft Entra ID.

• Übersicht über Berechtigungen und Zustimmungen in der Microsoft-Identitätsplattform
• Verständnis von Benutzer- und Administratorzustimmung

Open Authorization-Tokenflow (OAuth) für mehrinstanzenfähige Anwendungen

In einem Open Authorization-Flow (OAuth) für eine mehrinstanzenfähige Anwendung wird die Anwendung im Mandanten des CPV- oder CSP-Partners als mehrinstanzenfähige Anwendung dargestellt.

Um auf Microsoft-APIs (Partner Center-APIs, Graph-APIs usw.) zuzugreifen, müssen sich CSP-Partner bei der Anwendung anmelden und zustimmen, dass die Anwendung APIs in ihrem Auftrag aufrufen kann.

Die Anwendung erhält durch Zustimmung und OAuth-Berechtigungen Zugriff auf die Ressourcen des Partners, wie z. B. Graph- und Partner Center-APIs.

Erstellen einer Mehrinstanzenanwendung

Eine mehrinstanzenfähige Anwendung muss die folgenden Anforderungen erfüllen:

• Es muss sich um eine Web-App mit einer Anwendungs-ID und einem geheimen Schlüssel handeln.
• Er muss den impliziten Authentifizierungsmodus deaktiviert haben.

Darüber hinaus empfehlen wir die Einhaltung dieser bewährten Methoden:

• Verwenden Sie ein Zertifikat für den geheimen Schlüssel.
• Aktivieren Sie bedingten Zugriff, um EINSCHRÄNKUNGEN für DEN IP-Bereich anzuwenden. Möglicherweise muss dafür mehr Funktionalität auf dem Microsoft Entra-Mandanten aktiviert werden.
• Richtlinien zur Lebensdauer von Zugriffstoken auf die Anwendung anwenden.

Beim Abrufen eines Tokens müssen die App-ID und der geheime Schlüssel vorgelegt werden. Der geheime Schlüssel kann ein Zertifikat sein.

Die Anwendung kann so konfiguriert werden, dass mehrere APIs einschließlich Azure Resource Manager-APIs aufgerufen werden. Im Folgenden sind die mindesten Berechtigungen aufgeführt, die für Partner Center-APIs erforderlich sind:

• Delegierte Berechtigungen für Microsoft Entra-ID: Zugriff auf das Verzeichnis als angemeldete benutzende Person
• Delegierte Berechtigungen für Partner Center-APIs: Zugriff

Die Anwendung erfasst die Partnereinstimmung

Eine mehrinstanzenfähige Anwendung muss die Einwilligung von Partnern einholen und die Zustimmung und Zuweisung verwenden, um weitere Aufrufe an Partner Center-APIs zu durchzuführen. Die Zustimmung wird über einen OAuth-Authentifizierungscodefluss erworben.

Um die Einwilligung zu erhalten, müssen CPVs oder CSP-Partner eine Onboardingwebsite erstellen, welche die Zuweisung eines Authentifizierungscodes von Microsoft Entra ID akzeptieren kann.

Weitere Informationen finden Sie unter Microsoft Identity Platform und OAuth 2.0-Autorisierungscodeflow.

Hier sind die Schritte für eine mehrinstanzenfähige Anwendung zum Erfassen der CSP-Partnereinwilligung zusammen mit einem wiederverwendbaren Token zum Tätigen von Aufrufen an Partner Center-APIs.

Führen Sie die folgenden Schritte aus, um die Partnerzustimmung zu erhalten.

1. Erstellen Sie eine Onboarding-Webanwendung für Partner, die einen Einwilligungslink für den Partner hosten kann, um die Einwilligung für die mehrinstanzenfähige Anwendung zu akzeptieren.
2. Der CSP-Partner klickt auf den Zustimmungslink. Beispiel: https://login.microsoftonline.com/common/oauth2/authorize?&client_id=<marketplaceappid>&response_ty
3. Auf der Microsoft Entra-Anmeldeseite werden die Berechtigungen erläutert, die der Anwendung im Namen des Benutzers erteilt werden. Der CSP-Partner kann Anmeldeinformationen für Administrations- oder Vertriebsbeauftragte nutzen, um sich anzumelden und die Einwilligung zu genehmigen. Die Anwendung erhält Berechtigungen basierend auf der Benutzerrolle, die für die Anmeldung verwendet wird.
4. Sobald die Einwilligung erteilt wurde, erstellt Microsoft Entra-ID einen Dienstprinzipal der mehrinstanzenfähigen Anwendung des CPV im Mandanten des CSP-Partners.
   • Der Anwendung werden OAuth-Berechtigungen erteilt, um im Namen des Benutzers zu handeln. Diese Zuschüsse ermöglichen es der Mehrinstanzenanwendung, Partner Center-APIs im Auftrag des Partners aufzurufen.
   • An diesem Punkt leitet die Microsoft Entra-Anmeldeseite zur Partner-Onboarding-Webanwendung um. Die Webanwendung empfängt einen Autorisierungscode von der Microsoft Entra-ID. Die Partner-Onboarding-Webanwendung muss den Autorisierungscode zusammen mit der Anwendungs-ID und dem geheimen Schlüssel verwenden, um die Microsoft Entra-ID Token-API aufzurufen und ein Aktualisierungs-Token zu erhalten.
5. Speichern Sie das Aktualisierungstoken sicher. Das Aktualisierungstoken ist Teil der Partneranmeldeinformationen, die zum Erlangen des Zugriffs auf Partner Center-APIs im Auftrag des Partners verwendet werden. Nachdem das Aktualisierungstoken erworben wurde, verschlüsseln Sie es, und speichern Sie es in einem geheimen Schlüsselspeicher, z. B. dem Azure Key Vault.

Flow des Tokenanforderungsaufrufs

Eine CPVs- oder CSP-Partneranwendung muss ein Zugriffstoken erwerben, bevor Aufrufe an Partner Center-APIs ausgeführt werden. Diese APIs werden in der Ressourcen-URL https://api.partnercenter.microsoft.comdargestellt.

Eine CPV-Anwendung muss erkennen, welches Partnerkonto sie für den Aufruf von Partner Center-APIs auf der Grundlage von Produkt- oder Verbundanmeldung imitieren muss. Die Anwendung ruft das verschlüsselte Aktualisierungstoken für diesen Partnermandanten aus dem geheimen Schlüsselspeicher ab. Das Aktualisierungstoken muss vor der Verwendung entschlüsselt werden.

Für CSP-Partner, bei denen nur ein Mandant vorhanden ist, der seine Zustimmung erteilt, bezieht sich das Partnerkonto auf den Mandanten des CSP-Partners.

Das Refresh-Token ist ein Token für mehrere Zielgruppen. Das bedeutet, dass das Refresh-Token verwendet werden kann, um basierend auf der erteilten Zustimmung ein Token für mehrere Zielgruppen zu erhalten. Wenn z. B. die Partnereinwilligung für Partner Center-APIs und Microsoft Graph-APIs erteilt wird, kann das Aktualisierungstoken verwendet werden, um ein Zugriffstoken für beide APIs anzufordern. Das Zugriffstoken verfügt über die Gewährung "im Auftrag von" und ermöglicht es einer Marketplace-Anwendung, den Identitätswechsel des Partners zu übernehmen, der beim Aufrufen dieser APIs zugestimmt hat.

Ein Zugriffstoken kann für eine einzelne Zielgruppe gleichzeitig erworben werden. Wenn eine Anwendung auf mehrere APIs zugreifen muss, muss sie mehrere Zugriffstoken für die Zielgruppe anfordern. Um ein Zugriffstoken anzufordern, muss die Anwendung die Microsoft Entra-ID Token-APIaufrufen. Alternativ könnte auch AuthenticationContext.AcquireTokenAsync des Microsoft Entra SDK verwendet und folgende Informationen übergeben werden:

• Ressourcen-URL, bei der es sich um die Endpunkt-URL für die Anwendung handelt, die aufgerufen werden soll. Die Ressourcen-URL für die Microsoft Partner Center-API ist z. B. https://api.partnercenter.microsoft.com.
• Anwendungsanmeldeinformationen, die aus der Anwendungs-ID und dem geheimen Schlüssel der Web-App bestehen.
• Das Aktualisierungstoken

Das resultierende Zugriffstoken ermöglicht es der Anwendung, Aufrufe an APIs zu tätigen, die in der Ressource erwähnt werden. Die Anwendung kann kein Zugriffstoken für APIs anfordern, für die im Rahmen der Einwilligungsanforderung keine Berechtigung erteilt wurde. Der UserPrincipalName (UPN)-Attributwert ist der Microsoft Entra-Benutzername für die Benutzerkonten.

Weitere Überlegungen

Bedingter Zugriff

Wenn es um die Verwaltung Ihrer Cloudressourcen geht, ist ein wichtiger Aspekt der Cloudsicherheit Identität und Zugriff. In einer mobilen, cloudbasierten Welt können Benutzer über verschiedene Geräte und Apps von praktisch überall aus auf die Ressourcen Ihrer Organisation zugreifen. Einfach nur darauf zu konzentrieren, wer auf eine Ressource zugreifen kann, reicht nicht mehr aus. Um das Gleichgewicht zwischen Sicherheit und Produktivität zu meistern, müssen Sie auch überlegen, wie auf eine Ressource zugegriffen wird. Mithilfe des bedingten Zugriffs von Microsoft Entra können Sie diese Anforderung beheben. Mit bedingtem Zugriff können Sie automatisierte Zugriffssteuerungsentscheidungen für den Zugriff auf Ihre Cloud-Apps implementieren, die auf Bedingungen basieren.

Weitere Informationen finden Sie unter Was ist der bedingte Zugriff in Microsoft Entra ID?

IP-Bereichsbasierte Einschränkungen

Sie können Tokens einschränken, dass sie nur an bestimmte IP-Adressen ausgegeben werden können. Dieses Feature hilft, den Angriffsbereich nur auf ein bestimmtes Netzwerk einzuschränken.

Mehrstufige Authentifizierung

Durch das Erzwingen der Multi-Faktor-Authentifizierung können Sie die Kompromittierung von Anmeldeinformationen einschränken, indem sie die Überprüfung von Anmeldeinformationen mit zwei oder mehr Formularen erzwingen. Mit diesem Feature kann Microsoft Entra-ID die Identität des Anrufers über sichere sekundäre Kanäle, z. B. mobile oder E-Mails, vor dem Ausstellen von Token überprüfen.

Weitere Informationen finden Sie unter Funktionsweise von Azure Multi.

Verwandte Inhalte

• So konfigurieren Sie eine neue mehrinstanzenfähige Anwendung
• Autorisieren des Zugriffs auf Microsoft Entra-Webanwendungen mithilfe des OAuth 2.0-Codezuweisungsflows
• Funktionsweise der Anwendungsgenehmigung
• Partner Center REST-API-Referenz