Freigeben über

Framework „Sicheres Anwendungsmodell“

  • Artikel

Microsoft führt ein sicheres, skalierbares Framework für die Authentifizierung von CSP-Partnern (Cloud Solution Provider) und Systemsteuerung Vendors (CPV) über die Mehrstufige Authentifizierungsarchitektur von Microsoft Azure ein. CSP-Partner und Systemsteuerung Anbieter 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 Systemsteuerung Lieferanten, ihre Infrastruktur und Kundendaten vor Sicherheitsrisiken zu schützen.

Wichtig

Azure Active Directory (Azure AD) Graph ist ab dem 30. Juni 2023 veraltet. In Zukunft investieren wir nicht mehr in Azure AD Graph. Azure AD Graph-APIs haben keine SLA- oder Wartungsverpflichtungen, die über sicherheitsbezogene Fixes hinausgehen. Investitionen in neue Features und Funktionalitäten werden nur für Microsoft Graph vorgenommen.

Azure AD Graph wird inkrementellen Schritten eingestellt, sodass Sie genügend Zeit haben, um Ihre Anwendungen zu Microsoft Graph-APIs zu migrieren. Zu einem späteren Zeitpunkt, an dem wir ihnen mitteilen werden, werden wir die Erstellung neuer Anwendungen mit Azure AD Graph blockieren.

Weitere Informationen finden Sie unter "Wichtig": Veraltetes Azure AD Graph- und Powershell-Modul.To learn more, see Important: Azure AD Graph Retirement and Powershell Module Deprecation.

Bereich

Dieser Artikel bezieht sich auf die folgenden Partner:

  • Systemsteuerung Anbieter (CPVs) sind unabhängige Softwareanbieter, die Apps für die Verwendung von CSP-Partnern entwickeln, um sie in 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 einen einheitlichen Marketplace verkaufen können.
  • Indirekte CSP-Anbieter und direkte CSP-Partner, die App-ID- und Benutzerauthentifizierung verwenden und direkt in Partner Center-APIs integriert sind.

Hinweis

Um sich als CPV zu qualifizieren, müssen Sie das Partner Center zuerst als CPV integrieren. Wenn Sie ein bestehender CSP-Partner sind, der auch ein CPV ist, gilt diese Voraussetzung auch für Sie.

Sichere Anwendungsentwicklung

Bei der Bestellung von Aufträgen 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 Platzieren von Aufträgen und das Verwalten von Abonnementlebenszyklus.
  • Microsoft Graph-APIs, die 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 so konzipiert werden müssen, dass sie sicherheitsrelevanten Vektoren standhalten müssen. Sicherheitsangriffe auf diese sensiblen Anwendungen können dazu führen, dass Kundendaten kompromittiert werden. Daher müssen Berechtigungserteilungen und Identitätswechsel von Partnern so konzipiert sein, dass sie dem Prinzip der geringsten Rechte 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-Partnerbenutzerwörter sollten nicht freigegeben werden.

  • CSP-Partnermandanten-Web-App-Schlüssel dürfen nicht für Systemsteuerung Anbieter 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.

  • Access muss den Zweck des Identitätswechsels identifizieren.

  • 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 für zusätzliche Sicherheitsbestimmungen wie bedingten Zugriff auf ein besseres Sicherheitsmodell freundlich sein.

Hinweis

CSP-indirekte Anbieter und direkte CSP-Partner, die App-ID + Benutzerauthentifizierung verwenden und direkt in Partner Center-APIs integriert werden, müssen die oben genannten Prinzipien befolgen, um ihre eigenen Marketplace-Anwendungen zu schützen.

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 Mehrinstanz konfigurieren. Benutzer eines Microsoft Entra-Mandanten können sich bei Ihrer Anwendung anmelden, nachdem sie zugestimmt haben, ihr Konto mit Ihrer Anwendung zu verwenden.

Weitere Informationen zum Erstellen einer Mehrinstanzenanwendung finden Sie unter Anmelden eines beliebigen Microsoft Entra-Benutzers mithilfe des mehrinstanzenübergreifenden Anwendungsmusters.

Damit sich ein Benutzer bei einer Anwendung in der Microsoft Entra-ID anmeldet, muss die Anwendung im Mandanten des Benutzers dargestellt werden, sodass die Organisation Aufgaben wie das Anwenden eindeutiger Richtlinien ausführen kann, wenn Benutzer von ihrer Mandantenanmeldung an die Anwendung teilnehmen. 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 befindet sich die anfängliche Registrierung für die Anwendung im Microsoft Entra-Mandanten, der vom Entwickler verwendet wird. Wenn sich ein Benutzer von einem anderen Mandanten zum ersten Mal bei der Anwendung anmeldet, fordert Microsoft Entra ID ihn auf, den von der Anwendung angeforderten Berechtigungen zuzustimmen. Wenn sie zustimmen, wird eine Darstellung der Anwendung, die als Dienstprinzipal bezeichnet wird, im Mandanten des Benutzers erstellt, und der Anmeldevorgang kann fortgesetzt werden. Eine Delegierung wird auch im Verzeichnis erstellt, in dem die Zustimmung des Benutzers für die Anwendung aufgezeichnet wird.

Hinweis

