Strategie voor gedelegeerde machtigingen ontwikkelen

Dit artikel helpt u, als ontwikkelaar, bij het implementeren van de beste benadering voor het beheren van machtigingen in uw toepassing en het ontwikkelen met behulp van Zero Trust-principes. Zoals beschreven in Autorisatie verkrijgen voor toegang tot resources, worden gedelegeerde machtigingen gebruikt met gedelegeerde toegang om een toepassing toestemming te geven om namens een gebruiker te handelen, waarbij alleen toegang wordt verkregen tot waartoe de gebruiker toegang heeft. Toepassingsmachtigingen worden gebruikt met directe toegang om een toepassing toegang te geven tot gegevens waaraan de machtiging is gekoppeld. Alleen beheerders en eigenaren van service-principals kunnen toestemming geven voor toepassingsmachtigingen.

De machtigings- en toestemmingsmodellen verwijzen voornamelijk naar een toepassing. Het machtigings- en toestemmingsproces heeft geen controle over wat een gebruiker kan doen. Hiermee bepaalt u welke acties de toepassing mag uitvoeren.

Raadpleeg het volgende Venn-diagram. Met gedelegeerde machtigingen is er een snijpunt tussen wat de gebruiker mag doen en wat de toepassing mag doen. Dat snijpunt is de effectieve machtiging waarmee de toepassing is gebonden. Wanneer u een gedelegeerde machtiging gebruikt, wordt deze gebonden door de effectieve machtigingen.

'Beschrijving van venn-diagram: tekst links: apps krijgen toestemming voor het bewerkingsbereik van de app. Tekst in rechtercirkel: gebruikers hebben machtigingen voor bewerkingen die worden beheerd door hun organisatie. Snijpunt van cirkeltekst: Effectieve machtigingen: snijpunt van app-machtigingen en gebruikersmogelijkheden.

Uw toepassing met gebruikers voor de app krijgt bijvoorbeeld toestemming om het profiel van elke gebruiker in de tenant bij te werken. Dat betekent niet dat iemand die uw toepassing uitvoert, het profiel van iemand anders kan bijwerken. Als de beheerder besluit uw toepassing User.ReadWrite.Allte verlenen, denken ze dat uw toepassing de juiste dingen doet bij het bijwerken van een gebruikersprofiel. Uw app kan de wijzigingen registreren en de gegevens op de juiste manier beveiligen. De beheerder oordeelt een waarde over de toepassing, niet over de gebruiker.

Benadering met minimale bevoegdheden

API's kunnen complex zijn. Eenvoudige API's hebben mogelijk niet veel bewerkingen. Complexe API's zoals Microsoft Graph bevatten veel aanvragen die een toepassing mogelijk wil gebruiken. Alleen omdat de toepassing het recht heeft om te lezen, betekent dit niet dat deze het recht moet hebben om bij te werken. Microsoft Graph heeft bijvoorbeeld duizenden API's. Omdat u gemachtigd bent om het profiel van de gebruiker te lezen, is er geen reden waarom u ook gemachtigd moet zijn om al hun OneDrive-bestanden te verwijderen.

Als ontwikkelaar moet u het volgende doen:

• weten welke API's de app aanroept.
• inzicht in de API-documentatie en de machtigingen die de API vereist.
• gebruik de minst mogelijke machtiging om uw taken uit te voeren.

API's bieden vaak toegang tot organisatiegegevensarchieven en trekken de aandacht van aanvallers die toegang willen krijgen tot die gegevens.

Evalueer de machtigingen die u aanvraagt om ervoor te zorgen dat u de absolute minst bevoegde set zoekt om de taak uit te voeren. Vermijd het aanvragen van machtigingen voor hogere bevoegdheden; In plaats daarvan moet u zorgvuldig werken met het grote aantal machtigingen dat API's zoals Microsoft Graph bieden. Zoek en gebruik de minimale machtigingen om aan uw behoeften te voldoen. Als u geen code schrijft om het profiel van de gebruiker bij te werken, vraagt u deze niet aan voor uw toepassing. Als u alleen toegang hebt tot gebruikers en groepen, vraagt u geen toegang tot andere gegevens in de directory. U vraagt geen toestemming voor het beheren van gebruikers-e-mail als u geen code schrijft die toegang heeft tot gebruikers-e-mail.

