Überprüfbare Autorisierung in PHP: Berechtigungen ohne Ausnahmen

Das Design von Berechtigungen und Autorisierung in PHP lässt sich nicht mit einer Oberfläche lösen, in der Profile zugewiesen werden. Das Problem entsteht, wenn dieselbe Aktion davon abhängt, wer sie ausführt, für welche Organisation diese Person arbeitet, auf welche Daten sie zugreift und in welchem Zustand sich diese Daten befinden. Wenn diese Bedingungen über Controller, Abfragen, Templates und Validierungen der Benutzeroberfläche verteilt sind, sammelt das System schließlich schwer überprüfbare Ausnahmen an.

Ziel sollte sein, dass jede Entscheidung explizit, wiederholbar und überprüfbar ist: Eine Identität versucht, innerhalb eines Kontexts eine Operation an einer Ressource auszuführen, und eine Richtlinie entscheidet, ob sie erlaubt ist. Dieser Ansatz wandelt mehrdeutige operative Regeln in technische Kontrollen um, die Produkt, Betrieb und Entwicklung gemeinsam überprüfen können.

Identität, Autorisierung und Datenumfang trennen

Die Authentifizierung beantwortet, wer der Benutzer ist: Sitzung, Anmeldedaten, Identitätsanbieter oder Token. Die Autorisierung beantwortet, was diese Identität tun darf. Es ist nicht ratsam, Letztere ausschließlich aus Ersterer abzuleiten oder beide als eine einzige Schicht zu behandeln.

Eine Rolle bündelt Verantwortlichkeiten, etwa Organisationsadministrator, Supportmitarbeiter oder Genehmiger. Eine Berechtigung steht für eine konkrete Operation, beispielsweise invoice.read, invoice.approve oder member.invite. Der Umfang bestimmt, für welche Ressourcen diese Operation gilt: Rechnungen einer Organisation, Akten einer Einheit oder eigene Datensätze.

Diese Unterscheidung vermeidet einen häufigen Fehler: Die Berechtigung zum Lesen von Rechnungen zu erteilen und anzunehmen, dass dadurch jede Rechnung gelesen werden darf. Die Richtlinie muss weiterhin prüfen, ob die Ressource zur aktiven Organisation gehört, ob dem Benutzer die entsprechende Einheit zugewiesen ist und ob der Zustand der Ressource die angeforderte Aktion zulässt.

Eine Zugriffsmatrix aus Operationen erstellen

Bevor Sie Klassen oder Pakete auswählen, führen Sie die tatsächlichen Ressourcen und Operationen auf. Verwenden Sie Geschäftsverben statt vager Bezeichnungen wie „verwalten“: Bestellung erstellen, Bestellung anzeigen, Entwurf korrigieren, Bestellung genehmigen, Bestellung stornieren, Bestellungen exportieren oder Mitglieder ändern.

Vereinbaren Sie für jede Operation mit dem Fachbereich vier Elemente:

• Die Ressource und die geschützte Aktion.
• Die Profile, die sie anfordern können.
• Den anwendbaren Datenumfang: Organisation, Einheit, Eigentümer, Portfolio oder Zuweisung.
• Die Kontext- und Zustandsbedingungen: aktive Organisation, gültige Delegation, Betriebszeit oder Dokument im Entwurf.

Die resultierende Matrix ist nicht der Autorisierungscode, sondern eine überprüfbare Spezifikation. Zudem zwingt sie dazu, offene Entscheidungen zu erkennen. Wenn angegeben wird, dass der Support „Bestellungen anzeigen“ darf, muss präzisiert werden, ob er personenbezogene Daten, Anhänge, abgeschlossene Bestellungen oder Informationen aller Organisationen sehen darf.

Kleine und stabile Aktionen bevorzugen

Eine zu weit gefasste Aktion bündelt Privilegien und erschwert die Anwendung des Prinzips der geringsten Rechte. Die Trennung von order.read und order.export oder von user.update und user.assign_role ermöglicht eine präzise Zugriffsvergabe. Es ist auch nicht ratsam, für jeden Einzelfall eine Berechtigung anzulegen: Hängt der Unterschied von der Ressource ab, ist er meist eine Bedingung der Richtlinie und keine neue Rolle.

