Verifieerbare autorisatie in PHP: rechten zonder uitzonderingen

Het ontwerp van rechten en autorisatie in PHP wordt niet opgelost met een scherm waarin profielen worden toegewezen. Het probleem ontstaat wanneer eenzelfde actie afhangt van wie deze uitvoert, voor welke organisatie diegene werkt, op welke gegevens de actie betrekking heeft en in welke status die gegevens zich bevinden. Als deze voorwaarden verspreid staan over controllers, queries, templates en interfacevalidaties, stapelt het systeem uiteindelijk uitzonderingen op die moeilijk te beoordelen zijn.

Het doel moet zijn dat elke beslissing expliciet, herhaalbaar en verifieerbaar is: een identiteit probeert binnen een context een bewerking op een resource uit te voeren, en een beleid beslist of dit is toegestaan. Deze aanpak zet dubbelzinnige operationele regels om in technische controles die product, operations en ontwikkeling gezamenlijk kunnen beoordelen.

Identiteit, autorisatie en datareikwijdte scheiden

Authenticatie beantwoordt de vraag wie de gebruiker is: sessie, credentials, identity provider of token. Autorisatie beantwoordt de vraag wat die identiteit mag doen. Het is niet raadzaam om het tweede uitsluitend uit het eerste af te leiden of beide als één laag te behandelen.

Een rol groepeert verantwoordelijkheden, zoals organisatiebeheerder, supportmedewerker of goedkeurder. Een recht vertegenwoordigt een concrete bewerking, bijvoorbeeld invoice.read, invoice.approve of member.invite. De reikwijdte bepaalt voor welke resources die bewerking geldt: facturen van een organisatie, dossiers van een eenheid of eigen records.

Dit onderscheid voorkomt een veelgemaakte fout: leesrechten voor facturen verlenen en aannemen dat daarmee elke factuur mag worden gelezen. Het beleid moet nog steeds controleren of de resource bij de actieve organisatie hoort, of de gebruiker aan de betreffende eenheid is toegewezen en of de status van de resource de gevraagde actie toelaat.

Een toegangsmatrix opbouwen vanuit bewerkingen

Maak vóór u klassen of packages kiest een overzicht van de daadwerkelijke resources en bewerkingen. Gebruik bedrijfswerkwoorden in plaats van vage labels als “beheren”: bestelling aanmaken, bestelling bekijken, concept corrigeren, bestelling goedkeuren, bestelling annuleren, bestellingen exporteren of leden wijzigen.

Spreek voor elke bewerking vier elementen met de business af:

• De beschermde resource en actie.
• De profielen die deze kunnen aanvragen.
• De toepasselijke datareikwijdte: organisatie, eenheid, eigenaar, portefeuille of toewijzing.
• De context- en statusvoorwaarden: actieve organisatie, geldige delegatie, openingstijden of document in conceptstatus.

De resulterende matrix is niet de autorisatiecode, maar een controleerbare specificatie. Bovendien dwingt deze ertoe openstaande beslissingen te identificeren. Als wordt aangegeven dat support “bestellingen kan bekijken”, moet worden verduidelijkt of het persoonsgegevens, bijlagen, gesloten bestellingen of informatie van alle organisaties kan bekijken.

Geef de voorkeur aan kleine en stabiele acties

Een te brede actie bundelt privileges en maakt het moeilijk om het principe van minimale privileges toe te passen. Het scheiden van order.read en order.export, of van user.update en user.assign_role, maakt het mogelijk toegang nauwkeurig toe te kennen. Het is evenmin raadzaam om voor elk afzonderlijk geval een recht te creëren: als het verschil van de resource afhangt, is het doorgaans een beleidsvoorwaarde en geen nieuwe rol.

Kiezen tussen rollen, rechten, attributen en context

Eenvoudige rollen werken wanneer er weinig stabiele profielen zijn en bewerkingen nauwelijks van de gegevens afhangen. Ze vormen een goed startpunt, maar worden kwetsbaar als namen als manager_met_export of supervisor_alleen_eenheid_noord verschijnen. Die combinaties coderen uitzonderingen als permanente profielen.

Expliciete rechten zijn geschikt om verantwoordelijkheden van profielen los te koppelen en capaciteiten beheerbaar toe te kennen. Attributen zijn nuttig wanneer de beslissing afhangt van eigenschappen van het subject, de resource of de omgeving: organisatie, eenheid, classificatie, eigenaar, land of risiconiveau. Contextregels vullen het model aan wanneer tijdelijke voorwaarden meespelen, zoals een actieve delegatie of de goedkeuringsfase.

In de praktijk is een hybride model doorgaans beter onderhoudbaar: rollen verlenen basisrechten; een beleid evalueert attributen van de gebruiker en de resource; en de context levert de geselecteerde organisatie of het operationele kanaal. De rol mag de analyse van de gegevens niet vervangen.

Beleiden centraliseren en gegevens vanaf de bron filteren

Een PHP-applicatie heeft een consistent punt nodig om beslissingen uit te drukken. Dit kan worden vormgegeven in policyklassen, autorisatieservices of equivalente componenten van het gekozen framework. Het belangrijkste is dat controllers om een beslissing vragen en dat views niet de enige barrière zijn.