In zero Trust-toepassingsontwikkeling:

• Definieer de intentie van uw toepassing en wat deze nodig heeft.
• Zorg ervoor dat slechte actoren geen inbreuk kunnen maken en uw app kunnen gebruiken op een manier die u niet van plan was.
• Dien aanvragen in voor goedkeuring waarin u uw vereisten definieert (bijvoorbeeld de e-mail van de gebruiker lezen).

Gebruikers- en tenantbeheerdersrollen in machtiging en toestemming

Mensen die uw aanvragen kunnen goedkeuren, vallen in twee categorieën: beheerders die altijd toestemming kunnen geven voor machtigingsaanvragen en gewone gebruikers die geen beheerders zijn. De tenantbeheerders hebben echter de laatste uitspraak in hun tenant met betrekking tot welke machtigingen beheerderstoestemming vereisen en welke machtigingen een gebruiker toestemming kan geven.

Wanneer een API-ontwerper beheerderstoestemming vereist voor een machtiging, is voor die machtiging altijd beheerderstoestemming vereist; een tenantbeheerder kan dat niet overschrijven en alleen toestemming van de gebruiker vereisen.

Wanneer een API-ontwerper machtigingen definieert waarvoor toestemming van de gebruiker is vereist, kunnen suggesties voor gebruikerstoestemming door de API-ontwerper worden overschreven door de tenantbeheerder. De tenantbeheerders kunnen dit doen met een 'grote switch' in de tenant: voor alles is beheerderstoestemming vereist. Ze kunnen gebruikerstoestemming op een gedetailleerdere manier overschrijven met machtigings- en toestemmingsbeheer. Ze kunnen bijvoorbeeld toestaan dat gebruikers toestemming geven voor aanvragen van geverifieerde uitgevers , maar niet van andere uitgevers. In een ander voorbeeld kunnen ze toestaan User.Read om zich aan te melden bij de gebruiker en hun profiel te lezen, maar ze vereisen beheerderstoestemming voor apps die toestemming vragen voor e-mail of bestanden.

API-ontwerpers doen hun suggesties, maar tenantbeheerders hebben de laatste uitspraak. Daarom weet u als ontwikkelaar niet altijd wanneer uw app beheerderstoestemming vereist. Het is leuk om dat te plannen en te ontwerpen, maar vergeet niet, wanneer u een tokenaanvraag indient, kan het om welke reden dan ook worden geweigerd. In uw code moet u het ophalen van een token probleemloos afhandelen, omdat tenantbeheerders waarin uw klanten of gebruikers uw toepassing uitvoeren, bepalen wanneer machtigingen beheerderstoestemming vereisen.

Voorbeeld van het gebruik van JavaScript MSAL

Voor de verificatie in dit voorbeeld gebruikt u onze JavaScript Microsoft Authentication Library (MSAL) om de gebruiker aan te melden in een toepassing met één pagina (SPA) waar alle app-logica wordt uitgevoerd vanuit de browser.

In het gerelateerde quickstart-artikel kunt u een codevoorbeeld downloaden en uitvoeren. Het laat zien hoe een JavaScript-toepassing met één pagina (SPA) gebruikers kan aanmelden en Microsoft Graph kan aanroepen met behulp van de autorisatiecodestroom met Proof Key for Code Exchange (PKCE). In het codevoorbeeld ziet u hoe u een toegangstoken kunt ophalen om de Microsoft Graph API of een web-API aan te roepen.

Zoals wordt weergegeven in de onderstaande voorbeeldcode, maakt u een instantie van een openbare client omdat een toepassing die volledig in de browser wordt uitgevoerd, een openbare client moet zijn. De gebruiker kan de interne werking van uw toepassing in handen krijgen wanneer de code zich in de browser bevindt.

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

Vervolgens gebruikt u onze MSAL-bibliotheek. In MSAL JavaScript is er een specifieke API om u aan te melden. Er zijn twee API's die gebruikmaken van specifieke mogelijkheden in de browser. Een daarvan is om u aan te melden met een pop-upervaring; de andere is om u aan te melden met een browseromleidingservaring.