Indirekte CSP-Anbieter und CSP-direkte Partner, die App-ID + Benutzerauthentifizierung verwenden und direkt in Partner Center-APIs integriert werden, müssen ihrer Marketplace-Anwendung mit demselben Zustimmungsframework zustimmen.

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

  • Die Nur-App-Berechtigung wird direkt der Identität der Anwendung erteilt. 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 werden von einem regulären Benutzer zugestimmt, während andere die Zustimmung eines Mandantenadministrators erfordern. Weitere Informationen zum Microsoft Entra-Zustimmungsframework finden Sie unter Grundlegendes zur Zustimmung der Microsoft Entra-Anwendung.

Multitenant Application Open Authorization (OAuth)-Tokenfluss

In einem OAuth-Fluss (Multitenant Application Open Authorization) wird die Anwendung als mehrinstanzenfähige Anwendung im Mandanten des CPV- oder CSP-Partners dargestellt.

Für den Zugriff auf Microsoft-APIs (Partner Center-APIs, Graph-APIs usw.) müssen sich CSP-Partner bei der Anwendung anmelden und zustimmen, dass die Anwendung APIs in ihrem Auftrag aufruft.

Hinweis

Indirekte CSP-Anbieter und CSP-direkte Partner, die App-ID und Benutzerauthentifizierung verwenden und direkt in Partner Center-APIs integriert werden, müssen ihrer Marketplace-Anwendung zustimmen, um dasselbe Zustimmungsframework zu verwenden.

Die Anwendung erhält Zugriff auf die Ressourcen des Partners, z. B. Graph- und Partner Center-APIs, über Zustimmungs- und OAuth-Gewährungen.

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. Dies erfordert möglicherweise mehr Funktionen, die für den Microsoft Entra-Mandanten aktiviert werden müssen.
  • Anwenden von Zugriffstokenlebensdauerrichtlinien für die Anwendung.

Beim Abrufen eines Tokens muss die App-ID und der geheime Schlüssel angezeigt 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 der Microsoft Entra-ID: Zugreifen auf das Verzeichnis als angemeldeter Benutzer
  • Delegierte Berechtigungen für Partner Center-APIs: Access

Eine mehrinstanzenfähige Anwendung muss die Zustimmung von Partnern erwerben und die Zustimmung verwenden und weitere Aufrufe an Partner Center-APIs erteilen. Die Zustimmung wird über einen OAuth-Authentifizierungscodefluss erworben.

Um die Zustimmung zu erhalten, müssen CPVs oder CSP-Partner eine Onboarding-Website erstellen, die eine Authentifizierungscodegenehmigung von Microsoft Entra ID akzeptieren kann.

Weitere Informationen finden Sie unter Autorisieren des Zugriffs auf Azure Active- und Directory-Webanwendungen mithilfe des OAuth 2.0-Codeerteilungsflusses.

Hier sind die Schritte für eine mehrinstanzenfähige Anwendung zum Erfassen der CSP-Partnerzustimmung 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 Partner-Onboarding-Webanwendung, die einen Zustimmungslink für den Partner hosten kann, um die Zustimmung 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 entweder Administrator-Agent- oder Vertriebsmitarbeiter-Anmeldeinformationen verwenden, um sich anzumelden und die Zustimmung zu genehmigen. Die Anwendung erhält Berechtigungen basierend auf der Benutzerrolle, die für die Anmeldung verwendet wird.
  4. Sobald die Zustimmung erteilt wurde, erstellt Die Microsoft Entra-ID einen Dienstprinzipal der mehrinstanzenfähigen Anwendung des CPV im Mandanten des CSP-Partners. Der Anwendung wird OAuth gewährt, 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 Tokens-API aufzurufen, um ein Aktualisierungstoken abzurufen.
  5. Speichern Sie das Aktualisierungstoken sicher. Das Aktualisierungstoken ist Teil der Partneranmeldeinformationen, die zum Abrufen 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. im Azure-Schlüsseltresor.

Ablauf des Tokenanforderungsaufrufs

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

Eine CPV-Anwendung sollte ermitteln, welches Partnerkonto er für den Aufruf von Partner Center-APIs auf der Grundlage der Produkt- oder Verbundanmeldung annehmen 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 Aktualisierungstoken ist ein Mehrgruppentoken. Das bedeutet, dass das Aktualisierungstoken verwendet werden kann, um ein Token für mehrere Zielgruppen basierend auf der erteilten Zustimmung abzurufen. Wenn z. B. die Partnerzustimmung 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-API aufrufen. Alternativ können sie auch die AuthenticationContext.AcquireTokenAsync des Microsoft Entra SDK verwenden und folgende Informationen übergeben:

  • 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 lautet https://api.partnercenter.microsoft.comz. B. .
  • 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, die im Rahmen der Zustimmungsanforderung keine Berechtigung erteilt haben. 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 dem bedingten Zugriff können Sie basierend auf bestimmten Bedingungen automatisierte Entscheidungen hinsichtlich der Zugriffssteuerung für den Zugriff auf Ihre Cloud-Apps implementieren.

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

IP-Bereichsbasierte Einschränkungen

Sie können token so einschränken, dass sie nur für bestimmte IP-Adressen festgelegt werden. Dieses Feature hilft, den Angriffsbereich nur auf ein bestimmtes Netzwerk einzuschränken.

Mehrstufige Authentifizierung

Durch das Erzwingen der mehrstufigen Authentifizierung können Sie Die Kompromittierung von Anmeldeinformationen einschränken, indem sie die Überprüfung von Anmeldeinformationen auf zwei oder mehr Formulare 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 How it works: Azure Multi.

Zugehöriger Inhalt