Beispiel für eine API, die vom Zustimmungsframework für Microsoft Identity geschützt ist

Dieser Artikel kann Ihnen als Entwickler dabei helfen, Ihre App-Berechtigungsstrategie so zu entwerfen, dass sie die geringsten Berechtigungen bereitstellt. Bevor Sie fortfahren, lesen Sie den Artikel zum API-Schutz, um bewährte Methoden für Registrierung, Berechtigungen und Zugriff kennenzulernen.

Sehen wir uns an, wie eine API, die durch die Microsoft Identity Platform geschützt ist, das Zustimmungsframework für Microsoft Identity verwendet. Wir verwenden die Microsoft Graph-API als Beispiel, da sie das Microsoft Identity Platform-Einwilligungsframework am umfassendsten nutzt.

Benennungskonvention für Berechtigungsnamen

Das Microsoft Graph-Team hat eine Benennungskonvention für Berechtigungsnamen erstellt, um die Verbindung der Berechtigung mit dem Ressourcenzugriff zu erleichtern, den die Berechtigung ermöglicht. Microsoft Graph-Berechtigungsnamen entsprechen einem einfachen resource.operation.constraint-Muster. Die beiden primären Vorgänge sind Read und ReadWrite (einschließlich Aktualisieren und Löschen).

Das Einschränkungselement wirkt sich auf den Zugriffsgrad aus, den Ihre App im Verzeichnis hat. Microsoft Graph unterstützt diese Einschränkungen:

• All erteilt der App die Berechtigung, die Vorgänge für alle Ressourcen des angegebenen Typs in einem Verzeichnis auszuführen.
• Freigegeben erteilt Ihrer App die Berechtigung, die Vorgänge für Ressourcen auszuführen, die andere Benutzer für den angemeldeten Benutzer freigegeben haben.
• AppFolder gewährt Ihrer App die Berechtigung zum Lesen und Schreiben von Dateien in einem dedizierten Ordner in OneDrive. Diese Einschränkung wird nur für das Datei-Berechtigungsobjekt verfügbar gemacht und gilt nur für Microsoft-Konten.
• Wenn Sie keine Einschränkung angeben, kann Ihre App nur die Vorgänge für die Ressourcen ausführen, die der angemeldete Benutzer besitzt.

Zugriff und Vorgänge für bestimmte Ressourcen

Sehen wir uns einige Berechtigungen oder Bereiche für das Benutzerobjekt in Microsoft Graph an, um zu sehen, wie die Microsoft API-Designer spezifischen Zugriff und Vorgänge für bestimmte Ressourcen aktiviert haben:

User.Read und User.ReadWrite vorhanden (im Gegensatz zu einer einzigen Berechtigung wie User.Access, die nicht vorhanden ist), damit Anwendungen dem Zero Trust-Prinzip der geringsten Berechtigung folgen können. Wenn der Entwickler keine Anforderung und keinen Code zum Aktualisieren des Benutzerprofils festlegt, fordert die App User.ReadWrite nicht an. Daher kann ein Angreifer die Anwendung nicht kompromittieren und zum Ändern von Daten verwenden.

Beachten Sie, dass User.Read der Anwendung nicht nur Zugriff auf das Benutzerobjekt gibt. Jede Berechtigung stellt einen bestimmten Vorgangsbereich dar. Es ist wichtig, dass Entwickler und Administratoren die Berechtigungsbeschreibung lesen, um genau zu sehen, was eine bestimmte Berechtigung ermöglicht. User.Readermöglicht der Anwendung zusätzlich zum Lesen des vollständigen Profils des aktuellen Benutzers die grundlegenden Informationen aus dem Organisationsobjekt in Microsoft Graph.

Schauen wir uns eine weitere Berechtigung an:

Der Vorgangsbereich, User.ReadBasic.All der mit allem beginnt, was User.Read tut. Darüber hinaus können Sie auf Anzeigename, Vorname und Familienname, E-Mail-Adresse, Foto und offene Erweiterungen für andere Organisationsbenutzer zugreifen. Der spezifische Bereich des Vorgangs ermöglicht Anwendungen die Verwendung einer ansprechenden Benutzerauswahl-UI und ist ein Beispiel für die API-Designer, die eine Berechtigung zum Aktivieren eines bestimmten Vorgangsbereichs verwenden.

Sehen wir uns ein paar weitere Berechtigungen für das Microsoft Graph-Benutzerobjekt an:

Wie bei User.Read und User.ReadWrite, sind User.Read.All und User.ReadWrite.All unterschiedliche Berechtigungen, die es einer Anwendung ermöglichen, dem Zero Trust-Prinzip der geringsten Berechtigung zu folgen.