Zwischen Rollen, Berechtigungen, Attributen und Kontext wählen

Einfache Rollen funktionieren, wenn es wenige stabile Profile gibt und die Operationen kaum von den Daten abhängen. Sie sind ein guter Einstieg, werden jedoch fragil, wenn Namen wie manager_con_exportacion oder supervisor_solo_unidad_norte auftauchen. Solche Kombinationen kodieren Ausnahmen als dauerhafte Profile.

Explizite Berechtigungen eignen sich, um Verantwortlichkeiten von Profilen zu entkoppeln und Fähigkeiten verwaltbar zuzuweisen. Attribute sind geeignet, wenn die Entscheidung von Eigenschaften des Subjekts, der Ressource oder der Umgebung abhängt: Organisation, Einheit, Klassifizierung, Eigentümer, Land oder Risikostufe. Kontextregeln ergänzen das Modell, wenn vorübergehende Bedingungen beteiligt sind, etwa eine aktive Delegation oder die Genehmigungsphase.

In der Praxis ist ein hybrides Modell meist wartbarer: Rollen gewähren Basisberechtigungen; eine Richtlinie bewertet Attribute des Benutzers und der Ressource; und der Kontext liefert die ausgewählte Organisation oder den Operationskanal. Die Rolle darf die Analyse der Daten nicht ersetzen.

Richtlinien zentralisieren und Daten an der Quelle filtern

Eine PHP-Anwendung benötigt einen konsistenten Ort, um Entscheidungen auszudrücken. Dieser kann in Richtlinienklassen, Autorisierungsdiensten oder gleichwertigen Komponenten des gewählten Frameworks umgesetzt werden. Wichtig ist, dass Controller eine Entscheidung anfordern und Ansichten nicht die einzige Schranke sind.

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

Die Richtlinie sollte nur die Daten erhalten, die für die Entscheidung erforderlich sind: Identität, Operation, Ressource und Kontext. Vermeiden Sie Abfragen globaler Variablen oder eine implizite Abhängigkeit von der aktuellen Route; dadurch werden Regeln schwer testbar und wiederverwendbar.

Die Einzelprüfung reicht auf Listenansichten nicht aus. Wenn eine Abfrage Bestellungen mehrerer Organisationen zurückgibt und die Benutzeroberfläche anschließend einige ausblendet, hat bereits eine Offenlegung stattgefunden. Wenden Sie den Umfang im Repository oder in der Abfrageschicht an: Filtern Sie nach autorisierter Organisation, erlaubter Einheit oder zugewiesenem Portfolio, bevor Ergebnisse geladen werden. Prüfen Sie bei Ressourcen per Kennung sowohl die Operation als auch die Zugehörigkeit der Ressource.

Zustände und Übergänge als Teil der Richtlinie

Sensible Operationen hängen häufig vom Zustand ab. Ein Genehmiger kann eine ausstehende Bestellung genehmigen, aber keine stornierte und keine bereits genehmigte. Modellieren Sie den erlaubten Übergang explizit und validieren Sie erneut an der Stelle, an der die Änderung persistiert wird. Die Benutzeroberfläche kann zur Orientierung eine Schaltfläche deaktivieren, aber die Serverrichtlinie ist die wirksame Kontrolle.

Dauerhafte Ausnahmen und aufschlussreiche Ablehnungen vermeiden

Generische Rollen wie „Administrator“ benötigen klare Grenzen. Ein Administrator einer Organisation sollte nicht automatisch zum Administrator der Plattform werden. Ebenso muss eine Ausnahme wie „darf diesen konkreten Datensatz bearbeiten“ einen Eigentümer, einen Grund, ein Prüfdatum oder Ablaufdatum sowie Nachvollziehbarkeit haben. Wiederholt sie sich, fehlt wahrscheinlich eine Geschäftsregel oder ein Attribut im Modell.

