Entwickeln einer delegierten Berechtigungsstrategie

Dieser Artikel hilft Ihnen als Entwickler, den besten Ansatz zum Verwalten von Berechtigungen in Ihrer Anwendung zu implementieren und mithilfe von Zero Trust-Prinzipien zu entwickeln. Wie unter Abrufen der Autorisierung für den Zugriff auf Ressourcen beschrieben, werden delegierte Berechtigungen mit delegiertem Zugriff verwendet, um einer Anwendung das Handeln im Namen eines Benutzers zu ermöglichen, sie aber nur auf das zugreifen kann, auf was der Benutzer Zugriff hat. Anwendungsberechtigungen werden mit direktem Zugriff verwendet, um einer Anwendung den Zugriff auf alle Daten zu ermöglichen, denen die Berechtigung zugeordnet ist. Nur Administratoren und Besitzer des Dienstprinzipals können in Anwendungsberechtigungen einwilligen.

Die Berechtigungs- und Einwilligungsmodelle beziehen sich hauptsächlich auf eine Anwendung. Der Berechtigungs- und Einwilligungsprozess hat keine Kontrolle darüber, was ein Benutzer tun kann. Sie steuert, welche Aktionen die Anwendung ausführen darf.

Bezugnahme auf das folgende Venn-Diagramm. Mit delegierten Berechtigungen gibt es eine Schnittmenge zwischen dem, was der Benutzer tun darf und was die Anwendung tun darf. Diese Schnittmenge ist die effektive Berechtigung, an die die Anwendung gebunden ist. Immer dann, wenn Sie eine delegierte Berechtigung verwenden, sind effektive Berechtigungen daran gebunden.

„Venn-Diagrammbeschreibung: Linker Kreistext: Apps werden die Einwilligung für den App-Arbeitsbereich gewährt. Rechter Kreistext: Benutzer haben Berechtigungen für Vorgänge, die von ihrer Organisation verwaltet werden. Schnittmenge von Kreistexten: Effektive Berechtigungen: Schnittmenge von App-Berechtigungen und Benutzerfunktionen.“

Ihre Anwendung, die Benutzer vor der App hat, erhält beispielsweise die Berechtigung, das Profil jedes Benutzers im Mandanten zu aktualisieren. Das bedeutet nicht, dass jeder Benutzer, der Ihre Anwendung ausführt, das Profil einer anderen Person aktualisieren kann. Wenn der Administrator entscheidet, Ihre Anwendung zu gestatten User.ReadWrite.All, glauben Sie, dass Ihre Anwendung bei der Aktualisierung eines Benutzerprofils die richtigen Aktionen ausführt. Ihre App protokolliert möglicherweise die Änderungen und schützt die Informationen ordnungsgemäß. Der Administrator gibt ein Werturteil über die Anwendung und nicht über den Benutzer ab.

Ansatz geringster Berechtigungen

APIs können komplex sein. Einfache APIs verfügen möglicherweise nicht über viele Vorgänge. Komplexe APIs wie Microsoft Graph kapseln viele Anforderungen, die eine Anwendung verwenden möchte. Nur weil die Anwendung das Recht zum Lesen hat, bedeutet dies nicht, dass sie das Recht zum Aktualisieren haben sollte. Microsoft Graph verfügt beispielsweise über Tausende von APIs. Da Sie nur über die Berechtigung zum Lesen des Benutzerprofils verfügen, gibt es keinen Grund, warum Sie auch über die Berechtigung zum Löschen aller OneDrive-Dateien verfügen sollten.

Als Entwickler sollten Sie:

• wissen, welche APIs die App aufruft.
• die API-Dokumentation verstehen und welche Berechtigungen die API erfordert.
• verwenden Sie die geringste Berechtigung, um Ihre Aufgaben auszuführen.

APIs ermöglichen oft den Zugriff auf Organisationsdatenspeicher und können die Aufmerksamkeit von Angreifern wecken, die auf diese Daten zugreifen möchten.

Werten Sie die angeforderten Berechtigungen aus, um sicherzustellen, dass Sie den Satz mit den geringstmöglichen Berechtigungen für die jeweilige Aufgabe anfordern. Vermeiden Sie das Anfordern höherprivilegierter Berechtigungen. Arbeiten Sie stattdessen sorgfältig durch die große Anzahl von Berechtigungen, die APIs wie Microsoft Graph bereitstellen. Suchen und verwenden Sie die Mindestberechtigungen, um Ihre Anforderungen zu erfüllen. Wenn Sie keinen Code schreiben, um das Profil des Benutzers zu aktualisieren, fordern Sie ihn nicht für Ihre Anwendung an. Wenn Sie nur auf Benutzer und Gruppen zugreifen, fordern Sie keinen Zugriff auf andere Informationen im Verzeichnis an. Sie fordern keine Berechtigung zum Verwalten von Benutzer-E-Mails an, wenn Sie keinen Code schreiben, der auf Benutzer-E-Mails zugreift.