User.Read.All ist interessant, da jeder Benutzer in der Organisation über diese Funktion verfügt (z. B. Outlook öffnen, eine Berichtskette nach oben und unten öffnen). Sie können als Einzelperson das vollständige Benutzerprofil jedes anderen Benutzers in Ihrer Organisation sehen. Die Microsoft Graph-API-Designer haben jedoch entschieden, dass nur Administratoren zulassen sollten, dass eine Anwendung denselben Vorgang ausführen kann, da User.Read.All die Organisationshierarchie des Mandanten enthält. Wenn ein Angreifer auf diese Informationen zugegriffen hat, könnte er einen gezielten Phishing-Angriff starten, bei dem die Phishing-E-Mail vom Vorgesetzten einer Person oder dem Vorgesetzten seines Vorgesetzten stammt.

User.ReadWrite.All ist ein leistungsstarker Betriebsbereich. Eine Anwendung, die diese Berechtigung erteilt hat, kann jeden Benutzer im Mandanten aktualisieren oder sogar löschen. Als delegierte Berechtigung kann die App, wenn sich ein Benutzer vor der App befindet, nur die Aktionen ausführen, die der aktuelle Benutzer ausführen kann. Normale Benutzer können andere Benutzer unabhängig von den Berechtigungen der App nicht aktualisieren oder löschen. Wenn jedoch ein Mandantenadministrator die App verwendet, können sie diese Vorgänge ausführen. Bei der Entscheidung, diese Berechtigung zu erteilen oder zu verweigern, sollten Sie Ihre App mit einem Mandantenadministratorbenutzer auswerten.

Berechtigungen, die eine Administratoreinwilligung erfordern

Angesichts der Leistungsfähigkeit von User.Read.All und User.ReadWrite.All haben die Microsoft Graph-API-Designer diese Berechtigungen mit Einwilligung des Administrators festgelegt. Lassen Sie uns eine Spalte Administrator? in unserem Berechtigungsverzeichnis einfügen, um anzugeben, wann die Berechtigung eine Administratoreinwilligung erfordert:

Wie im Artikel Anfordern von Berechtigungen, die die Einwilligung eines Administrators erfordern veranschaulicht, können Mandantenadministratoren Anforderungen außer Kraft setzen und für einige oder alle Anwendungsberechtigungen in ihrem Mandanten festlegen, dass die Einwilligung eines Administrators erforderlich ist. Sie sind schlau genug, Ihre App so zu entwerfen, dass sie ordnungsgemäß verarbeitet wird, wenn Sie kein Token von Ihrer Anforderung erhalten. Eine fehlende Einwilligung ist einer von vielen Gründen, warum Ihre App möglicherweise kein Token empfängt.

Nächste Schritte

• Aufrufen einer API über eine andere API hilft Ihnen, Zero Trust sicherzustellen, wenn Sie über eine API verfügen, die eine andere API aufrufen muss, und Ihre Anwendung sicher zu entwickeln, wenn sie im Auftrag eines Benutzers arbeitet.
• Erwerben der Autorisierung für den Zugriff auf Ressourcen hilft Ihnen zu verstehen, wie Sie beim Abrufen von Ressourcenzugriffsberechtigungen für Ihre Anwendung Zero Trust am besten sicherstellen können.
• Anpassen von Token beschreibt die Informationen, die Sie in Microsoft Entra-Token empfangen können. Es wird erläutert, wie Token angepasst werden, um Flexibilität und Kontrolle zu verbessern, während gleichzeitig die Zero Trust-Sicherheit der Anwendung mit minimalen Berechtigungen erhöht wird.
• Konfigurieren von Gruppenansprüchen und App-Rollen in Token zeigt, wie Sie Ihre Apps mit App-Rollendefinitionen konfigurieren und Sicherheitsgruppen zu App-Rollen zuweisen. Diese Methoden tragen dazu bei, Flexibilität und Kontrolle zu verbessern und gleichzeitig die Zero Trust-Sicherheit der Anwendung mit minimalen Berechtigungen zu erhöhen.
• Anfordern von Berechtigungen, die die Einwilligung eines Administrators erfordern beschreibt die Benutzeroberfläche für Berechtigungen und Einwilligungen, wenn Anwendungsberechtigungen administrative Einwilligung erfordern.
• Laden Sie in diesem Schnellstart: Schützen einer Web-API mit der Microsoft Identity Platform ein Codebeispiels zum Schutz einer ASP.NET Web-API herunter, und führen Sie es aus.
• In diesem Tutorial – Transformieren und Schützen Ihrer API in Azure API Management erfahren Sie, wie Sie allgemeine Richtlinien konfigurieren, um die Technologiestapelinformationen oder die ursprünglichen URLs in der HTTP-Antwort der API auszublenden.
• Bewährte Methoden zur Autorisierung helfen Ihnen, die besten Autorisierungs-, Berechtigungs- und Zustimmungsmodelle für Ihre Anwendungen zu implementieren.