Autorisatie verkrijgen voor toegang tot resources

Dit artikel helpt u, als ontwikkelaar, om te begrijpen hoe u Zero Trust het beste kunt garanderen bij het verkrijgen van toegangsmachtigingen voor resources voor uw toepassing. Voor toegang tot beveiligde resources, zoals e-mail- of agendagegevens, heeft uw toepassing de autorisatie van de resource-eigenaar nodig. De resource-eigenaar kan toestemming geven voor of weigeren van de aanvraag van uw app. Uw app ontvangt een toegangstoken wanneer de resource-eigenaar toestemming verleent; uw app ontvangt geen toegangstoken wanneer de resource-eigenaar de toegang weigert.

Conceptuele beoordeling

U kunt het Microsoft Identity Platform gebruiken om uw toepassingen te verifiëren en autoriseren en machtigingen en toestemming te beheren. Laten we beginnen met enkele concepten:

• Verificatie (soms ingekort tot AuthN) is het proces om aan te tonen dat uw geclaimde identiteit nauwkeurig is. Het Microsoft Identity Platform maakt gebruik van het OpenID-Verbinding maken-protocol voor het verwerken van verificatie. Autorisatie (soms ingekort tot AuthZ) verleent een geverifieerde partij toestemming om iets te doen. Hiermee geeft u op welke gegevens de geverifieerde partij toegang heeft. Het Microsoft Identity Platform maakt gebruik van het OAuth2.0-protocol voor het verwerken van autorisatie. Autorisatieopties omvatten toegangsbeheerlijsten (ACL), op rollen gebaseerd toegangsbeheer en kenmerktoegangsbeheer (ABAC). Verificatie is vaak een factor van autorisatie.

• Gedelegeerde toegang (handelend namens een aangemelde gebruiker) of directe toegang (alleen fungeren als de eigen identiteit van de toepassing) staat uw toepassing toegang tot gegevens toe. Gedelegeerde toegang vereist gedelegeerde machtigingen (ook wel bereiken genoemd); de client en de gebruiker moeten afzonderlijk worden geautoriseerd om de aanvraag te kunnen indienen. Directe toegang vereist mogelijk toepassingsmachtigingen (ook wel app-rollen genoemd). Wanneer app-rollen worden verleend aan toepassingen, kunnen ze toepassingsmachtigingen worden genoemd.

• Gedelegeerde machtigingen, die worden gebruikt met gedelegeerde toegang, staan toe dat een toepassing namens een gebruiker actie kan ondernemen, waarbij alleen toegang wordt verleend tot waartoe de gebruiker toegang heeft. Toepassingsmachtiging, die wordt gebruikt met directe toegang, staat een toepassing toegang toe tot alle gegevens waaraan de machtiging is gekoppeld. Alleen beheerders en eigenaren van service-principals kunnen toestemming geven voor toepassingsmachtigingen.

• Toestemming is de manier waarop toepassingen machtigingen ontvangen. Gebruikers of beheerders autoriseren een toepassing voor toegang tot een beveiligde resource. Een toestemmingsprompt bevat de machtigingen die de toepassing nodig heeft, samen met uitgeversgegevens.

• Verificatie vooraf is de manier waarop eigenaren van resourcetoepassingen toegang verlenen tot client-apps. Ze kunnen dit doen in Azure Portal of met behulp van PowerShell en API's zoals Microsoft Graph. Ze kunnen resourcemachtigingen verlenen zonder dat gebruikers een toestemmingsprompt voor de set vooraf geverifieerde machtigingen moeten zien.

Verschil tussen gedelegeerde machtigingen en toepassingsmachtigingen

Toepassingen werken in twee modi: wanneer een gebruiker aanwezig is (gedelegeerde machtiging) en wanneer er geen gebruiker is (toepassingsmachtiging). Wanneer er een gebruiker voor een toepassing staat, wordt u gedwongen om namens die gebruiker te handelen; U moet niet namens de toepassing zelf handelen. Wanneer een gebruiker uw toepassing leidt, fungeert u als gemachtigde voor die gebruiker. U krijgt toestemming om te handelen namens de gebruiker die het token identificeert.

Servicetypetoepassingen (achtergrondtaken, daemons, server-naar-serverprocessen) hebben geen gebruikers die zichzelf kunnen identificeren of een wachtwoord kunnen typen. Ze vereisen een toepassingsmachtiging om namens zichzelf te handelen (namens de servicetoepassing).

Best practices voor Zero Trust-toepassingsautorisatie

Uw autorisatiemethode heeft verificatie als onderdeel wanneer u verbinding maakt met een gebruiker die aanwezig is in de toepassing en met de resource die u aanroept. Wanneer uw toepassing namens een gebruiker handelt, vertrouwen we een aanroepende toepassing niet om ons te laten weten wie de gebruiker is of laat de toepassing beslissen wie de gebruiker is. Microsoft Entra-id verifieert en geeft rechtstreeks informatie over de gebruiker in het token.

Wanneer u wilt toestaan dat uw toepassing een API aanroept of uw toepassing autoriseert zodat de toepassing toegang heeft tot een resource, kunnen moderne autorisatieschema's autorisatie vereisen via een machtigings- en toestemmingsframework. Aanbevolen procedures voor referentiebeveiliging voor toepassingseigenschappen met omleidings-URI, toegangstokens (gebruikt voor impliciete stromen), certificaten en geheimen, URI voor toepassings-id's en het eigendom van toepassingen.

Volgende stappen

• Tokens aanpassen beschrijft de informatie die u kunt ontvangen in Microsoft Entra-tokens. In dit artikel wordt uitgelegd hoe u tokens aanpast om de flexibiliteit en controle te verbeteren en tegelijkertijd de beveiliging van nul vertrouwensrelaties met minimale bevoegdheden te verhogen.
• 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. Deze methoden helpen om de flexibiliteit en controle te verbeteren en tegelijkertijd de beveiliging van de toepassing nul vertrouwen te verhogen met minimale bevoegdheden.
• Door een strategie voor gedelegeerde machtigingen te ontwikkelen, kunt u de beste aanpak implementeren voor het beheren van machtigingen in uw toepassing en ontwikkelen met behulp van Zero Trust-principes.
• Door een strategie voor toepassingsmachtigingen te ontwikkelen, kunt u beslissen over de benadering van uw toepassingsmachtigingen voor referentiebeheer.
• Geef referenties voor toepassingsidentiteiten op wanneer er geen gebruiker is waarom Beheerde identiteiten voor Azure-resources de beste methode voor clientreferenties zijn voor services (niet-gebruikerstoepassingen) in Azure.
• 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.
• Het bouwen van apps met een Zero Trust-benadering voor identiteit gaat verder vanuit het artikel best practices voor identiteits- en toegangsbeheer voor Zero Trust om u te helpen bij het gebruik van een Zero Trust-benadering voor identiteit in uw levenscyclus voor softwareontwikkeling (SDLC).