In der Zero Trust-Anwendungsentwicklung:

• Definieren Sie die Absicht Ihrer Anwendung und ihre Anforderungen.
• Stellen Sie sicher, dass Bösewichte Ihre App nicht kompromittieren und auf eine Weise verwenden können, die Sie nicht beabsichtigt haben.
• Stellen Sie Anträge auf Genehmigungen, in denen Sie Ihre Anforderungen definieren (z. B. die E-Mail des Benutzers lesen).

Rollen für Benutzer- und Mandantenadministratoren in Berechtigung und Einwilligung

Personen, die Ihre Anforderungen genehmigen können, unterteilen sich in zwei Kategorien: Administratoren, die immer Berechtigungsanforderungen bewilligen können und reguläre Benutzer, die keine Administratoren sind. Die Mandantenadministratoren haben jedoch in ihrem Mandanten das letzte Wort darüber, welche Berechtigungen Administratorzustimmung erfordern und welchen Berechtigungen ein Benutzer zustimmen kann.

Wenn ein API-Designer eine Administratorzustimmung für eine Berechtigung erfordert, erfordert diese Berechtigung immer die Administratorzustimmung. Ein Mandantenadministrator kann dies nicht außer Kraft setzen und nur die Zustimmung des Benutzers erfordern.

Wenn ein API-Designer Berechtigungen definiert, die eine Benutzerzustimmung erfordern, kann der Mandantenadministrator die Vorschläge zur Benutzerzustimmung des API-Designers überschreiben. Die Mandantenadministratoren können dies mit einem „großen Switch“ im Mandanten tun: Alles erfordert Administratorzustimmung. Sie können die Einwilligung des Benutzers präziser mit der Berechtigungs- und Zustimmungsverwaltung überschreiben. Sie können Benutzern beispielsweise erlauben, Anforderungen der Benutzerzustimmung von bestätigten Herausgebern, aber nicht von anderen Herausgebern, zuzustimmen. In einem anderen Beispiel können Sie zulassen, dass User.Read sich beim Benutzer anmeldet und das Profil liest, aber eine Administratorzustimmung für Apps erfordern, welche die Berechtigung für E-Mails oder Dateien anfordern.

API-Entwickler machen ihre Vorschläge, aber Mandantenadministratoren haben das letzte Wort. Daher wissen Sie als Entwickler nicht immer, wann Ihre App die Administratorzustimmung erfordert. Es ist schön, dies zu planen und zu entwerfen, aber denken Sie daran, dass Ihre Token-Anforderung auch aus irgendeinem Grund verweigert werden könnte. In Ihrem Code müssen Sie ordnungsgemäß damit umgehen, dass kein Token abgerufen wird, da Mandantenadministratoren, in denen Ihre Kunden oder Benutzer Ihre Anwendung ausführen, entscheiden, wann Berechtigungen eine Administratorzustimmung erfordern.

Beispiel für die Verwendung von JavaScript MSAL

Für die Authentifizierung in diesem Beispiel verwenden Sie unsere JavaScript Microsoft Authentication Library (MSAL), um den Benutzer in einer Einzelseitenanwendung (Single Page Application, SPA) anzumelden, in der alle App-Logik aus dem Browser ausgeführt wird.

Im zugehörigen Schnellstartartikel können Sie ein Codebeispiel herunterladen und ausführen. Es zeigt Ihnen, wie eine JavaScript-Single-Page-Webanwendung Benutzer anmelden und Microsoft Graph mithilfe des Autorisierungscodeflusses mit PKCE (Proof Key for Code Exchange) aufrufen kann. Das Codebeispiel veranschaulicht, wie Sie ein Zugriffstoken dazu bringen, die Microsoft Graph-API oder eine beliebigen Web-API aufzurufen.

Wie im folgenden Beispielcode gezeigt, instanziieren Sie einen öffentlichen Client, da eine Anwendung, die vollständig im Browser ausgeführt wird, ein öffentlicher Client sein muss. Der Benutzer kann die Interna seiner Anwendung einsehen, wenn sich der Code im Browser befindet.

// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);