Zoals wordt weergegeven in het onderstaande codevoorbeeld, verwerkt het pop-upvenster voor aanmelden de verificatie die de gebruiker moet uitvoeren door de signIn functie aan te roepen.

function signIn() {

    /**
     * You can pass a custom request object below. This will override 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);
        });
}

Uw app kan informatie over de gebruiker ophalen, zoals hun weergavenaam of gebruikers-id. Vervolgens heeft uw app autorisatie nodig om het volledige profiel van de gebruiker van Microsoft Graph te lezen door een patroon te volgen dat u in onze MSAL-bibliotheken gaat gebruiken.

Zoals wordt weergegeven in de onderstaande voorbeeldcode, probeert uw app de autorisatie op te halen door aan te roepen AcquireTokenSilent. Als Microsoft Entra ID het token kan uitgeven zonder interactie met de gebruiker, retourneert u AcquireTokenSilent het token dat uw app namens de gebruiker nodig heeft voor toegang tot Microsoft Graph.

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);
            }
    });
}

Vaak kan microsoft Entra-id het token echter niet uitgeven zonder interactie met de gebruiker (de gebruiker heeft bijvoorbeeld zijn wachtwoord gewijzigd of er is geen toestemming verleend). AcquireTokenSilent Daarom wordt een fout teruggestuurd naar de toepassing waarvoor gebruikersinteractie is vereist. Wanneer uw app de fout ontvangt, valt u terug om aan te roepen AcquireTokenPopup.

Op dat moment zal Microsoft Entra ID een gesprek hebben met de gebruiker, zodat ze de gebruiker kunnen verifiëren en uw app toestemming kunnen geven om namens de gebruiker te handelen (bijvoorbeeld een MFA uitvoeren, hun wachtwoord opgeven, toestemming verlenen). Vervolgens krijgt uw app het token dat nodig is om verder te gaan.

Een primaire stap in het traject van een onderneming naar Zero Trust is om sterkere verificatiemethoden te gebruiken in plaats van alleen een gebruikers-id en wachtwoord. Met de bovenstaande voorbeeldcode kan een onderneming volledig overstappen op de sterkere verificatiemethode die de onderneming kiest. Bijvoorbeeld meervoudige verificatie, volledig wachtwoordloos met een FIDO2-sleutel, Microsoft Authenticator.

Volgende stappen

• Het verkrijgen van autorisatie voor toegang tot resources helpt u te begrijpen hoe u Zero Trust het beste kunt garanderen bij het verkrijgen van machtigingen voor toegang tot resources voor uw toepassing.
• Door een strategie voor toepassingsmachtigingen te ontwikkelen, kunt u beslissen over de benadering van uw toepassingsmachtigingen voor referentiebeheer.
• Door tokens aan te passen worden de gegevens beschreven die u kunt ontvangen in Microsoft Entra-tokens en hoe u tokens kunt aanpassen om de flexibiliteit en controle te verbeteren en tegelijkertijd de beveiliging van het vertrouwen van toepassingen met minimale bevoegdheden te vergroten.
• Als u groepsclaims en app-rollen in tokens configureert, ziet u hoe u uw apps configureert met app-roldefinities en beveiligingsgroepen toewijst aan app-rollen om de flexibiliteit en controle te verbeteren en tegelijkertijd de beveiliging van nul vertrouwensrelaties met minimale bevoegdheden te vergroten.
• API Protection beschrijft aanbevolen procedures voor het beveiligen van uw API via registratie, het definiëren van machtigingen en toestemming en het afdwingen van toegang om uw Zero Trust-doelstellingen te bereiken.
• Als u een API aanroept vanuit een andere API, kunt u ervoor zorgen dat Zero Trust een API heeft die een andere API moet aanroepen en uw toepassing veilig moet ontwikkelen wanneer deze namens een gebruiker werkt.
• Met best practices voor autorisatie kunt u de beste autorisatie-, machtigings- en toestemmingsmodellen voor uw toepassingen implementeren.
• Gebruik best practices voor identiteits- en toegangsbeheer van Zero Trust in de ontwikkelingslevenscyclus van uw toepassing om veilige toepassingen te maken.