if (!$authorizer->can($actor, 'order.approve', $order, $context)) {
    throw new AccessDeniedException();
}

Het beleid mag alleen de gegevens ontvangen die nodig zijn om te beslissen: identiteit, bewerking, resource en context. Vermijd het raadplegen van globale variabelen of impliciete afhankelijkheid van de huidige route; dat maakt regels moeilijk te testen en te hergebruiken.

Een afzonderlijke controle volstaat niet op lijstschermen. Als een query bestellingen van meerdere organisaties retourneert en de interface sommige daarna verbergt, heeft er al blootstelling plaatsgevonden. Pas de reikwijdte toe in de repository of querylaag: filter op geautoriseerde organisatie, toegestane eenheid of toegewezen portefeuille voordat resultaten worden geladen. Controleer voor resources op identificator zowel de bewerking als het behoren van de resource.

Statussen en overgangen als onderdeel van het beleid

Gevoelige bewerkingen hangen vaak af van de status. Een goedkeurder kan een openstaande bestelling goedkeuren, maar geen geannuleerde of reeds goedgekeurde bestelling. Modelleer de toegestane overgang expliciet en valideer opnieuw op het punt waar de wijziging wordt opgeslagen. De interface kan een knop uitschakelen als leidraad, maar het serverbeleid is de effectieve controle.

Permanente uitzonderingen en onthullende weigeringen vermijden

Generieke rollen zoals “beheerder” hebben duidelijke grenzen nodig. Een beheerder van een organisatie mag niet automatisch platformbeheerder worden. Evenzo moet een uitzondering zoals “mag dit specifieke record bewerken” een eigenaar, reden, beoordelingsdatum of vervaldatum en traceerbaarheid hebben. Als dit zich herhaalt, ontbreekt waarschijnlijk een bedrijfsregel of een attribuut in het model.

Weigeringen moeten nuttig zijn zonder gevoelige informatie prijs te geven. Voor een rechtstreekse query op een resource van een andere partij heeft een antwoord dat niet te onderscheiden is van het antwoord dat de resource niet bestaat doorgaans de voorkeur. Bij een actie op een reeds zichtbare resource kan worden aangegeven dat rechten ontbreken, zonder interne regels, toewijzingen of beschermde attributen te detailleren.

Leg geautoriseerde en geweigerde gevoelige acties vast wanneer dat operationele waarde toevoegt: rolwijzigingen, exports, goedkeuringen, gedelegeerde toegang en configuratiewijzigingen. De audit moet actor, actie, resource, organisatie of context, tijdstip en resultaat bevatten. Leg geen credentials, tokens of onnodige persoonsgegevens vast.

Autorisatie testen als een producteigenschap

Autorisatietests moeten toegestane en geweigerde beslissingen dekken. Een minimale testset omvat: een gebruiker met een recht binnen zijn organisatie; dezelfde gebruiker bij een andere organisatie; een gebruiker zonder recht; een resource in een ongeldige status; en een contextwijziging, zoals het intrekken van een toewijzing of het beëindigen van een delegatie.

Test de beleidsregels rechtstreeks, omdat ze nauwkeurige diagnoses bieden, en voeg integratietests toe om te bevestigen dat routes, controllers, queries en schrijfbewerkingen de beslissing toepassen. De gevaarlijkste regressies zijn privilege-regressies: het toevoegen van een rol, een route of een queryoptimalisatie die onbedoeld de toegang verruimt.

• Controleer dat een lijst geen resources buiten de reikwijdte bevat.
• Controleer dat kennis van een identificator buiten de eigen bevoegdheid geen toegang verleent.
• Controleer dat een statuswijziging het bijbehorende beleid vereist.
• Controleer dat het intrekken van een recht de capaciteit bij het volgende verzoek ongeldig maakt.

Het model invoeren in een applicatie met verspreide regels

Het is niet nodig om het volledige systeem te herschrijven. Begin met het inventariseren van routes, commando's, geplande taken en exportpunten die gegevens wijzigen of blootstellen. Geef prioriteit aan acties met grote impact en resources die tussen organisaties worden gedeeld. Haal per domein één beleid eruit, dek het huidige gedrag met tests af en corrigeer de regels die meer toegang verlenen dan voorzien.

Vervang vervolgens verspreide controles door aanroepen naar de autorisatieservice en verplaats het filteren op reikwijdte naar de queries. Beoordeel periodiek ongebruikte rechten, rollen met te veel capaciteiten, verlopen delegaties en actieve uitzonderingen. Het ontwerp van rechten en autorisatie in PHP is onderhoudbaar wanneer een nieuwe functionaliteit vóór de ontwikkeling kan beantwoorden wie handelt, op welke resource, onder welke voorwaarden en met welk bewijs dit is gecontroleerd.

Checklist voor elke nieuwe module

• Zijn de bedrijfsbewerkingen en hun resources gedefinieerd?
• Maakt de matrix onderscheid tussen recht, reikwijdte en statusvoorwaarde?
• Worden de beleidsregels toegepast bij lezen, schrijven, export en niet-interactieve processen?
• Filteren queries gegevens voordat ze aan de interface worden geleverd?
• Zijn er tests voor toegestane, geweigerde en organisatieoverschrijdende toegang?
• Leveren gevoelige acties een proportionele en veilige audit op?