Ablehnungen müssen nützlich sein, ohne sensible Informationen preiszugeben. Bei einer direkten Abfrage einer fremden Ressource ist normalerweise eine Antwort vorzuziehen, die nicht von der Antwort unterscheidbar ist, dass die Ressource nicht existiert. Bei einer Aktion auf einer bereits sichtbaren Ressource kann angegeben werden, dass Berechtigungen fehlen, ohne interne Regeln, Zuweisungen oder geschützte Attribute näher auszuführen.

Protokollieren Sie autorisierte und abgelehnte sensible Aktionen, wenn sie operativen Nutzen bieten: Rollenänderungen, Exporte, Genehmigungen, delegierte Zugriffe und Konfigurationsänderungen. Die Auditierung muss Akteur, Aktion, Ressource, Organisation oder Kontext, Zeitpunkt und Ergebnis enthalten. Protokollieren Sie keine Anmeldedaten, Tokens oder unnötigen personenbezogenen Daten.

Autorisierung als Produkteigenschaft testen

Autorisierungstests müssen erlaubte und abgelehnte Entscheidungen abdecken. Eine Mindestsuite umfasst: einen Benutzer mit Berechtigung für seine Organisation; denselben Benutzer gegenüber einer anderen Organisation; einen Benutzer ohne Berechtigung; eine Ressource in einem ungültigen Zustand; und eine Kontextänderung, etwa das Entziehen einer Zuweisung oder das Beenden einer Delegation.

Testen Sie Richtlinien direkt, weil sie präzise Diagnosen liefern, und ergänzen Sie Integrationstests, um zu bestätigen, dass Routen, Controller, Abfragen und Schreiboperationen die Entscheidung anwenden. Die gefährlichsten Regressionen sind Privilegienregressionen: das Hinzufügen einer Rolle, einer Route oder einer Abfrageoptimierung, die den Zugriff unbeabsichtigt erweitert.

• Prüfen Sie, dass eine Liste keine Ressourcen außerhalb des Umfangs enthält.
• Prüfen Sie, dass die Kenntnis einer fremden Kennung keinen Zugriff gewährt.
• Prüfen Sie, dass eine Zustandsänderung die entsprechende Richtlinie erfordert.
• Prüfen Sie, dass das Entziehen einer Berechtigung die Fähigkeit bei der nächsten Anfrage ungültig macht.

Das Modell in einer Anwendung mit verteilten Regeln übernehmen

Es ist nicht notwendig, das gesamte System neu zu schreiben. Beginnen Sie damit, Routen, Befehle, geplante Aufgaben und Exportpunkte zu inventarisieren, die Daten ändern oder offenlegen. Priorisieren Sie Aktionen mit hoher Auswirkung und Ressourcen, die zwischen Organisationen geteilt werden. Extrahieren Sie eine Richtlinie pro Domäne, decken Sie das aktuelle Verhalten mit Tests ab und korrigieren Sie Regeln, die mehr Zugriff als vorgesehen gewähren.

Ersetzen Sie anschließend verteilte Prüfungen durch Aufrufe des Autorisierungsdienstes und verlagern Sie die Umfangsfilterung in die Abfragen. Überprüfen Sie regelmäßig ungenutzte Berechtigungen, Rollen mit zu vielen Fähigkeiten, abgelaufene Delegationen und aktive Ausnahmen. Das Design von Berechtigungen und Autorisierung in PHP wird wartbar sein, wenn eine neue Funktionalität vor ihrer Entwicklung beantworten kann, wer agiert, auf welcher Ressource, unter welchen Bedingungen und mit welchen Nachweisen dies geprüft wurde.

Checkliste für jedes neue Modul

• Sind die Geschäftsoperationen und ihre Ressourcen definiert?
• Unterscheidet die Matrix Berechtigung, Umfang und Zustandsbedingung?
• Werden die Richtlinien bei Lesen, Schreiben, Export und nicht interaktiven Prozessen angewendet?
• Filtern die Abfragen Daten, bevor sie an die Benutzeroberfläche übergeben werden?
• Gibt es Tests für erlaubten, abgelehnten und organisationsübergreifenden Zugriff?
• Hinterlassen sensible Aktionen eine angemessene und sichere Auditierung?