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.

• Voor toegang tot gegevens kan uw toepassing gedelegeerde toegang gebruiken (handelen namens een aangemelde gebruiker) of directe toegang (alleen fungeren als de eigen identiteit van de toepassing). 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.

• Toepassingen ontvangen machtigingen via toestemming; 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.

• Eigenaren van resourcetoepassingen kunnen client-apps vooraf verifiëren (in Azure Portal of met behulp van PowerShell en API's zoals Microsoft Graph). Ze kunnen resourcemachtigingen verlenen zonder dat gebruikers een toestemmingsprompt moeten zien voor de set machtigingen die vooraf zijn geverifieerd.

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 met 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 verstrekt 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

• 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.
• Het ontwikkelen van een strategie voor gedelegeerde machtigingen helpt u bij het implementeren van de beste benadering voor het beheren van machtigingen in uw toepassing en het 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.
• Het opgeven van toepassingsidentiteitsreferenties wanneer er geen gebruiker is, legt uit waarom de beste zero Trust-clientreferenties voor services (niet-gebruikerstoepassingen) in Azure Beheerde identiteiten zijn voor Azure-resources.
• 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).