Dann verwenden Sie unsere MSAL-Bibliothek. In MSAL JavaScript gibt es eine bestimmte API für die Anmeldung. Es gibt zwei APIs, die bestimmte Funktionen im Browser nutzen. Eine besteht darin, sich mit einer Popup-Oberfläche anzumelden. Die andere besteht darin, sich mit einer Browserumleitung anzumelden.

Wie im folgenden Codebeispiel gezeigt, verarbeitet das Anmelde-Popup die Authentifizierung, die der Benutzer ausführen muss, indem die signIn-Funktion aufgerufen wird.

function signIn() {

    /**
     * You can pass a custom request object. This overrides the initial configuration. For more information, visit:
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
     */

    myMSALObj.loginPopup(loginRequest)
        .then(handleResponse)
        .catch(error => {
            console.error(error);
        });
}

Ihre App kann Informationen über den Benutzer abrufen, z. B. den Anzeigenamen oder die Benutzer-ID. Als Nächstes benötigt Ihre App die Autorisierung, um das vollständige Profil des Benutzers aus Microsoft Graph zu lesen, indem Sie einem Muster folgen, das Sie in unseren MSAL-Bibliotheken verwenden.

Wie im folgenden Beispielcode gezeigt, versucht Ihre App, die Autorisierung durch Aufrufen von AcquireTokenSilent zu erhalten. Wenn die Microsoft Entra-ID das Token ausgeben kann, ohne mit dem Benutzer zu interagieren, gibt AcquireTokenSilent das Token zurück, das Ihre App für den Zugriff auf Microsoft Graph im Namen des Benutzers benötigt.

function getTokenPopup(request) {

    /**
     * See here for more info on account retrieval: 
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
     */
    request.account = myMSALObj.getAccountByUsername(username);
    
    return myMSALObj.`AcquireTokenSilent`(request)
        .catch(error => {
            console.warn("silent token acquisition fails. acquiring token using popup");
            if (error instanceof msal.InteractionRequiredAuthError) {
                // fallback to interaction when silent call fails
                return myMSALObj.`AcquireTokenPopup`(request)
                    .then(tokenResponse => {
                        console.log(tokenResponse);
                        return tokenResponse;
                    }).catch(error => {
                        console.error(error);
                    });
            } else {
                console.warn(error);
            }
    });
}

Häufig kann Microsoft Entra ID das Token jedoch nicht ausstellen, ohne mit dem Benutzer zu interagieren (z. B. falls der Benutzer sein Kennwort geändert oder keine Zustimmung erteilt hat). AcquireTokenSilent sendet daher einen Fehler zurück an die Anwendung, die eine Benutzerinteraktion erfordert. Wenn Ihre App den Fehler empfängt, greifen Sie auf den AcquireTokenPopup-Aufruf zurück.

Zu dem Zeitpunkt hat Microsoft Entra ID eine Unterhaltung mit dem Benutzer, um den Benutzer zu authentifizieren und Ihre App zu autorisieren, im Namen des Benutzers zu handeln (z. B. MFA ausführen, Kennwort angeben, Zustimmung erteilen). Dann ruft Ihre App das Token ab, das sie nach vorne verschieben muss.

Ein primärer Schritt in der Zero Trust-Journey eines Unternehmens besteht darin, stärkere Authentifizierungsmethoden anstelle einer Benutzer-ID und eines Kennworts zu übernehmen. Der voranstehende Beispielcode ermöglicht es einem Unternehmen, zur stärkeren Authentifizierungsmethode zu wechseln, die das Unternehmen auswählt. Beispiel: mehrstufige Authentifizierung, vollständig kennwortlos mit einem FIDO2-Schlüssel, Microsoft Authenticator.

Nächste Schritte

• 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.
• Entwickeln einer Strategie für Anwendungsberechtigungen hilft Ihnen bei der Entscheidung über den Ansatz Ihrer Anwendungsberechtigungen für die Verwaltung von Anmeldeinformationen.
• 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.
• Der API-Schutz beschreibt bewährte Methoden zum Schutz Ihrer API durch Registrierung, Definieren von Berechtigungen und Einwilligung sowie das Durchsetzen der Zugriffskontrolle, um Ihre Zero Trust-Ziele zu erreichen.
• 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.
• Bewährte Methoden zur Autorisierung helfen Ihnen, die besten Autorisierungs-, Berechtigungs- und Zustimmungsmodelle für Ihre Anwendungen zu implementieren.
• Verwenden Sie bewährte Methoden der Zero Trust-Identitäts- und Zugriffsverwaltungsentwicklung in Ihrem Anwendungsentwicklungslebenszyklus, um sichere Anwendungen zu erstellen.