Basisprincipes van autorisatie
Autorisatie (soms afgekort als AuthZ) wordt gebruikt om machtigingen in te stellen waarmee de toegang tot resources of functionaliteit kan worden geëvalueerd. Verificatie (soms afgekort als AuthN) is daarentegen gericht op het bewijzen dat een entiteit zoals een gebruiker of service inderdaad is wie ze beweren te zijn.
Autorisatie kan bestaan uit het opgeven van de functionaliteit, resources of gegevens die een entiteit mag openen. Autorisatie geeft ook aan wat er met de gegevens kan worden gedaan. Deze autorisatieactie wordt vaak aangeduid als toegangsbeheer.
Verificatie en autorisatie zijn concepten die niet beperkt zijn tot alleen gebruikers. Services of daemon-toepassingen worden vaak gebouwd om aanvragen voor resources zelf te maken in plaats van namens een specifieke gebruiker. In dit artikel wordt de term 'entiteit' gebruikt om te verwijzen naar een gebruiker of een toepassing.
Autorisatiemethoden
Er zijn verschillende algemene benaderingen voor het afhandelen van autorisatie. Op rollen gebaseerd toegangsbeheer is momenteel de meest voorkomende benadering met het Microsoft Identity Platform.
Verificatie als autorisatie
Mogelijk is de eenvoudigste vorm van autorisatie het verlenen of weigeren van toegang op basis van of de entiteit die een aanvraag indient, is geverifieerd. Als de aanvrager kan bewijzen dat hij/zij is wie hij/zij beweert te zijn, heeft hij/zij toegang tot de beveiligde resources of functionaliteit.
Toegangsbeheerlijsten
Autorisatie met behulp van toegangsbeheerlijsten (ACL's) omvat het onderhouden van expliciete lijsten met specifieke entiteiten die wel of geen toegang hebben tot een resource of functionaliteit. ACL's bieden een nauwkeurigere controle over verificatie als autorisatie, maar worden moeilijk te beheren naarmate het aantal entiteiten toeneemt.
Op rollen gebaseerd toegangsbeheer
Op rollen gebaseerd toegangsbeheer (RBAC) is mogelijk de meest voorkomende benadering voor het afdwingen van autorisatie in toepassingen. Wanneer u RBAC gebruikt, worden rollen gedefinieerd om de soorten activiteiten te beschrijven die een entiteit kan uitvoeren. Een toepassingsontwikkelaar verleent toegang tot rollen in plaats van aan afzonderlijke entiteiten. Een beheerder kan vervolgens rollen toewijzen aan verschillende entiteiten om te bepalen welke entiteiten toegang hebben tot welke resources en functionaliteit.
In geavanceerde RBAC-implementaties kunnen rollen worden toegewezen aan verzamelingen machtigingen, waarbij een machtiging een gedetailleerde actie of activiteit beschrijft die kan worden uitgevoerd. Rollen worden vervolgens geconfigureerd als combinaties van machtigingen. Bereken de algemene machtigingenset voor een entiteit door de machtigingen te combineren die zijn verleend aan de verschillende rollen waaraan de entiteit is toegewezen. Een goed voorbeeld van deze benadering is de RBAC-implementatie die de toegang tot resources in Azure-abonnementen regelt.
Notitie
Toepassings-RBAC verschilt van Azure RBAC en Microsoft Entra RBAC. Aangepaste Azure-rollen en ingebouwde rollen maken beide deel uit van Azure RBAC, waarmee u Azure-resources kunt beheren. Met Microsoft Entra RBAC kunt u Microsoft Entra-resources beheren.
Toegangsbeheer op basis van kenmerken
Op kenmerken gebaseerd toegangsbeheer (ABAC) is een nauwkeuriger mechanisme voor toegangsbeheer. In deze benadering worden regels toegepast op de entiteit, de resources die worden geopend en de huidige omgeving. De regels bepalen het toegangsniveau voor resources en functionaliteit. Een voorbeeld kan zijn dat gebruikers die managers zijn alleen toegang geven tot bestanden die zijn geïdentificeerd met een metagegevenstag 'managers alleen tijdens werkuren' tijdens de uren van 9:00 tot 17:00 uur op werkdagen. In dit geval wordt de toegang bepaald door het kenmerk (status als manager) van de gebruiker, het kenmerk (metagegevenstag op een bestand) van de resource te onderzoeken en ook een omgevingskenmerk (de huidige tijd).
Een voordeel van ABAC is dat meer gedetailleerd en dynamisch toegangsbeheer kan worden bereikt via regel- en voorwaardeevaluaties zonder dat grote aantallen specifieke rollen en RBAC-toewijzingen hoeven te worden gemaakt.
Eén methode voor het bereiken van ABAC met Microsoft Entra ID is het gebruik van dynamische lidmaatschapsgroepen. Met dynamische groepen kunnen beheerders gebruikers dynamisch toewijzen aan groepen op basis van specifieke gebruikerskenmerken met gewenste waarden. Een auteursgroep kan bijvoorbeeld worden gemaakt waarbij alle gebruikers met de functie Auteur dynamisch zijn toegewezen aan de groep Auteurs. Dynamische groepen kunnen worden gebruikt in combinatie met RBAC voor autorisatie waarbij u rollen toewijst aan groepen en gebruikers dynamisch toewijst aan groepen.
Azure ABAC is een voorbeeld van een ABAC-oplossing die momenteel beschikbaar is. Azure ABAC bouwt voort op Azure RBAC door roltoewijzingsvoorwaarden toe te voegen op basis van kenmerken in de context van specifieke acties.
Autorisatie implementeren
Autorisatielogica wordt vaak geïmplementeerd in de toepassingen of oplossingen waar toegangsbeheer vereist is. In veel gevallen bieden platformen voor toepassingsontwikkeling middleware of andere API-oplossingen die de implementatie van autorisatie vereenvoudigen. Voorbeelden hiervan zijn het gebruik van AuthorizeAttribute in ASP.NET of Route Guards in Angular.
Voor autorisatiemethoden die afhankelijk zijn van informatie over de geverifieerde entiteit, evalueert een toepassing informatie die tijdens de verificatie wordt uitgewisseld. Bijvoorbeeld door de informatie te gebruiken die is opgegeven in een beveiligingstoken. Als u van plan bent informatie van tokens te gebruiken voor autorisatie, raden we u aan deze richtlijnen te volgen voor het correct beveiligen van apps via claimvalidatie. in Voor informatie die niet is opgenomen in een beveiligingstoken, kan een toepassing extra aanroepen naar externe resources maken.
Het is niet strikt noodzakelijk dat ontwikkelaars autorisatielogica volledig insluiten in hun toepassingen. In plaats daarvan kunnen toegewezen autorisatieservices worden gebruikt om autorisatie-implementatie en -beheer te centraliseren.
Volgende stappen
- Zie Op rollen gebaseerd toegangsbeheer voor toepassingsontwikkelaars voor meer informatie over de implementatie van op rollen gebaseerd toegangsbeheer in toepassingen.
- Zie het toepassingsmodel voor meer informatie over het registreren van uw toepassing, zodat deze kan worden geïntegreerd met het Microsoft Identity Platform.
- Zie Uw App Service- of Azure Functions-app configureren voor het gebruik van Microsoft Entra-aanmelding voor een voorbeeld van het configureren van eenvoudige verificatiegebaseerde autorisatie.
- Zie Voor meer informatie over de juiste autorisatie met behulp van tokenclaims beveiligde toepassingen en API's door claims te valideren